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

[Eric C Rosen <[e-mail]>]

On 6/29/2015 7:19 AM, Stephen Farrell wrote:
> 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.

That sounds like a solution in search of a problem.

My point is that between the applicability restrictions (no MP2P) and 
the excessive granularity (security state per label), it's hard to see 
that this is a reasonable approach.  Even if you brought it to PALS and 
renamed it to be "pseudowire security", the need to have security state 
per pseudowire seems like a problem.

>> The draft would really benefit from having some worked out examples of
>> how MPLS security would work in various VPN deployment scenarios,

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

First design the hammer, then figure out later whether we need to pound 
any nails?

I'd have thought that before the WG adopts the draft, there should be 
some clue as to how the proposed MPLS security mechanism would be 
applied to most of the uses of MPLS.  When asked about how it might work 
in various common deployment scenarios, I don't think it's appropriate 
to say "first we need to design the mechanisms, later on we'll figure 
out how to use them to actually solve problems".

> Why would layer 2 [security] 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.

No impact to MPLS, fixed and unchanging granularity (per-link rather 
than per-LSP), reduced state (no constantly changing nonce per label, no 
key per label) simplified data flow (security processing cleanly 
separated from network layer processing), not to mention simplified key 
distribution.  I'm having trouble seeing what hop-by-hop MPLS security 
adds except more complexity.