One document matched: draft-ford-behave-top-00.txt
Internet Draft B. Ford
Document: draft-ford-behave-top-00.txt M.I.T.
Expires: August 14, 2005 P. Srisuresh
Caymas Systems
February 2005
Topology complications from Network Address Translator deployments
Status of this Memo
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.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document identifies and provides recommendations for dealing
with issues that have arisen recently from the ubiquitous deployment
of network address translators (NAT), and the unconventional network
topologies that are often constructed with them. First, the
simplicity of administering networks through the combination of NAT
and DHCP is increasingly leading to the deployment of multi-level
hierarchies of inter-connected private networks involving
overlapping private IP address spaces. The creation of these
multi-level hierarchies is often unintentional, since each level of
NAT is typically deployed by a separate administrative entity such
as an ISP, a corporation, or a home user. Second, the popularity of
Ford & Srisuresh [Page 1]
Internet-Draft Topology complications from NAT deployments February 2005
corporate virtual private networks (VPN) in conjunction with NAT
leads to problems in which the private IP address space of the
network through which a remote client is attached may
unintentionally conflict with the private IP address space of the
corporate network into which the remote client is tunneled. This
document specifies best current practice recommendations for
addressing the issues identified.
Table of Contents
1. Introduction .................................................
2. Multi-Level Private Address Space Topologies .................
2.1. Operational Details of the Network ......................
2.1.1. Client/Server Communication ...........................
2.1.2. Peer-to-Peer Communication ............................
2.2. Anomalies and Caveats with the Network ..................
2.2.1. Anomalies with the Network ............................
2.2.2. Caveats with the Network ..............................
2.3. Recommendations .........................................
3. Remote Access VPN Topologies with Private Address Space ......
3.1. Operational Details of the Network ......................
3.2. Caveats with the Network ................................
3.3. Recommendations .........................................
4. Security Considerations ......................................
1. Introduction
The Internet was originally designed to use a single, global 32-bit
IP address space to identify hosts on the network, allowing
applications on one host to address and initiate communications with
applications on any other host regardless of the respective hosts'
topological locations or administrative domains. For a variety of
pragmatic reasons, however, the Internet has gradually drifted away
from strict conformance to this ideal of a single flat global address
space, and towards a hierarchy of smaller "private" address spaces
[RFC1918] clustered around a large central "public" address space.
The most important pragmatic causes of this unintended evolution of
the Internet's architecture appear to be:
1. Depletion of the 32-bit IPv4 address space due to the exploding
total number of hosts on the Internet. Although IPv6 promises to
solve this problem, the uptake of IPv6 has in practice been slower
than expected.
2. Perceived Security and Privacy: Traditional NAT devices provide a
filtering function that permits session flows to cross the NAT in
Ford & Srisuresh [Page 2]
Internet-Draft Topology complications from NAT deployments February 2005
just one direction, from private hosts to public network hosts.
This filtering function is widely perceived as a security benefit.
In addition, the NAT's translation of a host's original IP
addresses and port number in private network into an unrelated,
external IP address and port number is perceived by some as a
privacy benefit.
3. Ease-of-use: NAT vendors often combine the NAT function with a
DHCP server function in the same device, which creates a
compelling, effectively "plug-and-play" method of setting up small
Internet-attached personal networks that is often much easier in
practice for unsophisticated consumers than configuring up a true
IP subnet. The many popular and inexpensive consumer NAT devices
on the market are usually configured "out of the box" to obtain a
single "public" IP address from an ISP or "upstream" network via
DHCP, and the NAT device in turn acts as both a DHCP server and
default router for any "downstream" hosts (and even other NATs)
that the user plugs into it. Consumer NATs in this way
effectively create and manage private home networks automatically
without requiring any knowledge of network protocols or management
on the part of the user.
This ease-of-use benefit of NAT stems ultimately from the fact
that DHCP is only capable of providing a single auto-configured IP
address to each client. A DHCP client currently has no way to
request a *block* of IP addresses from the server, from it might
in turn form its own auto-configured "downstream" IP subnet for
which it provides its own DHCP service. The fact that DHCP is
only capable of auto-configuring client hosts, and is not capable
of auto-configuring entire "client subnets", makes NAT a
compelling solution in this common scenario.
2 Multi-Level Private Address Space Topologies
Due to the above pragmatic considerations and perhaps others, NATs
are increasingly, and often unintentionally, used to create
hierarchically interconnected clusters of private networks as
illustrated in the following diagram.
Ford & Srisuresh [Page 3]
Internet-Draft Topology complications from NAT deployments February 2005
Public Internet
(Public IP addresses)
----+---------------+---------------+---------------+----
| | | |
| | | |
66.39.3.7 18.181.0.31 138.76.29.7 155.99.25.1
+-------+ Host A Host B +-------------+
| NAT-1 | (Alice) (Jim) | NAT-2 |
| (Bob) | | (CheapoISP) |
+-------+ +-------------+
10.1.1.1 10.1.1.1
| |
| |
Private Network 1 Private Network 2
(private IP addresses) (private IP addresses)
----+--------+---- ----+-----------------------+----
| | | | |
| | | | |
10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 10.1.1.12
Host C Host D +-------+ Host E +-------+
| NAT-3 | (Mary) | NAT-4 |
| (Ann) | | (Lex) |
+-------+ +-------+
10.1.1.1 10.1.1.1
| |
| |
Private Network 3 | Private Network 4
(private IP addresses)| (private IP addresses)
----+-----------+---+ ----+-----------+----
| | | |
| | | |
10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11
Host F Host G Host H Host I
Figure 1: Multi-level NAT topology with private address space
In the above scenario, Bob, Alice, Jim, and CheapoISP have each
obtained a "genuine", globally routable IP address from an upstream
service provider. Alice and Jim have chosen to attach only a single
machine at each of these public IP addresses, preserving the
originally intended architecture of the Internet and making their
hosts, A and B, globally addressable throughout the Internet. Bob,
in contrast, has purchased and attached a typical consumer NAT box.
Bob's NAT obtains its external IP address (66.39.3.7) from Bob's ISP
via DHCP, and automatically creates a private 10.1.1.x network for
Bob's hosts C and D, acting as the DHCP server and default router for
Ford & Srisuresh [Page 4]
Internet-Draft Topology complications from NAT deployments February 2005
this private network. Bob probably does not even know anything about
IP addresses; he merely knows that plugging the NAT into the Internet
as instructed by the ISP, and then plugging his hosts into the NAT as
the NAT's manual indicates, seems to work and gives all of his hosts
access to Internet.
CheapoISP, an inexpensive service provider, has allocated only one or
a few globally routable IP addresses, and uses NAT to share these
public IP addresses among its many customers. Such an arrangement is
becoming extremely common, especially in rapidly-developing countries
where the exploding number of Internet-attached hosts greatly
outstrips the ability of ISPs to obtain globally unique IP addresses
for them. CheapoISP has chosen the popular 10.1.1.x address for its
private network, since this is one of the three well-known private IP
address blocks allocated in RFC specifically for this purpose.
Out of the three incentives listed above for NAT deployment, the last
two still apply even to customers of ISPs that use NAT, resulting in
multi-level NAT topologies as illustrated in the right side of the
above diagram. (Even three-level NAT topologies are known to
exist.) CheapoISP's customers Ann, Mary, and Lex have each obtained
a single IP address on CheapoISP's network (Private Network 2), via
DHCP as usual. Mary attaches only a single host at this point, but
Ann and Lex each independently purchase and deploy consumer NATs in
the same way that Bob did above. As it turns out, these consumer
NATs also happen to use 10.1.1.x addresses for the private networks
they create, since these are the configuration defaults hard-coded
into the NATs by their vendors. Ann and Lex probably know nothing
about IP addresses, and in particular they are probably unaware that
the IP address spaces of their own private networks overlap not only
with each other but also with the private IP address space used by
their immediately upstream network.
Nevertheless, despite this direct overlap, all of the "multi-level
NATted hosts" - F, G, H, and I in this case - all nominally function
and are able to initiate connections to any public server on the main
Internet that has a globally routable IP address. Connections made
from these hosts to the main Internet are merely translated twice:
once by the consumer NAT (3 or 4) into the IP address space of
CheapoISP's Private Network 2, and then again by CheapoISP's NAT 2
into the main Internet's global IP address space.
2.1 Operational Details of the Network
In the "de facto" Internet address architecture that has resulted
from the above pragmatic and economic incentives, only the nodes on
the main Internet have globally unique IP addresses assigned by the
official IP address registries. IP addresses on different private
Ford & Srisuresh [Page 5]
Internet-Draft Topology complications from NAT deployments February 2005
networks are typically managed independently: either manually by the
administrator of the private network itself, or automatically by the
NAT through which the private network is connected to its "upstream"
service provider.
By convention, nodes on private networks are usually assigned IP
addresses in one of the private address space ranges specifically
allocated to this purpose in RFC 1918, ensuring that private IP
addresses are easily distinguishable and do not conflict with the
public IP addresses officially assigned to globally routable Internet
hosts. A given private IP address can be and often is reused across
many different private networks, however. In the figure above, for
example, private networks 1, 2, 3, and 4 all have a node with IP
address 10.1.1.10.
Because the public and private IP address ranges are numerically
disjoint, nodes on private networks can make use of both public and
private IP addresses when initiating network communication sessions.
Nodes on private networks can use private IP addresses to refer to
other nodes on the same private network, and nodes can use public IP
addresses to refer to nodes on the main Internet. Nodes on private
networks have no direct method of addressing nodes on other private
networks, however, and nodes on the main Internet have no direct way
to address nodes on any private network. For example, host F in the
figure above can directly address hosts A, B, and G using their
assigned IP addresses, but F has no way to address any of the other
hosts in the diagram. Host F in particular has no way even to
address host E, even though E is located on the immediately
"upstream" private network through which F is connected to the
Internet! (Host E has the same IP address as host G, which is
"legitimate" in the NAT world because the two hosts are on different
private networks.)
2.1.1. Client/Server Communication
When a host on a private network initiates a client/server-style
communication session with a server on the main Internet, via the
server's public IP address, the NAT intercepts the packets comprising
that session (usually as a consequence of being the default router
for the private network), and modifies the packets' IP and TCP/UDP
headers so as to make the session appear externally as if it was
initiated by the NAT itself.
For example, if host C above initiates a connection to host A at IP
address 18.181.0.31, NAT 1 modifies the packets comprising the
session so as to appear on the main Internet as if the session
originated from NAT 1. Similarly, if host F on private network 3
initiates a connection to host A, NAT 3 modifies the session so as to
Ford & Srisuresh [Page 6]
Internet-Draft Topology complications from NAT deployments February 2005
appear on private network 2 as if it had originated from NAT 3 at IP
address 10.1.1.10. The modified session then traverses private
network 2 and arrives at NAT 2, which further modifies the session so
as to appear on the main Internet as if it had originated from NAT 2
at public IP address 155.99.25.1. The NATs in effect serve as
proxies that give their private "downstream" client nodes a temporary
presence on "upstream" networks to support individual communication
sessions.
2.1.2. Peer-to-Peer Communication
While this network organization functions in practice for
client/server-style communication, when the client is behind one or
more levels of NAT and the server is on the main Internet, the lack
of globally routable addresses for hosts on private networks makes
direct peer-to-peer communication between those hosts difficult. For
example, two private hosts F and H on the network shown above might
"meet" and learn of each other through a well-known server on the
main Internet, such as Host A, and desire to establish direct
communication between G and H without requiring A to forward each
packet. If G and H merely learn each other's (private) IP addresses
from a registry kept by A, their attempts to connect to each other
will fail because G and H reside on different private networks.
Worse, if their connection attempts are not properly authenticated in
some fashion, they may appear to succeed but end up talking to the
wrong host: for example, G may end up talking to Host F, the host on
Private Network 3 that happens to have the same private IP address as
Host H. Host H might similarly end up unintentionally connecting to
Host I.
2.2. Anomalies and Caveats with the Network
(XXX needs work)
2.2.1 Anomalies with the network
Even though conventional wisdom would suggest that the network
described above is seriously broken, in practice it still works in
many ways. Let us look at some anomalies here.
For example, NAT-3 & NAT-4 are apparently multi-homed on the same
subnet through both their interfaces. NAT-3 is on subnet 10.1.1/24
through its external interface facing NAT-2, and is also on subnet
10.1.1/24 through its private interface facing clients, Host-F and
Host-G. Similarly the case wit NAT-4. In a traditional network, when
a node has multiple interfaces with IP addresses on the same subnet,
it is natural to assume that all interfaces with addresses on the
same subnet are on a single connected LAN (bridged LAN or a single
physical LAN). Clearly, that is not the case here. Even though both
Ford & Srisuresh [Page 7]
Internet-Draft Topology complications from NAT deployments February 2005
NAT-3 and NAT-4 have two interfaces on the same subnet 10.1.1/24, the
two interfaces are on two disjoint subnets and LANs. So, the NATs are
really not multi-homed. This is an anomaly.
Both NAT-3 and NAT-4 are incapable of communicating reliably as a
transport endpoint with other nodes on their adjacent networks
(ex: private networks 2 and 3 in the case of NAT-3 and private
Networks 2 and 4 in the case of NAT-4). This is because applications
on either of the Nat devices cannot know to differentiate packets
from hosts either of the subnets bearing the same IP address. If
NAT-3 attempts to resolve the IP address of a neighboring host in
the conventional manner by broadcasting an ARP request on all of its
physical interfaces bearing the same subnet, it may get a different
response on each of its physical interfaces. This is another
anomaly.
Broken as it already is, it could have been worse and non-functional
if the network layout wasn't carefully orchestrated to work.
For example, all external interfaces for intermediate Nat devices
in figure 1 are arranged hierarchically, so the outgoing path for
all intermediate NAT devices are oriented towards the Internet
facing NAT. Further, the NAT devices provide the DHCP-service on
the private interfaces and the NAT service on the external interface.
If the nodes are connected differently or the services were offered
on the wrong interface, chaos could have ensued. Imagine NAT-3
device having its private interface on private network 2 and NAT
interface on private network 3.
Chaos would also ensue if there were multiple NAT devices on the same
LAN. Multiple NAT devices providing DHCP service on the same LAN,
from the same address pool is a recipe for chaos. Multiple nodes
would end up having the same IP address. That would make the network
broken. The network can also be broken if two NAT nodes attempt to
provide NAT service without coordination between the two.
The network will also be broken, if the address a NAT node (ex: NAT-3
or NAT-4) assumed on the DHCP-service providing interface is same as
the address it is assigned on the external interface. This can easily
happen when the vendors are different. Say, both interfaces being
assigned 10.1.1.1
2.2.1 Caveats with the network
Below are some known caveats with the network shown in figure 1.
1. The NAT boxes (NAT-3, NAT-4, NAT-1, NAT-2) themselves do not
provide any service other than respond to ping. NATs are not managed.
Ford & Srisuresh [Page 8]
Internet-Draft Topology complications from NAT deployments February 2005
2. Hosts on the private realm are all assumed to be on a single LAN
subnet.
3. This can be a security threat. What if ISP unwisely uses private
RFC1918 IP addresses for its mail servers, etc., which need to be
accessible to its customers? Customer mail messages could be
hijacked by the ISPÆs mail server.
2.3. Recommendations
(XXX needs work.)
Consumer-oriented "Plug and Play" NAT devices MUST, and all NATs
SHOULD, be able to handle topologies such as the one described above,
in which a private IP address space on one side of the NAT
potentially conflicts with the private IP address space on the other
side. This means that the NAT must be able to keep the two IP
address spaces separate in its internal data structures, and base all
packet processing decisions on the "side" or "port" from which the
packet arrived and not just on the basis of the IP addresses it
contains.
NATs should individually conform to [BEHAVE-UDP] and [BEHAVE-TCP]
guidelines, especially including hairpin translation support.
Peer-to-peer apps should conform to [BEHAVE-APP] guidelines for
middlebox traversal.
Ideally, ISPs should not NAT their customers. If they do, any
servers on the ISP's private network that need to be accessible to
the ISP's customers (e.g., mail servers) should have global IP
addresses, to ensure accessibility to customers who deploy NAT
themselves.
NAT boxes should provide an ability to use one of two DHCP address
pools and automagically use an address pool that does not conflict
with the external interface IP address.
3. Remote Access VPN Topologies with Private Address Space
Remote Access VPN is quite popular amongst enterprises. Enterprises
use Remote Access VPN as a means to allow secure access to their
employees working from outside the enterprise premises. While
outside the enterprise premises, the employee may be located in
his/her home office, a hotel, a conference or a partner's office.
In all cases, it is desirable for the employee at the remote site
to have complete access to his/her corporate network and the
applications running on the corporate networks. This is so the
Ford & Srisuresh [Page 9]
Internet-Draft Topology complications from NAT deployments February 2005
employee can get his/her work done seamlessly without jeopardizing
the integrity and confidentiality of the corporate network and the
applications running on the network.
Besides authenticating the employees prior to granting access,
remote access servers in the enterprise enforce different forms of
security on the remote access VPN clients for securing the
integrity and confidentiality of the run-time traffic between the
VPN client and the remote access server. IPsec, L2TP and SSL are
some of the well known secure VPN technologies used by the remote
access vendors.
Many of the small enterprises deploy their internal networks using
the RFC-1918 specified private address space. The enterprises use
NAT devices to connect to the public Internet. Many of the
applications in the corporate network in turn refer to information
(such as URLs) and services that refer to other nodes in the
private corporate network. Some of the applications (such as NFS)
rely on simple source IP address based filtering to restrict
access to corporate users. These are some of the reasons why the
remote access servers are configured with a block of IP addresses
from the corporate network to assign to remote access VPN clients
prior to allowing access to corporate resources. VPN clients use
the virtual IP assigned to them by the corporate VPN server to
access networks and applications inside the corporate.
Consider the following remote access scenario.
Ford & Srisuresh [Page 10]
Internet-Draft Topology complications from NAT deployments February 2005
(Corporate Private network 10.0.0.0/8)
--------+---------------+------------+----------
|
|
10.1.1.1
+---------------+
| |
| Secure |
| Remote Access |
| VPN Server |
+------+--------+
129.32.34.18
|
{--------------------+---------------}
{ }
{ Public Internet }
{ (Public IP addresses) }
{ }
{--------------------+---------------}
|
155.99.25.1
+----------------+
| NAT |
| (in a Hotel | +--------+
| or home office | | |
| or a partner's | | DHCP |
| corp. office | | Server |
| | | |
+----------------+ +--------+
10.1.1.1 10.1.1.2
| |
Remote Private Network | |
----+-----------+-----------+-------------+----------+------
| | | |
| | | |
10.1.1.10 10.1.1.11 10.1.1.12 10.1.1.13
Host A Host B +--------+ Host C
| RA-VPN |
| Client |
| PC |
+--------+
Figure 2: Remote access VPN to access enterprise from private LAN
In the above scenario, say an employee of the corporate is at a
remote site and trying to access the corporate network using the
Ford & Srisuresh [Page 11]
Internet-Draft Topology complications from NAT deployments February 2005
VPN client. The corporate network is laid out using 10.0.0.0/8
and say the VPN server is configured with an address block of
10.1.1.0/24 to assign virtual IP addresses to its remote access
clients. Now. say the employee at the remote site is attached to
a network on the remote site which also happens to be using a
RFC-1918 address space based network and coincidentally overlaps
the corporate network. In such a situation, there can be several
problems with using the VPN client to connect to the remote
access server at the enterprise.
The following subsections go on to describe the operational
details of the VPN, caveats with the above address overlap
situation and possible remedies to correct the situation.
3.1. Operational Details of the Network
Typically, when an employee at the remote site launches his/her
VPN client, the VPN client is required to authenticate with the VPN
server at the corporate premises. Once the authentication succeeds,
the VPN server assigns a Virtual IP (VIP) address for use by the
VPN client in all its transactions with the corporate network and
applications. The VPN client in turn installs a Virtual adapter
(VA) on the PC and configures the VA with the VIP address it was
assigned by the VPN server. Further, the VPN client adds new routes
to the PC such that all the subnets in the corporate are accessible
via the Virtual Adapter. By doing this, all traffic directed to
and from the corporate networks is redirected to the secure VPN,
while leaving all other routes unchanged on the PC. This works well
so long as there is no conflict of routes on the PC when new routes
to the corporate network are added.
This becomes tricky when the corporate intranet network is built
using RFC1918 address space and the remote location where the
VPN client is launched is also using the RFC1918 address space.
In such a situation, the routing table on the PC will have a
conflict in accessing nodes on the corporate site and nodes in
the remote site bearing the same IP address simultaneously.
Consequently, the VPN client may be unable to have full access
to the employee's corporate network.
3.2. Caveats with the Network
When there is address overlap between corporate network and the
remote site, the VPN user may be unaware of this and may loose
connectivity to an arbitrary block of services on the corporate
network. Worse yet, when a certain service (ex: SMTP mail service)
Ford & Srisuresh [Page 12]
Internet-Draft Topology complications from NAT deployments February 2005
is configured on exactly the same IP address on both the corporate
site and the remote site, the user could unknowingly be using the
service on the wrong node at remote site, thereby violating the
integrity and confidentiality of the contents relating to that
application.
In the case a corporate address resource overlaps with the router
on the remote site, the VPN user could loose connectivity entirely
if requests to the router address are redirected to the VPN.
Likewise, if a corporate address resource overlaps with the DHCP
server on the remote site, the VPN user could also loose
connectivity if requests to the DHCP server are redirected to the
VPN.
3.3. Recommendations
Clearly, the remote access VPN client works best when the external
client IP address (on the ethernet NIC) does not overlap with the
corporate address space and the corporate VPN address pool. However,
this cannot be assumed always. Employees often need to work from
within arbitrary private IP address spaces such as hotel rooms, which
neither the employee nor the corporate network administrator has any
control over. In these situations, the following recommendations
will help ensure that a complete "network meltdown" is prevented.
1. The RA-VPN client's external IP address and subnet (at the remote
site) should not fall within the VIP address pool assigned by the
VPN server.
2. The VPN users should not attempt to access services on the remote
site and services on the corporate site simultaneously.
Specifically, while the VPN is connected, the VPN user should not
attempt to access services on the remote site. Some services such
as the routing and DHCP service may however be unavoidable.
3. Do not permit access to corporate services that are running on
an IP address that match the following entities at the remote
site. a) client's external IP address, b) client's next-hop
router IP address used to access the VPN server, and c) DHCP
server providing address lease on the external interface.
The good news is that all these three essential services are
on the same subnet on the external interface.
In general, it may be advisabale to disallow access to any
corporate network resource that overlaps the client's external
IP subnet. For example, if the PC's external NIC is configured
with 10.1.1.1/24, disallow access to the corporate network that
overlaps this subnet from the remote access VPN client.
Ford & Srisuresh [Page 13]
Internet-Draft Topology complications from NAT deployments February 2005
Note, the above recommendations do not guarantee that the remote
employee will be able to gain complete access to the corporate
network he needs to if there is address overlap. Below are some
recommendations to ensure the employee is always able to
access mission critical application on the corporate network.
1. Even if most of the private corporate network uses RFC1918 address
space, allocate global IP addresses at least for the pool of IP
addresses assigned to remote VPN clients, and for the critical
servers on the corporate network that the remote VPN clients
typically need to access. This will ensure at least that the
remote VPN clients can always access those critical servers
regardless of the private address space used at the remote
attachment point.
2. We can suggest that there be two IP address pools on the VPN
server, (or) two VPN servers with different address pools so
the address pool which is used for a VPN client doesn't
ever conflict with the physical NIC's IP address. For example,
the VPN server might detect a conflict and inform the user that
he/she should try to connect to the "other" VPN server or IP
address pool. Ideally, the VPN client and server could
cooperate to perform this negotiation automatically.
3. the subnet mask used on the hotels be as small as possible (say,
/29) and the hotels have a centralized DHCP-server that covers
multiple small subnets. By doing this, the likelihood of
conflict with corporate services is highly minimized.
Perhaps, if the VPN server identified the overlap of the remote IP
network and notified the VPN-client of the loss of connectivity to
that portion of the corporate world, the VPN-client could do
something about it - such as talk to the local admin about
assigning himself an IP address from a different subnet (say,
plugging to a different plug point) if the hotel has such a
facility.
4. Finally, the VPN-client could come in as bump in the stack and
redirect all relevant packets in the subnet (with the exception of
those that match with the router and DHCP server) over the VPN.
This at least reduces the size of the "black hole" on the
corporate network from a whole subnet to merely the specific
services running on the DHCP server and the next-hop router.
4. Security Considerations
(xxx needs work)
Ford & Srisuresh [Page 14]
Internet-Draft Topology complications from NAT deployments February 2005
References (XXX needs updating)
[BIDIR] Peer-to-Peer Working Group, NAT/Firewall Working Committee,
"Bidirectional Peer-to-Peer Communication with Interposing
Firewalls and NATs", August 2001.
http://www.peer-to-peerwg.org/tech/nat/
[ICE] J. Rosenberg, "Interactive Connectivity Establishment (ICE):
A Methodology for Network Address Translator (NAT) Traversal
for the Session Initiation Protocol (SIP)",
draft-rosenberg-sipping-ice-00 (Work In Progress),
February 2003.
[IPSEC-NAT] B. Aboba and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004.
[KEGEL] Dan Kegel, "NAT and Peer-to-Peer Networking", July 1999.
http://www.alumni.caltech.edu/~dank/peer-nat.html
[MIDCOM] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and
A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, August 2002.
[NAT-APPL] D. Senie, "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
[NAT-PROT] M. Holdrege and P. Srisuresh, "Protocol Complications
with the IP Network Address Translator", RFC 3027,
January 2001.
[NAT-PT] G. Tsirtsis and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[NAT-TERM] P. Srisuresh and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[NAT-TRAD] P. Srisuresh and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RSIP] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro,
"Realm Specific IP: Framework", RFC 3102, October 2001.
[SOCKS] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and
L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
Ford & Srisuresh [Page 15]
Internet-Draft Topology complications from NAT deployments February 2005
[STUN] J. Rosenberg, J. Weinberger, C. Huitema, and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[SYM-STUN] Y. Takeda, "Symmetric NAT Traversal using STUN",
draft-takeda-symmetric-nat-traversal-00.txt (Work In
Progress), June 2003.
[TCP] "Transmission Control Protocol", RFC 793, September 1981.
[TEREDO] C. Huitema, "Teredo: Tunneling IPv6 over UDP through NATs",
draft-ietf-ngtrans-shipworm-08.txt (Work In Progress),
September 2002.
[TURN] J. Rosenberg, J. Weinberger, R. Mahy, and C. Huitema,
"Traversal Using Relay NAT (TURN)",
draft-rosenberg-midcom-turn-01 (Work In Progress),
March 2003.
[UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized
Device Control Protocol V 1.0", November 2001.
http://www.upnp.org/standardizeddcps/igd.asp
[NAT-MIB] R. Rohit, P. Srisuresh, R. Raghunarayan, N. Pai, and,
C. Wang, "Definitions of Managed Objects for Network
Address Translators (NAT)", RFC 4008, February 2005
Authors' Addresses:
Bryan Ford
Computer Science and Artificial Intelligence Laboratory
Massachusetts Institute of Technology
77 Massachusetts Ave.
Cambridge, MA 02139
U.S.A.
Phone: (617) 253-5261
E-mail: baford@mit.edu
Web: http://www.brynosaurus.com/
Pyda Srisuresh
Caymas Systems, Inc.
1179-A North McDowell Blvd.
Petaluma, CA 94954
U.S.A.
Phone: (707) 283-5063
Ford & Srisuresh [Page 16]
Internet-Draft Topology complications from NAT deployments February 2005
E-mail: srisuresh@yahoo.com
Full Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Ford & Srisuresh [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 04:11:32 |