search

ietf-wg-masque / draft-ietf-masque-quic-proxy

Other
12 stars 7 forks source link

Idle timeouts and forwarded packets #15

Closed LPardue closed 3 years ago

LPardue commented 3 years ago

How do forwarded packets play with the proxy<->client QUIC connection idle timeout behaviour https://tools.ietf.org/html/draft-ietf-quic-transport-31#section-10.1? Does a client need to keepalive the QUIC connection (e.g. PING) in addition to sending packets to be forwarded. It would seem easier for those packets to somehow reset the timer. If that's the intention the spec should say something.

tfpauly commented 3 years ago

I think that the forwarded packets should indeed reset the timer. I view it similarly to the idle state that the kernel keeps for IPsec SAs to let an IKE engine know if it should tear down.

Any issue with saying we should have the timer be kept alive by forwarded packets?

LPardue commented 3 years ago

No issue with it resetting a timer. But I've not thought through all the edge cases. Does it apply in both directions or do we want to reset only on client->proxy packets?

LPardue commented 3 years ago

the reason I ask is because if the client goes away, a large response could keep the connection alive indefinitely. Reseting on client->proxy would naturally reflect the client Acks (and this active relationship) to the origin.

tfpauly commented 3 years ago

Yeah, having this be kept alive based on client -> proxy sounds right.