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

[Lou Berger <[e-mail]>]

Hi,
	Please see below.

On 4/10/19 5:40 PM, Roman Danyliw via Datatracker wrote:
> 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)
I think (a) and (b) are the normal expected configuration, but of course
defer to the WG and DLEP authors.

> (c) multiple connect (>1x modem + >=0 switches + 1x router)
I think this is allowed.

> (d) mobile environment (>=1x modem + switch + router + other devices in the
> switch) 
DLEP runs on the wired side, i.e., always between a modem and a local
router - never over a wireless network.  At least as I understand it.

>
(e) networked deployment (as stated in RFC8175/anything more
> complicated)
I don't think so.

> 
> 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.”
> 
I think this comment is really WRT base DLEP 8175 and that this
extension should be consistent with 8175.

> Warren: I believe that your neighbor scenario is likely scenario (c).
> 
how so?  when would a neighbor ever share a connection between a CPE
(modem) and a user's router?

> 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).
> 
Added to draft.

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

This is covered by the current text:

      Queue Parameter Sub Data Items are an unordered list composed of
      sub data items with a common format.  The format of the Queue
Parameter Sub
      Data Item is patterned after the standard DLEP data item format,
      see <xref target="RFC8175"/> Section 11.3.  Any errors
      or inconsistencies encountered in parsing Sub Data Items are
      handled in the same fashion as any other Data Item parsing error
      encountered in DLEP.

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

> 
> (3) Section 3.1.1, Please provide a section reference into RFC8175 on error
> parsing.
I've added text extracted from 8175:

      In particular, the receiving implementation MUST issue a
      Session Termination Message containing a Status Data Item with
      status code set to 130 'Invalid Data' and transition to the
      Session Termination state.


> 
> (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?

This isn't possible as defined since it states in the Queue Parameter
section:
   This data item MUST be
  included in a Session Initialization Response Message that also
  contains the Control Plane Based Pause Extension Type Value in the
  Extensions Supported Data Item.

and this exchange takes place before data can be sent.

> 
> (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?
> 

same response.

Thanks for the comments. Please let me know if you still have any
outstanding comments/DISCUSSes..

Lou
> 
>