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