--- 1/draft-ietf-mobike-design-06.txt 2006-02-04 17:01:46.000000000 +0100 +++ 2/draft-ietf-mobike-design-07.txt 2006-02-04 17:01:46.000000000 +0100 @@ -1,19 +1,19 @@ IKEv2 Mobility and Multihoming T. Kivinen (mobike) Safenet, Inc. Internet-Draft H. Tschofenig -Expires: July 9, 2006 Siemens - January 5, 2006 +Expires: July 31, 2006 Siemens + January 27, 2006 Design of the MOBIKE Protocol - draft-ietf-mobike-design-06.txt + draft-ietf-mobike-design-07.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,21 +24,21 @@ 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 will expire on July 9, 2006. + This Internet-Draft will expire on July 31, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The MOBIKE (IKEv2 Mobility and Multihoming) is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security @@ -231,23 +231,23 @@ We denote the two peers of a MOBIKE session by peer A and peer B. A peer address set is the subset of locally operational addresses of peer A that is sent to peer B. A policy available at peer A indicates which addresses are included in the peer address set. Such a policy might be created either manually or automatically through interaction with other mechanisms that indicate new available addresses. Bidirectional address pair - The address pair, where traffic can be sent to the both - directions, simply by reversing the IP addresses. Note, that the - path of the packets going to each direction might be different. + The address pair, where traffic can be sent to both directions, + simply by reversing the IP addresses. Note, that the path of the + packets going to each direction might be different. Unidirectional address pair The address pair, where traffic can only be sent in one direction, and reversing the IP addresses and sending reply back does not work. For mobility related terminology (e.g., Make-before-break or Break- before-make) see [RFC3753]. @@ -366,51 +366,53 @@ The MOBIKE protocol is not trying to be a full mobility protocol; there is no support for simultaneous movement or rendezvous mechanism, and there is no support for route optimization etc. The design document focuses on tunnel mode, everything going inside the tunnel is unaffected by the changes in the tunnel header IP address, and this is the mobility feature provided by the MOBIKE, i.e., applications running inside the MOBIKE controlled IPsec tunnel might not detect the movement since their IP addresses remain constant. The MOBIKE protocol should be able to perform the following - operations: + operations (not all of those are done explictly by the current + protocol): o Inform the other peer about the peer address set o Inform the other peer about the preferred address o Test connectivity along a path and thereby to detect an outage situation o Change the preferred address o Change the peer address set o Ability to deal with Network Address Translation devices Figure 3 shows an example protocol interaction between a pair of - MOBIKE peers. MOBIKE interacts with the IPsec engine using an - internal API (such as those based on PF_KEY [RFC2367]). Using this - API, the MOBIKE module can create entries in the Security Association - (SAD) and Security Policy Databases (SPD). The IPsec engine may also - interact with IKEv2 and MOBIKE module using this API. The content of - the Security Policy and Security Association Databases determines - what traffic is protected with IPsec in which fashion. MOBIKE, on - the other hand, receives information from a number of sources that - may run both in kernel-mode and in user-mode. Information relevant - for MOBIKE might be stored in a database. The content of such a - database, along with the occurrence of events of which the MOBIKE - process is notified, form the basis on which MOBIKE make decisions - regarding the set of available addresses, the peer address set, and - the preferred address. Policies may also affect the selection - process. + MOBIKE peers. MOBIKE interacts with the packet processing module of + the IPsec implementation using an internal API (such as those based + on PF_KEY [RFC2367]). Using this API, the MOBIKE module can create + entries in the Security Association (SAD) and Security Policy + Databases (SPD). The packet processing module of the IPsec + implementation may also interact with IKEv2 and MOBIKE module using + this API. The content of the Security Policy and Security + Association Databases determines what traffic is protected with IPsec + in which fashion. MOBIKE, on the other hand, receives information + from a number of sources that may run both in kernel-mode and in + user-mode. Information relevant for MOBIKE might be stored in a + database. The content of such a database, along with the occurrence + of events of which the MOBIKE process is notified, form the basis on + which MOBIKE make decisions regarding the set of available addresses, + the peer address set, and the preferred address. Policies may also + affect the selection process. The peer address set and the preferred address needs to be made available to the other peer. In order to address certain failure cases, MOBIKE should perform connectivity tests between the peers (potentially over a number of different paths). Although a number of address pairs may be available for such tests, the most important is the pair (source address, destination address) of the current path. This is because this pair is selected for sending and receiving MOBIKE signaling and IPsec traffic. If a problem along this current path is detected (e.g., due to a router failure) it is necessary to @@ -653,35 +655,35 @@ In case the responder is behind NAPT, then also finding the port numbers used by the responder is outside the scope of MOBIKE. 5.2.5. NAT Prevention One new feature created by MOBIKE is NAT prevention, i.e. if we detect NAT between the peers, we do not allow that address pair to be used. This can be used to protect IP addresses in cases where it is known by the configuration that there is no NAT between the nodes - (for example IPv6, or fixed site-to-site VPN). This gives extra - protection against 3rd party bombing attacks (the attacker cannot - divert the traffic to some 3rd party). This feature means that we - authenticate the IP-address and detect if they were changed. As this - is done on purpose to break the connectivity if NAT is detected, and - decided by the configuration, there is no need to do UNSAF - processing. + (for example IPv6, or fixed site-to-site VPN). This avoids any + possibility of on-path attackers modifying addresses in headers. + This feature means that we authenticate the IP-address and detect if + they were changed. As this is done on purpose to break the + connectivity if NAT is detected, and decided by the configuration, + there is no need to do UNSAF processing. 5.2.6. Suggested Approach The working group decided that MOBIKE uses NAT-T mechanisms from the IKEv2 protocol as much as possible, but decided to change the dynamic - address update for IKEv2 packets to MUST NOT (it would break path - testing using IKEv2 packets, see Section 6.2). The working group - also decided to only send keepalives to the current address pair. + address update (see [RFC4306] section 2.23 second last paragraph) for + IKEv2 packets to MUST NOT (it would break path testing using IKEv2 + packets, see Section 6.2). The working group also decided to only + send keepalives to the current address pair. 5.3. Scope of SA Changes Most sections of this document discuss design considerations for updating and maintaining addresses in the database entries that relate to an IKE SA. However, changing the preferred address also affects the entries of the IPsec SA database. The outer tunnel header addresses (source and destination IP addresses) need to be modified according to the current path to allow the IPsec protected data traffic to travel along the same path as the MOBIKE packets. If