One document matched: draft-gont-behave-nat-security-02.txt
Differences from draft-gont-behave-nat-security-01.txt
BEHAVE WG F. Gont
Internet-Draft UTN/FRH
Intended status: BCP P. Srisuresh
Expires: April 29, 2010 Kazeon Systems, Inc.
October 26, 2009
Security implications of Network Address Translators (NATs)
draft-gont-behave-nat-security-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
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 April 29, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Gont & Srisuresh Expires April 29, 2010 [Page 1]
Internet-Draft NAT security implications October 2009
Abstract
This document analyzes the security implications of Network Address
Translators (NATs). It neither deprecates nor encourages the use of
NATs, but rather aims to raise awareness about their security
implications, and possible implementation approaches to improve their
security.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Security Implications from IP fragmentation . . . . . . . . . 4
2.1. Fragment processing for inbound IP packets . . . . . . . . 4
2.2. Fragment processing on the outbound . . . . . . . . . . . 5
3. Port reservation . . . . . . . . . . . . . . . . . . . . . . . 6
4. Peer-to-peer Communication for the end hosts behind devices . 7
5. DHCP-Configured NATs . . . . . . . . . . . . . . . . . . . . . 7
5.1. DHCP-Configured NATs in a Multi-Level NAT deployments . . 7
5.2. DHCP-Configured NATs in a Remote Access VPN operation . . 8
6. Secure Transport for the end hosts behind NAT Devices . . . . 8
7. Security considerations arising from protocol header fields . 9
7.1. Internet Protocol version 4 (IPv4) header fields . . . . . 9
7.1.1. Version . . . . . . . . . . . . . . . . . . . . . . . 9
7.1.2. IHL . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1.3. Type of Service . . . . . . . . . . . . . . . . . . . 9
7.1.4. Total Length . . . . . . . . . . . . . . . . . . . . . 9
7.1.5. Identification . . . . . . . . . . . . . . . . . . . . 10
7.1.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1.7. Fragment Offset . . . . . . . . . . . . . . . . . . . 10
7.1.8. Time to Live . . . . . . . . . . . . . . . . . . . . . 10
7.1.9. Protocol . . . . . . . . . . . . . . . . . . . . . . . 10
7.1.10. Header Checksum . . . . . . . . . . . . . . . . . . . 10
7.1.11. Source Address . . . . . . . . . . . . . . . . . . . . 10
7.1.12. Destination Address . . . . . . . . . . . . . . . . . 11
7.1.13. Options . . . . . . . . . . . . . . . . . . . . . . . 11
7.1.14. Padding . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Transmission Control Protocol (TCP) header fields . . . . 11
7.2.1. Source Port . . . . . . . . . . . . . . . . . . . . . 11
7.2.2. Destination Port . . . . . . . . . . . . . . . . . . . 11
7.2.3. Sequence Number . . . . . . . . . . . . . . . . . . . 11
7.2.4. Acknowledgment Number . . . . . . . . . . . . . . . . 12
7.2.5. Data Offset . . . . . . . . . . . . . . . . . . . . . 12
7.2.6. Reserved . . . . . . . . . . . . . . . . . . . . . . . 12
7.2.7. Flags . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2.8. Window . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2.9. Checksum . . . . . . . . . . . . . . . . . . . . . . . 12
7.2.10. Urgent Pointer . . . . . . . . . . . . . . . . . . . . 13
Gont & Srisuresh Expires April 29, 2010 [Page 2]
Internet-Draft NAT security implications October 2009
7.2.11. Options . . . . . . . . . . . . . . . . . . . . . . . 13
7.2.12. Padding . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Change log (to be removed before publication of
the document as an RFC) . . . . . . . . . . . . . . . 16
A.1. Changes from draft-gont-behave-nat-security-01 . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Gont & Srisuresh Expires April 29, 2010 [Page 3]
Internet-Draft NAT security implications October 2009
1. Introduction
This document analyzes the security implications of Network Address
Translators (NATs). It neither deprecates nor encourages the use of
NATs, but rather aims to raise awareness about their security
implications, and possible implementation approaches to improve their
security.
Section 2 and Section 3 analyze the possible security implications of
basic NAT functionality. Section 5 analyzes the possible security
implications of DHCP-Configured NATs. Section 7 analyzes the
possible security implications araising from the non-modification of
protocol header fields by NATs.
Note: the security implications of a NAT device due to it being a
stateful device are not discussed in the current version of this
document (but may be added in future revisions). For what is worth,
many of these security implications are described in [RFC5382],
[RFC4787] and [I-D.ietf-behave-nat-icmp].
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].
2. Security Implications from IP fragmentation
2.1. Fragment processing for inbound IP packets
Routers in the network are able to forward fragmented IP packets just
as they do any other non-fragmented IP packets because packet
forwarding is based solely on looking up the destination IP address
in the routing table and finding the largest prefix match to identify
the next-hop to forward to. Routers do not need to retain any state
pertaining to fragmented packets traversing them.
A NAT device operates differently from a router in that the NAT
device must find the matching NAT Session for an IP packet and
perform NAT translation on the packet, prior to forwarding. NAT
Session lookup requires the full 5-tuple of the IP datagram. Only
the first fragment of the IP datagram contains the full-tuple.
Subsequent fragmented packets contain the fragment Id, but do not
contain transport protocol specific details such as source and
destination port numbers. The NAT device must be able to associate
the same session tuple for all fragments by virtue of the fragment ID
and use that information to locate the NAT Session the packets belong
to. Note however, the IP fragments cannot be assumed to arrive in
order. Some operating systems transmit the fragments of an IP
Gont & Srisuresh Expires April 29, 2010 [Page 4]
Internet-Draft NAT security implications October 2009
datagram out of their logical order as a matter of course. In
addition, network conditions can also cause dynamic packet reordering
in transit.
A NAT device not capable of processing all fragments of an inbound IP
datagram can cause the fragmented packets to be dropped causing some
applications to not function correctly.
NATs, capable of processing out-of-order packets store the out-of-
order packets prior to forwarding. This can open up the NAT device
for external attacks. As pointed out in [RFC4787], fragmentation has
been a tool used in many attacks, some involving passing fragmented
packets through NATs, and others involving DoS attacks based on the
state needed to reassemble the fragments. NAT implementers should be
aware of [RFC3128] and [RFC1858].
NATs may protect themselves against such attacks by limiting the
length of time they retain an incomplete IP packet before discarding
it, or by limiting the amount of internal buffer space incomplete IP
packets may consume before the oldest fragments are discarded. The
appropriate values of these limits vary across NATs, and may be
determined by the network administrator.
[CPNI-IP] contains a detailed discussion of the security implications
arising from the reassembly of IP fragments and of a number of
approaches to mitigate them.
REQ-1: A NAT device capable of forwarding out-of-order IP fragments
MUST take measures to protect itself against well-known IP fragment
based attacks.
2.2. Fragment processing on the outbound
Say, two private hosts originated TCP/UDP packets (fragmented or not)
to the same destination host and both packets transit the same NAPT
device and use the same fragmentation identifier. Say, the NAPT
device assembled the IP packets (in the case they were fragmented)
and translated the same using the appropriate NAT Sessions. When
NAPT translates IP datagrams, it would assign all outbound IP
datagrams the same Public IP, but different TCP/UDP numbers. While
forwarding, an IP datagram may be fragmented on the way out. Only
the first fragment contains the TCP/UDP header that would be
necessary to associate the packet to a specific session. Subsequent
fragments do not contain TCP/UDP port information, but simply carry
the same fragmentation identifier specified in the first fragment.
When the target host receives the two unrelated datagrams, carrying
same fragmentation id, and from the same assigned host address, the
Gont & Srisuresh Expires April 29, 2010 [Page 5]
Internet-Draft NAT security implications October 2009
target host is unable to determine which of the two sessions the
datagrams belong to and might corrupt both sessions. This can be a
security breach any of the sessions associated.
In order to avoid problems of this kind, the NAPT device MUST further
translate fragment ID in the outgoing packets such that the tuples of
(SrcIP, DestIP, fragment Id, Protocol) are unique and distinguishable
across all outgoing packets from the NAT device.
When fragmenting packets on the outbound, a NAT device implementing
NAPT function MUST ensure that the tuples of (SrcIP, DestIP, fragment
Id, Protocol) are unique across all outgoing packets.
REQ-2: when forwarding IP fragments on the outbound, a NAT device
implementing NAPT function MUST ensure that the tuple of (SrcIP,
DestIP, Protocol, fragment ID) is unique across NAT Sessions. Doing
this will eliminate the possibility of cross-session contamination
due to fragment Identifier overlap when more than one NAT session
share the same DestIP and Protocol.
3. Port reservation
A NAT device implementing NAPT function shares the source ports for
its public IP address with nodes in the private realm. The NAPT
device may also have end host applications of its own. Consider the
following scenario when a NAPT device uses the same TCP/UDP port for
local use as well as for mapping to a private host.
Say, an application on the NAPT device runs on port 5060 (SIP
Server), but not enabled. Say, a host in the private domain of the
Nat device also uses 5060 and obtains port 5060 from the NAT device.
While this Port Binding is active, say, the application on NAPT
device is activated. The application on the NAT device is unlikely
to be aware of the NAT function enforced by the NAT device. Once the
same port is assigned for NAT use as well as for use by local
application on the NAT device, data packets directed to the NAT
device could end up with the end host within the private domain or
the application on the NAT device. This behavior can cause
unpredictable behavior and may even result in data snooping.
Manual intervention becomes necessary to ensure that only one
instance of an application is actively using a port at a given time.
It is not desirable to either allow possible simulataneous use (or)
require manual intervention to serialize the use.
REQ-3: When a NAT device supports local applications on the device,
it is RECOMMENDED that the NAT device reserves specific ports for
Gont & Srisuresh Expires April 29, 2010 [Page 6]
Internet-Draft NAT security implications October 2009
local use, different from NAT use, so there is no overlap of ports
between local use and NAT use. Doing this will ensure there is no
possibility of cross session contamination between NAT sessions and
local sessions.
4. Peer-to-peer Communication for the end hosts behind devices
[RFC5128] refers to applications using TCP/UDP hole punching
technique to establish peer-to-peer communication. Section 6.1 of
[RFC5128] describes a scenario in which it can be problematic for
applications that do not use appropriate authentication mechanisms
while setting up peer connections. An application could end up
connecting to the wrong host or have its connections hijacked
maliciously by other hosts.
REQ-4: Applications attempting to establish peer-to-peer
communication across NAT devices using TCP/UDP hole punching
technique SHOULD employ relevant authentication mechanism to connect
to their peers.
5. DHCP-Configured NATs
5.1. DHCP-Configured NATs in a Multi-Level NAT deployments
Many NATs, particularly consumer-level devices designed to be
deployed by nontechnical users, also act as DHCP [RFC2131] clients.
In its default configuration, a consumer NAT typically obtains its
public IP address, default router, and other IP configuration
information Via DHCP from an ISP or other "upstream" network.
On its internal network side, the NAT then automatically sets up its
own private "downstream" subnet in one of the private IP address
regions assigned to this purpose in [RFC1918]. The NAT typically
acts as a DHCP server for its private downstream network, managing
its pool of private IP addresses automatically and handing them out
to the hosts (and perhaps other NATs) on the private network on
demand.
This auto-configuration of private networks can be problematic, if
the NAT's upstream network is also in RFC 1918 private address space.
In the Multi Level NAT deployments, end-hosts could have their
security compromised due to mistaken serveri identities as described
in section 3 of [I-D.ford-behave-top].
REQ-5: DHCP-Configured NATs SHOULD use different address spaces for
the private and the external realms.
Gont & Srisuresh Expires April 29, 2010 [Page 7]
Internet-Draft NAT security implications October 2009
5.2. DHCP-Configured NATs in a Remote Access VPN operation
In deployments where a corporate network deploys the same private
address space as used on sundry remote locations, end-hosts could
have their security compromised due to mistaken server identities, as
described in section 4 of [I-D.ford-behave-top].
6. Secure Transport for the end hosts behind NAT Devices
NAT devices are ubiquitous in the Internet. NAT devices can be found
in homes, hotels, Airports, conferences, coffee shops and plethora of
internet cafes.
Most users needing to carry out financial transactions and other
personal, sensitive applications use SSL/TLS protocol [RFC2246] to do
this. NAT devices enroute MUST support the traversal of SSL/TLS
protocol. TCP port 443 is the default port used for SSL/TLS
protocol.
Secure VPNs is another important use of secure protocols to access
corporate networks. Telecommuters and users in remote locations use
secure VPN to access their corporate networks. The secure VPNs may
use a combination of NAT-T [RFC3947] and IPSec-over-UDP [RFC3948] to
secure the VPN traffic. Alternately, some VPN vendors use SSL/TLS
protocol [RFC2246] to secure the VPN traffic. NAT devices enroute
MUST support the traversal of NAT compliant security protocols such
as SSL/TLS, NAT-T and IPsec-over-UDP.
Enforcement of NAT-T for IKE negotiation can be problematic, as
described in Section 2.3 of [RFC3715], if the NAT device enroute has
an Application Level Gateway (ALG) that attempts to treat IKE packets
differently from other UDP packets. A NAT device MUST NOT include an
ALG that treats IKE or SSL/TLS packets differently than any other
TCP/UDP packet.
REQ-6: A NAT device MUST permit the traversal of NAT compliant
security protocols. Specifically, a NAT device MUST do the
following.
a. A NAT device MUST NOT block traffic directed to or coming from
UDP port numbers 500 and 4500.
b. A NAT device MUST NOT block traffic directed to or coming from
TCP/UDP port number 443.
c. A NAT device MUST NOT include an ALG that treats IKE packets or
SSL/TLS packets differently than any other TCP/UDP packet.
Gont & Srisuresh Expires April 29, 2010 [Page 8]
Internet-Draft NAT security implications October 2009
7. Security considerations arising from protocol header fields
From the external real, all packets originated by any host in the
internal realm (or by the NAT itself) are seen as originating from
the NAT box. As a result, the same requirements that are applied to
an internet host must be applied to the aggregate traffic at the NAT
box. For example, in the same way that an internet host is required
not to reuse a tuple (SrcIP, DstIP, Protocol, IP ID) at any given
time, a NAT should enforce that a tuple (SrcIP, DstIP, Protocol, IP
ID) of the aggregate traffic is not reused at any given time.
In order to enforce some of these requirements, a NAT will usually
need to rewrite some of the TCP and/or IP header fields of the
incoming and outgoing packets.
The following subsections analyze the interoperability and security
implications arising from the non-modification of protocol header
fields by Network Address Translators (NATs)
7.1. Internet Protocol version 4 (IPv4) header fields
7.1.1. Version
This field does not require any special handling by NATs.
7.1.2. IHL
This field does not require any special handling by NATs.
7.1.3. Type of Service
End-systems have traditionally selected different TOS values
depending on the nature of the application making use of the IP
services. As the TOS value selected for each packet usually depends
the specific IP implementation, this could be exploited to roughly
count the number of systems behind a NAT. In order to avoid the TOS
field from revealing this information, NATs could rewrite the TOS
field in outgoing packets according to the Protocol value in the IP
header, and the Destination Port value in the header of the transport
protocol running on top of IP.
7.1.4. Total Length
This field does not require any special handling by NATs.
Gont & Srisuresh Expires April 29, 2010 [Page 9]
Internet-Draft NAT security implications October 2009
7.1.5. Identification
NATs must ensure that a tuple (SrcIP, DstIP, Protocol, IP ID) is not
reused while there are still packets in the network with that tuple.
In order to enforce this requirement, NATs MUST rewrite the IP
Identification field of the outgoing IP packets.
A trivial approach to enforce this requirement would be to rewrite
the IP Identification from a global counter that is increment by one
each time a packet is transmitted. However, while this would fulfil
the interoperability requirements, this would lead to predictable
Identification values, which have been found to have a number of
security implications [CPNI-IP].
In order to mitigate these security implications, NATs should rewrite
the IP Identification field such that it is not trivial for an
attacker to detect different "sequences" of the Identification field.
[CPNI-IP] discusses a number of approaches for selecting the
Identification value at end-systems, which could also be applied for
the selection of the Identification value at NATs.
REQ-6: NATs MUST ensure that a tuple (SrcIP, DstIP, Protocol, IP ID)
is not reused while there are still packets in the network with that
tuple. Additionally, they SHOULD generate the IP Identification
values such that they are not trivially predictable.
7.1.6. Flags
7.1.7. Fragment Offset
This field does not require any special handling by NATs.
7.1.8. Time to Live
To be added.
7.1.9. Protocol
This field does not require any special handling by NATs.
7.1.10. Header Checksum
This field does not require any special handling by NATs.
7.1.11. Source Address
Here we make no special considerations about this field.
Gont & Srisuresh Expires April 29, 2010 [Page 10]
Internet-Draft NAT security implications October 2009
7.1.12. Destination Address
Here we make no special considerations about this field
7.1.13. Options
Clearly, IP options could potentially be used for counting the number
of systems behind a NAT. However, as it is unusual for end-systems
to include IP options in the IP packets they send, in most cases this
IP options will not require any special handling by NATs.
7.1.14. Padding
This field does not require any special handling by NATs.
7.2. Transmission Control Protocol (TCP) header fields
7.2.1. Source Port
As part of its basic functionality, a NAT-PT will usually rewrite
(translate) the TCP Source Port of packets sent to the external
realm. As a result, the ephemeral port selection algorithm of a NAT
will "override" that of the end-systems behind the NAT.
In some cases, this may have the undesireable consequence that a
system implementing some algorithm for ephemeral port obfuscation may
end up establishing TCP connections with systems in the external
realm using a predictable (as seen from the external realm) ephemeral
port sequence.
NATs should implement an ephemeral port selection algorithm such that
the source port of outgoing packets is obfuscated, thus mitigating
blind (off-path) spoofing attacks.
It should be noted that use of an improper ephemeral port selection
algorithm may lead to collisions of connection-ids, with the
potential of failure in the establishment of new TCP connections.
[I-D.ietf-tsvwg-port-randomization]
7.2.2. Destination Port
Here we make no special considerations for this field.
7.2.3. Sequence Number
The choice of the Initial Sequence Number of a connection by an end-
system is not arbitrary, but aims to minimize the chances of a stale
segment from being accepted by a new incarnation of a previous
Gont & Srisuresh Expires April 29, 2010 [Page 11]
Internet-Draft NAT security implications October 2009
connection. [RFC0793] suggests the use of a global 32-bit ISN
generator, whose lower bit is incremented roughly every 4
microseconds. Based on the premise that the ISNs of consecutive TCP
connections are monotonically-increasing, BSD-derived implementations
use the ISN of an incomming connection request to perform heuristics
aiming at allowing a new incarnation of a previous connection to be
created, even if the pervious incarnation is still in the TIME-WAIT
state. However, an ISN such as that described in [RFC0793] makes it
trivial for an attacker to predict the ISN used for future
connections, thus making it easier for the attacker to perform
"blind" attacks against those connections.
NATs may rewrite the Sequence Number of outgoing segments such that
consecutive connections to a specific service at a specific system
use ISNs that are monotonically-increasing. Additionally, the ISN
generator should be such that it should be difficult for an off-path
attacker to predict the ISNs of future connections. [RFC1948]
describes an algorithm for the generation of ISN that complies with
these two "requirements".
7.2.4. Acknowledgment Number
If the NAT rewrites the Sequence Number of TCP segments forwarded
from the internal realm to the external realm, it must also rewrite
the Acknowledgement Number of TCP segments forwarded from the
external realm to the internal realm.
7.2.5. Data Offset
Here we make no special considerations for this field.
7.2.6. Reserved
Here we make no special considerations for this field.
7.2.7. Flags
Here we make no special considerations for this field.
7.2.8. Window
Here we make no special considerations for this field.
7.2.9. Checksum
Here we make no special considerations for this field.
Gont & Srisuresh Expires April 29, 2010 [Page 12]
Internet-Draft NAT security implications October 2009
7.2.10. Urgent Pointer
Here we make no special considerations for this field.
7.2.11. Options
7.2.11.1. TCP timestamps
The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP
to include a timestamp value in its segments, that can be used used
to perform two functions: Round-Trip Time Measurement (RTTM), and
Protect Against Wrapped Sequences (PAWS).
For the purpose of PAWS, the timestamps sent on a connection are
required to be monotonically increasing. While there is no
requirement that timestamps are monotonically increasing across TCP
connections, the generation of timestamps such that they are
monotonically increasing across connections between the same two
endpoints allows the use of timestamps for improving the handling of
SYN segments that are received while the corresponding four-tuple is
in the TIME-WAIT state. That is, the timestamp option could be used
to perform heuristics to determine whether to allow the creation of a
new incarnation of a connection that is in the TIME-WAIT state.
NATs could rewrite the TCP Timestamps option such that TCP
consecutive connections connections with a specific service at a
specific system use monotonically increasing timestamps (i.e., the
TCP timestamps are monotonically-increasing across those
connections). [I-D.gont-tcpm-tcp-timestamps] describes an algorithm
that complies with this requirement.
7.2.12. Padding
Here we make no special considerations for this field.
8. Security Considerations
This document analyzes the security implications of Network Address
Translators (NATs). It neither deprecates nor encourages the use of
NATs, but rather aims to raise awareness about their security
implications, and possible implementation approaches to improve their
security.
Note: the security implications of a NAT device due to it being a
stateful device are not discussed in the current version of this
document (but may be added in future revisions). For what is worth,
many of these security implications are described in [RFC5382],
Gont & Srisuresh Expires April 29, 2010 [Page 13]
Internet-Draft NAT security implications October 2009
[RFC4787] and [I-D.ietf-behave-nat-icmp].
9. IANA Considerations
This document has no actions for IANA.
10. Acknowledgements
The authors of this document would like to thank (in alphabetical
order) Brian Carpenter, Remi Denis-Courmont, Reinaldo Penno, Dave
Thaler, and Dan Wing for providing valuable feedback on earlier
versions of this document.
11. References
11.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
Gont & Srisuresh Expires April 29, 2010 [Page 14]
Internet-Draft NAT security implications October 2009
11.2. Informative References
[Bellovin2002]
Bellovin, S., "A Technique for Counting NATted Hosts",
IMW'02 Nov. 6-8, 2002, Marseille, France, 2002.
[CPNI-IP] CPNI, "Security Assessment of the Internet Protocol",
2008 .
[CPNI-TCP]
CPNI, "Security Assessment of the Transmission Control
Protocol (TCP)", (to be published) .
[I-D.ford-behave-top]
Srisuresh, P. and B. Ford, "Unintended Consequence of two
NAT deployments with Overlapping Address Space",
draft-ford-behave-top-07 (work in progress), August 2009.
[I-D.gont-tcpm-tcp-timestamps]
Gont, F., "On the generation of TCP timestamps",
draft-gont-tcpm-tcp-timestamps-02 (work in progress),
September 2009.
[I-D.ietf-behave-nat-icmp]
Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP protocol",
draft-ietf-behave-nat-icmp-12 (work in progress),
January 2009.
[I-D.ietf-tsvwg-port-randomization]
Larsen, M. and F. Gont, "Port Randomization",
draft-ietf-tsvwg-port-randomization-04 (work in progress),
July 2009.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
Gont & Srisuresh Expires April 29, 2010 [Page 15]
Internet-Draft NAT security implications October 2009
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, March 2008.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
Appendix A. Change log (to be removed before publication of the
document as an RFC)
A.1. Changes from draft-gont-behave-nat-security-01
o Addded Section 6.
Authors' Addresses
Fernando Gont
Universidad Tecnologica Nacional / Facultad Regional Haedo
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: fernando@gont.com.ar
URI: http://www.gont.com.ar
Gont & Srisuresh Expires April 29, 2010 [Page 16]
Internet-Draft NAT security implications October 2009
Pyda Srisuresh
Kazeon Systems, Inc.
1161 San Antonio Rd.
Mountain View, CA 94043
U.S.A.
Phone: +1 408 836 4773
Email: srisuresh@yahoo.com
Gont & Srisuresh Expires April 29, 2010 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 07:34:59 |