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

From: Andrew Mortensen <[email-masked]>
Date: Sat, 19 Mar 2016 23:15:32 -0400

Hi all. We’ve submitted a DOTS architecture draft for consideration. We look forward to discussion and feedback.

Thanks,
andrew

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-mortensen-dots-architecture-00.txt
> Date: March 19, 2016 at 11:10:54 PM EDT
> To: "Andrew Mortensen”, "Nik Teague", "Rich Compton", "Flemming Andreasen", "Christopher Gray", "Tirumaleswar Reddy" 
> 
> 
> A new version of I-D, draft-mortensen-dots-architecture-00.txt
> has been successfully submitted by Andrew Mortensen and posted to the
> IETF repository.
> 
> Name:		draft-mortensen-dots-architecture
> Revision:	00
> Title:		Distributed-Denial-of-Service (DDoS) Open Threat Signaling Architecture
> Document date:	2016-03-19
> Group:		Individual Submission
> Pages:		25
> URL:            https://www.ietf.org/internet-drafts/draft-mortensen-dots-architecture-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-mortensen-dots-architecture/
> Htmlized:       https://tools.ietf.org/html/draft-mortensen-dots-architecture-00
> 
> 
> Abstract:
>   This document describes an architecture for establishing and
>   maintaining Distributed Denial of Service (DDoS) Open Threat
>   Signaling (DOTS) within and between networks.  The document makes no
>   attempt to suggest protocols or protocol extensions, instead focusing
>   on architectural relationships, components and concepts used in a
>   DOTS deployment.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Sat, 26 Mar 2016 09:36:09 +0000

Hi Andrew,
It’s a good start for the DOTS architecture work. I have some comments as follows:

1.       In assumptions part, please consider add two more:

a)         The dots agents in the architecture are variable in the aspects such as: address, transport protocol, capability, as well as the addition of new agents or the leaving of old agents;

b)         In an end to end dots connection, there is possibly several different transport protocols applied over part of the path;

2.       What do you imply by “we request working group feedback and discussion of operational considerations relating to coordinating multiple provider responses to a mitigation request”? Could you elaborate more details about what is the possible problem for it?

3.       What is the exact meaning of the sentence – “The requests may be in response to an active, ongoing attack against a target in the DOTS  client’s domain, but no active attack is required for a DOTS client to request help. ”?

4.       Questions about the dots relay:

a)         Can you give me a concrete example of what kind of device can be as a dots relay? If it can be a router, does it mean that router need to be updated to support some dots relay functions?

b)         How to clearly differentiate the dots server and dots relay from functional perspective? Especially in the aspects of pre-provisioning, mutual authentication/authorization, dots signaling communication from the viewpoints of dots clients? It seems to have some functions overlapping between the relay and server.

c)         In general, relay means the in-path device being transparent to the end points, but do snooping over the protocol messages (such as dhcp relay, dns relay, etc). But in dots architecture, does the dots relay run in this way, or run more the way as a proxy?

5.       Comparing the redirect way with the recursive way, the former is not a good choice because we should not require the dots client to involve in more communications when it is under a severe attack;

6.       In the recursive way, why is it the mitigator to request more mitigation service to other dots server? Why not run all the mitigation control and decisions on the dots server? Do you agree it’s more clear aligned to dots scope?

B.R.
Frank
发件人: Dots [mailto:[email-masked]] 代表 Andrew Mortensen
发送时间: 2016年3月20日 11:16
收件人: dots
主题: [Dots] Fwd: New Version Notification for draft-mortensen-dots-architecture-00.txt

Thanks,
andrew

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-mortensen-dots-architecture-00.txt
Date: March 19, 2016 at 11:10:54 PM EDT
To: "Andrew Mortensen”, "Nik Teague", "Rich Compton", "Flemming Andreasen", "Christopher Gray", "Tirumaleswar Reddy"

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: "Teague, Nik" <[email-masked]>
Date: Sat, 26 Mar 2016 10:11:24 +0000

Frank hi,

On 26 Mar 2016, at 09:36, Xialiang (Frank) <[email-masked]<mailto:[email-masked]>> wrote:

.       What is the exact meaning of the sentence – “The requests may be in response to an active, ongoing attack against a target in the DOTS  client’s domain, but no active attack is required for a DOTS client to request help. ”?

This means that a client may of course request mitigation when actively under attack.  The client may also request services be put under mitigation protection at any time.  An example would be a client who receives reliable intel that they will be targeted from a certain date - they may proactively request service be swung to the scrubbing centre prior to an actual attack occurring.

A more mundane example is test swings during client set up or as a general test that their service will work when it comes to the crunch.

Thanks,

-Nik

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 26 Mar 2016 20:56:57 +0700

> Hi Andrew,

I'm not Andrew, but I'll take a stab at this - I'm sure Andrew, et. al. 
will correct me as necessary:

> a)         The dots agents in the architecture are variable in the 
> aspects such as: address, transport protocol, capability, as well as 
> the addition of new agents or the leaving of old agents;

I personally don't see any problem with this, but defer to Andrew and 
the other folks working on the architecture.

>
> b)         In an end to end dots connection, there is possibly several 
> different transport protocols applied over part of the path;

Yes, this is implied.  It should probably be expressed explicitly, IMHO.

> 2.       What do you imply by “we request working group feedback and 
> discussion of operational considerations relating to coordinating 
> multiple provider responses to a mitigation request”? Could you 
> elaborate more details about what is the possible problem for it?

I believe the request here is for additional feedback for any 
considerations which arise in a multi-provider scenario, where 
coordination is needed between the client and two or more mitigation 
providers, and between the mitigation providers themselves.  This 
scenario was described in use-cases-00 and -01, detailed in the diagrams 
in the -00 .pdf preso, and will be in the same preso for -01.

> 3.       What is the exact meaning of the sentence – “The requests 
> may be in response to an active, ongoing attack against a target in 
> the DOTS  client’s domain, but no active attack is required for a 
> DOTS client to request help. ”?

Nik already replied to this one.  Additionally, an organization may 
believe that they're about to come under attack - say, they received a 
DDoS extortion demand - and want to proactively request that mitigation 
be initiated.

> a)         Can you give me a concrete example of what kind of device 
> can be as a dots relay?

Anything with an IP address.

> If it can be a router, does it mean that router need to be updated to 
> support some dots relay functions?

Yes.

> b)         How to clearly differentiate the dots server and dots relay 
> from functional perspective? Especially in the aspects of 
> pre-provisioning, mutual authentication/authorization, dots signaling 
> communication from the viewpoints of dots clients? It seems to have 
> some functions overlapping between the relay and server.

They're essentially identical, except that the relay doesn't directly 
cause the initiation/termination of mitigation.

>
> c)         In general, relay means the in-path device being 
> transparent to the end points, but do snooping over the protocol 
> messages (such as dhcp relay, dns relay, etc).

That's a usage which has been adopted by some in the vendor and 
standards communities, but is not the standard dictionary definition of 
the word 'relay'.

> But in dots architecture, does the dots relay run in this way, or run 
> more the way as a proxy?

A proxying function is part of being a relay, yes.

> 5.       Comparing the redirect way with the recursive way, the former 
> is not a good choice because we should not require the dots client to 
> involve in more communications when it is under a severe attack;

When a client requests mitigation, and a server reports back that it 
can't initiate mitigation for whatever reason (lack of capacity, lack of 
functionality, error state, etc.), then the client is going to have to 
request mitigation elsewhere, anyways, assuming it's configured to do 
so.  The redirect message provides the client with the information it 
needs to reach a functioning DOTS server which can fulfill the request.

Without redirection, the client must try blindly, or just give up.

So, the implication that a redirect will cause more communications to be 
initiated by the client is incorrect.

> Why not run all the mitigation control and decisions on the dots 
> server?

Because of flexibility of deployment models, of course.  And because all 
mitigators - in fact, most mitigators, at least in the beginning of DOTS 
deployment - won't themselves be DOTS-capable.

> Do you agree it’s more clear aligned to dots scope?

Nope.

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 27 Mar 2016 10:36:24 +0000

> > messages (such as dhcp relay, dns relay, etc).

No need for the DOTS relay to snoop the messages sent by the DOTS client. DOTS relay is not transparent to the DOTS client, DOTS client will authenticate the DOTS relay and establish a secure session with the DOTS relay to exchange DOTS messages.

> 
> That's a usage which has been adopted by some in the vendor and standards
> communities, but is not the standard dictionary definition of the word 'relay'.
> 

It's more like a non-transparent proxy, to the DOTS client the DOTS relay acts as a DOTS server. DOTS client need not even have to distinguish b/w a DOTS relay and DOTS server.

-Tiru

---

From: "Roland Dobbins" <[email-masked]>
Date: Mon, 28 Mar 2016 22:35:15 +0700

On 27 Mar 2016, at 17:36, Tirumaleswar Reddy (tireddy) wrote:

> DOTS client need not even have to distinguish b/w a DOTS relay and 
> DOTS server.

Concur 100%.

It's an intermediary.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 31 Mar 2016 12:05:48 -0400

Thanks for the feedback on the document so far - I have added some 
additional responses below

On 3/26/16 9:56 AM, Roland Dobbins wrote:
> I'm not Andrew, but I'll take a stab at this - I'm sure Andrew, et. 
> al. will correct me as necessary:
>
We can add that.
>>
>> b)         In an end to end dots connection, there is possibly 
>> several different transport protocols applied over part of the path;
>
Section 2.2 has a few examples showing this, but we can call it more 
explicitly up front.

> providers, and between the mitigation providers themselves.

Correct - there are a few of these statements throughout the document. 
We don't claim to have everything fully fleshed out, and there were a 
few areas where we knew for sure we didn't so we added statements to 
explicitly highlight those.

>   This scenario was described in use-cases-00 and -01, detailed in the 
> diagrams in the -00 .pdf preso, and will be in the same preso for -01.
>
> DDoS extortion demand - and want to proactively request that 
> mitigation be initiated.
>
Agree with the above.
>> b)         How to clearly differentiate the dots server and dots 
>> relay from functional perspective? Especially in the aspects of 
> standards communities, but is not the standard dictionary definition 
> of the word 'relay'.
>
The details of the relay is something that requires further discussion 
in the group. Some of the open areas include:
- Identity and authentication - is it end-to-end or per-hop (or both) ?
- Integrity - end-to-end or per-hop (or both) ?
- Reliability - again, end-to-end or per-hop (or both) ?

The above needs to take into consideration that you may have more than 
one relay, and if we want to get into multi-tiered DOTS relationships 
(e.g. provider 1 requests further assistance from provider 2), then the 
above questions become harder.

In summary, I think it's premature to conclude exactly how transparent 
relays are - we need further discussion of the above issues (and 
probably others) to further detail the role and operation of the relays 
before we can really answer that.

>> 5.       Comparing the redirect way with the recursive way, the 
>> former is not a good choice because we should not require the dots 
>> client to involve in more communications when it is under a severe 
>> attack;
>
> can't initiate mitigation for whatever reason (lack of capacity, lack 
> of functionality, error state, etc.), then the client is going to have 
> to request mitigation elsewhere, anyways, assuming it's configured to 
> do so.  The redirect message provides the client with the information 
> it needs to reach a functioning DOTS server which can fulfill the 
> request.
>
> So, the implication that a redirect will cause more communications to 
> be initiated by the client is incorrect.
>
Not sure I see that. If the provider is able to redirect then it has 
knowledge of some other entity that can be tried for mitigation, which 
would enable the client to leverage the already established session. 
Granted, if the DOTS server is exhausted in terms of signaling support, 
then you have a problem, but that seems to be a more manageable problem 
than being exhausted for mitigation capacity.

>> Why not run all the mitigation control and decisions on the dots server?
>
> Because of flexibility of deployment models, of course.  And because 
> all mitigators - in fact, most mitigators, at least in the beginning 
> of DOTS deployment - won't themselves be DOTS-capable.
>
Agreed.

Thanks

-- Flemming

> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 31 Mar 2016 12:12:34 -0400

> No need for the DOTS relay to snoop the messages sent by the DOTS client. DOTS relay is not transparent to the DOTS client, DOTS client will authenticate the DOTS relay and establish a secure sessi…

More discussion is needed on these.
- If the DOTS relay can connect to multiple providers then it will need 
to look at something to determine where to send a message (or the relay 
is much intelligent that we have assumed so far). Similar considerations 
apply for the reverse direction.
- End-to-end vs. hop-by-hop identity and authentication is an area that 
requires further discussion of the overall architecture.

> It's more like a non-transparent proxy, to the DOTS client the DOTS relay acts as a DOTS server. DOTS client need not even have to distinguish b/w a DOTS relay and DOTS server.
Maybe - I agree it should be a goal, but it's not obvious to me right 
now whether that's where everything will end. It depends on further 
defintion of the DOTS relay in the overall architecture (see some of the 
open issues noted in the architecture document and my reply to Roland's 
e-mail).

Thanks

-- Flemming

> .

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 31 Mar 2016 23:26:02 +0700

On 31 Mar 2016, at 23:05, Flemming Andreasen wrote:

>  Identity and authentication - is it end-to-end or per-hop (or both) ?

Node-by-node - the whole point of the relay is to gain an additional 
layer of indirection.

> - Integrity - end-to-end or per-hop (or both) ?

Same as above.

> - Reliability - again, end-to-end or per-hop (or both) ?

Same as above.

> (e.g. provider 1 requests further assistance from provider 2), then 
> the above questions become harder.

No more so that for BGP.

> probably others) to further detail the role and operation of the 
> relays before we can really answer that.

They don't need to be transparent at all - the entire point of the relay 
is to provide a layer of indirection, per the above.

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 31 Mar 2016 23:29:07 +0700

On 31 Mar 2016, at 23:12, Flemming Andreasen wrote:

> - If the DOTS relay can connect to multiple providers then it will 
> need to look at something to determine where to send a message (or the 
> relay is much intelligent that we have assumed so far). Similar 
> considerations apply for the reverse direction.

Policies, like BGP - but simpler.

> - End-to-end vs. hop-by-hop identity and authentication is an area 
> that requires further discussion of the overall architecture.

Per previous email, node-by-node is the only thing which makes sense.

> defintion of the DOTS relay in the overall architecture (see some of 
> the open issues noted in the architecture document and my reply to 
> Roland's e-mail).

Per above, the DOTS client needn't know that it's talking to a relay.  A 
DOTS relay is just a subset of a DOTS server.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 31 Mar 2016 17:32:10 +0000

> -----Original Message-----
> From: Flemming Andreasen (fandreas)
> Sent: Thursday, March 31, 2016 9:43 PM
> To: Tirumaleswar Reddy (tireddy); Roland Dobbins; dots
> Subject: Re: [Dots] New Version Notification for draft-mortensen-dots-
> architecture-00.txt
> 
> 
> 
> > No need for the DOTS relay to snoop the messages sent by the DOTS client.
> DOTS relay is not transparent to the DOTS client, DOTS client will
> authenticate the DOTS relay and establish a secure session with the DOTS
> relay to exchange DOTS messages.
> 
> - If the DOTS relay can connect to multiple providers then it will need to look
> at something to determine where to send a message (or the relay is much
> intelligent that we have assumed so far). Similar considerations apply for the
> reverse direction.

Yes. In case of multi-homing, if it is one DOTS client, one DOTS relay in the Enterprise network and DOTS servers in access networks. DOTS relay located in the Enterprise premises will have to fork and forward the DOTS signal from the DOTS client to DOTS servers in multiple access networks, it will also have to strip and only forward attack targets addresses and prefixes owned by the access network.
We will also have to figure out how DOTS relay will handle different responses from each of the DOTS server.  
However if the DOTS client is knows about multi-homing, it can create multiple DOTS signals each carrying the addresses and prefixes owned by the access network and sends them to multiple DOTS relays. The latter mechanism looks simpler.

> requires further discussion of the overall architecture.

Hop-by-hop identity and authentication. Any specific reason for end-to-end identity and authentication ?

-Tiru

> >>> But in dots architecture, does the dots relay run in this way, or
> >>> run more the way as a proxy?
> > It's more like a non-transparent proxy, to the DOTS client the DOTS relay
> acts as a DOTS server. DOTS client need not even have to distinguish b/w a
> DOTS relay and DOTS server.
> Maybe - I agree it should be a goal, but it's not obvious to me right now
> whether that's where everything will end. It depends on further defintion of
> the DOTS relay in the overall architecture (see some of the open issues noted
> in the architecture document and my reply to Roland's e-mail).
> 
> Thanks
> 
> -- Flemming
> 
> > -Tiru

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 31 Mar 2016 13:42:40 -0400

> Node-by-node - the whole point of the relay is to gain an additional 
Sure, but but doesn't imply anything wrt to the above.

>> - Reliability - again, end-to-end or per-hop (or both) ?
I was hoping for some actual considerations rather than isolated 
statements - can you elaborate on all of the above ?

>> The above needs to take into consideration that you may have more 
>> than one relay, and if we want to get into multi-tiered DOTS 
>> relationships (e.g. provider 1 requests further assistance from 
>> provider 2), then the above questions become harder.
>
> No more so that for BGP.
>
I don't believe BGP has explicit relay functions as part of its 
architecture. Please elaborate on how you see BGP as the proper analogy 
here and not e.g. DIAMETER ?

>> In summary, I think it's premature to conclude exactly how 
>> transparent relays are - we need further discussion of the above 
>> issues (and probably others) to further detail the role and operation 
>> of the relays before we can really answer that.
>
> They don't need to be transparent at all - the entire point of the 
> relay is to provide a layer of indirection, per the above.
>
Ok.  If I understand your position correctly, you believe that relays 
are essentially full-fledged Server+Client implementations that fully 
terminate and re-originate all signaling and information elements and 
the entities that utilize them will not be able to directly see anything 
on the other side of the relay. This applies to the information itself, 
as well as reliability and all aspects of identity and security. Do I 
have that correct ?

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 31 Mar 2016 15:05:12 -0400

> However if the DOTS client is knows about multi-homing, it can create multiple DOTS signals each carrying the addresses and prefixes owned by the access network and sends them to multiple DOTS rela…
I'm not sure. Your scenarios make sense to me, but it looks like there 
is an element of topology awareness required here wrt the attack target 
network as well as the associated DOTS servers you are requesting 
service from. The closer the DOTS clients get to the actual attack 
targets (e.g. a web server), the less desirable it seems to have that 
functionality there. My preference would be to try and handle as much of 
this on the DOTS server/mitigation side as possible, but I haven't given 
much thought to the details of how all of that would actually work (in 
either scenario).

> Hop-by-hop identity and authentication. Any specific reason for end-to-end identity and authentication ?

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.

-- Flemming

---

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

> statements - can you elaborate on all of the above ?

It's simple - there's simply no need for end-to-end.  Node-by-node is 
perfectly adequate, is also much more easily operationally supported, 
and is considerably less brittle.

I'd turn that question on its head and ask why we would even consider 
end-to-end for this application?

> architecture. Please elaborate on how you see BGP as the proper 
> analogy here and not e.g. DIAMETER ?

I was trying to make an analogy with the peering and route-policy 
functions of BGP implementations which control what routing 
advertisements are propagated to which peers, in a multi-peered 
topology.

> If I understand your position correctly, you believe that relays are 
> essentially full-fledged Server+Client implementations that fully 
> the entities that utilize them will not be able to directly see 
> anything on the other side of the relay. This applies to the 
> information itself, as well as reliability and all aspects of identity 
> and security. Do I have that correct ?

Yes.  Indirection and obfuscation are highly desirable traits for this 
application; also, this type of model is really the only sort of thing 
which works from an operational perspective.  Anything else is too 
convoluted and brittle.

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 01 Apr 2016 02:12:24 +0700

On 1 Apr 2016, at 2:05, Flemming Andreasen wrote:

> there is an element of topology awareness required here wrt the attack 
> target network

I disagree with this premise.  All that information is out-of-band from 
a DOTS perspective; it's administrative logic/policy which is not within 
the ambit of the DOTS system.

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

Same as above - this is admin/policy stuff which is completely outside 
the scope of DOTS.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 31 Mar 2016 15:52:04 -0400

> end-to-end for this application?
Ok - you didn't answer my question though so I'll ask again.

There is a classic paper titled "end-to-end arguments in system design" 
that gets into some of the reasons beind end-to-end that you may want to 
take a look at.

> advertisements are propagated to which peers, in a multi-peered topology.
>
I agree that the route-policy issues seem to parallel some of the 
operational considerations in DOTS around which (alleged) attack targets 
a mitigation provider should actually start redirecting traffic for. I'm 
not sure if it's in scope of DOTS to solve that policy/authorization 
aspect though - the architecture draft explicitly noted (suggested) it 
as out of scope but it would be good to hear more opinions on that.

In either case, I'm not sure it helps us answer the relay question where 
I still see more parallels to something like DIAMETER than BGP (not that 
I am in anyway suggesting we should use DIAMETER, but there is at least 
something to look at in terms of capabilities and pitfalls).

>> information itself, as well as reliability and all aspects of 
>> identity and security. Do I have that correct ?
>
Ok. I'm not convinced because taking a pure hop-by-hop approach 
complicates the DOTS relay significantly by creating (end-to-end) 
reliability and security issues. The DOTS relay will have to be 
stateful, which is something you generally want to try and avoid if 
possible. If anything, a stateful relay is more brittle.

-- Flemming

---

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

On 1 Apr 2016, at 2:52, Flemming Andreasen wrote:

> There is a classic paper titled "end-to-end arguments in system 
> design" that gets into some of the reasons beind end-to-end that you 
> may want to take a look at.

Yeah, I read it thirty-odd years ago when it came out, thanks.

> the architecture draft explicitly noted  (suggested) it as out of 
> scope but it would be good to hear more opinions on that.

I believe we may be talking at cross purposes, here - what in 
draft-mortensen-dots-architecture-00 precludes your view of what we're 
discussing?

> but there is at least something  to look at in terms of capabilities 
> and pitfalls).

Can you expound upon what you find attractive in the Diameter model?

> reliability and security issues.

What kind of reliability issues are raised, in your view?

What kind of security issues are raised, in your view?

Keep in mind that this is not a general-purpose system and that a) the 
number of participants in a given DOTS communications chain is low and 
b) access to said communications chain and associated system is highly 
restrictive.

> The DOTS relay will have to be stateful, which is something you 
> generally want to try and avoid if possible.

Can you explain how statefulness implied in node-by-node?

---

From: Andrew Mortensen <[email-masked]>
Date: Thu, 31 Mar 2016 17:01:15 -0400

The discussion so far mostly covers how DOTS relays would pass signals, but not why DOTS relays might be valuable in the first place.

The two simplest—and in my mind strongest—use cases for the DOTS relay seem to be:

1) As an aggregation point at e.g. the DOTS client network edge in an inter-domain use case, simplifying network policy management for the DOTS client/server relationship, and for operators in both domains.

2) As a bridge between signaling sessions using different protocols, alluded to in I-D.ietf-dots.requirements OP-001.

Use cases beyond that are murkier to me, and need more discussion, e.g. could or should a relay operate as a signal reflector? in what way is that different from a multi-homed client? etc.

Flemming’s point regarding confidentiality and privacy concerns in the hop-by-hop model is valid, particularly around the sort of delegated ownership of the request for mitigation in the hosted or tiered services scenario. [1] (That particular use case also happens to align well with the Recursive Signaling mode of operation described in I-D.mortensen-dots-architecture 4.2.4.)

> Keep in mind that this is not a general-purpose system and that a) the number of participants in a given DOTS communications chain is low and b) access to said communications chain and associated system is highly restrictive.

This is a good point. It also raises more questions 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.

andrew

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 31 Mar 2016 17:23:27 -0400

> Yeah, I read it thirty-odd years ago when it came out, thanks.
You're welcome. You snipped my question though so I will now ask you for 
the third time to please answer that.

> draft-mortensen-dots-architecture-00 precludes your view of what we're 
I did not say that the architecture draft precludes anything. Please 
reply with the proper context instead of selectively deleting context.

> Can you expound upon what you find attractive in the Diameter model?
I did not say I find the Diameter model attractive. What I did say is 
that it defines the notion of relays (in contract to BGP) and hence it 
may be worth looking at.

> What kind of reliability issues are raised, in your view?
Message reliability for example. Without end-to-end acknowledgement you 
don't know if your messages are actually delivered to the intended target

> What kind of security issues are raised, in your view?
Classic man-in-the-middle; confidentiality/privacy and integrity as I 
noted previously.

> b) access to said communications chain and associated system is highly 
Where is that stated and how is that ensured ?

> Can you explain how statefulness implied in node-by-node?
If you do hop-by-hop acknowledgements only and you want to guarantee 
reliable delivery (or at least attempt to do), then you need to be 
stateful.

-- Flemming

---

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

On 1 Apr 2016, at 4:23, Flemming Andreasen wrote:

> You snipped my question though so I will now ask you for the third 
> time to please answer that.

I thought I answered all your questions, as you very nicely summed up 
what you believed to be my view of the DOTS relay, which summary I 
acknowledged as being accurate.  I'm not trying to avoid any question 
you have.

What is it specifically that I haven't answered?

> I did not say that the architecture draft precludes anything.

How should 'out of scope' be interpreted, if not to preclude something?

> Please reply with the proper context instead of selectively deleting 
> context.

I think we have differing philosophies with regards to email replies.  
My philosophy is to elide everything which isn't being directly replied 
to in my reply, so that successive email replies don't grow into 
unreadable messes.

> that it defines the notion of relays (in contract to BGP) and hence it 

The functions of Diameter relays, proxies, and translators map quite 
well onto projected DOTS relay functions, IMHO, as does the Diameter 
redirect.

Are we somehow talking at cross purposes with regards to 
'hop-by-hop'/'node-by-node'?

> Message reliability for example. Without end-to-end acknowledgement 
> you don't know if your messages are actually delivered to the intended 
> target

Sure you do, at the application layer.  Additional supporting 
confirmation/contradiction comes from external indicators that the 
desired actions have either been taken or not taken.

> Classic man-in-the-middle; confidentiality/privacy and integrity as I 

Without getting too far into the design weeds, there are ways to ensure 
end-to-end message authenticity/integrity in a node-by-node 
communications chain, are there not?

The same confidentiality issues arise if a DOTS client or DOTS sever are 
compromised.  Adding a relay node type doesn't increase those risks, 
IMHO.

> Where is that stated and how is that ensured ?

It's inherent in the nature of the thing itself.  There aren't going to 
be scads of DOTS clients, servers, or relays.

It's ensured via AAA, associated provisioning requirements, and network 
access control BCPs.

> reliable delivery (or at least attempt to do), then you need to be 

I was thinking of the reliability issue as being handled at layer-7, per 
the above.  Apologies for being unclear in that regard.

---

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

On 1 Apr 2016, at 4:01, Andrew Mortensen wrote:

> 1) As an aggregation point at e.g. the DOTS client network edge in an 
> inter-domain use case, simplifying network policy management for the 
> DOTS client/server relationship, and for operators in both domains.
>
> 2) As a bridge between signaling sessions using different protocols, 
> alluded to in I-D.ietf-dots.requirements OP-001.

Concur 100%.

> Use cases beyond that are murkier to me, and need more discussion, 
> e.g. could or should a relay operate as a signal reflector? in what 
> way is that different from a multi-homed client? etc.

Redirection is one that comes to mind.  Another is policy 
enforcement/transformation at layer 7.

> Flemming’s point regarding confidentiality and privacy concerns in 
> the hop-by-hop model is valid, particularly around the sort of 
> delegated ownership of the request for mitigation in the hosted or 
> tiered services scenario.

Can you comment on my reply on this topic to Flemming?

> This is a good point. It also raises more questions 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.

I personally haven't envisaged such a scenario being even theoretically 
possible nor desirable due to all the out-of-band administrative and 
policy overhead which would militate against such a model.  DOTS 
communications relationships are 'nailed up', with the possibility 
redirection to predesignated, mutually-agreed-upon fallbacks, IMHO.

Does this make sense?

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 31 Mar 2016 18:18:05 -0400

> What is it specifically that I haven't answered?
I'll resend separately.
> My philosophy is to elide everything which isn't being directly 
> replied to in my reply, so that successive email replies don't grow 
> into unreadable messes.
>
Entirely reasonable as long as you don't change the meaning of what was 
actually stated.

>> that it defines the notion of relays (in contract to BGP) and hence 
>> it may be worth looking at.
>
I don't know, but assuming you will be in Buenos Aires, a higher bw 
channel is probably a better way of figuring that out.

>> you don't know if your messages are actually delivered to the 
>> intended target
>
Sounds like end-to-end to me.
> Without getting too far into the design weeds, there are ways to 
> ensure end-to-end message authenticity/integrity in a node-by-node 
Indeed there is, but your original reply said it was node-by-node.

> The same confidentiality issues arise if a DOTS client or DOTS sever 
> are compromised.  Adding a relay node type doesn't increase those 
> risks, IMHO.
>
If it relays information for N number of clients (where N>1), then the 
risk is indeed higher. If you were an attacker, would you rather take 
control of a TLS proxy or a TLS endpoint ?

> It's inherent in the nature of the thing itself.  There aren't going 
> to be scads of DOTS clients, servers, or relays.
>
One of the use cases you presented previously argued that DOTS clients 
could be per endpoint (I believe you had a phone as an example). There 
could be a lot of those.

Regardless, whether we believe there will be a lot of these or not, I 
don't think that fundamentally changes anything wrt privacy and 
confidentiality. Arguments about access to them being "highly 
restrictive" as a way of addressing those security concerns are (IMO) 
unlikely to be viewed as adequate to most security/privacy folks these 
days. Given where these relays would furthermore have to be deployed, 
I'm not even sure it's feasible in practice.

> It's ensured via AAA, associated provisioning requirements, and 
> network access control BCPs.
>
> I was thinking of the reliability issue as being handled at layer-7, 
> per the above.  Apologies for being unclear in that regard.
>
No worries - it sounds like end-to-end to me though, but let's discuss 
further in Buenos Aires unless you believe we are actually in agreement 
here.

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 31 Mar 2016 18:20:27 -0400

[resending the parts that I don't believe got answered yet]

Thanks

-- Flemming

---

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

> Indeed there is, but your original reply said it was node-by-node.

Indeed, I think we were talking past one another - my mistake!

I was referring to the DOTS 'peering' relationship in particular, and 
whether the DOTS client is required to be cognizant in terms of 'DOTS 
peering' that there's a DOTS server sitting somewhere 'behind' the 
relay.

> control of a TLS proxy or a TLS endpoint ?

I'd go for the server endpoint.

;>

But I'm unsure it's a valid analogy, in this context.

DOTS clients, relays and DOTS servers all have the same threat model, 
IMHO.

> risk is indeed higher.

No higher than a server.  Plus, applying a statistical risk factor in 
this manner isn't necessarily valid, IMHO (we can discuss this in 
person, no need to type a semi-OT novel into the list).

> could be per endpoint (I believe you had a phone as an example).

That was meant to represent a specific DOTS client on a specific phone 
of a designated user who was using it to request DDoS mitigation for a 
specific public-facing asset, like a Web server or DNS server or SBC or 
whatnot - it wasn't meant to imply that individual phones were 
requesting DDoS mitigation services for themselves, heh.

Sorry for being unclear!

> Arguments about access to them being "highly restrictive" as a way of 
> addressing those security concerns are (IMO) unlikely to be viewed as 
> adequate to most security/privacy folks these days.

This system must be readily deployable, or it will not be utilized.  
Latter-day cryptosteria aside, if there's much more configuration of a 
DOTS client required than setting up 'DOTS peering' with an 
easily-distributed authentication token between said client and the 
relevant relay or server, it will likely be a non-starter, IMHO.

Note that it's pretty difficult to maintain confidentiality with regards 
to changes in BGP announcements, changes to authoritative DNS records, 
network traceroutes, protocol response changes denoting interactive 
countermeasures, lack of responses allowing the inference of packet 
filtering, et. al.  So, a great deal of the usual confidentiality 
arguments are actually moot, since these dramas are cited out on the 
stage of the public Internet, as it were.

> Given where these relays would furthermore have to be deployed, I'm 
> not even sure it's feasible in practice.

The network access policy model for DOTS relays (and servers, and 
clients) should be highly restrictive.  And there's a whole bunch of 
out-of-band admin/policy work which has to get done to even make the 
system function.  We should discuss this in more detail in person, as 
you indicate.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 1 Apr 2016 02:56:59 +0000

> 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 ?
DOTS relay is not transparent proxy, so DOTS client and DOTS relay will have to perform 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. 

-Tiru