Network Working Group K. Unice Internet-Draft Anonymous Intended status: Standards Track 4 February 2022 Expires: 8 August 2022Privatization of service type in IPv4/IPv6 data flows draft-unice-dispatch-enc-ports-00
Abstract
The internet and free flow of information has enabled the individual in society several advantages that have not been available in the past. The free flow of information has enabled social and political changes, open education for students, and now the free-flow of money without the need for intermediate institutions. This free flow of information etc. is continually under attack from institutions that are compromised by the Internet. So these institutions have and continue to implement controls in an attempt to stop the empowerment of the individual. These controls on information is what this RFC attempts to weaken.
Status of This Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 August 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Unice Expires 8 August 2022 [Page 1]
Internet-Draft Encrypted Ports February 2022
Table of Contents1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Implementation . . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Rationale
The socket number in data flows across the internet is usually tied to a specific service type. This is a security flaw in that flows can be intercepted, denied, or compromised by using the socket number in the IP packet. This RFC is to enable IP data flows across the internet to hide the type of service being provided from intermediate routers etc. This will enable internet software developers to build applications that cannot be subjected to censorship. This also prevents intermediate points from profiling certain applications.There are well known sockets (ports 0-1023) that are assigned to specific services (i.e. 80 is HTTP, 443 is HTTPS, 25 is SMTP, etc.). Other ports (1024-49151) are registered ports that can be reserved with IANA. Having well known ports for specific services enables intermediate routers etc. to snoop, block, or spoof these services. This RFC is meant to eliminate the ability of intermediate entities to attach a specific service by controlling the port used by a service in their routers.
2. Approach
This specification can accept and adopt recommendations for technical approaches as long as the recommendations maintain the final goal of this RFC. The final goal is to prevent intermediate internet providers from filtering and stopping a specific service.
3. Design
There are options as to how the receiving IP stack can determine if the IPv4/6 header has the ports portion encrypted. A. This Secured Service Type (SST) feature will start with a new (0th bit in the Flags header) in the IPv4 header that will indicate that the packet is encrypted at the point that the IPv4 header ends and the TCP/UDP header starts.
Unice Expires 8 August 2022 [Page 2]
Internet-Draft Encrypted Ports February 2022
B. The Traffic class field of IPv6 could have a number or bit reserved for SST.
4. Implementation
The IPv4/v6 stack will implement a "side stack" that will implement the decryption when the received flow has the bit set indicating a SST type packet. The "side stack" module will be passed inbound packets and will determine if the header has its ports encrypted. If so, then it will decrypt the rest of the portion of the IPv4/v6 packet header just after reception from the network controller and send the decrypted packet up the stack as a normal frame.As part of the usual "sockets" programming API ( socket, bind, connect, send, receive, etc. ) there will be an additional enumeration for the setsockopt API that will indicate the header will be partially encrypted and have the destination and source ports unreadable. Applications that want to obscure the service type will indicate in the APIs that the UDP packet be encrypted using SST, and to establish a TCP connection using SST.
Unice Expires 8 August 2022 [Page 3]
Internet-Draft Encrypted Ports February 2022
+--------------+
|Standard V4/V6|
|Software Stack+-----+
+-+------------+ |C
| ^ |
| | v
| +----+----------+
D| B | SST |
| |Encryption|
| +-+--------+
| | ^
v v |
+-----------------+ |A
|Network Interface+----+
|Software Driver |
+--+-------^------+
| |
+--v-------+------+
|Network Interface|
|Hardware |
+-----------------+
Figure describing the SST software function(A) All ingressing packets are sent to the SST software module. Both packets using SST and packets that are not using SST are passed to the SST module. Traffic that is using SST is decrypted and sent up the stack (B). Traffic that is not using SST is passed up the stack, without any change (B).
( C ) Egressing traffic checks the socket control structure for this socket. The SST module encrypts the ports section of the IPv4/v6 socket using its private key. ( D ) is for traffic that is not using SST and is passing the destination socket in clear text.
5. Security Considerations
There has to be an initial key acquisition in order for the initial traffic between the user and the domain server to be able to encrypt the ports section of the IPv4/v6 header.The initial idea would be that the DNS resolution of the domain name would include a public key as part of the response mapping the DNS ascii name to an IPv4/v6 address. The user would then use the domain server's public key to encrypt the portion of the IPv4/v6 header that contains the destination port. This first packet from the user sent to the domain server will have the destination port encrypted.
Unice Expires 8 August 2022 [Page 4]
Internet-Draft Encrypted Ports February 2022 6. IANA ConsiderationNone
Appendix A. Acknowledgments
TODOAuthor's Address
Kyle Unice Anonymous
Email: kspambot@gmail.com
Unice Expires 8 August 2022 [Page 5]
