Re: [RRG] arguments for map and encap

[Christian Vogt <christian.vogt@nomadiclab.com>]

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.

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