> Hi Dino, > > Actually when I said 3 RTTs I meant to say 3 TTs so 1.5 RTT. In any case the > below depends on the end point and recurrence of sessions vs pre copied keys: > > Connection setup… the QUIC way: > ○ 0 round-trips to a known server (common) > ○ 1 round-trip if crypto keys are not new > ○ 2 round-trips if QUIC version negotiation needed > > In your case 0.5 RTT seems to be in the case where there is no crypto > security. The draft talks about UDP authentication, but is pretty dry on the > details of it :(
The ETR can encrypt the Map-Register with one shared-key. And the Map-Register contains an authentication hash with another shared-key. So with LISP-proper using UDP, you can get security in 1 TT (.5 RTT). If you want dynamic key exchange, you can use QUIC but you can also use LISP-crypto. Which means a DH exchange happens with RLOC-probes, then the Map-Register is data encapsulated in LISP from the ETR to the Map-Server. This would be 1 RTT + 1 TT (that happens after the RTT). > In any case during mobility there is always radio overlap where the new > registration can take place while old is still working fine. This is the same > with mobile networks or wifi etc ... So I am not sure where the requirement > comes from to compromise security with need for speed ? Don't forget EIDs can roam across WiFi APs too. Dino > > Best, > Robert > > > On Fri, Apr 22, 2022 at 10:41 PM Dino Farinacci <farina...@gmail.com> wrote: > Actually there is, predictive-rlocs. No messaging is better than .5 RTT in > control-plane. But might not be fair to compare since you have to send data > to more places that may get dropped. > > Dino > > > On Apr 22, 2022, at 1:39 PM, Dino Farinacci <farina...@gmail.com> wrote: > > > > Nothing is better than .5 RTT. ;-) > > > > Dino > > > >> On Apr 22, 2022, at 1:18 PM, Robert Raszuk <rob...@raszuk.net> wrote: > >> > >> Hi Dino, > >> > >>> If you use a transport layer that requires connection setup, it will slow > >>> down handoff time when EIDs are moving. > >> > >> But quic connection setup is just 3 RTTs. Is that an issue ? > >> > >> Thx, > >> R. > >> > >> On Fri, Apr 22, 2022 at 8:40 PM Dino Farinacci <farina...@gmail.com> wrote: > >> The others know to add quic, it was part of a discussion on how to open > >> sockets using QUIC and which port numbers to use. That text is coming. The > >> drfat does intend to support multiple transports. Here is one excerpt that > >> proves that: > >> > >> <Screen Shot 2022-04-22 at 11.37.47 AM.png> > >> > >> QUIC will be added to the list above. > >> > >> To answer your second question. If you use a transport layer that requires > >> connection setup, it will slow down handoff time when EIDs are moving. So > >> in that case, a Map-Reqister should just be sent over UDP. And on the > >> Map-Request side you will require an RTT before getting the map-cache > >> populated. > >> > >> Dino > >> > >> > >>> On Apr 22, 2022, at 11:11 AM, Robert Raszuk <rob...@raszuk.net> wrote: > >>> > >>> Hi Dino, > >>> > >>> Before I hit sent I did search the draft and did not find any match on > >>> QUIC :( > >>> > >>> But to your question - yes. I see no reason why LISP control plane could > >>> not be running over QUIC. > >>> > >>> Best, > >>> R. > >>> > >>> On Fri, Apr 22, 2022 at 7:59 PM Dino Farinacci <farina...@gmail.com> > >>> wrote: > >>> The draft indicates QUIC can be used as a reliable transport. But are you > >>> saying QUIC should be used for all LISP messages? > >>> > >>> Dino > >>> > >>>> On Apr 22, 2022, at 6:35 AM, Robert Raszuk <rob...@raszuk.net> wrote: > >>>> > >>>> Hi, > >>>> > >>>> May I ask for reasons not to use QUIC instead of home made UDP based > >>>> transport followed by TCP ? > >>>> > >>>> Many thx, > >>>> Robert > >>>> > >>>> On Wed, Apr 20, 2022 at 9:42 AM Luigi Iannone <g...@gigix.net> wrote: > >>>> All, > >>>> > >>>> During the last LISP WG meeting in Vienna/Meetecho the authors of the > >>>> draft: > >>>> > >>>> LISP Map Server Reliable Transport > >>>> https://datatracker.ietf.org/doc/draft-kouvelas-lisp-map-server-reliable-transport/ > >>>> > >>>> Asked for adoption as WG document. > >>>> Call for adoption during the meeting showed clear consensus. > >>>> This email is the usual procedure to confirm the consensus on the > >>>> mailing list. > >>>> > >>>> If anybody has concerns about adopting this document please state so on > >>>> the mailing list before May 5th 2022. > >>>> Please also argument the technical reason why you have concerns. > >>>> > >>>> Ciao > >>>> > >>>> Luigi & Joel > >>>> > >>>> > >>>> _______________________________________________ > >>>> lisp mailing list > >>>> lisp@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/lisp > >>>> _______________________________________________ > >>>> lisp mailing list > >>>> lisp@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/lisp > >>> > >> > > > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
