RE: shim - transport/app communication

["Bound, Jim" <jim.bound@hp.com>]

Erik, down at my end will respond when I can thanks for this thread.
/jim 

> -----Original Message-----
> From: Erik Nordmark [mailto:erik.nordmark@sun.com] 
> Sent: Monday, March 21, 2005 4:29 PM
> To: Bound, Jim
> Cc: Kurtis Lindqvist; Pasi Sarolahti; ext Iljitsch van 
> Beijnum; Leif Johansson; shim6@psg.com
> Subject: Re: shim - transport/app communication
> 
> Bound, Jim wrote:
> 
> >>Nobody has proposed changing the IP addresses that are seen 
> >>on the wire. 
> >>All we are changing is to add a dynamic mapping between what IP 
> >>addresses the transport and above sees (the ULIDs) and the IP 
> >>addresses 
> >>the routing system sees.
> > 
> > 
> > That is not crystal clear to me in the spec above at all.
> 
> OK. If you have specific things that are unclear I can make a pass at 
> clarifying those in the next rev.
> 
> 
> > Something different.  Map an TCP request to an SCTP request 
> as if the
> > transport selected was SCTP.
> 
> But that has quite more limited applicability than a shim.
> First of all, the peer need to do the same (which is also the 
> case for 
> the shim) thus you need a very performant approach to 
> failback to using 
> TCP when the peer doesn't support this. It is hard for me to see an 
> approach using SCTP that can be as efficient as the shim, because the 
> shim defers its work thus there is no extra work (state or 
> packets) for 
> short-lived connections.
> But the SCTP providing the TCP socket API also has the issue that the 
> SCTP protocol can't provide the identical service as TCP, 
> with all the 
> details of TCP urgent data being the prime example. Even if almost no 
> applications use that aspect of TCP, it means that you can't 
> claim 100% 
> compatibility for the SCTP approach, whereas the shim can 
> make such a claim.
> Finally, SCTP doesn't help for UDP communication.
> 
> So while SCTP has many useful features, I don't see it as the 
> ideal fit 
> for something that we want to shim in under existing applications and 
> have everything work without application changes.
> Thus I'm interesting in figuring out how SCTP and the shim 
> can work well 
> together for the many cases where SCTP is the right transport 
> protocol 
> to use.
> 
> 
> >>I'd like to understand why you think a DST option in every 
> packet is 
> >>necessary. Such a thing would be complete untrusted.
> > 
> > 
> > Yes the trust would be a problem.  Could be reference to 
> look for ULID new
> > extension header then which could be encrypted with IPsec 
> then.  The reason
> > to pass the ULIDs is to save processing on each node for 
> mapping to them at
> > the transport and above.  This shim now will require a 
> search for ULID on
> > every packet. Providing the ULID in the packet avoids that 
> on every system?
> 
> If you want intermediaries (middleboxes) to use the ULID, 
> then carrying 
> it encrypted doesn't help, since they either don't have the 
> key (hence 
> can't decrypt to read the ULID), or they have the key and can 
> spoof the 
> ULID and thereby fool the next middle box.
> 
> For the endpoint, the processing to lookup the context state and find 
> the ULID is quite small, and in the common case of the ULID being the 
> same as the locator (which is the case before any failure has 
> happened)
> close to zero.
> For example, if the shim and no failure happens, the packets would be 
> the same as today (IPv6 followed by TCP, for instance) and the shim 
> would be close to a no-op. (I say "close to", because the shim might 
> want to count the number of packets so that it can determine whether 
> this is a long-lived communication i.e. whether it is worth-while to 
> establish multi6 state so that the communication can be 
> rehomed should a 
> failure occur).
> After a failure has occurred and the communication has been 
> rehomed to 
> use a different address pair, then the receiver needs to lookup the 
> context state and modify the packet before passing it to TCP etc.
> That does entail a lookup operation, but depending on details in the 
> protocol design it might be possible to have this be just an array 
> lookup based on an index in the packet (that's part of what 
> the receive 
> side demultiplexing issue is about in the shim draft).
> 
> >>Thus it would be 
> >>better if middleboxes that want to do verification either
> >>  - get explicitly signaled from the endpoints so that they 
> >>have the list
> >>    of IP addresses
> >>  - observe the sim6 signaling protocol and do the same 
> >>verification as
> >>    the endpoints do as a way to discover the list of IP addresses
> >>Both of those can be reasonably secure.
> > 
> > 
> > Yes that is possible but was trying to avoid this and keep 
> e2e only and as
> > needed also if they change that can be accomodated too.
> 
> Agreed.
> 
> I was confused and thought you wanted the DST option for 
> middleboxes and 
> not for the endpoints.
> 
>     Erik
>