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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Thu, 02 May 2019 04:24:44 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dots-data-channel-28: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Suresh's discuss that the process of how it is indicated if a 1 or 2
byte mask is used is not clear. However, I would additionally like to discuss
why this bit mask is needed at all. The TCP flags field in RFC8519 is already
defined as bits. Storing these bits in a signal 8 bit field and applying a
matching operation is implementation specific only and doesn't require any
changes to the YANG model.

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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Editorial comment: As alias and migration-scope (in the signal channel
document) have the same fields, wouldn't it make sense to only definite it once
somewhere?

---

From: <[email-masked]>
Date: Thu, 2 May 2019 11:54:50 +0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kühlewind via Datatracker [mailto:[email-masked]]
> Envoyé : jeudi 2 mai 2019 13:25
> À : The IESG
> Cc : [email-masked]; Roman Danyliw; dots-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Mirja Kühlewind's Discuss on draft-ietf-dots-data-channel-28: (with
> DISCUSS and COMMENT)
> 

[Med] The motivation is similar to the one for the IPv4 flags:  

   Nevertheless,
   the use of 'flags' is problematic since it does not allow to define a
   bitmask.  For example, setting other bits not covered by the 'flags'
   filtering clause in a packet will allow that packet to get through
   (because it won't match the ACE).  

The use of bitmask will also ease inter-working witg BGP flowspec.

> 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.

> Editorial comment: As alias 

[Med] The grouping "target" is defined in the data-channel, and reused in the signal channel. The name cannot be reused because it is a key of the aliases in data-channel and a node in the signal-channel. 

and migration-scope 

[Med] I guess you meant "mitigation-scope". There is no such item in the data channel. Please note that "ietf-data:target" is called in the signal-channel under mitigation-scope. 

(in the signal channel