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

[<home_pw at msn.com>]

I'm ill with nausea today, and probably thinking less 
straight than ever. But here goes.

---------------

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?)

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?

That is, in *this* context it didn't "wrap" did it?

--------

This is all interesting tho. There is also the TFTP approach 
to SSL over UDP with a reasonable reliability mechanism from 
tftp itself, and the EAP-TLS with its built in 
fragmentation/retry process, including now the record_layer 
(as EAP-TLS now has its privacy mode for sending user id to 
the radius server).

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

, ----- Original Message -----
From: "Mike" <mike-list at pobox.com>
To: "tls mailing list" <tls at ietf.org>
Sent: Thursday, January 18, 2007 9:38 AM
Subject: Re: [TLS] What's the proper alert for sequence 
wrap.

> Practically speaking, you don't ever need to worry about 
> this.
> Even if you send a billion records every second, it would 
> take
> 584 years to wrap the sequence number.
>
> Mike
>
>
> Andrew Fan wrote:
> > The RFC4346 says:
> >
> >      Sequence numbers are of type uint64 and may not
> >      exceed 2^64-1.  Sequence numbers do not wrap.  If a 
> > TLS
> >      implementation would need to wrap a sequence number, 
> > it must
> >      renegotiate instead.
> >
> > In a implementation, if one does not want to support 
> > sequence number wrap with renegotiation, a fatal alert 
> > should be sent to peer if the sequence number exceed. Or 
> > if one side receive a wrapped sequence number, a fatal 
> > alert also should be sent to peer. However, I don't find 
> > proper alert descriptions for both read and write 
> > sequence number exceed cases.
> >
> > Any suggestions?
>
> _______________________________________________
> TLS mailing list
> TLS at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls

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