Subject: [Dots] 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: 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: 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: Kristian Larsson <[email-masked]>
Date: Tue, 3 Nov 2015 17:42:40 +0100

On 03/11/15 17:22, Ca By wrote:
>
>
> On Tue, Nov 3, 2015 at 7:30 AM, Wesley Eddy <[email-masked]
> <mailto:[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 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?
>
>
>
>
>     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.
>
>
> The dotty yellow lines that cross the blue lines represent the packet
> loss that UDP policers cause \ absorb during a UDP DDoS attack.

Surely this is for the opposite direction. Quic is used to fetch web 
pages so the request is small but the response is much bigger and that 
response might run into various policers.

DOTS is only looking at sending a small packet. An incoming UDP based 
attack shouldn't influence that much.

Kind regards,
     Kristian.

---

From: Jelena Mirkovic <[email-masked]>
Date: Tue, 3 Nov 2015 09:42:39 -0800

I might have missed some context. Is there supporting evidence that TCP
ACKs have that much of a trouble getting through? First, they are small
packets and should fit into an almost full router queue by that virtue,
whereas data packets won't. Second, they are resent by TCP. Third, it
should be fairly easy to craft a filter that lets ACKs through at any level
(victim or first-hop ISP). So, while I second Wes's idea for multiple
channels is there strong operational evidence that ACKs indeed have a
problem?

Note that DDoS is a game of probability. X legitimate bytes + Y attack
bytes (Y>>X) are trying to fit a limited N sized link. Legitimate bytes
always have a non zero chance of getting through.

=========================

Jelena Mirkovic
Research Faculty
USC Information Sciences Institute
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292
310-448-9170

On Tue, Nov 3, 2015 at 8:42 AM, Kristian Larsson <[email-masked]>
wrote:

> Surely this is for the opposite direction. Quic is used to fetch web pages
> so the request is small but the response is much bigger and that response
> might run into various policers.
>

---

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.

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

---

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

On 4 Nov 2015, at 2:42, Jelena Mirkovic wrote:

> So, while I second Wes's idea for multiple channels is there strong 
> operational evidence that ACKs indeed have a
> problem?

Try Web browsing sometime whilst under a volumetric DDoS attack down the 
same link.

Or even when someone else is downloading enough large files 
simultaneously to tax the link capacity.

;>

In all seriousness, in many cases, enough will get through to allow a 
message to be sent.  But this protocol is designed for use under 
emergency conditions, with ongoing link congestion a commonplace event 
in the circumstances under which it is to be used.

So, we really need both stateless and stateful options.

One of the applications for DOTS relays is also to serve as a well-known 
address within a given organization for DOTS messaging which allows 
holes to be poked in overly-restrictive policies, and which has little 
need ever to be changed, irrespective of whatever configuration changes 
take place further in the background with regards to mitigation systems 
and DOTS servers which communicate with them.

Potential issues with networks policing down UDP is more likely to occur 
in situations involving overlay mitigation providers who're 
topologically distant from the properties they're protecting.

There's always UDP/53, if nothing else, of course.  But it's far too 
early to be thinking along those lines.

UDP works just fine, even when some networks are doing lots of UDP 
filtering, under most circumstances - e.g., if you can play your PS4 or 
XBone or PC multiplayer games, UDP is working.

---

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: Gilbert Clark <[email-masked]>
Date: Tue, 3 Nov 2015 17:49:22 -0500

tsvwg list removed from this message.

On 11/3/2015 5:10 PM, Roland Dobbins wrote:
> 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.
>

As a comment: the presentation referenced in the original note to tsvwg 
did explicitly note a proposed transport of UDP + DTLS for SOS 
messages.  There was no mention (as far as I'm aware, anyway) of an 
alternative stateful channel which could be used for that message type.  
For those to whom this is a new problem (read: folks on tsvwg who are 
not also on dots) or those who may have not attended the working group 
meeting, a lack of context may be contributing to the way this 
conversation has been going.

-Gilbert

---

From: Andrew Mortensen <[email-masked]>
Date: Tue, 3 Nov 2015 18:37:49 -0500

> On Nov 3, 2015, at 5:49 PM, Gilbert Clark <[email-masked]> wrote:
> 
>>> With DOTS in UDP, you are putting the DOTs traffic in that path that becomes the most lossy during a a DDoS.
>> 
>> 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.
>> 
> 
> As a comment: the presentation referenced in the original note to tsvwg did explicitly note a proposed transport of UDP + DTLS for SOS messages.  There was no mention (as far as I'm aware, anyway) of an alternative stateful channel which could be used for that message type.  For those to whom this is a new problem (read: folks on tsvwg who are not also on dots) or those who may have not attended the working group meeting, a lack of context may be contributing to the way this conversation has been going.

All draft-reddy-dots-transport-01 actually says with respect to protocol is the following: "TBD: SOS messages SHOULD be exchanged over DTLS over UDP.”

Compare with OP-001 from draft-ietf-dots-requirements-00:

"While the protocol resilience requirement strongly RECOMMENDS the use of connectionless protocol, 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."

andrew

---

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.

---

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: Wesley Eddy <[email-masked]>
Date: Tue, 3 Nov 2015 22:31:57 -0500

On 11/3/2015 8:29 PM, Aaron Falk wrote:
> On Wed, Nov 4, 2015 at 12:30 AM, Wesley Eddy <[email-masked] 
>     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
>     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.

By probing the path ahead of time, and using all available protocols, 
you're going to wind up utilizing any feasible channel. If there are no 
feasible channels, you're just screwed, and nothing more can really be 
done over the network.  You might fall-back to using a modem to dial-out 
and get a direct connection to control mitigations over, or maybe you 
can pack the SOS message into an SMS and text it out (securing that 
seems more difficult though).

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 04 Nov 2015 12:43:42 +0900

On 4 Nov 2015, at 12:31, Wesley Eddy wrote:

> By probing the path ahead of time,

Again, heartbeats fulfill this function pre-attack, and the status 
messaging and related acknowledgements fulfill this function during an 
attack.  And paths or some portions thereof may well be dynamic due to 
the nature of the Internet and BGP in general, much less any local 
decisionmaking on the originating end (presuming multihoming).

Ideally, DOTS signaling would be done out-of-band in relation to the 
attack path, but we know that the majority of deployments won't bother 
with this.

Nevertheless, it should be part of the deployment guidance for DOTS.

---

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:

> 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: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Nov 2015 04:32:58 +0000

[TR] DOTS client can possibly use "Happy Eyeball mechanism" to try both UDP and TCP. If UDP is not blocked then it will receive response from the DOTS server and can terminate the TCP connection. TCP could be subjected to RST attacks and the additional overhead of TCP-AO is required.

-Tiru

andrew

---

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

On 4 Nov 2015, at 13:32, Tirumaleswar Reddy (tireddy) wrote:

> [TR] DOTS client can possibly use "Happy Eyeball mechanism" to try 
> both UDP and TCP. If UDP is not blocked then it will receive response 
> from the DOTS server and can terminate the TCP connection.

Some type of fallback/alternate transport selection mechanism is 
definitely in order, IMHO.

There's also the question of fallback/selection between IPv4 and IPv6, 
in scenarios where both are available to the DOTS agents in question.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Nov 2015 05:01:03 +0000

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
> Sent: Wednesday, November 04, 2015 10:10 AM
> To: [email-masked]
> Subject: Re: [Dots] [tsvwg] Best transport selection during an attack?
> 
> Some type of fallback/alternate transport selection mechanism is definitely in
> order, IMHO.
> 
> There's also the question of fallback/selection between IPv4 and IPv6, in
> scenarios where both are available to the DOTS agents in question.

Browsers already use "Happy Eyeball mechanism" https://tools.ietf.org/html/rfc6555 for selection between IPv6 and IPv4. 

-Tiru

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 04 Nov 2015 14:33:36 +0900

On 4 Nov 2015, at 14:01, Tirumaleswar Reddy (tireddy) wrote:

> Browsers already use "Happy Eyeball mechanism" 
> https://tools.ietf.org/html/rfc6555 for selection between IPv6 and 
> IPv4.

Yes, I agree that Happy Eyeballs is something to consider for this.  Dan 
Wing is on this list, too.

---

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

> 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: "Teague, Nik" <[email-masked]>
Date: Thu, 5 Nov 2015 00:38:29 +0000

Hi,

>volunteering to present (plus summarize relevant dots WG and mailing list

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 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]
> Importance: High

---

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

>It's ok for you to not agree with the slide contents if you reuse someone

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: 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: "Black, David" <[email-masked]>
Date: Thu, 5 Nov 2015 01:01:12 +0000

> 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

---

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: 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: "Teague, Nik" <[email-masked]>
Date: Thu, 5 Nov 2015 06:24:09 +0000

>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.
> 
> Without such information, it will take more time to decide the next
> action, so it will harm the victim longer.
> 
> 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: "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: Linda Dunbar <[email-masked]>
Date: Tue, 10 Nov 2015 18:03:55 +0000

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

-----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: 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:39:36 +0000

>Wing is on this list, too.

One thing to keep in mind here, I believe ³Happy Eyeball² mechanism only
works for stateful transports.

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:

>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 20:21:55 +0000

Roland, 

More comments inserted below:

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
Sent: Tuesday, November 10, 2015 1:49 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Dots] [tsvwg] Best transport selection during an attack?

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

[Linda] Do you think the configuration on devices to trigger upstream mitigation assistance is static? Or dynamic? Are there any events that can impact the thresholds to be configured on the devices to call for "DDOS mitigation help"? Are those devices more likely to be L4-L7 devices? or routers/switches as well? 

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

[Linda] There could be many reasons for a device/app's "heartbeat" to stop or slow. So it would be difficult to conclude if it is caused by DOS attack. 

Thanks, 
Linda

---

From: Stefan Fouant <[email-masked]>
Date: Tue, 10 Nov 2015 20:29:20 +0000

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

>
>[Linda] Do you think the configuration on devices to trigger upstream
>mitigation assistance is static? Or dynamic? Are there any events that
>can impact the thresholds to be configured on the devices to call for
>"DDOS mitigation help"? Are those devices more likely to be L4-L7
>devices? or routers/switches as well?

IMO, more likely static thresholds, I.e. If link x observes 80%
saturation, request mitigation. Obviously configurable though.

>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).
>
>[Linda] There could be many reasons for a device/app's "heartbeat" to
>stop or slow. So it would be difficult to conclude if it is caused by DOS
>attack.

I agree, I don¹t think that the loss of heartbeat should necessarily
equate to a mandate for mitigation service, but that can be left as a
configurable option if needed which is largely a vendor implementation and
need not be spelled out in the drafts.

Stefan Fouant

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 12 Nov 2015 21:06:15 +0700

On 11 Nov 2015, at 3:21, Linda Dunbar wrote:

> mitigation assistance is static? Or dynamic?

Yes to both.

> Are there any events that can impact the thresholds to be configured 
> on the devices to call for "DDOS mitigation help"?

Yes.

> Are those devices more likely to be L4-L7 devices? or routers/switches 
> as well?

Either/or.

> stop or slow. So it would be difficult to conclude if it is caused by 
> DOS attack.

Hence, '. . . 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: Kristian Larsson <[email-masked]>
Date: Thu, 12 Nov 2015 17:19:23 +0100

> works for stateful transports.

Why? While rfc6555 targets stateful transports there is nothing 
preventing doing the same for UDP, as long as there is some form of 
request/response semantics of the service running on top, which I 
believe we will have.

I think  "Happy DOTS" should do v4/v6 selection and UDP / TCP selection 
per default. If someone wants to statically configure UDPoIPv4 that is 
fine but I'd like to see a recommendation for the default being to 
automatically figure out the best combination.

Kind regards,
     Kristian.

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 13 Nov 2015 08:55:01 +0700

On 12 Nov 2015, at 23:19, Kristian Larsson wrote:

> While rfc6555 targets stateful transports there is nothing preventing 
> doing the same for UDP, as long as there is some form of 

I *think* this is correct; Dan Wing and Tiru Reddy can certainly comment 
more.

> I think  "Happy DOTS" should do v4/v6 selection and UDP / TCP 
> selection per default. If someone wants to statically configure 
> UDPoIPv4 that is fine but I'd like to see a recommendation for the 
> default being to automatically figure out the best combination.

This is potentially useful implementation guidance, IMHO.  Very 
interested in hearing more from Dan, Tiru, and others as to their 
thoughts.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 13 Nov 2015 02:32:50 +0000

> From: Roland Dobbins [mailto:[email-masked]]
> Sent: Friday, November 13, 2015 7:25 AM
> To: [email-masked]
> Cc: Dan Wing (dwing); Tirumaleswar Reddy (tireddy)
> This is potentially useful implementation guidance, IMHO.  Very interested in
> hearing more from Dan, Tiru, and others as to their thoughts.

The above suggestions look good. By default v6 will be given higher precedence than v4 and will have a head-start. However policy table https://tools.ietf.org/html/rfc6724 on the DOTS client can be modified to change the preference.

-Tiru

---

From: Dave Dolson <[email-masked]>
Date: Fri, 13 Nov 2015 02:49:43 +0000

Something else to consider: I think the DOTS group has said that DNS resolution should not be attempted during an attack.
So then it's a case of having a number of configured IP/port/protocol end-points, regardless of IPv4 or IPv6.

I'm saying it isn't quite the same as doing DNS lookup and then deciding which address (family) to use, as is the "happy eyeballs" case.

-Dave

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Friday, November 13, 2015 11:33 AM
To: Roland Dobbins; [email-masked]
Cc: Dan Wing (dwing)
Subject: Re: [Dots] [tsvwg] Best transport selection during an attack?

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 13 Nov 2015 03:04:31 +0000

> From: Dave Dolson [mailto:[email-masked]]
> Sent: Friday, November 13, 2015 8:20 AM
> To: Tirumaleswar Reddy (tireddy); Roland Dobbins; [email-masked]
> Cc: Dan Wing (dwing)
> Subject: RE: [Dots] [tsvwg] Best transport selection during an attack?
> 
> Something else to consider: I think the DOTS group has said that DNS
> resolution should not be attempted during an attack.
> I'm saying it isn't quite the same as doing DNS lookup and then deciding
> which address (family) to use, as is the "happy eyeballs" case.

DNS resolution can be done during DOTS client configuration (non-attack time) or the DOTS client could be configured with the DOTS server IPv6 and IPv4 addresses. Happy eyeballs for DOTS is to try both address families and both transports.

-Tiru

> > > While rfc6555 targets stateful transports there is nothing
> > I *think* this is correct; Dan Wing and Tiru Reddy can certainly
> > comment more.
> >
> > interested in hearing more from Dan, Tiru, and others as to their thoughts.
> 
> The above suggestions look good. By default v6 will be given higher
> precedence than v4 and will have a head-start. However policy table
> https://tools.ietf.org/html/rfc6724 on the DOTS client can be modified to
> change the preference.
> 
> -Tiru
> 
> >

---

From: Andrew Mortensen <[email-masked]>
Date: Fri, 13 Nov 2015 12:23:08 -0500

> On Nov 12, 2015, at 8:55 PM, Roland Dobbins <[email-masked]> wrote:
> 
> 
>> While rfc6555 targets stateful transports there is nothing preventing doing the same for UDP, as long as there is some form of request/response semantics of the service running on top, which I believe we will have.
> 
> I *think* this is correct; Dan Wing and Tiru Reddy can certainly comment more.
> 
>> I think  "Happy DOTS" should do v4/v6 selection and UDP / TCP selection per default. If someone wants to statically configure UDPoIPv4 that is fine but I'd like to see a recommendation for the default being to automatically figure out the best combination.
> 
> This is potentially useful implementation guidance, IMHO.  Very interested in hearing more from Dan, Tiru, and others as to their thoughts.

TCP/IPv4 might be detected or selected by the DOTS agent as the best option under nominal conditions, but when an attack ramps up DOTS server signals go missing with increasing frequency, with proportional retransmissions and possible connection termination. That’s exactly the sort of fragility we want to avoid in DOTS, and it makes me skeptical of a conventional request/response model.

I’m similarly skeptical that it’s possible to make trustworthy estimations—at least the sort required by happy eyeballs—about which transport/protocol combination is best if DOTS agents are attempting to establish the signal channel *during* an attack, though of course I’d be happy to learn my concerns are off-base here and above. 

Since I'm touching again on the transport dispute which set off this entire thread, this seems like a good place to segue into the DOTS discussion at the tsvwg meeting last week. (I haven’t seen any writeup about it on this list, apologies if I missed it.)

Nik gave a quick overview of the problem DOTS intends to solve, described the dispute about signaling transport that emerged during the DOTS meeting, and showed a very basic slide in which a DOTS client with an existing relationship with a DOTS server must signal for help despite an ingress link congested with DDoS traffic. Time for feedback during the meeting was limited, so there were only a few comments (Cf. meeting minutes linked below, DOTS is the very last item [1]):

1) Inform any planned UDP use with a good understanding of RFC 5405bis. 
2) TCP incurs state. So does UDP with a heartbeat. Unidirectional DTLS is problematic [see also RFC 6520 —AM].
3) Too many DOTS clients could DoS a DOTS server. NAT binding timeouts could be a problem.
4) Redundant packets seems better than many idle encrypted sessions.
5) Consider using both UDP and TCP.

(Some discussion has continued on the tsvwg mailing list—dots@ got dropped from the replies—see [2] below.)

None of that looks like consensus on transport, though the points raised are valuable for requirements and protocol drafts.

andrew

[1] TSV WG minutes: <https://www.ietf.org/proceedings/94/minutes/minutes-94-tsvwg>
[2] <https://mailarchive.ietf.org/arch/msg/tsvwg/XUIr7TDlqeskSXO8HlLHAftNacs>

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 14 Nov 2015 00:28:51 +0700

On 14 Nov 2015, at 0:23, Andrew Mortensen wrote:

> That’s exactly the sort of fragility we want to avoid in DOTS, and 
> it makes me skeptical of a conventional request/response model.

This is a very cogent point, IMHO.  We want dynamism where it makes 
sense, but the majority of DOTS peering relationships will be 'nailed 
up' with a very specific admin focus.
>
> I’m similarly skeptical that it’s possible to make trustworthy 
> estimations—at least the sort required by happy eyeballs—about 
> which transport/protocol combination is best if DOTS agents are 
> attempting to establish the signal channel *during* an attack

Perhaps fallback of this nature would make sense in the event of the 
primary selected channel didn't appear to be viable?

---

From: 🔓Dan Wing <[email-masked]>
Date: Sun, 15 Nov 2015 12:31:43 -0800

>> While rfc6555 targets stateful transports there is nothing preventing doing the same for UDP, as long as there is some form of request/response semantics of the service running on top, which I bel…

Yes, Happy Eyeballs (RFC6555) concepts can be applied to other transports.  For example Preethi and I described how to apply Happy Eyeballs to SCTP, draft-wing-tsvwg-happy-eyeballs-sctp (expired).

-d

---

From: Kristian Larsson <[email-masked]>
Date: Mon, 16 Nov 2015 11:20:05 +0100

> DNS resolution can be done during DOTS client configuration (non-attack time) or the DOTS client could be configured with the DOTS server IPv6 and IPv4 addresses. Happy eyeballs for DOTS is to try…

Exactly, I didn't spell this out but I meant that DOTS happy eyeballs is 
to be performed during setup and perhaps continuously at certain 
intervals but the decision on transport is cached so when an attack 
happens we already know which transport to use.

    kll

---

From: Kristian Larsson <[email-masked]>
Date: Mon, 16 Nov 2015 11:49:25 +0100

On 13/11/15 18:23, Andrew Mortensen wrote:
>>> preventing doing the same for UDP, as long as there is some form
>>> of request/response semantics of the service running on top,
>>> which I believe we will have.
>>
>>> UDPoIPv4 that is fine but I'd like to see a recommendation for
>>> the default being to automatically figure out the best
>>> combination.
>>
> TCP/IPv4 might be detected or selected by the DOTS agent as the best
> option under nominal conditions, but when an attack ramps up DOTS
> server signals go missing with increasing frequency, with
> proportional retransmissions and possible connection termination.
> That’s exactly the sort of fragility we want to avoid in DOTS, and it
> makes me skeptical of a conventional request/response model.
>
> estimations—at least the sort required by happy eyeballs—about which
> transport/protocol combination is best if DOTS agents are attempting
> to establish the signal channel *during* an attack, though of course
> I’d be happy to learn my concerns are off-base here and above.

Agreed. Trying DOTS happy eyeballs during attack would most likely be a 
very bad idea. It needs to happen pre-attack, both during initial setup 
but I think it's wise to do it at certain intervals as to refresh the 
information.

> Since I'm touching again on the transport dispute which set off this
> entire thread, this seems like a good place to segue into the DOTS
> discussion at the tsvwg meeting last week. (I haven’t seen any
> writeup about it on this list, apologies if I missed it.)
>
> Nik gave a quick overview of the problem DOTS intends to solve,
> described the dispute about signaling transport that emerged during
> the DOTS meeting, and showed a very basic slide in which a DOTS
> client with an existing relationship with a DOTS server must signal
> for help despite an ingress link congested with DDoS traffic. Time
> for feedback during the meeting was limited, so there were only a few
> comments (Cf. meeting minutes linked below, DOTS is the very last
> item [1]):
>
> 2) TCP incurs state. So does UDP with a heartbeat. Unidirectional DTLS is problematic [see also RFC 6520 —AM]. 3) Too
> many DOTS clients could DoS a DOTS server. NAT binding timeouts could
> be a problem.

I imagine deploying my DOTS server in an anycast fashion to scale out 
and handle many clients. To avoid DDoS against my DOTS system I'd like 
to limit it's connectivity so that it's only reachable from my 
customers. This won't completely prevent attacks but will decrease the 
attack surface significantly. If there is a need to communicate with 
DOTS systems in other operator networks I could always put a second 
address on the system that is publicly routed.

Further, I would like to see an automatic discovery mechanism for DOTS. 
This is perhaps not strictly related to transport but I'll just put it 
out here if anyone wants to comment. It could be something along the 
lines of the well known 6to4 anycast address (192.88.99.1 - RFC3068) or 
using DNS SRV records.

I am seeing this from an operator perspective. We will naturally be in 
control of most of our own systems so configuring them to use the 
correct DOTS server is an easy task. For customers it's an entirely 
different thing though. Some will buy a DDoS mitigation service from us 
and we will in that case have control over a potential device at the 
customer premise that we can configure but there are lots of customers 
which won't buy such a service and I would still like to be able to 
offer them basic DDoS mitigation as part of their Internet service. 
Imagine something like just handling volumetric attacks. They are 
usually quite non-sophisticated making them both easy to detect and 
mitigate and while I could probably detect most using flow-based 
detection it would be a nice addition if the customer could send a DOTS 
MSR to a well known / discovered address in my network and receive help.

> 5) Consider using both UDP and TCP.

Right, perhaps the outcome of DOTS happy eyeballs is a list of 
transports in order of priority so in a "normal" scenario you'd have UDP 
as well as TCP but the happy eyeballs process could for example 
eliminate UDP from that list if it is detected that UDP packets are 
filtered.

    kll

> None of that looks like consensus on transport, though the points
> raised are valuable for requirements and protocol drafts.
>
> andrew
>
> [1] TSV WG minutes:
> <https://www.ietf.org/proceedings/94/minutes/minutes-94-tsvwg> [2]
> <https://mailarchive.ietf.org/arch/msg/tsvwg/XUIr7TDlqeskSXO8HlLHAftNacs>
>
>
> Dots mailing list [email-masked]

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 17 Nov 2015 00:29:30 +0700

On 16 Nov 2015, at 17:49, Kristian Larsson wrote:

> and handle many clients.

Concur.

> To avoid DDoS against my DOTS system I'd like to limit it's 
> connectivity so that it's only reachable from my customers. This won't 
> completely prevent attacks but will decrease the attack surface 
> significantly. If there is a need to communicate with DOTS systems in 
> other operator networks I could always put a second address on the 
> system that is publicly routed.

Concur - relevant BCPs applied to BGP, etc. will have relevance here.

> Further, I would like to see an automatic discovery mechanism for 
> DOTS. This is perhaps not strictly related to transport but I'll just 
> put it out here if anyone wants to comment. It could be something 
> along the lines of the well known 6to4 anycast address (192.88.99.1 - 
> RFC3068) or using DNS SRV records.

Insofar as this is consistent with the above, concur.  But this will 
likely be in a later stage, IMHO.

> transports in order of priority so in a "normal" scenario you'd have 
> UDP as well as TCP but the happy eyeballs process could for example 

I think this is the right sort of thinking.  DOTS peering will largely 
be 'nailed up' and manually configured for quite some time; fallback 
mechanisms are a good idea to provide for the possibility of some 
dynamism in this context.