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

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

Hiya,

See below. Adrian and I (the Farrelll twins, he seemingly can't
spell it right:-) have cooked up an idea for MPLS opportunistic
encryption.  As he says, its very early days, but if this was
something that MPLS folk wanted to implement, I think that'd be
a fine thing. As of now, I've no real clue if they would or not,
but Adrian I'm sure knows better. And as you can also see from
the mail below, Adrian has already posted to the MPLS WG list,
so comments about whether this is good or bad for MPLS etc are
probably better handled on that list rather than here.

So my question for this list is mainly to look for comments
on how we've handled the opportunistic crypto thing, especially
from the pov of whether that's something that could be copied
in other protocols. The meaty bit of that is really section
4.2 of the draft which is quite short.

One particular question to consider is whether or not a
generic MITM-detection protocol for OE-using protocols might
be interesting or better/worse than the idea of having each
protocol define ways in which you might post-facto catch a MITM.

Section 2 of the draft has some introductory text about OE. I'd
also be interested in comments on that but as our draft says, we
expect that to be superseded by a more generic OE draft. (I know
that Steve Kent is working on one like that, and maybe others are
too.) So your comments on that might really end up improving
some other draft and not this one, but that's fine.

Thanks,
S.

-------- Original Message --------
Subject: FW: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt
Date: Thu, 9 Jan 2014 11:51:03 -0000
From: Adrian Farrel <[email-masked]>
Reply-To: <[email-masked]>
To: <[email-masked]>
CC: <[email-masked]>

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: Watson Ladd <[email-masked]>
Date: Fri, 10 Jan 2014 08:42:38 -0800

> 4.2 of the draft which is quite short.

I think prime field elliptic curves would be more amenable to
implementation in restricted router
hardware.

How the receiver computes the nonce that goes with the packet is not
obvious to me from
what is written.

Otherwise this seems reasonable: it might be worth considering if this
can be extended to
authenticate both sides cleanly if some large networks want to be safe
against that.

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

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Jan 2014 17:21:43 +0000

Hiya,

> implementation in restricted router

Could be. If this doesn't turn out to be DOA then I'd
fully expect a bunch of discussion on that. For now,
we just picked MODP to avoid having to worry about IPR
FUDdiness.

> How the receiver computes the nonce that goes with the packet is not

Oops. Needs a fix:-)

> authenticate both sides cleanly if some large networks want to be safe

Not sure what you mean by cleanly?

Thanks for the comments,
S.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 10 Jan 2014 09:27:36 -0800

On Fri, Jan 10, 2014 at 9:21 AM, Stephen Farrell
<[email-masked]> wrote:
><snip>

By cleanly I mean if authentication is configured, it works, if not,
we wind up with OE without too much
in the way of complexity. This might be a bridge too far, but I
wouldn't be surprised if some people were concerned about false
termination in the middle of their MLPS networks induced by malicious
configuration.