Internet Draft R. Atkinson draft-rja-ilnp-intro-02.txt Extreme Networks Expires: 10 JUN 2009 10 December 2008 Category: Experimental ILNP Concept of Operations draft-rja-ilnp-intro-02.txt Status of this Memo Distribution of this memo is unlimited. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is a contribution to the IRTF Routing Research Group. It is NOT a contribution to the IETF or to any IETF Working Group or to any IETF Area. Abstract This documents the Concept of Operations for an experimental extension to IPv6 which is known as the Identifier Locator Network Protocol (ILNP). Atkinson Expires in 6 months [Page 1]
Internet Draft ILNP Intro 10 DEC 2008 Table of Contents 1. Introduction ...............................................2 2. Transport Protocols.........................................4 3. Multi-Homing................................................5 4. Mobility....................................................6 5. Localised Addressing........................................7 6. IP Security Enhancements....................................8 7. DNS Enhancements............................................9 8. Backwards Compatibility....................................10 9. Incremental Deployment.....................................11 10. Security Considerations ...................................12 11. IANA Considerations .......................................16 12. References ................................................16 1. Introduction At present, the IRTF Routing Research Group is studying different approaches to evolving the Internet Architecture. Several different classes of evolution are being considered. One class is often called "Map and Encapsulate", where traffic would be mapped and then tunnelled through the inter-domain core of the Internet. Another class being considered is sometimes known as "Identifier/Locator Split". This document relates to a proposal that is in the latter class of evoluationary approaches. There has been substantial research relating to naming in the Internet through the years.[IEN-1][IEN-19][IEN-23][IEN-31][RFC-814] [RFC-1498] More recently, and mindful of that important prior work, the author has been examining enhancements to certain naming aspects of the Internet Architecture.[MobiArch07][MobiWAC07] This architectural concept derives originally from a note by Dave Clark to the IETF mailing list suggesting that the IPv6 address be split into separate Identifier and Locator fields. Afterwards, Mike O'Dell persued this concept in Internet-Drafts describing "GSE" or "8+8".[8+8][GSE] More recently, the IRTF Namespace Research Group (NSRG) studied this matter. Unusually for an IRTF RG, the NSRG operated on the principle that unanimity was required for the NSRG to make a recommendation. The author was a member of the IRTF NSRG. At least one other proposal, the Host Identity Protocol (HIP), also derives in part from the IRTF NSRG studies (and related antecedant work). This current proposal differs from O'Dell's work in various ways. The crux of this proposal is to split each 128-bit IPv6 address into two separate fields, with crisp semantics for each. It is Atkinson Expires in 6 months [Page 2]
Internet Draft ILNP Intro 10 DEC 2008 worth remembering here that an IPv6 address names a specific interface on a node, since the new scheme will be different in that regard. 1 1 2 3 0 4 8 2 6 4 1 +---------------+-----------------+----------------+---------------+ | Version| Traffic Class | Flow Label | +---------------+-----------------+----------------+---------------+ | Payload Length | Next Header | Hop Limit | +---------------+-----------------+--------------------------------+ | Source Address | + + | | + + | | + + | | +---------------+-----------------+----------------+---------------+ | Destination Address | + + | | + + | | + + | | +---------------+-----------------+----------------+---------------+ Figure 1: Existing ("Classic") IPv6 Header The high-order 64-bits of the IPv6 address become the Locator. The Locator indicates the subnetwork point of attachment for a node. In essence, the Locator names a subnetwork. Locators are also known as Routing Prefixes. The low-order 64-bits of the IPv6 address become the Identifier. The Identifier provides a fixed-length identity for a node, rather than an identity for a specific interface of a node. Identifiers are bound to nodes, not to interfaces, and are in the same modified EUI-64 syntax already specified for IPv6.[RFC-2460][RFC-4219][IEEE-EUI] Identifiers are unique within the context of a given Locator; in many cases, Identifiers might happen to be globally unique, but that is not a functional requirement for this proposal. 1 1 2 3 Atkinson Expires in 6 months [Page 3]
Internet Draft ILNP Intro 10 DEC 2008 0 4 8 2 6 4 1 +---------------+-----------------+----------------+---------------+ | Version| Traffic Class | Flow Label | +---------------+-----------------+----------------+---------------+ | Payload Length | Next Header | Hop Limit | +---------------+-----------------+----------------+---------------+ | Source Locator | + + | | +---------------+-----------------+----------------+---------------+ | Source Identifier | + + | | +---------------+-----------------+----------------+---------------+ | Destination Locator | + + | | +---------------+-----------------+----------------+---------------+ | Destination Identifier | + + | | +---------------+-----------------+----------------+---------------+ Figure 2: Enhanced IPv6 Header Most commonly, a node's set of Identifiers are derived from the IEEE 802 or IEEE 1394 MAC addresses associated with that node. This use of MAC addresses to generate Identifiers is convenient and is not required. Other methods also might be used to generate Identifiers. For example, one might derive Identifiers using cryptographic-generation or using methods specified in the IPv6 Privacy Extensions to State-Less Address Auto-Configuration (SLAAC). [RFC-3972, RFC-4941] This proposal enhances the Internet Architecture by adding crisp and clear semantics for the Identifier and for the Locator, removing the semantically-muddled concept of the IP address, and updating end system protocols slightly, without requiring router changes. With these naming enhancements, we have improved the architectural support not only for multi-homing, but also for mobility, localised addressing (e.g. NAT/NAPT), and IP Security. 2. Transport Protocols At present, commonly deployed transport protocols include a Atkinson Expires in 6 months [Page 4]
Internet Draft ILNP Intro 10 DEC 2008 pseudo-header checksum that includes certain network-layer fields, the IP addresses used for the session, in its calculation. This inclusion of network-layer information within the transport-layer session state creates issues for multi-homing, mobility, IP Security, and localised addressing (e.g. using Network Address Translation). [RFC-1631][RFC-3022] This unfortunate aspect of the TCP pseudo-header checksum has been understood to be an architectural problem at least since 1977, well before the transition from NCP to IPv4.[IEN-1][IEN-19][IEN-23][IEN-31][RFC-1498] With this proposal, transport protocols include only the Identifier in their pseudo-header calculations, but do not include the Locator in their pseudo-header calculations. To minimise the changes required within transport protocol implementations, when this proposal is in use for an IP session, the Locator fields are zeroed before use by the transport protocols. Later in this document, methods for incremental deployment of this change and backwards compatibility with non-upgraded nodes are described. 3. Multi-Homing Conceptually, there are two kinds of multi-homing. Site multi-homing is when all nodes at a site are multi-homed at the same time. This is what most people mean when they talk about multi-homing. However, there is also a separate concept of node multi-homing, where only a single node is multi-homed. At present, site multi-homing is common in the deployed Internet. This is primarily achieved by advertising the site's routing prefix(es) to more than upstream Internet service provider at a given time. In turn, this requires de-aggregation of routing prefixes within the inter-domain routing system. In turn, this increases the entropy of the inter-omain routing system (e.g. RIB/FIB size increases beyond the minimal RIB/FIB size that would be required to reach all sites). At present, node multi-homing is not uncommon. When TCP or UDP are in use for a session, node multi-homing cannot provide session reslience, because the transport Atkinson Expires in 6 months [Page 5]
Internet Draft ILNP Intro 10 DEC 2008 pseudo-header checksum binds the session to a single interface of the multi-homed node. It must be noted that SCTP has a protocol-specific mechanism to support node multi-homing; SCTP can support session resilience both at present and also without change in the proposed approach. In the new scheme, when a node is multi-homed, it has more than one valid Locator value. When one upstream connection fails, the node sends an ICMP Locator Update message to each existing correspondent node to remove the no-longer-valid Locator from the set of valid Locators. [ILNP-ICMP] Also, the node will use Secure Dynamic DNS Update to alter the set of currently valid L records associated with that node. [RFC-3007] This second step ensures that any new correspondents can reach the node. In the new scheme, site multi-homing works in a similar manner, with nodes having one Locator for each upstream connection to the Internet. To avoid a DNS Update burst when a site or subnetwork moves location, a DNS record optimisation is possible. This would change the number of DNS Updates required from Order(number of nodes at the site/subnetwork that moved) to Order(1).[ILNP-DNS] Additionally, since the transport-protocol session state no longer includes the Locators, a site could choose to perform Locator rewriting at its site border routers, possibly in combination with applying site traffic engineering policy on which upstream link to use for which packets. Since the site border router(s) are in the middle of any exterior packet flow, they also can send proxy Locator Update messages on behalf of nodes inside that site, and can even include the appropriate Nonce value in such proxy Locator Updates, if desired by that site's administration. 4. Mobility First, note well that mobiity and multi-homing actually present the same set of issues. In each case, the set of Locators associated with a node or site changes. The reason for the change might be different, but the effects on the network and on correspondents is identical. There are no standardised mechanisms to update most transport protocols with new IP addresses in use for the session. Exceptionally, the Stream Control Transport Protocol (SCTP) Atkinson Expires in 6 months [Page 6]
Internet Draft ILNP Intro 10 DEC 2008 recently added this capability.[RFC-5061] This creates various issues for mobility. For example, there is no method at present to update the IP addresses associated with a transport layer session when one of the nodes in that session moves (i.e. changes one of its points of network attachment). So, the several approaches to IP mobility seek to hide the change in location (and corresponding change in IP addresses) via tunnelling, home agents, foreign agents, and so forth.[RFC-3775] All of this can add substantial complexity to IP mobility approaches, both in the initial deployment and also in ongoing operation. By contrast, this ILNP proposal hides each node's location information from the transport layer protocols at all times, by removing location information from the transport session state (e.g. pseudo-header checksum calculations). In this proposal, mobility is supported using the same mechanisms as multihoming. Both cases use Locator values to identify different IP subnetworks. To handle the move of a node, we add a new ICMP control message. The ICMP Locator Update message is used by a node to inform its existing correspondents that the set of valid Locators for the node has changed. This mechanism can be used to add newly valid Locators, to remove no longer valid Locators, or to do both at the same time. Further, the node uses Secure Dynamic DNS Update to correct the set of L records in the DNS for that node. This enables any new correspondents to correctly initiate a new session with the node at its new location. This use of DNS for initial rendezvous with mobile node was independently proposed by others [PHG02] and then separately by the current author later on. Note that we can (and do) treat network mobility (as well as node mobility) as a special case of multihoming. That is, when a network moves, it uses a new Locator value for all of its communications sessions. So, the same mechanism, using a new or additional Locator value, also supports network mobility. So in ILNP, when a connectivity change affects the set of valid Locators, the affected node(s) actively update their correspondents with the updated information and also update their DNS entries. This combination eliminates the need for network probing to discover how to reach an existing correspondent that has moved (or whose connectivity has developed Atkinson Expires in 6 months [Page 7]
Internet Draft ILNP Intro 10 DEC 2008 a fault). Middleboxes do not need to participate for this to succeed. 5. Localised Addressing As the Locator value no longer forms part of the node session state (e.g. TCP pseudo-header), it is easier to implement localised addressing based on the use of local values of the Locator. This would be either in place of, or to supplement, existing NAT-based schemes.[RFC-1631] [RFC-3022] For example, some form of IPv6 Unique Local Addressing (ULA) might be used for localised addressing along with some form of IPv6 network address translation at a site border gateway.[ID-ULA][RFC-4193] In the simplest case, an ILNP capable NAT only would need to change the value of the Source Locator in an outbound packet, and the value of the Destination Locator for an inbound packet. Identifier values would not need to change, so a true end-to-end session could be maintained. If a site using localised addressing chooses to deploy a split-horizon DNS server, then all internal nodes would advertise the global-scope Locator(s) of the site border routers outside the site and would advertise the local-scope Locator(s) specific to that internal node inside the site. Such deployments of split-horizon DNS servers are not unusual in the IPv4 Internet today. If a site using localised addressing chooses not to deploy a split-horizon DNS server, then all internal nodes would advertise the global-scope Locator(s) of the site border routers. To deliver packets from one internal node to another internal node, the site would either choose to use layer-2 bridging (e.g. IEEE Spanning Tree, IEEE Rapid Spanning Tree, or a link-state layer-2 algorithm such as the IETF TRILL group or IEEE 802.1 are developing), or the interior routers would forward packets up to the nearest site border router, which in turn would then rewrite the Locators to appropriate local-scope values, and forward the packet towards the interior destination node. Please note that with this proposal, localised addressing (e.g. using Network Address Translation on the Locator bits) would work in harmony with multihoming, mobility, and IP Security.[MobiWAC07] 6. IP Security Enhancements Atkinson Expires in 6 months [Page 8]
Internet Draft ILNP Intro 10 DEC 2008 A current issue is that the IP Security protocols, AH and ESP, have Security Associations that include the IP addresses of the secure session endpoints. This was understood to be a problem when AH and ESP were originally defined, however the limited set of namespaces in the Internet Architecture did not provide any better choices at that time. Operationally, this binding causes problems for the use of the IPsec protocols through Network Address Translation devices, with mobile nodes (because the mobile node's IP address changes at each network-layer handoff), and with multi-homed nodes (because the session is bound to a particular interface of the multi-homed node, rather than being bound to the node itself).[RFC-3027][RFC-3715] To resolve the issue of IPsec interoperability through a NAT deployment, UDP encapsulation of IPsec is commonly used today.[RFC-3948] With this proposal, the IP Security protocols, AH and ESP, are enhanced to bind Security Associations only to Identifier values and never to Locator values (and also not to an entire 128-bit IPv6 address). Similarly, key management protocols used with IPsec would be enhanced to deprecate use of IP addresses as identifiers and to substitute the use of the new Identifier for that purpose. This small change enables IPsec to work in harmony with multihoming, mobility, and localised addressing. Further, it would obviate the need for specialised IPsec NAT Traversal mechanisms, thus simplifying IPsec implementations while enhancing deployability and interoperability. [RFC-3948] This change does not reduce the security provided by the IP Security protocols. 7. DNS Enhancements As part of this proposal, additional DNS Resource Records have been proposed in a separate document. [ILNP-DNS] These new records store the Identifier and Locator values for nodes that have been upgraded to support the Identifier-Locator Split Mode. With this proposal, mobile or multi-homed nodes and sites are expected to use the existing widely implemented "Secure Dynamic Atkinson Expires in 6 months [Page 9]
Internet Draft ILNP Intro 10 DEC 2008 DNS Update" protocol to keep their Identifier and Locator records correct in its authoritative DNS server(s). [RFC-3007] Reverse DNS lookups, to find a node's Fully Qualified Domain Name from the combination of a Locator and related Identifier value, can be performed as at present. Previous research by others indicates that DNS caching is largely ineffective, with the exception of NS records and the addresses of DNS servers referred to by NS records.[SBK2002] This means DNS caching performance will not be adversely affected by assigning very short time-to-live (TTL) values to the Locator records of typical nodes. It also means that it is preferable to deploy the DNS server function on nodes that have longer TTL values, rather than on nodes that have shorter TTL values. Identifier values might be very long-lived (e.g. days) when they have been generated from an IEEE MAC Address on the system or are cryptographically-generated, or they might have a moderate lifetime (e.g. hours) when they have been created by the IPv6 Privacy Extensions or some other method that regularly generates new Identifier values over time. Existing DNS specifications require that DNS clients and DNS resolvers obey the TTL values provided by the DNS servers. In the context of this proposal, short DNS TTL values are assigned to particular DNS records to ensure that the ubiquitous DNS caching resolvers do not cache volatile values (e.g. Locator records of a mobile node) and consequently return stale information to new requestors. As a practical matter, it is not sensible to flush all Locator values associated with an existing session's remote node from the local node's I/L Session Cache. Instead, Locator values should be marked as "aged" when their TTL has expired until the next Locator Update message is received or there is other indication that a given Locator is not working any longer. During a long transition period, a node that is I/L-enabled should have not only I and L records present in its authoritative DNS server, but also should have AAAA records for the benefit of non-upgraded nodes. This capability might be implemented strictly inside a DNS server, whereby the DNS server synthesised a set of AAAA records to advertise from the I and L values that the node has kept updated in that DNS server. Existing DNS specifications require that a DNS resolver or DNS Atkinson Expires in 6 months [Page 10]
Internet Draft ILNP Intro 10 DEC 2008 client ignore unrecognised DNS record types. So gratuitously appending I and L records as "additional data" in DNS responses to AAAA queries is not expected to create any operational issues. 8. Backwards Compatibility First, if one comapres Figure 1 and Figure 2, one can see that IPv6 with the Identifier/Locator Split enhancement is fully backwards compatible with existing IPv6. This means that no router software or silicon changes are necessary to support the proposed enhancements. A router would be unaware whether the packet being forwarded were classic IPv6 or the proposed enhanced version of IPv6. So no changes to IPv6 routers is required to deploy this proposal. Further, IPv6 Neighbour Discovery should work fine without any significant protocol changes. If a node that has been enhanced to support the Identifier/ Locator Split mode initiates an IP session with another node, normally it will first perform a DNS lookup on the responding node's DNS name. If the inititator node does not find any new I and L DNS resource records for the responder node, then the initiator uses the Classical IPv6 mode of operation for the new session with the responder, rather than trying to use the I/L Split mode for that session. If the responder node for a new IP session has not been enhanced to support the I/L Split mode and receives initial packet(s) containing the Nonce Destination Option, the responder will drop the packet and send an ICMP Parameter Problem error message back to the initiator. If the initiator node does not receive a response from the responder in a timely manner (e.g. within TCP timeout for a TCP session) and also does not receive an ICMP Unreachable error message for that packet, OR if the initiator receives an ICMP Parameter Problem error message for that packet, then the initiator knows that the responder is not able to support the I/L Split Operating mode. In this case, the initiator node should try again to create the new IP session but this time OMITTING the Nonce Destination Option, and this time operating in Classic IPv6 mode, rather than I/L Split mode. The existing BSD Sockets API can continue to be used. That API can be implemented in a manner that hides the underlying protocol changes from the applications. So it is believed Atkinson Expires in 6 months [Page 11]
Internet Draft ILNP Intro 10 DEC 2008 that existing IP address referrals can continue to work properly in most cases. For a rapidly moving target node, referrals might break in at least some cases. The potential for referral breakage is necessarily dependent upon the specific application and implementation being considered. (We note, however, that a more architecturally sensible approach to referrals would be to use Fully-Qualified Domain Names (FQDNs), as is commonly done today with web URLs. This is true even with the deployed IPv4 or IPv6 Internet.) It is suggested, however, that a new, optional, more abstract, API be created so that new applications do not have to delve needlessly into low-level details of the underlying network protocols. 9. Incremental Deployment If a node has been enhanced to support the Identifier/ Locator Split operating mode, that node's fully-qualified domain name will normally have one or more I records and one or more L records associated with it in the DNS. When a host ("initiator") initiates a new IP session with a correspondent ("responder"), it normally will perform a DNS lookup to determine the address(es) of the responder. A host that has been enhanced to support the Identifier/ Locator Split operating mode normally will look for Identifier ("I") and Locator ("L") records in any received DNS replies. DNS servers that support I and L records should include them (when they exist) as additional data in all DNS replies to queries for DNS AAAA records.[ILNP-DNS] If the initiator supports the I/L Split mode and from DNS information learns that the responder also supports the I/L Split mode, then the initiator will generate an unpredictable nonce value, store that value in a local Correspondent Cache, and will include the Nonce Destination Option in its initial packet(s) to the responder.[ILNP-Nonce] If the responder supports the I/L Split mode and receives initial packet(s) containing the Nonce Destination Option, the responder will thereby know that the initiator supports the I/L Split mode and the responder will also operate in I/L Split mode for this new IP session. If the responder supports the I/L Split mode and receives Atkinson Expires in 6 months [Page 12]
Internet Draft ILNP Intro 10 DEC 2008 initial packet(s) NOT containing the Nonce Destination Option, the responder will thereby know that the initiator does NOT support the I/L Split mode and the responder will operate in classic IPv6 mode for this new IP session. The previous section described how interoperability between enhanced nodes and non-enhanced nodes is retained even if a non-enhanced node erroneously has I and L DNS resource records in place (e.g. due to some accident). 10. Security Considerations This proposal outlines a proposed evolution for the Internet Architecture to provide improved capabilities. This section discusses security considerations for this proposal. 10.1 Authentication of Locator Updates A separate document [ILNP-Nonce] proposed a new IPv6 Destination Option that can be used to carry a session nonce end-to-end between communicating nodes. That nonce provides protection against off-path attacks on an Identifier/Locator session. The Nonce Destination Option is used ONLY for IP sessions in the Identifier/Locator Split mode. Ordinary IPv6 is vulnerable to on-path attacks unless the IP Authentication Header or IP Encapsulating Security Payload is in use. So the Nonce Destination Option only seeks to provide protection against off-path attacks on an IP session -- equivalent to ordinary IPv6 when not using IP Security. When the Identifier/Locator split mode is in use for an existing IP session, the Nonce Destination Option must be included in any ICMP control messages (e.g. ICMP Unreachable, ICMP Locator Update) sent with regard to that IP session. It is common to have non-symmetric paths between two nodes on the Internet. To reduce the number of on-path nodes that know the Nonce value for a given session when the I/L split mode is in use, separate nonce values are used in each direction. For example, for a session between two nodes A and B, one nonce value is used from A to B and a different nonce value is used from B to A. When in the I/L Split operating mode for an existing IP Atkinson Expires in 6 months [Page 13]
Internet Draft ILNP Intro 10 DEC 2008 session, ICMP control messages received without a Nonce Destination Option must be discarded as forgeries. This security event should be logged. When in the I/L Split operating mode for an existing IP session, ICMP control messages received without a correct nonce value inside the Nonce Destination Option must be discarded as forgeries. This security event should be logged. When in the I/L Split operating mode for an existing IP session, and a node changes its Locator set, it should include the Nonce Destination Option in the first few data packets sent using a new Locator value, so that the recipient can validate the received data packets as valid (despite having an unexpected Source Locator value). For ID/Locator Split mode sessions operating in higher risk environments, the use of the cryptographic authentication provided by IP Authentication Header is recommended *in addition* to concurrent use of the Nonce Destination Option. It is important to note that at present an IPv6 session is entirely vulnerable to on-path attacks unless IPsec is in use for that particular IPv6 session, so the security properties of the new proposal are never worse than for existing IPv6. 10.2 Forged Identifier Attacks In the deployed Internet, active attacks using packets with a forged Source IP Address have been publicly known at least since early 1995.[CA-1995-01] While these exist in the deployed Internet, they have not been widespread. This is equivalent to the issue of a forged Identifier value and demonstrates that this is not a new threat created by the Identifier/Locator-split mode of operation. One mitigation for these attacks has been to deploy Source IP Address Filtering.[BCP-38] Jun Bi at U. Tsinghua cites Arbor Networks as reporting that this mechanism has less than 50% deployment and cites an MIT analysis indicating that at least 25% of the deployed Internet permits forged source IP addresses. Other parts of this document discuss the probability of an accidental duplicate Identifier being used on the Internet. However, this sub-section instead focuses on methods for Atkinson Expires in 6 months [Page 14]
Internet Draft ILNP Intro 10 DEC 2008 mitigating attacks based on packets containing deliberately forged Source Identifier values. First, the recommendations of [BCP-38] remain. Packets that have a forged Locator value can be easily filtered using existing widely available mechanisms. Second, the receiving node does not blindly accept any packet with the proper Source Identifier and proper Destination Identifier as an authentic packet. Instead, each node operating the I/L-split mode maintains a session cache for each of its correspondents. This cache contains two unidirectional nonce values (one used in control messages sent by this node, a different one used to authenticate messages from the other node). The cache also contains the currently valid set of Locators and set of Identifiers for each correspondent node. If a received packet contains valid Identifier values and a valid Destination Locator, but contains a Source Locator value that is not present in the session cache, the packet is dropped without further processing as an invalid packet, unless the packet also contains a Nonce Destination Option with the correct value used for packets from the node with that Source Identifier to this node. This prevents an off-path attacker from stealing an existing session. Third, any node can distinguish different nodes using the same Identifier value by other properties of their sessions. IPv6 Neighbor Discovery prevents more than one node from using the same source (Locator + Identifier) pair at the same time. So cases of different nodes using the same Identifier value will involve nodes that have different sets of valid Locator values. A node can thus demux based on the combination of Source Locator and Source Identifier if necessary. If IP Security is in use, the combination of the Source Identifier and the SPI value would be sufficient to demux two different sessions. Finally, deployments in high threat environments also should use the IP Authentication Header to authenticate control traffic and data traffic. Because in the I/L-split mode, IP Security binds only to the Identifier values, and never to the Locator values, this enables a mobile or multi-homed node to use IPsec even when its Locator value(s) have just changed. 10.3 IP Security Enhancements The IP Security standards are enhanced here by binding IPsec Security Associations to the Identifiers of the session endpoints, rather than binding IPsec Security Associations Atkinson Expires in 6 months [Page 15]
Internet Draft ILNP Intro 10 DEC 2008 to the IP Addresses as at present. This change enhances the deployability and interoperability of the IP Security standards, but does not decrease the security provided by those protocols. 10.4 DNS Security The DNS enhancements proposed here are entirely compatible with, and can be protected using, the existing IETF standards for DNS Security.[RFC-4033] The Secure DNS Dynamic Update mechanism used here is also used unchanged.[RFC-3007] So there is no change to the security properties of the Domain Name System. 10.5 Firewall Considerations In the proposed new scheme, firewalls are able to authenticate ICMP control messages arriving on the external interface. This enables more thoughtful handling of ICMP messages by firewalls than is commonly the case at present. As the firewall is along the path between the communicating nodes, the firewall can snoop on any Session Nonce being carried in the initial packets of an I/L Split mode session. The firewall can verify that nonce is present on incoming control packets, dropping any control packets that lack the correct nonce value. By always including the nonce, even when IP Security is also in use, the firewall can filter out all off-path attacks. In this case, a forged packet from an on-path attacker will still be detected when the IPsec input processing occurs in the receiving node; this will cause that forged packet to be dropped rather than acted upon. 10.6 Neighbor Discovery Authentication Nothing in this proposal prevents sites from using the Secure Neighbor Discovery (SEND) proposal for authenticating IPv6 Neighbor Discovery. [RFC-3971] 11. IANA Considerations This document has no IANA considerations. 12. References This section provides both normative and informative references relating to this note. Atkinson Expires in 6 months [Page 16]
Internet Draft ILNP Intro 10 DEC 2008 12.1. Normative References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC-2460] S. Deering & R. Hinden, "Internet Protocol Version 6 Specification", RFC-2460, December 1998. [RFC-3007] B. Wellington, "Secure Domain Name System Dynamic Update", RFC-3007, November 2000. [RFC-4033] R. Arends, et alia, "DNS Security Introduction and Requirements", RFC-4033, March 2005. [RFC-4219] R. Hinden & S. Deering, "IP Version 6 Addressing Architecture", RFC-4219, February 2006. 12.2. Informative References [8+8] M. O'Dell, "8+8 - An Alternate Addressing Architecture for IPv6", Internet-Draft, October 1996. [GSE] M. O'Dell, "GSE - An Alternate Addressing Architecture for IPv6", Internet-Draft, February 1997. [ID-ULA] R. Hinden, G. Huston, & T. Narten, "Centrally Assigned Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-ula-central-02.txt, 15 June 2007. [IEEE-EUI] IEEE Standards Association, "Guidelines for 64-bit Global Identifier (EUI-64)", IEEE, 2007. [IEN-1] C.J. Bennett, S.W. Edge, & A.J. Hinchley, "Issues in the Interconnection of Datagram Networks", Internet Experiment Note (IEN) 1, INDRA Note 637, PSPWN 76, University College London, 29 July 1977. http://www.postel.org/ien/ien001.pdf [IEN-19] J. F. Shoch, "Inter-Network Naming, Addressing, and Routing", IEN-19, January 1978. Atkinson Expires in 6 months [Page 17]
Internet Draft ILNP Intro 10 DEC 2008 [IEN-23] J. F. Shoch, "On Names, Addresses, and Routings", IEN-23, January 1978. [IEN-31] D. Cohen, "On Names, Addresses, and Routings (II)", IEN-31, April 1978. [ILNP-Nonce] R. Atkinson, "Nonce Destination Option", draft-rja-ilnp-nonce-01.txt, December 2008. [ILNP-DNS] R. Atkinson, "Additional DNS Resource Records", draft-rja-ilnp-dns-01.txt, December 2008. [ILNP-ICMP] R. Atkinson, "ICMP Locator Update message" draft-rja-ilnp-icmp-00.txt, December 2008. [MobiArch07] R. Atkinson, S. Bhatti, & S. Hailes, "Mobility as an Integrated Service Through the Use of Naming", Proceedings of ACM MobiArch 2007, August 2007, Kyoto, Japan. [MobiWAC07] R. Atkinson, S. Bhatti, & S. Hailes, "A Proposal for Unifying Mobility with Multi-Homing, NAT, & Security", Proceedings of ACM MobiWAC 2007, Chania, Crete. ACM, October 2007. [MILCOM08] R. Atkinson, S. Bhatti, & S. Hailes, "Harmonised Resilience, Security, and Mobility Capability for IP", Proceedings of IEEE Military Communications Conference, San Diego, CA, USA, November 2008. [PHG02] Pappas, A, S. Hailes, & R. Giaffreda, "Mobile Host Location Tracking through DNS", Proceedings of IEEE London Communications Symposium, IEEE, September 2002, London, England, UK. [SBK2002] Alex C. Snoeren, Hari Balakrishnan, & M. Frans Kaashoek, "Reconsidering Internet Mobility", Proceedings of 8th Workshop on Hot Topics in Operating Systems, 2002. [RFC-814] D.D. Clark, "Names, Addresses, Ports, and Routes", RFC-814, July 1982. [RFC-1498] J.H. Saltzer, "On the Naming and Binding of Atkinson Expires in 6 months [Page 18]
Internet Draft ILNP Intro 10 DEC 2008 Network Destinations", RFC-1498, August 1993. [RFC-1631] K. Egevang & P. Francis, "The IP Network Address Translator (NAT)", RFC-1631, May 1994. [RFC-3022] P. Srisuresh & K. Egevang, "Traditional IP Network Address Translator", RFC-3022, January 2001. [RFC-3027] M. Holdrege and P Srisuresh, "Protocol Complications of the IP Network Address Translator", RFC-3027, January 2001. [RFC-3715] B. Aboba and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC-3715, March 2004. [RFC-3775] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in IPv6", RFC-3775, June 2004. [RFC-3948] A. Huttunen, et alia, "UDP Encapsulation of IPsec ESP Packets", RFC-3948, January 2005. [RFC-3972] T. Aura, "Cryptographically Generated Addresses (CGAs)", RFC-3972, March 2005. [RFC-4193] R. Hinden & B. Haberman, "Unique Local IPv6 Unicast Addresses, RFC-4193, October 2005. [RFC-4941] T. Narten, R. Draves, & S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC-4941, September 2007. [RFC-5061] R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, & M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC-5061, September 2007. (Additional references to be added later.) Author's Address R. Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA Atkinson Expires in 6 months [Page 19]
Internet Draft ILNP Intro 10 DEC 2008 Telephone: +1 (408)579-2800 Email: rja@extremenetworks.com Atkinson Expires in 6 months [Page 20]
Internet Draft ILNP Intro 10 DEC 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. This document may not be modified, and derivative works of it may not be created. This document may only be posted in an Internet-Draft. Expires: 10 June 2009 Atkinson Expires in 6 months [Page 21]