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

[Lou Berger <[e-mail]>]

Hi,
	Please see below.

On 5/1/19 4:40 PM, Roman Danyliw via Datatracker wrote:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-manet-dlep-multi-hop-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-multi-hop-extension/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This extension (much like draft-ietf-manet-dlep-pause-extension) seems to
> provide a mechanism to direct a modem to drop traffic in an unauthenticated
> fashion -- for directly connected networks via the terminate action; and for
> multi-hop networks via the suppress action.
> 
> For example, per the mobile scenario in Section 4 of RFC8175, a compromised
> laptop in the switch could use this extension instruct the modem to drop
> packets without authentication.
> 
> I saw in Warren’s comment ballet on draft-ietf-manet-dlep-pause-extension
> (https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/ballot/)
> that
> 
> “Lou will add:
>   Implementations of the extension defined in this document MUST support
>    configuration of TLS usage, as describe in <xref target="RFC8175"/>,
>    in order to protect configurations where injection attacks are
>    possible, i.e., when the link between a modem and router is not
>    otherwise protected.”
> 
> I believe the same caveat is needed in this draft as they are enabling similar
> behavior.  Please correct me if I’m conflating the capabilities of this
> extension with the pause extension.
> 

On one hand I think it is reasonable to have the security sections match
between the two.  On the other, I think it really seems this IESG is
unhappy with the language  approved for 8175.  Given this, I'll go ahead
and add the requested test.


> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> A few questions and an editorial nit.
> 
> (1) Section 1.  Editorial.  There is a sentence fragment “example using.” which
> likely needs to be removed.
> 
> (2) Section 2.  Per “The use of the Multi-Hop Forwarding Extension SHOULD be
> configurable”, what is meant by configurable?
> 
> (3) Section 3.2.2 and 3.2.3.  The Terminate and Direct Connection messages are
> not supposed to be (MUST NO) be sent in a Session Update Message.  How should
> the modem behave if it receives one anyway?
> 

base DLEP 8175 resets a session on any type of parsing error. I'm
personally not a fan of this, but it *is* what RFC8175 says...

Thanks,
Lou

> 
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>