Hi, Spencer, Thank you for your quick answer.
The reason I asked if ATSSS requires changes to path migration is because path validation on an encrypted transport protocol is complicated. One of the requirements that is unique to path migration of QUIC is that it has to be tolerant against MOTS attacks. I think that the WG has, after some back and forth, come to a sensible design, but it has not been tested in the wild yet. Therefore trying to extend path migration might be a bit risky at this point. Also, because there are security requirements for path migration, we do not have the option to delegate the responsibility of doing the correct thing to the implementations. Compared to that, sending data simultaneously on multiple paths do not have security concerns (or they are comparably minor), and we (as a WG that designs the protocol) can delegate many design choices to implementations. Just my thoughts. 2020年10月21日(水) 13:37 Spencer Dawkins at IETF <[email protected] >: > Hi, Kazuho, > > On Tue, Oct 20, 2020, 21:14 Kazuho Oku <[email protected]> wrote: > >> Hello, >> >> Thank you for working on the slides and sharing them beforehand. They >> gave mea good understanding on what the requirements from ATSSS would be. >> >> I have one question: Regarding feature breakdown in pp. 7-8, would it be >> the case that the server address can be stable throughout the lifetime of a >> QUIC connection for all the bullet points? Or would it be the case that the >> server has to migrate to a different address mid-connection? >> > > (When you say "server", you mean "the other end of the QUIC connection", > right? That's often a UPF, which could be something like a MASQUE server in > some eATSSS proposals) > > I don't think the "other end of the QUIC connection" is likely to change > its addresses - the UE is the mobile part of eATSSS, and even then, 3GPP > networks use GTP tunneling to handle mobility, so the UE addresses don't > need to change. > > But I'm not sure everyone would agree about that. > > What I am wondering is if path validation scheme that we have in QUICv1 >> would be sufficient for supporting ATSSS, or if simultaneous migration >> would be required. >> >> I think that having that point clarified (possibly during the >> presentation) would help us better understand the amount of work we need to >> devote if we decide to design features necessary for ATSSS. >> > > I agree that's a good question to talk about in discussion. I haven't seen > concerns expressed about that, but people are still thinking through the > details. > > And thank you for raising the question! > > Best, > > Spencer > > Thank you in advance. >> >> 2020年10月21日(水) 3:18 Spencer Dawkins at IETF < >> [email protected]>: >> >>> Dear Chairs, >>> >>> You should have https://github.com/quicwg/wg-materials/pull/163 >>> available for your viewing pleasure :-) >>> >>> Best, >>> >>> Spencer >>> >> >> >> -- >> Kazuho Oku >> > -- Kazuho Oku
