Re: [tcpm] tcp-auth-opt issue: replay protection

On Wed, Jul 30, 2008 at 3:22 PM, Joe Touch <touch@isi.edu> wrote:
> 1. assume the key management system (KMS) will rollover the keys every
> 2^31 bytes
>
>        Eric noted this is weak, since we cannot rely on the KMS
>        to act on this without other info. Let's presume this
>        is unacceptable to the WG and move on...

I don't really like this solution, but I don't think it's too bad.
Here's what my test impl's currently do:

Each direction has a TX key and two valid RX keys configured. From the
point of view of a sending application, which keeps track of the
number of bytes sent:
  If I'm just about to cross a 2**31 bytes boundary, install the next TX key.

This means that retransmissions of some bytes with seq numbers less
than the boundary get the new key, but that's not a huge problem.

On the receiving side (for a given half-connection):
  From the current number of bytes received (n), ensure that keys for
n - 2**30 and n + 2**30 are installed as valid RX keys.

This ends up meaning that RX keys are rotated ever 2**31 bytes with a
2**30 byte phase.

This is fine so long as the window is < 2**31 bytes (which is defined
by the window scaling spec at the moment)

> Given that algorithm, every ESN increment would trash data in transit
> from A-B. Is there an algorithm that does not do this?

This seems an odd ESN to me:

The ESN is just a 64-bit sequence number. The SEQ field in the TCP
header is just the lower 32-bits of this counter. Thus, for the
half-connection from A to B, A knows the ESN exactly for every packet.
For a packet recved by B, it guesses the ESN based on the closest
value to it's last understanding. An example for B:

At the beginning of the connection, B knows the ESN for the A->B half
connection exactly: top 32-bits are 0, bottom 32-bits from the
handshake.
For each packet recved it gets the low 32-bits of the ESN, now assume
that that the ESN is the closest of the 2**32 possible ESN's to the
previous value of the ECN.
Update the previous value with this new guess.

This is very easy code.

Any packets which are reordered > 2**32 sequence bytes will be
misclassified and dropped, but 2**32 sequence bytes is a long way.

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm