[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pls review documents on IESG Agenda for April 25, 2005
Wijnen, Bert (Bert) wrote:
o draft-rescorla-dtls-04.txt
Datagram Transport Layer Security (Proposed Standard) - 2 of 5
Token: Russ Housley
Ok, I'll bite.
Its a great spec! Some minor nits below, however. Hope
you find them useful...
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."
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.
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."
layer security protocol. SIP, for instance, uses a subsert of
s/subsert/subset/
Multiple DTLS records may be placed in a single datagram. hey
s/hey/They/
Section 3.4.3 of [RFC 2402]
s/]/]./
A.1Summary of new syntax
Non-ascii char.
--Jari