A TCP Authentication Option NAT Extension
draft-touch-tcp-ao-nat-04

TCPM WG                                                        J. Touch
Internet Draft                                                  USC/ISI
Intended status: Experimental                         November 28, 2012
Expires: May 2013

                 A TCP Authentication Option NAT Extension
                       draft-touch-tcp-ao-nat-04.txt

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), 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 as "work in progress."

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

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

   This Internet-Draft will expire on May 28, 2013.

Copyright Notice

   Copyright (c) 2012 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
   (http://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 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.

Touch                    Expires May 28, 2013                  [Page 1]
Internet-Draft           TCP-AO NAT Extension             November 2012

Abstract

   This document describes an extension to the TCP Authentication
   Option (TCP-AO) to support its use over connections that pass
   through network address and/or port translators (NATs/NAPTs). This
   extension changes the data used to compute traffic keys, but does
   not alter TCP-AO's packet processing or key generation algorithms.

Table of Contents

   1. Introduction...................................................2
   2. Conventions used in this document..............................2
   3. Background.....................................................3
   4. Extension to Allow NAT Use.....................................3
   5. Intended Use...................................................4
   6. Security Considerations........................................4
   7. IANA Considerations............................................5
   8. References.....................................................5
      8.1. Normative References......................................5
      8.2. Informative References....................................5
   9. Acknowledgments................................................6

1. Introduction

   This document describes an extension to the TCP Authentication
   Option (TCP-AO) [RFC5925] to support its use in the presence of
   network address and/or port translators (NAT/NAPT) [RFC2663]. These
   devices translate the source address and/or the source port number
   of a TCP connection. TCP-AO without these extensions would be
   sensitive to these modifications, and would discard authenticated
   segments.

   At least one potential application of this extension is to support
   the experimental multipath TCP protocol [Fo11], which uses multiple
   IP addresses to support a single TCP transfer.

   This document assumes detailed familiarity with TCP-AO [RFC5925]. As
   a preview, this document focuses on how TCP-AO generates traffic
   keys, and does not otherwise alter the TCP-AO mechanism or that of
   its key generation [RFC5926].

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

Touch                    Expires May 28, 2013                  [Page 2]
Internet-Draft           TCP-AO NAT Extension             November 2012

   When used in lower case, these words have their conventional meaning
   and do not convey the interpretations in RFC-2119.

3. Background

   TCP-AO generates traffic keys that are specific to a socket pair
   [RFC5925]. Using the TCP-AO convention (local = source for outgoing
   segments, destination for incoming segments), the following
   information is used to create a connection's traffic keys:

   o  IP local address

   o  IP remote address

   o  TCP local port

   o  TCP remote port

   o  TCP local Initial Sequence Number (ISN)

   o  TCP remote Initial Sequence Number (ISN)

   Of these fields, the remote ISN is not known for SYN segments, and
   is excluded from the traffic key used to authenticate them.
   Otherwise, all fields are used in the traffic keys of all other
   segments.

   NATs and NAPTs (here just "NATs", even if port translation is
   included) would interfere with these uses, because they alter the IP
   address and TCP port of the endpoint behind the NAT [RFC2663].

4. Extension to Allow NAT Use

   It might be useful to allow TCP-AO use in the presence of NATs,
   e.g., to protect client/server communication where clients are
   behind NATs.

   This document describes an extension to TCP-AO that enables its use
   in the presence of NATs called TCP-AO-NAT. This extension requires
   no modification to the TCP-AO header or packet processing, and
   requires no modification to the algorithms used to generate traffic
   keys [RFC5926]. The change is limited to the data used to generate
   traffic keys only.

   In TCP-AO, "a Master Key Tuple (MKT) describes the TCP-AO properties
   to be associated with one or more connections" [RFC5925]. This
   includes the TCP connection identifier, the TCP option flag

Touch                    Expires May 28, 2013                  [Page 3]
Internet-Draft           TCP-AO NAT Extension             November 2012

   (indicating whether TCP options other than TCP-AO are included in
   the MAC calculation), keying information, and other parameters. TCP-
   AO-NAT augments the MKT with two additional flags:

   o  localNAT

   o  remoteNAT

   These flags indicate whether a segment's local or remote
   (respectively) IP address and TCP port are zeroed before MAC
   calculation, either for creating the MAC to insert (for outgoing
   segments) or for calculating a MAC to validate against the value in
   the option. I.e., these would modify the processing rules as
   follows:

   o  Traffic keys are computed by zeroing the local/remote IP address
      and TCP port as indicated by the localNAT or remoteNAT flags.

   o  MAC values are computed by zeroing the local/remote IP address
      and TCP port as indicated by the localNAT or remoteNAT flags.

5. Intended Use

   A client behind a NAT, or that suspects being behind a NAT, would
   set localNAT=TRUE. A server willing to support incoming TCP-AO-NAT
   connections would set remoteNAT=TRUE. Peer-to-peer applications with
   dual NAT support, e.g., those traversing symmetric NATs, would set
   both localNAT=TRUE and remoteNAT=TRUE [RFC5389].

   Note that this extension is not intended for use with services
   transiting application layer gateways (ALGs), i.e., NATs that also
   translate in-band addresses, such as used in FTP or SIP. TCP-AO-NAT
   protects the contents of the TCP segments from modification, and
   would (correctly) interpret with such alterations as an attack on
   those contents.

6. Security Considerations

   TCP-AO-NAT does not affect the security of connections that do not
   set either of the localNAT or remoteNAT flags. Such connections are
   not affected themselves, and are not affected by segments in other
   connections that set those flags.

   Setting either the localNAT or remoteNAT flags reduces the
   randomness of the input to the KDF used to generate the traffic
   keys. The largest impact occurs when using IPv4, which reduces the
   randomness from 2 IPv4 addresses, 2 ISNs, and both ports down to 1

Touch                    Expires May 28, 2013                  [Page 4]
Internet-Draft           TCP-AO NAT Extension             November 2012

   IPv4 address, 2 ISNs, and one port. The amount of randomness in the
   IPv4 addresses and service port is likely to be small, and the
   randomness of the dynamic port is under debate and should not be
   considered substantial [RFC6056]; the KDF input randomness is thus
   expected to be dominated by that of the ISNs, so reducing it by one
   IPv4 address and the service port may not have a significant impact.
   IPv6 addresses can have substantially more randomness because they
   usually include the device's MAC address, which itself has more
   randomness than IPv6 prefixes or IPv4 address in total.

   >> TCP-AO-NAT SHOULD NOT be used with both flags set in IPv4,
   however, as the result would rely entirely on the ISNs alone.

7. IANA Considerations

   There are no IANA considerations for this document. This section can
   be removed upon publication as an RFC.

8. References

8.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication
             Option", RFC 5925, Jun. 2010.

8.2. Informative References

   [Fo11]    Ford, A., C. Raiciu, M. Handley, O. Bonaventure, "TCP
             Extensions for Multipath Operation with Multiple
             Addresses", (work in progress), draft-ietf-mptcp-
             multiaddressed, Mar. 2011.

   [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
             Translator (NAT) Terminology and Considerations", RFC
             2663, August 1999.

   [RFC5389] Rosenberg, J., R. Mahy, P. Matthews, D. Wing, "Session
             Traversal Utilities for NAT (STUN)", RFC 5389, Oct. 2008.

   [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
             for the TCP Authentication Option (TCP-AO)", RFC 5926,
             June 2010.

Touch                    Expires May 28, 2013                  [Page 5]
Internet-Draft           TCP-AO NAT Extension             November 2012

   [RFC6056] Larsen, M., F. Gont, "Port Randomization," RFC 6056, Jan.
             2011.

9. Acknowledgments

   This extension was inspired by discussions with Dan Wing.

   This document was prepared using 2-Word-v2.0.template.dot.

Author's Address

   Joe Touch
   USC/ISI
   4676 Admiralty Way
   Marina del Rey, CA 90292
   USA

   Phone: +1 (310) 448-9151
   Email: touch@isi.edu

Touch                    Expires May 28, 2013                  [Page 6]