Error during BGP Sesson Establish (Open confirm state)

Question

I am trying to establish bgp session to HP-MSR Router using scapy with python. I am successful in creating a tcp socket. After this, Router is sending me one BGP Open message. In reply, I am sending BGP Open message, and acknowledging the Router's BGP Open. Router is also, acknowledging my BGP Open message. Finally Router is able to achieve "Open Confirm" state. When it achieves open confirm state, It starts sending some [TCP Re-transmission message, Group: Sequence] error. It remains in the Open Confirm state till the hold time expires.

Case 1) When my bgp id is lower than the Router id. In this case router is sending the Keep alive message, but it is also sending the same error [TCP Re-transmission message, Group: Sequence]. When I am sending some keep alive message, i am not getting any acknowledgement from router and it remains in the "Open confirm state" until hold timer expires. Router also sends a "Connection collision resolution" in this case, as expected.

Case 2) When my bgp id is greater than Router ID. In this case router is not sending any keep alive message, nor acknowledging mine. It keeps sending the same error message [TCP Re-transmission message, Group: Sequence] until hold timer expires.

I am considering that, Router should follow below bgp diagram:

-> syn
syn, ack <-
-> ack
Bgp open <-
-> BGP Open
-------------------- Open Confirm
Keep alive <-
-> Keep alive 
-------------------- Established

I expect behavior explained in above figure.

Do you build the TCP part in Scapy? If so- do you send ACK on all messages the router is sending? Do you update the Seq and Ack values in the packets you sent? — Shir, Jun 20 '19 at 09:58
Thanks Shir, I developed whole code in scapy, and I am correctly sending the tcp ack for each packet recieved and, the seq and ack values are also right. — MSS, Jun 21 '19 at 05:54
```tcp_reply = TCP(sport=received_pkt.dport, dport = received_pkt.sport, ack = received_pkt.seq+1, seq=received_pkt.ack, flags="PA")``` — MSS, Jun 21 '19 at 06:20
MSS, I'm pretty sure the ack should be `received_pkt.seq + len(received_packet[TCP].payload)` — Shir, Jun 22 '19 at 14:05
https://osqa-ask.wireshark.org/questions/9537/how-to-calculate-ack — Shir, Jun 22 '19 at 14:06
https://gist.github.com/N0dr4x/ffe99618a738978605719ce525a33042 this is a good reference for Scapy TCP uses like that — Shir, Jun 22 '19 at 14:07
Hi Shir, What do we do with TCP(PSH, ACK) messages. I am able to acheive establish state, after establish, I am acknowledging every packet like update, keepalive etc. I am getting TCP(PSH, ACK) packets in between. Do we need to acknowledge these packets or simply ignore them. — MSS, Jun 25 '19 at 07:03
You need to acknowledge only packets with payload over the TCP. If it is just PSH, ACK with no other data, this is a packets that is acknowledging *your* data, so no need to ack it again (or you'll create an infinite acking cycle...) — Shir, Jun 25 '19 at 07:31
Thank you Shir. The sequence number in the PSH, ACK (from router) keeps changing. Why we should not acknowledge it. (I have a doubt, as I don't know much, pardon me if I am wrong.). I think if we won't acknowledge the PSH, ACK then, router will think that data is not accepted at our end and it will keep retransmitting the same data. — MSS, Jun 25 '19 at 10:13
Again- if there *is* data, then acknowledge it, if there is no data (len=0 in packet's description in Wireshark)- then don't — Shir, Jun 25 '19 at 11:01
Ok Thank you shir. What is "Connection not synchronized" notification. Now I am getting it, when i am trying to establish two bgp routes parallelly with same Router. When I run only for single interface then it works fine. ```Tester A (10.110.99.2) ---- AS =2 ---> Router interface 1 (10.110.99.50)``` ; ```Tester B (10.110.101.4) ---- AS =2 ---> Router interface 2 (10.110.101.52)``` — MSS, Jun 26 '19 at 06:27
I don't know, sorry. maybe open a new question if you can't find an answer googling it or something — Shir, Jun 26 '19 at 08:30

score 1 · Answer 1 · answered Aug 18 '21 at 15:46

1

"The expected value of the Marker field of the message header is all ones. If the Marker field of the message header is not as expected, then a synchronization error has occurred and the Error Subcode MUST be set to Connection Not Synchronized." --https://datatracker.ietf.org/doc/html/rfc4271#section-6.1

But on old code it might relate to authentication: "The expected value of the Marker field of the message header is all ones if the message type is OPEN. The expected value of the Marker field for all other types of BGP messages determined based on the presence of the Authentication Information Optional Parameter in the BGP OPEN message and the actual authentication mechanism (if the Authentication Information in the BGP OPEN message is present). If the Marker field of the message header is not the expected one, then a synchronization error has occurred and the Error Subcode is set to Connection Not Synchronized." --https://datatracker.ietf.org/doc/html/rfc1771

"Optional Parameter Type 1 (Authentication Information) has been deprecated. UPDATE Message Error subcode 7 (AS Routing Loop) has been deprecated. OPEN Message Error subcode 5 (Authentication Failure) has been deprecated. Use of the Marker field for authentication has been deprecated. Implementations MUST support TCP MD5 [RFC2385] for authentication." --https://datatracker.ietf.org/doc/html/rfc4271#section-6.1

I also seem to recall this coming up if the router id of two peers is the same, which sounds like your case.

answered Aug 18 '21 at 15:46

Andrew

1
4
19

Hey andrew, its two year old question, i have figured it out then. Though thanks for answering, for the folks landing on this question. – MSS Aug 18 '21 at 17:55
Just curious, was it duplicate router IDs? This was not allowed in some/old BGP implementations. – Andrew Aug 19 '21 at 13:03
It was a mistake in TCP reply, I was not sending `received_pkt.seq + len(received_packet[TCP].payload)` instead i was always sending `received_pkt.seq + 1` ; you can refer to this conversation: https://stackoverflow.com/questions/56682202/error-during-bgp-sesson-establish-open-confirm-state/68835510?noredirect=1#comment99994168_56682202 – MSS Aug 19 '21 at 17:02
thanks for following up; guess it broke the bgp marker field indirectly – Andrew Aug 19 '21 at 18:28
No it's not like that, bgp marker field didn't broke, it will happen with any protocol which runs over TCP, if we will send incorrect `acknowledgement number` or `ack`. As TCP is not a stateless protocol, it verifies on both side if data is received fully or not on the other side. Let's say we send less than the `packet + payload size`. Then implicitly we are replying to server that we have received lesser bytes than what server sent. Then TCP will keep trying to send remaining bytes, until it hasn't received acknowledgment for all the bytes it sent. So make sure TCP implementation is correct. – MSS Aug 19 '21 at 19:41
1

Sorry, I tried to answer your question: "What is "Connection not synchronized" notification", which you asked in a comment above (on Jun 26 '19 at 6:27). – Andrew Aug 19 '21 at 22:51
yes sorry, thats right, later i did `connection not synchronised` as an usecase. – MSS Aug 20 '21 at 19:39

Error during BGP Sesson Establish (Open confirm state)

1 Answers1