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?

-----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-----

> 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