Internet Engineering Task Force Francis Dupont INTERNET DRAFT ENST Bretagne Expires in June 2003 January 2003 Address Management for IKE version 2 Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. This document is an Internet-Draft. 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. Distribution of this memo is unlimited. Abstract The current IKEv2 proposal [1] lacks an address management feature. As it includes a NAT traversal capability, this document extends it to a complete address management with support for NAT traversal, multi-homing and mobility. 1. Introduction In this document, the addresses used to transport IKE messages are named the "peer addresses" (term introduced by [2]). These peer addresses should no more be directly or indirectly included in identities ([3] and [4]) as it is commonly done for IKEv1. draft-dupont-ikev2-addrmgmt-00.txt [Page 1] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 NAT traversal, multi-homing and mobility should take benefit from this flexibility but the current IKEv2 draft [1] takes only account of NAT traversal in a flawed way [5]. This document describes the goals of an address management for IKEv2, including the requirements for NAT traversal, multi-homing and mobility support, and finishes by a concrete proposal. 2. Goals The goals of the address management proposed in the document can be divided in some general goals and in requirements for the three mechanisms which can change the peer addresses. 2.1 General goals 2.1.1 Simplicity, Performance and Security The address management should be as simple as possible, i.e., it should introduce minimal changes to the current IKEv2 draft [1] and each changes should be justified. The performance is an important criterion. For instance, rekeying can update the peer addresses of an IKE SA or of an IPsec SA pair, but rekeying is too expensive and a specific solution is needed. As a security protocol, IKEv2 should get a high security level. Unfortunately we already showed that the NAT traversal feature comes with a security issue (the transient pseudo-NAT attack [5]). Such problems introduced by the peer address flexibility must be described in this document and at least be mitigated by options in configurations. For instance, the NAT traversal feature should never be enabled when one knows that there can not be a NAT as in today IPv6. 2.1.4 Extensions of the IKEv2 draft The first things to fix in the current IKEv2 draft [1] are the notifications for NAT traversal (NAT-DETECTION-*-IP): - They use a hash of the SPIs, address and port, following a specification for IKEv1. This makes no sense for IKEv2. - There is no specified way to request the inclusion of these notifications in messages. - There can be multiple source notifications. IMHO this is a good idea but the rationale (the sender does not know what address it uses) is weak. The API to get the address used for UDP packets to a destination is very standard. draft-dupont-ikev2-addrmgmt-00.txt [Page 2] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 The second missing thing in the current IKEv2 draft [1] is about some misusage of the peer addresses: - At the reception of a message, the lookup of the corresponding IKE SA MUST be done using only the SPIs, never using the peer addresses. - An INITIAL-CONTACT notification deletes old IKE SAs associated to the peer Identity, not to the peer address. Current wording is misleading. - The revised identity proposal [3] should be integrated in the IKEv2 specifications. According to IAB recommendations [4], addresses should not be used as or associated to identities. Note that the last point stresses the issue of the lack of protection of peer addresses. The last thing to fix in the current IKEv2 draft [1] is the support of the proxy case: the setup of transport mode IPsec SAs on the behalf of another party. 2.2 NAT traversal requirements The NAT traversal feature is the support of en-route peer address modifications: - NATs must be detected, including their position, i.e., the receiver of an IKE message should be able to detect any peer address alteration. - The peer addresses are included in the pseudo IP header of transport checksums when a transport mode IPsec SA is used. The peers must know the original peer address of their correspondent. - When there are several VPN clients behind a NAT, the ability to request a three way handshake (a.k.a. a return routability check) is needed [6]. 2.3 Multi-homing requirements In this document, the support of multi-homing is the support of nodes with several global addresses. Some of the addresses can be "better" than others, or "better" for some destinations. Some can, from time to time, be unavailable. draft-dupont-ikev2-addrmgmt-00.txt [Page 3] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 The main requirement for the support of multi-homing is the management of a set of peer addresses for each peer. The set can be partially ordered or some subset can be loosely associated with some destinations (i.e., some subset of the other peer address set). For the communication between multi-addressed hosts, the support of the proxy case can be useful because it provides an easy way to setup transport mode IPsec SAs with different addresses from one IKE SA. In such cases the other party is in fact the same host, this dramatically simplifies the authorization issue. 2.4 Mobility requirements In the context of Mobile IPv6 ([7] and for the special case of Home Agents [8]), the interaction of Mobility and IPsec was analyzed in another document [9]. This document assumes an IPv6 context as Mobile IPv6 is the most powerful mobility proposal available today. An IPv6 mobile node is another type of multi-addressed node with: - a care-of address in a prefix of the visited link. The care-of address is used to route packets. - the home address in a prefix of the home link. The home address is used to identify the mobile node. The care-of address is transient and usually the mobile node can not provide a proof that it is the node using it. So it must be trusted and a return routability check (i.e., an enforced answer from this address) should be used if it is not. With a common correspondent, the mobility is transparent and there is no reason to use another address than the home address. With the home agent, there are three main cases (c.f. [8]): - The mobility signaling which is mandatory protected and raises a specific issue in its initial phase: the IKE SA must be setup using the care-of address as the peer address but this IKE SA is used to build an IPsec SA pair with the home address as traffic selector. This IPsec SA will protect the home registration which will make the home address available. This can be considered as a special proxy case. draft-dupont-ikev2-addrmgmt-00.txt [Page 4] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 - Other genuine communications between the home agent and the mobile node can be covered by the proxy case support too. Note this is the only case at the exception of signaling where mobility behaves in a different way than a mobile IPsec VPN (so we proposed to relax the corresponding rule in a future version of [7] and [8]). - The traffic relayed by the home agent through a tunnel with the mobile node can be partially or fully protected by IPsec SA pair(s). Encapsulation should be performed only once, including for degenerated (but not for free) encapsulation like the home address option or the mobility routing header. In all cases of interaction with the home agent, the mobile node peer address should be a care-of address. When the mobile node moves, another care-of address is used and some SAs, including the IKE SA, must be updated to use the new address. Usually the previous peer address is no more usable. In order to avoid a trivial denial of services, a strong sequencing of updates is required with a way to cancel possible pending updates when fast multiple handoff happen. The IPsec pair which protects the mobility signaling uses the home address as its traffic selector for the mobile node. It must not be updated at each handoff. The update mechanism must provide a fine grain (i.e., per SA) update. 3. Proposal The proposal for an address management in IKEv2 is mainly an extension of the NAT traversal notifications with a new peer address update notification. But there are some points that have to be kept as they are in the current IKEv2 draft [1]. 3.1 Kept points from draft 04 A peer address change has to be supported but not at any time: the peer addresses MUST NOT change during an exchange, i.e., they are allowed to change only between two exchanges. This address stability requirement applies in fact only to the Initial exchange as it is the only exchange with more than two messages specified today. draft-dupont-ikev2-addrmgmt-00.txt [Page 5] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 The peer addresses are used to transport messages. The reply to a request MUST be sent to the source of the request from the destination request, i.e., addresses and ports are reversed between the request and its reply. For tunnel mode IPsec SAs, the endpoint addresses are the peer addresses. We don't propose an alternate way to specify them. The same requirement applies to transport mode IPsec SAs at the exception of the proxy case. 3.2 Small points In the proxy case, the initiator is acting as a client negotiator on the behalf of another party. The address of this other party is sent in the initiator traffic selector and will become the address of this end of the transport mode IPsec SA pair. A proper authorization in the local policy of the responder is REQUIRED. Note that the IPsec SAs built in such cases are not managed in the proposal of these document, and that the proxy case is limited to the transport mode. The INITIAL-CONTACT notification uses only identities. All the references to peer addresses must be removed from or fixed in the current wording. 3.3 Peer address notifications The peer address notifications replace the current NAT-DETECTION-SOURCE-IP and NAT-DETECTION-DESTINATION-IP notifications. They includes the peer source or destination address and the source or destination port. They SHOULD be used only in protected messages (i.e., not in the first two messages) and SHOULD be ignored when they are not protected, i.e., outside an encrypted payload. For NAT traversal, they are used to detect NATs and their position, and they provide the original peer addresses for transport mode. For multi-homing and mobility, they provide a cryptographically proof of no alteration en-route of the peer addresses and, when multiple peer address notifications for the same peer are included, they encode its whole peer address set. Note: IMHO a whole/partial set flag is needed. draft-dupont-ikev2-addrmgmt-00.txt [Page 6] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 A new notification has to be defined for the peer address notification request by the responder. Typically a responder asking for either NAT traversal or a peer address protection (i.e., the opposite) will put this notification in the second message of the initial exchange. All following messages MUST include the requested peer address notifications. Note: is a way to request source or destination protection needed? For the initiator a simple way to request peer address notifications is to include then in requests: when peer address notifications are required, peer address notifications MUST be included in the encrypted payload of requests. When a peer address notification is included in a request, peer address notifications are required, all following messages MUST include the peer address protection notification(s), beginning by the reply message. If multiple peer address notifications for the same peer are included in a message, the first one SHOULD for the source and MUST for the destination be the used peer address. The extra addresses describe the other possible peer addresses, i.e., there is at least one peer address notification per address in the peer address set. In order to associate some possible peer source addresses to possible peer destination addresses, the source and destination peer addresses notifications MAY be mixed (i.e., not in the common order source(s) first, destination(s) after). For instance S1, S2, D1, S3, D2, D3 is a hint: S1 or S2 should be used in conjunction with D1, S3 with D2 or D3. When a peer can not find its peer addresses in the peer address notifications for its side, if NAT traversal is disabled then it MUST reject the compromised message and send an error notification to its peer, if NAT traversal is enabled it SHOULD take proper actions when a NAT is detected, for instance switch to the port 4500. This applies only to protected peer address notifications. 3.4 Implicit address update For address update, there is a choice between implicit and explicit mechanisms for IPsec SAs and IKE SAs. We claim that the implicit mechanism for IPsec SAs is far too unsecure: this mechanism is very (too?) simple. When a packet is received from another address, the peer addresses of the IPsec SA pair are updated. This opens the door to easy denial of service attacks and assumes extra-processing by the receiver device. draft-dupont-ikev2-addrmgmt-00.txt [Page 7] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 For the implicit mechanism for IKE SAs the things are even simpler. The implicit mechanism is mainly activated by keepalive exchanges: to switch from the implicit mechanism to the explicit one, only an update notification has to be included. The real difference is in the explicit case an observed peer address change is only a trigger. Note: should we specify a mechanism to advertise the other peer? It seems that NAT traversal needs it or should use an update all SAs in all IKE SA keepalive messages. 3.5 Explicit address update The explicit mechanism MUST be used. A new notification has to be defined. We propose to copy it from the delete notification. The new peer address notification has strong sequencing requirements. It MUST be processed in order and when a pending exchange with a peer address update has to be overrided by a more recent one, the peer address update notification MUST be canceled. Note: IKEv2 messages have a sequence number so the only sequencing issues are the window of processing and pending exchanges. But the sequence number (a.k.a. the message ID) must be protected, for instance by repetion inside the notification(s). Note: there are two obvious ways to cancel it (remove it from the message or define a cancellation flag) but both modify the message. When the receiver of an update request has to check the validity of the new peer address, it MAY use a return routability check sending an informational request at the new address and waiting for an answer. As informational exchanges are protected no more is needed. Example of a return routability check: I --- address update request --> R I <-- informational RR request - R I --- informational RR reply --> R now the responder knows the initiator should be where it said. I <--- address update reply ---- R As for the delete notification, the peer address update notification specifies the SPIs of the IPsec and IKE SAs it applies to. But a simple way to specify all SAs (i.e., the IKE SA and all the IPsec SAs it negotiated) is needed. Note: the "all SAs" MUST NOT be used when there is a proxy case SA pair. draft-dupont-ikev2-addrmgmt-00.txt [Page 8] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 4. Security Considerations Great care was used to avoid to introduce security threats. The NAT traversal feature comes with a security flaw (the transient pseudo-NAT attack [5]) which can not be easily avoid. IMHO the NAT traversal feature should be enabled only when the presence of NATs is likely/possible. When the NAT traversal feature is disabled, the other peer address can not be changed en-route by an attacker but the proofs the peer is really at its address are: - the trust in the peer - the proof that the peer can receive messages sent to its address The second (a.k.a. the return routability check) works only with at least three messages, i.e., for the initial exchange (with the address stability requirement) and for the explicit optional checks. IMHO these checks SHOULD be required by default. 5. Acknowledgments The need for an address management for IKEv2 was explained at the ipsec session of the Yokohama IETF meeting. It seems most people agree but do not propose concrete solutions. The rare people in the Mobility world with IPsec interests, or in the IPsec world with Mobility interest, should receive all thanks because without them we (me and all the future co-authors) have given up for a long time. 6. Normative References None? 7. Informative References [1] C. Kaufman, ed., "Proposal for the IKEv2 Protocol", draft-ietf-ipsec-ikev2-04.txt, January 2003. [2] B. Korver, E. Rescorla, "The Internet IP Security PKI Profile of ISAKMP and PKIX", draft-ietf-ipsec-pki-profile-01.txt, October 2002. [3] P. Hoffman, "Adding revised identities to IKEv2", http://www.vpnc.org/ietf-ipsec/, Message-Id: , November 2002. [4] M. Kaat, "Overview of 1999 IAB Network Layer Workshop", RFC 2956, October 2000. draft-dupont-ikev2-addrmgmt-00.txt [Page 9] INTERNET-DRAFT Address Management for IKEv2 Jan 2003 [5] F. Dupont, J.-J. Bernard, "Transient pseudo-NAT attacks or how NATs are even more evil than you believed", draft-dupont-transient-pseudonat-01.txt, December 2002. [6] Jayant Shukla, "RE: peer address protection and NAT Traversal", http://www.vpnc.org/ietf-ipsec/, Message-ID: <000201c2bb27$e7021ff0$5803a8c0@trlhpc1>, January 2003. [7] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-20.txt, January 2003. [8] J. Arkko, V. Devarapalli, F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-02.txt, January 2003. [9] F. Dupont, "How to make IPsec more mobile IPv6 friendly", draft-dupont-ipsec-mipv6-02.txt, January 2003. 9. Author's Address Francis Dupont ENST Bretagne Campus de Rennes 2, rue de la Chataigneraie BP 78 35512 Cesson-Sevigne Cedex FRANCE Fax: +33 2 99 12 70 30 EMail: Francis.Dupont@enst-bretagne.fr draft-dupont-ikev2-addrmgmt-00.txt [Page 10]