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

On 29/06/15 20:05, Eric C Rosen wrote:
> 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.

I guess it could if one wants to be argumentative but I'm
interested that other folks here who know far more about mpls
than I think this ought be adopted, so presumably others
disagree with your evaluation.

I would repeat though, that even if one wants some additional
more complex functionality later starting now with a simpler
specification on which one can build is IMO a far better and
much more practical approach when considering key management.

That said, I'm just a plumber here, and it's really for others
to say that they'd find this useful I think.

> 
> My point is that between the applicability restrictions (no MP2P) and
> the excessive granularity (security state per label), 

I'm not clear how one could avoid some state per LSP (is that
the same as per-label?) without getting into multiparty key
management, which is a technology with very little deployment
no matter the layer at which it is defined.

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

Isn't that purely pejorative? I don't see how that's helpful.

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

Again, we're positing a two party key exchange here. If the WG don't
think that's useful that's fine. But (to up my rhetoric in response
to yours:-) asking to boil the multiparty key exchange ocean before
doing anything would be a fine recipe for doing nothing at all.

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

I disagree that that makes layer 2 security much simpler. It means
the complexity is hidden from the layer above, which is a benefit if
you don't need to see it, but most of the complexity is there just
as much even if hidden. Bear in mind that we are not saying that
there's anything wrong with layer 2 security here, but claiming
that it's that much simpler isn't convincing.

Cheers,
S.


> 
> 
> 
> 
> 
> 
> 
> 
>