Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers
draft-ietf-sfc-nsh-integrity-09

[Ballot comment]
Thanks for the updates in the -07 and -08; I think we found a reasonable
way to address the issues that came up in my earlier review.

I turned most of my comments into a github PR against
https://github.com/boucadair/draft-ietf-sfc-nsh-integrity/ since that
repo was referenced in previous responses to comments.  The tip of the
branch I forked off seems to have corresponded to only the -07, though,
so I'm not sure if I should have gone somewhere else.  (I made a
separate first commit that just syncs down the -08 from the
datatracker.)
The PR is
https://github.com/boucadair/draft-ietf-sfc-nsh-integrity/pull/6 and the
actual "new" (non-08) changes are viewable via
https://github.com/boucadair/draft-ietf-sfc-nsh-integrity/compare/99c6484fbe85af7179086ab243c88813e2b47b74..kaduk:kaduk-review?expand=1

Section 4.4

  In order to accommodate deployments relying upon keying material per
  SFC/SFP and also the need to update keys after encrypting NSH data
  for a certain amount of time, this document uses key identifiers to
  unambiguously identify the appropriate keying material.  Doing so
  addresses the problem of synchronization of keying material.

I included a suggestion in my pull request, but I want to call out as a
potentially significant change that the key identifier should identify
not just the key material but also the algorithms that they key is to be
used with.

Section 5.1

  Nonce Length:  Carries the length of the Nonce.  If the Context
      Headers are only integrity protected, "Nonce Length" is set to
      zero (that is, no "Nonce" is included).  The "Nonce Length" can be
      set to zero depending on the encryption algorithm used to encrypt
      the Context Headers.

I included this in my PR, but want to call out that this last sentence
seems harmful.  It seems vastly preferrable to have "the nonce length
field is zero" indicate one specific thing, rather than having two
different possibilities for that situation, as this text appears to do.
I know that my earlier comments proposed a scenario where an AEAD might
validly encrypt with a zero-length nonce, but I don't think we should
support that at the cost of losing the clear signal that the encrypted
context headers are (not) present.

Section 7.3

  Using the secret key (ENC_KEY) and authenticated encryption
  algorithm, the NSH imposer encrypts the Context Headers (as set, for
  example, in Section 3) and inserts the resulting payload in the "MAC
  and Encrypted Metadata" Context Header (Section 5).  The entire
  Context Header carrying a sensitive metadata is encrypted (that is,
  including the MD Class, Type, Length, and associated metadata of each
  Context Header).

I included some text in my pull request, but want to call out as
important that this description does not specify what is to be used as
the "additional authenticated data" AEAD input.  (I assume the empty
string is intended, though other choices are valid.)

Section 7.5

  When an SFC data plane element conforms to this specification, it
  MUST ensure that a "MAC and Encrypted Metadata" Context Header is
  included in a received NSH packet.  [...]

This doesn't quite seem like the right condition -- this text sounds
like once you implement this context header you have to require that it
appears in all incoming packets, which breaks interoperability with
senders that don't produc this contxt header.

Section 9

  The secret key (K) must have an expiration time assigned as the
  latest point in time before which the key may be used for integrity
  protection of NSH data and encryption of Context Headers.  Prior to
  the expiration of the secret key, all participating NSH-aware nodes
  SHOULD have the control plane distribute a new key identifier and
  associated keying material so that when the secret key is expired,
  those nodes are prepared with the new secret key.  This allows the
  NSH imposer to switch to the new key identifier as soon as necessary.
  It is RECOMMENDED that the next key identifier and associated keying
  material be distributed by the control plane well prior to the secret
  key expiration time.

I note that draft-irtf-cfrg-aead-limits offers some guidance on how
often to rekey (though it gives data-based criteria, not time-based
ones), if that is potentially relevant.

[Ballot 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 ?

[Ballot comment]
Thanks for the discussion about updating RFC 8300.

Only nits to add, given the thorough treatment already given by others:

Section 4.1.2: "The first level of assurance where all NSH data ..." -- add "is" before "where"?  And the same issue in the next paragraph.

Section 5.2: s/Coves/Covers/

[Ballot discuss]
Enough other Area Directors have said, and I agree, that this should officially update RFC 8300, so I'd like to have the discussion.  In particular, given that this was identified as a gap in RFC 8300, and since I don't see any explicit statement that this is meant to be an optional extension, shouldn't it be an update?

[Ballot comment]
Only nits to add, given the thorough treatment already given by others:

Section 4.1.2: "The first level of assurance where all NSH data ..." -- add "is" before "where"?  And the same issue in the next paragraph.

Section 5.2: s/Coves/Covers/

[Ballot comment]
1. Section 4.2

  The authenticated encryption process takes as input four-octet
  strings: a secret key (K), a plaintext (P), Additional Authenticated
  Data (A) (which contains the data to be authenticated, but not
  encrypted), and an Initialization Vector (IV).  The ciphertext value
  (E) and the Authentication Tag value (T) are provided as outputs.

As written, this means that each of these quantities is a 32 bit string, even P and A. I think you don’t mean that. If you mean each quantity is a string of octets, then move the hyphen: “takes as input four octet-strings“. (In the unlikely event you really do mean each quantity is a string of four octets, then “… takes as input four strings, each of four octets.”)

2. Section 9

Regarding your use of the term “man-in-the-middle attacker”, you might want to take into consideration that this language may be seen as exclusionary by some readers, see also https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/. I’ve seen “on-path attacker“ used as a replacement in some cases, but I understand there may be nuances that make this inappropriate for some uses; it also appears you might just be able to use “attacker” in your case. The RFC Editor may have further guidance.

3. Section 9.1

You use “should“ in several places. As written, it isn’t clear if you’re indicating expectation, or requirement. After reading the whole section, I think you’re indicating requirement. This seems like a good place for use of the RFC 2119 style SHOULD keyword.

[Ballot discuss]
(0) (I came to this realization rather late in my review process, so
there may be places where the COMMENT and this discuss point are in
disagreement; this DISCUS takes precedence.)
I fear that the construction that separately distributes ENC_KEY and
MAC_KEY in an attempt to achieve privilege separation is fatally flawed.
In particular, the CBC encryption mode is a malleable encryption mode,
in that flipping a bit of ciphertext will filp the corresponding bit of
the next block of recovered plaintext (at the cost of completely
garbling the recovered block containing the bit that was modified).
Subsequent blocks are unaffected.  Typically we combine CBC mode with a
MAC such as HMAC in order to prevent such modifications from being
exposed as attack vectors, and while we do use HMAC here for that
purpose, we also introduce a separate class of actors that have access
to the HMAC key but not the encryption key.  Accordingly, those actors
can produce a new, valid, integrity tag after making a modification to
the ciphertext, allowing them to engage in attacks that make use of
ciphertext malleability.  Ciphertext malleability is particularly useful
as an attack vector when the structure of the plaintext being encrypted
is known, and there are portions of the plaintext that the application
will either ignore if they are garbled or are expected to be near random
in the normal case (and thus for which garbled output does not cause
rejection by the application).  In a SFC environment it seems highly
likely that the structure of the plaintext will be known or guessable,
and we don't have any real mechanisms to control what types of metadata
go into encrypted context headers, so it seems that we must act as if we
are exposed to this risk.

While §4.3 does have a note that use of GCM with HMAC is undesirable due
to the additional authentication tag, it may be unavoidable in order to
provide the properties that we need.

(1) Section 5.1 describes the MAC as:

  Message Authentication Code:  Covers the entire NSH data, excluding
      the Base header.  The Additional Authenticated Data (defined in
      [RFC7518]) MUST be the Service Path header, the unencrypted
      Context headers, and the inner packet on which the NSH is imposed.

This description seems to exclude from the MAC most of the MAC context
header itself (if we go by the corresponding figure), which is very bad
for security.  We definitely need to include under the MAC the MAC
context header bits from metadata class through and including at least
timestamp, and I think IV length as well.  (The IV itself would be
incorporated via the ciphertext, since the IV is an input to encryption,
but since the IV length field indicates whether or not encryption was
performed, we'd need to protect that information.)

Similarly, Section 5.2 has the description:

  Message Authentication Code:  Coves the entire NSH data.  The
      Additional Authenticated Data (defined in [RFC7518]) MUST be the
      entire NSH data (i.e., including the Base Header) excluding the
      Context Headers to be encrypted.

which on the face of it includes the field that holds the MAC itself
(and is not yet populated), i.e., is self-referential.

I think we need to be much more precise about the construction of the
AAD in both cases.  It's possible that the HMAC construction for the
no-encrypted-context-headers case can inherit a definition from the AAD
description, but if not we'll need to have some more precision there as
well.

(2) In order for the MAC-only construction in §7.2 to be compatible with
the AEAD integrity tag construction, we would need to include the 64-bit
AL after A.  While HMAC is intrinsically immune to length-extension
attacks, I think that having the explicit AL is useful to avoid any risk
of malleability, since the same MAC_KEY is used for constructing both
types of MACs.

(3) Section 5.1 describes the Timestamp field as an "unsigned 64-bit
integer value", which is inconsistent with the actual format given in
Section 6.

(4) Section 7.5 directs the verifier to check if "the value of the newly
generated digest is identical to the one enclosed in the NSH".  It is
critical for the security of the system that this comparison be done in
a constant-time manner that does not provide a side channel into whether
the generated digest and the value in the NSH share a common substring.

(5) Do the MAC context headers always have to be the last metadata
entries in the packet (to simplify the cryptographic calculations)?
Certainly the diagrams only show "unencrypted context headers" appearing
prior to the MAC context header, so if we expect unencrypted context
headers to appear after the MAC context header as well, we should be
clear about that both in the figures and in the specification for how to
prepare the AAD.

[Ballot comment]
Section 3

  o  Both encrypted and unencrypted Context Headers MAY be included in
      the same NSH.  That is, some Context Headers may be protected
      while others do not need to be protected.

In the security area we're pretty strongly moved towards a stance of
"encrypt everything that doesn't have a strong need to be plaintext
(since we don't want to assume that we can predict all threats and
attacks in advance), and QUIC has even taken that to new levels.  It's
quite surprising to see "don't need to be protected" as a justification
for lack of encryption, rather than "need to be unprotected".  Given
that we're going to be solving key distribution for integrity protection
anyway, it remains unclear to me why we wouldn't just encrypt
everything.

Section 4.1.1

Is the column heading for the middle column of Table 1 referring to the
Base Header and "Service Path Header"?  I'm not sure how to interpret
just "Service Header" other than the entire NSH, which doesn't seem
right...

  The Service Path Header (Section 2 of [RFC8300]) is not encrypted
  because SFFs use Service Index (SI) in conjunction with Service Path
  Identifier (SPI) for determining the next SF in the path.

It's good to see this spelled out like this; I'd love to have this kind
of explanation for every un-encrypted protocol element.

Section 4.1.2

  The solution provides integrity protection for the NSH data.  Two
  levels of assurance (LoAs) are supported.

I see (reading onward) that the two LoAs just differ in what is covered
by the integrity tag, but each involve only a single MAC.  There's a
reasonable argument that when there are overlapping needs for what data
needs protecting and who needs access to it, that multiple MACs (or
encryption, if needed) are most appropriate, which can be tailored to
the respective needs.  This is something that Phillip Hallam-Baker has
ascribed as the "short-blanket theory" of cryptography, in that it's
like a blanket that's too short to cover everything you want, so you
need to have more than one and put them in partially overlapping layers.
Perhaps this "short-blanket theory" is more applicable to Discuss point
(0) than what is covered by the MAC, though...

  The first level of assurance where all NSH data except the Base
  Header are integrity protected (Figure 2).  In this case, the NSH
  imposer may be a Classifier, an NSH-aware SF, or an SFC Proxy.  SFFs
  are not thus provided with authentication material.  [...]

There seems to be a gap in the chain of reasoning as to why SFFs are not
provided with authentication material.  It seems that the intent is
something along the lines of considering which entities need access to
the key material in order to successfully add an NSH or update context
headers, but that alone is not itself cause to say that other entities
can never be provided with the keys (subject to the security
considerations of group-shared PSKs, of course).  Furthermore, if a
particular SFF is trusted, it may have grounds to verify the integrity
tag even if it is administratively prohibited from writing such a tag.

  In both levels of assurance, the unencrypted Context Headers and the
  packet on which the NSH is imposed are subject to integrity
  protection.

Surely any encrypted Context Headers are also given integrity
protection, as excluding them from the MAC computation would be quite
complex.  I see that the encrypted context headers are not part of the
AAD input, but in the AEAD model the ciphertext is still given integrity
protection!

Section 4.2

  The authenticated encryption algorithm defined in [RFC7518] is used
  to provide NSH data integrity and to encrypt the Context Headers that
  carry privacy-sensitive metadata.

RFC 7518 (JSON Web Algorithms) is a very surprising reference for
generic AEAD encryption.  Continuing on, it becomes clear that we in
fact do not want a generic AEAD operation here, but instead have need
for separation of encryption and integrity protection due to the various
separations of roles that are possible.  Because this is a divergence
from current best practices (use of native AEAD cipher modes like GCM,
SIV, etc.), I might suggest a rather different introductory material:

% The AEAD interface specified in RFC 5116 is a very powerful tool for
% providing strong confidentiality and integrity protection for protocol
% messages, and has become quite widely adopted as a result.  For
% protecting NSH data we adhere to the spirit of the AEAD interface but
% use a slightly modified version in order to remain consistent with the
% privilege separation needed (e.g., in the second level of assurance,
% SFFs need to be able to update the message integrity tag but do not
% need access to the decrypted plaintext).  Accordingly, a compound AEAD
% mechanism combining CBC encryption and HMAC integrity tag is used, so
% that distribution of the encryption key can be limited.  Rather than
% define a new scheme from scratch, the AES_CBC_HMAC_SHA2 scheme from
% [RFC7518] is used.  In order to simplify key distribution, a single
% secret key material seed K is used, which can be kept private
% centrally or distributed to all parties that will have access to
% decrypted plaintext, and the secondary keys MAC_KEY and ENC_KEY are
% derived from K as discussed in Section 5.2.2.1 of [RFC7518].  Entities
% that need to update the integrity tag but are not authorized to see
% the decrypted plaintext will only receive MAC_KEY and not K or
% ENC_KEY.

  o  If the Context Headers are not encrypted, the Hashed Message
      Authentication Mode (HMAC) algorithm discussed in [RFC4868] is
      used to protect the integrity of the NSH data.

It's not clear to me that this is adding much value; HMAC is used
whether or not there are encrypted headers, and the RFC 4868 reference
is rather odd (see also my Discuss point (2)).

  The advantage of using the authenticated encryption algorithm is that
  NSH-aware SFs and SFC proxies only need to re-compute the message
  integrity of the NSH data after decrementing the Service Index (SI)
  and do not have to re-compute the ciphertext.  The other advantage is
  that SFFs do not have access to the ENC_KEY and cannot act on the
  encrypted Context Headers and, only in case of the second level of
  assurance, SFFs do have access to the MAC_KEY.  Similarly, an NSH-
  aware SF or SFC Proxy not allowed to decrypt the Context Headers will
  not have access to the ENC_KEY.

[If my above suggestion is used, this text has probably become mostly
redundant and could be trimmed down or removed.]

  The authenticated encryption process takes as input four-octet
  strings: a secret key (K), a plaintext (P), Additional Authenticated
  Data (A) (which contains the data to be authenticated, but not
  encrypted), and an Initialization Vector (IV).  The ciphertext value
  (E) and the Authentication Tag value (T) are provided as outputs.

  In order to decrypt and verify, the cipher takes as input K, IV, A,
  T, and E.  The output is either the plaintext or an error indicating
  that the decryption failed as described in Section 5.2.2.2 of
  [RFC7518].

This seems true for the abstract AEAD interface, but since we're peeling
off the HMAC integrity tag for standalone use, we may need to say
something about what inputs/outputs are needed for just using the
integrity tag without doing decryption.  In particular, we cannot use K
as an input for standalone HMAC verification!

Also, this is just the generic AEAD interface, so RFC 5116 is probably a
more apropos reference than RFC 7518.

Section 4.3

      Note: The use of Advanced Encryption Standard (AES) in Galois/
      Counter Mode (GCM) + HMAC may have CPU and packet size
      implications (need for a second 128-bit authentication tag).

[This might also be redundant if my earlier proposal is accepted.]

Section 4.4

  The document does not assume nor preclude the following:

  o  The same keying material is used for all the service functions
      used within an SFC-enabled domain.

  o  Distinct keying material is used per SFP by all involved SFC data
      path elements.

  o  Per-tenant keys are used.

I suggest a forward reference to the security considerations with a
brief note that the risk involved in using a group-shared symmetric key
increases with the size of the group to which it is shared.

  In order to accommodate deployments relying upon keying material per
  SFC/SFP and also the need to update keys after encrypting NSH data
  for a certain amount of time, this document uses key identifiers to
  unambiguously identify the appropriate keying material.  Doing so
  allows to address the problem of synchronization of keying material.

I'd suggest making a statement about the scope in which key identifiers
need to be unique.

Section 4.5

  An NSH-aware SF or SFC Proxy that needs to decrypt some Context
  Headers uses ENC_Key and the decryption algorithm for the key
  identifier being carried in the NSH.

I think we need to say that decryption MUST NOT proceed unless the
integrity tag has been successfully validated.  To decrypt without
checking the integrity tag violates the AEAD interface.  Alternately, we
could only ever describe decryption as the AEAD operation that uses K as
input (not just ENC_KEY) -- §7.6 seems to attempt to take this latter
approach, but the document as a whole is not consistent about it.

Section 5, 5.x

I strongly suggest changing "Key Length" to "keyid length", since there
is already convention on "key length" (e.g., for AES-128 vs AES-192 vs
AES-256).

Section 5.1

  Key Identifier:  Carries a variable-length Key Identifier object used
      to identify and deliver keys to SFC data plane elements.  This
      identifier is helpful to accommodate deployments relying upon
      keying material per SFC/SFP.  The key identifier helps in
      resolving the problem of synchronization of keying material.

I suggest clarifying that a single key identifier is used to lookup both
the associated ENC_KEY and the associated MAC_KEY (or, alternately, that
it is logically bound to K and remind the reader that ENC_KEY and
MAC_KEY are extracted from K and might be separately distributed).

  Key Length:  Variable.  Carries the length of the key identifier.
  [...]
  IV Length:  Carries the length of the IV (Section 5.2 of [RFC7518]).
      If encryption is not used, IV length is set to zero (that is, no
      "Initialization Vector" is included).

Please also specify that the Key/IV lengths are measured in bytes (the
reference for IV length, at least, talks about IVs in bits).

I strongly suggest using a value other than zero as the sentinel value
for "no encryption" -- there already exist modes like AES-SIV (RFC 5297)
that do not require an IV input, which would be a natural use for
zero-length IV.

Additionally, one might imagine using a non-zero-length IV as input to
an HMAC calculation as a per-message nonce.  On cursory examination,
since we are already using timestamp-based replay detection, the
additional nonce is unlikely to add much value, but I'm not willing to
completely rule it out on the basis of the minimal analysis I performed.

Section 7.1

  Only one instance of "MAC and Encrypted Metadata" Context Header
  (Section 5) is allowed.  If multiple instances of "MAC and Encrypted
  Metadata" Context Header are included in an NSH packet, the SFC data

I think Roman may have mentioned this already, but please clarify if
this is one instance per NSH or per packet (e.g., in hierarchical SFC we
might have more than one NSH in a packet).

Please also clarify it if is permitted to have both MAC#1 and MAC#2
present in the same packet.  (IIUC there are not obvious situations
where such a setup would be useful, but it's still good to be clear
about expectations.)

Section 7.2

  If the Context Headers are not encrypted, the HMAC algorithm
  discussed in [RFC4868] is used to integrity protect the target NSH
  data.  [...]

It's not really clear to me why RFC 4868 is the right reference here, as
opposed to (e.g.) RFC 2104.  In particular, see my Discuss point (2).

  The Message Authentication Code (T) computation process can be
  illustrated as follows:

        T = HMAC-SHA-256-128(MAC_KEY, A)

I agree with the other reviewer that wondered about just using "MAC" (or
maybe "HMAC") rather than "HMAC-SHA-256-128" here (I do see the "can be
illustrated as" qualifier).

It's also a little weird to reuse T and A from the AEAD construction (or
RFC 4868) here without additional discussion on how they apply and how
the value of A is constructed.

  An entity in the SFP that intends to update the NSH MUST follow the
  above behavior to maintain message integrity of the NSH for
  subsequent validations.

I'm not sure that "intends to" is needed; the requirement applies to
actions, not intent.

Section 7.3

  In an SFC-enabled domain where pervasive monitoring [RFC7258] is
  possible, all Context Headers carrying privacy-sensitive metadata
  MUST be encrypted; [...]

I agree with the other reviewer that noted that this seems to
effectively be an unqualified "MUST", since there is always some
possibility of monitoring.

        MAC_KEY = initial MAC_KEY_LEN octets of K,
        ENC_KEY = final ENC_KEY_LEN octets of K,
        E = CBC-PKCS7-ENC(ENC_KEY, P),
        M = MAC(MAC_KEY, A || IV || E || AL),
        T = initial T_LEN octets of M.
        MAC and Encrypted Metadata = E || T

I recognize that this is just copy+paste from RFC 7518 (with the
addition of the last line), but it seems a glaring omission that the
CBC-PKCS7-ENC() invocation does not include the IV as an input!
(In §5.2.2.1 of RFC 7518 we do see that "The plaintext is CBC encrypted
using PKCS #7 padding using ENC_KEY as the key and the IV", so it's just
the figure/formula that omits the IV.)

We also don't define or mention T_LEN in this document other than in
this formula and the analogous one for MAC-without-encryption, which
might be worth remedying.

Section 7.4

I suggest adding another word (like "Prevention") to the section title.

  The received NSH is accepted by an NSH-aware node if the Timestamp
  (TS) in the NSH is recent enough to the reception time of the NSH
  (TSrt).  The following formula is used for this check:

            -Delta < (TSrt - TS) < +Delta

(There's no real reason why the accepted timestamp skew parameter Delta
needs to be symmetric in the positive and negative directions.)

  Replay attacks within the Delta window may be detected by an NSH-
  aware node by recording a unique value derived, for example, from the
  NSH data and Original packet (e.g., using SHA2).  [...]

Note that the unique value MUST NOT use as input any bits that are not
covered by the MAC.  Indeed, just using the MAC itself as the unique
value would be a fairly straightforward scheme, I think.

Section 7.5

  When an SFC data plane element receives an NSH packet, it MUST first
  ensure that a "MAC and Encrypted Metadata" Context Header is
  included.  [...]

This sort of requirement (as written) would seem to support the position
of some other reviewers that this document would need to formally update
RFC 8300.

Section 9

We might discuss that this mechanism is only for metadata type 2 and not
type 1 (as well as that with the relatively small fixed length of type 1
metadata, it's quite challenging to provide useful cryptographic
protection), so that type-1 metadata still has no generic protection
mechanism.  A given metadata element could define its own protection
scheme, of course.

  The attacks discussed in [I-D.nguyen-sfc-security-architecture] are
  handled owing to the solution specified in this document, except for
  attacks dropping packets.  [...]

From a very quick read, draft-nguyen-sfc-security-architecture proposes
a probe-based scheme that monitors all middleboxes (or at least those in
the expected path) to detect a middlebox-bypass attack and verify that
the probe traversed the expected SFP.  I am not sure that this document
on its own suffices to prevent the middlebox-bypass attack for all
traffic (i.e., the probe-based scheme might still be needed).  If some
network entities know what the expected service index will be for a
given SPI at a given node, then middlebox-bypass attacks could be
natively detected, but my understanding was that such advance knowledge
of expected service index was not going to be available.

  The solution specified in this document does not provide data origin
  authentication.

I would have expected more in-depth discussion of the security
considerations for a group-shared PSK scheme, including how the risk of
key loss/compromise goes up when the key is distributed to more
locations.

Section 9.1

  No device other than the NSH-aware SFs in the SFC-enabled domain
  should be able to update the integrity protected NSH data.

What about classifiers and SFC proxies?

Section 9.2

I expected to see some remarks here analogous to the second paragraph of
§9.1 (even if just by reference to that section).

Section 9.3

  Section 5.6 of [RFC8633] describes best current practices to be
  considered in deployments where SFC data plane elements use NTP for
  time synchronization purposes.

The referenced section covers NTP symmetric mode only.  Is client/server
mode not a BCP for trusted networks and broadcast/symmetric the only
options?

NITS

Section 1

  network infrastructures against them, network slicing, etc.  Because
  of the proliferation of such advanced SFs together with complex
  service deployment constraints that demand more agile service
  delivery procedures, operators need to rationalize their service
  delivery logics and master their complexity while optimising service
  activation time cycles.  The overall problem space is described in
  [RFC7498].

The "their" in "master their complexity" is a bit ambiguous between
"operators" and "service delivery logics" (noting that the previous use
of "their" did refer to "operators").  (The sentence as a whole reads a
bit like marketing language, but that's not intended to be an actionable
comment.)

  This specification fills that gap.  Concretely, this document adds
  integrity protection and optional encryption of sensitive metadata
  directly to the NSH (Section 4); integrity protects the packet
  payload and provides replay protection (Section 7.4).  [...]

The clause after the semicolon needs to be able to stand alone as a
complete sentence in order to be grammatical, but it currently has no
subject.  Maybe prefixing "it also" would be enough to fix it.

Section 4.1.2

  The integrity protection scope is explicitly signaled to NSH-aware
  SFs and SFC proxies in the NSH by means of a dedicated MD Type
  (Section 5).

Signaled to SFFs as well, since in the second LoA they can use it.

Section 4.6

  As discussed in [RFC8459], an SFC-enabled domain (called, upper-level
  domain) may be decomposed into many sub-domains (called, lower-level
  domains).  In order to avoid maintaining state to restore back upper-
  lower NSH information at the boundaries of lower-level domains, two

I think s/upper-lower/upper-layer/ (across the line break)?

Section 5.1

  MAC#1 Context Header is a variable-length Context Header that carries
  the Message Authentication Code (MAC) for the Service Path Header,
  Context Headers, and the inner packet on which NSH is imposed,
  calculated using MAC_KEY and optionally Context Headers encrypted
  using ENC_KEY.  [...]

Comma after "calculated using MAC_KEY", please.  ("optionally Context
Headers [...]" are not used along with MAC_KEY in the calculation)

Section 5.2

  Message Authentication Code:  Coves the entire NSH data.  The

s/Coves/Covers/

Section 6

      The epoch is 1970-01-01T00:00Z in UTC time.  [...]

(IIUC, the "in UTC time" is redundant with the trailing 'Z'.)

Section 7.1

  element.  The details of sending notification alarms (i.e., the
  parameters affecting the transmission of the notification alarms
  depend on the information in the context header such as frequency,
  thresholds, and content in the alarm) SHOULD be configurable.

The grammar in the parenthetical seems off to me.  Possibly
s/depend/depending/ would be a fix, but I'm not sure.

  NSH-aware SFs and SFC proxies MUST re-apply the integrity protection
  if any modification is made to the Context Headers (strip a Context
  Header, update the content of an existing Context Header, insert a
  new Context Header).

I think maybe an "e.g.," in the parenthetical is in order, since this
doesn't seem to include things like "decrement the TTL".

Section 9

  The interaction between the SFC data plane elements and a key
  management system MUST NOT be transmitted in clear since this would
  completely destroy the security benefits of the integrity protection
  solution defined in this document.  The secret key (K) must have an
  expiration time assigned as the latest point in time before which the

This first sentence seems like it could probably be a paragraph of its
own; the subsequent discussion of expiration time seems to be mostly
unrelated.

We might also add another sentence to reiterate that "the security and
integrity of the key-distribution mechanism is vital to the security of
the system as a whole".

  o  Attacker replacing the packet on which the NSH is imposed with a
      bogus packet.

I'd probably say "modified or bogus".

  In an SFC-enabled domain where the above attacks are possible, (1)

This is perhaps ambiguous about whether an "any" or "all" criterion
should be used.  Perhaps that's desired :)

[Ballot comment]
I support Roman and Eric's DISCUSS points.

I also found:
"Note that some transport encapsulations (e.g., IPsec) only provide hop-by-hop security between two SFC data plane elements (e.g., two Service Function Forwarders (SFFs), SFF to SF) and do not provide SF-to-SF security of NSH metadata.  For example, if IPsec is used, SFFs or SFs within a Service Function Path (SFP) that are not authorized to access the privacy-sensitive metadata will have access to the metadata."
to be incredibly hard to read/parse. I think that my confusion comes in around the "that are not authorized to access the privacy-sensitive metadata will have access to the metadata." test, and thing that the last sentence should be rewritten to start with "Because IPsec does not... it exposes privacy-sensitive metadata to..."

Also, thanks to Jürgen Schönwälder for the OpsDir review, and to the authors for addressing the comments.

[Ballot discuss]
** Section 4.6.  This section explains that an upper NSH can be encapsulated in a lower NSH, and that “the Upper-NSH information is carried along the lower-level chain without modification.”  I read this to mean that the upper and lower NSH can independently be protected with different keys.  The text even helpfully points out that “Keying material used at the upper-level domain SHOULD NOT be the same as the one used by a lower-level domain.”  Such a construct suggests that there are multiple MAC/Encrypted Metadata context headers, one for the upper and another for the lower.  However, Section 7.1 later notes that “Only one instance of "MAC and Encrypted Metadata" Context Header (Section 5) is allowed.”  This seems like conflict.  What am I missing?

** Section 7.2.  On computing the HMAC in an integrity only situation:

-- This section defines the MAC as “T = HMAC-SHA-256-128(MAC_KEY, A)”.  Previously, A was defined as the Additional Authenticated Data (per Section 4.2).  Since this isn’t the AEAD use case, there is no A. It seems that this should be something closer to: “T = HMAC-SHA-256-128(MAC_KEY, )”.

-- The text would benefit from a description on how to serialize the packet for hashing.  For example, Figure 6 and 7 are helpful logical descriptions of the integrity scope.  However, the MAC field itself is depicted as part of the what should get hashed.  Should that field be zeroed out? Removed?

** Section 9.
  The attacks discussed in [I-D.nguyen-sfc-security-architecture] are
  handled owing to the solution specified in this document, except for
  attacks dropping packets. 

The above reference highlights the following attackers – “There are many types of compromised switches attack: packet dropping, packet duplicating, packet manipulating, incorrect forwarding,  eavesdropping, weight adjusting, man-in-the-middle, state-spoofing, control-channel hijacking, etc.”  Per the security services in this document, it doesn’t seem like all are mitigated by this draft as described above:

-- packet dropping = noted as not being handled

-- packet manipulating, eavesdropping, weight adjusting, man-in the-middle, state-spoofing, and control-channel hijacking = appear to be handled if both security services are applied

-- packet duplicating = this draft doesn’t not provide a standardized approach for mitigating this issue

-- incorrect forwarding = doesn’t appear to be mitigated.

[Ballot comment]
** Section 1.
  Thus, the NSH
  does not have to rely upon an underlying transport encapsulation for
  security and confidentiality.

Isn’t confidentiality just a subset of the provided security properties, or is something else intended?  Recommend s/for security and confidentiality/for security/

** Section 2.  Per “Key Identifier:  Is used to identify and deliver keys to authorized entities.  See, for example, 'kid' usage in [RFC7635]”. How does a key identifier “delivery keys”?  Doesn’t another protocol provide the delivery using the kid as an identifier?

** Section 7.2.  How does one serialize the packet data to construct A?  Figure 7 is the closest guidance but it includes the MAC itself.

** Section 7.4.
  … legitimate duplicate packets will be
  tagged by NSH-aware nodes involved in that segment as replay packets
  unless sufficient entropy is added to the duplicate packet.

What is the prescribed mechanism to add entropy?

** Section 7.5
  When an SFC data plane element receives an NSH packet, it MUST first
  ensure that a "MAC and Encrypted Metadata" Context Header is
  included. 

I was under the impression that the security protections specified in this document were optional in the overall SFC architecture.  Is there some caveat to add to this section to reminder readers?  Perhaps,  “When an SFC data plan element conforms to this specification, it MUST first …”

** Section 7.5 and 7.6.  What is the error processing for receiving a packet with an unknown key identifier?

** Section 9. Section 9.  Can you further clarify how is the reader supposed to interpret the guidance in RFC4107 which frames its scope as guidelines as to be “... use[d] by IETF working groups and protocol authors who are determining whether to mandate automated key    management and whether manual key management is acceptable.  Informed judgment is needed.”  Does this document take a position on automated vs. manual key management?

** Section 9.  Per “The secret key (K) must have an expiration time assigned …”:

(I suspect many of these issues are out of scope …)

-- who assigns that expiration time (the key management system)?

-- who knows about that expiration time, is it both the key management system and the participating nodes?  If the nodes know the expiration time, should they refuse to decrypt a message with an expired key?  This check of expiration is not the Section 7.5 or 7.6 procedures.

** Section 9.  In the spirit of inclusive language, please s/A man-in-the-middle/An on-path-attacker/

** Section 9. 
  In an SFC-enabled domain where the above attacks are possible, (1)
  NSH data MUST be integrity-protected and replay-protected, and (2)
  privacy-sensitive NSH metadata MUST be encrypted for confidentiality
  preservation purposes.

Related to the COMMENTs raised by Lars and Alvaro.

It’s my understanding that the security protections here are optional for the SFC architecture – is this correct?  If so, I don’t follow the above guidance.  With the exception of “data carried in the context headers having privacy sensitive information”, all SFC-enabled domains have the potential for the above described attacks.  It seems like this document is helpfully making integrity, replay and encrypted meta-data a requirement for the entire SFC architecture (without explicitly updating RFC8300)

** Section 9.1
  An active attacker can potentially modify the Base header (e.g.,
  decrement the TTL so the next SFF in the SFP discards the NSH
  packet).  In the meantime, an active attacker can also drop NSH
  packets.

The phrase “In the meantime …” suggests that these two active attackers are coordinating.  Both of these sentences seem to be describing independent attackers.

==[ Editorial
** Abstract.  Typo.  This sentence doesn’t parse.
OLD
Also,
  this specification allows to encrypt sensitive metadata that is
  carried in the NSH.

NEW
Also, this specification allows for the encryption of sensitive metadata  that is carried in the NSH.

** Section 1.  Editorial. s/to is an information/to is information/

** Section 1.  Editorial.  s/This specification fills that gap/This specification fills that gap for SFC/

** Section 1.  Editorial.  s/This specification limits thus access/This specification limits access/

** Section 3.  Editorial.  s/The NSH allows to share/The NSH shares/

** Section 4.1.2.  Editorial.  s/SFFs are not thus provided/SFFs are not provided/

** Section 4.2. Editorial.  Recommend being clearer on the section – s/The authenticated encryption algorithm defined in [RFC7518]/ The authenticated encryption algorithm defined in Section 5.2 of [RFC7518]/; or you could name the algorithm directly with the reference.

** Section 4.4. Editorial. s/Doing so allows to address the problem/Doing so addresses the problem/

[Ballot discuss]
Thank you for the work put into this document.

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

Please find below some blocking DISCUSS point (which should be easy to fix), some non-blocking COMMENT points (but replies would be appreciated), and one nit.

I hope that this helps to improve the document,

Regards,

-éric


== DISCUSS ==

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 ?

[Ballot comment]

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 ?

[Ballot comment]
Thanks for the efforts on this specification.

I have following non-blocking comments those I believe would improve the document if addressed --

* I agree with Alvaro and Lars's comment about updating 8300. Would like to get response(s) to their comments.

* I think it will be helpful to explicitly mention if integrity and confidentiality by the transport encapsulation is needed or not when this specification is in use. This specification definitely says that one does not need to relay on the service provided by the transport encapsulation but it does not says that those services are not longer required. 

* Section 1 : says -
    "This specification fills that gap.  Concretely, this document adds
  integrity protection and optional encryption of sensitive metadata
  directly to the NSH (Section 4);"
 
  Does this specification extends the use of NSH in multiple SFC domain? My little understanding of NSH says it is SFC domain specific and within one SFC domain the devices a vetted to be trusted. I think it will be very helpful to add zest from the section 3.2.1. of I-D.arkko-farrell-arch-model-t here.

* Section 6 :

  The epoch is 1970-01-01T00:00Z in UTC time.  Note this epoch value
      is different from the one used in Section 6 of [RFC5905].
 
  It would be great if we can add the implications of the difference. Now I don't know what it means.

[Ballot comment]
[S7.{2,3}] [question]

* Is the timestamp a part of the input to the MAC/encrypted metadata
  generation?  If so, perhaps consider adding an explicit mention
  (perhaps I missed it).

  For that matter, I can't quite tell of some normalized version of the
  MAC#1/2 header overall is part of the input to the MAC/AAD generation
  or not.

[Ballot comment]
Two nits:

Section 3 frequently uses the passive voice (“is instructed” “may be instructed”) and that makes it hard to understand who is doing the instruction. Please add subjects to at least the first of these sentences.

You frequently use the structure “allows to [verb]”. There are many ways to fix this gramatically, but recommend simply deleting “allows to” and conjugating the verb correctly.

[Ballot comment]

(1) Given the required behavior specified in the Security Considerations section...

  NSH data are exposed to several threats:

  o  A man-in-the-middle attacker modifying the NSH data.

  o  Attacker spoofing the NSH data.

  o  Attacker capturing and replaying the NSH data.

  o  Data carried in Context Headers revealing privacy-sensitive
      information to attackers.

  o  Attacker replacing the packet on which the NSH is imposed with a
      bogus packet.

  In an SFC-enabled domain where the above attacks are possible, (1)
  NSH data MUST be integrity-protected and replay-protected, and (2)
  privacy-sensitive NSH metadata MUST be encrypted for confidentiality
  preservation purposes.  The Base and Service Path headers are not
  encrypted.


Why doesn't this document formally update rfc8300?  Concerns that eventually led to this solution have been expressed for several other documents, including rfc8459 and rfc8979.

It looks like the WG didn't consider the question of Updating the base NSH specification.  I believe that this document specifies a required update to NSH, and would like the WG to consider formally Updating rfc8300.  [My search of the archive didn't find any related discussion -- did I miss it?]

[Even though I consider this omission a serious oversight, I don't think this issue raises to the level of a DISCUSS.]


(2) §3: I find the use of normative language to describe requirements (that are met in this same document) not the best use of rfc2119 language because any interoperability concerns would result from the specification itself and not the requirements.

The use of rfc2119 keywords to describe requirements may result in confusion.  For example, "The solution MAY provide integrity protection for the Base Header." -- as described later, protecting the Base Header is optional, but the solution *does* provide integrity protection for it.  IOW, the specification is what is reflected in the requirement, but referring to the solution, not the protection: providing integrity protection is not optional, using it is.  A better working would be: "The solution must provide optional integrity protection for the Base Header."

[Ballot comment]
Section 1. , paragraph 6, comment:
>    This specification fills that gap.  Concretely, this document adds
>    integrity protection and optional encryption of sensitive metadata
>    directly to the NSH (Section 4); integrity protects the packet
>    payload and provides replay protection (Section 7.4).  Thus, the NSH
>    does not have to rely upon an underlying transport encapsulation for
>    security and confidentiality.

Given that, I am surprised this document doesn't formally update RFC8300?

Section 6. , paragraph 16, comment:
>      This timestamp format is affected by leap seconds.  The timestamp
>      represents the number of seconds elapsed since the epoch minus the
>      number of leap seconds.

Any particular reason why leap seconds are being excluded here? This is unusual
and also requires care with synchronized clocks (as identified below).

Found terminology that should be reviewed for inclusivity:
* Term "master"; alternatives might be "active", "central", "initiator",
  "leader", "main", "orchestrator", "parent", "primary", "server".
* Term "man"; alternatives might be "individual", "people", "person".
See https://www.rfc-editor.org/part2/#inclusive_language for background and
more guidance.

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

"SFC ", paragraph 2, nit:
>  Also, this specification allows to encrypt sensitive metadata that is carrie
>                                  ^^^^^^^^^^
Did you mean "encrypting"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 2. , paragraph 7, nit:
> ng a service path. The NSH allows to share context information (a.k.a., metad
>                                  ^^^^^^^^
Did you mean "sharing"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 9. , paragraph 10, nit:
> ts This document was edited as a follow up to the discussion in IETF#104: ht
>                                  ^^^^^^^^^
This noun is spelled as one word.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-sfc-nsh-integrity-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the NSH IETF-Assigned Optional Variable-Length Metadata Types registry on the Network Service Header (NSH) Parameters registry page located at:

https://www.iana.org/assignments/nsh/

two new registrations are to be made as follows:

Value: [ TBD-at-Registration ]
Description: MAC and Encrypted Metadata #1
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: MAC and Encrypted Metadata #2
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-06-30):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sfc-nsh-integrity@ietf.org, gregimirsky@gmail.com, martin.vigoureux@nokia.com, sfc-chairs@ietf.org, sfc@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers) to Proposed Standard


The IESG has received a request from the Service Function Chaining WG (sfc)
to consider the following document: - 'Integrity Protection for the Network
Service Header (NSH) and
  Encryption of Sensitive Context Headers'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-06-30. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification adds integrity protection directly to the Network
  Service Header (NSH) used for Service Function Chaining (SFC).  Also,
  this specification allows to encrypt sensitive metadata that is
  carried in the NSH.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7665: Service Function Chaining (SFC) Architecture (Informational - Internet Engineering Task Force (IETF))

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

Shepherd Write-Up. Changes are expected over time.

(1) The document is on the Proposed Standard track that is the appropriate direction for the document.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  The document adds the integrity protection mechanism directly to the Network Service Header (NSH) used for Service Function Chaining (SFC).  Also, the document describes how to encrypt sensitive metadata that is carried in the NSH.

Working Group Summary:

The work on the draft was started as a follow-up to the discussion during the SFC WG meeting at IETF-104: https://datatracker.ietf.org/meeting/104/materials/slides-104-sfc-sfc-chair-slides-01 (slide 7). The draft was first submitted in October 2019, has been reviewed by a reasonable number of people in the SFC working group, which is reflected in the Acknowledgment section. Publication of the draft received a fair number of supporters and no objections from the working group.
Two early SecDir reviews were requested for the document. All raised issues were resolved.

No IPR disclosures have been filed that reference this document at any time. All authors have stated that none of them is aware of any IPR related to the draft.

The working group is solidly behind this document.

Document Quality:

The current version of the draft is clear, seems to have resolved all the issues, and has the consensus of the working group.

Personnel:

Who is the Document Shepherd for this document? Greg Mirsky
Who is the Responsible Area Director? Martin Vigoureux


(3) The Document Shepherd reviewed and shared his comments with the authors and the WG. All the comments were addressed.

(4) The document has been thoroughly reviewed by SFC experts.

(5) The Document Shepherd doesn't see the need for any specific review of the document.

(6) The Document Shepherd has no concerns with any part of the document.

(7) All authors have stated that none of them is aware of any IPR related to the draft.

(8) No IPR disclosures have been filed that reference this document at any time.

(9) The working group is solidly behind this document.

(10) There was no opposition to progressing this document.

(11) The document is ID nits free.

(12) The document does not require MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) All the references are properly listed in the normative and informative lists.

(14) No document has normative reference dependency on this document.

(15) The document includes a downward reference to RFC 7665 SFC Architecture. That is reasonable, as a reader is expected to be familiar with SFC's principles and elements.

(16) The publication of this document does not update any published RFC.

(17) The document requests IANA to allocate two types from the "NSH IETF-Assigned Optional Variable-Length Metadata Types".

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

Shepherd Write-Up. Changes are expected over time.

(1) The document is on the Proposed Standard track that is the appropriate direction for the document.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  The document adds the integrity protection mechanism directly to the Network Service Header (NSH) used for Service Function Chaining (SFC).  Also, the document describes how to encrypt sensitive metadata that is carried in the NSH.

Working Group Summary:

The work on the draft was started as a follow-up to the discussion during the SFC WG meeting at IETF-104: https://datatracker.ietf.org/meeting/104/materials/slides-104-sfc-sfc-chair-slides-01 (slide 7). The draft was first submitted in October 2019, has been reviewed by a reasonable number of people in the SFC working group, which is reflected in the Acknowledgment section. Publication of the draft received a fair number of supporters and no objections from the working group.
Two early SecDir reviews were requested for the document. All raised issues were resolved.

No IPR disclosures have been filed that reference this document at any time. All authors have stated that none of them is aware of any IPR related to the draft.

The working group is solidly behind this document.

Document Quality:

The current version of the draft is clear, seems to have resolved all the issues, and has the consensus of the working group.

Personnel:

Who is the Document Shepherd for this document? Greg Mirsky
Who is the Responsible Area Director? Martin Vigoureux


(3) The Document Shepherd reviewed and shared his comments with the authors and the WG. All the comments were addressed.

(4) The document has been thoroughly reviewed by SFC experts.

(5) The Document Shepherd doesn't see the need for any specific review of the document.

(6) The Document Shepherd has no concerns with any part of the document.

(7) All authors have stated that none of them is aware of any IPR related to the draft.

(8) No IPR disclosures have been filed that reference this document at any time.

(9) The working group is solidly behind this document.

(10) There was no opposition to progressing this document.

(11) The document is ID nits free.

(12) The document does not require MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) All the references are properly listed in the normative and informative lists.

(14) No document has normative reference dependency on this document.

(15) The document includes a downward reference to RFC 7665 SFC Architecture. That is reasonable, as a reader is expected to be familiar with SFC's principles and elements.

(16) The publication of this document does not update any published RFC.

(17) The document requests IANA to allocate two types from the "NSH IETF-Assigned Optional Variable-Length Metadata Types".

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

Shepherd Write-Up. Changes are expected over time.

(1) The document is on the Proposed Standard track that is the appropriate direction for the document.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Technical Summary:

  The document adds the integrity protection mechanism directly to the Network Service Header (NSH) used for Service Function Chaining (SFC).  Also, the document describes how to encrypt sensitive metadata that is carried in the NSH.

Working Group Summary:

The draft was first submitted in October 2019, has been reviewed by a reasonable number of people in the SFC working group, which is reflected in the Acknowledgment
section. Publication of the draft received a fair number of supporters and no objections from the working group.

No IPR disclosures have been filed that reference this document at any time. All authors have stated that none of them is aware of any IPR related to the draft.

The working group is solidly behind this document.

Document Quality:

The current version of the draft is clear, seems to have resolved all the issues, and has the consensus of the working group.

Personnel:

Who is the Document Shepherd for this document? Greg Mirsky
Who is the Responsible Area Director? Martin Vigoureux


(3) The Document Shepherd reviewed and shared his comments with the authors and the WG. All the comments were addressed.

(4) The document has been thoroughly reviewed by SFC experts.

(5) The Document Shephard doesn't see the need for any specific review of the document.

(6) The Document Shepherd has no concerns with any part of the document.

(7) All authors have stated that none of them is aware of any IPR related to the draft.

(8) No IPR disclosures have been filed that reference this document at any time.

(9) The working group is solidly behind this document.

(10) There was no opposition to progressing this document.

(11) The document is ID nits free.

(12) The document does not require MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) All the references are properly listed in the normative and informative lists.

(14) No document has normative reference dependency on this document.

(15) The document includes a downward reference to RFC 7665 SFC Architecture. That is reasonable, as a reader is expected to be familiar with SFC's principles and elements.

(16) The publication of this document does not update any published RFC.

(17) The document requests IANA to allocate two types from the "NSH IETF-Assigned Optional Variable-Length Metadata Types".

Thank you.  This document has completed WG Last Call successfully.  Thanks to the authors for promptly addressing comments raised during that last call.
We will now pick a document shepherd, and in parallel ask for an update security review.

This starts the SFC Working Group last call for the NSH integrity protection document.  This will run through the end of the day February 11, 2021.  (Don't worry about time zone.  If it is still Feb 11 2021 somewhere in the world, you can send in comments.)  Please respond.  Silence is not consent, and when (if, but we hope when) we send this to the AD, we need to be able to describe meaningful WG support for the publication.  And if possible, more than just +1. 

Thank you,
Joel (and Jim)