I see your point. Like you said, TTL security adds very little in terms of security. That was all I was trying to get across. Like I said previously, I've never used it in production. I think you can get a much better security posture with ACLs and BGP Authentication, but it is just another way to add a small amount of security to your BGP sessions. It is more of a Cisco exam "Gotcha" than a real world security technique, IMO.
V/r, Ryan Krcelic On Thu, Feb 27, 2014 at 1:32 PM, Marko Milivojevic <[email protected]>wrote: > TTL Security fundamentally changes the way "direct connectivity" is > measured using the TTL for BGP. I touched on that in my previous message. > Now... how does that increase the security? > > By very little, really. The only time it is going to be 100% accurate is > for directly connected hosts (TTL 255). In all other cases it's going to be > "that or closer". We cannot configure the routers for the peers to be > *exactly* 3 hops away, but we can for *3 or fewer* hops away. In my example > with 5 routers, I just used 19 as a number that first occurred to me that > will be incorrect. I could've used 6 with the same effect. > > -- > 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 10:24 AM, 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
