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