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

[Christian Huitema <[e-mail]>]

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

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

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

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? In the current version, it
seems that subverting just one element in the chain will provide access
to all the metadata.

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.

-- Christian Huitema





-- 
Christian Huitema