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

[Mirja Kuehlewind <[e-mail]>]

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]; [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.

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?

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-server-
>>>> 13 discusses persistent-connection and it’s a client preference on
>>>> how the connection is maintained (persistent or periodic).
>>> 
>