Spam Blocker <kspambot@gmail.com> Mon, 03 January 2022 20:29 UTC

MIME-Version: 1.0
From: Spam Blocker <kspambot@gmail.com>
Date: Mon, 03 Jan 2022 13:29:26 -0700
Message-ID: <CAHHQuSh2YE+PNB=EOXDex8P=sGGm0TBh3jaOtGgTTktM0WjbvQ@mail.gmail.com>
Subject:
To: tsv-area@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001cef8c05d4b361a1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-area/sImynyaxWUJzp3iSFL0SU-oK9as>
Precedence: list

 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.

Spam Blocker
Re: Martin Duke
Re: touch@strayalpha.com