Subject: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Mon, 12 Jul 2021 11:36:22 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-sfc-nsh-integrity-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

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

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

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

---

From: <[email-masked]>
Date: Mon, 12 Jul 2021 18:52:20 +0000

Hi Alvaro, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Alvaro Retana via Datatracker [mailto:[email-masked]]
> Envoyé : lundi 12 juillet 2021 20:36
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Objet : Alvaro Retana's No Objection on draft-ietf-sfc-nsh-
> integrity-06: (with COMMENT)
> 
> 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.)
> 
> 
> (1) Given the required behavior specified in the Security
> Considerations section...
> 
> 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?]

[Med] We don't use the update header as we don't formally update any text in 8300. I know that we can interpret the update as "amends", but unless I'm mistaken there is no formal IETF consensus on this. 

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

[Med] Good point. Fixed. Thanks.

_________________________________________________________________________________________________________________________

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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 12 Jul 2021 15:23:25 -0400

I find your description of this as a "required update to 8300" rather 
odd.  The working group did not agree to make implementation of this 
mandatory for 8300.  That would, indeed, be an update to 8300.   This is 
just another feature that can be used with NSH.  A useful feature.

The security considerations do give lots of reasons to do this. But that 
is not the same as making it "required" for all implementations of 8300.

Yours,
Joel

On 7/12/2021 2:36 PM, Alvaro Retana via Datatracker wrote:
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 12 Jul 2021 12:26:45 -0700

On July 12, 2021 at 2:52:22 PM, [email-masked] wrote:

Med:

Hi!

...
> > eventually led to this solution have been expressed for several other
> > documents, including rfc8459 and rfc8979.
> >
> [Med] We don't use the update header as we don't formally update any text
> in 8300.

Updating text is not the only reason to formally Update another specification.

This document requires the use of both integrity and encryption if
specific attacks are possible (text above).  It is reasonable to
interpret that as cases where the "operator deems protection is
required", which is the text that rfc8300 uses when it talks about the
need for integrity protection (similar text can also be found about
encryption).  IOW, the formal Update that I'm suggesting here is to
provide more insight into when integrity protection and encryption are
required, and the mechanism to use.

As I look into this further, I believe there is a normative
inconsistency between this document and rfc8300:

- rfc8300 requires the use of an encapsulating transport protocol that
can provide integrity protection and/or encryption, as needed.

- This document requires protection as specified in the text above.  A
stated goal of this specification is so that "the NSH does not have to
rely upon an underlying transport encapsulation for security and
confidentiality".

The outcome is that the requirements in rfc8300 would result in not
using this specification.

> I know that we can interpret the update as "amends", but unless I'm mistaken
> there is no formal IETF consensus on this.

True.

Without at least some text explaining the relationship between the
requirements in this document and how they may be considered instead
of the ones in rfc8300, I don't think this document is complete.  For
better or worse, the only tool we have right now to make that link
clear is the Updates tag.

Thanks!

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 12 Jul 2021 12:29:23 -0700

Joel:

Hi!

I guess I missed where that discussion happened — probably buried in one of
the threads.  Can you please point me to it?

Thanks!

Alvaro.

On July 12, 2021 at 3:23:28 PM, Joel M. Halpern ([email-masked]) wrote:

Yours,
Joel

> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/
eventually

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 12 Jul 2021 15:37:48 -0400

Depending upon what you mean, either

1) The discussion never happened, because the action was not suggested.

or, with a longer view

2) The discussion happened when 8300 was being approved.  We agreed with 
the IESG that we would not define a mandatory-to-implement NSH security 
mechanism, but that we would add an optional NSH security mechanism. 
Which this draft does.

Yours,
Joel

On 7/12/2021 3:29 PM, Alvaro Retana wrote:
> Joel:
> 
> Hi!
> 
> I guess I missed where that discussion happened — probably buried in one 
> of the threads.  Can you please point me to it?
> 
> Thanks!
> 
> Alvaro.
> 
> On July 12, 2021 at 3:23:28 PM, Joel M. Halpern ([email-masked] 
> <mailto:[email-masked]>) wrote:
> 
>> <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>> <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/>
>> >  
>> >  
>> >  
>> > [email-masked] <mailto:[email-masked]>
>> <https://www.ietf.org/mailman/listinfo/sfc>
>> >  
>

---

From: <[email-masked]>
Date: Mon, 12 Jul 2021 19:41:11 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Alvaro Retana [mailto:[email-masked]]
> Envoyé : lundi 12 juillet 2021 21:27
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; The
> IESG <[email-masked]>
> [email-masked]; [email-masked]
> Objet : RE: Alvaro Retana's No Objection on draft-ietf-sfc-nsh-
> > > other documents, including rfc8459 and rfc8979.
> > >
> > [Med] We don't use the update header as we don't formally update
> any
> > text in 8300.
> 
> required", which is the text that rfc8300 uses when it talks about
> the need for integrity protection (similar text can also be found
> about encryption).  IOW, the formal Update that I'm suggesting here
> is to provide more insight into when integrity protection and
> encryption are required, and the mechanism to use.
> 
> 
> - rfc8300 requires the use of an encapsulating transport protocol
> that can provide integrity protection and/or encryption, as needed.
> 
> - This document requires protection as specified in the text
> above.  A stated goal of this specification is so that "the NSH does
> not have to rely upon an underlying transport encapsulation for
> security and confidentiality".
> 

[Med] Not sure about this given that RFC8300 says the following:  

      NSH itself does not mandate protocol-specific integrity
      protection.  However, if an operator deems protection is required,
      several options are viable:

      1.  SFF/SF NSH verification
      ...
      2.  Transport Security
      ...
      3.  NSH Variable Header-Based Integrity

          Lastly, NSH MD Type 2 provides, via variable-length headers,
          the ability to append cryptographic integrity protection to
          the NSH packet.  The implementation of such a scheme is
          outside the scope of this document.

The I-D is basically the third option. 

> 
> > I know that we can interpret the update as "amends", but unless
> I'm
> > mistaken there is no formal IETF consensus on this.
> 
> True.
> 
> of the ones in rfc8300, I don't think this document is
> complete.  For better or worse, the only tool we have right now to
> make that link clear is the Updates tag.
> 
> 
> Thanks!
> 
> Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 12 Jul 2021 13:08:37 -0700

Hi!

I meant the discussion about this draft formally Updating rfc8300 — which I
would have hopped happened when processing/discussing this document (not
before).

I’m assuming that discussion never happened.

BTW, I’m not asking for the new mechanism to be MTI — the current text (at
least to me) reads as if it is not.  I’m ok with that.  [IOW, an Update to
rfc8300 would “inherit” that characteristic.]

Alvaro.

On July 12, 2021 at 3:37:51 PM, Joel M. Halpern ([email-masked]) wrote:

or, with a longer view

Yours,
Joel

On 7/12/2021 3:29 PM, Alvaro Retana wrote:
>> > Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html
>> <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/>
Considerations
eventually
>> > [Even though I consider this omission a serious oversight, I don't
think this
>> > For example, "The solution MAY provide integrity protection for the
Base
>> > protection: providing integrity protection is not optional, using it
is. A

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 12 Jul 2021 13:13:01 -0700

On July 12, 2021 at 3:41:13 PM, [email-masked]
([email-masked] (mailto:[email-masked]))
wrote:

...
> The I-D is basically the third option.

Ok.  Please make it extra obvious that this is the case -- using the
same words would be ideal.

§8.2.2 (Confidentiality) is a lot less clear.

Even though I still think that a formal Update to rfc8300 is the right
thing to do, I would be very happy if there was (at least) some
additional text included to clarify the expected relationship between
the 2 documents.

Thanks!

Alvaro.

> > > I'm mistaken there is no formal IETF consensus on this.
> >
> > True.
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 12 Jul 2021 16:23:57 -0400

I am not at all sure I understand you.

If youa re not arguing that this is somehow mandatory, then maybe you 
are arguing that this changes the security considerations in 8300 about 
transport.  It doesn't.  If it did, then yes, it would indeed update 
8300.  But the working group did not try to modify the transport 
requirements from 8300.  Maybe someone will at some point.  But this 
document doesn't.

If you want it marked "updates" anyway, then I want a strong assurance 
from the IESG that some other AD won't turn around and tell us to remove 
the "updates" tag since the document makes no change to 8300.  With that 
assurance, sure, we can give you a useless "updates" tag.

Yours,
Joel

On 7/12/2021 4:08 PM, Alvaro Retana wrote:
> Hi!
> 
> I meant the discussion about this draft formally Updating rfc8300 — 
> which I would have hopped happened when processing/discussing this 
> document (not before).
> 
> BTW, I’m not asking for the new mechanism to be MTI — the current text 
> (at least to me) reads as if it is not.  I’m ok with that.  [IOW, an 
> Update to rfc8300 would “inherit” that characteristic.]
> 
> Alvaro.
> 
> On July 12, 2021 at 3:37:51 PM, Joel M. Halpern ([email-masked] 
>> > On July 12, 2021 at 3:23:28 PM, Joel M. Halpern ([email-masked] <mailto:[email-masked]>
>> > <mailto:[email-masked] <mailto:[email-masked]>>) wrote:
>> >  
>> >> <https://www.ietf.org/iesg/statement/discuss-criteria.html 
>> <https://www.ietf.org/iesg/statement/discuss-criteria.html>>
>> >> <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/ 
>> <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/>>
>> >> >   
>> >> >   
>> >> >   
>> >> > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
>> <mailto:[email-masked]>>
>> >> <https://www.ietf.org/mailman/listinfo/sfc 
>> <https://www.ietf.org/mailman/listinfo/sfc>>
>> >> >   
>> >

---

From: <[email-masked]>
Date: Tue, 13 Jul 2021 06:14:13 +0000

Hi Alvaro, 

Sure. I made the changes that you can track at: https://tinyurl.com/nsh-integrity-latest 

* Added a pointer to 8.2 where the transport security is discussed
* added an explicit mention of the third option that refers to this I-D

We may tweak this a little more. 

Cheers,
Med

> Envoyé : lundi 12 juillet 2021 22:13
> Cc : [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> protection.
> > However, if an operator deems protection is required, several
> options
> > are viable:
> >
> > Lastly, NSH MD Type 2 provides, via variable-length headers, the
> > ability to append cryptographic integrity protection to the NSH
> > packet. The implementation of such a scheme is outside the scope
> of
> > this document.
> >
> Even though I still think that a formal Update to rfc8300 is the
> right thing to do, I would be very happy if there was (at least)
> some additional text included to clarify the expected relationship
> between the 2 documents.
> 
> Thanks!
> 
> Alvaro.
> 
> 
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 15 Jul 2021 07:27:57 -0700

> The I-D is basically the third option.

One of the things an "Updates" gives us is a forward pointer from RFC 8300
to this document.  I think when presented in the context you have here, the
notion of such linkage is better than "useless".

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 15 Jul 2021 07:32:37 -0700

> mechanism, but that we would add an optional NSH security mechanism.

I think on reading the document, I didn't find it clear that this was an
optional thing or an extension.  It read to me a lot more like it was
filling an important gap left by RFC 8300, which to me leans much more
firmly in the direction that it's appropriate to call it an update.

-MSK

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 15 Jul 2021 10:47:39 -0400

Given that the WG intent was that this be an optional extension, can you 
please suggest how we clarify that?

Thank you,
Joel

On 7/15/2021 10:32 AM, Murray S. Kucherawy wrote:
> On Mon, Jul 12, 2021 at 12:38 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 15 Jul 2021 08:18:25 -0700

> please suggest how we clarify that?

It's obvious from this discussion that that was the WG intent, but is it
also your view that this WG intent was made clear in the document?  That
was certainly not my impression, and I infer from the number of ballot
comments that that's not a singular view, though certainly that might be
more obvious to someone directly involved in this space.

How about this, or something like it, in your Abstract:

CURRENT:

   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.

NEW 1:
   This specification adds optional 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.

NEW 2:
   This specification presents an optional method to add
   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.

...and in Section 1:

CURRENT:
   This specification fills that gap.  Concretely, this document adds
   integrity protection and optional encryption of sensitive metadata
   directly to the NSH [...]

NEW:
   This specification presents an optional extension that fills that gap.
   Concretely, this document adds optional
   integrity protection and encryption of sensitive metadata
   directly to the NSH [...]

-MSK

---

From: <[email-masked]>
Date: Thu, 15 Jul 2021 15:32:11 +0000

Re-,

Please see inline.

Cheers,
Med

De : Murray S. Kucherawy [mailto:[email-masked]]
Envoyé : jeudi 15 juillet 2021 17:18
À : Joel Halpern Direct <[email-masked]>
Cc : Alvaro Retana <[email-masked]>; The IESG <[email-masked]>; Greg Mirsky <[email-masked]>; [email-masked]; Service Function Chaining IETF list <[email-masked]>
Objet : Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT)

On Thu, Jul 15, 2021 at 7:47 AM Joel Halpern Direct <[email-masked]<mailto:[email-masked]>> wrote:
Given that the WG intent was that this be an optional extension, can you
please suggest how we clarify that?

It's obvious from this discussion that that was the WG intent, but is it also your view that this WG intent was made clear in the document?  That was certainly not my impression, and I infer from the number of ballot comments that that's not a singular view, though certainly that might be more obvious to someone directly involved in this space.

   carried in the NSH.

NEW 1:

   carried in the NSH.

NEW 2:

   Service Header (NSH) used for Service Function Chaining (SFC).

[Med] I like this one. Thanks.

  Also,

   carried in the NSH.

...and in Section 1:

CURRENT:

[Med] For this one, I think this is already covered by the text proposed to Alvaro. The NEW text can be seen at: https://tinyurl.com/nsh-integrity-latest
   This specification fills that gap for SFC (that is, define the "NSH
   Variable Header-Based Integrity" option mentioned in Section 8.2.1 of
                                    ^^^^^^
   [RFC8300]).

NEW:

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 15 Jul 2021 08:40:45 -0700

Hi Mohamed,

Thank you, that looks good.

-MSK

On Thu, Jul 15, 2021 at 8:32 AM <[email-masked]> wrote:

> Re-,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Murray S. Kucherawy [mailto:[email-masked]]
> *Envoyé :* jeudi 15 juillet 2021 17:18
> *À :* Joel Halpern Direct <[email-masked]>
> *Cc :* Alvaro Retana <[email-masked]>; The IESG <[email-masked]>;
> Greg Mirsky <[email-masked]>; [email-masked];
> Service Function Chaining IETF list <[email-masked]>
> *Objet :* Re: [sfc] Alvaro Retana's No Objection on
> draft-ietf-sfc-nsh-integrity-06: (with COMMENT)
>
>
>
> *[Med] I like this one. Thanks. *
>
>
>
>   Also,
>
> *[Med] For this one, I think this is already covered by the text proposed to Alvaro. The NEW text can be seen at: https://tinyurl.com/nsh-integrity-latest <https://tinyurl.com/nsh-integrity-latest> *
>