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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 01 May 2019 13:40:13 -0700

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.

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

---

From: Lou Berger <[email-masked]>
Date: Sun, 5 May 2019 21:42:30 -0400

Hi,
	Please see below.

> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-multi-hop-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.

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 6 May 2019 21:59:48 +0000

> -----Original Message-----
> From: iesg [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Sunday, May 5, 2019 9:43 PM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [manet] Roman Danyliw's Discuss on draft-ietf-manet-dlep-
> multi-hop-extension-06: (with DISCUSS and COMMENT)
> 
> Hi,
> 	Please see below.
> 
> > 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
> > 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 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.
> >
> 
> 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.

Thanks.

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

Understood.  Thanks for the clarity.

Roman