Subject: [tsvwg] Best transport selection during an attack?

From: Aaron Falk <[email-masked]>
Date: Tue, 3 Nov 2015 14:42:23 +0900

Dear TSV-

There was a discussion in DDoS Open Threat Signaling (DOTS) this afternoon
about selecting a transport that is likely to be able to carry an "SOS"
message when a network is under DDOS.  UDP gets filtered.  TCP may have
trouble getting ACKs back through a congested link.  They'd like some
advice.  I suggested they come to the TSV Area meeting (but there isn't
one).  So, can the chairs give a few minutes from TSVWG to layout the
problem?

See - draft-reddy-dots-transport-01 Presentation
<https://www.ietf.org/proceedings/94/slides/slides-94-dots-5.pdf>

--aaron

---

From: Ca By <[email-masked]>
Date: Tue, 3 Nov 2015 06:01:47 -0800

> <https://www.ietf.org/proceedings/94/slides/slides-94-dots-5.pdf>

Please see  https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00

I am a network operator (eyeballs)

 Nearly 100% of my daily volumetric attacks are on udp and there is no
simple way to proactively stop this traffic aside from flat udp filters.

Using udp would be counter productive.  Anything aside from udp will do
fine. Sctp, tcp, udp in esp ...

You can also look to

https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-06

Don't use udp:

"These mechanisms are difficult to implement correctly. For most

applications, the use of one of the existing IETF transport protocols
is the simplest method of acquiring the required mechanisms.
Consequently, the RECOMMENDED alternative to the UDP usage described
in the remainder of this section is the use of an IETF transport
protocol such as TCP [RFC0793 <https://tools.ietf.org/html/rfc0793>],
Stream Control Transmission Protocol (SCTP) [RFC4960
<https://tools.ietf.org/html/rfc4960>], and SCTP Partial Reliability
Extension (SCTP-PR) [RFC3758 <https://tools.ietf.org/html/rfc3758>],
or Datagram Congestion Control Protocol (DCCP) [RFC4340
<https://tools.ietf.org/html/rfc4340>] with its different congestion
control types [RFC4341
<https://tools.ietf.org/html/rfc4341>][RFC4342][RFC5622
<https://tools.ietf.org/html/rfc5622>]."

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 3 Nov 2015 10:30:35 -0500

On 11/3/2015 12:42 AM, Aaron Falk wrote:
> Dear TSV-
>
> There was a discussion in DDoS Open Threat Signaling (DOTS) this 
> afternoon about selecting a transport that is likely to be able to 
> carry an "SOS" message when a network is under DDOS.  UDP gets 
> filtered.  TCP may have trouble getting ACKs back through a congested 
> link.  They'd like some advice.  I suggested they come to the TSV Area 
> meeting (but there isn't one).  So, can the chairs give a few minutes 
> from TSVWG to layout the problem?

The signaling shouldn't be high-bandwidth, so supporting multiple 
options, and using all available options, hoping at least one gets 
through, seems totally feasible to me.  The messaging just needs to be 
able to support de-duplication, in case multiple signaling channels 
happen to work.

Obviously any UDP-based options will be expected to follow the TSVWG UDP 
Guidelines RFC.  Whether or not UDP will work between networks can be 
tested and determined ahead of time, so resolving UDP-blocking problems 
can be dealt with in non-realtime (the same problem may exist for 
blocking of unknown TCP ports anyways, so testing of the signaling 
channel should always be done in nominal conditions, ahead of when its 
needed for attack response).  I don't think there are any real obstacles 
to having a UDP-based option, it's just that it seems like a good idea 
to have other options.

Using AQM with flow-based hashing like fq_codel on the congested link 
may help a bit with the TCP ACK problem, as well, but of course that's 
outside the protocol.  That same problem impacts SCTP.

---

From: Ca By <[email-masked]>
Date: Tue, 3 Nov 2015 08:22:25 -0800

On Tue, Nov 3, 2015 at 7:30 AM, Wesley Eddy <[email-masked]> wrote:

>> afternoon about selecting a transport that is likely to be able to carry an
>> "SOS" message when a network is under DDOS.  UDP gets filtered.  TCP may
>> have trouble getting ACKs back through a congested link.  They'd like some
> The signaling shouldn't be high-bandwidth, so supporting multiple options,
> and using all available options, hoping at least one gets through, seems
> totally feasible to me.  The messaging just needs to be able to support
> de-duplication, in case multiple signaling channels happen to work.
>
> tested and determined ahead of time, so resolving UDP-blocking problems can
> be dealt with in non-realtime (the same problem may exist for blocking of
> unknown TCP ports anyways, so testing of the signaling channel should
> always be done in nominal conditions, ahead of when its needed for attack
> response).  I don't think there are any real obstacles to having a
> UDP-based option, it's just that it seems like a good idea to have other
> options.
>
>
This is not correct, at least in the case i am most familiar with.

Check this diagram

https://twitter.com/theipv6guy/status/623535325915168768

The dotty yellow lines that cross the blue lines represent the packet loss
that UDP policers cause \ absorb during a UDP DDoS attack.

With DOTS in UDP, you are putting the DOTs traffic in that path that
becomes the most lossy during a a DDoS.

> Using AQM with flow-based hashing like fq_codel on the congested link may
> help a bit with the TCP ACK problem, as well, but of course that's outside
> the protocol.  That same problem impacts SCTP.
>
>
>
>

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 3 Nov 2015 11:30:44 -0500

> becomes the most lossy during a a DDoS.

You might have missed that I suggested to use multiple signaling 
channels, an dnot rely on UDP?

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 04 Nov 2015 10:13:46 +0900

> able to support de-duplication, in case multiple signaling channels 

Concur 100% with your very salient observations.

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

---

From: Aaron Falk <[email-masked]>
Date: Wed, 4 Nov 2015 10:29:48 +0900

On Wed, Nov 4, 2015 at 12:30 AM, Wesley Eddy <[email-masked]> wrote:

> Whether or not UDP will work between networks can be tested and determined
> ahead of time, so resolving UDP-blocking problems can be dealt with in
> non-realtime (the same problem may exist for blocking of unknown TCP ports
> anyways, so testing of the signaling channel should always be done in
> nominal conditions, ahead of when its needed for attack response).

Wes-

DOTS has a use case where the DOTS server may in a cloud provider, ie, not
be in an adjacent network.  I think your comment above may be difficult to
implement since the client would require cooperation from network providers
with whom they have no business relationship.  And, you might not be able
to tell you have a problem getting UDP through until you are under attack,
when some operator may implement filtering that inhibits connectivity.

--aaron

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 04 Nov 2015 10:37:19 +0900

On 4 Nov 2015, at 10:29, Aaron Falk wrote:

> And, you might not be able to tell you have a problem getting UDP 
> through until you are under attack,

Regular heartbeats between clients and servers, clients and relays, and 
relays and servers can serve the function of ensuring end-to-end 
connectivity on an ongoing basis.

Failure to receive service request acknowledgements can serve this 
purpose under duress.

It's expected that DOTS clients will update DOTS servers (either 
directly or via DOTS relays) with either continued mitigation requests 
and/or situational updates with regards to mitigation efficacy 
throughout mitigation service windows.  Likewise, DOTS servers are 
expected to do the same with regards to DOTS clients (again, either 
directly or via DOTS relays).

Note that other than a DOTS server receiving a DOTS mitigation service 
requests, none of these message types are necessary in order to 
mitigation service to be initiated.  They are important and useful, but 
not mission-critical; the only mission-critical DOTS messages are 
mitigation service requests from DOTS clients and mitigation service 
refusals from DOTS servers.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 4 Nov 2015 02:08:03 +1100

On Wed, Nov 4, 2015 at 1:01 AM, Ca By <[email-masked]> wrote:

<snip>

> https://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-06

for the data in question, the need is a packet which:
  1) is not going to require state be maintained from client -> server
  2) not require an ACK from the server (or management of a session at all
  3) not need many / any round-trips in order to get the job done

The thought expressed in slideware (and txt I believe) was:
  "Be able to send from client -> server a packet with:
   auth token
   'help!' message
   <nothing else>"

udp seems to fit the bill.. I suppose someone could just crap out a
raw IP packet with the data, because why bother putting an L4 header
at all?

> applications, the use of one of the existing IETF transport protocols is the
> simplest method of acquiring the required mechanisms. Consequently, the
> RECOMMENDED alternative to the UDP usage described in the remainder of this
> section is the use of an IETF transport protocol such as TCP [RFC0793],
> Stream Control Transmission Protocol (SCTP) [RFC4960], and SCTP Partial
> Reliability Extension (SCTP-PR) [RFC3758], or Datagram Congestion Control
> Protocol (DCCP) [RFC4340] with its different congestion control types
> [RFC4341][RFC4342][RFC5622]."
>
>
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots
>

---

From: Stefan Fouant <[email-masked]>
Date: Tue, 3 Nov 2015 18:06:20 +0000

>raw IP packet with the data, because why bother putting an L4 header

As it seems like there is not a general consensus here, and there are
valid points for both a connection-oriented and connection-less approach,
wouldn¹t it be feasible to have both?

While I do agree with your points above, I can see the case for a stateful
approach so that a DOTS client can receive notification that the request
went through... Of course, such a response may never come if the link is
saturated, but not all attacks are link saturating. In these cases there
is tremendous value to confirmation of a received request. If not, a
fallback mechanism can kick in and employ the use of UDP.

Stefan Fouant
JNCIE-SEC, JNCIE-SP, JNCIE-ENT, JNCI, CISSP
Senior Security Engineer
Corero Network Security
Mobile: +1.703.625.6243

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 04 Nov 2015 06:54:49 +0900

On 4 Nov 2015, at 3:06, Stefan Fouant wrote:

> I can see the case for a stateful approach so that a DOTS client can 
> receive notification that the request
> went through...

It's already been determined that both stateless and stateful transports 
are necessary because of overly-restrictive network access policies in 
many environments - we discussed that very early on, IIRC.

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 04 Nov 2015 07:10:18 +0900

On 4 Nov 2015, at 1:22, Ca By wrote:

> at least in the case i am most familiar with.

It is important to keep this part in mind.

> becomes the most lossy during a a DDoS.

This is an overgeneralization - see above.

There are lots of topological and pathing assumptions being made, here, 
as well as policy-filtering assumptions.

It has been clear from the beginning of this effort that both stateless 
and stateful transport options are necessary, due to overly-restrictive 
network access policies, edge QoSing as a (counterproductive, IMHO) 
measure against UDP reflection/amplification attacks, etc.  This has 
been discussed on-list and in meetings, it's unclear why it's become 
contentious, all of a sudden.

---

From: Aaron Falk <[email-masked]>
Date: Wed, 4 Nov 2015 13:02:28 +0900

TSVWG chairs-

Will you allocate some time for this topic?

--aaron

On Wed, Nov 4, 2015 at 7:10 AM, Roland Dobbins <[email-masked]> wrote:

> There are lots of topological and pathing assumptions being made, here, as
> well as policy-filtering assumptions.
>
> network access policies, edge QoSing as a (counterproductive, IMHO) measure
> against UDP reflection/amplification attacks, etc.  This has been discussed
> on-list and in meetings, it's unclear why it's become contentious, all of a
> sudden.
>

---

From: [email-masked]
Date: Wed, 4 Nov 2015 08:56:25 -0000

I'm in favour - but I am currently in a different timezone to my co-chair
- who is managing our agenda time...

Curiously: think this could be an excellent extension to the TAPS API -
saying you want robustness and letting it choose protocol - but we need
first of all to see if we can get something useful from TAPS first before
we build new "features":-)

Seriously: I think it deserves a heads-up presentation of the problem to
be addressed.

Gorry

>> measure

---

From: "Black, David" <[email-masked]>
Date: Thu, 5 Nov 2015 00:24:08 +0000

> Seriously: I think it deserves a heads-up presentation of the problem to

Yes, that can be done.  I'm pre-bashing today's agenda now - we'll confirm
the changes at the start of the meeting - there's at least one other item
that needs to be added to the agenda.

There is definitely time available for a heads-up presentation of the
problem (5-10 min).  However ... there is definitely not time available
for an extensive discussion (e.g., 30min).

I assume that this is about draft-reddy-dots-transport-01 - who's
volunteering to present (plus summarize relevant dots WG and mailing list
discussions)?

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 04, 2015 3:56 AM
> To: Aaron Falk
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [tsvwg] [Dots] Best transport selection during an attack?
>

---

From: Aaron Falk <[email-masked]>
Date: Thu, 5 Nov 2015 09:34:40 +0900

On Thu, Nov 5, 2015 at 9:24 AM, Black, David <[email-masked]> wrote:

> who's

I'll leave that to the DOTS folks to figure out.

--aaron

---

From: "Black, David" <[email-masked]>
Date: Thu, 5 Nov 2015 00:42:39 +0000

Talking points are *exactly* what's wanted - are the slides from draft-reddy
appropriate as a jumping-off point, or are there other slides that you'd
prefer?

It's ok for you to not agree with the slide contents if you reuse someone else's deck;-).

Thanks,
--David

> From: Teague, Nik [mailto:[email-masked]]
> Sent: Wednesday, November 04, 2015 7:38 PM
> To: Black, David; [email-masked]; Aaron Falk
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Dots] [tsvwg] Best transport selection during an attack?
> Importance: High
> 
> Hi,
> 
> On 05/11/2015 09:24, "Dots on behalf of Black, David"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
> I could speak - I don’t have time to do slides but I could certainly speak
> to the problem space.
> 
> Related drafts are:
> 
> https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/
> 
> 
> https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/
> 
> 
> draft-reddy-dots-transport-01 is a talking point but we’re in the protocol
> design infancy stage so I wouldn’t want to put too much weight on a given
> suggested solution at this stage
> 
> 
> Thanks,
> 
> -Nik

---

From: "Black, David" <[email-masked]>
Date: Thu, 5 Nov 2015 01:01:12 +0000

> I’m fine with them being a jumping off point for the discussion - the
> discussion is around the ‘SOS’ message transport.

That works for me.  I'll cross-post those slides to the TSVWG meeting
materials - you and Prashanth can sort out who wants to present.
	
Thanks,
--David

> Sent: Wednesday, November 04, 2015 7:51 PM
> On 05/11/2015 09:42, "Black, David" <[email-masked]> wrote:
> 
> The slides presented are here:
> 
> https://www.ietf.org/proceedings/94/slides/slides-94-dots-5.pdf
> 
> 
> I’m fine with them being a jumping off point for the discussion - the
> discussion is around the ‘SOS’ message transport.
> 
> I would of course defer to Prashanth who presented originally as Tiru
> couldn’t be here if they would prefer to represent their slides.
> 
> Thanks,
> 
> -Nik
>

---

From: "Teague, Nik" <[email-masked]>
Date: Thu, 5 Nov 2015 00:38:29 +0000

Hi,

Related drafts are:

Thanks,

-Nik

---

From: "Teague, Nik" <[email-masked]>
Date: Thu, 5 Nov 2015 00:51:20 +0000

Thanks,

-Nik

---

From: Andrew Mortensen <[email-masked]>
Date: Wed, 4 Nov 2015 19:58:49 -0500

> On Nov 4, 2015, at 7:51 PM, Teague, Nik <[email-masked]> wrote:
> 

And in fairness to the authors of draft-reddy-dots-transport, I believe they’re simply aligning the draft with the OP-001 requirement in the requirements draft:

   OP-001  Use of Common Transports: DOTS MUST operate over common
      standardized transport protocols.  While the protocol resilience
      requirement strongly RECOMMENDS the use of connectionless
      protocols, in particular the User Datagram Protocol (UDP)
      use of a standardized, connection-oriented protocol
      like the Transmission Control Protocol (TCP) MAY be
      necessary due to network policy or middleware limitations.

<https://tools.ietf.org/html/draft-ietf-dots-requirements-00#section-2.2>

andrew

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 05 Nov 2015 10:22:27 +0900

Hi David,

anything in the range of 1-5 minutes can be useful.

 From a practical point, the key objective is that it would be nice to 
have a few more "Transport Minds" looking at the protocols we need to 
use for some of DOTS communication (as some will be operating under 
duress).

I will be in the TSV meeting to make the call for comments on that.
Which will take about 1minute (=60 seconds.)

If one of our editors likes to raise this by some more, that's fine. The 
objective is not to come to a solution or conclusion, but rather to 
create awareness for the problem and invite feedback from the transport 
area on this specific problem, so we don't screw things up.

As saag and tsvwg are at the same time, I will be attending tsvwg to 
raise this issue while my co-chair Roman will be presenting our status 
at saag.

Best, Tobias (co-chair DOTS)

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 05 Nov 2015 10:40:41 +0900

On 5 Nov 2015, at 10:22, Tobias Gondrom wrote:

> If one of our editors likes to raise this by some more, that's fine.

Some background and context may be helpful for those new to DOTS:

DOTS Operational Requirements overview preso .pdf from IETF 93:

<https://app.box.com/s/wwvlklsqsaeus3upx2sssxu4p8wytpqq>

DOTS use-cases preso .pdf from IETF 94:

<https://app.box.com/s/pxdectifypevcvcyu1mm3fncvpv1mum4>

draft-ietf-dots-requirements-00:

<https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/>

draft-ietf-dots-use-cases-00:

<https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/>

---

From: "Black, David" <[email-masked]>
Date: Thu, 5 Nov 2015 01:42:34 +0000

Hi Tobias,

It looks like Nik has volunteered as the initial "designated victim" to
foster this TSVWG discussion (I squeezed the agenda and think I found
10 minutes), plus based on a quick look, I see enough background in the
slides for draft-reddy-dots-transport to explain the problem.

If you'd prefer to go to saag, I'll be happy to pass along your request.

On scheduling, my operating theory has been that as long as one tsvwg
session doesn't conflict w/saag, things should be ok ... and you've just
found the security flaw in that algorithm (can fail to deal w/security
concerns that arise during the meeting week).

I'll leave it to the SEC ADs to decide whether to put tsvwg on saag's 
meeting conflict list.  Perhaps you or Roman could mention that to them.

Nik - thanks for stepping up!

Thanks,
--David

> From: Tobias Gondrom [mailto:[email-masked]]
> Sent: Wednesday, November 04, 2015 8:22 PM
> To: Black, David; [email-masked]; [email-masked]

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 5 Nov 2015 01:42:48 +0000

> <https://tools.ietf.org/html/draft-ietf-dots-requirements-00#section-2.2>

I wanted to make sure DOTS is aware of RFC5405 and its intended successor draft-eggert-tsvwg-rfc5405bis.

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 5 Nov 2015 01:43:47 +0000

On 2015-11-05, at 10:42, Lars Eggert <[email-masked]> wrote:
> draft-eggert-tsvwg-rfc5405bis

draft-ietf-tsvwg-rfc5405bis (copy/paste error)

Lars

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 05 Nov 2015 10:50:05 +0900

On 5 Nov 2015, at 10:43, Eggert, Lars wrote:

> draft-ietf-tsvwg-rfc5405bis

We are aware - I believe it has been discussed on-list, and has been 
brought up in verbal discussions.

Thanks for the pointer!

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Wed, 4 Nov 2015 20:54:16 -0500

Yes, thank you for bringing this up. Speaking for myself, I believe the DOTS signal (distinct from bulk data exchanges, which must use reliable transports per requirements draft) fits the low-traffic characteristics of section 3.1.2.

andrew

On Thursday, November 5, 2015, Eggert, Lars <[email-masked] <mailto:[email-masked]>> wrote:

Lars

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 05 Nov 2015 10:54:27 +0900

Hi David,

no problem. All good.
If possible, could I get from the DOTS time the first 30 seconds for a 
quick call from a DOTS WG chair organisational perspective and am then 
very happy for Nik to talk about the technical issue and where we need 
advise.

And no worries, there is no conflict. That is the benefit of having two 
co-chairs.
If I can roughly know the time when you plan the DOTS related time slot, 
that would be helpful, but not essential

I will come to you at the beginning of TSV.

Cheers, Tobias

---

From: "Black, David" <[email-masked]>
Date: Thu, 5 Nov 2015 02:32:43 +0000

Hi Tobias,

Sure, happy to give you 30 seconds during the initial agenda review/bash.

DOTS session is at very end (last 10 minutes), but we might get to it early.

Thanks,
--David

> Sent: Wednesday, November 04, 2015 8:54 PM

---

From: "Teague, Nik" <[email-masked]>
Date: Thu, 5 Nov 2015 06:24:09 +0000

On 05/11/2015 15:08, "Dots on behalf of kaname nishizuka"
<[email-masked] on behalf of [email-masked]> wrote:
>
>IMHO, in this meaning, "SOS" is a little bit confusing because it seems
>like the signaling is one directional.

We should probably standardise on something like mitigation service
request, response and status(?).

-nik

---

From: <[email-masked]>
Date: Thu, 5 Nov 2015 07:39:53 +0000

Hi Kaname,

I agree with your comment about the status. 

FYI, we had this requirement in -00 of https://tools.ietf.org/html/draft-reddy-dots-transport-00#section-4: 

   o  Acknowledgement for the processing of a filtering request and the
      enforcement of associated countermeasures.

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de kaname nishizuka
> Envoyé : jeudi 5 novembre 2015 07:09
> À : Roland Dobbins; [email-masked]
> Cc : [email-masked]
> Objet : Re: [Dots] [tsvwg] Best transport selection during an attack?
> 
> 
>  >the only mission-critical DOTS messages are mitigation service requests
> from DOTS clients and mitigation service refusals from DOTS servers.
> 
> I'm in favor of the pointing out of the latter point: mitigation service
> In operator's point of view, returning of status is indispensable to know
> the mitigation is succeed or not.
> Without such information, it will take more time to decide the next
> action, so it will harm the victim longer.
> 
> regards,
> kaname nishizuka
> On 2015/11/04 10:37, Roland Dobbins wrote:
> and/or situational updates with regards to mitigation efficacy throughout
> mitigation service windows.  Likewise, DOTS servers are expected to do the
> same with regards to DOTS clients (again, either directly or via DOTS
> relays).
> >
> requests, none of these message types are necessary in order to mitigation
> service to be initiated.  They are important and useful, but not mission-
> critical; the only mission-critical DOTS messages are mitigation service
> requests from DOTS clients and mitigation service refusals from DOTS
> servers.
> >

---

From: "Mortensen, Andrew" <[email-masked]>
Date: Thu, 5 Nov 2015 03:14:12 -0500

Yes, this is captured in OP-005 of the requirements draft. I encourage WG
members to read it and send feedback. Thank you.

andrew

On Thursday, November 5, 2015, <[email-masked]> wrote:

> FYI, we had this requirement in -00 of
> https://tools.ietf.org/html/draft-reddy-dots-transport-00#section-4:
>
> > De : Dots [mailto:[email-masked] <javascript:;>] De la part de
> kaname nishizuka
> > À : Roland Dobbins; [email-masked] <javascript:;>
> > Cc : [email-masked] <javascript:;>
> mitigation
> > > Roland Dobbins <[email-masked] <javascript:;>>
> > >
> > > [email-masked] <javascript:;>
> > [email-masked] <javascript:;>
> [email-masked] <javascript:;>

---

From: <[email-masked]>
Date: Thu, 5 Nov 2015 09:29:03 +0100

Hi,

if DOTS allows for transport options, is QoS/DiffServ a possible option supporting a desired solution? Sure, DiffServ isn't available everywhere, that's why I call it an option. But if QoS is supported at an access, why shouldn't it be used to ensure reliable communication?

Regulation in my country enforces reliable VoIP emergency calls. This mechanism can't be used for DOTS I think, but there seem to be some parallels. The emergency call:
- must work under any network conditions
- must be authenticated and authorized
- must reach a special site (two in fact, the provider phone 
  service server and from there if possible the emergency call 
  center closest to the calling party - note that on telephony 
  level an "anycast" phone-number is used (US would be 911, here
  110/112)
- must provide the receiver with information which the calling 
  party may not be able to provide (here location information)

Emergency call transport is QoS based, if the customer signed for a telephony service offered by the access provider. 

Regards,

Ruediger

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 5 Nov 2015 15:08:59 +0900

>the only mission-critical DOTS messages are mitigation service requests from DOTS clients and mitigation service refusals from DOTS servers.

I'm in favor of the pointing out of the latter point: mitigation service refusals from DOTS servers.
In operator's point of view, returning of status is indispensable to know the mitigation is succeed or not.
Without such information, it will take more time to decide the next action, so it will harm the victim longer.

IMHO, in this meaning, "SOS" is a little bit confusing because it seems like the signaling is one directional.

regards,
kaname nishizuka

On 2015/11/04 10:37, Roland Dobbins wrote:
>> And, you might not be able to tell you have a problem getting UDP through until you are under attack,
> Regular heartbeats between clients and servers, clients and relays, and relays and servers can serve the function of ensuring end-to-end connectivity on an ongoing basis.
>
> Failure to receive service request acknowledgements can serve this purpose under duress.
>
> It's expected that DOTS clients will update DOTS servers (either directly or via DOTS relays) with either continued mitigation requests and/or situational updates with regards to mitigation efficacy throughout mitigation service windows.  Likewise, DOTS servers are expected to do the same with regards to DOTS clients (again, either directly or via DOTS relays).
>
> Note that other than a DOTS server receiving a DOTS mitigation service requests, none of these message types are necessary in order to mitigation service to be initiated.  They are important and useful, but not mission-critical; the only mission-critical DOTS messages are mitigation service requests from DOTS clients and mitigation service refusals from DOTS servers.
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 5 Nov 2015 10:02:55 +0000

We will update the draft to explain response codes and re-name SOS to 'Mitigation service request'.

-Tiru

> From: Dots [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, November 05, 2015 1:10 PM
> To: kaname nishizuka; Roland Dobbins; [email-masked]
> Cc: [email-masked]

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 05 Nov 2015 19:27:49 +0900

On 5 Nov 2015, at 17:29, [email-masked] wrote:

> if DOTS allows for transport options, is QoS/DiffServ a possible 
> option supporting a desired solution?

Yes, this is an option for topological situations in which the 
organization requesting mitigation and the upstream mitigator are 
adjacent; they'd have to work it out between themselves, of course.  
This has already been discussed on-list, I believe, and we should offer 
this guidance in terms of deployment recommendations.

However, there are topological situations in which we know markings 
won't be preserved.  Some of the diagrams in the use-cases .pdf preso 
are illustrative in this regard:

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 05 Nov 2015 19:29:44 +0900

> request, response and status(?).

Concur, we should formalize the status message categories and options.  
'SOS' isn't really specific enough, IMHO.

---

From: <[email-masked]>
Date: Thu, 5 Nov 2015 12:15:01 +0100

Hi Roland,

my understanding is, bi-directional QoS transport should be possible between DOTS client and server.

I think, transport QoS may be an option, if DOTS server and client are connected to the same provider. 

If the DOTS server is connected to a different provider than DOTS client, then this is a "remote access". Is the provider terminating the DOTS client access part of the DDoS defense system or may this provider be agnostic to all that? If the latter is true plain provider IP service is my expectation and then QoS transport between client and server is a challenge.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[email-masked]] Im Auftrag von Roland Dobbins
Gesendet: Donnerstag, 5. November 2015 11:28
An: [email-masked]
Cc: [email-masked]
Betreff: Re: [tsvwg] [Dots] Best transport selection during an attack?

> option supporting a desired solution?

Yes, this is an option for topological situations in which the organization requesting mitigation and the upstream mitigator are adjacent; they'd have to work it out between themselves, of course.  
This has already been discussed on-list, I believe, and we should offer this guidance in terms of deployment recommendations.

However, there are topological situations in which we know markings won't be preserved.  Some of the diagrams in the use-cases .pdf preso are illustrative in this regard:

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 05 Nov 2015 20:27:55 +0900

> between DOTS client and server.

Please see the network diagrams in the use-cases preso.  When they're 
located in topologically adjacent administrative domains, this is 
possible, and will be recommended, although it's up to operators whether 
or not they actually do this.

> connected to the same provider.

Concur.

> If the DOTS server is connected to a different provider than DOTS 
> client, then this is a "remote access". Is the provider terminating 
> the DOTS client access part of the DDoS defense system or may this 
> provider be agnostic to all that?

The main issue is intervening networks.

> If the latter is true plain provider IP service is my expectation and 
> then QoS transport between client and server is a challenge.

Yes, that's correct (along with the administrative and 
internal-political challenges operators may face even when they're 
directly topologically adjacent to the requesting organization's 
network).

---

From: Paul Ferguson <[email-masked]>
Date: Thu, 5 Nov 2015 06:25:27 -0800

On 11/5/2015 3:27 AM, Roland Dobbins wrote:

>> If the DOTS server is connected to a different provider than
>> DOTS client, then this is a "remote access". Is the provider
>> terminating the DOTS client access part of the DDoS defense
>> system or may this provider be agnostic to all that?
> 
>> If the latter is true plain provider IP service is my expectation
>> and then QoS transport between client and server is a challenge.
> 

Correct. And that is the big problem with QoS/diffserv packet marking:
Once a packet leaves your network and your administrative control, no
one has to honor your packet markings (QoS). All bets are off.

- - ferg

- -- 
Paul Ferguson
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2

---

From: <[email-masked]>
Date: Fri, 6 Nov 2015 09:42:47 +0100

Paul,

I'd expect business customers products offering QoS enabled access types. The point here is the server to client direction where QoS would be desirable. This requires QoS transit/peering between server provider and client provider for plain IP. That is rare, I guess.

In Germany, bilateral QoS interconnection at least for VPN like wholesale service will be a commodity within the next 5 years, I think.

I understand that the overlay model is expected, i.e. customers buying internet connectivity at provider A and getting value added service by provider B. If there's no incentive for A and B to cooperate, some bad guy fills the best effort pipe and out of band signaling is not an option, transport design is a serious task.  

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[email-masked]] Im Auftrag von Paul Ferguson
Gesendet: Donnerstag, 5. November 2015 15:25
An: Roland Dobbins
Cc: [email-masked]; [email-masked]
Betreff: ***CAUTION_Invalid_Signature*** Re: [tsvwg] [Dots] Best transport selection during an attack?

Correct. And that is the big problem with QoS/diffserv packet marking:
Once a packet leaves your network and your administrative control, no one has to honor your packet markings (QoS). All bets are off.

- ferg

--
Paul Ferguson

---

From: [email-masked]
Date: Fri, 6 Nov 2015 09:41:30 -0000

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
All true and we're likely to need multiple repeated packets sent to a
achieve any robustness- but I wonder if the important question  is here:
"would setting a non-default DSCP actually reduce the chance that a packet
reaches the intended destination?"

Gorry

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iF4EAREIAAYFAlY7ZtcACgkQKJasdVTchbLdhwD/Rmjk2H1fUperSsoDhk7TkeOS
> RINC2V3ooD9+BkLdnoEA/2KirmljqYeyS/Pr+fhVBoPp1ChfT5WcELuIZJENdkzI
> =0jkt
> -----END PGP SIGNATURE-----
>

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 06 Nov 2015 20:46:00 +0900

On 6 Nov 2015, at 18:41, [email-masked] wrote:

> but I wonder if the important question  is here:

QoS *may* be set up for DOTS traffic by operators who're providing 
transit and who're also performing upstream DDoS mitigation services for 
endpoint networks who buy transit from them.

But we can't count on that due to a) overlays and b) operators may not 
set it up for various reasons.

It should certainly be recommended in terms of deployment guidances in 
directly-connected scenarios, IMHO, but would be just that - a 
recommendation.

---

From: [email-masked]
Date: Fri, 6 Nov 2015 12:34:52 -0000

> directly-connected scenarios, IMHO, but would be just that - a
Yes I understand how diffserv works, indeed you need to say the protocol
MUST NOT rely upon this being set. Would it say "MAY set a DSCP" or
"SHOULD set a DSCP" or ...

SO my question(s) are:
(1) If we can recommend setting a DSCP - which one?
(2) Is there a reason that a sender would only set this if you know you
are in one operator domain (how would you know this? (is it more likely to
be discarded??)
so  (3) why not set it anyway (even if it is bleached) at operator
boundaries?

Gorry

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 06 Nov 2015 21:41:42 +0900

> (1) If we can recommend setting a DSCP - which one?

Isn't that situationally-specific between the networks in question?

> are in one operator domain (how would you know this? (is it more 

Senders should know this.

> so  (3) why not set it anyway (even if it is bleached) at operator

Because folks tend not to do things which are extra effort/require 
coordination, and DOTS nodes themselves oughtn't to be doing this, it 
should be handled by network infrastructure.

---

From: <[email-masked]>
Date: Fri, 6 Nov 2015 12:49:40 +0000

Hi Roland, all,

I agree. 

DOTS should not ** assume **  nor ** preclude ** such designs.

The exact details about the configuration of which class of service (or even other means to protect DOTS signaling traffic under severe network congestion conditions) should be left to polices local to each domain. 

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de Roland Dobbins
> Envoyé : vendredi 6 novembre 2015 12:46
> À : [email-masked]
> Cc : [email-masked]

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 6 Nov 2015 09:16:25 -0500

> Isn't that situationally-specific between the networks in question?

Definitely.  There doesn't have to be any specific single default or 
recommended value because it's not necessary to match for 
interoperability between different implementations; it's just a 
deployment configuration matter.  Receiving nodes don't need to know or 
care what DSCPs were used originally by the sender or by other 
classifiers in the path.

> should be handled by network infrastructure.

It would be fine for an implementation to set some operator-indicated 
value when sending, and not require further classification in the network.

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 07 Nov 2015 19:08:55 +0700

> value when sending, and not require further classification in the 

A capability to do marking in DOTS agents themselves, if so desired, you 
mean?

So, an implementation of a configuration option?  If so, I personally 
think that makes sense as something optional, but not necessarily 
something which ought to be mandatory.

---

From: <[email-masked]>
Date: Mon, 9 Nov 2015 08:31:34 +0100

Roland,

the communication server to client benefits most from QoS, if the client is DDoSed, doesn't it? I'd expect the ones operating such a service to be qualified enough to combine available options to reach a technical design serving the clients as desired. I may be wrong, but I don't expect the server, which I don't expect to be mass market device, to be connected to a consumer access.

Mentioning QoS as a reasonable option for server to client communication with an optional brief description of the cases when it useful is fine, I think.

Regards, 

Ruediger

-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[email-masked]] Im Auftrag von Roland Dobbins
Gesendet: Samstag, 7. November 2015 13:09
An: [email-masked]
Cc: [email-masked]
Betreff: Re: [tsvwg] [Dots] Best transport selection during an attack?

> value when sending, and not require further classification in the 

A capability to do marking in DOTS agents themselves, if so desired, you mean?

So, an implementation of a configuration option?  If so, I personally think that makes sense as something optional, but not necessarily something which ought to be mandatory.

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 09 Nov 2015 14:40:15 +0700

On 9 Nov 2015, at 14:31, [email-masked] wrote:

> Mentioning QoS as a reasonable option for server to client 
> communication with an optional brief description of the cases when it 
> useful is fine, I think.

Concur.

---

From: Stefan Fouant <[email-masked]>
Date: Tue, 10 Nov 2015 19:22:23 +0000

>one has to honor your packet markings (QoS). All bets are off.

We¹ve been down this path before - discussed on the mailing list last
month. We don¹t need an end-to-end guarantee of service to make this work.
QOS can be used on the local link simply to ensure that the DOTS request
gets a higher priority in the face of congestion or heavy back pressure.
Once it¹s past the congestion point, there is less likelihood of needing
differentiated treatment.

Stefan Fouant

---

From: Stefan Fouant <[email-masked]>
Date: Tue, 10 Nov 2015 19:41:45 +0000

On 11/10/15, 1:03 PM, "Dots on behalf of Linda Dunbar"
<[email-masked] on behalf of [email-masked]> wrote:

>
>I have to agree with Kaname.
>
>In addition, if a device/app is under attack severely, it may not even
>have the spare CPU to request for the "Help".
>
>Linda Dunbar

We spoke about this in Yokohama. One of the suggested use cases as
outlined by Roland was the use of an OOB mechanism, such as a mobile
app/supplicant that could request mitigation service if all else fails.
One thing is for sure, we need multiple options.

Stefan Fouant

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 11 Nov 2015 02:48:54 +0700

> have the spare CPU to request for the "Help".

Several of the use cases posited so far involve devices/mechanisms which 
aren't themselves under attack, FYI.

Also, note that with the ones which do involve devices which are in the 
path of an attack, they would be configured to request upstream 
mitigation assistance when traffic levels, types, and/or other 
conditions exceeded configured thresholds or boundaries.

There are cases in which attacks instantly are at a level/degree of 
complexity which degrade the ability of a device to respond; 
architectural guidance for implementors in this regard can be useful, 
and heartbeat can also be potentially useful in this regard (though 
there are a lot of implications to the latter, and its use as 'dead 
man's switch' must be carefully considered, along with all potential 
applications, in a given deployment scenario).

---

From: Stefan Fouant <[email-masked]>
Date: Tue, 10 Nov 2015 19:55:46 +0000

>conditions exceeded configured thresholds or boundaries.

100% concur. Many attacks, especially those involving many sources take
time to fully ramp (I.e. Zombies ramping up in response to botnet herder
instruction set). In many of these cases, there is a brief amount of time
before full link saturation affording an opportunity to send out a
mitigation request.

>applications, in a given deployment scenario).

Configurable options for a loss of heartbeat should be considered. Of
course, that¹s more of a vendor implementation and not necessarily
something that needs to be spelled out in the drafts. By any ³implied²
dead man's switch should not be mandatory.

Stefan Fouant

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 10 Nov 2015 18:03:55 +0000

In addition, if a device/app is under attack severely, it may not even have the spare CPU to request for the "Help". 

Linda Dunbar

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of kaname nishizuka
Sent: Thursday, November 05, 2015 12:09 AM
To: Roland Dobbins; [email-masked]
Cc: [email-masked]
Subject: Re: [Dots] [tsvwg] Best transport selection during an attack?

regards,
kaname nishizuka

On 2015/11/04 10:37, Roland Dobbins wrote:
>> through until you are under attack, when some operator may implement filtering that inhibits connectivity.
>

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 12 Nov 2015 05:50:06 -0800

> before full link saturation affording an opportunity to send out a
Exactly how does a DDOS attack target your *egress* ports?

The worst I can imagine is triggering fake replies. There's no 
amplification there.

This is exactly why it is vital that this type of service not rely upon 
its ingress paths to
enable sending notifications. It is the ingress paths that are under attack.

Reliability can be provided above the transport layer, and the rate 
required for these
notifications is low enough that we do not need flow control.

Any use of reliable connections for attack notifications is wrong.

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 12 Nov 2015 20:56:27 +0700

> Exactly how does a DDOS attack target your *egress* ports?

Where were egress ports mentioned in this thread?

Of course, egress ports/interfaces are affected on origination and 
intervening networks, but I can't find a mention of it on the list?

> The worst I can imagine is triggering fake replies. There's no 

Again, I'm lost, apologies.

>
> This is exactly why it is vital that this type of service not rely 
> upon its ingress paths to

Again, totally lost.

> notifications is low enough that we do not need flow control.

This depends upon the content and transport.

> Any use of reliable connections for attack notifications is wrong.

Except where unreliable transports aren't practical due to overzealous 
filtering

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 12 Nov 2015 06:03:45 -0800

> Where were egress ports mentioned in this thread?

If you need to send the notice *before* the attack is fully in progress 
it implies that the attack
is inhibiting your use of your egress paths.

The DDOS attacks I am familiar with can only jam your egress ports by 
preventing you from
completing reliable connections/associations.

> Except where unreliable transports aren't practical due to overzealous 

Then you need to carve paths for unrelliable notifications.

Pretending that reliable connections can be useful in this context 
provides no protection.
Even an idiot attack will interfere with connection establishment and 
maintenance.

---

From: "Roland Dobbins" <[email-masked]>
Date: Sun, 15 Nov 2015 09:04:32 +0700

On 12 Nov 2015, at 21:03, Caitlin Bestler wrote:

> If you need to send the notice *before* the attack is fully in 
> progress it implies that the attack

Your use of the term 'egress paths' in this context is nonstandard and 
confusing.

> completing reliable connections/associations.

Totally at a loss as to what 'egress paths' means, in this context.

 From the target's point of view, DDoS is an *ingress* phenomenon, 
though it may also inhibit outbound traffic utilizing stateful 
transports.

> Then you need to carve paths for unrelliable notifications.

It appears you haven't read the discussion on this list and in the 
various presentations on the desirability of out-of-band signaling for 
DOTS, although it won't be the most prevalent mode of deployment due to 
the fact that it requires extra effort and expense.

> Pretending that reliable connections can be useful in this context 

Nobody is pretending anything.

It has repeatedly been stated that unreliable transport is best for this 
application, whenever/wherever possible.

It has also been stated that overzealous localized network access 
policies often inhibit stateless transports.

It has further been noted that one of the reasons DOTS relays are noted 
is to transliterate between stateful and stateless DOTS transports.

> Even an idiot attack will interfere with connection establishment and 

It might be a good idea to read through the DOTS list archives, read the 
various documents related to DOTS, and read the various presentations 
related to DOTS in order to avoid restating points which are already 
well understood.

---

From: Caitlin Bestler <[email-masked]>
Date: Sat, 14 Nov 2015 20:25:45 -0800

> Your use of the term 'egress paths' in this context is nonstandard and 

An egress path is a path *away* from the server under attack *towards* 
the entity that the
alarm/notification is trying to reach.

> DOTS, although it won't be the most prevalent mode of deployment due 
> to the fact that it requires extra effort and expense.
>

But I see recurrent lack of understanding of basic transport issues.

For example, worrying that the alarm must be raised early, before the 
node under attack is stifled,
makes no sense.  A Denial of Service attack will not be able to prevent 
you from sending a notification,
unless you are stupid enough to send it over a path that is dependent on 
a reverse flow (i.e. over any
reliable transport).

If you publish a document that implies the IETF thinks that an "alarm" 
that can be silenced by the very
attack it is supposed to be preventing then many people might be fooled 
into thinking that they are
adding something of value.

Any DOS-alarm mechanism that shuts down when the ingress paths are 
flooded is worthless.

Not "less valuable than", worth nothing. You don't even have to very the 
goals of you DOS attack
to shut this down. The ability to establish or maintain any reliable 
connection is the primary target
of a DOS attack.

---

From: "Roland Dobbins" <[email-masked]>
Date: Sun, 15 Nov 2015 23:06:08 +0700

> alarm/notification is trying to reach.

Oh - you mean the *signaling* path.  Thanks for clearing that up.

> But I see recurrent lack of understanding of basic transport issues.

Actually, you don't.  But you seem to enjoy alleging you do, for reasons 
which are unclear.
> makes no sense.

I've said nothing of that nature.

> A Denial of Service attack will not be able to prevent you from 
> sending a notification,
> unless you are stupid enough to send it over a path that is dependent 
> on a reverse flow (i.e. over any
> reliable transport).

I'm really tired of seeing the word 'stupid' in your email messages.  It 
is uncouth, unprofessional and uncalled-for.

Those of us with real-world operational experience with reliable 
transports - like TCP - during DDoS attacks on production networks know 
that they do not always stop TCP cold; they interfere with it, but 
sometimes persistence on the part of the sender pays off.  But that's 
beside the point.

You've ignored the repeated statements that stateless transport is 
preferred, but that a stateful transport is necessary in some cases due 
to overly-restrictive network access policies.  You've also ignored the 
explanation that one of the functions of DOTS relays is to transliterate 
between stateful and stateless transports.

It's clear that you have not read the discussions on the DOTS list, nor 
read the drafts promulgated so far, nor read the presentations made at 
IETF 93 and IETF 94.

And it's also clear that you've ignored repeated statements that 
out-of-band signaling is preferable, and also not read the use cases 
which posit out-of-band signaling.

> attack it is supposed to be preventing then many people might be 
> fooled into thinking that they are

I have not published any such document.

> Any DOS-alarm mechanism that shuts down when the ingress paths are 

Nobody is proposing such a mechanism.

> You don't even have to very the goals of you DOS attack to shut this 
> down.

This is incoherent; I can't make heads nor tails of it, apologies.

> The ability to establish or maintain any reliable connection is the 
> primary target of a DOS attack.

DDoS attacks are attacks against availability.  They are attacks against 
capacity and/or state.  The goal of DDoS attacks is to negatively impact 
the availability of applications, services, and/or infrastructure.

So far, you are not contributing anything useful to this discussion.  If 
you've something constructive to add, it would be welcome; otherwise, 
you will simply be ignored.  Your call.