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

From: Richard Draves <[email-masked]>
Date: Sat, 18 Nov 2000 21:48:24 -0800

>    Mandating that the Home Address option appear before the
> Fragment header
>    does not keep the door open for using ESP instead of AH.
> It slams the door
>    shut.
>
> => the door was already shut by RFC 1825 and 2401, ie. far before the
> first mobile IPv6 draft. I don't know if you propose to use ESP in
> transport mode but in this case "In general, a packet's source address
> MUST match the SA selector value" applies then this doesn't work.

I do have transport mode in mind, although I wouldn't want to preclude
tunnel mode.

You are referring to RFC 2401 5.2.1. That section does NOT preclude the Home
Address option from appearing after an ESP header. An implementation can
work as follows:
1. find the SA, based on destination address, SPI, and IPsec protocol
2. use the SA to authenticate and decrypt.
3. locate the Home Address & other selector values.
4. compare the selector values against those in the SA.
Steps 3 & 4 can either be done immediately after step 2 (which would require
looking ahead in the packet) or lazy-evaluated ie postponed until after some
processing of a following destination options header.

I have an existence proof that an implementation like this is possible. I
understand that your implementation doesn't work this way and that you don't
care to change it. If that's the basis for your argument, you should say so
- appealing to RFC 2401 won't work.

Rich

---

From: Francis Dupont <[email-masked]>
Date: Sun, 19 Nov 2000 19:36:44 +0100

You are referring to RFC 2401 5.2.1.

=> yes, the section which mandates the check of the source address as
the second step of inbound IPsec header processing:
 - this step must be done before the processing of the next IPsec header
   (then you proposal won't work directly with more than one IPsec header)
 - in this step the code is not supposed to look at the next header
   (but you can say this is implementation dependent)
 - many implementations do the check in the step 1 (lookup).
   I know this is not a RFC 2401 compliant behavior (the check is in step 2
   because in tunnel mode the source address to check is the inner one)
   but this likely interoperability problem IMHO justifies a MUST.

   That section does NOT preclude the Home
   Address option from appearing after an ESP header. An implementation can
   work as follows:

=> do you propose to change all IPsec implementations?

=> lazy-evaluation is not an option if you'd like to support the multiple
IPsec header case.

   I have an existence proof that an implementation like this is possible.

=> I never say it is not possible but it is not RFC 2401 compliant
(not a real problem if you keep the behavior without new security issues)
and this is *not* the way existent implementations (with one exception) work.

   I understand that your implementation doesn't work this way

=> KAME implementation what I use doesn't check the source address
(I don't matter because I have disable the tunnel mode)...

   and that you don't care to change it.

=> ask Itojun (:-). I am afraid that near all implementors won't care to
change their implementation when there is a simpler and cleaner solution.

   If that's the basis for your argument, you should say so
   - appealing to RFC 2401 won't work.

=> please bring the discussion to the IPsec mailing list. I'd like to
get the rationale for this section of RFC 2401 (and some others).