Re: syn attack and source routing
John Hawkinson <jhawk@bbnplanet.com> wrote:
i should have been more specific. i don't like the idea (at all) of breaking traceroute -g either. i guess in a more general sense i should ask "just how dangerous *is* having backbone-wide/internet-wide loose source routing enabled?".
As Curtis explained, "not very".
Want to wait until SYN attacks are augmented with LSRR-enabled traffic randomization to the point of making it nearly impossible to trace? People knew about SYN flooding for years. Nothing happened until s*t hit the fan. I strongly suspect that LSRR is of the same category.
This is a very different case from that of SYN flooding, where the victims are powerless to stop it.
Now, providers being unable to trace would be a nice addition.
Please don't take our LSRR away from us, it is very useful.
Per se, LSRR is not useful. traceroute -g is. Why not to implement something saner like traceroute servers? Or better yet, the ICMP TRACEROUTE message, which would go hop by hop and on every hop generates a response message. Augmented with PROXY TRACEROUTE which will cause the destination box to send out the ICMP TRACEROUTE. I can write RFC in my copious spare time if you think that this makes more sense than the UDP kludge.
Campaigning to remove something just because you suspect it might be bad is really not nice -- it will result in random clueless people believeing you when perchance they should not :-)
Ah. I love the "the moozhik won't cross until thunder rolls" attitude. --vadim
Want to wait until SYN attacks are augmented with LSRR-enabled traffic randomization to the point of making it nearly impossible to trace?
They're optioned packets, I imagine tracing them is easier and one is able to bludgeon one's vendor into putting in better tracing for you without them having a cow.
People knew about SYN flooding for years. Nothing happened until s*t hit the fan. I strongly suspect that LSRR is of the same category.
I doubt it. As I said, anyone who's affected can cure themselves.
Please don't take our LSRR away from us, it is very useful.
Per se, LSRR is not useful. traceroute -g is.
Lately I feel like I'm the single person on the planet who actually uses LSRR for stuff. I do use loose source telnet on the average of once a week...
Why not to implement something saner like traceroute servers?
You go implement your traceroute servers everywhere I need them and THEN come back and ask me to shut it off and I'll consider it.
Or better yet, the ICMP TRACEROUTE message, which would go hop by hop and on every hop generates a response message. Augmented with PROXY TRACEROUTE which will cause the destination box to send out the ICMP TRACEROUTE.
I can write RFC in my copious spare time if you think that this makes more sense than the UDP kludge.
I'm not convinced it makes more sense. As I said to smd in response to his similar comments, the beauty of the current traceroute is that it's hard for idiots to turn it off. Very few other solutions have this wonderful property. --jhawk
John Hawkinson writes:
Lately I feel like I'm the single person on the planet who actually uses LSRR for stuff. I do use loose source telnet on the average of once a week...
You're not the only one... Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - chuckie@panix.com | Panix Public Access Internet and UNIX| |Network Administrator/Architect | New York City, NY | +------------------------------------+--------------------------------------+
Or better yet, the ICMP TRACEROUTE message, which would go hop by hop and on every hop generates a response message. Augmented with PROXY TRACEROUTE which will cause the destination box to send out the ICMP TRACEROUTE.
This would be bad. Remembering back to the dim prehistory of time, when RIP mattered, I recall that gated (version 1) would respond differently to "a routing daemon" (whose UDP source port was 520) than to a "management tool" like ripquery (whose UDP source port was >1023). This always struck me as idiotic (and let's have no quips about RIP itself being idiotic -- this was 1986 and the alternatives, for me at that time, were worse). What this meant was that if your routing daemon wasn't hearing something you thought it ought to be hearing, there was no way to use the management tool to actually _look_at_ what was being offered. (This was before tcpdump, too.) I guarantee you that if ICMP TRACEROUTE appears, at least one widely used router, for at least one year of its aggregate future history, will respond inaccurately to it. Possibly there will even be knobs on the router to help network administrators configure "appropriate" responses to ICMP TRACEROUTE. Vadim called "traceroute" a "UDP kludge" and so it is, but it lets me see what packets would do, which is a LOT more useful than seeing what a router wants me to see. Perhaps this can be well enough specified in an I-D. Experience says not.
(Again, sorry for the delay responding.) Paul A Vixie writes:
Or better yet, the ICMP TRACEROUTE message, which would go hop by hop and on every hop generates a response message. Augmented with PROXY TRACEROUTE which will cause the destination box to send out the ICMP TRACEROUTE.
This would be bad. Remembering back to the dim prehistory of time, when [...]
I'm very surprised that noone has mentioned what seems to me to be the *really* serious drawback to this scheme. Remember how much grief you had the last time someone did a news sendsys forged to your name? (If it's never happened to you, be glad...) This sort of attack got so bad that the default setup these days is to ignore sendsys. The principle's the same here. What's to stop me from forging TRACEROUTEs which cause many response packets to be sent to my victim for each single packet I send out? I'd have an easy way to multiply my effective bandwidth for simple DoS bandwidth attacks. Even an idiot with a 28.8 modem could wind up doing some serious damage. /a --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix & Internet, NYC. alexis@panix.com
In message <199609182107.OAA00889@quest.quake.net>, Vadim Antonov writes:
John Hawkinson <jhawk@bbnplanet.com> wrote:
i should have been more specific. i don't like the idea (at all) of breaking traceroute -g either. i guess in a more general sense i should ask "just how dangerous *is* having backbone-wide/internet-wide loose source routing enabled?".
As Curtis explained, "not very".
Want to wait until SYN attacks are augmented with LSRR-enabled traffic randomization to the point of making it nearly impossible to trace?
At the borders hosts that don't want to be attacked just shut off LSRR at the border router or at the host itself. Problem solved. And we still have traceroute "as is". Curtis
participants (6)
-
Alec H. Peterson -
Alexis Rosen -
Curtis Villamizar -
John Hawkinson -
Paul A Vixie -
Vadim Antonov