Subject: [lisp] LISP crypto

From: "Amjad Inamdar (amjads)" <[email-masked]>
Date: Thu, 5 Nov 2015 18:37:40 +0000

Hi Brian/Dino,

The key material derivation proposed in draft-ietf-lisp-crypto is based on Diffie-Hellman which is not Quantum Computer resistant. There is some work underway to make IKE that uses DH for key derivation Quantum Computer safe. Might be a good idea to consider this for lisp-crypto as well.

Thanks,
-Amjad

From: Amjad Inamdar (amjads)
Sent: 03 November 2015 PM 12:33
To: [email-masked]'
Subject: LISP NAT Traversal

Hi,

It will be useful if LISP NAT traversal draft (draft-ermagan-lisp-nat-traversal) can elaborate on the following

1) Why LISP NAT traversal cannot be accomplished without RTR (another network entity) which has implications on deployability, complexity and latency. There are other protocols (e.g IKE/IPsec) that achieve NAT-D and NAT-T without the need for additional network entity.

2) Some more details on RTR deployment
- location of RTR in the LISP deployment like there are recommendations on PITR/PETR deployments
- is RTR shared across LISP sites behind NAT or each site needs a dedicated RTR
- what if RTR is behind another NAT (SP-NAT)

3) How is multiple-NAT handled (e.g. enterprise and SP NAT)

Thanks,
-Amjad Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK
Senior Technical Leader
CSG PI Services Security - India

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 5 Nov 2015 16:03:58 -0800

Amjad, we are aware of the QC-safe work going on in CFRG. We are following it but it is very researchy at this point. We can add some text indicating that we’ll follow any CFRG/SAAG recommendations (or any security area working group’s recommendation) on using QC-safe technology.

If there is anything specific you want us to look at with IKE, please send some pointers. Thanks.

Dino

> On Nov 5, 2015, at 10:37 AM, Amjad Inamdar (amjads) <[email-masked]> wrote:
> 
> Hi Brian/Dino,
>  
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 6 Nov 2015 00:23:36 +0000

On 06/11/15 00:03, Dino Farinacci wrote:
> Amjad, we are aware of the QC-safe work going on in CFRG. We are
> following it but it is very researchy at this point. 

Correct. It would be premature IMO to try to incorporate any
functionality that aims to mitigate QC attacks against
asymmetric crypto since we're not at a point where we know how
to do that effectively and efficiently.

> We can add some
> text indicating that we’ll follow any CFRG/SAAG recommendations (or
> any security area working group’s recommendation) on using QC-safe
> technology.

I don't think that's needed myself.

S.

>> The key material derivation proposed in draft-ietf-lisp-crypto is
>> based on Diffie-Hellman which is not Quantum Computer resistant.
>> There is some work underway to make IKE that uses DH for key
>> derivation Quantum Computer safe. Might be a good idea to consider
>> this for lisp-crypto as well.
>> 
>> Thanks, -Amjad
>> 
>> From: Amjad Inamdar (amjads) Sent: 03 November 2015 PM 12:33 To:
>> [email-masked]' Subject: LISP NAT Traversal
>> 
>> Hi,
>> 
>> It will be useful if LISP NAT traversal draft
>> (draft-ermagan-lisp-nat-traversal) can elaborate on the following
>> 
>> 1) Why LISP NAT traversal cannot be accomplished without RTR
>> (another network entity) which has implications on deployability,
>> complexity and latency. There are other protocols (e.g IKE/IPsec)
>> that achieve NAT-D and NAT-T without the need for additional
>> network entity.
>> 
>> 2) Some more details on RTR deployment - location of RTR in the
>> LISP deployment like there are recommendations on PITR/PETR
>> deployments - is RTR shared across LISP sites behind NAT or each
>> site needs a dedicated RTR - what if RTR is behind another NAT
>> (SP-NAT)
>> 
>> Thanks, -Amjad Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK 
>> Senior Technical Leader CSG PI Services Security - India
>> 
>> _______________________________________________ lisp mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________ lisp mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 5 Nov 2015 16:36:22 -0800

Okay, thanks for input Stephen, appreciated.

Dino

> On Nov 5, 2015, at 4:23 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
>

---

From: "Amjad Inamdar (amjads)" <[email-masked]>
Date: Fri, 6 Nov 2015 04:47:51 +0000

Hi Dino,

The thing being proposed with IKEv2 is to include a pre-shared key in the key derivation and with sufficient entropy in the pre-shared key, this would offer fair amount of protection. You can please refer draft-fluhrer-qr-ikev2 for further details.

Thanks,
-Amjad

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: 06 November 2015 AM 05:34
To: Amjad Inamdar (amjads)
Cc: [email-masked]
Subject: Re: [lisp] LISP crypto

Dino

> -Amjad Inamdar CISSP, CCNP R&S, CCNP Security, CCDP, CCSK Senior 
> Technical Leader CSG PI Services Security - India
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 6 Nov 2015 15:44:35 +0900

In the lisp-crypto design, the ECDH shared secret is input to the KDF that produces the encryption key and integrity-check key. 

Sounds like we may already be doing what you suggest. 

And not clear to me how much more QC-safe this actually is. 

Dino

> On Nov 6, 2015, at 1:47 PM, Amjad Inamdar (amjads) <[email-masked]> wrote:
> 
> Hi Dino,
>

---

From: "Amjad Inamdar (amjads)" <[email-masked]>
Date: Fri, 6 Nov 2015 09:36:59 +0000

Hi Dino,

The pre-shared key I mentioned about would need to be pre-configured on the peers/xTRs. DH shared secret is based on DH public values exchanged on the wire which QC can break.

Thanks,
-Amjad

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: 06 November 2015 PM 12:15
To: Amjad Inamdar (amjads)
Cc: [email-masked]
Subject: Re: [lisp] LISP crypto

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 6 Nov 2015 21:29:18 +0900

Configured shared-keys is a non- starter for LISP. 

Imagine and ITR, just with 10K map-cache entries that point to dual-homed LISP sites. That is 20K keys that not only need to be configured but colocated with those 20K RLOCs. RLOCs that can change due to EID-prefix mobility. 

Dino

> On Nov 6, 2015, at 6:36 PM, Amjad Inamdar (amjads) <[email-masked]> wrote:
> 
> Hi Dino,
>