Subject: MIPv6 issue: HAO keyword

From: gabriel montenegro <[email-masked]>
Date: Tue, 01 Oct 2002 09:39:41 +0200

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-masked]
--------------------------------------------------------------------

---

From: Michael Thomas <[email-masked]>
Date: Tue, 1 Oct 2002 09:09:20 -0700 (PDT)

Gabriel,

On the requirement for HAO in all IPv6 nodes... is
this actually necessary? That is, if I do not
implement a binding cache (which is not a
requirment), the only processing the node would
need to do is inform the mobile node that it can
not/will not process the HAO because it's not
legal to interpret it as a home address without a
binding entry. Likewise, a MN shouldn't be sending
a HAO until it establishes a binding, thus there
shouldn't be a possibility for missynchronization
there either.

What am I missing?

	Mike

---

From: Jari Arkko <[email-masked]>
Date: Tue, 01 Oct 2002 23:53:54 +0300

> shouldn't be a possibility for missynchronization

Right. And that's what we are recommending. We
are saying that the current HAO requirement for all
nodes should be removed.

CN has no clue about HAO, MN sends anyway => ICMP Par.prob. code 2
MN tries to establish RO, no CN support => ICMP Par.prob. code 1

Jari

---

From: Michael Thomas <[email-masked]>
Date: Tue, 1 Oct 2002 14:03:50 -0700 (PDT)

> MN tries to establish RO, no CN support => ICMP Par.prob. code 1

   Good. Then I'm cool with the recommendation.

	      Mike