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

From: Loa Andersson <[email-masked]>
Date: Thu, 18 Jun 2015 11:12:09 +0200

Working Group,

This is to start a two week poll on adopting draft-farrelll-
mpls-opportunistic-encrypt-05 as an MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list ([email-masked]). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

There are no IPR disclosures directly against this document. An IPR
poll has been started in parallel to the adoption poll.

This poll ends July 2, 2015.

/Loa
MPLS wg co-chair
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 18 Jun 2015 09:46:49 +0000

Support.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, June 18, 2015 12:12 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [mpls] Poll to see if we have consensus to adopt draft-farrelll-mpls-opportunistic-encrypt as an MPLS wg document

Working Group,

Please send your comments (support/not support) to the mpls working group mailing list ([email-masked]). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document.

There are no IPR disclosures directly against this document. An IPR poll has been started in parallel to the adoption poll.

/Loa
MPLS wg co-chair
-- 

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 18 Jun 2015 12:01:37 +0100

Speaking as a co-author of this draft I am enthusiastic about getting more eyes on the material and particularly an understanding of whether the proposal is practical in implementation.

I think that bringing the work inside the working group will help achieve that.

Cheers,
Adrian

> From: Loa Andersson [mailto:[email-masked]]
> Sent: 18 June 2015 10:12
> Subject: Poll to see if we have consensus to adopt draft-farrelll-mpls-
> opportunistic-encrypt as an MPLS wg document
> 
> Working Group,
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 18 Jun 2015 07:04:05 -0700

Loa,

I support the adoption of this draft.

Thanks,
Andy

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Jun 2015 17:31:41 +0100

Seems odd to "support" one's own draft, but sure, I do:-)

I think defining this mechanism at this layer fills a gap
in the set of ways in which we can defend networks so is
well worth doing.

S.

On 18/06/15 12:01, Adrian Farrel wrote:
> Speaking as a co-author of this draft I am enthusiastic about getting
> more eyes on the material and particularly an understanding of
> whether the proposal is practical in implementation.
> 
> Cheers, Adrian
>> -----Original Message----- From: Loa Andersson [mailto:[email-masked]] 
>> Sent: 18 June 2015 10:12 To: [email-masked];
>> [email-masked] Cc:
>> [email-masked] Subject: Poll to see if we have
>> consensus to adopt draft-farrelll-mpls- opportunistic-encrypt as an
>> MPLS wg document
>> 
>> Working Group,
>> 
>> Please send your comments (support/not support) to the mpls
>> working group mailing list ([email-masked]). Please give a
>> technical motivation for your support/not support, especially if
>> you think that the document should not be adopted as a working
>> group document.
>> 
>> There are no IPR disclosures directly against this document. An
>> IPR poll has been started in parallel to the adoption poll.
>> 
>> /Loa MPLS wg co-chair --
>> Senior MPLS Expert                          [email-masked] Huawei
>> Technologies (consultant)     phone: +46 739 81 21 64
> 
>

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 18 Jun 2015 19:28:52 +0000

yes/support

	Regards,
		Greg

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, June 18, 2015 2:12 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [mpls] Poll to see if we have consensus to adopt draft-farrelll-mpls-opportunistic-encrypt as an MPLS wg document

Working Group,

/Loa
MPLS wg co-chair
--

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 22 Jun 2015 09:24:33 -0400

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.

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.

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.

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

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

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Jun 2015 12:19:36 +0100

Hi Eric,

> handled, I don't see how the draft can claim to be providing an MPLS

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.

> I'm not sure that any one security scheme is going to be suitable for

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.

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

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

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

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

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

> 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

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.

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 29 Jun 2015 15:05:21 -0400

On 6/29/2015 7:19 AM, Stephen Farrell wrote:
> What we're doing here I think is documenting a security

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.

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Jun 2015 22:53:41 +0100

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

> 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

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

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

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 30 Jun 2015 12:24:05 +0100

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

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: 29 June 2015 22:54
> To: Eric C Rosen; Loa Andersson; [email-masked]; draft-farrelll-mpls-opportunistic-
> [email-masked]
> Subject: Re: [mpls] Poll to see if we have consensus to adopt draft-farrelll-mpls-