[manet] Roman Danyliw's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-manet-dlep-pause-extension-06: 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-manet-dlep-pause-extension/



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

Unauthenticated shutdown of the network seems exceedingly dangerous.  An
expansion of the implementation scenarios described in Section 4 of RFC8175 and
the architecture laid out in Figure 1 of RFC8175 appears to be:

(a) single direct connect (1x modem + 1x router)
(b) single dedicated switch (1x modem + 1x switch + 1x router)
(c) multiple connect (>1x modem + >=0 switches + 1x router)
(d) mobile environment (>=1x modem + switch + router + other devices in the
switch) (e) networked deployment (as stated in RFC8175/anything more
complicated)

I believe that the safest thing is that using TLS with this extension should be
a MUST.  If that is problematic, then I’d only soften it to (text that amounts
to) “in environments and deployment scenarios (a) and (b), TLS SHOULD be used. 
In all other environments, TLS MUST be used.”

Warren: I believe that your neighbor scenario is likely scenario (c).

As the current security considerations say, using TLS in scenario (a) won’t
help if the modem gets compromised.  In the above recommendation, there is an
assumption that the switch(s) isn’t compromised (and that should be documented).


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

(0) I support Warren and Magnus’s DISCUSS positions.

(1) Section 3.1.  Per the Query Parameters data item, what is the router
behavior when it receives:

** Num Queues = 0
** Num Queues <> the queues sent?

(2) Section 3.1.  Nit.  The size of the Reserved field is not indicated in the
text (like the other fields)

(3) Section 3.1.1, Please provide a section reference into RFC8175 on error
parsing.

(4) Section 3.2  Per “Each Pause Data Item identifies the traffic to be
suppressed by the Queue Index defined by Section 3.1”, am I reading it right
that a Queue Parameter Data Item needs to be sent before a Pause is sent?  If
so, I’m not sure that is said anywhere and should be.  Furthermore, how does a
router behave if it does get a Pause message prior to getting a Parameter Data
Item message?

(5) Section 3.3  Related to comment-4, How does a router behave if it gets a
Restart message prior to getting a Parameter Data Item or Pause message?