[manet] Re: Deb Cooley's Discuss on draft-ietf-manet-dlep- traffic-classification-13: (with DISCUSS and COMMENT)

Apologies for the delay, it was a busy meeting week.

Thank you very much for thorough answers to all of my comments.  I will
clear my discuss now.

Deb Cooley


On Wed, Mar 19, 2025 at 11:32 AM Don Fedyk <[email protected]> wrote:

> Hi Deb
>
> Thank you for your comments. Sorry for the delay I was out on vacation
> when this came up and I am only now catching up. We have submitted
> https://www.ietf.org/archive/id/draft-ietf-manet-dlep-traffic-classification-14.txt to
> address your comments as well as other Reviewers,
>
> Please see my comment inline [Don]
>
> ------------------------------
> *From:* Deb Cooley via Datatracker <[email protected]>
> *Sent:* Sunday, February 2, 2025 9:38 AM
> *To:* The IESG <[email protected]>
> *Cc:* [email protected] <
> [email protected]>;
> [email protected] <[email protected]>; [email protected] <
> [email protected]>; [email protected] <[email protected]>;
> [email protected] <[email protected]>
> *Subject:* Deb Cooley's Discuss on
> draft-ietf-manet-dlep-traffic-classification-13: (with DISCUSS and COMMENT)
>
> Deb Cooley has entered the following ballot position for
> draft-ietf-manet-dlep-traffic-classification-13: Discuss
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> 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.
>
> [Don]  IMHO This comment applies flow control and traffic classification
> documents.  We see your point.  We will probably need help on getting this
> right. The use of TLS 1.2 predates my involvement but from what I
> understand it was chosen as a way to protect the link and modem traffic
> which in almost all cases is very localized between a router an a modem.
> Reading up on TLS, I think if we highlight that our Base DLEP draft RFC
> 8175 uses TLS 1.2 but implementations should follow the guidance on using
> TLS 1.2 outlined in RFC 9325 .
>
> We have updated the security section to include this:
> 4.  Security Considerations
>
>    This document introduces finer grain flow identification 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 modified Traffic Flow Classification Data Item
>    resulting in changes to class of service for affected flows.  The
>    Layer 2 and transport layer security mechanisms documented in
>    [RFC8175] can be applied equally to the mechanism defined in this
>    document.
>
>    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.
>
> [Don]  This is intentional and a common practice of TLVs.  We have updated
> the text to make this clear.
> Reserved:
>       For the Traffic Classification Data Item this reserved field is
>       currently unused.  It MUST be 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.
>
> While your point of leaking data is true, we feel the security  risk is
> very low given the typical deployment is a Router-Modem link and this is a
> common practice for small protocol extensions.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> [Don] For the following comments they required a pass over the document to
> align these points so I will comment here and point to an area where the
> authors put the next draft for review before submitting.
>
> Section 2.1:  Data item type field is 16 bits? Please clarify.
> [2] Yes 16 Bits this section terminology is a bit inconsistent; I have
> aligned definitions terminology.
> Section 2.1:  Is there an upper limit to the length of the length field (in
> Section 2.1.1 the length field for the sub data item is a 16 bit unsigned
> integer)?  If not, why not?
>
> [Don] The field length is limited by the number of markings that can be
> used which is 64 for IP and 8 for Ethernet at present.  I checked the Base
> DLEP RFC and length is usually fixed.  What I think we can do with this
> draft is limit the length by for Ethernet  and Diffserv based on maximum
> number of PCPs or DSCPs a max length for the respective Sub-Data Item
> type.   I will compute this value and propose it for review.
>
> Section 2.1:  Reserved field, why doesn't the router have to validate this
> (it
> allows a covert channel if not validated)?
> [Don] it is purposely left for future use of the general structure but
> I'll add text to restrict it to unused for the Traffic Classification  Data
> Item type.
>
> Section 2.2:  NumDSCPs:  How does it work to have a wildcard in this field?
> [Don]  I added text to explain this. The tuple is FID (which maps to a
> queue) and one or more DSCPs that are mapped to this FID. When you assign a
> number DSCPs to FIDs you do not need to map all possibilities if you are
> not using them.   A short form of mapping DSCPs to a default FID is to use
> the wildcard that matches any DSCP not explicitly mapped.  DSCPs that do
> not have a mapping to FID will be mapped to the wildcard.
>
> Does the entity creating the item not know how many DSCPs there are? odd.
> [Don] Yes but it may intentionally want to map many DSCPs to default.  It
> could do this explicitly with a long list, but wildcard is a short form.
> Also seems like a way for a third party to add/remove DSCPs.
> [Don] I don't follow. The DLEP protocol is between a Router and a Modem.
> Specifically, the Modem tells the Router a mapping of data plane markings
> to FID which the router can map to queues and use to provide class of
> service to traffic that is marked.   It's the modem telling the router that
> it can differentiate traffic that is marked so the Router can do the same.
> There is no third party this is local to the router and the Modem but it
> could be coordinated between ends of a link or across a network.
>
> Section 2.3:  Length:  Same comment as Section 2.1.  Is there a total bit
> length for the field?  If not, why not?
> [Don] Addressed above.
>
> Section 2.3:  NumPCPs:  Same comment as Section 2.2 (NumDSCPs).
> [Don] Addressed above.
>
> Section 2.3:  Pad:  Same comment as Section 2.1 (reserved field).
> [Don] Addressed above.
>
>
> Section 3:  What is the expected behaviour when either the router or modem
> don't understand the extensions?  Is it treated like a failure?  Or are
> they
> ignored?
> [Don] The Base DLEP RFC  states that for and TLVs
> The session is terminated.
> In the DLEP RFC8175:
> "All supported metric Data Items MUST be included in the Session
>    Initialization Response Message, with default values to be used on a
>    session-wide basis.  This can be viewed as the modem "declaring" all
>    supported metrics at DLEP session initialization.  Receipt of any
>    further DLEP Message containing a metric Data Item not included in
>    the Session Initialization Response Message MUST be treated as an
>    error, resulting in the termination of the DLEP session between
>    router and modem."
>
> Metrics include in our case Traffic Classification Identifiers and
> associated elements both sides router and mode must have the extension
> supported.
>
> Is there a transition strategy where some parts of the system have
> been updated but others have not?
> [Don] This is a single router to single modem protocol so a router and a
> modem can have an agreement of what they support without affecting any
> other modems.  This is highlighted more the companion
> draft-ietf-manet-dlep-credit-flow-control.
> The working group sepparted the drafts after WG discussions because they
> wanted:
> A flow control mechanism that was extensible.
> A traffic classification mechanism that was independent of the specific
> flow control (queueing algorithms).
> A spec for Diffserv Code Points.
> A spec for Ethernet Priority Code points.
> In theory new specifications could replace any one of these drafts but
> reuse the other drafts.
>
> Cheers
> Don
>
>
>
>

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