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

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 <mohamed.boucadair@orange.com> wrote:

> 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).
>
>  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.
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
>