This would be a matter for the Security Area rather than the Transport Area, and I would suggest first consulting RFC 4303, IP Encapsulating Security Payload (ESP), to understand how this problem has been addressed in the past. RFC 4303 is one of a number of RFCs that specify the IPsec protocol suite – RFC 6071, IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap, and the documents page for the IP Security Maintenance and Extensions (ipsecme) Working Group (WG) can help locate the others that are relevant.
RFC 4303: https://www.rfc-editor.org/info/rfc4303 RFC 6071: https://www.rfc-editor.org/info/rfc6071 ipsecme WG Documents: https://datatracker.ietf.org/wg/ipsecme/documents/ Thanks, --David From: tsv-area <[email protected]> On Behalf Of Spam Blocker Sent: Monday, January 3, 2022 3:29 PM To: [email protected] Subject: [EXTERNAL EMAIL] Dear Sirs, I would like to submit a suggestion for an RFC. I have included a rough description on the RFC below in this email. Please advise on if this is acceptable and what the next steps might be. Regards, Kyle RFC – Privatization of service type in IPv4/IPv6 data flows 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. Design: This Secured Service Type (SST) feature will start with a new (0th bit in the Flags header) in the IPv4/v6 header that will indicate that the packet is encrypted at the point that the IPv4/v6 header ends and the TCP/UDP header starts. 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. Then the ‘side stack’ will send the decrypted packet up the stack as a normal frame. 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.
