Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Ben, 

Thank you for the review. Much appreciated. 

Starting with the easy part (NITS) as we need more time to think about your point(0) and its impact on many COMMENT points. 

FYI, we used to have a discussion on AES-GCM in the past, but we went for the current design as we wanted to impose by design the separation between entities that access the encrypted data and avoid the extra 128 bits overhead. There was also a discussion about the parallelization provided by separating the two operations.  

Anyway, we will follow SOON on the DISCUSS and COMMENT parts with concrete proposals to hopefully fix them. 

The changes can be tracked at: https://tinyurl.com/nsh-integrity-latest 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk via Datatracker [mailto:[e-mail]]
> Envoyé : mercredi 14 juillet 2021 23:26
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-integrity-06:
> (with DISCUSS and COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-sfc-nsh-integrity-06: Discuss
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/
> 
> 
[..]
> 
> --------------------------------------------------------------------
> --
> COMMENT:
> --------------------------------------------------------------------
> --
> 
[..]
> 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"

[Med] s/their/its


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

[Med] OK to start a new sentence. 

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

[Med] Yes. 

> 
> 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)?

[Med] Yes, changed to "upper-level". 

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

[Med] Fixed, but that I'm afraid that we will touch this once we fix your discuss point (0).

 ("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/
> 

[Med] Fixed. 

> Section 6
> 
>       The epoch is 1970-01-01T00:00Z in UTC time.  [...]
> 
> (IIUC, the "in UTC time" is redundant with the trailing 'Z'.)

[Med] Right. 

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

[Med] Made these changes: 

s/affecting/that affect
s/depend/depending/

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

[Med] Fixed. 

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

[Med] Works for me. Fixed.

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

[Med] Added. 

> 
>    o  Attacker replacing the packet on which the NSH is imposed with
> a
>       bogus packet.
> 
> I'd probably say "modified or bogus".

[Med] Fixed. 

> 
>    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 :)
> 

[Med] I think you got it :-)


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.