Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-channel-28: (with DISCUSS and COMMENT)

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Hi Mirja,

We have updated the draft to address your Discuss (please see https://tools.ietf.org/html/draft-ietf-dots-data-channel-30) and Med responded to your comments. 
Please have a look and approve the draft.

Best Regards,
-Tiru

> -----Original Message-----
> From: [e-mail]
> <[e-mail]>
> Sent: Wednesday, July 3, 2019 11:21 PM
> To: Mirja Kuehlewind <[e-mail]>; Konda, Tirumaleswar Reddy
> <[e-mail]>
> Cc: Roman Danyliw <[e-mail]>; [e-mail]; The IESG <[e-mail]>;
> [e-mail]; [e-mail]; Benjamin Kaduk
> <[e-mail]>
> Subject: RE: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-
> channel-28: (with DISCUSS and COMMENT)
> 
> 
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Mirja Kuehlewind [mailto:[e-mail]] Envoyé : mercredi 3
> > juillet 2019 18:41 À : Konda, Tirumaleswar Reddy Cc : Roman Danyliw;
> > [e-mail]; The IESG; [e-mail]; draft-
> > [e-mail]; BOUCADAIR Mohamed TGI/OLN;
> Benjamin
> > Kaduk Objet : Re: [Dots] Mirja Kühlewind's Discuss on
> > draft-ietf-dots-data-
> > channel-28: (with DISCUSS and COMMENT)
> >
> > Hi Tiru, hi Med,
> >
> > Please see below.
> >
> > > On 3. Jul 2019, at 10:00, Konda, Tirumaleswar Reddy
> > <[e-mail]> wrote:
> > >
> > > Hi Mirja,
> > >
> > > Please see inline
> > >
> > >> -----Original Message-----
> > >> From: Mirja Kuehlewind <[e-mail]>
> > >> Sent: Tuesday, July 2, 2019 9:20 PM
> > >> To: Konda, Tirumaleswar Reddy
> <[e-mail]>
> > >> Cc: Benjamin Kaduk <[e-mail]>; Roman Danyliw <[e-mail]>;
> > >> [e-mail]; The IESG <[e-mail]>; [e-mail];
> > >> [e-mail]; draft-ietf-dots-data-
> [e-mail]
> > >> Subject: Re: [Dots] Mirja Kühlewind's Discuss on
> > >> draft-ietf-dots-data-
> > >> channel-28: (with DISCUSS and COMMENT)
> > >>
> > >> 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.
> > >>
> > >> Hi Tiru,
> > >>
> > >> Below...
> > >>
> > >>> On 2. Jul 2019, at 16:22, Konda, Tirumaleswar Reddy
> > >> <[e-mail]> wrote:
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Mirja Kuehlewind <[e-mail]>
> > >>>> Sent: Tuesday, July 2, 2019 7:36 PM
> > >>>> To: Konda, Tirumaleswar Reddy
> > >> <[e-mail]>
> > >>>> Cc: Benjamin Kaduk <[e-mail]>; Roman Danyliw
> <[e-mail]>;
> > >>>> [e-mail]; The IESG <[e-mail]>; [e-mail];
> > >>>> [e-mail];
> > >>>> [e-mail]
> > >>>> Subject: Re: [Dots] Mirja Kühlewind's Discuss on
> > >>>> draft-ietf-dots-data-
> > >>>> channel-28: (with DISCUSS and COMMENT)
> > >>>>
> > >>>>
> > >>>>
> > >>>> Hi Tiru,
> > >>>>
> > >>>> Please see below.
> > >>>>
> > >>>>> On 2. Jul 2019, at 09:55, Konda, Tirumaleswar Reddy
> > >>>> <[e-mail]> wrote:
> > >>>>>
> > >>>>>>>>> I would also quickly like to discuss the use of keep-alives
> > >>>>>>>>> as described in Section 3.1: "While the communication to the
> > >>>>>>>>> DOTS server is  quiescent, the DOTS client MAY probe the
> > >>>>>>>>> server to ensure it has  maintained cryptographic state.
> > >>>>>>>>> Such probes can also keep alive  firewall and/or NAT
> > >>>>>>>>> bindings.  A TLS heartbeat [RFC6520] verifies  that the DOTS
> > >>>>>>>>> server still has TLS state by returning
> > >>>> a TLS message."
> > >>>>>>>>> I understood that multiple requests can and should be send
> > >>>>>>>>> in the same connection, however, I would expect that those
> > >>>>>>>>> requests are send basically right after each other, such as
> > >>>>>>>>> a look-up and then change of the config. I don't see a need
> > >>>>>>>>> to keep up the connection for a
> > >>>>>> long time otherwise.
> > >>>>>>>>> Especially any action performed are (other than in the
> > >>>>>>>>> signal channel case) not time critical. Therefore I would
> > >>>>>>>>> rather recommend to close and reopen connections and not
> > >>>>>>>>> recommend
> > >> to
> > >>>> use
> > >>>>>>>>> keep-alives at all.
> > >>>>>>>>
> > >>>>>>>> [Med] The activity of the DOTS client may be used to
> > >>>>>>>> track/detect stale
> > >>>>>> entries:
> > >>>>>>>>
> > >>>>>>>> Also, DOTS servers
> > >>>>>>>> may track the inactivity timeout of DOTS clients to detect
> > >>>>>>>> stale entries.
> > >>>>>>>>
> > >>>>>> My understanding is that this is orthogonal. You can also see
> > >>>>>> that a client is inactive when it didn’t open a new connection
> > >>>>>> for a
> > certain
> > >> time…?
> > >>>>>
> > >>>>> The drop-list rules could be frequently updated by the DOTS
> > >>>>> client based on the tests used by the DOTS client domain (e.g.
> > >>>>> cryptographic
> > >>>>> challenge) to detect whether the IP address is for legitimate
> > >>>>> use or not, or based on threat intelligence feeds from security
> > >>>>> vendors providing the botnet/malicious IP addresses feed.
> > >>>>> Further, persistent DOTS data channel is required to handle
> > >>>>> updates to target resources (e.g. CDN hosting a domain, and it
> > >>>>> needs DDoS protection) and target IP/prefix may also change
> > >>>>> frequently (mobile branch office, prefix re-numbering etc.)
> > >>>>
> > >>>> This still doesn’t sounds like it is desirable to keep the TCP
> > connection
> > >> open.
> > >>>> Also if you can bear the time to reconnect (1-2 RTT for the
> > >>>> handshake) that is usually the better and easier options. I don’t
> > >>>> think the information we talk about here are that time-critical,
> > >>>> is it? When you say frequent what time frame do you mean, Hours,
> > minutes,
> > >> seconds, milliseconds?
> > >>>
> > >>> The frequency of updates to drop-list rules can be few milliseconds.
> > For
> > >> example, CAPTCHA and cryptographic puzzles can be used by DOTS
> > >> client domain to determine whether the IP address is used for
> > >> legitimate
> > purpose
> > >> or not, and can configure the drop-list rules.
> > >>> Further, the specification does not mandate the connection to be
> > >> persistent, but when needed, the probe mechanism applies.
> > >>
> > >> Then it really seems to me that the document would need to provide
> > further
> > >> guidance when a persistent connection is useful or when it is
> > >> recommend
> > to
> > >> close the connection (and reopen if needed).
> > >
> > > Sure, will add the following text:
> > >
> > >   A DOTS client can either maintain a persistent connection or periodic
> > >   connections with its DOTS server(s).  If the DOTS client needs to
> > >   frequently update the drop-list or accept-list filtering rules or
> > >   aliases, it maintains a persistent connection with the DOTS server.
> > >   For example, CAPTCHA and cryptographic puzzles can be used by the
> > >   mitigation service in the DOTS client domain to determine whether the
> > >   IP address is used for legitimate purpose or not, and the DOTS client
> > >   can frequently update the drop-list filtering rules.  A persistent
> > >   connection is also useful if the DOTS client subscribes to event
> > >   notifications (Section 6.3 of [RFC8040]).
> > >
> > > - Tiru and Med
> >
> > Thanks!
> >
> > Two more small comments:
> >
> > At least to me the term “periodic" is not clear. I guess mean
> > something like short-lived connections, where you have a request, you
> > open a connection, send it, get a reply, and close the connection
> > immediately or after a short idle period. Or is there actually any
> > kind of periodicity in the dots protocol in general? Can you pleas clarify.
> 
> [Med] We are trying to reuse the same terminology as RESTCONF (draft-ietf-
> netconf-restconf-client-server).
> 
> For the DOTS case, the DOTS client is required to register and send requests
> to refresh the registration in regular intervals (otherwise, the DOTS client
> won't be able to created filters). Likewise, cycles will be observed because
> the client will need to maintains the aliases and ACLs it created. The client
> may use these cycles for any planned activity (create new aliases, create a
> new filter, etc.) or not.
> 
> >
> > Also if a persistent connection is used, I think it would (again) be
> > good to clarify what should be done if the connection fails. I think
> > the right advise in this case, is to not reconnect immediately but
> > only if you have another request to send, right?
> >
> 
> [Med] draft-ietf-netconf-restconf-client-server voices for the following:
> 
>    Maintain a persistent connection to the
>    RESTCONF server. If the connection goes down,
>    immediately start trying to reconnect to the
>    RESTCONF server, using the reconnection strategy.
> 
> Which is the right approach, IMO.
> 
> We didn't touched on connection management because we are relying on
> RESTCONF. DOTS will use whatever strategy adopted for RESTCONF.
> 
> I don't think it is a good idea to add specific behavior into our spec.
> 
> 
> 
> > Mirja
> >
> >
> > >
> > >>
> > >> Mirja
> > >>
> > >>
> > >>>
> > >>> -Tiru
> > >>>
> > >>>>
> > >>>> Mirja
> > >>>>
> > >>>>
> > >>>>>
> > >>>>> Further, we are not mandating the connection to be persistent,
> > >>>>> but when
> > >>>> needed, the probe mechanism applies. Please note
> > >>>> https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-ser
> > >>>> ver-
> > >>>> 13 discusses persistent-connection and it’s a client preference
> > >>>> on how the connection is maintained (persistent or periodic).
> > >>>
> > >