<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:
From Dave Meyer's NANOG 27 presentation:
http://www.nanog.org/mtg-0302/hack.htmlNot 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/123t/123t_7/gtrollbk.htm
Regards
Magnus
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!
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.RFC 3682 - The Generalized TTL Security Mechanism (GTSM) (RFC3682)
Just to second what Vijay said here, what GTSM does is
close the window a bit; it doesn't shut it.
Dave
> 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.
>
RFC 3682 - The Generalized TTL Security Mechanism (GTSM) (RFC3682)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?
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
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
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
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
> 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.
