Subject: [sfc] Eric Rescorla's Discuss on draft-ietf-sfc-nsh-24: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Sep 2017 20:01:01 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-sfc-nsh-24: 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 IESG DISCUSS and COMMENT positions.

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

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I concur with Kathleen's DISCUSS. To state my view of things:

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.

2. The text in S 8.1 about how you might want to use some kind of
transport security does not seem sufficient. As above, we know that if
we don't specify something, people will deploy this technology in
insecure settings without any kind of security.

I concur with Kathleen's point that this document should provide
built-in security mechanisms rather than just punting to the
under-layer. Given that as S 1 makes clear, all these SFs are part of
the same administrative domain, this seems like a comparatively less
challenging setting. If there is some reason why that's infeasible,
that needs to be explained.

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

Line 143
                     |    Original Packet / Frame   |
                     +------------------------------+
Nit: I would have expected this stack to go the other way, with TE on the
bottom.

Line 165
   overlay domain using virtual connections and tunnels.  A corollary is
   that a network administrative domain has a well defined perimeter.
This is not a reasonable assumption in modern datacenter environments,
especially if you have virtualized services.

Line 372
   1 prior to NSH forwarding lookup.  Decrementing by 1 from an incoming
   value of 0 shall result in a TTL value of 63.  The packet MUST NOT be
   forwarded if TTL is, after decrement, 0.
I am having trouble following this, Is the point that I can emit a packet with
TTL 0, which is effectively TTL 64?

Line 375
   This TTL field is the primary loop prevention This TTL mechanism
   represents a robust complement to the Service Index, as the TTL is
Nit: "prevention mechanism. This"?

Line 379
   better, although not perfect, interoperation with pre-standard
   implementations that do not support this TTL field.
This point would be clearer if it were made before the rule about decrement.

Line 403
   0x0 - This is a reserved value.  Implementations SHOULD silently
   discard packets with MD Type 0x0.
Why is this a SHOULD and not a MUST? That seems like it will create potential
interop problems.

Line 651
       encapsulated packet.  It is therefore the last node operating on
       the service header.
Can you also nest NSHs?

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 28 Sep 2017 14:02:18 +0000

Hi, Eric,

> On Sep 27, 2017, at 11:01 PM, Eric Rescorla <[email-masked]> wrote:
> 

Thanks. It is important to discuss the security considerations for NSH (c.f., service chaining today), and see how we can improve the text, if it is not conveying what it needs to.

> reasonable one.

That is *not* what the draft says!

   However, the deployment scope (as defined in [RFC7665]) of the NSH
   encapsulation is limited to a single network administrative domain as
   a controlled environment, with trusted devices (e.g., a data center)
   hence mitigating the risk of unauthorized manipulation of the
   encapsulation headers or metadata.

It says “mitigating the risk”. It does not say “it is a secure environment”.

So, to address the portion of the risk that is *not* mitigated by that assumption, we have the rest of the text.

> As Kathleen and Adam both observer, datacenter
> claiming that this is only to be deployed in safe environments,

CPIGNATA-M-T30Q:nsh cpignata$ grep safe draft-ietf-sfc-nsh-24.txt 
CPIGNATA-M-T30Q:nsh cpignata$ 

The word “safe” is not present in the document...

> but we
> transport security does not seem sufficient.

Just to understand… why it does not seem sufficient? Packets over the DC would be encrypted.

> As above, we know that if

Again, that is *not* what the document says.

And frankly, the document gives guidance to people deploying this. 

> that needs to be explained.

Borrowing from a previous response:

The draft currently says:

  Operators SHOULD then select a transport
  encapsulation protocol such as one that supports [RFC6071] to provide
  the needed protection (e.g., authenticity, confidentiality) for the
  traffic between SFC components.

And then says:

  One useful element of providing privacy protection for sensitive
  metadata is described under the "SFC Encapsulation" area of the
  Security Considerations of [RFC7665].  Operators can and should use
  indirect identification for metadata deemed to be sensitive (such as
  personally identifying information) significantly mitigating the risk
  of privacy violation. 

And then further says:

  For those situations where obfuscation is either inapplicable or
  judged to be insufficient, an operator can also encrypt the metadata.
  An approach to an optional capability to do this was explored in
  [I-D.reddy-sfc-nsh-encrypt].  For other situations where greater
  assurance is desired, optional mechanisms such as
  [I-D.brockners-proof-of-transit] can be used.

So, following on [I-D.reddy-sfc-nsh-encrypt], it says:

  This draft adds authentication
  and optional encryption directly to NSH.  This way NSH data does not
  have to rely on underlying transport encapsulation for security and
  confidentiality.

And:

  An NSH imposer inserts an Authentication Tag TLV for data origin
  authentication and integrity protection.

All the pieces are there.

I will respond to the comments on separate cover.

Thanks!

Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 28 Sep 2017 14:09:07 +0000

Hi Eric,

Responding to the COMMENTS part of your ballot now. 

Thanks again for the thorough read and review of these comments.

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

I know, and probably you and roughly half of the readers. I suspect that the other half would like it as-is. Tabs or spaces? Canon or Nikon? Apple or Windows? These probably fall under the same category. The important thing is that the description of the layers are clear.

> especially if you have virtualized services.

The perimeter would be virtualized but well defined. No?

> TTL 0, which is effectively TTL 64?

The text says that if you decrement to zero you cannot forward.

> Nit: "prevention mechanism. This”?

Great catch! Thanks!

> This point would be clearer if it were made before the rule about decrement.

I am very hesitant to re-organize this text, because it represents a delicate balance of compromise from the WG.

> Why is this a SHOULD and not a MUST? That seems like it will create potential

Because we achieve the goal of discarding with the least amount of “force” — without completely locking the door and throwing away the key.

>       encapsulated packet.  It is therefore the last node operating on

Thanks for the question. We replied to Suresh on the same topic.

Not on tis spec, but being considered by the WG on draft-ietf-sfc-hierarchical.

Thanks!

— Carlos.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 28 Sep 2017 10:10:53 -0400

Hi Carlos,

Just a quick comment, I think what you are seeing here is similar to
how we worked through the layering confusion.  The text as-written is
read differently by security people and those outside of the WG.  It's
really common to get into a grove of language usage within a group
that is not understood in the same way outside of the group.  While
the expressions EKR includes below are not directly in the draft, this
is how we read it, and are concerned with the damage that could be
done with this protocol.  If MPLS is used similarly instead, yes, it
will have the same issues, but you also won't have a secure option if
this is done with the same security (or lack thereof) as MPLS.

Best regards,
Kathleen

-- 

Best regards,
Kathleen