Subject: [tsvwg] Stephen Farrell's Discuss on draft-ietf-tsvwg-gre-in-udp-encap-18: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 27 Sep 2016 06:21:47 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-tsvwg-gre-in-udp-encap-18: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I just wanted to check something relatively new (to me
anyway). This week there was an apparently record-breaking
(600+Gbps) DDoS attack on a web site in which GRE traffic is
said to have been a significant part of the attack. (See [1]
for some not very detailed information.)

Is the use of GRE traffic as part of DDoS well known in the
relevant communities? If so, are tunnels such as those
documented here involved or not? If we don't know, should we
try find out before approving this? If we do know, are there
additional security considerations needed here?

   [1] https://noise.getoto.net/tag/gre-ddos/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- Section 5: Do you need to say that (non-handshake?) traffic
that is not properly protected with DTLS MUST be discarded?

- Does 6.2(c) (in the 1st list) suggest some form of new DoS
vector? Not sure myself.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 27 Sep 2016 09:44:51 -0500

Hi, Stephen,

If you get responses from smarter people, please go with those responses,
but ...

> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/

Perhaps coincidentally, "GRE traffic suddenly appearing where GRE traffic
has not appeared before, because intermediate devices don't forward GRE but
do forward UDP" was a major point of discussion with this draft. I don't
remember whether the focus included DDOS, or just the usual
congestion-unresponsive firehose problem that TSV types go on about for
decades, but that's why there's the reference to
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/ (as
[CB]) in this draft - to make sure that a responsible adult can pull the
plug on GRE senders that Just Won't Shut Up.

It seems reasonable to me to ask whether the SHOULD on the use of [CB]
would be better as a MUST, and it's more than reasonable to think about
whether GRE-in-UDP is worse than the usual DDOS traffic type. But there has
been some awareness of the issue, so let's start there in resolving the
DISCUSS.

Spencer, who isn't an author or document shepherd, so let's see what
smarter people think, of course ...

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Sep 2016 15:59:16 +0100

Hiya,

> If you get responses from smarter people, please go with those responses,

Kathleen and I were chatting about this. She asked on
the dots list and got a good response. [1]

So it seems like this is a known, though until recently
less common, form of DDoS attack. I'd say that adding a
warning about that would be good, possibly plus your
suggestion to make [CB] a MUST. I'm agnostic on the
pros and cons of making [CB] a MUST, but would tend
to like it as MUST, if that's acceptable.

Assuming the authors etc. are fine with the above,
then sorting this discuss should be easy.

Cheers,
S.

[1] https://mailarchive.ietf.org/arch/msg/dots/ajG9cgUlGZvPKhpUPCzaa5S77Cg

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 27 Sep 2016 11:06:14 -0500

Stephen and Katheen,

> the dots list and got a good response. [1]

Thanks for chasing this. It's a good example of why we do cross-area review
at IESG evaluation time.

> to like it as MUST, if that's acceptable.

I'd be more agnostic about the pros and cons of the MUST if the authors
take your suggestion to add a warning (SHOULD is "make sure you know what
can happen if you don't", so the more the reader knows about what can
happen, the better).

> then sorting this discuss should be easy.

Easily sorted discusses are fabulous ... what do you think,
authors/shepherds?

Spencer

---

From: Edward <[email-masked]>
Date: Tue, 27 Sep 2016 09:30:54 -0700

As an author, I strongly disagree.  I've seen my fair share of DoS attacks,
and designed and/or operated my fair share of large overlay environments
and NSP networks.  There are a number of problems with the CB as MUST sop
being proposed:

1) Simply saying that a CB is a MUST would not be sufficient;  what form of
CB is a MUST? What monitoring interval? etc etc.  Throwing a MUST in the
draft provides more questions than answers.

2) The fact that this attack had GRE in it has little to know bearing on
this draft, or the DoS.  Attacks like this deliberately abuse protocols;
legislating that they act in a particular way will have little bearing on
their misuse. As an aside here, the article above incorrectly states that
GRE cannot be spoofed.

3) The CB concept itself has serious problems, especially with regard to
cross org operations concerns in remote metering and the like.  It is also,
AFAIK, not implemented anywhere, rendering the encaps useless for those
using 3rd party OEM devices.

4) CB will render this draft DOA:  Very few large scale network operator
will want to use an encaps at an intermediate node that requires (s)
additional protocol machinery on their device (b) additional control
systems that may interfere with existing /underlying/ (read: end to end
principal compliant) traffic and (c) that currently don't exist.  For those
implementing this as an overlay encaps for machines tthe standard would
likely be ignored anyway.  For those not ignoring it: (a) the use of CB as
MUST would render the protocol unusable as shutting down customer
communication altogether because of a capacity concern is something of a no
no and (b) the use of CB results in significantly more work, especially
w/r/t the monitoring requirements mentioned previously.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 27 Sep 2016 09:45:58 -0700

On 9/27/16 9:30 AM, Edward wrote:
> As an author, I strongly disagree.  I've seen my fair share of DoS
> attacks, and designed and/or operated my fair share of large overlay
> environments and NSP networks.  There are a number of problems with
> the CB as MUST sop being proposed:
>
>
> 1) Simply saying that a CB is a MUST would not be sufficient;  what
> form of CB is a MUST? What monitoring interval? etc etc.  Throwing a
> MUST in the draft provides more questions than answers.  

Synthetically generated flows aimed at resource consumption do not honor
circuit breakers. the attack traffic is not a tunnel.

the discuss is wrong headed and misapplied.

> 2) The fact that this attack had GRE in it has little to know bearing
> on this draft, or the DoS.  Attacks like this deliberately abuse
> protocols;  legislating that they act in a particular way will have
> little bearing on their misuse. As an aside here, the article above
> incorrectly states that GRE cannot be spoofed. 
>
> 3) The CB concept itself has serious problems, especially with regard
> to  cross org operations concerns in remote metering and the like.  It
> is also, AFAIK, not implemented anywhere, rendering the encaps useless
> for those using 3rd party OEM devices.
>
> 4) CB will render this draft DOA:  Very few large scale network
> operator will want to use an encaps at an intermediate node that
> requires (s) additional protocol machinery on their device (b)
> additional control systems that may interfere with existing
> /underlying/ (read: end to end principal compliant) traffic and (c)
> that currently don't exist.  For those implementing this as an overlay
> encaps for machines tthe standard would likely be ignored anyway.  For
> those not ignoring it: (a) the use of CB as MUST would render the
> protocol unusable as shutting down customer communication altogether
> because of a capacity concern is something of a no no and (b) the use
> of CB results in significantly more work, especially w/r/t the
> monitoring requirements mentioned previously. 
>
>
>
>
>
>
> On Tue, Sep 27, 2016 at 7:59 AM, Stephen Farrell
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Hiya,
>
>     [1]
>     https://mailarchive.ietf.org/arch/msg/dots/ajG9cgUlGZvPKhpUPCzaa5S77Cg
>     <https://mailarchive.ietf.org/arch/msg/dots/ajG9cgUlGZvPKhpUPCzaa5S77Cg>
>
>     >
>     > On Tue, Sep 27, 2016 at 8:21 AM, Stephen Farrell
>     <[email-masked] <mailto:[email-masked]>>
>     > wrote:
>     >
>     >> Please refer to
>     https://www.ietf.org/iesg/statement/discuss-criteria.html
>     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>     <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/>
>     >>
>     >>
>     >>
>     >>
>     <https://noise.getoto.net/tag/gre-ddos/>
>     >
>     >
>     https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/
>     <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/>
>     (as

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Sep 2016 17:47:54 +0100

> the discuss is wrong headed and misapplied.

Note that the discuss made no mention of [CB].

S.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 27 Sep 2016 09:53:18 -0700

On 9/27/16 6:21 AM, Stephen Farrell wrote:
> relevant communities? 
yes... protocol types other than udp and tcp are implicated in dos
attacks. ip in ip is also kind of popular, so is icmp.
> If so, are tunnels such as those
> documented here involved or not?
gre pdus employeed in a dos attack are not tunneled. they are
synthetically generated. the flows are not tunnels. this is a  pure
volumetric attack. transit providers are largely transparent to GRE so
it's a resonable choice. the traffic could have been spoofed, e.g. bcp
38 filtering on the part of the sending isps would have knocked that
down, but it likely was not given a lack of need to disguise what are
hundreds of thousands of sources.
>  If we don't know, should we
> try find out before approving this?
I recive packets that I don't want all the time.
>  If we do know, are there

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Sep 2016 17:58:05 +0100

On 27/09/16 17:53, joel jaeggli wrote:
> yes...

Right. As previously noted in this thread, it
seems like a warning about that might be useful
if GRE is recently getting more popular for
significant volumes of attack traffic.

And as also previously noted, that would be fine
for me to clear the discuss. If someone wants to
argue such a warning isn't useful that's also fine.

Additionally, we can all jump up and down about [CB],
or not, and either way, I'm happy to watch that
from the sidelines:-)

S.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 27 Sep 2016 12:09:51 -0500

Hi, Stephen and Joel,

> Note that the discuss made no mention of [CB].

Right, and with Joel's input that the GRE showing up in the attack isn't 
being tunneled using UDP, we've gone out of scope for this draft.

Thanks all, for your help with this.

Spencer

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Sep 2016 18:13:34 +0100

> being tunneled using UDP, we've gone out of scope for this draft.

Ah right. So if we're not seeing such GRE-in-UDP attack
traffic then yeah I guess the warning would be bogus,
or wrong-headed or misapplied:-)

I'll clear.

S.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 29 Sep 2016 00:00:59 -0700

On 9/27/16 10:09 AM, Spencer Dawkins at IETF wrote:
> Right, and with Joel's input that the GRE showing up in the attack
> isn't being tunneled using UDP, we've gone out of scope for this draft.
>
yup,thanks for your generous understanding

joel