Subject: Re:

From: Spam Blocker <[email-masked]>
Date: Mon, 3 Jan 2022 13:29:26 -0700

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.

---

From: Martin Duke <[email-masked]>
Date: Mon, 3 Jan 2022 17:23:59 -0800

Hi Kyle,

The first step in a proposal is to write an individual internet draft that
explains it. The first draft need not cover every detail.

Home | Internet-Draft Author Resources (Under development) (ietf.org)
<https://authors.ietf.org/en/home>

That said, the means of negotiating the key between the two endpoints seems
like the hardest problem to solve, and deserves some thought. Furthermore,
you should consider if IPSec largely covers your use case. If not, simply
negotiating an alternate ephemeral port to use seems like a simpler
solution.

Regards,
Martin Duke
Transport Area Director.

On Mon, Jan 3, 2022 at 12:50 PM Spam Blocker <[email-masked]> wrote:

> snoop, block, or spoof these services.  This RFC is meant to eliminate
> the ability of intermediate entities to attach a specific service by
> packet.  Then the ‘side stack’ will send the decrypted packet up the
> stack as a normal frame.
>
>
>

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 3 Jan 2022 18:02:45 -0800

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-masked]> 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.
> 
> 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.