RFC 4275 BGP-4 MIB Implementation Survey

Network Working Group                                       S. Hares
Request for Comments: 4275                                   NextHop
Category: Informational                                     D. Hares
                                             Hickory Hill Consulting
                                                        January 2006

Опрос по реализациям BGP-4 MIB

BGP-4 MIB Implementation Survey

PDF

Статус документа

Этот документ содержит информацию для сообщества Internet. Документ не задает каких-либо стандартов. Допускается свободное распространения документа.

Авторские права

Copyright (C) The Internet Society (2006).

Тезисы

Этот документ содержит результаты опроса по реализациям BGP-4, поддерживающим агенты RFC 1657 MIB в соответствии со спецификацией the BGP-4 v1 MIB.

Оглавление

Исключено из версии HTML

1. Введение

Этот документ содержит результаты опроса по реализациям BGP-4 v1 MIB [RFC4274]. После краткой вводной части приводятся все полученные отклики. Авторы документа не несут ответственности за корректность предоставленной в ответах информации.

Организации, сообщившие о наличии реализаций BGP-4 MIB: Cisco Systems, Redback Networks и NextHop Technologies.

2. Обзорная информация по опросу

В этом опросе у респондентов запрашивалась информация о реализациях протокола BGP-4 [RFC4271], которые поддерживают агенты MIB [RFC1657], соответствующие BGP-4 v1 MIB [RFC4274].

Две или более реализации BGP-4 v1 MIB [RFC4274] поддерживают все объекты. Ни одна из реализаций, для которых были получены отклики, не поддерживает переменные с возможностью записи (read-write, см. параграф 2.2). Два заданных в спецификации прерывания (TRAP) не поддерживаются двумя реализациями (параграф 2.3). Инициализация счетчиков нулевыми значениями наблюдается во всех реализациях, но сброс при переходе партнера в состояние Established происходит только в реализации Redback (параграф 2.4).

В документе рассматриваются 3 реализации агента из трех опршенных (параграф 2.5).

Для тестирования реализаций использовались SNMP1-менеджеры Net-SNMP (www.net-snmp.org), Multi Router Traffic Grapher (www.mrtg.org) и фирменный менеджер Cisco.

Проблем интероперабельности, связанных с менеджерами, не было отмечено.

2.1. Реализация объектов MIB

     Cisco  NextHop  Redback
        Y      Y      Y         bgpVersion
        Y      Y      Y         bgpLocalAs
        Y      Y      Y         bgpPeerIdentifier
        Y      Y      Y         bgpPeerState
        Y      Y      Y         bgpPeerAdminStatus
        Y      Y      Y         bgpPeerNegotiatedVersion
        Y      Y      Y         bgpPeerLocalAddr
        Y      Y      Y         bgpPeerLocalPort
        Y      Y      Y         bgpPeerRemoteAddr
        Y      Y      Y         bgpPeerRemotePort
        Y      Y      Y         bgpPeerRemoteAs
        Y      Y      Y         bgpPeerInUpdates
        Y      Y      Y         bgpPeerOutUpdates
        Y      Y      Y         bgpPeerInTotalMessages
        Y      Y      Y         bgpPeerOutTotalMessages
        Y      Y      Y         bgpPeerLastError
        Y      Y      Y         bgpPeerFsmEstablishedTransitions
        Y      Y      Y         bgpPeerFsmEstablishedTime
        Y      Y      Y         bgpPeerConnectRetryInterval
        Y      Y      Y         bgpPeerHoldTime
        Y      Y      Y         bgpPeerKeepAlive
        Y      Y      Y         bgpPeerHoldTimeConfigured
        Y      Y      Y         bgpPeerKeepAliveConfigured
        Y      Y      Y         bgpPeerMinASOriginationInterval
        Y      Y      Y         bgpPeerMinRouteAdvertisementInterval
        Y      Y      Y         bgpPeerInUpdateElapsedTime
        Y      Y      Y         bgpIdentifier

        N      N      N         bgpPathAttrPeer
        N      N      N         bgpPathAttrDestNetwork
        N      N      N         bgpPathAttrOrigin
        N      N      N         bgpPathAttrASPath
        N      N      N         bgpPathAttrNextHop
        N      N      N         bgpPathAttrInterASMetric

        Y      Y      Y         bgp4PathAttrPeer
        Y      Y      Y         bgp4PathAttrIpAddrPrefixLen
        Y      Y      Y         bgp4PathAttrIpAddrPrefix
        Y      Y      Y         bgp4PathAttrOrigin
        Y      Y      Y         bgp4PathAttrASPathSegment
        Y      Y      Y         bgp4PathAttrNextHop

        Y      Y      Y         bgp4PathAttrMultiExitDisc
        Y      Y      Y         bgp4PathAttrLocalPref
        Y      Y      Y         bgp4PathAttrAtomicAggregate
        Y      Y      Y         bgp4PathAttrAggregatorAS
        Y      Y      Y         bgp4PathAttrAggregatorAddr
        Y      Y      Y         bgp4PathAttrCalcLocalPref
        Y      Y      Y         bgp4PathAttrBest
        Y      Y      Y         bgp4PathAttrUnknown

 

Отметим, что объекты bgpPathAttrPeer, bgpPathAttrDestNetwork, bgpPathAttrOrigin, bgpPatthAttrASPath, bgpPathAttrNextHop и bgpPathAttrInterASMetric запрещены для использования. Ответы Y/N учитывают этот запрет.

2.2. Реализация объектов с возможностью записи (Read-Write)

Позволяет ли ваше реализация менеджерам устанавливать значения для перечисленных ниже объектов (укажите Y или N для каждого объекта):

      Cisco  NextHop  Redback
        N      N        N        bgpPeerAdminStatus
        N      N        N        bgpPeerConnectRetryInterval
        N      N        N        bgpPeerHoldTimeConfigured
        N      N        N        bgpPeerKeepAliveConfigured
        N      N        N        bgpPeerMinASOriginationInterval
        N      N        N        bgpPeerMinRouteAdvertisementInterval

Отметим, что реализации поддерживают указанные в опросе переменные типа read/write.

2.3. Hеализация прерываний (Trap)

Поддерживает ли ваша реализация перечисленные ниже уведомления (укажите Y или N для каждого уведомления):

Cisco NextHop Redback
 Y     N       N         bgpEstablished
 Y     N       Y2        bgpBackwardTransition

2.4. Инициализация и сброс счетчиков

Были заданы два вопроса об объектах bgpPeerInUpdates, bgpPeerOutUpdates, bgpPeerInTotalMessages и bgpPeerOutTotalMessages.

  1. Устанавливаете ли вы нулевые значения счетчиков при инициализации?
  2. Сбрасываете ли вы в ноль счетчики когда указанный в конфигурации партнер переходит в состояние Established?

       Cisco  NextHop  Redback
        Y      Y        Y        инициализация нулевыми значениями
        N      N        Y        сброс в 0 при переходе в состояние Established

2.5. Взаимодействие с менеджерами

Менеджеры:

Агент BGP MIB:

         Cisco  NextHop  Redback
           Y      Y        N     независимая реализация
           -      -        C     P или C – общедоступный или коммерческий

Код Redback основан на SNMP Research EMANATE

Взаимодействие с менеджерами SNMP

          Cisco  NextHop    Redback
          cisco  Net-SNMP   MRTG SNMP  использованный для теста менеджер
           -     Y           Y         менеджер реализован независимо от агента
           -     Y           Y         доступ для чтения переменных BGP-4 MIB
           N     N           N         доступ для записи переменных BGP-4 MIB
           -     N           Y         передача или прием уведомлений BGP-4 MIB.
           Y     Y           Y         тестирование с использованием SNMPv1/v2c.
           Y     N           Y         тестирование с использованием SNMPv3.

«-» показывает, что компания Cisco не ответила на эти вопросы.

Агент NextHop SNMP поддерживается через интерфейс SNMP Multiplex (SMUX).

MRTG SNMP можно найти на сайте www.mrtg.org, Net-SNMP (UC Davis tools) – на сайте www.net-snmp.org.

Проблемы интероперабельности между агентами и менеджерами.

Cisco NextHop Redback
 N     N       N        проблемы интероперабельности

3. Опросные листы

3.1. Cisco Systems

Реализация агента

Этот раздел следует заполнить лицу или компании, которые поддерживают реализацию RFC 1657 [RFC1657] в агенте SNMP.

Является ли ваша реализация агента BGP-4 MIB независимой или она базируется на публично доступном (public domain) или коммерческом коде? Если реализация не является независимой, какой код в ней используется?

- агент BGP-4 MIB реализован в коммерческой системе Cisco IOS3.

Проверяли ли вы интероперабельность с менеджерами, реализующими BGP-4 MIB? Если проверяли, то с какими?

- (компания Cisco не ответила на этот вопрос)

Какие функции тестировались для каждого менеджера, с которым обеспечивается интероперабельность? Продублируйте этот раздел для каждого протестированного менеджера и укажите (Y/N) для каждой функции:

- (компания Cisco не ответила на этот вопрос)

Использованная реализация менеджера: <название>

Основан на оригинальном коде (если известно): <название >

(Y/N) Менеджер реализован независимо от вашего агента?

(Y/N) Доступ для чтения переменных BGP-4 MIB.

(Y/N) Доступ для записи переменных BGP-4 MIB.

(Y/N) Прием и передача уведомлений BGP-4 MIB.

(Y/N) Тестировался с использованием SNMPv1/v2c.

(Y/N) Тестировался с использованием SNMPv3.

Возникали ли проблемы интероперабельности между вашим агентом BGP-4 MIB и каким-либо менеджером BGP-4 MIB, которые могут указывать на проблемы в спецификации? Если проблемы возникали, приведите технические детали.

— (эта часть опроса не была возвращена компанией Cisco)

(Y) Ваш агент поддерживает SNMPv3?

Ваш агент BGP-4 MIB реализует перечисленные ниже объекты? Укажите Y или N для каждого объекта:

       (Y)        bgpVersion
       (Y)        bgpLocalAs
       (Y)        bgpPeerIdentifier
       (Y)        bgpPeerState
       (Y)        bgpPeerAdminStatus
       (Y)        bgpPeerNegotiatedVersion
       (Y)        bgpPeerLocalAddr
       (Y)        bgpPeerLocalPort
       (Y)        bgpPeerRemoteAddr
       (Y)        bgpPeerRemotePort
       (Y)        bgpPeerRemoteAs
       (Y)        bgpPeerInUpdates
       (Y)        bgpPeerOutUpdates
       (Y)        bgpPeerInTotalMessages
       (Y)        bgpPeerOutTotalMessages
       (Y)        bgpPeerLastError
       (Y)        bgpPeerFsmEstablishedTransitions
       (Y)        bgpPeerFsmEstablishedTime
       (Y)        bgpPeerConnectRetryInterval
       (Y)        bgpPeerHoldTime
       (Y)        bgpPeerKeepAlive
       (Y)        bgpPeerHoldTimeConfigured
       (Y)        bgpPeerKeepAliveConfigured
       (Y)        bgpPeerMinASOriginationInterval
       (Y)        bgpPeerMinRouteAdvertisementInterval
       (Y)        bgpPeerInUpdateElapsedTime
       (Y)        bgpIdentifier
       (N)        bgpPathAttrPeer
       (N)        bgpPathAttrDestNetwork
       (N)        bgpPathAttrOrigin
       (N)        bgpPathAttrASPath
       (N)        bgpPathAttrNextHop
       (N)        bgpPathAttrInterASMetric
       (Y)        bgp4PathAttrPeer
       (Y)        bgp4PathAttrIpAddrPrefixLen
       (Y)        bgp4PathAttrIpAddrPrefix
       (Y)        bgp4PathAttrOrigin
       (Y)        bgp4PathAttrASPathSegment
       (Y)        bgp4PathAttrNextHop
       (Y)        bgp4PathAttrMultiExitDisc
       (Y)        bgp4PathAttrLocalPref
       (Y)        bgp4PathAttrAtomicAggregate
       (Y)        bgp4PathAttrAggregatorAS
       (Y)        bgp4PathAttrAggregatorAddr
       (Y)        bgp4PathAttrCalcLocalPref
       (Y)        bgp4PathAttrBest
       (Y)        bgp4PathAttrUnknown

Позволяет ли ваша реализация записывать в перечисленные ниже объекты типа read-write? Укажите Y или N для каждого объекта:

       (N) bgpPeerAdminStatus
       (N) bgpPeerConnectRetryInterval
       (N) bgpPeerHoldTimeConfigured
       (N) bgpPeerKeepAliveConfigured
       (N) bgpPeerMinASOriginationInterval
       (N) bgpPeerMinRouteAdvertisementInterval

Поддерживает ли ваша реализация перечисленные ниже уведомления? Укажите Y или N для каждого уведомления:

(Y) bgpEstablished
(Y) bgpBackwardTransition

Инициализирует ли ваша реализация счетчики bgpPeerInUpdates, bgpPeerOutUpdates, bgpPeerInTotalMessages и bgpPeerOutTotalMessages нулевыми значениями?

Да

Сбрасывает ли ваша реализация значения счетчиков bgpPeerInUpdates, bgpPeerOutUpdates, bgpPeerInTotalMessages и bgpPeerOutTotalMessages в 0 при переходе партнера в состояние Established?

Нет

3.2. NextHop Technologies

Реализация агента

Этот раздел следует заполнить лицу или компании, которые поддерживают реализацию RFC 1657 [RFC1657] в агенте SNMP.

Является ли ваша реализация агента BGP-4 MIB независимой или она базируется на публично доступном (public domain) или коммерческом коде? Если реализация не является независимой, какой код в ней используется?

— независимая реализация.

Проверяли ли вы интероперабельность с менеджерами, реализующими BGP-4 MIB? Если проверяли, то с какими?

— Да

Какие функции тестировались для каждого менеджера, с которым обеспечивается интероперабельность? Продублируйте этот раздел для каждого протестированного менеджера и укажите (Y/N) для каждой функции:

Использованная реализация менеджера: <название>

— UC Davis SNMP Tools (Net-SNMP)

Основан на оригинальном коде (если известно): UC Davis SNMP

(Y) Менеджер реализован независимо от вашего агента?
(Y) Доступ для чтения переменных BGP-4 MIB.
(na) Доступ для записи переменных BGP-4 MIB.
(na) Прием и передача уведомлений BGP-4 MIB.
(Y) Тестировался с использованием SNMPv1/v2c.
(N) Тестировался с использованием SNMPv3.

Возникали ли проблемы интероперабельности между вашим агентом BGP-4 MIB и каким-либо менеджером BGP-4 MIB, которые могут указывать на проблемы в спецификации? Если проблемы возникали, приведите технические детали.

(Y/N) Ваш агент поддерживает SNMPv3?

— N/A. Доступ к агенту обеспечивался через SMUX.

Ваш агент BGP-4 MIB реализует перечисленные ниже объекты? Укажите Y или N для каждого объекта:

       (Y)        bgpVersion
       (Y)        bgpLocalAs
       (Y)        bgpPeerIdentifier
       (Y)        bgpPeerState
       (Y)        bgpPeerAdminStatus
       (Y)        bgpPeerNegotiatedVersion
       (Y)        bgpPeerLocalAddr
       (Y)        bgpPeerLocalPort
       (Y)        bgpPeerRemoteAddr
       (Y)        bgpPeerRemotePort
       (Y)        bgpPeerRemoteAs
       (Y)        bgpPeerInUpdates
       (Y)        bgpPeerOutUpdates
       (Y)        bgpPeerInTotalMessages
       (Y)        bgpPeerOutTotalMessages
       (Y)        bgpPeerLastError
       (Y)        bgpPeerFsmEstablishedTransitions
       (Y)        bgpPeerFsmEstablishedTime
       (Y)        bgpPeerConnectRetryInterval
       (Y)        bgpPeerHoldTime
       (Y)        bgpPeerKeepAlive
       (Y)        bgpPeerHoldTimeConfigured
       (Y)        bgpPeerKeepAliveConfigured
       (Y)        bgpPeerMinASOriginationInterval
       (Y)        bgpPeerMinRouteAdvertisementInterval
       (Y)        bgpPeerInUpdateElapsedTime
       (Y)        bgpIdentifier
       (N)        bgpPathAttrPeer
       (N)        bgpPathAttrDestNetwork
       (N)        bgpPathAttrOrigin
       (N)        bgpPathAttrASPath
       (N)        bgpPathAttrNextHop
       (N)        bgpPathAttrInterASMetric
       (Y)        bgp4PathAttrPeer
       (Y)        bgp4PathAttrIpAddrPrefixLen
       (Y)        bgp4PathAttrIpAddrPrefix
       (Y)        bgp4PathAttrOrigin
       (Y)        bgp4PathAttrASPathSegment
       (Y)        bgp4PathAttrNextHop
       (Y)        bgp4PathAttrMultiExitDisc
       (Y)        bgp4PathAttrLocalPref
       (Y)        bgp4PathAttrAtomicAggregate
       (Y)        bgp4PathAttrAggregatorAS
       (Y)        bgp4PathAttrAggregatorAddr
       (Y)        bgp4PathAttrCalcLocalPref
       (Y)        bgp4PathAttrBest
       (Y)        bgp4PathAttrUnknown

Позволяет ли ваша реализация записывать в перечисленные ниже объекты типа read-write? Укажите Y или N для каждого объекта:

       (N) bgpPeerAdminStatus
       (N) bgpPeerConnectRetryInterval
       (N) bgpPeerHoldTimeConfigured
       (N) bgpPeerKeepAliveConfigured
       (N) bgpPeerMinASOriginationInterval
       (N) bgpPeerMinRouteAdvertisementInterval

Поддерживает ли ваша реализация перечисленные ниже уведомления? Укажите Y или N для каждого уведомления:

       (N) bgpEstablished
       (N) bgpBackwardTransition

Инициализирует ли ваша реализация счетчики bgpPeerInUpdates, bgpPeerOutUpdates, bgpPeerInTotalMessages и bgpPeerOutTotalMessages нулевыми значениями?

Да

Сбрасывает ли ваша реализация значения счетчиков bgpPeerInUpdates, bgpPeerOutUpdates, bgpPeerInTotalMessages и bgpPeerOutTotalMessages в 0 при переходе партнера в состояние Established?

Нет

3.3. Redback Networks

Реализация агента

Этот раздел следует заполнить лицу или компании, которые поддерживают реализацию RFC 1657 [RFC1657] в агенте SNMP.

Является ли ваша реализация агента BGP-4 MIB независимой или она базируется на публично доступном (public domain) или коммерческом коде? Если реализация не является независимой, какой код в ней используется?

— нет, агент основан на SNMP Research EMANATE

Проверяли ли вы интероперабельность с менеджерами, реализующими BGP-4 MIB? Если проверяли, то с какими?

— мы проверяли интероперабельность своего агента с менеджером MRTG.

Какие функции тестировались для каждого менеджера, с которым обеспечивается интероперабельность? Продублируйте этот раздел для каждого протестированного менеджера и укажите (Y/N) для каждой функции:

Использованная реализация менеджера: MRTG (www.mrtg.org)
(Y) Менеджер реализован независимо от вашего агента?
(Y) Доступ для чтения переменных BGP-4 MIB.
(N) Доступ для записи переменных BGP-4 MIB.
(Y) Прием и передача уведомлений BGP-4 MIB.
(Y) Тестировался с использованием SNMPv1/v2c.
(N) Тестировался с использованием SNMPv3.

Возникали ли проблемы интероперабельности между вашим агентом BGP-4 MIB и каким-либо менеджером BGP-4 MIB, которые могут указывать на проблемы в спецификации? Если проблемы возникали, приведите технические детали.

Нет, мы не сталкивались с неразрешимыми проблемами интероперабельности.

(Y) Ваш агент поддерживает SNMPv3?

Ваш агент BGP-4 MIB реализует перечисленные ниже объекты? Укажите Y или N для каждого объекта:

       (Y)        bgpVersion
       (Y)        bgpLocalAs
       (Y)        bgpPeerIdentifier
       (Y)        bgpPeerState
       (Y)        bgpPeerAdminStatus
       (Y)        bgpPeerNegotiatedVersion
       (Y)        bgpPeerLocalAddr
       (Y)        bgpPeerLocalPort
       (Y)        bgpPeerRemoteAddr
       (Y)        bgpPeerRemotePort
       (Y)        bgpPeerRemoteAs
       (Y)        bgpPeerInUpdates
       (Y)        bgpPeerOutUpdates
       (Y)        bgpPeerInTotalMessages
       (Y)        bgpPeerOutTotalMessages
       (Y)        bgpPeerLastError
       (Y)        bgpPeerFsmEstablishedTransitions
       (Y)        bgpPeerFsmEstablishedTime
       (Y)        bgpPeerConnectRetryInterval
       (Y)        bgpPeerHoldTime
       (Y)        bgpPeerKeepAlive
       (Y)        bgpPeerHoldTimeConfigured
       (Y)        bgpPeerKeepAliveConfigured
       (Y)        bgpPeerMinASOriginationInterval
       (Y)        bgpPeerMinRouteAdvertisementInterval
       (Y)        bgpPeerInUpdateElapsedTime
       (Y)        bgpIdentifier

       (N)        bgpPathAttrPeer
       (N)        bgpPathAttrDestNetwork
       (N)        bgpPathAttrOrigin
       (N)        bgpPathAttrASPath
       (N)        bgpPathAttrNextHop
       (N)        bgpPathAttrInterASMetric

       (Y)        bgp4PathAttrPeer
       (Y)        bgp4PathAttrIpAddrPrefixLen
       (Y)        bgp4PathAttrIpAddrPrefix
       (Y)        bgp4PathAttrOrigin
       (Y)        bgp4PathAttrASPathSegment
       (Y)        bgp4PathAttrNextHop
       (Y)        bgp4PathAttrMultiExitDisc
       (Y)        bgp4PathAttrLocalPref
       (Y)        bgp4PathAttrAtomicAggregate
       (Y)        bgp4PathAttrAggregatorAS
       (Y)        bgp4PathAttrAggregatorAddr
       (Y)        bgp4PathAttrCalcLocalPref
       (Y)        bgp4PathAttrBest
       (Y)        bgp4PathAttrUnknown

Позволяет ли ваша реализация записывать в перечисленные ниже объекты типа read-write? Укажите Y или N для каждого объекта:

       (N) bgpPeerAdminStatus
       (N) bgpPeerConnectRetryInterval
       (N) bgpPeerHoldTimeConfigured
       (N) bgpPeerKeepAliveConfigured
       (N) bgpPeerMinASOriginationInterval
       (N) bgpPeerMinRouteAdvertisementInterval

Поддерживает ли ваша реализация перечисленные ниже уведомления? Укажите Y или N для каждого уведомления:

    (Y) bgpEstablished
    (Y) bgpBackwardTransition – только при переходе из состояния Established в состояние Idle.

Инициализирует ли ваша реализация счетчики bgpPeerInUpdates, bgpPeerOutUpdates, bgpPeerInTotalMessages и bgpPeerOutTotalMessages нулевыми значениями?

Да

Сбрасывает ли ваша реализация значения счетчиков bgpPeerInUpdates, bgpPeerOutUpdates, bgpPeerInTotalMessages и bgpPeerOutTotalMessages в 0 при переходе партнера в состояние Established?

Да

4. Значения MIB Walk

Ниже представлены значения MIB walk, представленные респондентами.

4.1. Cisco Systems

   BGP4-MIB::bgpVersion.0
       = Hex-STRING: 10
   BGP4-MIB::bgpLocalAs.0
       = INTEGER: 65000
   BGP4-MIB::bgpPeerIdentifier.10.10.1.29
       = IpAddress: 10.10.2.229
   BGP4-MIB::bgpPeerIdentifier.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgpPeerState.10.10.1.29
       = INTEGER: established(6)
   BGP4-MIB::bgpPeerState.11.10.128.3
       = INTEGER: established(6)
   BGP4-MIB::bgpPeerAdminStatus.10.10.1.29
       = INTEGER: start(2)
   BGP4-MIB::bgpPeerAdminStatus.11.10.128.3
       = INTEGER: start(2)
   BGP4-MIB::bgpPeerNegotiatedVersion.10.10.1.29
       = INTEGER: 4
   BGP4-MIB::bgpPeerNegotiatedVersion.11.10.128.3
       = INTEGER: 4
   BGP4-MIB::bgpPeerLocalAddr.10.10.1.29
       = IpAddress: 11.10.128.4
   BGP4-MIB::bgpPeerLocalAddr.11.10.128.3
       = IpAddress: 11.10.128.4
   BGP4-MIB::bgpPeerLocalPort.10.10.1.29
       = INTEGER: 11014
   BGP4-MIB::bgpPeerLocalPort.11.10.128.3
       = INTEGER: 11013
   BGP4-MIB::bgpPeerRemoteAddr.10.10.1.29
       = IpAddress: 10.10.1.29
   BGP4-MIB::bgpPeerRemoteAddr.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgpPeerRemotePort.10.10.1.29
       = INTEGER: 179
   BGP4-MIB::bgpPeerRemotePort.11.10.128.3
       = INTEGER: 179
   BGP4-MIB::bgpPeerRemoteAs.10.10.1.29
       = INTEGER: 2
   BGP4-MIB::bgpPeerRemoteAs.11.10.128.3
       = INTEGER: 65000
   BGP4-MIB::bgpPeerInUpdates.10.10.1.29
       = Counter32: 54
   BGP4-MIB::bgpPeerInUpdates.11.10.128.3
       = Counter32: 5
   BGP4-MIB::bgpPeerOutUpdates.10.10.1.29
       = Counter32: 3
   BGP4-MIB::bgpPeerOutUpdates.11.10.128.3
       = Counter32: 54
   BGP4-MIB::bgpPeerInTotalMessages.10.10.1.29
       = Counter32: 12998
   BGP4-MIB::bgpPeerInTotalMessages.11.10.128.3
       = Counter32: 12949
   BGP4-MIB::bgpPeerOutTotalMessages.10.10.1.29
       = Counter32: 12947
   BGP4-MIB::bgpPeerOutTotalMessages.11.10.128.3
       = Counter32: 12998
   BGP4-MIB::bgpPeerLastError.10.10.1.29
       = Hex-STRING: 00 00
   BGP4-MIB::bgpPeerLastError.11.10.128.3
       = Hex-STRING: 00 00
   BGP4-MIB::bgpPeerFsmEstablishedTransitions.10.10.1.29
       = Counter32: 1
   BGP4-MIB::bgpPeerFsmEstablishedTransitions.11.10.128.3
       = Counter32: 1
   BGP4-MIB::bgpPeerFsmEstablishedTime.10.10.1.29
       = Gauge32: 776416
   BGP4-MIB::bgpPeerFsmEstablishedTime.11.10.128.3
       = Gauge32: 776416
   BGP4-MIB::bgpPeerConnectRetryInterval.10.10.1.29
       = INTEGER: 60
   BGP4-MIB::bgpPeerConnectRetryInterval.11.10.128.3
       = INTEGER: 60
   BGP4-MIB::bgpPeerHoldTime.10.10.1.29
       = INTEGER: 180
   BGP4-MIB::bgpPeerHoldTime.11.10.128.3
       = INTEGER: 180
   BGP4-MIB::bgpPeerKeepAlive.10.10.1.29
       = INTEGER: 60
   BGP4-MIB::bgpPeerKeepAlive.11.10.128.3
       = INTEGER: 60
   BGP4-MIB::bgpPeerHoldTimeConfigured.10.10.1.29
       = INTEGER: 180
   BGP4-MIB::bgpPeerHoldTimeConfigured.11.10.128.3
       = INTEGER: 180
   BGP4-MIB::bgpPeerKeepAliveConfigured.10.10.1.29
       = INTEGER: 60
   BGP4-MIB::bgpPeerKeepAliveConfigured.11.10.128.3
       = INTEGER: 60
   BGP4-MIB::bgpPeerMinASOriginationInterval.10.10.1.29
       = INTEGER: 0
   BGP4-MIB::bgpPeerMinASOriginationInterval.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgpPeerMinRouteAdvertisementInterval.10.10.1.29
       = INTEGER: 0
   BGP4-MIB::bgpPeerMinRouteAdvertisementInterval.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgpPeerInUpdateElapsedTime.10.10.1.29
       = Gauge32: 103451
   BGP4-MIB::bgpPeerInUpdateElapsedTime.11.10.128.3
       = Gauge32: 776416
   BGP4-MIB::bgpIdentifier.0
       = IpAddress: 11.10.128.4
   BGP4-MIB::bgp4PathAttrPeer.10.10.1.21.32.10.10.1.29
       = IpAddress: 10.10.1.29
   BGP4-MIB::bgp4PathAttrPeer.10.10.1.22.32.10.10.1.29
       = IpAddress: 10.10.1.29
   BGP4-MIB::bgp4PathAttrPeer.10.10.1.23.32.10.10.1.29
       = IpAddress: 10.10.1.29
   BGP4-MIB::bgp4PathAttrPeer.10.10.1.29.32.10.10.1.29
       = IpAddress: 10.10.1.29
   BGP4-MIB::bgp4PathAttrPeer.10.10.1.32.32.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgp4PathAttrPeer.10.10.1.33.32.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgp4PathAttrPeer.10.10.1.34.32.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgp4PathAttrPeer.10.10.1.61.32.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgp4PathAttrPeer.10.10.1.62.32.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgp4PathAttrPeer.10.10.2.0.24.10.10.1.29
       = IpAddress: 10.10.1.29
   BGP4-MIB::bgp4PathAttrPeer.10.10.3.0.24.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgp4PathAttrPeer.10.10.6.0.24.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.10.10.1.21.32.10.10.1.29
       = INTEGER: 32
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.10.10.1.22.32.10.10.1.29
       = INTEGER: 32
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.10.10.1.23.32.10.10.1.29
       = INTEGER: 32
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.10.10.1.29.32.10.10.1.29
       = INTEGER: 32
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.10.10.1.32.32.11.10.128.3
       = INTEGER: 32
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.10.10.1.33.32.11.10.128.3
       = INTEGER: 32
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.10.10.1.34.32.11.10.128.3
       = INTEGER: 32
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.10.10.1.61.32.11.10.128.3
       = INTEGER: 32
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.10.10.1.62.32.11.10.128.3
       = INTEGER: 32
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.10.10.2.0.24.10.10.1.29
       = INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.10.10.3.0.24.11.10.128.3
       = INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.10.10.6.0.24.11.10.128.3
       = INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.10.10.1.21.32.10.10.1.29
       = IpAddress: 10.10.1.21
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.10.10.1.22.32.10.10.1.29
       = IpAddress: 10.10.1.22
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.10.10.1.23.32.10.10.1.29
       = IpAddress: 10.10.1.23
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.10.10.1.29.32.10.10.1.29
       = IpAddress: 10.10.1.29
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.10.10.1.32.32.11.10.128.3
       = IpAddress: 10.10.1.32
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.10.10.1.33.32.11.10.128.3
       = IpAddress: 10.10.1.33
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.10.10.1.34.32.11.10.128.3
       = IpAddress: 10.10.1.34
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.10.10.1.61.32.11.10.128.3
       = IpAddress: 10.10.1.61
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.10.10.1.62.32.11.10.128.3
       = IpAddress: 10.10.1.62
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.10.10.2.0.24.10.10.1.29
       = IpAddress: 10.10.2.0
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.10.10.3.0.24.11.10.128.3
       = IpAddress: 10.10.3.0
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.10.10.6.0.24.11.10.128.3
       = IpAddress: 10.10.6.0
   BGP4-MIB::bgp4PathAttrOrigin.10.10.1.21.32.10.10.1.29
       = INTEGER: igp(1)
   BGP4-MIB::bgp4PathAttrOrigin.10.10.1.22.32.10.10.1.29
       = INTEGER: igp(1)
   BGP4-MIB::bgp4PathAttrOrigin.10.10.1.23.32.10.10.1.29
       = INTEGER: igp(1)
   BGP4-MIB::bgp4PathAttrOrigin.10.10.1.29.32.10.10.1.29
       = INTEGER: igp(1)
   BGP4-MIB::bgp4PathAttrOrigin.10.10.1.32.32.11.10.128.3
       = INTEGER: igp(1)
   BGP4-MIB::bgp4PathAttrOrigin.10.10.1.33.32.11.10.128.3
       = INTEGER: igp(1)
   BGP4-MIB::bgp4PathAttrOrigin.10.10.1.34.32.11.10.128.3
       = INTEGER: igp(1)
   BGP4-MIB::bgp4PathAttrOrigin.10.10.1.61.32.11.10.128.3
       = INTEGER: igp(1)
   BGP4-MIB::bgp4PathAttrOrigin.10.10.1.62.32.11.10.128.3
       = INTEGER: igp(1)
   BGP4-MIB::bgp4PathAttrOrigin.10.10.2.0.24.10.10.1.29
       = INTEGER: igp(1)
   BGP4-MIB::bgp4PathAttrOrigin.10.10.3.0.24.11.10.128.3
       = INTEGER: igp(1)
   BGP4-MIB::bgp4PathAttrOrigin.10.10.6.0.24.11.10.128.3
       = INTEGER: igp(1)
   BGP4-MIB::bgp4PathAttrASPathSegment.10.10.1.21.32.10.10.1.29
       = Hex-STRING: 02 01 00 02
   BGP4-MIB::bgp4PathAttrASPathSegment.10.10.1.22.32.10.10.1.29
       = Hex-STRING: 02 01 00 02
   BGP4-MIB::bgp4PathAttrASPathSegment.10.10.1.23.32.10.10.1.29
       = Hex-STRING: 02 01 00 02
   BGP4-MIB::bgp4PathAttrASPathSegment.10.10.1.29.32.10.10.1.29
       = Hex-STRING: 02 01 00 02
   BGP4-MIB::bgp4PathAttrASPathSegment.10.10.1.32.32.11.10.128.3
       = Hex-STRING: 02 01 00 03
   BGP4-MIB::bgp4PathAttrASPathSegment.10.10.1.33.32.11.10.128.3
       = Hex-STRING: 02 01 00 03
   BGP4-MIB::bgp4PathAttrASPathSegment.10.10.1.34.32.11.10.128.3
       = Hex-STRING: 02 01 00 03
   BGP4-MIB::bgp4PathAttrASPathSegment.10.10.1.61.32.11.10.128.3
       = Hex-STRING: 02 02 00 03 00 06
   BGP4-MIB::bgp4PathAttrASPathSegment.10.10.1.62.32.11.10.128.3
       = Hex-STRING: 02 02 00 03 00 06
   BGP4-MIB::bgp4PathAttrASPathSegment.10.10.2.0.24.10.10.1.29
       = Hex-STRING: 02 01 00 02
   BGP4-MIB::bgp4PathAttrASPathSegment.10.10.3.0.24.11.10.128.3
       = Hex-STRING: 02 01 00 03
   BGP4-MIB::bgp4PathAttrASPathSegment.10.10.6.0.24.11.10.128.3
       = Hex-STRING: 02 01 00 03
   BGP4-MIB::bgp4PathAttrNextHop.10.10.1.21.32.10.10.1.29
       = IpAddress: 10.10.1.29
   BGP4-MIB::bgp4PathAttrNextHop.10.10.1.22.32.10.10.1.29
       = IpAddress: 10.10.1.29
   BGP4-MIB::bgp4PathAttrNextHop.10.10.1.23.32.10.10.1.29
       = IpAddress: 10.10.1.29
   BGP4-MIB::bgp4PathAttrNextHop.10.10.1.29.32.10.10.1.29
       = IpAddress: 10.10.1.29
   BGP4-MIB::bgp4PathAttrNextHop.10.10.1.32.32.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgp4PathAttrNextHop.10.10.1.33.32.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgp4PathAttrNextHop.10.10.1.34.32.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgp4PathAttrNextHop.10.10.1.61.32.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgp4PathAttrNextHop.10.10.1.62.32.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgp4PathAttrNextHop.10.10.2.0.24.10.10.1.29
       = IpAddress: 10.10.1.29
   BGP4-MIB::bgp4PathAttrNextHop.10.10.3.0.24.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgp4PathAttrNextHop.10.10.6.0.24.11.10.128.3
       = IpAddress: 11.10.128.3
   BGP4-MIB::bgp4PathAttrMultiExitDisc.10.10.1.21.32.10.10.1.29
       = INTEGER: -1
   BGP4-MIB::bgp4PathAttrMultiExitDisc.10.10.1.22.32.10.10.1.29
       = INTEGER: -1
   BGP4-MIB::bgp4PathAttrMultiExitDisc.10.10.1.23.32.10.10.1.29
       = INTEGER: -1
   BGP4-MIB::bgp4PathAttrMultiExitDisc.10.10.1.29.32.10.10.1.29
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrMultiExitDisc.10.10.1.32.32.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrMultiExitDisc.10.10.1.33.32.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrMultiExitDisc.10.10.1.34.32.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrMultiExitDisc.10.10.1.61.32.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrMultiExitDisc.10.10.1.62.32.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrMultiExitDisc.10.10.2.0.24.10.10.1.29
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrMultiExitDisc.10.10.3.0.24.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrMultiExitDisc.10.10.6.0.24.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrLocalPref.10.10.1.21.32.10.10.1.29
       = INTEGER: -1
   BGP4-MIB::bgp4PathAttrLocalPref.10.10.1.22.32.10.10.1.29
       = INTEGER: -1
   BGP4-MIB::bgp4PathAttrLocalPref.10.10.1.23.32.10.10.1.29
       = INTEGER: -1
   BGP4-MIB::bgp4PathAttrLocalPref.10.10.1.29.32.10.10.1.29
       = INTEGER: -1
   BGP4-MIB::bgp4PathAttrLocalPref.10.10.1.32.32.11.10.128.3
       = INTEGER: -1
   BGP4-MIB::bgp4PathAttrLocalPref.10.10.1.33.32.11.10.128.3
       = INTEGER: -1
   BGP4-MIB::bgp4PathAttrLocalPref.10.10.1.34.32.11.10.128.3
       = INTEGER: -1
   BGP4-MIB::bgp4PathAttrLocalPref.10.10.1.61.32.11.10.128.3
       = INTEGER: -1
   BGP4-MIB::bgp4PathAttrLocalPref.10.10.1.62.32.11.10.128.3
       = INTEGER: -1
   BGP4-MIB::bgp4PathAttrLocalPref.10.10.2.0.24.10.10.1.29
       = INTEGER: -1
   BGP4-MIB::bgp4PathAttrLocalPref.10.10.3.0.24.11.10.128.3
       = INTEGER: -1
   BGP4-MIB::bgp4PathAttrLocalPref.10.10.6.0.24.11.10.128.3
       = INTEGER: -1
   BGP4-MIB::bgp4PathAttrAtomicAggregate.10.10.1.21.32.10.10.1.29
       = INTEGER: lessSpecificRrouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.10.10.1.22.32.10.10.1.29
       = INTEGER: lessSpecificRrouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.10.10.1.23.32.10.10.1.29
       = INTEGER: lessSpecificRrouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.10.10.1.29.32.10.10.1.29
       = INTEGER: lessSpecificRrouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.10.10.1.32.32.11.10.128.3
       = INTEGER: lessSpecificRrouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.10.10.1.33.32.11.10.128.3
       = INTEGER: lessSpecificRrouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.10.10.1.34.32.11.10.128.3
       = INTEGER: lessSpecificRrouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.10.10.1.61.32.11.10.128.3
       = INTEGER: lessSpecificRrouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.10.10.1.62.32.11.10.128.3
       = INTEGER: lessSpecificRrouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.10.10.2.0.24.10.10.1.29
       = INTEGER: lessSpecificRrouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.10.10.3.0.24.11.10.128.3
       = INTEGER: lessSpecificRrouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.10.10.6.0.24.11.10.128.3
       = INTEGER: lessSpecificRrouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAggregatorAS.10.10.1.21.32.10.10.1.29
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.10.10.1.22.32.10.10.1.29
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.10.10.1.23.32.10.10.1.29
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.10.10.1.29.32.10.10.1.29
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.10.10.1.32.32.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.10.10.1.33.32.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.10.10.1.34.32.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.10.10.1.61.32.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.10.10.1.62.32.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.10.10.2.0.24.10.10.1.29
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.10.10.3.0.24.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.10.10.6.0.24.11.10.128.3
       = INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.10.10.1.21.32.10.10.1.29
       = IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.10.10.1.22.32.10.10.1.29
       = IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.10.10.1.23.32.10.10.1.29
       = IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.10.10.1.29.32.10.10.1.29
       = IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.10.10.1.32.32.11.10.128.3
       = IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.10.10.1.33.32.11.10.128.3
       = IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.10.10.1.34.32.11.10.128.3
       = IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.10.10.1.61.32.11.10.128.3
       = IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.10.10.1.62.32.11.10.128.3
       = IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.10.10.2.0.24.10.10.1.29
       = IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.10.10.3.0.24.11.10.128.3
       = IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.10.10.6.0.24.11.10.128.3
       = IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrCalcLocalPref.10.10.1.21.32.10.10.1.29
       = INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.10.10.1.22.32.10.10.1.29
       = INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.10.10.1.23.32.10.10.1.29
       = INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.10.10.1.29.32.10.10.1.29
       = INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.10.10.1.32.32.11.10.128.3
       = INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.10.10.1.33.32.11.10.128.3
       = INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.10.10.1.34.32.11.10.128.3
       = INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.10.10.1.61.32.11.10.128.3
       = INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.10.10.1.62.32.11.10.128.3
       = INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.10.10.2.0.24.10.10.1.29
       = INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.10.10.3.0.24.11.10.128.3
       = INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.10.10.6.0.24.11.10.128.3
       = INTEGER: 100
   BGP4-MIB::bgp4PathAttrBest.10.10.1.21.32.10.10.1.29
       = INTEGER: true(2)
   BGP4-MIB::bgp4PathAttrBest.10.10.1.22.32.10.10.1.29
       = INTEGER: true(2)
   BGP4-MIB::bgp4PathAttrBest.10.10.1.23.32.10.10.1.29
       = INTEGER: true(2)
   BGP4-MIB::bgp4PathAttrBest.10.10.1.29.32.10.10.1.29
       = INTEGER: true(2)
   BGP4-MIB::bgp4PathAttrBest.10.10.1.32.32.11.10.128.3
       = INTEGER: true(2)
   BGP4-MIB::bgp4PathAttrBest.10.10.1.33.32.11.10.128.3
       = INTEGER: true(2)
   BGP4-MIB::bgp4PathAttrBest.10.10.1.34.32.11.10.128.3
       = INTEGER: true(2)
   BGP4-MIB::bgp4PathAttrBest.10.10.1.61.32.11.10.128.3
       = INTEGER: true(2)
   BGP4-MIB::bgp4PathAttrBest.10.10.1.62.32.11.10.128.3
       = INTEGER: true(2)
   BGP4-MIB::bgp4PathAttrBest.10.10.2.0.24.10.10.1.29
       = INTEGER: true(2)
   BGP4-MIB::bgp4PathAttrBest.10.10.3.0.24.11.10.128.3
       = INTEGER: true(2)
   BGP4-MIB::bgp4PathAttrBest.10.10.6.0.24.11.10.128.3
       = INTEGER: true(2)
   BGP4-MIB::bgp4PathAttrUnknown.10.10.1.21.32.10.10.1.29
       = ""
   BGP4-MIB::bgp4PathAttrUnknown.10.10.1.22.32.10.10.1.29
       = ""
   BGP4-MIB::bgp4PathAttrUnknown.10.10.1.23.32.10.10.1.29
       = ""
   BGP4-MIB::bgp4PathAttrUnknown.10.10.1.29.32.10.10.1.29
       = ""
   BGP4-MIB::bgp4PathAttrUnknown.10.10.1.32.32.11.10.128.3
       = ""
   BGP4-MIB::bgp4PathAttrUnknown.10.10.1.33.32.11.10.128.3
       = ""
   BGP4-MIB::bgp4PathAttrUnknown.10.10.1.34.32.11.10.128.3
       = ""
   BGP4-MIB::bgp4PathAttrUnknown.10.10.1.61.32.11.10.128.3
       = ""
   BGP4-MIB::bgp4PathAttrUnknown.10.10.1.62.32.11.10.128.3
       = ""
   BGP4-MIB::bgp4PathAttrUnknown.10.10.2.0.24.10.10.1.29
       = ""
   BGP4-MIB::bgp4PathAttrUnknown.10.10.3.0.24.11.10.128.3
       = ""
   BGP4-MIB::bgp4PathAttrUnknown.10.10.6.0.24.11.10.128.3
       = ""

4.2. NextHop Technologies

   BGP4-MIB::bgpVersion.0 = Hex-STRING: 10
   BGP4-MIB::bgpLocalAs.0 = INTEGER: 201
   BGP4-MIB::bgpPeerIdentifier.10.132.10.14 = IpAddress: 10.132.10.14
   BGP4-MIB::bgpPeerState.10.132.10.14 = INTEGER: established(6)
   BGP4-MIB::bgpPeerAdminStatus.10.132.10.14 = INTEGER: start(2)
   BGP4-MIB::bgpPeerNegotiatedVersion.10.132.10.14 = INTEGER: 4
   BGP4-MIB::bgpPeerLocalAddr.10.132.10.14 = IpAddress: 10.132.10.12
   BGP4-MIB::bgpPeerLocalPort.10.132.10.14 = INTEGER: 1639
   BGP4-MIB::bgpPeerRemoteAddr.10.132.10.14 = IpAddress: 10.132.10.14
   BGP4-MIB::bgpPeerRemotePort.10.132.10.14 = INTEGER: 179
   BGP4-MIB::bgpPeerRemoteAs.10.132.10.14 = INTEGER: 201
   BGP4-MIB::bgpPeerInUpdates.10.132.10.14 = Counter32: 1
   BGP4-MIB::bgpPeerOutUpdates.10.132.10.14 = Counter32: 1
   BGP4-MIB::bgpPeerInTotalMessages.10.132.10.14 = Counter32: 16
   BGP4-MIB::bgpPeerOutTotalMessages.10.132.10.14 = Counter32: 18
   BGP4-MIB::bgpPeerLastError.10.132.10.14 = Hex-STRING: 00 00
   BGP4-MIB::bgpPeerFsmEstablishedTransitions.10.132.10.14 = Counter32:1
   BGP4-MIB::bgpPeerFsmEstablishedTime.10.132.10.14 = Gauge32: 861
   BGP4-MIB::bgpPeerConnectRetryInterval.10.132.10.14 = INTEGER: 4
   BGP4-MIB::bgpPeerHoldTime.10.132.10.14 = INTEGER: 180
   BGP4-MIB::bgpPeerKeepAlive.10.132.10.14 = INTEGER: 60
   BGP4-MIB::bgpPeerHoldTimeConfigured.10.132.10.14 = INTEGER: 180
   BGP4-MIB::bgpPeerKeepAliveConfigured.10.132.10.14 = INTEGER: 60
   BGP4-MIB::bgpPeerMinASOriginationInterval.10.132.10.14 = INTEGER: 1
   BGP4-MIB::bgpPeerMinRouteAdvertisementInterval.10.132.10.14 =
   INTEGER: 1
   BGP4-MIB::bgpPeerInUpdateElapsedTime.10.132.10.14 = Gauge32: 861
   BGP4-MIB::bgpIdentifier.0 = IpAddress: 10.132.10.12
   BGP4-MIB::bgp4PathAttrPeer.223.1.0.0.24.10.132.10.14 = IpAddress:
   10.132.10.14
   BGP4-MIB::bgp4PathAttrPeer.223.2.0.0.24.10.132.10.14 = IpAddress:
   10.132.10.14
   BGP4-MIB::bgp4PathAttrPeer.223.3.0.0.24.10.132.10.14 = IpAddress:
   10.132.10.14
   BGP4-MIB::bgp4PathAttrPeer.223.137.137.0.24.10.132.10.14 = IpAddress:
   10.132.10.14
   BGP4-MIB::bgp4PathAttrPeer.223.137.138.0.24.10.132.10.14 = IpAddress:
   10.132.10.14
   BGP4-MIB::bgp4PathAttrPeer.223.137.139.0.24.10.132.10.14 = IpAddress:
   10.132.10.14
   BGP4-MIB::bgp4PathAttrPeer.223.137.140.0.24.10.132.10.14 = IpAddress:
   10.132.10.14
   BGP4-MIB::bgp4PathAttrPeer.223.137.141.0.24.10.132.10.14 = IpAddress:
   10.132.10.14
   BGP4-MIB::bgp4PathAttrPeer.223.137.142.0.24.10.132.10.14 = IpAddress:
   10.132.10.14
   BGP4-MIB::bgp4PathAttrPeer.223.137.143.0.24.10.132.10.14 = IpAddress:
   10.132.10.14
   BGP4-MIB::bgp4PathAttrPeer.223.137.144.0.24.10.132.10.14 = IpAddress:
   10.132.10.14
   BGP4-MIB::bgp4PathAttrPeer.223.137.145.0.24.10.132.10.14 = IpAddress:
   10.132.10.14
   BGP4-MIB::bgp4PathAttrPeer.223.137.146.0.24.10.132.10.14 = IpAddress:
   10.132.10.14
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.223.1.0.0.24.10.132.10.14 =
   INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.223.2.0.0.24.10.132.10.14 =
   INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.223.3.0.0.24.10.132.10.14 =
   INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.223.137.137.0.24.10.132.10.14 =
   INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.223.137.138.0.24.10.132.10.14 =
   INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.223.137.139.0.24.10.132.10.14 =
   INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.223.137.140.0.24.10.132.10.14 =
   INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.223.137.141.0.24.10.132.10.14 =
   INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.223.137.142.0.24.10.132.10.14 =
   INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.223.137.143.0.24.10.132.10.14 =
   INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.223.137.144.0.24.10.132.10.14 =
   INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.223.137.145.0.24.10.132.10.14 =
   INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefixLen.223.137.146.0.24.10.132.10.14 =
   INTEGER: 24
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.223.1.0.0.24.10.132.10.14 =
   IpAddress: 223.1.0.0
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.223.2.0.0.24.10.132.10.14 =
   IpAddress: 223.2.0.0
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.223.3.0.0.24.10.132.10.14 =
   IpAddress: 223.3.0.0
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.223.137.137.0.24.10.132.10.14 =
   IpAddress: 223.137.137.0
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.223.137.138.0.24.10.132.10.14 =
   IpAddress: 223.137.138.0
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.223.137.139.0.24.10.132.10.14 =
   IpAddress: 223.137.139.0
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.223.137.140.0.24.10.132.10.14 =
   IpAddress: 223.137.140.0
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.223.137.141.0.24.10.132.10.14 =
   IpAddress: 223.137.141.0
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.223.137.142.0.24.10.132.10.14 =
   IpAddress: 223.137.142.0
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.223.137.143.0.24.10.132.10.14 =
   IpAddress: 223.137.143.0
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.223.137.144.0.24.10.132.10.14 =
   IpAddress: 223.137.144.0
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.223.137.145.0.24.10.132.10.14 =
   IpAddress: 223.137.145.0
   BGP4-MIB::bgp4PathAttrIpAddrPrefix.223.137.146.0.24.10.132.10.14 =
   IpAddress: 223.137.146.0
   BGP4-MIB::bgp4PathAttrOrigin.223.1.0.0.24.10.132.10.14 = INTEGER:
   incomplete(3)
   BGP4-MIB::bgp4PathAttrOrigin.223.2.0.0.24.10.132.10.14 = INTEGER:
   incomplete(3)
   BGP4-MIB::bgp4PathAttrOrigin.223.3.0.0.24.10.132.10.14 = INTEGER:
   incomplete(3)
   BGP4-MIB::bgp4PathAttrOrigin.223.137.137.0.24.10.132.10.14 = INTEGER:
   incomplete(3)
   BGP4-MIB::bgp4PathAttrOrigin.223.137.138.0.24.10.132.10.14 = INTEGER:
   incomplete(3)
   BGP4-MIB::bgp4PathAttrOrigin.223.137.139.0.24.10.132.10.14 = INTEGER:
   incomplete(3)
   BGP4-MIB::bgp4PathAttrOrigin.223.137.140.0.24.10.132.10.14 = INTEGER:
   incomplete(3)
   BGP4-MIB::bgp4PathAttrOrigin.223.137.141.0.24.10.132.10.14 = INTEGER:
   incomplete(3)
   BGP4-MIB::bgp4PathAttrOrigin.223.137.142.0.24.10.132.10.14 = INTEGER:
   incomplete(3)
   BGP4-MIB::bgp4PathAttrOrigin.223.137.143.0.24.10.132.10.14 = INTEGER:
   incomplete(3)
   BGP4-MIB::bgp4PathAttrOrigin.223.137.144.0.24.10.132.10.14 = INTEGER:
   incomplete(3)
   BGP4-MIB::bgp4PathAttrOrigin.223.137.145.0.24.10.132.10.14 = INTEGER:
   incomplete(3)
   BGP4-MIB::bgp4PathAttrOrigin.223.137.146.0.24.10.132.10.14 = INTEGER:
   incomplete(3)
   BGP4-MIB::bgp4PathAttrASPathSegment.223.1.0.0.24.10.132.10.14 = ""
   BGP4-MIB::bgp4PathAttrASPathSegment.223.2.0.0.24.10.132.10.14 = ""
   BGP4-MIB::bgp4PathAttrASPathSegment.223.3.0.0.24.10.132.10.14 = ""
   BGP4-MIB::bgp4PathAttrASPathSegment.223.137.137.0.24.10.132.10.14 =
   ""
   BGP4-MIB::bgp4PathAttrASPathSegment.223.137.138.0.24.10.132.10.14 =
   ""
   BGP4-MIB::bgp4PathAttrASPathSegment.223.137.139.0.24.10.132.10.14 =
   ""
   BGP4-MIB::bgp4PathAttrASPathSegment.223.137.140.0.24.10.132.10.14 =
   ""
   BGP4-MIB::bgp4PathAttrASPathSegment.223.137.141.0.24.10.132.10.14 =
   ""
   BGP4-MIB::bgp4PathAttrASPathSegment.223.137.142.0.24.10.132.10.14 =
   ""
   BGP4-MIB::bgp4PathAttrASPathSegment.223.137.143.0.24.10.132.10.14 =
   ""
   BGP4-MIB::bgp4PathAttrASPathSegment.223.137.144.0.24.10.132.10.14 =
   ""
   BGP4-MIB::bgp4PathAttrASPathSegment.223.137.145.0.24.10.132.10.14 =
   ""
   BGP4-MIB::bgp4PathAttrASPathSegment.223.137.146.0.24.10.132.10.14 =
   ""
   BGP4-MIB::bgp4PathAttrNextHop.223.1.0.0.24.10.132.10.14 = IpAddress:
   10.132.10.242
   BGP4-MIB::bgp4PathAttrNextHop.223.2.0.0.24.10.132.10.14 = IpAddress:
   10.132.10.242
   BGP4-MIB::bgp4PathAttrNextHop.223.3.0.0.24.10.132.10.14 = IpAddress:
   10.132.10.242
   BGP4-MIB::bgp4PathAttrNextHop.223.137.137.0.24.10.132.10.14 =
   IpAddress: 10.132.10.242
   BGP4-MIB::bgp4PathAttrNextHop.223.137.138.0.24.10.132.10.14 =
   IpAddress: 10.132.10.242
   BGP4-MIB::bgp4PathAttrNextHop.223.137.139.0.24.10.132.10.14 =
   IpAddress: 10.132.10.242
   BGP4-MIB::bgp4PathAttrNextHop.223.137.140.0.24.10.132.10.14 =
   IpAddress: 10.132.10.242
   BGP4-MIB::bgp4PathAttrNextHop.223.137.141.0.24.10.132.10.14 =
   IpAddress: 10.132.10.242
   BGP4-MIB::bgp4PathAttrNextHop.223.137.142.0.24.10.132.10.14 =
   IpAddress: 10.132.10.242
   BGP4-MIB::bgp4PathAttrNextHop.223.137.143.0.24.10.132.10.14 =
   IpAddress: 10.132.10.242
   BGP4-MIB::bgp4PathAttrNextHop.223.137.144.0.24.10.132.10.14 =
   IpAddress: 10.132.10.242
   BGP4-MIB::bgp4PathAttrNextHop.223.137.145.0.24.10.132.10.14 =
   IpAddress: 10.132.10.242
   BGP4-MIB::bgp4PathAttrNextHop.223.137.146.0.24.10.132.10.14 =
   IpAddress: 10.132.10.242
   BGP4-MIB::bgp4PathAttrMultiExitDisc.223.1.0.0.24.10.132.10.14 =
   INTEGER: -1
   BGP4-MIB::bgp4PathAttrMultiExitDisc.223.2.0.0.24.10.132.10.14 =
   INTEGER: -1
   BGP4-MIB::bgp4PathAttrMultiExitDisc.223.3.0.0.24.10.132.10.14 =
   INTEGER: -1
   BGP4-MIB::bgp4PathAttrMultiExitDisc.223.137.137.0.24.10.132.10.14 =
   INTEGER: -1
   BGP4-MIB::bgp4PathAttrMultiExitDisc.223.137.138.0.24.10.132.10.14 =
   INTEGER: -1
   BGP4-MIB::bgp4PathAttrMultiExitDisc.223.137.139.0.24.10.132.10.14 =
   INTEGER: -1
   BGP4-MIB::bgp4PathAttrMultiExitDisc.223.137.140.0.24.10.132.10.14 =
   INTEGER: -1
   BGP4-MIB::bgp4PathAttrMultiExitDisc.223.137.141.0.24.10.132.10.14 =
   INTEGER: -1
   BGP4-MIB::bgp4PathAttrMultiExitDisc.223.137.142.0.24.10.132.10.14 =
   INTEGER: -1
   BGP4-MIB::bgp4PathAttrMultiExitDisc.223.137.143.0.24.10.132.10.14 =
   INTEGER: -1
   BGP4-MIB::bgp4PathAttrMultiExitDisc.223.137.144.0.24.10.132.10.14 =
   INTEGER: -1
   BGP4-MIB::bgp4PathAttrMultiExitDisc.223.137.145.0.24.10.132.10.14 =
   INTEGER: -1
   BGP4-MIB::bgp4PathAttrMultiExitDisc.223.137.146.0.24.10.132.10.14 =
   INTEGER: -1
   BGP4-MIB::bgp4PathAttrLocalPref.223.1.0.0.24.10.132.10.14 = INTEGER:
   100
   BGP4-MIB::bgp4PathAttrLocalPref.223.2.0.0.24.10.132.10.14 = INTEGER:
   100
   BGP4-MIB::bgp4PathAttrLocalPref.223.3.0.0.24.10.132.10.14 = INTEGER:
   100
   BGP4-MIB::bgp4PathAttrLocalPref.223.137.137.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrLocalPref.223.137.138.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrLocalPref.223.137.139.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrLocalPref.223.137.140.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrLocalPref.223.137.141.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrLocalPref.223.137.142.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrLocalPref.223.137.143.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrLocalPref.223.137.144.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrLocalPref.223.137.145.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrLocalPref.223.137.146.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrAtomicAggregate.223.1.0.0.24.10.132.10.14 =
   INTEGER: lessSpecificRouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.223.2.0.0.24.10.132.10.14 =
   INTEGER: lessSpecificRouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.223.3.0.0.24.10.132.10.14 =
   INTEGER: lessSpecificRouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.223.137.137.0.24.10.132.10.14 =
   INTEGER: lessSpecificRouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.223.137.138.0.24.10.132.10.14 =
   INTEGER: lessSpecificRouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.223.137.139.0.24.10.132.10.14 =
   INTEGER: lessSpecificRouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.223.137.140.0.24.10.132.10.14 =
   INTEGER: lessSpecificRouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.223.137.141.0.24.10.132.10.14 =
   INTEGER: lessSpecificRouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.223.137.142.0.24.10.132.10.14 =
   INTEGER: lessSpecificRouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.223.137.143.0.24.10.132.10.14 =
   INTEGER: lessSpecificRouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.223.137.144.0.24.10.132.10.14 =
   INTEGER: lessSpecificRouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.223.137.145.0.24.10.132.10.14 =
   INTEGER: lessSpecificRouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAtomicAggregate.223.137.146.0.24.10.132.10.14 =
   INTEGER: lessSpecificRouteNotSelected(1)
   BGP4-MIB::bgp4PathAttrAggregatorAS.223.1.0.0.24.10.132.10.14 =
   INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.223.2.0.0.24.10.132.10.14 =
   INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.223.3.0.0.24.10.132.10.14 =
   INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.223.137.137.0.24.10.132.10.14 =
   INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.223.137.138.0.24.10.132.10.14 =
   INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.223.137.139.0.24.10.132.10.14 =
   INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.223.137.140.0.24.10.132.10.14 =
   INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.223.137.141.0.24.10.132.10.14 =
   INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.223.137.142.0.24.10.132.10.14 =
   INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.223.137.143.0.24.10.132.10.14 =
   INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.223.137.144.0.24.10.132.10.14 =
   INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.223.137.145.0.24.10.132.10.14 =
   INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAS.223.137.146.0.24.10.132.10.14 =
   INTEGER: 0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.223.1.0.0.24.10.132.10.14 =
   IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.223.2.0.0.24.10.132.10.14 =
   IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.223.3.0.0.24.10.132.10.14 =
   IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.223.137.137.0.24.10.132.10.14 =
   IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.223.137.138.0.24.10.132.10.14 =
   IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.223.137.139.0.24.10.132.10.14 =
   IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.223.137.140.0.24.10.132.10.14 =
   IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.223.137.141.0.24.10.132.10.14 =
   IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.223.137.142.0.24.10.132.10.14 =
   IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.223.137.143.0.24.10.132.10.14 =
   IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.223.137.144.0.24.10.132.10.14 =
   IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.223.137.145.0.24.10.132.10.14 =
   IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrAggregatorAddr.223.137.146.0.24.10.132.10.14 =
   IpAddress: 0.0.0.0
   BGP4-MIB::bgp4PathAttrCalcLocalPref.223.1.0.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.223.2.0.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.223.3.0.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.223.137.137.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.223.137.138.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.223.137.139.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.223.137.140.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.223.137.141.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.223.137.142.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.223.137.143.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.223.137.144.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.223.137.145.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrCalcLocalPref.223.137.146.0.24.10.132.10.14 =
   INTEGER: 100
   BGP4-MIB::bgp4PathAttrBest.223.1.0.0.24.10.132.10.14 = INTEGER:
   false(1)
   BGP4-MIB::bgp4PathAttrBest.223.2.0.0.24.10.132.10.14 = INTEGER:
   false(1)
   BGP4-MIB::bgp4PathAttrBest.223.3.0.0.24.10.132.10.14 = INTEGER:
   false(1)
   BGP4-MIB::bgp4PathAttrBest.223.137.137.0.24.10.132.10.14 = INTEGER:
   true(2)
   BGP4-MIB::bgp4PathAttrBest.223.137.138.0.24.10.132.10.14 = INTEGER:
   true(2)
   BGP4-MIB::bgp4PathAttrBest.223.137.139.0.24.10.132.10.14 = INTEGER:
   true(2)
   BGP4-MIB::bgp4PathAttrBest.223.137.140.0.24.10.132.10.14 = INTEGER:
   true(2)
   BGP4-MIB::bgp4PathAttrBest.223.137.141.0.24.10.132.10.14 = INTEGER:
   true(2)
   BGP4-MIB::bgp4PathAttrBest.223.137.142.0.24.10.132.10.14 = INTEGER:
   true(2)
   BGP4-MIB::bgp4PathAttrBest.223.137.143.0.24.10.132.10.14 = INTEGER:
   true(2)
   BGP4-MIB::bgp4PathAttrBest.223.137.144.0.24.10.132.10.14 = INTEGER:
   true(2)
   BGP4-MIB::bgp4PathAttrBest.223.137.145.0.24.10.132.10.14 = INTEGER:
   true(2)
   BGP4-MIB::bgp4PathAttrBest.223.137.146.0.24.10.132.10.14 = INTEGER:
   true(2)
   BGP4-MIB::bgp4PathAttrUnknown.223.1.0.0.24.10.132.10.14 = ""
   BGP4-MIB::bgp4PathAttrUnknown.223.2.0.0.24.10.132.10.14 = ""
   BGP4-MIB::bgp4PathAttrUnknown.223.3.0.0.24.10.132.10.14 = ""
   BGP4-MIB::bgp4PathAttrUnknown.223.137.137.0.24.10.132.10.14 = ""
   BGP4-MIB::bgp4PathAttrUnknown.223.137.138.0.24.10.132.10.14 = ""
   BGP4-MIB::bgp4PathAttrUnknown.223.137.139.0.24.10.132.10.14 = ""
   BGP4-MIB::bgp4PathAttrUnknown.223.137.140.0.24.10.132.10.14 = ""
   BGP4-MIB::bgp4PathAttrUnknown.223.137.141.0.24.10.132.10.14 = ""
   BGP4-MIB::bgp4PathAttrUnknown.223.137.142.0.24.10.132.10.14 = ""
   BGP4-MIB::bgp4PathAttrUnknown.223.137.143.0.24.10.132.10.14 = ""
   BGP4-MIB::bgp4PathAttrUnknown.223.137.144.0.24.10.132.10.14 = ""
   BGP4-MIB::bgp4PathAttrUnknown.223.137.145.0.24.10.132.10.14 = ""
   BGP4-MIB::bgp4PathAttrUnknown.223.137.146.0.24.10.132.10.14 = ""

4.3. Redback Networks

   bgpPeerIdentifier.10.12.49.207 = 2.3.4.5
   bgpPeerIdentifier.50.1.1.63 = 2.2.2.63
   bgpPeerIdentifier.155.53.1.235 = 155.53.1.235
   bgpPeerState.10.12.49.207 = established(6)
   bgpPeerState.50.1.1.63 = established(6)
   bgpPeerState.155.53.1.235 = established(6)
   bgpPeerAdminStatus.10.12.49.207 = start(2)
   bgpPeerAdminStatus.50.1.1.63 = start(2)
   bgpPeerAdminStatus.155.53.1.235 = start(2)
   bgpPeerNegotiatedVersion.10.12.49.207 = 4
   bgpPeerNegotiatedVersion.50.1.1.63 = 4
   bgpPeerNegotiatedVersion.155.53.1.235 = 4
   bgpPeerLocalAddr.10.12.49.207 = 10.12.49.122
   bgpPeerLocalAddr.50.1.1.63 = 50.1.1.122
   bgpPeerLocalAddr.155.53.1.235 = 10.12.49.122
   bgpPeerLocalPort.10.12.49.207 = 65455
   bgpPeerLocalPort.50.1.1.63 = 179
   bgpPeerLocalPort.155.53.1.235 = 65456
   bgpPeerRemoteAddr.10.12.49.207 = 10.12.49.207
   bgpPeerRemoteAddr.50.1.1.63 = 50.1.1.63
   bgpPeerRemoteAddr.155.53.1.235 = 155.53.1.235
   bgpPeerRemotePort.10.12.49.207 = 179
   bgpPeerRemotePort.50.1.1.63 = 65529
   bgpPeerRemotePort.155.53.1.235 = 179
   bgpPeerRemoteAs.10.12.49.207 = 200
   bgpPeerRemoteAs.50.1.1.63 = 200
   bgpPeerRemoteAs.155.53.1.235 = 14207
   bgpPeerInUpdates.10.12.49.207 = 1
   bgpPeerInUpdates.50.1.1.63 = 0
   bgpPeerInUpdates.155.53.1.235 = 21176
   bgpPeerOutUpdates.10.12.49.207 = 2
   bgpPeerOutUpdates.50.1.1.63 = 2
   bgpPeerOutUpdates.155.53.1.235 = 2
   bgpPeerInTotalMessages.10.12.49.207 = 16
   bgpPeerInTotalMessages.50.1.1.63 = 2
   bgpPeerInTotalMessages.155.53.1.235 = 21189
   bgpPeerOutTotalMessages.10.12.49.207 = 18
   bgpPeerOutTotalMessages.50.1.1.63 = 5
   bgpPeerOutTotalMessages.155.53.1.235 = 18
   bgpPeerLastError.10.12.49.207 = 00 00
   bgpPeerLastError.50.1.1.63 = 04 00
   bgpPeerLastError.155.53.1.235 = 00 00
   bgpPeerFsmEstablishedTransitions.10.12.49.207 = 2
   bgpPeerFsmEstablishedTransitions.50.1.1.63 = 2
   bgpPeerFsmEstablishedTransitions.155.53.1.235 = 2
   bgpPeerFsmEstablishedTime.10.12.49.207 = 669
   bgpPeerFsmEstablishedTime.50.1.1.63 = 19
   bgpPeerFsmEstablishedTime.155.53.1.235 = 669
   bgpPeerConnectRetryInterval.10.12.49.207 = 120
   bgpPeerConnectRetryInterval.50.1.1.63 = 120
   bgpPeerConnectRetryInterval.155.53.1.235 = 120
   bgpPeerHoldTime.10.12.49.207 = 180
   bgpPeerHoldTime.50.1.1.63 = 180
   bgpPeerHoldTime.155.53.1.235 = 180
   bgpPeerKeepAlive.10.12.49.207 = 60
   bgpPeerKeepAlive.50.1.1.63 = 60
   bgpPeerKeepAlive.155.53.1.235 = 60
   bgpPeerHoldTimeConfigured.10.12.49.207 = 180
   bgpPeerHoldTimeConfigured.50.1.1.63 = 180
   bgpPeerHoldTimeConfigured.155.53.1.235 = 180
   bgpPeerKeepAliveConfigured.10.12.49.207 = 60
   bgpPeerKeepAliveConfigured.50.1.1.63 = 60
   bgpPeerKeepAliveConfigured.155.53.1.235 = 60
   bgpPeerMinASOriginationInterval.10.12.49.207 = 15
   bgpPeerMinASOriginationInterval.50.1.1.63 = 15
   bgpPeerMinASOriginationInterval.155.53.1.235 = 15
   bgpPeerMinRouteAdvertisementInterval.10.12.49.207 = 30
   bgpPeerMinRouteAdvertisementInterval.50.1.1.63 = 30
   bgpPeerMinRouteAdvertisementInterval.155.53.1.235 = 30
   bgpPeerInUpdateElapsedTime.10.12.49.207 = 9
   bgpPeerInUpdateElapsedTime.50.1.1.63 = 19
   bgpPeerInUpdateElapsedTime.155.53.1.235 = 3

   ============================================================
   bgpVersion.0 = 08
   bgpLocalAs.0 = 300
   bgpPeerIdentifier.10.12.49.207 = 2.3.4.5
   bgpPeerIdentifier.50.1.1.63 = 0.0.0.0
   bgpPeerIdentifier.155.53.1.235 = 155.53.1.235
   bgpPeerState.10.12.49.207 = established(6)
   bgpPeerState.50.1.1.63 = connect(2)
   bgpPeerState.155.53.1.235 = established(6)
   bgpPeerAdminStatus.10.12.49.207 = start(2)
   bgpPeerAdminStatus.50.1.1.63 = start(2)
   bgpPeerAdminStatus.155.53.1.235 = start(2)
   bgpPeerNegotiatedVersion.10.12.49.207 = 4
   bgpPeerNegotiatedVersion.50.1.1.63 = 0
   bgpPeerNegotiatedVersion.155.53.1.235 = 4
   bgpPeerLocalAddr.10.12.49.207 = 10.12.49.122
   bgpPeerLocalAddr.50.1.1.63 = 0.0.0.0
   bgpPeerLocalAddr.155.53.1.235 = 10.12.49.122

   bgpPeerLocalPort.10.12.49.207 = 65455
   bgpPeerLocalPort.50.1.1.63 = 0
   bgpPeerLocalPort.155.53.1.235 = 65456
   bgpPeerRemoteAddr.10.12.49.207 = 10.12.49.207
   bgpPeerRemoteAddr.50.1.1.63 = 50.1.1.63
   bgpPeerRemoteAddr.155.53.1.235 = 155.53.1.235
   bgpPeerRemotePort.10.12.49.207 = 179
   bgpPeerRemotePort.50.1.1.63 = 0
   bgpPeerRemotePort.155.53.1.235 = 179
   bgpPeerRemoteAs.10.12.49.207 = 200
   bgpPeerRemoteAs.50.1.1.63 = 200
   bgpPeerRemoteAs.155.53.1.235 = 14207
   bgpPeerInUpdates.10.12.49.207 = 1
   bgpPeerInUpdates.50.1.1.63 = 0
   bgpPeerInUpdates.155.53.1.235 = 21164
   bgpPeerOutUpdates.10.12.49.207 = 2
   bgpPeerOutUpdates.50.1.1.63 = 0
   bgpPeerOutUpdates.155.53.1.235 = 2
   bgpPeerInTotalMessages.10.12.49.207 = 15
   bgpPeerInTotalMessages.50.1.1.63 = 0
   bgpPeerInTotalMessages.155.53.1.235 = 21176
   bgpPeerOutTotalMessages.10.12.49.207 = 17
   bgpPeerOutTotalMessages.50.1.1.63 = 0
   bgpPeerOutTotalMessages.155.53.1.235 = 17
   bgpPeerLastError.10.12.49.207 = 00 00
   bgpPeerLastError.50.1.1.63 = 04 00
   bgpPeerLastError.155.53.1.235 = 00 00
   bgpPeerFsmEstablishedTransitions.10.12.49.207 = 2
   bgpPeerFsmEstablishedTransitions.50.1.1.63 = 1
   bgpPeerFsmEstablishedTransitions.155.53.1.235 = 2
   bgpPeerFsmEstablishedTime.10.12.49.207 = 643
   bgpPeerFsmEstablishedTime.50.1.1.63 = 5326
   bgpPeerFsmEstablishedTime.155.53.1.235 = 643
   bgpPeerConnectRetryInterval.10.12.49.207 = 120
   bgpPeerConnectRetryInterval.50.1.1.63 = 120
   bgpPeerConnectRetryInterval.155.53.1.235 = 120
   bgpPeerHoldTime.10.12.49.207 = 180
   bgpPeerHoldTime.50.1.1.63 = 0
   bgpPeerHoldTime.155.53.1.235 = 180
   bgpPeerKeepAlive.10.12.49.207 = 60
   bgpPeerKeepAlive.50.1.1.63 = 0
   bgpPeerKeepAlive.155.53.1.235 = 60
   bgpPeerHoldTimeConfigured.10.12.49.207 = 180
   bgpPeerHoldTimeConfigured.50.1.1.63 = 180
   bgpPeerHoldTimeConfigured.155.53.1.235 = 180
   bgpPeerKeepAliveConfigured.10.12.49.207 = 60
   bgpPeerKeepAliveConfigured.50.1.1.63 = 60
   bgpPeerKeepAliveConfigured.155.53.1.235 = 60
   bgpPeerMinASOriginationInterval.10.12.49.207 = 15
   bgpPeerMinASOriginationInterval.50.1.1.63 = 15
   bgpPeerMinASOriginationInterval.155.53.1.235 = 15
   bgpPeerMinRouteAdvertisementInterval.10.12.49.207 = 30
   bgpPeerMinRouteAdvertisementInterval.50.1.1.63 = 30
   bgpPeerMinRouteAdvertisementInterval.155.53.1.235 = 30
   bgpPeerInUpdateElapsedTime.10.12.49.207 = 43
   bgpPeerInUpdateElapsedTime.50.1.1.63 = 5506
   bgpPeerInUpdateElapsedTime.155.53.1.235 = 0
   bgpIdentifier.0 = 14.1.1.1
   bgp4PathAttrPeer.1.2.3.0.24.10.12.49.207 = 10.12.49.207
   bgp4PathAttrPeer.4.4.4.122.32.0.0.0.0 = 0.0.0.0
   bgp4PathAttrPeer.6.8.0.0.20.155.53.1.235 = 155.53.1.235
   bgp4PathAttrIpAddrPrefixLen.1.2.3.0.24.10.12.49.207 = 24
   bgp4PathAttrIpAddrPrefixLen.4.4.4.122.32.0.0.0.0 = 32
   bgp4PathAttrIpAddrPrefixLen.6.8.0.0.20.155.53.1.235 = 20
   bgp4PathAttrIpAddrPrefix.1.2.3.0.24.10.12.49.207 = 1.2.3.0
   bgp4PathAttrIpAddrPrefix.4.4.4.122.32.0.0.0.0 = 4.4.4.122
   bgp4PathAttrIpAddrPrefix.6.8.0.0.20.155.53.1.235 = 6.8.0.0
   bgp4PathAttrOrigin.1.2.3.0.24.10.12.49.207 = igp(1)
   bgp4PathAttrOrigin.4.4.4.122.32.0.0.0.0 = igp(1)
   bgp4PathAttrOrigin.6.8.0.0.20.155.53.1.235 = igp(1)
   bgp4PathAttrASPathSegment.1.2.3.0.24.10.12.49.207 = 02 01 00 00 00 c8
   bgp4PathAttrASPathSegment.4.4.4.122.32.0.0.0.0 =
   bgp4PathAttrASPathSegment.6.8.0.0.20.155.53.1.235 =
   02 05  00 00   37 7f  00 00    0f 68  00 00   0b 62  00 00
   02 9c  00 00   05 af
   bgp4PathAttrNextHop.1.2.3.0.24.10.12.49.207 = 10.12.49.207
   bgp4PathAttrNextHop.4.4.4.122.32.0.0.0.0 = 0.0.0.0
   bgp4PathAttrNextHop.6.8.0.0.20.155.53.1.235 = 155.53.1.235
   bgp4PathAttrMultiExitDisc.1.2.3.0.24.10.12.49.207 = 0
   bgp4PathAttrMultiExitDisc.4.4.4.122.32.0.0.0.0 = 0
   bgp4PathAttrMultiExitDisc.6.8.0.0.20.155.53.1.235 = 0
   bgp4PathAttrLocalPref.1.2.3.0.24.10.12.49.207 = 100
   bgp4PathAttrLocalPref.4.4.4.122.32.0.0.0.0 = 100
   bgp4PathAttrLocalPref.6.8.0.0.20.155.53.1.235 = 100
   bgp4PathAttrAtomicAggregate.1.2.3.0.24.10.12.49.207 =
      lessSpecificRouteSelected(2)
   bgp4PathAttrAtomicAggregate.4.4.4.122.32.0.0.0.0 =
      lessSpecificRouteSelected(2)
   bgp4PathAttrAtomicAggregate.6.8.0.0.20.155.53.1.235 =
      lessSpecificRouteSelected(2)
   bgp4PathAttrAggregatorAS.1.2.3.0.24.10.12.49.207 = 0
   bgp4PathAttrAggregatorAS.4.4.4.122.32.0.0.0.0 = 0
   bgp4PathAttrAggregatorAS.6.8.0.0.20.155.53.1.235 = 0
   bgp4PathAttrAggregatorAddr.1.2.3.0.24.10.12.49.207 = 0.0.0.0
   bgp4PathAttrAggregatorAddr.4.4.4.122.32.0.0.0.0 = 0.0.0.0
   bgp4PathAttrAggregatorAddr.6.8.0.0.20.155.53.1.235 = 0.0.0.0
   bgp4PathAttrCalcLocalPref.1.2.3.0.24.10.12.49.207 = 100
   bgp4PathAttrCalcLocalPref.4.4.4.122.32.0.0.0.0 = 100
   bgp4PathAttrCalcLocalPref.6.8.0.0.20.155.53.1.235 = 100
   bgp4PathAttrBest.1.2.3.0.24.10.12.49.207 = true(2)
   bgp4PathAttrBest.4.4.4.122.32.0.0.0.0 = true(2)
   bgp4PathAttrBest.6.8.0.0.20.155.53.1.235 = true(2)
   bgp4PathAttrUnknown.1.2.3.0.24.10.12.49.207 =
   bgp4PathAttrUnknown.4.4.4.122.32.0.0.0.0 =
   bgp4PathAttrUnknown.6.8.0.0.20.155.53.1.235 =

5. Вопросы безопасности

В этом документе не рассматриваются вопросы безопасности.

6. Благодарности

Благодарим Russ White (Cisco), Sundar Ramachandran (Cisco), Enke Chen (Redback), Jenny (Redback), Sharon Chisolm (Nortel), Jeff Haas (NextHop), Shane Wright (NextHop) за ответы на вопросы. Отдельные благодарности Jeff Haas за его “раскопки” по вопросам инициализации и сброса счетчиков, а также Bert Wijnen за руководство.

7. Нормативные документы

[RFC1657] Willis, S., Burruss, J., and J. Chu, «Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2», RFC 1657, July 1994.

[RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[RFC4274] Haas, J. and S. Hares, Eds., «Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4)», RFC 4274, January 2006.

Адреса авторов

Susan Hares

NextHop Technologies

825 Victors Way, Suite 100

Ann Arbor, MI 48108

Phone: 734-222-1600

EMail: skh@nexthop.com

David Hares

Hickory Hill Consulting

7453 Hickory Hill

Saline, MI 48176

EMail: dhares@hickoryhill-consulting.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

1Simple Network Management Protocol – простой протокол сетевого управления.

2Redback поддерживат уведомление только для перехода из состояния Established в состояние Idle.

3Internetwork Operating System




RFC 4274 BGP-4 Protocol Analysis

Network Working Group                                       D. Meyer
Request for Comments: 4274                                  K. Patel
Category: Informational                                Cisco Systems
                                                        January 2006

Анализ протокола BGP-4

BGP-4 Protocol Analysis

PDF

Статус документа

В этом документе содержится информация для сообщества Internet. Документ не задает каких-либо стандартов Internet. Допускается свободное распространение документа.

Авторские права

Copyright (C) The Internet Society (2006).

Тезисы

Целью этого отчета является документирование того, как требования для публикации протоколов маршрутизации в качестве Internet Draft Standard были удовлетворены для протокола BGP-41.

Этот документ удовлетворяет требованиям ко «второму отчету»2, описанным в параграфе 6.0 документа RFC 1264. Для удовлетворения требований данный документ дополняет RFC 1774 и резюмирует основные свойства BGP-4, а также анализирует протокол с точки зрения масштабирования и производительности.

Оглавление

Исключено из версии HTML

1. Введение

BGP-4 представляет собой протокол маршрутизации между автономными системами, созданный для сетей TCP/IP. Версия 1 протокола BGP была опубликована в [RFC1105]. После этого были разработаны версии BGP с номерами 2, 3 и 4. Версия 2 была документирована в [RFC1163], версия 3 – в [RFC1267], а версия 4 – в [BGP4] (четвертая версия протокола BGP далее будет обозначаться просто BGP). Отличия между версиями протокола рассмотрены в Приложении A документа [BGP4]. Возможные применения BGP в сети Internet описаны в документе [RFC1772].

BGP поддерживает бесклассовую междоменную маршрутизацию (CIDR3) [RFC1519]. Поскольку ранние версии BGP не поддерживали CIDR, они признаны устаревшими и непригодными для использования в современной сети Internet.

Целью этого отчета является документирование того, как требования для публикации протоколов маршрутизации в качестве Internet Draft Standard были удовлетворены для протокола BGP-4.

Этот документ удовлетворяет требованиям ко «второму отчету», описанным в параграфе 6.0 документа RFC 1264. Для удовлетворения требований данный документ дополняет RFC 1774 и резюмирует основные свойства BGP-4, а также анализирует протокол с точки зрения масштабирования и производительности.

2. Основные свойства и алгоритмы BGP

В этой главе кратко рассматриваются ключевые функции и алгоритмы протокола BGP. BGP представляет собой протокол маршрутизации между автономными системами; он разработан для использования в среде, включающей множество автономных систем (АС). BGP предполагает, что маршрутизация внутри автономных систем осуществляется с помощью протоколов внутридоменной маршрутизации. BGP также предполагает, что пакеты данных маршрутизируются от отправителя в направлении получателя независимо от отправителя. BGP не делает предположений о протоколах внутридоменной маршрутизации, используемых в различных АС. В частности, BGP не требует от всех автономных систем использования одного протокола внутридоменной маршрутизации (т. e., протокола внутренней маршрутизации или IGP4).

В заключение отметим, что BGP является реальным протоколом междоменной маршрутизации и, в качестве такового, не вносит ограничений на топологию соединений между автономными системами. Информации, передаваемой посредством BGP, достаточно для построения графа связности автономных систем, из которого могут быть удалены маршрутные петли и к которому могут быть применены многочисленные правила политики маршрутизации на уровне автономной системы.

2.1. Основные свойства

Ключевыми свойствами протокола являются способ записи (нотация) атрибутов пути и агрегирование NLRI5.

Атрибуты пути обеспечивают BGP гибкость и расширяемость. Эти атрибуты могут быть общеизвестными (well-known), обязательными или необязательными. Использование дополнительных атрибутов обеспечивает возможность проведения экспериментов, которые могут затрагивать группу маршрутизаторов BGP, не влияя на остальную часть Internet. Новые дополнительные атрибуты могут добавляться практически так же, как добавляются опции для протоколов (например, Telnet [RFC854]).

Одним из наиболее важных атрибутов пути является AS_PATH6. По мере перемещения информации о доступности через Internet к этим данным (AS_PATH) добавляется список автономных систем, через которые информация проходит. В результате этого добавления формируется атрибут AS_PATH. Использование AS_PATH обеспечивает простой способ удаления петель в маршрутной информации. В дополнение к этому AS_PATH является мощным и универсальным механизмом маршрутизации на основе правил.

BGP расширяет возможности AS_PATH путем включения наборов автономных систем, а также списков АС с помощью атрибута AS_SET. Расширенный формат позволяет сгенерированным объединенным (aggregate) маршрутам передавать информацию о пути из более специфичных маршрутов, использованных для агрегирования. Следует отметить, однако, что на момент создания этого документа атрибут AS_SET достаточно редко использовался в Internet [ROUTEVIEWS].

2.2. Алгоритмы BGP

Алгоритм, используемый BGP, не является в чистом виде ни алгоритмом на базе «векторов удаления» (distance vector algorithm), ни алгоритмом на основе состояний каналов (link state algorithm). Вместо этого протокол использует модифицированный алгоритм distance vector, который называют алгоритмом Path Vector7. Этот алгоритм использует информацию о пути для того, чтобы избавиться от проблем, присущих алгоритму distance vector. Каждый маршрут BGP объединяет в себе информацию об адресате с информацией о пути к нему. Информация о пути (ее называют еще информацией AS_PATH) сохраняется в атрибутах AS_PATH. Эта информация помогает BGP детектировать петли AS, позволяя в результате узлам BGP выбирать маршруты без петель.

BGP использует стратегию нарастающих обновлений для снижения расхода полосы каналов и процессорного времени. Таким образом, после начального обмена полной маршрутной информацией пара маршрутизаторов BGP обменивается между собой только данными об изменении этой информации. Такая стратегия нарастающих обновлений требует использования надежного транспорта между парами маршрутизаторов BGP для обеспечения корректной работы. BGP решает эту задачу за счет использования надежного транспорта TCP.

В дополнение к нарастающим обновлениям BGP добавил концепцию агрегирования (объединения) маршрутов так, что информация о группе адресатов, использующих иерархическое распределение адресов (например, CIDR), может быть агрегирована и передана как одно значение NLRI.

В заключение отметим, что BGP является самодостаточным протоколом, т. е., BGP задает обмен маршрутной информацией как между узлами BGP в разных автономных системах, так и между узлами BGP одной АС.

2.3. Машина конечных состояний BGP (FSM)

Машина конечных состояний BGP FSM8 представляет собой набор правил, которые применяются к указанным в конфигурации партнерам BGP для операций BGP. Реализация BGP требует, чтобы узел BGP присоединялся к порту TCP с номером 179 и прослушивал его для восприятия всех новых соединений BGP от своих партнеров. Машина конечных состояний BGP должна инициализироваться и поддерживаться для каждого нового входящего или исходящего соединения. Однако в стабильном (установившемся) состоянии поддерживается только один экземпляр BGP FSM для каждого соединения.

В течение коротких периодов времени возможны ситуации, когда узел BGP может иметь входящее и исходящее соединение с одним партнером. Это приводит к созданию двух разных BGP FSM для одного партнера (вместо одной). Для решения этой проблемы используются правила разрешения конфликтов в соединениях BGP, определенные в спецификации [BGP4].

Состояния BGP FSM перечислены ниже.

IDLE: в этом состоянии узел BGP отвергает все входящие соединения.

CONNECT: в этом состоянии узел BGP ожидает завершения процедуры организации соединения TCP.

ACTIVE: в этом состоянии узел BGP пытается обрести партнера путем прослушивания и восприятия соединений TCP.

OPENSENT: узел BGP ожидает сообщения OPEN от своего партнера.

OPENCONFIRM: узел BGP ожидает от своего партнера сообщения KEEPALIVE или NOTIFICATION.

ESTABLISHED: соединение BGP организовано и узел обменивается с партнером сообщениями UPDATE, NOTIFICATION и KEEPALIVE.

Существует множество событий BGP, происходящих в перечисленных выше состояниях BGP FSM для партнеров BGP. Поддержка этих событий может быть обязательной или опциональной. События управляются логикой протокола, являющейся частью BGP, или действиями оператора через интерфейс управления протокола BGP.

События BGP делятся на несколько типов – дополнительные события (Optional event), связанные с необязательными атрибутами сессии (Optional Session attribute), административные события (Administrative Event), события, связанные с таймерами (Timer Event), события, связанные с соединениями TCP (TCP Connection-based Event), и события, связанные с сообщениями BGP (BGP Message-based Event). Детальное описание FSM и событий BGP приведено в документе [BGP4].

3. Возможности BGP

Механизм BGP capability [RFC3392] обеспечивает простой и гибкий способ расширения возможностей протокола. В частности, этот механизм позволяет узлу BGP анонсировать своим партнерам в процессе организации соединения различные дополнительные возможности, поддерживаемые этим узлом, и получать аналогичную информацию от партнеров. Благодаря этому в базовый протокол BGP включены только необходимые функции и обеспечивается гибкий механизм согласования расширенных функций.

4. Постоянные осцилляции партнеров BGP

При обнаружении ошибок в соединении с партнером узел BGP разрывает соответствующее соединение и переводит FSM в состояние IDLE. Для повторной организации соединения с партнером узлу BGP требуется событие Start. Если ошибка сохраняется, а узел BGP генерирует событие Start автоматически, это может привести повторяющимся сменам маршрутов (flapping). Хотя в большинстве реализации BGP поддерживаются механизмы подавления осцилляций, методы подавления устойчивых осцилляций выходят за пределы базовой спецификации BGP.

5. Рекомендации разработчикам

Устойчивая к ошибкам реализация BGP должна быть достаточно “консервативной в работе”. Это значит, что при ограниченном числе префиксов может обеспечиваться устойчивость к произвольно высокому уровню изменчивости маршрута. Высокий уровень изменчивости не должен оказывать значительного влияния на время схождения при спорадических изменениях стабильных в общем случае маршрутов.

Устойчивая к ошибкам реализация BGP должна обладать следующими характеристиками:

  1. Способность работать при почти произвольно высоком уровне изменчивости маршрутов (route flap) без потери связи с партнером (отказа от передачи сообщений keepalive) или потери партнерских отношений (adjacency) для других протоколов в результате высокой загрузки BGP.
  2. Нестабильность подмножества маршрутов не должна оказывать влияния на анонсирование маршрутов и пересылку пакетов, связанные с множеством стабильных маршрутов.
  3. Нестабильность не должна возникать в результате наличия партнеров с высоким уровнем нестабильности или иной скоростью процессора, а также в результате нагрузки, воздействующей на скорость обработки маршрутов. Такие нестабильные партнеры не должны оказывать существенного влияния на время схождения для стабильных в общем случае маршрутов.

Существует множество устойчивых к ошибкам реализаций BGP. Создание такой реализации является нетривиальной, но достижимой задачей.

6. Производительность и масштабируемость BGP

В этой главе рассматриваются вопросы загрузки полосы каналов, памяти маршрутизатора и ресурсов процессора для работы BGP в нормальных условиях. В частности рассматриваются вопросы масштабирования BGP и ограничения этого протокола.

6.1. Использование полосы канала и ресурсов процессора

Непосредственно после организации соединения BGP партнеры обмениваются полными наборами маршрутной информации. Если обозначить общее число маршрутов в Internet N, все атрибуты путей (для всех N маршрутов), полученных от партнера, — A и предположить, что сети равномерно распределены между автономными системами, максимальная полоса, расходуемая на первоначальный обмен данными между парой партнеров BGP (P) составит

BW = O((N + A) * P)

При разработке BGP-4 одной из задач было снижение размера множества записей NLRI, которые будут передаваться между граничными маршрутизаторами. Схема агрегирования, определенная в [RFC1519], описывает объединение маршрутов провайдерами, повсеместно используемое сегодня в сети Internet.

Преимущества, достигнутые в результате анонсирования небольшого числа крупных агрегированных блоков (взамен множества более мелких блоков по классам сетей), сложно оценить с точки зрения экономии полосы. Если мы просто будем перечислять все компоненты агрегированных блоков, как сети того или иного класса, такое рассмотрение не будет учитывать неиспользуемое адресное пространство, зарезервированное для будущего расширения сети. Более эффективным показателем успеха схемы агрегирования BGP является сравнение числа записей NLRI в современной сети Internet (многосвязной в глобальном масштабе) со скоростью роста числа маршрутов до внедрения BGP.

На момент подготовки этого документа полный набор внешних маршрутов, передаваемых с использованием BGP, включал приблизительно 134000 записей [ROUTEVIEWS].

6.1.1. Загрузка процессора (CPU)

Важной особенностью протокола BGP является то, что расход процессорного времени определяется только стабильностью сети, поскольку при любом изменении происходит обмен сообщениями BGP UPDATE. Если сеть BGP стабильна, все маршрутизаторы BGP в этой сети будут находиться в устойчивом состоянии. В этом случае расход полосы каналов и ресурсов процессора, связанный с работой BGP, будет обусловлен только передачей сообщений BGP KEEPALIVE. Сообщения KEEPALIVE передаются только между партнерами. Предлагаемый интервал обмена такими сообщениями составляет 30 секунд. Сообщения KEEPALIVE достаточно малы (19 октетов) и практически не требуют обработки. В результате расход полосы на передачу сообщений KEEPALIVE составляет около 5 бит/сек. Практика показывает, что связанная с этими сообщениями дополнительная нагрузка (в терминах расхода полосы и процессорного времени), пренебрежимо мала.

В периоды нестабильности BGP-маршрутизаторы в сети генерируют обновления маршрутной информации и обмениваются этими обновлениями с помощью сообщений BGP UPDATE. Максимальная дополнительная нагрузка возникает в тех случаях, когда каждое сообщение UPDATE содержит информацию только для одной сети. Следует отметить, что на практике изменения маршрутов локализованы относительно атрибутов пути (т. е., изменяемые маршруты имеют общие атрибуты пути). В таких случаях информацию для множества сетей можно передать в одном сообщении UPDATE, что приведет к существенному снижению расхода полосы (см. Приложение F.1 к документу [BGP4]).

6.1.2. Требования к памяти

Для оценки максимального расхода памяти при работе BGP обозначим общее число сетей в Internet, как N, среднее значение AS distance (количество автономных систем) на пути через Internet, как M, а общее число уникальных путей (AS path), как A. Максимальный расход памяти (MR) может составить

MR = O(N + (M * A))

Поскольку значение M (AS distance) является медленно возрастающей функцией уровня связности Internet, для практических задач наибольший размер потребной памяти имеет порядок произведения общего числа сетей в Internet на число партнеров локальной системы. Ожидается, что общее число сетей в Internet будет расти гораздо быстрее, нежели среднее число соседей маршрутизатора. В результате расход памяти для работы BGP будет линейно связан с общим числом сетей в Internet.

Приведенная ниже таблица показывает типовые требования к оперативной памяти для маршрутизатора, поддерживающего BGP. Среднее число маршрутов, анонсируемых каждым партнером обозначено как N, общее число уникальных AS path — A, среднее число AS на пути через Internet (AS distance) — M (дистанция на уровне автономных систем задается числом AS), число октетов, требуемых для сохранения одной сети, — R, а число байтов, требуемых для сохранения одной AS в AS path — P. Предполагается, что каждая сеть представлена 4 байтами, каждая AS – двумя и каждая сеть достижима через некоторую часть полного множества узлов (число узлов BGP на сеть). Для оценки объема требуемой памяти используется формула

MR = (((N * R) + (M * A) * P) * S)
Число сетей
(N)
Среднее число AS на пути
(M)
Число AS path
(A)
Число узлов BGP на сеть
(P)
Расход памяти
(MR)

100000

20

3000

20

10400000

100000

20

15000

20

20000000

120000

10

15000

100

78000000

140000

15

20000

100

116000000

При анализе требований BGP к памяти мы фокусировались на размере таблицы BGP RIB, игнорируя детали реализации. В частности, мы получили значения верхней границы размера таблицы BGP RIB. Например, в период создания этого документа таблица BGP RIB в типовом магистральном маршрутизаторе содержала порядка 120 000 записей. Основываясь на этом значении можно задаться вопросом о возможности создания маршрутизатора для работы с таблицей, содержащей 1 000 000 записей. Очевидно, что ответ на этот вопрос зависит от реализации BGP. Устойчивая к ошибкам реализация BGP с разумным расходованием памяти и ресурсов процессора должна обеспечивать масштабирование до такого уровня.

7. Средства задания политики BGP и их подводные камни

BGP отличается от других распространенных протоколов маршрутизации IP тем, что картина маршрутизации определяется с использованием развитой семантики правил маршрутизации (routing policy). Хотя правила маршрутизации BGP являются одним из основных вопросов, которые должны принимать во внимание сетевые операторы, важно отметить, что языки и методы задания правил маршрутизации BGP не являются частью спецификации протокола (пример языка описания политики вы найдете в [RFC2622]). Спецификация BGP включает несколько явных и неявных ограничений для языков описания правил. Такие языки обычно создаются разработчиками и развиваются в процессе взаимодействия с сетевыми инженерами в среде с нехваткой независимых от разработчиков стандартов.

Сложность типовых конфигураций BGP (по крайней мере в сетях провайдеров) неуклонно возрастает. Производители маршрутизаторов зачастую предлагают сотни специальных команд для настройки BGP и эти наборы команд продолжают расширяться. Например группы BGP (BGP community) [RFC1997] позволяют создавать правила со специальными тегами маршрутов, которые могут использоваться другими маршрутизаторами BGP. Многие провайдеры позволяют своим заказчикам (а иногда и партнерам) использовать группы (community) для задания области действия и предпочтений. В связи с этим написание конфигурации BGP включает все больше аспектов, связанных с программированием. Это позволяет операторам кодировать сложные правила для того, чтобы учесть множество непредусмотренных ситуаций и обеспечивает возможность экспериментов с правилами маршрутизации. Такая гибкость правил является одной из основных причин того, что протокол BGP так хорошо подходит для использования в коммерческой среде сегодняшней сети Internet.

Однако широкие возможности создания правил имеют и теневую сторону, которую не всегда принимают во внимание. В частности, можно создавать локальные правила, которые будут приводить к расхождению (divergence) и другим глобальным аномалиям в маршрутизации (таким, как непреднамеренная неопределенность маршрутов). Если взаимодействующие правила, которые вызывают такие аномалии, определены в различных AS, это может приводить к возникновению весьма сложных в обнаружении и исправлении аномалий. В следующих параграфах будут описаны два таких случая, связанных с существованием (или нехваткой) стабильной картины маршрутизации.

7.1. Существование уникальной стабильной маршрутизации

Легко создать набор правил, для которого BGP не сможет гарантировать уникальность стабильной картины маршрутизации. Пример этого приводится ниже. Рассмотрим 4 автономных системы AS1, AS2, AS3 и AS4. AS1 и AS2 являются партнерами и обеспечивают транзит для AS3 и AS4, соответственно. Предположим, что AS3 обеспечивает транзит для AS4 (в этом случае AS3 является пользователем AS1, а AS4 – многодомным пользователем AS3 и AS2). AS4 может пожелать использовать канал в AS3 в качестве резервного и передать AS3 значение community, задающее для AS3 более низкий уровень предпочтения, нежели для маршрутов через AS1. Схема такой маршрутизации с резервированием показана на рисунке.

              AS1 ------> AS2
              /|\          |
               |           |
               |           |
               |          \|/
              AS3 ------- AS4

Канал AS3-AS4 должен в этой схеме использоваться лишь в тех случаях, когда соединение AS2-AS4 перестает работать (для исходящего трафика AS4 просто делает маршруты, полученные от AS2, более предпочтительными). Такое решение повсеместно используется в современной сети Internet. Отметим, однако, что в данной конфигурации имеется и другое стабильное решение, показанное на рисунке.

AS1 ------- AS2
 |           |
 |           |
 |           |
\|/         \|/
AS3 ------> AS4

В этом случае AS3 не транслирует группу «depref my route9«, полученную от AS4 в группу «depref my route» для AS1. Следовательно, если AS1 “слышит” маршрут в AS4 через AS3, она будет предпочитать этот маршрут (поскольку AS3 является заказчиком). Такое состояние может быть достигнуто, например, в результате инициирования “корректного” резервного маршрута с последующим обрывом и восстановлением сеанса BGP между AS2-AS4. В общем случае у BGP нет оснований для того, чтобы предпочесть “запланированный” вариант перед “аномальным”. В результате выбор картины маршрутизации будет зависеть от непредсказуемого порядка обмена сообщениями BGP.

Хотя этот пример достаточно прост, многие операторы могут не понимать, что источником проблем является неожиданный вариант взаимодействия правил BGP в автономных системах, который может приводить к существованию множества стабильных вариантов маршрутизации. В реальной сети Internet взаимодействие правил может оказаться значительно более сложным. Мы предполагаем, что описанные аномалии будут возникать более часто по мере того, как будут появляться новые способы задания правил маршрутизации BGP. Например, расширенные группы (extended community) обеспечивают дополнительную гибкость передачи сигнальной информации внутри AS и между автономными системами, нежели обычные группы [RFC1997]. В то же время использование групп сетевыми операторами постоянно расширяется для решения задач управления междоменным трафиком.

7.2. Существование стабильной маршрутизации

Можно создать набор правил, для которого BGP не сможет гарантировать наличие стабильной картины маршрутизации (или, хуже того, любая картина маршрутизации будет стабильной). Например, в [RFC3345] описано несколько сценариев, которые ведут к осцилляциям маршрутов, связанным с использованием атрибута MED (Multi-Exit Discriminator). Осцилляции маршрутов будут возникать в BGP, когда набор правил не дает решения. Т. е., при отсутствии стабильной картины маршрутизации, удовлетворяющей заданному набору правил, BGP не имеет выбора, но пытается найти его. В дополнение к этому даже при наличии для данной конфигурации BGP стабильной картины маршрутизации, протокол может оказаться неспособным найти эту картину. В результате BGP может пойти по “узкой дорожке” не приводящей к решению.

Дивергенция10 протокола, однако, не является проблемой, связанной только с использованием атрибута MED. Такая ситуация может возникать и в тех случаях, когда не используется атрибут MED. Следовательно, как при непреднамеренном индетерминизме, описанном выше, этот тип дивергенции является непредусмотренным следствием “мягкого” характера языков описания правил BGP.

8. Применимость

В этом параграфе мы рассмотрим среды, для которых протокол BGP хорошо подходит, и среды, для которых он не подходит. Ответ на этот вопрос частично дается в главе 2 спецификации BGP [BGP4]11:

«Для того чтобы охарактеризовать набор решений, которые могут быть реализованы с использованием BGP, следует принять правило, по которому узел BGP может анонсировать узлам-партнерам (peer) в соседних AS только те маршруты, которые этот узел использует сам. Это правило отражает парадигму поэтапной (hop-by-hop) маршрутизации, используемую в сети Internet для большинства случаев. Отметим, что некоторые правила не могут поддерживаться в рамках парадигмы «hop-by-hop» и, следовательно, требуется использовать другие методы маршрутизации (такие, как source routing). Например, BGP не позволяет AS передавать в соседнюю AS информацию, показывающую маршрут, отличающийся от того, который будет использоваться для трафика, происходящего из соседней AS. С другой стороны, BGP может поддерживать любые правила, соответствующие парадигме поэтапной маршрутизации. Поскольку в современной сети Internet используется только парадигма поэтапной маршрутизации и BGP может поддерживать любые правила, соответствующие этой парадигме, протокол BGP очень распространен для маршрутизации между AS в современной сети Internet.»

Одной из важнейших особенностей BGP является то, что протокол включает только базовый набор функций, обеспечивая в то же время гибкий механизм расширения функциональности. Например, механизм BGP capabilities обеспечивает простой и гибкий метод добавления новых возможностей для протокола. Наконец, в силу того, что протокол BGP был разработан с учетом обеспечения гибкости и расширяемости, новые и/или изменившиеся требования могут быть удовлетворены с использованием существующих механизмов.

Протокол BGP хорошо подходит для решения задач маршрутизации между автономными системами в любой сети, работающей на основе IP [RFC791] и использующей парадигму поэтапной (hop-by-hop) маршрутизации.

9. Благодарности

Благодарим Paul Traina за работу над предыдущими версиями этого документа. Elwyn Davies, Tim Griffin, Randy Presuhn, Curtis Villamizar и Atanu Ghosh также внесли много значимых поправок на этапах подготовки документа.

10. Вопросы безопасности

BGP обеспечивает для защиты гибкие механизмы с различными уровнями сложности. Для аутентификации сеансов BGP используются адреса сессий BGP и номера AS. Поскольку сессии BGP используют протокол TCP (и IP) для организации гарантированной доставки, для сеансов BGP могут использоваться дополнительные средства аутентификации и защиты, применяемые для протоколов TCP и IP.

BGP использует опцию TCP MD5 для проверки данных и защиты от подмены сегментов TCP. Использование опции TCP MD5 для протокола BGP подробно описано в документе [RFC2385]. Управление ключами TCP MD5 обсуждается в документе [RFC3562]. Шифрование данных BGP обеспечивается с помощью механизма IPsec, который шифрует данные протокола IP (включая данные TCP и BGP). Механизм IPsec может использоваться как в транспортном, так и в туннельном режиме. Этот механизм описан в документе [RFC2406]. Как опция TCP MD5, так и механизм IPsec на сегодняшний день недостаточно широко используются для защиты BGP в Internet. Следовательно, достаточно сложно оценить их реальное влияние на работу BGP. Однако оба эти механизма относятся к числу средств защиты на базе протоколов TCP и IP, расход полосы, загрузка процессора и расход памяти для BGP будут такими же, как и для других протоколов, работающих на основе TCP и IP.

BGP использует значение IP TTL для защиты сеансов EBGP12) от различных атак на уровне TCP или IP, ведущих в избыточному расходу процессорного времени. Это простой механизм фильтрации сегментов BGP (TCP) по значению поля TTL в заголовке IP сегментов BGP (TCP), передаваемых в сеансах EBGP. Механизм BGP TTL описан в документе [RFC3682]. Использование [RFC3682] оказывает на производительность такое же влияние, как использование любых правил на базе списков ACL13 для протокола BGP.

Такие гибкие механизмы защиты на уровне TCP и IP позволяют протоколу BGP предотвратить вставку, удаление или изменение данных BGP, отслеживание данных, кражу сеансов и т. п. Однако протокол BGP уязвим для атак, которым подвержен протокол TCP. В документе [BGP-VULN] рассматриваются уязвимости протокола BGP. На момент создания настоящего документа велись работы по созданию и определению подходящей защитной инфраструктуры в рамках самого протокола BGP для обеспечения аутентификации и защиты маршрутной информации – к таким работам относятся [SBGP] и [SOBGP].

11. Литература

11.1. Нормативные документы

[BGP4] Rekhter, Y., Li., T., and S. Hares, Eds., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, «Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy», RFC 1519, September 1993.

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC1997] Chandra, R., Traina, P., and T. Li, «BGP Communities Attribute», RFC 1997, August 1996.

[RFC2385] Heffernan, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, August 1998.

[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, «Border Gateway Protocol (BGP) Persistent Route Oscillation Condition», RFC 3345, August 2002.

[RFC3562] Leech, M., «Key Management Considerations for the TCP MD5 Signature Option», RFC 3562, July 2003.

[RFC3682] Gill, V., Heasley, J., and D. Meyer, «The Generalized TTL Security Mechanism (GTSM)», RFC 368215, February 2004.

[RFC3392] Chandra, R. and J. Scudder, «Capabilities Advertisement with BGP-4», RFC 3392, November 2002.

[BGP-VULN] Murphy, S., «BGP Security Vulnerabilities Analysis», RFC 4272, January 2006.

[SBGP] Seo, K., S. Kent and C. Lynn, «Secure Border Gateway Protocol (Secure-BGP)», IEEE Journal on Selected Areas in Communications Vol. 18, No. 4, April 2000, pp. 582-592.

11.2. Дополнительная литература

[RFC854] Postel, J. and J. Reynolds, «Telnet Protocol Specification», STD 8, RFC 854, May 1983.

[RFC1105] Lougheed, K. and Y. Rekhter, «Border Gateway Protocol (BGP)», RFC 1105, June 1989.

[RFC1163] Lougheed, K. and Y. Rekhter, «Border Gateway Protocol (BGP)», RFC 1163, June 1990.

[RFC1264] Hinden, R., «Internet Routing Protocol Standardization Criteria», RFC 1264, October 1991.

[RFC1267] Lougheed, K. and Y. Rekhter, «Border Gateway Protocol 3 (BGP-3)», RFC 1267, October 1991.

[RFC1772] Rekhter, Y., and P. Gross, Editors, «Application of the Border Gateway Protocol in the Internet», RFC 1772, March 1995.

[RFC1774] Traina, P., «BGP-4 Protocol Analysis», RFC 17743, March 1995.

[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, «Routing Policy Specification Language (RPSL)», RFC 2622, June 1999.

[RFC2406] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 240618, November 1998.

[ROUTEVIEWS] Meyer, D., «The Route Views Project», http://www.routeviews.org.

[SOBGP] White, R., «Architecture and Deployment Considerations for Secure Origin BGP (soBGP)», Work in Progress19, May 2005.

Адреса авторов

David Meyer

EMail: dmm@1-4-5.net

Keyur Patel

Cisco Systems

EMail: keyupate@cisco.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).


1Border Gateway Protocol version 4

2the second report

3Classless Inter-Domain Routing

4Interior gateway protocol – протокол внутреннего шлюза.

5Network Layer Reachability Information – информация о доступности на сетевом уровне.

6Autonomous System Path – путь через АС.

7Вектор пути. Более подробную информацию об этом алгоритме можно найти в RFC 1322. Прим. перев.

8Finite State Machine.

9Снизить уровень предпочтения для моего маршрута.

10Невозможность схождения. Прим. перев.

11Эта ссылка является ошибочной. Приведенная в оригинале цитата перенесена из документа [RFC1774], который содержит ссылку на RFC 1771 (предыдущий вариант спецификации BGP-4). В настоящем переводе приведена цитата из перевода RFC 1771. Прим. перев.

12External BGP

13access control list – список управления доступом.

15Этот документ устарел и заменен RFC 5082. Прим. перев.

16Этот документ устарел и заменен RFC 5492. Прим. перев.

18Этот документ устарел и заменен RFC 4303, 4305. Прим. перев.

19Работа не завершена (май 2009). Прим. перев.




RFC 4273 Definitions of Managed Objects for BGP-4

Network Working Group                                   J. Haas, Ed.
Request for Comments: 4273                             S. Hares, Ed.
Obsoletes: 1269, 1657                           NextHop Technologies
Category: Standards Track                               January 2006

Определения объектов управления для BGP-4

Definitions of Managed Objects for BGP-4

PDF

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2006).

Тезисы

Этот документ определяет часть базы MIB1 для использования с протоколами сетевого управления в сообществе Internet. В частности, документ определяет объекты управления для протокола BGP2 версии 4 и предыдущих версий.

Предтечей этого документа является RFC 1269 «Definitions of Managed Objects for the Border Gateway Protocol (Version 3)», который был обновлен для поддержки BGP-4 в RFC 1657. В документе исправлены ошибки, внесенные при конвертировании модуля MIB для использования с языком SMIv2. В документе также даются обновленные ссылки на современные документы SNMP.

В этом документе описаны развернутые на практике реализации данного модуля MIB в историческом контексте для прояснения некоторых элементов и отмечены ошибки, в результате которых модуль MIB давал неполное представление протокола BGP. В настоящее время продолжается работа по замене модуля MIB с учетом современного состояния протокола BGP и его расширений.

Этот документ отменяет действие RFC 1269 и RFC 1657.

Оглавление

Исключено из версии HTML

1. Введение

Этот документ определяет часть базы MIB3 для использования с протоколами сетевого управления в сообществе Internet. В частности, документ определяет объекты управления для протокола BGP4 версии 4 и предыдущих версий [BGP4, BGP4APP].

Этот документ отменяет действие RFC 1269 и RFC 1657.

2. Стандартная схема сетевого управления Internet

Подробный обзор современной стандартной схемы сетевого управления Internet (Internet-Standard Management Framework) содержится в главе 7 документа RFC 3410 [RFC3410].

Доступ к объектам управления осуществляется через виртуальное информационное хранилище, называемое базой данных управления (Management Information Base) или MIB. Для доступа к объектам MIB обычно используется простой протокол SNMP5.

Объекты MIB определяются с использованием механизмов, заданных в структуре SMI6. Данный документ описывает модуль MIB, соответствующий спецификации SMIv2, которая описана в документах STD 58 — RFC 2578 [RFC2578], RFC 2579 [RFC2579] и RFC 2580 [RFC2580].

3. Обзор

Эти объекты используются для контроля и управления реализациями протокола BGP-4.

За исключением небольшого числа скалярных объектов системного уровня модуль MIB поделен на три таблицы: таблица партнеров (BGP Peer Table), таблица полученных атрибутов пути (BGP Received Path Attribute Table) и таблица принятых атрибутов BGP-4 (BGP-4 Received Path Attribute Table). Таблица партнеров содержит сведения о состоянии и текущей активности соединений с партнерами BGP. Таблица полученных атрибутов пути содержит атрибуты пути, принятые от всех партнеров, использующих протокол BGP версии 3 или ниже. Таблица BGP-4 Received Path Attribute содержит атрибуты пути, полученные от всех партнеров BGP-4. Атрибуты, используемые в действительности для определения маршрутов, являются подмножеством таблиц принятых атрибутов после применения к этим таблицам правил локальной политки маршрутизации.

4. Определения

    BGP4-MIB DEFINITIONS ::= BEGIN

        IMPORTS
            MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
            IpAddress, Integer32, Counter32, Gauge32, mib-2
                FROM SNMPv2-SMI
            MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
                FROM SNMPv2-CONF;

        bgp MODULE-IDENTITY
            LAST-UPDATED "200601110000Z"
            ORGANIZATION "IETF IDR Working Group"
            CONTACT-INFO "E-mail:  idr@ietf.org

                          Jeffrey Haas, Susan Hares  (Editors)
                          NextHop Technologies
                          825 Victors Way
                          Suite 100
                          Ann Arbor, MI 48108-2738
                          Tel: +1 734 222-1600
                          Fax: +1 734 222-1602
                          E-mail: jhaas@nexthop.com
                                  skh@nexthop.com"

            DESCRIPTION1
                    "The MIB module for the BGP-4 protocol.
                    Copyright (C) The Internet Society (2006). This version of this MIB module
                    is part of RFC 4273; see the RFC itself for full legal notices."

            REVISION "200601110000Z"
            DESCRIPTION2
                   "Changes from RFC 1657:

                    1) Fixed the definitions of the notifications to make them equivalent to
                       their initial definition in RFC 1269.
                    2) Added compliance and conformance info.
                    3) Updated information for the values of  bgpPeerNegotiatedVersion,
                       bgp4PathAttrLocalPref, bgp4PathAttrCalcLocalPref,
                       bgp4PathAttrMultiExitDisc, bgp4PathAttrASPathSegement.
                    4) Added additional clarification comments where needed.
                    5) Noted where objects do not fully reflect the protocol as Known Issues.
                    6) Updated the DESCRIPTION for the bgp4PathAttrAtomicAggregate object.
                    7) The following objects have had their DESCRIPTION clause modified to
                       remove the text that suggested (using 'should' verb) initializing the
                       counter to zero on a transition to the established state:
                         bgpPeerInUpdates, bgpPeerOutUpdates,
                         bgpPeerInTotalMessages, bgpPeerOutTotalMessages
                       Those implementations that still do this are still compliant with this
                       new wording. Applications should not assume counters have started at
                       zero.

                     Published as RFC 4273."

            REVISION "199405050000Z"
            DESCRIPTION3
                    "Translated to SMIv2 and published as RFC 1657."

            REVISION "199110261839Z"
            DESCRIPTION4
                    "Initial version, published as RFC 1269."
            ::= { mib-2 15 }

        bgpVersion OBJECT-TYPE
            SYNTAX     OCTET STRING (SIZE (1..255))
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION5
                   "Vector of supported BGP protocol version numbers. Each peer negotiates the
                     version from this vector.  Versions are identified via the string of bits
                     contained within this object.  The first octet contains bits 0 to 7, the
                     second octet contains bits 8 to 15, and so on, with the most significant
                     bit referring to the lowest bit number in the octet (e.g., the MSB of the
                     first octet refers to bit 0).  If a bit, i, is present and set, then the
                     version (i+1) of the BGP is supported."
            REFERENCE
                    "RFC 4271, Section 4.2."
            ::= { bgp 1 }

        bgpLocalAs OBJECT-TYPE

            SYNTAX     Integer32 (0..65535)
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION6
                    "The local autonomous system number."
            REFERENCE
                     "RFC 4271, Section 4.2, 'My Autonomous System'."
            ::= { bgp 2 }

        -- BGP Peer table.  This table contains, one entry per
        -- BGP peer, information about the BGP peer.7

        bgpPeerTable OBJECT-TYPE
            SYNTAX     SEQUENCE OF BgpPeerEntry
            MAX-ACCESS not-accessible
            STATUS     current
            DESCRIPTION8
                    "BGP peer table.  This table contains, one entry per BGP peer, information
                     about the connections with BGP peers."
            ::= { bgp 3 }

        bgpPeerEntry OBJECT-TYPE
            SYNTAX     BgpPeerEntry
            MAX-ACCESS not-accessible
            STATUS     current
            DESCRIPTION9
                    "Entry containing information about the connection with a BGP peer."
            INDEX { bgpPeerRemoteAddr }
            ::= { bgpPeerTable 1 }

        BgpPeerEntry ::= SEQUENCE {
                bgpPeerIdentifier
                    IpAddress,
                bgpPeerState
                    INTEGER,
                bgpPeerAdminStatus
                    INTEGER,
                bgpPeerNegotiatedVersion
                    Integer32,
                bgpPeerLocalAddr
                    IpAddress,
                bgpPeerLocalPort
                    Integer32,
                bgpPeerRemoteAddr
                    IpAddress,
                bgpPeerRemotePort
                    Integer32,
                bgpPeerRemoteAs
                    Integer32,
                bgpPeerInUpdates
                    Counter32,
                bgpPeerOutUpdates
                    Counter32,
                bgpPeerInTotalMessages
                    Counter32,
                bgpPeerOutTotalMessages
                    Counter32,
                bgpPeerLastError
                    OCTET STRING,
                bgpPeerFsmEstablishedTransitions
                    Counter32,
                bgpPeerFsmEstablishedTime
                    Gauge32,
                bgpPeerConnectRetryInterval
                    Integer32,
                bgpPeerHoldTime
                    Integer32,
                bgpPeerKeepAlive
                    Integer32,
                bgpPeerHoldTimeConfigured
                    Integer32,
                bgpPeerKeepAliveConfigured
                    Integer32,
                bgpPeerMinASOriginationInterval
                    Integer32,
                bgpPeerMinRouteAdvertisementInterval
                    Integer32,
                bgpPeerInUpdateElapsedTime
                    Gauge32
                }

        bgpPeerIdentifier OBJECT-TYPE
            SYNTAX     IpAddress
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION10
                    "The BGP Identifier of this entry's BGP peer. This entry MUST be 0.0.0.0
                     unless the bgpPeerState is in the openconfirm or the established state."
            REFERENCE
                    "RFC 4271, Section 4.2, 'BGP Identifier'."
            ::= { bgpPeerEntry 1 }

        bgpPeerState OBJECT-TYPE
            SYNTAX     INTEGER {
                                idle(1),
                                connect(2),
                                active(3),
                                opensent(4),
                                openconfirm(5),
                                established(6)
                       }
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION11
                    "The BGP peer connection state."
            REFERENCE
                    "RFC 4271, Section 8.2.2."
            ::= { bgpPeerEntry 2 }

        bgpPeerAdminStatus OBJECT-TYPE
            SYNTAX     INTEGER {
                                stop(1),
                                start(2)
                       }
            MAX-ACCESS read-write
            STATUS     current
            DESCRIPTION12
                    "The desired state of the BGP connection. A transition from 'stop' to
                     'start' will cause the BGP Manual Start Event to be generated. A transition
                     from 'start' to 'stop' will cause the BGP Manual Stop Event to be
                     generated. This parameter can be used to restart BGP peer connections.
                     Care should be used in providing write access to this object without
                     adequate authentication."
            REFERENCE
                    "RFC 4271, Section 8.1.2."
            ::= { bgpPeerEntry 3 }

        bgpPeerNegotiatedVersion OBJECT-TYPE
            SYNTAX     Integer32
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION13
                    "The negotiated version of BGP running between the two peers.

                     This entry MUST be zero (0) unless the bgpPeerState is in the openconfirm
                     or the established state.

                     Note that legal values for this object are between 0 and 255."
            REFERENCE
                    "RFC 4271, Section 4.2.
                     RFC 4271, Section 7."
            ::= { bgpPeerEntry 4 }

        bgpPeerLocalAddr OBJECT-TYPE
            SYNTAX     IpAddress
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION14
                    "The local IP address of this entry's BGP connection."
            ::= { bgpPeerEntry 5 }

        bgpPeerLocalPort OBJECT-TYPE
            SYNTAX     Integer32 (0..65535)
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION15
                    "The local port for the TCP connection between the BGP peers."
            ::= { bgpPeerEntry 6 }

        bgpPeerRemoteAddr OBJECT-TYPE
            SYNTAX     IpAddress
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION16
                    "The remote IP address of this entry's BGP peer."
            ::= { bgpPeerEntry 7 }

        bgpPeerRemotePort OBJECT-TYPE
            SYNTAX     Integer32 (0..65535)
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION17
                   "The remote port for the TCP connection between the BGP peers.  Note that
                   the objects bgpPeerLocalAddr, bgpPeerLocalPort, bgpPeerRemoteAddr, and
                   bgpPeerRemotePort provide the appropriate reference to the standard MIB TCP
                   connection table."

            ::= { bgpPeerEntry 8 }

        bgpPeerRemoteAs OBJECT-TYPE
            SYNTAX     Integer32 (0..65535)
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION18
                    "The remote autonomous system number received in the BGP OPEN message."
            REFERENCE
                    "RFC 4271, Section 4.2."
            ::= { bgpPeerEntry 9 }

        bgpPeerInUpdates OBJECT-TYPE
            SYNTAX     Counter32
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION19
                    "The number of BGP UPDATE messages received on this connection."
            REFERENCE
                    "RFC 4271, Section 4.3."
            ::= { bgpPeerEntry 10 }

        bgpPeerOutUpdates OBJECT-TYPE
            SYNTAX     Counter32
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION20
                    "The number of BGP UPDATE messages transmitted on this connection."
            REFERENCE
                    "RFC 4271, Section 4.3."
            ::= { bgpPeerEntry 11 }

        bgpPeerInTotalMessages OBJECT-TYPE
            SYNTAX     Counter32
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION21
                    "The total number of messages received from the remote peer on this
                     connection."
            REFERENCE
                    "RFC 4271, Section 4."
            ::= { bgpPeerEntry 12 }

        bgpPeerOutTotalMessages OBJECT-TYPE
            SYNTAX     Counter32
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION22
                    "The total number of messages transmitted to the remote peer on this 
                     connection."
            REFERENCE
                    "RFC 4271, Section 4."
            ::= { bgpPeerEntry 13 }

        bgpPeerLastError OBJECT-TYPE
            SYNTAX     OCTET STRING (SIZE (2))
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION23
                    "The last error code and subcode seen by this peer on this connection. If 
                     no error has occurred, this field is zero.  Otherwise, the first byte of
                     this two byte OCTET STRING contains the error code, and the second byte
                     contains the subcode."
            REFERENCE
                    "RFC 4271, Section 4.5."
            ::= { bgpPeerEntry 14 }

        bgpPeerFsmEstablishedTransitions OBJECT-TYPE
            SYNTAX     Counter32
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION24
                    "The total number of times the BGP FSM transitioned into the established 
                     state for this peer."
            REFERENCE
                    "RFC 4271, Section 8."
            ::= { bgpPeerEntry 15 }

        bgpPeerFsmEstablishedTime OBJECT-TYPE
            SYNTAX     Gauge32
            UNITS      "seconds"
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION25
                   "This timer indicates how long (in seconds) this peer has been in the
                   established state or how long since this peer was last in the
                   established state.  It is set to zero when a new peer is configured or when
                   the router is booted."
            REFERENCE
                    "RFC 4271, Section 8."
            ::= { bgpPeerEntry 16 }

        bgpPeerConnectRetryInterval OBJECT-TYPE
            SYNTAX     Integer32 (1..65535)
            UNITS      "seconds"
            MAX-ACCESS read-write
            STATUS     current
            DESCRIPTION26
                   "Time interval (in seconds) for the ConnectRetry timer. The suggested value
                   for this timer is 120 seconds."
            REFERENCE
                    "RFC 4271, Section 8.2.2.  This is the value used
                     to initialize the 'ConnectRetryTimer'."
            ::= { bgpPeerEntry 17 }

        bgpPeerHoldTime OBJECT-TYPE
            SYNTAX     Integer32  ( 0 | 3..65535 )
            UNITS      "seconds"
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION27
                    "Time interval (in seconds) for the Hold Timer established with the peer.
                     The value of this object is calculated by this BGP speaker, using the
                     smaller of the values in bgpPeerHoldTimeConfigured and the Hold Time
                     received in the OPEN message.

                     This value must be at least three seconds if it is not zero (0).

                     If the Hold Timer has not been established with the peer this object MUST
                     have a value of zero (0).

                     If the bgpPeerHoldTimeConfigured object has a value of (0), then this
                     object MUST have a value of (0)."
            REFERENCE
                    "RFC 4271, Section 4.2."
            ::= { bgpPeerEntry 18 }

        bgpPeerKeepAlive OBJECT-TYPE
            SYNTAX     Integer32 ( 0 | 1..21845 )
            UNITS      "seconds"
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION28
                    "Time interval (in seconds) for the KeepAlive timer established with the
                    peer.  The value of this object is calculated by this BGP speaker such
                    that, when compared with bgpPeerHoldTime, it has the same proportion that
                    bgpPeerKeepAliveConfigured has, compared with bgpPeerHoldTimeConfigured.

                    If the KeepAlive timer has not been established with the peer, this object
                    MUST have a value of zero (0).

                    If the of bgpPeerKeepAliveConfigured object has a value of (0), then this
                    object MUST have a value of (0)."
            REFERENCE
                    "RFC 4271, Section 4.4."
            ::= { bgpPeerEntry 19 }

        bgpPeerHoldTimeConfigured OBJECT-TYPE
            SYNTAX     Integer32 ( 0 | 3..65535 )
            UNITS      "seconds"
            MAX-ACCESS read-write
            STATUS     current
            DESCRIPTION29
                    "Time interval (in seconds) for the Hold Time configured for this BGP
                    speaker with this peer.  This value is placed in an OPEN message sent to
                    this peer by this BGP speaker, and is compared with the Hold Time field in
                    an OPEN message received from the peer when determining the Hold Time
                    (bgpPeerHoldTime) with the peer. This value must not be less than three
                    seconds if it is not zero (0).  If it is zero (0), the Hold Time is NOT to
                    be established with the peer.  The suggested value for this timer is 90
                    seconds."
            REFERENCE
                    "RFC 4271, Section 4.2.
                     RFC 4271, Section 10."
            ::= { bgpPeerEntry 20 }

        bgpPeerKeepAliveConfigured OBJECT-TYPE

            SYNTAX     Integer32 ( 0 | 1..21845 )
            UNITS      "seconds"
            MAX-ACCESS read-write
            STATUS     current
            DESCRIPTION30
                   "Time interval (in seconds) for the KeepAlive timer configured for this BGP
                    speaker with this peer.  The value of this object will only determine the
                    KEEPALIVE messages' frequency relative to the value specified in
                    bgpPeerHoldTimeConfigured; the actual time interval for the KEEPALIVE
                    messages is indicated by bgpPeerKeepAlive.  A reasonable maximum value for
                    this timer would be one third of that of bgpPeerHoldTimeConfigured.
                    If the value of this object is zero (0), no periodical KEEPALIVE messages
                    are sent to the peer after the BGP connection has been established.  The
                    suggested value for this timer is 30 seconds."
            REFERENCE
                    "RFC 4271, Section 4.4.
                     RFC 4271, Section 10."
            ::= { bgpPeerEntry 21 }

        bgpPeerMinASOriginationInterval OBJECT-TYPE
            SYNTAX     Integer32 (1..65535)
            UNITS      "seconds"
            MAX-ACCESS read-write
            STATUS     current
            DESCRIPTION31
                    "Time interval (in seconds) for the MinASOriginationInterval timer.
                     The suggested value for this timer is 15 seconds."
            REFERENCE
                    "RFC 4271, Section 9.2.1.2.
                     RFC 4271, Section 10."
            ::= { bgpPeerEntry 22 }

        bgpPeerMinRouteAdvertisementInterval OBJECT-TYPE
            SYNTAX     Integer32 (1..65535)
            UNITS      "seconds"
            MAX-ACCESS read-write
            STATUS     current
            DESCRIPTION32
                  "Time interval (in seconds) for the MinRouteAdvertisementInterval timer. The
                   suggested value for this timer is 30 seconds for EBGP connections and 5
                   seconds for IBGP connections."
            REFERENCE
                    "RFC 4271, Section 9.2.1.1.
                     RFC 4271, Section 10."
            ::= { bgpPeerEntry 23 }

        bgpPeerInUpdateElapsedTime OBJECT-TYPE
            SYNTAX     Gauge32
            UNITS      "seconds"
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION33
                    "Elapsed time (in seconds) since the last BGP UPDATE message was received
                     from the peer. Each time bgpPeerInUpdates is incremented,
                     the value of this object is set to zero (0)."
            REFERENCE
                    "RFC 4271, Section 4.3.
                     RFC 4271, Section 8.2.2, Established state."
            ::= { bgpPeerEntry 24 }

        bgpIdentifier OBJECT-TYPE
            SYNTAX     IpAddress
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION34
                    "The BGP Identifier of the local system."
            REFERENCE
                    "RFC 4271, Section 4.2."
            ::= { bgp 4 }

        -- BGP Received Path Attribute Table.  This table contains one entry per path to a 
        -- network, and path attributes received from all peers running BGP version 3 or less.
        -- This table is obsolete, having been replaced in
        -- functionality by the bgp4PathAttrTable35.

        bgpRcvdPathAttrTable OBJECT-TYPE
            SYNTAX     SEQUENCE OF BgpPathAttrEntry
            MAX-ACCESS not-accessible
            STATUS     obsolete
            DESCRIPTION36
                    "The BGP Received Path Attribute Table contains information about paths to
                     destination networks, received from all peers running BGP version 3 or
                     less."
            ::= { bgp 5 }

        bgpPathAttrEntry OBJECT-TYPE
            SYNTAX     BgpPathAttrEntry
            MAX-ACCESS not-accessible
            STATUS     obsolete
            DESCRIPTION37
                    "Information about a path to a network."
            INDEX { bgpPathAttrDestNetwork,
                    bgpPathAttrPeer        }
            ::= { bgpRcvdPathAttrTable 1 }

        BgpPathAttrEntry ::= SEQUENCE {
            bgpPathAttrPeer
                 IpAddress,
            bgpPathAttrDestNetwork
                 IpAddress,
            bgpPathAttrOrigin
                 INTEGER,
            bgpPathAttrASPath
                 OCTET STRING,
            bgpPathAttrNextHop
                 IpAddress,
            bgpPathAttrInterASMetric
                 Integer32
        }

        bgpPathAttrPeer OBJECT-TYPE
            SYNTAX     IpAddress
            MAX-ACCESS read-only
            STATUS     obsolete
            DESCRIPTION38
                    "The IP address of the peer where the path information was learned."
            ::= { bgpPathAttrEntry 1 }

        bgpPathAttrDestNetwork OBJECT-TYPE
            SYNTAX     IpAddress
            MAX-ACCESS read-only
            STATUS     obsolete
            DESCRIPTION
                    "The address of the destination network."
            REFERENCE
                    "RFC 1267, Section 4.3."
            ::= { bgpPathAttrEntry 2 }

        bgpPathAttrOrigin OBJECT-TYPE
            SYNTAX     INTEGER {
                           igp(1),-- networks are interior39
                           egp(2),-- networks learned via the EGP protocol40
                           incomplete(3) -- networks that are learned by some other means41
                       }
            MAX-ACCESS read-only
            STATUS     obsolete
            DESCRIPTION42
                    "The ultimate origin of the path information."
            REFERENCE
                    "RFC 1267, Section 4.3.
                     RFC 1267, Section 5."
            ::= { bgpPathAttrEntry 3 }

        bgpPathAttrASPath OBJECT-TYPE
            SYNTAX     OCTET STRING (SIZE (2..255))
            MAX-ACCESS read-only
            STATUS     obsolete
            DESCRIPTION43
                    "The set of ASes that must be traversed to reach the network.  This object
                     is probably best represented as SEQUENCE OF INTEGER.  For SMI
                     compatibility, though, it is represented as OCTET STRING.  Each AS is
                     represented as a pair of octets according to the following algorithm:

                        first-byte-of-pair = ASNumber / 256;
                        second-byte-of-pair = ASNumber & 255;"
            REFERENCE
                    "RFC 1267, Section 4.3.
                     RFC 1267, Section 5."
            ::= { bgpPathAttrEntry 4 }

        bgpPathAttrNextHop OBJECT-TYPE
            SYNTAX     IpAddress
            MAX-ACCESS read-only
            STATUS     obsolete
            DESCRIPTION44
                    "The address of the border router that should
                     be used for the destination network."
            REFERENCE
                    "RFC 1267, Section 4.3.
                     RFC 1267, Section 5."
            ::= { bgpPathAttrEntry 5 }

        bgpPathAttrInterASMetric OBJECT-TYPE
            SYNTAX     Integer32
            MAX-ACCESS read-only
            STATUS     obsolete
            DESCRIPTION45
                   "The optional inter-AS metric.  If this attribute has not been provided for
                    this route, the value for this object is 0."
            REFERENCE
                    "RFC 1267, Section 4.3.
                     RFC 1267, Section 5."
            ::= { bgpPathAttrEntry 6 }

        -- BGP-4 Received Path Attribute Table.  This table contains one entry per path 
        -- to a network, and path attributes received from all peers running BGP-446.

        bgp4PathAttrTable OBJECT-TYPE
            SYNTAX     SEQUENCE OF Bgp4PathAttrEntry
            MAX-ACCESS not-accessible
            STATUS     current
            DESCRIPTION47
                  "The BGP-4 Received Path Attribute Table contains information about paths to
                   destination networks, received from all BGP4 peers."
            ::= { bgp 6 }

        bgp4PathAttrEntry OBJECT-TYPE
            SYNTAX     Bgp4PathAttrEntry
            MAX-ACCESS not-accessible
            STATUS     current
            DESCRIPTION48
                    "Information about a path to a network."
            INDEX { bgp4PathAttrIpAddrPrefix,
                    bgp4PathAttrIpAddrPrefixLen,
                    bgp4PathAttrPeer            }
            ::= { bgp4PathAttrTable 1 }

        Bgp4PathAttrEntry ::= SEQUENCE {
            bgp4PathAttrPeer
                 IpAddress,
            bgp4PathAttrIpAddrPrefixLen
                 Integer32,
            bgp4PathAttrIpAddrPrefix
                 IpAddress,
            bgp4PathAttrOrigin
                 INTEGER,
            bgp4PathAttrASPathSegment
                 OCTET STRING,
            bgp4PathAttrNextHop
                 IpAddress,
            bgp4PathAttrMultiExitDisc
                 Integer32,
            bgp4PathAttrLocalPref
                 Integer32,
            bgp4PathAttrAtomicAggregate
                 INTEGER,
            bgp4PathAttrAggregatorAS
                 Integer32,
            bgp4PathAttrAggregatorAddr
                 IpAddress,
            bgp4PathAttrCalcLocalPref
                 Integer32,
            bgp4PathAttrBest
                 INTEGER,
            bgp4PathAttrUnknown
                 OCTET STRING
        }

        bgp4PathAttrPeer OBJECT-TYPE
            SYNTAX     IpAddress
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION49
                    "The IP address of the peer where the path information was learned."
            ::= { bgp4PathAttrEntry 1 }

        bgp4PathAttrIpAddrPrefixLen OBJECT-TYPE
            SYNTAX     Integer32 (0..32)
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION50
                    "Length in bits of the IP address prefix in the Network Layer Reachability
                     Information field."
            ::= { bgp4PathAttrEntry 2 }

        bgp4PathAttrIpAddrPrefix OBJECT-TYPE
            SYNTAX     IpAddress
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION51
                  "An IP address prefix in the Network Layer Reachability Information field.
                   This object is an IP address containing the prefix with length specified by
                   bgp4PathAttrIpAddrPrefixLen. Any bits beyond the length specified by
                   bgp4PathAttrIpAddrPrefixLen are zeroed."
            REFERENCE
                    "RFC 4271, Section 4.3."
            ::= { bgp4PathAttrEntry 3 }

        bgp4PathAttrOrigin OBJECT-TYPE
            SYNTAX     INTEGER {
                           igp(1),-- networks are interior52
                           egp(2),-- networks learned via the EGP protocol53
                           incomplete(3) -- networks that are learned by some other means54
                       }
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION55
                    "The ultimate origin of the path information."
            REFERENCE
                    "RFC 4271, Section 4.3.
                     RFC 4271, Section 5.1.1."
            ::= { bgp4PathAttrEntry 4 }

        bgp4PathAttrASPathSegment OBJECT-TYPE
            SYNTAX     OCTET STRING (SIZE (2..255))
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION56
                  "The sequence of AS path segments.  Each AS path segment is represented by a
                   triple <type, length, value>.

                   The type is a 1-octet field that has two possible values:
                       1      AS_SET: unordered set of ASes that a route in the UPDATE message
                                   has traversed

                       2      AS_SEQUENCE: ordered set of ASes that a route in the UPDATE
                                   message has traversed.

                   The length is a 1-octet field containing the number of ASes in the value
               field. The value field contains one or more AS numbers.  Each AS is 
                   represented in the octet string as a pair of octets according to the 
                   following algorithm:

                        first-byte-of-pair = ASNumber / 256;
                        second-byte-of-pair = ASNumber & 255;

                   Known Issues:
                   o BGP Confederations will result in a type of either 3 or 4.
                   o An AS Path may be longer than 255 octets. This may result in this object
                       containing a truncated AS Path."
            REFERENCE
                    "RFC 4271, Section 4.3.
                     RFC 4271, Section 5.1.2."
            ::= { bgp4PathAttrEntry 5 }

        bgp4PathAttrNextHop OBJECT-TYPE
            SYNTAX     IpAddress
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION57
                    "The address of the border router that should be used for the destination
                     network. This address is the NEXT_HOP address received in the UPDATE
                     packet."
            REFERENCE
                    "RFC 4271, Section 4.3.
                     RFC 4271, Section 5.1.3."
            ::= { bgp4PathAttrEntry 6 }

        bgp4PathAttrMultiExitDisc OBJECT-TYPE
            SYNTAX     Integer32 (-1..2147483647)
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION58
                    "This metric is used to discriminate between multiple exit points to an
                     adjacent autonomous system.  A value of -1 indicates the absence of this
                     attribute.

                     Known Issues:
                     o The BGP-4 specification uses an unsigned 32 bit number.  Thus, this
                       object cannot represent the full range of the protocol."
            REFERENCE
                    "RFC 4271, Section 4.3.
                     RFC 4271, Section 5.1.4."
            ::= { bgp4PathAttrEntry 7 }

        bgp4PathAttrLocalPref OBJECT-TYPE
            SYNTAX     Integer32 (-1..2147483647)
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION59
                    "The originating BGP4 speaker's degree of preference for an advertised
                     route.  A value of -1 indicates the absence of this attribute.

                     Known Issues:
                     o The BGP-4 specification uses an unsigned 32 bit number and thus this
                       object cannot represent the full range of the protocol."
            REFERENCE
                    "RFC 4271, Section 4.3.
                     RFC 4271, Section 5.1.5."
            ::= { bgp4PathAttrEntry 8 }

        bgp4PathAttrAtomicAggregate OBJECT-TYPE
            SYNTAX     INTEGER {
                           lessSpecificRouteNotSelected(1), -- Typo corrected from RFC 165760
                           lessSpecificRouteSelected(2)
                       }
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION61
                    "If the ATOMIC_AGGREGATE attribute is present in the Path Attributes then
                     this object MUST have a value of 'lessSpecificRouteNotSelected'.

                     If the ATOMIC_AGGREGATE attribute is missing in the Path Attributes then
                     this object MUST have a value of 'lessSpecificRouteSelected'.

                     Note that ATOMIC_AGGREGATE is now a primarily informational attribute."
            REFERENCE
                    "RFC 4271, Sections 5.1.6 and 9.1.4."
            ::= { bgp4PathAttrEntry 9 }

        bgp4PathAttrAggregatorAS OBJECT-TYPE
            SYNTAX     Integer32 (0..65535)
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION62
                    "The AS number of the last BGP4 speaker that performed route aggregation.  
                     A value of zero (0) indicates the absence of this attribute.

                     Note that propagation of AS of zero is illegal in the Internet."
            REFERENCE
                    "RFC 4271, Section 5.1.7.
                     RFC 4271, Section 9.2.2.2."
            ::= { bgp4PathAttrEntry 10 }

        bgp4PathAttrAggregatorAddr OBJECT-TYPE
            SYNTAX     IpAddress
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION63
                    "The IP address of the last BGP4 speaker that performed route aggregation.
                     A value of 0.0.0.0 indicates the absence of this attribute."
            REFERENCE
                    "RFC 4271, Section 5.1.7.
                     RFC 4271, Section 9.2.2.2."
            ::= { bgp4PathAttrEntry 11 }

        bgp4PathAttrCalcLocalPref OBJECT-TYPE
            SYNTAX     Integer32 (-1..2147483647)
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION64
                    "The degree of preference calculated by the receiving BGP4 speaker for an
                     advertised route.  A value of -1 indicates the absence of this attribute.

                     Known Issues:
                     o The BGP-4 specification uses an unsigned 32 bit number and thus this
                       object cannot represent the full range of the protocol."

            REFERENCE
                    "RFC 4271, Section 9.1.1."
            ::= { bgp4PathAttrEntry 12 }

        bgp4PathAttrBest OBJECT-TYPE
            SYNTAX     INTEGER {
                           false(1),-- not chosen as best route65
                           true(2) -- chosen as best route66
                       }
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION67
                    "An indication of whether this route was chosen as the best BGP4 route for
                     this destination."
            REFERENCE
                    "RFC 4271, Section 9.1.2."
            ::= { bgp4PathAttrEntry 13 }

        bgp4PathAttrUnknown OBJECT-TYPE
            SYNTAX     OCTET STRING (SIZE(0..255))
            MAX-ACCESS read-only
            STATUS     current
            DESCRIPTION68
                    "One or more path attributes not understood by this BGP4 speaker.

                     Path attributes are recorded in the Update Path
                     attribute format of type, length, value.

                     Size zero (0) indicates the absence of such attributes.

                     Octets beyond the maximum size, if any, are not recorded by this object.

                     Known Issues:
                     o Attributes understood by this speaker, but not represented in this MIB,
                       are unavailable to the agent."
            REFERENCE
                    "RFC 4271, Section 5."
            ::= { bgp4PathAttrEntry 14 }

        -- Traps.
        -- Note that in RFC 1657, bgpTraps was incorrectly assigned a value of { bgp 7 } and  
        -- each of the traps had the bgpPeerRemoteAddr object inappropriately removed from  
        -- their OBJECTS clause.  The following definitions restore the semantics of the traps 
        -- as they were initially defined in RFC 1269.69

        bgpNotification OBJECT IDENTIFIER ::= { bgp 0 }

        bgpEstablishedNotification NOTIFICATION-TYPE
            OBJECTS { bgpPeerRemoteAddr,
                      bgpPeerLastError,
                      bgpPeerState      }
            STATUS  current
            DESCRIPTION70
                    "The bgpEstablishedNotification event is generated
                     when the BGP FSM enters the established state.

                     This Notification replaces the bgpEstablished Notification."
            ::= { bgpNotification 1 }

        bgpBackwardTransNotification NOTIFICATION-TYPE
            OBJECTS { bgpPeerRemoteAddr,
                      bgpPeerLastError,
                      bgpPeerState      }
            STATUS  current
            DESCRIPTION71
                   "The bgpBackwardTransNotification event is generated when the BGP FSM moves
                    from a higher numbered state to a lower numbered state.

                    This Notification replaces the bgpBackwardsTransition Notification."
            ::= { bgpNotification 2 }

        -- { bgp 7 } is deprecated.  Do not allocate new objects or
        --           notifications underneath this branch.72

        bgpTraps        OBJECT IDENTIFIER ::= { bgp 7 } -- deprecated73

        bgpEstablished NOTIFICATION-TYPE
            OBJECTS { bgpPeerLastError,
                      bgpPeerState      }
            STATUS  deprecated
            DESCRIPTION74
                    "The bgpEstablished event is generated when
                     the BGP FSM enters the established state.

                     This Notification has been replaced by the
                     bgpEstablishedNotification Notification."

            ::= { bgpTraps 1 }

        bgpBackwardTransition NOTIFICATION-TYPE
            OBJECTS { bgpPeerLastError,
                      bgpPeerState      }
            STATUS  deprecated
            DESCRIPTION75
                   "The bgpBackwardTransition event is generated when the BGP FSM moves from a
                    higher numbered state to a lower numbered state.

                    This Notification has been replaced by the
                    bgpBackwardTransNotification Notification."
            ::= { bgpTraps 2 }

        -- Conformance information76

        bgp4MIBConformance OBJECT IDENTIFIER
            ::= { bgp 8 }
        bgp4MIBCompliances OBJECT IDENTIFIER
                    ::= { bgp4MIBConformance 1 }
        bgp4MIBGroups      OBJECT IDENTIFIER
            ::= { bgp4MIBConformance 2 }

        -- Compliance statements77

        bgp4MIBCompliance MODULE-COMPLIANCE
            STATUS  current
            DESCRIPTION78
                    "The compliance statement for entities which implement the BGP4 mib."
            MODULE  -- this module79
                MANDATORY-GROUPS { bgp4MIBGlobalsGroup,
                                   bgp4MIBPeerGroup,
                                   bgp4MIBPathAttrGroup }
                GROUP bgp4MIBNotificationGroup
                DESCRIPTION80
                        "Implementation of BGP Notifications are
                         completely optional in this MIB."
            ::= { bgp4MIBCompliances 1 }

        bgp4MIBDeprecatedCompliances MODULE-COMPLIANCE
            STATUS  deprecated
            DESCRIPTION81
                    "The compliance statement documenting deprecated objects in the BGP4 mib."
            MODULE  -- this module5
                GROUP bgp4MIBTrapGroup
                DESCRIPTION82
                   "Group containing TRAP objects that were improperly converted from SMIv1 in
                    RFC 1657. The proper semantics have been restored with the objects in
                    bgp4MIBNotificationGroup."
            ::= { bgp4MIBCompliances 2 }

        bgp4MIBObsoleteCompliances MODULE-COMPLIANCE
            STATUS  obsolete
            DESCRIPTION
                    "The compliance statement documenting obsolete objects in the BGP4 mib."
            MODULE  -- this module5
                GROUP bgpRcvdPathAttrGroup
                DESCRIPTION83
                    "Group containing objects relevant to BGP-3 and earlier objects."
            ::= { bgp4MIBCompliances 3 }

        -- Units of conformance84

        bgp4MIBGlobalsGroup OBJECT-GROUP
            OBJECTS { bgpVersion,
                      bgpLocalAs,
                      bgpIdentifier }
            STATUS  current
            DESCRIPTION85
                    "A collection of objects providing information on global BGP state."
            ::= { bgp4MIBGroups 1 }

        bgp4MIBPeerGroup OBJECT-GROUP
            OBJECTS { bgpPeerIdentifier,
                      bgpPeerState,
                      bgpPeerAdminStatus,
                      bgpPeerNegotiatedVersion,
                      bgpPeerLocalAddr,
                      bgpPeerLocalPort,
                      bgpPeerRemoteAddr,
                      bgpPeerRemotePort,
                      bgpPeerRemoteAs,
                      bgpPeerInUpdates,
                      bgpPeerOutUpdates,
                      bgpPeerInTotalMessages,
                      bgpPeerOutTotalMessages,
                      bgpPeerLastError,
                      bgpPeerFsmEstablishedTransitions,
                      bgpPeerFsmEstablishedTime,
                      bgpPeerConnectRetryInterval,
                      bgpPeerHoldTime,
                      bgpPeerKeepAlive,
                      bgpPeerHoldTimeConfigured,
                      bgpPeerKeepAliveConfigured,
                      bgpPeerMinASOriginationInterval,
                      bgpPeerMinRouteAdvertisementInterval,
                      bgpPeerInUpdateElapsedTime }
            STATUS  current
            DESCRIPTION86
                    "A collection of objects for managing BGP peers."
            ::= { bgp4MIBGroups 2 }

        bgpRcvdPathAttrGroup OBJECT-GROUP
            OBJECTS { bgpPathAttrPeer,
                      bgpPathAttrDestNetwork,
                      bgpPathAttrOrigin,
                      bgpPathAttrASPath,
                      bgpPathAttrNextHop,
                      bgpPathAttrInterASMetric }
            STATUS  obsolete
            DESCRIPTION87
                    "A collection of objects for managing BGP-3 and earlier path entries.

                    This conformance group, like BGP-3, is obsolete."
            ::= { bgp4MIBGroups 3 }

        bgp4MIBPathAttrGroup OBJECT-GROUP
            OBJECTS { bgp4PathAttrPeer,
                      bgp4PathAttrIpAddrPrefixLen,
                      bgp4PathAttrIpAddrPrefix,
                      bgp4PathAttrOrigin,
                      bgp4PathAttrASPathSegment,
                      bgp4PathAttrNextHop,
                      bgp4PathAttrMultiExitDisc,
                      bgp4PathAttrLocalPref,
                      bgp4PathAttrAtomicAggregate,
                      bgp4PathAttrAggregatorAS,
                      bgp4PathAttrAggregatorAddr,
                      bgp4PathAttrCalcLocalPref,
                      bgp4PathAttrBest,
                      bgp4PathAttrUnknown }
            STATUS  current
            DESCRIPTION88
                    "A collection of objects for managing BGP path entries."

            ::= { bgp4MIBGroups 4 }

        bgp4MIBTrapGroup NOTIFICATION-GROUP
            NOTIFICATIONS { bgpEstablished,
                            bgpBackwardTransition }
            STATUS  deprecated
            DESCRIPTION89
                    "A collection of notifications for signaling
                     changes in BGP peer relationships.

                     Obsoleted by bgp4MIBNotificationGroup"
            ::= { bgp4MIBGroups 5 }

        bgp4MIBNotificationGroup NOTIFICATION-GROUP
            NOTIFICATIONS { bgpEstablishedNotification,
                            bgpBackwardTransNotification }
            STATUS current
            DESCRIPTION90
                    "A collection of notifications for signaling
                     changes in BGP peer relationships.

                     Obsoletes bgp4MIBTrapGroup."
            ::= { bgp4MIBGroups 6 }

    END

5. Вопросы безопасности

Данный модуль MIB относится к системам, обеспечивающим междоменную маршрутизацию. В силу этого неправомерные манипуляции с объектами, представленными в этом модуле MIB, могут приводить к возникновению отказов в обслуживании для множества пользователей.

В данном модуле MIB определено несколько объектов, которые имеют в пункте MAX-ACCESS значения read-write97 и/или read-create98. Такие объекты следует рассматривать как чувствительные или уязвимые в большинстве сетевых сред. Поддержка операции SET в незащищенных средах без соответствующей защиты может приводить к негативным последствиям для работы сети. К таким объектам относятся:

  • bgpPeerAdminStatus

    Неправомерное изменение значения bgpPeerAdminStatus со start на stop может приводить к существенным нарушениям связности для значительных областей Internet, доступ к которым осуществляется через соответствующие узлы BGP.

  • bgpPeerConnectRetryInterval

    Неправомерное изменение этого объекта может приводить к продолжительному разрыву соединений, когда они могли бы быть восстановленными за короткое время.

  • bgpPeerHoldTimeConfigured, bgpPeerKeepAliveConfigured

    Некорректная настройка этих объектов может сделать сессии BGP недолговечными и менее устойчивыми к атакам на отказ служб междоменной маршртуизации.

  • bgpPeerMinASOriginationInterval, bgpPeerMinRouteAdvertisementInterval

    Некорректная настройка этих значений может оказывать неблагоприятное воздействие на глобальное (в масштабах Internet) схождение маршрутов, анонсируемых данным узлом BGP. Это может приводить к возникновению долгоживущих маршрутных петель и “черных дыр” для областей Internet, использующих эти маршруты.

Множество объектов данного модуля MIB содержит достаточно важную информацию о работе сети. Например, адреса локального и удаленного узлов BGP могут быть важными с точки зрения ISP, желающих сохранить в тайне адреса интерфейсов своих маршрутизаторов в целях предотвращения использования этих адресов для DoS-атак или подмены.

Следовательно, для большинства сетевых сред важное значение имеет контроль доступа для чтения таких объектов и возможно даже требуется шифрование значений при передаче объектов через сеть по протоколу SNMP.

Версии протокола SNMP до SNMPv3 не обеспечивают должного уровня безопасности. Даже если сеть как таковая защищена (например, с помощью IPsec), это не обеспечивает контроля за внутрисетевым доступом и операциями GET/SET (read/change/create/delete99) по отношению к объектам данного модуля MIB.

Разработчикам рекомендуется рассмотреть использование средств защиты, обеспечиваемых моделью управления SNMPv3 (см. параграф 8 в [RFC3410]8), включая полную поддержку криптографических механизмов SNMPv3 (для аутентификации и сохранения тайны).

Более того, развертывание SNMP версий до SNMPv3 не рекомендуется. Взамен рекомендуется развертывать системы SNMPv3 и включать криптографические механизмы защиты. В этом случае заказчик/оператор может установить соответствующие права для SNMP-доступа к объектам данного модуля MIB, включая операции GET или SET (change/create/delete).

6. Благодарности

Благодарим за работу всех членов группы Inter-Domain Routing WG и персонально хотим отметить:

Yakov Rekhter, Juniper Networks

Rob Coltun, Redback

Guy Almes, Internet2

Jeff Honig, BSDi

Marshall T. Rose, Dover Beach Consulting, Inc.

Dennis Ferguson, Juniper Networks

Matt Mathis, PSC

John Krawczyk, Bay Networks

Curtis Villamizar, Avici

Dave LeRoy, Pencom Systems

Paul Traina, Juniper Networks

Andrew Partan, MFN

Robert Snyder, Cisco Systems

Dimitry Haskin, Nortel

Peder Chr Norgaard, Telebit Communications A/S

Joel Halpern, CTO Longitude Systems, Inc.

Nick Thille, RedBack Networks

Bert Wijnen, Lucent

Shane Wright, NextHop Technologies

Mike McFadden, Riverstone Networks, Inc.

Jon Saperia, JDS Consulting, Inc.

Wayne Tackabury, Gold Wire Technology, Inc.

Bill Fenner, AT&T Research

RJ Atkinson, Extreme Networks

Dan Romascanu, Avaya

Mathew Richardson, NextHop Technologies

Основой для данного документа является RFC 1269 «Definitions of Managed Objects for the Border Gateway Protocol (Version 3)», который написали Steve Willis и John Burruss, а обновления к этому документу, которые сделал John Chu для поддержки BGP-4 в RFC 1657. редакторы хотят отметить превосходную работу авторов этих исходных документов.

7. Нормативные документы

[BGP4] Rekhter, Y., Li, T., and S. Hares, Eds., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[BGP4APP] Rekhter, Y. and P. Gross, «Application of the Border Gateway Protocol in the Internet», RFC 1772, March 1995.

[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, April 1999.

[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Textual Conventions for SMIv2», STD 58, RFC 2579, April 1999.

[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Conformance Statements for SMIv2», STD 58, RFC 2580, April 1999.

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, «Introduction and Applicability Statements for Internet-Standard Management Framework», RFC 3410, December 2002.

Адреса редакторов

Jeffrey Haas

NextHop Technologies

825 Victor’s Way, Suite 100

Ann Arbor, MI 48103

Phone: +1 734 222-1600

Fax: +1 734 222-1602

EMail: jhaas@nexthop.com

 

Susan Hares

NextHop Technologies

825 Victor’s Way, Suite 100

Ann Arbor, MI 48103

Phone: +1 734 222-1600

Fax: +1 734 222-1602

EMail: skh@nexthop.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).


1Management Information Base – база данных управления.

2Border Gateway Protocol – протокол граничного шлюза.

3Management Information Base – база данных управления.

4Border Gateway Protocol – протокол граничного шлюза.

5Simple Network Management Protocol — простой протокол сетевого управления.

6Structure of Management Information – структура данных управления.

7Модуль MIB для протокола BGP-4.

Copyright (C) The Internet Society (2006). данная версия модуля MIB является частью RFC 4273; полная информация содержится в самом RFC.

8Отличия от RFC 1657:

  1. Исправлены определения уведомлений, чтобы сделать их эквивалентными исходным определениям RFC 1269.
  2. Добавлена информация о соответствии.
  3. Обновлена информация для значений …
  4. Добавлены дополнительные комментарии там, где это требовалось.
  5. Места, где объекты не полностью отражают протокол, помечены, как Known Issues (известные проблемы).
  6. Обновлено описание (DESCRIPTION) объекта bgp4PathAttrAtomicAggregate.
  7. Для перечисленных ниже объектов изменены описания с целью удаления текста, предлагающего (с использованием уровня следует) инициализировать счетчики нулевыми значениями при переходе в состояние Established:…Исполняющие удаленные требования реализации сохраняют совместимость с новыми требованиями. Приложениям не следует предполагать, что отсчет всегда начинается с нуля.

    Опубликовано как RFC 4273.

9Преобразовано в соответствии с SMIv2 и опубликовано как RFC 1657.

10Первоначальный вариант, опубликованный как RFC 1269.

11Вектор номеров поддерживаемых версий протокола BGP. Для каждого партнера согласуется значение номера версии из этого вектора. Версии идентифицируются строкой битов, содержащейся в данном объекте. Первый октет содержит биты от 0 до 7, второй – от 8 до 15 и т. д.. Старший бит помещается в младшую позицию октета и наоборот (например, старший бит первого октета является битом 0). Если бит i присутствует и имеет значение 1, это говорит о том, что поддерживается версия BGP с номером (i+1) .

12Номер локальной автономной системы.

13Таблица BGP Peer. Эта таблица содержит для каждого партнера BGP запись с информацией об этом партнере.

14Таблица BGP Peer. Эта таблица содержит для каждого партнера BGP запись с информацией о соединении с данным партнером.

15Запись, содержащая информацию о соединении с партнером.

16Идентификатор BGP для партнера, с которым связана запись. Это поле должно иметь значение 0.0.0.0, если значение bgpPeerState не равно openconfirm или established.

17Состояние соединения с партнером BGP.

18Желаемое состояние соединения BGP. Переход из состояния stop в состояние start будет приводить к генерации события BGP Manual Start Event. Переход из состояния start в состояние stop будет вызывать генерацию события BGP Manual Stop Event. Этот параметр может использоваться для перезапуска соединений BGP. Следует с осторожностью относиться к предоставлению возможности записи для этого параметра без соответствующей аутентификации.

19Согласованная партнерами версия протокола BGP.

Это поле должно иметь нулевое значение (0) пока переменная bgpPeerState не имеет значения openconfirm или established.

Отметим, что это поле может иметь значение в диапазоне от 0 до 255.

20Локальный адрес IP для этого соединения BGP.

21Локальный номер порта TCP для этого соединения BGP.

22Удаленный адрес IP для этого соединения BGP.

23Удаленный номер порта TCP для этого соединения BGP. Отметим, что объекты bgpPeerLocalAddr, bgpPeerLocalPort, bgpPeerRemoteAddr и bgpPeerRemotePort обеспечивают соответствующие ссылки на стандартную таблицу MIB соединения TCP.

24Номер удаленной AS, полученный в сообщении BGP OPEN.

25Число сообщений BGP UPDATE, полученных через данное соединение.

26Число сообщений BGP UPDATE, переданных через это соединение.

27Общее число сообщений, полученных от удаленного партнера через данное соединение.

28Общее число сообщений, переданных удаленному партнеру через это соединение.

29Код и субкод последней ошибки для данного соединения. При отсутствии ошибок переменная имеет нулевое значение. При наличии ошибок первый байт этого 2-байтового поля типа OCTET STRING содержит код ошибки, а второй байт — субкод.

30Общее число переходов BGP FSM в состояние Established для данного партнера.

31Этот таймер показывает продолжительность (в секундах) нахождения данного партнера в состоянии established или продолжительность последнего состояния established. Переменная устанавливается в 0 при организации нового соединения или загрузке маршрутизатора.

32Временной интервал (в секундах) для таймера ConnectRetry. Рекомендуемое значение — 120 секунд.

33Временной интервал (в секундах) согласованный с партнером для таймера удержания (Hold Timer. Значение этой переменной устанавливается данным узлом BGP путем выбора меньшего из двух значений — bgpPeerHoldTimeConfigured и Hold Time из принятого от партнера сообщения OPEN.

Если эта переменная отличается от нуля, ее значение должно быть не меньше 3 секунд.

Если значение Hold Timer не согласовано с партнером, эта переменная должна иметь нулевое значение (0).

Если bgpPeerHoldTimeConfigured object = 0, данная переменная также должна иметь значение 0.

34Временной интервал (в секундах) для таймера KeepAlive, согласованный с партнером. Значение этого объекта рассчитывается узлом BGP так, чтобы его отношение к bgpPeerHoldTime совпадало с отношением bgpPeerKeepAliveConfigured к значению bgpPeerHoldTimeConfigured.

Если значение таймера KeepAlive не согласовано с партнером, этот объект должен иметь значение (0).

Если bgpPeerKeepAliveConfigured = 0, данный объект также должен иметь значение 0.

35Временной интервал (в секундах) для Hold Time, указанный для данного узла BGP в его соединении с данным партнером. Это значение передается в сообщении OPEN, передаваемом партнеру данным узлом BGP, и сравнивается со значением поля Hold Time в полученном от партнера сообщении OPEN при выборе значение Hold Time (bgpPeerHoldTime) для данного соединения с партнером. Если это поле имеет отличное от 0 значение, оно должно быть не менее 3 секунд. Значение 0 говорит о том, что время удержания (Hold Time) не согласовано с данным партнером. Рекомендуемое значение – 90 секунд.

36Временной интервал (в секундах) для таймера KeepAlive, указанный для данного узла BGP в его соединении с данным партнером. Значение этого объекта будет определять только частоту передачи сообщений KEEPALIVE относительно значения, заданного bgpPeerHoldTimeConfigured; реальный интервал передачи сообщений KEEPALIVE указывается в переменной bgpPeerKeepAlive. Разумным значением для этого таймера является треть (1/3) от значения bgpPeerHoldTimeConfigured. Если данный объект имеет нулевое значение (0), периодической передачи партнеру сообщений KEEPALIVE после организации соединения BGP не происходит. Рекомендуемое значение — 30 секунд.

37Временной интервал (в секундах) для таймера MinASOriginationInterval. Рекомендуемое значение — 15 секунд.

38Временной интервал (в секундах) для таймера MinRouteAdvertisementInterval. Рекомендуемое значение — 30 секунд для соединений EBGP и 5 секунд для соединений IBGP.

39Время (в секундах) прошедшее с момента получения от партнера последнего сообщения BGP UPDATE. При каждом увеличении переменной bgpPeerInUpdates для этого объекта устанавливается нулевое значение (0).

40Значение идентификатора BGP для локальной системы.

41Таблица принятых атрибутов пути (BGP Received Path Attribute Table). Эта таблица содержит по одной записи для каждого пути в сеть (с атрибутами пути), полученного от всех партнеров, использующих BGP версии 3 или ниже. Данная таблица утратила силу и будет заменяется bgp4PathAttrTable.

42Таблица BGP Received Path Attribute содержит информацию о путях в сети адресатов, полученную от партнеров BGP версии 3 или ниже.

43Информация о пути в сеть.

44IP-адрес партнера, от которого получена информация о пути.

45Сети являются внутренними.

46Информация о сетях получена от протокола EGP.

47Информация о сетях получена из иных источников.

48Первичный источник информации о пути.

49Набор AS, через которые проходит путь в сеть. Этот объект возможно лучше представлять как SEQUENCE OF INTEGER. Однако для совместимости с SMI он представляется как OCTET STRING. Каждая AS представляется парой октетов, как показано ниже:

50Адрес граничного маршрутизатора, который следует использовать для сети адресата.

51Необязательная внутренняя метрика AS. Если данный атрибут не задан для маршрута, этот объект имеет значение 0.

52Таблица BGP-4 Received Path Attribute, содержащая по одной записи для каждого пути в сеть (с атрибутами этого пути), полученная от всех партнеров, использующих BGP-4.

53Таблица BGP-4 Received Path Attribute содержит информацию о путях в сети адресатов, полученную от всех партнеров BGP4.

54Информация о пути в сеть.

55IP-адрес партнера, от которого получена информация.

56Размер (в байтах) адресного префикса в поле Network Layer Reachability Information.

57Префикс IP из поля Network Layer Reachability Information. Этот объект представляет собой IP-адрес, содержащий префикс, размер которого задан переменной bgp4PathAttrIpAddrPrefixLen. Все биты за пределами bgp4PathAttrIpAddrPrefixLen имеют нулевые значения.

58Сети являются внутренними.

59Информация о сетях получена от протокола EGP.

60Информация о сетях получена из других источников.

61Исходный источник информации о пути.

62Последовательность сегментов AS, каждый из которых представляется тройкой <тип, размер, значение>.

Тип задается 1-октетным полем, которое может иметь два значения:

1 AS_SET: неупорядоченный набор AS, через которые проходит маршрут из сообщения UPDATE;

2 AS_SEQUENCE: неупорядоченный набор AS, через которые проходит маршрут из сообщения UPDATE.

Длина представляет собой 1-октетное поле, показывающее число AS в поле значения (value).

Поле value (значение) содержит один или множество номеров AS. Каждая AS представляется строкой из 2 октетов:

first-byte-of-pair = ASNumber / 256;

second-byte-of-pair = ASNumber & 255;

Известные проблемы:

— при использовании BGP Confederations поле типа может принимать значение 3 или 4.

— Значение AS Path может иметь размер более 255 октетов, что может приводить к потере данным объектом части информации из AS Path.

63Адрес граничного маршрутизатора, который следует использовать для сети адресата. Этот адрес содержится в поле NEXT_HOP сообщения UPDATE.

64Эта метрика используется для выбора между несколькими точками выхода в смежную автономную систему. Значение -1 говорит об отсутствии данного атрибута.

Известные проблемы:

— Спецификация BGP-4 использует 32-битовое целое число без знака, следовательно данный объект не может представлять весь диапазон.

65Установленный исходным узлом BGP4 уровень предпочтения для анонсируемого маршрута. Значение -1 говорит об отсутствии данного атрибута.

Известные проблемы:

— Спецификация BGP-4 использует 32-битовое целое число без знака, следовательно данный объект не может представлять весь диапазон.

66Написание скорректировано по отношению к RFC 1657

67Если ATOMIC_AGGREGATE присутствует в атрибутах пути, данный объект должен иметь значение lessSpecificRouteNotSelected.

Если атрибут ATOMIC_AGGREGATE отсутствует в пути, данный объект должен иметь значение lessSpecificRouteSelected.

Отметим, что атрибут ATOMIC_AGGREGATE в настоящее время используется в основном с информационной целью.

68Номер AS последнего узла BGP4, выполнявшего агрегирование маршрута. Нулевое значение (0) указывает на отсутствие атрибута.

Отметим, что распространение AS=0 запрещено для Internet.

69IP-адрес последнего узла BGP4, выполнявшего агрегирование маршрута. Нулевое значение (0.0.0.0) указывает на отсутствие атрибута.

70Уровень предпочтения, рассчитанный принимающим узлом BGP4 для анонсируемого маршрута. Значение -1 говорит об отсутствии данного атрибута.

Известные проблемы:

— Спецификация BGP-4 использует 32-битовое целое число без знака, следовательно данный объект не может представлять весь диапазон.

71Маршрут не выбран в качестве лучшего.

72Маршрут выбран в качестве лучшего.

73Состояние выбора данного маршрута в качестве лучшего маршрута BGP4 для данного адресата.

74Один или множество атрибутов пути, которые данный узел BGP4 не смог распознать.

Атрибуты пути записываются в сообщения UPDATE в формате <тип, размер, значение>.

Нулевой размер указывает на отсутствие атрибута.

Октеты за пределами указанного размера не сохраняются в данном объекте.

Известные проблемы:

— атрибуты, понятные данному узлу, но не представленные в этом модуле MIB, становятся недоступными для агента.

75Прерывания (Traps).

— Отметим, что в RFC 1657, переменной bgpTraps некорректно присвоено значение { bgp 7 } и каждое из прерываний, имеющих bgpPeerRemoteAddr некорректно удаляется из OBJECTS. Приведенное ниже определение восстанавливает семантику прерывания, определенную в RFC 1269.

76Событие bgpEstablishedNotification генерируется при переходе BGP FSM в состояние Established.

Данное сообщение NOTIFICATION заменяет собой прежнее уведомление bgpEstablished.

77Событие bgpBackwardTransNotification генерируется при переходе BGP FSM в состояние с меньшим номером.

Данное сообщение NOTIFICATION заменяет собой прежнее уведомление bgpBackwardsTransition.

78{ bgp 7 } запрещено к использованию. Не выделяйте новые объекты или уведомления для этой ветви.

79Использование запрещено.

80Событие bgpEstablished генерируется при переходе BGP FSM в состояние Established.

Данное сообщение NOTIFICATION заменено уведомлением bgpEstablishedNotification.

81Событие bgpBackwardTransition генерируется при переходе BGP FSM в состояние с меньшим номером.

Данное сообщение NOTIFICATION заменено уведомлением bgpBackwardTransNotification.

82Информация о соответствии.

83Заявление о соответствии.

84Заявление о соответствии для объектов, которые реализованы в BGP4 MIB.

85Данный модуль.

86Реализация BGP Notifications является необязательной в данном модуле MIB.

87Заявление о соответствии для запрещенных к использованию объектов в данном модуле BGP4 MIB.

88Группа, содержащая объекты TRAP, которые были некорректно конвертированы из SMIv1 в RFC 1657. Корректная семантика восстановлена для объектов в bgp4MIBNotificationGroup.

89Группа, содержащая объекты, которые относятся к BGP-3 и более ранним версиям.

90Объекты соответствия.

91Набор объектов, обеспечивающих информацию об общем (глобальном) состоянии BGP.

92Набор объектов для управления партнерами BGP.

93Набор объектов для управления элементами BGP-3 и более ранних версий.

Подобно BGP-3, эта группа соответствия утратила силу.

94Набор объектов для управления элементами пути BGP.

95Набор уведомлений для сигнализации об изменении партнерских отношений BGP. Заменено bgp4MIBNotificationGroup.

96Набор уведомлений для сигнализации об изменении партнерских отношений BGP. Заменяет собой bgp4MIBTrapGroup.

97Чтение и запись.

98Чтение и создание.

99Чтение/изменение/создание/удаление.

 




RFC 4272 BGP Security Vulnerabilities Analysis

Network Working Group                                      S. Murphy
Request for Comments: 4272                              Sparta, Inc.
Category: Informational                                 January 2006

Анализ уязвимостей протокола BGP

BGP Security Vulnerabilities Analysis

PDF

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2006).

Тезисы

Протокол BGP-41, как и множество других протоколов разработанных до того, как среда Internet стала зоной риска, создавался без принятия существенных мер по защите передаваемой информации. Внутри протокола BGP отсутствуют механизмы защиты от атак, которые изменяют, удаляют, подменяют или воспроизводят перехваченные данные и могут вносить существенные помехи в работу системы маршрутизации.

В этом документе обсуждаются некоторые вопросы безопасности, связанные с распространением маршрутной информации BGP. Документ не рассматривает вопросов безопасности при пересылке пакетов.

Оглавление

Исключено из версии HTML

1. Введение

Протокол междоменной маршрутизации BGP был создан, когда среда Internet еще не стала столь паскудной, какой она является сегодня. В результате архитектура BGP не включает средств защиты от случайных или обдуманных атак, которые могли бы повредить работе системы маршрутизации Internet.

В этом документе рассматриваются уязвимости протокола BGP, соответствующего спецификации [RFC4271]. Предполагается, что читатель знаком с документами RFC, посвященными протоколу BGP и поведению BGP-систем.

Очевидно, что сеть Internet уязвима для атак с использованием протоколов маршрутизации и BGP в этом смысле не является исключением. Дефектные, некорректно настроенные или преднамеренно искаженные источники могут внести существенные искажения в работу Internet путем вставки ложной маршрутной информации в распространяемые с помощью BGP базы маршрутных данных (путем изменения, подмены или повторного использования пакетов BGP). Существуют также некоторые методы нарушения работы сети в целом путем разрыва связей в системе обмена информацией между узлами BGP. Источниками ложной информации могут служить как внешние хосты (outsider) так и легитимные узлы BGP.

Криптографическая аутентификация обмена данными между партнерами не предусмотрена в BGP. Как и стек TCP/IP, протокол BGP может служить целью всех атак, включая IP spoofing, захват сессий и т. п. Любой сторонний узел может включить правдоподобные сообщения BGP в обмен данными между партнерами BGP и, следовательно, включить в таблицы обманные маршруты или разорвать соединение между партнерами. Любое прерывание связи между партнерами приводит к изменению распространяемой картины маршрутизации. Более того, внешние узлы могут также разрывать соединения между партнерами BGP, обрывая для них сессии TCP с помощью обманных пакетов2. Внешние источники обманной информации BGP могут располагаться в любой точке сети Internet.

Вследствие перечисленных выше проблем текущая спецификация BGP требует от реализаций протокола BGP поддержки механизма аутентификации, описанного в документе [TCPMD5]. Однако требование поддержки механизма аутентификации еще не означает его использования на практике. Механизм [TCPMD5] основан на использовании предустановленного разделяемого секрета (shared secret) и не включает возможностей IPsec [IPsec] по динамическому согласованию этого секрета. Следовательно, использование [TCPMD5] должно быть осознанным решением и не может быть включено автоматически или по умолчанию.

Текущая спецификация BGP также позволяет реализациям протокола принимать соединения от неуказанных в конфигурации партнеров3 ([RFC4271], глава 8). Однако в спецификации отсутствует четкое определение «неуказанного в конфигурации партнера» или способов использования аутентификации [TCPMD5] для таких случаев. Следовательно, анализ данного аспекта безопасности не представляется возможным. Когда будет выпущена спецификация, полностью описывающая эту проблему, анализ безопасности должен стать частью этой спецификации.

Сами узлы BGP могут включать ложные маршрутные данные, маскируясь под другой легитимный узел BGP или рассылая маршрутную информацию от своего имени без должных на то полномочий. Наблюдались случаи, когда некорректно настроенные или неисправные маршрутизаторы становились причиной серьезных нарушений в работе Internet. Легитимные узлы BGP имеют контекст и информацию для создания правдоподобных, но ложных маршрутных данных, и, следовательно, могут служить причиной серьезных нарушений. Криптографическая защита [TCPMD5] и защита работающих устройств не позволяют исключить ложную информацию, полученную от легитимного партнера. Риск нарушений, вызываемых легитимными партнерами BGP, является реальным и должен приниматься во внимание.

Ложные маршрутные данные могут оказывать различное влияние на картину маршрутизации. Если ложные данные удаляют корректную маршрутную информацию для отдельной сети, эта сеть может стать недоступной для части Internet, принявшей ложные данные. Если ложная информация изменяет маршрут в сеть, пакеты, адресованные в эту сеть, могут пересылаться по неоптимальному пути, путь пересылки не будет соответствовать ожидаемой политике или трафик будет просто утерян. В результате трафик в эту сеть может быть задержан на пути, который будет длиннее необходимого. Сеть может стать недоступной для областей, принявших ложные данные. Трафик может быть также направлен по пути, на котором данные могут быть подвергнуты нежелательному просмотру или искажены. Если ложная информация показывает, что автономная система включает сети, которые реально в нее не входят, пакеты для таких сетей могут быть не доставлены из тех частей Internet, которые приняли ложную информацию. Ложные анонсы принадлежности сетей к автономной системе могут также привести к фрагментированию агрегированных адресных блоков в других частях Internet и вызвать проблемы в маршрутизации для других сетей.

К нарушениям в результате таких атак относятся:

starvation (потеря пакетов) — трафик, адресованный узлу, пересылается в ту часть сети, которая не может обеспечить его доставку;

network congestion (перегрузка сети) – через какую-либо часть сети будет пересылаться больше данных, нежели эта сеть способна обработать;

blackhole (черная дыра) – большое количество трафика направляется для пересылки через один маршрутизатор, который не способен справиться с возросшим уровнем трафика и будет отбрасывать часть, большинство или все пакеты;

delay (задержка) – данные, адресованные узлу, пересылаются по более длинному пути, чем обычно;

looping (петли) – данные передаются по замкнутому пути и никогда не будут доставлены;

eavesdrop (перехват) – данные пересылаются через какой-либо маршрутизатор или сеть, которые не должны видеть эти данные, информация при такой пересылке может просматриваться;

partition (разделение сети) — некоторые части кажутся отделенными от сети, хотя на самом деле это не так;

cut (отключение) — некоторые части сети могут казаться отрезанными от сети, хотя реально они подключены;

churn (волны) — скорость пересылки в сеть изменяется быстрыми темпами, что приводит к значительным вариациям картины доставки пакетов (и может неблагоприятно влиять на работу системы контроля насыщения);

instability (нестабильность) – работа BGP становится нестабильной и не удается достичь схождения картины маршрутов;

overload (перегрузка) – сообщения BGP сами по себе становятся значительной частью передаваемого через сеть трафика;

resource exhaustion (истощение ресурсов) – сообщения BGP сами по себе отнимают слишком много ресурсов маршрутизатора (например, пространства таблиц);

address-spoofing (обманные адреса) – данные пересылаются через некий маршрутизатор или сеть, которые являются подставными и могут служить для перехвата или искажения информации.

Эти события могут наблюдаться в рамках одного сетевого префикса или воздействовать на работу сети в целом.

1.1. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

2. Атаки

Протокол BGP, как таковой, подвержен перечисленным ниже типам атак (список получен на основе IAB RFC с рекомендациями по подготовке разделов «Вопросы безопасности4» для RFC [SecCons]).

confidentiality violations (нарушение конфиденциальности) – маршрутные данные BGP передаются в открытом текстовом виде, что позволяет легко перехватывать информацию (конфиденциальность маршрутных данных не является общим требованием).

replay (воспроизведение) — BGP не включает мер по предотвращению повторного использования перехваченных сообщений.

message insertion (вставка сообщений) — BGP не включает защиты от вставки сообщений. Однако, поскольку BGP использует транспорт TCP, при завершенной организации соединения вставка сообщений внешним узлом потребует точного предсказания порядковых номеров (такое предсказание возможно, но весьма затруднено для хороших реализаций TCP) или перехвата сессий.

message deletion (удаление сообщений) — BGP не включает защиты от удаления сообщений. Опять-таки, такие атаки весьма затруднены для качественных реализаций TCP, но исключить их полностью нельзя.

message modification (изменение сообщений) — BGP не включает защиты от изменения сообщений. Синтаксически корректная модификация без изменением размера данных TCP в общем случае будет незаметной.

Man-in-the-middle (атаки с участием человека) — BGP не включает средств защиты от MITM-атак. BGP не использует аутентификации партнеров и такие атаки становятся “детской игрушкой”.

denial of service (атаки на службы) — Хотя ложные маршрутные данные сами по себе могут служить DoS-атакой на конечную систему, пытающуюся передавать данные через сеть, и сеть в целом, некоторые виды ложной информации могут создавать DoS-атаки на сам протокол BGP. Например, анонсирование большого числа более специфичных маршрутов (более длинных префиксов) может привести к росту трафика BGP и размера таблиц маршрутизации, который окажется неприемлемым для системы.

Обязательная поддержка механизма [TCPMD5] будет предотвращать вставку, удаление и изменение сообщений, а также MITM- и DoS-атаки со стороны внешних узлов. Использование [TCPMD5] не защищает от перехвата, но обеспечение конфиденциальности данных не входит в задачи протокола BGP. Механизм [TCPMD5] не обеспечивает зашиты от replay-атак и против них единственным средством защиты являются порядковые номера TCP. Следовательно, возможность организации таких атак на соединения BGP сохраняется и при использовании [TCPMD5], но только в течение очень короткого времени. Механизм [TCPMD5] не обеспечивает защиты от ложных маршрутных данных, распространяемых внутренним источником (insider).

3. Уязвимости и риски

Связанные с протоколом BGP риски обусловлены тремя основными уязвимостями:

  1. BGP не имеет внутреннего механизма обеспечения сильной защиты целостности и актуальности данных, а также аутентификации партнеров для сообщений, передаваемых между узлами BGP.
  2. Отсутствует механизм проверки полномочий AS для анонсируемой информации NLRI.
  3. Отсутствует механизм обеспечения достоверности атрибутов пути, анонсируемых AS.

Первая из перечисленных уязвимостей закрывается обязательной поддержкой [TCPMD5] в спецификации BGP. После развертывания [TCPMD5] целостность сообщения и аутентификация партнеров будут обеспечены. Механизм [TCPMD5] предполагает, что алгоритм MD5 является безопасным, а разделяемый секрет защищен и достаточно сложно предсказуем.

В последующем обсуждении уязвимости будут описываться в терминах машины конечных состояний BGP FSM5. Указанные здесь события определены и обсуждаются в разделе 8 документа [RFC4271]. К таким событиям относятся:

[Административные события]

Событие 2: ManualStop

Событие 8: AutomaticStop

[Таймеры]

Событие 9: ConnectRetryTimer_Expires

Событие 10: HoldTimer_Expires

Событие 11: KeepaliveTimer_Expires

Событие 12: DelayOpenTimer_Expires

Событие 13: IdleHoldTimer_Expires

[События, связанные с соединениями TCP]

Событие 14: TcpConnection_Valid

Событие 16: Tcp_CR_Acked

Событие 17: TcpConnectionConfirmed

Событие 18: TcpConnectionFails

[События, связанные с сообщениями BGP]

Событие 19: BGPOpen

Событие 20: BGPOpen with DelayOpenTimer running

Событие 21: BGPHeaderErr

Событие 22: BGPOpenMsgErr

Событие 23: OpenCollisionDump

Событие 24: NotifMsgVerErr

Событие 25: NotifMsg

Событие 26: KeepAliveMsg

Событие 27: UpdateMsg

Событие 28: UpdateMsgErr

3.1. Уязвимости в сообщениях BGP

Существует 4 типа сообщений BGP — OPEN, KEEPALIVE, NOTIFICATION и UPDATE6. В этом разделе обсуждаются уязвимости, связанные с каждым типом сообщений и возможности внешних атакующих или узлов BGP по использованию этих уязвимостей. Внешние атакующие могут использовать ложные сообщения OPEN, KEEPALIVE, NOTIFICATION или UPDATE для нарушения соединений между партнерами BGP. Они могут также использовать сообщения UPDATE для нарушения маршрутизации без разрыва соединений между партнерами. Внешний атакующий может также нарушить связь между партнерами путем вставки ложных пакетов TCP, которые нарушат обработку соединений TCP. В общем случае возможности внешних атакующих по использованию ложных сообщений BGP и TCP ограничены (но не предотвращаются полностью), благодаря обработке порядковых номеров TCP. Использование [TCPMD5] будет дополнительным отражением таких атак. Партнеры BGP могут сами разрывать соединения между собой в любой момент, используя для этого сообщения NOTIFICATION. Таким образом, использование сообщений OPEN, KEEPALIVE или UPDATE не порождает дополнительного риска. Однако партнеры BGP могут нарушить картину маршрутизации (вполне реально), используя сообщения UPDATE, содержащие ложную маршрутную информацию. В частности, ложные атрибуты ATOMIC_AGGREGATE, NEXT_HOP и AS_PATH, а также некорректное значение NLRI в сообщениях UPDATE могут нарушить маршрутизацию. Использование [TCPMD5] не препятствует этому типу атак со стороны узлов BGP.

Каждый тип сообщений связан с уязвимостями и риском, которые обсуждаются в следующих параграфах.

3.1.1. Заголовок сообщения

Событие 21. Каждое сообщение BGP начинается стандартным заголовком. Во всех случаях синтаксические ошибки в заголовке сообщения будут заставлять узел BGP закрывать соединение, освобождать все выделенные для BGP ресурсы, удалять все маршруты, полученные через это соединение, запускать процесс принятия решений для установки новой картины маршрутов и возвращаться в состояние Idle. В зависимости от реализации может также выполняться операция подавления “колебаний партнера”7. Этот процесс может влиять на время, через которое будет восстанавливаться разорванное соединение с партнером. Внешний атакующий, способный подменять сообщения, включая в них ошибки заголовков, может вызвать широкомасштабное нарушение картины маршрутизации.

3.1.2. OPEN

Событие 19. Прием сообщения OPEN узлом BGP, находящимся в состоянии Connect или Active будет заставлять узел закрыть соединение, освободить все связанные с ним ресурсы BGP, удалить связанные с соединением маршруты, запустить процесс принятия решения и перейти в состояние Idle. Удаление маршрутов приводит к каскадному эффекту, при котором изменения маршрутов распространяются через другие узлы. В зависимости от реализации может выполняться «подавление осцилляций». Этот процесс может влиять на время, через которое будет восстанавливаться разорванное соединение с партнером.

В состоянии OpenConfirm или Established доставка сообщения OPEN может указывать на конфликт в соединении. Если данное соединение отбрасывается, вводится Событие 23 (это событие рассматривается ниже и может приводить к таким же нарушениям картины маршрутизации, какие указаны выше для состояний Connect и Active).

В состоянии OpenSent получение сообщения OPEN будет переводить узел BGP в состояние OpenConfirm. Если внешний узел может передавать ложные сообщения OPEN (для этого требуется очень точная синхронизация), более поздняя доставка сообщения OPEN от легитимного партнера может заставить узел BGP декларировать конфликт в соединении. Процедура детектирования конфликтов может привести к отказу от легитимного соединения.

В результате возможность внешнего атакующего подменять сообщения этого типа может приводить к существенному и широкомасштабному нарушению картины маршрутизации.

Событие 20. Если сообщение OPEN принято при запущенном таймере OpenDelay когда соединение находится в состоянии OpenSent, OpenConfirm или Established, узел BGP будет разрывать соединение, освобождать связанные с ним ресурсы BGP, удалять все связанные с соединением маршруты, запускать процесс принятия решений и переходить в состояние Idle. Удаление маршрутов может вызывать каскадный эффект, при котором изменения маршрутов распространяются через другие узлы. В зависимости от реализации может выполняться “подавление колебаний”. Этот процесс может влиять на время, через которое будет восстанавливаться разорванное соединение с партнером. Поскольку таймер OpenDelay не должен запускаться в перечисленных выше состояниях, описываемый эффект может быть вызван лишь ошибкой в реализации (передается сообщение NOTIFICATION с кодом ошибки «Finite State Machine Error»). Для внешнего атакующего весьма сложно (или невозможно) вызвать такую ошибку FSM.

В состояниях Connect и Active это событие будет приводить к переходу в состояние OpenConfirm. Как и для события 19, если внешний атакующий способен передавать подставные сообщения OPEN, которые будут приниматься при запущенном таймере DelayOpen, последующее прибытие сообщения OPEN (от легитимного партнера) может рассматриваться как конфликт в соединении с отказом от легитимного соединения.

Возможность внешнего атакующего подменять сообщения этого типа может приводить существенному и широкомасштабному нарушению картины маршрутизации.

Событие 22. Ошибки в сообщениях OPEN (например, недопустимое состояние Hold, некорректно сформированное поле Optional Parameter, неподдерживаемая версия и т. п.) будут заставлять узел BGP разрывать соединение, освобождать связанные с ним ресурсы BGP, удалять все связанные с соединением маршруты, запускать процесс принятия решений и переходить в состояние Idle. Удаление маршрутов может вызывать каскадный эффект, при котором изменения маршрутов распространяются через другие узлы. В зависимости от реализации может выполняться “подавление колебаний”. Этот процесс может влиять на время, через которое будет восстанавливаться разорванное соединение с партнером. Следовательно, способность внешнего атакующего передавать обманные сообщения этого типа может приводить к существенным, широкомасштабным нарушениям картины маршрутизации.

3.1.3. KEEPALIVE

Событие 26. Прием сообщения KEEPALIVE в состоянии Connect, Active или OpenSent будет заставлять узел BGP переходить в состояние Idle и отказываться от организации соединения. В зависимости от реализации может выполняться “подавление колебаний”. Этот процесс может влиять на время, через которое будет восстанавливаться разорванное соединение с партнером. Возможность внешнего атакующего передавать подставные сообщения этого типа может вести к нарушению картины маршрутизации. Для осознанного использования этой уязвимости сообщение KEEPALIVE должно быть аккуратно синхронизировано в последовательности сообщений, передаваемых между партнерами. При отсутствии такой синхронизации нарушения картины маршрутизации не произойдет.

3.1.4. NOTIFICATION

Событие 25. Прием сообщения NOTIFICATION в любом состоянии будет заставлять узел BGP разрывать соединение, освобождать связанные с ним ресурсы BGP, удалять все связанные с соединением маршруты, запускать процесс принятия решений и переходить в состояние Idle. Удаление маршрутов может вызывать каскадный эффект, при котором изменения маршрутов распространяются через другие узлы. Кроме того, в состоянии Established в зависимости от реализации может выполняться «подавление колебаний». Этот процесс может влиять на время, через которое будет восстанавливаться разорванное соединение с партнером. Следовательно, способность внешнего атакующего передавать обманные сообщения этого типа может приводить к существенным, широкомасштабным нарушениям картины маршрутизации.

Событие 24. Сообщение NOTIFICATION, содержащее код ошибки Version Error вызывает такой же эффект, как событие 25 с тем лишь отличием, что дополнительная операция “подавления колебаний” не выполняется в состояниях OpenSent и OpenConfirm или в состояниях Connect и Active с запущенным таймером DelayOpen. Следовательно, уровень возможных нарушений будет меньше, поскольку не оказывается воздействия на время восстановления соединения.

3.1.5. UPDATE

Событие 8. Узел BGP может по своему разумению разрывать соединение BGP, если общее число префиксов превышает заданное конфигурационными параметрами значение. В таких случаях сообщение UPDATE может содержать число префиксов, приводящее к превышению заданного порога. Узел BGP будет разрывать соединение, освобождать связанные с ним ресурсы BGP, удалять все связанные с соединением маршруты, запускать процесс принятия решений и переходить в состояние Idle. Удаление маршрутов может вызывать каскадный эффект, при котором изменения маршрутов распространяются через другие узлы. Кроме того, в состоянии Established в зависимости от реализации может выполняться “подавление колебаний”. Этот процесс может влиять на время, через которое будет восстанавливаться разорванное соединение с партнером. Следовательно, способность внешнего атакующего передавать обманные сообщения этого типа может приводить к существенным, широкомасштабным нарушениям картины маршрутизации.

Событие 28. Если сообщение UPDATE имеет некорректный формат, узел BGP будет разрывать соединение, освобождать связанные с ним ресурсы BGP, удалять все связанные с соединением маршруты, запускать процесс принятия решений и переходить в состояние Idle (некорректность формата может быть связана с неверными значениями полей Withdrawn Routes Length, Total Attribute Length или Attribute Length, отсутствием обязательных атрибутов, значением поля Attribute Flags, конфликтующим с Attribute Type Codes, синтаксическими ошибками в ORIGIN, NEXT_HOP или AS_PATH и т. п.). Удаление маршрутов может вызывать каскадный эффект, при котором изменения маршрутов распространяются через другие узлы. Кроме того, в состоянии Established в зависимости от реализации может выполняться “подавление колебаний”. Этот процесс может влиять на время, через которое будет восстанавливаться разорванное соединение с партнером. Следовательно, способность внешнего атакующего передавать обманные сообщения этого типа может приводить к существенным, широкомасштабным нарушениям картины маршрутизации. Когда узел BGP имеет полномочия закрывать соединения по своему усмотрению, этот тип сообщений приводит к дополнительной возможности нарушения картины маршрутизации.

Событие 27. Сообщение UPDATE, полученное в любом состоянии за исключением Established, будет заставлять узел BGP разрывать соединение, освобождать связанные с ним ресурсы BGP, удалять все связанные с соединением маршруты, запускать процесс принятия решений и переходить в состояние Idle. Удаление маршрутов может вызывать каскадный эффект, при котором изменения маршрутов распространяются через другие узлы. Кроме того, в состоянии Established в зависимости от реализации может выполняться “подавление колебаний”. Этот процесс может влиять на время, через которое будет восстанавливаться разорванное соединение с партнером. Следовательно, способность внешнего атакующего передавать обманные сообщения этого типа может приводить к существенным, широкомасштабным нарушениям картины маршрутизации.

В состоянии Established сообщения UPDATE служат для передачи маршрутной информации. Возможность подмены любой части сообщения этого типа, может вести к нарушению картины маршрутизации независимо от того, является источник сообщений внешним атакующим или легитимным узлом BGP.

3.1.5.1. Недопустимые значения Routes Length и Total Path Attribute Length

Существуют уязвимости, связанные с возможностью изменения значений этих полей. При изменении размера корректный разбор сообщения может стать невозможным, что приведет к возникновению ошибки, передаче сообщения NOTIFICATION и разрыву соединения (см. Событие 28, описанное выше). Поскольку корректно настроенный узел BGP имеет возможность в любое время разорвать соединение, эта уязвимость ведет к дополнительному риску только в тех случаях, когда источником является не указанный в конфигурации партнер BGP (т. е., не возникает дополнительного риска со стороны действующих партнеров BGP).

3.1.5.2. Поле WITHDRAWN ROUTES (отозванные маршруты)

Внешний атакующий может уничтожить корректные маршруты путем подмены этого поля. Атакующий может также уничтожить воссозданные (reestablished) маршруты, заново передавая данные об отзыве маршрутов из перехваченных ранее пакетов.

Узел BGP может “ошибочно” отозвать действующие маршруты, используя поле WITHDRAWN ROUTES. Однако, поскольку узел BGP имеет полномочия для всех анонсируемых им маршрутов, он вправе отзывать любые из анонсированных ранее маршрутов. В силу того, что принимающий узел BGP будет реально отзывать только маршруты, связанные с передающим отзыв маршрутов узлом BGP, не возникает возможности отзыва чужих маршрутов. Следовательно, здесь не возникает дополнительного риска со стороны партнеров BGP.

3.1.5.3. Атрибуты пути

С атрибутами пути связано множество уязвимостей и рисков.

  • Attribute Flag, Attribute Type Code, Attribute Length

    Партнер BGP или внешний атакующий может изменить размер или тип (флаги или код типа) атрибута так, чтобы они не соответствовали значению атрибута. При изменении флагов эти флаги и код типа могут стать несовместимыми (например, обязательный атрибут будет указан как частный – partial), дополнительный атрибут может быть интерпретирован как обязательный и наоборот. При изменении кода типа атрибут может быть интерпретирован как тип и значение иного атрибута.

Наиболее очевидным результатом изменения размера, флагов или кода будет ошибка при анализе сообщения UPDATE. Такая ошибка вызовет передачу сообщения NOTIFICATION с последующим разрывом соединения (см. описанное выше событие 28). Поскольку корректно настроенный узел BGP может в любой момент разорвать соединение, эта уязвимость приводит к дополнительному риску только в тех случаях, когда источником является внешний атакующий (т. е., не возникает дополнительного риска со стороны партнеров BGP).

  • ORIGIN

Это поле показывает источник маршрутной информации — IGP или EGP. Поле используется на этапе выбора маршрутов, следовательно, здесь имеется незначительная уязвимость, которая позволяет воздействовать на процесс выбора маршрутов принимающим узлом BGP путем изменения этого поля.

  • AS_PATH

    Партнер BGP или внешний атакующий могут анонсировать значение AS_PATH, не связанное должным образом с NLRI.

    Поскольку партнер BGP может не проверять, что полученное значение AS_PATH начинается с номера AS его партнера, злонамеренный партнер BGP может анонсировать путь, начинающийся с номера AS любого узла BGP с минимальным воздействием на самого себя. Это может повлиять на процесс выбора маршрутов принимающим сообщение узлом BGP. Злонамеренный партнер может указать существенно более короткое значение AS_PATH, которое будет повышать шансы на выбор данного маршрута и, возможно, давать злонамеренному партнеру доступ к трафику, который он обычно не получает. Кратчайшее значение AS_PATH может также приводить к возникновению маршрутных петель, если в нем не содержится информации, требуемой для предотвращения петель.

    Узел BGP может быть настроен так, чтобы он принимал маршруты с номером своей AS в пути. Такие эксплуатационные вопросы определены как “выходящие за пределы” спецификации BGP. Но, поскольку AS_PATH может включать петли, разработчики не имеют возможности автоматически отбрасывать маршруты с петлями. Каждый узел BGP проверяет лишь отсутствие своего номера AS в AS_PATH.

    Вкупе с возможностью использования любых значений NEXT_HOP, это дает злонамеренным узлам BGP значительные возможности управления путями передачи трафика.

  • Originating Routes

    Специальным случаем анонсирования ложных атрибутов AS_PATH является ситуация, когда AS_PATH анонсирует прямое подключение к указанной сети. Партнер BGP или внешний атакующий могут нарушить маршрутизацию в сеть (сети), указанную в поле NLRI, путем рассылки ложных анонсов прямого соединения с сетью. NLRI станет недоступным для части сети, которая воспримет этот ложный маршрут, пока последняя AS из AS_PATH не создаст туннель для пересылаемых пакетов этого NLRI в направлении целевой AS по корректному пути. Но даже после туннелирования пакетов в корректную AS маршрут может быть неоптимальным или несоответствующим заданной политике. Кроме того, может быть оказано воздействие на маршрутизацию для других сетей в Internet, если ложные анонсы фрагментируют агрегированный блок адресов, заставляя маршрутизаторы обрабатывать (передавать сообщения UPDATE, сохранять и поддерживать маршруты) множество фрагментов взамен одного агрегированного маршрута. Фальшивые исходные точки для множества адресов могут приводить к тому, что маршрутизаторы и транзитные сети на анонсированном пути начнут лавинную рассылку потерявшего направление трафика.

  • NEXT_HOP

    Атрибут NEXT_HOP определяет IP-адрес граничного маршрутизатора, который следует использовать как следующий интервал при пересылке пакетов NLRI, указанному в сообщении UPDATE. Если получателем является внешний партнер, адрес получателя и значение NEXT_HOP должны находиться в одной подсети. Очевидно, что внешний атакующий, который изменит это поле, сможет нарушить пересылку трафика между двумя AS.

    Если получатель сообщения является внешним партнером AS и маршрут был получен от другой партнерской AS (это один из двух вариантов «third party» NEXT_HOP), тогда узел BGP, анонсирующий маршрут, имеет возможность направить трафик получателя узлу BGP, указанному адресом NEXT_HOP. Это дает возможность направить трафик на маршрутизатор, который не способен продолжать дальнейшую пересылку трафика. Злонамеренный узел BGP также может воспользоваться этим методом для того, чтобы заставить другую AS передавать трафик, который обычно через нее не проходит. В некоторых случаях это может дать злонамеренному узлу BGP преимущества, поскольку он способен направить передачу трафика по более длинному пути в ту или иную точку, которую он разделяет с атакуемым.

  • MULTI_EXIT_DISC

    Атрибут MULTI_EXIT_DISC используется в сообщениях UPDATE, передаваемых между партнерами, которые находятся в разных AS. Хотя полученное из другой AS значение MULTI_EXIT_DISC может распространяться внутри AS, его нельзя распространять в другие AS. В результате это поле используется только при внутреннем выборе маршрутов для одной AS. Изменение этого поля внешним атакующим или партнером BGP может сделать неоптимальной маршрутизацию внутри AS.

  • LOCAL_PREF

    Атрибут LOCAL_PREF должен включаться во все сообщения для внутренних партнеров и исключаться из сообщений для внешних партнеров. Следовательно, изменение LOCAL_PREF может повлиять только на маршрутизацию внутри AS. Отметим, что в спецификации BGP отсутствует требование согласованности LOCAL_PREF между внутренними узлами BGP одной AS. Поскольку узлы BGP свободны в выборе значения LOCAL_PREF, изменение этого поля является уязвимостью только со стороны внешних атакующих.

  • ATOMIC_AGGREGATE

    Поле ATOMIC_AGGREGATE показывает, что некая AS на пути объединяет несколько маршрутов и анонсирует объединенное значение NLRI без формирования AS_SET, обычно формируемого из AS в AS_PATH агрегированных маршрутов. Узлы BGP, получающие маршрут с ATOMIC_AGGREGATE, не могут делать NLRI более специфичным. Удаление атрибута ATOMIC_AGGREGATE снимает это ограничение и может стать причиной некорректной маршрутизации трафика, предназначенного для более специфичного NLRI. Добавление атрибута ATOMIC_AGGREGATE при отсутствии агрегирования будет давать незначительный эффект за счет того, что неагрегированный NLRI нельзя будет сделать более специфичным. Эта уязвимость существует независимо от того, является источник партнером BGP или внешним атакующим.

  • AGGREGATOR

    Это поле может включаться узлом BGP, который создал маршруты, представленные в сообщении UPDATE, путем объединения других маршрутов. Поле содержит номер AS и IP-адрес последнего сумматора (aggregator) маршрута. Если поле не используется при выборе маршрутов, никакой уязвимости не возникает.

3.1.5.4. NLRI

Изменяя это поле, внешний атакующий или партнер BGP могут нарушить маршрутизацию для анонсируемой сети перегрузить маршрутизатор на анонсируемом пути, вызвать потерю данных, если анонсируемый маршрут не будет передавать трафик в анонсируемую сеть, направить трафик по неоптимальному пути и т. п.

3.2. Использование уязвимостей других протоколов

3.2.1. Сообщения TCP

BGP работает на основе протокола TCP, прослушивая порт 179. Следовательно, протокол BGP уязвим для атак на TCP.

3.2.1.1. TCP SYN

SYN flooding: Подобно другим протоколам, BGP зависит от воздействия на реализацию TCP атак с помощью лавины пакетов SYN, и должен использовать поддерживаемые реализацией механизмы защиты от этого типа атак.

Событие 14. Если внешний атакующий способен передавать SYN-пакеты узлу BGP с достаточной скоростью на этапе организации соединения, пакеты SYN от легитимного партнера будут представляться как другое соединение. Если атакующий способен продолжать передачу последовательности пакетов, приводящей к организации соединения BGP (например, угадывая порядковый номер узла BGP для пакетов SYN ACK), соединения от атакующего и легитимного узла могут вступить в конфликт. В зависимости от результатов детектирования конфликтов (если атакующий выбирает идентификатор BGP, как будто хочет выиграть скачки) корректное соединение с легитимным партнером может быть разорвано. Использование [TCPMD5] может служить отражению таких атак.

3.2.1.2. TCP SYN ACK

Событие 16. Если внешний атакующий способен отвечать на SYN-пакеты узла BGP раньше легитимного партнера, в ответ на SYN-ACK от легитимного партнера будет передаваться пустой отклик ACK, заставляющий легитимного партнера передавать пакет RST, который будет разрывать соединение. Узел BGP будет разрывать соединение, освобождать связанные с ним ресурсы BGP, удалять все связанные с соединением маршруты и запускать процесс выбора маршрутов. Такая атака требует от внешнего атакующего предсказания порядковых номеров, используемых в пакетах SYN. Использование [TCPMD5] может служить отражению таких атак.

3.2.1.3. TCP ACK

Событие 17. Если внешний атакующий способен с достаточной скоростью передавать подставные пакеты ACK на этапе организации соединения, узел BGP может принять решение о завершении этапа организации соединения, передать пакет OPEN (Событие 17) и перейти в состояние OpenSent. Информация о доставке ACK от легитимного партнера не будет передаваться процессу BGP, поскольку будет воспринята как дубликат пакета. Таким образом, это сообщение не создает уязвимости BGP на этапе организации соединения. Подмена ACK после организации соединения требует точного предсказания используемого порядкового номера, что в общем случае является очень сложной задачей. Использование [TCPMD5] может служить отражению таких атак.

3.2.1.4. TCP RST/FIN/FIN-ACK

Событие 18. Если внешний атакующий способен генерировать подставные пакеты RST, узел BGP будет разрывать соединение, освобождать связанные с ним ресурсы BGP, удалять все связанные с соединением маршруты и запускать процесс выбора маршрутов. Если внешний атакующий способен генерировать подставные пакеты FIN, передача данных будет продолжаться, но любая попытка приема будет вызывать уведомление о закрытии соединения. В большинстве случаев это приведет к тому, что соединение будет переведено в состояние Idle. Однако соединения, находящиеся в момент атаки в состоянии Connect или OpenSent, будут возвращаться в состояние Active.

Генерация подставных пакетов RST в такой ситуации требует от атакующего предсказания порядкового номера, который должен попадать в окно приема [Watson04]. В общем случае это более простая задача, нежели точное предсказание порядкового номера, требуемое для успешной подмены FIN. Использование [TCPMD5] может служить отражению таких атак.

3.2.1.5. DoS и DDoS

Поскольку пакеты, направленные в порт TCP с номером 179, передаются процессу BGP, который потенциально является самым медленным процессом в маршрутизаторе, лавина пакетов, адресованных в порт TCP 179 маршрутизатора может использоваться как DoS-атака на маршрутизатор в целом. Протокол BGP не включает механизмов предотвращения таких атак и для их отражения нужны иные методы.

3.2.2. Прочие протоколы

3.2.2.1. Ручная остановка

Событие 2. Ручная остановка заставляет узел BGP разрывать соединение, освобождать связанные с ним ресурсы BGP, удалять все связанные с соединением маршруты и запускать процесс выбора маршрутов. Если механизм, используемый для уведомления узла BGP о ручной установке, недостаточно защищен, соединение BGP может быть разорвано внешним атакующим. Следовательно, безопасность BGP зависит от уровня безопасности протоколов управления и настройки, используемых для передачи сигнала о таких событиях.

3.2.2.2. Open Collision Dump

Событие 23. Событие OpenCollisionDump может генерироваться административным путем при обнаружении конфликта в соединении, если планируется разрыв этого соединения. Когда такое событие происходит, независимо от состояния соединения BGP, это соединение разрывается, освобождаются ресурсы BGP, удаляются связанные с соединением маршруты и т. д. Следовательно, безопасность BGP зависит от уровня безопасности протоколов управления и настройки, используемых для передачи сигнала о таких событиях.

3.2.2.3. Таймеры

События 9-13. Протокол BGP использует 5 таймеров (ConnectRetry, Hold, Keepalive, MinASOrigination-Interval, MinRouteAdvertisementInterval) и дополнительно может использовать еще 2 (DelayOpen и IdleHold). Эти таймеры играют важную роль в работе BGP. Например, при изменении значения таймера Hold удаленный партнер может решить, что соединение не отвечает и разорвать его, освободив ресурсы, удалив связанные маршруты и т. д. Следовательно, безопасность BGP зависит от уровня безопасности протоколов управления и настройки, используемых для управления таймерами.

4. Вопросы безопасности

Весь этот документ посвящен вопросам безопасности и включает анализ уязвимостей протокола BGP.

Использование обязательного для реализации механизма [TCPMD5] снижает уровень угрозы в результате вставки, изменения или удаления сообщений, а также атак с участием человека (man-in-the-middle) со стороны внешних узлов. Если желательно обеспечить конфиденциальность маршрутных данных (это спорный вопрос), эту задачу можно решить с помощью IPsec ESP.

4.1. Остаточный риск

Как криптографические механизмы, [TCPMD5] и IPsec [Ipsec] предполагают, что криптоалгоритм является безопасным, используемые секреты защищены от раскрытия и не могут быть угаданы, а также обеспечивается безопасное управление платформой, предотвращена возможность ее взлома и т. п.

Эти механизмы не предотвращают атак со стороны легитимных BGP-партнеров маршрутизатора. Существует несколько возможных решений для предотвращения вставки узлом BGP ложной информации в анонсы, рассылаемые партнерам (например, для организации атак на сети, из которых начинается маршрут, или AS-PATH):

  1. Защита источника – подпись исходной AS.

  2. Защита источника и соседей – подпись исходной AS или предшествующей информации ([Smith96])
  3. Защита источника и маршрута – подпись исходной AS и подписи AS_PATH для маршрутизаторов, со стороны которых вы хотите предотвратить возможность атаки ([SBGP00]).
  4. Фильтрация – основывается на проверке AS_PATH и NLRI исходной AS ([RPSL]).

Фильтрация используется в некоторых точках подключения пользователей, но неэффективна в “центральных узлах” Internet. Другие механизмы защиты пока обсуждаются и не нашли широкого применения.

4.2. Эксплуатационная защита

Протокол BGP используется прежде всего как средство предоставления данных о доступности автономных систем и распространения информации о доступности внешних сетей внутри AS. BGP является протоколом маршрутизации, используемым для распространения глобальной маршрутной информации в Internet. Следовательно, BGP используется всеми основными сервис-провайдерами (ISP8), а также более мелкими провайдерами и другими организациями.

Роль BGP в Internet помещает реализации протокола BGP в уникальные условия и предъявляет к BGP уникальные требования в части безопасности. Протокол BGP используется на интерфейсах, связывающих провайдеров, где уровни трафика требуют использования специально разработанного оборудования для пересылки пакетов и на многие порядки превосходят возможности шифровального оборудования. Способность атакующего генерировать трафик для организации DoS-атаки на рабочей станции с высокоскоростным интерфейсом значительно превосходит возможности программных систем шифрования или доступного по разумной цене криптографического оборудования, которые можно было бы использовать для детектирования такого трафика. В таких условиях основным средством защиты элементов сети от DoS-атак являются методы фильтрации пакетов на основе достаточно простых проверок. В результате для ISP, обслуживающих значительные объемы трафика, фильтрация пакетов по номерам портов является важным средством защиты от DoS-атак и необходимым дополнением к средствам криптографической инкапсуляции.

В современной практике ISP используют те или иные методы фильтрации общего назначения для снижения риска внешних атак. Для защиты внутренних сессий BGP (IBGP) фильтры реализуют на всех граничных узлах сети ISP. Эти фильтры блокируют весь трафик, адресованный внутренним элементам сети (обычно относящимся к одному префиксу) через порт BGP (179). При обнаружении номера порта BGP, пакеты из внутренней сети ISP не пересылаются с внутреннего интерфейса по адресу узла BGP, на котором поддерживаются внешние сессии BGP (EBGP), или адресам партнеров EBGP. Хорошо спроектированный и настроенный маршрутизатор способен ограничить риск компрометации, когда партнер BGP не может обеспечить должной фильтрации. Этот риск может быть ограничен также путем группировки сессий, в которых партнер не обеспечивает фильтрации, а также интерфейсов, через которые подключены партнеры.

Описанные выше меры существенно осложняют внешним узлам возможность организации DoS-атаки на ISP. Лишенный возможности создания требуемого для организации DoS-атаки внешнего трафика, злоумышленник вынужден будет использовать более сложные способы (например, взлом элементов сети ISP или перехват данных из физической среды).

5. Литература

5.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», RFC 2119, BCP 14, March 1997.

[TCPMD5] Heffernan, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, August 1998.

[RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

5.2. Дополнительная литература

[IPsec] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 240110, November 1998.

[SBGP00] Kent, S., Lynn, C. and Seo, K., «Secure Border Gateway Protocol (Secure-BGP)», IEEE Journal on Selected Areas in Communications, Vol. 18, No. 4, April 2000, pp. 582-592.

[SecCons] Rescorla, E. and B. Korver, «Guidelines for Writing RFC Text on Security Considerations», BCP 72, RFC 3552, July 2003.

[Smith96] Smith, B. and Garcia-Luna-Aceves, J.J., «Securing the Border Gateway Routing Protocol», Proc. Global Internet ’96, London, UK, 20-21 November 1996.

[RPSL] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy, «Routing Policy System Security», RFC 2725, December 1999.

[Watson04] Watson, P., «Slipping In The Window: TCP Reset Attacks»11, CanSecWest 2004, April 2004.

Адрес автора

Sandra Murphy

Sparta, Inc.

7075 Samuel Morse Drive

Columbia, MD 21046

EMail: Sandy@tislabs.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).


1Border Gateway Protocol 4 – протокол граничного шлюза, версия 4.

2Весьма интересны исследования Фернандо Гонта, опубликованные на сайте gont.com.ar/. Прим. перев.

3Unconfigured peer

4Security Considerations.

5Finite State Machine.

6Эти сообщения определены в спецификации протокола [RFC4271]. RFC 2918 определяет дополнительный тип (Type = 5) сообщение — Route-Refresh. Прим. перев.

7Peer oscillation damping/

8Internet Service Providers

10Этот документ признан устаревшим и заменен RFC 4301. Прим. перев.

11Копия этого документа доступна на сайте www.osvdb.org/reference/SlippingInTheWindow_v1.0.doc. Прим. перев.




RFC 4271 A Border Gateway Protocol 4 (BGP-4)

Network Working Group                                Y. Rekhter, Ed.
Request for Comments: 4271                                T. Li, Ed.
Obsoletes: 1771                                        S. Hares, Ed.
Category: Standards Track                               January 2006

Протокол BGP-4

A Border Gateway Protocol 4 (BGP-4)

PDF

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2006).

Тезисы

Этот документ посвящен обсуждению протокола BGP1, который является протоколом маршрутизации между автономными системами (inter-Autonomous System routing protocol).

Основной функцией поддерживающей протокол BGP системы является обмен информацией о доступности сетей с другими системами BGP. Информация о доступности сетей включает список автономных систем (AS), через которые проходит эта информация. Этих сведений достаточно для построения графа связности AS, из которого могут исключаться маршрутные петли (routing loop), а также для принятия некоторых решений на уровне политики AS.

BGP-4 обеспечивает новые механизмы поддержки бесклассовой междоменной маршрутизации (CIDR2). Эти механизмы включают поддержку анонсирования группы адресатов с помощью префикса IP и позволяют обойтись без концепции «класса» сетей в рамках протокола BGP. BGP-4 также добавляет механизм объединения маршрутов, включающий объединение путей AS.

Этот документ прекращает действие RFC 1771.

Оглавление

Исключено в версии HTML

1. Введение

Протокол граничного шлюза (BGP) является протоколом маршрутизации между автономными системами (AS).

Основной функцией поддерживающей протокол BGP системы является обмен информацией о доступности сетей с другими системами BGP. Информация о доступности сетей включает список автономных систем (AS), через которые проходит эта информация. Этих сведений достаточно для построения графа связности AS, из которого могут исключаться маршрутные петли (routing loop), а также для принятия некоторых решений на уровне политики AS.

BGP-4 обеспечивает новые механизмы поддержки бесклассовой междоменной маршрутизации (CIDR) [RFC1518, RFC1519]. Эти механизмы включают поддержку анонсирования группы адресатов с помощью префикса IP и позволяют обойтись без концепции «класса» сетей в рамках протокола BGP. BGP-4 также добавляет механизм объединения маршрутов, включающий объединение путей AS.

Маршрутная информация, передаваемая с использованием BGP поддерживает только парадигму пересылки на основе адреса получателя (destination-based forwarding paradigm), которая предполагает, что маршрутизатор пересылает пакеты, опираясь лишь на адрес получателя, содержащийся в заголовке IP-пакета. Это, в свою очередь, отражает набор правил политики, которые могут быть применены (или не применены) с использованием BGP. Протокол BGP может поддерживать только правила, соответствующие парадигме пересылки по адресу получателя.

1.1. Определения основных терминов

В этом разделе приводятся определения основных терминов, имеющих специфическое толкование в контексте протокола BGP и встречающихся в данном документе.

Adj-RIB-In

Необработанная маршрутная информация, которая анонсируется локальному узлу BGP его партнерами.

Adj-RIB-Out

Adj-RIBs-Out содержит маршруты, анонсируемые указанным партнерам BGP с помощью сообщений UPDATE, передаваемых локальным узлом BGP.

Autonomous System (AS) — автономная система

В соответствии с классическим определением автономная система представляет собой набор маршрутизаторов, находящихся под единым административным управлением, использующих один протокол внутридоменной маршрутизации (interior gateway protocol или IGP) и общую метрику для определения маршрутизации пакетов внутри AS, а также использующих протокол междоменной маршрутизации для определения маршрутов пересылки пакетов в другие AS. С момента создания этого определения для AS стало общепринятым использование нескольких протоколов IGP, а в некоторых случаях и нескольких наборов метрик. Использование термина AS в таких случаях подчеркивает, что даже при наличии нескольких IGP и метрик администрирование AS с точки зрения других автономных систем представляет собой единый согласованный план маршрутизации и согласованную картину адресатов, доступных через данную AS.

BGP Identifier — идентификатор BGP

4-октетное целое число без знака, идентифицирующее узел BGP, отправляющий сообщение BGP. Данный узел BGP устанавливает в качестве значения BGP Identifier адрес IP, присвоенный узлу. Значение идентификатора BGP задается при старте системы и совпадает для всех локальных интерфейсов и самого узла BGP.

BGP speaker — узел BGP

Маршрутизатор, поддерживающий протокол BGP.

EBGP

External BGP (BGP-соединение с внешним партнером).

External peer — внешний партнер

Партнер BGP, относящийся к другой (внешней по отношению к локальной системе) AS.

Feasible route — подходящий маршрут

Анонсируемый маршрут, который пригоден для использования получателем.

IBGP

Internal BGP (BGP-соединение с внутренним партнером).

Internal peer — внутренний партнер

Партнер BGP, относящийся к той же AS, что и локальная система.

IGP — протокол внутреннего шлюза

Interior Gateway Protocol — протокол маршрутизации, используемый для обмена маршрутной информацией между маршрутизаторами одной AS.

Loc-RIB

Loc-RIB содержит маршруты, выбранные процессом принятия решений (Decision Process) локального узла BGP.

NLRI

Network Layer Reachability Information — информация о доступности на сетевом уровне.

Route — маршрут

Единица информации, связывающая набор адресатов с атрибутами пути к этим адресатам. Набор адресатов представляет собой системы, чьи адреса IP содержатся в одном префиксе IP, передаваемом в поле NLRI сообщения UPDATE. Путь представляет собой информацию, содержащуюся в поле атрибутов пути того же сообщения UPDATE.

RIB

Routing Information Base — база маршрутной информации.

Unfeasible route — неподходящий маршрут

Анонсированный ранее подходящий маршрут, который утратил доступность.

1.2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

2. Благодарности

Первый вариант этого документа был опубликован в RFC 1267 (октябрь 1991), который подготовили Kirk Lougheed (Cisco Systems) и Yakov Rekhter (IBM).

Авторы выражают свою благодарность Guy Almes (ANS), Len Bosack (Cisco Systems) и Jeffrey C. Honig (Cornell University) за их вклад в подготовку предварительных вариантов документа.

Отдельно отметим Bob Braden (ISI) за обзор предварительных вариантов документа и конструктивные замечания.

Благодарим также Bob Hinden (директор по маршрутизации в IESG1) и команду специалистов, подготовивших обзор предыдущей версии документа (BGP-2). Эта команда, в состав которой входят Deborah Estrin, Milo Medin, John Moy, Radia Perlman, Martha Steenstrup, Mike St. Johns и Paul Tsuchiya, показала в работе высокий уровень профессионализма, упорство и такт.

Некоторые фрагменты этого документа были заимствованы из протокола IDRP [IS10747], являющегося аналогом BGP в OSI. В связи с этим следует отметить работу группы ANSI X3S3.3 под руководством Lyman Chapin и Charles Kunzinger, который также был редактором IDRP в этой группе.

Авторы также выражают свою признательность Benjamin Abarbanel, Enke Chen, Edward Crabbe, Mike Craren, Vincent Gillet, Eric Gray, Jeffrey Haas, Dimitry Haskin, Stephen Kent, John Krawczyk, David LeRoy, Dan Massey, Jonathan Natale, Dan Pei, Mathew Richardson, John Scudder, John Stewart III, Dave Thaler, Paul Traina, Russ White, Curtis Villamizar, Alex Zinin за их комментарии.

Отдельной благодарности заслуживает Andrew Lange за его помощь в подготовке окончательного варианта этого документа.

И, наконец, благодарим всех членов группы IDR за их идеи и поддержку в процессе создания этого документа.

3. Основы работы протокола

Протокол граничного шлюза BGP является протоколом маршрутизации между автономными системами3. Он создан на основе опыта, полученного при разработке протокола EGP (определен в [RFC904]) и его использовании в магистралях NSFNET ([RFC1092] и [RFC1093]). Дополнительную информацию о протоколе BGP можно найти в документах [RFC1772], [RFC1930], [RFC1997] и [RFC2858].

Основной функцией поддерживающей протокол BGP системы является обмен информацией о доступности сетей с другими системами BGP. Информация о доступности сетей включает список автономных систем (AS), через которые проходит эта информация. Этих сведений достаточно для построения графа связности AS, из которого могут исключаться маршрутные петли (routing loop), а также для принятия некоторых решений на уровне политики AS.

В контексте этого документа предполагается, что узел BGP анонсирует своим партнерам только те маршруты, которые он сам использует (т. е., узел BGP говорит, что он «использует» маршрут BGP, если тот является наиболее предпочтительным из BGP-маршрутов и применяется для пересылки пакетов). Рассмотрение прочих случаев не входит в задачи данного документа.

В контексте этого документа термин «IP-адрес» относится к адресам протокола IP версии 4 [RFC791].

Маршрутная информация, передаваемая с использованием BGP, поддерживает только парадигму пересылки на основе адреса получателя, которая предполагает, что маршрутизатор пересылает пакет исключительно на основе адреса получателя, содержащегося в заголовке IP-пакета. Это, в свою очередь, отражает набор правил политики, которые могут быть применены (или не применены) при использовании BGP. Протокол BGP может поддерживать только правила, соответствующие парадигме пересылки по адресу получателя. Отметим, что некоторые правила не могут поддерживаться в рамках парадигмы пересылки на основе адреса получателя и требуют использования иных методов типа маршрутизации, задаваемой отправителем (source routing или explicit routing). Такие правила не могут быть реализованы в рамках BGP. Например, BGP не позволяет одной AS, передающей трафик в соседнюю AS для пересылки тому или иному адресату (достижимому через эту AS, но не относящемуся к ней), предполагать, что этот трафик будет доставляться адресату иным путем, нежели трафик, исходящий из соседней AS (для того же адресата). С другой стороны, BGP может поддерживать любую политику, согласующуюся с парадигмой пересылки на основе адреса получателя.

BGP-4 обеспечивает новые механизмы поддержки бесклассовой междоменной маршрутизации (CIDR) [RFC1518, RFC1519]. Эти механизмы включают поддержку анонсирования набора адресатов в форме префикса IP и позволяют обойтись без концепции «класса» сетей в рамках BGP. BGP-4 также включает механизм объединения маршрутов, включающий объединение путей AS.

В этом документе используется термин «автономная система» (AS). По классическому определению автономная система представляет собой множество маршрутизаторов с единым техническим администрированием, использующих один протокол внутренней маршрутизации (IGP) и единую метрику для маршрутизации пакетов внутри AS, а для передачи пакетов в другие автономные системы применяющих протокол внешней маршрутизации (exterior gateway protocol или EGP). Со временем классическое определение AS было расширено и в современном понимании AS может использовать несколько протоколов внутренней маршрутизации, а в некоторых случаях даже несколько наборов метрик в рамках одной AS. Применение термина AS в таких случаях обусловлено тем, что даже при использовании множества метрик и протоколов IGP администрирование такой AS с точки зрения других автономных систем выглядит как единый план внутренней маршрутизации и показывает согласованную картину доступности адресатов через данную AS.

BGP использует в качестве транспортного протокол TCP [RFC793]. Это избавляет от необходимости реализации явного фрагментирования уведомлений, повторной передачи и порядковых номеров. BGP слушает протокол TCP через порт 179. Механизм уведомлений об ошибках, используемый в BGP, предполагает, что TCP поддерживает аккуратное завершение соединений (т. е., все остающиеся данные будут доставлены прежде, чем соединение будет закрыто).

Между парой систем организуется соединение TCP. После этого системы обмениваются между собой стандартными сообщениями для согласования и подтверждения параметров соединения.

Первоначальный поток данных является частью таблицы маршрутизации BGP, которая разрешена политикой экспорта, и называется Adj-Ribs-Out (Параграф 3.2). В дальнейшем при при изменении таблицы маршрутов передаются нарастающие обновления. BGP не требует периодического обновления таблицы маршрутизации. Чтобы локальные изменения политики могли вступать в силу без сброса соединений, узлу BGP следует (a) сохранять текущую версию маршрутов, анонсированных ему всеми партнерами в течение работы соединения или (b) использовать расширение Route Refresh4 [RFC2918].

Для обеспечения сохранности соединения периодически передаются сообщения KEEPALIVE. Сообщения NOTIFICATION передаются в ответ на ошибки или при возникновении особых условий. При возникновении ошибок в соединении передается сообщение NOTIFICATION и соединение закрывается.

Партнер в другой AS называется внешним партнером (external peer), а партнер из той же AS называется внутренним (internal peer). Для внутренних и внешних соединений BGP обычно используются аббревиатуры IBGP и EBGP, соответственно.

Если отдельная AS имеет множество узлов BGP и обеспечивает транзит для других AS, внутри этой системы должна обеспечиваться согласованная картина маршрутизации, обеспечиваемая протоколом внутренней маршрутизации (IGP) данной AS. В целях данного документа принимается допущение, что согласованная картина путей за пределы AS обеспечивается за счет организации каждым узлом BGP внутри данной AS соединений IBGP всеми остальными узлами BGP в этой AS.

Данный документ задает поведение протокола BGP. Это поведение может быть изменено (и изменяется) дополнительными спецификациями. При расширении протокола новое поведение полностью документируется в спецификациях расширения.

3.1. Маршруты — анонсирование и хранение

В целях данного протокола маршрут определяется как единица информации, связывающая набор адресатов с путем к этим адресатам. Набором адресатов являются системы, чьи адреса IP содержатся в одном префиксе IP, указываемом полем NLRI5 сообщения UPDATE, а путь представляет собой информацию, задаваемую в поле атрибутов пути того же сообщения UPDATE.

Маршруты анонсируются между узлами BGP в сообщениях UPDATE. Множество маршрутов с одинаковыми атрибутами пути может быть объединено в одном сообщении UPDATE путем включения множества префиксов в поле NLRI сообщения UPDATE.

Маршруты хранятся в базах маршрутных данных (RIB) Adj-RIBs-In, Loc-RIB и Adj-RIBs-Out, описанных в параграфе 3.2.

Если узел BGP решает анонсировать полученный ранее маршрут, он может добавить или изменить атрибуты пути перед анонсированием маршрута партнерам.

Протокол BGP обеспечивает механизмы, позволяющие узлам BGP информировать своих партнеров о том, что анонсированный ранее маршрут перестал быть доступным. Существует три метода, которые данный узел BGP может использовать для указания отзываемых маршрутов.

  1. Префикс IP, указывающий адресата ранее анонсированного маршрута, может быть анонсирован в поле WITHDRAWN ROUTES сообщения UPDATE и соответствующий маршрут будет помечен как недоступный для дальнейшего использования.

  2. Замена маршрута с сохранением ранее анонсированного значения NLRI.

  3. Узел BGP может закрыть соединение, что приведет к удалению всех маршрутов, которые данная пара узлов анонсировала друг другу.

Изменение одного или нескольких атрибутов маршрута сопровождается анонсированием замены. Анонсируемый измененный маршрут содержит иные атрибуты, но имеет такой же префикс, как и ранее анонсированный маршрут.

3.2. База маршрутной информации RIB

База маршрутной информации (RIB6) узла BGP состоит из трех отдельных частей.

  1. Adj-RIBs-In — маршрутные данные, полученные из входящих сообщений UPDATE, которые были приняты от других узлов BGP. Эта база представляет маршруты, которые могут использоваться как входные данные для процесса принятия решения (Decision Process).

  2. Loc-RIB — локальная маршрутная информация узла BGP, выбранная путем применения локальной политики к маршрутам, содержащимся в Adj-RIBs-In. Эти маршруты будут использоваться локальным узлом BGP. Значения next hop для каждого из этих маршрутов должны быть преобразуемыми с помощью таблицы маршрутизации (Routing Table) локального узла BGP.

  3. Adj-RIBs-Out — информация локального узла BGP, выбранная им для анонсирования своим партнерам. Маршрутные данные из Adj-RIBs-Out будут передаваться от локального узла BGP в сообщениях UPDATE для анонсирования партнерам.

Таким образом, Adj-RIBs-In содержит необработанные маршрутные данные, которые были анонсированы локальному узлу BGP его партнерами, Loc-RIB содержит маршруты, которые выбраны в процессе принятия решения локальным узлом BGP, Adj-RIBs-Out содержит маршруты для анонсирования заданным партнерам (в передаваемых локальным узлом сообщениях UPDATE).

Хотя концептуальная модель различает базы Adj-RIBs-In, Loc-RIB и Adj-RIBs-Out, это не требует от реализации протокола поддержки трех отдельных копий маршрутной информации. Выбор способа хранения маршрутных данных (например в 3 копиях или 1 копии с указателями) не задается протоколом.

Маршрутная информация, которую узел BGP использует для пересылки пакетов (или создания таблицы, используемой для пересылки пакетов), сохраняется в таблице маршрутизации. Таблица маршрутизации включает маршруты в непосредственно подключенные сети, статические маршруты, маршруты, полученные от протоколов IGP, и маршруты, полученные от BGP. Включение того или иного маршрута BGP в таблицу маршрутизации или замена маршрута, полученного из других источников, маршрутом BGP определяются локальной политикой, а не спецификациями данного документа. В дополнение к пересылке пакетов таблица маршрутизации используется для преобразования адресов next-hop, заданных в обновлениях BGP (Параграф 5.1.3).

4. Формат сообщений

В этой главе описан формат сообщений BGP.

Сообщения BGP передаются через соединения TCP. Обработка сообщений производится только после того, как сообщение будет принято полностью. Максимальный размер сообщения составляет 4096 октетов. Все реализации протокола должны поддерживать сообщения максимального размера. Наименьшее сообщение, которое может быть передано, содержит заголовок BGP (19 октетов) без поля данных.

Многооктетные поля передаются с использованием сетевого порядка байтов.

4.1. Формат заголовка

Каждое сообщение BGP имеет заголовок фиксированного размера, за которым может (но не обязано) следовать поле данных, зависящих от типа сообщения. Схема заголовка показана на рисунке.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

+ +

| |

+ +

| Marker |

+ +

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Length | Type |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Marker — маркер

Это 16-октетное поле включено для обеспечения совместимости7 и должно содержать 1 в каждом бите.

Length — размер

Это 2-октетное целое число без знака показывает общий размер сообщения, (включая заголовок) в октетах. По этому значению можно найти следующее сообщение (начало поля Marker) в потоке TCP. Значение поля Length должно быть не менее 19 и не более 4096. В зависимости от типа сообщения на значение поля размера могут накладываться дополнительные ограничения. Заполнение сообщения дополнительными октетами (padding) после данных не допускается. Следовательно, значение поля Length должно быть наименьшим числом, которое позволит включить оставшуюся часть сообщения.

Type — тип

Это 1-октетное целое число без знака содержит код типа сообщения. В данном документе определяются следующие коды типов сообщений:

1 — OPEN

2 — UPDATE

3 — NOTIFICATION

4 — KEEPALIVE

В [RFC2918] определен один дополнительный код типа8.

4.2. Формат сообщения OPEN

После организации соединения TCP первое сообщение от каждой из сторон соединения имеет тип OPEN. После восприятия сообщения OPEN узел BGP возвращает подтверждающее сообщение KEEPALIVE.

В дополнение к стандартному заголовку BGP сообщение OPEN содержит показанные на рисунке поля.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+

| Version |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| My Autonomous System |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Hold Time |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| BGP Identifier |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Opt Parm Len |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

| Optional Parameters (переменный размер) |

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Version — версия

1-октетное целое число без знака, показывающее номер версии протокола. Текущая версия BGP имеет номер 4.

My Autonomous System — моя АС

Это 2-октетное целое число без знака показывает номер AS отправителя сообщения9.

Hold Time — время удержания

Это 2-октетное целое число без знака показывает число секунд, которое отправитель предлагает установить для таймера удержания (Hold Timer). При получении сообщения OPEN узел BGP должен выбрать значение таймера, используя меньшее из значений Hold Time в локальной конфигурации и принятом сообщении OPEN. Значение Hold Time должно быть нулевым или не менее 3 секунд. Реализация может отвергать соединения по значению поля Hold Time. Рассчитанное значение показывает максимальное время (в секундах), которое может проходить между получением от партнера сообщений KEEPALIVE и/или UPDATE.

BGP Identifier — идентификатор BGP

Это 4-октетное целое число без знака показывает идентификатор BGP отправителя сообщения. Узел BGP устанавливает в качестве идентификатора BGP адрес IP, присвоенный этому узлу BGP. Значение идентификатора BGP определяется при старте узла и совпадает для всех локальных интерфейсов и самого узла BGP.

Optional Parameters Length — размер дополнительных параметров

Это 1-октетное целое число без знака показывает общий размер поля Optional Parameters в октетах. Нулевое значение этого поля говорит об отсутствии дополнительных параметров.

Optional Parameters — дополнительные параметры

0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-…

|Parameter Type | Размер | Значение (перемен.)

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-…

Это поле содержит список дополнительных параметров, представленных в формате <Parameter Type, Parameter Length, Parameter Value>.

Однооктетное поле типа (Parameter Type) обеспечивает однозначную идентификацию параметра. Однооктетное поле размера (Parameter Length) показывает размер поля Parameter Value в октетах. Значение параметра (Parameter Value) имеет переменный размер и интерпретируется в соответствии с типом (Parameter Type).

В [RFC3392] определен дополнительный параметр Capabilities (возможности).

Минимальный размер сообщения OPEN составляет 29 октетов (с учетом заголовка).

4.3. Формат сообщения UPDATE

Сообщения UPDATE используются для передачи маршрутной информации между партнерами BGP. Данные из сообщений UPDATE могут использоваться для построения графа, описывающего связи между различными AS. Применение обсуждаемых в этом документе правил позволяет избавиться от петель и некоторых других аномалий в маршрутизации между AS.

Сообщение UPDATE служит для анонсирования доступных маршрутов с общими атрибутами пути узлу-партнеру или для отзыва группы анонсированных ранее маршрутов (Параграф 3.1). Сообщение UPDATE может одновременно анонсировать доступный маршрут и отзывать группу недоступных более маршрутов. Сообщения UPDATE всегда включают заголовок BGP фиксированного размера, а также другие поля, показанные на рисунке (отметим, что некоторые из этих полей являются необязательными).

+——————————————————+

| Withdrawn Routes Length (2 октета) |

+——————————————————+

| Withdrawn Routes (перемен.) |

+——————————————————+

| Total Path Attribute Length (2 октета) |

+——————————————————+

| Path Attributes (перемен.) |

+——————————————————+

| Network Layer Reachability Information (перемен.) |

+——————————————————+


Withdrawn Routes Length — размер аннулируемых маршрутов

Это 2-октетное целое число без знакa указывает общий размер поля Withdrawn Routes в октетах. Значение этого поля должно позволять определение размера поля Network Layer Reachability Information в соответствии с приведенным ниже описанием.

Нулевое значение говорит об отсутствии отзываемых маршрутов и поля Withdrawn Routes в сообщении UPDATE.

Withdrawn Routes — отзываемые маршруты

+—————————+

| Length (1 октет) |

+—————————+

| Prefix (перемен.) |

+—————————+

Это поле переменной длины содержит список префиксов IP-адресов для маршрутов, которые отзываются. Каждый префикс представляется парой <length, prefix> в формате, показанном на рисунке.

Ниже описано назначение полей.

  1. Length — размер

    Поле Length показывает размер адресного префикса IP в битах. Нулевое значение размера указывает на префикс, которому соответствуют все адреса IP (сам префикс содержит 0 октетов).

  2. Prefix — префикс

    Поле Prefix содержит префикс адресов IP, за которым следует минимально возможное количество битов заполнения, служащих для выравнивания по границе октета. Отметим, что значения битов заполнения не принимаются во внимание.

Total Path Attribute Length — общий размер атрибутов пути.

Это 2-октетное целое число без знака показывает общий размер поля Path Attributes в октетах. Данное значение позволяет определить размер поля Network Layer Reachability Information, как описано ниже.

Нулевое значение поля говорит об отсутствии полей Network Layer Reachability Information и Path Attribute в данном сообщении UPDATE.

Path Attributes — атрибуты пути

Последовательность переменной длины с атрибутами пути присутствует в каждом сообщении UPDATE за исключением тех сообщений, которые служат только для отзыва маршрутов. Каждый атрибут пути представляется триплетом <attribute type, attribute length, attribute value> переменной длины.

0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Attr. Flags |Attr. Type Code|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле типа (Attribute Type) является двухоктетным и состоит из октета флагов (Attribute Flags), за которым следует октет кода типа (Attribute Type Code).

Старший бит (бит 0) октета Attribute Flags является флагом Optional и показывает относится данный атрибут к числу дополнительных (1) или общеизвестных (0).

Следующий по старшинству бит (бит 1) октета Attribute Flags является флагом транзитивности (Transitive), который определяет является атрибут транзитивным10 (1) или нетранзитивным (0).

Для общеизвестных (well-known) атрибутов флаг Transitive должен устанавливаться в 1 (см. обсуждение транзитивных атрибутов в разделе 5).

Следующий бит (бит 2) октета Attribute Flags является флагом Partial и показывает, является информация, содержащаяся в дополнительном транзитивном атрибуте частичной (1) или полной (0). Для общеизвестных атрибутов и дополнительных непереходных атрибутов флаг Partial должен иметь значение 0.

Четвертый по старшинству бит (бит 3) октета Attribute Flags является флагом расширенного размера (Extended Length) и определяет размер поля Attribute Length — 1 октет (0) или 2 октета (1).

Четыре младших бита октета Attribute Flags не используются. Отправитель должен устанавливать для них нулевые значения, а получатель должен игнорировать эти биты.

Октет Attribute Type Code содержит код типа атрибута. Определенные в настоящий момент коды типов перечислены в разделе 5.

Если бит Extended Length октета Attribute Flags имеет значение 0, третий октет Path Attribute содержит значение размера данных атрибута в октетах. При значении бита Extended Length = 1 третий и четвертый октеты атрибута пути содержат размер данных атрибута в октетах.

Остальные октеты поля Path Attribute представляют собой значение атрибута и интерпретируются в соответствии со значениями октетов Attribute Flags и Attribute Type Code. Коды поддерживаемых типов (Attribute Type Code) и значения их атрибутов описаны ниже.

  1. ORIGIN (тип 1)

Атрибут ORIGIN относится к числу общеизвестных и обязательных, определяя источник маршрутной информации. Октет данных может содержать значения, приведенные в таблице.

Значение

Описание

0

IGP — данные NLRI являются внутренними для исходной AS

1

EGP — данные NLRI получены от протокола EGP [RFC904]

2

INCOMPLETE — данные NLRI получены из иных источников.

Использование этого атрибута рассматривается в параграфе 5.1.1.

  1. AS_PATH (тип 2)

    Общеизвестный обязательный атрибут AS_PATH состоит из последовательности сегментов AS path. Каждый сегмент представляется триплетом <path segment type, path segment length, path segment value>.

    Тип сегмента пути (path segment type) представляет собой 1-октетное поле, для которого определены приведенные в таблице значения.

    Значение

    Тип сегмента

    1

    AS_SET — неупорядоченный набор AS, через которые проходит маршрут из сообщения UPDATE.

    2

    AS_SEQUENCE — упорядоченный набор AS (последовательность), через которые проходит маршрут из сообщения UPDATE.

    Размер сегмента пути (path segment length) представляет собой 1-октетное поле, в котором указывается число номеров AS (не число октетов) в поле path segment value. Поле сегмента пути (path segment value) содержит один или множество номеров AS, каждый из которых представляется 2-октетным11 полем. Использование этого атрибута рассматривается в параграфе 5.1.2.

  2. NEXT_HOP (тип 3)

    Этот общеизвестный обязательный атрибут определяет (индивидуальный12) IP-адрес маршрутизатора, который следует использовать в качестве следующего этапа на пути к адресатам, указанным в поле NLRI сообщения UPDATE.

    Использование этого атрибута рассматривается в параграфе 5.1.3.

  3. MULTI_EXIT_DISC (тип 4)

    Этот необязательный, непереходный атрибут представляет собой 4-октетное целое число без знака. Значение атрибута может использоваться узлом BGP в процессе выбора маршрутов (Decision Process) для разделения множества точек входа в соседнюю АС.

    Использование этого атрибута рассматривается в параграфе 5.1.4.

  4. LOCAL_PREF (тип 5)

    Общеизвестный атрибут LOCAL_PREF представляет собой 4-октетное целое число без знака. Узел BGP использует этот атрибут для информирования внутренних партнеров, показывая свой уровень предпочтения для анонсируемого маршрута.

    Использование этого атрибута рассматривается в параграфе 5.1.5.

  5. ATOMIC_AGGREGATE (тип 6)

    ATOMIC_AGGREGATE является общеизвестным необязательным атрибутом нулевой длины.

    Использование этого атрибута рассматривается в параграфе 5.1.6.

  6. AGGREGATOR (тип 7)

    Необязательный транзитивный атрибут AGGREGATOR имеет размер 6 октетов. Этот атрибут содержит номер последней AS, формирующей агрегированный маршрут (2 октета), после которого указан IP-адрес узла BGP, создавшего агрегированный маршрут (4 октета). Для этого поля следует устанавливать тот же адрес, который используется для поля BGP Identifier узла, создавшего агрегированный маршрут.

    Использование этого атрибута рассматривается в параграфе 5.1.7.

Network Layer Reachability Information

Это поле переменной длины содержит список адресных префиксов IP. Число октетов в поле Network Layer Reachability Information не задается явно, но может быть вычислено по формуле:

Поле Length сообщения UPDATE — 23 — Total Path Attributes Length — Withdrawn Routes Length

Значение поля Length для сообщения UPDATE указано в постоянной части заголовка BGP, Значения полей Total Path Attribute Length и Withdrawn Routes Length указываются в переменной части сообщения UPDATE, а 23 представляет собой суммарный размер постоянного заголовка BGP и полей Total Path Attribute Length, Withdrawn Routes Length.

+—————————+

| Length (1 октет) |

+—————————+

| Prefix (переменный размер)|

+—————————+

Информация о доступности представляется в форме одной или множества пар <length, prefix>.

Назначение полей пары описано ниже.

  1. Length — размер

    Поле Length показывает размер адресного префикса IP в битах. Нулевое значение размера указывает на префикс, которому соответствуют все адреса IP (сам префикс содержит 0 октетов).

  2. Prefix — префикс

    Поле Prefix содержит префикс адресов IP, за которым следует минимально возможное количество битов заполнения, служащих для выравнивания по границе октета. Отметим, что значения битов заполнения не принимаются во внимание.

Минимальный размер сообщения UPDATE составляет 23 октета; 19 занимает постоянный заголовок BGP, 2 октета — поле Withdrawn Routes Length и 2 октета — Total Path Attribute Length (поля Withdrawn Routes Length и Total Path Attribute Length в этом случае содержат значение 0).

Сообщение UPDATE может анонсировать не более одного набора атрибутов пути, но этому пути может соответствовать множество адресатов, путь к которым описывается общим набором атрибутов. Все атрибуты пути, содержащиеся в данном сообщении UPDATE, применимы к каждому из адресатов, соответствующих значению поля NLRI в сообщении UPDATE.

Сообщение UPDATE может содержать множество аннулируемых маршрутов. Каждый из таких маршрутов идентифицируется своим адресатом (указывается префиксом IP), однозначно определяющим маршрут в контексте соединения между парой узлов BGP, для которого ранее этот маршрут был анонсирован.

Сообщение UPDATE может анонсировать только отзываемые маршруты — в таких случаях сообщение не будет включать атрибутов пути и поля NLRI. Если же сообщение анонсирует только доступные маршруты, в него не требуется включать поле WITHDRAWN ROUTES.

В сообщениях UPDATE не следует указывать один и тот же префикс в полях WITHDRAWN ROUTES и NLRI. Однако узел BGP должен быть способен к обработке сообщений такого типа. Узлу BGP следует трактовать такие сообщения UPDATE, как будто они не содержат адресного префикса в поле WITHDRAWN ROUTES.

4.4. Формат сообщения KEEPALIVE

BGP не использует на уровне TCP каких-либо механизмов для проверки доступности других узлов. Вместо этого используются сообщения KEEPALIVE, которыми партнеры обмениваются достаточно часто, чтобы между двумя сообщениями не истекло время, заданное таймером удержания (Hold Timer). Разумным значением максимального интервала между передачей двух последовательных сообщений KEEPALIVE является треть интервала, заданного значением Hold Time. Недопустимо передавать сообщения KEEPALIVE чаще одного раза в секунду. Разработчики могут установить интервал между передачей сообщений KEEPALIVE, как функцию значения Hold Time.

Если Hold Time = 0, периодическая передача сообщений KEEPALIVE недопустима.

Сообщение KEEPALIVE состоит только из заголовка, следовательно, размер такого сообщения равен 19 октетам.

4.5. Формат сообщения NOTIFICATION

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Error code | Error subcode | Data (переменный размер) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Сообщения NOTIFICATION передаются в случаях обнаружения ошибок. Соединение BGP незамедлительно закрывается после передачи такого сообщения.

В дополнение к постоянному заголовку BGP сообщения NOTIFICATION содержат описанные ниже поля.

Error Code — код ошибки

Это 1-октетное целое число без знака показывает тип сообщения NOTIFICATION. Коды типов перечислены в таблице.

Код

Символьное имя

Описание

1

Message Header Error — ошибка в заголовке сообщения

параграф 6.1

2

OPEN Message Error — ошибка в сообщении OPEN

параграф 6.2

3

UPDATE Message Error — ошибка в сообщении UPDATE

параграф 6.3

4

Hold Timer Expired — истекло время удержания

параграф 6.5

5

Finite State Machine Error — ошибка машины конечных состояний

параграф 6.6

6

Cease — разрыв соединения

параграф 6.7

Error subcode — субкод ошибки

Это 1-октетное целое число без знака содержит более конкретную информацию о природе ошибки. С каждым кодом ошибки (Error Code) может быть связан один или несколько субкодов (Error Subcode). При отсутствии субкода для ошибки в поле Error Subcode помещается нулевое значение.

Субкоды для Message Header Error

0 — Unspecified — не указан13.

1 — Connection Not Synchronized — соединение не синхронизировано.

2 — Bad Message Length — некорректный размер сообщения.

3 — Bad Message Type — некорректный тип сообщения.

Субкоды для OPEN Message Error

0 — Unspecified — не указан1.

1 — Unsupported Version Number — неподдерживаемый номер версии.

2 — Bad Peer AS — некорректный номер AS у партнера.

3 — Bad BGP Identifier — некорректный идентификатор BGP.

4 — Unsupported Optional Parameter — неподдерживаемый дополнительный параметр.

5 — [Не используется, см. Приложение A].

6 — Unacceptable Hold Time — недопустимое значение времени удержания.

Субкоды для UPDATE Message Error

0 — Unspecified — не указан1.

1 — Malformed Attribute List — некорректно сформированный список атрибутов.

2 — Unrecognized Well-known Attribute — нераспознанный общеизвестный атрибут.

3 — Missing Well-known Attribute — отсутствует обязательный атрибут.

4 — Attribute Flags Error — некорректные флаги атрибута.

5 — Attribute Length Error — некорректный размер атрибута.

6 — Invalid ORIGIN Attribute — некорректный атрибут ORIGIN.

7 — [Не используется, см. Приложение A].

8 — Invalid NEXT_HOP Attribute — некорректный атрибут NEXT_HOP.

9 — Optional Attribute Error — ошибка в дополнительном атрибуте.

10 — Invalid Network Field — некорректное указание сети.

11 — Malformed AS_PATH — некорректный формат AS_PATH.

Data — данные

Это поле переменной длины служит для диагностики причины генерации сообщения NOTIFICATION. Содержимое поля данных зависит от значений полей Error Code и Error Subcode. Дополнительная информация приведена в главе 6.

Отметим, что размер поля Data можно определить на основании значения поля Length в заголовке сообщения по формуле:

Length в заголовке сообщения = 21 + размер поля Data

Минимальный размер сообщений NOTIFICATION составляет 21 октет (с учетом заголовка).

5. Атрибуты пути

В этой главе рассматриваются атрибуты пути, используемые в сообщениях UPDATE.

Атрибуты делятся на 4 категории:

  1. Wellknown mandatory — общеизвестные, обязательные.

  2. Wellknown discretionary — общеизвестные, необязательные.

  3. Optional transitive — дополнительные, транзитивные (переходные).

  4. Optional nontransitive — дополнительные, непереходные.

Реализации BGP должны распознавать все общеизвестные атрибуты. Некоторые из этих атрибутов являются обязательными и должны включаться в каждое сообщение UPDATE, содержащее поле NLRI. Остальные атрибуты являются необязательными и могут включаться или не включаться в сообщения UPDATE.

После того, как узел BGP обновит значения любого из общеизвестных атрибутов, он должен сообщить измененные атрибуты своим партнерам в передаваемых обновлениях.

Кроме общеизвестных атрибутов каждый путь может содержать один или несколько дополнительных атрибутов. Поддержка дополнительных атрибутов не является обязательной для каждой реализации BGP. Обработка нераспознанных дополнительных атрибутов определяется значением бита Transitive в октете флагов атрибута. Пути с нераспознанными переходными дополнительными атрибутами следует принимать. Если путь с нераспознанными дополнительными переходными атрибутами принят и передается другим узлам BGP, нераспознанные атрибуты этого пути должны передаваться другим узлам BGP с установленным (1) битом Partial в поле Attribute Flags. Если путь с распознанным переходным атрибутом воспринят и передается другим узлам BGP, а бит Partial октета Attribute Flags имеет значение 1, установленное какой-либо из предыдущих AS, данная автономная система не должна сбрасывать этот бит в 0. Нераспознанные дополнительные непереходные атрибуты следует просто игнорировать, не передавая их другим узлам BGP. Если путь с распознанными транзитивными атрибутами передается другим партнерам BGP и значение бита Partial в поле Attribute Flags уже установлено в 1 какой-либо из предшествующих AS, для текущей AS недопустимо сбрасывать этот бит в 0. Нераспознанные нетранзитивные дополнительные атрибуты должны игнорироваться без каких-либо действий и передачи другим партнерам BGP.

Новые дополнительные переходные атрибуты могут добавляться в конце пути исходным отправителем (originator) или любым узлом BGP на пути. Если эти атрибуты не добавлены исходным отправителем, для бита Partial в октете Attribute Flags устанавливается значение 1. Правила присоединения новых непереходных дополнительных атрибутов зависят от природы конкретного атрибута. Предполагается, что документация к каждому новому дополнительному непереходному атрибуту будет включать такие правила (описание атрибута MULTI_EXIT_DISC может служить примером). Все дополнительные атрибуты (переходные и непереходные) могут обновляться (если это допустимо) узлами BGP в пути.

Отправителю сообщения UPDATE следует размещать атрибуты пути в сообщениях UPDATE в порядке возрастания значения типа атрибута. Получатель сообщения UPDATE должен быть готов к обработке неупорядоченных атрибутов пути из сообщения UPDATE.

Один и тот же атрибут (несколько экземпляров одного типа) не может включаться несколько раз в поле Path Attributes сообщения UPDATE.

Обязательные атрибуты должны присутствовать в сообщениях, передаваемых в IBGP и EBGP, если сообщение UPDATE включает поле NLRI. Использование дополнительных атрибутов может определяться по собственному усмотрению, требоваться или запрещаться в зависимости от контекста.

Атрибут

EBGP

IBGP

ORIGIN

обязательно

обязательно

AS_PATH

обязательно

обязательно

NEXT_HOP

обязательно

обязательно

MULTI_EXIT_DISC

по своему усмотрению

по своему усмотрению

LOCAL_PREF

Параграф 5.1.5

требуется

ATOMIC_AGGREGATE

Параграфы 5.1.6 и 9.1.4

AGGREGATOR

по своему усмотрению

по своему усмотрению

5.1. Использование атрибутов пути

Ниже описывается использование всех атрибутов пути BGP.

5.1.1. ORIGIN

Атрибут ORIGIN является общеизвестным и обязательным. Этот атрибут генерируется автономной системой, которая является исходным отправителем маршрутной информации. Другим узлам BGP не следует изменять значение этого атрибута.

5.1.2. AS_PATH

AS_PATH относится к общеизвестным обязательным атрибутам и служит для идентификации автономных систем, через которые передается информация в данном сообщении UPDATE. Компонентами списка автономных систем являются поля AS_SET или AS_SEQUENCE.

Когда узел BGP распространяет маршрут, который был получен из сообщения UPDATE от другого узла BGP в сообщении UPDATE, он должен изменить в маршруте атрибут AS_PATH с учетом размещения узла BGP, которому передается маршрут:

  1. Когда узел BGP анонсирует маршрут внутреннему партнеру, анонсирующему узлу не следует изменять связанный с этим маршрутом атрибут AS_PATH.

  2. Когда узел BGP анонсирует маршрут внешнему партнеру, анонсирующий узел обновляет атрибут AS_PATH, как показано ниже:

  1. Если первый сегмент пути в AS_PATH имеет тип AS_SEQUENCE, локальному узлу следует поместить свой номер AS в качестве последнего элемента списка (в крайнюю левую позицию со смещением вправо остальных октетов протокольного сообщения). Если такое включение будет приводить к переполнению сегмента AS_PATH (т. е., число AS превысит 255 ), следует добавить впереди (prepend) новый сегмент, указав в нем свой номер AS.

  2. Если первый сегмент пути в AS_PATH имеет тип AS_SET, локальная система добавляет впереди (prepend) новый сегмент типа AS_SEQUENCE, включая в него свой номер AS.

  3. При пустом AS_PATH локальная система создает сегмент пути типа AS_SEQUENCE, помещает в него свой номер AS и включает этот сегмент в AS_PATH.

Когда узел BGP является источником маршрута:

  1. этот узел включает свой номер AS в сегмент пути типа AS_SEQUENCE атрибута AS_PATH всех сообщений UPDATE, передаваемых внешним партнерам. В таких случаях номер AS являющегося источником маршрута узла будет единственным элементом сегмента пути, а данный сегмент будет единственным в атрибуте AS_PATH.

  2. этот узел включает пустой атрибут AS_PATH во все сообщения UPDATE, передаваемые внутренним партнерам (пустой атрибут AS_PATH имеет нулевое значение в поле размера).

Всякий раз, когда изменение атрибута AS_PATH связано с включением или добавлением впереди номера AS локальной системы, эта система может включать/добавлять более одного экземпляра своего номера AS в атрибут AS_PATH. Этот процесс определяется параметрами локальной конфигурации.

5.1.3. NEXT_HOP

Общеизвестный обязательный атрибут NEXT_HOP определяет IP-адрес маршрутизатора, который следует использовать в качестве следующего интервала на пути к адресатам, указанным в сообщении UPDATE. Атрибут NEXT_HOP определяется следующим образом:

  1. При передаче сообщения внутреннему партнеру, если маршрут имеет нелокальное происхождение, узлу BGP не следует изменять значение NEXT_HOP за исключением тех случаев, когда он явно настроен на анонсирование своего адреса IP в качестве NEXT_HOP. При анонсировании внутренним партнерам маршрутов локального происхождения, узлу BGP следует использовать в качестве NEXT_HOP адрес внутреннего интерфейса, через который анонсируемая сеть доступна для принимающего анонс узла. Если маршрут непосредственно соединен с анонсирующим узлом или адрес интерфейса, через который узлу доступна анонсируемая сеть, является адресом внутреннего партнера, узлу BGP следует использовать свой адрес IP (адрес интерфейса, через который доступен партнер) в качестве значения атрибута NEXT_HOP.

  2. При передаче сообщения внешнему партнеру X, когда тот находится на расстоянии одного интервала IP от данного узла:

  • Если анонсируемый маршрут получен от внутреннего партнера или имеет локальное происхождение, узел BGP может использовать в качестве атрибута NEXT_HOP адрес интерфейса внутреннего партнера (или внутреннего маршрутизатора), через который анонсируемая сеть доступна для данного узла. В этом случае партнер X будет иметь общую подсеть с указанным адресом. Этот случай является вариантом NEXT_HOP из «вторых рук» (third party).

  • В остальных случаях, если анонсируемый маршрут получен от внешнего партнера, узел BGP может использовать в атрибуте NEXT_HOP адрес IP любого смежного маршрутизатора (известный из принятого атрибута NEXT_HOP), который данный узел использует для локального определения маршрута, В таких случаях X имеет с указанным адресом общую подсеть. Этот случай является вариантом NEXT_HOP из «вторых рук».

  • В противном случае, если внешний партнер, для которого анонсируется маршрут, имеет общую подсеть с одним из интерфейсов анонсирующего узла, последний может использовать связанный с таким интерфейсом адрес IP в качестве значения атрибута NEXT_HOP. Этот случай является вариантом NEXT_HOP из «первых рук» (first party).

  • По умолчанию (если не выполняется ни одно из перечисленных выше условий), узлу BGP следует использовать в качестве атрибута NEXT_HOP IP-адрес интерфейса, который служит данному узлу для организации соединения BGP с партнером X.

  1. При передаче сообщения внешнему партнеру X, находящемуся на расстоянии нескольких интервалов IP от данного узла (multihop EBGP)

  • Узел может быть настроен на распространение атрибута NEXT_HOP. В таких случаях при анонсировании полученного от одного из партнеров маршрута узел должен указывать в качестве атрибута NEXT_HOP в анонсируемом маршруте значение NEXT_HOP, полученное в анонсе маршрута от партнера (т. е, узел не изменяет значение NEXT_HOP).

  • По умолчанию узлу BGP следует использовать IP-адрес интерфейса, который узел указывает в атрибуте NEXT_HOP для организации соединения BGP с узлом X.

Обычно значение атрибута NEXT_HOP выбирается так, чтобы принимался кратчайший из возможных путей. Узел BGP должен обеспечивать возможность запрета анонсирования атрибутов NEXT_HOP, полученных из «вторых рук» для работы в сетях с несовершенными мостами.

Маршрут, порожденный узлом BGP, не следует анонсировать партнеру с использованием в качестве атрибута NEXT_HOP адреса этого партнера. Узлу BGP не следует устанавливать маршруты со своим адресом в качестве NEXT_HOP.

Атрибут NEXT_HOP используется узлами BGP для определения реального выходного интерфейса и адреса ближайшего маршрутизатора (immediate next-hop address), по которому следует пересылать транзитные пакеты для связанных с маршрутом адресатов.

Адрес ближайшего маршрутизатора определяется путем рекурсивного просмотра маршрутов для IP-адреса из атрибута NEXT_HOP, использования содержимого таблицы маршрутизации (Routing Table) и выбора одной записи, если существует множество равноценных путей. Запись таблицы маршрутизации, которая соответствует IP-адресу из атрибута NEXT_HOP, всегда будет задавать выходной интерфейс. Если запись таблицы маршрутизации указывает подключенную подсеть, но не задает адрес next-hop, тогда адрес из атрибута NEXT_HOP следует использовать в качестве адреса ближайшего маршрутизатора. Если запись в таблице также содержит адрес next-hop, этот адрес следует использовать в качестве адреса ближайшего маршрутизатора для пересылки пакетов.

5.1.4. MULTI_EXIT_DISC

Дополнительный непереходный атрибут MULTI_EXIT_DISC14 предназначен для использования на внешних (между AS) соединениях при выборе из множества путей в одну смежную AS. Значение атрибута MULTI_EXIT_DISC представляет собой 4-октетное целое число без знака, которое называют метрикой. При прочих равных из нескольких маршрутов следует выбирать тот, у которого меньше значение метрики. При получении через EBGP атрибут MULTI_EXIT_DISC можно распространять через IBGP другим узлам BGP в данной AS (см. также параграф 9.1.2.2). Атрибут MULTI_EXIT_DISC, полученный из соседней AS, недопустимо распространять в другие соседние AS.

Узел BGP должен обеспечивать механизм, позволяющий в соответствии с локальной конфигурацией удалять из маршрутов атрибут MULTI_EXIT_DISC. Если узел BGP настроен на удаление атрибута MULTI_EXIT_DISC из маршрутов, такое удаление должно выполняться до того, как будет определяться предпочтительный маршрут или происходить выбор маршрута (фазы 1 и 2 Decision Process).

Реализация может также в соответствии с локальной конфигурацией изменять значение атрибутов MULTI_EXIT_DISC, полученных через EBGP. Если узел BGP настроен на изменение значений атрибута MULTI_EXIT_DISC, принятых через EBGP, такое изменение должно выполняться до того, как будет определяться предпочтительный маршрут или происходить выбор маршрута (фазы 1 и 2 Decision Process). Некоторые ограничения описаны в параграфе 9.1.2.2.

5.1.5. LOCAL_PREF

Атрибут LOCAL_PREF относится к числу общеизвестных необязательных. Это атрибут следует включать во все сообщения UPDATE, которые данный узел BGP передает внутренним партнерам (узлам BGP, расположенным в той же автономной системе). Узлу BGP следует рассчитать уровень предпочтения для каждого внешнего маршрута на основе локальной политики и включать этот уровень в анонсы для внутренних партнеров. Предпочтение должно отдаваться маршрутам с более высоким уровнем. Узел BGP использует уровень предпочтения из LOCAL_PREF, в процессе выбора маршрутов (Параграф 9.1.1).

Для узлов BGP недопустимо включение этого атрибута в сообщения UPDATE, передаваемые внешним партнерам, за исключением случаев использования конфедераций BGP [RFC3065]. Если атрибут содержится в сообщении UPDATE, полученном от внешнего партнера, принимающий узел должен игнорировать этот атрибут, за исключением случаев использования конфедераций BGP [RFC3065].

5.1.6. ATOMIC_AGGREGATE

Атрибут ATOMIC_AGGREGATE относится к числу общеизвестных, но не обязательных.

Когда узел BGP объединяет (агрегирует) несколько маршрутов с целью анонсирования отдельному партнеру, значение AS_PATH агрегированного маршрута обычно включает сегмент AS_SET из набора AS, для которых выполняется объединение маршрутов. Во многих случаях администратор сети может определить возможность агрегирования маршрутов без анонсирования AS_SET, чтобы при этом не возникало маршрутных петель.

Если агрегирование не включает по крайней мере некоторые AS из атрибутов AS_PATH объединяемых маршрутов, в создаваемый агрегированный маршрут при анонсировании его партнеру следует включать атрибут ATOMIC_AGGREGATE.

Узлу BGP, получившему маршрут с атрибутом ATOMIC_AGGREGATE, не следует удалять этот атрибут при распространении маршрута другим узлам.

Для узла BGP, получившего маршрут с атрибутом ATOMIC_AGGREGATE, недопустимо указание каких-либо NLRI из этого маршрута как более специфичных (в соответствии с определением параграфа 9.1.4) при анонсировании данного маршрута другим узлам BGP.

Узлу BGP, получившему маршрут с атрибутом ATOMIC_AGGREGATE, следует отдавать себе отчет в том, что актуальный путь к адресату, указанному в NLRI этого маршрута, хотя и не содержит петель, может не совпадать с путем, заданным в атрибуте AS_PATH этого маршрута.

5.1.7. AGGREGATOR

Дополнительный транзитивный атрибут AGGREGATOR может включаться в обновления, формируемые при объединении маршрутов (Параграф 9.2.2.2). Узел BGP, выполняющий агрегирование, может добавлять атрибут AGGREGATOR, в который при этом следует включать свой номер AS и адрес IP. Адрес IP следует указывать тот же, который используется для поля BGP Identifier данного узла.

6. Обработка ошибок BGP

В этом разделе рассматриваются действия, предпринимаемые при обнаружении ошибок в процессе обработки сообщений BGP.

При выполнении любого из описанных здесь условий передается сообщение NOTIFICATION с соответствующими значениями кода (Error Code) и субкода (Error Subcode) ошибки, а также полем Data и соединение BGP закрывается (если явно не указано, что передается сообщение NOTIFICATION, но соединение BGP не закрывается). Если субкод ошибки не указан, должно использоваться нулевое значение.

Фраза «соединение BGP разрывается15» означает, что закрывается соединение TCP, очищается связанная с соединением BGP база Adj-RIB-In и удаляются все ресурсы, выделенные данному соединению BGP. Записи в базе Loc-RIB, связанные с удаленным партнером, помечаются как некорректные. Локальная система заново рассчитывает наилучшие маршруты для адресатов, маршруты к которым помечены как некорректные. До удаления непригодных маршрутов из таблицы партнерам анонсируется отзыва ставших некорректными маршрутов или новые маршруты взамен некорректных.

Если явно не указано иное, поле Data сообщений NOTIFICATION, передаваемых для индикации ошибок, остается пустым.

6.1. Отработка ошибок в заголовках сообщений

Все ошибки, обнаруживаемые при обработке заголовка сообщения, должны указываться путем передачи сообщений NOTIFICATION с кодом ошибки Message Header Error (ошибка в заголовке сообщения). Поле Error Subcode указывает природу ошибки более точно.

Ожидаемое в заголовке сообщения значение поля Marker состоит только из единиц. Если поле Marker в заголовке сообщения содержит неожиданное значение, возникает ошибка синхронизации и в поле Error Subcode должно указываться значение Connection Not Synchronized (соединение не синхронизировано).

Если выполняется хотя бы одно из перечисленных здесь условий:

  • поле Length в заголовке сообщения содержит значение меньше 19 или больше 4096;

  • значение поля Length в заголовке сообщения OPEN меньше минимального размера сообщения OPEN;

  • значение поля Length в заголовке сообщения UPDATE меньше минимального размера сообщения UPDATE;

  • значение поля Length в заголовке сообщения KEEPALIVE не равно 19;

  • значение поля Length в заголовке сообщения NOTIFICATION меньше минимального размера сообщения NOTIFICATION,

для поля Error Subcode должно устанавливаться значение Bad Message Length (некорректный размер сообщения). Поле Data в таких случаях должно содержать ошибочное значение поля Length.

Если не распознано поле Type в заголовке сообщения, в поле Error Subcode должно помещаться значение Bad Message Type (некорректный тип сообщения). Поле Data в таких случаях должно содержать ошибочное значение поля Type.

6.2. Отработка ошибок в сообщениях OPEN

Все ошибки, детектируемые в процессе обработки сообщений OPEN, должны указываться сообщениями NOTIFICATION с Error Code = OPEN Message Error. Значение Error Subcode уточняет природу ошибки.

Если версия протокола, указанная в поле Version полученного сообщения OPEN, не поддерживается, должно устанавливаться значение Error Subcode = Unsupported Version Number. Поле Data в таких случаях представляет собой 2-октетное целое число без знака, которое показывает (в старшем октете) насколько наибольший номер версии, поддерживаемой локально, меньше номера версии, предложенного удаленным партнером BGP (показан в принятом сообщении OPEN) или (в младшем октете) насколько наименьший локально поддерживаемый номер версии больше предложенного удаленным партнером BGP.

Если поле My Autonomous System в сообщении OPEN содержит неприемлемое значение, в поле Error Subcode должно помещаться значение Bad Peer AS. Определение допустимости номеров AS выходит за пределы спецификации данного протокола.

Если значение поля Hold Time в принятом сообщении OPEN неприемлемо, должно устанавливаться значение Error Subcode = Unacceptable Hold Time. Реализация должна отвергать значения Hold Time в одну или две секунды. Реализация может отвергнуть любое предложенное значение Hold Time. Реализация, принявшая значение Hold Time, должна использовать согласованное значение параметра Hold Time .

Если поле BGP Identifier в принятом сообщении OPEN синтаксически некорректно, должно устанавливаться значение Error Subcode = Bad BGP Identifier. Синтаксическая корректность означает, что поле BGP Identifier содержит допустимый индивидуальный (unicast) IP-адрес хоста.

Если не распознано поле Optional Parameters в принятом сообщении OPEN, должно устанавливаться Error Subcode = Unsupported Optional Parameters.

Если один из дополнительных параметров принятого сообщения OPEN распознан, но имеет некорректный формат, должно устанавливаться значение Error Subcode = 0.

6.3. Отработка ошибок в сообщениях UPDATE

Все ошибки, детектируемые при обработке сообщений UPDATE, должны приводить к генерации сообщения NOTIFICATION с Error Code = UPDATE Message Error. Субкод ошибки уточняет ее природу16.

Проверка ошибок в сообщении UPDATE начинается с атрибутов пути. Если значение поля Withdrawn Routes Length или Total Attribute Length слишком велико (т. е., Withdrawn Routes Length + Total Attribute Length + 23 превосходит значение поля Length в заголовке сообщения), в поле Error Subcode должно устанавливаться значение Malformed Attribute List.

Если в любом распознанном атрибуте возникает конфликт флагов (Attribute Flags) и типа атрибута (Attribute Type Code), должно устанавливаться значение Error Subcode = Attribute Flags Error. В поле Data должен включаться связанный с ошибкой атрибут (тип, размер и значение)2.

Если в любом распознанном атрибуте размер (Attribute Length) конфликтует с ожидаемым (на основе кода типа) значением, должно устанавливаться значение Error Subcode = Attribute Length Error. В поле Data должен включаться связанный с ошибкой атрибут (тип, размер и значение).

При отсутствии любого из общеизвестных обязательных атрибутов, должен устанавливаться субкод Missing Well-known Attribute, а в поле Data должен включаться код типа (Attribute Type Code) пропущенного атрибута.

Если не распознан любой из общеизвестных обязательных атрибутов, должно устанавливаться значение Error Subcode = Unrecognized Well-known Attribute, а в поле Data должен включаться нераспознанный атрибут (тип, размер и значение).

Если атрибут ORIGIN имеет неопределенный тип, в поле Error Subcode должно указываться значение Invalid Origin Attribute, а в поле Data должен включаться нераспознанный атрибут (тип, размер и значение).

Если поле атрибута NEXT_HOP синтаксически некорректно, для поля Error Subcode должно устанавливаться значение Invalid NEXT_HOP Attribute. Поле Data должно содержать некорректный атрибут (тип, размер и значение). Синтаксическая корректность означает, что атрибут NEXT_HOP содержит допустимый IP-адрес хоста.

Семантически корректный адрес IP в поле NEXT_HOP должен соответствовать двум критериям:

  1. недопустимо включать в это поле IP-адрес принимающего узла;

  2. в случае EBGP, когда отправитель и получатель расположены на расстоянии одного интервала (one IP hop), IP-адрес в поле NEXT_HOP должен быть IP-адресом отправителя, использованным для организации соединения BGP, или интерфейс, связанный с адресом из поля NEXT_HOP, должен находиться в одной подсети с принимающим узлом BGP.

Если атрибут NEXT_HOP семантически некорректен, следует записать информацию об этом в журнальный файл системы, маршрут следует игнорировать. В таких случаях передавать сообщение NOTIFICATION и разрывать соединение не следует.

Проверяется синтаксическая корректность атрибута AS_PATH. При наличии синтаксических ошибок в пути должно устанавливаться значение Error Subcode = Malformed AS_PATH.

Если сообщение UPDATE получено от внешнего партнера, локальная система может проверить совпадение расположенного слева (по порядку октетов протокольного сообщения) номера AS в атрибуте AS_PATH с номером автономной системы партнера, передавшего сообщение. Если номера не совпадают, должно устанавливаться значение Error Subcode = Malformed AS_PATH.

Если дополнительный атрибут распознан, его значение должно быть проверено. При обнаружении ошибки требуется установить Error Subcode = Optional Attribute Error17. Поле Data в таком случае должно содержать связанный с ошибкой атрибут (тип, размер и значение).

Если тот или иной атрибут неоднократно встречается в сообщении UPDATE, в поле Error Subcode должно устанавливаться значение Malformed Attribute List.

Проверяется синтаксическая корректность поля NLRI в сообщении UPDATE. При обнаружении ошибки должно устанавливаться значение Error Subcode = Invalid Network Field.

Если префикс в поле NLRI семантически некорректен (например, содержит неожиданный групповой адрес IP), информацию об ошибке следует записать в локальный журнальный файл, а префикс следует игнорировать.

Сообщения UPDATE с корректными атрибутами пути, но без NLRI следует трактовать как корректные.

6.4. Отработка ошибок в сообщениях NOTIFICATION

Если узел передает сообщение NOTIFICATION и получатель этого сообщения обнаруживает в нем ошибку, получатель не может использовать сообщение NOTIFICATION для уведомления своего партнера об ошибке. Все ошибки этого типа (например, нераспознанное значение Error Code или Error Subcode) должны локально протоколироваться с передачей уведомления администратору узла, отправившего ошибочное сообщение. Способы такого протоколирования и уведомления не рассматриваются в данном документе.

6.5. Отработка значений Hold Timer

Если система не получает сообщений KEEPALIVE, UPDATE или NOTIFICATION в течение периода, заданного полем Hold Time в сообщении OPEN, передается сообщение NOTIFICATION с кодом ошибки Hold Timer Expired и соединение BGP закрывается.

6.6. Обработка ошибок машины конечных состояний

Любая ошибка, обнаруженная машиной конечных состояний (FSM18) BGP (например, неожиданное событие), указывается путем передачи сообщения NOTIFICATION с Error Code = Finite State Machine Error.

6.7. Обработка Cease

При отсутствии каких-либо критических ошибок (из числа описанных выше) узел BGP может в любой момент закрыть соединение BGP, передав партнеру сообщение NOTIFICATION с Error Code = Cease. Однако такие сообщения недопустимо использовать при возникновении какой-либо из перечисленных выше критических ошибок.

Узел BGP может обеспечивать возможность вносить задаваемый параметрами локальной конфигурации верхний предел для числа адресных префиксов, принимаемых от соседа. В случае превышения порога, заданного параметрами локальной конфигурации (a) новые префиксы от этого соседа отбрасываются (с сохранением соединения с данным соседом) или (b) закрывается соединение BGP с этим соседом. Если узел BGP принимает решение о разрыве соединения BGP со своим соседом в результате получения от того избыточного числа префиксов, этот узел должен передать соседу сообщение NOTIFICATION с Error Code = Cease. Узел может также записать информацию об этом событии в журнальный файл.

6.8. Детектирование конфликтов в соединениях BGP

Если пара узлов BGP пытается одновременно организовать соединение TCP друг с другом, между узлами такой пары могут возникнуть два параллельных соединения. Если IP-адрес отправителя в одном из таких соединений совпадает с IP-адресом получателя в другом соединении и наоборот, возникает конфликт при соединении. При возникновении такого конфликта одно из соединений должно быть закрыто.

Выбор одного из пары соединений для закрытия базируется на соглашении об идентификаторах BGP. При возникновении конфликта сравниваются значения BGP Identifier вовлеченных в конфликт узлов и сохраняется только то соединение, которое было инициировано узлом BGP с большим значением BGP Identifier.

При получении сообщения OPEN локальная система должна проверить все свои соединения, находящиеся в состоянии OpenConfirm. Узел BGP может также проверить соединения, которые находятся в состоянии OpenSent, если он имеет информацию о значении BGP Identifier узла на противоположной стороне соединения (эта информация получается с помощью других протоколов). Если какое-либо из этих соединений относится к удаленному узлу BGP, идентификатор которого совпадает со значением BGP Identifier в сообщении OPEN, локальные система выполняет перечисленные ниже процедуры для разрешения конфликта.

  1. Значение BGP Identifier локальной системы сравнивается с идентификатором удаленного узла BGP, указанным в сообщении OPEN. Сравнение производится с преобразованием значений BGP Identifier к принятому для хостов порядку байтов (host byte order) и трактовкой полученных значений как 4-октетных целых чисел без знака.

  2. Если значение BGP Identifier для локального узла меньше соответствующего значения для удаленного узла, локальная система закрывает существующее соединение BGP с этим узлом (это соединение находится в состоянии OpenConfirm) и принимает соединение BGP от удаленного партнера.

  3. В противном случае локальная система закрывает недавно созданное соединение BGP (связанное с недавно полученным сообщением OPEN) и продолжает использовать существующее соединение с этим партнером (то, которое уже находится в состоянии OpenConfirm).

Если конфигурационные параметры не задают иного, конфликт с существующим соединением BGP, которое находится в состоянии Established, приводит к разрыву недавно созданного соединения.

Отметим, что конфликт соединений не может быть обнаружен для состояний Idle, Connect и Active.

Разрыв соединения BGP (в результате процедуры разрешения конфликта) осуществляется путем передачи сообщения NOTIFICATION с Error Code = Cease.

7. Согласование версий BGP

Узлы BGP могут согласовать версию протокола путем повторных попыток организации соединения BGP, используя в первой попытке высший номер, поддерживаемый локальной стороной. Если при попытке организации соединения возникает ошибка с Error Code = OPEN Message Error и Error Subcode = Unsupported Version Number, узел BGP имеет информацию о номере версии, который был использован при неудачной попытке, номере версии, которую пытался использовать партнер, номере версии, переданном партнером в сообщении NOTIFICATION, и номере версии, которую тот поддерживает. Если номера одной или более версий из числа поддерживаемых обоими партнерами совпадают, имеющаяся информация позволяет быстро определить максимальный поддерживаемый номер версии. Для поддержки согласования версии BGP в будущих версиях протокола должен сохраняться формат сообщений OPEN и NOTIFICATION.

8. Машина конечных состояний BGP

Структуры данных и FSM, описанные в данном документе, являются концептуальными моделями и не обязательно реализуются в точном соответствии с приведенными описаниями. Если реализация поддерживает описанную функциональность, она будет демонстрировать соответствующее описанному здесь поведение.

В этой главе описывается работа BGP в терминах машины конечных состояний (FSM). Глава разбита на две части:

  1. описание событий для машины состояний (параграф 8.1);

  2. описание FSM (параграф 8.2)

Обязательными атрибутами каждого соединения являются:

  1. State — состояние;

  2. ConnectRetryCounter — счетчик числа попыток организации соединения;

  3. ConnectRetryTimer — таймер повторов для соединения;

  4. ConnectRetryTime — время ожидания для повтора;

  5. HoldTimer — таймер удержания;

  6. HoldTime — время удержания;

  7. KeepaliveTimer — таймер сохранения;

  8. KeepaliveTime — время сохранения.

Атрибуты состояния сессии показывают текущее состояние BGP FSM. Счетчик ConnectRetryCounter показывает число попыток узла BGP организовать соединение с партнером.

Обязательные атрибуты, связанные с таймерами, описаны в главе 10. Для каждого таймера существуют значения «timer» и «time» (начальное значение).

Ниже перечислены дополнительные атрибуты сессий. Эти атрибуты могут поддерживаться для соединений или для локальной системы в целом:

1) AcceptConnectionsUnconfiguredPeers

2) AllowAutomaticStart

3) AllowAutomaticStop

4) CollisionDetectEstablishedState

5) DampPeerOscillations

6) DelayOpen

7) DelayOpenTime

8) DelayOpenTimer

9) IdleHoldTime

10) IdleHoldTimer

11) PassiveTcpEstablishment

12) SendNOTIFICATIONwithoutOPEN

13) TrackTcpState

Дополнительные атрибуты сессий определяют различные параметры BGP, оказывающие влияние на смену состояний BGP FSM. Две группы атрибутов, связанных с таймерами, включают:

Группа 1: DelayOpen, DelayOpenTime, DelayOpenTimer

Группа 2: DampPeerOscillations, IdleHoldTime, IdleHoldTimer

Первый параметр (DelayOpen, DampPeerOscillations) является дополнительным атрибутом, который показывает, что функция Timer активна. Значение Time указывает начальное состояние таймера (DelayOpenTime, IdleHoldTime). Timer задает реальный таймер.

Описание взаимодействия между дополнительными атрибутами и состояниями, передаваемыми FSM, приведено в параграфе 8.1.1. Параграф 8.2.1.3 содержит краткий обзор двух различных типов дополнительных атрибутов (флаги и таймеры).

8.1. События BGP FSM

8.1.1. Дополнительные события, связанные с дополнительными атрибутами сессии

Входной информацией для BGP FSM являются события, которые могут относиться к числу обязательных (mandatory) и необязательных (optional). Некоторые из дополнительных событий связаны с дополнительными атрибутами сессии. Дополнительные атрибуты сессий включают несколько групп функций FSM.

Связи между функциями FSM, событиями и дополнительными атрибутами сессий описаны ниже.

Группа 1: Автоматические административные события (старт/стоп)

Дополнительные атрибуты сессии: AllowAutomaticStart, AllowAutomaticStop, DampPeerOscillations, IdleHoldTime, IdleHoldTimer

Опция 1: AllowAutomaticStart

Описание. Соединение с партнером BGP может быть инициировано или разорвано административными средствами. Такая операция может выполняться вручную с участием оператора или автоматически под управлением встроенной логики реализации BGP. Термин «автоматически» говорит о том, что соединение с партнером BGP организуется тогда, когда логика определяет, что соединение BGP следует перезапустить.

Атрибут AllowAutomaticStart указывает, что данное соединение BGP поддерживает автоматический запуск соединения BGP.

Если реализация BGP поддерживает AllowAutomaticStart, рестарт соединения с партнером может повторяться. Опции DampPeerOscillations, IdleHoldTime, IdleHoldTimer управляют скоростью организации повторных соединений.

Опция DampPeerOscillations определяет использование дополнительной логики для подавления осцилляций BGP в форме последовательности автоматически повторяющихся процедур старта и остановки. Параметр IdleHoldTime задает продолжительность периода сохранения партнером BGP состояния Idle перед тем, как будет возможен новый автоматический рестарт. Таймер IdleHoldTimer управляет сохранением состояния Idle.

Примером логики DampPeerOscillations является рост значения IdleHoldTime в тех случаях, когда BGP-партнер порождает периодические осцилляции (организация/разрыв соединения) в течение некоторого интервала времени. Для включения этой логики партеру достаточно организовать 10 соединений и их разрывов в течение 5 минут. Значение IdleHoldTime будет сменено с нуля на 120 секунд.

Значения: TRUE или FALSE

Опция 2: AllowAutomaticStop

Описание. Этот дополнительный атрибут сессии BGP показывает, что для соединения BGP разрешено «автоматическое» прерывание. Автоматическим называется прерывание сессии под управлением поддерживаемой реализацией логики. Рассмотрение такой логики не входит в задачи данной спецификации.

Значения: TRUE или FALSE

Опция 3: DampPeerOscillations

Описание. Дополнительный атрибут сессии DampPeerOscillations показывает, что соединение BGP использует логику подавления осцилляций в состоянии Idle.

Значения: TRUE или FALSE

Опция 4: IdleHoldTime

Описание. IdleHoldTime принимает значение, установленное для IdleHoldTimer.

Значение: Время в секундах.

Опция 5: IdleHoldTimer

Описание. Таймер IdleHoldTimer служит для контроля осцилляций BGP за счет сохранения партнера BGP в состоянии Idle в течение заданного интервала времени. Событие IdleHoldTimer_Expires описано в параграфе 8.1.3.

Значение: Время в секундах.

Группа 2: Не указанные в конфигурации партнеры

Дополнительные атрибуты сессии: AcceptConnectionsUnconfiguredPeers

Опция 1: AcceptConnectionsUnconfiguredPeers

Описание. Машина состояний BGP FSM может позволять восприятие соединений BGP от неуказанных в конфигурации соседей. Дополнительный атрибут сессии AcceptConnectionsUnconfiguredPeers позволяет FSM поддерживать переходы состояний, которые позволяют реализации принимать или отвергать соединения от таких партнеров.

Атрибут AcceptConnectionsUnconfiguredPeers влияет на безопасность. Детальное описание можно найти в документе «Уязвимости BGP» [RFC4272].

Значения: TRUE или FALSE

Группа 3: Обработка TCP

Дополнительные атрибуты сессии: PassiveTcpEstablishment, TrackTcpState

Опция 1: PassiveTcpEstablishment

Описание. Эта опция показывает, что BGP FSM будет пассивно ожидать вызова от удаленного партнера BGP для организации соединения TCP.

Значения: TRUE или FALSE

Опция 2: TrackTcpState

Описание. BGP FSM обычно отслеживает конечный результат попытки организации соединения TCP, а не отдельные сообщения TCP. Опционально BGP FSM может поддерживать дополнительное взаимодействие с системой согласования параметров соединений TCP. Учет событий TCP может увеличить объем записей в журнальных файлах и число смен состояний BGP FSM.

Значения: TRUE или FALSE

Группа 4: Обработка сообщений BGP

Дополнительные атрибуты сессии: DelayOpen, DelayOpenTime, DelayOpenTimer, SendNOTIFICATIONwithoutOPEN, CollisionDetectEstablishedState

Опция 1: DelayOpen

Описание. Дополнительный атрибут сессии DelayOpen позволяет реализации настроить задержку передачи сообщения OPEN на заданное время. Такая задержка позволяет удаленному партнеру BGP первым отправить сообщение OPEN.

Значения: TRUE или FALSE

Опция 2: DelayOpenTime

Описание. DelayOpenTime — начальное значение таймера DelayOpenTimer.

Значение: Время в секундах.

Опция 3: DelayOpenTimer

Описание. Дополнительный атрибут сессии DelayOpenTimer используется для задержки передачи сообщения OPEN в данном соединении. Событие DelayOpenTimer_Expires (Событие 12) описано в параграфе 8.1.3.

Значение: Время в секундах.

Опция 4: SendNOTIFICATIONwithoutOPEN

Описание. SendNOTIFICATIONwithoutOPEN позволяет партнеру передать сообщение NOTIFICATION без отправки сначала сообщения OPEN. Без этого дополнительного атрибута соединение BGP предполагает, что сообщение OPEN должно быть отправлено партнером до того, как ему будет передаваться сообщение NOTIFICATION.

Значения: TRUE или FALSE

Опция 5: CollisionDetectEstablishedState

Описание. Обычно Detect Collision (Параграф 6.8) игнорируется для состояния Established. Этот дополнительный атрибут сессии показывает, что данное соединение BGP обрабатывает конфликты и в состоянии Established.

Значения: TRUE или FALSE

Примечание: Дополнительные сеансовые атрибуты проясняют описание BGP FSM для имеющихся возможностей реализации BGP. Эти атрибуты могут быть предопределенными для реализации и недоступными через интерфейс управления, поддерживаемый реализацией. Если поддерживается новая (2 и выше) версия BGP MIB, эти поля будут доступны через интерфейс управления.

8.1.2. События административного плана

К числу административных относятся те события, при которых операторский интерфейс машины политики BGP19 сигнализирует машине конечных состояний BGP о необходимости запуска или остановки машины состояний BGP. Базовые средства индикации запуска и остановки дополняются необязательными атрибутами соединения, которые передают сигналы о некоторых типах запуска и остановки BGP FSM. Примером такой комбинации может служить Событие 5 — AutomaticStart_with_PassiveTcpEstablishment. С помощью такого события реализация BGP сигнализирует BGP FSM об использовании Automatic Start с опцией для применения процедуры Passive TCP Establishment. В свою очередь Passive TCP establishment сигнализирует, что BGP FSM будет ждать вызова удаленной стороны для организации соединения TCP.

Отметим, что только Событие 1 (ManualStart) и Событие 2 (ManualStop) относятся к числу обязательных административных событий. Все остальные события административного типа (События 3-8) являются необязательными. Каждое из описанных ниже событий имеет номер, определение, статус (обязательное или дополнительное), а также дополнительные атрибуты сессии, которые следует устанавливать на каждой стадии. При генерации Событий 1 — 8 для BGP FSM проверяются условия, заданные в поле «Статус дополнительных атрибутов». Если любое из этих условий не выполняется, локальной системе следует записать в журнальный файл сведения об ошибке FSM.

В некоторых реализациях установка дополнительных атрибутов сессии может быть неявной и, следовательно, эти атрибуты не могут явно устанавливаться оператором. В параграфе 8.2.1.5 описаны такие неявные установки дополнительных сеансовых атрибутов. Описанные ниже административные события также могут быть в некоторых реализациях неявными и недоступными для оператора.

Событие 1: ManualStart

Определение: администратор локальной системы вручную инициирует соединение с партнером.

Статус: обязательный

Статус дополнительных атрибутов: для атрибута PassiveTcpEstablishment следует установить значение FALSE.

Событие 2: ManualStop

Определение: администратор локальной системы вручную останавливает соединение с партнером.

Статус: обязательный

Статус дополнительных атрибутов: взаимодействие с дополнительными атрибутами отсутствует.

Событие 3: AutomaticStart

Определение: локальная система автоматически организует соединение BGP.

Статус: дополнительный, зависит от локальной системы.

Статус дополнительных атрибутов:

  1. для атрибута AllowAutomaticStart следует установить значение TRUE, если происходит данное событие;

  2. если поддерживается дополнительный атрибут сессии PassiveTcpEstablishment, для него следует установить значение FALSE;

  3. если поддерживается DampPeerOscillations, следует установить значение FALSE, когда произойдет данное событие.

Событие 4: ManualStart_with_PassiveTcpEstablishment

Определение: локальный администратор вручную инициирует соединение с партнером при включенном режиме PassiveTcpEstablishment; дополнительный сеансовый атрибут PassiveTcpEstablishment показывает, что будут прослушиваться вызовы партнера прежде, чем соединение будет организовано.

Статус: дополнительный, зависит от локальной системы.

Статус дополнительных атрибутов:

  1. для атрибута PassiveTcpEstablishment следует установить значение TRUE, если это событие происходит;

  2. после завершения события для атрибута DampPeerOscillations следует установить значение FALSE.

Событие 5: AutomaticStart_with_PassiveTcpEstablishment

Определение: локальная система автоматически инициирует соединение BGP при включенном режиме PassiveTcpEstablishment; дополнительный сеансовый атрибут PassiveTcpEstablishment показывает, что будут прослушиваться вызовы партнера прежде, чем соединение будет организовано.

Статус: дополнительный, зависит от локальной системы.

Статус дополнительных атрибутов:

  1. для атрибута AllowAutomaticStart следует установить значение TRUE;

  2. для атрибута PassiveTcpEstablishment следует установить значение TRUE;

  3. если поддерживается атрибут DampPeerOscillations, для него следует установить значение FALSE.

Событие 6: AutomaticStart_with_DampPeerOscillations

Определение: локальная система автоматически инициирует соединение BGP при включенном режиме подавления осцилляций; конкретный метод подавления осцилляций определяется реализацией и его рассмотрение выходит за пределы данной спецификации.

Статус: дополнительный, зависит от локальной системы.

Статус дополнительных атрибутов:

  1. для атрибута AllowAutomaticStart следует установить значение TRUE;

  2. для атрибута DampPeerOscillations следует установить значение TRUE;

  3. для атрибута PassiveTcpEstablishment следует установить значение TRUE.

Событие 7: AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment

Определение: локальная система автоматически инициирует соединение BGP при включенном режиме подавления осцилляций и PassiveTcpEstablishment; конкретный метод подавления осцилляций определяется реализацией и его рассмотрение выходит за пределы данной спецификации.

Статус: дополнительный, зависит от локальной системы.

Статус дополнительных атрибутов:

  1. для атрибута AllowAutomaticStart следует установить значение TRUE;

  2. для атрибута DampPeerOscillations следует установить значение TRUE;

  3. для атрибута PassiveTcpEstablishment следует установить значение TRUE.

Событие 8: AutomaticStop

Определение: локальная система автоматически останавливает соединение BGP; примером автоматической остановки может служить избыточное число префиксов от данного партнера и автоматический разрыв локальной системой соединения с этим партнером.

Статус: дополнительный, зависит от локальной системы.

Статус дополнительных атрибутов: для атрибута AllowAutomaticStop следует установить значение TRUE.

8.1.3. События, связанные с таймерами

Событие 9: ConnectRetryTimer_Expires

Определение: событие генерируется при завершении отсчета таймера ConnectRetryTimer.

Статус: обязательное.

Событие 10: HoldTimer_Expires

Определение: событие генерируется при завершении отсчета таймера HoldTimer.

Статус: обязательное.

Событие 11: KeepaliveTimer_Expires

Определение: событие генерируется при завершении отсчета таймера KeepaliveTimer.

Статус: обязательное.

Событие 12: DelayOpenTimer_Expires

Определение: событие генерируется при завершении отсчета таймера DelayOpenTimer.

Статус: дополнительное.

Статус дополнительных атрибутов: если произошло данное событие

  1. для атрибута DelayOpen следует установить значение TRUE;

  2. следует поддерживать атрибут DelayOpenTime;

  3. следует поддерживать атрибут DelayOpenTimer.

Событие 13: IdleHoldTimer_Expires

Определение: это событие генерируется при завершении отсчета таймера IdleHoldTimer, которое показывает, что для соединения BGP завершился период ожидания (back-off), служащий для предотвращения осцилляции BGP.

Таймер IdleHoldTimer используется только в тех случаях, когда разрешено постоянное использование функции подавления осцилляций путем установки DampPeerOscillations = TRUE.

Реализации, не поддерживающие функцию постоянного подавления осцилляций, могут не поддерживать таймер IdleHoldTimer.

Статус: дополнительное.

Статус дополнительных атрибутов: если происходит данное событие:

  1. для атрибута DampPeerOscillations слебует установить значение TRUE;

  2. следует дождаться завершения отсчета таймера IdleHoldTimer.

8.1.4. События, связанные с соединениями TCP

Событие 14: TcpConnection_Valid

Определение: событие, показывающее прием локальной системой запроса на соединение TCP с корректным адресом и номером порта TCP для отправителя и получателя; принятие решение о корректности IP-адресов отправителя и получателя является прерогативой реализации.

В качестве порта получателя BGP следует использовать значение 179, заданное IANA.

Запросы на организацию соединений TCP фиксируются локальной системой при получении пакетов TCP SYN.

Статус: дополнительное.

Статус дополнительных атрибутов: для атрибута TrackTcpState следует установить значение TRUE, если происходит данное событие.

Событие 15: Tcp_CR_Invalid

Определение: событие, показывающее получение локальной системой запроса на организацию соединения TCP с некорректным значением адреса или номера порта для отправителя или получателя.

В качестве порта получателя BGP следует использовать значение 179, заданное IANA.

Запросы на организацию соединений TCP фиксируются локальной системой при получении пакетов TCP SYN.

Статус: дополнительное.

Статус дополнительных атрибутов: для атрибута TrackTcpState следует установить значение TRUE, если происходит данное событие.

Событие 16: Tcp_CR_Acked

Определение: событие, показывающее, что локальная система запросила организацию соединения TCP с удаленным партнером.

Локальная система передала пакет TCP SYN, приняла отклик TCP SYN/ACK и передала подтверждение TCP ACK.

Статус: обязательное.

Событие 17: TcpConnectionConfirmed

Определение: событие, показывающее, что локальная система получила от удаленного узла подтверждение организации соединения TCP.

Модуль TCP удаленного партнера передал пакет TCP SYN; локальный модуль передал в ответ SYN, ACK и получил завершающее подтверждение ACK.

Статус: обязательное.

Событие 18: TcpConnectionFails

Определение: событие, показывающее, что локальная система получила информацию об отказе при попытке организации соединения TCP.

Модуль TCP удаленного партнера BGP мог передать пакет FIN, на который локальный узел ответил пакетом FIN-ACK. Другим вариантом является детектирование тайм-аута для соединения TCP и прекращения попытки организации соединения.

Статус: обязательное.

8.1.5. События, связанные с сообщениями BGP

Событие 19: BGPOpen

Определение: это событие генерируется при получении корректного сообщения OPEN.

Статус: обязательное.

Статус дополнительных атрибутов:

  1. для атрибута DelayOpen следует установить значение FALSE;

  2. таймер DelayOpenTimer следует выключить.

Событие 20: BGPOpen with DelayOpenTimer running

Определение: это событие генерируется при получении корректного сообщения OPEN для партнера, который уже имеет организованное транспортное соединение и в настоящее время задерживает передачу сообщения BGP OPEN.

Статус: дополнительное.

Статус дополнительных атрибутов:

  1. для атрибута DelayOpen следует установить значение FALSE;

  2. таймер DelayOpenTimer следует включить.

Событие 21: BGPHeaderErr

Определение: это событие генерируется при получении сообщения BGP с некорректным заголовком.

Статус: обязательное.

Событие 22: BGPOpenMsgErr

Определение: это событие генерируется при получении сообщения OPEN, содержащего ошибки.

Статус: обязательное.

Событие 23: OpenCollisionDump

Определение: это событие генерируется административным путем при детектировании конфликта соединений в процесс обработки входящего сообщения OPEN, если данное соединение планируется разорвать; описание детектирования конфликтов приведено в параграфе 6.8.

Событие 23 является административным действием, генерируемым логикой реализации, принимающей решение о сбросе соединения в соответствии с правилами параграфа 6.8. Это событие может происходить, если FSM реализована как две связанных машины состояний.

Статус: дополнительное.

Статус дополнительных атрибутов: если машина состояний обрабатывает это событие из состояния Established, для дополнительного атрибута CollisionDetectEstablishedState следует установить значение TRUE.

Примечание: событие OpenCollisionDump может происходить в состояниях Idle, Connect, Active, OpenSent и OpenConfirm без установки каких-либо дополнительных атрибутов.

Событие 24: NotifMsgVerErr

Определение: это событие генерируется при получении сообщения NOTIFICATION с кодом ошибки несоответствия версий.

Статус: обязательное.

Событие 25: NotifMsg

Определение: это событие генерируется при получении сообщения NOTIFICATION с кодом ошибки, отличным от несовпадения версий.

Статус: обязательное.

Событие 26: KeepAliveMsg

Определение: это событие генерируется при получении сообщения KEEPALIVE.

Статус: обязательное.

Событие 27: UpdateMsg

Определение: это событие генерируется при получении корректного сообщения UPDATE.

Статус: обязательное.

Событие 28: UpdateMsgErr

Определение: это событие генерируется при получении некорректного сообщения UPDATE

Статус: обязательное.

8.2. Описание FSM

8.2.1. Определение FSM

Реализация BGP должна поддерживать отдельную FSM для каждого включенного в конфигурацию партнера. Каждый узел BGP, включенный в потенциальное соединение, будет пытаться связаться с партнером, если для данного узла не задано сохранение состояния Idle или пассивный режим. В последующем обсуждении активная или подключающаяся сторона соединения TCP (та сторона, с которой был передан первый пакет TCP SYN) называется исходящей (outgoing). Пассивная или ожидающая сторона (отправитель первого пакета SYN/ACK) будет называться входящей. Дополнительные разъяснения терминов «активный» и «пассивный» приведены ниже в параграфе 8.2.1.1.

Реализация BGP должна подключиться к порту TCP с номером 179 и прослушивать его с целью приема входящих вызовов в дополнение к своим попыткам организовать соединение с партнером. Для каждого входящего соединения должен создаваться экземпляр машины состояний. Существует период, в течение которого соединение с партнером на другой стороне уже организовано, но его идентификатор BGP еще не известен. В течение этого периода могут одновременно существовать входящее и исходящее соединение для одной пары партнеров. Такая ситуация называется конфликтом при соединении (Параграф 6.8).

Реализация BGP будет иметь не более одной машины FSM для каждого указанного в конфигурации партнера и одну FSM для каждого входящего соединения TCP, в котором партнер еще не идентифицирован. Каждый экземпляр FSM соответствует одному соединению TCP.

Между парой партнеров может существовать несколько соединений, если в них используются различные пары адресов IP. Такая ситуация называется «множественным партнерством» (multiple «configured peerings»).

8.2.1.1. Термины «активный» и «пассивный»

Термины «активный» и «пассивный» присутствуют в сленге операторов Internet уже почти десятилетие и оказались весьма полезными. Эти термины в контексте соединений TCP или соединений с партнерами имеют специфическое толкование. В любом соединении TCP может быть только одна активная и одна пассивная сторона (в соответствии с приведенным выше определением и описанными ниже состояниями FSM). Когда узел BGP настроен как активный, он может располагаться как на активной, так и на пассивной стороне соединения, которое будет организовано в результате. После завершения процесса организации соединения TCP уже не имеет значения, какая из сторон была активной, а какая пассивной на этапе организации соединения. Единственное различие заключается в том, какая из сторон будет использовать порт TCP с номером 179.

8.2.1.2. FSM и детектирование конфликтов

Существует одна машина FSM на каждое соединение BGP. При возникновении конфликта соединений до того, как партнер будет полностью идентифицирован, может существовать два соединения с одним партнером. После разрешения конфликта (Параграф 6.8) FSM разорванного соединения следует освободить (отключить).

8.2.1.3. FSM и дополнительные атрибуты сессий

Дополнительные атрибуты сессий действуют как флаги (TRUE или FALSE) или дополнительные таймеры. Для атрибутов, являющихся флагами, должно поддерживаться соответствующее действие BGP FSM, если для флага может быть установлено значение TRUE. Например, если в реализации BGP могут быть установлены опции AutoStart и PassiveTcpEstablishment, должны поддерживаться События 3, 4 и 5. Если дополнительный атрибут сессии не может иметь значения TRUE, соответствующие события не поддерживаются.

Каждый из дополнительный таймеров (DelayOpenTimer и IdleHoldTimer) имеет группу атрибутов, включающую:

  • флаг индикации поддержки;

  • значение времени (Time) для таймера;

  • таймер.

Формат дополнительный таймеров показан ниже:

DelayOpenTimer: DelayOpen, DelayOpenTime, DelayOpenTimer

IdleHoldTimer: DampPeerOscillations, IdleHoldTime, IdleHoldTimer

Если флаг индикации поддержки дополнительного таймера (DelayOpen или DampPeerOscillations) не может иметь значение TRUE, таймеры и события, поддерживающие данную опцию, не применяются.

8.2.1.4. Номера событий FSM

Номера событий (1-28) используются при описании машины состояний. Реализации могут использовать эти номера для систем сетевого управления. Точная форма FSM или событий FSM зависит от реализации.

8.2.1.5. Действия FSM, зависящие от реализации

В некоторых случаях BGP FSM указывает, что будет выполняться инициализация BGP или удаление ресурсов BGP. Инициализация BGP FSM и связанных с машиной ресурсов зависит от связанной с политикой части реализации BGP. Детальное рассмотрение этих действий выходит за пределы описания FSM.

8.2.2. Машина конечных состояний

Состояние Idle

Изначально FSM узла BGP находится в состоянии Idle (далее машина конечных состояний узла BGP будет обозначаться для краткости BGP FSM).

В этом состоянии BGP FSM отвергает все входящие соединения BGP для данного узла. Никаких ресурсов не выделено. В ответ на событие ManualStart (1) или AutomaticStart (3) локальная система будет:

  • инициализировать все ресурсы BGP для соединения с партнером20;

  • устанавливать ConnectRetryCounter = 0;

  • запускать таймер ConnectRetryTimer с начальным значением;

  • инициировать соединение TCP с другим узлом BGP;

  • прослушивать соединения, инициированные удаленными узлами BGP;

  • переходить в состояние Connect.

События ManualStop (Событие 2) и AutomaticStop (Событие 8) игнорируются в состоянии Idle.

В ответ на событие ManualStart_with_PassiveTcpEstablishment (4) или AutomaticStart_with_PassiveTcpEstablishment (5) локальная система будет:

  • инициализировать все ресурсы BGP;

  • устанавливать ConnectRetryCounter = 0;

  • запускать таймер ConnectRetryTimer с начальным значением;

  • прослушивать соединения, инициированные удаленными узлами BGP;

  • переходить в состояние Active.

Точное значение ConnectRetryTimer определяется локально, но его следует делать достаточно большим для того, чтобы прошла инициализация TCP.

Если атрибут DampPeerOscillations имеет значение TRUE, в состоянии Idle возможны три события:

  • AutomaticStart_with_DampPeerOscillations (Событие 6),

  • AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment (Событие 7),

  • IdleHoldTimer_Expires (Событие 13).

Эти события будут использоваться локальной системой для предотвращения осцилляций. Метод предотвращения постоянных осцилляций выходит за пределы данного документа.

Любое другое событие (9-12, 15-28) в состоянии Idle не приводит к смене состояния локальной системы.

Состояние Connect

В этом состоянии BGP FSM ожидает завершения процесса организации соединения TCP. Стартовые события (1, 3-7) игнорируются в состоянии Connect. В ответ на событие ManualStop (Событие 2) локальная система будет:

  • сбрасывать соединение TCP;

  • освобождать все ресурсы BGP;

  • устанавливать ConnectRetryCounter = 0;

  • останавливать таймер ConnectRetryTimer и устанавливать для него нулевое значение;

  • переходить в состояние Idle.

В ответ на событие ConnectRetryTimer_Expires (9) локальная система будет:

  • сбрасывать соединение TCP;

  • заново запускать таймер ConnectRetryTimer;

  • останавливать таймер DelayOpenTimer и сбрасывать его значение в 0;

  • инициировать соединение TCP с другим узлом BGP;

  • продолжать прослушивание порта для определения входящих вызовов от других узлов BGP;

  • сохранять состояние Connect.

Если происходит событие DelayOpenTimer_Expires (12) в состоянии Connect, локальная система будет:

  • передавать партнеру сообщение OPEN;

  • устанавливать большое значение для таймера удержания HoldTimer;

  • переходить в состояние OpenSent.

Если BGP FSM получает информацию о событии TcpConnection_Valid (14), обрабатывается соединение TCP и сохраняется состояние Connect.

При получении BGP FSM информации о событии Tcp_CR_Invalid (15) локальная система отвергнет соединение TCP и сохранит состояние Connect.

При успешной организации соединения TCP (Событие 16 или 17) локальная система будет сначала проверять атрибут DelayOpen. Если этот атрибут имеет значение TRUE, локальная система будет:

  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его в 0;

  • устанавливать начальное значение для таймера DelayOpenTimer;

  • сохранять состояние Connect.

Если атрибут DelayOpen имеет значение FALSE, локальная система будет:

  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его в 0;

  • завершать инициализацию BGP;

  • передавать партнеру сообщение OPEN;

  • устанавливать большое значение для таймера удержания HoldTimer;

  • переходить в состояние OpenSent.

Предлагается использовать для HoldTimer значение 4 минуты.

При отказе в организации соединения TCP (Событие 18) локальная система проверяет DelayOpenTimer. Если этот таймер запущен, локальная система будет:

  • заново запускать таймер ConnectRetryTimer;

  • останавливать таймер DelayOpenTimer и сбрасывать его значение в 0;

  • продолжать прослушивание порта для приема входящих вызовов от других узлов BGP;

  • переходить в состояние Active.

Если таймер DelayOpenTimer не запущен, локальная система будет:

  • заново запускать таймер ConnectRetryTimer;

  • сбрасывать соединение TCP;

  • освобождать все ресурсы BGP;

  • переходить в состояние Idle.

Если получено сообщение OPEN при запущенном таймере DelayOpenTimer (Событие 20), локальная система будет:

  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его значение в 0;

  • завершать инициализацию BGP;

  • останавливать и сбрасывать в 0 таймер DelayOpenTimer;

  • передавать сообщение OPEN;

  • передавать сообщение KEEPALIVE;

  • если начальное значение таймера HoldTimer отлично от 0:

  • запускается таймер KeepaliveTimer с начальным значением;

  • таймер HoldTimer сбрасывается в согласованное значение,

в противном случае (начальное значение HoldTimer равно 0)

  • сбрасывается таймер KeepaliveTimer;

  • таймер HoldTimer сбрасывается в 0,

  • система переходит в состояние OpenConfirm.

Если значение поля AS совпадает с номером локальной автономной системы, для соединения устанавливается статус внутреннего, в противном случае соединение считается внешним.

Если обнаружены ошибки при проверке заголовка BGP (Событие 21) или сообщения OPEN (Событие 22) (Параграф 6.2), локальная система будет:

  • (необязательно) если атрибут SendNOTIFICATIONwithoutOPEN имеет значение TRUE, локальная система сначала будет передавать сообщение NOTIFICATION с соответствующим кодом ошибки;

  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его значение в 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

При получении сообщения NOTIFICATION об ошибке верификации (Событие 24), локальная система проверяет таймер DelayOpenTimer. Если этот таймер запущен, локальная система будет:

  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его значение в 0;

  • останавливать и сбрасывать в 0 таймер DelayOpenTimer;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • переходить в состояние Idle.

Если таймер DelayOpenTimer не запущен, локальная система будет:

  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его значение в 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

В ответ на все остальные события (8, 10-11, 13, 19, 23, 25-28) локальная система будет:

  • если таймер ConnectRetryTimer запущен, — останавливать и сбрасывать его в 0;

  • если таймер DelayOpenTimer, — останавливать и сбрасывать его в 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

Состояние Active

В этом состоянии BGP FSM пытается приобрести партнеров путем прослушивания и восприятия соединений TCP.

Стартовые события (1, 3-7) игнорируются в состоянии Active. В ответ на событие ManualStop (2) локальная система будет:

  • при запущенном таймере DelayOpenTimer и установленном атрибуте SendNOTIFICATIONwithoutOPEN передавать сообщение NOTIFICATION с кодом ошибки Cease;

  • освобождать все ресурсы BGP и останавливать таймер DelayOpenTimer;

  • сбрасывать соединение TCP;

  • устанавливать ConnectRetryCounter = 0;

  • останавливать таймер ConnectRetryTimer и сбрасывать его значение в 0;

  • переходить в состояние Idle.

В ответ на событие ConnectRetryTimer_Expires (9) локальная система будет:

  • заново запускать таймер ConnectRetryTimer (с начальным значением);

  • инициировать соединение TCP с другим узлом BGP;

  • продолжать прослушивание входящих вызовов TCP, которые могут приходить от удаленных узлов BGP;

  • переходить в состояние Connect.

В ответ на событие DelayOpenTimer_Expires (12) локальная система будет:

  • устанавливать ConnectRetryCounter = 0;

  • останавливать и сбрасывать в 0 таймер DelayOpenTimer;

  • завершать инициализацию BGP;

  • передавать удаленному узлу сообщение OPEN;

  • устанавливать большое значение для таймера удержания;

  • переходить в состояние OpenSent.

Для этого перехода предлагается устанавливать значение HoldTimer равным 4 минутам.

При получении сведений о событии TcpConnection_Valid (14) локальная система обрабатывает флаги соединения TCP и остается в состоянии Active.

При получении информации о событии Tcp_CR_Invalid (15) локальная система отвергнет соединение TCP и сохранит состояние Active.

При успешной организации соединения TCP (Событие 16 или 17) локальная система будет проверять сначала дополнительный атрибут DelayOpen.

Если DelayOpen = TRUE, локальная система будет:

  • останавливать таймер ConnectRetryTimer и сбрасывать его значение в 0;

  • устанавливать для таймера DelayOpenTimer начальное значение (DelayOpenTime);

  • сохранять состояние Active.

Если DelayOpen = FALSE, локальная система будет:

  • устанавливать ConnectRetryTimer = 0;

  • завершать инициализацию BGP;

  • передавать удаленному узлу сообщение OPEN;

  • устанавливать большое значение для таймера удержания;

  • переходить в состояние OpenSent.

Для этого перехода предлагается устанавливать значение HoldTimer равным 4 минутам.

В ответ на событие TcpConnectionFails (18) локальная система будет:

  • заново запускать таймер ConnectRetryTimer (с начальным значением);

  • останавливать и сбрасывать в 0 таймер DelayOpenTimer;

  • освобождать все ресурсы BGP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

Если получено сообщение OPEN и запущен таймер DelayOpenTimer (Событие 20), локальная система будет:

  • останавливать таймер ConnectRetryTimer (если тот запущен) и сбрасывать его значение в 0;

  • останавливать и сбрасывать в 0 таймер DelayOpenTimer;

  • завершать инициализацию BGP;

  • передавать сообщение OPEN;

  • передавать сообщение KEEPALIVE;

  • если значение HoldTimer отлично от 0:

  • запускать таймер KeepaliveTimer с начальным значением;

  • сбрасывать таймер HoldTimer в согласованное значение,

если HoldTimer = 0

  • сбрасывать таймер KeepaliveTimer (0);

  • сбрасывать в 0 таймер HoldTimer;

  • переходить в состояние OpenConfirm.

Если в поле AS содержится номер локальной автономной системы, соединение относится к числу внутренних, в противном случае считается внешним.

Если обнаружены ошибки при проверке заголовка BGP (Событие 21) или сообщения OPEN (Событие 22) (Параграф 6.2), локальная система будет:

  • (необязательно) если атрибут SendNOTIFICATIONwithoutOPEN имеет значение TRUE, локальная система сначала будет передавать сообщение NOTIFICATION с соответствующим кодом ошибки;

  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его значение в 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

При получении сообщения NOTIFICATION об ошибке верификации (Событие 24), локальная система проверяет таймер DelayOpenTimer. Если этот таймер запущен, локальная система будет:

  • останавливать таймер ConnectRetryTimer (если тот включен) и сбрасывать его значение в 0;

  • останавливать и сбрасывать в 0 таймер DelayOpenTimer;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • переходить в состояние Idle.

Если таймер DelayOpenTimer не запущен, локальная система будет:

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

В ответ на любое другое событие (8, 10-11, 13, 19, 23, 25-28) локальная система будет:

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

Состояние OpenSent

В этом состоянии BGP FSM ожидает сообщения OPEN от партнера.

Стартовые события (1, 3-7) игнорируются в состоянии OpenSent.

Если в состоянии OpenSent происходит событие ManualStop (2), локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • устанавливать ConnectRetryCounter = 0;

  • переходить в состояние Idle.

Если в состоянии OpenSent происходит событие AutomaticStop (8), локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

В ответ на событие HoldTimer_Expires (10) локальная система будет:

  • передавать сообщение NOTIFICATION с кодом ошибки Hold Timer Expired;

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

События TcpConnection_Valid (14), Tcp_CR_Acked (16) или TcpConnectionConfirmed (17) говорят о том, что может иметь место попытка организации второго соединения TCP. Это второе соединение находится под контролем системы обработки конфликтов при соединениях (параграф 6.8), пока не будет принято сообщение OPEN.

Запросы соединений TCP через некорректный порт (Tcp_CR_Invalid — Событие 15)) игнорируются.

При получении информации о событии TcpConnectionFails (18) локальная система будет:

  • закрывать соединение BGP;

  • заново запускать таймер ConnectRetryTimer;

  • продолжать прослушивание порта на предмет вызовов от удаленных узлов BGP;

  • переходить в состояние Active.

При получении сообщения OPEN проверяется корректность всех полей этого сообщения. Если сообщение OPEN не содержит ошибок (Событие 19), локальная система будет:

  • сбрасывать в 0 таймер DelayOpenTimer;

  • устанавливать для таймера ConnectRetryTimer значение 0;

  • передавать сообщение KEEPALIVE;

  • устанавливать значение таймера KeepaliveTimer (см. ниже);

  • устанавливать для таймера HoldTimer согласованное значение (Параграф 4.2);

  • переходить в состояние OpenConfirm.

Если согласованное время удержания равно 0, таймеры HoldTimer и KeepaliveTimer не запускаются. Если значение поля My Autonomous System совпадает с номером локальной AS, соединение трактуется как внутреннее, в противном случае относится к числу внешних (это будет оказывать влияние на описанную ниже обработку сообщений UPDATE).

Если обнаружены ошибки при проверке заголовка BGP (Событие 21) или сообщения OPEN (Событие 22) (Параграф 6.2), локальная система будет:

  • передавать сообщение NOTIFICATION с соответствующим кодом ошибки;

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

При получении корректного сообщения BGP OPEN (Событие 19 или 20) требуется применять механизм детектирования конфликтов (параграф 6.8).

Событие CollisionDetectDump происходит, когда реализация BGP определяет наличие конфликта при соединении (рассмотрение этих механизмов выходит за пределы данного документа).

Если в состоянии OpenSent возникает необходимость закрыть соединение, машине состояний передается сигнал OpenCollisionDump (Событие 23). При получении такого события в состоянии OpenSent локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

Если получено сообщение NOTIFICATION с кодом ошибки несоответствия версий (Событие 24), локальная система будет:

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • переходить в состояние Idle.

В ответ на любое другой событие (9, 11-13, 20, 25-28) локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Finite State Machine Error;

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

Состояние OpenConfirm

В этом состоянии BGP FSM ожидает приема сообщения KEEPALIVE или NOTIFICATION.

Любый стартовые события (1, 3-7) игнорируются в состоянии OpenConfirm.

В ответ на событие ManualStop (2), инициированное оператором, локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • устанавливать ConnectRetryCounter = 0;

  • устанавливать ConnectRetryTimer = 0;

  • переходить в состояние Idle.

В ответ на событие AutomaticStop (8), инициированное системой, локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

Если событие HoldTimer_Expires (Событие 10) происходит до получения сообщения KEEPALIVE, локальная система будет:

  • удалять все маршруты, связанные с этим соединением21;

  • передавать сообщение NOTIFICATION с кодом ошибки Hold Timer Expired;

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

Если локальная система получает сигнал KeepaliveTimer_Expires (Событие 11), она будет:

  • передавать сообщение KEEPALIVE;

  • заново запускать таймер KeepaliveTimer;

  • сохранять состояние OpenConfirm22.

Событие TcpConnection_Valid (14) или успешная организация соединения TCP (Событие 16 или 17) в состоянии OpenConfirm требуют от локальной системы проверки отсутствия второго соединения (с тем же партнером).

При попытке организации соединения TCP через некорректный порт (Событие 15) локальная система будет игнорировать вторую попытку организации соединения.

Если локальная система получает сигнал TcpConnectionFails (Событие 18) от нижележащего уровня TCP или сообщение NOTIFICATION (Событие 25), она будет:

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

Если локальная система получает сообщение NOTIFICATION с кодом ошибки несоответствия версий (NotifMsgVerErr — Событие 24)), она будет:

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • переходить в состояние Idle.

Если локальная система получает корректное сообщение OPEN (BGPOpen — Событие 19), выполняется процесс детектирования конфликтов, описанный в параграфе 6.8. Если в результате данное соединение будет разрываться, локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP (пакет TCP FIN);

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

Если получено сообщение OPEN, проверяется корректность всех полей этого сообщения. Если обнаружены ошибки при проверке заголовка BGP (Событие 21) или сообщения OPEN (Событие 22) (Параграф 6.2), локальная система будет:

  • передавать сообщение NOTIFICATION с соответствующим кодом ошибки;

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

Если (в процессе обработки другого сообщения OPEN) реализация BGP определяет (способы детектирования выходят за пределы данного документа), что произошел конфликт при соединении и данное соединение будет закрыто, локальная система будет подавать сигнал OpenCollisionDump (Событие 23). При получении сигнала OpenCollisionDump (Событие 23) локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

При получении сообщения KEEPALIVE (KeepAliveMsg — Событие 26) локальная система будет:

  • заново запускать таймер HoldTimer;

  • переходить в состояние Established.

В ответ на все остальные события (9, 12-13, 20, 27-28) локальная система будет:

  • передавать сообщение NOTIFICATION с соответствующим кодом Finite State Machine Error;

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

Состояние Established

В состоянии Established машина BGP FSM может обмениваться сообщениями UPDATE, NOTIFICATION и KEEPALIVE со своим партнером. Любые стартовые события (1, 3-7) игнорируются в состоянии Established.

В ответ на событие ManualStop (Событие 2), инициированное оператором, локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • устанавливать ConnectRetryCounter = 0;

  • переходить в состояние Idle.

В ответ на событие AutomaticStop (8) локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;

  • устанавливать ConnectRetryTimer = 0;

  • удалять все маршруты, связанные с этим соединением;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

Одной из причин сигнала AutomaticStop может быть получение сообщений UPDATE с числом префиксов, превышающим заданный предел общего числа префиксов. Локальная система будет автоматически разрывать соединение с данным партнером.

В ответ на событие HoldTimer_Expires (10) локальная система будет:

  • передавать сообщение NOTIFICATION с кодом ошибки Hold Timer Expired;

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations attribute = TRUE;

  • переходить в состояние Idle.

По сигналу KeepaliveTimer_Expires (Событие 11) локальная система будет:

  • передавать сообщение KEEPALIVE;

  • заново запускать таймер KeepaliveTimer, если согласованное значение HoldTime не равно 0.

Каждый раз при получении локальной системой сообщения KEEPALIVE или UPDATE она заново запускает таймер KeepaliveTimer, если согласованное значение HoldTime не равно 0.

Сигнал TcpConnection_Valid (Событие 14), принятый для корректного порта, будет инициировать систему отслеживания второго соединения.

Некорректные соединения (Tcp_CR_Invalid — Событие 15) будут игнорироваться.

В ответ на индикацию завершения организации соединения TCP (Событие 16 или 17) нужно отслеживать второе соединение, пока не будет передано сообщение OPEN23.

Если получено корректное сообщение OPEN (BGPOpen — Событие 19) и CollisionDetectEstablishedState = TRUE, сообщение OPEN будет проверяться на предмет конфликта (параграф 6.8) с другими соединениями. Если реализация BGP принимает решение о разрыве данного соединения, она будет генерировать сигнал OpenCollisionDump (Событие 23). Если соединение нужно разорвать, локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Cease;

  • устанавливать ConnectRetryTimer = 0;

  • удалять все маршруты, связанные с соединением;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

Если локальная система получает сообщение NOTIFICATION (Событие 24 или 25) или сигнал TcpConnectionFails (Событие 18) от нижележащего уровня TCP, она будет:

  • устанавливать ConnectRetryTimer = 0;

  • удалять все маршруты, связанные с соединением;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • переходить в состояние Idle24.

При получении сообщения KEEPALIVE (Событие 26) локальная система будет:

  • заново запускать таймер HoldTimer, если согласованное значение HoldTime не равно 0;

  • сохранять состояние Established.

В ответ на сообщение UPDATE (Событие 27) локальная система будет:

  • обрабатывать принятое сообщение;

  • заново запускать таймер HoldTimer, если согласованное значение HoldTime не равно 0;

  • сохранять состояние Established.

Если локальная система получает сообщение UPDATE и процедура контроля ошибок в сообщениях UPDATE (Параграф 6.3) обнаруживает ошибку (Событие 28), локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Update Error;

  • устанавливать ConnectRetryTimer = 0;

  • удалять все маршруты, связанные с соединением;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

В ответ на все прочие события (9, 12-13, 20-22) локальная система будет:

  • передавать сообщение NOTIFICATION с кодом Finite State Machine Error,

  • удалять все маршруты, связанные с соединением;

  • устанавливать ConnectRetryTimer = 0;

  • освобождать все ресурсы BGP;

  • сбрасывать соединение TCP;

  • увеличивать значение ConnectRetryCounter на 1;

  • (необязательно) выполнять процедуру подавления осцилляций, если DampPeerOscillations = TRUE;

  • переходить в состояние Idle.

9. Обработка сообщений UPDATE

Сообщение UPDATE может быть получено только в состоянии Established. Получение такого сообщения в любом другом состоянии является ошибкой. При получении сообщения UPDATE проверяется корректность каждого поля в соответствии с параграфом 6.3.

Если не удается распознать дополнительные непереходные атрибуты, они просто игнорируются. Если не удается распознать дополнительные переходные атрибуты, устанавливается значение бита Partial=1 в поле флагов атрибута (третий по старшинству бит) и атрибут сохраняется для передачи другим узлам BGP.

Если дополнительный атрибут распознан и имеет корректное значение, тогда (в зависимости от типа дополнительного атрибута) этот атрибут обрабатывается локально, сохраняется и обновляется (при необходимости) для возможной передачи другим узлам BGP.

Если сообщение UPDATE содержит непустое поле WITHDRAWN ROUTES (отзываемые маршруты), ранее анонсированные маршруты, чьи адресаты указаны префиксами IP в данном поле, удаляются из таблицы AdjRIBIn. Узлу BGP следует запустить процесс выбора маршрутов (Decision Process), поскольку анонсированные ранее маршруты больше не являются доступными.

Если сообщение UPDATE содержит доступный маршрут, таблицу AdjRIBIn следует обновить, добавив этот маршрут, как указано здесь — если поле NLRI нового маршрута идентично одному из маршрутов, хранящихся в Adj-RIB-In, новый маршрут нужно поместить взамен имеющегося в Adj-RIB-In (таким образом, неявно отзывая более старый маршрут). В противном случае, если Adj-RIB-In не содержит маршрута с идентичным значением NLRI, новый маршрут следует включить в таблицу Adj-RIB-In.

После того, как узел BGP обновит базу Adj-RIB-In, ему следует инициировать процесс выбора маршрутов (Decision Process).

9.1. Процесс выбора маршрутов (Decision Process)25

Процесс выбора маршрутов (Decision Process) обеспечивает выбор маршрутов для последующего анонсирования путем применения правил, заданных в локальной базе PIB (Policy Information Base), к маршрутам из базы AdjRIBIn. Результатом процесса является набор маршрутов, которые будут анонсироваться всем партнерам, — эти маршруты хранятся в локальной базе AdjRIBOut в соответствии с политикой.

BGP Decision Process описывается здесь концептуально и не обязательно должен быть реализован в точном соответствии с этим описанием. Если реализация поддерживает описанную функциональность, она будет демонстрировать внешнее поведение, соответствующее данному описанию.

Процесс выбора формализуется путем определения функций, принимающих атрибуты данного маршрута в качестве аргументов и возвращающих (a) неотрицательное целое число, которое задает уровень предпочтения для данного маршрута, или (b) значение, показывающее, что данный маршрут нежелательно включать в Loc-RIB и он будет исключен рассмотрения на последующих этапах процесса выбора.

В функции, вычисляющей уровень предпочтения для данного маршрута, не следует использовать в качестве входных данных перечисленной здесь информации — существование других маршрутов, отсутствие других маршрутов, атрибуты пути для других маршрутов. Процесс выбора маршрутов состоит из независимого определения уровня предпочтения каждого доступного маршрута и последующего выбора одного из маршрутов с максимальным уровнем предпочтения.

Процесс выбора применяется ко всем маршрутам из базы AdjRIBIn и отвечает за:

  • выбор маршрутов, которые будут использоваться локальным узлом;

  • выбор маршрутов, которые будут анонсироваться партнерам BGP;

  • агрегирование (объединение) маршрутов и снижение объема маршрутной информации.

Decision Process делится на три фазы, каждая из которых включается определенными событиями:

  1. Фаза 1 отвечает за расчет уровня предпочтения для каждого маршрута, полученного от партнеров.

  2. Фаза 2 начинается по завершении фазы 1 и отвечает за выбор лучшего маршрута из числа доступных для каждого адресата, а также включение выбранных маршрутов в LocRIB.

  3. Фаза 3 начинается после обновления LocRIB и отвечает за распространение маршрутов из LocRIB всем партнерам в соответствии с политикой, содержащейся в PIB. На этой фазе также может выполняться объединение маршрутов и снижение объема маршрутной информации.

9.1.1. Фаза 1: Расчет предпочтений (Calculation of Degree of Preference)

Фаза 1 активизируется всякий раз, когда локальный узел BGP получает от партнера сообщение UPDATE, анонсирующее новый маршрут, замену или отзыв маршрута.

Фаза 1 представляет собой отдельный процесс, который завершается после выполнения всех требуемых операций.

Функция, используемая в фазе 1, блокирует базу AdjRIBIn прежде, чем начать работу с содержащимися в ней маршрутами и снимет блокировку по завершении работы со всеми новыми или недоступными маршрутами в этой базе.

При получении нового маршрута или замене доступного маршрута локальный узел BGP определяет уровень предпочтения, как описано ниже.

Если маршрут получен от внутреннего партнера в качестве уровня предпочтения принимается значение атрибута LOCAL_PREF или локальная система рассчитывает этот уровень на основе заданных конфигурацией параметров политики. Отметим, что последний вариант может приводить к возникновению постоянных маршрутных петель.

Если маршрут получен от внешнего партнера, локальный узел BGP рассчитывает уровень предпочтения на основе заданных конфигурацией параметров политики. Если полученное значение показывает, что маршрут является неподходящим, этот маршрут недопустимо передавать26 на следующий этап процесса выбора, в противном случае возвращенное значение должно использоваться как значение LOCAL_PREF в любом повторном анонсе IBGP.

Конкретные правила политики и методы расчета уровня предпочтения задаются локально.

9.1.2. Фаза 2: Выбор маршрута (Route Selection)

Фаза 2 выполняется после завершения фазы 1 и представляет собой отдельный процесс, который завершается после выполнения всех необходимых операций. В фазе 2 используются все маршруты из базы AdjRIBsIn.

Активизация фазы 2 блокируется, пока не будет завершена работа фазы 3. Функция фазы 2 блокирует целиком базу AdjRIBsIn перед началом работы и снимает блокировку по завершении расчета.

Если атрибут NEXT_HOP маршрута BGP указывает непреобразуемый адрес27 или этот адрес не будет преобразовываться после установки маршрута, такой маршрут BGP должен исключаться из обработки в фазе 2.

Если атрибут AS_PATH маршрута BGP содержит петлю (AS loop), маршрут BGP следует исключить из рассмотрения в фазе 2. Детектирование петель осуществляется путем полного сканирования пути, указанного в атрибуте AS_PATH, и проверки отсутствия в нем номера локальной AS. Обсуждение работы узлов BGP, настроенных на восприятие маршрутов с номером AS этого узла в атрибутах пути, выходит за пределы данного документа.

Важно, чтобы узлы BGP внутри AS при выборе маршрутов не принимали конфликтующих решений, которые будут приводить к возникновению петель при пересылке пакетов.

Для каждого набора адресатов, к которому существует доступный маршрут в таблице AdjRIBsIn, локальный узел BGP идентифицирует маршрут, соответствующий одному из перечисленных условий:

  1. маршрут имеет высший уровень предпочтения из всего набора путей к этому множеству адресатов;

  2. маршрут является единственным для данного множества адресатов;

  3. маршрут выбран в результате применения в фазе 2 правил «отбрасывания лишнего» (tie breaking) описанных в параграфе 9.1.2.2.

После этого локальному узлу следует установить маршрут в таблицу Loc-RIB, заменяя любой маршрут к тому же адресату, который в настоящее время хранится в Loc-RIB. После включения нового маршрута BGP в таблицу маршрутизации следует принять меры по удалению из таблицы других маршрутов к тому же адресату. Принятие решения о замене имеющегося в таблице маршрута, полученного не от BGP, на маршрут BGP определяется локальной политикой узла BGP.

Локальный узел должен определить адрес ближайшего маршрутизатора (immediate next-hop) из атрибута NEXT_HOP выбранного маршрута (Параграф 5.1.3). При смене ближайшего маршрутизатора или стоимости IGP28 до NEXT_HOP (NEXT_HOP преобразуется через маршрут IGP) выбор маршрута в фазе 2 должен быть проведен заново.

Отметим, что даже в тех случаях, когда маршруты BGP не включаются в таблицу маршрутизации с immediate next-hop, реализация должна принять меры для того, чтобы адрес NEXT_HOP был преобразован в адрес подключенного напрямую следующего маршрутизатора29 до того, как по маршруту BGP будет начата пересылка пакетов, и этот адрес (адреса) использовался при реальной пересылке пакетов.

Маршруты, которые невозможно преобразовать, следует удалить из базы Loc-RIB и таблицы маршрутизации. Однако соответствующие непреобразуемые маршруты следует сохранить в базе Adj-RIBs-In (впоследствии их преобразование может стать возможным).

9.1.2.1. Возможность преобразования маршрута

Как сказано в параграфе 9.1.2, узлам BGP следует исключать непреобразуемые маршруты из рассмотрения в фазе 2. Это позволяет включать в базу Loc-RIB и таблицу маршрутизации только действующие маршруты.

Возможность преобразования маршрута определяется перечисленными ниже условиями:

  1. Маршрут Rte1, указанный только промежуточным адресом, рассматривается как преобразуемый, если таблица маршрутизации содержит по крайней мере один маршрут Rte2, который соответствует промежуточному адресу маршрута Rte1 и преобразуется без рекурсии (непосредственно или опосредованно) через Rte1. Пр наличии более одного такого маршрута следует рассматривать только маршрут с максимальным соответствием.

  2. Маршруты, указанные интерфейсами (с промежуточным адресом или без него) считаются преобразуемыми, если указанный для маршрута интерфейс активен и для него включена обработка IP.

Маршруты BGP не включают интерфейсов, но могут быть преобразованы в маршруты из таблицы маршрутизации, которые могут относиться к обоим перечисленным выше типам (т. е., задавать или не задавать интерфейс). Предполагается, что маршруты IGP и маршруты в непосредственно подключенные сети задают выходной интерфейс. Статические маршруты могут задавать выходной интерфейс, промежуточный адрес или оба параметра.

Отметим, что маршрут BGP рассматривается как непреобразуемый в ситуации, когда таблица маршрутизации узла BGP не включает маршрута, соответствующего значению NEXT_HOP из маршрута BGP. Взаимно-рекурсивные маршруты (маршруты, преобразующие друг друга или самого себя) также не проходят проверку на возможность преобразования.

Важно также обеспечить исключение доступных маршрутов, которые станут непреобразуемыми после их включения в таблицу маршрутизации даже если значение NEXT_HOP для такого маршрута может быть преобразовано в текущем контексте таблицы маршрутизации (примером могут служить взаимно-рекурсивные маршруты). Эта проверка гарантирует, что узел BGP не включит в свою таблицу маршруты, которые будут удалены и не будут использоваться узлом. Следовательно, в дополнение к стабильности локальной таблицы маршрутизации эта проверка также делает более эффективной работу протокола в сети.

В тех случаях, когда узел BGP идентифицирует маршрут как непреобразуемый по причине взаиморекурсии, следует записывать сообщение об ошибке в журнальный файл системы.

9.1.2.2. Отбрасывание лишнего (фаза 2)

В таблице AdjRIBsIn узла BGP может храниться несколько маршрутов к одному адресату, имеющих одинаковый уровень предпочтения. Локальный узел может выбрать только один из таких маршрутов для включения в таблицу LocRIB. К рассмотрению принимаются все маршруты с одинаковым уровнем предпочтения, полученные как от внутренних, так и от внешних партнеров.

В описанной ниже процедуре предполагается, что для каждого маршрута-кандидата все узлы BGP в автономной системе могут определить стоимость пути (внутренняя дистанция) до адреса, указанного атрибутом NEXT_HOP в данном маршруте, и применяется один алгоритм выбора маршрутов.

Работа алгоритма tie-breaking начинается с рассмотрения всех маршрутов к одному множеству адресатов, имеющих одинаковый уровень предпочтения, и выбором маршрутов, которые будут исключаться из рассмотрения. Работа алгоритма завершается после того, как останется единственный маршрут. Критерии отбора должны применяться в указанном ниже порядке.

Некоторые критерии описаны с использованием псевдокода. Отметим, что выбор псевдокода был продиктован соображениями ясности, а не эффективности. Он не предназначен для конкретной реализации. Реализации протокола BGP могут использовать любой алгоритм, который будет давать такой же результат, как описано здесь.

  1. Исключаются из рассмотрения все маршруты, с числом номеров AS в атрибуте AS_PATH, большим минимального значения. Отметим, что при расчете этого значения AS_SET учитывается как 1, независимо от количества AS в данном наборе.

  2. Исключаются из рассмотрения все маршруты, для которых значение атрибута Origin превышает минимальное.

  3. Исключаются из рассмотрения маршруты с менее предпочтительными атрибутами MULTI_EXIT_DISC. Значения MULTI_EXIT_DISC можно сравнивать только для маршрутов, полученных из одной соседней AS (эта AS определяется из атрибута AS_PATH). Маршруты без атрибута MULTI_EXIT_DISC рассматриваются как маршруты с наименьшим возможным значением MULTI_EXIT_DISC.

    Описанный выше алгоритм можно представить в виде следующей процедуры:

    for m = число остающихся в рассмотрении маршрутов

    for n = число остающихся в рассмотрении маршрутов

    if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))

    исключить маршрут m из рассмотрения

    В приведенном выше псевдокоде функция MED(n) возвращает значение атрибута MULTI_EXIT_DISC для маршрута n. Если маршрут n не имеет атрибута MULTI_EXIT_DISC, функция возвращает минимальное из возможных значений MULTI_EXIT_DISC (т. е., 0).

    Функция neighborAS(n) возвращает номер соседней AS, из которой был получен маршрут n. Если маршрут получен через IBGP и другой узел IBGP не является исходной точкой этого маршрута, это будет номер соседней AS, из которой другой узел IBGP получил маршрут. Если маршрут получен через IBGP и другой узел IBGP (a) является исходной точкой маршрута или (b) создал маршрут путем агрегирования и атрибут AS_PATH агрегированного маршрута пуст или начинается с AS_SET, это локальная AS.

    Если атрибут MULTI_EXIT_DISC удаляется до повторного анонсирования маршрута в IBGP, можно провести сравнение с использованием полученного через EBGP атрибута MULTI_EXIT_DISC. Если реализация решает удалить MULTI_EXIT_DISC, тогда дополнительное сравнение MULTI_EXIT_DISC, если оно выполняется, должно учитывать только маршруты, полученные через EBGP. Наилучший маршрут от EBGP можно тогда сравнивать с маршрутами от IBGP после удаления атрибута MULTI_EXIT_DISC. Если атрибут MULTI_EXIT_DISC удаляется из подмножества маршрутов от EBGP и из выбранного “лучшего” маршрута от EBGP не будет удален атрибут MULTI_EXIT_DISC, тогда этот атрибут должен использоваться для сравнения с маршрутами от IBGP. Для полученных через IBGP маршрутов атрибут MULTI_EXIT_DISC должен использоваться при сравнении маршрутов, которые не исключены на предыдущих этапах выбора (Decision Process). Включение атрибута MULTI_EXIT_DISC маршрутов от EBGP в сравнение с маршрутами от IBGP с последующим удалением атрибута MULTI_EXIT_DISC и анонсированием маршрута будет предотвращать возникновение маршрутных петель.

  4. Если хотя бы один из маршрутов-кандидатов получен через EBGP, исключаются из рассмотрения все маршруты, полученные от IBGP.

  5. Исключаются из рассмотрения все маршруты с наименее предпочтительной внутренней стоимостью (interior cost). Внутренняя стоимость маршрута определяется путем расчета метрики до NEXT_HOP для маршрута с использованием таблицы маршрутизации. Если маршрутизатор NEXT_HOP для этого маршрута доступен, но стоимость пути невозможно определить, этот этап следует пропустить (возможно, рассматривая все маршруты, как равноценные).

    Описанный выше алгоритм можно представить псевдокодом.

    for m = число остающихся в рассмотрении маршрутов

    for n = число остающихся в рассмотрении маршрутов

    if (cost(n) < cost(m))

    исключить маршрут m из рассмотрения

    В приведенном псевдокоде функция cost(n) возвращает стоимость пути (внутренняя дистанция) до адреса, указанного в атрибуте NEXT_HOP рассматриваемого маршрута.

  6. Исключаются из рассмотрения все маршруты, кроме того, который был анонсирован узлом BGP с наименьшим значением BGP Identifier30.

  7. Выбирается маршрут, полученный от партнера с наименьшим адресом.

9.1.3. Фаза 3: Распространение маршрутов (Route Dissemination)31

Фаза 3 выполняется после завершения операций фазы 2 или по любому из перечисленных ниже событий:

  1. изменение в Loc-RIB маршрутов к локальным адресатам;

  2. изменение локально сгенерированных маршрутов, которые не были получены от BGP;

  3. организация соединения с новым узлом BGP.

Функция фазы 3 представляет собой отдельный процесс, работа которого завершается после выполнения всех требуемых действий. Функция фазы 3 блокируется на время работы функции фазы 2.

Все маршруты базы Loc-RIB обрабатываются для включения в Adj-RIBs-Out, согласно заданной конфигурацией политике. Эта политика может исключать маршруты, содержащиеся в Loc-RIB, из числа добавляемых в базу Adj-RIB-Out. Маршрут не следует устанавливать в Adj-Rib-Out, если для адресатов и NEXT_HOP этого маршрута а таблице маршрутизации нет соответствующей записи. Если маршрут из базы Loc-RIB не включается в ту или иную базу Adj-RIB-Out, ранее анонсированный маршрут этой базы Adj-RIB-Out должен быть отозван с помощью сообщения UPDATE (Параграф 9.2).

В этой фазе могут дополнительно применяться методы агрегирования маршрутов и снижения объема маршрутных данных (Параграф 9.2.2.1).

Вопросы локальной политики, которая может приводить к включению маршрутов в базу Adj-RIB-Out без их добавления в таблицу пересылки локального узла BGP выходят за пределы данного документа.

После завершения процессов обновления Adj-RIBs-Out и таблицы маршрутизации локальный узел BGP запускает процесс передачи обновлений (Update-Send — параграф 9.2).

9.1.4. Перекрывающиеся маршруты

Узел BGP может передавать маршруты с перекрывающимися NLRI другому узлу BGP. Перекрытие NLRI происходит в тех случаях, когда множество адресатов отображается в несоответствующее множество маршрутов. Поскольку BGP представляет NLRI с использованием префиксов IP, перекрытия всегда могут быть выражены как подмножества. Маршрут, описывающий более узкое множество адресатов (более длинный префикс), будем называть более специфичным по сравнению с маршрутом, описывающим более широкое множество адресатов (префикс короче), — такие маршруты будем называть менее специфичными.

Отношения предпочтительности позволяют разделить менее специфичный маршрут на 2 части:

    • множество адресатов, описываемое менее специфичным маршрутом, и

    • множество адресатов, описываемое перекрытием менее специфичного и более специфичного маршрутов.

Набор адресатов, описываемый перекрытием, представляет часть менее специфичного маршрута, которая доступна, но в настоящее время не используется. Если более специфичный маршрут впоследствии отзывается, описываемые перекрытием адресаты остаются доступными через менее специфичный маршрут.

Если узел BGP получает перекрывающиеся маршруты, процесс выбора маршрутов (Decision Process) должен рассматривать оба маршрута на основе заданной конфигурацией политики восприятия маршрутов. Если приемлемы оба маршрута (менее специфичный и более специфичный), процесс выбора должен установить в Loc-RIB оба маршрута или объединить их и установить в Loc-RIB агрегированный маршрут, что обеспечивается наличием в обоих маршрутах одинакового значения атрибута NEXT_HOP.

Если узел BGP выбирает агрегирование маршрутов, ему следует включить все AS, используемые при формировании агрегированного маршрута, в AS_SET или добавить в маршрут атрибут ATOMIC_AGGREGATE. Данный атрибут в настоящее время используется в основном как информационный. По мере избавления от протоколов маршрутизации IP, хостов и маршрутизаторов, не поддерживающих бесклассовую маршрутизацию, необходимость в деагрегировании маршрутов отпадет. Маршруты не следует деагрегировать. В частности, маршруты с атрибутом ATOMIC_AGGREGATE деагрегировать недопустимо. Таким образом, значение NLRI такого маршрута не может быть более специфичным. Пересылка по такому маршруту не обеспечивает гарантии, что пакеты IP будут в реальности проходить только через AS, указанные в атрибуте AS_PATH этого маршрута.

9.2. Процесс передачи обновлений (Update-Send)

Процесс передачи обновлений (UpdateSend) отвечает за анонсирование сообщений UPDATE всем партнерам. Например, он распространяет маршруты, выбранные Decision Process, другим узлам BGP, которые могут располагаться в той же или соседних AS.

Когда узел BGP получает сообщение UPDATE от внутреннего партнера, принимающему узлу BGP не следует заново распространять содержащуюся в сообщении UPDATE информацию другим внутренним узлам (если данный узел не используется как BGP Route Reflector [RFC2796]).

В фазе 3 процесса выбора маршрутов узел BGP обновляет свою базу Adj-RIBs-Out. Все вновь включенные маршруты и все маршруты, ставшие недоступными (если для них нет замены), следует анонсировать партнерам в сообщениях UPDATE.

Узлу BGP не следует анонсировать доступный маршрут BGP из своей базы Adj-RIB-Out, если это будет порождать сообщение UPDATE, содержащее маршрут BGP, который уже был анонсирован.

Все маршруты из базы Loc-RIB, помеченные как недоступные, следует удалять. Изменения в состоянии доступности адресатов внутри своей автономной системы также следует анонсировать в сообщениях UPDATE.

Если единичный маршрут в силу ограничений на размер сообщений UPDATE (см. главу 4) не помещается в сообщение, для узла BGP недопустимо анонсирование этого маршрута; реализация может записывать информацию о таких фактах в системный журнал.

9.2.1. Контроль служебного трафика

Протокол BGP вынужден ограничивать объем служебного трафика (сообщения UPDATE) в целях снижения расхода полосы каналов на анонсирование и ресурсов системы, требуемых на этапе выбора маршрутов (Decision Process) для обработки информации, содержащейся в сообщениях UPDATE.

9.2.1.1. Частота анонсирования маршрутов

Параметр MinRouteAdvertisementInterval определяет минимальное время, которое должно пройти между анонсированием и/или отзывом маршрутов для конкретного адресата от одного узла BGP. Процедура ограничения частоты рассылки обновлений применяется независимо для каждого адресата, хотя значение MinRouteAdvertisementInterval устанавливается для узла BGP в целом.

Два сообщения UPDATE, передаваемые партнеру узлом BGP, с анонсами доступных и/или недоступных маршрутов к некоторому общему набору адресатов, должны быть разделены промежутком времени не менее MinRouteAdvertisementInterval. Очевидно, что для достижения этого требуется использовать отдельный таймер для каждого общего набора адресатов. Такой подход будет порождать недопустимую нагрузку (overhead). Для практического применения подходит любой метод, обеспечивающий между двумя последовательными сообщениями UPDATE с анонсом доступных и/или недоступных маршрутов к некому множеству адресатов, адресованными одному партнеру, интервал не менее MinRouteAdvertisementInterval и способный гарантировать приемлемое постоянное значение верхней границы для такого интервала.

Поскольку внутри AS требуется быстрое схождение маршрутов, (a) значение MinRouteAdvertisementIntervalTimer, используемое для внутренних партнеров, следует делать меньше значения этого параметра для внешних партнеров или (b) описанную здесь процедуру не следует применять для маршрутов, передаваемых внутренним партнерам.

Эта процедура не ограничивает скорость выбора маршрута, внося лишь ограничение на частоту анонсирования. Если новые маршруты были выбраны несколько раз в течение ожидания MinRouteAdvertisementInterval, по завершении этого периода следует анонсировать последний выбранный маршрут.

9.2.1.2. Частота обновления из исходной AS

Параметр MinASOriginationInterval определяет минимальный интервал времени между последовательными сообщениями UPDATE, которые содержат информацию об изменениях внутри AS анонсирующего узла BGP.

9.2.2. Эффективная организация маршрутных данных

Имея маршрутную информацию для анонсирования, узел BGP может воспользоваться несколькими методами эффективной организации маршрутных данных.

9.2.2.1. Снижение объема информации

Снижение объема информации означает снижение уровня гранулярности контроля над политикой маршрутизации — после сжатия информации одни и те же правила будут применяться ко всем адресатам и путям одного класса.

Процесс выбора маршрутов (Decision Process) может дополнительно снижать объем информации, включаемой в базу Adj-RIBs-Out, любым из перечисленных ниже методов.

  1. Информация о доступности на сетевом уровне (NLRI)

    IP-адреса получателей могут быть представлены как префиксы IP. В тех случаях, когда имеется соответствие между структурой адреса и системами, находящимися под управлением администратора AS, можно уменьшить размер NLRI, передаваемых в сообщениях UPDATE.

  2. AS_PATH:

    Информация об AS в пути может быть упорядоченной (AS_SEQUENCE) или неупорядоченной (AS_SET). Вариант AS_SET используется в алгоритме агрегирования маршрутов, описанном в параграфе 9.2.2.2. Агрегирование снижает объем данных AS_PATH за счет однократного указания номера каждой AS (независимо от числа ее упоминаний во множестве агрегируемых атрибутов AS_PATH).

    AS_SET означает, что адресаты, указанные в NLRI, могут быть достигнуты по пути, проходящему по крайней мере через некоторые из включенных в сегмент AS. Сегменты AS_SET обеспечивают достаточную информацию для предотвращения маршрутных петель, однако при их использовании могут теряться потенциально возможные пути, поскольку они больше не указываются индивидуально в форме AS_SEQUENCE. На практике это обычно не вызывает проблем, поскольку по прибытии одного пакета IP на границу группы AS узел BGP в этой точке явно будет иметь более детальную информацию о пути и сможет различать отдельные маршруты к адресатам.

9.2.2.2. Агрегирование маршрутной информации

Агрегирование представляет собой процесс объединения характеристик нескольких маршрутов таким образом, чтобы их можно было анонсировать как единый маршрут. Агрегирование может выполняться как часть процесса выбора маршрутов для снижения объема маршрутных данных, помещаемых в AdjRIBsOut.

Агрегирование снижает объем информации, которую узел BGP должен сохранять и рассылать другим узлам BGP. Маршруты можно агрегировать путем применения описанной ниже процедуры раздельно к однотипным атрибутам пути и NLRI.

Маршруты с разными атрибутами MULTI_EXIT_DISC не следует агрегировать.

Если агрегированный маршрут имеет сегмент AS_SET в качестве первого элемента атрибута AS_PATH, маршрутизатору, от которого исходит маршрут, не следует анонсировать с этим маршрутом атрибут MULTI_EXIT_DISC.

Атрибуты пути с различными кодами типа не могут быть агрегированы. Однотипные атрибуты пути могут агрегироваться в соответствии с приведенными ниже правилами:

NEXT_HOP

При агрегировании маршрутов с разными атрибутами NEXT_HOP в атрибуте NEXT_HOP агрегированного маршрута следует указывать интерфейс узла BGP, выполняющего агрегирование.

Атрибут ORIGIN

Если хотя бы один из агрегируемых маршрутов имеет ORIGIN = INCOMPLETE, для объединенного маршрута также должно устанавливаться ORIGIN = INCOMPLETE. Если хотя бы один из объединяемых маршрутов имеет значение ORIGIN = EGP, агрегированный маршрут также должен иметь значение EGP для этого атрибута. В остальных случаях для агрегированного маршрута устанавливается ORIGIN = IGP.

Атрибут AS_PATH

Если агрегируемые маршруты имеют идентичные атрибуты AS_PATH, объединенный маршрут имеет такое же значение AS_PATH.

В целях объединения атрибутов AS_PATH будем моделировать каждую AS в атрибуте AS_PATH как пару <type, value>, где type определяет тип сегмента пути, к которому относится AS (например, AS_SEQUENCE, AS_SET), а value указывает номер AS. Если агрегируемые маршруты имеют разные атрибуты AS_PATH, для агрегированного атрибута AS_PATH следует обеспечить выполнение всех перечисленных ниже требований:

  • всем парам типа AS_SEQUENCE агрегированного AS_PATH следует присутствовать в каждом атрибуте AS_PATH исходного набора агрегируемых маршрутов;

  • всем парам типа AS_SET агрегированного AS_PATH следует присутствовать хотя бы в одном атрибуте AS_PATH исходного набора (возможно, как AS_SET или AS_SEQUENCE);

  • для любой пары X типа AS_SEQUENCE в агрегированном AS_PATH, которая предшествует паре Y агрегированного AS_PATH, X предшествует Y в каждом атрибуте AS_PATH исходного набора, который содержит Y, независимо от типа Y;

  • ни одной паре типа AS_SET не следует появляться в агрегированном AS_PATH более одного раза;

  • множество пар типа AS_SEQUENCE с одинаковыми значениями может присутствовать в агрегированном AS_PATH только по соседству с другой однотипной парой с совпадающим значением.

Разработчики могут выбирать любой алгоритм, который обеспечивает соответствие приведенным правилам. Соответствующей требованиям этого документа реализации следует поддерживать по крайней мере описанный ниже алгоритм для выполнения всех приведенных выше требований:

  • определить наиболее длинную последовательность лидирующих пар (как описано выше), присутствующую в атрибутах AS_PATH всех объединяемых маршрутов и сделать ее лидирующей в AS_PATH объединенного атрибута;

  • установить для оставшихся пар из атрибутов AS_PATH объединяемых маршрутов тип AS_SET и присоединить их в конце агрегированного атрибута AS_PATH;

  • если объединенный атрибут AS_PATH содержит несколько одинаковых пар (независимо от типа), лишние (все, кроме одной) пары типа AS_SET следует удалить из объединенного атрибута AS_PATH;

  • для каждых двух смежных пар в агрегированном AS_PATH следует произвести операцию их слияния, если пары имеют одинаковый тип и размер сегмента не будет превышать 255.

В приложении F (параграф F.6) представлен другой алгоритм, соответствующий условиям и допускающий более сложную конфигурационную политику.

Атрибут ATOMIC_AGGREGATE

Если хотя бы один из объединяемых маршрутов имеет атрибут ATOMIC_AGGREGATE, в объединенный маршрут также следует включать этот атрибут.

Атрибут AGGREGATOR

Любые атрибуты AGGREGATOR из агрегируемых маршрутов недопустимо включать в агрегированный маршрут. Выполняющий агрегирование узел BGP может включить в маршрут новый атрибут AGGREGATOR (Параграф 5.1.7).

9.3. Критерии выбора маршрута

В общем случае рассмотрение дополнительных правил сравнения маршрутов выходит за пределы данного документа. Однако имеются два исключения:

  • если локальная AS присутствует в пути нового маршрута, этот маршрут не может считаться лучше какого-либо из имеющихся путей (предполагается, что узел принимает такие маршруты); нарушение этого правила ведет к возникновению маршрутных петель;

  • для обеспечения эффективной распределенной обработки следует выбирать только маршруты, представляющиеся стабильными. Таким образом, AS следует избегать применения нестабильных маршрутов и не следует вносить скороспелых спонтанных изменений при выборе путей. Трактовка слов «нестабильный» и «скороспелый» в предыдущем предложении требует некоторого опыта, но, в принципе, достаточно понятна. Нестабильные маршруты могут быть “оштрафованы” (например, с использованием процедур, описанных в документе [RFC2439]).

9.4. Порождение маршрутов BGP

Узел BGP может порождать (originate) маршруты BGP, помещая информацию, полученную из других источников (например, IGP), в BGP. Порождающий маршруты узел BGP указывает для таких маршрутов уровень предпочтения (например, в соответствии с локальной политикой), используя для этого Decision Process (Параграф 9.1). Эти маршруты могут также рассылаться другим узлам BGP в локальной AS, как часть процесса обновления (Параграф 9.2). Решение о целесообразности рассылки полученной из других источников информации внутри AS с использованием BGP зависит от используемой в AS среды (например, типа IGP) и его следует задавать на уровне конфигурации.

10. Таймеры BGP

BGP поддерживает пять таймеров — ConnectRetryTimer (см. главу 8), HoldTimer (Параграф 4.2), KeepaliveTimer (см. главу 8), MinASOriginationIntervalTimer (Параграф 9.2.1.2) и MinRouteAdvertisementIntervalTimer (Параграф 9.2.1.1).

Могут также поддерживаться два дополнительных таймера — DelayOpenTimer и IdleHoldTimer (см. главу 8). Использование этих таймеров описано в главе 8. Полное описание работы этих дополнительных таймеров выходит за пределы данного документа.

Параметр ConnectRetryTime является обязательным атрибутом FSM и хранит начальное значение для таймера ConnectRetryTimer. Предлагается по умолчанию устанавливать значение ConnectRetryTime равным 120 секундам.

Параметр HoldTime является обязательным атрибутом FSM и сохраняет начальное значение таймера HoldTimer. Предлагается по умолчанию использовать для HoldTime значение 90 секунд.

На некоторых этапах (см. главу 8) для HoldTimer устанавливается большое значение. Предлагается в качестве такого значения устанавливать 4 минуты.

Параметр KeepaliveTime является обязательным атрибутом FSM и сохраняет начальное значение таймера KeepaliveTimer. По умолчанию предлагается устанавливать для KeepaliveTime значение 1/3 HoldTime.

Для таймера MinASOriginationIntervalTimer предлагается по умолчанию использовать значение 15 секунд.

Для таймера MinRouteAdvertisementIntervalTimer предлагается устанавливать значение 30 секунд на соединениях EBGP.

Для таймера MinRouteAdvertisementIntervalTimer предлагается устанавливать значение 5 секунд на соединениях IBGP.

Реализация BGP должна обеспечивать возможность установки значения HoldTimer с помощью конфигурационного параметра независимо для каждого партнера и может обеспечивать возможность выбора значений для других таймеров.

Для снижения вероятности возникновения пиков при распространении сообщений BGP данным узлом следует использовать флуктуации (jitter) для таймеров, связанных с MinASOriginationIntervalTimer, KeepaliveTimer, MinRouteAdvertisementIntervalTimer и ConnectRetryTimer. Данный узел BGP может использовать одинаковые флуктуации для каждого из этих таймеров независимо от адресатов передаваемых обновлений (т. е., флуктуации не требуется делать независимыми для каждого партнера).

Предлагаемую по умолчанию величину флуктуаций следует определять путем умножения базового значения соответствующего таймера на случайное значение из диапазона 0,75 — 1,0. При каждой установке таймера следует выбирать новое случайное значение. Диапазон флуктуаций может быть настраиваемым.

Приложение A. Сравнение с RFC 1771

В настоящем документе имеется множество редакторских правок спецификации [RFC1771] (слишком много для перечисления).

Ниже приводится список технических изменений:

Внесены изменения, связанные с использованием TCP MD5 [RFC2385], BGP Route Reflectors [RFC2796], BGP Confederations [RFC3065] и BGP Route Refresh [RFC2918].

Разъяснено использование поля BGP Identifier в атрибуте AGGREGATOR.

Процедуры задания верхней границы для числа префиксов, которые узел BGP будет принимать от партнера.

Возможность включать более одного экземпляра своей AS в атрибут AS_PATH для управления картиной трафика между AS.

Разъяснены различные типы NEXT_HOP.

Разъяснено использование атрибута ATOMIC_AGGREGATE.

Соотношения между ближайшим маршрутизатором (immediate next hop) и следующим маршрутизатором, указанным атрибутом пути NEXT_HOP.

Разъяснены процедуры “отбрасывания лишнего” (tie-breaking).

Разъяснены требования по частоте анонсирования маршрутов.

Отменено использование дополнительного параметра типа 1 (Authentication Information).

Отменен субкод 7 (AS Routing Loop) для ошибок в сообщениях UPDATE.

Отменен субкод 5 (Authentication Failure) для ошибок в сообщениях OPEN.

Отменено использование поля Marker для аутентификации.

Реализация должна поддерживать механизм TCP MD5 [RFC2385] для аутентификации.

Разъяснена работа BGP FSM.

Приложение B. Сравнение с RFC 1267

Все изменения, перечисленные в Приложении A, а также указанные ниже изменения.

BGP-4 может работать в среде, где множество доступных адресатов может указываться с помощью одного префикса IP. Концепция классов сетей или подсетей чужеродна для BGP-4. Для поддержки работы с префиксами в BGP-4 изменена семантика и кодирование, связанное с атрибутом AS_PATH. В спецификацию добавлено определение семантики, связанной с префиксами IP. Такое расширение позволяет BGP-4 поддерживать предложенную схему supernet [RFC1518, RFC1519].

Для упрощения настройки вводится новый атрибут LOCAL_PREF, упрощающий процедуру выбора маршрута.

Атрибут INTER_AS_METRIC переименован в MULTI_EXIT_DISC.

Добавлен новый атрибут ATOMIC_AGGREGATE для управления возможностью деагрегирования маршрутов. Другой новый атрибут — AGGREGATOR — может добавляться в агрегированные маршруты, чтобы указать, какая AS и какой узел BGP в этой AS выполнили агрегирование.

Для обеспечения симметрии значение Hold Time согласуется на уровне соединений. Поддерживаются нулевые значения Hold Time.

Приложение C. Сравнение с RFC 1163

Все изменения, перечисленные в Приложениях A и B, а также указанные ниже изменения.

Для обнаружения конфликтов при соединениях BGP и восстановления работы протокола добавлено новое поле BGP Identifier в сообщения OPEN. Для описания процедур детектирования и разрешения конфликтов при соединениях в документ добавлен новый параграф (6.8).

Снято ограничение, требовавшее чтобы граничный маршрутизатор, указанный атрибутом пути NEXT_HOP, относился к той же AS, в которой находится узел BGP.

В новом документе оптимизировано и упрощено описание процедур обмена информацией о ранее доступных маршрутах.

Приложение D. Сравнение с RFC 1105

Все изменения, перечисленные в Приложениях A, B и C, а также указанные ниже изменения.

Потребовалось внесение незначительных изменений в машину конечных состояний RFC1105 для согласования с пользовательским интерфейсом TCP в системах BSD версии 4.3.

Понятия и отношения Up/Down/Horizontal, присутствующие в RFC1105, были исключены из протокола.

Внесен ряд изменений в формат сообщений RFC1105:

  1. Поле Hold Time было удалено из заголовка BGP и включено в сообщение OPEN.

  2. Поле номера версии было удалено из заголовка BGP и включено в сообщение OPEN.

  3. Из сообщений OPEN было удалено поле Link Type.

  4. Вместо подтверждений OPEN CONFIRM используются сообщения KEEPALIVE.

  5. Существенно изменен формат сообщений UPDATE, добавлены новые поля для поддержки множества атрибутов пути.

  6. Поле Marker было расширено и стало использоваться также для аутентификации.

Отметим, что достаточно часто протокол BGP, соответствующий RFC 1105, называют BGP-1, соответствующий RFC 1163 — BGP-2, а соответствующий RFC 1267 — BGP-3. Вариант BGP, описанный в этом документе, называют BGP-4.

Приложение E. Опции TCP, которые могут использоваться с BGP

Если пользовательский интерфейс TCP в локальной системе поддерживает функцию TCP PUSH, каждое сообщение BGP следует передавать с установленным флагом PUSH. Установка флага приводит к ускорению передачи сообщений BGP.

Если пользовательский интерфейс TCP в локальной системе поддерживает установку поля DSCP [RFC2474] для соединений TCP, транспортные соединения для BGP следует открывать с битами 0-2 поля DSCP, имеющими двоичное значение 110.

Реализация должна поддерживать опцию TCP MD5 [RFC2385].

Приложение F. Рекомендации для разработчиков

В этом приложении даются некоторые рекомендации разработчикам.

Приложение F.1. Множество префиксов сетей в одном сообщении

Протокол BGP позволяет указывать в одном сообщении множество адресных префиксов с одинаковыми атрибутами пути. Настоятельно рекомендуется использовать эту возможность. Передача сообщений с единственным префиксом существенно повышает нагрузку на получателя. В результате передачи множества сообщений растет не только нагрузка на системы, но и издержки при сканировании таблиц маршрутизации для передачи обновлений партнерам BGP и другим протоколам маршрутизации (увеличивается и объем передаваемых обновлений).

Одним из способов создания сообщений с множеством префиксов для каждого набора атрибутов пути из таблицы маршрутизации, не организованной по наборам атрибутов, является создание множества сообщений при сканировании таблицы. При обработке каждого префикса создается сообщение для связанного набора атрибутов пути, если оно не существует и в это сообщение добавляется новый префикс. Если сообщение уже создано, новый префикс просто добавляется в конец этого сообщения. Если в сообщение уже нельзя добавить новый префикс по соображениям размера, имеющееся сообщение передается, а для префикса создается новое сообщение. После завершения сканирования всей таблицы маршрутов созданные сообщения передаются и выделенные для них ресурсы освобождаются. Максимальное сжатие при таком методе обеспечивается в тех случаях, когда все адресаты перекрываются адресными префиксами с одним набором атрибутов пути. В этом случае сообщение может содержать столько префиксов, сколько позволяет ограничение на размер сообщений BGP (4096 октетов).

При работе с реализациями BGP, которые не поддерживают множества префиксов в одном сообщении, может потребоваться выполнение ряда операций для снижения нагрузки в результате лавинной рассылки данных, полученных при обретении нового партнера или существенном изменении сетевой топологии. Одним из способов такого снижения является ограничение частоты передачи обновлений. Это позволяет избавиться от избыточного сканирования таблиц для «мгновенного» обновления узлов BGP и других протоколов маршрутизации. Недостатком этого способа является увеличение задержек при распространении маршрутной информации. Выбор минимального интервала обновлений, который незначительно превышает время обработки множества сообщений, позволяет минимизировать эту задержку. Наилучшим решением будет просмотр всех полученных сообщений до передачи обновлений.

Приложение F.2. Снижение числа переключений маршрутов

Во избежание ненужных переключений маршрутов (route flapping) узлу BGP, которому нужно отозвать маршрут к адресатам и передать обновление с более (или менее) специфичным маршрутом, следует объединять такие анонсы в одно сообщение UPDATE.

Приложение F.3. Упорядочение атрибутов пути

Реализации, комбинирующие обновления (как описано в приложении F.132), могут предпочесть просмотр всех атрибутов пути, представленных в определенном порядке. Такой подход позволяет быстро идентифицировать наборы атрибутов из разных обновлений, которые идентичны семантически. Для реализации такого подхода полезно упорядочивать атрибуты в соответствии с кодом типа. Такая оптимизация не является обязательной.

Приложение F.4. Сортировка AS_SET

Другим полезным способом оптимизации является упорядочение по номерам AS, найденным в атрибуте AS_SET. Такая оптимизация не является обязательной.

Приложение F.5. Контроль за согласованием версий

Поскольку протокол BGP-4 может передавать агрегированные маршруты, которые не могут быть корректно представлены в BGP-3, реализациям, поддерживающим BGP-4 и иные версии BGP, следует обеспечивать возможность работы только с BGP-4 независимо для каждого партнера.

Приложение F.6. Комплексное агрегирование AS_PATH

Реализация, обеспечивающая механизм агрегирования маршрутов с сохранением значительного количества данных о пути, может использовать описанную ниже процедуру.

Для объединения атрибутов AS_PATH двух маршрутов будем представлять каждую AS как пару <type, value>, где type указывает тип сегмента пути, к которому принадлежит AS (например, AS_SEQUENCE, AS_SET), а value задает номер AS. Если две пары <type, value> совпадают, они относятся к одной AS.

Алгоритм объединения двух атрибутов AS_PATH работает следующим образом:

  1. Идентифицируется совпадение AS (как описано выше) в каждом атрибуте AS_PATH, которые находятся в том же относительном порядке для каждого атрибута AS_PATH. Две AS (X и Y) следуют в одинаковом порядке, если выполняется любое из приведенных ниже условий:

  • X предшествует Y в обоих атрибутах AS_PATH;

  • Y предшествует X в обоих атрибутах AS_PATH.

  1. Агрегированный атрибут AS_PATH состоит из AS, найденных на этапе (a) и представленных в том же порядке, который был обнаружен в объединяемых атрибутах AS_PATH. Если две последовательные AS, найденные на этапе (a), не следуют одна за другой непосредственно в каждом из объединяемых атрибутов AS_PATH, мешающие AS (AS, расположенные между двумя последовательно совпадающими AS) из обоих атрибутов объединяются в сегмент пути AS_SET. Этот сегмент пути помещается в агрегированном атрибуте между двумя последовательными AS, идентифицированными в пункте (a).

  2. Для каждых из двух смежных пар в агрегированном AS_PATH (если они имеют одинаковый тип) выполняется слияние, если оно не будет приводить к генерации сегмента пути размером более 255.

Если в результате применения описанной выше процедуры данный номер AS появляется в агрегированном атрибуте AS_PATH более одного раза, все вхождения этого номера, кроме последнего (самый правый) следует удалить из агрегированного атрибута PATH.

Вопросы безопасности

Реализация BGP должна поддерживать механизм аутентификации, определенный в RFC 2385 [RFC2385]. Аутентификация на основе этого механизма может осуществляться независимо для каждого партнера.

BGP использует протокол TCP для организации надежного обмена трафиком между маршрутизаторами-партнерами. Для обеспечения целостности соединений и аутентификации источников данных в соединениях между парами узлов спецификация BGP задает использование механизма, определенного в RFC 2385. Этот механизм предназначен для детектирования и предотвращения активного перехвата (wiretapping attacks) данных из соединений TCP между маршрутизаторами. В отсутствие такого рода механизмов обеспечения безопасности атакующие могут разрывать соединения TCP и/или маскироваться под легитимные партнерские маршрутизаторы. Поскольку определенный в RFC механизм не обеспечивает аутентификацию партнеров, протокольные соединения могут служить объектом некоторых атак с повторным использованием перехваченных ранее данных (replay attack), которые не будут детектироваться уровнем TCP. Такие атаки могут приводить к доставке (от уровня TCP) “испорченных” или “подмененных” сообщений BGP.

Механизм, определенный в RFC 2385, добавляет к обычным контрольным суммам TCP 16-байтовый код аутентификации сообщения (MAC1) который рассчитывается на основе тех же данных, что и контрольная сумма TCP. Расчет MAC основан на использовании необратимой хэш-функции (MD5) и закрытых ключей. Ключ известен паре маршрутизаторов-партнеров и используется для генерации значений MAC, которые не могут быть вычислены атакующим без знания ключа. Соответствующие спецификации реализации протокола должны поддерживать этот механизм и позволять администратору активизировать его использование независимо для каждого партнера.

RFC 2385 не задает механизмов поддержки ключей (например, их генерации, распространения и замены), используемых для расчета MAC. Документ RFC 3562 [RFC3562] (он имеет статус информационного) содержит некоторые рекомендации в этом направлении с обоснованием приведенных рекомендаций. В документе отмечается, что следует использовать разные ключи для связи с каждым защищенным партнером. Если один ключ используется для множества партнеров, это может привести к снижению уровня безопасности (например, за счет того, что при компрометации одного маршрутизатора становятся известными ключи, используемые для других маршрутизаторов).

Используемые для расчета MAC ключи следует периодически заменять для минимизации возможности компрометации ключа или успешной криптоаналитической атаки. В RFC 3562 предлагается устанавливать крипто-период (срок действия ключа) не более 90 дней. Более частая смена ключей снижает вероятность успеха атак с повторным использованием перехваченных данных. Однако отсутствие стандартного механизма эффективной координированной замены ключа, используемого парой маршрутизаторов, не позволяет надеяться, что реализации BGP-4, соответствующие данной спецификации, будут поддерживать такую частоту смены ключей.

Очевидно, что ключи следует выбирать так, чтобы атакующему было сложно угадать или подобрать ключ. Описанные в RFC 1750 методы генерации случайных чисел обеспечивают руководство по созданию значений, которые могут использоваться в качестве ключей. RFC 2385 предлагает разработчикам использовать ключи, представляющие собой строки печатных символов ASCII размером 80 байтов или меньше. В RFC 3562 предлагается в таком контексте использовать ключи размером от 12 до 24 байтов, состоящие из случайных (псевдослучайных) битов. Это полностью совместимо с предложениями для аналогичных алгоритмов MAC, которые обычно используют ключи размером от 16 до 20 байтов. В части обеспечения достаточного уровня случайности при использовании ключей минимальной длины в RFC 3562 также отмечается,что типичная срока текста ACSII будет близка к верхней границе диапазона длины ключей, заданного в RFC 2385.

Анализ уязвимостей протокола BGP приводится в документе [RFC4272].

Взаимодействие с IANA

Все сообщения BGP содержат 8-битовые идентификаторы типа сообщения, для которых агентство IANA создало и поддерживает реестр BGP Message Types1. В данном документе определены следующие типы сообщений:

Имя

Значение

Определение

OPEN

1

Параграф 4.2.

UPDATE

2

Параграф 4.3.

NOTIFICATION

3

Параграф 4.5.

KEEPALIVE

4

Параграф 4.4.

Выделение новых значений для типов сообщений происходит на основе процесса стандартизации (Standards Action), определенного в [RFC2434], или путем “Заблаговременного выделения агентством IANA2”, как описано в [RFC4020]. Типы сообщений задаются именем и числовым идентификатором.

Сообщения BGP UPDATE могут содержать один или множество атрибутов пути (Path Attribute), каждый из которых включает 8-битовый код типа (Attribute Type Code). Агентство IANA поддерживает реестр таких кодов, названный «BGP Path Attributes3«. В этом документе определяются следующие типы атрибутов пути (Path Attributes Type Code)

Имя

Значение

Определение

ORIGIN

1

Параграф 5.1.1.

AS_PATH

2

Параграф 5.1.2.

NEXT_HOP

3

Параграф 5.1.3.

MULTI_EXIT_DISC

4

Параграф 5.1.4.

LOCAL_PREF

5

Параграф 5.1.5.

ATOMIC_AGGREGATE

6

Параграф 5.1.6.

AGGREGATOR

7

Параграф 5.1.7.

Выделение новых значений для кодов атрибутов пути происходит на основе процесса стандартизации (Standards Action), определенного в [RFC2434], или путем “Заблаговременного выделения агентством IANA”, как описано в [RFC4020]. Типы атрибутов задаются именем и числовым идентификатором.

Сообщения BGP NOTIFICATION содержат 8-битовые значения кода ошибки (Error Code), для которых агентство IANA создало и поддерживает реестр «BGP Error Codes4«. В этом документе определены следующие коды ошибок:

Имя

Значение

Определение

Message Header Error

1

Параграф 6.1.

OPEN Message Error

2

Параграф 6.2.

UPDATE Message Error

3

Параграф 6.3.

Hold Timer Expired

4

Параграф 6.5.

Finite State Machine Error

5

Параграф 6.6.

Cease

6

Параграф 6.7.

Выделение новых значений для кодов ошибок происходит на основе процесса стандартизации (Standards Action), определенного в [RFC2434], или путем «Заблаговременного выделения агентством IANA», как описано в [RFC4020]. Коды ошибок задаются именем и числовым идентификатором.

Сообщения BGP NOTIFICATION содержат 8-битовые значения субкода ошибки (Error Subcode) и каждое значение субкода определяется в контексте соответствующего кода ошибки (Error Code) и, таким образом, является уникальным только в этом контексте.

Агентство IANA создало и поддерживает набор реестров Error Subcodes33, в котором для каждого кода ошибки BGP имеется отдельный реестр. Выделение новых значений для субкодов ошибок происходит на основе процесса стандартизации (Standards Action), определенного в [RFC2434], или путем “Заблаговременного выделения агентством IANA”, как описано в [RFC4020]. Субкоды ошибок задаются именем и числовым идентификатором.

В этом документе определяются следующие субкоды для ошибок в заголовках сообщений (Message Header Error)

Имя

Значение

Определение

Connection Not Synchronized

1

Параграф 6.1.

Bad Message Length

2

Параграф 6.1.

Bad Message Type

3

Параграф 6.1.

В этом документе определяются следующие субкоды для ошибок в сообщениях OPEN (OPEN Message Error)

Имя

Значение

Определение

Unsupported Version Number

1

Параграф 6.2.

Bad Peer AS

2

Параграф 6.2.

Bad BGP Identifier

3

Параграф 6.2.

Unsupported Optional Parameter

4

Параграф 6.2.

[отменено]

5

Приложение A.

Unacceptable Hold Time

6

Параграф 6.2.

В этом документе определяются следующие субкоды для ошибок в сообщениях UPDATE (UPDATE Message Error)

Имя

Значение

Определение

Malformed Attribute List

1

Параграф 6.3.

Unrecognized Well-known Attribute

2

Параграф 6.3.

Missing Well-known Attribute

3

Параграф 6.3.

Attribute Flags Error

4

Параграф 6.3.

Attribute Length Error

5

Invalid ORIGIN Attribute

6

Параграф 6.3.

[отменено]

7

Приложение A.

Invalid NEXT_HOP Attribute

8

Optional Attribute Error

9

Invalid Network Field

10

Malformed AS_PATH

11

Нормативные документы

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2385] Heffernan, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, August 1998.

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

Дополнительная литература

[RFC904] Mills, D., «Exterior Gateway Protocol formal specification», RFC 904, April 1984.

[RFC1092] Rekhter, J., «EGP and policy based routing in the new NSFNET backbone», RFC 1092, February 1989.

[RFC1093] Braun, H., «NSFNET routing architecture», RFC 1093, February 1989.

[RFC1105] Lougheed, K. and Y. Rekhter, «Border Gateway Protocol (BGP)», RFC 1105, June 1989.

[RFC1163] Lougheed, K. and Y. Rekhter, «Border Gateway Protocol (BGP)», RFC 1163, June 1990.

[RFC1267] Lougheed, K. and Y. Rekhter, «Border Gateway Protocol 3 (BGP-3)», RFC 1267, October 1991.

[RFC1771] Rekhter, Y. and T. Li, «A Border Gateway Protocol 4 (BGP-4)», RFC 1771, March 1995.

[RFC1772] Rekhter, Y. and P. Gross, «Application of the Border Gateway Protocol in the Internet», RFC 1772, March 1995.

[RFC1518] Rekhter, Y. and T. Li, «An Architecture for IP Address Allocation with CIDR», RFC 1518, September 1993.

[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, «Classless Inter-Domain Routing (CIDR) an Address Assignment and Aggregation Strategy», RFC 1519, September 1993.

[RFC1930] Hawkinson, J. and T. Bates, «Guidelines for creation, selection, and registration of an Autonomous System (AS)», BCP 6, RFC 1930, March 1996.

[RFC1997] Chandra, R., Traina, P., and T. Li, «BGP Communities Attribute», RFC 1997, August 1996.

[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, «BGP Route Flap Damping», RFC 2439, November 1998.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, December 1998.

[RFC2796] Bates, T., Chandra, R., and E. Chen, «BGP Route Reflection — An Alternative to Full Mesh IBGP», RFC 2796, April 2000.

[RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, «Multiprotocol Extensions for BGP-4», RFC 285834, June 2000.

[RFC3392] Chandra, R. and J. Scudder, «Capabilities Advertisement with BGP-4», RFC 339235, November 2002.

[RFC2918] Chen, E., «Route Refresh Capability for BGP-4», RFC 2918, September 2000.

[RFC3065] Traina, P., McPherson, D., and J. Scudder, «Autonomous System Confederations for BGP», RFC 3065, February 2001.

[RFC3562] Leech, M., «Key Management Considerations for the TCP MD5 Signature Option», RFC 3562, July 2003.

[IS10747] «Information Processing Systems — Telecommunications and Information Exchange between Systems — Protocol for Exchange of Inter-domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs», ISO/IEC IS10747, 1993.

[RFC4272] Murphy, S., «BGP Security Vulnerabilities Analysis», RFC 4272, January 2006

[RFC4020] Kompella, K. and A. Zinin, «Early IANA Allocation of Standards Track Code Points», BCP 100, RFC 4020, February 2005.

Адреса редакторов

Yakov Rekhter

Juniper Networks

EMail: yakov@juniper.net

Tony Li

EMail: tony.li@tony.li

Susan Hares

NextHop Technologies, Inc.

825 Victors Way

Ann Arbor, MI 48108

Phone: (734)222-1610

EMail: skh@nexthop.com

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

1Border Gateway Protocol — протокол граничного шлюза.

2Classless Interdomain Routing — бесклассовая междоменная маршрутизация. Прим. перев.

1 Internet Engineering Steering Group

3 inter-Autonomous System routing protocol

4Route Refresh — обновление маршрута.

5Network Layer Reachability Information — информация о доступности на сетевом уровне.

6Routing Information Base

7С предыдущими версиями спецификации протокола BGP. Прим. перев.

8 Значение поля Type=5 используется для сообщений Route-Refresh, добавленных в RFC 2918. Прим. перев.

9 Если в AS используется 4-октетный номер, данное поле содержит зарезервированное значение 23456, определенное в RFC 4893. Прим. перев.

10Переходным. Прим. перев.

11В настоящее время могут использоваться также 4-октетные значения номеров AS. Поддержка таких значений определена в RFC 4893. Прим. перев.

12Unicast.

13В оригинале субкоды 0 отсутствуют, см. https://www.rfc-editor.org/errata/eid4493. Прим. перев.

14Этот атрибут рассматривается в RFC 4451. Прим. перев.

15“the BGP connection is closed“

16Текст этого абзаца изменен в RFC 7606. Прим. перев.

17В оригинале текст этого предложения отличается, см. https://www.rfc-editor.org/errata/eid1633. Прим. перев.

18Finite State Machine — машина конечных состояний.

19BGP Policy engine

20RFC 4724 дополняет текст этого предложения. Прим. перев.

21Этого предложения нет в оригинальном документе, см. https://www.rfc-editor.org/errata/eid2838. Прим. перев.

22В оригинале ошибочно сказано OpenConfirmed, см. https://www.rfc-editor.org/errata/eid5421. Прим. перев.

23RFC 4724 меняет текст этого предложения. Прим. перев.

24RFC 4724 меняет текст этого абзаца. Прим. перев.

25RFC 8212 добавляет к этому параграфу еще один абзац. Прим. перев.

26В оригинале ошибочно сказано «может не передаваться», см. https://www.rfc-editor.org/errata/eid5000. Прим. перев.

27Локальный узел не имеет маршрута для этого адреса в своей таблице. Прим. перев.

28Протокола внутренней маршрутизации. Прим. перев.

29immediate (directly connected) next-hop address.

30RFC 4456 вносит изменение в это правило и добавляет еще одно правило между f) и g). Прим. перев.

31RFC 8212 добавляет к этому параграфу еще один абзац. Прим. перев.

32В оригинале ошибочно указан параграф 6.1, см. https://www.rfc-editor.org/errata/eid3264. Прим. перев.

1Message authentication code.

1Типы сообщений BGP. Реестр доступен по адресу http://www.iana.org/assignments/bgp-parameters. Прим. перев.

2Early IANA Allocation.

3Атрибуты путей BGP. Реестр доступен по адресу http://www.iana.org/assignments/bgp-parameters. Прим. перев.

4Коды ошибок BGP. Реестр доступен по адресу http://www.iana.org/assignments/bgp-parameters. Прим. перев.

33Субкоды ошибок BGP. Реестр доступен по адресу http://www.iana.org/assignments/bgp-parameters. Прим. перев.

34Этот документ заменен RFC 4760. Прим. перев.

35Этот документ заменен RFC 5492. Прим. перев.

 




RFC 4256 Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)

Network Working Group                                      F. Cusack
Request for Comments: 4256                              savecore.net
Category: Standards Track                                 M. Forssen
                                         AppGate Network Security AB
                                                        January 2006

Базовая аутентификация обмена сообщениями для SSH

Generic Message Exchange Authentication for

the Secure Shell Protocol (SSH)

PDF

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2006).

Тезисы

Протокол SSH [6] обеспечивает защищенный вход в удаленные системы (remote login) и другие защищенные услуги в сетях без защиты. В этом документе описан метод проверки подлинности общего назначения для протокола SSH, пригодный для интерактивной проверки подлинности, когда данные для проверки должны вводиться с клавиатуры (или заменяющего ее алфавитно-цифрового устройства ввода). Основная цель этого метода заключается в обеспечении клиентам SSH возможности поддержки целого класса механизмов проверки подлинности без наличия сведений о специфике конкретного механизма.

1. Введение

Протокол аутентификации SSH [SSH-USERAUTH] представляет собой протокол общего назначения для проверки подлинности пользователей. Этот протокол предназначен для работы поверх транспортного протокола SSH [SSH-TRANS]. Протокол аутентификации предполагает, что нижележащие протоколы обеспечивают целостность и конфиденциальность данных.

В этом документе описан метод проверки подлинности общего назначения для протокола аутентификации SSH. Этот метод подходит для интерактивных вариантов проверки подлинности, не требующих какой-либо специальной программной поддержки на стороне клиента. Все аутентификационные данные должны вводиться с клавиатуры. Основная цель этого метода заключается в том, чтобы позволить клиентам SSH не иметь информации об используемых сервером SSH механизмах аутентификации или обходиться минимальным объемом такой информации. Это будет позволять серверам произвольно выбирать или менять механизмы аутентификации без необходимости обновления кода на клиентской стороне.

Для этого метода проверки подлинности используется имя «keyboard-interactive».

Данный документ следует читать после ознакомления с архитектурой SSH [SSH-ARCH] и протоколом аутентификации SSH [SSH-USERAUTH]. В данном документе используется терминология и нотация из упомянутых документов без ссылок и дополнительных разъяснений.

В документе также описаны некоторые процедуры взаимодействия с пользователем на клиентской стороне при получении информации для проверки подлинности пользователя. Хотя это несколько выходит за рамки спецификации протокола, здесь приведено описание такого взаимодействия, поскольку некоторые аспекты протокола разработаны с учетом взаимодействия с пользователем и отказ от рассмотрения этой информации может привести к появлению несовместимых или неудобных в использовании реализаций.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC-2119].

2. Обоснование

Определенные к настоящему времени методы аутентификации SSH тесно связаны с лежащими в их основе механизмами проверки подлинности. Это осложняет добавление новых механизмов проверки подлинности, поскольку требуется обновление всех клиентов для поддержки каждого нового механизма. С использованием описанного здесь общего метода для поддержки новых механизмов аутентификации не потребуется менять клиентские программы, а при использовании отдельного уровня проверки подлинности (например, [PAM]) можно обойтись без изменения программного кода даже на серверах.

Это обеспечивает значимые преимущества по сравнению с другими методами типа парольной аутентификации — «password» (определена в [SSH-USERAUTH]), поскольку новые (предположительно, более строгие) методы проверки подлинности могут добавляться «по желанию», обеспечивая прозрачное повышение уровня защищенности системы.

Механизм «запрос-отклик» (Challenge-response) и одноразовые пароли (One Time Password) легко могут поддерживаться при использовании этого метода.

Однако этот метод проверки подлинности ограничивается использованием механизмов, не требующих на клиентах специального кода (драйверов устройств или программ «искажения» паролей.

3. Протокольный обмен данными

Клиент инициирует аутентификацию сообщением SSH_MSG_USERAUTH_REQUEST, на которое сервер отвечает запросом аутентификационной информации от клиента в сообщении SSH_MSG_USERAUTH_INFO_REQUEST. Клиент получает информацию от пользователя и передает серверу сообщение SSM_MSG_USERAUTH_INFO_RESPONSE. Серверу недопустимо передавать другой запрос SSH_MSG_USERAUTH_INFO_REQUEST, пока не получен ответ от клиента.

3.1. Начальный обмен

byte SSH_MSG_USERAUTH_REQUEST
string имя пользователя (ISO-10646 UTF-8, как определено в [RFC-3629])
string имя службы (US-ASCII)
string "keyboard-interactive" (US-ASCII)
string тег языка (как определено в [RFC-3066])
string субметоды (ISO-10646 UTF-8)

Проверка подлинности начинается с передачи клиентом сообщения, показанного на рисунке.

Использование тега языка осуждается и это поле следует оставлять пустым. В будущей версии спецификации поле будет удалено. Серверу следует выбирать язык на базе тегов, переданных в процессе обмена ключами [SSH-TRANS].

Если задан непустой тег языка, серверу следует использовать указанный язык для всех сообщений, передаваемых клиенту в рамках этого протокола. Тег языка не следует применять для выбора языка сообщений, выходящих за рамки протокола. Если сервер не поддерживает запрошенный язык, выбор используемого языка будет зависеть от реализации.

Поле субметодов включено для того, чтобы пользователь мог дать рекомендации о методах, которые он желает использовать. Это поле представляет собой список разделенных запятыми субметодов (аппаратных или программных) предпочитаемых пользователем. Если клиенту известны пользовательские предпочтения (предположительно, из конфигурационных параметров), он может использовать это поле для передачи имеющейся информации серверу. В остальных случаях поле должно оставаться пустым.

Реальные имена субметодов должны быть как-то согласованы между пользователем и сервером.

Интерпретация сервером поля субметодов зависит от реализации.

Одной из возможных стратегий обработки поля субметодов в серверной реализации является простое игнорирование этого поля, если у пользователя нет возможности применять множество разных субметодов. Если пользователь может проверять подлинность с помощью одного из нескольких различающихся субметодов, серверу следует трактовать это поле, как рекомендацию по выбору желательного для пользователя метода.

Отметим, что к моменту передачи сообщения серверу клиент еще не выдает запроса пользователю на ввод пароля и парольная информация не включается в начальное сообщение (в отличие от метода «password»).

Сервер должен ответить на запрос сообщением SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, или SSH_MSG_USERAUTH_INFO_REQUEST.

Серверу не следует передавать ответ SSH_MSG_USERAUTH_FAILURE, если причиной отказа является имя пользователя или службы — вместо этого следует передать сообщение(я) SSH_MSG_USERAUTH_INFO_REQUEST, которое(ые) выглядит, как сообщение, передаваемое в случаях, когда следует выполнить аутентификацию, и после этого передать сообщение об отказе (с подобающей задержкой, как описано ниже). Цель такого поведения заключается в предотвращении возможности подбора корректных имен пользователей путем сравнения результатов аутентификации для различных имен.

Сервер может ответить сообщением SSH_MSG_USERAUTH_SUCCESS, если для указанного пользователя проверять подлинность не требуется. Однако, в силу описанных выше причин, лучше будет передать в ответ сообщение SSH_MSG_USERAUTH_INFO_REQUEST и игнорировать (без проверки) отклик на него.

3.2. Запросы информации

byte SSH_MSG_USERAUTH_INFO_REQUEST
string имя (ISO-10646 UTF-8)
string инструкция (ISO-10646 UTF-8)
string тег языка (как определено в [RFC-3066])
int num-prompts
string prompt[1] (ISO-10646 UTF-8)
boolean echo[1]
...
string prompt[num-prompts] (ISO-10646 UTF-8)
boolean echo[num-prompts]

Запросы информации генерируются со стороны сервера с использованием сообщений SSH_MSG_USERAUTH_INFO_REQUEST message.

Сервер может передать для аутентификации клиента столько запросов информации, сколько сочтет нужным. Клиент должен быть готов к обработке множества таких запросов. Однако для сервера недопустимо иметь даже одно не обработанное сообщение SSH_MSG_USERAUTH_INFO_REQUEST. Т. е., сервер не может передавать другое сообщение, пока клиент не ответит на предыдущее.

Формат сообщения SSH_MSG_USERAUTH_INFO_REQUEST показан на рисунке.

Использование тега языка осуждается и это поле следует оставлять пустым. В будущей версии спецификации поле будет удалено. Серверу следует выбирать язык на базе тегов, переданных в процессе обмена ключами [SSH-TRANS].

Если задан непустой тег языка, серверу следует использовать указанный язык для всех сообщений, передаваемых клиенту в рамках этого протокола. Тег языка не следует применять для выбора языка сообщений, выходящих за рамки протокола. Если сервер не поддерживает запрошенный язык, выбор используемого языка будет зависеть от реализации.

Серверу следует принимать в внимание неспособность некоторых клиентов корректно отображать длинные поля имен или приглашений (см. следующий параграф) и по возможности ограничивать размер этих полей. Например, вместо инструкции «Enter Password»1 и поля приглашения «Password for user23@host.domain: «2 лучше будет задать инструкцию «Password authentication for user23@host.domain»3 и поле приглашения «Password: «. Предполагается, что этот метод аутентификации будет в основном использоваться с [PAM] и такого выбора просто не будет возникать.

Поля имени и инструкции могут быть пустыми строками и клиент должен быть готов к корректной обработке таких полей. В качестве полей приглашения (prompt) недопустимо указывать пустые строки.

Поле num-prompts может иметь значение 0, показывающее отсутствие в сообщении полей prompt/echo, но клиенту по-прежнему следует отображать поля имени и инструкции (как описано ниже).

3.3. Пользовательский интерфейс

При получении запроса клиенту следует выдать приглашение пользователю на ввод данных, как описано ниже.

Клиентам с интерфейсом CLI4 следует отобразить имя и инструкцию (при наличии), добавляя новые строки. После этого для для каждого из полей prompt[ ] клиенту следует вывести на экран приглашение и прочитать введенные пользователем данные.

Клиенты с графическим интерфейсом (GUI) имеют множество вариантов вывода приглашения для пользователя. Одним из таких вариантов является использование значения поля name (возможно, с именем приложения в качестве префикса) в качестве заголовка диалогового окна, в котором содержится приглашение на ввод информации. В этом диалоговом окне поле инструкции будет служить текстовым сообщением, а поля prompt[ ] — метками для полей ввода информации. Пльзователю следует показывать все поля. Например, реализациям не следует отбрасывать поле имени по причине отсутствия заголовка у окна — вместо этого следует найти другой вариант отображения информации. Если в диалоговом окне выводятся приглашения, клиенту не следует представлять каждое из таких приглашений в отдельном окне.

Все клиенты должны корректно обрабатывать поле инструкции с символами новой строки. Следует также обеспечивать отображение полей имен и приглашений размером не менее 30 символов. Если сервер представляет имена и приглашения размером более 30 символов, клиент может укоротить эти поля до поддерживаемого им размера. Если клиент укорачивает поля, он должен очевидным образом указать этот факт. Поля инструкции укорачивать не следует.

Клиентам следует использовать фильтрацию символов управления, как описано в [SSH-ARCH], для предотвращения атак с использованием символов управления в отображаемых полях.

Для каждого приглашения (prompt) соответствующее поле echo указывает, нужно ли отображать введенную пользователем информацию. Клиентам следует корректно отображать/маскировать пользовательский ввод для каждого приглашения независимо. Если клиент по тем или иным причинам не способен выполнить требования поля echo, он должен маскировать вводимые пользователем символы. GUI-клиенты могут добавлять поле переключения (checkbox) для управления отображением/маскированием. Клиентам не следует добавлять какие-либо символы (типа двоеточия) в приглашение, поскольку сервер полностью отвечает за текст, отображаемый пользователю. Клиенты должны также воспринимать от пользователя пустые отклики и передавать их в виде пустых строк.

3.4. Информационные отклики

byte SSH_MSG_USERAUTH_INFO_RESPONSE
int num-responses
string response[1] (ISO-10646 UTF-8)
...
string response[num-responses] (ISO-10646 UTF-8)

После получения от пользователя запрошенной информации клиент должен ответить сообщением SSH_MSG_USERAUTH_INFO_RESPONSE.

Формат SSH_MSG_USERAUTH_INFO_RESPONSE показан на врезке справа.

Отметим, что отклики представляются в кодировке ISO-10646 UTF-8. Интерпретация и проверка откликов определяется сервером. Однако, если клиент считывает отклики пользователя в иной кодировке (например, ISO 8859-1), он должен преобразовать их в кодировку ISO-10646 UTF-8 до передачи серверу.

С точки зрения поддержки разных языков желательно, чтобы при обработке пользовательских откликов процесс аутентификации работал независимо от используемой операционной системы и клиентских программ. Это достигается за счет нормализации. Системам, поддерживающим пароли в кодировках, отличных от ASCII, следует всегда нормализовать пароли и имена пользователей при добавлении в базу данных и сравнении их (с хэшированием или без него) с имеющимися в базе записями. Реализациям SSH, хранящим и сравнивающим пароли, следует использовать нормализацию [SASLPREP].

Если число откликов (num-responses) не соответствует числу запросов (num-prompts), сервер должен передать сообщение об отказе.

Если в запросе сервера было 0 полей num-prompts, клиент должен передать отклик с нулевым значением num-responses.

Отклики должны упорядочиваться в соответствии с порядком приглашений. Т. е., отклик response[n] должен быть ответом на приглашение prompt[n].

После получения отклика сервер должен передать сообщение об успехе (SSH_MSG_USERAUTH_SUCCESS) или отказе (SSH_MSG_USERAUTH_FAILURE) или дополнительный запрос SSH_MSG_USERAUTH_INFO_REQUEST.

Если сервер отказался аутентифицировать пользователя (на основе применяемого механизма проверки подлинности), ему не следует передавать другие запросы с целью получения новой аутентификационной информации. Вместо этого серверу следует передать сообщение об отказе. Единственным случаем, когда серверу следует передавать множество сообщений с запросами является потребность в дополнительных аутентификационных данных (т. е., при использовании для проверки подлинности пользователя множества механизмов аутентификации). Если сервер считает нужным передать сообщение об отказе, он может задержать его отправку клиенту (время задержки определяется реализацией). Предполагается, что реализации будут позволять настраивать время задержки, предлагаемая по умолчанию задержка составляет 2 секунды.

4. Примеры проверки подлинности

Здесь приведены два примера обмена информацией между клиентом и сервером. В первом случае используется механизм challenge/response с ручным маркером (token). Такая аутентификация невозможна при использовании других методов проверки подлинности.

C: byte SSH_MSG_USERAUTH_REQUEST
C: string "user23"
C: string "ssh-userauth"
C: string "keyboard-interactive"
C: string ""
C: string ""

S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "CRYPTOCard Authentication"
S: string "The challenge is '14315716'"5
S: string "en-US"
S: int 1
S: string "Response: "6
S: boolean TRUE

[Клиент запрашивает у пользователя пароль]

C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 1
C: string "6d757575"

S: byte SSH_MSG_USERAUTH_SUCCESS

Во втором случае показана обычная парольная аутентификация с истекшим сроком действия пароля.

C: byte SSH_MSG_USERAUTH_REQUEST
C: string "user23"
C: string "ssh-userauth"
C: string "keyboard-interactive"
C: string "en-US"
C: string ""

S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Authentication"7
S: string ""
S: string "en-US"
S: int 1
S: string "Password: "8
S: boolean FALSE

[Клиент запрашивает у пользователя пароль]

C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 1
C: string "password"

S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password Expired"9
S: string "Your password has expired."10
S: string "en-US"
S: int 2

S: string "Enter new password: "11
S: boolean FALSE
S: string "Enter it again: "12
S: boolean FALSE

[Клиент запрашивает у пользователя новый пароль]

C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 2
C: string "newpass"
C: string "newpass"

S: byte SSH_MSG_USERAUTH_INFO_REQUEST
S: string "Password changed"13
S: string "Password successfully changed for user23."14
S: string "en-US"
S: int 0

[Клиент выводит сообщение для пользователя]

C: byte SSH_MSG_USERAUTH_INFO_RESPONSE
C: int 0

S: byte SSH_MSG_USERAUTH_SUCCESS

5. Согласование с IANA

Для этого метода проверки подлинности используется тип userauth «keyboard-interactive».

В этом методе аутентификации используются две специфичных для метода константы:

SSH_MSG_USERAUTH_INFO_REQUEST  60
SSH_MSG_USERAUTH_INFO_RESPONSE 61

6. Вопросы безопасности

Протокол и метод аутентификации зависят от защищенности нижележащего транспортного уровня SSH. Без обеспечиваемой этим уровнем конфиденциальности данные аутентификации, передаваемые с использованием этого метода могут быть перехвачены.

Число обменов данными между клиентом и сервером в процессе аутентификации может меняться. Вполне возможно, что наблюдатель сможет получить ценную информацию, просто посчитав число пакетов. Например, наблюдатель может догадаться, что у пользовательского пароля истек срок действия, а дальнейшие наблюдения могут позволить определить время действия паролей, раскрывая частично политику сайта.

7. Литература

7.1. Нормативные документы

[RFC-2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC-3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, November 2003.

[RFC-3066] Alvestrand, H., «Tags for the Identification of Languages», BCP 47, RFC 3066, January 2001.

[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Protocol Architecture», RFC 4251, January 2006.

[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Authentication Protocol», RFC 4252, January 2006.

[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Transport Layer Protocol», RFC 4253, January 2006.

[SASLPREP] Zeilenga, K., «SASLprep: Stringprep Profile for User Names and Passwords», RFC 4013, February 2005.

7.2. Дополнительная литература

[PAM] Samar, V., Schemers, R., «Unified Login With Pluggable Authentication Modules (PAM)», OSF RFC 86.04, October 1995.

Адреса авторов

Frank Cusack

savecore.net

EMail: frank@savecore.net

Martin Forssen

AppGate Network Security AB

Otterhallegatan 2

SE-411 18 Gothenburg

SWEDEN

EMail: maf@appgate.com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).


1Введите пароль.

2Пароль для пользователя user23@host.domain:

3Парольная аутентификация для пользователя user23@host.domain.

4Command line interface — командный (текстовый) интерфейс.

5Запрос «14315716».

6Отклик:

7Парольная аутентификация.

8Пароль:

9Срок действия пароля закончился.

10Срок действия Вашего пароля закончился.

11Введите новый пароль:

12Введите пароль еще раз:

13Пароль изменен.

14Пароль для пользователя user23 изменен.




RFC 4255 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints

Network Working Group                                    J. Schlyter
Request for Comments: 4255                                   OpenSSH
Category: Standards Track                                 W. Griffin
                                                              SPARTA
                                                        January 2006

Использование DNS для защищенной публикации отпечатков ключей SSH

Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints

PDF

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2006).

Тезисы

В этом документе описан метод верификации ключей хостов SSH (Secure Shell) с использованием DNSSEC1. Документ определяет новую запись DNS, которая содержит стандартный отпечаток ключа SSH.

Оглавление

Исключено из версии HTML

1. Введение

Протокол SSH [6] обеспечивает защищенный вход в удаленные системы (remote login) и другие защищенные услуги в сетях без защиты. Защита соединений базируется на идентификации сервера для клиентов, а также идентификации пользователя на сервере.

Если соединение организуется с сервером, открытый ключ которого еще не известен клиенту, пользователю предоставляется отпечаток ключа (fingerprint) для его верификации. Если пользователь примет решение о корректности отпечатка и восприятии ключа, этот ключ сохраняется локально и будет использоваться для верификации последующих соединений. Хотя некоторые, озабоченные безопасностью пользователи проверяют отпечаток независимыми путями (out-of-band) до восприятия ключа, многие пользователи слепо доверяют представленному ключу.

Описанный здесь метод может обеспечить независимый канал верификации за счет поиска отпечатка открытого ключа сервера в DNS [1][2] и использования DNSSEC [5] для верификации такого поиска.

Для распространения отпечатков с использованием DNS в этом документе определяется новая запись DNS «SSHFP», позволяющая передавать отпечатки.

Предполагается, что читатель имеет базовые знания в области DNS [1][2] и защитных расширений DNS [5].

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [3].

2. Верификация ключа хоста SSH

2.1. Метод

При соединении с сервером SSH клиент SSH может отыскать запись(и) SSHFP для хоста, к которому он подключается. Если алгоритм и отпечаток, полученные от сервера SSH, соответствуют алгоритму и отпечатку одной из записей SSHFP, полученных от DNS, клиент может воспринять идентификацию сервера.

2.2. Замечания по реализации

Реализациям клиентов следует обеспечивать настраиваемое правило, используемое для выбора порядка методов верификации ключей хостов. В этом документе определяется один из таких методов — хранение отпечатка ключа в DNS. Другой метод, определенный в архитектуре SSH [6], использует локальные файлы для хранения сравниваемых ключей. Иные методы, которые могут быть определены в будущем, могут включать хранение отпечатков в LDAP или других базах данных. Настраиваемые правила позволяют администратору определить, какие методы он желает использовать и задать порядок применения выбранных методов. Это позволит администраторам определить уровень доверия к различным методам.

Одним из сценариев с настраиваемой политикой относится к случаю, когда клиенты не используют полные имена хостов для обращения к серверам. В этом сценарии реализациям следует сравнивать ключ хоста с локальной базой данных до верификации ключа с использованием отпечатка, полученного от DNS. Это поможет предотвратить атаки, связанные со вставкой пути поиска в DNS в локальный преобразователь (resolver) для принудительного подключения клиента к другому хосту.

2.3. Соответствие отпечатков

Открытый ключ и запись SSHFP сравниваются путем сопоставления номера алгоритма и отпечатка ключа.

алгоритм открытого ключа и алгоритм в записи SSHFP должны совпадать;

цифровая подпись открытого ключа с использованием алгоритма, указанного в типе отпечатка SSHFP, должна совпадать с отпечатком в SSHFP.

2.4. Аутентификация

Открытому ключу, проверенному с использованием этого метода, недопустимо доверять, если запись SSHFP RR2 не была аутентифицирована с помощью доверенной записи SIG RR.

Клиентам, самостоятельно выполняющим валидацию подписей DNSSEC, следует использовать стандартные процедуры валидации DNSSEC.

Клиенты, которые не выполняют самостоятельно валидацию подписей DNSSEC, должны использовать защищенный транспорт (например, TSIG [9], SIG(0) [10] или IPsec [8]) до элемента, выполняющего валидацию подписей.

3. Запись SSHFP

Запись SSHFP RR используется для хранения отпечатка открытого ключа хоста SSH, связанного с именем DNS3.

Код типа RR для записи SSHFP RR имеет значение 44.

3.1. Формат SSHFP RDATA

Поле RDATA записи SSHFP RR включает номер алгоритма, тип отпечатка и сам отпечаток (fingerprint) открытого ключа хоста.

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   алгоритм    |    тип fp     |                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
/                                                               /
/                           Отпечаток                           /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.1.1. Спецификация номера алгоритма

Октет номера алгоритма указывает алгоритм открытого ключа. Выделенные значения номеров алгоритмов показаны в таблице.

Значение Имя алгоритма
0 резерв
1 RSA
2 DSS

Резервирование других значений требует согласования с IETF [4].

3.1.2. Спецификация типа отпечатка

Октет типа отпечатка указывает алгоритм цифровой подписи, используемый для получения отпечатка открытого ключа. Выделенные значения приведены в таблице.

Значение Тип отпечатка
0 резерв
1 SHA-1

Резервирование других значений требует согласования с IETF [4].

Из соображений интероперабельности следует минимизировать число используемых типов отпечатков. Единственной причиной выделения новых типов может служить повышение уровня безопасности.

3.1.3. Отпечаток

Отпечаток рассчитывается для открытого ключа (blob), как описано в [7].

Предполагается, что алгоритм создания цифровой подписи дает на выходе строку октетов, которая без дополнительной обработки помещается в поле RDATA fingerprint.

3.2. Формат представления SSHFP RR

Поле RDATA в формате представления SSHFP состоит из двух целых чисел (номер алгоритма и тип отпечатка), за которыми следует сам отпечаток, представленный в шестнадцатеричном формате:

host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890

Использование вместо номеров мнемонических имен не допускается.

4. Вопросы безопасности

В настоящее время уровень доверия пользователей к серверным ключам пропорционален усилиям по проверке соответствия представленного открытого ключа секретному ключу сервера. Если пользователь воспринимает ключ без верификации отпечатка с помощью средств, использующих защищенный канал, соединение становится уязвимым для MITM-атак4.

Общий уровень безопасности при использовании SSHFP для ключа хоста SSH зависит от правил безопасности, заданных администратором хоста SSH и администратором зоны DNS (в части передачи отпечатков), деталей процесса верификации в реализации SSH и уровня защиты доступа клиента к DNS.

Одним из аспектов безопасности является порядок просмотра отпечатков (например, сначала просматривается локальный файл, а потом SSHFP). Отметим, что в дополнение к защите изначального переноса ключей хоста SSHFP опционально может применяться для более сильной защиты ключа хоста.

Если сначала проверяется SSHFP, новые ключи хостов SSH могут быть распространены путем замены соответствующих записей SSHFP в DNS.

Если верификация ключей хостов SSH может быть настроена так, чтобы требовалось использование SSHFP, отзыв ключа хоста SSH может быть реализован путем удаления соответствующей записи SSHFP из DNS.

Как было отмечено в параграфе 2.2, разработчикам SSH рекомендуется обеспечивать механизм правил для управления порядком использования методов верификации ключей хостов. Одним из сценариев, требующих таких правил, является случай использования неполных имен хостов для подключения к серверам. В этом случае разработчикам SSH рекомендуется сначала сравнивать ключ хоста с локальной базой данных и только после этого проверять по отпечатку, полученному от DNS. Это поможет предотвратить атаки со вставкой пути поиска в DNS в локальный преобразователь для того, чтобы вынудить клиента подключаться к другому хосту.

Другим вариантом решения вопроса с подменой пути поиска в DNS является использование клиентами доверенного пути поиска в DNS, который получен не от DHCP или иных механизмов автоматической настройки. Поскольку в современных API для поиска в DNS нет способа проверки доверенности пути поиска, всю клиентскую систему потребуется настроить на использование доверенного пути поиска в DNS.

Другая зависимость связана с реализациями DNSSEC. Как отмечено в параграфе 2.4, требуется использовать защищенные методы поиска, а записи SSHFP RR должны подтверждаться доверенными записями SIG RR. Это особенно важно в тех случаях, когда SSHFP используется в качестве основы для возобновления и/или отзыва ключей хостов, как описано выше.

Поскольку DNSSEC лишь защищает целостность отпечатка после того, как он был подписан администратором зоны DNS, требуется обеспечить защищенную передачу отпечатков от администратора хоста SSH к администратору зоны DNS. Это можно сделать вручную или автоматически с использованием защищенного динамического обновления DNS [11] между сервером SSH и сервером имен. Отметим, что это не отличается от других ситуаций с обновлением ключей (например, клиенты отправляют запросы сертификатов уполномоченным агентствам для подписания).

5. Согласование с IANA

Агентство IANA выделило код типа RR со значением 44 для записей SSHFP из стандартного пространства типов RR.

Агентство IANA создало новый реестр для алгоритмов открытых ключей в записях типа SSHFP RR, включающий три элемента:

0 — резерв

1 — RSA

2 — DSA

Добавление новых значений требует согласования с IETF [4].

Агентство IANA создало новый реестр типа отпечатков для записей SSHFP RR, включающий два элемента:

0 — резерв

1 — SHA-1

Добавление новых значений требует согласования с IETF [4].

6. Нормативные документы

[1] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[2] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

[3] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[4] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, March 2005.

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for the DNS Security Extensions», RFC 4034, March 2005.

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, March 2005.

[6] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Protocol Architecture», RFC 4251, January 2006.

[7] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Transport Layer Protocol», RFC 4253, January 2006.

7. Дополнительная литература

[8] Thayer, R., Doraswamy, N., and R. Glenn, «IP Security Document Roadmap», RFC 2411, November 1998.

[9] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, «Secret Key Transaction Authentication for DNS (TSIG)», RFC 2845, May 2000.

[10] Eastlake 3rd, D., «DNS Request and Transaction Signatures ( SIG(0)s )», RFC 2931, September 2000.

[11] Wellington, B., «Secure Domain Name System (DNS) Dynamic Update», RFC 3007, November 2000.

8. Благодарности

Авторы выражают свою благодарность:

Martin Fredriksson

Olafur Gudmundsson

Edward Lewis

Bill Sommerfeld

Адреса авторов

Jakob Schlyter

OpenSSH

812 23rd Avenue SE

Calgary, Alberta T2G 1N8

Canada

EMail: jakob@openssh.com

URI: http://www.openssh.com/

Wesley Griffin

SPARTA

7075 Samuel Morse Drive

Columbia, MD 21046

USA

EMail: wgriffin@sparta.com

URI: http://www.sparta.com/


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).


1Domain Name System Security — защита системы доменных имен.

2Resource record — запись о ресурсе.

3Domain Name System — система доменных имен.

4Man-in-the-middle attack — атака с перехватом трафика на пути и участием человека в точке перехвата.




RFC 4254 The Secure Shell (SSH) Connection Protocol

Network Working Group                                      T. Ylonen
Request for Comments: 4254          SSH Communications Security Corp
Category: Standards Track                            C. Lonvick, Ed.
                                                 Cisco Systems, Inc.
                                                        January 2006

Протокол соединений SSH

The Secure Shell (SSH) Connection Protocol

PDF

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2006).

Тезисы

Протокол SSH1 используется для организации безопасного входа в удаленную систему (login) и организации иных безопасных служб через сети, не обеспечивающие защиты.

Этот документ описывает протокол соединений SSH, обеспечивающий интерактивные сеансы работы в системе, удаленное выполнение команд, перенаправление соединений TCP/IP и X11. Все эти каналы мультиплексируются в один зашифрованный туннель.

Протокол соединений SSH разработан для использования на базе транспортного уровня SSH и протоколов аутентификации пользователей.

Оглавление

Исключено из версии HTML

1. Введение

Протокол соединений SSH разработан для использования поверх протоколов транспортного уровня и аутентификации пользователей SSH ([SSH-TRANS] и [SSH-USERAUTH]). Он обеспечивает интерактивные сеансы работы в системе, удаленное выполнение команд, а также перенаправление соединений TCP/IP и X11.

Имя службы (service name) для данного протокола — ssh-connection.

Этот документ следует читать только после прочтения документа по архитектуре SSH [SSH-ARCH]. В документе используется терминология и нотация из описания архитектуры без ссылок и дополнительных разъяснений.

2. Разработчики

Основными разработчиками этого комплекта документов являются: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (все из SSH Communications Security Corp.) и Markku-Juhani O. Saarinen (университет Jyvaskyla). Darren Moffat был редактором этого комплекта документов и внес важный вклад в работу.

За годы подготовки этого документа множество людей внесло свой вклад. В их число входят: Mats Andersson, Ben Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller, Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse и Tadayoshi Kohno. Указанные в списке люди могли не участвовать в написании данного документа, но они внесли свой вклад в его подготовку.

3. Используемые в документе соглашения

Во всех документах, связанных с протоколом SSH, следует использовать ключевые слова: необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) для описания уровня требования. Интерпретация этих слов описана в [RFC2119].

Ключевые слова приватное использование (PRIVATE USE), иерархическое выделение (HIERARCHICAL ALLOCATION), выделение в соответствии с порядком запросов (FIRST COME FIRST SERVED), экспертное рассмотрение (EXPERT REVIEW), требуется спецификация (SPECIFICATION REQUIRED), одобрение IESG (IESG APPROVAL), согласование с IETF (IETF CONSENSUS), стандартизация (STANDARDS ACTION) в данном документе при их использовании в контексте распределения пространства имен интерпретируются в соответствии с [RFC2434].

В данном наборе документов определяются поля протокола и возможные значения этих полей. Поля будут определяться вместе с протокольными сообщениями. Например, поле SSH_MSG_CHANNEL_DATA определяется следующим образом:

byte SSH_MSG_CHANNEL_DATA
uint32 канал получателя
string данные

В данном документе поля протокола будут указываться в одинарных кавычках, а значения полей – в двойных. В приведенном выше примере поле ‘data’ может содержать значения «foo» и «bar».

4. Глобальные запросы

Существует несколько типов запросов, оказывающих глобальное влияние на состояние удаленной стороны, независимо от каких-либо каналов. Примером такого запроса может служить запрос на перенаправление TCP/IP для заданного порта. Отметим, что клиент и сервер могут одновременно передавать глобальные запросы и получатель запроса должен реагировать подобающим образом. Формат глобальных запросов показан на рисунке.

byte SSH_MSG_GLOBAL_REQUEST
string request name in US-ASCII only
boolean want reply
.... request-specific data follows

Значение request name следует соглашению по расширяемому именованию DNS, приведенному в [SSH-ARCH].

Получатель будет отвечать на этот запрос сообщением SSH_MSG_REQUEST_SUCCESS или SSH_MSG_REQUEST_FAILURE, если want reply имеет значение TRUE.

byte SSH_MSG_REQUEST_SUCCESS
.... данные, специфичные для отклика

Данные, специфичные для отклика, обычно отсутствуют.

Если получатель не может распознать запрос или не поддерживает его, он просто передает сообщение SSH_MSG_REQUEST_FAILURE.

byte SSH_MSG_REQUEST_FAILURE

В общем случае отклики не включают идентификаторов запроса. Инициатор запроса для обеспечения возможности связать полученные отклики с соответствующими запросами вводится требование о том, что отклики на запросы SSH_MSG_GLOBAL_REQUEST должны передаваться в том же порядке, в котором были получены сообщения с запросами. Для канальных запросов отклики, связанные с одним каналом, также должны передаваться с сохранением порядка. Однако отклики на канальные запросы для различных каналов могут передаваться с нарушением порядка.

5. Канальный механизм

Все терминальные сессии, перенаправления и т. п. являются каналами. Канал может открыть любая сторона. Множество каналов мультиплексируется в одно соединение.

Каналы идентифицируются номерами на каждой стороне, которые не обязательно совпадают для обеих сторон одного канала. Запросы на создание канала включают номер канала, заданный инициатором. Все остальные канальные запросы включают номер канала на стороне получателя.

Каналы управляются по потоку данных. Никакие данные не могут передаваться в канал, пока не будет получено сообщение о доступности пространства в окне.

5.1. Создание канала

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

byte SSH_MSG_CHANNEL_OPEN
string тип канала в кодировке US-ASCII
uint32 канал отправителя
uint32 начальный размер окна
uint32 максимальный размер пакета
.... данные, зависящие от типа канала

Тип канала (channel type) представляет собой имя (как описано в [SSH-ARCH] и [SSH-NUMBERS]) с возможным использованием расширений. Поле ‘канал отправителя’ содержит локальный идентификатор, заданный отправителем данного сообщения. Поле ‘начальный размер окна’ задает число байтов данных канала, которые могут быть переданы отправителем без подстройки размера окна. Поле ‘максимальный размер пакета’ указывает размер наибольшего пакета данных, который может быть передан отправителем. Например, для интерактивных соединений могут использоваться мелкие пакеты для ускорения откликов при использовании медленных соединений.

Удаленная сторона принимает решение о создании канала и возвращает сообщение о согласии (SSH_MSG_CHANNEL_OPEN_CONFIRMATION) или отказе (SSH_MSG_CHANNEL_OPEN_FAILURE).

byte SSH_MSG_CHANNEL_OPEN_CONFIRMATION
uint32 канал получателя
uint32 канал отправителя
uint32 начальный размер окна
uint32 максимальный размер пакета
.... данные, зависящие от типа канала

Поле ‘канал получателя’ содержит номер канала, выделенный инициатором запроса, а поле ‘канал отправителя’ — номер канала, выделенный другой стороной.

byte SSH_MSG_CHANNEL_OPEN_FAILURE
uint32 канал получателя
uint32 код причины
string описание в кодировке ISO-10646 UTF-8 [RFC3629]
string тег языка [RFC3066]

Если получатель сообщения SSH_MSG_CHANNEL_OPEN не поддерживает заданный тип канала, он просто возвращает отклик SSH_MSG_CHANNEL_OPEN_FAILURE. Клиент может включить строку описания причины отказа для пользователя. В этом случае клиентские программы должны принимать меры предосторожности, описанные в [SSH-ARCH].

Имя Код причины
SSH_OPEN_ADMINISTRATIVELY_PROHIBITED 1
SSH_OPEN_CONNECT_FAILED 2
SSH_OPEN_UNKNOWN_CHANNEL_TYPE 3
SSH_OPEN_RESOURCE_SHORTAGE 4

Значения поля ‘код причины’ в сообщениях SSH_MSG_CHANNEL_OPEN_FAILURE показаны в таблице справа. Отметим, что коды для удобства приведены в десятичном формате, но на практике используются значения типа uint32.

Запросы на выделение новых значений кодов причин SSH_MSG_CHANNEL_OPEN (‘reason code’) из диапазона 0x00000005 — 0xFDFFFFFF и тектов связанных с ними описаний (‘description’) должны удовлетворяться по согласованию с IETF, как описано в [RFC2434]. Агентство IANA не будет выделять значений кодов причин отказа для канальных соединений (Channel Connection Failure ‘reason code’) из диапазона of 0xFE000000 — 0xFFFFFFFF. Эти значения выделены для приватного использования, как описано в [RFC2434].

Несмотря на то, что IANA не контролирует значения кодов из диапазона 0xFE000000 — 0xFFFFFFFF, этот диапазон разделен на две части, администрируемые, как описано ниже.

  • Диапазон 0xFE000000 — 0xFEFFFFFF используется совместно с локально выделенными каналами. Например, если предлагается канал типа ‘channel type’ = «example_session@example.com» и организация его завершается отказом, отклик будет содержать код причины, выделенный IANA (как сказано выше, из диапазона 0x00000001 — to xFDFFFFFF), или выделенное локально значение из диапазона 0xFE000000 — 0xFEFFFFFF. Естественно, что если сервер не понимает ‘channel type’, даже определенного локально типа, в качестве кода причины (если он передается) должно использоваться значение 0x00000003, как описано выше. Если сервер понимает тип канала, но создать канал не удается, серверу следует отвечать с выделенным локально кодом причины, соответствующим предложенному локальному типу ‘channel type’. Предполагается, что на практике сначала будет предприниматься попытка использовать выделенные IANA значения ‘reason code’, а при отсутствии нужных выделять свои значения кодов причины.
  • Для значений, начинающихся с 0xFF нет ограничений или предложений по использованию. При использовании таких значений интероперабельность не предполагается. Естественно, что этот поддиапазон предназначен для экспериментов.

5.2. Передача данных

Размер окна задает число байтов, которые другая сторона может передать до того, как она должна будет дождаться подстройки размера окна. Обе стороны используют для подстройки размера окна сообщение, показанное на рисунке.

byte SSH_MSG_CHANNEL_WINDOW_ADJUST
uint32 канал получателя
uint32 число добавляемых байтов

После приема такого сообщения получатель может передать на указанное число байтов больше, чем было дозволено раньше. Реализации должны корректно работать с окнами размером до 232-1 байтов. Увеличивать размер окна сверх этого значения недопустимо.

byte SSH_MSG_CHANNEL_DATA
uint32 канал получателя
string данные

Передача данных осуществляется с помощью сообщений, показанных на рисунке.

Максимальное число данных в сообщении определяется меньшим из значений максимального размера пакетов для канала и текущего размера окна. После передачи сообщения текущий размер окна уменьшается на объем переданной информации. Обе стороны могут игнорировать любые данные, которые были переданы после опустошения дозволенного окна.

Предполагается, что реализации будут вносить те или иные ограничесния на размер пакетов транспортного уровня SSH (предельный размер принимаемых пакетов должен быть не менее 32768 байтов, как описано в [SSH-TRANS]). Для реализаций уровня соединений SSH

  • недопустимо анонсировать максимальный размер пакетов, который будет приводить к увеличению размера пакетов транспортного уровня сверх значения, которое этот уровень будет принимать;

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

byte SSH_MSG_CHANNEL_EXTENDED_DATA
uint32 канал получателя
uint32 data_type_code (код типа данных)
string данные

Кроме того, некоторые каналы могут передавать разные типы данных (примером могут служить данные стандартного вывода ошибок (stderr) в интерактивных сессиях). Такие данные можно передавать в сообщениях SSH_MSG_CHANNEL_EXTENDED_DATA, где тип данных указывается отдельным целочисленным идентификатором (см. врезку справа). Доступные типы и их интерпретация зависят от типа канала.

Данные, передаваемые в таких сообщениях потребляют пространство окна, как и обычные данные.

Имя data_type_code
SSH_EXTENDED_DATA_STDERR 1

В настоящее время определен только один тип данных (см. таблицу справа). Отметим, что значение ‘data_type_code’ приведено в десятичном формате, хотя на практике используется тип uint32.

Значения типа для расширенных каналов данных (Extended Channel Data Transfer ‘data_type_code’) должны выделяться последовательно. Запросы на выделение новых значений ‘data_type_code’ из диапазона 0x00000002 — 0xFDFFFFFF и связанных с ними строк ‘data’ должны удовлетворяться по процедуре IETF CONSENSUS, как описано в [RFC2434]. Агентство IANA не будет выделять значений ‘data_type_code’ из диапазона 0xFE000000 — 0xFFFFFFFF. Эти значения ‘data_type_code’ выделены для приватного использования, как описано в [RFC2434]. Как было отмечено выше, актуальные инструкции для IANA содержатся в [SSH-NUMBERS].

5.3. Закрытие канала

byte SSH_MSG_CHANNEL_EOF
uint32 канал получателя

Когда одна из сторон уже не будет передавать данные в канал, ей следует отправить на другою сторону сообщение SSH_MSG_CHANNEL_EOF.

На такие сообщения явных откликов не передается. Однако приложение может передать сигнал EOF2 на другую сторону канала. Отметим, что канал остается открытым после передачи этого сообщения и данные в обратном направлении могут по-прежнему передаваться. Сообщение не расходует пространства окна и может передаваться даже при пустом окне.

byte SSH_MSG_CHANNEL_CLOSE
uint32 канал получателя

Когда любая из сторон желает разорвать канал, она передает сообщение SSH_MSG_CHANNEL_CLOSE. Приняв такое сообщение, получатель должен отправить в ответ сообщение SSH_MSG_CHANNEL_CLOSE, если оно уже не было передано. Канал считается закрытым для данной стороны, когда она передала и приняла сообщение SSH_MSG_CHANNEL_CLOSE; после этого освободившийся номер канала можно использовать снова. Любая из сторон может передать сообщение SSH_MSG_CHANNEL_CLOSE без предварительной отправки или приема сообщения SSH_MSG_CHANNEL_EOF.

Сообщение не расходует пространства окна и может передаваться даже при пустом окне.

Рекомендуется все данные, отправленные до этого сообщения доставить конечному получателю, если это возможно.

5.4. Специфичные для канала запросы

byte SSH_MSG_CHANNEL_REQUEST
uint32 канал получателя
string тип запроса в кодировке US-ASCII
boolean нужен ответ
.... зависящие от типа данные

Многие типы каналов имеют расширения, характерные для данного значения ‘channel type’. Примером может служить запрос pty (псевдотерминал) для интерактивной сессии.

Все специфические для каналов запросы имеют одинаковый формат (см. рисунок).

Если поле ‘want reply’ (нужен ответ) имеет значение FALSE, отклик в ответ на запрос не будет передаваться. В противном случае получатель запроса будет передавать SSH_MSG_CHANNEL_SUCCESS, SSH_MSG_CHANNEL_FAILURE или специфичное для канала сообщение. Если запрос не распознан или не поддерживается, возвращается сообщение SSH_MSG_CHANNEL_FAILURE.

Сообщение не расходует пространства окна и может передаваться даже при пустом окне. Значения типа запроса (‘request type’) являются локальными для каждого типа каналов.

Клиент может передавать последующие сообщения, не ожидая отклика на такой запрос.

Имена ‘request type’ следуют соглашению о расширенном именовании DNS, описанному в [SSH-ARCH] и [SSH-NUMBERS].

byte SSH_MSG_CHANNEL_SUCCESS
uint32 канал получателя

byte SSH_MSG_CHANNEL_FAILURE
uint32 канал получателя

Эти сообщения не расходуют пространства окна и могут передаваться даже при пустом окне.

6. Интерактивные сеансы

Сессия представляет собой удаленное выполнение программы. Программой может быть командный процессор (shell), приложение, системная команда или некая встроенная подсистема. Программа может иметь терминал tty и может использовать перенаправление X11. Одновременно могут быть активны множество сессий.

6.1. Открытие сессии

Сессия начинается с передачи сообщения (см. рисунок).

byte SSH_MSG_CHANNEL_OPEN
string "session"
uint32 канал отправителя
uint32 начальный размер окна
uint32 максимальный размер пакета

Реализациям клиентов следует отвергать любые запросы на открытие сеансовых каналов для осложнения организации атак на них со стороны поврежденных серверов.

6.2. Запрос псевдотерминала

byte SSH_MSG_CHANNEL_REQUEST
uint32 recipient channel
string "pty-req"
boolean want_reply
string значение переменной среды TERM (например, vt100)
uint32 ширина терминала в символах (например, 80)
uint32 высота терминала в строках (например, 24)
uint32 ширина терминала в пикселях (например, 640)
uint32 высота терминала в пикселях (например, 480)
string кодированные режимы терминала (encoded terminal modes)

Для запроса псевдотерминала в сессии используется сообщение, показанное на рисунке.

Кодированные режимы терминала (‘encoded terminal modes’) описаны в разделе 8. Параметры нулевого размера должны игнорироваться. Размеры терминала в символах и строках имеют более высокий приоритет, нежели размеры в пикселях. Размеры в пикселях указывают доступную для вывода область терминального окна.

Параметры размеров передаются только для информации.

Клиентам следует игнорировать запросы pty.

6.3. Перенаправление X11

6.3.1. Запрос перенаправления X11

byte SSH_MSG_CHANNEL_REQUEST
uint32 канал получателя
string "x11-req"
boolean нужен ответ
boolean одно соединение
string протокол аутентификации x11
string cookie для аутентификации x11
uint32 номер экрана x11

Перенаправление X11 для сессии можно запросить, передав сообщение SSH_MSG_CHANNEL_REQUEST.

В качестве пол ‘x11 authentication cookie’ рекомендуется передавать случайное поддельное значение cookie, которое будет проверяться и заменяться реальным значением при получении запроса на соединение.

Перенаправление X11 следует останавливать при закрытии сеансового канала. Однако уже организованные перенаправления не будут автоматически закрываться при разрыве сеансового канала.

Если поле ‘single connection’ (одно соединение) имеет значение TRUE, перенаправлять следует только одно соединение. После его направления или после разрыва сеансового канала другие соединения перенаправляться не будут.

Поле ‘x11 authentication protocol’ (протокол аутентификации) задает имя используемого X11 метода аутентификации (например, «MIT-MAGIC-COOKIE-1»).

Значение поля ‘x11 authentication cookie’ должно указываться в шестнадцатеричном формате.

X Protocol документирован в [SCHEIFLER].

6.3.2. Каналы X11

byte SSH_MSG_CHANNEL_OPEN
string "x11"
uint32 канал отправителя
uint32 начальный размер окна
uint32 максимальный размер пакета
string адрес инициатора (например, "192.168.7.38")
uint32 порт инициатора

Каналы X11 создаются с помощью запросов на организацию канала (см. рисунок). Созданные каналы не зависят от сессии и закрытие сеансового канала не закрывает каналы перенаправления X11.

Получателю запроса следует передать в ответ SSH_MSG_CHANNEL_OPEN_CONFIRMATION или SSH_MSG_CHANNEL_OPEN_FAILURE.

Реализации должны отвергать любые запросы на организацию канала X11, если в них не запрашивается перенаправление X11.

6.4. Передача переменных окружения

byte SSH_MSG_CHANNEL_REQUEST
uint32 канал получателя
string "env"
boolean нужен ответ
string имя переменной
string значение переменной

Переменные окружения могут передаваться команде/командному процессору, который будет запущен позже. Неконтролируемая установка переменных окружения в привилегированных процессах может приводить к рискам безопасности. Реализациям рекомендуется поддерживать список разрешенных имен переменных или устанавливать переменные окружения лишь после того, как серверный процесс откажется от значимых привилегий.

6.5. Запуск командного процессора или команды

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

byte SSH_MSG_CHANNEL_REQUEST
uint32 канал получателя
string "shell"
boolean нужен ответ

Это сообщение запрашивает установленную по умолчанию (обычно задается в файле /etc/passwd для UNIX-систем) для пользователя командную оболочку (shell).

byte SSH_MSG_CHANNEL_REQUEST
uint32 канал получателя
string "exec"
boolean нужен ответ
string команда

Данное сообщение будет запрашивать у сервера запуск на выполнение заданной команды. Поле команды (‘command’) может содержать полный путь. Должны приниматься обычные меры предосторожности против несанкционированного выполнения команд.

byte SSH_MSG_CHANNEL_REQUEST
uint32 канал получателя
string "subsystem"
boolean нужен ответ
string имя подсистемы

Последний вариант является запросов на запуск предопределенной подсистемы. Предполагается, что это будет включать обычный перенос файлов и, возможно, другие функции. Разработчики могут также разрешить включение дополнительных механизмов. Поскольку для запуска подсистемы обычно используется пользовательский командный процессор (shell) протоколу подсистемы рекомендуется использовать «magic cookie» в начале протокольной транзакции, чтобы отличить его от произвольного вывода, создаваемого сценариями инициализации оболочки и т. п. Побочный вывод командного процессора может быть отфильтрован сервером или клиентом.

Серверу не следует прерывать работу стека протоколов при запуске командного процессора или программы. Весь ввод и вывод следует перенаправлять в канал или шифрованный туннель.

Рекомендуется запрашивать и проверять отклики на описанные выше запросы. Клиентам следует игнорировать такие запросы.

Имена подсистем должны следовать соглашению о расширенном именовании DNS приведенному в [SSH-NUMBERS].

6.6. Передача данных в сессии

Передача данный в сессии осуществляется с помощью пакетов SSH_MSG_CHANNEL_DATA и SSH_MSG_CHANNEL_EXTENDED_DATA с использованием механизма окна. Для стандартного вывода ошибок (stderr) определен расширенный тип данных SSH_EXTENDED_DATA_STDERR.

6.7. Сообщение об изменении размеров терминального окна

byte SSH_MSG_CHANNEL_REQUEST
uint32 канал получателя
string "window-change"
boolean FALSE
uint32 ширина терминала в символах
uint32 высота терминала в строках
uint32 ширина терминала в пикселях
uint32 высота терминала в пикселях

При изменении размеров терминального окна на клиентской стороне клиент может передать другой стороне сообщение с информацией о новых размерах (см. рисунок).

Передавать отклики на такие сообщения не следует.

6.8. Локальное управление потоком данных

На многих системах можно определить, использует ли псевдотерминал управление потоком данных Control-S/Control-Q. При включенном управлении потоком зачастую желательно контролировать поток на клиентской стороне для ускорения откликов на запросы пользователя. Это достигается с помощью показанного здесь уведомления. Изначально за управление потоком данных отвечает сервер (напомним, что клиентом является сторона, инициировавшая сессию, а сервером — другая сторона).

byte SSH_MSG_CHANNEL_REQUEST
uint32 канал получателя
string "xon-xoff"
boolean FALSE
boolean клиенту разрешено

Показанное на врезке слева сообщение используется сервером для информирования клиента о возможности (или невозможности) управлять потоком данных (обработка Control-S/Control-Q). Если управление разрешено для клиента (‘client can do’ = TRUE), он может использовать Control-S и Control-Q для управления потоком данных. Клиент может игнорировать это сообщение.

Отклик на такое сообщение не передается.

6.9. Сигналы

byte SSH_MSG_CHANNEL_REQUEST
uint32 канал получателя
string "signal"
boolean FALSE
string имя сигнала (без префикса "SIG")

Сигналы могут передаваться процессу или службе на удаленной стороне с помощью показанного на рисунке сообщения. Некоторые системы могут не поддерживать часть сигналов — в таких случаях им следует игнорировать сообщение.

Значения поля «имя сигнала» (‘signal name’) представляются, как описано ниже для сообщений SSH_MSG_CHANNEL_REQUEST, использующих «exit-signal».

6.10. Возврат состояния при завершении

byte SSH_MSG_CHANNEL_REQUEST
uint32 канал получателя
string "exit-status"
boolean FALSE
uint32 exit_status

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

Клиент может игнорировать сообщение с кодом завершения программы.

byte SSH_MSG_CHANNEL_REQUEST
uint32 канал получателя
string "exit-signal"
boolean FALSE
string имя сигнала (без префикса "SIG")
boolean core dumped
string сообщение об ошибке в кодировке ISO-10646 UTF-8
string тег языка [RFC3066]

Работа удаленной программы может быть также прекращена «жестко» по сигналу. Для индикации таких случаев используется специальный вариант сообщения, показанный на врезке справа. Нулевое значение поля ‘exit_status’ обычно означает успешное завершение команды.

Поле «имя сигнала» (‘signal name’) может содержать одно из приведенных ниже значений (заимствовано из [POSIX]).

ABRT
ALRM
FPE
HUP
ILL
INT
KILL
PIPE
QUIT
SEGV
TERM
USR1
USR2

Дополнительные значения имени сигнала (‘signal name’) могут передаваться в формате «sig-name@xyz», где «sig-name» и «xyz» могут быть произвольными строками по усмотрению разработчика (за исключением символа @). Однако предлагается при использовании конфигурационного сценария (‘configure’) все обнаруженные нестандартные значения ‘signal name’ представлять в формате «SIG@xyz.config.guess», где «SIG» — значение ‘signal name’ без префикса «SIG», а «xyz» — тип хоста, как определено в «config.guess».

Поле сообщения об ошибке (‘error message’) содержит дополнительную текстовую информацию об ошибке. Текст может включать множество строк, разделенных символами CRLF (возврат каретки — перевод строки). Клиентская программ может отображать текст сообщения об ошибке пользователю. Если это осуществляется, клиентской программе следует принимать меры предосторожности, рассмотренные в [SSH-ARCH].

7. Перенаправление для портов TCP/IP

7.1. Запрос перенаправления для порта

byte SSH_MSG_GLOBAL_REQUEST
string "tcpip-forward"
boolean нужен ответ
string адрес для привязки (например, "0.0.0.0")
uint32 номер порт для привязки

Участнику не требуется явно запрашивать перенаправление со своей стороны на другое направление. Однако, если он желает, чтобы соединение с портом на другой стороне перенаправлялось на локальную сторону, это нужно запрашивать явно (см. сообщение на рисунке).

Поля адреса (‘address to bind’) и порта (‘port number to bind’) задают IP-адрес (или доменное имя) и номер порта, для которого будет восприниматься перенаправление. Некоторые строки, используемые в поле привязки адреса, имеют специальное значение.

  • «» означает, что соединения будут восприниматься для всех семейств протоколов, поддерживаемых реализацией SSH;
  • «0.0.0.0» означает, что прослушиваются все адреса IPv4;
  • «::» означает, что прослушиваются все адреса IPv6;
  • «localhost» означает, что прослушиваются все семейства протоколов, поддерживаемые реализацией SSH, но только на адресах loopback ([RFC3330] и [RFC3513]);
  • «127.0.0.1» и «::1» указывает прослушивание на loopback-интерфейсах для IPv4 и IPv6, соответственно.

Отметим, что клиент может фильтровать соединения на основе информации, переданной в запросе на организацию.

Реализациям следует разрешать перенаправление для привилегированных портов только привилегированным пользователям.

Клиентским реализациям следует отвергать запросы на перенаправление портов, поскольку такие запросы обычно передаются только клиентами.

byte SSH_MSG_REQUEST_SUCCESS
uint32 номер порта, который будет привязан на сервере

Если клиент предает значение 0 в качестве номера порта для привязки и поле запроса отклика (‘want reply’) имеет значение TRUE, сервер выделяет следующий доступный непривилегированный номер порта и отвечает сообщением, показанным на врезке справа. В остальных случаях специфичные для отклика данные отсутствуют.

byte SSH_MSG_GLOBAL_REQUEST
string "cancel-tcpip-forward"
boolean нужен ответ
string адрес для привязки (например, "127.0.0.1")
uint32 номер порт для привязки

Для отмены перенаправления порта может использоваться сообщение, показанное на врезке слева. Отметим, что запросы на организацию канала могут приниматься, пока не получен отклик на такое сообщение.

Клиентским реализациям следует отвергать эти, поскольку они обычно передаются только клиентами.

7.2. Каналы перенаправления TCP/IP

byte SSH_MSG_CHANNEL_OPEN
string "forwarded-tcpip"
uint32 канал отправителя
uint32 начальный размер окна
uint32 максимальный размер пакета
string адрес, который был соединен
uint32 порт, который был соединен
string IP-адрес инициатора
uint32 порт инициатора

Когда соединение приходит в порт, для которого было запрошено удаленное перенаправление, открывается канал для перенаправления порта на другую сторону (см. рисунок).

Реализации должны отвергать такие сообщения, если они ранее не запрашивали удаленное перенаправление для порта TCP/IP с указанным номером.

byte SSH_MSG_CHANNEL_OPEN
string "direct-tcpip"
uint32 канал отправителя
uint32 начальный размер окна
uint32 максимальный размер пакета
string хост для соединения
uint32 порт для соединения
string IP-адрес инициатора
uint32 порт инициатора

Когда соединение приходит в локально перенаправляемый порт TCP/IP, на другую сторону передается пакет, показанный на рисунке. Отметим, что такие сообщения могут также передаваться для портов, по отношению к которым перенаправление не запрашивалось явно. Принимающая сторона должна принять решение о возможности перенаправления.

Поля хоста (‘host to connect’) и порта (‘port to connect’) для соединения задают хост TCP/IP и номер порта, с которым получателю следует организовать канал. Хост может быть задан адресом IP или доменным именем.

Поле адреса инициатора (‘originator IP address’) содержит числовое представление IP-адреса машины, отправившей запрос на соединение, а поле ‘originator port’ указывает номер порт на этом хосте.

Перенаправляемые каналы TCP/IP независимы от каких-либо сессий и закрытие сеансового канала не оказывает влияния на закрытие перенаправляемых соединений.

Клиентским реализациям следует отвергать прямые запросы на открытие соединений TCP/IP из соображений безопасности.

8. Кодирование терминальных режимов

Все кодированные режимы терминала (‘encoded terminal modes’), передаваемые в запросах pty, представляются в форме потока байтов. Это сделано для того, чтобы кодирование можно было передавать через различные среды. Поток состоит из пар «код-аргумент» (opcode-argument), где opcode выражается одним байтом. Коды от 1 до 159 используют один аргумент типа uint32. Коды 160 — 255 в настоящее время не определены и вызывают прекращение обработки (их следует указывать только после всех прочих данных). Байтовый поток завершается кодом TTY_OP_END (0x00).

Клиенту следует помещать в поток все режимы, которые ему известны, а сервер может игнорировать любые неизвестные ему режимы. Это дает относительную независимость от аппаратной реализации по крайней мере для систем с интерфейсом tty в стиле POSIX. Протокол может поддерживать и другие системы, но от клиента может потребоваться указание приемлемых значений множества параметров, чтобы сервер pty получил набор значений для установки подходящего режима (сервер оставляет для всех не заданных битов режима принятые по умолчанию значения, а работоспособны не все комбинации битов).

Именование кодов в основном следует флагам терминальных режимов POSIX. В таблице приведены определенные к настоящему моменту коды. Отметим, что в таблице для удобства восприятия даны десятичные значения, а на практике используются байты.

Код Имя Описание
0 TTY_OP_END Показывает завершение кодов.
1 VINTR Символ прерывания (255, если не задан). Аналогичен других символам. Не все такие символы поддерживаются в каждой системе.
2 VQUIT Символ завершения (в системах POSIX передается сигнал SIGQUIT).
3 VERASE Удалить символ слева от курсора.
4 VKILL Удалить полностью текущую строку ввода.
5 VEOF Символ завершения файла (с терминала передается EOF).
6 VEOL Символ завершения строки в дополнение к символу возврата каретки и/или перевода строки.
7 VEOL2 Дополнительный символ завершения строки.
8 VSTART Продолжение вывода после паузы (обычно Control-Q).
9 VSTOP

Пауза при выводе (обычно Control-S).

10 VSUSP Приостановка текущей программы.
11 VDSUSP Другой символ приостановки.
12 VREPRINT Перепечатка текущей строки ввода.
13 VWERASE Удалить слово слева от курсора.
14 VLNEXT Ввести следующий набранный символ, даже если он относится к специальным.
15 VFLUSH Символ очистки вывода.
16 VSWTCH Переключение на другой уровень командной оболочки.
17 VSTATUS Печать строки состояния системы (загрузка, команда, pid и т. п.).
18 VDISCARD Переключение очистки терминального вывода.
30 IGNPAR Флаг игнорирования четности. Для параметра следует устанавливать значение 0, если флаг имеет значение FALSE и 1 при флаге TRUE.
31 PARMRK Маркировка ошибок четности и кадрирования.
32 INPCK Разрешить проверку ошибок четности.
33 ISTRIP Вырезать восьмой бит символов.
34 INLCR Отображать на входе NL в CR.
35 IGNCR Игнорировать CR на входе.
36 ICRNL Отображать на входе CR в NL.
37 IUCLC Переводить символы верхнего регистра в символы нижнего.
38 IXON Разрешить управление потоком на выходе.
39 IXANY Любой символ будет возобновлять работу после остановки.
40 IXOFF Разрешить управление потоком на входе.
41 IMAXBEL Сигнал звонка при заполнении входной очереди.
50 ISIG Разрешить сигналы INTR, QUIT, [D]SUSP.
51 ICANON Канонизировать строки ввода.
52 XCASE Разрешить ввод и вывод символов верхнего регистра путем добавления перед символом нижнего регистра знака \.
53 ECHO Разрешить эхо-вывод.
54 ECHOE Визуально уничтожать символы.
55 ECHOK Символ отбрасывания текущей строки.
56 ECHONL Вывести NL, если эхо-вывод отключен.
57 NOFLSH Не очищать после прерывания.
58 TOSTOP Остановить вывод из фоновых заданий.
59 IEXTEN Разрешить расширения.
60 ECHOCTL Отображение управляющих символов, как ^(Char).
61 ECHOKE Визуальное удаление уничтоженной строки.
62 PENDIN Повторный набор ожидающего ввода.
70 OPOST Разрешить обработку вывода.
71 OLCUC Преобразовать символы нижнего регистра в верхний.
72 ONLCR Отображать на входе NL в CR-NL.
73 OCRNL Преобразовать символ возврата каретки в новую строку (выход).
74 ONOCR Преобразовать символ новой строки в «возврат каретки — новая строка» (выход).
75 ONLRET Символ новой строки выполняет возврат каретки (выход).
90 CS7 7-битовый режим.
91 CS8 8-битовый режим.
92 PARENB Четность включена.
93 PARODD Нечетность.
128 TTY_OP_ISPEED Задает входную скорость в битах в секунду.
129 TTY_OP_OSPEED Задает выходную скорость в битах в секунду.

9. Номера сообщений

В таблице справа приведен список сообщений с номерами.

Сообщение Номер
SSH_MSG_GLOBAL_REQUEST 80
SSH_MSG_REQUEST_SUCCESS 81
SSH_MSG_REQUEST_FAILURE 82
SSH_MSG_CHANNEL_OPEN 90
SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91
SSH_MSG_CHANNEL_OPEN_FAILURE 92
SSH_MSG_CHANNEL_WINDOW_ADJUST 93
SSH_MSG_CHANNEL_DATA 94
SSH_MSG_CHANNEL_EXTENDED_DATA 95
SSH_MSG_CHANNEL_EOF 96
SSH_MSG_CHANNEL_CLOSE 97
SSH_MSG_CHANNEL_REQUEST 98
SSH_MSG_CHANNEL_SUCCESS 99
SSH_MSG_CHANNEL_FAILURE 100

10. Согласование с IANA

Этот документ является частью набора связанных документов. Вопросы согласования с агентством IANA для протокола SSH, связанные с [SSH-ARCH], [SSH-TRANS], [SSH-USERAUTH] и данным документом, детализированы в [SSH-NUMBERS].

11. Вопросы безопасности

Предполагается, что этот протокол будет работать на основе защищенного транспорта с аутентификацией. Предполагается также, что аутентификация пользователей и защита от атак на сетевом уровне обеспечивается нижележащими протоколами.

Полное рассмотрение вопросов безопасности приведено в документе [SSH-ARCH]. Специфичной для данного документа является рекомендация запрещать в реализациях все потенциально опасные функции (например, перенаправления агентов, X11 и TCP/IP) если ключ хоста изменился без уведомления или объяснения.

12. Литература

12.1. Нормативные документы

[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Protocol Architecture», RFC 4251, January 2006.

[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Transport Layer Protocol», RFC 4253, January 2006.

[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., «The Secure Shell (SSH) Authentication Protocol», RFC 4252, January 2006.

[SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., «The Secure Shell (SSH) Protocol Assigned Numbers», RFC 4250, January 2006.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[RFC3066] Alvestrand, H., «Tags for the Identification of Languages», BCP 47, RFC 3066, January 2001.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, November 2003.

12.2. Дополнительная литература

[RFC3330] IANA, «Special-Use IPv4 Addresses», RFC 33304, September 2002.

[RFC3513] Hinden, R. and S. Deering, «Internet Protocol Version 6 (IPv6) Addressing Architecture», RFC 35135, April 2003.

[SCHEIFLER] Scheifler, R., «X Window System : The Complete Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.», Digital Press ISBN 1555580882, February 1992.

[POSIX] ISO/IEC, 9945-1., «Information technology – Portable Operating System Interface (POSIX)-Part 1: System Application Program Interface (API) C Language», ANSI/IEE Std 1003.1, July 1996.

Адреса авторов

Tatu Ylonen

SSH Communications Security Corp

Valimotie 17

00380 Helsinki

Finland

EMail: ylo@ssh.com

Chris Lonvick (редактор)

Cisco Systems, Inc.

12515 Research Blvd.

Austin 78759

USA

EMail: clonvick@cisco.com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Торговые марки

ssh – торговый знак, зарегистрированный в США и/или других странах.

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

1Secure Shell — защищенная командная оболочка.

2End of File — конец файла. Прим. перев.

4Этот документ признан устаревшим и заменен RFC 5735, перевод которого доступен на сайте www.protocols.ru. Прим. перев.

5Этот документ признан устаревшим и заменен RFC 4291, перевод которого доступен на сайте www.protocols.ru. Прим. перев.




RFC 4253 The Secure Shell (SSH) Transport Layer Protocol

Network Working Group                                      T. Ylonen
Request for Comments: 4253          SSH Communications Security Corp
Category: Standards Track                            C. Lonvick, Ed.
                                                 Cisco Systems, Inc.
                                                        January 2006

Транспортный протокол SSH

The Secure Shell (SSH) Transport Layer Protocol

PDF

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа «Internet Official Protocol Standards» (STD 1). Документ может распространяться без ограничений.

Авторские права

Copyright (C) The Internet Society (2006).

Тезисы

Протокол SSH1 используется для организации безопасного входа в удаленную систему (login) и организации иных безопасных служб через сети, не обеспечивающие безопасности.

В этом документе описан протокол транспортного уровня SSH, который обычно работает на базе TCP/IP. Протокол может использоваться в качестве базы для множества защищенных сетевых служб. Он обеспечивает сильное шифрование, аутентификацию серверов и защиту целостности. Протокол может также обеспечивать компрессию.

Метод обмена ключами, алгоритм открытых ключей, симметричный алгоритм шифрования, алгоритм аутентификации сообщений и алгоритм хэширования согласуются сторонами.

В этом документе также описан метод обмена ключами Diffie-Hellman и минимальный набор алгоритмов, требуемых для реализации транспортного уровня SSH.

Оглавление

Исключено из версии HTML

1. Введение

Транспортный уровень SSH обеспечивает защищенный транспорт с сильным шифрованием, криптографической аутентификацией хостов и защитой целостности.

Аутентификация на этом уровне протокола осуществляется для хостов, аутентификации пользователей на транспортном уровне нет. Для аутентификации пользователей может быть разработан протокол вышележащего уровня, работающий на базе данного протокола.

Протокол разработан с учетом простоты и гибкости согласования параметров и минимизации числ