[sfc] Éric Vyncke's No Objection on draft-ietf-sfc-nsh-integrity-08: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-sfc-nsh-integrity-08: No Objection

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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/



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

Thank you for the work put into this document. As already communicated by
email, I am now clearing my previous DISCUSS ballot (kept below only for
archiving purposes), I am also trusting the responsible AD about my previous
COMMENT points.

Special thanks to Greg Mirsky for his shepherding especially about his summary
of the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

PS: your reply was lost in the ‘fury’ ot the IETF week, sorry about that and
please thank your AD, Martin Vigoureux, for sending me today a gentle nudge...

== previous DISCUSS (for archive only as the current revision addresses all the
points) ==

I failed to spot the order of the operations for the integrity and
confidentiality operations, e.g., I did not find on what the HMAC is computed:
in the unencrypted or encrypted field ?

-- Section 5.1 --
What is the unit of "key length", I assume a length expressed in octets but it
is not specified.

-- Section 7.2 --
What is the "A" used in the HMAC computation ?

The formula specifies HMAC-SHA-256-128() but what if another HMAC is used ?
Section 7.3 use MAC() which is more flexible.

As the MAC field is included in the integrity protected header, please specify
the value of this field when computing the HMAC (I assume 0 but let's be clear)

-- Section 7.5 --
What is the expected behavior when a NSH does not contain a "MAC and Encrypted
Metadata" Context Header ? §1 hints to packet drop ? Should there be a local
policy for this case ?

I second Alvaro's and Lars' point about formally updating RFC 8300.

Quite often in the text "privacy-sensitive metadata" is used but encryption is
not only required for privacy but also to protect operational data from
attackers (i.e., not linked to privacy), is there a real need to qualify
"metadata" with "privacy-sensitive", i.e., "confidential metadata" may be more
appropriate ?

-- Section 4.1.1 --
The use of 'metadata' (notably in table 1) for 'context headers' is confusing
for a first-time reader. Any chance to be consistent and only use 'context
headers' ?

-- Section 4.2 --
At first reading, I am confused by the use of the word 'secret key' for what
appears to be a 'shared key'. Or is this 'secret key' never shared and simply
used to generate the secondary keys, which are then shared ? Even if discussed
later, some early explanations would be welcome.

-- Section 5.1 --
Is there a good reason why the field name "key length" is not "key ID length" ?

I also find very strange to define "Length: variable" as the header field
itself as a fixed length, simply state "unsigned integer".

As timestamp can include fractions of second, which is a good thing, then
please reword "expressed in seconds relative" to indicate that fraction of
second is included.

The 32-bit epoch will wrap around in 2036, should this I-D already consider
what to do at that moment ?

-- Section 8 --
Indeed MTU is always an interesting 'problem' but how is this extension
different than plain NSH ? The NSH neither increases nor decreases on the fly
with this document.

== NITS ==

-- Section 3 --
Should 'figure 1' be 'table 1' per consistency with section 4.1.1 ?