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

[Benjamin Kaduk <[e-mail]>]

Hi Med,

A few notes on the new security considerations

   sources within an SFC-enabled domain (e.g., line identifier).  As w
   The structure of the identifiers conveyed in these Context Headers is

I'm not sure if the "As w" is spurious or was supposed to have more after
it.

   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).  Such disclosure can be a violation in many jurisdictions

(maybe "be a violation of legal requirements"?)

   because such information should be available to very few network
   operator personnel.  Furthermore, access to subscriber data usually
   requires specific access privilege levels.  To maintain that
   protection, an SF keeping operational logs should not log the content
   of a Subscriber and Performance Policy Context Headers unless the SF
   actually uses the content of these headers for its operation.  [...]

It's not clear to me that "don't log it" would actually help all the way if
it's "having the information available on the node at all is a legal
violation" that is problem.  If it's only "operator access" that's the
problem, then the question of what kind of network capture/visibility
processes are available and to which operator personnel, which is probably
more detail than we want to get into at this point, so I'm not entirely
sure what the best option is.  (I'm also not entirely sure if this
mechanism would be fit for purpose at all if the legal requirements
prohibits "available at all on the node", but maybe that's not actually a
relevant requirement.)


More inline.

On Mon, Nov 09, 2020 at 12:42:40PM +0000, [e-mail] wrote:
> 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.  

I think it flows better, thanks.

> >    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, ".

+1

> > 
> > > >
> > > > 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.
> ...

Very nice!

> > > >
> > > > 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.

+1

Thanks again for the updates,

Ben