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

["Adrian Farrel" <[e-mail]>]

I think there are two things going on in one conversation. There is multi-party key exchange that one might need for P2MP or MP2P so that all senders/receivers on a multi(>2)-party LSP have the sam key. And there is multi-LSP keying where all LSPs (or a subset of all LSPs?) between a pair of LSRs use the same key.

The former would be ugly especially in an opportunistic world. That limits the applicability of MPLS-OS to P2P LSPs. Eric is right that this cuts out "routed MPLS" so that the classic LDP application would be unable to use MPLS-OS. (Although, there may be scope to identify the sender or the MPLS-OS SA per packet as is done for OAM - the question is whether it can be handled at line rate for a large number of senders.) 

So this degrades to determining whether MPLS-OS would be useful if limited to TE LSPs (RSVP-TE and static provisioning) and PWs (T-LDP and static provisioning).


The second issue is a trade...
- maintain security state per LSP
versus
- maintain a nonce across LSPs
- handle "all or nothing" for LSPs between a pair of LSRs


My feeling from various conversations over the last 18 months is that the desired applicability is for virtual links that span multiple hops in an MPLS network (which maps to TE LSPs and PWs quite well), and that OS would be enabled in a somewhat ad hoc manner on key LSPs but not all of them.

I think that at this point we need operators to speak. Even though we are still looking at this as an experiment and a feasibility study, it would help a lot to know where and how this might get used.

And that last point cuts a little into "a solution in search of a problem". We know, in general that there is a problem with wholesale tapping of data in tier 1 networks: and we know that organised crime is in this business. We also know that individual users should but do not protect their own transactions, and would find it hard to protect their metadata. So there is a problem that needs attention. Is this the single solution that will fix it? No. Could it be a tool to help? That is what we would like to find out. Is a WG Experimental I-D something vendors should feel pressure to implement? No, absolutely not especially if the operators on this list are not joining in the discussion. 

Thanks,
Adrian


> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: 29 June 2015 22:54
> To: Eric C Rosen; Loa Andersson; [e-mail]; draft-farrelll-mpls-opportunistic-
> [e-mail]
> Cc: [e-mail]
> Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-farrelll-mpls-
> opportunistic-encrypt as an MPLS wg document
> 
> 
> 
> 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.
> 
> 
> >
> >
> >
> >
> >
> >
> >
> >
> >