Re: J'accuse!: Whitehouse and NSA vs. Panix and VTW
At 11:33 AM 9/13/96 -0700, stewarts@ix.netcom.com wrote:
At least one of the newspaper articles I've read has referred to the need for real authentication on the net to prevent the anonymity that makes this kind of attack possible, and in particular for the major network providers to make sure that they don't export messages with bogus addressing, a cure that the article said would take several months to deploy. I don't know if they were referring to IPv6, or sendmail modifications, or router hacks, or what; the article's author seemed to think this was about bogusly-addressed email messages rather than understanding SYNs.
Well IPSec provides for authentication of endpoints which would identify the syn attacker. What amazes me is that routers happily pass packets with foreign IP return addresses. I guess there is some valid utility to being able to originate a connection that actually goes somewhere else for intiating a many to many protocol. But I can't think of any practical application that would necessarily be that way. So why do routers let packets leave local networks that do not appear to originate from said local network? Doesn't routing work "both ways" so to speak?
Well IPSec provides for authentication of endpoints which would identify the syn attacker.
Only if the attacker were so stupid as to put in valid authentication data identifying herself. I think IPSEC would allow you to throw away the SYNs without processing them and without putting anything in your incoming connection queue. On the other hand, you'd have to do all the authentication protocol and computation for each packet in order to determine that it was bogus. I can see where that could lead to a still worse denial-of-service attack if your IPSEC code wasn't properly written.
What amazes me is that routers happily pass packets with foreign IP return addresses.
Defining what a "foreign IP return address" is quickly becomes complicated.
I guess there is some valid utility to being able to originate a connection that actually goes somewhere else for intiating a many to many protocol. But I can't think of any practical application that would necessarily be that way.
As far as I know, nothing does that.
So why do routers let packets leave local networks that do not appear to originate from said local network?
Because routers don't know which networks are "local networks" and which networks are transit networks. When a router gets a packet from one of its interfaces, it has no way of knowing whether that packet originated on the local network, or was forwarded on by some other router... possibly from an original source a dozen network hops away.
Doesn't routing work "both ways" so to speak?
Um, "both ways"? No, not really, if you mean what I think you mean. I think you're saying that, if a router receives a packet claiming to be from host A, and that packet doesn't come from the direction of host A, as defined by the direction in which the router itself would send a packet which was destined for host A, it should drop the packet. The problem with that is that, if host A sends a packet to host B, there's no guarantee that the path that packet takes is the same as the path a packet would take from host B to host A. It usually is, but not always. Transient routing assymetries are very common in routing protocols, and it's possible, and even occasionally useful, to set up networks where there are permanent asymmetries. It's a pretty basic part of the architecture of IP networks that routers forward based only on destination addresses. Changing this would break a lot of existing systems. Keeping both "to" and "from" route information for each destination would entail redesigning all the routing protocols now in use, as well as doubling the associated memory and computation requirements. It won't happen soon, if ever. It may happen that router vendors will start adding configurable options to discard suspicious packets in the (pretty common) case where routing is expected to be symmetric. Such options would have to be used with great care, by network administrators who were very sure they knew what they were doing. They couldn't be made the defaults without breaking the universe, so there'd always be people who should turn them on, but wouldn't. As it stands today, it's possibly to manually configure a router to reject packets that don't come from addresses expected on the interface the packets arrive on. Such filters are entirely static, and don't respond to changes in the network. It's reasonable to set them up on a "stub" link that forms the only path leading to a reasonably well-defined segment of the network... like a LAN, or a small site. It's much less reasonable on a router in the middle of a complex network, and more or less impossible in Internet "core" routers... unless you can anticipate every possible dynamic network change, your filters are going to get it wrong sometimes. Myself, I always configure routers to filter out bogus source addresses... when they're being installed at points in the network where it's obvious which addresses those are. Most ISPs don't do it even when it's easy, and that's one of the sources of the problem. -- John B.
John Bashinski wrote: | > Well IPSec provides for authentication of endpoints which would | > identify the syn attacker. | | Only if the attacker were so stupid as to put in valid authentication | data identifying herself. | | I think IPSEC would allow you to throw away the SYNs without processing | them and without putting anything in your incoming connection queue. On the | other hand, you'd have to do all the authentication protocol and | computation for each packet in order to determine that it was bogus. I can | see where that could lead to a still worse denial-of-service attack if your | IPSEC code wasn't properly written. This is not correct. IPsec requires key negotiation, which takes place as or after a connection starts. (Photuris has a system where a new connection requires a cookie be traded before any expensive works gets done. It does not avoid all work.) Peter DaSilva, in a posting to firewalls, suggested that routers turn on record route on packets with SYN set. My initial reaction, that the core doesn't have the CPU, and the leafs will never deploy, turns out to be wrong; the big providers can make it a condition of connecting to them that this be done, and the problem of non-existant return addresses substantially diminishes as soon as cisco releases the software. The core routers don't change, since they are busy; the leafs do, since they need to connect to the core. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
-----BEGIN PGP SIGNED MESSAGE----- On Mon, 16 Sep 1996, John F. Fricker wrote:
Well IPSec provides for authentication of endpoints which would identify the syn attacker.
What amazes me is that routers happily pass packets with foreign IP return addresses. I guess there is some valid utility to being able to originate a connection that actually goes somewhere else for intiating a many to many protocol. But I can't think of any practical application that would necessarily be that way.
So why do routers let packets leave local networks that do not appear to originate from said local network? Doesn't routing work "both ways" so to speak?
Probably the same reason that most routers let packets claiming to be from the local net through. Even those that do filter packets claiming to be from the local net don't have any real reason to block packets claiming to be from foreign addresses -- the administrators don't have anything to gain. It'll probably take some time before this is considered standard netiquette. - -- Mark PGP encrypted mail prefered. Key fingerprint = d61734f2800486ae6f79bfeb70f95348 http://www.voicenet.com/~markm/ -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQEVAwUBMj3WtizIPc7jvyFpAQFIaQf+LFurdJzTgysANF8KNutVkYPR/29jHHON Vf+2SBn71AYhuBbkwAuAyCr+MyI7T0+Cct6sDq/F6FotiI8fUid2HKmcvfdSBl7l dRdKRfeNVKrbwggx8cg+smgWlx47zmMKNYa5RO1q53xwKHUBrLjEB+FzpLXryAbJ 5fbg/0ujnqPejHDBdjeDGyebzE6FOr/2qjCpGZb9CU+2Df35VJde5sNuObLo/H1q mM70vPMsMzSiRkSzDTtnsJZJumOqMP92Q3KSSwtOre5D7Fxg9g9anpTxYmYQhBEs SqyKMOTluFUh1Uq+8cizqZ+zzc89cnM1+vUJKRe4TxvNxMY0JJ7CWQ== =yYoB -----END PGP SIGNATURE-----
participants (4)
-
Adam Shostack -
jfricker＠vertexgroup.com -
John Bashinski -
Mark M.