Re: tunneling [Was: Agenda for Vienna]

[Iljitsch van Beijnum <iljitsch@muada.com>]

This message was supposed to go to my drafts folder but I must have hit 
send...

On dinsdag, mei 20, 2003, at 17:14 Europe/Amsterdam, Iljitsch van 
Beijnum wrote:

> > To do this compression would require some packet exchange to 
> > establish the
> > state thus for delay reasons it might in some cases make sense to be 
> > able
> > to start sending "uncompressed" packets in parallel with such state 
> > being
> > established.
> I see three ways to do this. See the link to a draft I posted on this 
> list last week 
> (http://www.muada.com/drafts/draft-van-beijnum-multi6-2pi1a.txt) where 
> I tried to make this work with as little state as possible. The 
> destination identifier in packets to the server is implied, as the 
> server can map the locator address used to the identifier without 
> maintaining any per-session state. For the client address we can't do 
> this so I decided to encode the alternative prefix into the address in 
> addition to the regular prefix.
Five ways. The above uses two different ones for servers and clients:

1. Encoding the locators in the identifier
2. Looking up the mapping from the identifier to locators somewhere
3. Negotiate the mapping before communication happens (like the ISAKMP 
protocol does) but this requires some bootstrapping mechanism
4. Negotiate the mapping during session start
5. Send the packet and receive the mapping state if there is any

I think the simple DNS approach is a good choice to start with unless 
depending on the DNS isn't acceptable. Option 5 could be a reasonable 
alternative if we decide we have to go with crypto (which I personally 
don't care for).

But it's hard to know at this stage what the best approach is, and 
there probably isn't a single best approach. So what I'd like to see 
happen is that we select the simplest option as a default mechanism 
that everyone must implement, but keep the option open for the user to 
override this default behavior in a way that doesn't make the 
implementation too complex.

This could solve the policy problem in enterprises. People running 
enterprise networks have told us they absolutely positively need 
mechanisms to implement traffic engineering and other policies and not 
depend on what any particular host decides is the best way to route a 
packet. With this hook in place hosts could run a daemon that asks some 
central servers about the mapping state and source/dest locator 
preference whenever a session is initiated to a destination for which 
there is no mapping state yet. (A stateless way to see if a destination 
is multihomed or legacy v4 would be good here.)

This has the additional benefit that the dependence on the DNS isn't so 
bad anymore. Mapping information for known correspondents can be cached 
on local storage and periodically updated rather than resolved whenever 
the information is needed.

> > And perhaps such state should be optional. It isn't likely to be 
> > harmful
> > when the tunnel endpoint is the host, but there might potentially be
> > scaling issues when the tunnel endpoint is some form of per-site 
> > proxy.
We can make receiving stateless if we create our own mapping for 
sending and depend on return routability. This wouldn't lead to worse 
security problems than regular IP. So if we can make mapping from the 
identifier to the locator for sending stateless we're in stateless 
business.