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

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