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

Reply via email to