Subject: [OPSEC] draft-byrne-opsec-udp-advisory

From: Ca By <[email-masked]>
Date: Mon, 20 Jul 2015 17:46:44 -0700

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.

The IETF Secretariat

---

From: "George, Wes" <[email-masked]>
Date: Sat, 25 Jul 2015 21:21:02 -0400

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-masked]<mailto:[email-masked]>> on behalf of Ca By <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 20, 2015 at 8:46 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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.

=========

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:

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.