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

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]