[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [RRG] arguments for map and encap



Christian, 

>-----Original Message-----
>From: Christian Vogt [mailto:christian.vogt@nomadiclab.com] 
>Sent: Sunday, May 18, 2008 11:16 AM
>To: Michael Meisel; Dan Jen
>Cc: Routing Research Group Mailing List
>Subject: Re: [RRG] arguments for map and encap
>
>Dan and Michael,
>
>I would like to make the observation that, by advocating map and
>encap, one actually promotes two separate concepts:
>
>- indirection between address realms (map)
>- tunneling as a means to represent indirected packets (encap)
>
>The arguments you put forth in favor of map and encap are in fact
>arguments for only the 1st concept, address indirection.  Your
>arguments would still hold if tunneling (the 2nd concept) was replaced
>by address translation as a means to represent indirected packets.
>
>I hence suggest to seek consensus more generally on "address
>indirection", instead of more specifically on map and encap -- and to
>leave it open, for now, how to represent indirected packets.  Below I
>provide more rationale for this by (i) looking at how tunneling and
>address translation differ conceptually, (ii) discussing what these
>differences mean in the context of address indirection, and (iii)
>concluding that tunneling and address translation are both valid
>alternatives.
>
>The difference between tunneling and translation is in the amount of
>information about the original appearance of an indirected packet,
>that is explicitly included in the indirected packet.  With tunneling,
>all information needed to reestablish the original appearance is
>included in packets.  With translation, information must be looked up
>from elsewhere.
>
>Including explicit information in indirected packets avoids state at
>the receiving side (where the original appearance of the packets is to
>be reestablished) *if* this information is trustworthy.  Avoiding
>state, in turn, increases robustness to route changes, because the
>route of packets depends less on information stored on entities on any
>particular route.  Robustness to route changes is clearly an
>attractive property.  It is one of the fundamental principles of IP,
>and should be upheld by any new routing architecture.
>
>But is tunneling the only way to facilitate robustness to path
>changes?  I argue it is not:  State at the receiver could also be
>avoided by storing it in an infrastructure, thus making it retrievable
>by any entity on a new route after a route change.  More generally
>hence, robustness to route changes requires that...
>
>(a)  the information needed to reestablish the original appearance of
>      an indirected packet is retrievable by any network entity that is
>      to perform the reestablishment, independent of the route of the
>      packet, and
>(b)  the source of that information is trustworthy.
>
>Tunneling is one way to achieve (a).  Yet tunneling alone does not
>satisfy (b) because it does not protect against spoofing an inner IP
>header.  An extra mechanism is needed for validating the mapping
>between original and indirected addresses, such as per-packet
>signatures as previously proposed by Noel, or by inquiry in a trusted
>infrastructure.  Per-packet signatures would come at the cost of
>per-packet overhead.  Inquiry in an infrastructure would come at the
>cost of delay, although the validation result could be cached so that
>the delay affects at most the 1st packet in a session and the 1st
>packet after every route change.  The trusted infrastructure that is
>consulted for mapping validation at the receiving side could be the
>same infrastructure that the sending side uses for mapping resolution.

Your analysis of (b) I think was rather well stated. Just as
examples of existing map-and-encaps schemes, ISATAP (RFC5214)
validates mappings via inquiry in a trusted infrastructure
exactly as you say. Per-packet signatures on the inner packet
are also possible, but not on the outer packet header (which
may not be necessary if the inner packet has a signature).

Additionally, VET (draft-templin-autoconf-dhcp) updates ISATAP
by introducing an expanded domain of applicability that allows
tunnel-mode IPsec encapsulation between the inner and outer IP
layers. This provides a per-packet signature that applies to
both the inner and outer layers.

Thanks for this informed post,

Fred
fred.l.templin@boeing.com 

>Address translation requires mapping resolution via some
>infrastructure at the receiving side to satisfy (a).  If the
>infrastructure is furthermore trusted, (b) is satisfied at the same
>time.  Again, this would come at the cost of delaying at most the 1st
>packet in a session and the 1st packet after every route change,
>assuming the resolution/validation results are cached.
>
>Overall, this shows that tunneling (encap) and address translation are
>alternatives with similar properties in terms of robustness to route
>changes.  I therefore believe that limiting RRG's design space to map
>and encap is too restrictive.  While I would be favorable to limiting
>the design space to address indirection in general (map), RRG should
>IMO continue to be allowed to consider alternatives to tunneling, such
>as address translation, as a way to represent indirected packets.
>
>Lastly, it is noteworthy that there is a continuum of methods for
>representing indirected packets; pure tunneling and pure address
>translation are just the two extremes.  E.g., indirected packets could
>carry only their original source address in an extension header, but
>not the original destination address.  This method would rely on
>knowledge at the receiving side to perform the trivial mapping of the
>packets' destination address.
>
>- Christian
>
>
>
>--
>to unsubscribe send a message to rrg-request@psg.com with the
>word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
>

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg