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

From: Charlie Perkins <[email-masked]>
Date: Thu, 9 Nov 2000 04:44:55 -0800

Hello,

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.

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.

Based on this evidence, I am leaning towards a mandatory placement
before the Fragment Header.  As soon as I can determine consensus
on this point, I am ready to issue a revised (and hopefully last)
Internet Draft for Mobile IPv6.

Thanks for your comments!

Regards,
Charlie P.

---

From: "mohan.parthasarathy" <[email-masked]>
Date: Thu, 9 Nov 2000 14:31:15 -0800

> IPv6 source address at all when identifying the correct
RFC 2401, section 5.2.1 step(2) does mandate verifying the
SA with the source address in the IPv6 header. There are
actually two parts. One is locating the SA which uses
only SPI and destination address. The other is verifying whether
the SA is right or not. For this, you need to know the source
address.

The conclusion is it does not really matter where the home
address option is. As SA verification could mean more than
just verifying addresses e.g. you may have to verify ports,
then you need to get all your SAs and then finally do
the verification as ports are not visible in the case of ESP.
This means that Home address option would be traversed
while doing so.

>    same options header as the Binding Update, or else before
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.

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Fri, 10 Nov 2000 17:59:16 +0100

In your previous mail you wrote:

=> the current IPsec spec (RFC 2401) is not very clear but:
 - the source address should not be used by the lookup of the SA
 - the source address should be used by post-processing checks
I have looked at 4 free implementations:
 - all of them don't use the source address for the SA lookup
 - two of them do the check of the source address at the end of
   the SA lookup then the source address must be available (ie.
   the header with the home address option must be before the first
   IPsec header)
 - only one of them don't check the source address after the processing
   of a IPsec header in transport mode
Conclusion: if the home address is not available after the processing
of *each* IPsec header then we'll kill near all IPsec implementations
(ie. someone will say we'll kill all compliant implementations), if
it is not available before any IPsec header then we'll kill all paranoic
implementations (at least one half IMHO).

=> I agree. According to RFC 2401 section 5.2.1 (1) and (2) the placement
after ESP is not possible then only the placement before the fragment
header doesn't badly interfere with (mandatory) IPsec.

=> simply doesn't work: if you have AH then ESP, AH is mandatory and
this order is the preferred one for many reasons (it is enough that
it is a legal order BTW) then the AH processing will fail at the (2)
(selector check) of RFC 2401 (*).

=> I think this placement is the best one and I agree this should be
mandatory.

Thanks

[email-masked]

* PS: RFC 2401 Section 5.2.1:

   ... Note that the
   selector checks are made on the inner headers not the outer (tunnel)
   headers.  The steps followed are:

           1. Use the packet's destination address (outer IP header),
              IPsec protocol, and SPI to look up the SA in the SAD.  If
              the SA lookup fails, drop the packet and log/report the
              error.

           2. Use the SA found in (1) to do the IPsec processing, e.g.,
              authenticate and decrypt.  This step includes matching the
              packet's (Inner Header if tunneled) selectors to the
              selectors in the SA.  Local policy determines the
              specificity of the SA selectors (single value, list,
              range, wildcard).  In general, a packet's source address
              MUST match the SA selector value.
              ...

              Do (1) and (2) for every IPsec header until a Transport
              Protocol Header or an IP header that is NOT for this
              system is encountered.

(the last statement is very important for the AH then ESP sequence).