One document matched: draft-shepard-tcp-reassign-port-number-00.txt

Network Working Group                                        Tim Shepard
INTERNET DRAFT                                             July 12, 2004
Expires: January 13, 2005


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.


                    Reassign Port Number option for TCP
               draft-shepard-tcp-reassign-port-number-00.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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 a "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


Abstract

   Most TCP connections are protected from spoofing attacks from off-
   path attackers by their obscurity.  This memo suggests that the few
   TCP connections that aren't so protected today may be protected by
   making them obscure by using random values for both port numbers.
   The obvious difficulty with this approach is that the well-known port



Shepard                 Expires January 13, 2005                [Page 1]

draft-shepard-tcp-reassign-port-number-00.txt                  July 2004


   number is required on the initial SYN to connect to the desired
   service.  A TCP option is proposed which can be used during the SYN
   and SYN-ACK exchange to request (and accomplish) reassignment of the
   well known port number to a random value.

Introduction

   Communication on the Internet today typically involves no end-to-end
   cryptography and is therefore secured only as much as the entire path
   of routers and links between the two communicating parties is
   secured.  More robust methods of securing end-to-end communication
   involving cryptography have been developed but have only seen limited
   deployment.  Most communication on the Internet today remains
   vulnerable to an attacker who is located somewhere along the path of
   communication.

   In the past few months a vulnerability of TCP connections to an off-
   path attacker has raised concern.  An attacker who merely knows of or
   can surmise the existence of an active TCP connection can inject
   packets into the connection with forged source addresses (making
   packets arrive at one host with a source address which makes it
   appear to have come from the other host), disrupting communication in
   a variety of ways.  These injected packets could come from distant
   parts of the Internet, and tracing the true origin of packets with
   forged source addresses can be difficult.

   Even if the attacker's knowledge of the existence of the connection
   is imperfect, the attacker may cover the unknown space rather quickly
   by injecting many packets covering all of the possibilities.

   To know completly of the existence of a TCP connection, an attacker
   would need to know the IP addresses of the two endpoints and the two
   16-bit TCP port numbers in use by the TCP connection.  If this much
   is known to an attacker, then the only hurdle remaining for the
   attacker's forged packets is the sequence number acceptability test
   where the 32-bit sequence number in the TCP header of the arriving
   packet is tested to see if it is in-window.

   The RFC1323 window scale option, makes the fraction of TCP sequence
   space that is acceptable potentially quite large (as much as 1/4 of
   the 32-bit sequence number space).

   The RFC1323 timestamp option would seem to help, but packets without
   the RFC1323 timestamp option can still cause disruption---RSTs
   without a timestamp option generally need to be accepted and
   processed (e.g. in case a dialup user hangs up and a new dialup user
   sends RSTs in response to arriving TCP packets).  Also note that no
   known implementations include a timestamp option on RST packets.



Shepard                 Expires January 13, 2005                [Page 2]

draft-shepard-tcp-reassign-port-number-00.txt                  July 2004


   In most cases, TCP connections as implemented and used by
   applications today are robust against spoofing attacks simply because
   the attacker has no way of learning or knowing of the existence of
   the TCP connection (identified by the two IP addresses and the two
   16-bit port numbers).  The vulnerability comes when the off-path
   attacker can, for a long-lived TCP connection, obtain or surmise the
   IP addresses and port numbers involved, or sufficiently narrow the
   possibilities so that the search space is small enough to allow the
   attacker to exhaustively enumerate the remaining possibilities.  In
   particular, this can happen if the IP addresses involved and one of
   the port numbers are known, leaving only one 16-bit port number
   unknown.  In the case of some services listening on a well-known port
   (such as BGP, SSH, or XMPP), this situation is typical.


   This memo suggest that the way to secure TCPs from spoofed packets
   sent by off-path attackers is:

        1. Don't reveal the port numbers, and

        2. Use good random values for both port numbers.

   The difficulty with doing this today is that typically a well-known
   port number is used to find the server, and this would be difficult
   to change.  The remainder of this memo describes a TCP option which
   can be used to negotiate a reassignment of the well-known port number
   to a randomly assigned value as part of the SYN/SYN-ACK handshake
   that occurs at the beginning of the connection.

The Reassign Port Number option carried on the SYN

   A client wishing to have the server reassign the well-known port
   number to a random value may include a Reassign Port Number option on
   the segment that carries the SYN.

                   +---------+---------+
                   | Kind=99 |Length=2 |
                   +---------+---------+

   (note: 99 is here as a place holder until an IANA assignment)

   This option requests that the server reassign the port it will use
   for this connection to a random value.  The Destination Port field in
   the TCP header itself will carry the normal well-known port number on
   which the server is expected to be listening.

   If the server does not implement this option, it will be ignored, and
   the TCP connection will continue without any reassignment of port



Shepard                 Expires January 13, 2005                [Page 3]

draft-shepard-tcp-reassign-port-number-00.txt                  July 2004


   numbers.

The Reassign Port Number option carried on the SYN ACK

   If a server receives a SYN carrying the Reassign Port Number option,
   then it will (as usual) use the Destination Port field in the segment
   carrying the SYN to identify which listening socket it should be
   associated with, but when creating the established socket, it may (if
   it implements this option) reassign a random value to the local port
   number, and return a SYN ACK with the newly assigned port number, and
   include the Reassign Port Number option with the SYN ACK:

                   +---------+---------+---------+---------+
                   | Kind=99 |Length=4 | original port num |
                   +---------+---------+---------+---------+

   (note: 99 is here as a place holder until an IANA assignment)

   This SYN ACK will be received by the host that sent the SYN with the
   Reassign Port Number request, and will have a pair of port numbers in
   the TCP header which will not correspond to the port numbers in any
   connection block the host has.  The option, however, will provide the
   client with the original port number of the server and allow the
   connection block to be found.    The client should process this
   option on a SYN ACK when it fails to find a corresponding connection
   block for TCP segment with both the SYN and ACK control bits turned
   on.  If the ACK of the client's SYN is correct, then the connection
   block on the client can have the foreign port number overwritten with
   the Source Port number from the TCP header.

   Note that until the server receives an ACK of its SYN, and for some
   time after that, it will need to be prepared to process any received
   retransmissions of the original SYN which would still be directed at
   the listening port number, and the server MUST ensure that the
   processing of any such duplicate SYNs gets the same reassignment,
   even if the duplicate SYNs do not carry the Reassign Port Number
   option.

Steps a client may take to ensure robustness

   The client MAY, upon any retransmission of the SYN, try removing the
   Reassign Port Number option.  A better strategy to cope with a broken
   path (e.g. containing a NAT or some other connection tracking
   middlebox that does not understand the remapping) would be for the
   client, upon failure to establish a connection with the Reassign Port
   Number option, would be to retry the connection from a new port
   number without the Reassign Port Number option.




Shepard                 Expires January 13, 2005                [Page 4]

draft-shepard-tcp-reassign-port-number-00.txt                  July 2004


   Implementors should carefully consider whether or not this option
   should be on by default for all TCP connections.  Most TCP
   connections are already protected by their natural obscurity and/or
   short lifetime.  Setting this option on by default in a general
   purpose operating system would probably cause many more failed
   connections due to the meddling of middleboxes than connections saved
   from spoofing attacks.  In other words, there is potential to do more
   harm then good.

   Applications (such as BGP, JABBER, and perhaps SSH) may benefit from
   code which explicitly requests the use of this option and carefully
   manages the fallback to a connection attempt without this option.

Firewall and NAT considerations

   (More thought may be needed here.)

   Simple sorts of firewalls that disallow incoming TCP segments which
   do not have an ACK control bit set (to disallow the initiation of TCP
   connections from machines beyond the firewall) should not cause any
   problem for this scheme.

   Firewalls that track TCP connections, and NATs, will need to be aware
   of this option and track the connection to the new port number.  Any
   such firewalls or NATs on the path that have not been upgraded to
   handle this option will likely cause connection attempts using this
   option to fail.

   Upgrading firewalls and NATs to track this option should be
   straightforward.  (The simplest upgrade to a firewall that avoids
   blocking connection attempts carrying this option would be to simply
   strip this option from the TCP SYN segment, though that would leave
   such connections more vulnerable to spoofed packets.)

Security Considerations

   This memo describes a method of making it more difficult for an off-
   path attacker to slip a spoofed packet into a TCP connection by
   randomizing the port numbers involved (including what would normally
   be a well-known port number), and recommends that the port numbers
   not be revealed publicly (e.g. through any publicly-readable network
   management databases).  This method provides only a limited
   enhancement of security, and does not come close to the robustness
   that can be achieved by techniques employing end-to-end encryption of
   the TCP segments (such as IPSEC).






Shepard                 Expires January 13, 2005                [Page 5]

draft-shepard-tcp-reassign-port-number-00.txt                  July 2004


IANA Considerations

   A single new TCP option value will need to be assigned for the
   Reassign Port Number option described above.

Author's  Address:

   Tim Shepard
   122 Beech Street
   Belmont, MA 02478

   +1 617 489 7135
   shep@alum.mit.edu

Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Shepard                 Expires January 13, 2005                [Page 6]