Re: [TLS] Last Call: draft-ietf-tls-rfc4347-bis-04.txt (Datagram Transport Layer Security version 1.2) to Proposed Standard
On Mon, Dec 20, 2010 at 11:01 AM, Juho Vähä-Herttua juh...@iki.fi wrote: On 20.12.2010, at 15.15, Pekka Savola wrote: 3.2.3. Message Size TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams are often limited to 1500 bytes if fragmentation is not desired. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records. Each DTLS handshake message contains both a fragment offset and a fragment length. 4.1.1. Transport Layer Mapping Each DTLS record MUST fit within a single datagram. In order to avoid fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer. ... these seem somewhat contradictory. Maybe I'm missing something. The latter seems to be saying that DTLS implementations should try to avoid IP fragmentation, but the former seems to imply that it's de-facto mode of operation. These are not contradictory. If a handshake message size and record header don't fit inside single datagram, it should be fragmented into several small handshake messages and each of these is put into a separate DTLS record. The resulting DTLS record after encryption should not exceed the maximum UDP (or DCCP or whatever) datagram size and therefore doesn't need IP level fragmentation. I think what you missed was simply the difference of IP level fragmentation and DTLS handshake protocol level fragmentation. I think that is a lot of the issue here. We probably don't distinguish these clearly. Given that I don't want to change terminology now I suggest we just say DTLS fragmentation and IP fragmentation. It's clunky but serviceable. WRT to the ICMP issue, my take on this is that ICMP Isn't reliable both because of filtering and that it implies connected sockets. So, the application needs to be able to determine PMTU even if it never gets any kind of error indication. However, I agree that if the stack does get an explicit error it MUST adjust. The rest of Pekka's suggestions make sense and I should be able to implement them. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-ietf-tls-rfc4347-bis-04.txt (Datagram Transport Layer Security version 1.2) to Proposed Standard
On 20.12.2010, at 15.15, Pekka Savola wrote: 3.2.3. Message Size TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams are often limited to 1500 bytes if fragmentation is not desired. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records. Each DTLS handshake message contains both a fragment offset and a fragment length. 4.1.1. Transport Layer Mapping Each DTLS record MUST fit within a single datagram. In order to avoid fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer. ... these seem somewhat contradictory. Maybe I'm missing something. The latter seems to be saying that DTLS implementations should try to avoid IP fragmentation, but the former seems to imply that it's de-facto mode of operation. These are not contradictory. If a handshake message size and record header don't fit inside single datagram, it should be fragmented into several small handshake messages and each of these is put into a separate DTLS record. The resulting DTLS record after encryption should not exceed the maximum UDP (or DCCP or whatever) datagram size and therefore doesn't need IP level fragmentation. I think what you missed was simply the difference of IP level fragmentation and DTLS handshake protocol level fragmentation. Juho smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tls-rfc4347-bis-04.txt (Datagram Transport Layer Security version 1.2) to Proposed Standard
On Tue, 30 Nov 2010, The IESG wrote: The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Datagram Transport Layer Security version 1.2' draft-ietf-tls-rfc4347-bis-04.txt as a Proposed Standard A bit late to the IETF LC, but hopefully these are still useful. This is an ops-dir review of draft-ietf-tls-rfc4347-bis-04 (DTLS 1.2). This looks good, but the text seems a bit unclear on IP fragmentation vs packetization. ICMP notifications passing up to the app is only a 'should' and this begs the question why. IANA considerations practicalities could also be spelled out (not sure how detailed IANA wants these to be). In more detail: If I understand correctly *), initial DTLS exchanges will typically use fragmented UDP packets due certificate sizes etc. The likelyhood of getting fragmented IP packets through firewalls and other devices is significantly lower than getting UDP packets through. The spec would be more robust and the protocol likely more applicable in the face of these 'network effects' if it tried to do packetization itself in such a manner that IP fragmentation would not be necessary. *) S 3.2.3 and 4.1.1 appear to be somewhat contradictory on this. See below. The document does not have a Changes from DTLS 1.0 (RFC4347) section that is is mandated or at least strongly recommended for update-specs. The document does not describe how DTLS 1.2 will interwork with DTLS 1.0 (if it will). The TLS 1.2 spec (RFC5246, Appendix E.1) does have some that will apply, but there are likely some DTLS specifics as well. specific comments - 3.2.3. Message Size TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams are often limited to 1500 bytes if fragmentation is not desired. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records. Each DTLS handshake message contains both a fragment offset and a fragment length. 4.1.1. Transport Layer Mapping Each DTLS record MUST fit within a single datagram. In order to avoid fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer. ... these seem somewhat contradictory. Maybe I'm missing something. The latter seems to be saying that DTLS implementations should try to avoid IP fragmentation, but the former seems to imply that it's de-facto mode of operation. If there is a transport protocol indication (either via ICMP or via a refusal to send the datagram as in DCCP Section 14), then DTLS record layer should inform the upper layer protocol of the error. .. is this too weak? I've have thought that it would be natural that if DTSLS record layer gets this notification (which, in the case of ICMP and omitting information, is not necessarily given), it MUST pass this information up. Note that the refusal to send could also apply to UDP if packet is bigger than PMTU and DF bit is set or IPv6 is used. What is the alternative if it doesn't? It would be fine if the alternative is that the DTLS record layer react to that information itself, but completely ignoring e.g. ICMP packet too big would lead to communication failure. 7. IANA Considerations This document uses the same identifier space as TLS [TLS12], so no new IANA registries are required. When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS. ... this may be inadequate. I was unable to find from the registry (tls-parameters) which of these parameters this applies to. All of them? (This was triggered by S 4.1.2.5, so at least new Cipher Suites must indicate this.) If I understand what you mean, 1) you should actually be asking IANA to reformat the registry so that there is an additional column in all the tables DTLS-OK? or some such, and possibly 2) modifying TLS 1.2 spec IANA registration guidelines (i.e. what should the IANA requesters know about when they're making their request), and also possibly 3) asking IANA to ask future registrants about DTLS-OK feature if the requestor fails to do so on their own. editorial - ... For the completeness, when referring to PMTU discovery, in addition to RFC1191 one should probably also refer to RFC1981 (the IPv6 version). [WHYIPSEC] Bellovin, S., Guidelines for Mandating the Use of IPsec, Work in Progress, October 2003. ... this should probably be rfc5406? [IKEv2]C. Kaufman (ed), Internet Key Exchange (IKEv2) Protocol, RFC 4306, December 2005. Kaufman, C., Internet Key Exchange (IKEv2) Protocol, RFC 4306, December 2005. ... remove the latter 'reference' (edit glitch?) ___ Ietf mailing list Ietf@ietf.org
Re: Last Call: draft-ietf-tls-rfc4347-bis-04.txt (Datagram Transport Layer Security version 1.2) to Proposed Standard
* Pekka Savola: If there is a transport protocol indication (either via ICMP or via a refusal to send the datagram as in DCCP Section 14), then DTLS record layer should inform the upper layer protocol of the error. .. is this too weak? I've have thought that it would be natural that if DTSLS record layer gets this notification (which, in the case of ICMP and omitting information, is not necessarily given), it MUST pass this information up. Note that the refusal to send could also apply to UDP if packet is bigger than PMTU and DF bit is set or IPv6 is used. What is the alternative if it doesn't? It would be fine if the alternative is that the DTLS record layer react to that information itself, but completely ignoring e.g. ICMP packet too big would lead to communication failure. ICMP packet too big is typically handled by the stack, not the application. The stack updates the stored path MTU, the application tries again, and this time, the stack produces smaller fragments. AFAIUI, requiring ICMP processing in applications prescribes an implementation model based on connected UDP sockets (in the terminology of the BSD sockets API). This is not always desirable or possible. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-tls-rfc4347-bis-04.txt (Datagram Transport Layer Security version 1.2) to Proposed Standard
The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Datagram Transport Layer Security version 1.2' draft-ietf-tls-rfc4347-bis-04.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-12-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4347-bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4347-bis/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
