Christian, >-----Original Message----- >From: Christian Vogt [mailto:[EMAIL PROTECTED] >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 [EMAIL PROTECTED] >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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
