Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension
draft-ietf-manet-dlep-pause-extension-08

Thank you for addressing my DISCUSS.

DISCUSS -> NoObj.

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.

to address my DISCUSS. 


--- Archived DISCUSS position for hysterical raisins ---

Please note that I'm really not a DLEP person, and so this may be completely incorrect -- in which case I'm (of course!) happy to clear my discuss.

Hypothetical Scenario:
My next-door neighbor keeps using up all the bandwidth, making my Internets slow! Stupid neighbor!

Until now I didn't have much motivation to mess with DLEP (it didn't really gain me anything), but now I can spoof Pause Data Items to get the router to stop sending traffic to her, freeing up all the bandwidth for me.

The security considerations section doesn't *really* cover this -- it says: 
" Note that this extension does allow a compromised or impersonating modem to suppress transmission by the router, but this is not a substantively different attack by such a compromised modem simply dropping all traffic destined to, or sent by a router." -- that only covers compromised modems, not impersonating modems.

It also says:
"[RFC8175] defines the use of TLS to protect against the impersonating attacker." -- yes, RFC8175 does indeed define the use of TLS, but doesn't require it.

RFC8175 Security Considerations also say:
" This specification does not address security of the data plane, as it (the data plane) is not affected, and standard security procedures can be employed." and "Similar issues can arise if DLEP data is used as an input to policing algorithms -- injection of malicious data via DLEP can cause those policing algorithms to make incorrect decisions, degrading network throughput."

It seems that this specification is specifically allowing the dataplane to be affected by (spoofed) DLEP messages, and in a much more direct way than discussed in the RFC8175 security considerations section. I think that this is dangerous without much more direct advice (like "MUST use TLS" or similar).
-------

Thanks to everyone who worked on this document.

I share Roman and Warren's concerns about authentication of pause messages.

---------------------------------------------------------------------------

§3.2:

>  particular threshold.  Other use cases are possible, e.g., when there
>  a non queue related congestion points within a modem, but such are

Nit: I can't quite parse the "when there a non queue" part of this.

DISCUSS cleared, leaving in my previous COMMENT:

I support the DISCUSS positions of Warren and Magnus.

I'm unclear on why this specification is necessary, i.e. why the use of existing transport protocols and processing of DSCPs do not suffice to achieve what this specification is aiming to achieve. Is that explained in another document somewhere?

= Section 1 =

"Various flow control methods are possible, e.g.,
   see [I-D.ietf-manet-dlep-da-credit-extension]."

The referenced document does not specify a flow control method. Maybe draft-ietf-manet-dlep-credit-flow-control is what was intended?

Thank you for resolving my Discuss points!

Thanks for the discussion!