характеризуют безопасность, достижимую при использовании
Следующие выдержки из [RFC2385] характеризуют безопасность, достижимую при использовании опции подписи TCP MD5:
"IESG заявление
Этот документ описывает существующую практику обеспечения безопасности BGP против определенного типа простых атак. Понятно, что система имеет определенные слабости в отношении некоторых атак".
"Аннотация
Этот меморандум описывает расширение TCP с целью улучшения безопасности BGP. Он определяет новую опцию TCP для формирования MD5-дайджеста в сегменте TCP [RFC1321]. Этот дайджест действует подобно подписи для этого сегмента, вводя информацию, известную только конечным пунктам соединения. Так как BGP применяет TCP в качестве транспорта, использование этой опции способом, описанным в данном документе, значительно сокращает опасность определенных атак на BGP."
"Введение
Первоначальная мотивация этой опции заключается в разрешении для BGP защитить себя от введения фальсифицированных TCP сегментов в поток соединения. Особое внимание уделяется сигналам сброса TCP (reset).
Чтобы сфальсифицировать соединения с использованием схемы, описанной в данном документе, атакер должен не только угадать номера TCP-сегментов, но также получить пароль, вставленный в дайджест MD5. Этот пароль никогда не появляется в потоке соединения, а действительная форма пароля определяется приложением. Он может быть изменен за время жизни конкретного соединения при условии синхронности изменения для обоих концов виртуального канала (хотя повторная передача может вызвать проблемы в некоторых TCP реализациях с изменением пароля).
Наконец, не существует процедуры согласования использования этой опции при соединении, скорее это является вопросом политики, использовать данную опцию или нет".
"MD5 в качестве алгоритма хэширования
Так как данный меморандум был сначала выпущен под другим заголовком, алгоритм MD5 был признан уязвимым для атак поиска столкновений [Dobb], и рассматривался как недостаточно строгий для данного типа соединений".
Этот меморандум специфицирует алгоритм MD5, однако, так как опция уже использовалась в работе, и не существует поля "тип алгоритма", чтобы позволить обновление, используется тот же самый номер опции. Исходный документ не специфицирует поле тип, так как это потребовало бы, по крайней мере, на один байт больше, и кажется, что использование 19 байт для полной опции (которая, вероятно в TCP реализации займет за счет заполнителя 20 байт) слишком много для ограниченного пространства опций.
Это не препятствует применению другой подобной опции, которая бы использовала другой алгоритм хэширования (например, SHA-1). Кроме того, если большинство реализаций все равно дополняют 18 байт опции до 20 байт, было бы хорошо определить новую опцию, которая бы содержала поле тип.
На этом выдержки из [RFC2385] завершаются
