Re: [mpls] Poll to see if we have consensus to adopt draft-farrelll-mpls-opportunistic-encrypt as an MPLS wg document

[Stephen Farrell <[e-mail]>]

Hi Eric,

On 22/06/15 14:24, Eric C Rosen wrote:
> I don't think we can tell yet whether this draft really provides a good
> basis for future work.  As such, it seems premature for the WG to adopt
> it.  I think there are several major issues that should be confronted
> first.
> 
> The draft seems heavily focused on P2P LSPs.  That wouldn't be a problem
> if it were about pseudowire security.  But it's a big problem if the
> draft is supposed to apply to MPLS generally.  There's a lot of MPLS out
> there that uses LDP or BGP (or even IGP) to bind labels to address
> prefixes, thereby creating MP2P LSPs.  If that's not going to be
> handled, I don't see how the draft can claim to be providing an MPLS
> security scheme.

The key exchange in the draft only covers two party cases, yes. That's
deliberate since multi-party key exchange is a really hard problem with
a history of solutions that don't get deployed.

If or when someone documented a way to establish a key between multiple
parties, then that key could be used as documented here. However, I
think it's still better to document both a two party key exchange and
the bulk encryption in one document as we've done, as that combination
is basically the minimum needed to get something useful.

I have no opinion on whether that causes some terminology issue, but
wouldn't have any problem with clarifying any such.

> Of course, it could be that MPLS is not the right layer for security;
> I'm not sure that any one security scheme is going to be suitable for
> all uses of MPLS.

I think it's fairly well accepted that there is no "right layer for
security." What we're doing here I think is documenting a security
mechanism for this layer for use in cases when this layer turns out
to be what someone wants to use.

I don't think it's a goal of this draft to define every cryptographic
security mechanism that will ever be needed for all uses of MPLS, and
I think it'd be unwise to adopt such a goal.

> 
> The idea of applying security on a per-LSP basis doesn't really seem
> right either.  In VPN, with per-address-prefix labeling, there could be
> hundreds of thousands of LSPs.  I can see someone claiming that security
> needs to be provided on a VRF-to-VRF basis rather than on a PE-to-PE
> basis, but having security on a per-address-prefix basis seems like way
> too much granularity.  I can't really tell from the draft how it would
> be intended to apply to VPN, so I don't really know what the authors
> have in mind for securing VPNs.

Is it possible you're missing out on the opportunistic nature of
the scheme here? When you say "securing" a VPN, I would have thought
that one would want endpoint authentication for that, and ways to
do endpoint authentication are outside the scope of this draft. So
any work to address endpoint-authenticated VPNs could build on this
draft, but wouldn't be a part of this draft.

I personally think that the approach of defining the basic mechanism
opportunistically and then figuring out ways to bootstrap from that
to endpoint-authentication is much more likely to work out than if
we followed the approach of trying to define all of the automated
key management needed for multiparty endpoint authentication now.

> The draft would really benefit from having some worked out examples of
> how MPLS security would work in various VPN deployment scenarios,
> including the following (and combinations thereof):
> 
> - Multi-AS VPN with "option b" interconnect
> 
> - Multi-AS VPN with "option c" interconnect
> 
> - VPN with per-address-prefix labels assigned by BGP
> 
> - VPN with per-VRF labels assigned by BGP

Again, I think that the above would be done building on top of this
scheme, but not as part of this scheme. But I admit that I don't myself
understand those deployment scenarios enough to be certain of that.

> The multi-AS VPN cases are particularly interesting, because they make
> use (in different ways) of nested LSPs.  Someone who wants privacy for
> his VPN traffic will want security applied to the inner LSP (the one

(Aside: I'm not sure what you mean by "want security" there, but I
think we maybe don't need to bottom out on that right now. And I also
assume you mean confidentiality when you say privacy.)

> that goes from the ingress PE to the egress PE), not just to the outer
> LSPs (the ones that go from ingress PE to ASBR, etc.) but it's not clear
> whether any of the techniques in the draft can be used that way.

Yes, it ought be possible to nest the scheme. If not, we should fix
it so it can be, but I think that should just work. In any case,
there's no  cryptographic reason why that should be hard so long as
we're talking about nesting.

> There are also cases where labels get assigned to anycast addresses.  I
> wonder how the security scheme would be applied to those cases.

Again, we're only defining a two party key exchange here. More complex
things could be done later.

> 
> There are other issues in the draft as well, such as whether
> MPLS-specific hop-by-hop security is really useful when one can use
> simpler layer 2 security schemes instead. 

Why would layer 2 be simpler? If you mean because it already exists
and can be used that's fine, but I'd be interested if there were some
way in which MACsec were substantively simpler. (I don't believe there
is but maybe I'm wrong.)

> But right now my main concern
> is that the end-to-end scheme will turn out to have very limited
> applicability.
> 
> Working out some realistic examples would help us understand whether
> this is really the right way to proceed.

Actually, I think regardless of what kind of scenario one considers,
you will end up needing to define a two party key exchange and a
way to do the bulk encryption, so I think what's proposed here is
basically the minimum needed to provide any confidentiality service.

I do agree that how one might build from that is something to consider,
but I don't think the WG need to hold off on doing this work in order
to later figure out how to handle much more complex endpoint-
authenticated multiparty scenarios.

Cheers,
S.


> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> 
>