Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers
draft-ietf-sfc-nsh-integrity-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-12-09
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-11-18
|
09 | (System) | RFC Editor state changed to AUTH48 |
2021-10-14
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-09-23
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-09-22
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-09-22
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-09-22
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-09-21
|
09 | Luc André Burdet | Request closed, assignment withdrawn: Andy Smith Early RTGDIR review |
2021-09-21
|
09 | Luc André Burdet | Request closed, assignment withdrawn: Harish Sitaraman Early RTGDIR review |
2021-09-21
|
09 | Luc André Burdet | Closed request for Early review by RTGDIR with state 'Overtaken by Events': Review no longer needed (currently in RFC Ed queue) |
2021-09-20
|
09 | (System) | RFC Editor state changed to EDIT |
2021-09-20
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-09-20
|
09 | (System) | Announcement was received by RFC Editor |
2021-09-20
|
09 | (System) | IANA Action state changed to In Progress |
2021-09-20
|
09 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-09-20
|
09 | Cindy Morgan | IESG has approved the document |
2021-09-20
|
09 | Cindy Morgan | Closed "Approve" ballot |
2021-09-20
|
09 | (System) | Removed all action holders (IESG state changed) |
2021-09-20
|
09 | Martin Vigoureux | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2021-09-20
|
09 | Martin Vigoureux | Ballot approval text was generated |
2021-09-20
|
09 | Mohamed Boucadair | New version available: draft-ietf-sfc-nsh-integrity-09.txt |
2021-09-20
|
09 | (System) | New version approved |
2021-09-20
|
09 | (System) | Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Dan Wing , Mohamed Boucadair |
2021-09-20
|
09 | Mohamed Boucadair | Uploaded new revision |
2021-09-18
|
08 | Roman Danyliw | [Ballot comment] Thanks for addressing my COMMENT and DISCUSS items. |
2021-09-18
|
08 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2021-09-14
|
08 | Benjamin Kaduk | [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 … [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. |
2021-09-14
|
08 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2021-09-13
|
08 | Éric Vyncke | [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 … [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 ? |
2021-09-13
|
08 | Éric Vyncke | [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss |
2021-09-05
|
08 | Haomian Zheng | Request for Early review by RTGDIR is assigned to Andy Smith |
2021-09-05
|
08 | Haomian Zheng | Request for Early review by RTGDIR is assigned to Andy Smith |
2021-09-02
|
08 | Haomian Zheng | Request for Early review by RTGDIR is assigned to Harish Sitaraman |
2021-09-02
|
08 | Haomian Zheng | Request for Early review by RTGDIR is assigned to Harish Sitaraman |
2021-09-02
|
08 | Haomian Zheng | Assignment of request for Early review by RTGDIR to Christian Hopps was marked no-response |
2021-08-18
|
08 | Tirumaleswar Reddy.K | New version available: draft-ietf-sfc-nsh-integrity-08.txt |
2021-08-18
|
08 | (System) | New version accepted (logged-in submitter: Tirumaleswar Reddy.K) |
2021-08-18
|
08 | Tirumaleswar Reddy.K | Uploaded new revision |
2021-07-29
|
07 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Overtaken by Events' |
2021-07-29
|
07 | Jean Mahoney | Assignment of request for Last Call review by GENART to Jouni Korhonen was marked no-response |
2021-07-26
|
07 | Murray Kucherawy | [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: … [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/ |
2021-07-26
|
07 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss |
2021-07-26
|
07 | (System) | Changed action holders to Martin Vigoureux (IESG state changed) |
2021-07-26
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-07-26
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-07-26
|
07 | Tirumaleswar Reddy.K | New version available: draft-ietf-sfc-nsh-integrity-07.txt |
2021-07-26
|
07 | (System) | New version accepted (logged-in submitter: Tirumaleswar Reddy.K) |
2021-07-26
|
07 | Tirumaleswar Reddy.K | Uploaded new revision |
2021-07-25
|
06 | Joseph Touch | Request for Last Call review by TSVART Completed: Not Ready. Reviewer: Joseph Touch. Sent review to list. |
2021-07-15
|
06 | (System) | Changed action holders to Dan Wing, Martin Vigoureux, Mohamed Boucadair, Tirumaleswar Reddy.K (IESG state changed) |
2021-07-15
|
06 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2021-07-15
|
06 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-07-14
|
06 | Murray Kucherawy | [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 … [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? |
2021-07-14
|
06 | Murray Kucherawy | [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 … [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/ |
2021-07-14
|
06 | Murray Kucherawy | [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy |
2021-07-14
|
06 | John Scudder | [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 … [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. |
2021-07-14
|
06 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2021-07-14
|
06 | Benjamin Kaduk | [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 … [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. |
2021-07-14
|
06 | Benjamin Kaduk | [Ballot comment] Section 3 o Both encrypted and unencrypted Context Headers MAY be included in the same NSH. That is, some … [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 :) |
2021-07-14
|
06 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2021-07-14
|
06 | Warren Kumari | [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 … [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. |
2021-07-14
|
06 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2021-07-14
|
06 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2021-07-13
|
06 | Roman Danyliw | [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 … [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. |
2021-07-13
|
06 | Roman Danyliw | [Ballot comment] ** Section 1. Thus, the NSH does not have to rely upon an underlying transport encapsulation for security and confidentiality. … [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/ |
2021-07-13
|
06 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2021-07-13
|
06 | Éric Vyncke | [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 … [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 ? |
2021-07-13
|
06 | Éric Vyncke | [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 … [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 ? |
2021-07-13
|
06 | Éric Vyncke | [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke |
2021-07-13
|
06 | Zaheduzzaman Sarker | [Ballot Position Update] Position for Zaheduzzaman Sarker has been changed to No Objection from No Record |
2021-07-13
|
06 | Zaheduzzaman Sarker | [Ballot comment] Thanks for the efforts on this specification. I have following non-blocking comments those I believe would improve the document if addressed -- * … [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. |
2021-07-13
|
06 | Zaheduzzaman Sarker | Ballot comment text updated for Zaheduzzaman Sarker |
2021-07-12
|
06 | Erik Kline | [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 … [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. |
2021-07-12
|
06 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-07-12
|
06 | Martin Duke | [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 … [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. |
2021-07-12
|
06 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2021-07-12
|
06 | Alvaro Retana | [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 … [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." |
2021-07-12
|
06 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2021-07-12
|
06 | Lars Eggert | [Ballot comment] Section 1. , paragraph 6, comment: > This specification fills that gap. Concretely, this document adds > integrity protection and optional … [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. |
2021-07-12
|
06 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2021-07-07
|
06 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-07-07
|
06 | Cindy Morgan | Placed on agenda for telechat - 2021-07-15 |
2021-07-07
|
06 | Martin Vigoureux | Ballot has been issued |
2021-07-07
|
06 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2021-07-07
|
06 | Martin Vigoureux | Created "Approve" ballot |
2021-07-07
|
06 | Martin Vigoureux | IESG state changed to IESG Evaluation from Waiting for Writeup |
2021-07-07
|
06 | Martin Vigoureux | Ballot writeup was changed |
2021-07-02
|
06 | Martin Vigoureux | Changed document external resources from: to: github_repo https://github.com/boucadair/draft-ietf-sfc-nsh-integrity |
2021-07-01
|
06 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-07-01
|
06 | Mohamed Boucadair | New version available: draft-ietf-sfc-nsh-integrity-06.txt |
2021-07-01
|
06 | (System) | New version approved |
2021-07-01
|
06 | (System) | Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Dan Wing , Mohamed Boucadair , sfc-chairs@ietf.org |
2021-07-01
|
06 | Mohamed Boucadair | Uploaded new revision |
2021-06-30
|
05 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2021-06-28
|
05 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2021-06-28
|
05 | Sabrina Tanamal | (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 … (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 |
2021-06-25
|
05 | Jürgen Schönwälder | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Jürgen Schönwälder. Sent review to list. |
2021-06-24
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jouni Korhonen |
2021-06-24
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jouni Korhonen |
2021-06-24
|
05 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Joseph Touch |
2021-06-24
|
05 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Joseph Touch |
2021-06-22
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder |
2021-06-22
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder |
2021-06-18
|
05 | Luc André Burdet | Request for Early review by RTGDIR is assigned to Christian Hopps |
2021-06-18
|
05 | Luc André Burdet | Request for Early review by RTGDIR is assigned to Christian Hopps |
2021-06-16
|
05 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2021-06-16
|
05 | Cindy Morgan | 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 … 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)) |
2021-06-16
|
05 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2021-06-16
|
05 | Martin Vigoureux | Requested Early review by RTGDIR |
2021-06-16
|
05 | Martin Vigoureux | Last call was requested |
2021-06-16
|
05 | Martin Vigoureux | Ballot approval text was generated |
2021-06-16
|
05 | Martin Vigoureux | Ballot writeup was generated |
2021-06-16
|
05 | Martin Vigoureux | IESG state changed to Last Call Requested from AD Evaluation |
2021-06-16
|
05 | Martin Vigoureux | Last call announcement was generated |
2021-06-07
|
05 | (System) | Changed action holders to Martin Vigoureux (IESG state changed) |
2021-06-07
|
05 | Martin Vigoureux | IESG state changed to AD Evaluation from Publication Requested |
2021-03-24
|
05 | Joel Halpern | Changed consensus to Yes from Unknown |
2021-03-24
|
05 | Joel Halpern | Intended Status changed to Proposed Standard from None |
2021-03-24
|
05 | Joel Halpern | 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 … 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". |
2021-03-24
|
05 | Joel Halpern | Responsible AD changed to Martin Vigoureux |
2021-03-24
|
05 | Joel Halpern | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2021-03-24
|
05 | Joel Halpern | IESG state changed to Publication Requested from I-D Exists |
2021-03-24
|
05 | Joel Halpern | IESG process started in state Publication Requested |
2021-03-24
|
05 | Greg Mirsky | 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 … 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". |
2021-03-24
|
05 | Greg Mirsky | 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 … 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". |
2021-03-23
|
05 | Mohamed Boucadair | New version available: draft-ietf-sfc-nsh-integrity-05.txt |
2021-03-23
|
05 | (System) | New version approved |
2021-03-23
|
05 | (System) | Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Dan Wing , Mohamed Boucadair , sfc-chairs@ietf.org |
2021-03-23
|
05 | Mohamed Boucadair | Uploaded new revision |
2021-03-14
|
04 | Steve Hanna | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Steve Hanna. Sent review to list. |
2021-02-25
|
04 | Jim Guichard | Notification list changed to gregimirsky@gmail.com because the document shepherd was set |
2021-02-25
|
04 | Jim Guichard | Document shepherd changed to Greg Mirsky |
2021-02-18
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Steve Hanna |
2021-02-18
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Steve Hanna |
2021-02-18
|
04 | Joel Halpern | Requested Last Call review by SECDIR |
2021-02-18
|
04 | Joel Halpern | 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 … 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. |
2021-02-18
|
04 | Joel Halpern | Tag Doc Shepherd Follow-up Underway set. |
2021-02-18
|
04 | Joel Halpern | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2021-02-16
|
04 | Mohamed Boucadair | New version available: draft-ietf-sfc-nsh-integrity-04.txt |
2021-02-16
|
04 | (System) | New version approved |
2021-02-16
|
04 | (System) | Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Dan Wing , Mohamed Boucadair , sfc-chairs@ietf.org |
2021-02-16
|
04 | Mohamed Boucadair | Uploaded new revision |
2021-01-28
|
03 | Joel Halpern | 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, … 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) |
2021-01-28
|
03 | Joel Halpern | IETF WG state changed to In WG Last Call from WG Document |
2021-01-22
|
03 | Mohamed Boucadair | New version available: draft-ietf-sfc-nsh-integrity-03.txt |
2021-01-22
|
03 | (System) | New version approved |
2021-01-22
|
03 | (System) | Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Dan Wing , Mohamed Boucadair , sfc-chairs@ietf.org |
2021-01-22
|
03 | Mohamed Boucadair | Uploaded new revision |
2021-01-07
|
02 | Mohamed Boucadair | New version available: draft-ietf-sfc-nsh-integrity-02.txt |
2021-01-07
|
02 | (System) | New version approved |
2021-01-07
|
02 | (System) | Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Dan Wing , Mohamed Boucadair , sfc-chairs@ietf.org |
2021-01-07
|
02 | Mohamed Boucadair | Uploaded new revision |
2020-12-24
|
01 | Steve Hanna | Request for Early review by SECDIR Completed: Has Issues. Reviewer: Steve Hanna. Sent review to list. |
2020-11-26
|
01 | Tero Kivinen | Request for Early review by SECDIR is assigned to Steve Hanna |
2020-11-26
|
01 | Tero Kivinen | Request for Early review by SECDIR is assigned to Steve Hanna |
2020-11-24
|
01 | Joel Halpern | Requested Early review by SECDIR |
2020-11-16
|
01 | Mohamed Boucadair | New version available: draft-ietf-sfc-nsh-integrity-01.txt |
2020-11-16
|
01 | (System) | New version approved |
2020-11-16
|
01 | (System) | Request for posting confirmation emailed to previous authors: sfc-chairs@ietf.org, "Tirumaleswar Reddy.K" , Mohamed Boucadair , Dan Wing |
2020-11-16
|
01 | Mohamed Boucadair | Uploaded new revision |
2020-06-19
|
00 | Jim Guichard | This document now replaces draft-rebo-sfc-nsh-integrity instead of None |
2020-06-19
|
00 | Mohamed Boucadair | New version available: draft-ietf-sfc-nsh-integrity-00.txt |
2020-06-19
|
00 | (System) | WG -00 approved |
2020-06-18
|
00 | Mohamed Boucadair | Set submitter to "Mohamed Boucadair ", replaces to draft-rebo-sfc-nsh-integrity and sent approval email to group chairs: sfc-chairs@ietf.org |
2020-06-18
|
00 | Mohamed Boucadair | Uploaded new revision |