Re: [tcpm] draft-ietf-tcpm-tcp-auth-opt-00

[Joe Touch <[e-mail]>]

Adam Langley wrote:
...
...
>> TCP already includes a 16-bit counter - the sequence number. The use of
>> longer counters that retain the high-order bits of that number were
>> discussed in Philadelphia.

(I had the IP ID on my brain; it's a 32-bit counter, as noted below).

> The security properties of these functions usually depend strongly on
> the condition that no two messages be transmitted with the same nonce.

Note that the inclusion of the IP ID may help in this regard; not only 
does the 32-bit seqno need to be repeated, but so does the ID; overall, 
the pair of those two should could be sufficient for statistical 
uniqueness (although, if we relax the ID requirement as per my intarea 
draft, that might not be the case)...

We talked in Phila about the use of either counters for the high-order 
bits of the 32-bit space, or about the use of rekeying to handle this.

>> The key problems involve retransmission at the
>> edge of counter wrap; a goal of TCP-AO is to avoid modifying the TCP
>> protocol itself. As you note, there didn't seem to be a good solution here.
> 
> I don't see that's a big problem: The host maintains a belief of the
> high 32-bits (H) of the counter and the last low-32 bits that it saw
> (L). For each packet with a new sequence number (S):
>   If the distance from L..S is < S..L (mod 2**32) then assume
> out-of-order reception; if L...S crosses a rollover, decrement H. L <-
> S.
>   Otherwise, if S..L crosses a rollover, increment H. L <- S
> 
> This can be confused by massive reordering. However, that just leads
> to the packet being rejected and it's probably been retransmitted
> anyway. Also, if a huge number of packets were lost the hosts could be
> knocked out of sync. Some additional logic could cope with this
> (assume it might have happened and check the MAC for another sequence
> number), but I believe that the window would have to be about 2GB big
> for this to happen.

IMO, this is much more effectively handled by rekeying. Doing so every 
4GB (or even twice as often) should be more than sufficient.

Joe

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm