Subject: [Dots] Adoption call for draft-reddy-dots-home-network-04

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 8 Apr 2019 18:28:45 +0300

Hi all,

the chairs recently received an adoption request for draft-reddy-dots-home-network-04.

This message starts a two-week adoption call for draft-reddy-dots-home-network-04.
The call ends up on Tuesday, April the 23rd.

Please send your opinion regarding adoption of this document to the list before this date.
If you think the draft should be adopted, please indicate whether you're willing 
to review it/to work on it. If you think the draft should not be adopted, please explain why.

Regards,
Frank & Valery.

---

From: "Teague, Nik" <[email-masked]>
Date: Mon, 8 Apr 2019 15:32:20 +0000

Hi,

I support adoption of this draft.

Thanks,

-Nik

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of Valery Smyslov
> Sent: Monday, April 08, 2019 4:29 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [EXTERNAL] [Dots] Adoption call for draft-reddy-dots-home-network-
> 04
> 
> Hi all,
> 
> If you think the draft should be adopted, please indicate whether you're
> willing to review it/to work on it. If you think the draft should not be
> adopted, please explain why.
> 
> Regards,
> Frank & Valery.
> 
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 8 Apr 2019 16:50:57 +0100

Hi,

As an author, I obviously support the adoption of this draft

Regards

Jon

> From: Dots [mailto:[email-masked]] On Behalf Of Valery
> Smyslov
> Sent: 08 April 2019 16:29
> To: [email-masked]
> Subject: [Dots] Adoption call for draft-reddy-dots-home-network-04
> 
> Hi all,
> 
> the chairs recently received an adoption request for
draft-reddy-dots-home-
> network-04.
> willing

---

From: 林 裕平 <[email-masked]>
Date: Tue, 09 Apr 2019 09:19:38 +0900

Hi,

Thanks,

Yuhei

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Valery Smyslov
Sent: Tuesday, April 09, 2019 12:29 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Dots] Adoption call for draft-reddy-dots-home-network-04

Hi all,

Regards,
Frank & Valery.

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 9 Apr 2019 17:08:49 +0000

-prashanth

On 4/8/19, 8:28 AM, "Dots on behalf of Valery Smyslov" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Regards,
Frank & Valery.

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

---

From: Andrew Mortensen <[email-masked]>
Date: Wed, 10 Apr 2019 10:34:56 -0400

> On Apr 8, 2019, at 11:28 AM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi all,
>

---

From: "Panwei (William)" <[email-masked]>
Date: Mon, 15 Apr 2019 03:06:29 +0000

Hi,

Best Regards
Wei Pan

-----Original Message-----
From: Dots [mailto:[email-masked]] On Behalf Of Valery Smyslov
Sent: Monday, April 08, 2019 11:29 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Dots] Adoption call for draft-reddy-dots-home-network-04

Hi all,

Please send your opinion regarding adoption of this document to the list before this date.
If you think the draft should be adopted, please indicate whether you're willing to review it/to work on it. If you think the draft should not be adopted, please explain why.

Regards,
Frank & Valery.

---

From: Daniel Migault <[email-masked]>
Date: Mon, 15 Apr 2019 12:04:07 -0400

I support the adoption of the draft, please see my comments on the current
version. None of them should be considered as preventing the adoption.

Yours,
Daniel

Some random comments:

Section 1:

"""
   Some of the DDoS attacks like spoofed RST or FIN packets, Slowloris,
   and TLS re-negotiation are difficult to detect on the home network
   devices without adversely affecting its performance.  The reason is
   typically home routers have fast path to boost the throughput.  For
   every new TCP/UDP flow, only the first few packets are punted through
   the slow path.  Hence, it is not possible to detect various DDoS
   attacks in the slow path, since the attack payload is sent to the
   target server after the flow is switched to fast path.  Deep packet
   inspection (DPI) of all the packets of a flow would be able to detect
   some of the attacks.  However, a full-fledged DPI to detect these
   type of DDoS attacks is functionally or operationally not possible
   for all the devices attached to the home network owing to the memory
   and CPU limitations of the home routers.  Further, for certain DDoS
   attacks the ability to distinguish legitimate traffic from attacker
   traffic on a per packet basis is complex.  This complexity originates
   from the fact that the packet itself may look "legitimate" and no
   attack signature can be identified.  The anomaly can be identified
   only after detailed statistical analysis.
"""

I understand, the paragraph below as saying that detection at the ISP is
easier than at the homenet level as the ISP aggregates the traffic. This
is correct and I agree with the text. However, if we are going a bit
further, the detection is even easier to the DDoS target. I believe that
the same mechanism could be deployed between a DDoS target, its Cloud
provider major ISPs up to the origin. The example of the Homenet and the
ISP is only one bound but the mechanism can be generalized and actually
help coordination between independent domains.  I believe the draft can
be placed in a larger perspective.

Section 3.1 Procedure:

I am not convinced this is the right approach to switch the roles
between clients and servers. I believe that while the previous dots
signal-channel was foreseeing the relation as asymmetric, we are now
considering DOTS Client and DOTS Server as mostly symmetric. Maybe one
way to see this could be to have a DOTS communication between different
entities, and exchanges can be in both directions. The one initiating
the exchange could be designated as DOTS Initiator, while the receiving
side is the DOTS Responder.

Here is a more concrete example while Client / Server  might be
confusing. When  a server sends an alert when under attach it is designated
as the DOTS Client, while the same client specifying these IP addresses
are detected as belonging to an attacker will be the Server.

It seems also to me that establishment of the (D)TLS channel can be sent
by any other peer, not necessarily the peer sending further
notification/request. Typically the DOTS Client may have set the DOTS
channel protected by (D)TLS, and the DOTS Server may re-use that exact
same channel.

I am also wondering if the support of the extension is agreed or
announced. If so this would ease the negotiation of which peer is able
to handle the requests and be a "Server".

I believe the clarification and comparison with the
"traditional"/"initial" DOTS use cases is useful and needs to stay for
clarification purpose. However, one should make sure also that such
signalling can also be made with a signal dots signalling established in
the initial use cases. Typically, the DOTS client may have set the DOTS
channel and set a DTLS session which could carry the signalling of the
draft.

On Sun, Apr 14, 2019 at 11:06 PM Panwei (William) <[email-masked]>
wrote:

> draft-reddy-dots-home-network-04.
>

---

From: Dan Wing <[email-masked]>
Date: Mon, 15 Apr 2019 11:04:59 -0700

I support adoption of draft-reddy-dots-home-network.

-d

> On Apr 8, 2019, at 8:28 AM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi all,
>

---

From: "MeiLing Chen" <[email-masked]>
Date: Wed, 17 Apr 2019 17:22:15 +0800

Hi,
I have a question, does the call home in draft-reddy-dots-home-network-04 consistent with the "call home" in RFC8071?

best regards.
--------------------------------------------------------------------------------------
Research institute of China mobile communications co. LTD
Institute of safety technology
Email address: [email-masked]
Phone: 13810149515
Telephone: 15801696688-34283
Address: no. 32, xuanwumen west street, xicheng district, Beijing (mobile innovation building)
 
From: Valery Smyslov
Date: 2019-04-08 23:28
To: [email-masked]
CC: dots-chairs; kaduk

 
 
Regards,
Frank & Valery.

---

From: <[email-masked]>
Date: Wed, 17 Apr 2019 09:44:16 +0000

Hi Meiling,

Both draft-reddy-dots-home-network and RFC807 adopt the same approach for managing roles and connections.

That’s said, RFC8071 would be appropriate if a call home functionality was needed for the data channel.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de MeiLing Chen
Envoyé : mercredi 17 avril 2019 11:22
À : Valery Smyslov; dots
Cc : dots-chairs; kaduk
Objet : Re: [Dots] Adoption call for draft-reddy-dots-home-network-04

Hi,

best regards.

Phone: 13810149515

From: Valery Smyslov<mailto:[email-masked]>
Date: 2019-04-08 23:28
To: [email-masked]<mailto:[email-masked]>
CC: dots-chairs<mailto:[email-masked]>; kaduk<mailto:[email-masked]>
Subject: [Dots] Adoption call for draft-reddy-dots-home-network-04
Hi all,

Regards,
Frank & Valery.

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 18 Apr 2019 09:48:48 +0900

I support adoption of this draft.
And +1 to this Daniel's comment.

 > the mechanism can be generalized and actually

thanks,
Kaname Nishizuka

On 2019/04/16 1:04, Daniel Migault wrote:
> I support the adoption of the draft, please see my comments on the current version. None of them should be considered as preventing the adoption.
>
> Yours,
> Daniel
>
> Some random comments:
>
>
> Section 1:
>
> """
> On Sun, Apr 14, 2019 at 11:06 PM Panwei (William) <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     From: Dots [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Valery Smyslov
>     To: [email-masked] <mailto:[email-masked]>
>     Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 18 Apr 2019 12:52:02 +0000

Hi Daniel,

Thanks for the review, Please see inline [TR]

From: Dots <[email-masked]> On Behalf Of Daniel Migault
Sent: Monday, April 15, 2019 9:34 PM
To: Panwei (William) <[email-masked]>
Cc: [email-masked]; Valery Smyslov <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Dots] Adoption call for draft-reddy-dots-home-network-04

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
I support the adoption of the draft, please see my comments on the current version. None of them should be considered as preventing the adoption.

Yours,
Daniel

Some random comments:

Section 1:

"""

[TR] Agreed, it is relatively easy for the DDoS mitigation provider for the attack target to detect sophisticated DDoS attacks (especially if the attack uses encrypted traffic).

I will add the following lines:

BGP defines a mechanism as described in [RFC5575] that can be used to
automate inter-domain coordination of traffic filtering, such as what
is required in order to mitigate DDoS attacks. DDoS mitigation provider
for the attack target can detect sophisticated DDoS attacks
using encrypted attack traffic, and can possibly use BGP flowspec [RFC5575] to
  convey the filtering rules to filter block, or rate-limit DDoS attack traffic originating
  from the ISP's subscribers to the attack target.

Section 3.1 Procedure:

[TR] Both draft-reddy-dots-home-network and RFC8071 adopt the same approach for managing roles and connections. You may want to look into RFC8071.
        CoAP allows asynchronous messages but the request is always sent by the CoAP client.

[TR] I don’t get the above comment.

Cheers,
-Tiru

On Sun, Apr 14, 2019 at 11:06 PM Panwei (William) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Best Regards
Wei Pan

-----Original Message-----
From: Dots [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Valery Smyslov
Sent: Monday, April 08, 2019 11:29 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Dots] Adoption call for draft-reddy-dots-home-network-04

Hi all,

Regards,
Frank & Valery.

---

From: <[email-masked]>
Date: Thu, 18 Apr 2019 13:12:56 +0000

Hi Tiru, Daniel,

With regards to:

“ I believe that
the same mechanism could be deployed between a DDoS target, its Cloud
provider major ISPs up to the origin.”

This is not currently doable with DOTS. Some key functional components are needed:
(1) To identify the appropriate ISP which is hosting a DDoS source once a DDoS target has detected/reported an attack to its DOTS server/provider. The target may not be on the same network as the source.
(2) That ISP needs to expose a service to receive these notifications.

Of course, if the ISP is capable of receiving these notifications, it can invoke the procedure in draft-reddy-dots-home-network.

The scenario mentioned by Daniel is an interesting problem to address…but I’m afraid this is out of scope of the current DOTS charter.

I don’t see how BGP Flowspec solves this.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Konda, Tirumaleswar Reddy
Envoyé : jeudi 18 avril 2019 14:52
À : Daniel Migault; Panwei (William)
Cc : [email-masked]; Valery Smyslov; [email-masked]; [email-masked]
Objet : Re: [Dots] Adoption call for draft-reddy-dots-home-network-04

Hi Daniel,

Yours,
Daniel

Some random comments:

Section 1:

"""

Section 3.1 Procedure:

Cheers,
-Tiru

Best Regards
Wei Pan

-----Original Message-----
From: Dots [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Valery Smyslov
Sent: Monday, April 08, 2019 11:29 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Dots] Adoption call for draft-reddy-dots-home-network-04

Hi all,

Regards,
Frank & Valery.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 18 Apr 2019 13:59:08 +0000

From: [email-masked] <[email-masked]>
Sent: Thursday, April 18, 2019 6:43 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Daniel Migault <[email-masked]>
Cc: [email-masked]; Valery Smyslov <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Dots] Adoption call for draft-reddy-dots-home-network-04

With regards to:

“ I believe that

[TR] Agree with your response

[TR], BGP Flowspec allows the ISP to receive the filtering rules from the mitigation provider (downstream ISP) for the attack target, do you see a problem with my proposed text ?

-Tiru

Cheers,
Med

Cc : [email-masked]<mailto:[email-masked]>; Valery Smyslov; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Daniel,

From: Dots <[email-masked]<mailto:[email-masked]>> On Behalf Of Daniel Migault
Sent: Monday, April 15, 2019 9:34 PM
To: Panwei (William) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Valery Smyslov <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Adoption call for draft-reddy-dots-home-network-04

Yours,
Daniel

Some random comments:

Section 1:

"""

Section 3.1 Procedure:

Cheers,
-Tiru

Best Regards
Wei Pan

-----Original Message-----
From: Dots [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Valery Smyslov
Sent: Monday, April 08, 2019 11:29 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Dots] Adoption call for draft-reddy-dots-home-network-04

Hi all,

Regards,
Frank & Valery.

---

From: <[email-masked]>
Date: Thu, 18 Apr 2019 14:33:12 +0000

Re-,

Please see inline.

Cheers,
Med

De : Konda, Tirumaleswar Reddy [mailto:[email-masked]]
Envoyé : jeudi 18 avril 2019 15:59
À : BOUCADAIR Mohamed TGI/OLN; Daniel Migault
Cc : [email-masked]; Valery Smyslov; [email-masked]; [email-masked]
Objet : RE: [Dots] Adoption call for draft-reddy-dots-home-network-04

With regards to:

“ I believe that

[TR], BGP Flowspec allows the ISP to receive the filtering rules from the mitigation provider (downstream ISP) for the attack target, do you see a problem with my proposed text ?
[Med] The attack target is not necessarily attached to the downstream ISP. Multi-hop ASes may be between the AS hosting the target and the one connecting the attack source.

-Tiru

Cheers,
Med

Hi Daniel,

Yours,
Daniel

Some random comments:

Section 1:

"""

Section 3.1 Procedure:

Cheers,
-Tiru

Best Regards
Wei Pan

-----Original Message-----
From: Dots [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Valery Smyslov
Sent: Monday, April 08, 2019 11:29 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Dots] Adoption call for draft-reddy-dots-home-network-04

Hi all,

Regards,
Frank & Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 24 Apr 2019 08:01:40 +0300

Hi,

we received a lot of replies supporting adoption of the document.
So, the document is adopted. Authors, please re-submit it as WG draft.

A couple of comments.
1. The draft uses few times a keyword "MAY NOT". This combination is not
     among the list of RFC requirement keywords (it is not listed neither
     in RFC2119, nor in RFC8174). If the intent was to use RFC requirement
     language, then I'd suggest replacing it with one of MUST NOT, SHALL
NOT,
     SHOULD NOT. Otherwise please make it lowcase.

2. When describing transport, the draft allows both TLS and DTLS. What
     makes me confusing is that the draft describes it several times as
"TCP/TLS or DTLS".
     Why TCP is ever mentioned here? We all know that TLS usually runs over 
     TCP (however we now have QUICK) and DTLS runs over UDP. 
     The way it is presented in the draft makes me think that probably 
     plain TCP is also allowed as a transport, but is seems to contradict 
     everything I read about DOTS. Am I missing something here?

Regards,
Valery.

draft-reddy-dots-home-
willing
> to review it/to work on it. If you think the draft should not be adopted,
please
> explain why.

---

From: <[email-masked]>
Date: Wed, 24 Apr 2019 05:55:58 +0000

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de Valery Smyslov
> Envoyé : mercredi 24 avril 2019 07:02
> À : [email-masked]
> Cc : [email-masked]; [email-masked]

[Med] Good catch. Fixed. 

>      everything I read about DOTS. Am I missing something here?

[Med] Plain TCP is not allowed. The intent was to be explicit that there is a reversal in both TCP and TLS layers, but as you rightfully raised this may be confusing since, for the DOTS case, it is trivial that the reversal of TLS roles implies the reversal of TCP ones. The use of TCP/TLS is OK but may be confusing. I changed TCP/TLS to TLS.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 24 Apr 2019 06:12:40 +0000

> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Wednesday, April 24, 2019 11:26 AM
> To: Valery Smyslov <[email-masked]>; [email-masked]
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > Envoyé : mercredi 24 avril 2019 07:02 À : [email-masked] Cc :
> > [email-masked]; [email-masked] Objet : Re: [Dots] Adoption call
> > for draft-reddy-dots-home-network-04
> >
> > Hi,
> >
> >      language, then I'd suggest replacing it with one of MUST NOT,
> > SHALL NOT,
> >      makes me confusing is that the draft describes it several times
> > as "TCP/TLS or DTLS".
> [Med] Plain TCP is not allowed. The intent was to be explicit that there is a
> reversal in both TCP and TLS layers, but as you rightfully raised this may be
> confusing since, for the DOTS case, it is trivial that the reversal of TLS roles
> implies the reversal of TCP ones. 

RESTCONF call home only reverses the TCP role but not the TLS role. In DOTS case, the server has to initiate DTLS handshake for UDP. To keep the roles same for TCP,  TLS handshake is also initiated by the server.

> The use of TCP/TLS is OK but may be
> confusing. I changed TCP/TLS to TLS.

Role reversal at TLS does not mean necessarily mean role reversal at TCP.

-Tiru

> > > This message starts a two-week adoption call for
> > > draft-reddy-dots-home- network-04.

---

From: <[email-masked]>
Date: Wed, 24 Apr 2019 06:47:34 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 24 avril 2019 08:13
> À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; [email-masked]
> RESTCONF call home only reverses the TCP role but not the TLS role. In DOTS
> case, the server has to initiate DTLS handshake for UDP. To keep the roles
> same for TCP,  TLS handshake is also initiated by the server.

[Med] You missed "for the DOTS case" in my previous reply :-)

We do have the following in the draft:

                   DOTS                                DOTS
                  Server                              Client
                    |                                    |
                    |         1. (D)TLS connection       |
                    |----------------------------------->|
                    |         2. Mitigation request      |
                    |<-----------------------------------|
                    |                                    |

That can be trivially expanded as follows for the TLS case:

                   DOTS                                DOTS
                  Server                              Client
                    |                                    |
                    |         1.1. TCP                   |
                    |----------------------------------->|
                    |         1.2. TLS                   |
                    |----------------------------------->|
                    |         2. Mitigation request      |
                    |<-----------------------------------|
                    |                                    |

As mentioned earlier, the use of TCP/TLS is OK but it may be confusing as initially raised by Valery.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 24 Apr 2019 11:01:01 +0000

> Sent: Wednesday, April 24, 2019 12:18 PM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>; Valery Smyslov
> <[email-masked]>; [email-masked]
> > De : Konda, Tirumaleswar Reddy
> > [mailto:[email-masked]]
> > À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; [email-masked] Cc :
> > [email-masked]; [email-masked] Objet : RE: [Dots] Adoption call
> > > This email originated from outside of the organization. Do not click
> > > links
> > or
> > > open attachments unless you recognize the sender and know the
> > > content is safe.
> > >
> > > Re-,
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > De : Dots [mailto:[email-masked]] De la part de Valery
> > > > Smyslov Envoyé : mercredi 24 avril 2019 07:02 À : [email-masked] Cc :
> > > > [email-masked]; [email-masked] Objet : Re: [Dots] Adoption
> > > > call for draft-reddy-dots-home-network-04
> > > >
> > > > Hi,
> > > >
> > > >      makes me confusing is that the draft describes it several
> > > > times as "TCP/TLS or DTLS".
> > > >      Why TCP is ever mentioned here? We all know that TLS usually
> > > > runs
> > over
> > > [Med] Plain TCP is not allowed. The intent was to be explicit that
> > > there is
> > a
> > > reversal in both TCP and TLS layers, but as you rightfully raised
> > > this may
> > be
> > > confusing since, for the DOTS case, it is trivial that the reversal
> > > of TLS
> > roles
> > RESTCONF call home only reverses the TCP role but not the TLS role. In
> > DOTS case, the server has to initiate DTLS handshake for UDP. To keep
> > the roles same for TCP,  TLS handshake is also initiated by the server.
> 

Okay.

> initially raised by Valery.

The updated text is not accurate if TCP is not covered, role reversal at TLS does not mean role reversal at TCP. 
Similar to (D)TLS, I prefer explicit text to say role reversal at TCP. The security considerations section says " DOTS agents MUST authenticate each other using (D)TLS before a DOTS
signal channel session is considered valid.", so clear text DOTS traffic is ruled out.

Cheers,
-Tiru

---

From: <[email-masked]>
Date: Wed, 24 Apr 2019 11:18:23 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 24 avril 2019 13:01

[Med] The updated text is still fine (ref to Figure 1). We don't have any ambiguity in the procedure part with regards to TCP. We explicitly say the following:  

       If TCP is used, the DOTS server begins by initiating a TCP
       connection to the DOTS client.  The DOTS client MUST support
       accepting TCP connections on the IANA-assigned port number
       defined in Section 4.1, but MAY be configured to listen to a
       different port number.  Using this TCP connection, the DOTS
       server initiates a TLS connection to the DOTS client.

> Similar to (D)TLS, I prefer explicit text to say role reversal at TCP.

[Med] We already have such text (see the above excerpt). 

 The
> security considerations section says " DOTS agents MUST authenticate each
> other using (D)TLS before a DOTS

[Med] Fully agree.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 24 Apr 2019 12:55:30 +0000

> Sent: Wednesday, April 24, 2019 4:48 PM
> > > > Envoyé : mercredi 24 avril 2019 08:13 À : BOUCADAIR Mohamed
> > > > TGI/OLN; Valery Smyslov; [email-masked] Cc :
> > > > [email-masked]; [email-masked] Objet : RE: [Dots] Adoption
> > > > > This email originated from outside of the organization. Do not
> > > > > click links
> > > > or
> > > > > > [email-masked]; [email-masked] Objet : Re: [Dots]
> > > > > > Adoption call for draft-reddy-dots-home-network-04
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > So, the document is adopted. Authors, please re-submit it as
> > > > > > WG
> > draft.
> > > > > >
> > > > > > A couple of comments.
> > > > > > 1. The draft uses few times a keyword "MAY NOT". This
> > > > > > combination is
> > > not
> > > > > >      among the list of RFC requirement keywords (it is not
> > > > > > listed
> > neither
> > > > > >      language, then I'd suggest replacing it with one of MUST
> > > > > > NOT, SHALL NOT,
> > > > > >      Why TCP is ever mentioned here? We all know that TLS
> > > > > > usually runs
> > > > over
> > > > > [Med] Plain TCP is not allowed. The intent was to be explicit
> > > > > that there is
> > > > a
> > > > > reversal in both TCP and TLS layers, but as you rightfully
> > > > > raised this may
> > > > be
> > > > > confusing since, for the DOTS case, it is trivial that the
> > > > > reversal of TLS
> > > > roles
> > > > RESTCONF call home only reverses the TCP role but not the TLS
> > > > role. In DOTS case, the server has to initiate DTLS handshake for
> > > > UDP. To keep the roles same for TCP,  TLS handshake is also initiated by
> the server.
> > >
> > The updated text is not accurate if TCP is not covered, role reversal
> > at TLS does not mean role reversal at TCP.
> 
> [Med] The updated text is still fine (ref to Figure 1). We don't have any
> ambiguity in the procedure part with regards to TCP. We explicitly say the
> following:
> 

[TR] Yes, but the updated sentences are incomplete/incorrect at various places. I have listed one of the inconsistencies below

   The one and only role reversal that
   occurs are at the TLS or DTLS layers; that is, the DOTS server acts
   as a DTLS client and the DOTS client acts as a DTLS server or the
   DOTS server acts as a TLS client and the DOTS client acts as a TLS
   server.  The DOTS server initiates TLS handshake or DTLS handshake to
   the DOTS client.

The above update means no role reversal at the TCP layer !

-Tiru

> 
>  The
> > security considerations section says " DOTS agents MUST authenticate
> > each other using (D)TLS before a DOTS signal channel session is
> > considered valid.", so clear text DOTS traffic is ruled out.
> 
> [Med] Fully agree.

---

From: <[email-masked]>
Date: Wed, 24 Apr 2019 13:11:43 +0000

Re-,

Please see inline. 

Cheers,
Med
> Envoyé : mercredi 24 avril 2019 14:56
> [TR] Yes, but the updated sentences are incomplete/incorrect at various
> places. I have listed one of the inconsistencies below
> 

[Med] This text assumes that the TCP is implicitly covered by "TLS layer" (refer again to Figure 1). There is no ambiguity that the reversal at the TLS layer for the DOTS case implies a reversal of the TCP roles, because otherwise the connection cannot be established at the first place (due to the presence of NATs/FWs) !

We can removed "one and only" if this really hurts, though.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 24 Apr 2019 13:25:42 +0000

> Sent: Wednesday, April 24, 2019 6:42 PM
> > > > Envoyé : mercredi 24 avril 2019 13:01 À : BOUCADAIR Mohamed
> > > > > > [email-masked]; [email-masked] Objet : RE: [Dots]
> > > > > > > This email originated from outside of the organization. Do
> > > > > > > not click links
> > > > > > or
> > > > > > > open attachments unless you recognize the sender and know
> > > > > > > the content is safe.
> > > > > > >
> > > > > > > Re-,
> > > > > > >
> > > > > > > Please see inline.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Med
> > > > > > >
> > > > > > > > -----Message d'origine----- De : Dots
> > > > > > > > [mailto:[email-masked]] De la part de Valery
> > > > > > > > Smyslov Envoyé : mercredi 24 avril 2019 07:02 À :
> > > > > > > > [email-masked]
> > Cc :
> > > > > > > > So, the document is adopted. Authors, please re-submit it
> > > > > > > > as WG
> > > > draft.
> > > > > > > >
> > > > > > > > A couple of comments.
> > > > > > > >      in RFC2119, nor in RFC8174). If the intent was to use
> > > > > > > > RFC
> > > > > > requirement
> > > > > > > >      language, then I'd suggest replacing it with one of
> > > > > > > > MUST NOT, SHALL NOT,
> > > > > > > >      makes me confusing is that the draft describes it
> > > > > > > > several times as "TCP/TLS or DTLS".
> > > > > > > >      The way it is presented in the draft makes me think
> > > > > > > > that
> > > > probably
> > > > > > > >      plain TCP is also allowed as a transport, but is
> > > > > > > > seems to
> > > > contradict
> > > > > > > [Med] Plain TCP is not allowed. The intent was to be
> > > > > > > explicit that there is
> > > > > > a
> > > > > > role. In DOTS case, the server has to initiate DTLS handshake
> > > > > > for UDP. To keep the roles same for TCP,  TLS handshake is
> > > > > > also initiated
> > by
> > > the server.
> > > > >
> > > > The updated text is not accurate if TCP is not covered, role
> > > > reversal at TLS does not mean role reversal at TCP.
> > >
> > > [Med] The updated text is still fine (ref to Figure 1). We don't
> > > have any ambiguity in the procedure part with regards to TCP. We
> > > explicitly say the
> > > following:
> > >
> > [TR] Yes, but the updated sentences are incomplete/incorrect at
> > various places. I have listed one of the inconsistencies below
> >
> [Med] This text assumes that the TCP is implicitly covered by "TLS layer"
> (refer again to Figure 1). There is no ambiguity that the reversal at the TLS
> layer for the DOTS case implies a reversal of the TCP roles, because
> otherwise the connection cannot be established at the first place (due to the
> presence of NATs/FWs) !

If NAT is not present, connection can be established. FW can be configured to permit TCP connections from external peer (e.g. port forwarding).

> We can removed "one and only" if this really hurts, though.

I propose the following additional change:

    The role reversal that
    occurs are at the TLS or DTLS layers; that is, the DOTS server acts
    as a DTLS client and the DOTS client acts as a DTLS server or the
   DOTS server acts as a TLS client initiating the underlying TCP connection and the DOTS client acts as a TLS
   server.  The DOTS server initiates TLS handshake or DTLS handshake to
   the DOTS client.

-Tiru

---

From: <[email-masked]>
Date: Thu, 25 Apr 2019 06:13:32 +0000

Hi Tiru,

Works for me. 

An updated version with a slightly updated wording is available at: 
https://github.com/boucadair/dots-call-home/blob/master/draft-ietf-dots-signal-call-home-00.txt 

Cheers,
Med

> Envoyé : mercredi 24 avril 2019 15:26
> > > > > > > > > 2. When describing transport, the draft allows both TLS and
> DTLS.
> > > > > What
> If NAT is not present, connection can be established. FW can be configured to
> permit TCP connections from external peer (e.g. port forwarding).
> 
> >

---

From: <[email-masked]>
Date: Thu, 25 Apr 2019 06:58:39 +0000

Hi Tiru, Daniel,

I’d like we conclude on this one.

Here is a NEW text proposal to capture what I think is the main comment from Daniel while avoiding to include considerations that are not currently supported by DOTS:

   A DOTS client relies upon a variety of triggers to invoke the Call
   Home function (e.g., scrubbing the traffic from the attack source,
   receiving an alert from an attack target, a peer DDoS Mitigation
   System (DMS), or a transit provider).  The definition of these
   triggers is deployment-specific.  It is therefore out of the scope of
   this document to elaborate on how these triggers are made available
   to a DOTS client.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de [email-masked]
Envoyé : jeudi 18 avril 2019 16:33
À : Konda, Tirumaleswar Reddy; Daniel Migault
Cc : [email-masked]; Valery Smyslov; [email-masked]; [email-masked]
Objet : Re: [Dots] Adoption call for draft-reddy-dots-home-network-04

Re-,

Please see inline.

Cheers,
Med

With regards to:

“ I believe that

-Tiru

Cheers,
Med

Hi Daniel,

Yours,
Daniel

Some random comments:

Section 1:

"""

Section 3.1 Procedure:

Cheers,
-Tiru

Best Regards
Wei Pan

-----Original Message-----
From: Dots [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Valery Smyslov
Sent: Monday, April 08, 2019 11:29 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Dots] Adoption call for draft-reddy-dots-home-network-04

Hi all,

Regards,
Frank & Valery.

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 25 Apr 2019 11:27:23 +0100

Hi Med / Tiru,

I am having a hard time working out how to implement this Call Home using libcoap.

The easiest way in my current thinking is that the role reversal should only be at the UDP or TCP layer and then (D)TLS is set up / initiated by the DOTS client to the DOTS server (and is how RFC8071 defines the setup of the security layer over TCP).

Otherwise, libcoap needs to be taught that (D)TLS set up is in the reverse direction to the CoAP transfers which would involve a significant re-write and a lot of clarity in the code (e.g. am I a server or a client at this point of working in the network stack?).

Just establishing a session 5 tuple in the reverse direction and then remembering this only for the UDP/TCP layer is a simple libcoap change.

So, I would like to see it as (as per RFC8071 Figure 1:)

                  DOTS                                   DOTS
                  Server                                 Client
                    |                                                 |
                    |         1.  TCP or UDP              |
                    |----------------------------------->|
                    |         2.  (D)TLS  set up          |
                    |<-----------------------------------|
                    |         3. Mitigation request   |
                    |<-----------------------------------|
                    |                                                 |

Regards

Jon
> From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
> Sent: 25 April 2019 07:14
> Cc: [email-masked]
> content is

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 25 Apr 2019 10:34:19 +0000

> Sent: Thursday, April 25, 2019 11:44 AM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: [email-masked]

Thanks, update looks good.

-Tiru

> > > > Envoyé : mercredi 24 avril 2019 14:56 À : BOUCADAIR Mohamed
> > > > > > > > -----Message d'origine----- De : Konda, Tirumaleswar Reddy
> > > > > > > > Envoyé : mercredi 24 avril 2019 08:13 À : BOUCADAIR
> > > > > > > > Mohamed TGI/OLN; Valery Smyslov; [email-masked] Cc :
> > > > > > > > > This email originated from outside of the organization.
> > > > > > > > > Do not click links
> > > > > > > > or
> > > > > > > > > open attachments unless you recognize the sender and
> > > > > > > > > know the content is safe.
> > > > > > > > >
> > > > > > > > > Re-,
> > > > > > > > >
> > > > > > > > > Please see inline.
> > > > > > > > >
> > > > > > > > > Cheers,
> > > > > > > > > Med
> > > > > > > > >
> > > > > > > > > > we received a lot of replies supporting adoption of
> > > > > > > > > > the
> > > document.
> > > > > > > > > > So, the document is adopted. Authors, please re-submit
> > > > > > > > > > it as WG
> > > > > > draft.
> > > > > > > > > >
> > > > > > > > > > A couple of comments.
> > > > > > > > > >      among the list of RFC requirement keywords (it is
> > > > > > > > > > not listed
> > > > > > neither
> > > > > > > > > >      in RFC2119, nor in RFC8174). If the intent was to
> > > > > > > > > > use RFC
> > > > > > > > requirement
> > > > > > > > > >      language, then I'd suggest replacing it with one
> > > > > > > > > > of MUST NOT, SHALL NOT,
> > > > > > > > > >      Why TCP is ever mentioned here? We all know that
> > > > > > > > > > TLS usually runs
> > > > > > > > over
> > > > > > > > > >      The way it is presented in the draft makes me
> > > > > > > > > > think that
> > > > > > probably
> > > > > > > > > >      everything I read about DOTS. Am I missing
> > > > > > > > > > something
> > here?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > reversal in both TCP and TLS layers, but as you
> > > > > > > > > rightfully raised this may
> > > > > > > > be
> > > > > > > > > confusing since, for the DOTS case, it is trivial that
> > > > > > > > > the reversal of TLS
> > > > > > > > roles
> > > > > > > > RESTCONF call home only reverses the TCP role but not the
> > > > > > > > TLS role. In DOTS case, the server has to initiate DTLS
> > > > > > > > handshake for UDP. To keep the roles same for TCP,  TLS
> > > > > > > > handshake is also initiated
> > > > by
> > > > > the server.
> > > > > > >
> > > > > > Similar to (D)TLS, I prefer explicit text to say role reversal
> > > > > > at
> > TCP.
> > > > >
> > > (refer again to Figure 1). There is no ambiguity that the reversal
> > > at the
> > TLS
> > > otherwise the connection cannot be established at the first place
> > > (due to
> > the
> > > presence of NATs/FWs) !
> >
> > If NAT is not present, connection can be established. FW can be
> > configured to permit TCP connections from external peer (e.g. port
> forwarding).
> >
> > >
> >    DOTS server acts as a TLS client initiating the underlying TCP
> > connection and the DOTS client acts as a TLS

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 25 Apr 2019 10:40:41 +0000

Hi Jon,

For UDP,  the first packet is the DTLS ClientHello message and it has to be sent by the DOTS server. The DOTS client cannot send the ClientHello Message as the first packet 
because of the reasons listed in https://tools.ietf.org/html/rfc8071#section-1.1. We followed the same logic for TLS/TCP.
 
Cheers,
-Tiru

> From: Jon Shallow <[email-masked]>
> Sent: Thursday, April 25, 2019 3:57 PM
> To: [email-masked]; Konda, Tirumaleswar Reddy
> <[email-masked]>; [email-masked]
> The easiest way in my current thinking is that the role reversal should only be
> at the UDP or TCP layer and then (D)TLS is set up / initiated by the DOTS client
> to the DOTS server (and is how RFC8071 defines the setup of the security
> layer over TCP).
> 
> Otherwise, libcoap needs to be taught that (D)TLS set up is in the reverse
> direction to the CoAP transfers which would involve a significant re-write and
> a lot of clarity in the code (e.g. am I a server or a client at this point of working
> in the network stack?).
> 
> Just establishing a session 5 tuple in the reverse direction and then
> remembering this only for the UDP/TCP layer is a simple libcoap change.
> 
> > https://github.com/boucadair/dots-call-home/blob/master/draft-ietf-dot
> > s-
> > signal-call-home-00.txt
> >
> > Cheers,
> > Med
> >
> > > Envoyé : mercredi 24 avril 2019 15:26 À : BOUCADAIR Mohamed TGI/OLN;
> > > Valery Smyslov; [email-masked] Cc : [email-masked];
> > > [email-masked] Objet : RE: [Dots] Adoption call for
> > > draft-reddy-dots-home-network-04
> > >
> > > > > > > > > -----Message d'origine----- De : Konda, Tirumaleswar
> > > > > > > > > Reddy [mailto:[email-masked]]
> > > > > > > > > > This email originated from outside of the
> > > > > > > > > > organization. Do not click links
> > > > > > > > > or
> > > > > > > > > > > [email-masked]; [email-masked] Objet : Re:
> > > > > > > > > > > [Dots] Adoption call for
> > > > > > > > > > > draft-reddy-dots-home-network-04
> > > > > > > > > > >
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > So, the document is adopted. Authors, please
> > > > > > > > > > > re-submit it as WG
> > > > > > > draft.
> > > > > > > > > > >
> > > > > > > > > > > A couple of comments.
> > > > > > > > > > > 1. The draft uses few times a keyword "MAY NOT".
> > > > > > > > > > > This combination is
> > > > > > > > not
> > > > > > > > > > >      among the list of RFC requirement keywords (it
> > > > > > > > > > > is not listed
> > > > > > > neither
> > > > > > > > > > >      in RFC2119, nor in RFC8174). If the intent was
> > > > > > > > > > > to use RFC
> > > > > > > > > requirement
> > > > > > > > > > >      language, then I'd suggest replacing it with
> > > > > > > > > > > one of MUST NOT, SHALL NOT,
> > > > > > > > > > >      makes me confusing is that the draft describes
> > > > > > > > > > > it several times as "TCP/TLS or DTLS".
> > > > > > > > > > >      Why TCP is ever mentioned here? We all know
> > > > > > > > > > > that TLS usually runs
> > > > > > > > > over
> > > > > > > > > > >      TCP (however we now have QUICK) and DTLS runs
> > > > > > > > > > > over
> > UDP.
> > > > > > > > > > >      plain TCP is also allowed as a transport, but
> > > > > > > > > > > is seems to
> > > > > > > contradict
> > > > > > > > > RESTCONF call home only reverses the TCP role but not
> > > > > > > > > the TLS role. In DOTS case, the server has to initiate
> > > > > > > > > DTLS handshake for UDP. To keep the roles same for TCP,
> > > > > > > > > TLS handshake is also initiated
> > > > > by
> > > > > > the server.
> > > > > > > >
> > > > > > > > As mentioned earlier, the use of TCP/TLS is OK but it may
> > > > > > > > be confusing as initially raised by Valery.
> > > > > > >
> > > > > > [Med] The updated text is still fine (ref to Figure 1). We
> > > > > > don't have any ambiguity in the procedure part with regards to
> > > > > > TCP. We explicitly say the
> > > > > > following:
> > > > > >
> > > > > > > Similar to (D)TLS, I prefer explicit text to say role
> > > > > > > reversal at
> > > TCP.
> > > > > >
> > > > >    server.  The DOTS server initiates TLS handshake or DTLS
> > > > > handshake
> > to
> > > > >    the DOTS client.
> > > > >
> > > > layer for the DOTS case implies a reversal of the TCP roles,
> > > > because otherwise the connection cannot be established at the
> > > > first place (due to
> > > the
> > > > presence of NATs/FWs) !
> > >
> > > configured
> > to

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 25 Apr 2019 12:16:31 +0100

Hi Tiru,

Good point about the DOTS server initial UDP Packet needs to include the Client Hello.  However, if it was an empty packet (no data, or some other specifically defined data),  the DOTS client could ignore any data (as it is listening on the Call Home port) then use the 5 tuple of the received packet to send the initial Client Hello to the DOTS server. 

However, that does raise the question of an attack where someone is sending spoofed IP packets to the DOTS client.  But that would also be true for a Client Hello packet with a spoofed source IP causing the recipient to send out the Server Hello to the spoofed originator.

I will continue to look at how to do the current draft thinking in libcoap ....

Regards

Jon

> From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
> Sent: 25 April 2019 11:41
> To: Jon Shallow; [email-masked]; [email-masked]
> For UDP,  the first packet is the DTLS ClientHello message and it has to be
> sent by the DOTS server. The DOTS client cannot send the ClientHello
> Message as the first packet
> because of the reasons listed in https://tools.ietf.org/html/rfc8071#section-
> 1.1. We followed the same logic for TLS/TCP.
> 
> Cheers,
> -Tiru
> 
> > I am having a hard time working out how to implement this Call Home
> using
> > libcoap.
> >

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 25 Apr 2019 13:47:21 +0000

> Sent: Thursday, April 25, 2019 4:47 PM
> <[email-masked]>;
> [email-masked]; [email-masked]
> Good point about the DOTS server initial UDP Packet needs to include the
> Client Hello.  However, if it was an empty packet (no data, or some other
> specifically defined data),  the DOTS client could ignore any data (as it is
> listening on the Call Home port) then use the 5 tuple of the received packet
> to send the initial Client Hello to the DOTS server.
> 
> However, that does raise the question of an attack where someone is
> sending spoofed IP packets to the DOTS client.  But that would also be true
> for a Client Hello packet with a spoofed source IP causing the recipient to
> send out the Server Hello to the spoofed originator.

DTLS uses stateless cookie mechanism to defend against DOS attacks, see https://tools.ietf.org/html/rfc7525. 

> I will continue to look at how to do the current draft thinking in libcoap ....

We should discuss this problem in the CORE WG, RFC7252 says CoAP implementation can act in both client and server roles.

-Tiru

> > For UDP,  the first packet is the DTLS ClientHello message and it has
> > to be sent by the DOTS server. The DOTS client cannot send the
> > ClientHello Message as the first packet because of the reasons listed
> > in https://tools.ietf.org/html/rfc8071#section-
> > > The easiest way in my current thinking is that the role reversal
> > > should only
> > be
> > > at the UDP or TCP layer and then (D)TLS is set up / initiated by the
> > > DOTS
> > client
> > > to the DOTS server (and is how RFC8071 defines the setup of the
> > > security layer over TCP).
> > >
> > > Otherwise, libcoap needs to be taught that (D)TLS set up is in the
> > > reverse direction to the CoAP transfers which would involve a
> > > significant re-write
> > and
> > > a lot of clarity in the code (e.g. am I a server or a client at this
> > > point of
> > working
> > > in the network stack?).
> > >
> > > Just establishing a session 5 tuple in the reverse direction and
> > > then remembering this only for the UDP/TCP layer is a simple libcoap
> change.
> > >
> > > > > > > > > Envoyé : mercredi 24 avril 2019 13:01 À : BOUCADAIR
> > > > > > > > > > > [email-masked]; [email-masked] Objet : RE:
> > > > > > > > > > > [Dots] Adoption call for
> > > > > > > > > > > > open attachments unless you recognize the sender
> > > > > > > > > > > > and know the content is safe.
> > > > > > > > > > > >
> > > > > > > > > > > > Re-,
> > > > > > > > > > > >
> > > > > > > > > > > > Please see inline.
> > > > > > > > > > > >
> > > > > > > > > > > > Cheers,
> > > > > > > > > > > > Med
> > > > > > > > > > > >
> > > > > > > > > > > > > [mailto:[email-masked]] De la part de
> > > > > > > > > > > > > Valery Smyslov Envoyé : mercredi 24 avril 2019 07:02 À :
> > > > > > > > > > > > > [email-masked]
> > > > > > > Cc :
> > > > > > > > > > > > > we received a lot of replies supporting adoption
> > > > > > > > > > > > > of the
> > > > > > document.
> > > > > > > > > > > > >      among the list of RFC requirement keywords
> > > > > > > > > > > > > (it is not listed
> > > > > > > > > neither
> > > > > > > > > > > > >      in RFC2119, nor in RFC8174). If the intent
> > > > > > > > > > > > > was to use RFC
> > > > > > > > > > > requirement
> > > > > > > > > > > > >      language, then I'd suggest replacing it
> > > > > > > > > > > > > with one of MUST NOT, SHALL NOT,
> > > > > > > > > > > > >      makes me confusing is that the draft
> > > > > > > > > > > > > describes it several times as "TCP/TLS or DTLS".
> > > > > > > > > > > > >      TCP (however we now have QUICK) and DTLS
> > > > > > > > > > > > > runs over
> > > > UDP.
> > > > > > > > > > > > >      The way it is presented in the draft makes
> > > > > > > > > > > > > me think that
> > > > > > > > > probably
> > > > > > > > > > > > >      plain TCP is also allowed as a transport,
> > > > > > > > > > > > > but is seems to
> > > > > > > > > contradict
> > > > > > > > > > > > [Med] Plain TCP is not allowed. The intent was to
> > > > > > > > > > > > be explicit that there is
> > > > > > > > > > > a
> > > > > > > > > > > > confusing since, for the DOTS case, it is trivial
> > > > > > > > > > > > that the reversal of TLS
> > > > > > > > > > > roles
> > > > > > > > > > > RESTCONF call home only reverses the TCP role but
> > > > > > > > > > > not the TLS role. In DOTS case, the server has to
> > > > > > > > > > > initiate DTLS handshake for UDP. To keep the roles
> > > > > > > > > > > same for TCP, TLS handshake is also initiated
> > > > > > > by
> > > > > > > > the server.
> > > > > > > > > >
> > > > > > > > > > [Med] You missed "for the DOTS case" in my previous
> > > > > > > > > > reply
> > > > > > > > > > :-)
> > > > > > > > > >
> > > > > > > > > > As mentioned earlier, the use of TCP/TLS is OK but it
> > > > > > > > > > may be confusing as initially raised by Valery.
> > > > > > > > >
> > > > > > > > > The updated text is not accurate if TCP is not covered,
> > > > > > > > > role reversal at TLS does not mean role reversal at TCP.
> > > > > > > >
> > > > > > > > don't have any ambiguity in the procedure part with
> > > > > > > > regards to TCP. We explicitly say the
> > > > > > > > following:
> > > > > > > >
> > > > > > > >        connection to the DOTS client.  The DOTS client
> > > > > > > > MUST
> > support
> > > > > > > [TR] Yes, but the updated sentences are incomplete/incorrect
> > > > > > > at various places. I have listed one of the inconsistencies
> > > > > > > below
> > > > > > >
> > > > > > [Med] This text assumes that the TCP is implicitly covered by
> > > > > > "TLS
> > layer"
> > > > > > (refer again to Figure 1). There is no ambiguity that the
> > > > > > reversal at the
> > > > > TLS
> > > > >    DOTS server acts as a TLS client initiating the underlying
> > > > > TCP connection and the DOTS client acts as a TLS

---

From: Daniel Migault <[email-masked]>
Date: Thu, 25 Apr 2019 17:25:12 -0400

Thanks Tiru,

Thanks for the feedback. Please see my comments/response and clarification.
Apology for being so long to respond.

Yours,
Daniel

On Thu, Apr 18, 2019 at 8:53 AM Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

> *From:* Dots <[email-masked]> *On Behalf Of * Daniel Migault
> *Sent:* Monday, April 15, 2019 9:34 PM
> *To:* Panwei (William) <[email-masked]>
> *Cc:* [email-masked]; Valery Smyslov <[email-masked]>;
> [email-masked]; [email-masked]
> *Subject:* Re: [Dots] Adoption call for draft-reddy-dots-home-network-04
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> ------------------------------
>
> [TR] Agreed, it is relatively easy for the DDoS mitigation provider for
> the attack target to detect sophisticated DDoS attacks (especially if the
> attack uses encrypted traffic).
>
>
>
> [TR] Both draft-reddy-dots-home-network and RFC8071 adopt the same
> approach for managing roles and connections. You may want to look into
> RFC8071.
>
<mglt>ok thanks. and we wants to map the DOTS Client with the CoAP client.
In other words, it is out of scope to have a DOT CLient with a CoAP client
and a CoAP server. When I wrote the comment I had a push request in mind,
and observe does not work ;-)</mglt>

> [TR] I don’t get the above comment.
<mglt>I suppose my mouse pointer tricked me. The idea I wanted to provide
was that *maybe* it would be good to think as DOTS peers that establish a
channel using DTLS and each peer can be over the same channel act as a
client or server. We would rather talk about initiator and responder. In
other word, to make teh protocol less asymmetric. </mglt>

>
>
> Cheers,
>
> -Tiru
>
>
>
>
>
> On Sun, Apr 14, 2019 at 11:06 PM Panwei (William) <
> [email-masked]> wrote:
>
> Hi,
>

---

From: Daniel Migault <[email-masked]>
Date: Thu, 25 Apr 2019 21:00:42 -0400

Hi,

Please find my comments inline. I believe my initial comment is addressed.
Igot confused between the DOTS and DTLS Client.

Yours,
Daniel

On Thu, Apr 18, 2019 at 9:13 AM <[email-masked]> wrote:

> (1) To identify the appropriate ISP which is hosting a DDoS source once a
> DDoS target has detected/reported an attack to its DOTS server/provider.
> The target may not be on the same network as the source.
>
<mglt>I might be wrong, but it seems to me that when the IP address is not
spoof, you can relatively easily go back to the ISP of that IP address. (at
least). Am I missing something ?</mglt>

> (2) That ISP needs to expose a service to receive these notifications.
<mglt>Theoretically, you would need an mesh of ISP DOTS communications (for
DTLS). but I imagine we could start with ISP you peer with or have servers
at the RIR level....</mglt>

>
>
> Of course, if the ISP is capable of receiving these notifications, it can
> invoke the procedure in draft-reddy-dots-home-network.
>

>
>
> The scenario mentioned by Daniel is an interesting problem to address…but
> I’m afraid this is out of scope of the current DOTS charter.
>
<mglt>In fact what I really wanted to point out was that at the target
node. a DOT Client sends a message to the DMS. briefly re-reading the draft
I have the impression the DOTS client is on the ISP side. Only TCP/DTLS
client server are exchanged. This seems fine. I believe I misread this the
first time.</mglt>

> *De :* Dots [mailto:[email-masked]] *De la part de* Konda,
> Tirumaleswar Reddy
> *Envoyé :* jeudi 18 avril 2019 14:52
> *À :* Daniel Migault; Panwei (William)
> *Cc :* [email-masked]; Valery Smyslov; [email-masked]; [email-masked]
> *Objet :* Re: [Dots] Adoption call for draft-reddy-dots-home-network-04
>
>
>
> Hi Daniel,
>
>
>
> *From:* Dots <[email-masked]> *On Behalf Of *Daniel Migault

---

From: Daniel Migault <[email-masked]>
Date: Thu, 25 Apr 2019 21:03:01 -0400

Works fine for me. Thanks for addressing this. I believe the text clarified
what confused me in the beginning.
Yours,
Daniel

On Wed, Apr 24, 2019 at 7:18 AM <[email-masked]> wrote:

> click
> > > As mentioned earlier, the use of TCP/TLS is OK but it may be confusing
> as
> > > initially raised by Valery.
> >
> > The updated text is not accurate if TCP is not covered, role reversal at
> TLS
> > does not mean role reversal at TCP.
>
> > signal channel session is considered valid.", so clear text DOTS traffic
> is
> > ruled out.
>
> [Med] Fully agree.
>

---

From: <[email-masked]>
Date: Fri, 26 Apr 2019 06:16:03 +0000

Hi Daniel,

Please see inline.

Cheers,
Med

De : Daniel Migault [mailto:[email-masked]]
Envoyé : vendredi 26 avril 2019 03:01
À : BOUCADAIR Mohamed TGI/OLN
Cc : Konda, Tirumaleswar Reddy; [email-masked]; Valery Smyslov; [email-masked]; [email-masked]
Objet : Re: [Dots] Adoption call for draft-reddy-dots-home-network-04

Hi,

Please find my comments inline. I believe my initial comment is addressed.  Igot confused between the DOTS and DTLS Client.

Yours,
Daniel

On Thu, Apr 18, 2019 at 9:13 AM <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tiru, Daniel,

With regards to:

“ I believe that

This is not currently doable with DOTS. Some key functional components are needed:
(1) To identify the appropriate ISP which is hosting a DDoS source once a DDoS target has detected/reported an attack to its DOTS server/provider. The target may not be on the same network as the source.
<mglt>I might be wrong, but it seems to me that when the IP address is not spoof, you can relatively easily go back to the ISP of that IP address. (at least). Am I missing something ?</mglt>
[Med] That’s a good starting point (assuming workarounds for some issues such as: registries are not always up to date due to secondary market and so on.)

(2) That ISP needs to expose a service to receive these notifications.
<mglt>Theoretically, you would need an mesh of ISP DOTS communications (for DTLS). but I imagine we could start with ISP you peer with or have servers at the RIR level....</mglt>
[Med] That’s an option. A solution is missing in that space, IMO. Such solution would also be used, for example, by IP reputation systems which currently add IP addresses to blacklists without even informing the ISPs. If that information is made available using some dynamic means, appropriate actions can be enforced by ISPs rather than assigning a “polluted” IP address to customers who will experience a bad quality because of restrictions induced by the reputation of the assigned IP address. We can discuss this offline as this is not specific to DOTS.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 26 Apr 2019 08:25:17 -0400

Thanks for the response.
Yours,
Daniel

On Fri, Apr 26, 2019 at 2:16 AM <[email-masked]> wrote:

> Hi Daniel,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Daniel Migault [mailto:[email-masked]]
> *Envoyé :* vendredi 26 avril 2019 03:01
> *À :* BOUCADAIR Mohamed TGI/OLN
> *Cc :* Konda, Tirumaleswar Reddy; [email-masked]; Valery Smyslov;
> Please find my comments inline. I believe my initial comment is
> addressed.  Igot confused between the DOTS and DTLS Client.
>
>
>
> Yours,
>
> Daniel
>
>
>
> [Med] That’s a good starting point (assuming workarounds for some issues
> such as: registries are not always up to date due to secondary market and
> so on.)
>
>
>
> <mglt>Theoretically, you would need an mesh of ISP DOTS communications
> (for DTLS). but I imagine we could start with ISP you peer with or have
> servers at the RIR level....</mglt>
>
> [Med] That’s an option. A solution is missing in that space, IMO. Such
> solution would also be used, for example, by IP reputation systems which
> currently add IP addresses to blacklists without even informing the ISPs.
> If that information is made available using some dynamic means, appropriate
> actions can be enforced by ISPs rather than assigning a “polluted” IP
> address to customers who will experience a bad quality because of
> restrictions induced by the reputation of the assigned IP address. We can
> discuss this offline as this is not specific to DOTS.
>
>
>