This is an attempt to close issue 53 in the MIPv6 draft
("HAO keyword"):http://www.piuha.net/~jarkko/publications/mipv6/issues/issue53.txt We're cross-posting to both IPv6 and MobileIP as this concerns both lists. I'm sending this on behalf of Jari Arkko and the Mobile IP chairs. Please send any issues to the lists. tnx, -gabriel -------------------------------------------------------------- In July we had a big discussion around the right keyword for the Home Address destination option support in IPv6 nodes. This e-mail reviews the issue and makes a recommendation. Unless otherwise specified, section numbers refer to rev 18 of the draft: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-18.txt BACKGROUND In the new security design for Mobile IPv6 (adopted to the base specification over the course of the last year), we allow two modes of operation for communicating with the correspondent nodes: 1. Tunneling via the home agent (also called "reverse tunneling" in section 11.2.1). 2. Route Optimization (also called "direct delivery" in section 11.2.1): routing directly from the mobile node to the correspondent node (using a "home address option"), and from the correspondent node to the mobile node (using a "routing header - type 2"). Note that tunneling happens in *both* directions and that optimal routing can *only* be performed if a binding cache entry has been established. The mobile node can't send a packet directly to the correspondent node until it has completed return routability procedure and sent a binding update. This is a change from previous versions of the protocol and was done in order to guard against certain reflection attacks. (But see below for a special case.) The return routability procedure and binding updates are carried by the Mobility Header protocol (a new IPv6 protocol). According to RFC 2463, any node that doesn't recognize a specific "next header" protocol value will return ICMP Parameter Problem, Code 1 to the sender. The MIPv6 specification requires that the reception of such a message is taken as an indication that the peer does not support Route Optimization. Furthermore, even nodes that support MIPv6 may decline requests for Route Optimization due to temporary lack of resources, for instance. This happens via an error response within the Mobility Header protocol itself. The new version of MIPv6 protocol is therefore capable of operating both with nodes that support this specification (regardless of any temporary inability to accept requests) and with nodes that do not support MIPv6 (such as nodes that have already been deployed). The current MIPv6 specification lists the benefits of route optimization (Section 8.2) but does not state whether it is mandatory or not for all IPv6 nodes. The plan is to leave that for the IPv6 node requirements document to decide. THE PROBLEM Even though it does not mandate route optimization itself, the current MIPv6 spec does mandate that two items MUST be implemented by *all* IPv6 nodes (section 8.1): 1. All IPv6 nodes MUST recognize the Home Address destination option and, 2. All IPv6 nodes MUST be able to return Mobility Header error messages. However, several people have complained that in the current state of IPv6 deployment, they do not wish to add new requirements for all nodes. As explained above, this isn't technically necessary as the ICMP Parameter Problems (or the lack of response) is adequate to keep the mobile node using tunneling. No payload packets will be sent to the wrong place, and no packets are lost. However, these two requirements relate to a special case we currently allow in the specification: direct delivery from the mobile node to the correspondent node (which uses a home address destination option) is allowed not just when a binding exists but also if the packets have been protected by IPsec. This constitutes "triangular routing": whereas the mobile node can directly deliver packets to the correspondent node by virtue of IPsec, the opposite is not true: the reverse direction cannot be optimized if the correspondent node does not have a binding for the mobile node. Although allowed, triangular routing is not adequately described in the current spec (more below). Note that in any case a correspondent node that doesn't support the Home Address destination option will send ICMP Parameter Problem, Code 2, so that the mobile node may learn the fact that this node is of an older variant that doesn't support this option, and continues using reverse tunneling. ALTERNATIVES The main question in the debate was to choose: 1. Remove the current requirements for all nodes. 2. Keep the current requirements for all nodes. However, we also have some additional questions to answer: - Should triangular routing (the IPsec-protected HAO) mode be a part of the Mobile IPv6 specification, even as optional? - What is the right keyword for Route Optimization support in correspondent nodes? - Should the MIPv6 specification state all these requirements for IPv6 nodes, or the IPv6 node requirements document? ANALYSIS - Mobile nodes that try to improve upon reverse tunneling by either route optimization or triangular routing can survive a situation where they connect to an older node with no MIPv6 support at all. In this case they can fall back to reverse tunneling mode which does not require any support from the correspondent node. - We need to separate the technical requirements for mandating a specific protocol function (e.g. saying that "route optimization or some part of it is mandatory"), and more high level requirements (e.g. saying "security is mandatory"). - It is likely that obtaining an IPsec security association between a mobile node and an arbitrary correspondent node continues to be difficult. Even if possible, it may not be justifiable for the mobile node to either (1) obtain such a security association (e.g. if the traffic pattern consists of access to public web sites), or (2) obtain it and stop without spending the negligible *additional* effort to create a binding entry. This implies that the main modes would be reverse tunneling and route optimization, whereas triangular routing via the IPsec-protected HAO would be perhaps less often used. - The IPsec-protected HAO mode is inadequately described in the current specification. Section 9.2.2 describes this possibility for the correspondent node, but not for the mobile node in 11.2.1. This can be easily fixed, however. - If we removed the IPsec-protected HAO mode from the specification along with the HAO requirement, the effect would be that even nodes that use IPsec would have to establish a binding before any optimization is possible. Establishing a binding requires 1.5 roundtrips every 7 minutes. Of course, such nodes can continue using reverse tunneling. Note that the establishment of the binding can take place in parallel with the security association establishment. - RFC 2119 states on the use of imperatives in RFC's: "MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability." In this respect, the "MUST" keywords on HAO processing & error message requirements do not seem necessary, as (1) interoperability is already achieved using other mechanisms (ICMP/lack of answer and reverse tunneling via the home agent), and (2) for the mode that could potentially benefit from this the difference is not catastrophic as explained in the previous bullet. RECOMMENDATION The requirements of RFC 2119 for a "MUST" are not fulfilled in this case: interoperability is achieved in any case. Furthermore, it is questionable that nodes that bother to set up an IPsec security association would not be able to afford a much smaller amount of memory for a binding cache entry, particularly when bidirectionally optimal routing can only be achieved with Route Optimization. Therefore, we recommend that the HAO processing and error message MUST requirements be removed for all nodes. Instead, we recommend that Route Optimization support for correspondent nodes be made a SHOULD in the IPv6 node requirements document. The ability of a correspondent node to participate in route optimization is good for the efficient operation of the IPv6 Internet, beneficial for robustness and reduction of jitter and latency, and is in some cases necessary to avoid congestion in the home network. We also recommend that triangular routing via the IPsec-protected HAO processing be described in the Mobile IPv6 base specification, and be made a SHOULD for mobile and correspondent nodes. This includes describing how nodes can survive the situation where the other side does not support this mode. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
