INTERNET-DRAFT Erik Nordmark July 7, 2004 Sun Microsystems Multihoming without IP Identifiers Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet Draft expires January 7, 2005. Abstract This document outlines a potential solution to IPv6 multihoming in order to stimulate discussion. This proposed solution relies on verification using the existing DNS to prevent redirection attacks, while allowing locator rewriting by (border) routers, with no per-packet overhead. The solution does not introduce a "stack name" type of identifier, instead it ensures that all upper layer protocols can operate unmodified in a multihomed setting while still seeing a stable IPv6 address. draft-nordmark-multi6-noid-02.txt [Page 1] INTERNET-DRAFT Multihoming without IDs July 7, 2004 Contents 1. INTRODUCTION............................................. 4 1.1. Non-Goals........................................... 4 1.2. Assumptions......................................... 5 2. TERMINOLOGY.............................................. 5 2.1. Notational Conventions.............................. 6 3. PROTOCOL OVERVIEW........................................ 7 3.1. DNS Usage and Dependencies.......................... 11 3.2. Host-Pair Context................................... 12 3.3. Message Formats..................................... 13 3.3.1. Context Initiator (INIT) Message Format........ 14 3.3.2. Context Check (CC) Message Format.............. 15 3.3.3. Context Check Reply (CCR) Message Format....... 16 3.3.4. Context Confirm (CONF) Message Format.......... 16 3.3.5. Update Request (UR) Message Format............. 16 3.3.6. Update Acknowledgement (UA) Message Format..... 17 3.3.7. Unknown Context (UC) Message Format............ 17 4. PROTOCOL WALKTHROUGH..................................... 18 4.1. Initial Context Establishment....................... 18 4.2. Locator Change...................................... 21 4.3. Concurrent Context Establishment.................... 22 4.3.1. Crossing INIT messages......................... 22 4.3.2. Sending INIT after sending CC.................. 23 4.4. Handling Locator Failures........................... 23 4.5. Locator Set Changes................................. 24 4.6. Preventing Premeditated Redirection Attacks......... 26 5. HANDLING STATE LOSS...................................... 26 5.1. State Loss and Packets from the Peer................ 27 5.2. State Loss and Packets from the ULP................. 28 6. ENCODING BITS IN THE IPv6 HEADER?........................ 29 7. PROTOCOL PROCESSING...................................... 30 7.1. State Machine....................................... 30 7.2. Sending INIT messages............................... 30 7.3. Receiving INIT messages............................. 31 7.4. Receiving CC messages............................... 32 7.5. Receiving CCR messages.............................. 33 7.6. Receiving CONF messages............................. 34 7.7. Sending Update Request messages..................... 35 7.8. Receiving Update Request messages................... 35 7.9. Receiving Update Acknowledgement messages........... 36 7.10. Retransmission..................................... 36 draft-nordmark-multi6-noid-02.txt [Page 2] INTERNET-DRAFT Multihoming without IDs July 7, 2004 7.11. Receiving Data Packets............................. 36 7.12. Receiving Unknown Context messages................. 37 7.13. DNS Verification and Hosts without a FQDN.......... 38 7.14. Birthday Counter................................... 40 8. COMPATIBILITY WITH STANDARD IPv6......................... 40 9. APPLICATION USAGE OF IDENTIFIERS......................... 41 10. CHECKSUM ISSUES......................................... 42 11. IMPLICATIONS FOR PACKET FILTERING....................... 43 12. IPSEC INTERACTIONS...................................... 43 13. SECURITY CONSIDERATIONS................................. 44 14. PRIVACY CONSIDERATIONS.................................. 45 15. DESIGN ALTERNATIVES..................................... 45 15.1. Avoid introduction of M6 DNS Resource Record type.. 45 15.2. Extension header instead of using flow label....... 46 15.3. Explicit close exchange............................ 47 16. OPEN ISSUES............................................. 47 16.1. Renumbering Considerations......................... 48 16.2. Initiator Confusion vs. "Virtual Hosting".......... 48 17. ACKNOWLEDGEMENTS........................................ 49 18. REFERENCES.............................................. 49 18.1. Normative References............................... 49 18.2. Informative References............................. 49 19. CHANGE LOG.............................................. 51 APPENDIX A: CONTEXT CLOSE PROTOCOL........................... 52 AUTHORS' ADDRESSES........................................... 56 draft-nordmark-multi6-noid-02.txt [Page 3] INTERNET-DRAFT Multihoming without IDs July 7, 2004 1. INTRODUCTION The goal of the IPv6 multihoming work is to allow a site to take advantage of multiple attachments to the global Internet without having a specific entry for the site visible in the global routing table. Specifically, a solution should allow users to use multiple attachments in parallel, or to switch between these attachment points dynamically in the case of failures, without an impact on the upper layer protocols. This proposed solution uses existing DNS mechanisms to perform enough validation to prevent redirection attacks. The goals for this proposed solution is to: o Have no impact on upper layer protocols in general and on transport protocols in particular. o Address the security threats in [M6THREATS]. o Allow routers rewriting the (source) locators as a means of quickly detecting which locator is likely to work for return traffic. o No per-packet overhead. o No extra roundtrip for setup. o Take advantage of multiple locators/addresses for load spreading. 1.1. Non-Goals The assumption is that the problem we are trying to solve is site multihoming, with the ability to have the set of site locator prefixes change over time due to site renumbering. Further, we assume that such changes to the set of locator prefixes can be relatively slow and managed; slow enough to allow updates to the DNS to propagate. This proposal does not attempt to solve, perhaps related, problems such as host multihoming or host mobility. This proposal also does not try to provide an IP identifier. Even though such a concept would be useful to ULPs and applications, especially if the management burden for such a name space was zero and there was an efficient yet secure mechanism to map from identifiers to locators, such a name space isn't necessary (and furthermore doesn't seem to help) when using the DNS to verify the locator relationships. draft-nordmark-multi6-noid-02.txt [Page 4] INTERNET-DRAFT Multihoming without IDs July 7, 2004 1.2. Assumptions The main technical assumptions this proposal makes is that the DNS infrastructure can be used for verification of the relationship between locators on both the initiator of communication and the responding peer. In particular, it assumes that getting DNS reverse tree (ip6.arpa) populated for the hosts that wish to take advantage of multihoming, will not be a significant problem. This version of the document further relaxes this constraint so that if two communication hosts are in separate multihomed sites, if only one of them has correct information in the forward plus reverse DNS, the communication between them can benefit from the multiple locators of that host. However, without loss of security it isn't possible to benefit from the multiple locators of a host with no DNS information (or incorrect/missing forward and reverse DNS information). 2. TERMINOLOGY upper layer protocol (ULP) - a protocol layer immediately above IP. Examples are transport protocols such as TCP and UDP, control protocols such as ICMP, routing protocols such as OSPF, and internet or lower-layer protocols being "tunneled" over (i.e., encapsulated in) IP such as IPX, AppleTalk, or IP itself. interface - a node's attachment to a link. address - an IP layer name that contains both topological significance and acts as a unique identifier for an interface. 128 bits. locator - an IP layer topological name for an interface or a set of interfaces. 128 bits. The locators are carried in the IP address fields as the packets traverse the network. identifier - an IP layer identifier for an IP layer endpoint (stack name in [NSRG]). The transport endpoint is a function of the transport protocol and would typically include the IP identifier plus a port number. NOTE: This proposal does not contain any IP layer identifiers. Application identifier (AID) - an IP locator which has been selected for communication with a peer to be used by the upper draft-nordmark-multi6-noid-02.txt [Page 5] INTERNET-DRAFT Multihoming without IDs July 7, 2004 layer protocol. 128 bits. This is used for pseudo-header checksum computation and connection identification in the ULP. Different sets of communication to a host (e.g., different connections) might use different AIDs in order to enable load spreading. address field - the source and destination address fields in the IPv6 header. As IPv6 is currently specified this fields carry "addresses". If identifiers and locators are separated these fields will contain locators. FQDN - Fully Qualified Domain Name 2.1. Notational Conventions A, B, and C are hosts. X is a potentially malicious host. FQDN(A) is the domain name for A. Lsl(A) is the "local" locator set for A, that is, the set of locators that A itself knows it has. This set expresses which locators should be acceptable to receive packets sent by A. Lsr(A) is the "remote" locator set for A, that is, the set of locators of A that its peer found in the DNS. Normally Lsl(A) and Lsr(A) are the same, but due to DNS updates, DNS load balancing, or misconfiguration they might differ. Ls(A) is the locator set for A, which consists of L1(A), L2(A), ... Ln(A). For robustness Ls(A) is computed as the intersection of Lsl(A) and Lsr(A) by both A and its peer. Lsv(A) is the verified locator set for A. This is the subset of Ls(A) which has been verified with both forward and reverse DNS lookups to be a set corresponding to a single FQDN. This set expresses which locators are safe to use as destinations when sending packets to A. AID(A) is an application ID for A. In this proposal, AID(A) is always one member of A's locator set. draft-nordmark-multi6-noid-02.txt [Page 6] INTERNET-DRAFT Multihoming without IDs July 7, 2004 3. PROTOCOL OVERVIEW In order to prevent redirection attacks this protocol relies on the DNS (for the hosts which want to take advantage of themselves having multiple locators) being maintained with consistent forward and reverse information. This allows any host, given one locator, to determine the corresponding FQDN and the set of locators for the host. Once those lookups have been performed, and the original locator is indeed part of the set, the host can happily allow any of those locators to be used without being subject to redirection attacks. Keeping the FQDN around allows the solution to handle graceful renumbering by being able to redo the DNS lookups (e.g., based on the TTL on the resource records). DNS is also used to provide an indication of multihoming capability of a host. The details of this is TBD but a simple example would be to introduce a new M6 Resource Record type in the DNS which has no RDATA; thus the mere existence of such a record at a FQDN would imply that the host supports the M6 protocol. See Section 15.1 for an alternative approach that doesn't need a new RR type. ----------------------- | Transport Protocols | ----------------------- ------ ------- -------------- ------------- | AH | | ESP | | Frag/reass | | Dest opts | ------ ------- -------------- ------------- ----------------- | M6 shim layer | ----------------- ------ | IP | ------ Figure 1: Protocol stack The proposal uses an M6 shim layer between IP and the ULPs as shown in figure 1, in order to provide ULP independence. Conceptually the M6 shim layer behaves as if it is associated with an extension header, which would be ordered immediately after any hop-by-hop options in the packet. However, the amount of data that needs to be carried in an actual M6 extension header is close to zero. By using some encoding of the nexthdr value it is possible to carry the common protocols/extension headers without making the packets larger. The nexthdr encodings are discussed later in this document. We refer to draft-nordmark-multi6-noid-02.txt [Page 7] INTERNET-DRAFT Multihoming without IDs July 7, 2004 packets that use this encoding to indicate to the receiver that M6 processing should be applied as "M6 packets" (analogous to "ESP packets" or "TCP packets"). Layering AH and ESP above the M6 shim means that IPsec can be made to be unaware of locator changes the same way that transport protocols can be unaware. Thus the IPsec security associations remain stable even though the locators are changing. Layering the fragmentation header above the M6 shim makes reassembly robust in the case that there is broken multi-path routing which results in using different paths, hence potentially different source locators, for different fragments. Thus, effectively the M6 shim layer is placed between the IP endpoint sublayer, which handles fragmentation, reassembly, and IPsec, and the IP routing sublayer, which on a host selects which default router to use etc. The proposal uses router rewriting of (source) locators as one way to determine which is the preferred (or only working) locator to use for return traffic. But not all packets can have their locators rewritten. In addition to existing IPv6 packets, the packets exchanged before M6 host-pair context state is established at the receiver can not have their locators rewritten. Thus a simple mechanism is needed to indicate to the routers on the path whether or not it is ok to rewrite the locators in the packet. Conceptually this is a single bit in the IPv6 header (we call it the "rewrite ok" bit) but there is no spare bit available. Later in the document we show how we solve this by allocating a range of next header values to denote this semantic bit. Applications and upper layer protocols use AIDs which the M6 layer will map to/from different locators. The M6 layer maintains state, called host-pair context, in order to perform this mapping. The mapping is performed consistently at the sender and the receiver, thus from the perspective of the upper layer protocols, packets appear to be sent using AIDs from end to end, even though the packets travel through the network containing locators in the IP address fields, and even though those locators might be rewritten in flight. draft-nordmark-multi6-noid-02.txt [Page 8] INTERNET-DRAFT Multihoming without IDs July 7, 2004 ---------------------- ---------------------- | Sender A | | Receiver B | | | | | | ULP | | ULP | | | src AID(A) | | ^ | | | dst AID(B) | | | src AID(A) | | v | | | dst AID(B) | | M6 | | M6 | | | src L1(A) | | ^ | | | dst L1(B) | | | src L2(A) | | v | | | dst L1(B) | | IP | | IP | ---------------------- ---------------------- | ^ -- cloud with some routers ------- src L2(A) [Rewritten] dst L1(B) Figure 2: Mapping with router rewriting of locators. The result of this consistent mapping is that there is no impact on the ULPs. In particular, there is no impact on pseudo-header checksums and connection identification. Conceptually one could view this approach as if both AIDs and locators are being present in every packet, but with a header compression mechanism applied that removes the need for the AIDs once the state has been established. As we will see below the flow label will be used akin to a "compression tag" i.e., to indicate the correct context to use for decompression. The need for some "compression tag" is because the desire to allow load spreading and handle site renumbering. Without those desires it could have been possible to e.g. designate one fixed locator as the AID for a host and storing that in the DNS. But instead different connections between two hosts are allowed to use different AIDs and on reception of a M6 packet the correct AIDs must be inserted into the IP address fields before passing the packet to the ULP. The flow label serves as a convenient "compression tag" without increasing the packet size, and this usage doesn't conflict with other flow label usage. In addition to the zero overhead data messages, there are seven different M6 message types introduced (which are defined as new ICMPv6 messages). Four types are used to perform a 4-way handshake to create state at both endpoints without creating state on the first received packet (which would introduce a memory consumption DoS attack), and two types are used to update the set of locators used for the context, and finally a single message type to signal that draft-nordmark-multi6-noid-02.txt [Page 9] INTERNET-DRAFT Multihoming without IDs July 7, 2004 state has been lost. The seven message types are called: o Context Initiator message (INIT); first message of the 4-way context establishment. Sent by the initiator when there is a desire to create a host-pair context for future locator agility. Normally sent when a data packet is passed down to IP from the ULP when there is no context state. An ULP packet can be piggybacked on this message. o Context Check message (CC); second message of the 4-way context establishment. Sent in response to a INIT message. An ULP packet can be piggybacked on this message. o Context Check Reply message (CCR); third message of the 4-way context establishment. Sent in response to a CC message. An ULP packet can be piggybacked on this message. o Context Confirm message (CONF); Last message in the context establishment exchange; can be sent in response to a CCR or an INIT message. Carries the responders flow label as well as any initial reductions in the locator set to the initiator. o Update Request message (UR); sent to update the local and remote locator sets. An ULP packet can be piggybacked on this message. o Update Acknowledgement message (UA); sent to acknowledge an Update Request message. An ULP packet can be piggybacked on this message. o Unknown Context message (UC); error which is sent when no state is found. Similar to MAST [MAST] the above exchange can be performed asynchronously with data packets flowing between the two hosts; until context state has been established at both ends the packets would flow without allowing router rewriting of locators and without the ability for the hosts to switch locators. Once the 4-way state creation exchange has completed there is host- pair context state at both hosts, and both ends know a set of locators for the peer that are acceptable as the source in received packets. At that point in time the responder (which didn't use DNS before the setup) can asynchronously start verifying additional locators using the DNS. Once a peer locator has been verified it will be a candidate destination locator including the ability to dynamically switch to using the last received source locator (that is already verified) as the destination locator for return traffic. draft-nordmark-multi6-noid-02.txt [Page 10] INTERNET-DRAFT Multihoming without IDs July 7, 2004 3.1. DNS Usage and Dependencies For the protocol to be beneficial at least one of the communicating peers need to have a FQDN with consistent information in the forward and reverse trees. The protocol uses the DNS at the end of the communication which normally does the DNS lookup, to not only find all the locators (as AAAA records) but also verify that these locators have reverse tree entries which point back at the FQDN. The locators which do not point back to the FQDN will not be used as part of the locator set. At the end of the communication which isn't required to do a DNS lookup today (the responder or server), this protocol, at some point after the context has been created message is received, will use the AID (normally the source address of the CCR packet) to first find the peer's FQDN, and them perform a forward lookup plus a reverse lookup of all the IPv6 locators, in order to verify that these locators are bound to the same FQDN. As in the initiator case, the locators which do not verify using this method will be excluded from the locator set. If no locators verify, then only the AID will be viewed as part of the locator set i.e., the protocol falls back to not providing any address agility. For the protocol to work well, both ends have to agree on each other's locator sets. There are several reasons why a host's notion of its locators (or IPv4 addresses today) might be different than the set of locators present in the DNS for the host's FQDN (misconfiguration, DNS load balancing, in-progress DNS update, etc.) In order to cope with this, the two communicating hosts exchange each other's notion of each other's locators and form the intersection about what they know (about themselves as well as the peer) and what the peer knows (about themselves as well as the peer). A property of this approach is that the locator set can never be larger than what is contained in the DNS, that is, a host can not use this to fool its peer to include additional locators as destinations, for instance for 3rd party DoS attacks [M6THREATS]. This intersection should never be empty; an empty intersection is an indication that only the AID should be used. The hosts' locators might change over time due to renumbering. At some point in time such a change will need to be reflected in the DNS in order for this protocol to be able to take advantage of any added locators. The protocol uses the Update Request from the peer in combination with the DNS TTL as an indication when it makes sense to redo the DNS lookup of the peer's FQDN to detect changes in the locator set. draft-nordmark-multi6-noid-02.txt [Page 11] INTERNET-DRAFT Multihoming without IDs July 7, 2004 3.2. Host-Pair Context The host-pair context is established on the initiator of communication based on information learned from the DNS (either by starting with a FQDN or with an IP address -> FQDN lookup). The responder will establish some initial state using the context creation 4-way handshake and later verify the peer's locators using the DNS. The context state contains the following information: - the peer locator which the ULP uses as ID; AID(peer) - the local locator which the ULP uses as ID; AID(local) - the set of peer locators determined from the DNS; Lsr(peer) - the set of peer locators communicated from the peer; Lsl(peer) - the set of peer locators; Ls(peer); intersection of the two above - for each peer locator, a bit whether it has been verified with the DNS (by doing reverse + forward lookup). This can be viewed as forming a subset of Ls(peer) which we call Lsv(peer). - the preferred peer locator - used as destination; Lp(peer) - the set of local locators from local information; Lsl(local) - the set of local locators communicated from the peer, that is, which the peer found in the DNS; Lsr(local) - the set of local locators; Ls(local); intersection of the two above - the preferred local locator - used as source; Lp(local) - the flow label allocated by the peer that is used to transmit packets; F(peer) - the flow label allocated by the host to expect in received packets; F(local) - the fully qualified domain name for the peer; FQDN(peer) - State about peer locators that are in the process of being verified in the DNS draft-nordmark-multi6-noid-02.txt [Page 12] INTERNET-DRAFT Multihoming without IDs July 7, 2004 - Peer's birthday counter (a counter which increments by one each time the host reboots) This state is accessed differently in the transmit and receive paths. In the transmit path when the ULP passes down a packet the key to the context state is the tuple ; this key must identify at most one state record. In the receive path it is the F(local) flow label, which was allocated by the host itself, to uniquely identify a host-pair context. This limits a single host to maintaining about 1 Million host-pair contexts at a time; limited by the 20 bits of flow label. A host that needs to support more than this limit, can do so by acting as multiple hosts from the perspective of this protocol. This would entail having multiple FQDNs and each FQDN being associated with a different set of locators. For instance, these different locators might use different interface identifiers. Note that the flow labels could be selected to be finer grain than above; for instance having a different flow label for each connection. Doing so requires some efficient data structure organization at the receiver to map multiple F(local) to the same context and it might make the host run out of flow labels more easily. However, the use of finer grain flow labels might be necessary when the flow labels are also used for QoS purposes in the routers. [RFC3697]. 3.3. Message Formats The set of messages and message sequences are similar to those in [HIP] and [WIMP] but the content is quite different, due to the different approach to security. The base M6 header is an ICMPv6 header as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ICMPv6 Fields: Type TBD [IANA] draft-nordmark-multi6-noid-02.txt [Page 13] INTERNET-DRAFT Multihoming without IDs July 7, 2004 Code 8-bit field. The type of M6 message. The M6 header carries seven different types of messages: o Context Initiator message (INIT) o Context Check message (CC) o Context Check Reply message (CCR) o Context Confirm message (CONF) o Update Request message (UR) o Update Acknowledgement message (UA) o Unknown Context message (UC) Checksum The ICMPv6 checksum. Future versions of this protocol may define new message codes. Receivers MUST silently ignore any message code they do not recognize. This drafts doesn't contain actual message layout for the code specific part. However, the content of these messages is specified below. 3.3.1. Context Initiator (INIT) Message Format The Context Initiator (INIT) message contains: - Initiator Nonce (used to match the CC message with the INIT message) - Initiator's AID - Responder's AID - Initiator's locally determined locators - Lsl(initiator) - Responder's remotely determined locators - Lsr(responder) - Initiator's flow label (20 bits) - Initiator's birthday counter (a counter which increments by one draft-nordmark-multi6-noid-02.txt [Page 14] INTERNET-DRAFT Multihoming without IDs July 7, 2004 each time the host reboots) 3.3.2. Context Check (CC) Message Format When the responder receives an INIT message it does not allocate any state to prevent a class of DoS attacks. Instead it sends a CC message, which effectively contains the state it would have allocated, and gets that information echoed back from the initiator in a CCR message. This context state consists of: - the two AIDs - the initiator's flow label (The responder's flow label is allocated when the CCR message is received.) - the initiator's locator set from the INIT message; Lsl(initiator) - the responder's locator set from the INIT message; Lsr(responder) - the responder's locator set as know to the responder itself; Lsl(responder). The encoding [TBD] for the responder's locator set can use two bits per locator to indicate whether a locator is in Lsr(responder), Lsl(responder), or both. - The two birthday counters - The "ULP packet discarded" bit indicating that the ULP packet piggybacked on an INIT message was not delivered to the ULP. The Context Check (CC) message contains: - Initiator's Nonce (copied from the INIT message) - Context state as above - A timestamp or nonce (for the benefit of the responder matching the CCR message with the CC, as well as finding the per-host key which was used with the hash below) - A hash over the context state and timestamp/nonce (to prevent modification of the context state between sending it in the CC and receiving it back in the CCR message) draft-nordmark-multi6-noid-02.txt [Page 15] INTERNET-DRAFT Multihoming without IDs July 7, 2004 3.3.3. Context Check Reply (CCR) Message Format The Context Check Reply (CCR) message contains: - Initiator's nonce (to match the CONF message with the CCR) - The context state, timestamp/nonce, and hash copied from the CC message. 3.3.4. Context Confirm (CONF) Message Format In case the responder performs some verification of the peer's locator before it sends the CONF message, it can include the Lsr(initiator) in the CONF message. If this verification is deferred, then a Update Request message will need to be sent later if the DNS verification indicates that some of the peer's locators should not be used because they are not in the DNS. The Context Confirm (CONF) message contains: - Initiator's AID - Responder's AID - Initiator's Nonce (copied from the INIT or CCR message which triggered sending the CONF message) - The responder's flow label - Responder's birthday counter. (Needed when the CONF is in response to an INIT message). - Optionally the initiator's remotely determined locators - Lsr(initiator) - Optionally the responder's locally determined locators - Lsl(responder). (Needed when the CONF is in response to an INIT message). 3.3.5. Update Request (UR) Message Format Either end of the communication can send an update request to inform the peer of a change in the locator sets. This change could be any combination of additions to the sender's local locators, deletions to draft-nordmark-multi6-noid-02.txt [Page 16] INTERNET-DRAFT Multihoming without IDs July 7, 2004 the sender's local locators, or changes to the peers locators that have been determined from the DNS. The Update request message contains: - Request nonce/timestamp (used to match the UA with the UR) - Sender's and receiver's AID - Sender's and receiver's flow label for the context. - Sender's locally determined locators - Lsl(sender) - Receiver's remotely determined locators - Lsr(receiver) 3.3.6. Update Acknowledgement (UA) Message Format The Update Acknowledgement message signals the receipt of the Update Request message and contains: - Nonce/timestamp copied from the UR message - Sender's and receiver's AID - Sender's and receiver's flow label for the context. If both ends need to update each other, each end has to send an Update Request message. 3.3.7. Unknown Context (UC) Message Format The Unknown Context message contains: - The 20-bit flow label from the triggering packet. - The birthday counter (a counter which increments by one each time the host reboots) - The triggering packet starting with the IPv6 header (as much of the packet as fits in the MTU) draft-nordmark-multi6-noid-02.txt [Page 17] INTERNET-DRAFT Multihoming without IDs July 7, 2004 4. PROTOCOL WALKTHROUGH 4.1. Initial Context Establishment Here is the sequence of events when A starts talking to B: 1. A looks up FQDN(B) in the DNS which returns Lsr(B) plus "B is M6 capable". One locator is selected to be returned to the application: AID(B) = L1(B). The others are installed in the M6 layer on the host with AID(B) being the key to find that state. To make sure that the lookup from AID(B) returns a single state record it appears that one needs to do a reverse lookup of AID(B) to get the FQDN and check that the result is indeed FQDN(B). Whether this check can be deferred until two entities try to use the same AID(B) for a different Ls is for further study. Always doing the reverse lookup would be more predictable in any case. See section 16.2 for some more discussion. 2. The ULP creates "connection" state between AID(A)=L1(A) and AID(B) and sends the first packet down to the IP/M6 shim layer on A. L1(A) was picked using regular source address selection mechanisms. 3. The M6 layer matches on AID(B) and finds the proto-context state (setup in step #1) with Lsr(B). The existence of that state means that it is possible to establish a host-pair context. Host A can decide when to establish the context; it can defer this and use regular IPv6 with the locators being the AIDs for some time. In this example A decides to immediately establish the host-pair context. Thus it sends an INIT message with the ULP packet as part of the payload (if the MTU allows it to fit). Before sending the INIT message A selects a unique flow label F(local) for the new context and a nonce to match the CC with the INIT. 4. The packet (TCP SYN or whatever) is sent to the peer with locators L1(A) to L1(B) i.e., the same as the AIDs, piggybacked on the INIT message. It is possible to set the "rewrite ok" bit in the header for the INIT header, but if the locators are rewritten the piggybacked packet can not be passed to the ULP. draft-nordmark-multi6-noid-02.txt [Page 18] INTERNET-DRAFT Multihoming without IDs July 7, 2004 5. Host B receives the INIT message and passes the packet to the M6 shim layer. The M6 layer can't create state on the first packet, but if the packet was not rewritten in transit (that is, the AIDs are in the IP address fields) it can pass a piggybacked packet to the ULP. The ULP sees a packet identified by AID(A), AID(B). If the source address field is different than AID(A), then it is not safe to pass a piggybacked packet to the ULP since it could have been a case of spoofed AIDs. In this case the CC message would indicate that the ULP packet was dropped so that the initiator can retransmit the ULP packet once the context has been established. The CC message is sent to the source locator of the INIT, even if the peer AID is different. The same technique as in [MIPv6] is used to securely do the CC/CCR exchange without any local state; use a local per-host key which is never shared with anybody and pass the context state, a timestamp, and the keyed hash of the state+timestamp in the CC message. When the state, timestamp, and keyed hash value is returned in the CCR message, the hash is used to verify that the state hasn't been modified by the initiator. The 4-way exchange is done asynchronously with ULP packets, but it is possible (assuming the MTU allows) to piggyback ULP packets on the CC message. Should ULP packets be passed down to the M6 layer on B before the CCR message has been received, there will be no context state and no state installed as a result of a DNS lookup (unlike on A). This will indicate that the ULP message should be passed as-is (not as an M6 message) to the peer. Thus during the 4-way exchange packets can flow in both directions using the original locators=AIDs. 6. Host A receives the CC message. It verifies that the message is sent in response to the INIT by comparing the nonce. If a ULP packet was piggybacked A will pass that to the ULP. This can be done even if the locators where rewritten as long as the locators are part of the locator sets known to A. A forms the peer's locator set by taking the intersection of the Lsr it found in the DNS and the Lsl returned in the CC message. If the AID(peer) is not part of the Lsl(peer) it is an error and the AID is added to the locator set. [The fact that the peer forgot to include the AID could be an indication that it is seriously confused. The sender should ensure that the AID is draft-nordmark-multi6-noid-02.txt [Page 19] INTERNET-DRAFT Multihoming without IDs July 7, 2004 always included in the locator set when sending a locator set to a peer.] Then A sends a CCR message which has the same information as the CC message. The message is sent to the source locator for the CC message. 7. Host B receives the CCR message. It verifies that the hash of the state is correct using its per-host key and verifies that the timestamp is recent. At this point in time it knows that A is at least not just blasting out INIT messages as a DoS - A is also responding to CC messages. Thus B goes ahead and allocates state at this point in time using the state that is in the CCR message, and allocates a unique F(local) for this context. At this point in time B has enough information to handle M6 packets from A, even though it hasn't yet verified the peer's locators in the DNS. If a ULP packet was piggybacked on the CCR message, B will pass that to the ULP. This is done even if the IP address fields do not contain the AIDs, since having created the context state when the CCR was received, any "response" packets from the ULP will only be sent out to the verified peer locators for the context. Hence there is no risk that this can be used for reflection attacks that bypass any deployed ingress filtering. In response to the CCR message, B sends a CONF message which includes the allocated F(B). Also, if B has performed some DNS verification of the initiator's locators prior to sending the CONF message, and not all locators in Lsl(A) verified, then B includes the Lsr(A) in the CONF message. If B later discovers that not all locators in Lsl(A) verified it will need to send an Update Request message. At this point in time B can start asynchronously and incrementally extracting and verifying Lsr(A) from the DNS. The first lookup consists of finding L1(A)=AID(A) in ip6.arpa to get the FQDN and record it, and lookup the AAAA RR set for that FQDN to get Lsr(A). Based on Lsr(A) and the Lsl(A) received in the CCR, B can form the intersection Ls(A). If this intersection does not contain AID(A) it is an error and the AID is added to the locator set. Once Ls(A) is known, B can verify (also incrementally) that each member of Ls(A) is indeed assigned to A by doing a reverse lookup of each one (except L1(A) which was already looked up above). Only when the reverse lookup of a given peer locator draft-nordmark-multi6-noid-02.txt [Page 20] INTERNET-DRAFT Multihoming without IDs July 7, 2004 has completed is that locator marked as verified. This reverse lookup of each locator prevents 3rd party DoS attacks as described in [M6THREATS]. At this point in time B knows that A has context state and it knows the flow label to use, thus it can start sending packets using the context. 8. Host A receives the CONF message, records F(peer) from the packet, and if present, extracts the Lsr(A) and forms the intersection Lsl(A) and Lsr(A) and uses this to update Ls(A). If the resulting Ls(A) does not contain AID(A) this is an error and the AID is added to the locator set. If a ULP packet was piggybacked on the CONF message, A will pass that to the ULP as long as the source locator of the CONF message was one of as part of the verified Ls(peer) locators. At this point in time A knows that B has context state and it knows the flow label to use, thus it can start sending packets using the context. 4.2. Locator Change This is the sequence of events when B receives a packet with a previously unused source locator for A, for instance L2(A). Host B receives M6 packet with source L2(A) and destination L1(B). Looks up context state using the flow label. If this lookup succeeds and the source address field contains a locator which is in Lsl(B), then the locator is acceptable for incoming packets (even though it might not have been verified for use as return traffic) and the packet is rewritten to contain the AIDs from the context state and passed to the ULP. If L2(A) has not been verified then it would make sense for B to put that locator first in the list of asynchronous DNS verifications that are needed. If/once L2(A) has been verified B can make it the preferred peer locator to use when sending packets to AID(A). The verification needs to complete before using the locator as a destination in order to prevent 3rd party DoS attacks [M6THREATS]. If a host receives a packet with a known flow label but where the locators (source and/or destination) are not part of the locator sets, the packet is silently dropped as specified in more detail in Section 7.11. draft-nordmark-multi6-noid-02.txt [Page 21] INTERNET-DRAFT Multihoming without IDs July 7, 2004 4.3. Concurrent Context Establishment Should both A and B attempt to contact each other at about the same time using the same AIDs for each other, the message flow is different than above. However, if different AIDs are used this would result in two completely independent contexts between the two hosts following the basic content establishment above. If B tries to contact A after B has received the CCR message, then B will discover the context state for AID(A) and not trigger creating a new context. But since B does not create any state when receiving the INIT, it is possible for B to send a INIT after it has received an INIT (and sent a CC), as well as the case of two crossing INIT messages. 4.3.1. Crossing INIT messages Here is the sequence of events when A starts talking to B at the same time as B starts talking to A: 1. A sends an INIT message to B. As part of this A creates proto- state for the context and allocates its flow label. It has Lsr(B) from the DNS lookup. 2. B sends an INIT message to A. As part of this B creates proto- state for the context and allocates its flow label. It has Lsr(A) from the DNS lookup. 3. B receives the INIT message from A. It discovers the context it created in step 2 since it matches the AIDs. Thus it can immediately send a CONF message containing its flow label and Lsr(A). 4. A receives the INIT message from B. It discovers the context it created in step 1 since it matches the AIDs. Thus it can immediately send a CONF message containing its flow label and Lsr(B). 5. A receives the CONF message from B and can complete the context state creation. 6. B receives the CONF message from A and can complete the context state creation. draft-nordmark-multi6-noid-02.txt [Page 22] INTERNET-DRAFT Multihoming without IDs July 7, 2004 4.3.2. Sending INIT after sending CC Here is the sequence of events when A starts talking to B, and after B has received the INIT but before B has received the CCR, B starts establishing a context with A: 1. A sends an INIT message to B. As part of this A creates proto- state for the context and allocates its flow label. It has Lsr(B) from the DNS lookup. 2. B receives the INIT message from A. It finds no matching context thus it proceeds in the normal context establishment and sends a CC message to A. 3. A ULP on B wants to send a packet to AID(A) which triggers B to send an INIT message to A. As part of this B creates proto- state for the context and allocates its flow label. B has Lsr(A) from the DNS lookup. 4. A receives the CC message from B and responds with a CCR message as in the normal context establishment. 5. A receives the INIT message from B. It discovers the context it created in step 1 since it matches the AIDs. Since A has sent the CCR it knows that the B will soon complete the context establishment and respond with a CONF message. Thus the INIT can be silently ignored. 6. B receives the CCR message from A. At this point in time it discovers that it is a bidirectional setup because it has context state indicating that it has sent an INIT message. B needs to inform A of the flow label it selected in step 3, which is does in the CONF message. 4.4. Handling Locator Failures Should not all locators be working when the communication is initiated some extra complexity arises, because the ULP has already been told which AIDs to use. If the locators that where selected to be AIDs are not working it isn't possible to defer the context establishment, but instead it needs to be performed before ULP packets can be successfully exchanged. If the destination locator isn't reachable, the M6 layer needs to retry the INIT message with different destination locators until a working one is found. If the source locator isn't reachable for return traffic, routers which rewrite the source locator at site exit can be helpful to convey to draft-nordmark-multi6-noid-02.txt [Page 23] INTERNET-DRAFT Multihoming without IDs July 7, 2004 the peer which locator to use. When the initiator's AID is not working as a locator, it isn't possible to piggyback ULP packets on the INIT message, to prevent using packets with a source locator different than the source AID being used for reflection attacks that would bypass any deployed ingress filtering. After context setup the sender can use retransmit hints from the ULP to get the M6 layer to try a different verified locator. This is the only possibility when only one end is (re)transmitting ULP packets and the destination locator is no longer working. Some heuristics are needed in the M6 layer to determine which alternative destination locator to try, and how often to try a different one when there are persistent failures. If one outbound path from the site fails and the border routers rewrite source locators then the peer will see packets with the working source locators. Once that locator has been verified by the peer, the return path will switch to use the working locator. As long as both ends are transmitting packets this will relatively quickly switch to working locators except when both hosts experience a failing locator at the same time. Without locator rewriting, it would be beneficial to add some notification e.g., by defining a new bit in the router advertisement prefixes to indicate that the prefix is problematic to use for due to failures at the site border (IMHO this is semantically different than the preferred vs. deprecated semantics), but we would also need some mechanism to carry this information from the border routers to the routers on each subnet. Perhaps the router renumbering protocol [RFC2894] could be extended to carry this information. 4.5. Locator Set Changes Due to events like site renumbering, the set of locators assigned to a host might change at a slow rate. Since this proposal uses the locators in the DNS as the credible source for which locators are assigned, there is some coordination necessary to ensure that before a host, or the border routers for a site doing rewriting, start using a new source locator, the peer has been informed about the new locator. The Update Request message is sufficient to inform the peer that a new locator should be acceptable as the source of packets from the host, while DNS verification needs to be involved to make that locator usable as a destination. Due to concerns about having packets with unknown, hence potentially bogus, source locators triggering DNS lookups this proposal instead uses the DNS TTL in combination with the locator sets in the Update draft-nordmark-multi6-noid-02.txt [Page 24] INTERNET-DRAFT Multihoming without IDs July 7, 2004 Request message, as an indication that the set of locators need to be refreshed. Each host determines when its own notion of its locators change, and uses the Update Request message to inform the peer of these changes. If a locator is removed from the set this will make the peer immediately stop considering that locator as part of the locator set. However, if an additional local locator is communicated to the peer in an Update Request, it can not be added to the verified locator set at the peer until it has also been seen in the DNS. Thus, when a host observes that it has a new locator, the host might want to verify that this locator has been added to the DNS for itself, before announcing it to the peer in an Update Request message. When a host receives an Update Request with an additional locator for the peer and the DNS TTL for the FQDN->Ls lookup has expired, the peer will redo this DNS lookup to find the, perhaps updated, set of locators in the DNS. (Presumably failures to redo the lookup shouldn't have a negative effect.) TBD: Even if there is no Update Request, should the DNS verification be redone periodically based on the DNS TTL? If so, what should the minimum time be to avoid DNS storms for FQDNs which have a very low TTL? When the DNS lookup for the peer's FQDN returns a different locator set than previously, the host will inform the peer of the new Lsr locator set in an Update Request. However, since this change to Lsv(peer) doesn't effect which source locators are acceptable in received packets, it is not time critical to send the Update Request message. If a host wants to modify the set of locators from which the peer accepts packets for the context, the host can send an Update Request message with a different Lsl(sender). When a host sees (based on router advertisements [DISCOVERY]) that one of its locators has become deprecated and it has additional locators that are still preferred, it is recommended that the host stop using the deprecated locator(s) as the source locator with the contexts that have already been established. This ensures that, should the deprecated locator become invalid, the peers have already verified other locator(s) for the host. TBD: Is there is a need to explicitly signal to the peer "this locator is deprecated - please verify another locator and use that as Lp(peer)" draft-nordmark-multi6-noid-02.txt [Page 25] INTERNET-DRAFT Multihoming without IDs July 7, 2004 4.6. Preventing Premeditated Redirection Attacks The threats document [M6THREATS] talks of premeditated redirection attacks, that is, where an attacker claims to be a host before the real host appears. The absence of an actual IP layer identifier in this proposal makes that a non-issue; the attacker could only claim to be host A if the attacker is reachable at one of A's locators. Thus by definition the attacker would have to be on the path between the communicating peers and such attackers can already perform redirection attacks in today's Internet. 5. HANDLING STATE LOSS The protocol needs to handle two forms of state loss: - a host loosing the M6 layer state followed by packets arriving from a peer which hasn't lost the state. This could be due to the host crashing and rebooting, or due to the M6 layer discarding the state too early. - the M6 layer garbage collecting state too early due to not being aware of what all ULPs do, resulting in the ULP passing down packets when there is no context state any more. Part of the first case is the already existing case of a host crashing and "rebooting" and as a result loosing transport and application state. In this case there are some added complications from the M6 layer since a peer will continue to send packets assuming the context still exists and due to the loss of state on the receiver it isn't even able to pass the correct packet up to the ULP (e.g., to be able to get TCP to generate a reset packet) since it doesn't know what AIDs to use when replacing the locators. The second case is a bit more subtle and has two facets. Ideally an implementation shouldn't discard the context state when there is some ULP that still depends on this state. While this might be possible for some implementations with a fixed set of applications, it doesn't appear to be possible for implementations which provide the socket API; there can be things like user-level "connections" on top of UDP as well as application layer "session" above TCP which retain the identifiers from some previous communication and expect to use those identifiers at a later date. But the M6 layer has no ability to be aware of this. Thus an implementation shouldn't discard context state when it knows it has ULP connection state (which can be checked in e.g., Unix for draft-nordmark-multi6-noid-02.txt [Page 26] INTERNET-DRAFT Multihoming without IDs July 7, 2004 TCP), or when there is active communication (UDP packets being sent to AID(A) recently), but when there is an infrequently communicating user-level "connection" over UDP or "session" over TCP the context state might be garbage collected even though it shouldn't. Knowing whether the ULP depends on the M6 layer state is not sufficient; even if the ULP doesn't, the peer host might still keep the context state. Thus the peer might send a packet using the context at some future time. To the host this looks similar to the reboot state loss, in the sense that it receives packets from the peer and has no matching context. The host doesn't know whether this is due to a legitimate peer which has retained the context state, or whether it is a DoS attack using random flow labels. However, if the ULP on the host passes down a packet to transmit it would turn into the second case. 5.1. State Loss and Packets from the Peer If B crashes and reboots and A retransmits a packet with flow label, L3(B), L2(A) then what is needed on B is a packet to L1(B) from L1(A) passed to the ULP so that the ULP can send an error (such as a TCP reset). But B has no matching state thus it needs to send an Unknown Context error back to try to help A discover the state loss. Another case is when B decides that the context has not been used for a long time and as a result discards the context state, and then a packet (perhaps a TCP SYN for a new connection) arrives from the peer using the context i.e., an M6 packet with a flow label. In this case, B has no choice but send an Unknown Context error back to A. (But see Appendix A for a method to remove the need for this error ever arising.) However, if A blindly trusts the Unknown Context message and uses it to restart a context establishment, that is, discarding its current context state and sending a INIT, then this could be used by attackers to force extra work, but also it would allow an attacker that arrives on the path after a context has been established to destroy the existing context and insert itself as a Man-in-The-Middle for the new context establishment. Given that the locators might be rewritten by routers, the main thing A has to identify the context is the flow label in the packet that caused the Unknown Context error at B. While this uniquely identifies the context on host B, it does not do so on A. Thus if A maintains some number of contexts with different peers, it might not be able to uniquely tell to which context the Unknown Context error should be applied. The use of the source address field in the draft-nordmark-multi6-noid-02.txt [Page 27] INTERNET-DRAFT Multihoming without IDs July 7, 2004 Unknown Context message should help disambiguate things, but it isn't clear to what extent this helps. This ambiguity is an opportunity that an attacker can take advantage of. The introduction of the birthday counter (an idea from [HIP]), with a relatively small window (e.g., 900) of acceptable birthday counter values can substantially reduce the probability of off-path attackers being able to use the Unknown Context error to kill a context by sending bogus Unknown Context errors. If we in addition introduce the close exchange, as suggested in Appendix A, we also remove most of the ability of an attacker to cause extra work by having a host respond to packets with random flow labels with Unknown Context errors. This combination of the birthday counter and the CLOSE/CLOSEACK messages, means that the Unknown Context error only needs to be when packets with an unknown flow label are received during the first X minutes after the reboot. 5.2. State Loss and Packets from the ULP If host B only lost (for instance, by garbage collecting too early) the M6 context state, things are a bit more complicated for packets passed down from the ULP. Without any context state the M6 layer on B can not determine whether packets to AID(A) coming from the ULP are destinated to a standard IPv6 host, or to a host which supports multihoming. At a minimum the host needs to try to determine this, and if it somehow determines that the peer supports multihoming, then it should try to determine the peer's locators and reestablish a host-pair context. B can determine whether A is M6 capable by doing a reverse lookup of AID(A)->FQDN(A) followed by a FQDN(A) lookup to see of there is an M6 record (and get the locator set of A as well). Or, if DNS reverse lookups are undesirable or do not work, perhaps a packet could be exchanged with A to ask it whether it supports multihoming. Simply sending an INIT message to the AID(A) will not only tell it whether A supports multihoming, but also let B know the flow label and Lsl(A) locators to use. But as this protocol is currently specified, using a new ICMP type, an INIT message sent to a host which doesn't support multihoming will be silently dropped. TBD: Would it make sense to instead use a new payload type for the M6 messages to at least receive an ICMP payload type unknow error from hosts which do not support multihoming? If B is communicating with both standard IPv6 hosts and hosts which support multihoming, then for performance reasons it should avoid doing these DNS lookups or peer queries for every packet sent to a standard IPv6 host. Implementation tricks (such as "has this socket draft-nordmark-multi6-noid-02.txt [Page 28] INTERNET-DRAFT Multihoming without IDs July 7, 2004 ever used M6" flag at the socket layer, "negative caching" of peers that do not support M6) can be useful to avoid performance overhead, and caching of the peers that do support M6 can all be used to address this performance concern. If, as part of this, B determines that A is M6 capable, it has the same information as the initiator during the initial context establishment thus it can follow that procedure starting by sending an INIT message. If A didn't garbage collect its end of the state this will result in receiving a CONF message from A which includes the flow label etc. 6. ENCODING BITS IN THE IPv6 HEADER? The idea is to pick extra IP protocol values for common combinations, and have a designated protocol value to capture the uncommon IP protocols which might use M6. The uncommon IP protocol values would require an additional extension header when used over M6. We pick two unused ranges of IP protocol values with 8 numbers each (assuming we will not need more than 7 common transport protocols). The ranges start at P1 and P2, respectively: P1 TCP over M6 - rewrite ok P1+1 UDP over M6 - rewrite ok P1+2 SCTP over M6 - rewrite ok P1+3 RDDP over M6 - rewrite ok P1+4 ESP over M6 - rewrite ok (...) P1+7 escape - any protocol over M6 - rewrite ok In this case we spend another 8 bytes (minimum IPv6 extension header size due to alignment rule) to carry the actual IP protocol. This causes some mtu concerns for those protocols, but they aren't very likely to be used with M6? P2 TCP over M6 - no rewrite P2+1 UDP over M6 - no rewrite P2+2 SCTP over M6 - no rewrite P2+3 RDDP over M6 - no rewrite P2+4 ESP over M6 - no rewrite (...) P2+7 escape - any protocol over M6 - no rewrite In this case we spend another 8 bytes (minimum IPv6 extension header size due to alignment rule) to carry the actual IP protocol. This causes some mtu concerns for those protocols, but they aren't very likely to be used with M6? draft-nordmark-multi6-noid-02.txt [Page 29] INTERNET-DRAFT Multihoming without IDs July 7, 2004 Thus a router would check if the protocol is in the P1 range and if so, it can rewrite the locator(s). A host would check a received packet against both P1 and P2 ranges and if so pass it to the M6 shim layer. Some possible alternatives to the above encoding: - use some combination of the universal/local and group bit in the interface id of the source address field to indicate "rewrite ok". - always have a M6 shim header - adds 8 bytes overhead per packet. 7. PROTOCOL PROCESSING A more detail description of the protocol is presented in this section. 7.1. State Machine The protocol can be described using the following states: o IDLE: no state for the context at all. o INIT-SENT: an INIT message has been sent. o CCR-SENT: a CCR message has been sent. o ESTABLISHED: a CCR or CONF message has been received thus the context is fully established with data packets being carried using the flow labels and Section 6 encoding. o UR-SENT: Established but awaiting an Update Acknowledgement. 7.2. Sending INIT messages When a host needs a host-pair context it first checks if there already is a context which matches the pair of AIDs. If not, it will establish such a context by sending an INIT message. The sender of the INIT message is a called the "initiator" and the peer is called the "responder" even if this terminology is inexact when both ends send INIT messages at about the same time. The initiator must verify that the AIDs are part of the locator sets; draft-nordmark-multi6-noid-02.txt [Page 30] INTERNET-DRAFT Multihoming without IDs July 7, 2004 if this is not the case it is most likely due to some local confusion on the initiator since the AIDs were selected (see Section 4.1) from the locator sets. If the initiator knows that it doesn't have a FQDN or that a verification using forward and reverse lookups would fail, for instance due to the reverse tree not being populated, it might as well only include the AID in Lsl(initiator) since this saves the responder the effort to try to verify things in the DNS. The initiator creates a proto-context state and allocates a unique flow label; F(local). Then it picks a random [RANDOM] nonce to include in the INIT message, sends the INIT message, and sets the state to INIT-SENT. The first INIT message is sent to the destination locator which is the AID. Should the INIT message be retransmitted, a different destination locator should be used. The INIT messages, as all other M6 control messages, can be sent with the "rewrite ok" bit set. If the routers do not rewrite the source locators it might be necessary for the initiator to try different source locators as well as destination locators as it is retransmitting the INIT message. 7.3. Receiving INIT messages When a host receives an INIT message it first checks whether it has an existing context for the AID pair. If such a context is found, the following additional checks are applied: o The state is INIT-SENT or ESTABLISHED o The IP source address field in the INIT contains a locator which is part of Lsl(peer) o The IP destination address field in the INIT contains a locator which is part of Lsl(host) If any of the above checks fail the INIT message is silently dropped. If all the checks succeed, the host can update the existing context from the INIT message (the peer's birthday counter, locator set, and flow label) and respond with a CONF message. The CONF message should include the nonce from the INIT message, the local flow label, the local birthday counter, Lsr(peer) and Lsl(responder) from the existing context. If the INIT message matching an existing context draft-nordmark-multi6-noid-02.txt [Page 31] INTERNET-DRAFT Multihoming without IDs July 7, 2004 has piggybacked a ULP packet, this packet is passed to the ULP. In there is no state matching the AID pair, the host verifies that the AID(responder) is in fact one of its locators. Should this fail the INIT message is silently dropped. Then the responder forms a CC message using a per-host key and a timestamp or serial number to produce a keyed hash to protect the state information carried in the CC message and returned in the CCR message. If the responder knows that it doesn't have a FQDN or that a verification using forward and reverse lookups would fail, for instance due to the reverse tree not being populated, it might as well only include the AID in Lsl(responder) in the CC message since this might save the initiator the effort to try to verify things in the DNS. If the INIT packet has a piggybacked ULP packet, that is, the nexthdr value is something different than NONXTHDR, this packet can potentially be passed to the ULP. It is safe to pass it to the ULP when the source and destination address fields in the INIT packet are the AIDs, and it is also safe to accept such packets when the destination address field contain a locator different than the AID. But if either the INIT packet was sent with a different source locator or the source locator was rewritten in transit, it is not safe to pass the piggybacked packet to the ULP. (This is because until the context state is created, any "response" packet from the ULP would be sent as a regular IPv6 packet to the peer AID. The need to prevent reflection attacks which can bypass any deployed ingress filtering means that we need to avoid this when the INIT packet was not sourced by the AID.) In this case the responder sets the "ULP packet discarded" bit in the CC message. 7.4. Receiving CC messages The host looks for a matching context based on the AID pair. If no context is found, or if the context is not in state INIT-SENT, or if the nonce doesn't match what was sent in the INIT, the CC message is silently dropped. Otherwise the host records the Lsl(peer) from the CC message, changes the state to CCR-SENT, and sends a CCR message. The CCR message can either reuse the nonce used with the INIT message, or a new random nonce can be selected. The host forms Ls(peer) as the intersection between Lsr(peer) and draft-nordmark-multi6-noid-02.txt [Page 32] INTERNET-DRAFT Multihoming without IDs July 7, 2004 Lsl(peer). If this intersection does not contain AID(peer) it is an error and the AID is added to the set. If the CC packet has a piggybacked ULP packet, this packet can potentially be passed to the ULP. It is clearly safe to pass it to the ULP when the source and destination address fields in the CC packet are the AIDs. But it seems to also be safe when the address field contents fall in the locators sets as known to the initiator. If this is not the case, then the piggybacked ULP packet is silently ignored. 7.5. Receiving CCR messages The timestamp/serial is verified to be recent, and then the timestamp/serial is used to determine which per-host key was used for the keyed hash in the CC message. Using this key, the keyed hash is verified. If it does not verify, or if the timestamp/serial is too old, the CCR message is silently dropped. Then the host looks for a matching context based on the AID pair. If a context is found this could be the second form of concurrent context establishment. The host performs the following checks: o The state is INIT-SENT o The IP source address field in the CCR contains a locator which is part of Lsl(peer) o The IP destination address field in the CCR contains a locator which is part of Lsl(host) If any of the above checks fail the CCR message is silently dropped. If the checks all succeed, the host can update the existing context from the CCR message (the peer's birthday counter, locator set, and flow label) and respond with a CONF message. If this update results in Ls(local) or Ls(peer) not including the corresponding AID, this is an error and the AID is added to the set. The CONF message should include the nonce from the CCR message, the local flow label, the local birthday counter, the Lsr(peer), and Lsl(responder) from the existing context. If a context is not found, then one is created based on the information in the CCR message. The host allocates a flow label for the context. The host MAY perform a reverse plus forward DNS lookup starting with AID(peer), and if so it includes the resulting draft-nordmark-multi6-noid-02.txt [Page 33] INTERNET-DRAFT Multihoming without IDs July 7, 2004 Lsr(initiator) in the CONF message. Otherwise, the CONF message only contains the nonce, flow label and birthday counter. If the CCR packet has a piggybacked ULP packet, it will be passed to the ULP independently of the IP address fields in the CCR message. This is possible because even if the CCR contains spoofed locators and/or AIDs, any "response" packet from the ULP will only be sent to the verified peer locators now that the context state has been created. 7.6. Receiving CONF messages The host looks for a matching context based on the AID pair. If no matching context is found the CONF message is silently discarded. If the state is INIT-SENT and the nonce does not match the nonce sent in the INIT, the CONF message is silently discarded. If the state is CCR-SENT and the nonce does not match the nonce sent in the CCR, the CONF message is silently discarded. In any other state the CONF message is silently discarded. Then the CONF message is used to record the peer's flow label. If the CONF message contains the Lsr(initiator) this is used to update the context. As part of this Ls(initiator) is updated to be the intersection of Lsr(initiator) and Lsl(initiator). If this intersection does not contain AID(initiator) this is an error and the AID is added to the set. If the CONF message contains the Lsl(responder), which is the case during bidirectional establishment i.e., the CONF was sent in response to an INIT message, then this is used to update the context and Ls(responder) is updated to be the intersection of Lsr(responder) and the received Lsl(responder). If this intersection does not contain AID(responder) this is an error and the AID is added to the set. Finally the state is changed to be ESTABLISHED. If the CONF packet has a piggybacked ULP packet, this packet can potentially be passed to the ULP. It is clearly safe to pass it to the ULP when the source and destination address fields in the CONF packet are the AIDs. But it seems to also be safe when the address field contents fall in the locators sets as known to the initiator. [Given that the CONF is know to be the result of a INIT/CCR packet, draft-nordmark-multi6-noid-02.txt [Page 34] INTERNET-DRAFT Multihoming without IDs July 7, 2004 it can be assumed that the locators fall in the sets?] If this is not the case, then the piggybacked ULP packet is silently ignored. 7.7. Sending Update Request messages When a hosts sees that either its own locator set has changed, or that the DNS verification (initial, or redone after DNS TTL expiry) of the peers locators show a reduction in the locator set, the host should send an Update Request. The sender of the Update Request should verify that the AIDs are part of the locator sets as part of sending the Update Request. The sender picks a random nonce to include in the message, sends the message to Lp(peer), and sets the state to UR-SENT. 7.8. Receiving Update Request messages The host looks for a matching context based on the AID pair and the flow label pair in the Update Request message. If no context is found, the Update Request is silently dropped. If a context is found, it is verified that the locators that are in the IP address fields are part of the Lsl locator sets. If not, the update request is silently dropped. Then the locators in the Update Request are used to update the context state. As part of this the intersections of the local and remote locator sets are maintained. Should either of the intersections not include the corresponding AID this is an error and the AID in question is added to the set. The receipt of a reduced Lsl(sender) should result in immediately no longer using the removed locators as destination locators for transmitted packets. The receipt of an increased Lsl(sender) should, if the remaining DNS TTL for the FQDN has reached zero, trigger a a DNS verification (forward and reverse lookup) of the new locators. Should this verification complete successfully, the locator(s) will be added to the verified set of peer locators hence be valid for transmitting packets. The receipt of changes to Lsr(receiver) is less critical since the peer will accept as source locators any of the locators that are part of the Lsl(receiver) that was communicated to the peer during context establishment or in the most recent Update Request. draft-nordmark-multi6-noid-02.txt [Page 35] INTERNET-DRAFT Multihoming without IDs July 7, 2004 The host responds to the Update Request by sending an Update Acknowledgement back to the sender of the request copying the nonce/timestamp, AIDs and flow labels from the request. 7.9. Receiving Update Acknowledgement messages The host looks for a matching context based on the AID pair and the flow label pair in the Update Acknowledgement message. If no context is found, the Update Acknowledgement is silently dropped. If a context is found, it is verified that the context state is in UR-SENT and that the nonce in the acknowledgement matches the nonce that was sent in the request. If either of those checks fail, the message is silently dropped. Otherwise, the state for the context is changed back to ESTABLISHED. 7.10. Retransmission The INIT messages are retransmitted by the initiator until a CC or a CONF message with a matching nonce is received. The CC messages are not retransmitted; if they are lost the initiator will retransmit the INIT message. The CCR messages are retransmitted by the initiator until a CONF message with a matching nonce is received. The Update Request messages are retransmitted until an Update Acknowledgement with a matching nonce is received. These retransmissions continue with binary exponential backoff until CONTEXT_IDLE_TIME (suggested 5 or 15 minutes) have passed. The initial retransmit timer is 4 seconds. It is suggested that some randomness be applied to the retransmit timer to avoid synchronization should lots of hosts in a site follow the same pattern of retransmissions. 7.11. Receiving Data Packets Received M6 control packets (INIT) etc are dispatched based on the ICMP code and processed as indicated in the sections above. draft-nordmark-multi6-noid-02.txt [Page 36] INTERNET-DRAFT Multihoming without IDs July 7, 2004 Received M6 data packets (as indicated by the payload types in section 6) are processed as follows: 1. Lookup the context based on the flow label 1a. If no context found, drop the packet and send a Unknown Context message to the sender. 2. Compare the destination address field with Lsl(local) 2a. If destination is not in Lsl(local), silently drop the packet. 2b. If destination is Lp(local), no action is needed. 2c. If destination is not Lp(local), should we change Lp(local) so that the source locator for transmitted packets is changed? [TBD] 3. Compare the source address field with Lsl(peer), Lsv(peer) 3a. If source is not in Lsl(peer), silently drop the packet. 3b. If source is in Lsl(peer) but not in Lsv(peer), trigger verifying that locator (and accept the packet). 3b. If source is Lp(peer), no action is needed. 3c. If source is not Lp(peer) and is in Lsv(peer), change Lp(peer) so that the destination locator for transmitted packets is changed. In the cases where the packet wasn't dropped above, the packet is rewritten to contain the AIDs from the context state and passed to the ULP. 7.12. Receiving Unknown Context messages Look for matching contexts (there might be multiple) that have the same peer flow label as the one in the UC message, and where Lsl(peer) in the context includes the source address field of the UC message. If no such context is found, silently discard the UC message. If the birthday counter in the UC message is the same as the recorded birthday counter for the peer, the UC message was due to the context draft-nordmark-multi6-noid-02.txt [Page 37] INTERNET-DRAFT Multihoming without IDs July 7, 2004 state being garbage collected without the peer rebooting. If the birthday counter in the UC message is greater than (using serial number arithmetic) the recorded birthday counter, but is not more than MAX_BIRTHDAY_INCR than this number, then the UC message is assumed to be due to a reboot of the peer. In both of the above cases the context can be discarded and a new context be initiated by sending an INIT message. [TBD: discard vs. update the existing context based on the CC and CONF messages?] If the birthday counter doesn't match either criteria, then UC message is silently dropped. In both above cases of acceptable UC messages it is RECOMMENDED that the host also verify whether the included packet is consistent with a packet that the host might have sent recently; for instance that in the case of UDP, TCP, or SCTP, the port numbers match port numbers that are currently in use and that the TCP and SCTP sequence numbers are reasonable for the matched connections. [The utility of these checks is limited, because for some ULPs such as ICMP echo messages, the host might not have any way to check things hence it is required to accept the UC message.] 7.13. DNS Verification and Hosts without a FQDN A host without a FQDN, or a host which knows that the forward and reverse DNS information for it is missing or inconsistent, can remove the need for the peer to detect this by passing a Lsl in INIT and CC messages which consists of only the AID for the context. When doing so, the "rewrite ok" bit should not be set for those messages. This approach is possible even if the host has multiple locators; it implies that such a host can take advantage of any multihoming of the peer even though it can't take full advantage of itself being multihomed. Thus the peer's locators can change for the context, but the host itself can only use its AID for the context. When a host verifies the locator relationship it treats the peer's AID as being implicitly verified by the context establishment handshake as long as the AID was used as the locator for this exchange. This is basically relying on the return routability property for the AID being a locator. Thus is Lsl(peer) contains the AID as a single member, and that AID is used as the locator during the context establishment, there is no need to perform any DNS verification. Since the host might not itself know that it doesn't have a FQDN or draft-nordmark-multi6-noid-02.txt [Page 38] INTERNET-DRAFT Multihoming without IDs July 7, 2004 that the reverse plus forward lookups would fail to verify, the peer also needs to take this into account in the verification. When an initiator verifies things using the reverse lookup and it discovers that the lookup for one or more of the peer's locators fail with a permanent DNS error, it should exclude those locator(s) from the set. And if all of them fail, it should still include the peer's AID as the only member in the peer's locator set. When a responder tries to verify the peer by performing DNS lookups (reverse and forward), if it fails to perform a reverse lookup on the peer AID due to a permanent DNS error, which is needed to find the FQDN, then it will assume that the peer has no FQDN. In this case the Lsr(peer) will contain only the AID(peer) i.e., the peer's locator can not change. However, it will still accept data packets with any of the Lsl(peer) locators in the source address fields; it will not send packets to any locator but the AID. If the reverse lookup of the peer's AID fails with a transient DNS error, it is recommended that the DNS lookup is redone (using binary exponential backoff until it either succeeds or fails with a permanent error). If the DNS lookups fail with a permanent error it is recommended that the locator set with the failed locators removed is signaled to be the peer as Lsr(peer) in an Update Request message. This will make the peer stop using those locators as source locators even though the host sending the Update Request will continue to accept packets from any of the locators in Lsl(peer). The initiator starts off with Lsr(responder) being based on what the forward DNS lookup returned. As successful reverse lookups, that is reverse lookups that point at the same FQDN, are completed on these locators, the locators are added to Lsv(responder) i.e. become candidate destination locators. The initial Lsv(responder) is the AID even without a reverse lookup. But should the INIT message be (re)transmitted to different destination locators, the AID will not be considered verified unless there has been a successful reverse lookup. The responder starts off with Lsv(initiator) containing only the AID, if and only if the AID was used as a locator during the context establishment. If the AID was not used as a locator during the establishment, the Lsv(initiator) will initially be empty. This implies that data packets can not be sent until at least one locator has been verified using the DNS. [TBD: Is this too strict? Can we allow the locator that was used during establishment to be in Lsv even though it is not the AID?] draft-nordmark-multi6-noid-02.txt [Page 39] INTERNET-DRAFT Multihoming without IDs July 7, 2004 When the host receives messages (CC, CONF, Update Request) which shrinks Lsl(peer), it will remove the deleted locators from Ls(peer) and as a result from Lsv(peer) as well. TBD: Need to know whether there is a strict definition of temporary vs. permanent DNS errors. Things like NXDOMAIN should be a permanent error. 7.14. Birthday Counter Each host needs to maintain a birthday counter in stable storage to help with safe resynchronization when one of the ends have lost its state. When a host is first initialized it allocates a random initial value for the birthday counter [RANDOM]. Each time the host looses all state, that is, crashes or powers off and reboots, it increments the birthday counter by one and saves the result in stable storage. The protocol needs a constant, MAX_BIRTHDAY_INCR, which should be chosen so that during the lifetime of a context after the peer has stopped sending (Appendix A uses X minutes for this), no host should reboot and increment its birthday counter more than this number of times. It might be reasonable to assume that no host can reboot more frequently than once a second. This implies that if the context is discarded 15 minutes after the last packet was received, the peer could have rebooted at most 900 times after it sent the last packet using the context. As a result the probability of an off-path attacker hitting this window of 900 in a 32-bit birthday counter is about 1 in a million. A 64-bit birthday counter might be overkill. 8. COMPATIBILITY WITH STANDARD IPv6 A host can easily implement M6 in a way that interoperates with current IPv6 as follows. When the DNS lookup routines do not find an M6 record for the peer they will return the AAAA resource record set to the application; those would be the IPv6 addresses. When the ULP passes down these addresses, the M6 layer will not have any state generated by the DNS lookup code, thus no M6 processing will take place on the sender. (Note that this relates to the M6 layer state recovery in section 5.2) draft-nordmark-multi6-noid-02.txt [Page 40] INTERNET-DRAFT Multihoming without IDs July 7, 2004 The receive side handles both standard IPv6 and M6 since it demultiplexes on whether a packet is an M6 packet, that is, based on the payload types in Section 6. 9. APPLICATION USAGE OF IDENTIFIERS The upper level protocols will operate on AIDs which are mere locators. Thus as long as a site hasn't renumbered, the AID can be used to either send packets to the host, or (e.g. if that locator isn't working) it is possible for an application to do a reverse lookup plus forward lookup of the AID to get the set of locators for the peer. Once a site has been renumbered, the AIDs which contain the old prefix will no longer be useful. Hence applications must try to honor the DNS TTL somehow. But this is a renumbering issue and not an effect of the multihoming support. Applications, which map the peer's IP address to a domain name, today perform a reverse lookup in the DNS (e.g., using the getnameinfo() API). This proposal doesn't add or subtract to the benefits of performing such reverse lookups. Applications which today either retain a peer's IPv6 address for future use, such as connecting back to that peer ("callbacks"), or pass a peer's IPv6 address to a third party ("referrals") will not break with this multihoming support; they will end up retaining and/or passing the AID instead of an IPv6 address. Since the AID is a locator things will still work as long as that locator is reachable. However, the AID doesn't contain information whether the host is M6 capable, thus the callbacks and referrals would use IPv6 without multihoming support unless something special is done. To be able to take advantage of the multihoming support the application or host would need to detect whether the AID is M6 capable, for instance, by doing a reverse lookup on the AID to get the FQDN and the a forward lookup on the FQDN to look for the "M6 capable" DNS RR. An alternative would be to use the suggestion in Section 5.2 to send an INIT message to the peer to discover if it is M6 capable. Also, should the locator which is the AID not be reachable, the application/host will fail to communicate with the peer. A reverse plus forward lookup of the AID, or the INIT suggestion, can be performed to discover all the locators. draft-nordmark-multi6-noid-02.txt [Page 41] INTERNET-DRAFT Multihoming without IDs July 7, 2004 Whether these lookups can be hidden from the application, or whether the applications need to be modified to make the callbacks and referrals take full advantage of the multihoming is for further study. 10. CHECKSUM ISSUES The IPv6 header does not have a checksum field; the IPv6 address fields are assumed to be protected by the ULP pseudo-header checksum. The general approach of an M6 shim which replaces locators with identifiers (where only the identifiers are covered by the ULP checksum) raises the potential issue of robustly handling bit errors in the address fields. With the definition of the M6 shim there can be undetectable bit errors in the flow label field or the nexthdr field which might adversely affect the operation of the protocol. And since the AIDs are what's covered by the ULP's pseudo-header checksum the locators in the address fields are without checksum protection. An undetected bit error in the source locator would look like an unverified source locator to the receiver. In this proposal such packets are silently ignored. Except for the obscure case when Ls(A) contains multiple locators, one or more of those are not working, and the bit error causes L1(A) to be replaced by L2(A). That would make the return traffic go to L2(A), but that might be a non-functioning locator. In this case the mistake will be corrected when a subsequent packet is received from A. An undetected bit error in the destination address field is also harmless; it might cause misdelivery of the packet to a host which has no context but when the peer receives any resulting Unknown Context error message, it will not contain a source locator which is in the peer's locator set, hence it will be silently ignored. An undetected bit error in the IPv6 next header field can potentially make a M6 packet appear as a non-M6 packet and vice versa. This isn't any different than undetected bit errors in IPv6 next header field without multihoming support. An undetected bit error in the flow label in a data message could have two possible effects: not finding any context state, or finding the incorrect context state. In the first case any Unknown Context error message would be dropped by the peer since the flow label included in the error message doesn't match the flow label that was draft-nordmark-multi6-noid-02.txt [Page 42] INTERNET-DRAFT Multihoming without IDs July 7, 2004 originally sent. In the second case this will result in a packet with incorrect identifiers being delivered to the ULP which most like will drop it due to ULP checksums not matching. 11. IMPLICATIONS FOR PACKET FILTERING Ingress filtering should be replaced by locator rewriting when the "rewrite ok" bit is set. Locator rewriting (when the bit is set) can be applied at places where ingress filtering isn't currently performed (e.g., due to multihoming issues). Firewall filtering potentially require modifications to be aware of M6. All the packets contain locators thus a stateful firewall would need to be aware of the context state to let the correct packets through as locators might change during some communication/connections. Such firewalls could optionally perform their own verification by issuing DNS lookups the same way as the endpoint. However, the firewalls probably has to be more careful not exposing themselves to DoS attacks by doing too much DNS lookups. 12. IPSEC INTERACTIONS As specified, all of ESP, AH, and key management is layered above the M6 layer. Thus they benefit from the stable AIDs provided above the M6 layer. This means the IPsec security associations are unaffected by switching locators. The alternative would be to layer M6 above IPsec, but that doesn't seem to provide any benefits. Since we want to allow routers performing locator rewriting it wouldn't be possible to take advantage of for instance AH to protect the integrity of the IP headers. A result of layering M6 above IPsec is that the M6 protocol can potentially be used to redirect IPsec protected traffic as a selective DoS mechanism. If we somehow could require IPsec for the M6 protocol packets when the ULP packets between the same hosts use IPsec, then we could prevent such attacks. However, due to the richness in IPsec policy, this would be a bit tricky. If only some protocols or port numbers/selectors are to be protected by IPsec per a host's IPsec policy, then how would one draft-nordmark-multi6-noid-02.txt [Page 43] INTERNET-DRAFT Multihoming without IDs July 7, 2004 determine whether M6 traffic needs to be protected? Should one take the conservative approach that if any packets between the hosts/AIDs need to be protected, then the M6 traffic should also be protected? For this to be useful both communicating hosts would need to make the same policy decisions, so if we are to take this path there would need to some standardization in this area. 13. SECURITY CONSIDERATIONS This analysis is far from complete. Early analysis indicates this addresses the issues in [M6THREATS]. Just as in today's Internet hosts on the path can inject bogus packets; in this proposal they need to extract the flow labels from the packets in order to do this which wouldn't be hard. Packet injection from off-path places becomes harder since it requires guessing the 20 bit flow label together with locators that are in the locator sets. If ingress filtering is deployed the attacker might not be able to freely choose the source locator, thus just as in today's Internet ingress filtering further limits attackers ability to inject packets with spoofed source addresses. An attacker can inject bogus Update Request messages by picking random flow labels and locators, in an attempt to make the communication break or make it use less locators. Worst case this can cause the communication to drop down to only using the AIDs and no other locators. Such an attacker needs to know the AID pair and guess the flow label pair for the attack to be successful. Guessing a total of 40 bits of flow labels would be hard for an off-path attacker. One could make this even harder by, in addition to the flow labels, have the context establishment exchange some larger random numbers between the peers, and using those numbers to compute a HMAC on the Update Request. This would still be subject to Man- in-The-Middle attacks for on-path attackers, but it would make it a lot harder for off-path attackers to hit something with random packets. An attacker can inject bogus Unknown Context messages. The protection against this is a locator and flow label match as well as hitting the relatively small window of acceptable Birthday Counters. In addition, the receiver will reject Unknown Context messages if the included payload packet was not a packet that it might have recently sent. DNS verification implications TBD. draft-nordmark-multi6-noid-02.txt [Page 44] INTERNET-DRAFT Multihoming without IDs July 7, 2004 14. PRIVACY CONSIDERATIONS The existence of mappings in the DNS from any locator to a FQDN and from the FQDN to all the locators of a host can potentially make it harder than in today's Internet for a host that is part of a multihomed site to be anonymous. This is especially true if the host wants to take advantage of RFC 3401 temporary addresses, or if the host is moving between different subnets since the forward and reverse information would need to be updated. Thus a host which is in a multihomed site which desires to have multiple pseudonyms and use the M6 protocol would need to, not only have multiple locators per prefix (as in RFC 3041), but also have multiple FQDNs each FQDN corresponding to a separate set of locators. Note that hosts that communicate with peers that are multihomed are not required to have a FQDN to take advantage of the multiple locators of the peer, hence they can retain the same amount of pseudonyms as with RFC 3041. 15. DESIGN ALTERNATIVES Several aspects of the protocol can be tweaked while following the original idea of using a set of locators as an equivalence set and using the DNS to verify the set membership. A few to consider are listed in this section. 15.1. Avoid introduction of M6 DNS Resource Record type It is possible to avoid introducing a new resource record type to indicate whether a peer is M6 capable. Instead one of the M6 packets can be used. For instance, a host can send an INIT message to the peer and if the host receives a response it knows the peer is M6 capable. This potentially has some performance implications, hence it would be desirable to structure the use of the protocol slightly differently. For instance, if the peer is not M6 capable it is useful if the INIT message would result in an ICMP error being returned. As currently specified, with the M6 messages being an informational ICMP type, no such error message will be returned. Thus it would be better if the M6 messages were instead defined to be a separate new payload type so draft-nordmark-multi6-noid-02.txt [Page 45] INTERNET-DRAFT Multihoming without IDs July 7, 2004 that hosts which do not implement the protocol respond with an ICMPv6 "payload type unknown" error. If the initiator doesn't know whether the peer supports M6 or not, it would seem better to not piggyback a ULP packet on the INIT message but instead send any ULP packet separately. Since this might be suboptimal when the peer does support M6, it would be useful for the host to cache which AIDs/FQDNs support M6 so it can use piggybacking in that case. And since sending the INIT message over and over to a host which doesn't support M6, it would also be useful for the host to cache which AIDs/FQDNs do not support M6 so that it can skip trying an INIT message when it has already tried once. 15.2. Extension header instead of using flow label Use an actual extension header for M6 and use a context tag in that header instead of using the flow label. This would make the packets 8 bytes larger since the minimum extension header size is 8 bytes due to the alignment rules for extension headers in IPv6. With an 8 byte extension header one could fit - 8 bits of next header value - 16 bits of checksum (over the extension header only) [TBD: is this useful?] - 1 bit to indicate that it is a M6 data packets (other M6 packets would have e.g. a 8 bit message type instead) - 39 bits of context tag As a result one would only need to allocate 2 protocol values instead of the 16 suggested in Section 6: One protocol value for "M6 - rewrite ok" and one value for "M6 - no rewrite". The data messages could look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Nexthdr |0| Context Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Tag (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-nordmark-multi6-noid-02.txt [Page 46] INTERNET-DRAFT Multihoming without IDs July 7, 2004 M6 control messages could look like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Nexthdr |1| Message Type| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 15.3. Explicit close exchange Instead of relying on the Unknown Context error to try to synchronize when one has garbage collected the context state and the other end has not, we could define an explicit close exchange. An early attempt at this is specified in Appendix A. This approach would remove any DoS concerns related to responding to Unknown Context errors. 16. OPEN ISSUES Either we need to specify an upper lifetime of a context after no packets have been received on the context, or we need to adopt a close handshake akin to the example in Appendix A. This need arises because the logic for the birthday counter needs to know how many times a peer can reboot while the host maintains an old context with that peer; this number determines the window of allowed birthday counter values for the Unknown Context error. Which DNS errors should be treated as temporary vs. permanent? Does it make sense to establish a larger context tag for each direction in addition to the flow label, so that Update Request messages and Close messages can be less subject to random packet injection? Is it possible to facilitate transition to M6 using some "M6 proxy" at site boundaries until all important hosts in a site have been upgraded to support M6? Would would be the properties of such a proxy? Would it place any additional requirements on the protocol itself? Would destination locator rewriting be a useful way for the routing system to pass some information to the host? Or is source locator rewriting sufficient? draft-nordmark-multi6-noid-02.txt [Page 47] INTERNET-DRAFT Multihoming without IDs July 7, 2004 Understanding the performance of DNS verification with and without DNSsec. With DNSsec how many public key signature verifications are likely to be needed for the reverse lookup of each locator? How does the use of the last verified source locator as a destination locator for subsequent return traffic interact with ingress filtering? It would be nice if the protocol could operate with uncoordinated ingress filtering between the different exits/ISPs, but it is unclear whether this is feasible. 16.1. Renumbering Considerations Need to write down any special coordination needed when a locator is added to a locator set or when one is removed; this can happen when a site is renumbered. 16.2. Initiator Confusion vs. "Virtual Hosting" When A wants to communicate with host B and host X at the same time there can be some confusion since the DNS could return partially overlapping locator sets for the two remote hosts. For example, The lookup of FQDN(B) returns Ls(B) which contains L1(B), L2(B), ... Ln(B). The lookup of FQDN(X) returns L1(B), L1(X) The result is that connections that could be intended to go to B and to X could both end up with an AID=L1(B), but the multihoming shim layer would have two separate locator sets associated with L1(B). Thus at a minimum when the second of the two communications starts there has to be some way to resolve this conflict. In Section 4.1 this is resolved by the initiator performing a reverse lookup on the AID. Thus looking up L1(B) in the ip6.arpa tree in the above example. That works because it would return FQDN(B) thus X could be safely declared as being bogus. As a result communication with X would not be possible. However, in many (IPv4) hosting setups today multiple domain names (www.foo.com, www.bar.com) are served by a single IP address. In this case the reverse lookup can't point back at both names unless the PTR resource record contains multiple records with different names. Per [RFC2181] section 10.2 this is allowed but it doesn't appear to be commonly used. Can we depend on this little used feature of the PTR usage? If not it would seems to mean that each locator can only be used with one draft-nordmark-multi6-noid-02.txt [Page 48] INTERNET-DRAFT Multihoming without IDs July 7, 2004 FQDN which would be more restrictive than we have with IPv4 today. 17. ACKNOWLEDGEMENTS The first version of this document was the result of discussions in a MULTI6 design team but is not the "product" of that design team. The scribe wishes to acknowledge the contributions of (in alphabetical order): Iljitsch van Beijnum, Brian Carpenter, Tony Li, Mike O'Dell, and Pekka Savola. The idea to allow locator rewriting by routers was first presented by Mike O'Dell [ODELL96]. The techniques for avoiding state DoS attacks on the first packet are patterned after [MIPv6]. The idea to use a set of locators and not inventing a new identifier name space, as well as using the DNS for verification of the locators, was first brought up by Tony Li. Later versions of the document have benefited from the comments of many participants in the Multi6 WG. 18. REFERENCES 18.1. Normative References [M6THREATS] Nordmark, E., and T. Li, "Threats relating to IPv6 multihoming solutions", draft-ietf-multi6-multihoming- threats-00.txt, July 2004. [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 Addressing Architecture", RFC 3513, April 2003. [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2461. [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. 18.2. Informative References [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the NSRG", draft-irtf-nsrg-report-09.txt (work in progress), March 2003. [MIPv6] Johnson, D., C. Perkins, and J. Arkko, "Mobility Support in draft-nordmark-multi6-noid-02.txt [Page 49] INTERNET-DRAFT Multihoming without IDs July 7, 2004 IPv6", RFC 3775, June 2004. [AURA02] Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", draft-aura-mipv6-bu-attacks-01 (work in progress), March 2002. [NIKANDER03] Nikander, P., T. Aura, J. Arkko, G. Montenegro, and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", draft-nikander-mobileip-v6-ro-sec-02 (work in progress), June 2003. [ODELL96] O'Dell M., "8+8 - An Alternate Addressing Architecture for IPv6", draft-odell-8+8-00.txt, October 1996, [MAST] D. Crocker, "MULTIPLE ADDRESS SERVICE FOR TRANSPORT (MAST): AN EXTENDED PROPOSAL", draft-crocker-mast-protocol-01.txt, October, 2003. [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [IPv6-SA] R. Atkinson. "Security Architecture for the Internet Protocol". RFC 2401, November 1998. [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402, November 1998. [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2181] R. Elz, and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC3697] J. Rajahalme, A. Conta, B. Carpenter, S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. [RFC2894] M. Crawford, "Router Renumbering for IPv6", RFC 2894, August 2000. [RFC3041] T. Narten, R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [HIP] Robert Moskowitz, "Host Identity Protocol", 11-Jun-04, [WIMP] Jukka Ylitalo, "Weak Identifier Multihoming Protocol (WIMP)", July 2004, draft-nordmark-multi6-noid-02.txt [Page 50] INTERNET-DRAFT Multihoming without IDs July 7, 2004 19. CHANGE LOG Changes since version -01: o Made the protocol allow for locator rewriting of all the M6 control messages. o Allow for hosts without a FQDN or without a correct forward+reverse relationship benefit from the peer being multihomed. o Handle inconsistencies between the DNS and host configuration, e.g. due to two-faced DNS or DNS-based load balancing, by having the host tell its peer what it received from the DNS and use the intersection of the DNS info and the info known by the host itself. o Removed the probability of DNS inconsistencies resulting in packets being dropped due to having an unknown source locator; a host informs its peer which locators should be acceptable as source addresses while the destination locators continue to be verified in the DNS. o Changed the context establishment to start with an INIT message from the Initiator instead of having the establishment be driven by a message with an unknown flow label arriving at a host. This allows the Initiator to decide when to establish the context; before the context is established "regular" packets can be exchanged as long as the locators used are the AIDs. o Renamed the messages to have the same names as in WIMP; INIT/CC/CCR/CONF o Simplified the uniqueness requirements for the flow label to be "unique per receiving host" in order to handle dynamic changes (driven from the DNS) of the set of locators assigned to a host. Without this change it was impossible to make the flow label plus locators uniquely identify a context at the receiver when the set of locators changes over time (e.g., due to renumbering). This limits each (virtual) host to about 1 Million contexts at any given time. Removing this limitation would imply carrying a larger context tag in an extension header, which is a possible tweak to this protocol. o The simplified uniqueness requirement resulted in needing receiver instead of sender allocation of the flow label, which in turn resulted in the initiator sending the first message (the INIT) in the context establishment exchange. o Made it possible to allow locator rewriting on the context establishment messages, while allowing piggybacking of ULP packets. draft-nordmark-multi6-noid-02.txt [Page 51] INTERNET-DRAFT Multihoming without IDs July 7, 2004 However, in some cases when locators are being rewritten, ULP packets can not be piggybacked until the context is established, to avoid security exposure. o Added details of how the host-pair context is established when both ends initiate the setup at the same time. o Worked out the details for how messages are retransmitted. As a result, the 4th message in the establishment exchange needs to be mandatory to ensure that the initiator always knows the correct flow label to use in transmitted packets. Thus the 3-way context establishment exchange becomes a 4-way exchange as in [HIP] and [WIMP], with the ability to piggyback ULP packets on all those messages. o As a result of needing a 4-way exchange there is no longer any benefit in attempting a provisional allocation of a flow label when receiving the INIT. Hence the responders flow label allocation is now done when receiving the CCR message. o Added details about how the host-pair context state could be removed in a coordinated fashion in Appendix A. o Added details on state recovery when one end has lost the peer's host-pair context state, using a birthday counter as in [HIP] o Added a suggestion on how one can avoid introducing a new M6 DNS Resource Record type. o Renamed "flowid" to correctly be "flow label" APPENDIX A: CONTEXT CLOSE PROTOCOL This scheme is robust against arbitrary network partitioning and loss, whether in both directions or in one direction, through the use of timers plus new CLOSE and CLOSEACK messages. It introduces one additional state in the state machine: o CLOSING: about to go away but the state is retained to be able to reliably inform the peer that the state is being removed. No data packets can be sent using the context when in closing state, but otherwise it is the same as ESTABLISHED state. The underlying observation is that the network doesn't spontaneously generate packets, thus for a packet to be received it must have been draft-nordmark-multi6-noid-02.txt [Page 52] INTERNET-DRAFT Multihoming without IDs July 7, 2004 sent by the peer, and if the host does not send a packet no packet will be received by the peer. (But packets might be sent and never received.) In the basic analysis we assume that the network delay (propagation and queuing) is zero, that is, a packet is received by the peer either immediately when sent, or never (in the case of loss). The mechanism uses a time constant: X minutes. The mechanism works as follows: 1. When no packet has been received on the context for X minutes the context transitions to CLOSING state. A CLOSE message is transmitted to the peer. When in CLOSING state the host must not send any data packets using the context. If there is a need to send a data packet a new context must be created by starting by sending an INIT. 2. When the host receives a CLOSE message it discards the context state and responds with a CLOSEACK message. (The authenticity of the CLOSE message can be verified the same way data messages are verified, that is, the flow label needs to match and the locators be in the locator sets.) This processing applies whether or not the state is CLOSING in order to handle CLOSE messages from both ends crossing in flight. Once the context state has been discarded any need to send data packets will trigger establishing a new context, starting with sending an INIT. 3. A CLOSE message which is received when there is no context state can not be verified but will result in a CLOSEACK response to speed up the peer discarding the state in the presence of packet loss. 4. The CLOSE message is retransmitted until either a CLOSEACK message is received, or it has been retransmitted for a total of X minutes. When either occurs the context state is discarded. 5. When a host receives a CLOSEACK message it verifies that it is in CLOSING state and that the CLOSEACK was in response to the CLOSE (using e.g., a nonce in the CLOSE message). It is possible to use stronger verification of the CLOSEACK based on secrets tied to the context state, but only for the first CLOSE message since the state is discarded on its draft-nordmark-multi6-noid-02.txt [Page 53] INTERNET-DRAFT Multihoming without IDs July 7, 2004 reception. Thus if the CLOSEACK response to the first CLOSE is lost, the host would need to wait for the full X minutes until discarding its state. Due to packet loss the two sides can have different views of when the last packet might have been sent, but because no received packets in X minutes causes a state transition, this difference can not be larger than X. Since the CLOSE messages are retransmitted for X minutes (during which the peer can not possibly receive any data packets) the peer will transition to CLOSING and stop sending data packets before the host will discard its state. Example 2 shows a case when this happens. Example 1: working communication in both directions Time T: A sends a packet to B. While A doesn't know it yet, this is the last packet A will send using the context. B continues to send packets to A. Time T+X: B has not received any packets from A for X seconds. B marks the context as CLOSING, that is, it will not use the state to transmit any more. B sends a CLOSE message to A. Time T+X: A receives a CLOSE message from A. Discards the context state and responds with a CLOSEACK message. Time T+X: B receives the CLOSEACK message and discards the context state. Example 2: Unidirectional failure; A->B packets are all dropped. Time T: A sends a packet to B. While A doesn't know it, this is the last packet B will receive from A. Time T+1 etc: A sends a packet to B which is lost. Time T+X: B has not received any packets from A for X seconds. B marks the context as CLOSING, that is, it will not use the state to transmit any more. B sends a CLOSE message to A. Time T+X: A receives a CLOSE message from A. Discards the context state and responds with a CLOSEACK message. The CLOSEACK message is lost. Time T+X+1 etc: B retransmits the CLOSE message. Time T+X+1 etc: A receives the CLOSE message, has no context state, draft-nordmark-multi6-noid-02.txt [Page 54] INTERNET-DRAFT Multihoming without IDs July 7, 2004 and responds with a CLOSEACK message. The CLOSEACK message is lost. Time T+2X: B stops retransmitting the CLOSE message and discards the session state. Example 3: Bidirectional failure; all packets are dropped. Time T1: A sends a packet to B. While A doesn't know it, this is the last packet B will receive from A. Time T2: B sends a packet to A. While B doesn't know it, this is the last packet A will receive from B. Time T1+1 etc: A sends a packet to B which is lost. Time T2+1 etc: B sends a packet to A which is lost. Time T1+X: B has not received any packets from A for X seconds. B marks the association as CLOSING, that is, it will not use the state to transmit any more. B sends a CLOSE message to A. The CLOSE message is lost. Time T2+X: A has not received any packets from B for X seconds. A marks the association as CLOSING, that is, it will not use the state to transmit any more. A sends a CLOSE message to B. The CLOSE message is lost. Time T1+X+1 etc: B retransmits the CLOSE message, which is lost. Time T2+X+1 etc: A retransmits the CLOSE message, which is lost. Time T1+2X: B stops retransmitting the CLOSE message and discards the session state. Time T2+2X: A stops retransmitting the CLOSE message and discards the session state. Since the difference between T1 and T2 can't be more than X, we know that the session state can not be discarded before the other end has transitioned to CLOSING. The above examples generalize to arbitrary packet loss; in no case will a data packet be received when there is no association state. Hence data packet that are received and have no matching session state can be silently dropped; no need to send an Unknown Context error or an INIT message. Intuitively it seems like network delays can be handled to make the period for the retransmission of the CLOSE message be X+MSL (Maximum draft-nordmark-multi6-noid-02.txt [Page 55] INTERNET-DRAFT Multihoming without IDs July 7, 2004 segment lifetime) instead of X, but this needs to be verified. The introduction of the close mechanism adds some considerations to the state machine. For instance, if an INIT arrives when in CLOSING state, the INIT would need to create a separate, new context, which has different flow labels at both ends. That way the context in CLOSING state is allowed to expire based on timeout or receiving a Close Acknowledgement message, in parallel with the new context being created. This means that there might be more than one context for the same AID pair. This has the following implications: o When handling packets passed down from the ULP, the M6 layer should not match any contexts in CLOSING state, but instead behave as if there was no context even when there is a context in CLOSING state. [TBD: It might be useful to copy certain information from the context in CLOSING state to the new context.] o The context establishment packets (INIT, CC, CCR, and CONF) should also ignore any context in CLOSING state. o Data packets received from the wire identify which context to use with the flow label field. o M6 control packets that are sent after the context is established needs to be able to indicate which of possibly multiple contexts are intended. As a result, the Update Request, Update Acknowledgement, Close and Close Acknowledgement messages carry both flow labels which are used to identify the state. AUTHORS' ADDRESSES Erik Nordmark Sun Microsystems, Inc. 17 Network Circle Mountain View, CA USA phone: +1 650 786 2921 fax: +1 650 786 5896 email: erik.nordmark@sun.com Intellectual Property Statement 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 draft-nordmark-multi6-noid-02.txt [Page 56] INTERNET-DRAFT Multihoming without IDs July 7, 2004 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 implementors 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. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. draft-nordmark-multi6-noid-02.txt [Page 57]