Hi Gorry, Yes, thanks to Pasi and Colin for their comments. I'm still digesting the issues and will respond soon... Tom P. > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@xxxxxxxxxxxxxx] > Sent: Friday, October 26, 2007 3:54 AM > To: dccp@xxxxxxxx > Cc: Pasi.Eronen@xxxxxxxxx > Subject: [Fwd: WGLC comments for draft-ietf-dccp-dtls-02] > > 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 > >
