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

Re: [RRG] arguments for map and encap

Hi David -


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.


At this point, I was deliberately talking about translation in
general, be it 1-to-1 or 1-to-many.  But yes, we are in complete
agreement that 1-to-1 translation is advantageous.  I was coming to
that later in the email, when talking about robustness to path
changes.

In this spirit, I am currently modifying Six/One Router to use
1-to-1 translation.  Address translation as used in Six/One Router
then differs from classic NAT boxes in two main aspects:

- Global host reachability -- Hosts behind a classic NAT box cannot
 be contacted from hosts on the other side of the NAT box because
 they use non-unique addresses.  Differently, hosts in Six/One-
 Router-capable edge networks use globally unique edge addresses.
 So they can be contacted from hosts elsewhere in the Internet.

- Robustness to route changes, as previously discussed -- Classic NAT
 boxes limit a network’s ability to reroute traffic in case of path
 failures because they build up dynamic state that communication
 sessions depend on.  The reason for having that state is that NAT
 boxes multiplex multiple host addresses onto a single translated
 address.  They need the state to perform the reverse operation,
 the demultiplexing from a translated address onto the correct host
 address.  With 1-to-1 translation, Six/One avoids address
 multiplexing, so rerouting between different paths is not a
 problem.

One may even claim that 1-to-1 translation between globally unique
edge and transit addresses does not break end-to-end semantics (though
this is clearly a personal opinion).  What is commonly associated with
"end-to-end semantics" is that the addresses that a packet receiver
sees are the same as the addresses the packet sender has used.  But
specifically and architecturally, what advantage does this have?
(...Other than not confusing protocols that have been build on the
assumption that addresses do not change in flight.)  Isn't the true
meaning of end-to-end semantics covered by global host reachability
and robustness to route changes, as long as there is a working route?


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)


Yes, excellent.


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.


No problem.  What I meant was that we shouldn't limit ourselves to
tunneling without discussing the alternatives.  Didn't mean to suggest
postponing the discussion -- although, re-reading my own text, I
certainly was unclear in this regard.


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.


Oh yes, fully agree.

One observation that may be input to this discussion is that the
requirements in things address mapping are very similar for the sender
and the receiver, yet the solution spaces are different.

Regarding requirements, sender and receiver both need access to
address mapping information that provably originates from the owner of
the edge address ("identifier") in the mapping.  The sending host
needs it to accomplish the edge-to-transit mapping of the destination
address in a packet; the receiving host needs it to validate the
transit-to-edge mapping of the source address in the packet.

The solution space for the sender coincides with the solution space
for mapping resolution systems (including systems that can route
packets based on identifiers via a sub-optimal path).  The solution
space for the receiver is a true super-set of this.  In addition to
re-using the mapping resolution system for the purpose of mapping
validation, it also includes in-packet information, such as the edge
addresses in inner tunnel headers.  Either way, the mapping must
provably originate from the owner of the edge address.


(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.


By "quarantining", do you mean buffering?


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. 

Yes.  You could use ALT for this -- by adding an unguessable nonce to
the request packet, and requiring the mapping response to echo this
nonce back.  Such "routing based on identifiers" is exactly what
Mobile IPv6 does during a home address test (exchange of Home Test
Init and Home Test messages), or what DNS does by traversing a tree of
administrative relationships.  Although neither Mobile IPv6 nor DNS
piggyback their requests onto datagram packets.


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?


This is correct, but note that routing based on edge addresses (via a
sub-optimal path) is an option only for the sender.  The receiver
doesn't have this option when it comes to validating the mapping for a
received packet.  (Of course, the receiver could use the "sub-optimal
path infrastructure" in order to validate a mapping.  But this would
alleviate it from having to buffer the packet in the meantime.)
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. 

Yep, as noted above, this would in fact be completely alright with me.

Thanks for this nice discussion!

- 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