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

From: "George, Wes" <[email-masked]>
Date: Tue, 4 Aug 2015 14:37:05 -0400

I'm wondering if perhaps some parts of this udp-advisory document would be better served integrated into this document: http://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-05

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.

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.

---

From: Jared Mauch <[email-masked]>
Date: Tue, 4 Aug 2015 15:17:36 -0400

On Sat, Jul 25, 2015 at 09:21:02PM -0400, George, Wes wrote:
> 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".
> 

	Wes,

	This is sadly not the case as some of the operational
attacks observed have ephemeral ports for both numbers so it
is harder to mitigate as vendors quickly run out of TCAM when 
implementing these features in hardware.  It's not easy to compile
a filter that matches all the traffic and just QoS against the bad
as it's been NTP, DNS, CHARGEN, SSDP and with full UPnP/SSDP enumeration
of hosts within the home occuring, traffic from those inside
hosts mean the call^Wattack is "coming from inside the house".  With
attacks using UDP/80,443 as common destination ports it's not easy to 
discern these from actual NAT'ed traffic egressing a home or otherwise.

	We sadly had to deploy some UDP limits at $dayjob due to
attack sizes.  Once we did this the daily triage went away.  We were not
happy about the E2E aspect of this but the damage is now limited and
people can literaly sleep better at night with fewer pages and escalations.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 4 Aug 2015 17:57:47 -0700

> people can literaly sleep better at night with fewer pages and escalations.

Which does not bode well for WebRTC (which uses UDP for its SRTP and its data channel) or QUIC.

-d

> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

---

From: Ca By <[email-masked]>
Date: Tue, 4 Aug 2015 22:26:08 -0700

On Tuesday, August 4, 2015, George, Wes <[email-masked]> wrote:

> I'm wondering if perhaps some parts of this udp-advisory document would be
> better served integrated into this document:
> http://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-05
>
> Thanks,
>
>
>
> Wes
>
>
>

I believe that has already taken place in the recent revisions of said
I-d's security section.

This is both important and good.

To that end, I would like to see opsec take on draft-byrne-opsec-udp-advisory
to publish the full threat and known remediation and related impacts that
are within the opsec charter. .

CB

>
> From: OPSEC <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> on behalf of Ca
> By <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> To: "[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>" <
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> Cc: "[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>"
> <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> >
> 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.
>
> 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:
> 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.
>

---

From: Ca By <[email-masked]>
Date: Tue, 4 Aug 2015 22:37:25 -0700

Wes

On Saturday, July 25, 2015, George, Wes <[email-masked]> 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

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 05 Aug 2015 14:06:12 +0700

On 5 Aug 2015, at 12:37, Ca By wrote:

> Constantly re-evaluated is not scalable.

It is in fact scalable, given network infrastructure with sufficient 
instrumentation capabilities/capacity and sufficient telemetry 
collection/analysis.  Many organizations do this today.

Not everyone has those things, however.  They should, and eventually 
most will, but it takes time.

The other factor is the reliable automation of policy construction and 
deployment based on said analysis.  Besides the usual gaps and hurdles 
(standardization of mechanisms still in its relative infancy, lack of 
skills/resources in many organizations to perform systems integration, 
et. al.), there is a potential for cascading, feedback loops, and other 
undesirable forms of oscillation.

> I am open to more discussion here. I do not want to be ambiguous

Many folks here might generally agree that we don't want to see tons 
more UDP dumped into the cesspit (QUIC and WebRTC come to mind, as Dan 
Wing notes) in the current situation, but flatly stating 'no more new 
UDP, ever' may have difficulty n the necessary consensus in the broader 
arena.

That being said, QUIC and WebRTC in particular are significantly 
problematic on the operational side of things due to many aspects of 
this general problem-set.  Some middle ground between 'no new UDP, ever' 
and 'let's switch all Web traffic over to UDP, because it'd be cool' 
ought to be possible, no?

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: Ca By <[email-masked]>
Date: Wed, 5 Aug 2015 05:24:34 -0700

On Wednesday, August 5, 2015, Roland Dobbins <[email-masked]> wrote:

> Not everyone has those things, however.  They should, and eventually most
> will, but it takes time.
>
> skills/resources in many organizations to perform systems integration, et.
> al.), there is a potential for cascading, feedback loops, and other
> Many folks here might generally agree that we don't want to see tons more
> UDP dumped into the cesspit (QUIC and WebRTC come to mind, as Dan Wing
> notes) in the current situation, but flatly stating 'no more new UDP, ever'
> may have difficulty n the necessary consensus in the broader arena.
>
> problematic on the operational side of things due to many aspects of this
> general problem-set.  Some middle ground between 'no new UDP, ever' and
> 'let's switch all Web traffic over to UDP, because it'd be cool' ought to
> be possible, no?
>
>
Yes. Can you please suggest text?

CB

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 05 Aug 2015 19:31:36 +0700

On 5 Aug 2015, at 19:24, Ca By wrote:

> Can you please suggest text?

Yes, let me think on it.

---

From: Jared Mauch <[email-masked]>
Date: Fri, 14 Aug 2015 08:59:21 -0400

> Which does not bode well for WebRTC (which uses UDP for its SRTP and its data channel) or QUIC.

	Yes, I think this is why the draft is important to discuss
at least so protocol people understand the operator challenges
faced.  

	Most people don't realize that TCP performance is many times
UDP performance in hosts as well.

[jared@npd ~]$ iperf -c localhost
------------------------------------------------------------
Client connecting to localhost, TCP port 5001
TCP window size: 2.50 MByte (default)
------------------------------------------------------------
[  3] local 127.0.0.1 port 55428 connected with 127.0.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  20.5 GBytes  17.6 Gbits/sec
[jared@npd ~]$ iperf -u -b 99999m -c localhost
------------------------------------------------------------
Client connecting to localhost, UDP port 5001
Sending 1470 byte datagrams, IPG target: 0.12 us (kalman adjust)
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 127.0.0.1 port 33166 connected with 127.0.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.59 GBytes  1.37 Gbits/sec
[  3] Sent 1163581 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec  1.59 GBytes  1.36 Gbits/sec   0.000 ms 5416/1163581 (0.47%)

	This means you're not getting the UDP performance advantage
you think you are.  The challenge here appears to be part of assumptions
which are clearly untrue.

	Looking at my IPv4 stats:

	89.4% TCP
	10.5% UDP
	0.15% ICMP
	.. other

	Doing a rate-limit like this:

ipv4 access-list ntp-limit
 permit udp any eq 123 any
 permit udp any eq 1900 any
 permit udp any eq 19 any

	Seems perfectly reasonable and has reduced the impact
of attacks seen by our customers.

	- Jared

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 19 Aug 2015 19:06:25 +0000

H8Hz
[email-masked]

>       From: OPSEC [[email-masked]] on behalf of George, Wes [[email-masked]]
>       Sent: Saturday, July 25, 2015 7:21 PM
>       To: Ca By; [email-masked]
>       Cc: [email-masked]
>       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-masked]> on behalf of Ca By <[email-masked]>
>       To: "[email-masked]" <[email-masked]>
>       Cc: "[email-masked]" <[email-masked]>
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.

---

From: Ca By <[email-masked]>
Date: Wed, 19 Aug 2015 12:30:48 -0700

On Wed, Aug 19, 2015 at 12:06 PM, Smith, Donald <
[email-masked]> wrote:

> >       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.
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
> If you have Arbor's peakflow this is not hard to do since they keep
> metadata around much of the traffic they see.
> 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?
>
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

>    application and protocol developers may want to avoid using UDP as a
ok

> and you should reference that rfc.
Those keywords are are allowed for informational documents AFAIK

>
> 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

---

From: John Kristoff <[email-masked]>
Date: Wed, 19 Aug 2015 14:38:24 -0500

Hi Don,

On Wed, 19 Aug 2015 19:06:25 +0000

> using UDP yes but not UDP as a protocol.

As a specific IP protocol, it happens and it has happened.  And not
just with UDP.  If you're not on NANOG, I described what was done in
a university environment I was at years ago:

  <https://mailman.nanog.org/pipermail/nanog/2015-July/078010.html>

While perhaps not on transit networks, some networks have UDP dropped
by their upstream(s) or at their own "border", primarily as a means to
mitigate all the UDP-based amplified reflection traffic they might
otherwise have to carry.

Its not very elegant perhaps, but it does happen and seemingly the
trade-off some find to be worth it.

John

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 19 Aug 2015 19:53:48 +0000

Thanks John, and universities are their own ISP sort of so I see how you relate this.

But I am not sure that supports their original statement about ISPs limiting udp.
I have discussed this with several large ISPs. So far I haven't heard anyone advocating rate limiting UDP as a protocol.
Now udp:123 upd:1900 yes, many of us are or will be rate limiting those.

Things like udp:1900, a lan protocol, could even in theory even be dropped. I know of no valid use of it over the Internet.
RIPv1 same it is depreciated.

However if they just said some networks may rate limit udp ... it would still cover the basic concept without making any false claims.
If our enterprise started seeing a lot of udp reflective attacks I would recommend this approach if we could limit it to a specific set of ports.

H8Hz

From: John Kristoff [[email-masked]]
Sent: Wednesday, August 19, 2015 1:38 PM
To: Smith, Donald
Cc: George, Wes; Ca By; [email-masked]; [email-masked]
Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory

Hi Don,

John

---

From: Jared Mauch <[email-masked]>
Date: Wed, 19 Aug 2015 16:05:07 -0400

> On Aug 19, 2015, at 3:53 PM, Smith, Donald <[email-masked]> wrote:
> 

We had to do these to mitigate issues and have some fairly generous rate-limits compared to the observed traffic rates.

While we don’t do UDP across the board, some of the attacks have been creeping to make it more likely.

- Jared

---

From: Ca By <[email-masked]>
Date: Wed, 19 Aug 2015 13:08:06 -0700

On Wed, Aug 19, 2015 at 12:53 PM, Smith, Donald <
[email-masked]> wrote:

> I have discussed this with several large ISPs. So far I haven't heard
> anyone advocating rate limiting UDP as a protocol.
As an edge network provider, i rely on my upstream backbone provide to stop
my attachment circuit from getting saturated with UDP junk.  Unfortunately,
my upstream also sells a DDoS protection service and network based firewall
service which cost north of 10x what i normally pay per meg.  When i
provide them with a list of ports, and then add some ports later, they
refer me to said expensive products.

If i give them a one-liner policer for UDP, then there is nothing much for
me or them to manage.  We have not discussed in 2 years in fact.

> Things like udp:1900, a lan protocol, could even in theory even be
> dropped. I know of no valid use of it over the Internet.
And Chargen, and SNMP, and ...

> However if they just said some networks may rate limit udp ... it would
> still cover the basic concept without making any false claims.
> If our enterprise started seeing a lot of udp reflective attacks I would
> recommend this approach if we could limit it to a specific set of ports.
>
> H8Hz
> Cc: George, Wes; Ca By; [email-masked];
> [email-masked]
> 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.
>

---

From: John Kristoff <[email-masked]>
Date: Wed, 19 Aug 2015 15:30:06 -0500

On Wed, 19 Aug 2015 19:53:48 +0000

> But I am not sure that supports their original statement about ISPs

I took the context of the discussion at face value.  Also, if I'm not
mistaken,the draft refers more generally to "network operators", which
may include a whole class of networks.  I'm not supportive of the
draft's recommendation on that more general basis and I'm not aware of
so-called transit ISPs that do this already, but there are networks and
network operators that have and do rate limit at borders and throughout
their network.  Semantics.  :-)

> However if they just said some networks may rate limit udp ... it
> would still cover the basic concept without making any false claims.

That would be better I agree and if their was some discussion about the
trade-offs of doing these sorts of things, and perhaps some discussion
about the effects of them depending on where they reside, that might be
helpful too.

> If our enterprise started seeing a lot of udp reflective attacks I
> would recommend this approach if we could limit it to a specific set
> of ports.

There is likely going to be some number of benign packets that are going
to be dropped. Clients that just happen to pick the unlucky ephemeral
value of 1900 (or whatever other unlucky value is being filtered) plus
the occasional port selection by NAPT devices will be caught up in the
packet dropping dragnet.  Some people clearly don't mind this
collateral damage and no amount of e2e talk will convince everyone.
This too should be clearly spelled out so the trade-offs, potential
problems and *sob* loss of transparency are documented.

John

---

From: Jared Mauch <[email-masked]>
Date: Wed, 19 Aug 2015 22:03:43 -0400

I can name two that do this in some part at least. 

Jared Mauch

> On Aug 19, 2015, at 4:30 PM, John Kristoff <[email-masked]> wrote:
> 
> I'm not aware of
> so-called transit ISPs that do this already,

---

From: Ca By <[email-masked]>
Date: Thu, 20 Aug 2015 15:23:05 -0700

> recommend this approach if we could limit it to a specific set of ports.

US CERT via a reference to Level3 has suggested that you may want to add
UDP 111 to your list.

https://www.us-cert.gov/ncas/alerts/TA14-017A

http://blog.level3.com/security/a-new-ddos-reflection-attack-portmapper-an-early-warning-to-the-industry/

The larger point being, you can have an ever growing constantly maintained
list of after-the-fact ports that cause problems.

Or, you can come to the conclusion that UDP is broadly abused

>From the Level3 blog:

"Global portmap traffic grew by a factor of 22x when comparing the last 7
days of June with the 7 days, ending August 12.  Clearly the success of
using this method for attacks is growing aggressively. "

This fits in-line with what the I-D says: have a baseline for UDP and
enforce it (providing a healthy margin of growth, which is well below 22x.)

CB