Re:

[Martin Duke <[e-mail]>]

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 <[e-mail]> 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.
>