[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Datagram TLS



Bodo Moeller <bmoeller@eecs.berkeley.edu> writes:

> On Sat, Jan 31, 2004 at 09:38:04AM -0800, Eric Rescorla wrote:
> > Bodo Moeller <bmoeller@eecs.berkeley.edu> writes:
> 
> [...]
> >>    Section 4.2.3 of the DTLS Internet Draft essentially describes how
> >>    long handshake messages can be fragmented into multiple shorter
> >>    handshake messages.  However, I haven't seen language in the draft
> >>    actually saying that messages must not be otherwise fragmented into
> >>    multiple records, which is perfectly legal in TLS (a 97-byte
> >>    ClientHello message could be sent in 97 records carrying one handshake
> >>    protocol byte each, for example).  Obviously you don't want this to
> >>    be done in DTLS, but the draft does not appear to forbid it.
> 
> > Well, I think this is bad practice, but I'm not sure we want to
> > forbid this.
> 
> If you don't forbid it, I don't see a need to add fragmentation on the
> handshake protocol level -- recipients would have to be able to perform
> reassambly of Handshake data structures that are spread over multiple
> records anyway.  Reassembly is simpler with the fragment_offset
> provided by your higher-level fragmentation mechanism, but
> implementations don't really profit from this if fragmentation could
> actually happen at either level.
Ah. Good point--and that reassembly isn't deterministic.

We'll arrange to forbid it.

> By the way, section 4.1.1 (transport layer mapping) is not entirely
> clear.  Unless your intention is that each datagram should contain
> only a single DTLS record (which should be clarified in the Internet
> Draft if this is the case), I suggest changing
> 
>    Each DTLS record MUST fit within a single datagram. In order to avoid
>    IP fragmentation [MOGUL], DTLS implementations SHOULD determine the
>    MTU and send records smaller than the MTU. [...]
> 
> into
> 
>    Each DTLS record MUST fit within a single datagram, and DLTS record
>    boundaries MUST observe datagram boundaries.  If lengths permit, multiple
>    DTLS records can be concatenated (in order) and sent within a
>    single datagram.  In order to avoid IP fragmentation [MOGUL], DTLS
>    implementations SHOULD determine the MTU and send datagrams smaller
>    than the MTU. [...]
>    
> or something along those lines.  (Record concatenation is useful
> when data from multiple message types is sent at the same time,
> such as ClientKeyExchange, ChangeCipherSpec, and Finished.)
Agreed. Good point.

> Right, I don't really fancy adding a new alert either, I just wanted
> to describe an option that *might* have some value.  If no one wants
> to have it, than I'm entirely comfortable without this kind of
> "non-alert".  (Other new alerts that I can think of but that I don't
> really want are alerts for indicating high record loss, i.e.
> holes in the list of sequence numbers received in valid records.)
In the spirit of adding as few things as possible, I think I'd
rather hold off on these for now until we we have some application
that clearly needs it.

Thanks,
-Ekr