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

Deb Cooley has entered the following ballot position for
draft-ietf-manet-dlep-traffic-classification-13: 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-traffic-classification/



----------------------------------------------------------------------
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.

Section 4:  I would also like to see documentation of the risk of 'leaking
data' into unused (and unvalidated by the receiver) protocol fields.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2.1:  Data item type field is 16 bits? Please clarify.

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?

Section 2.1:  Reserved field, why doesn't the router have to validate this (it
allows a covert channel if not validated)?

Section 2.2:  NumDSCPs:  How does it work to have a wildcard in this field? 
Does the entity creating the item not know how many DSCPs there are?  Seems
odd.  Also seems like a way for a third party to add/remove DSCPs.

Section 2.3:  Length:  Same comment as Section 2.1.  Is there a total bit
length for the field?  If not, why not?

Section 2.3:  NumPCPs:  Same comment as Section 2.2 (NumDSCPs).

Section 2.3:  Pad:  Same comment as Section 2.1 (reserved field).

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?  Is there a transition strategy where some parts of the system have
been updated but others have not?



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