Subject: RE: [TLS] Last call comments about DTLS (mostly editorial)

From: [email-masked]
Date: Wed, 23 Mar 2005 14:18:09 +0200

Here's my last batch of comments about DTLS:

20)

The document does a reasonably good job at making the distinction
between (UDP) "datagrams" and "IP packets". However, there are a
couple of instances where they are mixed up:

- Section 3.2.3 says "By contrast, UDP datagrams are often 
  limited to <1500 bytes."

This probably depends on your definition of "often", but many
operating systems (Windows, Linux, ..) support UDP datagrams 
of up to around 65000 bytes (which, of course, get fragmented
to several IP packets).

- 4.1.1 "DTLS implementations SHOULD provide a way for 
  applications to determine the value of the MTU (optimally the 
  maximum application datagram size, which is the PMTU minus the 
  DTLS per-record overhead)."

I think this sentence has some kind of grammar problem... or
at least I would expect that normally the maximum application 
datagram size is the maximum UDP datagram size minus DTLS overhead, 
but that does not depend on the PMTU.

21)

Section 4.1.1 says that "If the application attempts to send 
a record larger than the MTU, the DTLS implementation MUST either 
generate an error or fragment the packet."

It seems DTLS does not provide fragmentation for application data, 
so the fragmentation is really done by the IP/UDP implementation, 
not DTLS?

22)

I'm not very comfortable with the way PMTUD is done.

PMTUD is most useful when the transport or application can use
the PMTU value to adjust how large "segments" they send.  Since
DTLS does not provide fragmentation for application data, the
whole PMTUD stuff is useful only for the handshake messages and
the small class of applications that can vary how large 
application datagrams they supply to DTLS.

(The discovery process also requires this kind of adjustments,
since it involves sending packets both smaller and larger than
the actual (and at that point, unknown) PMTU value.  How are
these adjustments done? Is the application responsible for
supplying suitably sized application datagrams, or does DTLS
somehow "manufacture" the packets used for PMTUD?)

Furthermore, the "classical PMTU" approach described in 4.1.1.1
is seriously broken, because firewalls filter the ICMP messages.
The "new PMTU algorithm" (draft-ietf-pmtud-method) does not have
this problem, but it requires some kind of acknowledgements to
determine which packets were lost (and thus would not work
for DTLS application data).

I see at least couple of ways how this could be made more
logical.

One possibility would be to leave PMTU to applications
(draft-ietf-pmtd-method does talk about that possibility as
well): applications that can adjust the segment size probably
have some kind of acknowledgement structure already, and DTLS
would be responsible only for setting the DF bit when requested
by the application. (And the handshake messages could be handled
by always fragmenting them to some small size.)

Another possibility would be to add fragmentation of application
data (and thus the possibility to adjust packet boundaries) to
DTLS.  This way, PMTU value would be taken into account by DTLS,
not the application. But this would also require some kind of
acknowledgements (that would be used only for PMTU adjustment,
not retransmitting the data) so that the "new PMTU" algorithm
would work.

(I think the former approach would be simpler.)

23)

Last but not least: although I've sent a long list of somewhat
negative sounding comments, my overall impression of this
document is quite positive. There are no major problems in the
spec, and I expect that DTLS will a useful protocol in many
environments.

Best regards,
Pasi

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Mar 2005 07:08:49 -0800

> of up to around 65000 bytes (which, of course, get fragmented
Right. I should add "without fragmentation" here.

> but that does not depend on the PMTU.
Yes, I'll correct.

> so the fragmentation is really done by the IP/UDP implementation, 
Absolutely.

> by always fragmenting them to some small size.)
Our approach is basically similar to this.

We assume that any application which runs over UDP at all must
somehow handle PMTU discovery (or send small fragments). So,
as far as application data is concerned our job is not to
inhibit that. This means:

1. Setting DF if required by the app (this isn't explicitly 
   stated in the spec. I'll add it)
2. Handling ICMP messages and adjusting our estimate of PMTU
   so we can inform the application if the app tries to
   send a too large message). Ordinarily the app would do
   this, but of course we're consuming any such messages.
   (This is explicitly stated).

However, this only gets half the job done because weneed to also
handle handshake. Our approach is slightly different from the one
you suggest: we start with the interface MTU and then back off
either due to ICMP messages or due to too much timeout
(see S 4.1.1). These aren't "small" messages, but the 
interface MTU is generally the Ethernet MTU which is the
current recommendation for starting PMTU...

> spec, and I expect that DTLS will a useful protocol in many
Thanks!

-Ekr