Pzz>Вот смотри, вот нормальное завершение TCP сессии:
Pzz>1) A->B: FIN
Pzz>2) B->A: FIN+ACK
Pzz>3) A->B: FIN+ACK

Pzz>По идее, получив третий пакет в этой последовательности, роутер может забыть про сессию. Однако что будет, если третий пакет не дойдет до стороны B? В этом случае B перепошлет 2-й пакет, A перепошлет 3-й, и сессия завершится. Но это не сработает, 3 пакет дойдет до роутера где-то по-середине, удалив сессию из его таблиц, но не дойдет до стороны B. Поэтому, даже в случае TCP, роутерам приходится помнить про сессию некоторое время после ее завершения, и удалять эти записи по таймеру.
В данной ситуации с потерей FIN+ACK в NAT'е вообще не вижу смысла чегото ждать. Ведь можно просто отвечать FIN+ACK-ом или даже RST на все FIN+ACKи, отсутствующие в данный момент в таблице трансляции.
Не говоря уж о том что stateful inspection FW может свободно забывать про конекшен уже на шаге 2.

Pzz> Кстати, в таймерах ничего такого ужасного нет, миллион таймеров можно поддерживать с очень небольшими затратами.
Дело не в самом таймере, а в ресурсах связанным с конекшеном и которые заморожены на время ожидания сработки этого таймера.



O>>Логично было бы оставить расшифрованный пакет, или добавить специальное ICMP сообщение, например. Да даже добавлять не нужно, ведь есть же ICMP port unreachable который посылается в ответ на UDP датаграмму на закрытый порт, вот его можно просто самостоятельно слать при "закрытии" QUIC потока. Оборудование подозреваю уже отработает такой пакет как положено.
Pzz>Тогда можно будет принудительно завершать чужие сессии, не зная сессионных ключей.
Как будто сейчас этого сделать нельзя. ICMP port unreachable это _уже_ работающий механизм. Если его послать с правильными портами — висящий recv с UDP сокета обломится с ошибкой. Или последующий sendto на этот порт обломится — деталей не помню уже, т.к. сканер портов, работающий по данному принципу писал 15 лет назад

Pzz>Вот смотри, вот нормальное завершение TCP сессии:
Pzz>1) A->B: FIN
Pzz>2) B->A: FIN+ACK
Pzz>3) A->B: FIN+ACK

Pzz>По идее, получив третий пакет в этой последовательности, роутер может забыть про сессию. Однако что будет, если третий пакет не дойдет до стороны B? В этом случае B перепошлет 2-й пакет, A перепошлет 3-й, и сессия завершится. Но это не сработает, 3 пакет дойдет до роутера где-то по-середине, удалив сессию из его таблиц, но не дойдет до стороны B. Поэтому, даже в случае TCP, роутерам приходится помнить про сессию некоторое время после ее завершения, и удалять эти записи по таймеру.
В данной ситуации с потерей FIN+ACK в NAT'е вообще не вижу смысла чегото ждать. Ведь можно просто отвечать FIN+ACK-ом или даже RST на все FIN+ACKи, отсутствующие в данный момент в таблице трансляции.
Не говоря уж о том что stateful inspection FW может свободно забывать про конекшен уже на шаге 2.

Pzz> Кстати, в таймерах ничего такого ужасного нет, миллион таймеров можно поддерживать с очень небольшими затратами.
Дело не в самом таймере, а в ресурсах связанных с конекшеном и которые заморожены на время ожидания сработки этого таймера.



O>>Логично было бы оставить расшифрованный пакет, или добавить специальное ICMP сообщение, например. Да даже добавлять не нужно, ведь есть же ICMP port unreachable который посылается в ответ на UDP датаграмму на закрытый порт, вот его можно просто самостоятельно слать при "закрытии" QUIC потока. Оборудование подозреваю уже отработает такой пакет как положено.
Pzz>Тогда можно будет принудительно завершать чужие сессии, не зная сессионных ключей.
Как будто сейчас этого сделать нельзя. ICMP port unreachable это _уже_ работающий механизм. Если его послать с правильными портами — висящий recv с UDP сокета обломится с ошибкой. Или последующий sendto на этот порт обломится — деталей не помню уже, т.к. сканер UDP портов, работающий по данному принципу, писал >15 лет назад