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

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]