Cameron - Thank you for writing this. I think it's useful guidance, but I have some specific suggestions:
First of all, you need to be clearer what you mean by baseline in your recommendations that operators should do it. I know from other conversations that what you mean is that the rate-limit is not set and forget, but something that is constantly re-evaluated to determine the baseline, i.e. As a percentage of overall traffic, and this is intended to be a circuit-breaker of sorts that protects against sudden spikes of UDP traffic with the least possible impact to legitimate traffic, knowing full well that legitimate traffic continues to increase, or may follow a diurnal pattern, flash mob, etc. If there is information available about how this is accomplished on some types of hardware (i.e. The way that you're doing it isn't proprietary) it might be useful to discuss this, because that makes people more likely to implement it. Second, I would remove the recommendation against using UDP. Your discussion of the practice of doing this sort of rate limiting and an explanation of the risk to UDP traffic should be enough to make people consider their use of UDP for their applications more carefully. Doing that makes this document more likely to achieve consensus and less likely to be misinterpreted as the IETF saying "UDP considered harmful" or similar. Last โ I had a conversation with someone (whose name is unfortunately escaping me) in Prague regarding this, and he mentioned one point to potentially highlight is that UDP attacks that are abusing open reflectors (NTP, Chargen, etc) can be distinguished from legitimate traffic if there is something in the header of most legitimate UDP traffic (especially that which is congestion-aware at the app level, or otherwise well-behaved) because while an app could generate packets with the right flag, traffic coming in from a reflector is unlikely to have that information on the header since the attacker does not have any actual control over the reflector. It wouldn't fix raw UDP floods (non-reflected DDoS) where the attacker generates packets with that bit set but it would at least give you another piece of data when establishing your baseline. I hate to say it, but it's almost like the opposite of the "evil bit". Thanks, Wes From: OPSEC <[email protected]<mailto:[email protected]>> on behalf of Ca By <[email protected]<mailto:[email protected]>> Date: Monday, July 20, 2015 at 8:46 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [OPSEC] draft-byrne-opsec-udp-advisory Op sec, Given the number of udp related developments, I created this I-d to express concern about further udp work and expound on some operational practices that conflict with udp growth. Your feedback is welcome. ========= A new version of I-D, draft-byrne-opsec-udp-advisory-00.txt has been successfully submitted by Cameron Byrne and posted to the IETF repository. Name: draft-byrne-opsec-udp-advisory Revision: 00 Title: Advisory Guidelines for UDP Deployment Document date: 2015-07-20 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-byrne-opsec-udp-advisory-00.txt Status: https://datatracker.ietf.org/doc/draft-byrne-opsec-udp-advisory/ Htmlized: https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 Abstract: User Datagram Protocol (UDP) is commonly used as a volumetric attack transport on the internet. Some network operators experience surges of UDP attack traffic that are multiple orders of magnitude above the baseline traffic rate for UDP. Application developers should be advised that UDP is being rate-limited on a bits-per-second and packet-per-second basis by network operators to enforce known good baseline traffic levels for UDP. UDP has been abused to such an extent that legitimate use may become collateral damage and application and protocol developers should avoid using UDP as a transport when possible. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>. The IETF Secretariat ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
