Re: [quicwg/base-drafts] IP Anycast with server IP+Port renegotiation (#560)

[Mike Bishop <[e-mail]>]

I don't see this as being ALTSVC -- ALTSVC by definition implies the other endpoint is an acceptable *alternative* the client should consider for the future, not a "move now" directive.  However, I do see this as being a special case of server-side migration.  We can borrow the logic from Teredo of sending appropriate bubble packets to open the NAT, but we should keep things symmetrical with an eye toward peer-to-peer uses of QUIC.

Perhaps the MIGRATE frame simply says, "I expect to shortly begin using this IP/port/Connection ID; please send a PING frame to that destination"?  The recipient then begins the process in #732 as if it had just received a packet from that IP/port.

We'd need to think about attacks where the sender knows there's an existing QUIC connection at that IP/port with that Connection ID (the attempt to validate then looks like an address change from the target connection's peer), but I'd hope that it's sufficiently difficult to force your connection to use the same key as the target, so decryption would just drop the packet.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/560#issuecomment-324166090