Subject: Re: [mobile-ip] question on protecting MN - HA communication

From: Marc Hasson <[email-masked]>
Date: Wed, 9 Oct 2002 18:16:21 -0700 (PDT)

Vijay,

On this note excerpt from you:

 > 
 > anyway, the new text in the HA-MN IPsec draft says
 > 
 >      - We have chosen to require policy entries that are specific to a
 >      tunnel interface. This means that implementations have to regard
 >      the Home Agent - Mobile Node tunnel as a separate interface on
 >      which IPsec SPDs can be based.
 > 
 > this is under implementations considerations. 

Is the term "tunnel interface" mandatory and to be taken literally for
implementations, not just here in an implementation considerations
section (which seems fine) but throughout the rest of the
mipv6-ha-ipsec-00 draft?

With all the ip routing configs possible, mobility binding info (when
established), and IPsec SPD/SA info already required I would think that
there is enough addressing/routing information so that some
implementations may not need/desire to actually have something thats an
actual "tunnel interface".  It should be possible without a "tunnel
interface" to ensure that the right (tunnel and other) headers per the
draft can still be generated on the wire(less) media for all the
required mobility payloads/signaling.

IPsec SPD entries may be based on the appropriate physical interface to
cause the right mobility tunnel/transport mode behaviors without having
to only exist on a "tunnel interface" as stated in the excerpt.  This
may be especially (only?) true with a closely-integrated IPsec/mobility
implementation, which has been stated as an eventual goal in various
IPSec/mobility drafts and notes I've seen.

Note that a MN may have some kind of IPsec (or at least firewall-level) SPD
on its physical interface configured anyway, if only to protect itself from
non-tunneled attacks while roaming.

In the subject draft I've been assuming that I can read statements like:

   "IF interface = tunnel to home agent &" (as in Hesham's original citation)

to be:

   "IF the following selectors would/should be tunneled to the home agent"

Do you or anyone else see any problems from this (minor?)
reinterpretation and/or issues from not having an actual "tunnel
interface"?  If not, then I'd like to see the draft seem less like its
*requiring* that implementation methodology though, of course, that may
still be the most convenient/efficient for some (most?) designs or
architectures.  So its fine to explain that in more detail in an
explanatory/appendix-like section.

I guess my summary point is that generation of outgoing tunnel headers
or inspection/validation of incoming ones doesn't require the
implementation of an actual "tunnel interface" construct.  I've
implemented tunneling multiple ways for past projects, each approach has
had its own pros/cons.  Implementers should be free to choose unless there
is some (currently unclear to me here) requirement for a specific approach.

   -- Marc --

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 09 Oct 2002 18:30:12 -0700

the draft says (somewhere), implementations are free to
choose whatever mechanism they want internally as long
as the packets on the wire look as described in the draft.

> Is the term "tunnel interface" mandatory and to be taken literally for

no.

> is some (currently unclear to me here) requirement for a specific approach.

absolutely.

Vijay

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 11 Oct 2002 16:03:19 +0200 (CEST)

> section (which seems fine) but throughout the rest of the

I think you are asking an implementation question and
not a specification question.

In terms of specifying protocols we use the term interface as defined in
RFC 2460:
   link        - a communication facility or medium over which nodes can
                 communicate at the link layer, i.e., the layer
                 immediately below IPv6.  Examples are Ethernets (simple
                 or bridged); PPP links; X.25, Frame Relay, or ATM
                 networks; and internet (or higher) layer "tunnels",
                 such as tunnels over IPv4 or IPv6 itself.

   interface   - a node's attachment to a link.

Per these definitions the attchment to the tunnel link is an interface.

However, for implementations that have a concept of "interface"
it is an implementation choice whether this be 1-1 with the interfaces
defined using the above terminology. As Vijay pointed out it is
the externally visible behavior that matters for interoperability.

One thing I haven't though about is RFC 2667 "IP Tunnel MIB".
If one implements that RFC one at least needs an ifindex in order to
represent the conceptual tunnel interface in the MIB. But presumably
even this can be handled without actually using the implementation concept
of an interface for the tunnel.

  Erik