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

[Jari Arkko <jari.arkko@kolumbus.fi>]

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