Skip to main content

Privatization of service type in IPv4/IPv6 data flows
draft-unice-dispatch-enc-ports-00

Document Type Active Internet-Draft (individual)
Author Kyle Unice
Last updated 2022-02-07
Stream (None)
Intended RFC status (None)
Formats plain text htmlized pdfized bibtex
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-unice-dispatch-enc-ports-00
Network Working Group                                           K. Unice
Internet-Draft                                                 Anonymous
Intended status: Standards Track                         4 February 2022
Expires: 8 August 2022

         Privatization of service type in IPv4/IPv6 data flows
                   draft-unice-dispatch-enc-ports-00

Abstract

   The internet and free flow of information has enabled the individual
   in society several advantages that have not been available in the
   past.  The free flow of information has enabled social and political
   changes, open education for students, and now the free-flow of money
   without the need for intermediate institutions.  This free flow of
   information etc. is continually under attack from institutions that
   are compromised by the Internet.  So these institutions have and
   continue to implement controls in an attempt to stop the empowerment
   of the individual.  These controls on information is what this RFC
   attempts to weaken.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 8 August 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights

Unice                     Expires 8 August 2022                 [Page 1]
Internet-Draft               Encrypted Ports               February 2022

   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Approach  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Design  . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Implementation  . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Consideration  . . . . . . . . . . . . . . . . . . . . .   5
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  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.

2.  Approach

   This specification can accept and adopt recommendations for technical
   approaches as long as the recommendations maintain the final goal of
   this RFC.  The final goal is to prevent intermediate internet
   providers from filtering and stopping a specific service.

3.  Design

   There are options as to how the receiving IP stack can determine if
   the IPv4/6 header has the ports portion encrypted.

Unice                     Expires 8 August 2022                 [Page 2]
Internet-Draft               Encrypted Ports               February 2022

   A.  This Secured Service Type (SST) feature will start with a new
   (0th bit in the Flags header) in the IPv4 header that will indicate
   that the packet is encrypted at the point that the IPv4 header ends
   and the TCP/UDP header starts.

   B.  The Traffic class field of IPv6 could have a number or bit
   reserved for SST.

4.  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.  The "side stack" module will be passed inbound
   packets and will determine if the header has its ports encrypted.  If
   so, then it will decrypt the rest of the portion of the IPv4/v6
   packet header just after reception from the network controller and
   send the decrypted packet up the stack as a normal frame.

   As part of the usual "sockets" programming API ( socket, bind,
   connect, send, receive, etc. ) there will be an additional
   enumeration for the setsockopt API that will indicate the header will
   be partially encrypted and have the destination and source ports
   unreadable.  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.

Unice                     Expires 8 August 2022                 [Page 3]
Internet-Draft               Encrypted Ports               February 2022

   +--------------+
   |Standard V4/V6|
   |Software Stack+-----+
   +-+------------+     |C
     |      ^           |
     |      |           v
     |      +----+----------+
    D|      B    |  SST     |
     |           |Encryption|
     |           +-+--------+
     |             |      ^
     v             v      |
   +-----------------+    |A
   |Network Interface+----+
   |Software Driver  |
   +--+-------^------+
      |       |
   +--v-------+------+
   |Network Interface|
   |Hardware         |
   +-----------------+

   Figure describing the SST software function

   (A) All ingressing packets are sent to the SST software module.  Both
   packets using SST and packets that are not using SST are passed to
   the SST module.  Traffic that is using SST is decrypted and sent up
   the stack (B).  Traffic that is not using SST is passed up the stack,
   without any change (B).

   ( C ) Egressing traffic checks the socket control structure for this
   socket.  The SST module encrypts the ports section of the IPv4/v6
   socket using its private key.  ( D ) is for traffic that is not using
   SST and is passing the destination socket in clear text.

5.  Security Considerations

   There has to be an initial key acquisition in order for the initial
   traffic between the user and the domain server to be able to encrypt
   the ports section of the IPv4/v6 header.

   The initial idea would be that the DNS resolution of the domain name
   would include a public key as part of the response mapping the DNS
   ascii name to an IPv4/v6 address.  The user would then use the domain
   server's public key to encrypt the portion of the IPv4/v6 header that
   contains the destination port.  This first packet from the user sent
   to the domain server will have the destination port encrypted.

Unice                     Expires 8 August 2022                 [Page 4]
Internet-Draft               Encrypted Ports               February 2022

6.  IANA Consideration

   None

Appendix A.  Acknowledgments

   TODO

Author's Address

   Kyle Unice
   Anonymous

   Email: kspambot@gmail.com

Unice                     Expires 8 August 2022                 [Page 5]