Wes On Saturday, July 25, 2015, George, Wes <[email protected]> wrote:
> 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 > Ehh. Constantly re-evaluated is not scalable. Today, udp traffic levels in aggregate are small. So it is easy to set a threshold at 5x, 10x or even 20x busy hour and be capable of absorbing the blow before policing kicks in. If legit udp traffic rates rise, this is no longer possible, and hence the I-d > 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. > > Ok. > 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. > > I am open to more discussion here. I do not want to be ambiguous > 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". > I think you mean draft-herbert-udp-magic-numbers That's not a knob on a router I have. And, dipping into the transport frame for explicit middlebox signaling gives me indigestion. CB > Thanks, > > > > Wes > > > > > From: OPSEC <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> on behalf of Ca > By <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > Date: Monday, July 20, 2015 at 8:46 PM > To: "[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>" < > [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>> > Cc: "[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>" > <[email protected] > <javascript:_e(%7B%7D,'cvml','[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. > > 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
