Subject: [sfc] NSH DISCUSS Status

From: <[email-masked]>
Date: Thu, 19 Oct 2017 08:49:12 +0000

Hi Alia,

Can you please share with us the current status of the document and the list of pending blocking points?

I went through all public email exchanges, especially the ones related to security, but it is not that easy to understand what are the remaining issues that need fixes.

In particular, is there a concern with assuming the current NSH threat model?

1.  NSH is secure against attacks induced by nodes that inject (spoofed) NSH before entering an SFC-enabled domain. Indeed, SFC ingress nodes MUST discard packets carrying NSH.

2.  NSH is secure against attacks from within the SFC-enabled domain to inject non-authorized context headers. From a service perspective, the guard is the CP which is responsible for instructing the SFC-aware nodes about the mandatory-to-process and optional-to-process context headers. Furthermore, whatever the origin of a supplied context header, the last SFF of a chain (and egress nodes) MUST remove the NSH before forwarding upstream.

3.  NSH is secure against leaking privacy information outside an SFC enabled domain. The last SFF of a chain (and egress nodes) MUST remove the NSH before forwarding upstream.

4.  NSH is secure against indefinite SF/SFF loops by means of SI and TTL fields.

5.  Control plane specific threats are out of scope, but the document cites I-D.ietf-sfc-control-plane for the expected behavior when instructing SFC nodes. BTW, the secdir review of the CP requirements can be retrieved here (https://datatracker.ietf.org/doc/review-ietf-sfc-control-plane-02-secdir-early-meadows-2015-12-10/).

6.  NSH does not share privacy data with non-authorized parties. Indeed, data carried in context headers are derived from the original packet (e.g., source IP address) or are already known to the operator (e.g., subscriber identifier, policy identifier, service identifier). The context information is shared with nodes that are within the same administrative domain.

7.  Like other communication protocols, attacks from within the network are possible, but those are soften by relying on the procedures put in place by operators for testing and validating nodes/features before actual activation. NSH does not provide a built-in feature to prevent misbehaving nodes, but recommends to rely on the security features provided by the underlying transport encapsulation schemes.

Let's now focus on the typical "attacks" that can be issued from within the network:

1.  A misbehaving node redirect the traffic to non-authorized nodes outside a domain: This is not NSH-specific.

2.  A misbehaving SFC-unware node alters the content of a packet: This is not NSH-specific.

3.  A misbehaving SFC-aware node alters the content of NSH:

            i.     It removes the NSH header from all packets it sees: This will imply that the packets, the misbehaving node intercepts, will be forwarded upstream without invoking the required SFs (which may be seen as a feature, not a bug if one dislikes "middleboxes" :)). More seriously, the OAM NSH feature will allow an operator to detect whether NSH packets are travelling in accordance with SFC instructions of that domain. Running that feature will help detecting the misbehaving node.

          ii.     It modifies the content of SPI: This will imply that these packets will be forwarded over a wrong path. Again, running OAM NSH will allow the operator to detect whether a packet is travelling in accordance with SFC instructions. Running that feature regularly will help identifying the misbehaving node and whether the SFC configuration of a domain is aligned with the expected behavior.

        iii.     It modifies the content of SI/TTL: This will increase the authorized maximum SFF/SF hops. Not sure if there is a security problem out there.

          iv.     The misbehaving node is a classifier: The implications will be severe from a service standpoint. NSH relies on OAM and control-plane to detect such case.

            v.     The misbehaving node is an SFF: Examples of misbehaviors are: strip NSH, forward to a non-authorized SF, redirect the traffic to a non-authorized nodes, etc. Like for the classifier case, NSH relies on OAM and control-plane to detect such case.

Are there specific attacks that are not listed above and that need more attention from the WG?

Thank you.

Cheers,
Med

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 19 Oct 2017 17:41:44 +0000

Med,

I wholeheartedly agree with your analysis, thanks for sending this out.  I’d also add that much of this is also applicable to existing and forthcoming network-centric protocols (of course with domain specific terminology substituted as needed).

Paul

On Oct 19, 2017, at 4:49 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Alia,

Let’s now focus on the typical “attacks” that can be issued from within the network:
1.  A misbehaving node redirect the traffic to non-authorized nodes outside a domain: This is not NSH-specific.
2.  A misbehaving SFC-unware node alters the content of a packet: This is not NSH-specific.
3.  A misbehaving SFC-aware node alters the content of NSH:
            i.     It removes the NSH header from all packets it sees: This will imply that the packets, the misbehaving node intercepts, will be forwarded upstream without invoking the required SFs (which may be seen as a feature, not a bug if one dislikes “middleboxes” :)). More seriously, the OAM NSH feature will allow an operator to detect whether NSH packets are travelling in accordance with SFC instructions of that domain. Running that feature will help detecting the misbehaving node.
          ii.     It modifies the content of SPI: This will imply that these packets will be forwarded over a wrong path. Again, running OAM NSH will allow the operator to detect whether a packet is travelling in accordance with SFC instructions. Running that feature regularly will help identifying the misbehaving node and whether the SFC configuration of a domain is aligned with the expected behavior.
        iii.     It modifies the content of SI/TTL: This will increase the authorized maximum SFF/SF hops. Not sure if there is a security problem out there.
          iv.     The misbehaving node is a classifier: The implications will be severe from a service standpoint. NSH relies on OAM and control-plane to detect such case.
            v.     The misbehaving node is an SFF: Examples of misbehaviors are: strip NSH, forward to a non-authorized SF, redirect the traffic to a non-authorized nodes, etc. Like for the classifier case, NSH relies on OAM and control-plane to detect such case.

Thank you.

Cheers,
Med
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: Alia Atlas <[email-masked]>
Date: Thu, 19 Oct 2017 14:49:52 -0400

Hi Med,

Since you directed this at me, there are efforts to have some discussions
and understand better the particular threats.
Currently, there is no transport with integrity protection that is even a
SHOULD to implement, much less a MUST.  There
is no control-plane defined (beyond the BGP work) that describes detecting
issues.  There is no OAM defined and adopted
by the WG that detects or handles these types of attacks. I see the
structure that you are presuming, but none of these are
available as normative references to NSH today.

I had recommended having a focused interim meeting to make sure that
everyone concerned understood the issues and
worked through the threat analysis and possible solutions together. At this
point, clearly the most that could happen is a
virtual interim.  There are some background discussions going on.

I do not want to assume what mixture will be acceptable to handle the
security concerns expressed by Kathleen and Eric
and supported by a number of other ADs.

I do greatly appreciate your attention and efforts to clarify and try to
move this work forward. I have been expressing concerns
about the security aspects of this work since RFC 7665 went through the
publication process - and strongly encouraging serious
WG focus to prevent precisely what has now happened.

Regards,
Alia

On Thu, Oct 19, 2017 at 4:49 AM, <[email-masked]> wrote:

> I went through all public email exchanges, especially the ones related to
> security, but it is not that easy to understand what are the remaining
> issues that need fixes.
>
>
>
> 1.  NSH is secure against attacks induced by nodes that inject (spoofed)
> NSH before entering an SFC-enabled domain. Indeed, SFC ingress nodes MUST
> discard packets carrying NSH.
>
> 2.  NSH is secure against attacks from within the SFC-enabled domain to
> inject non-authorized context headers. From a service perspective, the
> guard is the CP which is responsible for instructing the SFC-aware nodes
> about the mandatory-to-process and optional-to-process context headers.
> Furthermore, whatever the origin of a supplied context header, the last SFF
> of a chain (and egress nodes) MUST remove the NSH before forwarding
> upstream.
>
> 3.  NSH is secure against leaking privacy information outside an SFC
> enabled domain. The last SFF of a chain (and egress nodes) MUST remove the
> NSH before forwarding upstream.
>
> 5.  Control plane specific threats are out of scope, but the document
> cites I-D.ietf-sfc-control-plane for the expected behavior when instructing
> SFC nodes. BTW, the secdir review of the CP requirements can be retrieved
> here (https://datatracker.ietf.org/doc/review-ietf-sfc-control-
> plane-02-secdir-early-meadows-2015-12-10/).
>
> 6.  NSH does not share privacy data with non-authorized parties. Indeed,
> data carried in context headers are derived from the original packet (e.g.,
> source IP address) or are already known to the operator (e.g., subscriber
> identifier, policy identifier, service identifier). The context information
> is shared with nodes that are within the same administrative domain.
>
> 7.  Like other communication protocols, attacks from within the network
> are possible, but those are soften by relying on the procedures put in
> place by operators for testing and validating nodes/features before actual
> activation. NSH does not provide a built-in feature to prevent misbehaving
> nodes, but recommends to rely on the security features provided by the
> underlying transport encapsulation schemes.
>
>
>
> 1.  A misbehaving node redirect the traffic to non-authorized nodes
> outside a domain: This is not NSH-specific.
>
>             i.     It removes the NSH header from all packets it sees:
> This will imply that the packets, the misbehaving node intercepts, will be
> forwarded upstream without invoking the required SFs (which may be seen as
> a feature, not a bug if one dislikes “middleboxes” :)). More seriously, the
> OAM NSH feature will allow an operator to detect whether NSH packets are
> travelling in accordance with SFC instructions of that domain. Running that
> feature will help detecting the misbehaving node.
>
>           ii.     It modifies the content of SPI: This will imply that
> these packets will be forwarded over a wrong path. Again, running OAM NSH
> will allow the operator to detect whether a packet is travelling in
> accordance with SFC instructions. Running that feature regularly will help
> identifying the misbehaving node and whether the SFC configuration of a
> domain is aligned with the expected behavior.
>
>         iii.     It modifies the content of SI/TTL: This will increase
> the authorized maximum SFF/SF hops. Not sure if there is a security problem
> out there.
>
>           iv.     The misbehaving node is a classifier: The implications
> will be severe from a service standpoint. NSH relies on OAM and
> control-plane to detect such case.
>
>             v.     The misbehaving node is an SFF: Examples of
> misbehaviors are: strip NSH, forward to a non-authorized SF, redirect the
> traffic to a non-authorized nodes, etc. Like for the classifier case, NSH
> relies on OAM and control-plane to detect such case.
>
>
>

---

From: <[email-masked]>
Date: Fri, 20 Oct 2017 06:35:25 +0000

Hi Alia,

Thank you for the feedback.

Please see inline.

Cheers,
Med

De : Alia Atlas [mailto:[email-masked]]
Envoyé : jeudi 19 octobre 2017 20:50
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]; Kathleen Moriarty; Eric Rescorla
Objet : Re: NSH DISCUSS Status

Hi Med,

Since you directed this at me
[Med] I sent it to you because you are our AD and I was sure you have a full visibility on ongoing discussions and pending issues.

, there are efforts to have some discussions and understand better the particular threats.
Currently, there is no transport with integrity protection that is even a SHOULD to implement, much less a MUST.

[Med] Agree. But.. the question Alia is to understand what attacks built-in integrity protection will prevent/solve. Is there a pointer where we can find a description of such attacks?

  There
is no control-plane defined (beyond the BGP work) that describes detecting issues.

[Med] The WG produced a set of security requirements that need to be met by any SFC CP solution. The security review of those requirements said: “It is very well-thought out and comprehensive”. IMHO, we don’t need CP solutions to be listed as normative because the NSH is a data-plane solution; CP-related aspects are out of scope.

  There is no OAM defined and adopted
by the WG that detects or handles these types of attacks.

[Med] The WG has already a framework document to describe required features (e.g., trace) to assess whether the behavior of an underlying SFC-enabled domain is aligned with the expected SFC behavior (draft-ietf-sfc-oam-framework). Adding an informative pointer to that document is sufficient for the current NSH discussion.

I see the structure that you are presuming, but none of these are
available as normative references to NSH today.

[Med] Two comments here:

·         These references do not need to be “normative” for NSH for the simple reason that an “implementer” of NSH spec does not need to read those documents. This is the definition of “normative” vs “informative”.

·         I agree those are important for the entity that will operate an “SFC domain” that is a collection of SFC data-plane solution (i.e., NSH), SFC control-plane protocol(s), and SFC OAM protocols. NSH is not defining such collection.

I had recommended having a focused interim meeting to make sure that everyone concerned understood the issues and
worked through the threat analysis and possible solutions together. At this point, clearly the most that could happen is a
virtual interim.  There are some background discussions going on.

I do not want to assume what mixture will be acceptable to handle the security concerns expressed by Kathleen and Eric

[Med] What would be really valuable and helpful for the WG is to understand attack vectors that are not covered in the threat model I described. I’m sure Kathleen and Eric can help us with sketching some attack examples that triggered their comments.

I do greatly appreciate your attention and efforts to clarify and try to move this work forward. I have been expressing concerns
about the security aspects of this work since RFC 7665 went through the publication process - and strongly encouraging serious
WG focus to prevent precisely what has now happened.

[Med] Thank you.

Regards,
Alia

On Thu, Oct 19, 2017 at 4:49 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

Thank you.

Cheers,
Med

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Fri, 20 Oct 2017 13:31:12 +0000

Hi Alia,

On Oct 19, 2017, at 2:49 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Hi Med,

Since you directed this at me, there are efforts to have some discussions and understand better the particular threats.
Currently, there is no transport with integrity protection that is even a SHOULD to implement, much less a MUST.  There
is no control-plane defined (beyond the BGP work) that describes detecting issues.  There is no OAM defined and adopted
by the WG that detects or handles these types of attacks. I see the structure that you are presuming, but none of these are
available as normative references to NSH today.

OAM does not address the security concern around integrity and devices.  If you and the WG believe OAM is the next “to do” for the WG, that’s fine, but it’s orthogonal to the security points raised.

I had recommended having a focused interim meeting to make sure that everyone concerned understood the issues and
worked through the threat analysis and possible solutions together.

Let’s please not conflate the ongoing security discussion with OAM, or other topics.  The security reality, as you pointed out in your email to Eric, is that we, as a community and industry, accept a level of trust wrt network devices.  The ongoing edits and dialogue with Kathleen and Eric are working through their concerns.  An interim to talk about next SFC steps, post NSH, is a different matter.

At this point, clearly the most that could happen is a
virtual interim.  There are some background discussions going on.

Regards,
Alia

Thank you.

Cheers,
Med

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 06:45:25 -0700

On Fri, Oct 20, 2017 at 6:31 AM, Paul Quinn (paulq) <[email-masked]> wrote:

> Hi Alia,
>
>
>
> On Oct 19, 2017, at 2:49 PM, Alia Atlas <[email-masked]> wrote:
>
> Hi Med,
>
> OAM does not address the security concern around integrity and devices.
> If you and the WG believe OAM is the next “to do” for the WG, that’s fine,
> but it’s orthogonal to the security points raised.
>
>
> Let’s please not conflate the ongoing security discussion with OAM, or
> other topics.  The security reality, as you pointed out in your email to
> Eric, is that we, as a community and industry, accept a level of trust wrt
> network devices.
>

I don't actually think that's the point of contention, at least from my
perspective. Rather it's about the level of trust to be placed in the
networking path through which that data flows.

-Ekr

>  The ongoing edits and dialogue with Kathleen and Eric are working through
> their concerns.  An interim to talk about next SFC steps, post NSH, is a
> different matter.
>
>
>
>> here (https://datatracker.ietf.org/doc/review-ietf-sfc-control-pl
>> ane-02-secdir-early-meadows-2015-12-10/).
>>
> [email-masked]

---

From: <[email-masked]>
Date: Fri, 20 Oct 2017 13:51:49 +0000

Dear Eric,

Can you please clarify this point: “Rather it's about the level of trust to be placed in the networking path through which that data flows.”?

Sorry if you have already explained it to the editors, but as a WG participant I don’t have access to a record of such discussion.

Thank you.

Cheers,
Med

De : Eric Rescorla [mailto:[email-masked]]
Envoyé : vendredi 20 octobre 2017 15:45
À : Paul Quinn (paulq)
Cc : Alia Atlas; BOUCADAIR Mohamed IMT/OLN; Kathleen Moriarty; [email-masked]
Objet : Re: [sfc] NSH DISCUSS Status

On Fri, Oct 20, 2017 at 6:31 AM, Paul Quinn (paulq) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

Hi Med,

Let’s please not conflate the ongoing security discussion with OAM, or other topics.  The security reality, as you pointed out in your email to Eric, is that we, as a community and industry, accept a level of trust wrt network devices.

I don't actually think that's the point of contention, at least from my perspective. Rather it's about the level of trust to be placed in the networking path through which that data flows.

-Ekr

 The ongoing edits and dialogue with Kathleen and Eric are working through their concerns.  An interim to talk about next SFC steps, post NSH, is a different matter.

Regards,
Alia

Thank you.

Cheers,
Med

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 06:55:35 -0700

It's explained in detail in my DISCUSS:

"1. The assumption that the datacenter is a secure environment is not a

reasonable one. As Kathleen and Adam both observer, datacenter
breaches are common and that is why people are moving towards
encryption inside the data center. I see that this draft has text
claiming that this is only to be deployed in safe environments, but we
know that technologies like this get deployed outside the locations
for which we claim they are to be deployed, and there's nothing here
to stop that. Moreover, the whole trend towards cloud computing pushes
us away from designs in which you can safely talk about single secure
zones."

-Ekr

On Fri, Oct 20, 2017 at 6:51 AM, <[email-masked]> wrote:

> Dear Eric,
>
>
>
> Can you please clarify this point: “Rather it's about the level of trust
> to be placed in the networking path through which that data flows.”?
>
>
>
> Sorry if you have already explained it to the editors, but as a WG
> participant I don’t have access to a record of such discussion.
>
>
>
> Thank you.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Eric Rescorla [mailto:[email-masked]]
> *Envoyé :* vendredi 20 octobre 2017 15:45
> *À :* Paul Quinn (paulq)
> *Cc :* Alia Atlas; BOUCADAIR Mohamed IMT/OLN; Kathleen Moriarty;
> [email-masked]
> *Objet :* Re: [sfc] NSH DISCUSS Status
>
>
>
>
>
>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 20 Oct 2017 14:01:07 +0000

Eric,

On Oct 20, 2017, at 9:45 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

Hi Med,

Understood. How about this?

              X.2.  Transport Encapsulation Security

                        NSH is always encapsulated by an outer transport
                        encapsulation as detailed in Section 4 of this
                        specification, and as depicted in Figure 1.  If an operator
                        deems cryptographic integrity protection necessary due to
                        their risk analysis, then an outer transport encapsulation
                        that provides such protection [RFC6071], such as IPsec, MUST
                        be used.

— Carlos.

-Ekr

Regards,
Alia

Thank you.

Cheers,
Med

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 07:08:03 -0700

On Fri, Oct 20, 2017 at 7:01 AM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Eric,
>
> On Oct 20, 2017, at 9:45 AM, Eric Rescorla <[email-masked]> wrote:
>
>
>
>> is no control-plane defined (beyond the BGP work) that describes
>> detecting issues.  There is no OAM defined and adopted

I can't speak for Kathleen, but I don't really think this gets the job done.

As described in RFC 3552 (https://tools.ietf.org/html/rfc3552#section-3)
our threat model is that the Internet is untrusted. That means we should be
designing protocols that are safe to operate in that environment, which in
this case means that the protocol should either (a) come with a built-in
security mechanism or (b) be run over a secure transport. I don't think
telling operators "you figure it out" reflects best current practice.

-Ekr

>
>
> — Carlos.
>
> -Ekr
>
>
>
>>  The ongoing edits and dialogue with Kathleen and Eric are working
>> through their concerns.  An interim to talk about next SFC steps, post NSH,
>> is a different matter.
>>
>>
>>
>>> I went through all public email exchanges, especially the ones related
>>> to security, but it is not that easy to understand what are the remaining
>>> issues that need fixes.
>>>
>>>
>>>
>>> 1.  NSH is secure against attacks induced by nodes that inject
>>> (spoofed) NSH before entering an SFC-enabled domain. Indeed, SFC ingress
>>> nodes MUST discard packets carrying NSH.
>>>
>>> 6.  NSH does not share privacy data with non-authorized parties.
>>> Indeed, data carried in context headers are derived from the original
>>> packet (e.g., source IP address) or are already known to the operator
>>> (e.g., subscriber identifier, policy identifier, service identifier). The
>>> context information is shared with nodes that are within the same
>>> administrative domain.
>>>
>>>           iv.     The misbehaving node is a classifier: The
>>> implications will be severe from a service standpoint. NSH relies on OAM
>>> and control-plane to detect such case.
>>>

---

From: <[email-masked]>
Date: Fri, 20 Oct 2017 14:12:55 +0000

Re-,

Thank you, Eric.

There is a misunderstanding here. The document does not claim DCs are safe and secure environments. What it says is that the NSH specification is scoped to be deployed in a single administrative domain with measures to, e.g.,:

-    Protect against spoofed data

-    Leaking data outside a domain

-    Detect and prevent indefinite forwarding loops

A single administrative domain is not necessarily a secure or a safe one. That’s evident. Attacks from within an administrative domain are possible with or without NSH.

I’m reiterating my question: what specific attacks built-in/mandatory integrity mechanisms will solve for the particular case of NSH? Thank you.

Cheers,
Med

De : Eric Rescorla [mailto:[email-masked]]
Envoyé : vendredi 20 octobre 2017 15:56
À : BOUCADAIR Mohamed IMT/OLN
Cc : Paul Quinn (paulq); Alia Atlas; Kathleen Moriarty; [email-masked]
Objet : Re: [sfc] NSH DISCUSS Status

zones."

-Ekr

On Fri, Oct 20, 2017 at 6:51 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear Eric,

Thank you.

Cheers,
Med

De : Eric Rescorla [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : vendredi 20 octobre 2017 15:45
À : Paul Quinn (paulq)
Cc : Alia Atlas; BOUCADAIR Mohamed IMT/OLN; Kathleen Moriarty; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] NSH DISCUSS Status

Hi Med,

-Ekr

Regards,
Alia

Thank you.

Cheers,
Med

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 20 Oct 2017 14:18:24 +0000

On Oct 20, 2017, at 10:08 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Oct 20, 2017 at 7:01 AM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Eric,

Hi Med,

As described in RFC 3552 (https://tools.ietf.org/html/rfc3552#section-3) our threat model is that the Internet is untrusted.

Yes. Just to clarify, though, NSH is not an end-to-end protocol. It doesn’t “start” in a host and “end” in a host/server. It’s a network-centric like Provisioned Virtual Private Networks, Traffic Engineering, MPLS.

That means we should be designing protocols that are safe to operate in that environment, which in this case means that the protocol should either (a) come with a built-in security mechanism or (b) be run over a secure transport. I don't think telling operators "you figure it out" reflects best current practice.

But… we are saying “run over a secure transport”.

This was best captured in Alia’s message to you, copied on this list:

"There are no encapsulations from the Routing Area that require integrity protection that I am aware of;
when privacy is required IPsec or MAC sec are used.”

Thanks for engaging in dialogue now, can you clarify?

Carlos.

-Ekr

— Carlos.

-Ekr

Regards,
Alia

Thank you.

Cheers,
Med

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 07:21:52 -0700

On Fri, Oct 20, 2017 at 7:12 AM, <[email-masked]> wrote:

> Re-,
>
>
>
> Thank you, Eric.
>
>
>
> There is a misunderstanding here. The document does not claim DCs are safe
> and secure environments. What it says is that the NSH specification is
> scoped to be deployed in a single administrative domain with measures to,
> e.g.,:
>
> -    Detect and prevent indefinite forwarding loop
>
Yes, and my point (and I believe Kathleen's) is that this is not a
realistic operating model given the actual state of the world.

A single administrative domain is not necessarily a secure or a safe one.
> That’s evident. Attacks from within an administrative domain are possible
> with or without NSH.
>
>
>
> I’m reiterating my question: what specific attacks built-in/mandatory
> integrity mechanisms will solve for the particular case of NSH? Thank you.
>

Tampering with the path packets take through the NFC.

-Ekr

> *Envoyé :* vendredi 20 octobre 2017 15:56
> *À :* BOUCADAIR Mohamed IMT/OLN
> *Cc :* Paul Quinn (paulq); Alia Atlas; Kathleen Moriarty; [email-masked]
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 07:26:04 -0700

On Fri, Oct 20, 2017 at 7:18 AM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

>
> On Oct 20, 2017, at 10:08 AM, Eric Rescorla <[email-masked]> wrote:
>
>
>>> Since you directed this at me, there are efforts to have some
>>> discussions and understand better the particular threats.
>>> Currently, there is no transport with integrity protection that is even
>>> a SHOULD to implement, much less a MUST.  There
> our threat model is that the Internet is untrusted.
>
>
> Yes. Just to clarify, though, NSH is not an end-to-end protocol. It
> doesn’t “start” in a host and “end” in a host/server. It’s
> a network-centric like Provisioned Virtual Private Networks, Traffic
> Engineering, MPLS.
>

Sure, and in this case it's the network between the nodes that is relevant
here.

That means we should be designing protocols that are safe to operate in
> that environment, which in this case means that the protocol should either
> (a) come with a built-in security mechanism or (b) be run over a secure
> transport. I don't think telling operators "you figure it out" reflects
> best current practice.
>
>

Well, that's not what your proposed text says you should do it "If an
operator deems cryptographic integrity protection necessary due to their
risk analysis". If you want to say "this is only specified to run over a
secure transport" then fine, but that's not what this says.

-Ekr

>>>> 2.  NSH is secure against attacks from within the SFC-enabled domain
>>>> to inject non-authorized context headers. From a service perspective, the
>>>> 7.  Like other communication protocols, attacks from within the
>>>> network are possible, but those are soften by relying on the procedures put
>>>> in place by operators for testing and validating nodes/features before
>>>> actual activation. NSH does not provide a built-in feature to prevent
>>>> misbehaving nodes, but recommends to rely on the security features provided
>>>> by the underlying transport encapsulation schemes.
>>>>
>>>>
>>>>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Fri, 20 Oct 2017 14:37:36 +0000

On Oct 20, 2017, at 10:26 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Oct 20, 2017 at 7:18 AM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Med,

Sure, and in this case it's the network between the nodes that is relevant here.

Well, that's not what your proposed text says you should do it "If an operator deems cryptographic integrity protection necessary due to their risk analysis". If you want to say "this is only specified to run over a secure transport" then fine, but that's not what this says.

This ignore the reality of running a network: creating largely unrealizable security requirements simply results relegating security to something ignored.  IMO, we — the IETF — are far better off with a pragmatic approach: document the risk and provide possible mitigations.  From there, if the risks are deemed sufficient, an operator has guidance.  Frankly, this is the only way network protocols (e.g. MPLS, SPRING, SFC, etc.) will be viable.  In fact, the BIER secdir reviewer took exactly this stance:

https://datatracker.ietf.org/doc/review-ietf-bier-mpls-encapsulation-09-secdir-telechat-atkins-2017-10-19/

<trimmed>

---

From: <[email-masked]>
Date: Fri, 20 Oct 2017 14:38:44 +0000

Re-,

Please see inline.

Cheers,
Med

Envoyé : vendredi 20 octobre 2017 16:22

On Fri, Oct 20, 2017 at 7:12 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Re-,

Thank you, Eric.

-    Detect and prevent indefinite forwarding loop
Yes, and my point (and I believe Kathleen's) is that this is not a realistic operating model given the actual state of the world.

Tampering with the path packets take through the NFC.
[Med] Thank you. I have two comments:

-    Such behavior can also be detected by means of SFC OAM in an SFC domain. See my first message.

-    Such misbehaving node will act on ALL the traffic, not only NSH. The question is why the NSH stamped traffic must be provided with built-in integrity feature while the traffic not elected to be forwarded via a service chain will be left subject to tampering attacks? Wouldn’t be consistent generalize that feature (if provided) to all traffic that is transiting for a given domain?

-Ekr

Cheers,
Med

De : Eric Rescorla [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : vendredi 20 octobre 2017 15:56
À : BOUCADAIR Mohamed IMT/OLN
Cc : Paul Quinn (paulq); Alia Atlas; Kathleen Moriarty; [email-masked]<mailto:[email-masked]>

zones."

-Ekr

Thank you.

Cheers,
Med

Hi Med,

-Ekr

Regards,
Alia

Thank you.

Cheers,
Med

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 20 Oct 2017 14:41:03 +0000

Eric,

Hi Med,

Right. Not an application layer construct, not the end-to-end Internet.

Well, you somehow edited out text that I included from Alia — let me copy it back again:

—>8—

—>8—

That says “when privacy is required” as a qualifier.

To understand, are you suggesting (or stating) that all RTG-Area encapsulations always need to unconditionally run over a secure transport?

In other words, we can mandate that those mechanisms exist and mandate that they are used when required.

Thanks,

— Carlos.

-Ekr

-Ekr

— Carlos.

-Ekr

Regards,
Alia

Thank you.

Cheers,
Med

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 07:45:31 -0700

On Fri, Oct 20, 2017 at 7:38 AM, <[email-masked]> wrote:

> *Envoyé :* vendredi 20 octobre 2017 16:22
> -    Such misbehaving node will act on ALL the traffic, not only NSH. The
> question is why the NSH stamped traffic must be provided with built-in
> integrity feature while the traffic not elected to be forwarded via a
> service chain will be left subject to tampering attacks? Wouldn’t be
> consistent generalize that feature (if provided) to all traffic that is
> transiting for a given domain?
>

The issue here is attacks on the network function itself (e.g., bypassing
or rerouting traffic). Generally, we look to protect the traffic itself via
other mechanisms, preferably end-to-end.

-Ekr

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 20 Oct 2017 14:49:45 +0000

On Oct 20, 2017, at 10:21 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

[Assuming you mean SFP (or maybe even SFC) instead of NFC. If you are referring to something else, I missed the acronym.]

To your point, there are other improvements we can make to the text, indeed. For example, here’s a suggestion re Integrity:

—>8—
SFC Devices

                SFC devices MAY
                perform various forms of verification on received NSH packets
                such as only accepting NSH packets from expected devices,
                checking that NSH SPI and SI values received from expected
                devices conform to expected values and so on. Implementation of
                these additional checks are a local matter and thus out of scope
                of this document.

NSH Base and Service Path Headers

                1.  SFF/SF NSH verification

                        Although strictly speaking not integrity protection, some of
                        the techniques mentioned above such as checking expected NSH
                        values are received from expected SFC device(s) can provide
                        a form of verification without incurring the burden of a
                        full-fledged integrity protection deployment.

                2.  Transport Security

What do you think?

Thanks,

Carlos.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 07:50:59 -0700

Well, I see how you can feel that way, but on the other hand, Proposed
Standard is supposed to be for documents which, to quote RFC 2026  "A
Proposed Standard should have no known technical omissions with respect to
the requirements placed upon it." and a number of IETF documents
memorializing a threat model in which NSH is not a safe design. I
appreciate that you feel that that threat model is not applicable here, but
I don't agree, and I think the number of DISCUSSes on this document
suggests I'm not the only one.

In any case, I don't think going back and forth in email is productive
here. I'm happy to do this live in Singapore or on a phone call where the
other people who filed DISCUSSes can also attend.

-Ekr

On Fri, Oct 20, 2017 at 7:37 AM, Paul Quinn (paulq) <[email-masked]> wrote:

>
>
> On Oct 20, 2017, at 10:26 AM, Eric Rescorla <[email-masked]> wrote:
>
>
>
>>>> OAM does not address the security concern around integrity and
>>>> devices.  If you and the WG believe OAM is the next “to do” for the WG,
>>>> that’s fine, but it’s orthogonal to the security points raised.
>>>>
>>>>
> This ignore the reality of running a network: creating largely
> unrealizable security requirements simply results relegating security to
> something ignored.  IMO, we — the IETF — are far better off with a
> pragmatic approach: document the risk and provide possible mitigations.
> From there, if the risks are deemed sufficient, an operator has guidance.
> Frankly, this is the only way network protocols (e.g. MPLS, SPRING, SFC,
> etc.) will be viable.  In fact, the BIER secdir reviewer took exactly this
> stance:
>
> https://datatracker.ietf.org/doc/review-ietf-bier-mpls-
> encapsulation-09-secdir-telechat-atkins-2017-10-19/
>
>
> <trimmed>
>
>
>

---

From: <[email-masked]>
Date: Fri, 20 Oct 2017 14:54:18 +0000

Re-,

Please see inline.

Cheers,
Med

Envoyé : vendredi 20 octobre 2017 16:46

On Fri, Oct 20, 2017 at 7:38 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Re-,

Please see inline.

Cheers,
Med

Thank you, Eric.

The issue here is attacks on the network function itself (e.g., bypassing or rerouting traffic).
[Med] Yes, I got that. It corresponds to what I have described earlier:

1.  A misbehaving SFC-aware node alters the content of NSH:

·         It removes the NSH header from all packets it sees: This will imply that the packets, the misbehaving node intercepts, will be forwarded upstream without invoking the required SFs (which may be seen as a feature, not a bug if one dislikes “middleboxes” :)). More seriously, the OAM NSH feature will allow an operator to detect whether NSH packets are travelling in accordance with SFC instructions of that domain. Running that feature will help detecting the misbehaving node.

·         It modifies the content of SPI: This will imply that these packets will be forwarded over a wrong path. Again, running OAM NSH will allow the operator to detect whether a packet is travelling in accordance with SFC instructions. Running that feature regularly will help identifying the misbehaving node and whether the SFC configuration of a domain is aligned with the expected behavior.

·         It modifies the content of SI/TTL: This will increase the authorized maximum SFF/SF hops. Not sure if there is a security problem out there.

·         The misbehaving node is a classifier: The implications will be severe from a service standpoint. NSH relies on OAM and control-plane to detect such case.

·         The misbehaving node is an SFF: Examples of misbehaviors are: strip NSH, forward to a non-authorized SF, redirect the traffic to a non-authorized nodes, etc. Like for the classifier case, NSH relies on OAM and control-plane to detect such case.

Do you think that current security considerations need call out these items explicitly?

Generally, we look to protect the traffic itself via other mechanisms, preferably end-to-end.
[Med] NSH does not interfere with end-to-end security mechanisms. NSH will supply some data for service-derived forwarding and then strip that data before forwarding outside the domain.

-Ekr

-Ekr

Cheers,
Med

zones."

-Ekr

Thank you.

Cheers,
Med

Hi Med,

-Ekr

Regards,
Alia

Thank you.

Cheers,
Med

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Oct 2017 11:02:32 -0400

Hi,

I think one of the important points to note is that adding E2E
encryption doesn't make sense here.  You would only have on the wire
protection and not on the boxes that might be compromised.  The NSH is
modified at many points along the path as well, so providing integrity
protection of the NSH is also a hard problem.

In a separate thread, I worked through some suggestions that should
appear in the next revision.  They will be making the security
considerations more clear on options and pit falls.  There is a
possibility to do path assurance (but, I'm told it's hard). Language
will also be added to suggest the use of continuous audits -
essentially that term means regular verification of the security
controls that assure the security posture of devices.

They also agreed to note the typical assumption of a zero trust model
and the reliance in routing on distributed computing and therefore
'trust'.

Let's see how that evolves and we're getting closer.  I'd like to see
routing protocols include more security, but minimally that the
considerations are fully listed with mitigations.

Best regards,
Kathleen

On Fri, Oct 20, 2017 at 10:54 AM,  <[email-masked]> wrote:
> Yes, and my point (and I believe Kathleen's) is that this is not a realistic
> operating model given the actual state of the world.
>
>
>
> ·         It removes the NSH header from all packets it sees: This will
> imply that the packets, the misbehaving node intercepts, will be forwarded
> upstream without invoking the required SFs (which may be seen as a feature,
> not a bug if one dislikes “middleboxes” :)). More seriously, the OAM NSH
> feature will allow an operator to detect whether NSH packets are travelling
> in accordance with SFC instructions of that domain. Running that feature
> will help detecting the misbehaving node.
>
> ·         It modifies the content of SPI: This will imply that these packets
> will be forwarded over a wrong path. Again, running OAM NSH will allow the
> operator to detect whether a packet is travelling in accordance with SFC
> instructions. Running that feature regularly will help identifying the
> misbehaving node and whether the SFC configuration of a domain is aligned
> with the expected behavior.
>
> ·         It modifies the content of SI/TTL: This will increase the
> authorized maximum SFF/SF hops. Not sure if there is a security problem out
> there.
>
> ·         The misbehaving node is a classifier: The implications will be
> severe from a service standpoint. NSH relies on OAM and control-plane to
> detect such case.
>
> ·         The misbehaving node is an SFF: Examples of misbehaviors are:
> strip NSH, forward to a non-authorized SF, redirect the traffic to a
> non-authorized nodes, etc. Like for the classifier case, NSH relies on OAM
> [Med] NSH does not interfere with end-to-end security mechanisms. NSH will
> supply some data for service-derived forwarding and then strip that data
> before forwarding outside the domain.
>
>
>
>
>
> -Ekr
>
>
>
>
>
>
>
> -Ekr
>
>
>
>
>
> Cheers,
>
> Med
>
>
>
> Can you please clarify this point: “Rather it's about the level of trust to
> be placed in the networking path through which that data flows.”?
>
>
>
> OAM does not address the security concern around integrity and devices.  If
> you and the WG believe OAM is the next “to do” for the WG, that’s fine, but
> it’s orthogonal to the security points raised.
>
>
>
>
>
> Let’s please not conflate the ongoing security discussion with OAM, or other
> topics.  The security reality, as you pointed out in your email to Eric, is
> that we, as a community and industry, accept a level of trust wrt network
> devices.
>
>
>
> 1.  NSH is secure against attacks induced by nodes that inject (spoofed) NSH
> before entering an SFC-enabled domain. Indeed, SFC ingress nodes MUST
> inject non-authorized context headers. From a service perspective, the guard
> is the CP which is responsible for instructing the SFC-aware nodes about the
> mandatory-to-process and optional-to-process context headers. Furthermore,
> whatever the origin of a supplied context header, the last SFF of a chain
> (and egress nodes) MUST remove the NSH before forwarding upstream.
>
> 3.  NSH is secure against leaking privacy information outside an SFC enabled
> domain. The last SFF of a chain (and egress nodes) MUST remove the NSH
> before forwarding upstream.
>
> 5.  Control plane specific threats are out of scope, but the document cites
> I-D.ietf-sfc-control-plane for the expected behavior when instructing SFC
> nodes. BTW, the secdir review of the CP requirements can be retrieved here
> (https://datatracker.ietf.org/doc/review-ietf-sfc-control-plane-02-secdir-early-meadows-2015-12-10/).
>
> 7.  Like other communication protocols, attacks from within the network are
> possible, but those are soften by relying on the procedures put in place by
> operators for testing and validating nodes/features before actual
>             i.     It removes the NSH header from all packets it sees: This
> will imply that the packets, the misbehaving node intercepts, will be
> forwarded upstream without invoking the required SFs (which may be seen as a
> feature, not a bug if one dislikes “middleboxes” :)). More seriously, the
>           ii.     It modifies the content of SPI: This will imply that these
> packets will be forwarded over a wrong path. Again, running OAM NSH will
> allow the operator to detect whether a packet is travelling in accordance
> with SFC instructions. Running that feature regularly will help identifying
> the misbehaving node and whether the SFC configuration of a domain is
> aligned with the expected behavior.
>
>         iii.     It modifies the content of SI/TTL: This will increase the
> authorized maximum SFF/SF hops. Not sure if there is a security problem out
> there.
>
>             v.     The misbehaving node is an SFF: Examples of misbehaviors
> are: strip NSH, forward to a non-authorized SF, redirect the traffic to a
> non-authorized nodes, etc. Like for the classifier case, NSH relies on OAM

-- 

Best regards,
Kathleen

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 20 Oct 2017 22:12:10 +0000

Eric,

I am just trying to understand…

On Oct 20, 2017, at 10:50 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

In any case, I don't think going back and forth in email is productive here. I'm happy to do this live in Singapore or on a phone call where the other people who filed DISCUSSes can also attend.

Are you saying that will not respond anymore on this specific thread (like to an email response I sent earlier addressed to you), on forks of this thread, or on this topic at all?

I am not sure why so abruptly you do not respond while holding a DISCUSS.

For me, this back and forth in email (also referred to as “communication” and “dialogue”), has been immensely productive. I thank you for it. I understand better your position now — at least better than with the silence (also known as absence of back-and-forth-in-email) of before.

So, would it be possible for you to check the new text and see how it addresses your DISCUSS? I trust you will find areas in which it can be improved.

Additionally, it would be super if you could further make time for a phone/video conversation this coming week! Thanks in advance for that suggestion!

But really, if you could articulate in writing how the new section fits when you try it on for size, it would be of great help.

Best,

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 15:18:48 -0700

On Fri, Oct 20, 2017 at 3:12 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> On Oct 20, 2017, at 10:50 AM, Eric Rescorla <[email-masked]> wrote:
>
> Are you saying that will not respond anymore on this specific thread (like
> to an email response I sent earlier addressed to you), on forks of this
> thread, or on this topic at all?
>

I'm saying I'm not finding this productive and we should do it live. I've
CCed my EA, Cate, who can help us find a time next week.

-Ekr

> For me, this back and forth in email (also referred to as “communication”
> and “dialogue”), has been immensely productive. I thank you for it. I
> understand better your position now — at least better than with the silence
> (also known as absence of back-and-forth-in-email) of before.
>
> So, would it be possible for you to check the new text and see how it
> addresses your DISCUSS? I trust you will find areas in which it can be
> improved.
>
> Additionally, it would be super if you could further make time for a
> phone/video conversation this coming week! Thanks in advance for that
> suggestion!
>
> But really, if you could articulate in writing how the new section fits
> when you try it on for size, it would be of great help.
>
> Best,
>
> —
> Carlos Pignataro, [email-masked]
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
>

---

From: Sumandra Majee <[email-masked]>
Date: Mon, 30 Oct 2017 23:21:28 +0000

Hello,

Jumping into this a bit late into this discussion and it seems not much progress has been made.

I have some questions, observations etc.

  1.  This group is concerned about security and authenticity of NSH encapsulation only. In that case a transport level security should be able to at least provide that functionality, so why is that not an option?
  2.  PATH assurance or integrity? Few things come to mind,
     *   SFF guarantees that NSH->SPI and SI combo that it puts on the wire. Does it mean signing these info…
     *   Path can change somewhere in the graph. Let’s say only a classifier node can change PathID, so every classifier now signs these info.
Sumandra

From: sfc <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Date: Friday, October 20, 2017 at 3:19 PM
To: "Carlos Pignataro (cpignata)" <[email-masked]>, Catherine Groswird <[email-masked]>
Cc: Med Boucadair <[email-masked]>, Kathleen Moriarty <[email-masked]>, "Paul Quinn (paulq)" <[email-masked]>, "[email-masked]" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [sfc] NSH DISCUSS Status

EXTERNAL MAIL: [email-masked]

On Fri, Oct 20, 2017 at 3:12 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Eric,

I'm saying I'm not finding this productive and we should do it live. I've CCed my EA, Cate, who can help us find a time next week.

-Ekr

Best,

—