Subject: Re: [MOBILE-IP] Comment Please: Placement for Home Address option header

From: Richard Draves <[email-masked]>
Date: Thu, 9 Nov 2000 21:54:09 -0800

[Charlie]
> I'm trying to follow up on some discussion a few days ago
> about this point.  The last indication I received was that a
> node receiving a packet with an ESP header should be
> able to decrypt the payload using only the SPI and the
> destination IPv6 address.  I had always thought that the
> receiving node would want to use the mobile node's home
> address to select the correct security association.  Recent
> messages indicate that other implementations do not use
> that information; then they presumably do not use the
> IPv6 source address at all when identifying the correct
> security association.

RFC2401 compliant implementations find the correct security association
based on the destination address, SPI, and IPsec header type.

> This is a crucial point, and a decision should be made ASAP.
>
> There seem to be two additional relevant points:
>
> - We should pick a placement for the Home Address option,
>    and make it mandatory.  Doing so will simplify the implementation
>    for all the billions of correspondent nodes of the future.  We want
>    that implementation to be as simple as possible.  The two
>    candidate placements are either after ESP, possibly in the
>    same options header as the Binding Update, or else before
>    the Fragment Header.
>
> - Putting the information after ESP will make things substantially
>    more complicated for possible firewall management.

ESP might make firewall management more complicated, I won't dispute that.
But my point is that users & admins should have a choice of using AH or ESP.
In some environments, the appropriate choice might be ESP. In other
environments, AH might be an appropriate choice.

If the Home Address option follows an AH header, a firewall can still find
it easily. So if you want to be friendly to firewalls, have a policy of
using AH. But please don't prevent others from using ESP.

[Mohan]
> As there is no real benefit in putting it after AH/ESP header, i would
> suggest leaving it as it is i.e before AH/ESP header.

There is real benefit. If you put the Home Address option after, then you
can use either AH or ESP depending your policy/whim. If you put the Home
Address option before, then you must use AH because ESP won't protect it.

So to summarize, I think the spec should say the Home Address option and the
Binding Update option appear in the same destination options header, after
the IPsec header(s), and if AH is not used, then the Binding Update must
have a Care-Of Address suboption.

Rich

---

From: Francis Dupont <[email-masked]>
Date: Tue, 14 Nov 2000 11:54:42 +0100

In your previous mail you wrote:

=> and after each IPsec header processing they MUST check if the
source address matches the SA selector then the SA lookup is
not a valid argument.

=> I read "or" not "either". AH and ESP have different properties then
different usage.

=> and in some environments both are needed.

   it easily.

=> this is not true for fragments.

   So if you want to be friendly to firewalls, have a policy of
   using AH. But please don't prevent others from using ESP.

=> we don't want to prevent others from using ESP, I believe there are
many cases with both AH and ESP. And this is a case where the "after ESP"
placement doesn't work.

   [Mohan]

=> but as you can use both then I can't see a problem here?

   the IPsec header(s),

=> this simply doesn't work if you have AH then ESP (then HA & BU) or
a paranoic IPsec implementation (which does the selector check at
lookup time, this is not in RFC 2401 but is very common).

   and if AH is not used, then the Binding Update must
   have a Care-Of Address suboption.

=> I agree, if the protection is not done by AH then there must be an
alternate care-of address suboption in order to protect the care-of.

Regards

[email-masked]