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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 1 Feb 2015 10:05:23 -0000

Stephen says it all.

There will (possibly, and in the opinion of the authors) be some situations where e2e encryption is not possible or desirable, but encryption over a single MPLS hop will add value (perhaps over a vulnerable link).

Of course, if you choose to achieve e2e encryption by concatenating hop-by-hop encryption on every hop, then you will have achieved exactly what you talk about. That would have the costs you describe, and someone doing that (it's a deployment choice!) would have to have a reason.

Adrian

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: 30 January 2015 11:34
> To: Uma Chunduri; [email-masked]; [email-masked]
> Subject: Re: [mpls] FW: New Version Notification for draft-farrelll-mpls-
> opportunistic-encrypt-04.txt
> 
> 
> Hiya,
> 
> On 30/01/15 01:41, Uma Chunduri wrote:
> > 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
> >
> >
> >
> > On 29/01/15 04:03, Uma Chunduri wrote:
> >>  But the important point here is - packet is getting encrypted and decrypted
> >>                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.
> >
> > [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??
> >
> 
> 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.
> 
> 
> >
> > 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: Mon, 2 Feb 2015 19:10:39 +0000

Dear Authors,

I am fine with the assumptions  and applicability.

Probably you might consider group keying with OS (I don't know how this can be achievable precisely), where all nodes (or subset of nodes) participate in the group.
This could enable anonymous encryption you are seeking effectively and will eliminate the both 
a. hop-by-hop encryption requirement as well as 
b. in SR cases Labels in LSPs are from non-adjacent nodes (learned through flooding) and where there is no possibility to do DH to get the keys.

Quick response, In-line [Uma]:

--
Uma C.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Sunday, February 01, 2015 2:05 AM
To: 'Stephen Farrell'; Uma Chunduri; [email-masked]
Subject: RE: [mpls] FW: New Version Notification for draft-farrelll-mpls-opportunistic-encrypt-04.txt

Stephen says it all.
There will (possibly, and in the opinion of the authors) be some situations where e2e encryption is not possible or desirable, 
but encryption over a single MPLS hop will add value (perhaps over a vulnerable link).
[Uma]:  Sure - then I presume OS could possibly give easier deployment that IPSec and IKE together over the vulnerable link, 
              with a cost of unauthenticated DH keys exchanged with peer.

Of course, if you choose to achieve e2e encryption by concatenating hop-by-hop encryption on every hop, then you will have achieved exactly what you talk about. 
That would have the costs you describe, and someone doing that (it's a deployment choice!) would have to have a reason.
[Uma]: Thx for ack-ing the same.

Adrian

> Subject: Re: [mpls] FW: New Version Notification for 
> draft-farrelll-mpls- opportunistic-encrypt-04.txt
> 
> 
> Hiya,
> 
> once when following this specification. And the packet can traverse 
> LSRs whilst encrypted without those having to decrypt and then re-encrypt.
> >
> 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:
> 
>                    -----------        -----------
> Which I think makes things quite clear - the top label is present in 
> clear as required.
> 
> 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.
> 
> 
> >
> 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.
> >