Re: Pls review documents on IESG Agenda for April 25, 2005

[Eric Rescorla <ekr@rtfm.com>]

Jari,

Thanks for your review.

Jari Arkko <jari.arkko@piuha.net> wrote:
> 
> > 4.1.1. Transport Layer Mapping
> >
> >    Each DTLS record MUST fit within a single datagram. In order
> >    to avoid IP fragmentation [MOGUL], DTLS implementations SHOULD
> >    determine the MTU and send records smaller than the MTU. DTLS
> >    implementations SHOULD provide a way for applications to
> >    determine the value of the PMTU (or alternately the maximum
> >    application datagram size, which is the PMTU minus the DTLS
> >    per-record overhead). If the application attempts to send a
> >     ...
> >
> > 4.1.1.1. PMTU Discovery
> >
> >    In general, DTLS's philosophy is to avoid dealing with PMTU
> >    issues. The general strategy is to start with a conservative
> >    MTU and then update it if events require it, but not actively
> >    probe for MTU values. PMTU discovery is left to the
> >    application.
> 
> I think I know what you intend to do here, but the above two
> text pieces appear to be in conflict. And isn't PMTU probing is
> more or less what you are doing in Section 4.1.1.1 anyway?
> 
> Suggest changing the latter text to "The general strategy
> is to start with a conservative MTU and then update it if
> events either during the handshake or actual application
> data transport phase require it."

Sounds good.

> 
> >    The PMTU SHOULD be initialized from the interface MTU that
> >    will be used to send packets. If the DTLS implementation
> >    receives an RFC 1191 [RFC1191] ICMP Destination Unreachable
> >    message with the "fragmentation needed and DF set" Code
> >    (otherwise known as Datagram Too Big) it should decrease its
> >    PMTU estimate to that given in the ICMP message. A DTLS
> >    implementation SHOULD allow the application to occasionally
> >    reset its PMTU estimate. The DTLS implementation SHOULD also
> >    allow applications to control the status of the DF bit. These
> >    controls allow the application to perform PMTU discovery.
> 
> How does this play with RFC 1981, IPv6 version of PMTU discovery?
> At least the ICMPs are different, and the IPv6 version appears to
> say something more specific about the aging of PTMU information.
> 
> Suggest adding "RFC 1981 procedures SHOULD be followed for
> IPv6.", or something to this effect.

That works for me as well.


<> >       2. An attacker can use the server as an amplifier by
> >       sending connection initiation messages with a forged source
> >       of the victim. The server then sends its next message (in
> >       DTLS, a Certificate message, which can be quite large) to
> >       the victim machine, thus flooding it.
> > ...
> >    Although DTLS servers are not required to do a cookie
> >    exchange, they SHOULD do so whenever a new handshake is
> >    performed in order to avoid being used as amplifiers. If the
> >    server is being operated in an environment where amplification
> >    is not a problem, the server MAY choose not to perform a
> >    cookie exchange. In addition, the server MAY choose not do to
> >    a cookie exchange when a session is resumed. Clients MUST be
> >    prepared to do a cookie exchange with every handshake.
> 
> This is pretty good stuff.
> 
> But given that the victim is a different entity than the one that
> decides whether the cookies are used, I wonder if you should say
> this slightly differently. Maybe "DTLS servers SHOULD perform
> a cookie exchange whenever a new handshake is being performed.
> If the server is being operated in an environment where amplification
> is not a problem, the server MAY be configured to not to perform a
> cookie exchange. The default SHOULD be that the exchange is performed,
> however.  In addition, the server MAY choose not do to a cookie
> exchange when a session is resumed. Clients MUST be
> prepared to do a cookie exchange with every handshake."

Yes, this is an improvement. Thanks.

Thanks,
-Ekr