Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-serviceid-header-12: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Ben, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[e-mail]] De la part de Benjamin Kaduk
> Envoyé : vendredi 6 novembre 2020 21:16
> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
> Cc : [e-mail]; Greg Mirsky
> <[e-mail]>; [e-mail]; The IESG
> <[e-mail]>; [e-mail]
> Objet : Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-
> serviceid-header-12: (with DISCUSS and COMMENT)
> 
> Hi Med,
> 
> Thanks for another quick turnaround.
> (Inline.)
> 
> On Wed, Nov 04, 2020 at 10:33:26AM +0000,
> [e-mail] wrote:
> > Re-,
> >
> > Focusing on the DISCUSS.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Benjamin Kaduk via Datatracker [mailto:[e-mail]]
> Envoyé
> > > : mercredi 4 novembre 2020 05:37 À : The IESG <[e-mail]>
> Cc :
> > > [e-mail]; [e-mail];
> > > [e-mail]; Greg Mirsky <[e-mail]>;
> > > [e-mail] Objet : Benjamin Kaduk's Discuss on
> > > draft-ietf-sfc-serviceid-header-
> > > 12: (with DISCUSS and COMMENT)
> > >
> > > Benjamin Kaduk has entered the following ballot position for
> > > draft-ietf-sfc-serviceid-header-12: Discuss
> > >
...
> > >
> > > To record some additional synthesis of the above (original)
> remark
> > > with my more thorough reading of the document: we are defining
> > > containers specifically to contain subscriber and performance
> policy
> > > identifiers/information.  While the specific contents are out of
> > > scope for this document, we still are obligated to describe the
> > > general classes of issues that can arise due to conveying those
> > > types of information within a SFC domain.  We should also give
> > > guidance on how to populate the contents of these context
> headers in
> > > a secure and privacy-supporting manner, including the use of
> > > indirect identification and obfuscation/encryption.
> >
> > [Med] I made the following changes:
> > * Reiterate the reco to use obfuscated as this may be missed in
> the "one" pointer to the Security section of 8300.
> > * Add a new text for the use of non-persistent identifiers as well
> as instructing SFs to remove the header early in the SFP.
> > * Add new text to illustrate that the nature of SFs in a chain and
> a subscriber ID may be a privacy violation.
> > * Add text to point to the NSH encryption when obfuscation is not
> sufficient.
> >
> > The full text can be seen in: https://tinyurl.com/sfc-service-
> iesg.
> 
> Thanks, this is improving.
> 
> Some notes:
> 
> 
>    Aligned with Section 8.2.2 of [RFC8300], this identifier SHOULD
> be
>    obfuscated.
> 
> Maybe
> 
> % While this document does not specify an internal structure for
> these % identifiers, it also does not provide any cryptographic
> protection for % them; any internal structure to the identifier
> values chosen will thus be % visible on the wire.

[Med] s/the wire/the wire if no secure transport encapsulation is used.

  Accordingly, in
> alignment with Section 8.2.2 of % [RFC8300], identifier values
> SHOULD be obfsucated.
> 
> though I would be receptive to claims that this is hitting the
> reader over the head too much or too redundant with the new security
> considerations text.

[Med] It is indeed redundant but given the various comments I don't object to have it mentioned twice so that we (hopefully) avoid confusions.  

> 
>    headers (e.g., IP addresses).  If no secure transport
> encapsulation
>    is enabled, the use of trivial subscriber identifier structures
>    together with the presence of specific SFs in a service function
>    chain may reveal sensitive information to every on-path device
> (but
>    also to teams managing these devices).  [...]
> 
> I think the concerns are greater when combining the presence of
> specific SFs with a given identifier, but there are considerations
> just from having the unprotected identifier present on its own.
> Typically we would cover these baseline considerations for "having
> this information at all" first, and then go on to talk about
> additional considerations in more complicated scenarios.  (I can't
> quite tell if some of the following text is intended to cover this
> "baseline" scenario or not.)
> 

[Med] Updated and rearranged the text: https://tinyurl.com/sfc-service-iesg. I hope this is better.  

>    headers for its operation.  As discussed in Section 8.2.2 of
>    [RFC8300], subscriber-identifying information should be
> obfuscated
>    and security features in the transport encapsulation protocol
> (such
>    as IPsec) must be used.  A mechanism for encrypting sensitive NSH
> 
> AFAICT the "must be used" is referring to this chunk from 8300:
> 
> % Protecting NSH metadata information between SFC components can be
> % done using transport encapsulation protocols with suitable %
> security capabilities, along the lines discussed above.  If a %
> security analysis deems these protections necessary, then security %
> features in the transport encapsulation protocol (such as IPsec) %
> MUST be used.
> 
> which is a conditional "MUST", and I'm not sure the text proposed
> here catches that nuance.
> 

[Med] We can add: "if an operator deems cryptographic integrity protection needed, ".

> 
> > >
> > > Futhermore (and this part is not a discuss point but may lead to
> me
> > > switching my position to Abstain once the discusses are
> resolved), I
> > > have some misgivings about including subscriber identification
> > > information at all, and would prefer if it could instead be
> > > translated into the relevant policy information element(s)
> needed by
> > > the SFP in question before being applied to the NSH.  For
> example,
> > > rather than saying "this packet is from user X" we could say
> "this
> > > packet is part of quota bucket ABC (with bucket size Z) for time
> > > period Y" to enforce per-user quota.
> >
> > [Med] Putting aside how the quota usage can be conveyed in a
> policy instead of a subscriber id, the issue Ben is that a per-
> subscriber policy is not only about a quota. There are bunch of SFs
> that are making use of the subscriber identifier (e.g., implicit
> identification to portal, control the number of devices of a
> subscriber accessing to a service). The identity of the subscriber
> is also needed for various reasons (legal data retention).
> 
> Of course it's not just for the quota, yes -- quota is just an easy
> example that fits very nicely into my point (as opposed to some of
> the other examples you list, which do not fit so well) :) On the
> other hand, "apply resource quota" is the only listed example at
> present, so there might be cause to add a few more examples to that
> list.
> 
> I recognize that in some cases the raw subscriber ID is the most
> effective tool to use, but I am hoping that the document can also
> mentionn other alternatives that can apply in other cases and are
> compatible with the principle of least privilege.  We cannot tell
> people how to run their networks, of course, but we can list some
> options and why/when they might be advantageous.

[Med] What about?

OLD:
   This subscriber identifier can be used by service
   functions to enforce per-subscriber policies (e.g., apply resource
   quota).

NEW:
   The Subscriber Identifier Context Header is used by service functions
   to enforce per-subscriber policies (e.g., resource quota, customized
   filtering profile, accounting).  To that aim, network operators may
   rely on identifiers that are generated from those used in legacy
   deployments (e.g., Section 3.3 of[I-D.ietf-sfc-use-case-mobility]).
   Alternatively, network operators may use identifiers that are
   associated with customized policy profiles that are preconfigured on
   SFs using an out of band mechanism.  Such mechanism can be used to
   rotate the identifiers allowing thus for better unlinkability
   (Section 3.2 of [RFC6973]).  Such alternative methods may be
   suboptimal (e.g., scalability issues induced by maintaining and
   processing finer granular profiles) or inadequate to provide some
   per-subscriber policies.  The assessment whether a method for
   defining a subscriber identifier provides the required functionality
   and that it is compliant with SFs capabilities with the intended
   performance levels is deployment specific.
...

> > >
> > > I have an additional Discuss point after doing a more thorough
> > > review of the document -- I think there's a (minor) internal
> > > inconsistency within Section 3:
> > >
> > >    Intermediary NSH-aware nodes have to preserve Subscriber
> > > Identifier
> > >    Context Headers (i.e., the information can be passed to next
> hop
> > > NSH-
> > >    aware nodes), but local policy may require an intermediary
> NSH-
> > > aware
> > >    node to strip a Subscriber Identifier Context Header after
> > > processing
> > >    it.
> > >
> > > since it seems to say that NSH-aware intermediary nodes both
> "have
> > > to preserve" and "may strip" a Service Identifier Context
> Header.
> >
> > [Med] The default behavior is to preserve the context header when
> present, but the node may strip it if it is instructed to do so.
> 
> Ah, that should be an easy text change, then.
> 

[Med] Updated to: 

   The default behavior of intermediary NSH-aware nodes is to preserve
   Subscriber Identifier Context Headers (i.e., the information can be
   passed to next hop NSH-aware nodes), but local policy may require an
   intermediary NSH-aware node to strip a Subscriber Identifier Context
   Header after processing it.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.