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

"Jon Shallow" <supjps-ietf@jpshallow.com> Thu, 25 April 2019 11:16 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 0420C1200A2 for <dots@ietfa.amsl.com>; Thu, 25 Apr 2019 04:16:39 -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 sencQm2_RT3Z for <dots@ietfa.amsl.com>; Thu, 25 Apr 2019 04:16:36 -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 AF18A120045 for <dots@ietf.org>; Thu, 25 Apr 2019 04:16:35 -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 1hJcMj-0000Kb-3s; Thu, 25 Apr 2019 12:16:33 +0100
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: "'Konda, Tirumaleswar Reddy'" <TirumaleswarReddy_Konda@mcafee.com>, mohamed.boucadair@orange.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> <012e01d4fb51$7a4d0e20$6ee72a60$@jpshallow.com> <BYAPR16MB27907A8A494FDA074713490FEA3D0@BYAPR16MB2790.namprd16.prod.outlook.com>
In-Reply-To: <BYAPR16MB27907A8A494FDA074713490FEA3D0@BYAPR16MB2790.namprd16.prod.outlook.com>
Date: Thu, 25 Apr 2019 12:16:31 +0100
Message-ID: <013c01d4fb58$576f1ae0$064d50a0$@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+AjVMCj0CD7jm6QEHvqv3AesrjAABLjgzegH8cTfnAb8negMCuGSEXaST/aNQ
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/cpRCM1QFiapowKQIRoLOatT6SY8>
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 11:16:39 -0000

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

> -----Original Message-----
> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
> Sent: 25 April 2019 11:41
> To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org
> Subject: Re: [Dots] Adoption call for draft-reddy-dots-home-network-04
> 
> 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
> 
> > -----Original Message-----
> > From: Jon Shallow <supjps-ietf@jpshallow.com>
> > Sent: Thursday, April 25, 2019 3:57 PM
> > To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy
> > <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
> > Subject: RE: [Dots] Adoption call for draft-reddy-dots-home-network-04
> >
> >
> >
> > 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-dot
> > > s-
> > > 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
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots