Subject: [MOBILE-IP] Implementation Issues re MobileIP and IPSec

From: Stefan Schmid <[email-masked]>
Date: Thu, 27 Jul 2000 22:18:59 +0100

Hi,

  we are currently implementing IPsec support for our Mobile IPv6
stack. However, after looking closely at the Mobile IPv6 specification, we
found the following contradictions/obscurities:

1. According to the Mobile IPv6 specification only "once the packet is
fully assembled, the necessary IPsec authentication [...] processing
is performed on the packet, initializing the Authentication Data in
the AH or ESP header" (see 10.2). This implies that the mobile node's
care-of-address must be used within the IPv6 source address.
However, at the receiver, the Mobile IPv6 specification demands: "when
any node receives a packet containing a Home Address option, it MUST
process the option in a manner consistent with copying the Home
Address field from the Home Address option into the IPv6 header,
replacing the original value of the Source Address field there [...]
Further processing of such a packet after option processing (e.g., at
the transport layer) thus need not know that the original Source
Address was a care-of address [...]" (see 8.1.) Therefore, by the time
the AH header is processed (note that the AH must be processed after
the Home Address option), it would use the home address to compute the
authentication data rather than the care-of-address.

2. According to the IPv6 RFC (2460) "extension headers must be
processed strictly in the order they appear in the packet". It
explicitly states that "a receiver MUST NOT, for example, scan through
a packet looking for a particular kind of extension header and process
that header prior to processing all preceding ones".
However, in contrast, the Mobile IPv6 specification declares that "the
Destination Options header in which the Binding Update option is
inserted MAY appear either before or after the AH or ESP header".
Since a Binding Update option cannot be processed before the packet
was properly authenticated (note that "any packet carrying a BU MUST
be protected by IPSEC [...]" (see 4.4), it should never occur before
the AH header in the packet.

In addition, we believe the current specification lacks clarification
regarding:

1. It should explicitly state which address, the mobile node's Home
Address or care-of-address, must be used as IPv6 source address for
the authentication calculation.

   We believe that only the latter makes sense, as the
care-of-address must be authenticated in order to prevent malicious
binding update messages. Note that otherwise (i.e. the source address
is set
to the Home Address when authentication is perfomed) the
care-of-address would not be authenticated.

2. It should clarify which address, the mobile node's Home Address or
care-of-address, must be used for the SA/SP lookup.

   Here we believe that only the former is useful. Since using the
care-of-address as key to identify the correct SA/SP for
authentication would result in exploding number of SAs/SPs (one for
each care-of-address). However, a clear statement in the specification
that the Home Address must be used is missing.

Any comments? Also, could anybody please confirm if we are on the
right track, or if we have overlooked something.

Regards,

- Stefan

---
  Stefan Schmid (Dipl.-Inf)      Distributed Multimedia Research Group
  Research Assistant                              Computing Department
  Phone: +44 (0)7989 400707                       Lancaster University
  Fax:   +44 (0)1524 593608                          Lancaster LA1 4YR
  Email: mailto:[email-masked]                          U.K.
  WWW:   http://www.landmarc.net/people/stefan.htm
  SMS:   mailto:[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 31 Jul 2000 19:30:02 +0200

In your previous mail you wrote:

   1.

=> this point was signaled by me and others... The final document
is supposed to fix it.

=> I disagree because you put more in "Binding Update option processing"
than it should be. In fact when you decode the BU you don't know if there
is an AH after or (the argumebnt :-) a HA option. I execute the BU only
when I see the upper layer header, the processing itself is restricted
to length/alignement checks.

=> agree but I don't know what will be in the final document
(then I don't know if my code will interoperate because there are
two options :-).

=> an older document suggests to swap the two addresses (same protection
but interoperability problem).

=> this is clearly specified in the I-D (home address must be used).

=> I know only two missing parts in the last I-D:
 - HA option processing (=> home and care-of address order)
 - protocol(s) in phase 2 IKE ID payloads (I use 60 with no/any port)
Both should not block your work (ie you should get a working implementation
after some fight with/against IKE :-).

Regards

[email-masked]