Subject: Re: [Dots] New Version Notification for draft-mortensen-dots-architecture-00.txt

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 01 Apr 2016 16:29:57 +0700

On 1 Apr 2016, at 9:56, Tirumaleswar Reddy (tireddy) wrote:

>  What is the use case for DOTS relay operated by some other entity ?

I'm having a hard time coming up with this one, as well.

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

---

From: Andrew Mortensen <[email-masked]>
Date: Fri, 1 Apr 2016 08:37:16 -0400

> On Apr 1, 2016, at 5:29 AM, Roland Dobbins <[email-masked]> wrote:
> 

Yes, this was precisely my point about the utility of multiple DOTS relays in the signaling path when those relays are not owned by the entity originating the request for mitigation or the entity acting on the request for mitigation. In the case where a mitigating entity needs to be backstopped to handle abnormally large attacks, the recursive signaling mode seems most apt.

andrew

---

From: "Teague, Nik" <[email-masked]>
Date: Fri, 1 Apr 2016 12:54:17 +0000

>Yes, this was precisely my point about the utility of multiple DOTS relays in the signaling path when those relays are not owned by the entity originating the request for mitigation or the entity ac…

I agree - the relay outside of the two contexts listed becomes problematic.  

Thanks,

-Nik

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 1 Apr 2016 10:01:44 -0400

On 3/31/16 10:56 PM, Tirumaleswar Reddy (tireddy) wrote:
>> Confidentiality and privacy concerns would be the typical considerations
>> here, especially if we get into hosted or tiered services scenarios where the
>> DOTS relay may not be owned by the same entity as who is requesting
>> and/or providing the service. Consider for example a case where we the
>> DOTS client needs to provide the DOTS server with keying material in order
>> for the DDoS mitigation service to properly deal with TLS flows.
> I have assumed DOTS relay is either owned by the DOTS client or DOTS server. What is the use case for DOTS relay operated by some other entity ?
Inter-domain use cases, e.g. distributed/coordinated DDoS mitigation 
and/or the initial mitigation provider getting help from another entity.
> DOTS relay is not transparent proxy, so DOTS client and DOTS relay will have to perform mutual authentication,
At what level ? Transport/Session (e.g. TLS/DTLS) and/or App (DOTS) ?

> and DOTS relay and DOTS server will have to perform mutual authentication. If the DOTS relay is not trusted then the DOTS client will not reveal the private keys to the DOTS relay.
So you are arguing for hop-by-hop security and not end-to-end ?

-- Flemming

> -Tiru
>> -- Flemming
> .

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 1 Apr 2016 10:07:48 -0400

> I agree - the relay outside of the two contexts listed becomes problematic.
 From a privacy/confidentiality point of view, I'm not sure I see a lot 
of difference between a relay and a server+client if they each are 
forwarding sensitive information to a third party that the attack target 
had not signed up with initially. You could deal with this in different 
ways:
- Part of the service agreement with the DOTS provider (i.e. out of 
scope of DOTS)
- Have a way of separating/indicating in the DOTS signaling whether 
certain information can be shared with other parties or not.

It seems desirable for DOTS to support a distributed inter-domain model, 
however I do believe you have to handle privacy/confidentiality concerns 
as part of that.

Thanks

-- Flemming

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 01 Apr 2016 21:23:36 +0700

On 1 Apr 2016, at 21:07, Flemming Andreasen wrote:

> to a third party that the attack target had not signed up with 
> initially.

This scenario is not envisaged any time in the medium-term future.  
Service must be pre-provisioned; DOTS can help with the registration 
process.

> > - Part of the service agreement with the DOTS provider (i.e. out of 

This, yes.

> certain information can be shared with other parties or not.

This is way too complex, unneeded for the medium-term future.

> It seems desirable for DOTS to support a distributed inter-domain 
> model, however I do believe you have to handle privacy/confidentiality 
> concerns as part of that.

That isn't an initial requirement; it's a futures kind of thing.

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 1 Apr 2016 10:34:45 -0400

To be clear - the below is your personal view. The WG charter mentions 
inter-domain and we have a couple of (individual) drafts related to 
inter-domain already. While I share your concern about developing overly 
complicated mechanism that take many years to get through the whole 
process let alone implemented and deployed, I'm also not in favor of 
short-term solutions that cannot be extended to longer-term envisioned 
scenarios. In summary, more discussion in the WG is needed here.

Thanks

-- Flemming

On 4/1/16 10:23 AM, Roland Dobbins wrote:
>> model, however I do believe you have to handle 
>> privacy/confidentiality concerns as part of that.
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots
> .
>

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 01 Apr 2016 21:52:15 +0700

On 1 Apr 2016, at 21:34, Flemming Andreasen wrote:

> The WG charter mentions inter-domain

It's definitely inter-domain, as you indicate, concur 100%.

>  The WG charter mentions inter-domain and we have a couple of 
> (individual) drafts related to inter-domain already.

Again, concur 100%, the whole point of this exercise is inter-domain.  
We get intra-domain for free.

But a *federated* inter-domain model is something else entirely; that's 
what seems to be implied with talk of relays forwarding messages between 
domains which have no direct administrative/contractual relationship 
with one another.

Or am I misunderstanding your meaning?

> I'm also not in favor of short-term solutions that cannot be extended 
> to longer-term envisioned scenarios.

I'm in favor of something relatively simple and deployable near-term 
which can be expanded long-term, too.  We don't want to preclude 
anything useful down the road, agree 100%.

But we need to look at the actual problem-set which is crying for a 
solution at the present time, and for the foreseeable near-term future.  
That involves one-to-one and one-to-many bilateral relationships, not 
multilateral relationships - but again, I could be misunderstanding, 
here.

> In summary, more discussion in the WG is needed here.

The only possible point of contention I see here is federated vs. 
bilateral.  Again, I may be misunderstanding, so apologies if I am doing 
so.

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 01 Apr 2016 21:58:19 +0700

> I agree - the relay outside of the two contexts listed becomes 

So, in this sub-thread, I think we've explicitly derived a principle 
which many of us took as implicit - that the near-term model is 
one-to-one or one-to-many bilateralism, but *not* multilateralism.

I don't know of any multilateral models in this space today.  They're 
all bilateral (some with transitive practical outcomes), AFAICT.

There's a huge amount of complexity that comes with multilateralism, 
much of it outside the scope of DOTS.

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 01 Apr 2016 22:20:33 +0700

> At what level ? Transport/Session (e.g. TLS/DTLS) and/or App (DOTS) ?

Yes, this is the confusion to which I succumbed earlier.  From my 
standpoint, transport-level is node-by-node, application-layer is 
probably end-to-end, if that makes sense?

> So you are arguing for hop-by-hop security and not end-to-end ?

Does a distinction between transport-level and application-level make 
sense, here?

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 1 Apr 2016 15:31:57 +0000

> -----Original Message-----
> From: Flemming Andreasen (fandreas)
> Sent: Friday, April 01, 2016 7:32 PM
> To: Tirumaleswar Reddy (tireddy); Roland Dobbins; dots
> Subject: Re: [Dots] New Version Notification for draft-mortensen-dots-
> architecture-00.txt
> 
> 
> 
> >> Confidentiality and privacy concerns would be the typical
> >> considerations here, especially if we get into hosted or tiered
> >> services scenarios where the DOTS relay may not be owned by the same
> >> entity as who is requesting and/or providing the service. Consider
> >> for example a case where we the DOTS client needs to provide the DOTS
> >> server with keying material in order for the DDoS mitigation service to
> properly deal with TLS flows.
> > I have assumed DOTS relay is either owned by the DOTS client or DOTS
> server. What is the use case for DOTS relay operated by some other entity ?
> Inter-domain use cases, e.g. distributed/coordinated DDoS mitigation and/or
> the initial mitigation provider getting help from another entity.
> > DOTS relay is not transparent proxy, so DOTS client and DOTS relay
> > will have to perform mutual authentication,

Session level, as discussed in https://tools.ietf.org/html/draft-reddy-dots-transport-03 
(D)TLS can be used for mutual authentication.

> 
> > and DOTS relay and DOTS server will have to perform mutual
> authentication. If the DOTS relay is not trusted then the DOTS client will not
> reveal the private keys to the DOTS relay.

Yes, provided DOTS relay is fully-trusted (and not semi-trusted like the scenario where DOTS relay is owned by some other entity other than the DOTS client and server). 

-Tiru

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 01 Apr 2016 23:00:11 +0700

On 1 Apr 2016, at 22:31, Tirumaleswar Reddy (tireddy) wrote:

> Yes, provided DOTS relay is fully-trusted (and not semi-trusted like 
> the scenario where DOTS relay is owned by some other entity other than 
> the DOTS client and server).

I don't see the semi-trusted model becoming a real-world concern, 
anytime soon.  Fully-trusted is the expected model for the medium-term 
future, AFAICT.

---

From: Andrew Mortensen <[email-masked]>
Date: Tue, 5 Apr 2016 12:53:12 -0400

> On Apr 1, 2016, at 10:07 AM, Flemming Andreasen <[email-masked]> wrote:
> 
> 
> 
> From a privacy/confidentiality point of view, I'm not sure I see a lot of difference between a relay and a server+client if they each are forwarding sensitive information to a third party that the attack target had not signed up with initially. You could deal with this in different ways:
> - Part of the service agreement with the DOTS provider (i.e. out of scope of DOTS)
> - Have a way of separating/indicating in the DOTS signaling whether certain information can be shared with other parties or not.

(Apologies, I’ve been AFK for several days.)

I think there’s a subtle difference here that I didn’t make clear. In the case of recursive signaling, the DOTS client has already make an explicit choice to delegate mitigation to the entity controlling the DOTS server. If that entity lacks mitigation capacity entirely, and is simply reselling capacity from an upstream provider, that is opaque to the client. It does not make sense to me to require e2e in such a model, as the DOTS client entity may have no relationship with the resold mitigating entity, and indeed requiring such a model seems to complicate provisioning significantly.

In contrast, DOTS clients would NOT be delegating control over the mitigation to a third-party relay in the signaling path.

But this returns me to my previous point about when relays are appropriate. In what situation does a third-party relay make sense?

andrew

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 5 Apr 2016 15:12:02 -0300

> On Apr 5, 2016, at 1:53 PM, Andrew Mortensen <[email-masked]> wrote:

In what situation does a third-party relay make sense?

In none, AFAICT.   

Out of curiosity, where did the discussion of 3rd-party relays originate?   I was quite surprised & confused when I realized that this was being discussed.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 5 Apr 2016 22:04:18 -0400

On 4/1/16 10:52 AM, Roland Dobbins wrote:
> But a *federated* inter-domain model is something else entirely; 
> that's what seems to be implied with talk of relays forwarding 
> messages between domains which have no direct 
> administrative/contractual relationship with one another.
>
I think you get the general idea, but I don't really like the term 
"federated" because it tends to be poorly defined and I don't know what 
you imply by it. In terms of message forwarding between domains, I am in 
fact assuming that there is some well-defined relationship in place 
between them, at least one as long as we are one "DOTS-hop" away.

> solution at the present time, and for the foreseeable near-term 
> future.  That involves one-to-one and one-to-many bilateral 
> relationships, not multilateral relationships - but again, I could be 
> misunderstanding, here.
>
I'm not sure - let's discuss in person here in Buenos Aires.

Thanks

-- Flemming
> bilateral.  Again, I may be misunderstanding, so apologies if I am 
> doing so.
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 5 Apr 2016 22:07:41 -0400

> Does a distinction between transport-level and application-level make 
It helps clarify, but it does assume a certain design wrt node-by-node 
(we do have examples of protocols that provide node-by-node/hop-by-hop 
security at the app-layer).

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 5 Apr 2016 22:33:52 -0400

On 4/1/16 12:00 PM, Roland Dobbins wrote:
>> the scenario where DOTS relay is owned by some other entity other 
>> than the DOTS client and server).
>
So that is indeed the question. I agree it simplifies the overall design 
and I am not opposed to have a multi-phased approach where we tackle a 
simpler problem first, provided we can extend it later. Having said that:
1) There is interest in multi-provider scenarios, as evidenced by the 
inter-domain drafts
2) You cannot ignore privacy and regulatory requirements these days - 
they are real both in terms of customer request/demands and actual 
implementation in the form of Data Centers/Cloud services 
implemented/deployed in certain geographic areas to satisfy these 
concerns. This is not what I would call "fully trusted" (but then again, 
I'm not entirely clear on your definition here)

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 5 Apr 2016 22:43:49 -0400

On 4/5/16 12:53 PM, Andrew Mortensen wrote:
> I think there’s a subtle difference here that I didn’t make clear. In the case of recursive signaling, the DOTS client has already make an explicit choice to delegate mitigation to the entity controlling the DOTS server.
Agreed.
>   If that entity lacks mitigation capacity entirely, and is simply reselling capacity from an upstream provider, that is opaque to the client. It does not make sense to me to require e2e in such a model, as the DOTS client entity may have no relationship with the resold mitigating entity, and indeed requiring such a model seems to complicate provisioning significantly.
So again, this is the part I want us all to be clear on (and explicit in 
our assumptions and operations/trust model going forward):

 From a DOTS client point of view, when I have signed up with a provider A:
1) Can I assume that all information shared with A will not be shared 
further ?
2) Can I assume that all mitigation will be provided by A (or at least 
mitigation that requires access to potentially confidential information 
such as keying material which would give the provider clear-text access 
to payload.)
3) If information and/or mitigation is provided by parties other than A, 
should I have a way of controlling who those parties are and/or what 
confidential information they can get access to ?

> But this returns me to my previous point about when relays are appropriate. In what situation does a third-party relay make sense?
See above (it's not so much a third-party relay to begin with as it is a 
question of multiple providers and hence my information and/or 
mitigation ending up with somebody else than I though to begin with).

Thanks

-- Flemming

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 06 Apr 2016 08:25:06 -0300

> 1) Can I assume that all information shared with A will not be shared 

Yes.

> mitigation that requires access to potentially confidential 
> information such as keying material which would give the provider 
> clear-text access to payload.)

Yes.

> 3) If information and/or mitigation is provided by parties other than 
> A, should I have a way of controlling who those parties are and/or 
> what confidential information they can get access to ?

Again, these are bilateral relationships from a DOTS perspective, not 
multilateral.  So, yes, with the above caveat that they will by 
definition be able to see the network traffic itself.

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 06 Apr 2016 17:40:42 -0300

> I'm not sure - let's discuss in person here in Buenos Aires.

Note that currently and for the foreseeable future, multilateral is 
pretty much a nonstarter for both out-of-band administrative and trust 
reasons surrounding BGP, DNS, et. al., as well as the potential for 
misuse.