Subject: [sfc] Eric Rescorla's No Objection on draft-farrel-sfc-convent-05: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Tue, 06 Feb 2018 19:18:41 -0800

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

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

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

   The need to protect the metadata is not modified by this document and
   forms part of the NSH definition found in [I-D.ietf-sfc-nsh].
Nit: I wouldn't limit this to encryption. If you care about integrity/data
origin authentication, then encryption may not supply that,

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 8 Feb 2018 20:16:54 -0000

Hey Eric,

Thanks for this comment.

> origin authentication, then encryption may not supply that,

If I'm reading you right, you're observing that the mechanism described in the
document might allow an imposter to introduce metadata.

That's sounds like a real problem and we should do something like:

OLD
   The mechanism described in this document might possibly be used to
   introduce packets into the SFC overlay network.  Therefore measures
   SHOULD be taken to ensure authorization of sources of such packets,
   and tunneling of such packets into the network SHOULD be prevented.
   The amount of packets with "Next Protocol" set to "None" on an SFP
   SHOULD be rate limited at each point on the SFP to provide additional
   security.
NEW
   The mechanism described in this document might be used to introduce
   packets into the SFC overlay network and might be used to
   illegitimately introduce false metadata to the nodes on an SFC. 
   Therefore measures SHOULD be taken to ensure authorization of sources
   of such packets, and tunneling of such packets into the network
   SHOULD be prevented. 
   
   The amount of packets with "Next Protocol" set to "None" on an SFP
   SHOULD be rate limited at each point on the SFP to provide additional
   network security.
END

Does that do it?

Cheers,
Adrian

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Feb 2018 16:39:46 -0800

This is actually a smarter point that I was intending to make.

I was just looking at the following text?
"   according to the perceived vulnerabilities of the network. Protection
of metadata may be achieved by using encrypted transport
  between SFC entities or by encrypting the metadata in its own right."

This isn't necessarily a function of "encrypting" but rather of providing
integrity and data origin authentication, although good encryption
protocols do provide both.

-Ekr