Subject: [sfc] Security Considerations in draft-ietf-sfc-nsh-05

From: Martin Stiemerling <[email-masked]>
Date: Fri, 19 Aug 2016 08:37:46 +0200

Dear all,

I am in the process of reviewing the different documents with respect to 
security and did run through RFC 7665. RFC 7665 is doing a pretty good 
job in highlighting the areas of interest with respect to SFC security.

However, I am shocked by what is document (or better *not* documented) 
in the NSH draft. Right now the security considerations section says this:

   "As with many other protocols, NSH data can be spoofed or otherwise
    modified.  In many deployments, NSH will be used in a controlled
    environment, with trusted devices (e.g. a data center) thus
    mitigating the risk of unauthorized header manipulation.

    NSH is always encapsulated in a transport protocol and therefore,
    when required, existing security protocols that provide authenticity
    (e.g.  RFC 2119 [RFC6071]) can be used.

    Similarly if confidentiality is required, existing encryption
    protocols can be used in conjunction with encapsulated NSH.

    Further security considerations are discussed in [nsh-sec]."

This is handwaiving and will not survive any stage of WG external 
review. So we as WG are better working on this now!

Three ideas to get the discussion started:
- The usage of NSH may increase the usage of IP fragments. This can lead 
to security issues, but potentially in the reverse, as a number of 
firewalls are blocking IP fragments. See also RFC 1858. This may be 
worth to document.

- NSH can be encapsulated in different "transports", e.g., GRE, 
Ethernet, VXLAN, etc. This has also implications and mainly it will ok 
to say that these encapsulations have also security considerations that 
have to be properly obyed.

- NSH is going to carry meta data that is linked to Personally 
Identifiable Information (PII). How is NSH dealing with this? This has 
to be mentioned and the solution has to be documented.

There are more issues to think about, of course.

Regards,

   Martin

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 19 Aug 2016 11:04:51 -0500

Hi Martin,

On Fri, Aug 19, 2016 at 1:37 AM, Martin Stiemerling <[email-masked]> wrote:
> security and did run through RFC 7665. RFC 7665 is doing a pretty good job
> in highlighting the areas of interest with respect to SFC security.
>
> However, I am shocked by what is document (or better *not* documented) in
> the NSH draft. Right now the security considerations section says this:
>
> This is handwaiving and will not survive any stage of WG external review. So
> we as WG are better working on this now!
>
> - The usage of NSH may increase the usage of IP fragments. This can lead to
> security issues, but potentially in the reverse, as a number of firewalls
> are blocking IP fragments. See also RFC 1858. This may be worth to document.
>
> - NSH can be encapsulated in different "transports", e.g., GRE, Ethernet,
> VXLAN, etc. This has also implications and mainly it will ok to say that
> these encapsulations have also security considerations that have to be
> properly obyed.
>
> - NSH is going to carry meta data that is linked to Personally Identifiable
> Information (PII). How is NSH dealing with this? This has to be mentioned
> and the solution has to be documented.
>

We do have some metadata that is linked to Personally Identifiable
Information in
https://tools.ietf.org/id/draft-sarikaya-sfc-hostid-serviceheader-03.txt

Also in this draft we have a Privacy Considerations section which deals with it.

I think that it should be left into the individual documents to deal
with security and privacy issues for the metadata that they define.
I think you alluded to this in your next mail, which we concur.

Regards,

Behcet
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 19 Aug 2016 12:43:02 -0400

I can not find the original email from Martin.
The security considerations section was discussed during the IETF 
meeting in Berlin.
The next revision of the draft will have more explanation of what we are 
and are not commiting to in the base spec regarding security.  This 
includes a recapitulation of the recommendations regarding metadata from 
the architecture document, and observations as to why we expect that we 
can cover security issues when they are needed with the current header 
structure.

Yours,
Joel

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 24 Aug 2016 09:10:52 +0000

Agree with Martin's observation. On the second note, NSH is an encapsulation, similar to NxLAN, GRE, LISP, except NSH has many more bytes than other types of encapsulation. Therefore, there is higher chance of fragmentation,  which IMHO needs to be addressed.  

Linda
-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Martin Stiemerling
Sent: Friday, August 19, 2016 1:38 AM
To: [email-masked]
Subject: [sfc] Security Considerations in draft-ietf-sfc-nsh-05

Dear all,

I am in the process of reviewing the different documents with respect to security and did run through RFC 7665. RFC 7665 is doing a pretty good job in highlighting the areas of interest with respect to SFC security.

However, I am shocked by what is document (or better *not* documented) in the NSH draft. Right now the security considerations section says this:

This is handwaiving and will not survive any stage of WG external review. So we as WG are better working on this now!

Three ideas to get the discussion started:
- The usage of NSH may increase the usage of IP fragments. This can lead to security issues, but potentially in the reverse, as a number of firewalls are blocking IP fragments. See also RFC 1858. This may be worth to document.

- NSH can be encapsulated in different "transports", e.g., GRE, Ethernet, VXLAN, etc. This has also implications and mainly it will ok to say that these encapsulations have also security considerations that have to be properly obyed.

- NSH is going to carry meta data that is linked to Personally Identifiable Information (PII). How is NSH dealing with this? This has to be mentioned and the solution has to be documented.

Regards,

   Martin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Aug 2016 12:48:17 -0400

Folks, please look at the Security considerations section in -07.  We 
attempted to address the issues that many people have raised.  If we 
missed something, please let us know.

Yours,
Joel