Subject: [mpls] FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 9 Jan 2014 11:51:03 -0000

Hi MPLS working group,

Stephen and I have been looking at MPLS data plane security and wondering
whether anything could be done to help protect against various types of bulk
surveillance achieved by tapping entire links without requiring full and
management-heavy establishment of security associations.

This I-D is very rough! it is a first attempt to show what might be achieved. We
are confident that there are problems with what we have suggested both from a
security and an MPLS perspective. Your thoughts and comments are encouraged.

Thanks,
The Farrel twins.

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 09 January 2014 11:44
> To: [email-masked]
> Subject: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 
>         Title           : Opportunistic Encryption in MPLS Networks
>         Authors         : Adrian Farrel
>                           Stephen Farrell
> 	Filename        : draft-farrelll-mpls-opportunistic-encrypt-00.txt
> 	Pages           : 22
> 	Date            : 2014-01-09
> 
> Abstract:
>    This document describes a way to apply opportunistic encryption
>    between adjacent nodes on an MPLS Label Switched Path (LSP) or
>    between end points of an LSP.  It explains how keys may be exchanged
>    to enable the encryption, and indicates how key identifiers are
>    exchanged in encrypted MPLS packets.  Finally, this document
>    describes the applicability of opportunistic encryption in MPLS
>    networks with an indication of the level of improved security as well
>    as the continued vulnerabilities.
> 
>    This document does not describe security for MPLS control plane
>    protocols.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic-encrypt/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Mark Tinka <[email-masked]>
Date: Thu, 9 Jan 2014 15:14:29 +0200

On Thursday, January 09, 2014 01:51:03 PM Adrian Farrel 
wrote:

> Hi MPLS working group,
> 
> Stephen and I have been looking at MPLS data plane
> security and wondering whether anything could be done to
> help protect against various types of bulk surveillance
> achieved by tapping entire links without requiring full
> and management-heavy establishment of security
> associations.
> 
> This I-D is very rough! it is a first attempt to show
> what might be achieved. We are confident that there are
> problems with what we have suggested both from a

Thanks for this draft, Farrel twins.

As an operator, my rather high level concerns are:

	- What impact does this have on linear data plane
	  throughput?

	- What impact does this have on data plane
	  operational complexity?

	- What impact does this have on the control plane.

	- How efficient is key management on a global level,
	  and what is the practical impact to day-to-day
	  operations, for situations where MPLS paths cross
	  distinct routing domains?

	- What kind of backward compatibility is there for
	  domains that do not participate, or for nodes
	  within the same domain that do not participate, as
	  this has an impact on overall domain capability
	  (i.e., cost).

Cheers,

Mark.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 9 Jan 2014 14:16:03 -0000

Hi Mark,

Thanks for the rapid response.

I leave some of your questions for wider discussion and just respond to a few of
them...

> 	- What impact does this have on linear data plane

TBD
Some people have noted that per hop encryption/decryption might be an issue.
Others have countered that ETH h/w can already handle MACsec at line rate.
e2e encryption seems (to me) to be less likely to be an issue.

> 	- What impact does this have on the control plane.

AFAIK, none. The I-D doesn't touch the control plane.

> 	  distinct routing domains?

The point of OE is that there is no key management on a global level.
It is, of course, still relatively rare that LSPs cross distinct routing
domains, but when they do, this need not have any impact on OE.

> 	  this has an impact on overall domain capability

This is covered in the document (although maybe not in enough detail?).
Transit nodes (and so domains) do not need to be aware of the encryption which
is below the top labels and potentially below the entropy label.
End nodes that do not support will, erm, not support :-)

Thanks for the early thoughts and I encourage an in-depth read and some more
pontifications.

Adrian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Jan 2014 14:18:20 +0000

> e2e encryption seems (to me) to be less likely to be an issue.

I'm not a h/w person myself, so take this with salt, but [1]
indicates they got 30Gbps with one Xilinx Virtex5 FPGA and
AES-GCM is designed to be parallelised.

S.

[1] http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6674921

---

From: Mark Tinka <[email-masked]>
Date: Thu, 9 Jan 2014 16:46:44 +0200

On Thursday, January 09, 2014 04:16:03 PM Adrian Farrel 
wrote:

> TBD
> Some people have noted that per hop encryption/decryption
> might be an issue. Others have countered that ETH h/w
> can already handle MACsec at line rate. e2e encryption
> seems (to me) to be less likely to be an issue.

Optical vendors have started supporting encryption at the 
DWDM level. I haven't implemented such myself, so can't 
really qualify its stability in the field, but those 
chipsets are limited in their service flexibility.

Vendors generally bias ASIC development toward supporting 
line rate for Ethernet and upper Layer 3 protocols at line 
rate, with a reasonable amount of trade-off.

I'm not sure whether this could signal for them to develop 
even more expensive ASIC's, or have a separate ASIC handling 
the encryption, either along with the MPLS forwarding or in 
parallel.

My concern is data plane complexity and line card cost. But, 
obviously, this could be out of scope of this I-D, to a 
great extent. My concerns are just operational.

> AFAIK, none. The I-D doesn't touch the control plane.

Key exchange is inband, yes?

> The point of OE is that there is no key management on a
> global level. It is, of course, still relatively rare
> that LSPs cross distinct routing domains, but when they
> do, this need not have any impact on OE.

Again, because key exchange is inband?

> This is covered in the document (although maybe not in
> enough detail?). Transit nodes (and so domains) do not
> need to be aware of the encryption which is below the
> top labels and potentially below the entropy label. End
> nodes that do not support will, erm, not support :-)

Given LSP's can interconnect various nodes in the same 
domain in any number of ways, OE would require all MPLS 
nodes support it in unison, to avoid global domain traffic 
drops, yes?

Mark.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 9 Jan 2014 15:56:24 -0000

Hi again Mark,

Just pursuing one point...

> > Transit nodes (and so domains) do not

I don't get this.
Only the end points of the encryption need to be aware of it.
It is only used when the end points agree to do it.
If one end point does not agree we have status quo.
If both end points agree then the transit points (if they exist) don't
participate.

So I can't fathom your statement.
Can you give me an example?

Thanks,
Adrian

---

From: Eric Rosen <[email-masked]>
Date: Thu, 09 Jan 2014 12:34:23 -0500

> wondering whether anything could be done to help protect against various
> types of bulk surveillance achieved by tapping entire links

Aren't there link layer encryption schemes that protect the confidentiality
of all traffic on the link?  I don't see why one would want an MPLS-specific
protocol for  "single hop" encryption.

I also don't understand the need for MPLS-specific "end-end" (probably
"edge-edge" is what is meant) encryption, as one can always send traffic
via IPsec.  

So, just what is the unsolved problem addressed by this draft?  (I was going
to ask whether RFC 5566 is relevant at all, but first it would be good to
get a clear statement of the scenarios that are being addressed.)

BTW, most of the draft seems to be about encryption and/or key distribution,
which of course is out of scope for this WG.  Surely the security ADs will
not tolerate having the MPLS WG invent new key distribution protocols.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Jan 2014 18:32:47 +0000

Hi Eric,

> protocol for  "single hop" encryption.

Are those widely used? I'd be interested to know. If not, then
this tool as another tool in the toolbox may be of use.

And those don't address the end-end (or edge-edge) cases, right?

> "edge-edge" is what is meant) encryption, as one can always send traffic

My understanding is that not all traffic being sent in an LSP is
IP, is that wrong? (I'm told end-end is right also for an LSP, but
am happy to admit my ignorance of terminology here.)

> get a clear statement of the scenarios that are being addressed.)

I guess I'd refer to draft-farrell-perpass-attack and
draft-barnes-pervasive-problem. I realise you're not a big
fan of at least the first one there.

> not tolerate having the MPLS WG invent new key distribution protocols.

Heh. This one is happy. The other was was too when he had a read
of this. If the draft looks like its attractive and useful then we
can figure out how to process it so its handled properly. (I also
forwarded Adrian's note to the perpass list - this might also be
useful as a template for how to add OE to other protocols.) But
we'll for sure get the right review.

Cheers,
S.

---

From: Eric Rosen <[email-masked]>
Date: Fri, 10 Jan 2014 11:06:06 -0500

Eric> Aren't there link layer encryption schemes that protect the
Eric> confidentiality of all traffic on the link?  I don't see why one would
Eric> want an MPLS-specific protocol for "single hop" encryption.

Stephen> Are those widely used? I'd be interested to know.

Well, if one thinks that "single hop" encryption is an important tool for
ensuring privacy, the first thing one should do is look at the state of the
art and figure out why there isn't more deployment.

Stephen> If not, then this tool as another tool in the toolbox may be of
Stephen> use.

And why would an MPLS-specific single-hop encryption scheme gain any more
deployment than a more general link layer encryption scheme?

I suspect that service providers don't see how protecting their users'
privacy in this manner is going to result in a positive return on investment
for them. 

Stephen> And those don't address the end-end (or edge-edge) cases, right?

Wouldn't ubiquitous link layer encryption be the best defense against any
sort of wire tapping?  Then not even the network addresses appear in the
clear on the wire.

Of course, an enduser who is worried about pervasive monitoring might not
want to rely on the service providers to protect his traffic.

But an edge-to-edge MPLS-specific scheme won't provide any more confidence,
as it still relies on the service providers to ensure privacy.  Endusers
don't generate MPLS traffic.

Stephen> I'm told end-end is right also for an LSP

An LSP typically begins at the ingress point to a service provider backbone,
and typically ends at the egress point of that backbone.  There are
scenarios in which there are multi-provider LSPs, but that is still not
end-end, as the source and destination hosts are rarely involved.

Note also that the ingress node and egress node of a particular LSP often do
not have a control plane connection between them, and in many cases neither
knows the identity of the other.

There are a number of internet drafts that have addressed the use of IPsec
in MPLS/BGP/VPN environments, e.g.:

- draft-ietf-l3vpn-ipsec-2547-05 (expired)
- RFC 4023, section 8.1
- RFC 5566

But there has never been enough interest (measured in dollars) to deploy any
of the security schemes described in these drafts.

> not all traffic being sent in an LSP is IP

True enough.  That doesn't preclude the use of IPsec, since one can always
encapsulate anything inside IP and then use IPsec transport mode.  That's
what draft-ietf-l3vpn-ipsec-2547 proposed for one kind of non-IP packet
(MPLS).

Eric> So, just what is the unsolved problem addressed by this draft?

Stephen> I guess I'd refer to draft-farrell-perpass-attack

I don't think that draft mentions any MPLS-specific issues, nor does it
suggest that there is a need to encrypt parts of the MPLS label stack.
Since MPLS labels have local significance, I don't think there's that much
to be learned by looking at the last billion label stacks that appeared on
the wire.  If there is some analysis to show otherwise, that would be
interesting.

Adrian> Some people have noted that per hop encryption/decryption might be
Adrian> an issue.  Others have countered that ETH h/w can already handle
Adrian> MACsec at line rate.  e2e encryption seems (to me) to be less likely
Adrian> to be an issue.

I think encryption at the network layer is much more complicated to do at
scale than is encryption at the data link layer.  There's just a lot more to
figure out on a per-packet basis, and the system design becomes more
complex.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 10 Jan 2014 11:39:59 -0500

> figure out on a per-packet basis, and the system design becomes more

I agree with Eric on this point. There is 100 GigE/OTU4 encryption
commercially available (not to mention 10G and 40G as well), so why
not just use that at the link layer?

Cheers,
Andy

---

From: Mark Tinka <[email-masked]>
Date: Sun, 12 Jan 2014 14:01:35 +0200

On Thursday, January 09, 2014 05:56:24 PM Adrian Farrel 
wrote:

> I don't get this.
> Only the end points of the encryption need to be aware of
> it. It is only used when the end points agree to do it.
> If one end point does not agree we have status quo. If
> both end points agree then the transit points (if they
> exist) don't participate.

Thanks, Adrian. This clarifies, then.

I just wanted to make sure that if one end supports 
encryption (and independently encrypts the flow) while the 
other end does not, we don't lose traffic.

As you explain, both ends must agree to OE support before 
anything can happen, and if they don't, existing forwarding 
paradigms remain in place, which is fine by me.

Mark.

---

From: Mark Tinka <[email-masked]>
Date: Sun, 12 Jan 2014 14:06:19 +0200

On Thursday, January 09, 2014 08:32:47 PM Stephen Farrell 
wrote:

> Are those widely used? I'd be interested to know. If not,
> then this tool as another tool in the toolbox may be of
> use.

Folk like Adva, Tejas and others have encryption at the 
optical layer. I'm not sure how well this scales in service 
provider deployments, but I know enterprises have been 
lapping it up.

The fastest data rates I've seen being encrypted at the 
optical layer are 10Gbps.

Mark.

---

From: Mark Tinka <[email-masked]>
Date: Sun, 12 Jan 2014 14:14:56 +0200

On Friday, January 10, 2014 06:06:06 PM Eric Rosen wrote:

> I think encryption at the network layer is much more
> complicated to do at scale than is encryption at the
> data link layer.  There's just a lot more to figure out
> on a per-packet basis, and the system design becomes
> more complex.

This is one of my major concerns with this draft. 
Implementation is likely to make the forwarding plane very 
complex to the extent that if any vendor is brave enough to 
support this, they will, in all likelihood, develop a 
completely separate line card that employes this kind of 
security, while building the generalized line cards in 
parallel. Want to guess which one is more likely to be 
affordable/sellable?

Optical vendors are providing low-latency encryption at the 
link layer, but I suspect that will not succeed much (in the 
service provider market, anyway) because Ethernet speeds are 
growing at a very fast rate; and it's hard enough to scale 
that before one considers how adding security in the data 
plane affects the same.

Mark.