Subject: RE: [mobile-ip] Re: MIPv6 issue: HAO keyword

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 4 Oct 2002 17:56:04 +0200

> >>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.
  > > 
  > > 
  > > Is there proposed text for the above part?

  > 
  > No, I guess the assumption was that it would not be too hard to
  > write the MN equivalent of the current text for the CN side.
  > But perhaps the existing CN side is underspecified as it is.

=> I think it is actually underspecified. The text does not
explain how the CN should ensure that the MN was authorised
to setup this SA in the first place. If the SA was 
manually configured then it is most likely safe
to accept the HAO provided that IPsec processing was ok.
If the SA was negotiated using IKE (with PKs) then 
this is far from clear and may still cause reflection
attacks. For example, if the attacker uses the HoA
in phase 2 of the negotiation, how can the CN check
if he/she is authorised to do so? 
Unless there is somewhere to check in the MN's certificate
(like making the subjectuniqueidentifier include a HoA) it 
wouldn't be obvious that the MN is authorised to do this.
So I think more explanation is required.

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Sat, 05 Oct 2002 09:12:24 +0300

When we wrote the recommendation, the thinking was that an SA
is sufficient to prevent reflection attacks, as a manual configuration
would imply a trusted peer. And IKE-based SAs would imply some rounds
of packet exchanges, meaning that the address on the other side is
valid and tested. This would also work for opportunistic security,
as that too needs some packet exchanges.

Perhaps this was a too simple view of the situation.

One issue is that we have now specified that IKE should run on top
of the care-of addresses. This means that if we have opportunistic
security, anyone can establish a security association from a care-of
address. Can we take that as a guarantee that the MN does not lie about
the home address and still try to use HAO as a reflection tool?
Apparently not, as the home address does not get "tested" as a part
of the security association set-up.

This would imply that we need either some smart rules about which
SAs are OK to be used together with HAOs, or we should take out
the IPsec-protected-HAO mode and just rely on RR and BCEs.

Jari

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 07 Oct 2002 18:01:47 +0200

Ok, after discussing with some folks and the chairs,
it is now obvious that whatever is in the spec for the
IPsec protected HAO is underspecified, and that the best
course of action right now is to remove the issue outside
of the base MIPv6 schedule. Interested folks can work on
it on a separate time line.

I have modified the issue writeup to reflect this and include
it below. FYI, as far as the RECOMMENDATION section is concerned,
the changed paragraph is as follows:

"We also recommend that triangular routing via the IPsec-protected
HAO processing NOT be allowed in the Mobile IPv6
base specification.  Given that this feature is not at all
essential to the basic specification, it can be specified in a
separate document later on. Wording in the base MIPv6 spec
must allow for this future possibility."

This issue is now closed.

-gabriel
ps - Only sending to the mip alias as the change in the recommendation
does not concern the ipv6 alias.

--------------------------------------------------------
--------------------------------------------------------------
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 (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 ("reverse tunneling" in
        section 11.2.1).
     2. Route Optimization ("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 document. Section 9.2.2 describes
   this possibility for the correspondent node, but does
   not fully specify it. This possibility is not even
   mentioned for the mobile node in 11.2.1. This functionality
   will require some careful thinking and detailed wording
   to get right. It is clear that the dubious benefit is not
   worth the trouble at this particular point in time, in
   which the main focus is to finish the base specification.
   Furthermore, this mode is not at all essential to the base
   MIPv6 spec. Accordingly, it can be worked out later on
   outside of the base MIPv6 schedule, as a separate
   optimization.

- 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.

   Furthermore, the IPsec-protected HAO mode can be specified
   at a later date if experience shows that it would be indeed
   valuable/worthwhile to add this optimization to the protocol.

- 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 NOT be allowed in the Mobile IPv6
base specification.  Given that this feature is not at all
essential to the basic specification, it can be specified in a
separate document later on. Wording in the base MIPv6 spec
must allow for this future possibility.