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

From: Eric C Rosen <[email-masked]>
Date: Wed, 1 Jul 2015 11:53:57 -0400

On 6/29/2015 5:53 PM, Stephen Farrell wrote:

> [Stephen] I'm not clear how one could avoid some state per LSP ...
> without getting into multiparty key management.

I think Adrian answered that question quite well -- a key known to only
two PEs could cover all the LSPs running between those two PEs.  I 
understand that there's a certain elegance about having a key per LSP 
and a nonce per LSP, but IMHO the practicality is questionable.

However, if Adrian is right about the use case:

> [Adrian] the desired applicability is for virtual links that span
> multiple hops in an MPLS network ..., and that OS would be enabled in
> a somewhat ad hoc manner on key LSPs but not all of them.

If the use case is to just protect a few key P2P LSPs, per-LSP state 
might not be that big a problem.  If that's the use case, the draft 
should really make it clear that the proposed procedures do not apply to 
MPLS generally and do not scale to large numbers of LSPs.

> [Stephen] state per LSP (is that the same as per-label?)

A label is the representation in the forwarding plane of an LSP, and 
generally each distinct label represents a distinct LSP.  One can think 
of an LSP as a sequence of routers leading from ingress to egress, with 
a label representing that LSP at each router as each router other than 
the ingress.  It's possible to omit the label at the egress 
("penultimate hop popping"), but  presumably this would be prohibited 
when OS is applied.

> [Stephen] 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.

Here is why I think layer 2 security is simpler:

- If you use layer 2 security, no changes to MPLS are required at all. 
That seems much simpler than using a scheme that does require changes.

- One security relationship between a pair of neighboring routers covers 
all data sent between those routers; this is much less state than is 
required for per-LSP security.  It also provides much more complete 
coverage, not limited to MPLS.  Less state, more coverage, seems simpler 
to me.

So I don't see why link layer encryption would not be preferable to MPLS 
hop-by-hop encryption in all cases.

Coming back to the issue of whether the WG should adopt the draft, I 
don't see any advantage in doing so.  This really seems to be a research 
topic, and it's not clear that this is really the right direction.  If 
it is adopted, we'll start to hear things from the IESG like "the MPLS 
WG has a consensus that this is the right approach", which will be 
followed quickly by a demand from the Security ADs that this become 
"mandatory to implement".  (This last remark is based on my experience 
with several generations of Security AD, and is not aimed at any 
particular person.)

BTW, failure to adopt the document doesn't mean that we don't think 
security is important.

It would certainly be interesting to hear from operators whether they 
think there really is a need for "opportunistic" security as opposed to 
PKI-based security, especially given the way that some of the evolving 
BGP security schemes seem to be relying on PKI-based techniques.  It 
would also be interesting to hear whether scalability is unimportant, 
because the solution only needs to be applied to small number of LSPs.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Jul 2015 17:17:47 +0100

Eric,

On 01/07/15 16:53, Eric C Rosen wrote:

I'll skip over the speculative negative rhetoric about security ADs:-)

> BGP security schemes seem to be relying on PKI-based techniques.  

That would be interesting yes, though its not actually at all about
whether one does or does not use a PKI. (A PKI could easily be used
to authenticate the keys belonging to endpoints implementing this
draft - that's an entirely straight forward option one could define
in a few minutes.)

But if one looks at the complexity of the RPKI and contrasts that with
this draft, there is a real divergence in approaches for sure. RPKI
is v. complex but aims to be comprehensive, has taken a long time to
develop and more to start deployment and may need to achieve
significant deployment before its most appealing benefits accrue.
The reason for that isn't the PKI in the RPKI name, but I think the
fact that it's main aim is to provide authentication and authorization
for the entire routing infrastructure.

This approach tries to be much more light weight and focus on ease
of deployment as and where beneficial but without trying to meet
every potential need.

My experience of security protocols is that the approach we're trying
to follow here is more likely to lead to useful deployment. But that
experience may or may not be replicated in this space, I'm not sure.

S.

---

From: Loa Andersson <[email-masked]>
Date: Mon, 13 Jul 2015 15:50:22 +0200

Working Group,

This working group adoption poll has ended. We have a new working group
document. Can the authors please post the draft as
draft-ietf-mpls-opportunistic-encrypt, without any other than
administrative changes.

The working group chairs like to note that we are accepting the
document as an Experimental draft (intended to become an Experimental
RFC), this means that while we have consensus to accept the document,
we also have consensus on that one or more experiments are necessary
to reach consensus on what a solution (if any) will look like.

/Loa
  for the wg chairs

On 2015-06-18 11:12, Loa Andersson wrote:
> 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