DNS, each DNS RRset is signed with a key from within the zone.
Moreover, the authenticity of a specific key is verified by following
a chain of trust that goes all the way to the DNS root. When a DNS-
ALG modifies addresses (e.g., as in the case of Twice-NAT),
verification of signatures fails.
It may be of interest to note that IKE (Session key negotiation
protocol) is a UDP based session layer protocol and is not protected
by network based IPsec security. Only a portion of the individual
payloads within IKE are protected. As a result, IKE sessions are
permissible across NAT, so long as IKE payload does not contain
addresses and/or transport IDs specific to one realm and not the
other. Given that IKE is used to setup IPSec associations, and there
are at present no known ways of making IPSec work through a NAT
function, it is a future work item to take advantage of IKE through a
NAT box.
One of the most popular internet applications "FTP" would not work
with the definition of NAT as described. The following sub-section is
devoted to describing how FTP is supported on NAT devices. FTP ALG
is an integral part of most NAT implementations. Some vendors may
choose to include additional ALGs to custom support other
applications on the NAT device.
7.1. FTP support
"PORT" command and "PASV" response in FTP control session payload
identify the IP address and TCP port that must be used for the data
session it supports. The arguments to the PORT command and PASV
response are an IP address and a TCP port in ASCII. An FTP ALG is
required to monitor and update the FTP control session payload so
that information contained in the payload is relevant to end nodes.
The ALG must also update NAT with appropriate data session tuples and
session orientation so that NAT could set up state information for
the FTP data sessions.
Because the address and TCP port are encoded in ASCII, this may
result in a change in the size of packet. For instance,
10,18,177,42,64,87 is 18 ASCII characters, whereas
193,45,228,137,64,87 is 20 ASCII characters. If the new size is same
as the previous, only the TCP checksum needs adjustment as a result
of change of data. If the new size is less than or greater than the
previous, TCP sequence numbers must also be changed to reflect the
change in length of FTP control data portion. A special table may be
used by the ALG to correct the TCP sequence and acknowledge numbers.
The sequence number and acknowledgement correction will need to be
performed on all future packet of the connection.
8.0. NAT limitations
8.1. Applications with IP-address Content
Not All applications lend themselves easily to address translation by
NAT devices. Especially, the applications that carry IP address (and
TU port, in case of NAPT) inside the payload. Application Level
Gateways, or ALGs must be used to perform translations on packets
pertaining to such applications. ALGs may optionally utilize address
(and TU port) assignments made by NAT and perform translations
specific to the application. The combination of NAT functionality and
ALGs will not provide end-to-end security assured by IPsec. However,
tunnel mode IPsec can be accomplished with NAT router serving as
tunnel end point.
SNMP is one such application with address content in payload. NAT
routers would not translate IP addresses within SNMP payloads. It is
not uncommon for an SNMP specific ALG to reside on a NAT router to
perform SNMP MIB translations proprietary to the private network.
8.2. Applications with inter-dependent control and data sessions
NAT devices operate on the assumption that each session is
independent. Session characteristics like session orientation,
source and destination IP addresses, session protocol, and source and
destination transport level identifiers are determined independently
at the start of each new session.
However, there are applications such as H.323 that use one or more
control sessions to set the characteristics of the follow-on sessions
in their control session payload. Such applications require use of
application specific ALGs that can interpret and translate the
payload, if necessary. Payload interpretation would help NAT be
prepared for the follow-on data sessions.
8.3. Debugging Considerations
NAT increases the probability of mis-addressing. For example, same
local address may be bound to different global address at different
times and vice versa. As a result, any traffic flow study based
purely on global addresses and TU ports could be confused and might
misinterpret the results.
If a host is abusing the Internet in some way (such as trying to
attack another machine or even sending large amounts of junk mail or
something) it is more difficult to pinpoint the source of the trouble
because the IP address of the host is hidden in a NAT router.
8.4. Translation of fragmented FTP control packets
Translation of fragmented FTP control packets is tricky when the
packets contain "PORT" command or response to "PASV" command.
Clearly, this is a pathological case. NAT router would need to
assemble the fragments together first and then translate prior to
forwarding.
Yet another case would be when each character of packets containing
"PORT" command or response to "PASV" is sent in a separate datagram,
unfragmented. In this case, NAT would simply have to let the packets
through, without translating the TCP payload. Of course, the
application will fail if the payload needed to be altered. The
application could still work in a few cases, where the payload
contents can be valid in both realms, without modifications enroute.
For example, FTP originated from a private host would still work
while traversing a traditional NAT or bi-directional NAT device, so
long as the FTP control session employed PASV command to establish
data sessions. The reason being that the address and port number
specified by FTP server in the PASV response (sent as multiple
unfragmented packets) is valid to the private host, as is. The NAT
device will simply view the ensuing data session (also originating
from private host) as an independent TCP session.
8.5. Compute intensive
NAT is compute intensive even with the help of a clever checksum
adjustment algorithm, as each data packet is subject to NAT lookup
and modifications. As a result, router forwarding throughput could
be slowed considerably. However, so long as the processing capacity
of the NAT device exceeds line processing rate, this should not be a
problem.
9.0. Security Considerations
Many people view traditional NAT router as a one-way (session)
traffic filter, restricting sessions from external hosts into their
machines. In addition, when address assignment in NAT router is done
dynamically, that makes it harder for an attacker to point to any
specific host in the NAT domain. NAT routers may be used in
conjunction with firewalls to filter unwanted traffic.
If NAT devices and ALGs are not in a trusted boundary, that is a
major security problem, as ALGs could snoop end user traffic payload.
Session level payload could be encrypted end to end, so long as the
payload does not contain IP addresses and/or transport identifiers
that are valid in only one of the realms. With the exception of RSIP,
end-to-end IP network level security assured by current IPsec
techniques is not attainable with NAT devices in between. One of the
ends must be a NAT box. Refer section 7.0 for a discussion on why
end-to-end IPsec security cannot be assured with NAT devices along
the route.
The combination of NAT functionality, ALGs and firewalls will provide
a transparent working environment for a private networking domain.
With the exception of RSIP, end-to-end network security assured by
IPsec cannot be attained for end-hosts within the private network
(Refer section 5.0 for RSIP operation). In all other cases, if you
want to use end-to-end IPsec, there cannot be a NAT device in the
path. If we make the assumption that NAT devices are part of a
trusted boundary, tunnel mode IPsec can be accomplished with NAT
router (or a combination of NAT, ALGs and firewall) serving as tunnel
end point.
NAT devices, when combined with ALGs, can ensure that the datagrams
injected into Internet have no private addresses in headers or
payload. Applications that do not meet these requirements may be
dropped using firewall filters. For this reason, it is not uncommon
to find NAT, ALG and firewall functions co-exist to provide security
at the borders of a private network. NAT gateways can be used as
tunnel end points to provide secure VPN transport of packet data
across an external network domain.
Below are some additional security considerations associated with NAT
routers.
1. UDP sessions are inherently unsafe. Responses to a datagram
could come from an address different from the target address
used by sender ([Ref 4]). As a result, an incoming UDP packet
might match the outbound session of a traditional NAT router
only in part (the destination address and UDP port number of
the packet match, but the source address and port number may
not). In such a case, there is a potential security compromise
for the NAT device in permitting inbound packets with partial
match. This UDP security issue is also inherent to firewalls.
Traditional NAT implementations that do not track datagrams on
a per-session basis but lump states of multiple UDP sessions
using the same address binding into a single unified session
could compromise the security even further. This is because,
the granularity of packet matching would be further limited to
just the destination address of the inbound UDP packets.
2. Multicast sessions (UDP based) are another source for security
weakness for traditional-NAT routers. Once again, firewalls face
the same security dilemma as the NAT routers.
Say, a host on private network initiated a multicast session.
Datagram sent by the private host could trigger responses in the
reverse direction from multiple external hosts. Traditional-NAT
implementations that use a single state to track a multicast
session cannot determine for certain if the incoming UDP packet
is in response to an existing multicast session or the start of
new UDP session initiated by an attacker.
3. NAT devices can be a target for attacks.
Since NAT devices are Internet hosts they can be the target of a
number of different attacks, such as SYN flood and ping flood
attacks. NAT devices should employ the same sort of protection
techniques as Internet-based servers do.
REFERENCES
[1] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,G. and E.
Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.
[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC1700,
October, 1994.
[3] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC1122, October 1989.
[4] Braden, R., "Requirements for Internet Hosts -- Application and
Support", STD 3, RFC1123, October 1989.
[5] Baker, F., "Requirements for IP Version 4 Routers", RFC1812,
June 1995.
[6] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD
9, RFC959, October 1985.
[7] Postel, J., "Transmission Control Protocol (TCP) Specification",
STD 7, RFC793, September 1981.
[8] Postel, J., "Internet Control Message Protocol Specification"
STD 5, RFC792, September 1981.
[9] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC768,
August 1980.
[10] Mogul, J. and J. Postel, "Internet Standard Subnetting
Procedure", STD 5, RFC950, August 1985.
[11] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behavior Today", RFC2101, February 1997.
[12] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
[13] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC2406, November 1998.
[14] Kent, S. and R. Atkinson, "IP Authentication Header", RFC2402,
November 1998.
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC2409, November 1998.
[16] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC2407, November 1998.
[17] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC2385, August 1998.
[18] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
Authors' Addresses
Pyda Srisuresh
Lucent Technologies
4464 Willow Road
Pleasanton, CA 94588-8519
U.S.A.
Phone: (925) 737-2153
Fax: (925) 737-2110
EMail: srisuresh@lucent.com
Matt Holdrege
Lucent Technologies
1701 Harbor Bay Parkway
Alameda, CA 94502
Phone: (510) 769-6001
EMail: holdrege@lucent.com
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.