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

Re: [RRG] arguments for map and encap


On May 18, 2008, at 2:15 PM, Christian Vogt wrote:


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 assume you mean only translations whose functions are one-to-one and onto in a mathematical sense, and for which the inverse is trivially computed. Additional design considerations on translation vs. encapsulation are: 
- wire overhead
- state overhead at the translation or encap/decap points
- are the functions recursive
- traceability, fault isolation and debug
- attack surface (assuming the same threat model)



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.
While these things are separable in principle, I think that the indirection mechanisms are first-order considerations and we should not in fact leave this open or consider the issue separately. That's my opinion, anyway. 


 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.
True, but "looked up from elsewhere" could be state that is local to the translation points, or held by third parties and this makes a big difference. Also, when you look at the control plane, there may or may not be an explicit state setup protocol. What this winds up looking like is in fact not a detail but a really important part of the design and hence can't be pushed off as a secondary consideration. 


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.


This is really good - add it to my list of considerations above.


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.
As long as there are no circular dependencies, and that you build delay and possible quarantining complexities into the equation. 



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.
there could also be a protocol which establishes trust in an encapsulator. That way, although an encapsulator taken over by the enemy could inject packets spoofed from anywhere, you have a handle to use to damp an attack. 


 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.
Generally router folks cringe if you need to quarantine packets. This of course brings up the whole "how bad is dropping" discussion, which at the RRG meeting produced a lot more heat than light. 


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.
There is a difference between quarantining and sending the packet on a sub-optimal path. Do you think this deserves highlighting? 


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.
I see no problem with considering both seriously, but have misgivings about analyzing translation versus encapsulation independently of mapping. 


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.
Good points. Just as there are continuums in the mapping part between pure push and pure pull, and between directory-based and overlay topology based mapping. 

DaveO.


- 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