[manet] Re: Deb Cooley's Discuss on draft-ietf-manet-dlep- credit-flow-control-17: (with DISCUSS and COMMENT)

Thank you for the work on these drafts.  I've cleared my discuss.

Deb Cooley

On Sun, Mar 23, 2025 at 7:46 AM Eric Kinzie <[email protected]> wrote:

> Deb,
>
> Please see my comments below.  These changes are similar to those made
> for the traffic classification draft.
>
> Thanks,
> Eric
>
> On Sun Feb 02 07:57:59 -0800 2025, Deb Cooley via Datatracker wrote:
> > Deb Cooley has entered the following ballot position for
> > draft-ietf-manet-dlep-credit-flow-control-17: 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/about/groups/iesg/statements/handling-ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> >
> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-credit-flow-control/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Please note that this discuss applies to the traffic classification
> draft, and
> > perhaps to the other two DLEP drafts on the telechat.  I would be happy
> to have
> > them all addressed together, at the authors discretion.
> >
> > Section 4:  The transport layer security recommendations in RFC8175 are
> largely
> > outdated (it predates TLS1.3, RFC8446).  It references RFC 7525 (which
> has been
> > obsoleted by RFC 9325) and RFC 5487 which may/may not be relevant today
> (i.e.
> > it is very old - predating both TLS 1.2, RFC 5746, and TLS1.3).  In
> addition,
> > the link layer security recommendations are similarily outdated.  Please
> > address this issue in this draft's Security Considerations.
>
> The Security Considerations have been updated with:
>
>    This document introduces credit window control and flow mechanisms to
>    DLEP.  These mechanisms expose vulnerabilities similar to existing
>    DLEP messages.  For example, a malicious actor masquerading as a DLEP
>    peer could inject a Credit Window Initialization Data Item which
>    resizes a credit window to a value that results in a denial of
>    service.  The transport layer security mechanisms documented in
>    [RFC8175] can, with some updates, be applied to this document.
>    Implementations following the "networked deployment" model described
>    in the "Implementation Scenarios" of [RFC8175] SHOULD refer to
>    [BCP195] for additional details.  The Layer 2 security mechanisms
>    documented in [RFC8175] can also, with some updates, be applied to
>    the mechanism defined in this document.  Examples of technologies
>    that can be deployed to secure the Layer 2 link include
>    [IEEE-802.1AE] and [IEEE-8802-1X].
>
> >
> > Section 4:  I would also like to see documentation of the risk of
> 'leaking
> > data' into unused (and unvalidated by the receiver) protocol fields.
>
> As Don pointed out for the traffic classification draft, this is
> intentional.  Reserved fields are now described this way:
>       For the Credit Window Initialization Data Item this reserved field
>       is currently unused.  It MUST set to all zeros for this version of
>       the Data Item and it is currently ignored on reception.  This
>       allows for future extensions of the Data Item if needed.
> >
> >
> >
>
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 2, paragraph 6:  Wildcards are mentioned here, but no where else
> in the
> > draft.  Specifically, which packet types listed in this draft can have
> > wildcards specified?
>
> I have included the message types to which this applies:
>
>     The Traffic Classification Data Item, included in either a Session
>     Initialization Response Message or a Session Update Message, allows
>     the modem to specify a wildcard to match any packets that do not
>     match other data items.
>
> >
> > Sections 2.3.1, 2.3.3, 2.3.4:  Reserved field, why doesn't the
> router/modem
> > have to validate this (it allows a covert channel if not validated)?
>
> The wording of the reserved field descriptions indicates that they are
> currently unused.
>

_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]