Subject: Re: [sfc] Mail regarding draft-mglt-sfc-security-environment-req

From: <[email-masked]>
Date: Thu, 26 Nov 2015 15:39:56 +0000

Re-,

(adding the sfc list as suggested by Behcet)

The NEW proposed rationale looks good to me. It is much better than the initial "one" sentence in -00. Thank you.

BTW, it would be good to include a reference to, e.g.- https://tools.ietf.org/html/rfc6973#section-5.2.2, as an example of what is meant by privacy-sensitive data. 

Cheers,
Med

> -----Message d'origine-----
> De : Daniel Migault [mailto:[email-masked]]
> Envoyé : jeudi 26 novembre 2015 16:18
> À : BOUCADAIR Mohamed IMT/OLN; draft-mglt-sfc-security-environment-
> [email-masked]
> Cc : Behcet Sarikaya ([email-masked]); Dirk.von-
> [email-masked]; Tirumaleswar Reddy (tireddy) ([email-masked]); sfc-
> [email-masked]
> Objet : RE: Mail regarding draft-mglt-sfc-security-environment-req
> 
> Hi Mohamed,
> 
> Thanks for raising the concern. This is important for us to have feed
> backs as one of the issue we have is to provide requirements that could be
> well understood in any specific deployment case.
> I am CC the sfc design team, as we are currently discussing the whole
> scope/content of the draft.
> 
> The reason we mentioned MUST as a requirement was to specify that if you
> do not follow the requirement your are at your own risk and must provide
> the necessary means to prevent any leak - in our case enforcing the
> necessary boundaries security policies that your environment / deployment
> needs to enforce.
> 
> Would you agree with this way of defining requirements ? -- We are
> planning to indicate it more clearly.
> 
> The working version provides more explanations on the scope and
> applicability of the reqs. This has been done partly to address the
> comment from Linda among others. Once we have a more stable version we are
> planning to put it on github.
> 
> 
> What do you think of the following text ?
> 
> As a general guidance exposing privacy sensitive metadata in any
> communications between two any SFC component should be avoided. [One way,
> for example  to avoid exposing privacy sensitive metadata is to include a
> reference to the metadata instead of the metadata itself. Another way
> could be to encrypt the metadata itself - but that is part of the solution
> space.]  Applying this principle prevents any private oriented data to be
> leaked. This requirement is mandatory when the SFC is not deployed in a
> trusted environment.
> When exposition of the privacy sensitive metadata cannot be avoided and
> you are in a trusted domain, then exposing privacy sensitive metadata may
> be considered as long as they do not leak outside the boundaries of the
> trusted environment.  In this case, the security is delegated to the
> security policies of the trusted environment boundaries, that may be
> outside the scope of SFC. More especially, the security policies may be
> for example enforced by a firewall. In this specific case, the trusted
> environment MUST prevent leakage of the metadata out of the trusted
> environment and MUST ensure that untrusted node cannot access in any way
> the communications within the trusted environment.
> 
> The reason we mentioned MUST as a requirement was to specify that if you
> do not follow the requirement your are at your own risk and must provide
> the necessary means to prevent any leak - in our case enforcing the
> necessary security policies that your environment / deployment needs.
> 
> Would you agree with this way of defining requirements ?
> 
> BR,
> Daniel
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, November 26, 2015 4:08 AM
> To: [email-masked]
> Cc: Behcet Sarikaya ([email-masked]); Dirk.von-
> [email-masked]; Tirumaleswar Reddy (tireddy) ([email-masked])
> Subject: Mail regarding draft-mglt-sfc-security-environment-req
> 
> Bonjour Daniel,
> 
> Je te contacte à propos du REQ15 :
> 
> 
> 
>    REQ15: Communication MUST NOT reveal privacy sensitive metadata.
> 
> This requirement as currently worded is not accurate. It is not an issue
> if SFC-tagged packets include privacy-related data (as this is already the
> case within a domain: a network has access to that information anyway).
> What is problematic is to LEAK that information OUTSIDE an administrative
> domain