Subject: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 27 Oct 2014 16:31:09 -0000

Hi MPLS WG,

The Farrel twins have been playing with the concept of opportunistic encryption for MPLS. This is very much positioned as an experiment.

We'd like to hear from people who are interested in this as an idea we should look into further.

And, of course, we'd love to discuss the ideas in the draft.

Adrian and Stephen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 26 October 2014 23:16
> To: Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen Farrell
> Subject: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-
> 03.txt
> 
> 
> A new version of I-D, draft-farrelll-mpls-opportunistic-encrypt-03.txt
> has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
> 
> Name:		draft-farrelll-mpls-opportunistic-encrypt
> Revision:	03
> Title:		Opportunistic Security in MPLS Networks
> Document date:	2014-10-26
> Group:		Individual Submission
> Pages:		30
> URL:            http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic-
> encrypt-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic-
> encrypt/
> Htmlized:       http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt-
> 03
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-farrelll-mpls-opportunistic-
> encrypt-03
> 
> Abstract:
>    This document describes a way to apply opportunistic security
>    between adjacent nodes on an MPLS Label Switched Path (LSP) or
>    between end points of an LSP.  It explains how keys may be agreed
>    to enable encryption, and how key identifiers are exchanged in
>    encrypted MPLS packets.  Finally, this document describes the
>    applicability of this approach to opportunistic security 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.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat

---

From: "Osborne, Eric" <[email-masked]>
Date: Tue, 28 Oct 2014 18:41:59 +0000

First, a disclaimer.  I know enough about crypto to know I don't know enough about crypto to say anything useful about it.  I assume the magic Just Works.

Second, a question on the key change frequency.
The document RECOMMENDs a new key every 10^6 packets, and sets a hard limit of 2^64.  This is a huge range, and the recommended value doesn't seem useful on anything modern.  160Mpps with a new key every 10^6 packets is 160 keys per second.  Even on a 10Mb Ethernet it's almost a new key every minute[1] per interface.

Are there cryptographic reasons for the 10^6 recommendation?  If not, can it be bumped to something saner, or perhaps provide a recommend range?  Practically speaking this is going to be so heavy to implement that any recommended numbers should be about putting as much time as possible between key exchanges if they can't be eliminated outright.

Third, a nit.
Typo: Section 4.2.1, "bidirecitonal"

eric
[1] because I never trust myself to do math in public: at 16kpps for 10Mbit ethernet and 10^6 packets per key, that's 0.02 keys/sec, or 0.96 keys/minute.

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Monday, October 27, 2014 12:31 PM
To: [email-masked]
Cc: [email-masked]
Subject: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt

Hi MPLS WG,

Adrian and Stephen

> Subject: New Version Notification for 
> draft-farrelll-mpls-opportunistic-encrypt-
> 03.txt
> 
> 
> 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.
> 
> The IETF Secretariat

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Oct 2014 12:10:02 +0000

On 28/10/14 18:41, Osborne, Eric wrote:
> First, a disclaimer.  I know enough about crypto to know I don't know
> enough about crypto to say anything useful about it.  I assume the
> magic Just Works.
> 
> Second, a question on the key change frequency. The document
> RECOMMENDs a new key every 10^6 packets, and sets a hard limit of
> 2^64.  This is a huge range, and the recommended value doesn't seem
> useful on anything modern.  160Mpps with a new key every 10^6 packets
> is 160 keys per second.  Even on a 10Mb Ethernet it's almost a new
> key every minute[1] per interface.
> 
> Are there cryptographic reasons for the 10^6 recommendation?  

TBH, I forget, but probably not:-) Happy to look at making it
longer and/or related to pps figures. (Would that last help?)
Not going beyond the max (2^64) is the important one from a
crypto POV.

Cheers,
S.

> If not,
> can it be bumped to something saner, or perhaps provide a recommend
> range?  Practically speaking this is going to be so heavy to
> implement that any recommended numbers should be about putting as
> much time as possible between key exchanges if they can't be
> eliminated outright.
> 
> 
> Third, a nit. Typo: Section 4.2.1, "bidirecitonal"
> 
> 
> 
> 
> eric [1] because I never trust myself to do math in public: at 16kpps
> for 10Mbit ethernet and 10^6 packets per key, that's 0.02 keys/sec,
> or 0.96 keys/minute.
> 
> 
> -----Original Message----- From: mpls [mailto:[email-masked]]
> On Behalf Of Adrian Farrel Sent: Monday, October 27, 2014 12:31 PM 
> To: [email-masked] Cc:
> [email-masked] Subject:
> [mpls] FW: New Version Notification for
> draft-farrelll-mpls-opportunistic-encrypt-03.txt
> 
> Hi MPLS WG,
> 
> The Farrel twins have been playing with the concept of opportunistic
> encryption for MPLS. This is very much positioned as an experiment.
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] Sent: 26 October 2014 23:16 To:
>> Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen Farrell 
>> draft-farrelll-mpls-opportunistic-encrypt- 03.txt
>> 
>> 
>> A new version of I-D,
>> draft-farrelll-mpls-opportunistic-encrypt-03.txt has been
>> successfully submitted by Adrian Farrel and posted to the IETF
>> repository.
>> 
>> Name:		draft-farrelll-mpls-opportunistic-encrypt Revision:	03 
>> Title:		Opportunistic Security in MPLS Networks Document date:
>> 2014-10-26 Group:		Individual Submission Pages:		30 URL:
>> http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic-
>>
>> 
encrypt-03.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic-
>>
>> 
encrypt/
>> Htmlized:
>> http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt-
>>
>> 
03
>> Diff:
>> http://www.ietf.org/rfcdiff?url2=draft-farrelll-mpls-opportunistic-
>>
>> 
encrypt-03
>> 
>> Abstract: This document describes a way to apply opportunistic
>> security between adjacent nodes on an MPLS Label Switched Path
>> (LSP) or between end points of an LSP.  It explains how keys may be
>> agreed to enable encryption, and how key identifiers are exchanged
>> in encrypted MPLS packets.  Finally, this document describes the 
> _______________________________________________ mpls mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/mpls
>

---

From: "Osborne, Eric" <[email-masked]>
Date: Wed, 29 Oct 2014 14:32:11 +0000

"> Are there cryptographic reasons for the 10^6 recommendation?  

TBH, I forget, but probably not:-) Happy to look at making it longer and/or related to pps figures. (Would that last help?) Not going beyond the max (2^64) is the important one from a crypto POV."

Key exchange should be done for two reasons:

1) the operator initiates it
2) the system requires it and does it automatically, perhaps with a preconfigured second key or perhaps with something auto-generated.

#2 should happen as rarely as possible, if for no other reason than key exchange is likely to be perilous.  The actual crypto will be implemented in hardware and the exchange in software, so there needs to be some method to ensure that packets aren't lost during exchange.  IIRC (from discussions in a previous life, not current employer) that's why there was very little MD5 auth deployed.

But that's nothing to do with key change frequency.

Let's assume I have a 10x100GE LAG - this is on the higher end of things today, but will be here soon enough.  With something that big you're looking at 1.6*10^9 pps, perhaps better written as 2^30.57pps.  This leaves me 2^33.4sec before I hit 2^64 packets.  That's a little over 365 years.

Set the key change threshold to 2^63 instead, to allow the operator sufficient time (!!) to change keys, and you're looking at 182 years before it's even a problem.  Yes, 640k should be enough for everyone, and 512-bit crypto is going to be impossible to crack, and y2k is so far away nobody will care if we do two digit datecodes now...but seriously...that's a long time.  

I'd vote for setting that threshold as high as possible since there seems to be no reason to do otherwise.  I don't see a reason to tie any recommendation to pps.

eric

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, October 29, 2014 8:10 AM
To: Osborne, Eric; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt

On 28/10/14 18:41, Osborne, Eric wrote:
> is 160 keys per second.  Even on a 10Mb Ethernet it's almost a new key 
> every minute[1] per interface.
> 

TBH, I forget, but probably not:-) Happy to look at making it longer and/or related to pps figures. (Would that last help?) Not going beyond the max (2^64) is the important one from a crypto POV.

Cheers,
S.

> range?  Practically speaking this is going to be so heavy to implement 
> that any recommended numbers should be about putting as much time as 
> possible between key exchanges if they can't be eliminated outright.
> 
> 
> for 10Mbit ethernet and 10^6 packets per key, that's 0.02 keys/sec, or 
> 0.96 keys/minute.
> 
> 
encrypt-03.txt
encrypt/
03
encrypt-03
>> agreed to enable encryption, and how key identifiers are exchanged in 
>> networks with an indication of the level of improved security as well 
>> as the continued vulnerabilities.
>>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Oct 2014 14:35:45 +0000

On 29/10/14 14:32, Osborne, Eric wrote:
> TBH, I forget, but probably not:-) Happy to look at making it longer
> and/or related to pps figures. (Would that last help?) Not going
> beyond the max (2^64) is the important one from a crypto POV."
> 
> 
> 1) the operator initiates it 2) the system requires it and does it
> automatically, perhaps with a preconfigured second key or perhaps
> with something auto-generated.

Or #3, you aren't that confident that a D-H derived key won't
leak out, which is a reason to minimise the symmetric key
lifetime.

S

> 
> #2 should happen as rarely as possible, if for no other reason than
> key exchange is likely to be perilous.  The actual crypto will be
> implemented in hardware and the exchange in software, so there needs
> to be some method to ensure that packets aren't lost during exchange.
> IIRC (from discussions in a previous life, not current employer)
> that's why there was very little MD5 auth deployed.
> 
> Let's assume I have a 10x100GE LAG - this is on the higher end of
> things today, but will be here soon enough.  With something that big
> you're looking at 1.6*10^9 pps, perhaps better written as 2^30.57pps.
> This leaves me 2^33.4sec before I hit 2^64 packets.  That's a little
> over 365 years.
> 
> Set the key change threshold to 2^63 instead, to allow the operator
> sufficient time (!!) to change keys, and you're looking at 182 years
> before it's even a problem.  Yes, 640k should be enough for everyone,
> and 512-bit crypto is going to be impossible to crack, and y2k is so
> far away nobody will care if we do two digit datecodes now...but
> seriously...that's a long time.
> 
> I'd vote for setting that threshold as high as possible since there
> seems to be no reason to do otherwise.  I don't see a reason to tie
> any recommendation to pps.
> 
> 
> 
> 
> eric
> 
> 
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Wednesday, October 29, 2014
> 8:10 AM To: Osborne, Eric; [email-masked]; [email-masked] Cc:
> [email-masked] Subject: Re:
>> First, a disclaimer.  I know enough about crypto to know I don't
>> know enough about crypto to say anything useful about it.  I assume
>> the magic Just Works.
>> 
>>  useful on anything modern.  160Mpps with a new key every 10^6
>> packets is 160 keys per second.  Even on a 10Mb Ethernet it's
>> almost a new key every minute[1] per interface.
>> 
> TBH, I forget, but probably not:-) Happy to look at making it longer
> and/or related to pps figures. (Would that last help?) Not going
> beyond the max (2^64) is the important one from a crypto POV.
> 
> Cheers, S.
> 
>> If not, can it be bumped to something saner, or perhaps provide a
>> recommend range?  Practically speaking this is going to be so heavy
>> to implement that any recommended numbers should be about putting
>> as much time as possible between key exchanges if they can't be
>> eliminated outright.
>> 
>> 
>> eric [1] because I never trust myself to do math in public: at
>> 16kpps for 10Mbit ethernet and 10^6 packets per key, that's 0.02
>> keys/sec, or 0.96 keys/minute.
>> 
>> 
>> -----Original Message----- From: mpls
>> [mailto:[email-masked]] On Behalf Of Adrian Farrel Sent:
>> Monday, October 27, 2014 12:31 PM To: [email-masked] Cc: 
>> The Farrel twins have been playing with the concept of
>> opportunistic encryption for MPLS. This is very much positioned as
>> an experiment.
>> 
>>> [mailto:[email-masked]] Sent: 26 October 2014 23:16
>>> To: Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen
>>> Farrell Subject: New Version Notification for 
>>> http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic
>>>
>>> 
-
encrypt/
03
encrypt-03
>>> (LSP) or between end points of an LSP.  It explains how keys may
>>> be agreed to enable encryption, and how key identifiers are
>>> exchanged in encrypted MPLS packets.  Finally, this document
>>> describes the applicability of this approach to opportunistic
>>> security in MPLS networks with an indication of the level of
>>> improved security as well as the continued vulnerabilities.
>>>

---

From: "Osborne, Eric" <[email-masked]>
Date: Wed, 29 Oct 2014 14:52:07 +0000

Inline with EO#

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, October 29, 2014 10:36 AM
To: Osborne, Eric; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-03.txt

On 29/10/14 14:32, Osborne, Eric wrote:
> automatically, perhaps with a preconfigured second key or perhaps with 
> something auto-generated.

Or #3, you aren't that confident that a D-H derived key won't leak out, which is a reason to minimise the symmetric key lifetime.

EO#  That seems like another flavor of either #1 or #2.  
Perhaps this should be covered in an operations section - "the operator should be able to change keys as frequently as desired in order to minimize the risk of a leaked key, but at a frequency not deemed to be operationally onerous.  This varies both by pps and operator preference.  On a typical 10Gbit link a threshold of 2^50 packets should allow the operator a little over two years before changing keys.  On a 1Tbit link a two-year key lifetime requires a 2^63 threshold".

If you're going to RECOMMEND a default, I'd say something like "default SHOULD be set to a threshold that gives a key a 1-year lifetime at line rate with small packets".

eric

S

>> to implement that any recommended numbers should be about putting as 
>> On Behalf Of Adrian Farrel Sent:
-
encrypt/
03
encrypt-03

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Oct 2014 18:59:35 +0000

Hiya,

On 29/10/14 14:52, Osborne, Eric wrote:
> 10:36 AM To: Osborne, Eric; [email-masked]; [email-masked] Cc:
>> longer and/or related to pps figures. (Would that last help?) Not
>> going beyond the max (2^64) is the important one from a crypto
>> POV."
>> 
>> 
> Or #3, you aren't that confident that a D-H derived key won't leak
> out, which is a reason to minimise the symmetric key lifetime.
> 
> 
> EO#  That seems like another flavor of either #1 or #2. Perhaps this
> should be covered in an operations section - "the operator should be
> able to change keys as frequently as desired in order to minimize the
> risk of a leaked key, but at a frequency not deemed to be
> operationally onerous.  This varies both by pps and operator
> preference. 

Something like that sounds reasonable, yes.

> On a typical 10Gbit link a threshold of 2^50 packets
> should allow the operator a little over two years before changing
> keys.  On a 1Tbit link a two-year key lifetime requires a 2^63
> threshold".
> 
> If you're going to RECOMMEND a default, I'd say something like
> "default SHOULD be set to a threshold that gives a key a 1-year
> lifetime at line rate with small packets".

I guess it depends on threat models. If you're worried about [1]
then one might consider that 1 or two years for a symmetric key
is too long. And re-keying had better be smooth anyway or else
it'll just not be done. Both of those would argue for shorter key
life-cycles, but I do agree that "not operationally onerous" is
the top level requirement.

S.

[1]
http://www.spiegel.de/international/world/the-nsa-uses-powerful-toolbox-in-effort-to-spy-on-global-networks-a-940969-3.html

>>  implemented in hardware and the exchange in software, so there
>> needs to be some method to ensure that packets aren't lost during
>> exchange. IIRC (from discussions in a previous life, not current
>> employer) that's why there was very little MD5 auth deployed.
>> 
>> things today, but will be here soon enough.  With something that
>> big you're looking at 1.6*10^9 pps, perhaps better written as
>> 2^30.57pps. This leaves me 2^33.4sec before I hit 2^64 packets.
>> That's a little over 365 years.
>> 
>>  sufficient time (!!) to change keys, and you're looking at 182
>> years before it's even a problem.  Yes, 640k should be enough for
>> everyone, and 512-bit crypto is going to be impossible to crack,
>> and y2k is so far away nobody will care if we do two digit
>> datecodes now...but seriously...that's a long time.
>> 
>>  seems to be no reason to do otherwise.  I don't see a reason to
>> tie any recommendation to pps.
>> 
>> 
>> 
>> 
>> eric
>> 
>> 
>> 
>> [mailto:[email-masked]] Sent: Wednesday, October 29,
>> 2014 8:10 AM To: Osborne, Eric; [email-masked]; [email-masked]
>> Subject: Re: [mpls] FW: New Version Notification for 
>>> know enough about crypto to say anything useful about it.  I
>>> assume the magic Just Works.
>>> 
>>>  2^64.  This is a huge range, and the recommended value doesn't
>>> seem useful on anything modern.  160Mpps with a new key every
>>> 10^6 packets is 160 keys per second.  Even on a 10Mb Ethernet
>>> it's almost a new key every minute[1] per interface.
>>> 
>> longer and/or related to pps figures. (Would that last help?) Not
>> going beyond the max (2^64) is the important one from a crypto
>> POV.
>> 
>> Cheers, S.
>> 
>>>  recommend range?  Practically speaking this is going to be so
>>> heavy to implement that any recommended numbers should be about
>>> putting as much time as possible between key exchanges if they
>>> can't be eliminated outright.
>>> 
>>> 
>>> opportunistic encryption for MPLS. This is very much positioned
>>> as an experiment.
>>> 
>>>> http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunisti
>>>>
>>>> 
c
encrypt/
>>>> Htmlized: 
>>>> http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt
>>>>
>>>> 
-
encrypt-03
>>>>  security between adjacent nodes on an MPLS Label Switched
>>>> Path (LSP) or between end points of an LSP.  It explains how
>>>> keys may be agreed to enable encryption, and how key
>>>> identifiers are exchanged in encrypted MPLS packets.  Finally,
>>>> this document describes the applicability of this approach to
>>>> opportunistic security in MPLS networks with an indication of
>>>> the level of improved security as well as the continued
>>>> vulnerabilities.
>>>> 
>>>> 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.
>>>> 
>>>> The IETF Secretariat
>>>

---

From: "Osborne, Eric" <[email-masked]>
Date: Wed, 29 Oct 2014 19:18:42 +0000

Inline

...

> > On a typical 10Gbit link a threshold of 2^50 packets should allow the
> > operator a little over two years before changing keys.  On a 1Tbit
> > link a two-year key lifetime requires a 2^63 threshold".
> >
> I guess it depends on threat models. If you're worried about [1] then one
> might consider that 1 or two years for a symmetric key is too long.

Agreed.  So maybe 1 year is as arbitrary a recommendation as 160 times a second. 
There ought to be some recommended default just so things work nicely out of the box, but the right value is going to depend mostly on the actual interface load, which seems weird.  Maybe the right way to do it is to specify a fairly high packet trigger threshold (2^63) but also provide a separate, time-based threshold that says "generate and send a new key every X hours/days/weeks", and then issue a new key when we trip either of these.

eric

> And re-
> keying had better be smooth anyway or else it'll just not be done. Both of
> those would argue for shorter key life-cycles, but I do agree that "not
> operationally onerous" is the top level requirement.
> 
> S.
> 
> [1]
> http://www.spiegel.de/international/world/the-nsa-uses-powerful-
> toolbox-in-effort-to-spy-on-global-networks-a-940969-3.html
> 
> >
> >
> >
> >
> > eric
> >
> >
> > S
> >
> >>
> >> IIRC (from discussions in a previous life, not current
> >> This leaves me 2^33.4sec before I hit 2^64 packets.
> >>> useful on anything modern.  160Mpps with a new key every
> >>> 10^6 packets is 160 keys per second.  Even on a 10Mb Ethernet it's
> as