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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 1 Jan 2015 14:27:27 -0000

Hi,

Update is minor.

- draft-dukhovni-opportunistic-security has been published as RFC 7435.
- Add place-holder section 1.2 "Existing Security Tools for MPLS Data"

I know a couple of people are considering experimental implementations and (of course) we would welcome feedback from their experiences.

We'd also really appreciate input from people close to silicon to understand whether what we are proposing is achievable with existing hardware or would require new silicon.

Thanks,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 01 January 2015 14:22
> To: Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen Farrell
> Subject: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-
> 04.txt
> 
> 
> A new version of I-D, draft-farrelll-mpls-opportunistic-encrypt-04.txt
> has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
> 
> Name:		draft-farrelll-mpls-opportunistic-encrypt
> Revision:	04
> Title:		Opportunistic Security in MPLS Networks
> Document date:	2015-01-01
> Group:		Individual Submission
> Pages:		30
> URL:            http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic-
> encrypt-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic-
> encrypt/
> Htmlized:       http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt-
> 04
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-farrelll-mpls-opportunistic-
> encrypt-04
> 
> 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: Stephen Farrell <[email-masked]>
Date: Thu, 01 Jan 2015 14:59:14 +0000

On 01/01/15 14:27, Adrian Farrel wrote:
> Hi,
> 
> Update is minor.
> 
> - draft-dukhovni-opportunistic-security has been published as RFC
> 7435. - Add place-holder section 1.2 "Existing Security Tools for
> MPLS Data"

Happy to get text help on the MACsec thing there in particular, we
can probably write or find help with the IPsec stuff easily enough.

> I know a couple of people are considering experimental
> implementations and (of course) we would welcome feedback from their
> experiences.
> 
> We'd also really appreciate input from people close to silicon to
> understand whether what we are proposing is achievable with existing
> hardware or would require new silicon.

And on the crypto/key agreement side, is integer DH ok when
considering that or is ECDH so significantly better that that'd
make a difference to the experiment or to later deployment? We've
stuck with integer DH for now as the IPR is still cleaner and I'd
rather we had the results of the CFRG work on additional ECDH
curves done and dusted before considering whether to use one of
those or a NIST curve as a possible ECDH MTI as an alternative to
or in addition to integer DH.

Cheers,
S.

> 
> Thanks, Adrian
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] Sent: 01 January 2015 14:22 To:
>> Adrian Farrel; Stephen Farrell; Adrian Farrel; Stephen Farrell 
>> Subject: New Version Notification for
>> draft-farrelll-mpls-opportunistic-encrypt- 04.txt
>> 
>> 
>> A new version of I-D,
>> draft-farrelll-mpls-opportunistic-encrypt-04.txt has been
>> successfully submitted by Adrian Farrel and posted to the IETF
>> repository.
>> 
>> Name:		draft-farrelll-mpls-opportunistic-encrypt Revision:	04 
>> Title:		Opportunistic Security in MPLS Networks Document date:
>> 2015-01-01 Group:		Individual Submission Pages:		30 URL:
>> http://www.ietf.org/internet-drafts/draft-farrelll-mpls-opportunistic-
>>
>> 
encrypt-04.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-farrelll-mpls-opportunistic-
>>
>> 
encrypt/
>> Htmlized:
>> http://tools.ietf.org/html/draft-farrelll-mpls-opportunistic-encrypt-
>>
>> 
04
>> Diff:
>> http://www.ietf.org/rfcdiff?url2=draft-farrelll-mpls-opportunistic-
>>
>> 
encrypt-04
>> 
>> 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 
>> 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: <[email-masked]>
Date: Thu, 1 Jan 2015 18:21:27 +0000

Are jargon and acronyms a barrier to meaningful discussion in the ietf?

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: mpls <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Friday, 2 January 2015 1:59:14 AM
To: [email-masked]; [email-masked]
Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt

Cheers,
S.

encrypt-04.txt
encrypt/
04
encrypt-04
>> submission until the htmlized version and diff are available at

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

---

From: "Black, David" <[email-masked]>
Date: Fri, 2 Jan 2015 01:15:27 +0000

> Are jargon and acronyms a barrier to meaningful discussion in the ietf?

I suppose this is what can happen when a SEC AD posts to an RTG WG list :-).

Here's an attempt at a "secret decoder ring" ...

> can probably write or find help with the IPsec stuff easily enough.

MACsec = IEEE 802.1AE, a standard for Ethernet link security that is roughly
analogous to IPsec for IP security, but is at the link layer,
see: http://en.wikipedia.org/wiki/IEEE_802.1AE

> make a difference to the experiment or to later deployment?

DH = Diffie-Hellman, a class of algorithms used for key agreement or key exchange.
     Protocols based on these algorithms produce session keys (e.g., for encryption)
     that are computationally infeasible to determine from the messages exchanged. 
integer DH - key agreement based on exponentiation involving large numbers, 2048
     bits is the minimum size that should currently be used.
ECDH = Elliptic Curve DH.  Key agreement based on elliptic curve crypto involves
     much smaller numbers - 224-bit ECDH calculations have comparable security
     strength to 2048-bit integer DH calculations, although the calculations are
     different.  EC calculations are done with respect to a "curve" (effectively a
     set of parameters).

> We've

IPR = Intellectual Property Rights - go ask a lawyer, not me ;-).

CFRG = IRTF Crypto Forum Research Group, a community of cryptographers that
     provides crypto advice to the IETF, see https://irtf.org/cfrg.

NIST = National Institute of Standards and Technology (US government agency).
NIST curve - One of the NIST-specified curves for EC crypto.  The NIST curves 
      are currently the most commonly used for EC crypto in IETF standards.
      The CFRG is in the midst of figuring out what other curves to recommend.

MTI = Mandatory To Implement.

Enjoy,
--David
________________________________________
From: mpls [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Thursday, January 01, 2015 1:21 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt

Lloyd Wood

Cheers,
S.

encrypt-04.txt
encrypt/
04
encrypt-04

---

From: <[email-masked]>
Date: Fri, 2 Jan 2015 13:57:00 +0000

More a barrier to discussion is that a conversation about anything can now be derailed into a conversation about security, because all groups are security groups.

The pressing question for mpls has always been not whether mpls requires security, not what security mpls should have, but exactly what type of elliptic curve to use. Good that we're attempting to answer that, no?

L.

Oh, and security is ALWAYS mandatory to implement. Because... It's security.
________________________________________
From: Black, David <[email-masked]>
Sent: Friday, 2 January 2015 12:15:27 PM
To: Wood L  Dr (Electronic Eng); [email-masked]; [email-masked]; [email-masked]
Cc: Black, David
Subject: RE: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt

Enjoy,
--David

Lloyd Wood

Cheers,
S.

encrypt-04.txt
encrypt/
04
encrypt-04

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 2 Jan 2015 16:41:45 -0000

Lloyd,

It would be excellent to have the discussion of whether it is inappropriate or
even impossible to provide security at the MPLS layer.

My view was that the overhead of managed security associations in an MPLS
network where relationships were n-squared times "class of service" was a
limiting factor. 

This draft discusses some of the issues, and it is intended that section 1.2
will add a discussion of security-over (e.g., IPsec) and security-under (e.g.,
MACsec). Both of these have a part to play in security in MPLS networks, but it
is not clear that they deliver everything you need.

The discussion of Opportunistic Security and some of the lessons coming out of
growing awareness of fibre-tap and untrusted routers leads to the thought that
per hop layer 2 security may provide a lot of benefits, but that MPLS security
might also have value.

This draft is targeted at Experimental and several people have stated that they
intend to experiment with it.

>From a protocol point of view, I think that this working group is the right
place to discuss how to negotiate the use of security and how to encode the
security parameters on the wire. I don't believe this working group is the right
place to determine what those parameters are, and I rely on security whizzards
to tell me what information I need to carry. 

As far as "mandatory to implement" is concerned, Stephen and I might have some
small disagreement :-)
Nothing documented now is likely to be mandatory to implement in existing
implementations. Therefore, this experiment (even were it to be standards track)
would not be anything more than a strong recommendation for as many years as it
takes to upgrade a lot of boxes - and so, of course, the document has to
describe what happens if one or more routers in the network do not support these
security mechanisms. This opens up the possibility of downgrade attacks, and the
document observes that how you respond to a request to downgrade depends on how
much you want to secure the data.
However, once someone has decided to implement this document, there is value in
observing that, from a set of security algorithms that are possible to support,
there should be a common subset that all implementations will support - absent
that, there is a high chance of lack of interop even between implementations of
this document. So, to that extent, it is valuable to talk about mandatory to
implement.

Thanks for your interest in this work.

Adrian

> From: [email-masked] [mailto:[email-masked]]
> Sent: 02 January 2015 13:57
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> More a barrier to discussion is that a conversation about anything can now be
> derailed into a conversation about security, because all groups are security
> groups.
> 
> The pressing question for mpls has always been not whether mpls requires
> security, not what security mpls should have, but exactly what type of
elliptic
> curve to use. Good that we're attempting to answer that, no?

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 6 Jan 2015 20:49:58 +0000

Dear Authors -

I have few basic questions -

1. Is it on every hop/LSR along the path the whole packet with label stack had to be decrypted and encrypted with Mel? If yes, IMO this is really 
   bad w.r.t performance (issues of key exchange for thousands of LSPs and load associated would be insignificant in comparison perhaps?). 
    From this PoV content in section 1.2 is critical. 

2. Section 2 is covering this -  OS proposed here is similar to TCPInc stuff - meaning no authenticated key exchange (possible MITM) and no PFS.  

3. Do you see any key roll over issues?

--
Uma C.

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, January 02, 2015 8:42 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt

Lloyd,

It would be excellent to have the discussion of whether it is inappropriate or even impossible to provide security at the MPLS layer.

My view was that the overhead of managed security associations in an MPLS network where relationships were n-squared times "class of service" was a limiting factor. 

This draft discusses some of the issues, and it is intended that section 1.2 will add a discussion of security-over (e.g., IPsec) and security-under (e.g., MACsec). Both of these have a part to play in security in MPLS networks, but it is not clear that they deliver everything you need.

The discussion of Opportunistic Security and some of the lessons coming out of growing awareness of fibre-tap and untrusted routers leads to the thought that per hop layer 2 security may provide a lot of benefits, but that MPLS security might also have value.

This draft is targeted at Experimental and several people have stated that they intend to experiment with it.

>From a protocol point of view, I think that this working group is the 
place to discuss how to negotiate the use of security and how to encode the security parameters on the wire. I don't believe this working group is the right place to determine what those parameters are, and I rely on security whizzards to tell me what information I need to carry. 

As far as "mandatory to implement" is concerned, Stephen and I might have some small disagreement :-) Nothing documented now is likely to be mandatory to implement in existing implementations. Therefore, this experiment (even were it to be standards track) would not be anything more than a strong recommendation for as many years as it takes to upgrade a lot of boxes - and so, of course, the document has to describe what happens if one or more routers in the network do not support these security mechanisms. This opens up the possibility of downgrade attacks, and the document observes that how you respond to a request to downgrade depends on how much you want to secure the data.
However, once someone has decided to implement this document, there is value in observing that, from a set of security algorithms that are possible to support, there should be a common subset that all implementations will support - absent that, there is a high chance of lack of interop even between implementations of this document. So, to that extent, it is valuable to talk about mandatory to implement.

Adrian

> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [mpls] FW: New Version Notification for 
> draft-farrelll-mpls- opportunistic-encrypt-04.txt
> 
> More a barrier to discussion is that a conversation about anything can 
> now be derailed into a conversation about security, because all groups 
> are security groups.
> 
> The pressing question for mpls has always been not whether mpls 
> requires security, not what security mpls should have, but exactly 
> what type of
elliptic

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 06 Jan 2015 23:14:29 +0000

Hiya,

A partly contingent answer from me sorry, MPLS specifics need Adrian
for more certainty:-)

On 06/01/15 20:49, Uma Chunduri wrote:
> 1. Is it on every hop/LSR along the path the whole packet with label
> stack had to be decrypted and encrypted with Mel? If yes, IMO this is
> really bad w.r.t performance (issues of key exchange for thousands of
> LSPs and load associated would be insignificant in comparison
> perhaps?). From this PoV content in section 1.2 is critical.

I believe not. Encryption is done once and decryption once, for any
given secret established via the key exchange. I think that means this
should be less demanding of CPU than e.g. MACsec for common cases
where you might want to use this.

> 2. Section 2 is covering this -  OS proposed here is similar to
> TCPInc stuff - meaning no authenticated key exchange (possible MITM)
> and no PFS.

You do get PFS as it's a D-H exchange. And it is quite like TCPinc
in that this protocol doesn't give you endpoint authentication but
it does allow one to export values that can be used for endpoint
authentication. (Or were it useful we could accept such values as
an input to the KDF I guess.)

Interestingly, I think MPLS, with all it's highly managed identifiers
could make it practical to detect a MitM post-facto without endpoint
authentication, which isn't going to be practical for TCPInc (e.g.
due to NAT). I'll be interested in trying to figure out if that's
possible later since if it were possible, it'd be very nice.

> 3. Do you see any key roll over issues?

Always;-) We tried to cover that in the draft but I'm sure that
implementation and initial experimentation might tell us that more
work is needed.

Cheers,
S.

> 
> -- Uma C.
> 
> 
> -----Original Message----- From: mpls [mailto:[email-masked]]
> On Behalf Of Adrian Farrel Sent: Friday, January 02, 2015 8:42 AM To:
> [email-masked]; [email-masked]; [email-masked] Subject: Re:
> [mpls] FW: New Version Notification for
> draft-farrelll-mpls-opportunistic-encrypt-04.txt
> 
> Lloyd,
> 
> It would be excellent to have the discussion of whether it is
> inappropriate or even impossible to provide security at the MPLS
> layer.
> 
> My view was that the overhead of managed security associations in an
> MPLS network where relationships were n-squared times "class of
> service" was a limiting factor.
> 
> This draft discusses some of the issues, and it is intended that
> section 1.2 will add a discussion of security-over (e.g., IPsec) and
> security-under (e.g., MACsec). Both of these have a part to play in
> security in MPLS networks, but it is not clear that they deliver
> everything you need.
> 
> The discussion of Opportunistic Security and some of the lessons
> coming out of growing awareness of fibre-tap and untrusted routers
> leads to the thought that per hop layer 2 security may provide a lot
> of benefits, but that MPLS security might also have value.
> 
> place to discuss how to negotiate the use of security and how to
> encode the security parameters on the wire. I don't believe this
> working group is the right place to determine what those parameters
> are, and I rely on security whizzards to tell me what information I
> need to carry.
> 
> As far as "mandatory to implement" is concerned, Stephen and I might
> have some small disagreement :-) Nothing documented now is likely to
> be mandatory to implement in existing implementations. Therefore,
> this experiment (even were it to be standards track) would not be
> anything more than a strong recommendation for as many years as it
> takes to upgrade a lot of boxes - and so, of course, the document has
> to describe what happens if one or more routers in the network do not
> support these security mechanisms. This opens up the possibility of
> downgrade attacks, and the document observes that how you respond to
> a request to downgrade depends on how much you want to secure the
> data. However, once someone has decided to implement this document,
> there is value in observing that, from a set of security algorithms
> that are possible to support, there should be a common subset that
> all implementations will support - absent that, there is a high
> chance of lack of interop even between implementations of this
> document. So, to that extent, it is valuable to talk about mandatory
> to implement.
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] Sent: 02 January 2015 13:57 To:
>> [email-masked]; [email-masked]; 
>> [email-masked]; [email-masked] Subject: Re: [mpls] FW: New
>> Version Notification for draft-farrelll-mpls-
>> opportunistic-encrypt-04.txt
>> 
>> More a barrier to discussion is that a conversation about anything
>> can now be derailed into a conversation about security, because all
>> groups are security groups.
>> 
> _______________________________________________ mpls mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/mpls
> 
> _______________________________________________ mpls mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/mpls
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 7 Jan 2015 16:46:02 -0000

Hi have read the thread based on this email from Stephen and Stewart, but
deciding to reply back on Uma's original ...

> 1. Is it on every hop/LSR along the path the whole packet with label stack had
to
> be decrypted and encrypted with Mel? If yes, IMO this is really
>    bad w.r.t performance (issues of key exchange for thousands of LSPs and
load
> associated would be insignificant in comparison perhaps?).

The text in the introduction:
   MPLS opportunistic security can be achieved between adjacent Label
   Switching Routers (LSRs) on an MPLS Label Switched Path (LSP), and
   also between end points of an LSP.
...was intended to say that there are two options:
1. encrypt between two adjacent LSRs on an LSP
2. encrypt between the end-points of an LSP
In the latter case you would not encrypt and decrypt at each hop (and indeed
would not be able to since the keys would only be known at the end points).

You are right to point at section 1.2 (and we do need to write that section :-)
because L2 solutions (such as MACsec) are typically used on a hop-by-hop basis.
I am not clear that MACsec used in this way is a significant performance issue
(I think chips can do L2 security at line speed), although it might cause
additional power consumption.

> 2. Section 2 is covering this -  OS proposed here is similar to TCPInc stuff -
meaning
> no authenticated key exchange (possible MITM) and no PFS.

Adding to Stephen's reply:
Yes, OS is vulnerable to Man-in-the-Middle attacks.
It's a trade: if you make your security too hard to manage and configure, you
get no security; if you make your security to simplistic, everyone uses it and
it is no good.
Our approach here is to make the security easy to use, suffer the potential MitM
attacks, but:
a. make MitM as expensive as possible
b. make a MitM attack possible to detect

> 3. Do you see any key roll over issues?

I think key roll is covered in the text. We *do* need to roll the keys, but we
believe that key roll can be achieved using the existing keying mechanisms with
the additional benefit that the key messages are protected by the previous keys.

... and to answer Stewart's question about whether operators want this:
I have certainly discussed the principle with a number of network operators and
they have not said to be "you are crazy" (perhaps this is taken as read). On the
other hand,  would say that the interest is currently cautious.
That is certainly why this document is positioned as Experimental, but also why
we have tried to make the protocol mechanisms such that partial or incremental
deployment is possible.
But perhaps operators will want to speak for themselves (or perhaps they will be
inclined to be shy because expressing an interest might be taken to mean their
networks are currently vulnerable, or might lead to them being leant on).

Adrian

---

From: "Black, David" <[email-masked]>
Date: Sat, 10 Jan 2015 19:09:37 +0000

> the additional benefit that the key messages are protected by the previous keys.

Related question - why is the key-id an output of the key exchange process,
specifically part of the HKDF output (near the end of 4.2.2)?

Since the key-id is 4-bits, there's a 1-in-16 possibility that rekeying
yields the same id, which is a potential minor problem - if that happens,
I suppose one could rerun the key exchange, which is unlikely to collide
a second time (odds of two collisions in a row is less than one-half of 1%).

I'd also expect that configuration could override that key-id output
(e.g., Alice and Bob might both know via some other means that this key
exchange is generating key 7, even if the HKDF produces a key-id of 2).

If I had to guess why key-id is a key exchange output, it might be courtesy
of the initial key exchange being unauthenticated - the obvious alternative
of passing the key-id in the unauthenticated key exchange messages makes
it simple for a man-in-the-middle to defeat opportunistic encryption by
changing that key-id.  Such a change causes the resulting key to be
installed under key-ids at the two endpoints, which will then fail to
successfully exchange encrypted traffic using that key ...

Thanks,
--David
________________________________________
From: mpls [[email-masked]] on behalf of Adrian Farrel [[email-masked]]
Sent: Wednesday, January 07, 2015 11:46 AM
To: 'Uma Chunduri'; [email-masked]
Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt

to
load

meaning

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 10 Jan 2015 22:13:19 -0000

> a second time (odds of two collisions in a row is less than one-half of 1%).

Ah, no. The key-id is not the key. The key-id is an ID used to refer to the key.
It is used in the encrypted packets to refer to the key and, since there is no
need for more than a couple of active keys (current and roll-forward) at any
time one could argue that one bit is enough, but four seemed safer for rapid
rolls and a couple of spare keys.

So all that is necessary is that the KDF generates a new number each time. Maybe
that requires state and something in the input to the KDF.

> exchange is generating key 7, even if the HKDF produces a key-id of 2).

So long as Alice and Bob both know that the same key-id refers to the same key
and algorithm everything in the world will be wonderful.

Adrian

---

From: "Black, David" <[email-masked]>
Date: Sun, 11 Jan 2015 14:30:31 +0000

> Ah, no. The key-id is not the key. The key-id is an ID used to refer to the

Yes, that's what I understood.  Generating the same key twice from this sort
of key exchange is effectively impossible if the entropy inputs are good.
If the entropy inputs aren't good, that's a much bigger problem (resulting
keys appear to be secure, but actually aren't).  OTOH, generating the same
4-bit key-id is definitely going to happen.

> So all that is necessary is that the KDF generates a new number each time.
> Maybe that requires state and something in the input to the KDF.

That won't work with HKDF.  Moreover, it's a bad design approach in general,
as it leads to weak KDFs courtesy of predictable output - don't go there ;-).

One could deterministically find another key-id if the generated key-id
is in use (e.g., via iteration - if the KDF generates key-id 7 but key-id 7
is not available, try 8, etc.).

Another idea would be to take two key-ids from the KDF output instead of
just one.  Then if the first key-id matches the key-id that's being rekeyed,
try the second key-id; if that also matches, just rerun the key exchange.
The odds of the key-id that's being rekeyed showing up twice is 1-in-256,
so key exchange reruns should be infrequent.

In all cases, both endpoints have to figure out whether the new key-id is
acceptable and reach the same conclusion.  The requirement that "once
encrypted data packets protected with the new key have been successfully
received, the old key SHOULD be discarded" is helpful, but probably not
enough.

I can think of more that could be said, but understanding what happens in
practice with error and corner cases will be important, e.g., if things
break in the wrong way at the wrong moment, can the two endpoints reach
different conclusions about whether the new key is working?  If so,
that's probably of significant interest to an attacker who can introduce
errors.

Thanks,
--David

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Saturday, January 10, 2015 5:13 PM
> To: Black, David; [email-masked]; [email-masked]
> > > I think key roll is covered in the text. We *do* need to roll the keys,
> but
> we

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Jan 2015 00:30:21 +0000

Hi David,

> 4-bit key-id is definitely going to happen.

Good catch.

> so key exchange reruns should be infrequent.

Yep, something like one of the above. Or we just take more output
bits from HKDF and say that the new key-id is the first of the
relevant set of bits != the old key-id. That way we can lower the
probability of a collision as much as we want. Will include a fix
in a -05.

Cheers,
S.

>> Maybe

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 29 Jan 2015 04:03:52 +0000

Hi Adrian,

In-line [Uma1]:

===
	Uma>> 1. Is it on every hop/LSR along the path the whole packet with label  stack had
                       >> to be decrypted and encrypted with Mel? If yes, IMO this is really
                       >>  bad w.r.t performance (issues of key exchange for thousands of LSPs 
                       >> and load associated would be insignificant in comparison perhaps?).

      >also between end points of an LSP....was intended to say that there are two options:
      >1. encrypt between two adjacent LSRs on an LSP 2. encrypt between the end-points of 
     >an LSP In the latter case you would not encrypt and decrypt at each hop (and indeed would 
     >not be able to since the keys would only be known at the end points).

[Uma1]: Exactly and I got that. 
                In case 1, above its pretty much each LSR has to decrypt the packet to get the top label and encrypt it 
                again with the keys exchanged with neighbor. In case 2, this process could be reduced a bit as you may 
               eliminate few LSRs as keys would be known between the end points.
               But the important point here is - packet is getting encrypted and decrypted 
               multiple times;  which is not TRUE if IPsec is used between the entry and exit ASBRs (transport mode).
               It's good to capture this.
             
 [Uma1]:  Also,  case2 assumption may not hold good,  if labels are learnt Via IGPs (Segment routing cases) as the end points may 
                  not be neighbors and hence no key exchanging session. This need to be clarified a bit in the document. 

      >You are right to point at section 1.2 (and we do need to write that section :-) because L2 
      >solutions (such as MACsec) are typically used on a hop-by-hop basis. I am not clear that MACsec 
      >used in this way is a significant performance issue (I think chips can do L2 security at line speed),
     >although it might cause additional power consumption.

[Uma1]:  It's good to see, but in comparison to transport mode IPSec, IMO, it's significant forwarding 
                 burden on each LSR, even crypto functionality is done in hardware.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Jan 2015 11:32:45 +0000

On 29/01/15 04:03, Uma Chunduri wrote:
>                multiple times; 

Sorry, but that is not the case. The packet is encrypted once
and decrypted once when following this specification. And the
packet can traverse LSRs whilst encrypted without those having
to decrypt and then re-encrypt.

The entire e2e path of a packet may cause it to traverse more
than one encrypt/decrypt but that is as true for IPsec as it
is for this. That is, one can arrange that the endpoints of
cryptographic protection are wherever you want.

S.

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 30 Jan 2015 01:41:57 +0000

Hi Stephen,

In-line [Uma]:

--
Uma C.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Thursday, January 29, 2015 3:33 AM
To: Uma Chunduri; [email-masked]; [email-masked]
Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt

>  But the important point here is - packet is getting encrypted and decrypted

Sorry, but that is not the case. The packet is encrypted once and decrypted once when following this specification. And the packet can traverse LSRs whilst encrypted without those having to decrypt and then re-encrypt.

[Uma]: I am sure then there is some gap (in my understanding perhaps??), but from the draft I clearly see this-

From Section 3:

                    ----------- .      -----------
                   | Top Label | .    | Label 15  |
                   +-----------+  .   +-----------+
                   |   Label   |   .  | MEL   S=1 |
                   +-----------+    . +-----------+
                   | Label S=1 |     .| Ctrl Word |
                   +-----------+      +-----------+
                   |           |      |           |
                   ~  Payload  ~      ~ Encrypted ~
                   |           |      |           |
                    -----------........-----------

        Figure 1 : The Use of the MEL for Hop-by-Hop Encryption

Each LSR has to decrypt first to get the top label and at the egress swap it without label encrypt with keys for the neighbor, put MEL and send out, right? And the same should happen at each LSR..isn’t it??

The entire e2e path of a packet may cause it to traverse more than one encrypt/decrypt but that is as true for IPsec as it is for this. That is, one can arrange that the endpoints of cryptographic protection are wherever you want.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 30 Jan 2015 11:33:52 +0000

Hiya,

> In-line [Uma]:

I'm afraid not. Figure 1 is about hop-by-hop (as it says in the
Figure caption copied above). There is only one hop and hence
no repeated en/decryption.

And (if we look down the page a few centimeters:-) we also have
Figure 2:

                   -----------        -----------
                   | Top Label |      | Top Label |
                   +-----------+      +-----------+
                   |   Label   |      |   Label   |
                   +-----------+.     +-----------+
                   |   Label   | .    | Label 15  |
                   +-----------+  .   +-----------+
                   |   Label   |   .  | MEL   S=1 |
                   +-----------+    . +-----------+
                   | Label S=1 |     .| Ctrl Word |
                   +-----------+      +-----------+
                   |           |      |           |
                   ~  Payload  ~      ~ Encrypted ~
                   |           |      |           |
                    -----------........-----------

        Figure 2 : The Use of the MEL for End-to-End Encryption

Which I think makes things quite clear - the top label is present
in clear as required.

It just would not make any sense (and it simply wouldn't work) for
this specification to require such repeated en/decryptions of the
same payload. If there is any text that implies one does that,
then that text needs fixing and I'd be delighted to see OLD/NEW
form corrections offered. But I do not see any such text to be
honest.

Cheers,
S.