Шифрование в BGP

Чтобы злоумышленник не мог свои bgp-апдейты слать и направлять трафик в свою сторону или вообще всё поломать.

Подробности в гугле по запросу cisco bgp password. А если нужны низкоуровневые детали то http://www.ietf.org/rfc/rfc2385.txt

В общих словах я понимаю для чего это нужно. Но хочу узнать для чего именно нужен пароль! Ведь бывает его используют для аутентификации просто.. бывает как ключ для шифрования.. еще как-то. А как именно в ВGP это?

Хз, поэтому предлагаю тебе прочитать rfc :). По-моему, там на первой же странице писалось что именно они хотят делать.

Enables/disables MD5 authentication on a TCP connection between two BGP peers.

Syntax: neighbor {ip-address | peer-group-name} encryption password string

[no] neighbor {ip-address | peer-group-name} password

ip-address IP address of the BGP speaker neighbor. peer-group-name Name of a BGP peer group. encryption Specifies whether password encryption is enabled or not. Valid values: 0 - disabled, 7 - enabled. Default: 7 - enabled. string Password of up to 80 characters.

Description: Authentication between two BGP peers causes each segment sent on the TCP connection to be verified.

Use the neighbor password command to enable authentication. The same password must be used on both systems. If different passwords are used, the connection will fail.

------------------------------------------------------

Вот такое нашел. НО.. при чeм тогда MD5?

Я тебе говорю rfc читай :)

Да понял это уже :) . Подтвердите мои мысли.. Вот кусочек текста из RFC:

To spoof a connection using the scheme described in this paper, an attacker would not only have to guess TCP sequence numbers, but would also have had to obtain the password included in the MD5 digest. This password never appears in the connection stream, and the actual form of the password is up to the application. It could even change.

Every segment sent on a TCP connection to be protected against spoofing will contain the 16-byte MD5 digest produced by applying the MD5 algorithm to these items in the following order:

1. the TCP pseudo-header (in the order: source IP address, destination IP address, zero-padded protocol number, and segment length) 2. the TCP header, excluding options, and assuming a checksum of zero 3. the TCP segment data (if any) 4. an independently-specified key or password, known to both TCPs and presumably connection-specific

--------------------------------------------------------------

Так вот.. ставим пароль, чтоб 2 узла знали, что это именно они между собой общаются, а не кто-то другой. Ну это как обычно. Потом всё это складывается как в этих 4 пунктах и вычисляется хеш, который потом и сверяется на этих 2-ух узлах. Правельно я понимаю?

ой.. там немного в кучу получились пынкта! но там понятно - 4 цифры в последнем абзаце это 4 начала пунктов

Короче, каждый ip-пакет включает контрольную сумму которая вычисляется на основе содержимого пакета ПЛЮС пароль. Принимающая сторона при получении пакета извлекает оттуда хэш, к оставшимся данным приплюсовывает пароль и хэширует всё. Если вычесленный хэш совпал с тем что пришло по сети то значит всё хорошо.

Это как в /etc/shadow при хэшировании добавляется salt, тут что-то похожее.

s/контрольная сумма/хэш/g

И это значит что содержимое пакетов не шифруется.

ааа... так вот в каком месте пароль используется :) понятно.. Вы разложили всё по полочкам. Спасибо

;)