Сообщение Re[10]: TCP все... от 16.11.2018 9:15
Изменено 16.11.2018 9:31 Cyberax
Re[10]: TCP все...
Здравствуйте, netch80, Вы писали:
C>>Дополнительно, QUIC сделан так, что предотвращает окостеневание протоколов (protocol ossification).
N>Прошу показать, как QUIC позволит устранять какие-то нормы стандарта, которые позднее признаны неадекватными и предложена замена (причём, какие именно, мы ещё не знаем).
TCP закостенел. Его невозможно изменить. Простенький ECN (Explicit Congestion Notification) до сих пор не поддерживается всеми middlebox'ами, через 17 лет после RFC.
С QUIC так не получится, так как там шифруется практически всё. Для middlebox'ов оставили один незашифрованный бит.
N>The "ossification" Google harps on is someone else exercising some form of non-Google control, usually by virtue of having bought or being the owner or contractor of the network or computing gear, deploying something designed to be controlled by its owner, or applying standards with the same objective.
Бред.
N>Я знаю проблемы TCP. Но решение от гугла, которое притягивается за уши, может быть ещё хуже.
Чем?
Ops>>>Что усложняет отладку, но не является непреодолимым препятствием для злоумышленника.
C>>В большинстве случаев это означает, что злоумышленник должен иметь полный контроль за каналом.
N>И всё это на той же централизованной схеме сертификатов?
То есть? Никто не мешает использовать DNSSEC+DANE с QUIC. Или свою иерархию. В следующем стандарте будет поддержка PAKE и сильной аутентификации с паролями.
C>>Дополнительно, QUIC сделан так, что предотвращает окостеневание протоколов (protocol ossification).
N>Прошу показать, как QUIC позволит устранять какие-то нормы стандарта, которые позднее признаны неадекватными и предложена замена (причём, какие именно, мы ещё не знаем).
TCP закостенел. Его невозможно изменить. Простенький ECN (Explicit Congestion Notification) до сих пор не поддерживается всеми middlebox'ами, через 17 лет после RFC.
С QUIC так не получится, так как там шифруется практически всё. Для middlebox'ов оставили один незашифрованный бит.
N>The "ossification" Google harps on is someone else exercising some form of non-Google control, usually by virtue of having bought or being the owner or contractor of the network or computing gear, deploying something designed to be controlled by its owner, or applying standards with the same objective.
Бред.
N>Я знаю проблемы TCP. Но решение от гугла, которое притягивается за уши, может быть ещё хуже.
Чем?
Ops>>>Что усложняет отладку, но не является непреодолимым препятствием для злоумышленника.
C>>В большинстве случаев это означает, что злоумышленник должен иметь полный контроль за каналом.
N>И всё это на той же централизованной схеме сертификатов?
То есть? Никто не мешает использовать DNSSEC+DANE с QUIC. Или свою иерархию. В следующем стандарте будет поддержка PAKE и сильной аутентификации с паролями.
Re[10]: TCP все...
Здравствуйте, netch80, Вы писали:
C>>Дополнительно, QUIC сделан так, что предотвращает окостеневание протоколов (protocol ossification).
N>Прошу показать, как QUIC позволит устранять какие-то нормы стандарта, которые позднее признаны неадекватными и предложена замена (причём, какие именно, мы ещё не знаем).
TCP закостенел. Его невозможно изменить. Простенький ECN (Explicit Congestion Notification) до сих пор не поддерживается всеми middlebox'ами, через 17 лет после RFC.
С QUIC так не получится, так как там шифруется практически всё. Для middlebox'ов оставили один незашифрованный бит.
Из конкретных улучшений по сравнению с TCP:
1) PMTU полностью поднят на уровень QUIC, так как на уровне IP оно всё сдохло.
2) Multi-homing внедрён в QUIC и полностью поддерживается. Для TCP это есть только в расширении MPTCP.
3) Продуманный механизм будущих расширений.
4) FEC для компенсации потерянных пакетов (возможно, что в первую версию стандарта не попадёт).
...
N>The "ossification" Google harps on is someone else exercising some form of non-Google control, usually by virtue of having bought or being the owner or contractor of the network or computing gear, deploying something designed to be controlled by its owner, or applying standards with the same objective.
Бред.
N>Я знаю проблемы TCP. Но решение от гугла, которое притягивается за уши, может быть ещё хуже.
Чем?
Ops>>>Что усложняет отладку, но не является непреодолимым препятствием для злоумышленника.
C>>В большинстве случаев это означает, что злоумышленник должен иметь полный контроль за каналом.
N>И всё это на той же централизованной схеме сертификатов?
То есть? Никто не мешает использовать DNSSEC+DANE с QUIC. Или свою иерархию. В следующем стандарте будет поддержка PAKE и сильной аутентификации с паролями.
C>>Дополнительно, QUIC сделан так, что предотвращает окостеневание протоколов (protocol ossification).
N>Прошу показать, как QUIC позволит устранять какие-то нормы стандарта, которые позднее признаны неадекватными и предложена замена (причём, какие именно, мы ещё не знаем).
TCP закостенел. Его невозможно изменить. Простенький ECN (Explicit Congestion Notification) до сих пор не поддерживается всеми middlebox'ами, через 17 лет после RFC.
С QUIC так не получится, так как там шифруется практически всё. Для middlebox'ов оставили один незашифрованный бит.
Из конкретных улучшений по сравнению с TCP:
1) PMTU полностью поднят на уровень QUIC, так как на уровне IP оно всё сдохло.
2) Multi-homing внедрён в QUIC и полностью поддерживается. Для TCP это есть только в расширении MPTCP.
3) Продуманный механизм будущих расширений.
4) FEC для компенсации потерянных пакетов (возможно, что в первую версию стандарта не попадёт).
...
N>The "ossification" Google harps on is someone else exercising some form of non-Google control, usually by virtue of having bought or being the owner or contractor of the network or computing gear, deploying something designed to be controlled by its owner, or applying standards with the same objective.
Бред.
N>Я знаю проблемы TCP. Но решение от гугла, которое притягивается за уши, может быть ещё хуже.
Чем?
Ops>>>Что усложняет отладку, но не является непреодолимым препятствием для злоумышленника.
C>>В большинстве случаев это означает, что злоумышленник должен иметь полный контроль за каналом.
N>И всё это на той же централизованной схеме сертификатов?
То есть? Никто не мешает использовать DNSSEC+DANE с QUIC. Или свою иерархию. В следующем стандарте будет поддержка PAKE и сильной аутентификации с паролями.