BGP TTL check in 12.3(7)T
<http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/prod_bulletin09186a00801abfda.html#wp55584> From Dave Meyer's NANOG 27 presentation: http://www.nanog.org/mtg-0302/hack.html Not bad - Feb 2003 till April 2004 to code, test and implement a change driven by NANOG :-) Interesting that it is listed under the Routing enhancements and not under the Security enhancements of 12.3(7)T. -Hank
Hank Nussbacher wrote:
<http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/prod_bulletin09186a00801abfda.html#wp55584>
From Dave Meyer's NANOG 27 presentation: http://www.nanog.org/mtg-0302/hack.html
Not bad - Feb 2003 till April 2004 to code, test and implement a change driven by NANOG :-)
Interesting that it is listed under the Routing enhancements and not under the Security enhancements of 12.3(7)T. When it comes to great new features in IOS, I must say that this will help all who uses IOS in production environments.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123... Regards Magnus
On Thu, Apr 08, 2004 at 11:30:38AM +0200, Hank Nussbacher wrote:
<http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/prod_bulletin09186a00801abfda.html#wp55584>
From Dave Meyer's NANOG 27 presentation: http://www.nanog.org/mtg-0302/hack.html
Not bad - Feb 2003 till April 2004 to code, test and implement a change driven by NANOG :-)
Interesting that it is listed under the Routing enhancements and not under the Security enhancements of 12.3(7)T.
The TTL mechanism is just a way to distinguish at low cost between good for_us traffic and junk. So more of a classifer than a security layer, though it can be argued both ways. And even though it does have security in the title, it is _not_ a panacea for "securing" bgp or any routing information. http://www.faqs.org/rfcs/rfc3682.html /vijay /vijay
The TTL mechanism is just a way to distinguish at low cost between good for_us traffic and junk. So more of a classifer than a security layer, though it can be argued both ways. And even though it does have security in the title, it is _not_ a panacea for "securing" bgp or any routing information.
http://www.faqs.org/rfcs/rfc3682.html I agree that it is not a panacea... But, you must admit, it provides an incredible level of comfort. It would be wonderful to only allow internally generated traffic to talk to the core of your network with a simple TTL filter. Versus anti-spoofing filters from hell. Now, when do we get it at line speed on engine 0 cards? I hope some other vendors are listening to this conversation!
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of vijay gill Sent: Thursday, April 08, 2004 10:41 AM To: Hank Nussbacher Cc: nanog@merit.edu Subject: Re: BGP TTL check in 12.3(7)T
On Thu, Apr 08, 2004 at 11:30:38AM +0200, Hank Nussbacher wrote:
<http://www.cisco.com/en/US/products/sw/iosswr> el/ps5207/prod_bulletin0
9186a00801abfda.html#wp55584>
From Dave Meyer's NANOG 27 presentation: http://www.nanog.org/mtg-0302/hack.html
Not bad - Feb 2003 till April 2004 to code, test and implement a change driven by NANOG :-)
Interesting that it is listed under the Routing enhancements and not under the Security enhancements of 12.3(7)T.
The TTL mechanism is just a way to distinguish at low cost between good for_us traffic and junk. So more of a classifer than a security layer, though it can be argued both ways. And even though it does have security in the title, it is _not_ a panacea for "securing" bgp or any routing information.
http://www.faqs.org/rfcs/rfc3682.html /vijay /vijay
On Thu, 8 Apr 2004, Blaine Christian wrote:
The TTL mechanism is just a way to distinguish at low cost between good for_us traffic and junk. So more of a classifer than a security layer, though it can be argued both ways. And even though it does have security in the title, it is _not_ a panacea for "securing" bgp or any routing information.
http://www.faqs.org/rfcs/rfc3682.html
I agree that it is not a panacea... But, you must admit, it provides an incredible level of comfort. It would be wonderful to only allow internally generated traffic to talk to the core of your network with a simple TTL filter. Versus anti-spoofing filters from hell.
You may be misunderstanding the applicability of GTSM. It's only really useful for eBGP sessions, not for "internally generated traffic" (unless you fix the TTLs manually for iBGP sessions). Spoofing filters (source address is most useful, but a few protocols being deployed now also require destination address based filtering) at your border are still best to prevent external abuse to your infrastructure?
Now, when do we get it at line speed on engine 0 cards?
I hope some other vendors are listening to this conversation!
(tongue in cheek) Maybe you should be listening to the vendors instead, and pick ones which provide the features you need? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Hi Pekka,
Spoofing filters (source address is most useful, but a few protocols being deployed now also require destination address based filtering) at your border are still best to prevent external abuse to your infrastructure?
I agree that spoofing filters help also (perhaps we are not communicating)... But TTL helps in places where you can't just anti-spoof. For example, suppose you have box X which can do ZERO filtering at line rate. Then box Y that can... X->Y You have a BGP session between X and Y and many untrusted things talking to X. How would I anti-spoof X's protocol traffic when I am at Y? The nice thing about X is that it does, hopefully reliably, decrement the TTL. Michel, this same answer should apply to your statement. I agree that anti-spoofing helps. But TTL filtering can fix some very interesting problems. BTW, I am only commenting on TTL filtering and not necessarily Cisco's implementation (I have not even read through their implementation yet). Regards, Blaine
The TTL mechanism is just a way to distinguish at low cost between good for_us traffic and junk. So more of a classifer than a security layer, though it can be argued both ways. And even though it does have security in the title, it is _not_ a panacea for "securing" bgp or any routing information.
Just to second what Vijay said here, what GTSM does is close the window a bit; it doesn't shut it. Dave
On 8-apr-04, at 11:30, Hank Nussbacher wrote:
<http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/ prod_bulletin09186a00801abfda.html#wp55584>
Not bad - Feb 2003 till April 2004 to code, test and implement a change driven by NANOG :-)
Here is the feature guide, for those who can't wait to implement it: http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/ products_feature_guide09186a008020e6f5.html However, this says a TTL of 254 will be accepted. Now the fact that I can talk to boxes running a slightly older IOS with a TTL of 0 without any problems suggests to me that emitting packets with a TTL of 255 on router A and accepting packets with a TTL of 254 on router B allows for the presence of a router C in the middle. That can't be good. Also, they say enabling this feature won't change behavior for outgoing packets. So do these now have a TTL of 255, regardless?
However, this says a TTL of 254 will be accepted. Now the fact that I can talk to boxes running a slightly older IOS with a TTL of 0 without any problems suggests to me that emitting packets with a TTL of 255 on router A and accepting packets with a TTL of 254 on router B allows for the presence of a router C in the middle. That can't be good.
I suspect they set the limit to 254 because they expected to decrement the TTL on ingress (or that the box sending the packets would decrement on send). You have an interesting point WRT the TTL 0. Perhaps if you receive a packet with a TTL of 0 that is destined for yourself you should just accept it? It is not clear to me exactly when you "have" to throw away the packet (on ingress/themiddle/egress). I believe it is valid to accept a packet that is destined for yourself with a TTL of zero. Since I have observed that packets received from some types of routers have their TTL set to 255 (on upon reaching the receiving device route processor) I would have to assume that the TTL is not being decremented for route processor packets. Of course I was only playing with one router and it may be vendor dependant (the vendor was not Cisco). I am not sure that 254 is a good maximum number. Perhaps someone "in the know" can enlighten all of us as to why they chose to stop at 254 instead of 255. Regards, Blaine
On 8-apr-04, at 20:37, Blaine Christian wrote:
However, this says a TTL of 254 will be accepted. Now the fact that I can talk to boxes running a slightly older IOS with a TTL of 0 without any problems suggests to me that emitting packets with a TTL of 255 on router A and accepting packets with a TTL of 254 on router B allows for the presence of a router C in the middle. That can't be good.
I suspect they set the limit to 254 because they expected to decrement the TTL on ingress (or that the box sending the packets would decrement on send).
But neither common sense nor observations support this expectation.
You have an interesting point WRT the TTL 0. Perhaps if you receive a packet with a TTL of 0 that is destined for yourself you should just accept it?
The interesting thing is that packets with a TTL of 0 wouldn't ordinarily be seen in the wild. A router won't forward a packet with a TTL of 1 (as this becomes 0 during the forwarding process) and a host that sends out packets with a TTL 0 can only expect to communicate on the local subnet. (So I guess doing all of this with TTL 0 rather than 255 would have been just as effective.)
It is not clear to me exactly when you "have" to throw away the packet (on ingress/themiddle/egress). I believe it is valid to accept a packet that is destined for yourself with a TTL of zero.
Agree. Yet another interesting aspect: a Cisco won't forward a packet with a TTL of 0: Minimum Time to Live [1]: 0 Maximum Time to Live [30]: 4 Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 23.16.3.14 0 23.16.3.19 8 msec 0 msec 4 msec 1 23.16.3.19) 4 msec 4 msec 4 msec 2 23.16.3.14) 12 msec * 16 msec So apparently a Cisco checks for TTL <= 1 on ingress when forwarding rather than TTL == 0 on egress. How hard do we have to look before we find a box that doesn't and accepts a packet with a TTL of 0 and then emits this packet with a TTL of 255?
Since I have observed that packets received from some types of routers have their TTL set to 255 (on upon reaching the receiving device route processor) I would have to assume that the TTL is not being decremented for route processor packets. Of course I was only playing with one router and it may be vendor dependant (the vendor was not Cisco).
In the (Free)BSD (4.9) code the TTL decrementing is done in the ip_forward() function. (That is, unless IPSTEALTH is defined, in which case the box doesn't bother.) Since many a router vendor borrowed code from BSD it is likely most do it like this.
I am not sure that 254 is a good maximum number. Perhaps someone "in the know" can enlighten all of us as to why they chose to stop at 254 instead of 255.
Yes, that would be helpful. Iljitsch
On Thu, 8 Apr 2004, Iljitsch van Beijnum wrote:
You have an interesting point WRT the TTL 0. Perhaps if you receive a packet with a TTL of 0 that is destined for yourself you should just accept it?
The interesting thing is that packets with a TTL of 0 wouldn't ordinarily be seen in the wild. A router won't forward a packet with a TTL of 1 (as this becomes 0 during the forwarding process) and a host that sends out packets with a TTL 0 can only expect to communicate on the local subnet. (So I guess doing all of this with TTL 0 rather than 255 would have been just as effective.)
Even sending packets with TTL=0 is invalid, so this is a moot point. Or were you proposing modifying the sending and receiving implementations and the IPv4/6 specifications?
From hosts requirements for v4, for example:
A host MUST NOT send a datagram with a Time-to-Live (TTL) value of zero. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
I am not sure that 254 is a good maximum number. Perhaps someone "in the know" can enlighten all of us as to why they chose to stop at 254 instead of 255.
I can think of at least one vendor who decremented TTL prior to letting the packet come up to the RP. Further, the same vendor would drop the packet on the line card when the TTL went to zero, so the RP never got a chance to see it. I suspect that there are no other routers out there that do this today, but unless all vendors are willing to stand up and say that they deal with such things properly today, this is a possible issue. Allowing 254 gives some slack and doesn't open the window significantly. If someone were to use this to attack, then at the very worst, they are one hop away from an EBGP speaker. I suspect that this will make them relatively easy to track down. If folks do feel that this is a significant issue, then some operator who is both motivated about this and about to write a big check should poll his favorite router vendors and see if they all comply and then report back. Tony
participants (8)
-
Blaine Christian -
David Meyer -
Hank Nussbacher -
Iljitsch van Beijnum -
Magnus Eriksson -
Pekka Savola -
Tony Li -
vijay gill