Re: Comments on draft-ietf-mobileip-mipv6-ha-ipsec-04.txt

[Bernard Aboba <aboba@internaut.com>]

Thanks. Looks good.

On Mon, 31 Mar 2003, Jari Arkko wrote:

> One final thing. The IP-in-IP encapsulation + transport mode vs.
> IPsec tunnel mode encapsulation. You wrote:
>
>  > "When IPsec is used to protect return routability signaling or payload
>  > packets, the security policy database entries SHOULD be defined
>  > specifically for the tunnel interface between the mobile node and the
>  > home agent. That is, the policy entries are not generally applied on
>  > all traffic on the physical interface of the nodes but rather only
>  > on the traffic that enters this tunnel."
>  >
>  > Maybe I'm not understanding what you mean here, but this looks to me like
>  > special case IPsec processing. My understanding is that the processing
>  > described above is somewhat more akin to what occurs with transport mode
>  > IP-IP encapsulation than with tunnel mode. See the following draft for more details:
>  >
>  > http://www.ietf.org/internet-drafts/draft-touch-ipsec-vpn-04.txt
>
> I have read the draft now. Actually, I don't fully agree with the
> draft. It seems to say that interface is not a required component
> in IPsec policy processing. Yet RFC 2401 says "Each interface for
> which IPsec is enabled requires nominally separate inbound vs.
> outbound databases (SAD and SPD), ..." and RFC 2460 indicates in
> Section 2 that the term interfaces / links should include also
> tunnels.
>
> Nevertheless, I do agree with the touch-ipsec-vpn draft in the sense
> that there are implementations that don't fully support interface-specific
> policies.
>
> So where does this leave us? I have the following proposal:
>
> - Change the current language so that it doesn't dictate a particular
>    implementation of tunnel interface. So the text above would change
>    to
>
>       "When IPsec is used to protect return routability signaling or payload
>        packets, the security policy database entries SHOULD be defined
>        as if they were specifically for the tunnel interface between the
>        mobile node and the home agent. That is, the policy entries are not
>        generally applied on all traffic on the physical interface of the
>        nodes but rather only on the traffic that enters this tunnel."
>
>     I added the well known "as if they were" wease words to make it
>     clearer that the implementation does not matter as long as the
>     results are the same on the wire.
>
> - Add an informational reference to touch-ipsec-vpn:
>
>       "Note that this requirement is similar to the approach taken
>        in dynamically routed VPNs [ref]."
>
>  > Note also that in various places in the document, tunnel mode is required
>  > in preference to transport mode IP-IP, even where manual keying is used.
>  > Since the two are identical on the wire (the difference is in how they are
>  > negotiated within IKE), I am not sure how such a preference can be
>  > enforced.
>
> I added this text to the first case where we talk about TUNNEL mode:
>
>       "Note that this specification concerns itself only with on-the-wire
>        formats, and does not dictate specific implementations mechanisms.
>        In the case of IPsec tunnel mode, the use of IP-in-IP encapsulation
>        followed by IPsec transport mode encapsulation may also be possible.
>        The tradeoffs related to the use of tunnel mode and IP-in-IP encapsulation
>        have been discussed in [ref]."
>
> If this is agreeable to you, I think we have addressed everything
> that you raised in your e-mail. Changes are no the web.
>
> Jari
>