Subject: Re: [TLS] Last Call: <draft-ietf-tls-rfc4347-bis-04.txt> (Datagram Transport Layer Security version 1.2) to Proposed Standard

From: Florian Weimer <[email-masked]>
Date: Mon, 20 Dec 2010 14:50:00 +0000

* 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 Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Pekka Savola <[email-masked]>
Date: Mon, 20 Dec 2010 15:15:18 +0200 (EET)

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.

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?)

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Mon, 20 Dec 2010 21:01:02 +0200

> fragmentation, but the former seems to imply that it's de-facto mode of

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