Thank you Pasi!
This review was received by a reviewer for this WG, and should be taken
into consideration during the WGLC,
Best wishes,
Gorry
-------- Original Message --------
Subject: WGLC comments for draft-ietf-dccp-dtls-02
Date: Thu, 25 Oct 2007 11:23:32 +0300
From: <Pasi.Eronen@xxxxxxxxx>
To: <gorry@xxxxxxxxxxxxxx>, <lars.eggert@xxxxxxxxx>, <tphelan@xxxxxxxxxxxx>
CC: <dccp@xxxxxxxx>
This is a quite short and straightforward draft. The main
differences from DTLS-over-UDP come from being connection-oriented,
and taking somewhat different approach to MTUs.
Covering PMTU-related issues first:
Section 3.3
Each DTLS record must fit within a single DCCP-Data packet. DCCP
packets are normally transmitted with the DF (Don't Fragment) bit
set for IPv4, and of course all IPv6 packets are unfragmentable.
Because of this, DCCP performs Path Maximum Transmission Unit
(PMTU) Discovery. In determining the maximum size for DTLS
records, a DTLS over DCCP implementation SHOULD use the
DCCP-managed value for PMTU. A DTLS over DCCP implementation MAY
choose to use its own PMTU Discovery calculations, as specified
in [RFC4347], but MUST NOT use a value greater the value
determined by DCCP.
This topic is a bit complex, and probably needs some clarification.
RFC 4347 mostly uses an approach where the application is the
"packetization layer" responsible for doing PMTUD (the exception
being the DTLS handshake messages), including probing for larger
PMTUs and maintaining PMTU estimates. Partly, this is because
"modern" PMTU (RFC 4821 style) can't be done without
acknowledgements, and neither DTLS nor UDP has those. Also, neither
DTLS nor UDP has a "packetization layer" (ability to split a single
application message to multiple DTLS records or UDP datagrams),
so the application has to be involved anyway.
This means DTLS should allow the application to request particular
per-packet treatment, either "don't fragment" (set DF bit in IPv4,
don't do local fragmentation even if IP layer PMTU estimate is
exceeded), or "fragment if needed" (don't set DF bit in IPv4, do
local fragmentation if exceeds IP layer PMTU estimate).
Also, the application should get feedback when possible (e.g.
"packet could not be sent at all", or "warning, packet was sent but
exceeded local PMTU estimate", or "IP PMTU estimate changed due to
ICMP"), and have access to lower layer MTU-related parameters, such
as the maximum transport datagram size (which can't be exceeded --
for DCCP, the CCMPS minus any overhead?; for UDP, I guess usually
64K minus overhead), the maximum DTLS record size (16K), the local
link MTU (exceeding which is possible, but will always trigger
fragmentation), and if available, PMTU estimate maintained by IP
layer (exceeding which is possible, but is likely to trigger
fragmentation or result in lost datagram) (this PMTU estimate is
based on "classical" PMTUD, and thus is likely to be larger than
the actual PMTU)
However, I would guess most applications simply choose to ignore
this complexity (and might not have really good ability to adjust
their message size), and just tell DTLS to "fragment if needed"
(as most apps using UDP do). Presumably, this could be the case
even when running DTLS over DCCP?
Given this, the advice "in determining the maximum size of DTLS
records, a DTLS over DCCP implementation SHOULD use the
DCCP-managed value for PMTU" is a misleading. DTLS should certainly
allow the application to find out what the DCCP-managed PMTU value
is, but for most applications (which can't/don't want to adjust
their message sizes, and don't want to implement PLPLMTUD), the
maximum size of DTLS record would be larger.
One remaining case is retransmitting DTLS handshake messages. Even
here, the advice to just use the DCCP-managed value for PMTU might
not be very good one. Currently, RFC 4347 basically recommends
starting with MTU or PMTU estimate given by the IP/transport
layer(s), but decreasing the handshake message size if
retransmissions are needed (essentially doing simplified "modern"
PMTUD, which is more likely to work than "classical" PMTU).
I'm not quite sure how the text should be modified to take this
into account. DCCP might also be slightly different in this regard,
since it has some kind of acknowledgements, and thus can do the
more reliable "modern" PMTUD (as suggested in RFC 4340, last
paragraph of Section 14.1). However, this seems to be purely
optional, and not something that DCCP is required to do. (And if
given the choice only between "classical PMTUD" and "fragment if
needed", I'm not sure what applications would prefer).
----------
Section 3.2:
However, the DCCP handshake packets DCCP-Request and
DCCP-Response have Application Data fields and can carry user
data during the DCCP handshake. DTLS client implementations MAY
choose to transmit the ClientHello message in the DCCP-Request
packet. DTLS server implementations MAY choose to respond to a
ClientHello message received in a DCCP-Request packet with a
HelloVerifyRequest message, if denial of service countermeasures
are to be used or, a ServerHelloDone message otherwise, in the
DCCP-Response packet.
Subsequent DTLS handshake messages, and retransmissions of the
ClientHello message, if necessary, MUST wait for the completion
of the DCCP handshake.
This is somewhat inaccurate, as the things that can be piggybacked
in DCCP-Request/Response are DTLS records, not necessarily whole
DTLS handshake messages (and for the server, ServerHelloDone is not
the first message sent).
I'd suggest rephrasing this along the lines "A DTLS client
implementation MAY choose to transmit its first DTLS record(s) in
the DCCP-Request packet. Similarly, a DTLS server implementation
MAY choose to include DTLS record(s) in the DCCP-Response
packet. The sending of subsequent DTLS records, including
retransmissions, MUST wait for the completion of the DCCP
handshake. Note that DCCP server may not accept the application
data in DCCP-Request. If this happens, DTLS will eventually
retransmit the message."
----------
DTLS's Cookie/HelloVerifyRequest mechanism is meant to provide some
protection against spoofed source IP address, so it isn't really
that useful on connection-oriented transports like DCCP (which has
its own Init Cookie option). The document should mention this, and
perhaps recommend that when run over DCCP, this feature of DTLS
should not be used (as it doesn't seem to add any value).
----------
Should the document say something about DCCP checksums and their
coverage?
----------
RFC 4347, Section 4.1.1:
Some transports, such as DCCP, provide congestion control for
traffic carried over them. If the congestion window is
sufficiently narrow, DTLS handshake retransmissions may be held
rather than transmitted immediately, potentially leading to
timeouts and spurious retransmission. When DTLS is used over
such transports, care should be taken not to overrun the likely
congestion window. In the future, a DTLS-DCCP mapping may be
specified to provide optimal behavior for this interaction.
This draft doesn't seem to address congestion at all. Is there
perhaps something that needs to be said? (Possibly the answer
is "no", but I'm not sure.)
----------
Maybe this is obvious, but it might be worth mentioning explicitly
that the DCCP "Service Code" is not protected by DTLS.
----------
Minor editorial nits:
Section 3 says "Multiple DTLS records MAY be sent in one DCCP
packet, as long as the resulting packet is within the Path
Maximum Transfer Unit (PMTU) currently in force".
The construct "MAY do X as long as Y" is prone to different
interpretations (it's not clear if it's supposed to imply
"if not Y, MUST NOT do X"). I'd suggest rephrasing this simply as
"Multiple DTLS records MAY be sent in one DCCP packet." (Avoiding
fragmentation is just a strong recommendation, not an absolute
prohibition.)
Section 3.3 says "of course all IPv6 packets are unfragmentable".
This is a bit misleading; the sending host can fragment a single
DCCP packet to multiple IPv6 packets.
Section 6.1, reference RFC4347 is missing the second author.
Section 6.1, reference SCODES could be changed to Informative (it
provides useful information, but is not required to implement this
spec) to avoid delays in publication.
----------
Best regards,
Pasi
