INTERNET-DRAFT Erik Nordmark Oct 27, 2003 Sun Microsystems Strong Identity Multihoming using 128 bit Identifiers (SIM/CBID128) Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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 April 27, 2004. Abstract This document contains a rough outline of a potential solution to IPv6 multihoming in order to stimulate discussion. This proposed solution uses 126 bit identifiers which are hashes of public keys (know as Cryptographically-based Identifiers) which are created in an autonomous fashion by every host. When there is a need to verify whether a new locator should be used with an identifier than a public-key based challenge-response is used. The proposal allows locator rewriting by (border) routers, and ensures that the upper layer protocols can operate unmodified in a multihomed setting using the stable identifiers. draft-nordmark-multi6-sim-01.txt [Page 1] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 Contents 1. INTRODUCTION............................................. 3 1.1. Non-Goals........................................... 3 1.2. Assumptions......................................... 4 2. TERMINOLOGY.............................................. 4 2.1. Notational Conventions.............................. 5 3. PROTOCOL OVERVIEW........................................ 6 3.1. Host-Pair Context................................... 8 3.2. Message Formats..................................... 9 4. PROTOCOL WALKTHROUGH..................................... 12 4.1. Initial Context Establishment....................... 12 4.2. Locator Change...................................... 13 4.3. Handling Locator Failures........................... 14 4.4. Locator Set Changes................................. 15 4.5. Preventing Premeditated Redirection Attacks......... 15 5. HANDLING STATE LOSS...................................... 17 6. APPLICATION USAGE OF IDENTIFIERS......................... 18 7. COMPATIBILITY WITH STANDARD IPv6......................... 19 8. CHECKSUM ISSUES.......................................... 20 9. IMPLICATIONS FOR PACKET FILTERING........................ 21 10. IPSEC INTERACTIONS...................................... 22 11. SECURITY CONSIDERATIONS................................. 22 12. OPEN ISSUES............................................. 23 12.1. Initiator Confusion vs. "Virtual Hosting".......... 24 13. FUTURE WORK............................................. 25 14. ACKNOWLEDGEMENTS........................................ 26 15. REFERENCES.............................................. 26 15.1. Normative References............................... 26 15.2. Informative References............................. 27 AUTHORS' ADDRESSES........................................... 28 draft-nordmark-multi6-sim-01.txt [Page 2] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 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 crypto-based identifiers [CBID] properties 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 [M6SEC]. o Allow routers rewriting the (source) locators as a means of quickly detecting which locator is likely to work for return traffic. o Minimal per-packet overhead. o No extra roundtrip for setup through optional piggybacking. o Take advantage of multiple locators 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 introduces an IP layer identifier, but it does not make this identifier a first class object. In particular, there is no method for taking a identifier and using it to lookup other information (FQDN, set of locators, etc) about the identified entity. Even with this limitation the introduction of the identifier is quite draft-nordmark-multi6-sim-01.txt [Page 3] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 useful in identifying the a host. See discussion in the section on future work how it might be possible to add a lookup function over time. 1.2. Assumptions The main technical assumptions this proposal makes is that using public key signatures during the more uncommon operations would provide acceptable performance. The proposal doesn't require such operations during normal communication; only when a locator changes for a host will it need to be verified before return traffic will be sent to that locator, or when two hosts claim to use the same identifier. Another assumption is that where DNS is already used (normally at the initiating end of communication) it is acceptable to lookup the identifier of the peer in the DNS in addition to the current AAAA lookup (of the addresses/locators). 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. draft-nordmark-multi6-sim-01.txt [Page 4] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 Application identifier (AID) - The 128 bit quantity used by upper layer protocols for identifying a peer. In this proposal the AID=ID i.e. an IP layer identifier. This is used for pseudo-header checksum computation and connection identification in the ULP. 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. Ls(A) is the locator set for A, which consists of L1(A), L2(A), ... Ln(A). ID(A) is an application ID for A. ID(A) is a 128 bit number consisting of two fixed bits (e.g., 10) followed by 126 bits of a truncated SHA1 hash of a public key that the host has generated. CT(A) is a 64 bit "context tag" allocated by A and used when B sends packets to A. The packets contain the low-order 32 bits of the tag, named CT32(A). The full tag is used for DoS-attack prevention during the PK challenge/response. draft-nordmark-multi6-sim-01.txt [Page 5] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 3. PROTOCOL OVERVIEW In order to prevent redirection attacks this protocol relies on the ability to verify (using public key crypto as in [CBID]) that the entity requesting redirection indeed holds the private key where the hash of the corresponding public key hashes to the ID itself. The initiator of communication, where it uses DNS today to lookup FQDN->addresses, will instead lookup both FQDN->identifier (probably using some new DNS RR type) and FQDN->locator set (using AAAA resource records). The existence of the identifier RR for the name is an indication that the node supports multihoming. ----------------------- | 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. The M6 layer corresponds to an extension header which is the minimum 8 octets for data packets but larger for the messages used to establish the state at the two ends and perform the public key challenge response exchanges. In addition to carrying data packets, the M6 protocol has three message types to perform a 3-way handshake to establish state at the two ends, two message types to perform a challenge request/response exchange when a new locator is introduced, and finally a single message type to signal that state has been lost. 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 draft-nordmark-multi6-sim-01.txt [Page 6] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 paths, hence potentially different source locators, for different fragments. 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. 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. Instead we allocate two next header values for M6; one which means "rewrite ok" and one which means the rewrite should not be performed by routers. Applications and upper layer protocols use IDs 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 IDs 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. ---------------------- ---------------------- | Sender A | | Receiver B | | | | | | ULP | | ULP | | | src ID(A) | | ^ | | | dst ID(B) | | | src ID(A) | | v | | | dst ID(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 IDs and locators being present in every packet, but with a header compression draft-nordmark-multi6-sim-01.txt [Page 7] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 mechanism applied that removes the need for the IDs once the state has been established. As we will see below the context tag will be used akin to a "compression tag" i.e., to indicate the correct context to use for decompression. The use of the context tag allows the receiver to find the correct context without relying on the locators in the packet. 3.1. 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 3-way handshake. Both hosts later update the peer locators based on the source locator in received packets after having verified the new locator using a challenge exchange. The context state contains the following information: - the peer ID; ID(peer) - the local ID; ID(local) - the set of peer locators; Ls(peer) - for each peer locator, a bit whether it has been verified for return traffic using a PK challenge. - the preferred peer locator - used as destination; Lp(peer) - the set of local locators; Ls(local) - the preferred local locator - used as source; Lp(local) - the context tag used to transmit packets; CT(local) - the context to expect in receive packets; CT(peer) - State about peer locators that are in the process of being verified in using challenge/response. 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 draft-nordmark-multi6-sim-01.txt [Page 8] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 CT32(local) that is used to identify at most one state record. At the initiating end it is possible that the DNS lookup of different FQDNs return the same ID and different locator sets. This is discussed in section 4.1 and 12.1. The receiving end allocates the context tags thus it can trivially ensure that the CT32(local) is unique. 3.2. Message Formats The base M6 header is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Type | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M6 Fields: Next Header 8-bit selector. Identifies the type of header immediately following the M6 header. Uses the same values as the IPv4 Protocol field [RFC-1700 et seq.]. Type 8-bit field. The type of M6 message. The M6 header carries 7 different message types: o Data message; to be passed to the ULP after replacing the locators with the identifiers. o Context request message; first message of the 3-way context establishment. An ULP packet can be piggybacked on this message. o Context response message; second message of the 3-way context establishment. An ULP packet can be piggybacked on this message. o Context confirm message; third message of the 3-way context establishment. An ULP packet can draft-nordmark-multi6-sim-01.txt [Page 9] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 be piggybacked on this message. o Challenge request message; first message of the 2-way challenge. o Challenge response message; second message of the 2-way challenge. o Unknown context message; error which is sent when no state for context tag. Checksum The Internet checksum applied to the IPv6 address fields and the M6 header. When computing the checksum the checksum field is set to zero. Future versions of this protocol may define message types. Receivers MUST silently ignore? Reject? [TBD] any message type they do not recognize. The M6 data message is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Type = 0 | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M6 Fields: Context Tag 32-bit field. Identifies the context at the receiver. This drafts doesn't contain actual message layout for the other M6 message types. However, the content of these messages is specified below. The Context request message contains: - Sender Nonce - Sender ID - Receiver ID - Sender context tag (64 bits) draft-nordmark-multi6-sim-01.txt [Page 10] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 The Context response message contains: - Receiver Nonce (copied from Sender Nonce in request) - Context state consisting of: the two IDs, the two context tags, and the initial locators - A timestamp or nonce (for sender's benefit) - A hash over the context state and timestamp (to prevent modification) The Context confirm message contains: - The context state, timestamp/nonce, and hash copied from the context response. The Challenge request message contains: - Sender generated nonce/timestamp - The two IDs - The 32-bit context tag from the received data message - The source locator from the received data message The Challenge response message contains: - The nonce/timestamp from the challenge request - The 32-bit context tag (from the challenge request) - The above locator - A hash value (H2) which proves that the sender knows the full 64 bits of both the context tags. This allows the receiver of the response to avoid verifying the PK signature generated by a host which can't be the original peer. - The public key of the sender. - The public key signature of all of the above fields. The Unknown context message contains: - The 32 bit context tag in the triggering data message. draft-nordmark-multi6-sim-01.txt [Page 11] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 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. The lookup is both for the new ID records and the AAAA records. If no ID record then the peer is a standard IPv6 host and the set of AAAA records is returned to the application as today. If an ID record is found then only that record is returned to the application. The ID and AAAA content is passed to the M6 layer on the host as ID(B) and Ls(B). To make sure that the lookup from ID(B) returns a single state record in the M6 layer there has to be a check if there is already a record for that ID with a different Ls. One could envision sending a PK challenge to the locators to resolve such a conflict. See section 12.1 for more discussion. 2. The ULP creates "connection" state between ID(A) and ID(B) and sends the first packet. ID(A) was picked using regular source address selection mechanisms. 3. The leading two bits of the destination address (10) makes the transmit side go through M6 processing. The M6 layer matches on ID(B) and finds the proto-context state containing Ls(B) created in step 1. The fact that the context state isn't complete triggers context creation. 4. A picks a random Nonce to include in the Context Request message. A picks pseudo-random 64-bit context tags (CT(A)) and checks for duplicates against existing context state records until it finds a unique one. The nonce and CT(A) are saved in the context state. Then A sends the context request message to one of B's locators. The data packet (TCP SYN or whatever) can be piggybacked on the context request message. The "rewrite ok" bit is set in the header. 5. The M6 layer on B receives context request message. It does not find any context state for the pair of IDs. It forms the 64-bit pseudo-random CT(B) and checks it against duplicates for existing contexts. (It can't check against other contexts in progress of being created since it doesn't create any state until the context confirm is received. Hence the duplicate check is redone on the context confirm.) It forms a keyed hash (using K(B) which is never shares with anybody) of the context state and a timestamp. Then puts the state, timestamp and hash draft-nordmark-multi6-sim-01.txt [Page 12] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 in the context response message. If there was a piggybacked packet on the context request message then B passes packet to ULP after putting the identifiers in the IP address fields. The ULP sees a packet identified by ID(A), ID(B). 6. The M6 layer on A receives the context response message. It looks up the state using CT32(A). It verifies that the stored nonce matches the echoed nonce in the message. It records the source address field in as Lp(peer). It sends back a context confirm message containing what was in the response message. If there was a piggybacked packet on the context response message then A passes packet to ULP after putting the identifiers in the IP address fields. The ULP sees a packet identified by ID(A), ID(B). 7. The M6 layer on B receives context confirm message. It looks up context state using CT32(B). If state is found and the identifiers are different than in the context confirm this must have been a duplicate caused by concurrent context creations in progress. Requires restarting by responding with a new context response with a different CT(B). B verifies that the timestamp is recent and then verifies that the hash over the state is correct. Then it can create the context state. If there was a piggybacked packet on the context confirm message then B passes packet to ULP after putting the identifiers in the IP address fields. The ULP sees a packet identified by ID(A), ID(B). 4.2. Locator Change This is the sequence of events when B receives a packet with a previously unknown source locator for A. 1. Host B receives a data message. Finds the context using the CT32(B) that is in the message. B passes the packet to the ULP after replacing the locators with the IDs (whether or not the source locator is known). If the source locator is in Ls(peer) and already verified then the preferred return locator (Lp(peer)) is updated to use it for draft-nordmark-multi6-sim-01.txt [Page 13] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 return packets. If the source locator is previously unknown then it is added to the context state as a Ls(peer) awaiting verification and a Challenge Request packet is generated. The challenge request includes a nonce generated by B, CT32(B) (that was received in the packet from the unknown locator), the identifiers and the previously unknown peer locator. 2. Host A receives the challenge request packet. Verifies that it has state for those identifiers with the CT32(peer) it received on the request. It computes the hash H2 to show to B that it knows both full 64 bit context tags as H2 = SHA1(nonce from request, CT(A), CT(B), ID(A), ID(B)) It includes its public key (the one whose hash is ID(A)) and signs the whole challenge response using its private key. 3. Host B receives the challenge response packet. It finds the context state using CT32(B). It verifies the nonce against what it used for sending the challenge request. It verifies H2. (Only devices on the path between A and B during the context establishment knows CT(A) and CT(B), thus this check limits DoS attacks based on forcing PK signature verification to attackers on the path.) Then it verifies that the hash of the public key equals ID(A), and finally the public key signature using that public key. 4.3. Handling Locator Failures The M6 layer is responsible for retransmitting context request messages using different locators until a contest response is received. After context setup the sender can use retransmit hints from the ULP to get the M6 layer to try a different verified locator. If one outbound path from the site fails and the border routers rewrite source locators then the peer in another site will see packets with the working source locators. Once that locator has been verified, 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. draft-nordmark-multi6-sim-01.txt [Page 14] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 Without locator rewriting one would need to add some notification e.g., by defining a new bit in the router advertisement prefixes (IMHO this is semantically different than the preferred vs. deprecated stuff), but we also need some mechanism to carry this info from the border routers to the routers on each subnet. 4.4. Locator Set Changes Should the set of locators change after the context has been established the ability to learn and verify new peer locators will handle this fine. The DNS only needs to be updated with new locators in order to allow new communication to be established. 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 start using the preferred locator(s) 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. 4.5. Preventing Premeditated Redirection Attacks The threats document [M6SEC] talks of premeditated redirection attacks that is where an attacker claims to be a host before the real host appears. This proposal is potentially subject to this threat because for performance reasons there is no public-key challenge when the context state is initially established. The following sequence shows how such a redirection attack is detected when X pretends to be A: 1. Host X with locator L1(X) sends a content request message to B. In the message it claims to have ID(A) and includes CT(X). 2. The context response and context confirm messages are exchanged resulting on B selecting CT(B) for communicating with X (which B believes has identifier ID(A)). 3. X and B happily communicate without B performing any higher- draft-nordmark-multi6-sim-01.txt [Page 15] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 level, such as IKE/IPsec, identity check on its peer. 4. Host A tries to communicate with B. It sends a context request message to B where the message claims to have ID(A) and includes CT(A). 5. Host B receives the context request and discovers it already has context state for ID(A). B doesn't do anything different than if there was no context state - the difference in processing happens when the context confirm is received - except that any piggybacked ULP packet is not passed to the ULP. Thus, as in section 4.1, a context tag is selected and the context reply is sent, which makes A send back a context confirm. 6. Host B receives the context confirm and verifies it the same way as in section 4.1. Then it looks if there is already a context for ID(A) and finds the context which contains CT(X) and L1(X). The existence of this "old" context could be due to multiple reasons: - The peer lost state while B retained the context state. In this case one would expect that the old context has not been used to receive packets for some time. (Having a protocol constant denoting the minimum time after sending a packet that state can be lost and later recreated would be helpful here.) In this case it would also be common that the source address of the packet would fall in the locator set for the old context. But it isn't impossible that a peer state loss and using a different locator happens at the same time. - The old host was performing a premediated redirection attack. - The new host is attempting a redirection attack. In all cases the approach consists of sending a challenge to both the "new" A and the "old" A. But depending on the time since packets where last received from the "old" A the order can be different. The first peer locator which responds with a valid challenge response will "win" and the other context state will be deleted. TBD: The above has DoS concerns in terms of verifying the challenge response. Having both ends remove the context state at about the same time would be beneficial since it would reduce the frequency of this happening in the absence of attacks, thus it would be more realistic to apply resource limits for this type of challenges. draft-nordmark-multi6-sim-01.txt [Page 16] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 5. HANDLING STATE LOSS The protocol needs to handle two forms of state loss: - a peer loosing all state, - the M6 layer garbage collecting state too early due to not being aware of what all ULPs do. 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 IDs to use when replacing the locators. The second case is a bit more subtle. 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 TCP), or when there is active communication (UDP packets being sent to ID(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. Independently whether the state loss was for the whole host or for just the M6 layer things can be recovered when the loss is detected as a result of receiving a packet from the peer. Should B receive a packet from some locator without being able to find any context state for the CT32(B) that is in the packet, it will send back an Unknown context message to the source. The unknown context message includes the receive tag (and it can't receive much other useful information since B has no state). The Unknown context message is sent without setting the "rewrite ok" bit since locator rewriting would make it harder for A to perform sanity checks on this error message. When A receives the Unknown context message it verifies that the draft-nordmark-multi6-sim-01.txt [Page 17] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 CT32(B) value is used by a context with the locators that are in the IP address fields, and that the source address field is Lp(peer) for the context (the preferred peer locator - to which an earlier data message would have been sent). Once this verification has been done A needs to restart the 3-way context establishment; A can reuse CT(A) for this if it so desires. As a result of this error handling mechanism an attacker on the path between A and B can send frequent Unknown context messages (but an off-path attacker cannot since it wouldn't know CT32(B)). Since state loss is expected to be infrequent it is reasonable to rate limit the handling of Unknown context messages per context to one per minute. In the case of M6 layer state loss (due to too early garbage collection) the above provides recovery when the peer transmits. But there is also the possibility that the lack of state will be detected when the ULP is passing down a packet to transmit. In this case M6 would see a packet which needs state (because the leading to bits of the address field is 10) but there is no state. Unless we invent a method (see section 14) to lookup identifiers there is nothing that can be done in that case (except perhaps wait for a while in case the peer will send a packet triggering recovery using the Unknown context message). Thus it is quite important that the context state is not discarded prematurely. TBD: If we decide to explore the approach in this proposal further, would be it useful to add APIs that allow applications to advise when it isn't and when it is ok to discard the context state for a particular id? 6. APPLICATION USAGE OF IDENTIFIERS In this proposal the upper layer protocols will operate on the identifiers. As long as the M6 layer doesn't garbage collect context state too early then those identifiers can be used by other applications on the same host; they will only become useless if none of the locators stored in Ls(peer) stop working for instance due to renumbering of the peer. But the identifier is rather useless for referrals; should B pass ID(A) to C there is no mechanism for C to find A's locators. It is only if A somehow contacts C that it can tell that it is indeed A. draft-nordmark-multi6-sim-01.txt [Page 18] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 In order to be able to use an identifier for establishing communication a host would also need a set of locators where at least one locator is still current and working. Thus with this approach, unless we defer until we have explored the future work in section 14, it would make sense to perform referrals by either passing FQDNs or by passing an ID plus the list of locators know by the referring host. One could envision a getpeerlocators() API which, given an ID, would extract the locator set from the context on the host itself. Applications which use to map the peer's IP address to a domain name today perform a reverse lookup in the DNS (e.g., using the getnameinfo() API). Since the flat identifier space can't be effectively added to the ip6.arpa tree, the getnameinfo() can instead extract the locators from the local context state. For example, this operation by B on ID(A) would find Ls(A) in the context and do a reverse lookup (presumably only on one of them); L1(A). This would be likely to return FQDN(A). Applications which today perform a forward+reverse lookup would need then lookup FQDN(A) - to find the identifier. Note that the above doesn't show that A actually is the "owner" of ID(A). One could envision providing an optional stronger verification to the applications using the CBID properties; a verification of ID(A) would extract Ls(A) and then send a challenge request to the locator. That proof of ownership of ID(A) coupled with the locator->FQDN->ID DNS looks gives stronger assurance of the identity of the peer IP layer than today. But as pointed out in [M6SEC], applications which require strong identity authentication typically also want integrity with or without confidentiality for the communication. Thus identity checks unrelated to payload cryptography might be unnecessary as a specific service to the application layer. 7. 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 ID 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 see that the leading two bits are not draft-nordmark-multi6-sim-01.txt [Page 19] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 (10) thus it will pass things through. It is an open issue whether or not it makes sense to check in an implementation that the content of the returned ID records start with binary 10 and that the content of the returned AAAA records not start with binary 10. 8. 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. This proposal as currently written has an M6 checksum field to cover the locators and the M6 header, but it isn't obvious that such a checksum is strictly required for the data packets. If there is an undetected bit error in the source address field, this would look like an unverified source locator to the receiver. Thus the packet would (after replacing locators with identifiers based on the context) be passed to the ULP and a challenge response exchange be triggered. In the case of a bit error in the locator this challenge isn't likely to receive a response; and if there is a response by someone it wouldn't be from the actual peer thus the verification would fail. Thus such an undetected bit error is harmless. Except for the obscure case when Ls(A) contains multiple verified 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 the reception of the resulting Unknown context error message will show that it arrives from the incorrect locator thus it will be ignored. draft-nordmark-multi6-sim-01.txt [Page 20] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 An undetected bit error in the M6 next header field isn't any different than for the base IPv6 next header field. An undetected bit error in the context tag in a data message could have two possible effects: not finding any context state, or finding the incorrect context state. In the first case the Unknown context error message would be dropped by the peer since the tag doesn't match the tag that was 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. NOTE: If one thinks that new peer locators could be used for return traffic without any challenge/response (e.g., relying on the hard to guess context tags), then clearly a checksum must protect against undetected bit errors causing the return packets to be sent to a bogus locator. 9. IMPLICATIONS FOR PACKET FILTERING Ingress filtering should be replaced by locator rewrite 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 locator thus a firewall would need to be aware of the context state to let the correct packets through. Such firewalls could optionally perform their own verification by issuing challenge request messages (the protocol doesn't explicitly allow for this; they would have to pretend being the actual endpoint sending the challenge). draft-nordmark-multi6-sim-01.txt [Page 21] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 10. IPSEC INTERACTIONS As specified all of ESP, AH, and key management is layered above the M6 layer. Thus they benefit from the stable identifiers 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 possible to take advantage of for instance AH to protect the integrity of the IP headers. 11. SECURITY CONSIDERATIONS This analysis is far from complete. Early analysis indicates this addresses the issues in [M6SEC]. Just as in today's Internet hosts on the path can inject bogus packets; in this proposal they need to extract the context tags 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 32 bit context tag. Hosts on the path can also launch PK signature verification DoS attacks against either end since they can observe the context tags from the establishment and therefor compute the H2 hash in the challenge response packet. This would force the endpoint to run the signature verification algorithm which is expensive. If we don't expect the locator sets to be very dynamic one could restrict the rate at which such verification takes place, at least after the first few locators have been verified for a peer. The initial setup of a host-pair context does not perform any verification using public key crypto, but this does not seem to make the result less secure than today's Internet. Applications which do not perform access control based on it's notion of the peer wouldn't care about the strength of the peer's identifier. And applications which perform strict access control hopefully do this using strong crypto (IPsec, TLS, etc) today and would continue to do so. That leaves applications which perform the questionable practise of merely verifying the forward plus reverse lookups in the DNS and then using the IP address (or resulting FQDN) for access control discussions. As discussed in section 6 the application's lookup of locator->FQDN- draft-nordmark-multi6-sim-01.txt [Page 22] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 >ID and verifying that the identifier matches provides about the same strength. [TBD are we really sure?] The CBIDs are only statistically unique. But 126 bit identifiers seems large enough to make collisions unlikely enough to keep the protocol simple. (If not one could envision complications like making the protocol capable of detecting collisions by storing the public key in the context state and seeing if a host claims to use the same ID but has a different public key.) While at about 8*10^18 hosts in the Internet there is approximately a 50% probability that there exists 2 hosts with the same 126-bit identifier this has no effect on the protocol per see. It is not until a single host has that order of magnitude of context state records that it could get confused due to collisions. 12. OPEN ISSUES Some protocol complexity is added by not performing a mutual public- key challenge immediately when a context is created. At the expensive of a performance hit one could simplify the protocol to always to these challenges. 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? One of the issues with FQDNs mapping to AAAA records is that in some cases multiple AAAA records mean a multihomed host and in other cases it means multiple hosts providing the same service. If we need to introduce a new "ID" resource record type for multihoming, would it be useful to try to make this host/service distinction more clear at the same time? An example solution would be that the ID record in addition to returning the identifier return the FQDN under which to lookup the locators. 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? With a context tag sufficiently large, what would happen to the residual threats if redirection was allowed without PK checks; either draft-nordmark-multi6-sim-01.txt [Page 23] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 by just verifying the H2 hash result (which prevents off-path attackers from redirecting) or by only verifying the correct context tag in the received packets? In that case the public key verification would only occur when there is a conflict i.e. trying to create state for an ID when context state already exists for that ID perhaps with different peer locators. The mechanisms allow adding locators to a locator set but there is currently no mechanism for removing a locator (e.g., when a host renumbers). Does it make sense to add such a mechanism? The responder only discovers the peer's locators once they are used as sources in packets. Would it make sense to allow the initiator to pass a list of its locators to the responder? (They would still need to be verified before use to prevent 3rd party DoS attacks [M6SEC]). 12.1. 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 the same identifier for B and X while returning different locator sets. For example, The lookup of FQDN(B) returns ID(B), Ls(B) The lookup of FQDN(X) returns ID(B), Ls(X) The result is that connections that could be intended to go to B and to X would both end up with the same ID at the ULP, but the multihoming shim layer would have two separate locator sets associated with ID(B). Thus at a minimum when the second of the two communications starts there has to be some way to resolve this conflict. If multiple FQDNs map to the same host, which is common in virtual hosting using IPv4 today, and the locator set is being modified for that host then this could be quite normal; looking up www.foo.com would provide the ID of the peer and a perhaps staler set of locators for the ID than looking up www.bar.com. Is it reasonable to assume when there is some overlap between Ls(B) and Ls(X) above that this is a normal condition? Should one form the intersection of Ls(B) and Ls(X) and use that for the existing context state? Or at least purge unverified peer locators, those from which the host hasn't seen a challenge response, that are not in the intersection from the locator set draft-nordmark-multi6-sim-01.txt [Page 24] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 Section 4.1 suggests using a challenge request/response exchange when the second lookup takes place. Should the challenge be performed with the newer or older locator sets? What are the DoS issues in performing such a challenge? 13. FUTURE WORK It would be desirable to explore making identifiers first class objects and having a lookup system, perhaps based on distributed hash tables, for identifiers. But there are significant scaling issues in this domain. Instead of making the identifier a hash of a host public key it could be composed in two parts (about 60 bits each): - A hash of a site public key - A hash of a host-within site certificate The certificate would be issued by using the site key. Thus the verification of a challenge response would consist of verifying that - the site public key hashes to top N bits of the ID - the host certificate hashes to the bottom 126-N bits of the ID - the host certificate is signed by the site public key - the response is signed by the host public key While this in itself isn't interesting, it would make it more feasible to use techniques like distributed hash tables to build a mapping system from IDs to locators; once (if?) we could do so the IP identifiers could become a first class object in the architecture. Doing a DHT which scales to having one entry for every IP addressable device in the Internet is less likely to be feasible than designing an DHT which only needs to scale to one entry per site in the Internet. There are several issues related to designing such a DHT such as ensuring that lookups for IDs within the same site don't depend on draft-nordmark-multi6-sim-01.txt [Page 25] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 external connectivity (and the above scheme can easily handle that), making the DHT robust against failures and malice, and making it so that those deploying hosts in the DHT benefit themselves somehow. The use of CBIDs make authorizing insertion and modification straightforward; a PK challenge using the CBID property can take care of that. 14. ACKNOWLEDGEMENTS This document has benefited from discussions with (in alphabetical order): Marcelo Bagnulo, Iljitsch van Beijnum, Brian Carpenter, Dave Crocker, Tony Li, Pekka Nikander, 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]. There are certain similarities with HIP, but the SIM design factors things so that the strength of the identifier (for "rehoming") is separate from payload protection (which can use existing techniques like IPsec). 15. REFERENCES 15.1. Normative References [M6SEC] Nordmark, E., and T. Li, "Threats relating to IPv6 multihoming solutions", draft-nordmark-multi6-threats- 00.txt, October 2003. [CBID] G. Montenegro and C. Castelluccia, "Statistically Unique and Cryptographically Verifiable Identifiers and Addresses", ISOC NDSS02, San Diego, February 2002. [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 Addressing Architecture", RFC 3513, April 2003. draft-nordmark-multi6-sim-01.txt [Page 26] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 15.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 IPv6", draft-ietf-mobileip-ipv6-24.txt (work in progress), June 2003. [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-01 (work in progress), June 2003. [PAXSON01] V. Paxson, "An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks", Computer Communication Review 31(3), July 2001. [INGRESS] Ferguson P., and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2827, May 2000. [ODELL96] O'Dell M., "8+8 - An Alternate Addressing Architecture for IPv6", draft-odell-8+8-00.txt, October 1996, [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2461. [NOID] E. Nordmark, "Multihoming without IP Identifiers", draft- nordmark-multi6-noid-00.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. draft-nordmark-multi6-sim-01.txt [Page 27] INTERNET-DRAFT Strong Identity Multihoming Oct 27, 2003 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 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. draft-nordmark-multi6-sim-01.txt [Page 28]