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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Christian,

Thank you for the dialogue — please see inline.

> On Sep 9, 2017, at 7:42 PM, Christian Huitema <[e-mail]> wrote:
> 
> 
> 
> On 9/7/2017 9:06 AM, Carlos Pignataro (cpignata) wrote:
>> Christian,
>> 
>> Thanks for taking time to review this document. The net-result of addressing them will be an improved specification.
> I am looking at the changes between draft-18 and draft-20, and draft-20
> is indeed improved.

This is great to hear. Thank you for your comments that, along with others', resulted in incorporating needed clarifications and a more precisely-scoped specification.

>> 
>> We took some additional time before responding, because some of your comments are very likely addressed (or partially addressed at least) in the current revision -20. 
>> 
>> You raise some very general broadly-scoped questions, such as “Why is the IETF even working on such specifications?” Those are probably beyond the scope of a SecDir review, but nonetheless, important LC comments. As those are beyond the technology specifics of draft-ietf-sfc-nsh, I can (and I do) share my perspective, but I will let others (responsible AD, sfc chairs, doc shepherd) add on more authoritatively.
>> ...
>> 
>> But, if you knew all this, I am not sure what is the question behind your question… 
>> 
>> I can offer that there’s market demand for interoperable implementations of service function chaining solutions...
> 
> I have no doubt that there are multiple products developed and sold, and
> that interoperable specifications are preferable to competing
> proprietary specifications. My initial reaction was largely motivated by
> the lack of scoping in the document.

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

That said, we arrived at the same place after just one round-trip, and rev -19 plus rev -20 successively make that more clear and less ambiguous.

The doc is improved, making those assumptions explicit in the text.

> Without that scoping, it looks like
> a general architecture for adding metadata to packets on the Internet,
> and that's a big red flag, big enough to state that no, the IETF should
> not endorse that at all, interop be damned.
> 
> The scoping mitigates some of the concerns. I am still troubled by some
> of the specification, such as the example giving a scope as "a campus
> physical network". Environments like that are only partially controlled.
> Adding metadata to packets in such wide locations could enable many
> attacks.

OK, we can qualify the campus network with “controlled”, or frankly remove it or choose a different example. It is, after all, an example.

> 
>> 
>>> What
>>> does this have to do with the Internet?
>> I’ll just share that, just like RFC 7665, this specification narrowscopes itself to a single provider’s operational domain. 
>> 
>> Relevant text from revision -20, that was not there on the revision -18 you reviewed, includes:
>> 
>> The intended scope of the NSH is for use within a single provider's
>> operational domain.  This deployment scope is deliberately
>> constrained, as explained also in [RFC7665], and limited to a single
>> network administrative domain.  In this context, a "domain" is a set
>> of network entities within a single administration.  For example, a
>> network administrative domain can include a single data center, a
>> campus physical network, or an overlay domain using virtual
>> connections and tunnels.  A corollary is that a network
>> administrative domain has a well defined perimeter.
> 
> Yes, I saw that. That's good. But I also only see minimal mechanisms in
> the draft for enforcing the removal of the metadata before a packet
> leaves the specified domain. Section 2 states that "the last SFF in the
> service chain removes the NSH". That's fine, but that's not a fail-safe
> mechanism.

The I-D mentions in several places beyond Section 2 the requirement to remove the NSH on SFP exit. The Security Considerations currently includes:

 Means to prevent
 leaking privacy-related information outside an administrative domain
 are natively supported by the NSH given that the last SFF of a
 service path will systematically remove the NSH encapsulation before
 forwarding a packet exiting the service path.

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.

>> 
>>> And why such disregard
>>> for privacy and security? In any case, this document has significant
>>> issues. It does not explaining where exactly the proposed Network
>>> Service Header would be inserted (MPLS or IPv6?).
>> This is another good comment, we believe is already addressed in rev -20 with the additions to the Introduction and Figure 1, among others.
> 
> Figure 1 does help, thank you. I assume that the intent is to complete
> the NSH draft with specifications of the actual encapsulations over
> MPLS, Ethernet, IPv4 and IPv6. But it is pretty hard to review the
> security of the system without a description of these encapsulations.

The specifics of those are expected in separate documents, as needed (for MPLS, or UDP, or VXLAN-GPE, etc).

> 
>> 
>>> The security
>>> provisions boil down to lip-service mentions of IPSEC, and that's way
>>> insufficient given the nature of the protocol.
>>> ...
>>> ...
>> I believe one source of confusion here is the extrapolation of carrying privacy-sensitive metadata across the Internet. That is not the case.
>> 
>> The so-called "RFC 7665" defined the applicability scope, but we the NSH specification has failed to make that clear. This is a good point, and one that needs text changes. We took initial steps in -20 to correct that and be clear and explicit.
> Yes, the new introduction is much better.

Good to see. Thank you.

>> 
>>> In a spirit of
>>> cooperation, I choose the latter, and here is the two steps advice:
>>> 
>>> The first step to better security and privacy there would be to present
>>> the practical deployment conditions. I could only make guesses, and
>>> that's silly. There should be some kind of diagram explaining how the
>>> SFH is inserted in packets, and where it sits between Ethernet, MPLS and
>>> IP.
>>> 
>>> The next step is to develop a protection model. Given that the goal of
>>> the architecture is to decorate the packets with sensitive metadata,
>>> there need to be some thinking about who should be able to see it. How
>>> would path encryption like IPSEC be deployed? Should all elements on
>>> path really be able to access all metadata, or should some of it be
>>> further protected?
>>> 
>>> Please fix that before the document is published.
>>> 
>> A lot of this conversation is déjà vu of the RFC 7665 WG, LC, and ballot discussions. Those discussions resulted in significant work with the Security ADs, security-focused SFC experts, and SFC-focused security experts; those in turn are codified in the text of RFC 7665’s security considerations.
> 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.

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

> In the current version, it
> seems that subverting just one element in the chain will provide access
> to all the metadata.

Not really. NSH replies on a existing encryption solutions for both confidentiality and integrity protection.  As per the draft, if an operator deems additional protection needed, then they utilize time proven, standard protocols in conjunction with NSH.  Not only is this consistent layering-wise, but also ensure that the crypto solution is one that is well vetted and understood.

If you are directly talking about metadata-level encryption, I’ll let Joel (as shepherd and chair) comment since that was a topic discussed in the WG.

That said, again, there is likely an opportunity to polish a bit. Will try.

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

Thanks again for the review and comments.

Best,

—
Carlos Pignataro, [e-mail]

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis.”

> 
> -- Christian Huitema
> 
> 
> 
> 
> 
> -- 
> Christian Huitema
> 
>