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 protected]> wrote: > > 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 protected]] > Sent: 06 November 2015 PM 12:15 > To: Amjad Inamdar (amjads) > Cc: [email protected] > Subject: Re: [lisp] LISP crypto > > 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 protected]> wrote: >> >> 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 protected]] >> Sent: 06 November 2015 AM 05:34 >> To: Amjad Inamdar (amjads) >> Cc: [email protected] >> Subject: Re: [lisp] LISP crypto >> >> 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 protected]> >>> wrote: >>> >>> 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 protected]' >>> 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 >>> >>> _______________________________________________ >>> lisp mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lisp >> _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
