Assuming this is discussing the "slipping in the tcp window" tcp reset attack.

4.1.  Protection of TCP sessions used by BGP

   Attacks on TCP sessions used by BGP (ex: sending spoofed TCP
   RST packets) could bring down the TCP session.  Following a
   successful ARP spoofing attack (or other similar Man-in-the-Middle
   attack), the attacker might even be able to inject packets into
   the TCP stream (routing attacks).

You do NOT have to do arp spoofing to inject packets into the bgp session.
The same "guessing the sequence number within the window" trick works for 
packet injection not just resets.

It is possible to blindly inject bgp updates into a bgp stream without doing 
any kind of MITM.
You have to know more about the bgp session such as BGP ID etc... but it is 
possible.


This is mostly true:
4.2.  BGP TTL security (GTSM)

   BGP sessions can be made harder to spoof with the Generalized TTL
   Security Mechanisms (aka TTL security) [9].  Instead of sending TCP
   packets with TTL value = 1, the routers send the TCP packets with TTL
   value = 255 and the receiver checks that the TTL value equals 255.
   Since it's impossible to send an IP packet with TTL = 255 to a non-
   directly-connected IP host, BGP TTL security effectively prevents all
   spoofing attacks coming from third parties not directly connected to
   the same subnet as the BGP-speaking routers.  Network administrators
   SHOULD implement TTL security on directly connected BGP peerings.

   Note: Like MD5 protection, TTL security has to be configured on both
   ends of a BGP session.

Many routers today actually do ttl decrement on the line card while GTSM is 
likely further up the cpu/npu stack. So depending on vendor and router you 
probably need to allow 254 for a directly connected router.




"Pampers use multiple layers of protection to prevent leakage. Rommel used 
defense in depth to defend European fortresses." (A.White) 
[email protected]


>-----Original Message-----
>From: OPSEC [mailto:[email protected]] On Behalf Of Ronald Bonica
>Sent: Wednesday, April 16, 2014 7:34 AM
>To: Gunter Van de Velde (gvandeve); opsec wg mailing list
>Cc: [email protected]; [email protected]
>Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
>
>Folks,
>
>
>
>This document is very comprehensive and well-written. Kudos to the authors.
>
>
>
>However, please take a look at the Forward.
>
>
>
>                                                Ron
>
>
>
>
>
>From: OPSEC [mailto:[email protected]] On Behalf Of Gunter Van de Velde
>(gvandeve)
>Sent: Wednesday, April 16, 2014 7:56 AM
>To: opsec wg mailing list
>Cc: [email protected]; [email protected]
>Subject: Re: [OPSEC] Start of 2nd WGLC for draft-ietf-opsec-bgp-security
>
>
>
>Please find this reminder to query for your feedback.
>
>
>
>Brgds,
>
>G/
>
>
>
>From: Gunter Van de Velde (gvandeve)
>Sent: 08 April 2014 11:18
>To: opsec wg mailing list
>Cc: KK ([email protected]); [email protected]
><mailto:[email protected]>
>Subject: Start of 2nd WGLC for draft-ietf-opsec-bgp-security
>
>
>
>Dear OpSec WG,
>
>
>
>This starts a 2nd Working Group Last Call for draft-ietf-opsec-bgp-security.
>
>Due to the time taken to integrate all comments from the first WGLC this 2nd
>WGLC is initiated.
>
>
>
>All three authors have replied, stating that they do not know of any IPR
>associated with this draft.
>
>
>
>The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-opsec-
>bgp-security/ <https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/>
>
>
>
>Please review this draft to see if you think it is ready for publication and
>comments to the list, clearly stating your view.
>
>
>
>This WGLC ends 22-April-2014.
>
>
>
>Thanks,
>
>G/
>
>

_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec

Reply via email to