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

[Eric Rosen <[e-mail]>]

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.