Re: state loss detection

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

On 13-jul-2005, at 16:01, Erik Nordmark wrote:


> > It just occurred to me that the state loss problem may not be as   
> > intractable as we thought.


> FWIW I don't think it is intractable. An error message "no shim6  
> context" and 8 or so protocol numbers is all that's needed to do  
> this without any byte overhead in the shim6 data packets.

Ok...


> > it may be a good idea to  rewrite the checksum too, in order to  
> > avoid confusing firewalls and  the like unnecessarily, and to  
> > maintain compatibility with NICs that  do checksum offloading.


> I see a few problems with this:
> 1) The transport checksum no longer protects against packet  
> misdelivery to another IP address. Thus in the odd case that the  
> shim6 state has been lost, but there is some transport state which  
> matches the IP address fields and port numbers, the packet will  
> potentially be accepted by the transport (subject to sequence  
> number checks in the case of TCP).

Is this a realistic scenario?

I mean, hosts A and B must have a session, say using A1 and B1. Then  
there must be a rehoming, so now the packets flow between A2 and B2.  
Then, B loses state. A continues to send packets from A2 to B2. So  
obviously for a new session to clash with the existing one, either A  
must have set up a new session (which it wouldn't) or B would have to  
do it. Since A would presumably reject such a session if the protocol  
has a notion of sessions (ie, certainly TCP and probably UDP) there  
is only a window between the time B is setting up a new session and A  
hasn't rejected it. TCP and most UDP protocols use a sequence number  
or transaction id, so the chance of anything happening here is very  
small.

Alternatively, the protocol may not know about sessions. However:

- these protocols may not have checksums
- we (the shim) may not know where the checksum is in the packet
- we can selectively enable/disable checksum rewriting per protocol

So if we assume checksum rewriting will only be done for TCP and UDP,  
do you think the very small chance of session clashing is more  
important than the likelihood of confused firewalls and the  
fundamental inability to offload checksum calculations to the NIC?


> 2) Rewriting the transport checksum is hard when the packet is  
> protected by IPsec.

That's a feature.  :-)


> It is "just" an implementation chore in the normal case of a host  
> doing shim6, but if you ever want to have shim6 proxies/middleboxes  
> (to help with a transition to shim6) then this becomes intractable.

When there is encryption, there is no problem since we can't rewrite  
the checksum even if we wanted to.

For authentication-only IPsec it's still possible to do this. Since  
the authentication makes sure we have to write back the correct  
original checksum we basically get to have our cake and it it too.

Alternatively, we could only rewrite when the TCP or UDP protocol is  
the first header after the IPv6 header. I think we have to talk to  
NIC vendors.


> 3) Transport protocols unknown to the shim6 implementor (could be  
> implemented in some unrelated kernel patch, or in user space using  
> raw sockets) would need to trigger a shim6 state refresh in this  
> case. But the implementor of that (user level?) transport protocol  
> might not be aware of shim6.

This can be handled in several ways:

- well, learn about the shim then
- ignore this, live with the longer timeouts
- use extra bits or possibly and extra header for these protocols

What's important is that we get TCP and UDP right in an efficient  
way, because TCP is the most used protocol and UDP is often used with  
small payloads so any overhead there is especially bad.