Re: [manet] Warren Kumari's Discuss on draft-ietf-manet-dlep-pause-extension-06: (with DISCUSS)

[Warren Kumari <[e-mail]>]

On Thu, Apr 11, 2019 at 8:21 AM Lou Berger <[e-mail]> wrote:

>
> On 4/8/2019 2:57 PM, Warren Kumari via Datatracker wrote:
> > Warren Kumari 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:
> > ----------------------------------------------------------------------
> >
> > 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.
>
> FWIW an impersonator can shut a router completely down, by constantly
> resetting the DLEP session.  RFC8175 defines TLS protected DLEP as the
> solution.  To make this clear(er) the text has been updated to read
>
>
>    Note that this extension does allow a compromised or impersonating
>    modem to suppress transmission by the router.  Similar attacks are
>    generally possible base DLEP, for example an impersonating modem may
>    cause a session reset or a compromised modem simply can
>    drop all traffic destined to, or sent by a router.  <xref
>    target="RFC8175"/> defines the use of TLS to protect against the
>    impersonating attacker.
>
> suggested improvements are most welcome! (but see below addition before
> drafting ;-)
>
> > 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).
>
> I have no objection to something.  How about, to the end of the prior
> paragraph:
>
>    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.
>


Thank you, that works for me.

I'll clear my DISCUSS, and trust y'all to include it.
W

>
> Lou
>
> >
> >
> >
> >
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf