Re: shim6 and bit errors in data packet headers

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Erik,

Erik Nordmark wrote:
> Greg Daley wrote:
>
> > In some circumstances, there may be a port unreachable response before
> > the checksum is even consulted (UDP-Lite).
>
>
> If that's the case it sounds like a bug in UDP-Lite. UDP-lite can verify 
> the checksum (which only covers part of the payload unlike UDP), before 
> it generates the ICMP error.

Sorry about that: rfc3828:

"The UDP-Lite header MUST always be covered by the checksum."

I was importing bad IPv4 knowledge without checking carefully.

> > I believe that there's a chance of additional responding port
> > unreachables or resets for flows which match but do not have upper layer
> > sessions for the flow (since it is tied to different IP addresses).
>
>
> There is a small probability, but not qualitatively different than for 
> IPv6 itself. For this to happen the bit error would have to be such that 
> the resulting packet is ok according to the TCP/UDP/ICMP checksum.
>
> When this low probability even happens in IPv4 or IPv6 today, the result 
> is quite unpredictable. Could cause undetected data corruption in the 
> application payload.
>
> I don't think the indirection via the shim (which would change the 
> locators to ULIDs for the incorrectly matched context) changes much in 
> terms of the probability.

Agreed.

[cut]
> But we also get loss of state when B has rebooted, and lost all state.
> In this case B would be unable to deliver any higher-level error (TCP 
> reset, UDP port unreachable) until it either has reacquired the shim 
> state, or convinced A to send using the ULIDs as locators (so no receive 
> side address field replacement is necessary).

This is likely to be one of the big issues.

There may be varying degrees of state loss.  One of the hosts
may lose one of its ULIDs, which could make session reestablishment
tricky (trying to bind to an identity which doesn't exist).

This is clearly an error condition, but sending responses from an
address in the destination locator should be able to show that this
is a legitimate response.

For example, if a CGA or HBA locator exists while an identity has been
lost, then packet reception can be validated using the already known
parameters for this HBA on the notified receiver, so that it can
distinguish errors from DoS.


Otherwise, more expensive timeout operations may need to occur,
before other state is removed, or procedures retried.
This is what would happen if the host lost its CGA/HBA locators too
(and didn't receive the packet).

Greg