Hello Francis et al.,
I am writing this note in response to your note, appended after
the main body of this note. I have been studying the issues
relevant to the placement of the Home Address option and the
Binding Update option, in preparation for making a new revision
for Mobile IPv6. It is a tough problem.
I agree with you that the existing choices for ordering AH
and Destination Options are not sufficient. In my mind,
the first and most serious error, that affects the placement
of the Home Address option, is it has to go before AH, but
there is no need at all for it to be processed by the
intermediate routing points of a routing header.
Therefore, I'd like to suggest that in the Mobile IPv6
specification, we enable the placement of Destination Options
after the Routing Header, but before the Fragment Header.
This will enable the correct placement of the Home Address
destination option, and it will greatly simplify any needed
firewall treatment.
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 PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
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 PROTECTED],
PS *: to put the HA option after the BU option is a favorite in
the UNH mobile IPv6 test suite...
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
