On Wed, Aug 19, 2015 at 12:06 PM, Smith, Donald < [email protected]> wrote:
> > > 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. > > Yes, agreed. The challenge is that if YouTube switches to QUIC overnight, then your baseline is not very effective > >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. > > Cisco IOS-XR allows PPS rate-limit, this is specifically relevant in when a stateful device such as a CGN is part of the deployed network > > 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. > > ok > Also was the should meant to be an RFC2119 should? It probably should be > and you should reference that rfc. > > Those keywords are are allowed for informational documents AFAIK > 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 :) > > Yeah, i don't like DRDOS either but i used it for consistency with the cited work. Thanks for taking the time to send feedback. CB
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
