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

From: "Marc Blanchet" <[email-masked]>
Date: Tue, 21 Jul 2015 03:15:20 +0200

FYI. Marc.

Forwarded message:

> From: Ca By <[email-masked]>
> To: [email-masked] <[email-masked]>
> Cc: [email-masked]
> Subject: [OPSEC] draft-byrne-opsec-udp-advisory
> 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
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

---

From: Brian Trammell <[email-masked]>
Date: Tue, 21 Jul 2015 10:49:18 +0200

hi Marc,

Thanks for the pointer. I presume that the opsec list is the right place to discuss this?

I gave it a quick look. One takeaways for the upcoming architectural guidance document: UDP-based encapsulations need to have a good answer as to how they address the reflection and amplification problem (this we already know) as well as some answer about mitigation of simple crap packet floods. Posing the question "where does all of this traffic come from" would be interesting but not addressed by the draft. How much of the problem isn't simply solved by reflection and amplification is unclear to me. I suspect not much.

But the rest of it kind of reads like "we've got filters, and it's our network, and your stuff won't get through, so change your stuff", which is IMO equivalent to "we've got filters and we don't want to have to change them". Filtering and throttling on 17 is fundamentally lazy, and while may currently be acceptable to this one network's customers, it will be less so if and when the traffic mix changes.

An observation: if you can use a magic number (as in draft-hildebrand-spud-prototype as well as draft-herbert-gue) that does appear in reflected packets, i.e. is not part of a valid reply in any protocol is widely used in reflection attacks, your 17 filter turns into a 17 && !magic filter. That doesn't stop crap packet attacks, but crap packet attacks are N times more expensive for an average reflection amplification of N.

Cheers,

Brian

> On 21 Jul 2015, at 03:15, Marc Blanchet <[email-masked]> wrote:
> 
> FYI. Marc.
> 
> Forwarded message:
> 
>> 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
>> Please note that it may take a couple of minutes from the time of submission
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo

---

From: "Marc Blanchet" <[email-masked]>
Date: Tue, 21 Jul 2015 10:53:48 +0200

> Thanks for the pointer. I presume that the opsec list is the right 

Cameron has targeted it to opsec, but the issues are, to me, larger and 
related in general to ossification, transport services, stackevo, etc… 
So I’m not sure, but I wanted to alert people here of this relevant 
document, which comes from a real operator with real concerns and real 
deployment challenges. (I’m not saying the solution is good or bad, 
but more stating that these are real issues found in operator networks 
and that people should be aware of them).

Marc.

>
> I gave it a quick look. One takeaways for the upcoming architectural 
> guidance document: UDP-based encapsulations need to have a good answer 
> as to how they address the reflection and amplification problem (this 
> we already know) as well as some answer about mitigation of simple 
> crap packet floods. Posing the question "where does all of this 
> traffic come from" would be interesting but not addressed by the 
> draft. How much of the problem isn't simply solved by reflection and 
> amplification is unclear to me. I suspect not much.
>
> But the rest of it kind of reads like "we've got filters, and it's our 
> network, and your stuff won't get through, so change your stuff", 
> which is IMO equivalent to "we've got filters and we don't want to 
> have to change them". Filtering and throttling on 17 is fundamentally 
> lazy, and while may currently be acceptable to this one network's 
> customers, it will be less so if and when the traffic mix changes.
>
> An observation: if you can use a magic number (as in 
> draft-hildebrand-spud-prototype as well as draft-herbert-gue) that 
> does appear in reflected packets, i.e. is not part of a valid reply in 
> any protocol is widely used in reflection attacks, your 17 filter 
> turns into a 17 && !magic filter. That doesn't stop crap packet 
> attacks, but crap packet attacks are N times more expensive for an 
> average reflection amplification of N.
>
> Cheers,
>
> Brian
>
>

---

From: Brian Trammell <[email-masked]>
Date: Tue, 21 Jul 2015 12:42:55 +0200

> On 21 Jul 2015, at 10:53, Marc Blanchet <[email-masked]> wrote:
> 
> Cameron has targeted it to opsec, but the issues are, to me, larger and related in general to ossification, transport services, stackevo, etc… So I’m not sure, but I wanted to alert people here of this relevant document, which comes from a real operator with real concerns and real deployment challenges. (I’m not saying the solution is good or bad, but more stating that these are real issues found in operator networks and that people should be aware of them).

Yep.

I do think we need to have an answer to the operations community about why using UDP to evolve the stack is a good idea, and how we intend to address the concerns about crap traffic.

But what we have here is essentially one report from one operator. Useful anecdote, yes, but we need data about the prevalence of this kind of filtering.

Thanks, cheers,

Brian

---

From: "Marc Blanchet" <[email-masked]>
Date: Tue, 21 Jul 2015 12:49:57 +0200

On 21 Jul 2015, at 12:42, Brian Trammell wrote:

>> Cameron has targeted it to opsec, but the issues are, to me, larger 
>> and related in general to ossification, transport services, stackevo, 
>> etc… So I’m not sure, but I wanted to alert people here of this 
>> relevant document, which comes from a real operator with real 
>> concerns and real deployment challenges. (I’m not saying the 
>> solution is good or bad, but more stating that these are real issues 
>> found in operator networks and that people should be aware of them).
>
> Yep.
>
> I do think we need to have an answer to the operations community about 
> why using UDP to evolve the stack is a good idea, and how we intend to 
> address the concerns about crap traffic.
>
> But what we have here is essentially one report from one operator. 
> Useful anecdote, yes, but we need data about the prevalence of this 
> kind of filtering.

- sure. but I’m for one have been involved (managing, configuring, 
monitoring, security, managing ops team, …) in network operations for 
20+ years, I can tell you that we are in some ways very lucky to have an 
operator taking the time to write drafts of this kind and participate in 
IETF. On the other hand, from the operations side, filtering of this 
kind is happening everywhere in all networks and that is almost all the 
time not documented outside the organization. So it will be difficult to 
get some good coverage of what is done on the field, not impossible, but 
… So while I agree that we need to verify, on the other hand, having a 
documented draft on this topic has higher value than just one network 
operator POV, so requires appropriate consideration.

- I really think this draft should also be discussed in various other 
transport mailing lists.

- when I was for a short period of time, co-chair of the IP evol 
program, I suggested to bring some operators in the program to get their 
« reality on the ground » view for our work. Cameron and a few other 
guys were high on my personal list. Maybe I should suggest to the 
current co-chairs about bringing him in the program?

Marc.

>>> guidance document: UDP-based encapsulations need to have a good 
>>> answer as to how they address the reflection and amplification 
>>> problem (this we already know) as well as some answer about 
>>> mitigation of simple crap packet floods. Posing the question "where 
>>> does all of this traffic come from" would be interesting but not 
>>> addressed by the draft. How much of the problem isn't simply solved 
>>> by reflection and amplification is unclear to me. I suspect not 
>>> much.
>>>
>>> But the rest of it kind of reads like "we've got filters, and it's 
>>> our network, and your stuff won't get through, so change your 
>>> stuff", which is IMO equivalent to "we've got filters and we don't 
>>> want to have to change them". Filtering and throttling on 17 is 
>>> fundamentally lazy, and while may currently be acceptable to this 
>>> one network's customers, it will be less so if and when the traffic 
>>> mix changes.
>>>
>>> does appear in reflected packets, i.e. is not part of a valid reply 
>>> in any protocol is widely used in reflection attacks, your 17 filter

---

From: Ken Calvert <[email-masked]>
Date: Tue, 21 Jul 2015 10:18:00 -0400

> - sure. but I’m for one have been involved (managing, configuring, monitoring, security, managing ops team, …) in network operations for 20+ years, I can tell you that we are in some ways very lucky to have an operator taking the time to write drafts of this kind and participate in IETF. On the other hand, from the operations side, filtering of this kind is happening everywhere in all networks and that is almost all the time not documented outside the organization. So it will be difficult to get some good coverage of what is done on the field, not impossible, but … So while I agree that we need to verify, on the other hand, having a documented draft on this topic has higher value than just one network operator POV, so requires appropriate consideration.

Data-gathering about this sounds like a great job for HOPS (BOF Friday a.m.), which I suspect is what Brian had in mind.

> - I really think this draft should also be discussed in various other transport mailing lists.

My one-sentence summary of this draft is "Datagram services considered harmful (by operators)."   If that idea is widely held, it obviously has serious implications for stack evolution, even if the problems described in the draft result mostly from source address spoof-ability.

It kind of makes sense that service providers would prefer a connection-oriented interface between user and network (cf. X.25).   (I would find it ironic if we moved toward a network that is connection-oriented at the edge and datagram on the inside.  I have heard that at least one of the early 70's commercial packet networks - Tymnet? DATAPAC? - was built that way.) 

Ken