TCPM WG J. Touch
Internet Draft USC/ISI
Intended status: Proposed Standard January 31, 2010
Expires: July 2010
A TCP Authentication Option NAT Extension
draft-touch-tcp-ao-nat-01.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 July 31, 2010.
Copyright Notice
Copyright (c) 2010 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 July 31, 2010 [Page 1]
Internet-Draft TCP-AO NAT Extension January 2010
Abstract
This document describes an extension to the TCP Authentication
Option to support its use over connections that pass through network
address and/or port translators (NATs/NAPTs). This document
describes this extension, and is intended that if desired, would be
incorporated into the TCP-AO description currently under
development. This document is not intended to remain stand-alone.
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................................................5
1. Introduction
This document assumes detailed familiarity with TCP-AO [ID-TCP-AO].
It is intended as an extension to TCP-AO, and is described
separately to allow its separate consideration. If approved, it is
expected that this document would be integrated with TCP-AO. As a
result, no background is included herein.
TCP-AO can be extended to support use through NAT/NAPT devices
[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.
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].
When used in lower case, these words have their conventional meaning
and do not convey the interpretations in RFC-2119.
Touch Expires July 31, 2010 [Page 2]
Internet-Draft TCP-AO NAT Extension January 2010
3. Background
TCP-AO generates traffic keys that are specific to a socket pair
[ID-TCP-AO]. 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 when for SYN segments,
and is excluded from the traffic key used to authentication 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
local IP address and local TCP port [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.
We propose an extension to TCP-AO that enables its use in the
presence of NATs. This extension requires no modification to the
TCP-AO header. The change is limited to the way in which traffic
keys are generated. We call this TCP-AO-NAT.
For TCP-AO-NAT, there are two additional flags for each TCP
connection. These flags, which could be copied from parameters of
the MKT or set on a per-connection basis, are:
o localNAT
o remoteNAT
Touch Expires July 31, 2010 [Page 3]
Internet-Draft TCP-AO NAT Extension January 2010
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 and remoteNAT flags.
o MAC values are computed by zeroing the local/remote IP address
and TCP port as indicated by the localNAT and 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].
6. Security Considerations
TCP-AO-NAT does not affect the security of connections that set
neither 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 entropy
of the input to the KDF used to generate the traffic keys. The
largest impact occurs when using IPv4, which reduces the entropy
from 2 IPv4 addresses, 2 ISNs, and both ports down to 1 IPv4
address, 2 ISNs, and only the dynamic port. The amount of entropy in
the IPv4 addresses and service port is likely to be small, and the
entropy of the dynamic port is under debate and should not be
considered substantial [La09]; the KDF input entropy 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 entropy because they
usually include the device's MAC address, which itself has more
entropy 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.
Touch Expires July 31, 2010 [Page 4]
Internet-Draft TCP-AO NAT Extension January 2010
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.
[ID-TCP-AO] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication
Option",draft-ietf-tcpm-tcp-auth-opt-09.txt, Jan. 2010.
8.2. Informative References
[La09] Larsen, M., F. Gont, "Port Randomization," draft-ietf-
tsvwg-port-randomization-05, Nov. 09.
[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.
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 July 31, 2010 [Page 5]