[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