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

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 4 Oct 2000 08:15:32 -0700

Hello again Francis,

This is in further response to your note, appended below,
but regarding the placement of the Binding Update option.
I made two notes, because I thought that the IPng mailing
list would not be interested in this part.

The Binding Update, as you and others have mentioned, could
reasonably go either in the same Destination Options header
as the Home Address option, or after AH.  It seems to be a
matter of convenience.  The Binding Update option seems to
have less needs for protection against snooping than the IPv6
header.  In other words, if one wanted to protect the Binding
Update, then one would also want to protect the preceding
IPv6 header.  That implies to me that the main good
reason for requiring the Binding Update to go after AH,
except possibly for natural processing requirements.
On the other hand, the latter is a good reason!

I do see that we should make a definite specification for
particular placement of the Binding Update.

I would like to make the following proposal for discussion.

- Allow Home Address option to be placed after the routing
  header but before the fragment header (as mentioned earlier)
- Require Binding Update to occur after AH.

The cost is additional header bytes, but the benefit is
more natural header processing.  I think that we ought to
get this issue settled ASAP, with a specific placement, and then
try to get some mileage out of using header compression to squeeze
the bytes back out again.   Using header compression might be more
efficient if there are fewer possibilities for placement.

Regards,
Charlie P.

-------- Original Message --------
Subject: Re: [MOBILE-IP] Implementation Issues re MobileIP and IPSec
Date: Tue, 1 Aug 2000 21:16:56 +0200
From: Francis Dupont <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]

 In your previous mail you wrote:

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

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

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

=> the second MUST is yours and obviously is incorrect because I can implement
this with only one DO 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?

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

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

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

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

=> 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: Francis Dupont <[email-masked]>
Date: Thu, 5 Oct 2000 14:47:11 +0200

=> this argument (natural processing) was shared by a majority
of the people here at ETSI bake-off (ie. most of us would like
to execute the binding update when the option is found then
it must be after the home address option and the authentication
header, according to mobile IPv6 + IPsec requirements this gives
exactly the "note 3" position, ie. after IPsec headers (including
the required AH)).

=> and use the same for other binding options ("previous" draft
is not enough accurate about this then we have this discussion).

=> this is good for us.

=> anything is simpler and more efficient with fewer possibilities.
Obviously the "previous" draft has too much freedom there...

Thanks

[email-masked]