Subject: Re: [Tsvwg] TSVWG last call on "UDP Usage Guidelines for Application Designers" to BCP

From: Lars Eggert <[email-masked]>
Date: Tue, 15 Apr 2008 08:45:54 -0700

Hi, Peter,

On 2008-4-7, at 8:50, ext Peter Koch wrote:
> Neither the section on message sizes nor the security considerations  
> mention
> the potential threat of amplification attacks in simple request- 
> response
> protocols based on UDP.  Of course, we'd hope BCP38 was more widely  
> deployed,
> but until then it might be useful to recommend that new UDP based  
> protocols
> intended for WAN use restrict responses to unauthenticated clients  
> to no more
> than some factor (say, 1 or 2) until the upper layer has completed  
> at least
> a full three-way-handshake (for poor man's authentication) or apply  
> other
> protocol specific measures of DDoS mitigation. See also the Security  
> Considerations
> in RFC 4993.

RFC4993 says this:

    Because IRIS-LWZ is a UDP-based protocol, it is possible for servers
    using IRIS-LWZ to be used in a type of distributed denial-of-service
    attack known as a reflection attack.  This type of attack affects
    other types of UDP-using protocols, such as DNS.  Server operators
    should be prepared to apply the same methods used for mitigating
    reflection attacks with other protocols, such as DNS, when using
    IRIS-LWZ.  All operators should follow the advice given in BCP 38
    [7].

Which doesn't seem to go quite as far as what you suggest, i.e.,  
restrict responses to unauthenticated clients. If our document says  
something on this issue, it should be recommending something that the  
security folks see as being best current practice. I'm not a security  
guy, so I don't know if your proposal would qualify as such, or what  
else we should be saying about this (if anything.)

Lars

---

From: Peter Koch <[email-masked]>
Date: Mon, 21 Apr 2008 13:43:15 +0200

Hi Lars,

> >protocol specific measures of DDoS mitigation. See also the Security  
[...]

> restrict responses to unauthenticated clients. If our document says  

yes, well, on second thought the text suggested above was a bit rough.
It's also the number of potential reflectors that needs to be taken into
account as well as protocol specifics that make one UDP based protocol
more susceptible to this attack than others.

> security folks see as being best current practice. I'm not a security  

Maybe security folks and the operational community.  In the case of IRIS-LWZ
this is what the security considerations refers to, and despite the fact
that the number of IRIS servers is not expected to reach the number of open
recursive name servers, access restrictions (not packet size limits) were
implicitly recommended.

> else we should be saying about this (if anything.)

At least text along the lines of RFC 4993 should guide the protocol
designers, but I agree this is for the sec-dir review to find out.

-Peter

---

From: <[email-masked]>
Date: Mon, 21 Apr 2008 17:48:58 +0300

In general, the document is clear and well written. Couple of
additional suggestions follow:

Two topics which could be useful to mention in Section 3.5 
(middlebox traversal guidelines):

- Typically, TCP needs keep-alives much less frequently than UDP.
Sending frequent keep-alive messages can, depending on the underlying 
technology, consume significant amounts of energy, which can be a 
problem especially for battery-powered devices. In this kind of
situation, if an application needs to maintain connectivity for long 
periods with little traffic (e.g., VoIP phone that's just waiting
for an incoming call), TCP could be more suitable than UDP.

- Techniques such as ICE allow two hosts behind different middleboxes
to establish direct communication in some circumstances. Reputedly, the
real-world success rate is much higher for UDP than for TCP, and this
alone may be a reason for using UDP in some situations.

Section 4 says "Many other options for authenticating or encrypting
UDP payloads exist.  These include IETF security frameworks such as
GSS-API [RFC2743], SASL [RFC4422] and EAP [RFC3748], which are
designed to provide security services for network protocols."

EAP doesn't provide any kind of security services for UDP payloads
(although it could be used together with a mechanism that does 
provide such services), and SASL runs over reliable bidirectional 
streams (like TCP), not datagrams. Also, it might be useful to mention 
CMS here.

Best regards,
Pasi