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
