See RFC 4272, section 3.2.1.4. As I recall from when this stuff was hot, it turned out that guessing a valid sequence number in a given window size was no *so* hard as long as you could send a 20 Mb/s stream of TCP RSTs at the target for a few seconds (or something along those lines). You'd get a packet that was close enough fairly quickly.
Bob -- Sent from my iPhone, please excuse any typos. > On Feb 27, 2014, at 6:52 PM, Tony Singh <[email protected]> wrote: > > > Looking at my notes the OPEN message contains the authentication hash, this > is in the optional parameters field. > > To quote Cisco Netacad CCNP BSCI v5.0 > > IDLE - Router is searching routing table to see whether a route exists to > reach the neighbor. > CONNECT - Router found a route to the neighbor and has completed the > three-way TCP handshake. > OPEN SENT - Open message sent, with parameters for the BGP session. > OPEN CONFIRM - Router received agreement on the parameters for establishing > session. > ACTIVE - Router didn't receive agreement on parameters of establishment. > ESTABLISHED - Peering is established; routing begins. > > > the RST would be if our TCP retransmits are getting no where i.e if the > connection is broken somewhere > > Also to add, the TCP sequence number would also need to match when a spoofer > matches the TTL right? > > -- > BR > > Tony > > Sent from my iPad > >> On 27 Feb 2014, at 18:36, Bob McCouch <[email protected]> wrote: >> >> The value of TTL security is not that it "scopes" your BGP advertisements, >> quite the opposite. It's an anti-spoofing technique. By default, EBGP >> packets have a TTL of 1 to limit their scope to the local segment. However, >> an attacker could spoof a TCP RST from anywhere on the Internet that >> appears to come from your neighbor to kill your session. BGP TTL security >> addresses this by setting the TTL up to 255 (which in theory means the >> "scope" of the advertisement is much larger), but requires that the >> received packet have a TTL of 255-(hops). So if you say "ttl-security hops >> 1" then it means the received BGP messages must have an IP TTL of 254 (or >> higher as Marko pointed out). >> >> It's pretty easy to spoof a packet and have it land with a TTL of 1 at >> your target. But it's very hard to spoof a packet from across the Internet >> and have it land at your target with a TTL of 254. That's what TTL security >> does for you. >> >> That said, I've never used it in production. It's usually enough of a >> battle to get an ISP to actually put an MD5 on the session... >> >> A spoofed packet could get past ACLs. I'm not sure off hand if the TCP RST >> has to have the MD5 on it or not to get processed and reset the connection. >> Anyone know that? >> >> >>> On Thu, Feb 27, 2014 at 1:24 PM, Ryanlk18 . <[email protected]> wrote: >>> >>> Marko, >>> >>> Thanks for the clarification on the sequence number. >>> >>> As for the TTL Security, very true that it doesn't have to match exactly, >>> but isn't the point of ttl security to limit the scope of your BGP >>> advertisements? Scaling it down to 19 from 255 does add some security, but >>> IMO if you are going to use it, then why not use it with the highest level >>> and set it to the exact number of hops. If the lab were to ask for you to >>> secure your BGP session as much as possible without using BGP >>> authentication, do you think 19 would suffice to satisfy that requirement? >>> >>> FYI, I've never used it before in production because we didn't feel it >>> added any additional benefit since our ebgp neighbors were 1 hop away and >>> we were using authentication and access lists to restrict peerings to >>> specific addresses. >>> >>> V/r, >>> >>> Ryan Krcelic >>> >>> >>> >>> On Thu, Feb 27, 2014 at 12:24 PM, Marko Milivojevic >>> <[email protected]>wrote: >>> >>>> If I recall, ASA won't change the actual MD5, but it will change TCP >>>> sequence numbers, which in turn affect the calculated MD5 (it becomes >>>> wrong). >>>> >>>> As far as TTL security goes, what you wrote is one of the big >>>> misconceptions most people have about it. The TTL doesn't have to match >>>> *exactly* it needs to be *at least* a certain value, or higher. Here's >>>> another example: >>>> >>>> R1---R2---R3---R4---R5 >>>> >>>> I'm running EIGRP between them, just to get loopbacks of R1 and R5 into >>>> the tables. Here's the relevant BGP config: >>>> >>>> R1: >>>> router bgp 65001 >>>> neighbor 10.0.0.5 remote-as 65005 >>>> neighbor 10.0.0.5 ttl-security hops 19 >>>> neighbor 10.0.0.5 update-source Loopback0 >>>> ! >>>> address-family ipv4 >>>> neighbor 10.0.0.5 activate >>>> ! >>>> >>>> R5: >>>> router bgp 65005 >>>> neighbor 10.0.0.1 remote-as 65001 >>>> neighbor 10.0.0.1 ttl-security hops 19 >>>> neighbor 10.0.0.1 update-source Loopback0 >>>> ! >>>> address-family ipv4 >>>> neighbor 10.0.0.1 activate >>>> ! >>>> >>>> So, I'm fairly positive they're fewer than 19 hops away: >>>> >>>> R1#traceroute 10.0.0.5 source Loopback0 >>>> Type escape sequence to abort. >>>> Tracing the route to 10.0.0.5 >>>> VRF info: (vrf in name/id, vrf out name/id) >>>> 1 192.168.12.2 2 msec 1 msec 0 msec >>>> 2 192.168.23.3 1 msec 1 msec 0 msec >>>> 3 192.168.34.4 1 msec 1 msec 1 msec >>>> 4 192.168.45.5 1 msec * 1 msec >>>> >>>> Yet... >>>> >>>> R1#show bgp ipv4 unicast summary >>>> BGP router identifier 192.168.12.1, local AS number 65001 >>>> BGP table version is 1, main routing table version 1 >>>> >>>> Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down >>>> State/PfxRcd >>>> 10.0.0.5 4 65005 7 7 1 0 0 >>>> 00:03:10 0 >>>> >>>> -- >>>> Marko Milivojevic - CCIE #18427 (SP R&S) >>>> Senior CCIE Instructor / Managing Partner - iPexpert >>>> :: Free Video Training: http://youtube.com/iPexpertInc >>>> :: Social: http://twitter.com/@icemarkom | http://fb.me/ccie18427 >>>> :: iPexpert: http://www.ipexpert.com/Communities | +1-810-326-1444 >>>> >>>> >>>> >>>> On Thu, Feb 27, 2014 at 6:00 AM, Ryanlk18 . <[email protected]>wrote: >>>> >>>>> Some food for thought, I would avoid TTL security unless specifically >>>>> asked to use it (or in cisco's round about way of asking to use it). If >>>>> you are asked to "Secure your BGP Session" then just use authentication. >>>>> TTL security is pretty straight forward, but requires you to know the >>>>> exact >>>>> hop count of the underlying IGP to your destination. If you are off by 1, >>>>> then no dice. >>>>> >>>>> In the lab, probably not a big deal. In the real world, it can >>>>> sometimes be a bit more tricky. >>>>> >>>>> One other thing about BGP authentication, in case anyone is interested. >>>>> I was having a problem with BGP authentication going through an ASA. >>>>> Although the ASA was configured to allow all traffic through, when I >>>>> enabled authentication, BGP would drop. The debug told me the problem was >>>>> with the password. After a little goole'ing, I found that the ASA was >>>>> changing the MD5 on the authentication packets, causing my authentication >>>>> to fail. To fix this you have to go in and tell the ASA to leave the BGP >>>>> authentication packets alone. >>>>> >>>>> Here is a good article describing how to set it up. >>>>> >>>>> https://supportforums.cisco.com/docs/DOC-21347 >>>>> >>>>> V/r, >>>>> >>>>> Ryan Krcelic >>>>> >>>>> >>>>> >>>>> On Thu, Feb 27, 2014 at 8:51 AM, Christopher Lemish < >>>>> [email protected]> wrote: >>>>> >>>>>> Thanks guys! >>>>>> >>>>>> Thank you, >>>>>> Chris >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: [email protected] [mailto: >>>>>> [email protected]] On Behalf Of Bob McCouch >>>>>> Sent: Wednesday, February 26, 2014 7:36 PM >>>>>> To: Marko Milivojevic >>>>>> Cc: OSL CCIE ([email protected]) >>>>>> Subject: Re: [OSL | CCIE_RS] BGP: TTL Security >>>>>> >>>>>> I think the issue is exactly what Marko mentions in #1 & 2: >>>>>> >>>>>> 1) The TTL is set to 255, instead of 1 (default) >>>>>> 2) TTL security feature needs to be turned on on both sides >>>>>> >>>>>> If you were to only enable TTL security on one side, it would need >>>>>> "hops 254" because the other EBGP peer will send its packets with TTL 1, >>>>>> the default for EBGP sessions. You need to enable it on both sides for it >>>>>> to work correctly by setting the TTL to 255 and then subtracting only the >>>>>> expected number of hops. After all, spoofing a packet that lands on your >>>>>> router with a TTL 1 is not too hard. But spoofing a packet that lands on >>>>>> your router with a TTL of 254 would be quite a feat if you're not on the >>>>>> same wire. >>>>>> >>>>>> Best, >>>>>> Bob >>>>>> CCIE #38296 >>>>>> HerdingPackets.net >>>>>> >>>>>> >>>>>> On Wed, Feb 26, 2014 at 3:41 PM, Marko Milivojevic <[email protected] >>>>>>> wrote: >>>>>> >>>>>>> I can confirm (and so can you in the lab environment). >>>>>>> >>>>>>> When configured with the ttl-security, several things are important >>>>>>> for the eBGP neighbors: >>>>>>> >>>>>>> 1) The TTL is set to 255, instead of 1 (default) >>>>>>> 2) TTL security feature needs to be turned on on both sides >>>>>>> 3) TTL of the incoming packet will be matched against the configured >>>>>>> hop count using a simple check: (255-Packet_TTL) <= hops >>>>>>> >>>>>>> Let's take a look. >>>>>>> >>>>>>> (AS65001)R1[Gi1]---{192.168.12.0/24}---[Gi1]R2(AS65002)<http://192.168.12.0/24%7D---%5BGi1%5DR2(AS65002)> >>>>>>> >>>>>>> >>>>>>> R1: >>>>>>> interface GigabitEthernet1 >>>>>>> ip address 192.168.12.1 255.255.255.0 ! >>>>>>> router bgp 65001 >>>>>>> neighbor 192.168.12.2 remote-as 65002 neighbor 192.168.12.2 >>>>>>> ttl-security hops 2 ! >>>>>>> address-family ipv4 >>>>>>> neighbor 192.168.12.2 activate >>>>>>> ! >>>>>>> >>>>>>> R2: >>>>>>> interface GigabitEthernet1 >>>>>>> ip address 192.168.12.2 255.255.255.0 ! >>>>>>> router bgp 65001 >>>>>>> neighbor 192.168.12.1 remote-as 65001 neighbor 192.168.12.1 >>>>>>> ttl-security hops 2 ! >>>>>>> address-family ipv4 >>>>>>> neighbor 192.168.12.1 activate >>>>>>> ! >>>>>>> >>>>>>> R1: >>>>>>> R1#show bgp ipv4 unicast summary >>>>>>> BGP router identifier 192.168.12.1, local AS number 65001 BGP table >>>>>>> version is 1, main routing table version 1 >>>>>>> >>>>>>> Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ >>>>>> Up/Down >>>>>>> State/PfxRcd >>>>>>> 192.168.12.2 4 65002 7 7 1 0 0 >>>>>> 00:04:15 >>>>>>> 0 >>>>>>> >>>>>>> So, the session is up, even though they're directly connected (proving >>>>>>> the point of the TTL statement above). But what WAS the actual TTL >>>>>>> used on the wire? See for yourself - this is the SYN packet for that >>>>>> session. >>>>>>> >>>>>>> Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) >>>>>>> Ethernet II, Src: 00:0c:29:84:d3:2e (00:0c:29:84:d3:2e), Dst: >>>>>>> 00:50:56:92:37:3d (00:50:56:92:37:3d) >>>>>>> Internet Protocol Version 4, Src: 192.168.12.1 (192.168.12.1), Dst: >>>>>>> 192.168.12.2 (192.168.12.2) >>>>>>> Version: 4 >>>>>>> Header length: 20 bytes >>>>>>> Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; >>>>>> ECN: >>>>>>> 0x00: Not-ECT (Not ECN-Capable Transport)) >>>>>>> Total Length: 44 >>>>>>> Identification: 0xa870 (43120) >>>>>>> Flags: 0x02 (Don't Fragment) >>>>>>> Fragment offset: 0 >>>>>>> Time to live: 255 >>>>>>> Protocol: TCP (6) >>>>>>> Header checksum: 0x3947 [correct] >>>>>>> Source: 192.168.12.1 (192.168.12.1) >>>>>>> Destination: 192.168.12.2 (192.168.12.2) Transmission Control >>>>>>> Protocol, Src Port: 51300 (51300), Dst Port: bgp (179), Seq: 0, Len: 0 >>>>>>> >>>>>>> -- >>>>>>> Marko Milivojevic - CCIE #18427 (SP R&S) Senior CCIE Instructor / >>>>>>> Managing Partner - iPexpert >>>>>>> :: Free Video Training: http://youtube.com/iPexpertInc >>>>>>> :: Social: http://twitter.com/@icemarkom | http://fb.me/ccie18427 >>>>>>> :: iPexpert: http://www.ipexpert.com/Communities | +1-810-326-1444 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 26, 2014 at 12:19 PM, Edgar Díaz Orellana < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> In fact using an loopback interface is kind of had a second hop, 1 >>>>>>>> of >>>>>>> them >>>>>>>> is external the other is internal thru control-plane. >>>>>>>> >>>>>>>> That's why need to use 2 hops if you had neighbors peering thru >>>>>>>> loopbacks >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>>> On 26-02-2014, at 14:09, marc abel <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Are you peering between loopbacks? In this case you would need to >>>>>>>>> do ttl-security hops 2. Your neighbor is going to decrement 1 ttl >>>>>>>>> before sending and then local router would decrement 1 before >>>>>>>>> delivering to loopback interface. This probably wouldn't show up >>>>>>>>> in your traceroute, >>>>>>>> but >>>>>>>>> you would have a ttl of 253. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Feb 26, 2014 at 10:22 AM, Christopher Lemish < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Guys, >>>>>>>>>> >>>>>>>>>> I just turned up a BGP session for a customer (doing BGP Failover >>>>>>>>>> for them). I am using the "neigh ttl-security hops" cmd. A >>>>>>>>>> traceroute confirms it is 1 hop away. The Cisco documentation >>>>>>>>>> explains that if a >>>>>>>> TTL >>>>>>>>>> is received that equals the TTL value expected or is higher, the >>>>>>> router >>>>>>>>>> will accept that packet. >>>>>>>>>> >>>>>>>>>> I was troubleshooting it quickly and the cmd "neigh x.x.x.x >>>>>>> ttl-security >>>>>>>>>> hops 254" is the only hop count that maintains the BGP session. >>>>>>>>>> I >>>>>>>> thought >>>>>>>>>> I recall that the ttl-security cmd "must exactly" match the >>>>>>>>>> number of >>>>>>>> hops >>>>>>>>>> away from one of Joe's videos. But, I thought we could use the >>>>>>>>>> "neigh x.x.x.x ttl-security hops 1" which means it is 1 hop away >>>>>>>>>> and would >>>>>>>> accept >>>>>>>>>> a TTL of 254 or higher, indicating that it is 1 hop away. >>>>>>>>>> >>>>>>>>>> (TTL=255)-->(TTL=254) >>>>>>>>>> PE--------CE >>>>>>>>>> >>>>>>>>>> The IOS version of this 3925 is the following: >>>>>>>>>> Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version >>>>>>>>>> 15.2(4)M5, RELEASE SOFTWARE (fc2) >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security >>>>>>>>>> Videos >>>>>>> :: >>>>>>>>>> >>>>>>>>>> iPexpert on YouTube: www.youtube.com/ipexpertinc >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Marc Abel >>>>>>>>> CCIE #35470 >>>>>>>>> (Routing and Switching) >>>>>>>>> _______________________________________________ >>>>>>>>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security >>>>>>>>> Videos >>>>>>> :: >>>>>>>>> >>>>>>>>> iPexpert on YouTube: www.youtube.com/ipexpertinc >>>>>>>> _______________________________________________ >>>>>>>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security >>>>>> Videos :: >>>>>>>> >>>>>>>> iPexpert on YouTube: www.youtube.com/ipexpertinc >>>>>>> _______________________________________________ >>>>>>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos >>>>>> :: >>>>>>> >>>>>>> iPexpert on YouTube: www.youtube.com/ipexpertinc >>>>>> _______________________________________________ >>>>>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: >>>>>> >>>>>> iPexpert on YouTube: www.youtube.com/ipexpertinc >>>>>> _______________________________________________ >>>>>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: >>>>>> >>>>>> iPexpert on YouTube: www.youtube.com/ipexpertinc >> _______________________________________________ >> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: >> >> iPexpert on YouTube: www.youtube.com/ipexpertinc _______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
