Subject: [Dots] Deprecate DOTS Relay and limit scope to 1-hop (DOTS Client - Server) Re: 答复: Hi, some comments to DOTS requirements draft:

From: Flemming Andreasen <[email-masked]>
Date: Fri, 10 Jun 2016 13:16:29 -0400

Following up on this thread and changing the subject to make it explicit:

As we have seen in a couple of drafts and accompanying discussions, DOTS 
relays introduce a fair amount of complexity and multi-level 
authentication/authorization issues that we currently do not have good 
answers for. Based on that and given an apparent lack of a compelling 
need for DOTS relays, it was suggested that we remove DOTS relays from 
the overall DOTS architecture and effectively limit the requirements, 
architecture and protocol scope to a single hop (DOTS client - DOTS 
server). As noted below, that doesn't mean you cannot have more than one 
hop in practice by leveraging recursive signaling and a Back-2-Back DOTS 
Agent, and we should in fact document that, however there should *not* 
be any special considerations anywhere in the protocol or overall design 
to deal with that.

If people agree, then we should update the requirements, architecture 
and use case document(s) accordingly.

I'll add myself to the list of people in favor of this approach and ask 
for people to chime in with their opinion so we can proceed accordingly.

Thanks

-- Flemming

On 5/11/16 10:01 PM, Xialiang (Frank) wrote:
> Hi Roland and Andrew,
> Thanks for clarification and consideration.
>
> B.R.
> Frank
>
> -----邮件原件-----
> 发件人: Dots [mailto:[email-masked]] 代表 Roland Dobbins
> 发送时间: 2016年5月11日 20:32
> 收件人: [email-masked]
> 主题: Re: [Dots] Hi, some comments to DOTS requirements draft:
>
> On 11 May 2016, at 19:26, Mortensen, Andrew wrote:
>
>> Relayed signaling would remain a concept, but would look more or less
>> like what's currently called Recursive signaling in the architecture
>> draft.
> Essentially, a server and client grafted back-to-back.  So, we'll have a relay function, but it won't be a distinct node type for crypto/auth purposes.
>
> I believe that's what Frank was alluding to - that we need to spell this out.
> -----------------------------------
> Roland Dobbins <[email-masked]>
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Teague, Nik" <[email-masked]>
Date: Fri, 10 Jun 2016 17:18:35 +0000

>for people to chime in with their opinion so we can proceed accordingly.

+1 to remove the relay as a ‘thing’ and favour back to back client/server pairs

Thanks,

-Nik

---

From: Andrew Mortensen <[email-masked]>
Date: Fri, 10 Jun 2016 14:04:05 -0400

> On Jun 10, 2016, at 1:18 PM, Teague, Nik <[email-masked]> wrote:
> 

+1

andrew

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 11 Jun 2016 08:48:17 +0700

+1 - but we need to explain this in all the relevant documents, and it 
needs to be explicitly called out as a necessary mode of operation, not 
implicitly.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 11 Jun 2016 02:49:23 +0000

> -----Original Message-----
> From: Dots [mailto:[email-masked]] On Behalf Of Roland Dobbins
> Sent: Saturday, June 11, 2016 7:18 AM
> To: dots
> Subject: Re: [Dots] Deprecate DOTS Relay and limit scope to 1-hop (DOTS
> Client - Server) Re: 答复: Hi, some comments to DOTS requirements draft:
> 

Agreed. 

-Tiru

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Sun, 12 Jun 2016 01:00:51 +0000

-----邮件原件-----
发件人: Teague, Nik [mailto:[email-masked]] 
发送时间: 2016年6月11日 1:19
收件人: Flemming Andreasen; Xialiang (Frank); Roland Dobbins; Andrew Mortensen; [email-masked]
主题: Re: [Dots] Deprecate DOTS Relay and limit scope to 1-hop (DOTS Client - Server) Re: 答复: Hi, some comments to DOTS requirements draft:

>for people to chime in with their opinion so we can proceed accordingly.

+1 to remove the relay as a ‘thing’ and favour back to back 
+client/server pairs

Thanks,

-Nik

Agree!

B.R.
Frank

---

From: kaname nishizuka <[email-masked]>
Date: Mon, 13 Jun 2016 10:45:07 +0900

>> needs to be explicitly called out as a necessary mode of operation, not

+1 - and agreed.

kaname nishizuka

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 15 Jun 2016 04:17:50 +0000

In place of DOTS relay, we should discuss introducing B2BDA (Back-to-back DOTS Agent) to support the following scenarios.

1)With the recent increase in targeted DDOS attacks, any type of device (IOT devices, Mobile Device etc.) can be subjected to DDOS attacks. 
If these type of devices can act as DOTS clients in an Enterprise network and detect DDOS attack then these devices need a mechanism to talk to the DOTS server via a B2BDA in the Enterprise network for the reason discussed below. 

DOTS client and DOTS server must perform mutual authentication, it's easy for the DOTS client to authenticate the DOTS server but not the other way around.  However, B2BDA in the same administrative domain can easily authenticate the DOTS clients.

2)B2BDA may validate if the DOTS client is not misbehaving (e.g. an IOT device must only ask for DDOS mitigation for traffic coming to the IOT device and not request mitigation for  others devices in the network).  

3)With multi-homing, multiple B2BDA must be advertised to the client. DOTS client must also send separate DOTS signals and select the B2BDA address based on the IP address being attacked. This solves the problem that B2BDA has to only forward the request from the DOTS client based on the source IP address of the DOTS client. The proposed mechanism avoids the complexity of forking.

4)If DOTS clients and B2BDA (DDOS detector acting as both B2BDA and DOTS client) both detect DDOS then B2BDA can respond to the DOTS client based on the response it receives from the DOTS server and does not have to forward the DOTS signal from the DOTS client to the DOTS server.

-Tiru

> From: Dots [mailto:[email-masked]] On Behalf Of Flemming
> Andreasen (fandreas)
> Sent: Friday, June 10, 2016 10:46 PM
> To: Xialiang (Frank); Roland Dobbins; Andrew Mortensen; [email-masked]
> Subject: [Dots] Deprecate DOTS Relay and limit scope to 1-hop (DOTS Client -
> Server) Re: 答复: Hi, some comments to DOTS requirements draft:
> 
> answers for. Based on that and given an apparent lack of a compelling need
> for DOTS relays, it was suggested that we remove DOTS relays from the
> overall DOTS architecture and effectively limit the requirements, architecture
> and protocol scope to a single hop (DOTS client - DOTS server). As noted
> below, that doesn't mean you cannot have more than one hop in practice by
> leveraging recursive signaling and a Back-2-Back DOTS Agent, and we should
> in fact document that, however there should *not* be any special
> considerations anywhere in the protocol or overall design to deal with that.
> 
> If people agree, then we should update the requirements, architecture and
> use case document(s) accordingly.
> 
> I'll add myself to the list of people in favor of this approach and ask for
> people to chime in with their opinion so we can proceed accordingly.
> 
> Thanks
> 
> -- Flemming
> 
> 
> > Essentially, a server and client grafted back-to-back.  So, we'll have a relay
> function, but it won't be a distinct node type for crypto/auth purposes.
> >

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 15 Jun 2016 14:09:13 +0700

On 15 Jun 2016, at 11:17, Tirumaleswar Reddy (tireddy) wrote:

> In place of DOTS relay, we should discuss introducing B2BDA 
> (Back-to-back DOTS Agent) to support the following scenarios.

Well, most people are familiar with the term 'relay'.

So, if we describe a DOTS relay in the terms you mention, that works, 
yes?

> it's easy for the DOTS client to authenticate the DOTS server but not 
> the other way around.

Are we sure that's the case?  That would be problematic, would it not?

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 15 Jun 2016 12:05:16 +0000

Hi Tiru,
My comments are inline:

-----邮件原件-----
发件人: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
发送时间: 2016年6月15日 12:18
收件人: Flemming Andreasen (fandreas); Xialiang (Frank); Roland Dobbins; Andrew Mortensen; [email-masked]
主题: RE: [Dots] Deprecate DOTS Relay and limit scope to 1-hop (DOTS Client - Server) Re: 答复: Hi, some comments to DOTS requirements draft:

2)B2BDA may validate if the DOTS client is not misbehaving (e.g. an IOT device must only ask for DDOS mitigation for traffic coming to the IOT device and not request mitigation for  others devices in the network).  
[Frank]: Since the DOTS server can do it, why do we need B2BDA?

3)With multi-homing, multiple B2BDA must be advertised to the client. DOTS client must also send separate DOTS signals and select the B2BDA address based on the IP address being attacked. This solves the problem that B2BDA has to only forward the request from the DOTS client based on the source IP address of the DOTS client. The proposed mechanism avoids the complexity of forking.
[Frank]: The DOTS server seems to support it too.

-Tiru

> As we have seen in a couple of drafts and accompanying discussions, 
> DOTS relays introduce a fair amount of complexity and multi-level 
> server). As noted below, that doesn't mean you cannot have more than 
> one hop in practice by leveraging recursive signaling and a 
> Back-2-Back DOTS Agent, and we should in fact document that, however 
> there should *not* be any special considerations anywhere in the protocol or overall design to deal with that.
> 
> I'll add myself to the list of people in favor of this approach and 
> ask for people to chime in with their opinion so we can proceed accordingly.
> 
> Thanks
> 
> -- Flemming
> 
> 
> >> Relayed signaling would remain a concept, but would look more or 
> >> less like what's currently called Recursive signaling in the 
> >> architecture draft.

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 15 Jun 2016 09:10:37 -0400

> So, if we describe a DOTS relay in the terms you mention, that works, 
At the end of the day, it's just a name, but I don't think relay is a 
good choice here for at least two reasons:
1) We have previously definied it to mean something different than what 
is referred to as B2BDA
2) The relay concept is well-known in other protocols (e.g. DIAMETER and 
DHCP) where they serve a forwarding/routing role rather than full-stack 
termination and re-origination with the possibility of completely 
changing everything (in theory).

Now, whether we then want to call it B2BDA or something else (besides 
relay) is not important to me.

> Are we sure that's the case?  That would be problematic, would it not?
Yeah - not sure I see that either, but then again, I'm not sure that's 
really what Tiru's e-mail was calling out (and that's also why I"m not 
really not fond of selective quoting of the original e-mails). If we 
look at the problem Tiru described in his e-mail, then it's how to do 
mutual client-server authentication in the presence of an intermediary 
when you potentially have a lot of clients. For sure there is an 
administrative/operational complexity aspect here, which is what I 
believe Tiru was pointing out.

Thanks

-- Flemming

> .

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 15 Jun 2016 09:27:03 -0400

I tend to agree with this. Taking a step back, I think there are various 
motivations for having this intermediary thingie (whether we call it a 
relay, B2BDA, or something else), and several of these are called out in 
the current architecture draft. We have already discussed the mutual 
authentication/authorization considerations, but other motivations 
include aggregation, transport protocol conversion, recursive signaling, 
etc.

The point with changing from we have so-far called a relay (with limited 
functionality) to a full-fledged client/server thingie (B2BDA in this 
thread) is that
1) We are not trying to limit and/or standardize the kinds of things 
this entity can do
2) We want to avoid complicating the DOTS protocol by introducing 
protocol mechanism to deal with some of the issues introduced by an 
intermediary.

The implication of the above is that we forgo certain end-to-end 
features, but that's a conscious trade-off between complexity and 
functionality that we believe is right for the initial DOTS protocol.

Thanks

-- Flemming

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 15 Jun 2016 22:57:19 +0700

+1

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 16 Jun 2016 00:54:53 +0000

Hi Flemming,
I support the idea of " a full-fledged client/server thingie (B2BDA in thisthread)". It's the current trade-off.
Thanks!

B.R.
Frank

-----邮件原件-----
发件人: Flemming Andreasen [mailto:[email-masked]] 
发送时间: 2016年6月15日 21:27
收件人: Xialiang (Frank); Tirumaleswar Reddy (tireddy); Roland Dobbins; Andrew Mortensen; [email-masked]
主题: Re: 答复: [Dots] Deprecate DOTS Relay and limit scope to 1-hop (DOTS Client - Server) Re: 答复: Hi, some comments to DOTS requirements draft:

I tend to agree with this. Taking a step back, I think there are various motivations for having this intermediary thingie (whether we call it a relay, B2BDA, or something else), and several of these are called out in the current architecture draft. We have already discussed the mutual authentication/authorization considerations, but other motivations include aggregation, transport protocol conversion, recursive signaling, etc.

The point with changing from we have so-far called a relay (with limited
functionality) to a full-fledged client/server thingie (B2BDA in this
thread) is that
1) We are not trying to limit and/or standardize the kinds of things this entity can do
2) We want to avoid complicating the DOTS protocol by introducing protocol mechanism to deal with some of the issues introduced by an intermediary.

The implication of the above is that we forgo certain end-to-end features, but that's a conscious trade-off between complexity and functionality that we believe is right for the initial DOTS protocol.

Thanks

-- Flemming

On 6/15/16 8:05 AM, Xialiang (Frank) wrote:
>> authentication/authorization issues that we currently do not have 
>> good answers for. Based on that and given an apparent lack of a 
>> compelling need for DOTS relays, it was suggested that we remove DOTS 
>> relays from the overall DOTS architecture and effectively limit the 
>> requirements, architecture and protocol scope to a single hop (DOTS 
>> client - DOTS server). As noted below, that doesn't mean you cannot 
>> have more than one hop in practice by leveraging recursive signaling 
>> and a Back-2-Back DOTS Agent, and we should in fact document that, 
>> however there should *not* be any special considerations anywhere in the protocol or overall design to deal with that.
>>

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 16 Jun 2016 09:05:45 +0700

On 16 Jun 2016, at 7:54, Xialiang (Frank) wrote:

> B2BDA

This is not a well-known, commonly-understood acronym, AFAICT.

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 15 Jun 2016 23:08:27 -0400

> This is not a well-known, commonly-understood acronym, AFAICT.
Quite possible and I'm entirely open to a different name.

Btw, the notion of "back-to-back" comes from SIP where you have proxies 
and Back-to-Back User Agents (B2BUA).

Cheers

-- Flemming

---

From: <[email-masked]>
Date: Thu, 16 Jun 2016 06:46:52 +0000

Hi Roland, all,

The B2BDA acronym is not needed to be defined as a new functional entity as a far as the definition of relay (that is used in various documents) makes it clear, e.g.,:

"The DOTS relay is a back-to-back DOTS server and client."

Cheers,
Med 

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Roland Dobbins
> Envoyé : jeudi 16 juin 2016 04:06
> À : [email-masked]
> Objet : Re: [Dots] Deprecate DOTS Relay and limit scope to 1-hop (DOTS

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 17 Jun 2016 11:42:27 +0700

> Quite possible and I'm entirely open to a different name.

'Relay' or 'proxy' would probably be more widely understood.

---

From: "Roland Dobbins" <[email-masked]>
Date: Fri, 17 Jun 2016 11:43:29 +0700

> "The DOTS relay is a back-to-back DOTS server and client."

Right - so let's use 'relay' or 'proxy', something that a) communicates 
the functionality of this configuration mode and b) is a term in general 
use.

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 17 Jun 2016 10:39:31 -0400

> 'Relay' or 'proxy' would probably be more widely understood.
The reason I'm not really in favor of these is that they tend to be 
defined differently in other protocols. Proxies are generally visible at 
some level and have explicit protocol level support (e.g. witness HTTP 
and SIP) and relays are more geared towards message routing/forwarding 
functionality (like in DIAMETER and DHCP, and also the way had defined 
it in DOTS so far).

Do you know of any other protocols that define either relay or proxy the 
way we are trying to define this client/server thing ?

Thanks

-- Flemming

---

From: "Roland Dobbins" <[email-masked]>
Date: Sat, 18 Jun 2016 02:25:06 +0700

On 17 Jun 2016, at 21:39, Flemming Andreasen wrote:

> Do you know of any other protocols that define either relay or proxy 
> the way we are trying to define this client/server thing ?

I guess not . . . ALGs are commonly conflated with proxies, of course.  
Does what we're talking about

DOTS 'gateway'?

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 17 Jun 2016 15:45:29 -0400

Works for me.

-- Flemming

On 6/17/16 3:25 PM, Roland Dobbins wrote:
> I guess not . . . ALGs are commonly conflated with proxies, of 
> course.  Does what we're talking about
>
> DOTS 'gateway'?
>

---

From: <[email-masked]>
Date: Mon, 20 Jun 2016 05:35:54 +0000

Dear Flemming, 

Please see inline.

Cheers,
Med

> De : Dots [mailto:[email-masked]] De la part de Flemming Andreasen
> Envoyé : vendredi 17 juin 2016 16:40
> À : Roland Dobbins; [email-masked]

 [Med] https://tools.ietf.org/html/rfc7648 

"the
   PCP proxy is logically equivalent to a PCP client back-to-back with a
   PCP server."

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 20 Jun 2016 13:25:56 -0400

Thanks Med

-- Flemming