Re: [secdir] SECDIR review of draft-ietf-sfc-nsh-18

["Joel M. Halpern" <[e-mail]>]

IF removing the two references to Campus networks would help, we can do 
that.  deployment in a campus (sa distinct from the DC within campus) is 
indeed more complex.

With regard to threats, a lot of the reason I have trouble with 
providing good answers is that a service function that stores the 
metadata for later analysis is perfectly legitimate.  If the operator 
contract with the SF provider is that the provider gets the metadata the 
service function sees, that the operators chaice.  Given that SFs have 
to be able to get at whatever metadata they need, the protocol can not 
inherently prevent that. People have suggested in Internet-Drafts 
mechanisms whereby the SFF trim and restore the metadata sets.  that 
does not actually rpevent this, it merely adds the complication that the 
operator has to configure what is allowed where.  If their contract for 
a given SF says that it gets all the metadata, it will get all the metadata.
The one piece we can do is that personally identifying metadata can be 
obfuscated, preferably by indirection.  We should however recognize that 
the indirection will be known to the operator, and if they choose to 
reveal it by other means we can not prevent that.

Yours,
Joel

On 9/17/17 12:21 AM, Christian Huitema wrote:
> 
> 
> On 9/14/2017 4:22 AM, Carlos Pignataro (cpignata) wrote:
>> ...
>> it’s not uncommon to forget how broadly understood assumptions and design criteria for a document are, when being knee-deep in work. This is probably the case here, in which scope should have been more explicit.
>>
>> For completeness, the document is the document plus its context. A peek at the normatively-cited RFC 7665, SFC architecture, (or at the charter as part of a Directorate review) would have proactively reduced your concerns, leaving the editorial need to make it very clear and explicit in “the document” (as opposed to your initial reaction).
> I did read RFC 7665. Before writing the initial review, and again now as
> a refresher. Yes, RFC 7665 mentions an "administrative domain". But it
> is also a very abstract document, leaving open many possibilities. And
> it does contain the text about sharing metadata along a function path
> that gave me pause: "For example, an external repository might provide
> user/subscriber information to a service chain classifier. This
> classifier could in turn impose that information in the SFC
> encapsulation for delivery to the requisite SFs. The SFs could in turn
> utilize the user/subscriber information for local policy decisions.
> Metadata can also share SF output along the SFP." The draft translates
> the architecture into practical protocol specification. It is good to
> include at that stage concrete protections.
>> OK, we can qualify the campus network with “controlled”, or frankly remove it or choose a different example. It is, after all, an example.
> I saw the "controlled" addition in your text, but I don't quite
> understand what a "controlled campus network" is. I understand that one
> of the goals is to place a variety of functions in separate boxes
> independently of topology, but if I was managing a campus network I
> would much rather place these functions in controlled spaces like data
> centers rather than, say, student dorms. Not all places on the campus
> will be tightly controlled. It might be simpler to just not mention
> these campus networks.
> ...
>> How would you suggest this can be strengthened? We do add some relevant text based on the next comment.
>>
>>> The draft mentions using IPv4 or IPv6 as transport. It seems
>>> that in that case there should be some ingress/egress filtering, as in
>>> "packets originating outside the service domain must be dropped if they
>>> contain an NSH," and similarly must be drop on domain exit if they
>>> contain an NSH.
>>>
>> This is a good suggestion. We can add some clarifying text after the first paragraph of the Security Considerations.
>> This can take care of your previous comment as well.
> I saw the text added in the latest draft. That's fine.
> 
>>> The new security section does provide a number of recommendations, such
>>> as the obfuscation of metadata. That's definitely an improvement. But I
>>> believe there are still issues.
>>>
>>> The first issue is that "Metadata privacy and security considerations
>>> are a matter for the documents that define metadata format." That does
>>> not give me a warm and fuzzy feeling at all. I understand that the
>>> formats will be only registered "after IETF review", but these future
>>> reviews would be much easier if the NSH mechanism defined at least a
>>> baseline security posture, and maybe some generic mechanisms for
>>> obfuscation or encryption.
>> I do not know if future reviews might or might not be easier, since there would be a need for a reviewer to follow and read normative references, which practice shows not always happens... But, that aside, ease of future review for reviewers is not a design principle for NSH :-)
>>
>> That said, I agree that there is an opportunity to, without specifying, provide forward-looking guidance or references to potential work. We will add that in.
> 
> I see that you added references to "proof of transit" in draft-21. That,
> and the reference to obfuscating subscriber info, certainly helps. It
> seems that the security protection is based on three broad principles:
> 
> 1) Encrypt the data in transit, using IPSEC or similar;
> 
> 2) Obfuscate by default critical metadata such as subscriber info;
> 
> 3) Encrypt some of the metadata.
> 
> That's not a bad posture, but I wish that you were explicit about the
> threats. I am somewhat concerned that the "administrative domain"
> approach leads to complacency, as in "my domain is secure, I am only
> concerned with external leakage". I think it would be good to point at
> explicit threats. Encrypt in transit addresses one type of threats,
> adversaries tapping conduits to observe the data. But how about hacking
> into an SFF? Or providing a "free" function that pays for itself by
> collecting the meta-data? These all go into the idea that in a complex
> system, it is good to compartment who routinely sees what information.
> That's the rational motivating obfuscation and other such techniques,
> and it would be nice to be explicit about it.
> 
>>
>>> The second issue is that the security section provide recommendations
>>> about solutions, but does not analyze the threats. In particular, one of
>>> the threats that I find worrisome is, what happens if a specific
>>> function in a service chain gets subverted?
>> If a firewall or a router gets subverted, we likely have bigger problems. More below.
> Maybe. Maybe not. What if an intrusion detection system gets subverted?
> What if an accounting system gets subverted? You hope that the intrusion
> will be detected shortly, but principles like "least privilege" are a
> good way to provide defense in depth and minimize the damage during the
> early stages of the intrusion.
> 
> 
> 
>>> I may be paranoid, but there is already an history of adversaries
>>> attacking complex systems like data centers, network control systems or
>>> corporate networks, not to mention campus networks. These adversaries
>>> typically proceed by lateral movement after an initial penetration until
>>> they get closer to their actual target inside the domain. I can see an
>>> adversary trying to penetrate one of these domains in order to access
>>> the metadata. In our case, it would try to find a weak link in the
>>> service function chain. It maybe that one of the functions is deemed
>>> benign, and thus was less secured than the others. But if all functions
>>> see the metadata, then the adversaries will achieve their goal by
>>> targeting that weak link. Some application of the "least privilege"
>>> principle would be useful there.
>> See above. Not all functions see the metadata, if so desired. For example, all SFFs do not see any metadata if the transport uses existing proven encryption techniques, IPsec, TLS, etc.
> 
> Yes. Somehow stating that and explaining why it matters would be nice.
> 
> -- Christian Huitema
> 
>