Subject: [MOBILE-IP] Implementation question about MIPv6 and IPSec

From: Lars Henrik Petander <[email-masked]>
Date: Mon, 18 Sep 2000 19:27:40 +0300

Hello!

We have implemented Mobile IPv6 for Linux, check
http://www.mipl.mediapoli.com for more information. I am currently
designing the addition and processing of the authentication header.

According to RFC2460 extension headers should be added in the order
they are going to be processed. In order to process a BU the datagram
needs to be authenticated. However the Mobile IPv6 draft version 12 does
not clearly define the place of the BU. Is there a reason for this
ambiguity?

I understand, that there are benefits in adding a BU before or after the
AH and ESP, but the potential benefits are lost if one can't be sure of
the location of the BU. IMO, it would be better if the BU was after the AH
and ESP. Any opinions on this?

Regards,

Henrik Petander

---

From: Francis Dupont <[email-masked]>
Date: Mon, 18 Sep 2000 19:43:12 +0200

In your previous mail you wrote:

   However the Mobile IPv6 draft version 12 does not clearly define
   the place of the BU. Is there a reason for this ambiguity?

=> there is no ambiguity because there is no good reason to put the BU
after or before the AH.

   IMO, it would be better if the BU was after the AH and ESP.

=> I disagree but this is not the point. You may put it where you'd like
but you must be able to find it in any reasonable position.

   Any opinions on this?

=> I can't see a reason to specify the BU position. I-D 12 is fine
(for this point) for me.

Regards

[email-masked]

PS: do you know when your implementation will support secure mobile IPv6
(ie. Mobile IPv6 + IPsec, including IKE)?

---

From: AIme Le-Rouzic <[email-masked]>
Date: Thu, 21 Sep 2000 09:37:49 +0200

Hi,

We are also implementing MobileIPv6 with IPSECv6 in AIX.
For our opinion we choice to add the BU before the security headers for
an easier implementation raison and to make it more accessible even ESP
like it has been generalized for the HA.

Regards.

--
     ________________________Aime LEROUZIC____________________________
     BULL S.A ECHIROLLES FRANCE      mailto:[email-masked]
     http://www-frec.bull.com                tel: +33 (0)4 76 29 75 51
     Communications TCPIP                     http://intranet/lerouzic

---

From: Lars Henrik Petander <[email-masked]>
Date: Fri, 22 Sep 2000 10:07:10 +0300

> like it has been generalized for the HA.

Thanks for your reply. I didn't however quite understand your comment on
ESP and HA. Since the HA has a SA with the MN, it should also be able to
decrypt the ESP payload or did I misunderstand your comment? In any case
it needs to process the security headers, at least AH, before it can
process the BU option.

I think that the problem with adding BU before the AH, is that you need to
add hooks to the AH processing (or after it) to know whether the BU was
valid. This makes life difficult if you want to use a generic IPSecv6
implementation. When the AH is before the BU the processing is much more
straightforward, since you already have the knowledge of a succesful
authentication before you start the processing of the BU.  With the BU in
the second destination options header the protocol, besides being
"cleaner" to implement would also comply better with RFC2460.

BR,
Henrik

---

From: Stefan Schmid <[email-masked]>
Date: Fri, 22 Sep 2000 10:25:26 +0100

> "cleaner" to implement would also comply better with RFC2460.

  I completely agree with you. In our implementation for Microsoft, we have
done it the way you described it above (BU and BA in 2nd destionation
options header) for exactly the same reasons - mainly because we argue it is
conceptually the cleanest way (at least according to the current specs.) ...

Regards,

- Stefan

PS: BTW, we (mainly Francis Dupont and myself) had a similar discussion
about 2-3 months ago on this list. See archive ...

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Sep 2000 11:57:37 +0200

Thanks for your reply. I didn't however quite understand your comment on
   ESP and HA. Since the HA has a SA with the MN, it should also be able to
   decrypt the ESP payload or did I misunderstand your comment?

=> Aime comment was not very clear (:-). The idea is:
 1- it is easier to put home address and binding update options in the
    same extension header.
 2- there is no good reason to hide an option when ESP is used (or with
    other words if you need to hide something in a header then you should
    simply use the tunnel mode).
IMHO the RFC 2460 is wrong in its recommendation for header ordering:
security headers should be last. For instance the tunnel encapsulation
limit option (the not-for-mobility destination option) is not useful/usable
if it is hidden by an ESP...

   implementation.

=> life is difficult (:-)! You have to deal with multiple destination
option extensions which should contain a home address and a binding
update in any order (between them and with security headers) then
you should defer BU execution when you know you have got everything,
ie. at the first transport/not-extension header.

   When the AH is before the BU the processing is much more
   straightforward, since you already have the knowledge of a succesful
   authentication before you start the processing of the BU.

=> you have to support the other case then there is not real benefit here
(ie. you should try to make the sending code as easy as possible,
the receiving code must be (too) generic).

   With the BU in the second destination options header the protocol,
                  ^^^

=> can you explain why it is not *a* second ...? For instance what is
your proposed layout for a BU between two mobiles (with optimized
routing).

   besides being "cleaner" to implement

=> it is a matter of taste. The only easy thing here is to forget to
implement the (mandatory) authentication (:-). IMHO the two hard points
in mobile IPv6 is movement detection and IPsec interaction.

   would also comply better with RFC2460.

=> compliance is binary... RFC 2460 must be fixed, I don't know how
or when and this topics doesn't move crowds in the IPng mailing-list.

Regards

---

From: Stefan Schmid <[email-masked]>
Date: Fri, 22 Sep 2000 11:41:41 +0100

>  1- it is easier to put home address and binding update options in the

  True, but using two extension headers is not difficult either ...

> if it is hidden by an ESP...

  Okay ... but for this reason (i.e. options that have to be clear), the
spec defines the 1st destination option header. Options that should be
protected (i.e. BU/BA) go in the 2nd destination option header.

> the receiving code must be (too) generic).

  This argument only holds when the specifiction is not clear. If it would
be clear, one would have to support (and may optimize) only the correct way.

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: Fri, 22 Sep 2000 13:51:52 +0200

Okay ... but for this reason (i.e. options that have to be clear), the
   spec defines the 1st destination option header.

=> NO, this is a mistake. The first destination option header in RFC 2460
is for intermediate hops specified by a routing header, this has nothing
to do with security or mobility and is currently unused (no such option
are defined, nor the way to apply them to the right hop).

   Options that should be protected (i.e. BU/BA) go in the 2nd
   destination option header.

=> I disagree:
 - ESP in transport mode doesn't provide the needed protection for BU/BA
   (for instance the source address is not protected).
 - some destination options should not be hidden (my favorite example
   is the tunnel encapsulation limit).

   > the receiving code must be (too) generic).

     This argument only holds when the specifiction is not clear.

=> yes the specification is not clear enough but RFC 2460 notes 1 and 3
in section 4.1 page 8 are clear.

   If it would be clear, one would have to support (and may optimize)
   only the correct way.

=> according to RFC 2460 none are correct then you have to wait for
the next draft or the next version of RFC 2460...

Regards

PS: is there something in the IPv6 Linux implementation which constraints
destination option headers? We already had this discussion between me
and a Linux guy...

---

From: Stefan Schmid <[email-masked]>
Date: Fri, 22 Sep 2000 15:43:59 +0100

> is for intermediate hops specified by a routing header,

  So what about the section 4.1 of RFC 2460 ...

  Recommended header order:
  "        IPv6 header
           Hop-by-Hop Options header
           Destination Options header (note 1)
           Routing header
           Fragment header
           Authentication header
           Encapsulating Security Payload header
           Destination Options header (note 3)
           upper-layer header

           note 1: for options to be processed by the first destination
                   that appears in the IPv6 Destination Address field
                   plus subsequent destinations listed in the Routing
                   header.
             [...]
           note 3: for options to be processed only by the final
                   destination of the packet."

  Note 1 tells me that if no routing header is present, the 1st Destination
Options header is (apart from its processing order within the IPv6 stack)
equivalent to the 2nd Destination Options header. But it can still be used
in the same (or a similar) way as the 1st Destination Options header. Note,
only if an routing header is available, the possible options MIGHT be
processed (if the node supports the option) by "intermediate destinations".
  Thus, I can't see why we should not be able to use this extension header
for the Home Address Option and Binding Request.

> this has nothing

  Moreover, the mobile IPv6 specification even mandates the use of the 1st
Destination Options header. I am not sure how you can claim that no such
option is defined, when it is even stated by the mobile IPv6 spec?

  Have a look what it says in section 10.2 (page 74):

"Since the mobile node is away from home, the mobile node inserts
a Home Address option into the packet, replacing the Source
Address in the packet's IP header with a care-of address suitable
for the link on which the packet is being sent, as described in
Section 10.1.  The Destination Options header in which the Home
Address option is inserted MUST appear in the packet before the
AH [11] (or ESP [12]) header, so that the Home Address option is
processed by the destination node before the AH or ESP header is
processed."

  According to the IPv6 RFC (also see above), there is only one Destination
Option header which occurs before the AH & ESP header.

>    is the tunnel encapsulation limit).

   Hence the 1st Destination Option header ...

Regards,

- Stefan

---

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Sep 2000 19:12:43 +0200

Note 1 tells me that if no routing header is present, the 1st Destination
   Options header is (apart from its processing order within the IPv6 stack)
   equivalent to the 2nd Destination Options header.

=> this is not what I read. IMHO note 1 says the 1st DO header is valid
only if there is a routing header and it specifies options which will be
processed by all intermediate hops (including the first one which is in
the destination address field when the packet is sent and the last one
which is in the last address field in the routing header until the last
segment).

   But it can still be used in the same (or a similar) way as the 1st
   Destination Options header.

=> I disagree. If you put an option in the 1st DO header then the first
hop will processed it and will reject the packet if the option is not a pad
or is maked as "should be skipped" (which is not the case for BU and HA).

   Note, only if an routing header is available, the possible options MIGHT be
   processed (if the node supports the option) by "intermediate destinations".

=> I can find where is your MIGHT. The text specifies they will be processed.

=> you just don't understand the purpose of this extension header.
For the last time, BU and HA are sent to the FINAL destination.

     Moreover, the mobile IPv6 specification even mandates the use of the 1st
   Destination Options header.

=> where? The mobile IPv6 mandates only the use of a DO header placed before
the AH header. There is no reference to this section of RFC 2460 (of course,
the I-D violates it :-).

   I am not sure how you can claim that no such
   option is defined, when it is even stated by the mobile IPv6 spec?

=> please read the list archive, I have not the time to do the whole
discussion again...

=> definitively NO!

---

From: Stefan Schmid <[email-masked]>
Date: Fri, 22 Sep 2000 20:56:07 +0100

> which is in the last address field in the routing header until the last

  Under certain circumstances there might be some sense in reading it that
way, however, Note 1 does not say the first DO header is valid only if there
is a routing header. Clarification in the spec is needed.

> or is maked as "should be skipped" (which is not the case for BU and HA).

  Do you know the exact reason why the HA option could not be skipped by
intermediate nodes?

> For the last time, BU and HA are sent to the FINAL destination.

  This wouldn't be a problem if intermediate nodes don't process the
mobileip options :-). Unfortunately, this would require modification to
current spec(s) :-(

> => where? The mobile IPv6 mandates only the use of a DO header
> placed before the AH header. There is no reference to this section of RFC
> 2460 (of course, the I-D violates it :-).

  Assuming the mobile I-D is compliant with the IPv6 spec (RFC 2460), it
_demands_ the use of the 1st DO header. But you are right, that if one
simply ignores the spec, one can interpret it your way. ;-)

> => please read the list archive, I have not the time to do the whole

  Sorry, I know we had this discussion already some month ago, but as long
as the spec(s) are not changed, your arguments are not well establishied.
Hopefully this discussion will stimulate clarification of the Mobile IPv6
spec.

Regards,

- Stefan

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Sep 2000 18:42:18 +0200

is a routing header.

=> I don't know the meaning of note 1 if there is no routing header...

=> first bits are not 00 then the HA option will not be skipped.

   mobileip options :-).

=> the current meaning of note 1 is "if intermediate nodes should process
the options, put them here" and note 3 is "if only the final destination
should process the options, put them there".

   Unfortunately, this would require modification to current spec(s) :-(

=> the mobile IPv6 ID should not ignore this issue...

    Assuming the mobile I-D is compliant with the IPv6 spec (RFC 2460),

=> it is not compliant! I expect the next one will be.

---

From: Antti Tuominen <[email-masked]>
Date: Mon, 25 Sep 2000 16:00:13 +0300

On Sat, Sep 23, 2000 at 06:42:18PM +0200, Francis Dupont wrote:

Hello!

Since I'm a first time poster on this list, I will say a word or two
about myself.  I'm a computer science and engineering student doing my
master's thesis on using IPv6 in mobile ad hoc networks.  I work as a
research assistant at telecommunication software lab at HUT and am
involved in a Mobile IPv6 implementation for Linux.

> => I don't know the meaning of note 1 if there is no routing header...

If you take a look at "The Case for IPv6"
(http://www.ietf.org/internet-drafts/draft-iab-case-for-ipv6-06.txt)
section 2.4, it says: "A Destination Header appearing after a Routing
Header, or without a Routing Header, will be processed only by the
final destination."

Though I perfectly well understand that this document is no
specification whatsoever it does imply that RFC 2460 does mean that
intermediate nodes should not process the first DO if no routing
header is present.

> should process the options, put them there".

If there is a routing header, that is.

Regards,

Antti

--
Antti J. Tuominen, JMT 3A 131, FIN-02150 Espoo, Finland.
Research assistant, TSE Institute at Helsinki University of Technology
work: [email-masked]; home: [email-masked]

---

From: Linfeng Yang <[email-masked]>
Date: Mon, 25 Sep 2000 17:16:14 +0300

> intermediate nodes should not process the first DO if no routing

Both "The Case of IPv6" and RFC 2460 suggest, as I understood, there will
be only one DO (Destination Header) if there is no routing header. This
only DO will appear just before upper layer header or another IPv6 header
if encapsulation is employed.

I guess that is the thought behind Francis' comments.

Regards,

Linfeng Yang
                Helsinki University of Technology
                Telecommunications Software and Multimedia Laboratory
                P.O.Box 9700, 02015 HUT, Finland
                Phone: +358 9 451 5250           Fax: +358 9 451 5351

---

From: Linfeng Yang <[email-masked]>
Date: Mon, 25 Sep 2000 18:11:36 +0300

> if encapsulation is employed.

Sorry, DO stands for Destination Option. Another correction, if Home
Address DO is included, there will be more than one DO, but it will appear
even after other DO as MIPv6 recommended. So there is one point not
explicitly stated in MIPv6, but it should be assumed, all these DOs (BU,
BA, BR and HA) are intended to the final hop. So they should appear after
Routing Header if there is. As a result, these DOs all appears after
Authentication Header, and be protected.

Regards,

Linfeng Yang

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Sep 2000 15:28:52 -0700

> conceptually the cleanest way (at least according to the current specs.) ...

Even in that case you need to carry some extra information between the
different extension header processing code.
In particular, while the AH processing can find the SADB entry using
the destination and the SPI (which doesn't require looking at
the home address option) the tail end of the AH processing might
very well include a check that the source address of the packet
is consistent with the SADB entry. Since the SADB entry is based on
the home address of the sender, this check can't be done until the
home address option has been processed.
(Whether your AH does a "peek ahead" to find the home address option
or you defer this part of AH processing until the destination
options have been processed is an implementation choice.)

If you look at the actual dependencies between the pieces of processing
you'll see that all possible orderings (including placing a destination
options header just before the AH header that some folks are proposing)
you need to carry some information around in all the cases.
It would be useful to actually look at the different cases in detail
to see if there are significant differences in implementation complexity.
The cases I can think of are
 - Home Agent option in destination options header before AH.
   Binding Update option in destopt after AH.
 - Both before AH - is there a difference in the ordering of the options
   within the destopt header?
 - Both after AH - does the option order matter here?

 Erik

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Sep 2000 09:36:11 +0200

=> exactly!

=> we have understood the same thing.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Sep 2000 09:42:11 +0200

Routing Header if there is.

=> I agree. In fact there is no DO defined for intermediate hops then
only pad DOs can occur in the RFC 2460 "first header".

   As a result, these DOs all appears after Authentication Header, and
   be protected.

=> An Authentication Header protects all headers, including headers before it.
The mobility draft specifies the home address DO must be before the AH
(then it amends RFC 2460 recommendations, both about DO header/security
headers order and about multiple final DO headers).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Sep 2000 10:07:09 +0200

=> AH processing is supposed to do a SPD and a SADB lookups then
the real source address (aka the home address) is a priori useful.
(another way to say the same thing)

=> in the mobility draft the home address option is before the AH then
this problem doesn't exist (ie. it is solved by the specification).

=> some folks = draft authors with the support of many of us.

=> I agree. The BU can be before or after the home address and the AH,
in the same or a different DO header than the home address.
If a correspondent node implements the optional BU processing then
it should be prepared to deal with all cases.

=> for me significant is mainly for:
 - mandatory features (vs optional features)
 - receiving side (vs sending/mobile node side)

    - Home Addrss option in destination options header before AH.

=> the only significant difference is when the Home Address option is
after the AH because it makes a real exception in security processing
(which is already complex). The BU position is not important (ie. doesn't
make a significant difference) then the current proposal is fine for me
(I've spent far more time in IKE tuning than in AH+mobility interaction).

Regards

PS: I've talked about SPD because it is the way IKE is involved (the SPD
is looked up, the policy requires AH/transport, a SADB_ACQUIRE is sent
to the registered IKE daemon). Of course the implementation can do this
ASAP and not wait for the first BU packet (PS: replace "can" by "should" :-).

---

From: Stefan Schmid <[email-masked]>
Date: Tue, 26 Sep 2000 09:51:06 +0100

> different extension header processing code.

  Yep, but I don't think there is anything wrong with that as long you don't
have to look ahead in following extension headers. I believe the proper way
should be to process the extension headers "in order" as they appear in the
packet.

> home address option has been processed.

  Exactly ;-) That's why we propose to put the home address option in the
1st Destination Options header (before the AH/ESP).

> options have been processed is an implementation choice.)

  Yes, but both is conceptually unclean.

> options header just before the AH header that some folks are proposing)

  Yes, we do ;-)

Regards,

- Stefan

---

From: Linfeng Yang <[email-masked]>
Date: Wed, 27 Sep 2000 16:19:08 +0300

> headers order and about multiple final DO headers).

Thanks your correction! Indeed it is clearly stated in Section 10.2. of
MIPv6 draft, but I did not check it last time and did not read Stefan's
mail thoroughly.

>  True, but using two extension headers is not difficult either ...

The paragraph following the note 3 of RFC 2460 Section 4.1 reads:

   Each extension header should occur at most once, except for the
   Destination Options header which should occur at most twice (once
   before a Routing header and once before the upper-layer header).

So, if there is a Routing header, HA should appear alone before it, or
with BU compose one DO, but not with two extension headers.

Shall we interpret the quoted paragraph this way also concerning HA and BU
DO -- if there is no Routing header, HA and BU must compose into one DO,
and it should appear immediately before upper-layer header. I added the
word, 'immediately', I think it is the underlying thought of the RFC. But
this interpretation conflict with I-D.

Or we can say the composed DO should appear before AH, and it surely
before upper-layer header too. No conflict, but I feel strange for this
interpretation.

Regards,

Linfeng Yang

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Sep 2000 16:49:27 +0200

=> this is modified by the mobile IPv6 draft which should state this
fact far more clearly.

=> yes, the I-D and the RFC conflicts.

=> I expect to get a clear statement about that in the new mobility draft.
For the moment the I-D (abusively) preempts RFC 2460 recommendations...

Regards