Jared Mauch writes: | The reason to permit this is to verify peering policy. This | allows people to traceroute to verify packet path. Example: | I announce 172.16.0.0/16 only. I want to verify that you are not | pointing default at me, so I can do a loose source | traceroute to 10.0.0.0 via the peering point. Yes, this is one use of LSRR, but this can be accomplished through a standard looking-glass, also, which in my opinion is a much better requirement of one's potential peers (and suppliers). The major cost to LSRR is not in security (LSRR doesn't open any new attacks, it just makes some that require handshaking easier, when IP addresses are used as "authentication"), but rather in slow-path performance in some types of router/software combinations. LSRR is a phenomenally useful feature that simply was never popularized at the client level; few people used the "telnet @gateway1@gateway2:destination" syntax in those telnets that supported LSRR, and nearly no other clients offered any way to construct LSRR, pace traceroute and some pings. As a result, barely any effort goes into LSRR support in intermediate systems (routers, gateways, NATs, you name it) -- vicious circle. SSRR is even less well known/supported in the network. On the other hand, haha, that's what we have MPLS for (puke puke puke). There is an important lesson here for people who suggest that route optimization policy should be done on hosts rather than in the network. Sean.
Hosts cannot and should not do route optimization since it requires the knowledge of global network toplogy. BGP to every host? Nyet! Now, LSRR is _expensive_. Modern routers handle packets with options in hardware, and doing IP options in hardware is not cheap. (BTW, what other options are actually used? :) IMO, prohibiting IP options altogether would be a good idea (and don't ask me about fragmentation). As for debugging routing - isn't it much better to ask OFRVs to add remotely accessible traceroute servers to their boxes? There is no engineering or economic justification for diagnostic fucntionality like LSRR to stay anywhere close to the fast packet path. --vadim Brought to you by the Society For Non-Perpetuation Of Old Kludges and The K.I.S.S. Coalition. Next topic on agenda - "Do We Really Need Fragmentation In Backbones?" On Tue, 6 Mar 2001 smd@clock.org wrote:
Jared Mauch writes:
| The reason to permit this is to verify peering policy. This | allows people to traceroute to verify packet path. Example: | I announce 172.16.0.0/16 only. I want to verify that you are not | pointing default at me, so I can do a loose source | traceroute to 10.0.0.0 via the peering point.
Yes, this is one use of LSRR, but this can be accomplished through a standard looking-glass, also, which in my opinion is a much better requirement of one's potential peers (and suppliers).
The major cost to LSRR is not in security (LSRR doesn't open any new attacks, it just makes some that require handshaking easier, when IP addresses are used as "authentication"), but rather in slow-path performance in some types of router/software combinations.
LSRR is a phenomenally useful feature that simply was never popularized at the client level; few people used the "telnet @gateway1@gateway2:destination" syntax in those telnets that supported LSRR, and nearly no other clients offered any way to construct LSRR, pace traceroute and some pings.
As a result, barely any effort goes into LSRR support in intermediate systems (routers, gateways, NATs, you name it) -- vicious circle.
SSRR is even less well known/supported in the network. On the other hand, haha, that's what we have MPLS for (puke puke puke).
There is an important lesson here for people who suggest that route optimization policy should be done on hosts rather than in the network.
Sean.
On Tue, 06 Mar 2001 19:24:34 PST, Vadim Antonov said:
As for debugging routing - isn't it much better to ask OFRVs to add remotely accessible traceroute servers to their boxes? There is no engineering or economic justification for diagnostic fucntionality like LSRR to stay anywhere close to the fast packet path.
Amen, brother. ;) Anybody want to place bets that there exists at least one majr vendor whos routers do fast-path switching in hardware, but have buggy software paths that will under certain circumstances (for instance, maybe while a BGP flat is in progress) route slow-path packets differently? I know of none offhand, but the combination of opportunity for bugs, combined with the impact, makes it something dangerous to do. If a bug WERE to exist in LSRR routing, the sort of border conditions that would make it manifest are the times your peer would be poking you with LSRR packets to test what the problem is. At that point, you *really* want to be using traceroute servers so you know that your test packets are as identical as possible as the packets you're having problems with. Valdis Kletnieks Operating Systems Analyst Virginia Tech
Now, LSRR is _expensive_. Modern routers handle packets with options in hardware, and doing IP options in hardware is not cheap.
Conveniently, not very many of them are sent.
(BTW, what other options are actually used? :) IMO, prohibiting IP options altogether would be a good idea (and don't ask me about fragmentation).
I use the timestamp option sometimes. And the record route (no source routing) option. I do suspect that I'm one of a very small set with respect to the former, however.
As for debugging routing - isn't it much better to ask OFRVs to add remotely accessible traceroute servers to their boxes? There is no engineering or economic justification for diagnostic fucntionality like LSRR to stay anywhere close to the fast packet path.
While this might be nice in theory, I think that it would be a political nightmare to deploy. Thus leaving us with the status quo. It also has nasty state implications. --jhawk
participants (4)
-
John Hawkinson -
smd＠clock.org -
Vadim Antonov -
Valdis.Kletnieks＠vt.edu