Re: [lisp] Draft-kouvelas-lisp-map-server-reliable-transport WG Adoption

[Dino Farinacci <[e-mail]>]

> 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 <[e-mail]> 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 <[e-mail]> wrote:
> > 
> > Nothing is better than .5 RTT.  ;-)
> > 
> > Dino
> > 
> >> On Apr 22, 2022, at 1:18 PM, Robert Raszuk <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/lisp
> >>>> _______________________________________________
> >>>> lisp mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/lisp
> >>> 
> >> 
> > 
>