H8Hz [email protected]
> From: OPSEC [[email protected]] on behalf of George, Wes > [[email protected]] > Sent: Saturday, July 25, 2015 7:21 PM > To: Ca By; [email protected] > Cc: [email protected] > Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory > > > 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. Base lining is important. If you have netfow or something like it and the ability to due reports based on months/years of it, you can see what the traffic was like before it started being commonly used for attacks. You should even be able to do some predictive modeling. >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 I would say frequently. I suspect you could safely review it annually or monthly? As long as you set your rate limit Nx higher than the normal rate for that upd protocol/service where 1<N<??? > 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. If you have Arbor's peakflow this is not hard to do since they keep metadata around much of the traffic they see. But anything that tracks the flow of packets including the standard 5 tuple could be used. > > > 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. Agree. Is this true? 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. I am not aware of anyone rate-limiting UDP itself. Specific ports using UDP yes but not UDP as a protocol. Also when we rate limit it is nearly always done on bps because many routers won't let you do pps. This 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. Should probably be this. UDP has been abused to such an extent that legitimate use may suffer collateral damage and application and protocol developers may want to avoid using UDP as a transport when possible. Also was the should meant to be an RFC2119 should? It probably should be and you should reference that rfc. This TCP has a three- way handshake and SCTP has a four-way handshake, Should probably be this: TCP has a three- way session setup handshake and SCTP has a four-way session setup handshake , Should this be UDP or IP? In the case of SNMP, NTP, CHARGEN, and DNS, a single spoofed IP packet can generate a much larger response to an attack target in many deployments It is true it is a single IP packet, it is slightly more correct to say UDP. I hate the use of DRDOS. Please use amplified reflective attacks instead. You can say amplified reflective DDOS attacks if you like :) That's as far as I got so far. > > > 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]> on behalf of Ca By > <[email protected]> > Date: Monday, July 20, 2015 at 8:46 PM > To: "[email protected]" <[email protected]> > Cc: "[email protected]" > <[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. > This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
