cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2285
Views
10
Helpful
3
Replies

BGP authentication and NAT

adalili11
Level 1
Level 1

Authentication is configed for 2 BGP peers. Can there be a static NAT in between these 2 BGP peers?

Thanks

1 Accepted Solution

Accepted Solutions

Georg is right. This won't work. I would like to clarify the reason the authentication would fail in this scenario.

Using the shared key, MD5 creates a hash of the pseudo header, which includes the following fields (from RFC2385):

- IP source and destination addresses,

- zero-padded protocol number,

- segment length

- the TCP header, excluding options, and assuming a checksum of zero

- the TCP segment data (if any)

The hash is then inserted as a TCP option and the message is sent. If any of the fields used to create the hash are altered, which is the case if you use NAT, the receiver gets the message, creates a hash value and compares it to the one received in the TCP options and this obviously fails.

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

View solution in original post

3 Replies 3

Hello,

AFAIK, authentication uses a random TCP port above 11000, hence static translations won´t work in your scenario.

HTH,

Georg

Georg is right. This won't work. I would like to clarify the reason the authentication would fail in this scenario.

Using the shared key, MD5 creates a hash of the pseudo header, which includes the following fields (from RFC2385):

- IP source and destination addresses,

- zero-padded protocol number,

- segment length

- the TCP header, excluding options, and assuming a checksum of zero

- the TCP segment data (if any)

The hash is then inserted as a TCP option and the message is sent. If any of the fields used to create the hash are altered, which is the case if you use NAT, the receiver gets the message, creates a hash value and compares it to the one received in the TCP options and this obviously fails.

Hope this helps,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

Hi Harold,

This is an excellent answer. Another question is I thought when BGP peers try to establish neighbor, both sides would initiate a seperate TCP session, after the negotiation, only one TCP session will stay, which one stays depends on the BGP router ID. But sometime, when I debug bgp try to see the session establishment, I can only see one TCP session being initiated. Why?

Thanks