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

From: Stefan Schmid <[email-masked]>
Date: Tue, 1 Aug 2000 09:53:21 +0100

Francis,

  please see my comments below.

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

  So, the care-of-address is used as the IP source address for the
authentication calculations. Correct?

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

  Now, I am confused ... Since we propose to put the BU in the 2nd
Destination Options header, this problem wouldn't occur. By the time we get
to the BU message, we have already processed the HA option (which MUST be in
the 1st Destination Options header) and the AH (which MUST occur before the
2nd Destination Options header).

> I execute the BU only
> when I see the upper layer header, the processing itself is restricted
> to length/alignement checks.

  So, what would you say are the advantages of putting the BU in the 1st
Destination Options header? Or is it just convenience since only one of the
Destination Options headers must be processed then?

>    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.
>
> => 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 :-).

  Could anybody working on the "final document" respond to this question?

>    2. It should clarify which address, the mobile node's Home Address or
>    care-of-address, must be used for the SA/SP lookup.
>
> => this is clearly specified in the I-D (home address must be used).

  Could you please point out the respective section?

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 1 Aug 2000 21:16:56 +0200

=> we need both the home and the care-of address, one will be in the
source address field, the other in the home address option.
But we have to wait for the final document to know the exact order
(ie. swapped (me) or not (Microsoft)).

   > is an AH after or (the argument :-) a HA option.

     Now, I am confused ... Since we propose to put the BU in the 2nd
   Destination Options header, this problem wouldn't occur.

=> you can put the BU in the first/only DO header before the HA: you have
replaced "MUST include" by "MUST be before" which is far stronger... (*)
The only constraint in the order is there MUST be a DO header with
a HA option before the AH header, you can put the BU where you'd like
(before or after, in the same header than the HA or in an other one.
In my code I put it in the same header than the HA in the order which
gives the smallest length).

   By the time we get

=> the second MUST is yours and obviously is incorrect because I can implement
this with only one DO header...

     So, what would you say are the advantages of putting the BU in the 1st
   Destination Options header?

=> simpler, smaller, ...

   Or is it just convenience since only one of the
   Destination Options headers must be processed then?

=> of course it is convenience. But if you have an ESP header too
our firewall implementors want to have all DO headers in clear, ie
before the ESP. Then they convince me to keep the way I built the DO
header before IPsec introduction and just add some code which:
 - puts the AH after the DO header
 - supports DO headers (and DO themselves) in *any* order on input

=> I'll try to catch Dave Johnson who is here (IETF, mobileip 1st session).

=> section 10.2 (inbound processing must be symmetrical).
Beware that IKE rules are a bit hairy (but less than IKE itself :-).

Regards

[email-masked],

PS *: to put the HA option after the BU option is a favorite in
the UNH mobile IPv6 test suite...

---

From: Stefan Schmid <[email-masked]>
Date: Tue, 1 Aug 2000 22:06:48 +0100

Francis,

> replaced "MUST include" by "MUST be before" which is far stronger... (*)

  Sorry the confusion ... I just tried to point out that the specification
is not entirely clear re AH processing. It states quite clear though, that
the Home Address option must be in the 1st Destionation Options header (if
included) and that the BU can be either in the 1st or 2nd Destination
Options header.

> this with only one DO header...

  Nope ... but I guess you got me wrong here. The second MUST is defined by
the extension header order specified in RFC 2460 (IPv6 specification). It
does not imply that a 2nd Destination Option header is required. It simply
says that iff a 2nd DO header is present, it must occur after the
Authentication Header.

>    Destination Options header?

  True.

> before the ESP. Then they convince me to keep the way I built the DO

  Ei? Not sure if I understand you right here, because the 2nd DO header
cleary must succeed the IPsec headers according to the IPv6 specification. I
understand the benefits of clear (unencrypted) BU messages though.

> => section 10.2 (inbound processing must be symmetrical).

  Okay, I guess you refere to the following sentence ...

   "[...] it is assumed that IPsec is being used in transport mode [13] and
that
    the mobile node is using its home address as the source for the
packet[...]"

  Although it is quite clear, I still believe the specification could be
improved by adding a clear statement (regarding which address to use for
SA/SP lookup and where to use the HA/COA for the authentication calculation)
to section 4.4 and/or 13, since both specifically discuss IPsec
issues/requirements.

Regards,

- Stefan

---

---

From: Francis Dupont <[email-masked]>
Date: Wed, 2 Aug 2000 19:15:29 +0200

=> the word in RFC 2460 is "recommended" ie. a SHOULD and I think
this recommendation is wrong because no already defined destination
option is very useful when it is after an ESP header, ie. if/when
the RFC 2460 will be revisited I'll ask to change the recommended order
(put destination options before IPsec headers, AH, ESP and IPCOMP).
My argument is the non-mobility destination option, tunnel encapsulation
limit, must be in clear text...

Regards

[email-masked]

PS: I can't get an immediate answer from Dave Johnson about AH/HA issue
but he recognized he had to fix it...