draft-ietf-ipngwg-esd-analysis-04.txt   draft-ietf-ipngwg-esd-analysis-05.txt 
INTERNET-DRAFT Matt Crawford INTERNET-DRAFT Matt Crawford
Fermilab Fermilab
<draft-ietf-ipngwg-esd-analysis-04.txt> Allison Mankin <draft-ietf-ipngwg-esd-analysis-05.txt> Allison Mankin
ISI ISI
Thomas Narten Thomas Narten
IBM IBM
John W. Stewart, III John W. Stewart, III
Juniper Juniper
Lixia Zhang Lixia Zhang
UCLA UCLA
February 12, 1999 October, 1999
Separating Identifiers and Locators in Addresses: Separating Identifiers and Locators in Addresses: |
An Analysis of the GSE Proposal for IPv6 An Analysis of the GSE Proposal for IPv6
<draft-ietf-ipngwg-esd-analysis-04.txt> <draft-ietf-ipngwg-esd-analysis-05.txt> |
Status of this Memo Status of this Memo |
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted. produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 11 skipping to change at page 2, line 11
"GSE - An Alternate Addressing Architecture for IPv6" proposal [GSE]. "GSE - An Alternate Addressing Architecture for IPv6" proposal [GSE].
In GSE, 16-byte IPv6 addresses are split into distinct portions for In GSE, 16-byte IPv6 addresses are split into distinct portions for
global routing, local routing and end-point identification. GSE global routing, local routing and end-point identification. GSE
includes the feature of configuring a node internal to a site with includes the feature of configuring a node internal to a site with
only the local routing and end-point identification portions of the only the local routing and end-point identification portions of the
address, thus hiding the full address from the node. When such a address, thus hiding the full address from the node. When such a
node generates a packet, only the low-order bytes of the source node generates a packet, only the low-order bytes of the source
address are specified; the high-order bytes of the address are filled address are specified; the high-order bytes of the address are filled
in by a border router when the packet leaves the site. in by a border router when the packet leaves the site.
There is a long history of a vague assertion in certain circles that It has often been said that IPv4 "got it wrong" by treating its |
IPv4 "got it wrong" by treating its addresses simultaneously as addresses simultaneously as locators and identifiers. However, there |
locators and identifiers. Despite these claims, however, there was has never beeeen a detailed and comprehensive proposal for a |
never a complete proposal for a scaleable network protocol which scaleable network protocol which separated the functions. As a |
separated the functions. As a result, it wasn't possible to do a result, it wasn't possible to do a serious analysis comparing and |
serious analysis comparing and contrasting a "separated" architecture contrasting a "separated" architecture and an "overloaded" |
and an "overloaded" architecture. The GSE proposal serves as a architecture. The GSE proposal serves as a vehicle for just such an |
vehicle for just such an analysis, and that is the purpose of this analysis, and that is the purpose of this paper.
paper.
We conclude that an architecture that clearly separates locators and We conclude that an architecture that clearly separates locators and
identifiers in addresses introduces new issues and problems that do identifiers in addresses introduces new issues and problems that do
not have an easy or clear solution. Indeed, the alleged not have an easy or clear solution. Indeed, the alleged
disadvantages of overloading addresses turn out to provide some disadvantages of overloading addresses turn out to provide some
significant benefits over the non-overloaded approach. significant benefits over the non-overloaded approach.
Contents Contents
Status of this Memo.......................................... 1 Status of this Memo.......................................... 1 |
1. Introduction............................................. 3
2. Definitions and Terminology.............................. 4 1. Introduction............................................. 3 |
3. Addressing and Routing in IPv4........................... 5 2. Definitions and Terminology.............................. 4 |
3.1. The Need for Aggregation............................ 7
3.2. The Pre-CIDR Internet............................... 7
3.3. CIDR and Provider-Based Addressing.................. 9
3.4. Multi-Homed Sites and Aggregation................... 12
4. The GSE Proposal......................................... 15 3. Addressing and Routing in IPv4........................... 5 |
4.1. Motivation For GSE.................................. 15
4.2. GSE Address Format.................................. 16
4.2.1. Routing Stuff (RG and STP)..................... 16
4.2.2. End-System Designator.......................... 18
4.3. Address Rewriting by Border Routers................. 19
4.4. Renumbering and Rehoming Mid-Level ISPs............. 20
4.5. Support for Multi-Homed Sites....................... 21
4.6. Explicit Non-Goals for GSE.......................... 22
5. Analysis: The Pros and Cons of Overloading Addresses..... 22 4. The GSE Proposal......................................... 14 |
5.1. Purpose of an Identifier............................ 23
5.2. Mapping an Identifier to a Locator.................. 25
5.2.1. Scalable Mapping of Identifiers to Locators.... 27
5.2.2. Insufficient Hierarchy Space in ESDs........... 27
5.3. Authentication of Identifiers....................... 28
5.3.1. Identifier Authentication in IPv4.............. 29
5.3.2. Identifier Authentication in GSE............... 30
5.4. Transport Layer: What Locator Should Be Used?....... 30
5.4.1. RG Selection On An Active Open................. 31
5.4.2. RG Selection On An Passive Open................ 31
5.4.3. Mid-Connection RG Changes...................... 31
5.4.4. The Impact of Corrupted Routing Goop........... 33
5.5. On The Uniqueness Of ESDs........................... 34
5.5.1. Impact of Duplicate ESDs....................... 34
5.5.2. New Denial of Service Attacks.................. 35
5.6. Summary of Identifier Authentication Issues......... 35
6. Conclusion............................................... 37 5. Analysis: The Pros and Cons of Overloading Addresses..... 21 |
7. Security Considerations.................................. 38 6. Conclusion............................................... 39 |
8. Acknowledgments.......................................... 38 7. Security Considerations.................................. 40 |
9. References............................................... 38 8. Acknowledgments.......................................... 40 |
10. Authors' Addresses...................................... 40 9. References............................................... 41 |
Appendix A: Increased Reliance on Domain Name System (DNS)... 41 10. Authors' Addresses...................................... 43 |
Appendix B: Additional Issues Related to GSE................. 45 Appendix A: Increased Reliance on Domain Name System (DNS)... 43 |
Appendix B: Additional Issues Related to Specifically to GSE. 47 |
Appendix C: Ideas Incorporated Into IPv6..................... 46 Appendix C: Ideas Incorporated Into IPv6..................... 48 |
Appendix D: Reverse Mapping of Complete GSE Addresses........ 47 Appendix D: Reverse Mapping of Complete GSE Addresses........ 49 |
1. Introduction 1. Introduction
In October of 1996, Mike O'Dell published an Internet-Draft (dubbed In October of 1996, Mike O'Dell published an Internet-Draft (dubbed
"8+8") that proposed significant changes to the IPv6 unicast "8+8") that proposed significant changes to the IPv6 unicast
addressing architecture. The 8+8 proposal was the topic of addressing architecture. The 8+8 proposal was the topic of
considerable discussion at the December 1996 IETF meeting in San considerable discussion at the December 1996 IETF meeting in San
Jose. Because the proposal offered both potential benefits (e.g., Jose. Because the proposal offered both potential benefits (e.g.,
enhanced routing scalability) and risks (e.g., changes to the basic enhanced routing scalability) and risks (e.g., changes to the basic
IPv6 architecture), the IPng Working Group held an interim meeting on IPv6 architecture), the IPng Working Group held an interim meeting on
skipping to change at page 14, line 5 skipping to change at page 13, line 16
It should be noted that the above example simplifies a very complex It should be noted that the above example simplifies a very complex
issue. For example, consider the example in Figure 4 again. issue. For example, consider the example in Figure 4 again.
Provider A could choose not to propagate a route entry for the longer Provider A could choose not to propagate a route entry for the longer
204.1.0/19 prefix, advertising only the shorter 204.1/16. In such 204.1.0/19 prefix, advertising only the shorter 204.1/16. In such
cases, provider C would always select Provider B. Internally, cases, provider C would always select Provider B. Internally,
Provider A would continue to route traffic from its other customers Provider A would continue to route traffic from its other customers
to Customer1 directly. If Provider A had a large enough customer to Customer1 directly. If Provider A had a large enough customer
base, effective load sharing might be achieved. base, effective load sharing might be achieved.
A advertises A advertises |
+------------+ 204.1/16 to C +------------+ +------------+ 204.1/16 to C +------------+ |
___| Provider A |-----------------| Provider C | ___| Provider A |-----------------| Provider C | |
/ +------------+ +------------+ / +------------+ +------------+ |
/ +----------/ / +----------/ |
/ / / / |
Customer1 --- / B advertises 204.1.0/19 to C Customer1 --- / B advertises 204.1.0/19 to C |
204.1.0.0/19 | / 204.1.0.0/19 | / |
| +------------+ | +------------+ |
----- | Provider B | ----- | Provider B | |
+------------+ +------------+ |
Figure 4 Figure 4 |
The third approach is for a multi-homed site to receive an allocation The third approach is for a multi-homed site to receive an allocation *
from each of its providers and not advertise the prefix obtained from from each of its providers and not advertise the prefix obtained from
one provider to any of its other providers. This approach has one provider to any of its other providers. This approach has
advantages from the perspective of route scaling because both advantages from the perspective of route scaling because both
allocations are aggregatable. Unfortunately, the approach doesn't allocations are aggregatable. Unfortunately, the approach doesn't
necessarily meet the demands of the multi-homed site. A site that necessarily meet the demands of the multi-homed site. A site that
has a prefix from each of its providers faces a number of choices has a prefix from each of its providers faces a number of choices
about how to use that address space. Possibilities include: about how to use that address space. Possibilities include:
1) The site can number a distinct set of hosts out of each of the 1) The site can number a distinct set of hosts out of each of the
prefixes. Consider a configuration where a site is connected to prefixes. Consider a configuration where a site is connected to
skipping to change at page 19, line 45 skipping to change at page 19, line 4
leaves a site, the egress border router fills in the high-order leaves a site, the egress border router fills in the high-order
portion of the source address with the appropriate RG. portion of the source address with the appropriate RG.
The point of keeping the RG hidden from nodes within the core of a The point of keeping the RG hidden from nodes within the core of a
site is to insure the changeability of the RG without impacting the site is to insure the changeability of the RG without impacting the
site itself. It is expected that the RG would need to change site itself. It is expected that the RG would need to change
relatively frequently (e.g., several times a year) in order to relatively frequently (e.g., several times a year) in order to
support sufficient aggregation as the topology of the Internet support sufficient aggregation as the topology of the Internet
changes. A change to a site's RG would only require a change at the changes. A change to a site's RG would only require a change at the
site's egress point, and it's well possible that this change could be site's egress point, and it's well possible that this change could be
accomplished through a dynamic protocol with the upstream provider. accomplished through a dynamic protocol with the upstream provider. |
In addition, the site's DNS records would need updating to properly |
indicate the current RG value.
Hiding a site's RG from its internal nodes does not, however, mean Hiding a site's RG from its internal nodes does not, however, mean
that changes to RG have no impact on end sites. Since the full 16- that changes to RG have no impact on end sites. Since the full 16-
byte address of a node isn't a stable value (the RG portion can byte address of a node isn't a stable value (the RG portion can
change), a stored address may contain invalid RG and be unusable if change), a stored address may contain invalid RG and be unusable if
it isn't "refreshed" through some other means. For example, opening it isn't "refreshed" through some other means. For example, opening
a TCP connection, writing the address of the peer to a file and then a TCP connection, writing the address of the peer to a file and then
later trying to reestablish a connection to that peer may well fail. later trying to reestablish a connection to that peer may well fail.
For intra-site communication, however, it is expected that only the For intra-site communication, however, it is expected that only the
Site-Local RG would be used (and stored) which would continue to work Site-Local RG would be used (and stored) which would continue to work
skipping to change at page 26, line 19 skipping to change at page 25, line 30
Routing Stuff will result any time when cached addresses are used Routing Stuff will result any time when cached addresses are used
after the Routing Stuff of the address becomes invalid. This may after the Routing Stuff of the address becomes invalid. This may
happen if addresses are stored in configuration files, a mobile node happen if addresses are stored in configuration files, a mobile node
moves to a new location, long-running applications (clients and moves to a new location, long-running applications (clients and
servers) cache the result of DNS queries, a long-running connection servers) cache the result of DNS queries, a long-running connection
attempts to continue operating during a site renumbering event, etc. attempts to continue operating during a site renumbering event, etc.
Whatever the causes, the failures are fundamentally due to dynamic Whatever the causes, the failures are fundamentally due to dynamic
topological changes at the network layer, yet in GSE such failures topological changes at the network layer, yet in GSE such failures
are left to be dealt with at the application level (through DNS), are left to be dealt with at the application level (through DNS),
because neither the transport nor the network level has the ability because neither the transport nor the network level has the ability
to re-mapping identifiers to corresponding locators. to re-map identifiers to corresponding locators. |
To avoid the above problem a network architecture must provide the To avoid the above problem a network architecture must provide the
ability to map an identifier to a locator. In IPv4, this mapping is ability to map an identifier to a locator. In IPv4, this mapping is
trivial, since the identifier and locator are combined in a single trivial, since the identifier and locator are combined in a single
quantity (i.e., the IPv4 address). GSE does not provide this mapping quantity (i.e., the IPv4 address). GSE does not provide this mapping
functionality directly. Instead, GSE assumes that a node's DNS name functionality directly. Instead, GSE assumes that a node's DNS name
serves as its stable identifier, and uses normal DNS queries to map serves as its stable identifier, and uses normal DNS queries to map
the DNS "identifier" into an IPv6 address. The IPv6 address contains the DNS "identifier" into an IPv6 address. The IPv6 address contains
both the ESD identifier together with its Routing Stuff, that is an both the ESD identifier together with its Routing Stuff, that is an
initial binding/mapping between the identifier and locator. When initial binding/mapping between the identifier and locator. When
skipping to change at page 29, line 5 skipping to change at page 28, line 14
The remainder of this section discusses how identifier authentication The remainder of this section discusses how identifier authentication
is done in both IPv4 and GSE, and shows how overloading an address is done in both IPv4 and GSE, and shows how overloading an address
with both an identifier and a locator provides a significant with both an identifier and a locator provides a significant
automatic identifier authentication. In contrast, there is automatic identifier authentication. In contrast, there is
essentially no identifier authentication in GSE. It should be noted essentially no identifier authentication in GSE. It should be noted
that the actual strength of authentication that would be considered that the actual strength of authentication that would be considered
sufficient is a topic in its own right, and we do not cover it here. sufficient is a topic in its own right, and we do not cover it here.
Instead, we focus on the relative strengths in the two schemes. Instead, we focus on the relative strengths in the two schemes.
The following discussion assumes an absence of cryptographic |
authentication to bind an identifier to an end site. Many of the |
concerns described below would become non-issues if an appropriate |
cryptographic infrastructure were available. Section 5.5 discusses |
this issue in more detail. |
5.3.1. Identifier Authentication in IPv4 5.3.1. Identifier Authentication in IPv4
As described earlier, an IPv4 address simultaneously plays two roles: As described earlier, an IPv4 address simultaneously plays two roles:
a unique identifier and a locator. Using an overloaded address as an a unique identifier and a locator. Using an overloaded address as an
identifier has the side-effect of insuring that (for all practical identifier has the side-effect of insuring that (for all practical
purposes) the identifier is globally unique. Furthermore, because purposes) the identifier is globally unique. Furthermore, because
the same number is used both to identify an interface and to deliver the same number is used both to identify an interface and to deliver
data to that interface, it is impossible for some interface A to use data to that interface, it is impossible for some interface A to use
the identification of another interface B in an attempt to receive the identification of another interface B in an attempt to receive
data destined to B without being detected, unless the routing system data destined to B without being detected, unless the routing system
is compromised. is compromised. |
When both interfaces A and B claim the same unicast address, the When both interfaces A and B claim the same unicast address, an |
routing subsystem generally delivers packets to only one of them. (uncompromised) routing subsystem generally delivers packets to only |
The other node will quickly realize that something is wrong (since one of them. The other node will quickly realize that something is |
communication using the duplicate address fails) and take corrective wrong (since communication using the duplicate address fails) and |
actions, either correcting a misconfiguration or otherwise detecting take corrective actions, either correcting a misconfiguration or |
and thwarting the intruder. To understand how the routing subsystem otherwise detecting and thwarting the intruder. To understand how |
prevents the same address from being used in multiple locations, the routing subsystem prevents the same address from being used in |
there are two cases to consider, depending on whether the two multiple locations, there are two cases to consider, depending on |
interfaces using duplicate addresses are attached to the same or to whether the two interfaces using duplicate addresses are attached to |
different links. the same or to different links.
When two interfaces on the same link use the same address, a node When two interfaces on the same link use the same address, a node
(host or router) sending traffic to the duplicate address will in (host or router) sending traffic to the duplicate address will in
practice send all packets to one of the nodes. On Ethernets, for practice send all packets to one of the nodes. On Ethernets, for
example, the sender will use ARP (or Neighbor Discovery in IPv6) to example, the sender will use ARP (or Neighbor Discovery in IPv6) to
determine the link-layer address corresponding to the destination determine the link-layer address corresponding to the destination
address. When multiple ARP replies for the target IP address are address. When multiple ARP replies for the target IP address are
received, the most recently received response replaces whatever is received, the most recently received response replaces whatever is
already in the cache. Consequently, the destinations a node using a already in the cache. Consequently, the destinations a node using a
duplicate IP address can communicate with depends on what its duplicate IP address can communicate with depends on what its
neighboring nodes have in their ARP caches. In most cases, such neighboring nodes have in their ARP caches. In most cases, such
communication failures become apparent relatively quickly, since it communication failures become apparent relatively quickly, since it
is unlikely that communication can proceed correctly on both nodes. is unlikely that communication can proceed correctly on both nodes.
It is also the case that a number of ARP implementations (e.g., BSD- It is also the case that a number of ARP implementations (e.g., BSD-
derived implementations) log warning messages when an ARP request is derived implementations) log warning messages when an ARP request is
received from a node using the same address as the machine receiving received from a node using the same address as the machine receiving
the ARP request. the ARP request.
The previous discussion describes the operation of ARP in the absence |
of intruders or other malicious users. ARP has a number of security |
vulnerabilities that make it trivial for an intruder to intercept |
traffic and selectively process traffic that traverses a link, |
provided the intruder is attached to the link the traffic of interest |
traverses. For example, an intruder could intercept all traffic to an |
address by being the last to return an ARP response, and then |
selectively relay the traffic (after examining and/or modifying it) |
to its intended recipient. This is a classic man-in-the-middle |
attack. |
When two interfaces on different links use the same address, the When two interfaces on different links use the same address, the
routing subsystem generally delivers packets to only one of the nodes routing subsystem generally delivers packets to only one of the nodes
because only one of the links has the right subnet corresponding to because only one of the links has the right subnet corresponding to
the IP address. Consequently, the node using the address on the the IP address. Consequently, the node using the address on the
"wrong" link will generally never receive any packets sent to it and "wrong" link will generally never receive any packets sent to it and
will be unable to communicate with anyone. For obvious reasons, this will be unable to communicate with anyone. For obvious reasons, this
condition is usually detected quickly. condition is usually detected quickly.
It should be noted that although an address containing a combined It should be noted that although an address containing a combined
identifier and locator can be forged, the routing subsystem identifier and locator can be forged, the routing subsystem
significantly limits communication using the forged address. First, significantly limits communication using the forged address. First,
return traffic will be sent to the correct destination and not the return traffic will be sent to the correct destination and not the
originator of the forged address. This alone prevents certain types originator of the forged address. This alone prevents certain types
of spoofing attacks. For example, if a destination receives an of spoofing attacks. For example, if a destination receives an
unexpected packet corresponding to a TCP connection that it is unexpected packet corresponding to a TCP connection that it is
unaware of, it may return at TCP segment resetting the connection. unaware of, it may return a TCP segment resetting the connection. |
Second, routers performing ingress filtering can refuse to forward Second, routers performing ingress filtering can refuse to forward
traffic claiming to originate from a source whose claimed address traffic claiming to originate from a source whose source address does |
does not match the expected addresses (from a topology perspective) not match the expected addresses (from a topology perspective) for
for sources located within a particular region [RFC 2267]. To sources located within a particular region [RFC 2267]. To
effectively masquerade as someone else requires subverting the effectively masquerade as someone else requires subverting the
intermediate routing subsystem. intermediate routing subsystem.
To summarize, the routing subsystem in IPv4 provides a limited (but |
quite significant) defense against arbitrary hijacking of packets to |
an improper destination. We do not claim that this defense is |
sufficient against all types of attacks by a determined intruder. |
However, it does provide some degree of defense against accidental |
misconfigurations (e.g., assigning an improper address to an |
interface) and does erect hurdles that prevent an abritrary node from |
impersonating another node. The more dangerous attack, subverting |
the routing subsystem by injecting unauthorized routes, can be traced |
and detected by appropriate tools. |
5.3.2. Identifier Authentication in GSE 5.3.2. Identifier Authentication in GSE
In GSE, it is not possible for the routing subsystem to provide any In GSE, it is not possible for the routing subsystem to provide any
enforcement on the authenticity of identifiers with respect to their enforcement on the authenticity of identifiers with respect to their
corresponding Routing Stuff, since the Routing Stuff and ESD portions corresponding Routing Stuff, since the Routing Stuff and ESD portions |
of an address are by definition completely orthogonal quantities. of an address are by definition completely orthogonal quantities. |
This fundamental problem is compounded by the fact that GSE provides Thus, even the limited protection offered by IPv4 is not immediately |
no way (at the transport or network layer) to map an ESD into its available. |
corresponding Routing Stuff. Thus, when looking at the source
address of a received packet, there is no way to ascertain whether An interesting question is whether any such protection is needed. One |
the Routing Stuff portion of the address corresponds to legitimate argument is that address-based authentication is so inherently weak |
Routing Stuff with respect to the corresponding ESD. Consequently, as to be useless, thus the increased vulnerability of a GSE-like |
it becomes trivial in many cases for one node to masquerade as scheme is not significant. Where authentication is desired, the use |
another. of something based on cryptography is necessary (e.g., IPsec |
[RFC2401]). |
There are at least two arguments against this line of thought. |
First, the lack of protection comparable to IPv4 may lead to a new |
set of (poorly understood) security threats; Section 5.5 below |
describes one possible threat. These threats must be dealt with at |
the transport (or lower) layer because the threats are to the |
integrety of the transport layer itself. Attempting to solve them at |
higher-layers (e.g., via IPsec [RFC2401] and IKE [RFC2409]) results |
in a potential layering circularity, where the security mechanisms |
rely on a correctly functioning transport, but the transport relies |
on those same security mechanisms to provide a service. Whether such |
a mechanism can be designed is an area of future work. |
Second, requiring that basic threats to the transport layer be dealt |
with using cryptographic techniques significantly increases the cost |
of formerly simple packet exchanges. Cryptographic security no longer |
becomes a choice an application can make, but quite possibly a |
requirement to protect against certain types of attacks. Thus, the |
cost of deploying effective defenses against a new class of denial of |
service attacks may be quite significant.
5.4. Transport Layer: What Locator Should Be Used? 5.4. Transport Layer: What Locator Should Be Used?
In the following, we focus on what Routing Stuff to use with TCP; UDP In the following, we focus on what Routing Stuff to use with TCP; UDP
also depends on the Routing Stuff in similar way. Indeed, we believe also depends on the Routing Stuff in similar way. Indeed, we believe
that TCP is the "easier" case to deal with, for two reasons. First, that TCP is the "easier" case to deal with, for two reasons. First,
TCP is a stateful protocol in which both ends of the connection can TCP is a stateful protocol in which both ends of the connection can
negotiate with each other. UDP-based communications are stateless, negotiate with each other. UDP-based communications are stateless,
and remember nothing from one packet to the next. Consequently, and remember nothing from one packet to the next. Consequently,
changing UDP to remember locator information in addition to the changing UDP to remember locator information in addition to the
skipping to change at page 33, line 7 skipping to change at page 33, line 19
authenticated (e.g., using cryptographic means). In the GSE authenticated (e.g., using cryptographic means). In the GSE
proposal, the is no apparent way to authenticate such a change, since proposal, the is no apparent way to authenticate such a change, since
the remote peer doesn't even know its own RG. Consequently, the only the remote peer doesn't even know its own RG. Consequently, the only
reasonable approach in GSE is to send to the peer using the first RG reasonable approach in GSE is to send to the peer using the first RG
used for the entire life of a connection. That is, always use the used for the entire life of a connection. That is, always use the
first RG seen, and accept the loss of connectivity whenever the RG first RG seen, and accept the loss of connectivity whenever the RG
changes. changes.
5.4.4. The Impact of Corrupted Routing Goop 5.4.4. The Impact of Corrupted Routing Goop
Another interesting issue that arises is what impact corrupted RG Another interesting issue that arises is what impact corrupted RG |
would have on robustness. Because the RG is not covered by the TCP would have on robustness, given that there is no IPv6 header checksum |
checksum (the sender doesn't know what source RG will be inserted), that could help detect a corrupted source address field. Because the |
no TCP mechanism can detect such corruption at the receiver. RG is not covered by the TCP checksum (the sender doesn't know what |
Moreover, once a specific RG is in use, it does not change for the source RG will be inserted), no TCP mechanism can detect such |
duration of a connection. One interesting case occurs on the passive corruption at the receiver. Moreover, once a specific RG is in use, |
side of a TCP connection, where a server accepts incoming connections it does not change for the duration of a connection. One interesting |
from remote clients. If the initial SYN from the client includes a case occurs on the passive side of a TCP connection, where a server |
corrupted RG, the server TCP will create a TCP connection (in the accepts incoming connections from remote clients. If the initial SYN |
SYN-RECEIVED state) and cache the corrupted RG with the connection. from the client includes a corrupted RG, the server TCP will create a |
The second packet of the 3-way handshake, the SYN-ACK packet, would TCP connection (in the SYN-RECEIVED state) and cache the corrupted RG |
be sent to the wrong RG and consequently not reach the correct with the connection. The second packet of the 3-way handshake, the |
destination. Later, when the client retransmits the unacknowledged SYN-ACK packet, would be sent to the wrong RG and consequently not |
SYN, the server will continue to send the SYN-ACK using the bad RG. reach the correct destination. Later, when the client retransmits |
Eventually the client times out, and the attempt to open a TCP the unacknowledged SYN, the server will continue to send the SYN-ACK |
connection fails. using the bad RG. Eventually the client times out, and the attempt |
to open a TCP connection fails.
We next consider relaxing the restriction on switching RGs in an We next consider relaxing the restriction on switching RGs in an
attempt to avoid the previous failure scenario. The situation is attempt to avoid the previous failure scenario. The situation is
complicated by the fact that the RG on received packets may change complicated by the fact that the RG on received packets may change
for legitimate reasons (e.g., a multi-homed site load-shares traffic for legitimate reasons (e.g., a multi-homed site load-shares traffic
across multiple border routers). The key question is how one can across multiple border routers). The key question is how one can
determine which RG is valid and which is not. That is, for each of determine which RG is valid and which is not. That is, for each of
the destination RGs a sender attempts to use, how can it determine the destination RGs a sender attempts to use, how can it determine
which RG worked and which did not? Solving this problem is more which RG worked and which did not? Solving this problem is more
difficult than first appears, since one must cover the cases of difficult than first appears, since one must cover the cases of
skipping to change at page 34, line 20 skipping to change at page 34, line 35
malicious attacks. The exact uniqueness requirements for ESDs malicious attacks. The exact uniqueness requirements for ESDs
depends on what purpose they serve and how they are used. If the depends on what purpose they serve and how they are used. If the
correctness of some applications relies on the global uniqueness of correctness of some applications relies on the global uniqueness of
ESDs, then active checking and enforcement will be necessary. On the ESDs, then active checking and enforcement will be necessary. On the
other hand if ESDs are used only to uniquely identify individual other hand if ESDs are used only to uniquely identify individual
endpoints within a session, then one may consider global uniqueness endpoints within a session, then one may consider global uniqueness
as unnecessary. as unnecessary.
5.5.1. Impact of Duplicate ESDs 5.5.1. Impact of Duplicate ESDs
Consider what happens when two nodes using the same ESD attempt to Consider what happens when two nodes using the same ESD attempt to |
communicate with each other. In the GSE proposal, a node queries the communicate with each other. In the GSE proposal, a node queries the |
DNS to obtain an IPv6 address. The returned address includes the DNS to obtain an IPv6 address. The returned address includes the |
Routing Stuff of an address (the RG+STP portions). The sender may Routing Stuff of an address (the RG+STP portions). At this point, |
not notice the destination ESD is the same as its own ESD and may the sender might notice the destination ESD is the same as its own |
well forward the packet to a router that delivers the packet to its ESD and indicate an error. If it doesn't check, however, it may well |
correct destination (using the information in the Routing Stuff). On forward the packet to a router that delivers the packet to its |
receipt of the packet, however, the destination node would extract correct destination (using the information in the Routing Stuff). On |
the ESD portion of the destination address and detect the conflict. receipt of the packet, again, the destination node could examine the |
ESD portion of the source address and determine that it is the same |
as its own and indicate an error. Alternatively, it could just |
process the packet without detecting the duplication and |
communication would proceed as normal (unless there are port number |
conflicts due to the sender and receiver allocating port numbers from |
the same name space).
A more problematic case occurs if two nodes having the same ESD A more problematic case occurs if two nodes having the same ESD
communicate with a third party. To the third party, packets received communicate with a third party. To the third party, packets received
from either machine might appear to be coming from the same machine from either machine might appear to be coming from the same machine
since they all carry the same ESD. Consequently, at the transport since they all carry the same ESD. Consequently, at the transport
level, if both machines choose the same source and destination port level, if both machines choose the same source and destination port
numbers (one of the ports --- a server's well-known port number --- numbers (one of the ports --- a server's well-known port number ---
will likely be the same), packets belonging to two distinct transport will likely be the same), packets belonging to two distinct transport
connections will be demultiplexed to a single transport end-point. connections will be demultiplexed to a single transport end-point.
skipping to change at page 35, line 40 skipping to change at page 36, line 14
purpose of invalidating the uniqueness assumption. For example, one purpose of invalidating the uniqueness assumption. For example, one
could deny service to host foo.bar.com by querying the DNS for its could deny service to host foo.bar.com by querying the DNS for its
corresponding ESD, and then impersonating that ESD. corresponding ESD, and then impersonating that ESD.
As a specific example, one GSE-specific denial-of-service attack As a specific example, one GSE-specific denial-of-service attack
would be for an intruder to masquerade as another host and "wedge" would be for an intruder to masquerade as another host and "wedge"
connections in a SYN-RECEIVED state by sending SYN segments connections in a SYN-RECEIVED state by sending SYN segments
containing an invalid RG in the source IP address for a specific ESD. containing an invalid RG in the source IP address for a specific ESD.
Subsequent connection attempts to the wedged host from the legitimate Subsequent connection attempts to the wedged host from the legitimate
owner of the ESD (if they used the same TCP port numbers) would then owner of the ESD (if they used the same TCP port numbers) would then
not complete, since return traffic would be sent to the wrong place. not complete, since return traffic would be sent to the wrong place. |
Note that this attack is worse than the common syn-flood attack |
because it not only ties up resources on the target machine, it |
blocks out legitimate access to the target machine by a specific |
third party. |
Another potential attack involves an intruder assuming the ESD of a |
target site (e.g., mit.edu), then opening TCP connections using |
mit.edu's ESD to a targer server (e.g., big-server.com). Because the |
RG would point back to the attacker, the attacker could create a |
number of TCP connections in an OPEN state without needing to guess |
the sequence numbers needed to complete a 3-way handshake. Once those |
connections are open, it would be difficult to (automatically) |
distinguish between connections that are part of a denial-of-service |
attack from those (idle) connections that are part of a legitimate |
activity. |
The previous discussion indicates that separating identifiers and |
locators opens up new potential denial-of-service attack policies |
that would need to be carefully studied. One way of addressing them |
would be to have a way to authenticate the RG associated with an |
identifier, as the attacks take advantage of the distinction between |
identifiers and locators.
5.6. Summary of Identifier Authentication Issues 5.6. Summary of Identifier Authentication Issues
In summary, changing the RG dynamically in a safe way for a In summary, changing the RG dynamically in a safe way for a
connection requires that an originator of traffic be able to connection requires that an originator of traffic be able to
authenticate a proposed change in the RG before sending to a authenticate a proposed change in the RG before sending to a
particular ESD via that RG. This is difficult for several reasons: particular ESD via that RG. This is difficult for several reasons:
1) It can't be done on an end-to-end basis in GSE (e.g., via IPSec) 1) It can't be done on an end-to-end basis in GSE (e.g., via IPsec) |
because the sender doesn't know what value the RG portion of the because the sender doesn't know what value the RG portion of the |
address will have when it reaches the receiver. address will have when it reaches the receiver. This issue is |
specific to GSE and other approaches in which the end node knows |
its own RG would not automatically have this problem. |
2) It can't be easily done in GSE using just the ESD because there |
is no mechanism at or below the transport layer to map ESDs into |
a quantity that can be used as a key to jump start the |
authentication process (using the DNS would be problematic due |
to layering circularity considerations). |
2) It can't be easily done in GSE because there is no mechanism at 3) It is conceivable that one could send a "who are you" type |
or below the transport layer to map ESDs into a quantity that message to a peer asking it to return a more suitable identifier |
can be used as a key to jump start the authentication process that can be used to jump start the authentication process. This |
(using the DNS would be problematic due to layering circularity additional information would include information needed to |
considerations). obtain keys, certificates, etc. from an appropriate source that |
can be used to verify proper use of an ESD by a particular node. |
Note, however, that the "who are you" makes use of the full |
address, not just the ESD portion.
3) Any scheme that uses the full IPv6 address to do the 4) Any scheme that uses the full IPv6 address to do the |
authentication can be used with today's standard provider-based authentication can be used with today's standard provider-based
addressing, raising the question of what benefit is retained addressing, raising the question of what benefit is retained
from having separate identifiers and locators. from having separate identifiers and locators.
Our final conclusion is that with the GSE approach, transport Our final conclusion is that with the GSE approach, transport
protocol end-points must make an early, single choice of the RG to protocol end-points must make an early, single choice of the RG to
use when sending to a peer and stick with that choice for the use when sending to a peer and stick with that choice for the
duration of the connection. Specifically: duration of the connection. Specifically:
1) The demultiplexing of arriving packets to their transport end 1) The demultiplexing of arriving packets to their transport end
skipping to change at page 36, line 50 skipping to change at page 38, line 9
separating identifiers and locators is the ability to have separating identifiers and locators is the ability to have
communication (e.g., a TCP connection) continue transparently, even communication (e.g., a TCP connection) continue transparently, even
when the Routing Stuff associated with a particular ESD changes. when the Routing Stuff associated with a particular ESD changes.
However, switching to a new Routing Stuff without properly However, switching to a new Routing Stuff without properly
authenticating it makes it trivial to hijack connections. authenticating it makes it trivial to hijack connections.
We cannot emphasize enough that the use of an ESD independent of an We cannot emphasize enough that the use of an ESD independent of an
associated RG can be very dangerous. That is, communicating with a associated RG can be very dangerous. That is, communicating with a
peer implies that one is always talking to the same peer for the peer implies that one is always talking to the same peer for the
duration of the communication. But as has been described in previous duration of the communication. But as has been described in previous
sections, such assurance can only come from properly authenticating sections, such assurance can only come from properly authenticating |
the RG associated with an ESD. That is not possible in GSE. the RG associated with an ESD. How to authentic the RG associated |
with an ESD in GSE does not appear to have a trivial solution is an |
open problem. |
5.7. The Need For Strong Authentication |
The problems described earlier stem from an inability to verify |
whether a particular RG is legitimately associated with an ESD. One |
approach that would address this problem is to use cryptographic |
techniques to verify the binding between RG and an ESD. There are two |
cases to consider. |
First, for an existing connection, switching from one RG to another |
risks the possibility of an intruder hijacking a connection. |
Addressing this risk involves having one endpoint verify |
(cryptographically) with its peer that proposed new RG is acceptable. |
This requires only an ability to communicate with the peer using the |
older (i.e., current) RG and using the older RG to verify the new RG. |
For example, a node could send its peer a message requesting |
cryptographic verification for a new RG prior to actually switching |
to it. Such verification would not require a public key |
infrastrucutre, as the purpose is not to verify that the legitimate |
owner of the ESD approves use of the RG, but that the peer with which |
one is currently communicating with (and who is using a particular |
ESD -- possibly illegally) approves switching to a different RG. |
A more problematic case involves the wedging of connections as |
described in Section 5.5.2. Here, an intruder improperly uses an |
identifier legitimately belonging to someone else, denying the |
legitimate owner service. Addressing this problem is more difficult. |
One approach is to verify the RG associated with an identifier the |
first time it is used. This would appear to require a global PKI |
infrastructure (not available today) in which every potential node is |
registered so that in the case of conflicts, it becomes possible to |
determine the legitimate owner of an identifier. |
Another interesting question concerns at what layer such |
cryptographic mechanisms would be needed. Ideally, the denial of |
service threats must be dealt with at the transport (or lower) layer |
because the threats are to the integrety of the transport layer |
itself. Attempting to solve them at higher-layers (e.g., via IPsec |
and IKE) results in a potential layering circularity, where the |
security mechanisms rely on a correctly functioning transport, but |
the transport relies on those same security mechanisms to provide a |
service. Further work is needed to determine whether such a mechanism |
can be designed using IPsec. |
6. Conclusion 6. Conclusion
The GSE proposal provides a concrete example of a network protocol The GSE proposal provides a concrete example of a network protocol
design that separates identifiers from locators in addresses. In design that separates identifiers from locators in addresses. In
this paper we compared GSE with IPv4's CIDR-style addressing to this paper we compared GSE with IPv4's CIDR-style addressing to
better understand the pros and cons of the respective design better understand the pros and cons of the respective design
approaches. approaches.
Functionally speaking, identifiers and locators each have a logically Functionally speaking, identifiers and locators each have a logically
different role to play. Thus overloading both in one field causes different role to play. Thus overloading both in one field causes
problems whenever the location of a node changes but its identity problems whenever the location of a node changes but its identity
does not. However, our analysis shows that overloading also presents does not. However, our analysis shows that overloading also presents |
two critically important benefits. three critically important benefits.
First, for network entity A to send data to network entity B, A must First, for network entity A to send data to network entity B, A must
not only know B's end identifier but also B's locator. No scalable not only know B's end identifier but also B's locator. No scalable
way is known at this time to provide this mapping at the network way is known at this time to provide this mapping at the network
layer, other than overloading the two quantities into an address as layer, other than overloading the two quantities into an address as
is done in IPv4. Fundamentally, a scalable mapping algorithm is done in IPv4. Fundamentally, a scalable mapping algorithm
strongly suggests that the identifier space be structured strongly suggests that the identifier space be structured
hierarchically, yet identifiers in GSE are not sufficiently large to hierarchically, yet identifiers in GSE are not sufficiently large to
both contain sufficient hierarchy and support stateless address both contain sufficient hierarchy and support stateless address
autoconfiguration. Instead, GSE forces applications to supply up- autoconfiguration. Instead, GSE forces applications to supply up-
to-date locators. However, relying on the locator provided at the to-date locators. However, relying on the locator provided at the
time communication is established as GSE does is inadequate when the time communication is established as GSE does is inadequate when the
remote locator can change dynamically, precisely the scenario that is remote locator can change dynamically, precisely the scenario that is
supposed to benefit from the separation. That is, the benefits of supposed to benefit from the separation. That is, the benefits of
separating the identifier from the locator are largely lost, if the separating the identifier from the locator are largely lost, if the
changes in the identifier to locator binding are not tracked quickly. changes in the identifier to locator binding are not tracked quickly.
Secondly, when communicating with a remote site, if the RG changes Second, when communicating with a remote site, if the RG changes |
there begins to be uncertainty as to whether a reliable TCP handshake there begins to be uncertainty as to whether a reliable TCP handshake
is possible (because of the need for passively opened TCP to use the is possible (because of the need for passively opened TCP to use the
RG's it obtains from the packets). Because the reliability of TCP's RG's it obtains from the packets). Because the reliability of TCP's
byte stream is critically dependent on its three-way handshake, this byte stream is critically dependent on its three-way handshake, this
is a significant issue. is a significant issue.
Finally, when communicating with a remote site, a receiver must be Finally, when communicating with a remote site, a receiver must be
able to insure (with reasonable certainty) that received data does able to insure (with reasonable certainty) that received data does
indeed come from the expected remote entity. In IPv4, it is possible indeed come from the expected remote entity. In IPv4, it is possible
to receive packets from a forged source, but the potential for to receive packets from a forged source, but the potential for
skipping to change at page 39, line 45 skipping to change at page 42, line 5
Microprocessor systems: Control and Status Registers (CSR) Microprocessor systems: Control and Status Registers (CSR)
Architecture for microcomputer buses." Architecture for microcomputer buses."
[IPv6-ADDRESS] "An IPv6 Aggregatable Global Unicast Address [IPv6-ADDRESS] "An IPv6 Aggregatable Global Unicast Address
Format", R. Hinden, M. O'Dell, S. Deering, RFC 2374, July, Format", R. Hinden, M. O'Dell, S. Deering, RFC 2374, July,
1998. 1998.
[MOBILITY] "IP Mobility Support", C. Perkins, RFC 2002, October, [MOBILITY] "IP Mobility Support", C. Perkins, RFC 2002, October,
1996. 1996.
[NAT] "IP Network Address Translator (NAT) Terminology and |
Considerations", P. Srisuresh, M. Holdrege, RFC 2663, |
August, 1999. |
[RFC1752] "The Recommendation for the IP Next Generation Protocol", [RFC1752] "The Recommendation for the IP Next Generation Protocol",
S. Bradner, A. Mankin, RFC 1752, January, 1995. S. Bradner, A. Mankin, RFC 1752, January, 1995.
[RFC1788] "ICMP Domain Name Messages", W. Simpson, RFC 1788, April, [RFC1788] "ICMP Domain Name Messages", W. Simpson, RFC 1788, April,
1995. 1995.
[RFC1884] "IP Version 6 Addressing Architecture", R. Hinden & S. [RFC1884] "IP Version 6 Addressing Architecture", R. Hinden & S.
Deering, Editors, RFC 1884. Deering, Editors, RFC 1884.
[RFC1958] "Architectural Principles of the Internet", B. Carpenter, [RFC1958] "Architectural Principles of the Internet", B. Carpenter,
skipping to change at page 40, line 21 skipping to change at page 42, line 34
[RFC2008] "Implications of Various Address Allocation Policies for [RFC2008] "Implications of Various Address Allocation Policies for
Internet Routing", Y. Rekhter, T. Li, RFC 2008, October Internet Routing", Y. Rekhter, T. Li, RFC 2008, October
1996. 1996.
[RFC2073] An IPv6 Provider-Based Unicast Address Format. Y. [RFC2073] An IPv6 Provider-Based Unicast Address Format. Y.
Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel. RFC Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel. RFC
2073, January, 1997. 2073, January, 1997.
[RFC2267] Network Ingress Filtering: Defeating Denial of Service [RFC2267] Network Ingress Filtering: Defeating Denial of Service
Attacks which employ IP Source Address Spoofing, P. Attacks which employ IP Source Address Spoofing, P.
Ferguson, D. Senie, RFC 2267. Ferguson, D. Senie, RFC 2267, January, 1998. |
[RFC2401] Security Architecture for the Internet Protocol. S. Kent, |
R. Atkinson, RFC 2401, November 1998. |
[RFC2409] The Internet Key Exchange (IKE). D. Harkins, D. Carrel, |
RFC 2267 November 1998.
[ROUTER-RENUM] "Router Renumbering for IPv6", M. Crawford, draft- [ROUTER-RENUM] "Router Renumbering for IPv6", M. Crawford, draft-
ietf-ipngwg-router-renum-06.txt. ietf-ipngwg-router-renum-06.txt. |
[SITE-PREFIXES] "Site prefixes in Neighbor Discovery", E. Nordmark, |
draft-ietf-ipngwg-site-prefixes-03.txt. |
10. Authors' Addresses 10. Authors' Addresses
Matt Crawford John Stewart Matt Crawford John Stewart
Fermilab MS 368 Juniper Networks, Inc. Fermilab MS 368 Juniper Networks, Inc.
PO Box 500 385 Ravendale Drive PO Box 500 385 Ravendale Drive
Batavia, IL 60510 USA Mountain View, CA 94043 Batavia, IL 60510 USA Mountain View, CA 94043
Phone: 630-840-3461 Phone: +1 650 526 8000 Phone: 630-840-3461 Phone: +1 650 526 8000
EMail: crawdad@fnal.gov EMail: jstewart@juniper.net EMail: crawdad@fnal.gov EMail: jstewart@juniper.net
skipping to change at page 45, line 5 skipping to change at page 47, line 5
addresses. Because the total number of root DNS servers is addresses. Because the total number of root DNS servers is
relatively small, the routing subsystem is expected to be able to relatively small, the routing subsystem is expected to be able to
handle this requirement. handle this requirement.
All other DNS server addresses can be changed, since their addresses All other DNS server addresses can be changed, since their addresses
are typically learned from an upper-level DNS server that has are typically learned from an upper-level DNS server that has
delegated a part of the name space to them. So long as the delegated a part of the name space to them. So long as the
delegating server is configured with the new address, the addresses delegating server is configured with the new address, the addresses
of other servers can change. of other servers can change.
Appendix B: Additional Issues Related to GSE Appendix B: Additional Issues Related to Specifically to GSE |
This paper focused primarily on the issues of separating identifiers This paper focused primarily on the issues of separating identifiers
and locators in unicast addresses. It is worth noting that a number and locators in unicast addresses. It is worth noting that a number |
of additional issues were identified during the IPng interim meeting of GSE-specific additional issues were identified during the IPng |
with respect to the GSE proposal that would need to be considered interim meeting. These stem from a GSE end node not knowing its own |
before an architecture such as GSE could be deployed. Specifically: RG and the need for border routers to translate the RG of addresses. |
These issues would need to be considered before an architecture such |
as GSE could be deployed. Specifically:
- - it is not known how multicast would work under GSE. One - - it is not known how multicast would work under GSE. One
identified issue is that a site with multiple egress routers identified issue is that a site with multiple egress routers
would (by default) inject multicast traffic through each of all would (by default) inject multicast traffic through each egress |
the egress routers, each would then replace the source Routing routers, each would then replace the source Routing Goop with a
Goop with a differing value. This would lead to multiple copies differing value. This would lead to multiple copies of the same
of the same packet each carrying a different IPv6 address, thus packet each carrying a different IPv6 address, thus being
being considered as from different sources. considered as from different sources.
- - It would be more difficult to create tunnels. Any tunnel that - - It would be more difficult to create tunnels. Any tunnel that
crosses a site boundary (i.e., the entry and exit points are in crosses a site boundary (i.e., the entry and exit points are in
differing sites) would in effect require that both tunnel differing sites) would in effect require that both tunnel
endpoints be border routers to insure that the addresses in the endpoints be border routers to insure that the addresses in the
inner headers were rewritten correctly. inner headers were rewritten correctly.
- - In order for the DNS to hide a site's Routing Goop from - - In order for the DNS to hide a site's Routing Goop from
internal nodes yet make it visible to external nodes requires a internal nodes yet make it visible to external nodes requires a
two-faced DNS. The current DNS model assumes a single global two-faced DNS. The current DNS model assumes a single global
database in which all queries are answered the same way, database in which all queries are answered the same way,
irregardless of who issued the query. It is unclear how to make irregardless of who issued the query. It is unclear how to make
the DNS answer queries in a context-sensitive manner without the DNS answer queries in a context-sensitive manner without |
also negatively impacting its caching model. also negatively impacting (i.e., crippling) its caching model. |
- - Applications that send addresses in payloads (e.g., FTP PORT |
command) may run into difficulties with GSE. Because the sender |
does not know its own RG, the addresses it sends in payloads |
will contain only the site-local prefix in the RG portion of the |
address. In order for the receiver to open a connection back to |
that address, it needs the proper RG. This problem is analagous |
to that of NATs, where addresses in payloads need to be |
rewritten (e.g., via an ALG) when crossing the boundary between |
different addressing realms [NAT]. |
- - Border routers need to rewrite the source address of outgoing |
packets. Additional parsing of packet headers is also required, |
to find and rewrite any other addresses containing the site- |
local prefix. For example, the source routing header may contain |
additional addresses.
Appendix C: Ideas Incorporated Into IPv6 Appendix C: Ideas Incorporated Into IPv6
This section summarizes changes made to IPv6 specifications which This section summarizes changes made to IPv6 specifications which
originated in the GSE proposal or in the discussions arising from it. originated in the GSE proposal or in the discussions arising from it.
The unicast address format was changed to improve the aggregability The unicast address format was changed to improve the aggregability
of unicast addresses. Instead of a topologically insignificant of unicast addresses. Instead of a topologically insignificant
Registry ID immediately following the Format Prefix [RFC2073], there Registry ID immediately following the Format Prefix [RFC2073], there
is now a Top-Level Aggregation Identifier [IPv6-ADDRESS]. This field is now a Top-Level Aggregation Identifier [IPv6-ADDRESS]. This field
skipping to change at page 47, line 18 skipping to change at page 49, line 18
pointer which leads to the high-order part of the address. There may pointer which leads to the high-order part of the address. There may
be multiple levels of indirection and a changed record at any one be multiple levels of indirection and a changed record at any one
level would suffice to update the DNS's record of the IPv6 addresses level would suffice to update the DNS's record of the IPv6 addresses
of every node in a given branch of the addressing hierarchy. of every node in a given branch of the addressing hierarchy.
A change in the method of doing DNS address-to-name lookups is also A change in the method of doing DNS address-to-name lookups is also
in the works. This may be a change in the form and/or operation of in the works. This may be a change in the form and/or operation of
the ip6.int domain or some new mechanism which involves participation the ip6.int domain or some new mechanism which involves participation
by the routers or the end-nodes themselves. by the routers or the end-nodes themselves.
Another example of follow-on work is site prefixes [SITE-PREFIXES], |
whose aim is to have communicating parties prefer site-local |
addresses for internal communication. Applications using site-local |
addresses are generally immune to renumbering issues that effect only |
global-scope addresses. |
Two other changes arising from GSE will not affect the IPv6 base Two other changes arising from GSE will not affect the IPv6 base
specifications themselves, but do direct additional work. Those are specifications themselves, but do direct additional work. Those are
the injection of global prefix information into a site from a the injection of global prefix information into a site from a
provider or exchange [ROUTER-RENUM], and some inter-provider provider or exchange [ROUTER-RENUM], and some inter-provider
cooperative method of providing multihoming to mutual customers with cooperative method of providing multihoming to mutual customers with
minimal impact on routing tables in distant parts of the network. minimal impact on routing tables in distant parts of the network.
Appendix D: Reverse Mapping of Complete GSE Addresses Appendix D: Reverse Mapping of Complete GSE Addresses
The ability to map an IP address into its corresponding DNS name is The ability to map an IP address into its corresponding DNS name is
skipping to change at page 48, line 4 skipping to change at page 50, line 10
connection accepted as being from the indicated DNS name. connection accepted as being from the indicated DNS name.
It is important to note that although two DNS queries are made It is important to note that although two DNS queries are made
during the above operation, it is the second one --- mapping the during the above operation, it is the second one --- mapping the
peer's DNS name back into an IP address --- that provides the peer's DNS name back into an IP address --- that provides the
authentication property. The first transaction simply obtains authentication property. The first transaction simply obtains
the peer's DNS name, but no assumption is made that the returned the peer's DNS name, but no assumption is made that the returned
DNS name is correct. Thus, the first DNS query could be DNS name is correct. Thus, the first DNS query could be
replaced by an alternate mechanism without weakening the already replaced by an alternate mechanism without weakening the already
weak authentication check described above. One possible weak authentication check described above. One possible
alternate mechanism, an ICMP "Who Are You" message, is described alternate mechanism, an ICMP "Who Are You" message, is described |
below below.
3) Applications that log all incoming network connections (e.g., 3) Applications that log all incoming network connections (e.g.,
anonymous FTP servers) may prefer logging recognizable DNS names anonymous FTP servers) may prefer logging recognizable DNS names
to addresses. to addresses.
4) Network administrators examining logs or other trace data 4) Network administrators examining logs or other trace data
containing addresses may wish to determine the DNS name of some containing addresses may wish to determine the DNS name of some
addresses. Note that this may occur sometime after those addresses. Note that this may occur sometime after those
addresses were actually used. addresses were actually used.
skipping to change at page 48, line 44 skipping to change at page 50, line 50
itself, but the operational issues involved in keeping it up-to-date. itself, but the operational issues involved in keeping it up-to-date.
For the rest of this section, however, let us assume that such a For the rest of this section, however, let us assume that such a
database can be built. database can be built.
A mechanism supporting a lookup keyed on a flat-space ESD from an A mechanism supporting a lookup keyed on a flat-space ESD from an
arbitrary site requires having sufficient structure to identify the arbitrary site requires having sufficient structure to identify the
site that needs to be queried. In practice, since the Routing Stuff site that needs to be queried. In practice, since the Routing Stuff
is organized hierarchically, if an ESD is always used in conjunction is organized hierarchically, if an ESD is always used in conjunction
with Routing Stuff (i.e., a full 16-byte address), it becomes with Routing Stuff (i.e., a full 16-byte address), it becomes
feasible to maintain a DNS-like tree that maps full GSE addresses feasible to maintain a DNS-like tree that maps full GSE addresses
into DNS names, in a fashion analogous to what is done with IPv4 PTR into DNS names, in a fashion analagous to what is done with IPv4 PTR |
records today. records today.
It should be noted that a GSE address lookup will work only if the It should be noted that a GSE address lookup will work only if the
Routing Stuff portion of the address is correctly entered in the DNS Routing Stuff portion of the address is correctly entered in the DNS
tree. Because the Routing Stuff portion of an address is expected to tree. Because the Routing Stuff portion of an address is expected to
change over time, this assumption will not hold valid indefinitely. change over time, this assumption will not hold valid indefinitely.
As a consequence, a packet trace recorded in the past might not As a consequence, a packet trace recorded in the past might not
contain enough information to identify the off-Site sources of the contain enough information to identify the off-Site sources of the
packets in the present. This problem can be addressed by requiring packets in the present. This problem can be addressed by requiring
that the database of RG delegations be maintained, together with that the database of RG delegations be maintained, together with
accurate timing information, for some period of time after the RG is accurate timing information, for some period of time after the RG is
no longer usable for routing packets. no longer usable for routing packets.
Finally, it should be noted that the problem where an address's RG Finally, it should be noted that the problem where an address's RG
"expires" with the implication that the mapping of "expired" "expires" with the implication that the mapping of "expired"
addresses into DNS names may no longer hold is not a problem specific addresses into DNS names may no longer hold is not a problem specific
skipping to change at page 49, line 33 skipping to change at page 51, line 38
There is widespread agreement on the utility of being able to There is widespread agreement on the utility of being able to
determine the DNS name one is communicating with from the address determine the DNS name one is communicating with from the address
being used. In addition to the fact that DNS names are more being used. In addition to the fact that DNS names are more
meaningful to human users and more stable than addresses, many users meaningful to human users and more stable than addresses, many users
use this reverse mapping as part of a poor-man's authentication for use this reverse mapping as part of a poor-man's authentication for
the remote peer; if one can map the obtained DNS name back to the the remote peer; if one can map the obtained DNS name back to the
same address, one has an increased confidence of the peer being a same address, one has an increased confidence of the peer being a
legitimate one. legitimate one.
In practice, however, the IN-ADDR.ARPA domain is not fully populated In practice, however, the IN-ADDR.ARPA domain is not fully populated |
and poorly maintained. Consequently, an old proposal to define an and poorly maintained. Consequently, an old proposal to define an
ICMP Who-Are-You message was resurrected [RFC1788]. A client would ICMP Who-Are-You message was resurrected [RFC1788]. A client would
send such a message to a peer, and that peer would return an ICMP send such a message to a peer, and that peer would return an ICMP
message containing its DNS name. Asking a remote host to supply its message containing its DNS name. Asking a remote host to supply its
own name in no way implies that the returned information is accurate. own name in no way implies that the returned information is accurate.
However, having a remote peer provide a piece of information that a However, having a remote peer provide a piece of information that a
client can use as input to a separate authentication procedure client can use as input to a separate authentication procedure
provides a starting point for performing strong authentication. The provides a starting point for performing strong authentication. The
actual strength of the authentication depends on the authentication actual strength of the authentication depends on the authentication
procedure invoked, rather than the untrustable piece of information procedure invoked, rather than the untrustable piece of information
 End of changes. 55 change blocks. 
158 lines changed or deleted 298 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/