Subject: [Dots] Using Diameter transport for DOTS?

From: Dave Dolson <[email-masked]>
Date: Tue, 3 Nov 2015 19:43:17 +0000

Could Diameter satisfy the transport protocol needs of DOTS?
It already has security, mutual authentication, both datagram (SCTP) and TCP transports‎, watchdog timers, redundancy, the concept of relays...

-Dave

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 3 Nov 2015 15:26:36 -0500

I thought end-to-end crypto hasn't been solved for Diameter yet...

Thanks,
Kathleen 

Sent from my iPhone

> On Nov 3, 2015, at 2:43 PM, Dave Dolson <[email-masked]> wrote:
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Dave Dolson <[email-masked]>
Date: Tue, 3 Nov 2015 20:54:46 +0000

Is end-to-end crypto required in DOTS, given hop-by-hop security is good?
[Not intended as a rhetorical question.]
To those not familiar with Diameter, in the DOTS context, the client-to-proxy and proxy-to-server connections would be secure and encrypted, but the proxy could view and modify messages.

In DOTS, are the proxy and server in the same or different administrative domains, or is the proxy trusted?
Even so, are there messages components that should be hidden from the proxy?

Practically, if it is a hard problem in Diameter, is it also hard for DOTS?
Conversely, when dime figures it out, it would be inherited for free.

The more I think about it, it seems to me a lot easier than starting at the UDP layer and inventing a protocol from scratch.
Should DOTS brainstorm other candidate session-layer protocols as well?

-Dave

-----Original Message-----
From: Kathleen Moriarty [mailto:[email-masked]] 
Sent: Wednesday, November 04, 2015 5:27 AM
To: Dave Dolson
Cc: dots
Subject: Re: [Dots] Using Diameter transport for DOTS?

Thanks,
Kathleen 

Sent from my iPhone

---

From: Stefan Fouant <[email-masked]>
Date: Tue, 3 Nov 2015 21:01:28 +0000

> On Nov 4, 2015, at 5:55 AM, Dave Dolson <[email-masked]> wrote:
> 
> 

There is no mandate for that requirement DOTS currently, but I can name a few large ISPs that I am talking to who would likely prefer any such signaling to be fully encrypted end-to-end as they have a mandate to encrypt or fully privatize any customer related data due to contractual obligations.

Stefan

Sorry for the typos, on my iPhone.

---

From: Andrew Mortensen <[email-masked]>
Date: Tue, 3 Nov 2015 16:06:24 -0500

> On Nov 3, 2015, at 4:01 PM, Stefan Fouant <[email-masked]> wrote:
> 
> 

Nor is hop-by-hop security going to be adequate for the use case Flemming brought up yesterday (service on public cloud signaling a third-party scrubbing service).

andrew

---

From: Dave Dolson <[email-masked]>
Date: Tue, 3 Nov 2015 21:16:01 +0000

If I understand correctly, to spell it out:
If the proxy is more than an IP router,
- a message is comprised of information elements that the proxy needs to read and those end-to-end elements it must not be able to read
- the end-to-end information elements are encrypted/signed with end-to-end keys
- the entire message is encrypted/signed with hop-by-hop keys.

Out of curiosity, can you give examples of what aspects of the "SOS" message must not be seen by the proxy?

-Dave

-----Original Message-----
From: Andrew Mortensen [mailto:[email-masked]] 
Sent: Wednesday, November 04, 2015 6:06 AM
To: Stefan Fouant
Cc: Dave Dolson; Kathleen Moriarty; dots
Subject: Re: [Dots] Using Diameter transport for DOTS?

>> [Not intended as a rhetorical question.] To those not familiar with 
>> Diameter, in the DOTS context, the client-to-proxy and proxy-to-server connections would be secure and encrypted, but the proxy could view and modify messages.
> 

andrew

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 3 Nov 2015 21:48:41 -0500

We obvioulsy should do a proper evaluation against the requirements once 
we have vetted those a bit more, but my initial reaction is that this 
seems like a fairly heavy-handed approach to the problem at hand (we do 
need to understand the requirements on DOTS relays better though). 
TLS/DTLS satisfy a lot of what you list below, and I'm not sure we need 
something as elaborate as DIAMETER on top of that. Also, please keep in 
mind that we have use case scenarios involving endpoints, and requiring 
those to support DIAMETER for a basic client-side app or web portal 
seems like a tall order to me.

On a related note, it's been a while since I looked at DIAMETER, but 
what is the adoption/deployment status of that outside of 3GPP these days ?

Thanks

-- Flemming

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 3 Nov 2015 18:57:30 -0800

May I also underscore this sentiment:

> TLS/DTLS satisfy a lot of what you list below, and I'm not sure we
> need something as elaborate as DIAMETER on top of that.

This is a statement I also endorse, and would like to understand
better what DIAMETER would actually add to the equation.

- - ferg

On 11/3/2015 6:48 PM, Flemming Andreasen wrote:

> We obvioulsy should do a proper evaluation against the requirements
> once we have vetted those a bit more, but my initial reaction is
> that this seems like a fairly heavy-handed approach to the problem
> at hand (we do need to understand the requirements on DOTS relays
> better though). TLS/DTLS satisfy a lot of what you list below, and
> I'm not sure we need something as elaborate as DIAMETER on top of
> that. Also, please keep in mind that we have use case scenarios
> involving endpoints, and requiring those to support DIAMETER for a
> basic client-side app or web portal seems like a tall order to me.
> 
> On a related note, it's been a while since I looked at DIAMETER,
> but what is the adoption/deployment status of that outside of 3GPP
> these days ?
> 
> Thanks
> 
> -- Flemming
> 
> 
> 
> 
>> Could Diameter satisfy the transport protocol needs of DOTS? It
>> already has security, mutual authentication, both datagram
>> (SCTP) and TCP transports‎, watchdog timers, redundancy, the
>> concept of relays...
>> 
>> -Dave
>> 
>> _______________________________________________ Dots mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/dots
> 
> _______________________________________________ Dots mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dots

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

---

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

+ 1 for (D)TLS. And with TLS 1.3, 0-RTT is possible. 
DOTS client and server can complete DTLS handshake during non-attack time and the DOTS client can convey the SOS message along with the Client Hello. Similarly with TCP fast Open, SOS can be sent in SYN packet itself along with the Client Hello. SOS message and most of the handshake message will also be encrypted. 

-Tiru

> From: Dots [mailto:[email-masked]] On Behalf Of Flemming
> Andreasen (fandreas)
> Sent: Wednesday, November 04, 2015 8:19 AM
> To: Dave Dolson; dots
> we have vetted those a bit more, but my initial reaction is that this seems like
> a fairly heavy-handed approach to the problem at hand (we do need to
> understand the requirements on DOTS relays better though).
> those to support DIAMETER for a basic client-side app or web portal seems
> like a tall order to me.
> 
> On a related note, it's been a while since I looked at DIAMETER, but what is
> the adoption/deployment status of that outside of 3GPP these days ?
> 
> Thanks
> 
> -- Flemming
> 
> 
> 
> 
> > It already has security, mutual authentication, both datagram (SCTP) and
> TCP transports‎, watchdog timers, redundancy, the concept of relays...
> >
> > -Dave
> >

---

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

On 4 Nov 2015, at 12:20, Tirumaleswar Reddy (tireddy) wrote:

> DOTS client and server can complete DTLS handshake during non-attack 
> time

This assumes pre-attack provisioning.  A depressingly large proportion 
of DDoS mitigation provisioning takes place during an attack.

> and the DOTS client can convey the SOS message along with the Client 
> Hello.

Personally, I'm not a big fan of the 'SOS' terminology.

> Similarly with TCP fast Open, SOS can be sent in SYN packet itself 
> along with the Client Hello.

True, s/'SOS'/'Mitigation service request'.

> SOS message and most of the handshake message will also be encrypted.

Again, this assumes proactive provisioning.  Sadly, we can't assume 
that, per the above.

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Nov 2015 04:02:23 +0000

> From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
> Sent: Wednesday, November 04, 2015 9:18 AM
> To: dots
> This assumes pre-attack provisioning.  A depressingly large proportion of
> DDoS mitigation provisioning takes place during an attack.

DOTS client and server must perform mutual authentication, and if authentication is to happen during an attack then it involves multiple messages back and forth. With TLS 1.3, pre-attack provisioning helps to send only one encrypted and integrity protected 'Mitigation service request' message. 

> Personally, I'm not a big fan of the 'SOS' terminology.

Any suggestions for alternate names ?

-Tiru

> Again, this assumes proactive provisioning.  Sadly, we can't assume that, per
> the above.
>

---

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

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

> DOTS client and server must perform mutual authentication, and if 
> authentication is to happen during an attack then it involves multiple 
> messages back and forth.

Not necessarily:

<https://tools.ietf.org/html/draft-ietf-lisp-crypto-01>

> With TLS 1.3, pre-attack provisioning helps to send only one encrypted 
> and integrity protected 'Mitigation service request' message.

True, in the context of TLS 1.3.

> Any suggestions for alternate names ?

'Mitigation service request'.

;>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Nov 2015 04:56:29 +0000

> Sent: Wednesday, November 04, 2015 9:49 AM
> To: dots

The above draft is using DH and it involves multiple round-trips. Further DH can subjected to MIM attacks and has dependency on 
https://tools.ietf.org/html/draft-ietf-lisp-sec-09 which uses OTK for data origin authentication. OTK generation is not standardized in the LISP security draft and is a pre-provisioning step (it may also involve multiple round-trips). 

> True, in the context of TLS 1.3.

Yes, TLS 1.3 is more likely to get standardized before DOTS protocol.

-Tiru

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 4 Nov 2015 05:08:01 +0000

> <https://tools.ietf.org/html/draft-ietf-lisp-crypto-01>

Pure DH and not X25519?  Eww.

---

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

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

> The above draft is using DH and it involves multiple round-trips.

Interesting, given the following from 
<https://tools.ietf.org/html/draft-ietf-lisp-crypto-02> (I mistakenly 
cited -01, apologies; same language in both):

'The budget for key exchange MUST be one round-trip time.  That is, only 
a two packet exchange can occur.'

> Further DH can subjected to MIM attacks

I don't think those MITM scenarios really apply here (correction welcome 
if I'm wrong), given the high level of attention paid to this occasional 
task.  This isn't a general-purpose information channel, and it's 
expected to remain relatively static in terms of participating nodes.

> and has dependency on 
> https://tools.ietf.org/html/draft-ietf-lisp-sec-09 which uses OTK for 
> data origin authentication. OTK generation is not standardized in the 
> LISP security draft and is a pre-provisioning step (it may also 
> involve multiple round-trips).

OK.  I didn't get that it was multiple round-trips, but again am happy 
to be educated.

> Yes, TLS 1.3 is more likely to get standardized before DOTS protocol.

Concur.

---

From: Dave Dolson <[email-masked]>
Date: Wed, 4 Nov 2015 05:41:18 +0000

It might be overkill, but off the top of my head, Diameter provides:
- a rich dictionary-driven, ‎binary packet format comprised of attribute-value pairs, allowing structs, lists, etc., and is vendor-extensible
- peer connectivity maintenance, with watchdog messages
- ‎primary/secondary peer fail-over
- message routing by peer name
- retransmission semantics

It might be most appropriate to borrow some of the paradigms.

‎Other session protocols? SNMP, using a trap for the SOS??

I'm just throwing out ideas because inventing a new protocol from scratch is fun, but will take longer as the interesting corner cases are discovered.

  Original Message
From: Paul Ferguson
Sent: Wednesday, November 4, 2015 11:57 AM
To: Flemming Andreasen
Cc: Dave Dolson; dots
Subject: Re: [Dots] Using Diameter transport for DOTS?

- - ferg

- --
Paul Ferguson

---

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

> It might be most appropriate to borrow some of the paradigms.

Yes, this makes more sense, IMHO.

> ‎Other session protocols? SNMP, using a trap for the SOS??

No - heavily filtered at network edges.

> I'm just throwing out ideas because inventing a new protocol from 
> scratch is fun, but will take longer as the interesting corner cases 
> are discovered.

IPFIX is also something to consider *as a potential transport* (e.g., 
not the network telemetry export functionality).

We definitely want to reuse existing standards wherever possible, when 
they're suitable to requirements.

---

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

> Sent: Wednesday, November 04, 2015 11:02 AM
> To: dots
> <https://tools.ietf.org/html/draft-ietf-lisp-crypto-02> (I mistakenly cited -01,
> apologies; same language in both):
> 
> 'The budget for key exchange MUST be one round-trip time.  That is, only a
> two packet exchange can occur.'

I see three packet exchanges in https://tools.ietf.org/html/draft-ietf-lisp-crypto-02#section-3 to setup DH.

> I don't think those MITM scenarios really apply here (correction welcome if
> I'm wrong), given the high level of attention paid to this occasional task.  This
> isn't a general-purpose information channel, and it's expected to remain
> relatively static in terms of participating nodes.

MITM is an possible attack and I see it also discussed in https://tools.ietf.org/html/draft-ietf-lisp-crypto-02#section-10.2 and to prevent MIM 
it relies on https://tools.ietf.org/html/draft-ietf-lisp-sec-06. DH alone cannot just be used to authenticate the DOTS agents. LISP security uses One-Time Key for authentication, which again involves multiple round trips b/w the ITR and ETR. 
I don't understand what you mean by "static nodes" ?

> OK.  I didn't get that it was multiple round-trips, but again am happy to be
> educated.

OTK b/w two peers typically involves multiple round-trips (connection setup, mutual authentication b/w peers, signaling OTK and receiving acknowledgment, periodic updates to OTK etc.). 

-Tiru

> > Yes, TLS 1.3 is more likely to get standardized before DOTS protocol.

I guess we should 

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Nov 2015 06:17:23 +0000

https://tools.ietf.org/html/draft-reddy-dots-transport-01 for SOS (or 'Mitigation service request) uses REST over (D)TLS. In similar lines, I see that COAP designed for constrained nodes and constrained networks also uses REST (with few modifications) to run over UDP. 

-Tiru

> Sent: Wednesday, November 04, 2015 11:33 AM
> To: dots
> IPFIX is also something to consider *as a potential transport* (e.g., not the
> network telemetry export functionality).
>

---

From: "Teague, Nik" <[email-masked]>
Date: Wed, 4 Nov 2015 06:43:31 +0000

>not the network telemetry export functionality).

Some of the reasons I suggested IPFIX as a signaling base in the BoF
originally and reflected in:

https://tools.ietf.org/html/draft-teague-open-threat-signaling-01 (and -00)

Were:

* Template - the schema being set in the template export lent itself to
efficient use of the data export in addition to a degree of extensibility
either by additional fields beyond those required or with additional
template/data set pairings.

* Mutli transport support - IPFIX may use udp, sctp or tcp.

* Tooling - IPFIX already exists in many applications in this field

Drawbacks are obviously that there’s not usually bidirectional
communication in IPFIX although that’s not to say that the DOTS
implementation couldn’t overcome that.  Also there’s no real encryption so
it would be tls or dtls.

That’s not to say there aren’t other (more or less) potentially suitable
ideas/options - just highlighting the thinking behind how IPFIX ended up
as a recurring theme in DOTS.

Thanks,

-Nik

---

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

> I don't understand what you mean by "static nodes" ?

It's a very bounded communications channel, low-risk for undetected 
MITM.

> OTK b/w two peers typically involves multiple round-trips (connection 
> setup, mutual authentication b/w peers, signaling OTK and receiving 
> acknowledgment, periodic updates to OTK etc.).

Gotcha.

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 04 Nov 2015 15:58:02 +0900

> template/data set pairings.

Yes - something could potentially be prototyped within the existing 
IPFIX framework using enterprise IEs without starting from scratch.

<http://tools.ietf.org/html/rfc7012#section-2.1>

<http://tools.ietf.org/html/rfc7012#section-4>

<http://tools.ietf.org/html/rfc7013#section-6.2>

<http://tools.ietf.org/html/rfc7013#section-8>

> implementation couldn’t overcome that.

Yes, this isn't an issue.  There are no inherent design or functionality 
constraints in IPFIX which prohibit bidirectional comms.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Nov 2015 08:15:51 +0000

> Sent: Wednesday, November 04, 2015 12:28 PM
> To: dots
> > * Template - the schema being set in the template export lent itself
> > to efficient use of the data export in addition to a degree of
> > extensibility either by additional fields beyond those required or
> > with additional template/data set pairings.
> 
> Yes - something could potentially be prototyped within the existing IPFIX
> framework using enterprise IEs without starting from scratch.
> 

I am not sure how it meets the below requirement

   G-004  Bidirectionality: To support peer health detection, to
      maintain an open signal channel, and to increase the probability
      of signal delivery during attack, the signal channel MUST be
      bidirectional, with client and server transmitting signals to each
      other at regular intervals, regardless of any client request for
      mitigation.

-Tiru

---

From: "Teague, Nik" <[email-masked]>
Date: Wed, 4 Nov 2015 08:37:43 +0000

>      other at regular intervals, regardless of any client request for

You just implement it bi-directionally - the traditional client and server
roles blur somewhat when you require loosely coupled feedback and
heartbeat functionality.

If I take an existing implementation then the concept isn’t really there
as its all directed to flow collectors today but that’s not to say you
have to implement it that way in DOTS.

As an aside - Something else to consider is that if you want to extend it
later to communication between a DOTS agent and an actual mitigator you
could just add a mitigation template and data-set.

That was my thinking anyway.

-Nik

---

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

> I am not sure how it meets the below requirement

Because we implement it bidirectionally.

There is no unidirectional restriction for IPFIX.

---

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

> That was my thinking anyway.

Strongly concur for use *as a transport*.

---

From: Kristian Larsson <[email-masked]>
Date: Wed, 4 Nov 2015 10:27:03 +0100

On 04/11/15 04:47, Roland Dobbins wrote:
>> DOTS client and server can complete DTLS handshake during non-attack time
>

Is DOTS relevant in such a scenario?
If there is no pre-attack provisioning I would assume that the party 
being attacked would use an alternative method, such as a phone, to 
communicate with their provider of DDoS mitigation services. They would 
then manually start a mitigation for a given set of IPs. When and how 
would DOTS come into play?

> Personally, I'm not a big fan of the 'SOS' terminology.

Neither am I but it is short and easy to say :)

    kll

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Nov 2015 09:31:43 +0000

> From: Teague, Nik [mailto:[email-masked]]
> Sent: Wednesday, November 04, 2015 2:08 PM
> To: Tirumaleswar Reddy (tireddy); Roland Dobbins; dots

REST seems to fit the requirements better.

> have to implement it that way in DOTS.

Got it. I guess comparison of these two protocols for DOTS signaling protocol will be helpful. Anyways both IPFIX and REST use (D)TLS for security, and meet the transport and security requirements.

-Tiru

---

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

On 4 Nov 2015, at 18:27, Kristian Larsson wrote:

> When and how would DOTS come into play?

The mitigation provider instructs the organization seeking DDoS 
mitigation services to enter the appropriate DOTS peering and 
authentication information into their DOTS-capable 
mitigator/device/service/app, it registers and describes the properties 
to be protected, auto-provisioning on the mitigation provider side takes 
place, and situationally-appropriate mitigation is initiated.

This is a much better scenario than fumbling around trying to get all 
this information via voice from organizations - even the largest of the 
large - who can't properly articulate what servers/services/applications 
they're running, what their network access policies are (or ought to be, 
based on what they're running), etc.

---

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

> REST seems to fit the requirements better.

I'm unsure it does.

Can you expound on that view?

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Nov 2015 13:26:24 +0000

> Sent: Wednesday, November 04, 2015 6:39 PM
> To: dots

https://tools.ietf.org/html/draft-reddy-dots-transport-01#section-4 discusses SOS.

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Nov 2015 13:37:39 +0000

> Sent: Wednesday, November 04, 2015 6:35 PM
> To: [email-masked]
> The mitigation provider instructs the organization seeking DDoS mitigation
> services to enter the appropriate DOTS peering and authentication
> information into their DOTS-capable mitigator/device/service/app, it
> registers and describes the properties to be protected, auto-provisioning on
> the mitigation provider side takes place, and situationally-appropriate
> mitigation is initiated.

If all the above steps are performed then why can't the DOTS client cannot perform DTLS handshake with the DOTS server as pre-provisioning  step ? 
DOTS client also needs to configured with the DOTS server domain/IP addresses and DOTS client needs to be configured with certificates or SPKI fingerprint etc. to validate the DOTS server identity.

-Tiru

> 
> This is a much better scenario than fumbling around trying to get all this
> information via voice from organizations - even the largest of the large - who
> can't properly articulate what servers/services/applications they're running,
> what their network access policies are (or ought to be, based on what they're
> running), etc.
>

---

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

> https://tools.ietf.org/html/draft-reddy-dots-transport-01#section-4 

HTTP seems to be precisely the sort of chatty thing we'd like to avoid, 
does it not?

---

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

On 4 Nov 2015, at 22:37, Tirumaleswar Reddy (tireddy) wrote:

> If all the above steps are performed then why can't the DOTS client 
> cannot perform DTLS handshake with the DOTS server as pre-provisioning 
>  step ?

Because all the above is stuff that gets configured on the mitigation 
service request side and doesn't involve a bunch of chatty bidirectional 
comms.

> DOTS client also needs to configured with the DOTS server domain/IP 
> addresses and DOTS client needs to be configured with certificates or 
> SPKI fingerprint etc. to validate the DOTS server identity.

That's covered under 'appropriate DOTS peering and authentication 
information', which doesn't involve a bunch of chatty bidirectional 
comms.

Certificates and PKI are a big no-no for this kind of application.  They 
can't be readily obtained/provisioned/relied upon during an attack which 
is in-band in terms of the available communications paths to/from those 
working to establish relief via upstream mitigation service.

Those who've been directly affected any kind of 
operationally-significant DDoS attack and observed its effect on 
communications across the affected links/paths/topologies can testify 
that relying on any kind of complex communications interactions to take 
place during an attack isn't an optimal strategy.

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 04 Nov 2015 23:00:05 +0900

On 4 Nov 2015, at 22:56, Roland Dobbins wrote:

> that relying on any kind of complex communications interactions to 
> take place during an attack isn't an optimal strategy.

Typing this out has made me realize that if we end up going with 
something like D/TLS, we're probably going to need an en clair 
communications mode for use when the necessary crypto handshaking and 
key exchanges and whatnot aren't possible due to adverse network 
conditions.

---

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

> Sent: Wednesday, November 04, 2015 7:17 PM
> To: dots
> HTTP seems to be precisely the sort of chatty thing we'd like to avoid, does it
> not ?

If you review the above draft, the REST message fits within MTU and it's a simple request/response. COAP also uses REST with some changes for constrained devices and constrained networks.

-Tiru

---

From: Kristian Larsson <[email-masked]>
Date: Wed, 4 Nov 2015 15:24:30 +0100

> based on what they're running), etc.

I like the scenario you are describing, essentially removing verbal 
communication between humans and instead relying on structured data 
transfer between DOTS capable devices.

However, I think there is a big difference between the preparations that 
typically takes place pre-attack and the actions taken when a customer 
calls while under an attack.

I'm sure you are familiar with the scenarios. A distraught customer 
calls in and wants help as they are currently under attack, or maybe 
they are calling their ISP because there is "a problem" with their 
Internet connection, i.e. they haven't even realized it's an attack.

What happens today is that the ticket is sent to the DDoS operations 
teams, someone takes a look at flow records to identify the attack and 
then starts a mitigation with guesstimated countermeasure settings. It's 
not perfect and might have negative impact on legitimate traffic but 
it's better than the attack keeping all the customers services down.

I have a hard time believing that we, as a provider of DDoS mitigation 
service, could get away with answering the customer that they have to 
install a DOTS client, configure it and start it up for us to initiate a 
mitigation for them.

Technically it will difficult for them to download the DOTS client due 
to their congested Internet link. It will be difficult for them to 
configure it without any experience and only then do we arrive at the 
topic currently being discussed, ie sending SOS / Mitigation service 
request. Of these three steps I think sending SOS, regardless of 
transport, is the most likely to succeed.

To top it off, the customer likely won't be very happy having had to 
install and configure things while under extreme pressure.

But, keeping to the intent of avoiding verbal communication, perhaps an 
out of band method, that the customer can reach from a device that is 
separate from their production network, could be used to input basic 
data. It could be as minimal as a web page that the customer reaches 
from their mobile phone and inputs their production networks IP address 
ranges or more information, if they have it. It could follow the same 
data models used in DOTS, just with a different encapsulation / 
transport protocol. Is this feasible? Out of scope? We don't care? I'm 
brainstorming at this point.

Kind regards,
    Kristian.

--
Level 60 Network Automation Paladin at DT / TeraStream [AS2792]

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Nov 2015 14:26:45 +0000

> Sent: Wednesday, November 04, 2015 7:26 PM
> To: [email-masked]
> Because all the above is stuff that gets configured on the mitigation service
> request side and doesn't involve a bunch of chatty bidirectional comms.
> 
> information', which doesn't involve a bunch of chatty bidirectional comms.
> 
> Certificates and PKI are a big no-no for this kind of application.  They can't be
> readily obtained/provisioned/relied upon during an attack which is in-band
> in terms of the available communications paths to/from those working to
> establish relief via upstream mitigation service.

DOTS client and DOTS server could be in different administrative domains, we will have to figure out the trust model. If it's not PKI then pre-shared keys, raw public keys etc. can also be used with (D)TLS for mutual authentication b/w DOTS peers.
What alternative mechanism are you proposing for authentication ?

> 
> Those who've been directly affected any kind of operationally-significant
> DDoS attack and observed its effect on communications across the affected
> links/paths/topologies can testify that relying on any kind of complex
> communications interactions to take place during an attack isn't an optimal
> strategy.

I am not proposing any complex communication, DOTS client and server do (D)TLS handshake during non-attack times and just need 0-RTT proposed in TLS 1.3 or use (D)TLS session without session resumption to signal SOS. (D)TLS session resumption involves 1-RTT before SOS message can be conveyed. The first TLS handshake in TLS 1.3 takes 1 RTT (for full handshake).

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Nov 2015 14:45:11 +0000

> From: Dots [mailto:[email-masked]] On Behalf Of Kristian Larsson
> Sent: Wednesday, November 04, 2015 7:55 PM
> To: [email-masked]
> > mitigator/device/service/app, it registers and describes the
> > properties to be protected, auto-provisioning on the mitigation
> > provider side takes place, and situationally-appropriate mitigation is
> initiated.
> >
> > this information via voice from organizations - even the largest of
> > the large - who can't properly articulate what
> > servers/services/applications they're running, what their network
> > access policies are (or ought to be, based on what they're running), etc.
> 
> typically takes place pre-attack and the actions taken when a customer calls
> while under an attack.
> 
> I'm sure you are familiar with the scenarios. A distraught customer calls in
> and wants help as they are currently under attack, or maybe they are calling
> their ISP because there is "a problem" with their Internet connection, i.e.
> they haven't even realized it's an attack.
> 
> What happens today is that the ticket is sent to the DDoS operations teams,
> someone takes a look at flow records to identify the attack and then starts a
> mitigation with guesstimated countermeasure settings. It's not perfect and
> might have negative impact on legitimate traffic but it's better than the attack
> keeping all the customers services down.
> 
> I have a hard time believing that we, as a provider of DDoS mitigation service,
> could get away with answering the customer that they have to install a DOTS
> client, configure it and start it up for us to initiate a mitigation for them.
> 
> Technically it will difficult for them to download the DOTS client due to their
> congested Internet link. It will be difficult for them to configure it without any
> experience and only then do we arrive at the topic currently being discussed,
> ie sending SOS / Mitigation service request. Of these three steps I think
> sending SOS, regardless of transport, is the most likely to succeed.
> 
> To top it off, the customer likely won't be very happy having had to install
> and configure things while under extreme pressure.
> 
> But, keeping to the intent of avoiding verbal communication, perhaps an out
> of band method, that the customer can reach from a device that is separate
> from their production network, could be used to input basic data. It could be
> as minimal as a web page that the customer reaches from their mobile
> phone and inputs their production networks IP address ranges or more
> information, if they have it. It could follow the same data models used in
> DOTS, just with a different encapsulation / transport protocol. Is this
> feasible? Out of scope? We don't care? I'm brainstorming at this point.

It makes sense and are discussed in sections 4.1.5 and 4.1.6 https://tools.ietf.org/html/draft-ietf-dots-use-cases-00. 

-Tiru

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 4 Nov 2015 09:52:56 -0500

Sent from my iPhone

> On Nov 4, 2015, at 8:56 AM, Roland Dobbins <[email-masked]> wrote:
> 
> Because all the above is stuff that gets configured on the mitigation service request side and doesn't involve a bunch of chatty bidirectional comms.
> 
> That's covered under 'appropriate DOTS peering and authentication information', which doesn't involve a bunch of chatty bidirectional comms.
> 
> Certificates and PKI are a big no-no for this kind of application.  They can't be readily obtained/provisioned/relied upon during an attack which is in-band in terms of the available communications paths to/from those working to establish relief via upstream mitigation service.

You should look at the work in ACME for backup solutions to certificate provisioning and negotiations.

This thread has focused on solutions and not requirements.  I fear that this will result in poor selection with requirements not fully considered.

I also didn't buy the argument earlier that you don't need to worry about MiTM, making the LISP solution ok.  ACME won't be as secure as pre-provisioned connections, but would be an option to fill the gap for emergency situations, OS after that.  

Maybe a separate thread on requirements would help.

Kathleen  
> 
> Those who've been directly affected any kind of operationally-significant DDoS attack and observed its effect on communications across the affected links/paths/topologies can testify that relying on any kind of complex communications interactions to take place during an attack isn't an optimal strategy.
>

---

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

On 4 Nov 2015, at 23:52, Kathleen Moriarty wrote:

> You should look at the work in ACME for backup solutions to 
> certificate provisioning and negotiations.

Symmetrical shared-secret is much more operationally flexible than 
anything to do with certificates in the ops space; we also can't depend 
upon a PKI system being reachable and available during an attack.

ACME is new to me - I'll go check it out, thanks!

> This thread has focused on solutions and not requirements.  I fear 
> that this will result in poor selection with requirements not fully 
> considered.

This is almost a sidebar discussion to the main effort, which is focused 
on requirements derived from use-cases.  It doesn't hurt to kibitz a bit 
ahead of ourselves, in this regard.

Getting tsvwg involved at this early stage is somewhat distracting, 
IMHO, and has led to a lot of this on-list discussion.  It seems to me 
that collaboration with tsvwg will be much more effective and a more 
efficient use of their time once we have our requirements solidified.

> I also didn't buy the argument earlier that you don't need to worry 
> about MiTM, making the LISP solution ok.

DH MITM isn't a big risk for this application, IMHO, as it's a highly 
monitored, special-purpose communications channel with a predetermined 
set of participants.

I'm not religious on this issue, just pointing out that the crypto risk 
model for DOTS is quite a bit different than that of a general-purpose 
communications channel with lots of participant dynamism.

> ACME won't be as secure as pre-provisioned connections, but would be 
> an option to fill the gap for emergency situations, OS after that.

Will look into it, thanks!

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 4 Nov 2015 10:20:11 -0500

Sent from my iPhone

> On Nov 4, 2015, at 10:11 AM, Roland Dobbins <[email-masked]> wrote:
> 
> Symmetrical shared-secret is much more operationally flexible than anything to do with certificates in the ops space; we also can't depend upon a PKI system being reachable and available during an attack.
> 
> This is almost a sidebar discussion to the main effort, which is focused on requirements derived from use-cases.  It doesn't hurt to kibitz a bit ahead of ourselves, in this regard.

Agreed, I wasn't saying that.
> 
> Getting tsvwg involved at this early stage is somewhat distracting, IMHO, and has led to a lot of this on-list discussion.  It seems to me that collaboration with tsvwg will be much more effective and a more efficient use of their time once we have our requirements solidified.

I disagree and think DOTS can benefit from the experience of TSV before a direction is selected.

> 
>> I also didn't buy the argument earlier that you don't need to worry about MiTM, making the LISP solution ok.
> 
> DH MITM isn't a big risk for this application, IMHO, as it's a highly monitored, special-purpose communications channel with a predetermined set of participants.

I'm not convinced and don't think this is a good argument in terms of the current threat landscape.

> 
> I'm not religious on this issue, just pointing out that the crypto risk model for DOTS is quite a bit different than that of a general-purpose communications channel with lots of participant dynamism.

We try not to define new protocols that are not secure.  It was already stated that end-to-end crypto was needed, I don't see how you could justify doing something that's weak.

> 
>> ACME won't be as secure as pre-provisioned connections, but would be an option to fill the gap for emergency situations, OS after that.
> 

Layering this I think would be better than accepting less than secure for all connections.

Kathleen

---

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

> before a direction is selected.

It will be helpful to be able to present the tsvwg folks with a more 
definitive set of requirements, IMHO.

This goes back to solutions vs. requirements.

;>

> the current threat landscape.

OK.

Again, I'm not religious on this issue.  But understanding that the 
threat model for DOTS is somewhat different than a general-purpose 
communications channel with lots of dynamic participation will help us 
scope our crypto requirements more closely in relation to the actual 
operational environment.

> We try not to define new protocols that are not secure.  It was 
> already stated that end-to-end crypto was needed, I don't see how you 
> could justify doing something that's weak.

Nobody wants to do something that's weak, concur 100%.  At the same 
time, the crypto portion of DOTS is actually the least-significant part, 
compared to the actual functionality of DOTS, the transport 
characteristics, auth, and so forth.

End-to-end crypto is something everyone/everything 'requires' in the 
current environment, often for non-technical reasons, so it's something 
we absolutely must do.  For DOTS, authentication is actually a lot more 
important than encryption; but, as they sort of go hand-in-hand, we end 
up with both.

> Layering this I think would be better than accepting less than secure 
> for all connections

Understood, will read up on ACME.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Nov 2015 15:42:12 +0000

> I also didn't buy the argument earlier that you don't need to worry about
> MiTM, making the LISP solution ok.  ACME won't be as secure as pre-
> provisioned connections, but would be an option to fill the gap for
> emergency situations, OS after that.

Agreed. MiTM is an important attack to consider for DOTS, DDOS is typically a targeted attack and attackers most likely would be interested to break the DOTS signaling protocol. 

> Maybe a separate thread on requirements would help.

Requirements OP-002, G-006 and G-007 in https://tools.ietf.org/html/draft-ietf-dots-requirements-00  discuss requirements to handle MiTM attack. 

-Tiru

---

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

On 4 Nov 2015, at 23:15, Tirumaleswar Reddy (tireddy) wrote:

> If you review the above draft, the REST message fits within MTU and 
> it's a simple request/respons

I see that, thanks.  576 or below is nice, but 1476 or below is 
generally OK, these days, FYI.

---

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

On 4 Nov 2015, at 23:24, Kristian Larsson wrote:

> However, I think there is a big difference between the preparations 
> that typically takes place pre-attack and the actions taken when a 
> customer calls while under an attack.

Yes - removing as much ambiguity as possible from provisioning

> I'm sure you are familiar with the scenarios.

Painfully so.

;>

> then starts a mitigation with guesstimated countermeasure settings.

Yes - and this is a highly suboptimal approach, as the general 
organizing principle for successful DDoS attack mitigation is actually 
centered around the properties being protected.

And, yes, there are certainly alterations one must make based on 
variations in attack methodology and evolving operational circumstances 
over the duration of an attack, in many cases.  But suboptimal 
countermeasure selection and tuning based on a) an incomplete (or total 
lack of) understanding of the properties being protected and/or b) 
attack methodology is a significant of DDoS mitigation today.

> install a DOTS client, configure it and start it up for us to initiate 
> a mitigation for them.

The idea is that the DOTS client is *already there* - just input a few 
params shared out-of-band over the phone or whatever, and it's done.

;>

As an operational person handling DDoS attacks for lo these many years, 
I understand completely the scenarios and pressures you describe.  
Pervasive DOTS is intended to greatly improve the operational situation, 
reducing response times, improving mitigation efficacy, et. al.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Nov 2015 16:08:48 +0000

> Sent: Wednesday, November 04, 2015 9:20 PM
> To: dots
> I see that, thanks.  576 or below is nice, but 1476 or below is generally OK,
> these days, FYI.

Yes, the DOTS client will have to restrict the SOS message length if Path MTU is unknown ,and It's 576 for IPv4 and 1280 for IPv6.

-Tiru

---

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

On 5 Nov 2015, at 0:42, Tirumaleswar Reddy (tireddy) wrote:

> Agreed. MiTM is an important attack to consider for DOTS,

It's actually the least important attack to consider.

I'm not saying it's unimportant, but in the scheme of things, it doesn't 
rise to the scale that it does in general-purpose communications 
systems.

> and attackers most likely would be interested to break the DOTS 
> signaling protocol.

If they're even able to be aware of the DOTS signaling, much less send 
traffic to the DOTS endpoints, it's been implemented incorrectly from an 
operational and deployment architecture standpoint.

If they're in a position to even attempt to MITM this traffic, the 
reality is that the involved parties have problems technology can't 
solve.

We're edging into movie-plot threat territory, here.

---

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

On 5 Nov 2015, at 1:08, Tirumaleswar Reddy (tireddy) wrote:

> Yes, the DOTS client will have to restrict the SOS message length if 
> Path MTU is unknown ,and It's 576 for IPv4

Again, 576 is really too strict for IPv4 on the modern Internet to be a 
hard-and-fast requirement.  It's nice, but shouldn't be a primary design 
consideration, at least to the degree that it might impede something 
else that's important.

Plus, there's always application-layer message segmentation.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 4 Nov 2015 11:16:57 -0500

Sent from my iPhone

> On Nov 4, 2015, at 11:09 AM, Roland Dobbins <[email-masked]> wrote:
> 
> I'm not saying it's unimportant, but in the scheme of things, it doesn't rise to the scale that it does in general-purpose communications systems.
> 

As soon as you deploy a consistent protocol, you'll see attacks like this emerge more.  MiTM is an important consideration as the game will change.

>> and attackers most likely would be interested to break the DOTS signaling protocol.
> 
> If they're even able to be aware of the DOTS signaling, much less send traffic to the DOTS endpoints, it's been implemented incorrectly from an operational and deployment architecture standpoint.
> 
> If they're in a position to even attempt to MITM this traffic, the reality is that the involved parties have problems technology can't solve.

We can do our best and follow BCPs for new protocols.

> We're edging into movie-plot threat territory, here.

Not really.

Kathleen

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 4 Nov 2015 16:25:40 +0000

> Sent: Wednesday, November 04, 2015 9:43 PM
> To: dots

COAP protocol published recently https://tools.ietf.org/html/rfc7252#section-4.6 discusses message size limitations if Path MTU is unknown. STUN,  TURN and DNS protocols already have this limitation (If Path MTU is not performed by the client).

-Tiru

---

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

On 5 Nov 2015, at 1:16, Kathleen Moriarty wrote:

> As soon as you deploy a consistent protocol, you'll see attacks like 
> this emerge more.  MiTM is an important consideration as the game will 
> change.

The general nature of routing in the Internet does not, however.

I understand where you're coming from.  I don't dismiss MITM as 
unimportant.  But it's not the or even a primary attack vector for DOTS 
itself, and it's unlikely to be so in the foreseeable future, IMHO, due 
to the nature of the Internet.

We must plan for the worst, of course, understood.

> We can do our best and follow BCPs for new protocols.

Concur 100%.

> Not really.

If the attackers have the ability to MITM this traffic, then they've 
already achieved effective control over the networks/systems in 
question, including the DOTS clients and all network traffic to/from the 
affected properties, to a degree which renders them situationally 
omnipotent.

Perversely, dedicated out-of-band DOTS signaling, which is highly 
preferable in terms of ensuring DOTS messages get through under duress, 
is actually the communications channel most (still highly unlikely, with 
huge implications if it ever comes to pass) susceptible to MITMing.  It 
won't be nearly as prevalent as in-band signaling, of course.

---

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

On 5 Nov 2015, at 1:25, Tirumaleswar Reddy (tireddy) wrote:

> STUN,  TURN and DNS protocols already have this limitation (If Path 
> MTU is not performed by the client).

I'm aware of this.  My point is that on the modern Internet, this is 
overly conservative.

576 or lower is nice, if practical.  It is not and should not be 
considered a primary design constraint.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 4 Nov 2015 13:14:51 -0500

Sent from my iPhone

> On Nov 4, 2015, at 11:42 AM, Roland Dobbins <[email-masked]> wrote:
> 
> I understand where you're coming from.  I don't dismiss MITM as unimportant.  But it's not the or even a primary attack vector for DOTS itself, and it's unlikely to be so in the foreseeable future, IMHO, due to the nature of the Internet.
> 
> If the attackers have the ability to MITM this traffic, then they've already achieved effective control over the networks/systems in question, including the DOTS clients and all network traffic to/from the affected properties, to a degree which renders them situationally omnipotent.
> 
> Perversely, dedicated out-of-band DOTS signaling, which is highly preferable in terms of ensuring DOTS messages get through under duress, is actually the communications channel most (still highly unlikely, with huge implications if it ever comes to pass) susceptible to MITMing.  It won't be nearly as prevalent as in-band signaling, of course.

Just to be clear, your arguments do not convince me despite the persistent messages.  I don't have time to continue the debate, so my lack of response at this time does not signal agreement.

Thanks,
Kathleen

---

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

On 5 Nov 2015, at 3:14, Kathleen Moriarty wrote:

> Just to be clear, your arguments do not convince me despite the 
> persistent messages.

OK.

It doesn't much matter, anyways, as I'm not religious on the subject of 
DH, LISP crypto, etc.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 10 Nov 2015 15:00:01 -0600

> It already has security, mutual authentication, both datagram (SCTP) and TCP transports‎, watchdog timers, redundancy, the concept of relays...

I think this is using a 32lb hammer to pound in a 3p nail (very 
US-centric model).

We do specific work here in the IETF instead of repurposing existing 
tech because you can be focused on solving your problem, not taking on 
their problem(s).