Service numbers don’t have to be ‘public’; per RFC 7605 Sec 5, port numbers have true meaning as a service ID only at endpoints. Everywhere else, they are have *assumed* meanings at best.
You can decouple the port number use as a connection demultiplexer from its use as a service type via the Service Number Option (https://datatracker.ietf.org/doc/draft-touch-tcpm-sno/09/ <https://datatracker.ietf.org/doc/draft-touch-tcpm-sno/09/>, which is planned as an individual experimental doc eventually). Joe — Joe Touch, temporal epistemologist www.strayalpha.com > On Jan 3, 2022, at 12:29 PM, Spam Blocker <[email protected]> wrote: > > 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.
