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

"Jon Shallow" <supjps-ietf@jpshallow.com> Thu, 25 April 2019 10:27 UTC

Return-Path: <supjps-ietf@jpshallow.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DE6120111 for <dots@ietfa.amsl.com>; Thu, 25 Apr 2019 03:27:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ec8rrvT1B4Sy for <dots@ietfa.amsl.com>; Thu, 25 Apr 2019 03:27:29 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3DA412006F for <dots@ietf.org>; Thu, 25 Apr 2019 03:27:28 -0700 (PDT)
Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.91) (envelope-from <jon.shallow@jpshallow.com>) id 1hJbbB-0000IS-3b; Thu, 25 Apr 2019 11:27:25 +0100
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: mohamed.boucadair@orange.com, "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>, dots@ietf.org
References: <023d01d4ee1f$c2bcb190$483614b0$@smyslov.net> <019001d4fa5a$cf08fb60$6d1af220$@smyslov.net> <787AE7BB302AE849A7480A190F8B93302EA648E7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB27907ABC5E91DD572EBE7807EA3C0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA649DB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB2790ED963937C8C15B319F63EA3C0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA64C46@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB27902B9175E96A2062D06E83EA3C0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA64E53@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB27908314C1236FE8846984E5EA3C0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA656B7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA656B7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Thu, 25 Apr 2019 11:27:23 +0100
Message-ID: <012e01d4fb51$7a4d0e20$6ee72a60$@jpshallow.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJbKhUsh7U/p5pdx+eMSV8unPEt3QGUJEMaAbTQtMAA8kzLKQJ12CJ+AjVMCj0CD7jm6QEHvqv3AesrjAABLjgzegH8cTfnpLerT2A=
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/dPs5NSRiHBszZqI9gPS3AE5LhNw>
Subject: Re: [Dots] Adoption call for draft-reddy-dots-home-network-04
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Apr 2019 10:27:32 -0000

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
> -----Original Message-----
> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
> Sent: 25 April 2019 07:14
> To: Konda, Tirumaleswar Reddy
> Cc: dots@ietf.org
> Subject: Re: [Dots] Adoption call for draft-reddy-dots-home-network-04
> 
> 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
> 
> > -----Message d'origine-----
> > De : Konda, Tirumaleswar Reddy
> [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > Envoyé : mercredi 24 avril 2019 15:26
> > À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; dots@ietf.org
> > Cc : dots-chairs@ietf.org; kaduk@mit.edu
> > Objet : RE: [Dots] Adoption call for draft-reddy-dots-home-network-04
> >
> > > -----Original Message-----
> > > From: mohamed.boucadair@orange.com
> > > <mohamed.boucadair@orange.com>
> > > Sent: Wednesday, April 24, 2019 6:42 PM
> > > To: Konda, Tirumaleswar Reddy
> > > <TirumaleswarReddy_Konda@McAfee.com>; Valery Smyslov
> > > <valery@smyslov.net>; dots@ietf.org
> > > Cc: dots-chairs@ietf.org; kaduk@mit.edu
> > > Subject: RE: [Dots] Adoption call for draft-reddy-dots-home-network-04
> > >
> > > 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 : Konda, Tirumaleswar Reddy
> > > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > > Envoyé : mercredi 24 avril 2019 14:56
> > > > À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; dots@ietf.org Cc :
> > > > dots-chairs@ietf.org; kaduk@mit.edu Objet : RE: [Dots] Adoption call
> > > > for draft-reddy-dots-home-network-04
> > > >
> > > > > -----Original Message-----
> > > > > From: mohamed.boucadair@orange.com
> > > > > <mohamed.boucadair@orange.com>
> > > > > Sent: Wednesday, April 24, 2019 4:48 PM
> > > > > To: Konda, Tirumaleswar Reddy
> > > > > <TirumaleswarReddy_Konda@McAfee.com>; Valery Smyslov
> > > > > <valery@smyslov.net>; dots@ietf.org
> > > > > Cc: dots-chairs@ietf.org; kaduk@mit.edu
> > > > > Subject: RE: [Dots] Adoption call for
> > > > > draft-reddy-dots-home-network-04
> > > > >
> > > > > 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 : Konda, Tirumaleswar Reddy
> > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > > > > Envoyé : mercredi 24 avril 2019 13:01 À : BOUCADAIR Mohamed
> > > > > > TGI/OLN; Valery Smyslov; dots@ietf.org Cc :
> > > > > > dots-chairs@ietf.org; kaduk@mit.edu Objet : RE: [Dots] Adoption
> > > > > > call for draft-reddy-dots-home-network-04
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: mohamed.boucadair@orange.com
> > > > > > > <mohamed.boucadair@orange.com>
> > > > > > > Sent: Wednesday, April 24, 2019 12:18 PM
> > > > > > > To: Konda, Tirumaleswar Reddy
> > > > > > > <TirumaleswarReddy_Konda@McAfee.com>; Valery Smyslov
> > > > > > > <valery@smyslov.net>; dots@ietf.org
> > > > > > > Cc: dots-chairs@ietf.org; kaduk@mit.edu
> > > > > > > Subject: RE: [Dots] Adoption call for
> > > > > > > draft-reddy-dots-home-network-04
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Re-,
> > > > > > >
> > > > > > > Please see inline.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Med
> > > > > > >
> > > > > > > > -----Message d'origine-----
> > > > > > > > De : Konda, Tirumaleswar Reddy
> > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > > > > > > Envoyé : mercredi 24 avril 2019 08:13 À : BOUCADAIR Mohamed
> > > > > > > > TGI/OLN; Valery Smyslov; dots@ietf.org Cc :
> > > > > > > > dots-chairs@ietf.org; kaduk@mit.edu Objet : RE: [Dots]
> > > > > > > > Adoption call for draft-reddy-dots-home-network-04
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Dots <dots-bounces@ietf.org> On Behalf Of
> > > > > > > > > mohamed.boucadair@orange.com
> > > > > > > > > Sent: Wednesday, April 24, 2019 11:26 AM
> > > > > > > > > To: Valery Smyslov <valery@smyslov.net>; dots@ietf.org
> > > > > > > > > Cc: dots-chairs@ietf.org; kaduk@mit.edu
> > > > > > > > > Subject: Re: [Dots] Adoption call for
> > > > > > > > > draft-reddy-dots-home-network-04
> > > > > > > > >
> > > > > > > > > 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:dots-bounces@ietf.org] De la part de Valery
> > > > > > > > > > Smyslov Envoyé : mercredi 24 avril 2019 07:02 À :
> > > > > > > > > > dots@ietf.org
> > > > Cc :
> > > > > > > > > > dots-chairs@ietf.org; kaduk@mit.edu Objet : Re: [Dots]
> > > > > > > > > > Adoption call for draft-reddy-dots-home-network-04
> > > > > > > > > >
> > > > > > > > > > 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.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > [Med] Good catch. Fixed.
> > > > > > > > >
> > > > > > > > > > 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?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > [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.
> > > > > > >
> > > > > > > [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      |
> > > > > > >                     |<-----------------------------------|
> > > > > > >                     |                                    |
> > > > > >
> > > > > > Okay.
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 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.
> > > > >
> > > > > [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).
> > > >
> > > > [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 !
> > >
> > > [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
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots