[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