Re: [TLS] What's the proper alert for sequence wrap.

[Eric Rescorla <ekr at networkresonance.com>]

<home_pw at msn.com> writes:
> Lets assume we are in a connectionless environment, and the bearer is
> Not UDP/IP.  Its just ethernetv2. Assume we are NOT supported by a
> connectionless upper layer stack
>
> We handshake according to the author's scheme in DTLS, setting up
> classical duplication detect windows and out of order queues.
>
> (NB DTLS REQUIRES us to operate in application space, note, to
> implement the intent of the designers. Why?... cannot I make a
> (trusted) socket implementation even if the bearer was UDP?)

There's no reason you can't use DTLS that way.


> Lets say, the DTLS sender is a switch working with BPDUs send 2**s
> packets a second (s) on a ramp, and it now loses 2**s-1 sequence
> numbers in that same second (s) due to a faulty MAC hardware engine.
> That is, the switch generates the frame and then just throws it away
> detecting the mac error in its ASICs, as the speed of at line speed
> ~10G. Thus, in practice it actually communicates 1 frame a second
> (with seq_number 2**s-1) on the wire
>
> And, the world of hardware being as strange as it is, the receiver now
> happens to receives seq_number 2*64 (known as 0 in some circles) in
> the same epoch, and flood of good frames with increasing sequence
> numbers.
>
> Now doesn't the DTLS just recognize 0 as already received, and discard
> it?h
> Ok, for commercial systems, I'm assuming unrealistic windows, bit
> stores, queue length etc. But, if I then receive a frame whose
> sequence_number I have not previously received, I just accept it don't
> I?

If you assume that DTLS is using an infinite replay window, yes, it
treats this as a replay. That's why you can't allow the sequence
number to wrap on the sender side, because it creates ambiguity/aliasing.

> I'm not sure why DTLS has such a grudge against RC4.

Because it's very difficult to make RC4 work properly in an
out-of-order delivery mode, which we learned to our distress
with WEP.

-Ekr

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls