Subject: Internet SYN Flooding, spoofing attacks

From: Bernie Volz <[email-masked]>
Date: Fri, 11 Feb 2000 14:40:15 -0500

Regarding the recent TCP SYN Flooding attacks, why aren't ALL ISPs
required to put filtering on their networks that PREVENTS packets with
invalid source addresses ever entering their infrastructure? If every
site connected to the Internet did this, spoofing would be much more
difficult because you couldn't do it. Sure, you could spoof an address
from YOUR network, but that's all. And guess what, it would be much
easier to track and thus to shut down the intrusions should they occur.

Thus ever edge router should have filter lists that prevent it
forwarding traffic out to the Internet (ISPs network) any packet that
does not have a source address that is valid from that site.

I would hope that lots of ISPs already do this. But, perhaps not.

- Bernie Volz
  Process Software

---

From: Randy Bush <[email-masked]>
Date: Fri, 11 Feb 2000 11:57:30 -0800

> invalid source addresses ever entering their infrastructure?

maybe you want to be reading the nanog mailing list, [email-masked], where
the problems with and tactics for this and other approaches are discussed.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 11 Feb 2000 11:57:30 -0800

randy

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 15:15:07 -0500

>invalid source addresses ever entering their infrastructure?

Because there is no "Internet Police", that's why.

>If every

Yes, this practice is documented in RFC2267.

>I would hope that lots of ISPs already do this. But, perhaps not.

I would hope so, too, but apparently many do not.

Thus, the problem at hand.

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 15:15:07 -0500

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 15:29:08 -0500

>the problems with and tactics for this and other approaches are discussed.

Let's point folks to:

  http://www.nanog.org/mailinglist.html

instead.

The last thing I want to see on the NANOG list is a bunch of
"subscribe me" messages.

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 15:29:08 -0500

Let's point folks to:

instead.

- paul

---

From: [email-masked]
Date: Fri, 11 Feb 2000 15:33:12 -0500

> site connected to the Internet did this, spoofing would be much more

See RFC2267.

The problem is that the IETF doesn't have the legal authority to beat ISP's
into submission on this one.  There's also the problem that many ISP's are
somewhat marginal in cluefulness, so things like RFC2267 tend to be of the
"preaching to the choir" variety.

Given that RFC2267 is over 2 years old now, what *do* you suggest the network
community at large do to motivate the sites that still haven't implemented it?

Would somebody be interested in running a BGP blackhole feed of prefixes
known not to be filtering, similar to the maps.vix.com feed for closing
off E-mail spam?  Perhaps if that became prevalent, ISPs would cleanup their
act when their legitimate users couldn't get anyplace because their ISP
wasn't filtering.

<As he dons his asbestos underwear> ;)

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: [email-masked]
Date: Fri, 11 Feb 2000 15:33:12 -0500

See RFC2267.

---

From: John Stracke <[email-masked]>
Date: Fri, 11 Feb 2000 15:45:09 -0500

> invalid source addresses ever entering their infrastructure?

That wouldn't help with the current version of the problem.  An attacker
sends out a virus or worm or something; when it's running on 10^5
machines, the attacker turns them loose on the target.  Each of the source
addresses is valid; each of the packets sent is innocuous in and of
itself.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |"Genius, Brain! But what if the dragon eats us?"|
[email-masked]|"That would alter our plans."                   |
\=================================================================/

---

From: John Stracke <[email-masked]>
Date: Fri, 11 Feb 2000 15:45:09 -0500

---

From: "Michael H. Warfield" <[email-masked]>
Date: Fri, 11 Feb 2000 16:17:54 -0500

> easier to track and thus to shut down the intrusions should they occur.

	Clue alert...

	The recent attacks were not TCP SYN Floods.

	Please check recent Bugtraq and Cert information regarding
Distributed DoS attacks.

	Further references:

http://xforce.iss.net/alerts/advise40.php3
http://www.cert.org/advisories/CA-2000-01.html
http://www.fbi.gov/nipc/trinoo.htm

	Detailed analysis of TFN (Tribe Flood Network), Trin00, and
Stacheldraht (Barbed Wire) are here:

http://staff.washington.edu/dittrich/misc/tfn.analysis
http://staff.washington.edu/dittrich/misc/trinoo.analysis
http://staff.washington.edu/dittrich/misc/stacheldraht.analysis

	Contrary to popular belief and the common press, TFN2K (Tribe
Flood Network 2000) also has Windows versions of the slave daemons
as well as Solaris and Linux versions.

	A lot of these attacks appeared to be SMURF style attacks and
TFN (Tribe Flood Network) and TFN2K have distributed smurf capabilities.

	This wasn't even close to being a TCP SYN flood.

	As far as spoofing goes, in their SMURF mode, the only spoofing
is the src_addr part of the ICMP echo that the slave systems send to
their LOCAL broadcast address.  That src_addr is the address of the
system being attacked by ICMP_ECHOREPLY packets that simply consume all
its bandwidth.  Check out the analysis.

	Anti spoofing entry filters would have been of zero effect.

> does not have a source address that is valid from that site.

	Would not have helped except maybe in some of the UDP attack
modes of the slaves.

>   Process Software

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  [email-masked]
  (The Mad Wizard)      |  (770) 331-2437   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

---

From: "Michael H. Warfield" <[email-masked]>
Date: Fri, 11 Feb 2000 16:17:54 -0500

Clue alert...

	Further references:

	Mike

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 16:35:18 -0500

>community at large do to motivate the sites that still haven't implemented it?

Do you think that if RFC2267 was advanced as a BCP that
it would carry more weight, and therefore more ISP's would
implement RFC2267-style filtering? Coupled with the latest
denial of service attacks?

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 16:35:18 -0500

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 16:49:08 -0500

>addresses is valid; each of the packets sent is innocuous in and of

Yes, it would certainly help.

It would allow the attacks to be traced back to the zombies (in
the case of these DDoS attacks), and the perpetrators to be traced
back and identified.

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 16:49:08 -0500

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 17:14:02 -0500

Steve,

That's simply propagating FUD, and I think that by
making such sweeping assumptions, you are doing the
Internet community a disservice.

Is RFC2267-style filtering a perfect solution for
every situation? No. Sure there are some scenarios
where it foo bars transit traffic, but in the larger
scheme of things, most dual-homed networks are not
providing transit.

Does it impact router performance? Perhaps. It really
depends on various arbitrary issues.

 From an architectural perspective, it is very important
_where_ you filter to be effective, not cause transit
problems, and not make smoke roll out of the back of
the equipment.

Will it stop bogon source packets from being injected into
the Internet, so that anyone foolish enough top launch a
denial of service attack can be traced back, identified, and
prosecuted? Absolutely.

- paul

At 04:59 PM 02/11/2000 -0500, Stephen Kent wrote:

>Paul & Bernie,
>
>A more technically focused answer is that most routers are not
>designed to perform the filtering without adversely impacting
>throughput, and because dual homing and the mesh nature of Internet
>connectivity makes it hard to apply appropriate filters for all
>subscribers (remembering that some subscribers are really down stream
>service providers ...)
>
>Steve
>

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 17:14:02 -0500

Steve,

- paul

---

From: [email-masked]
Date: Fri, 11 Feb 2000 17:24:04 -0500

> denial of service attacks?

On the one hand, I think it would make a good candidate for BCP.  It seems
to be similar in tone with RFCs 2502 and 2644.  I'd have to re-read it to
see if it would need any textual changes, or if it's OK as it is.

I was talking to a co-worker on this topic, and his exact quote was
"We have our s--t more together than most sites, despite our best
efforts".  The problem is that he was right - our site may have clue,
but there's a lot of uneducated sites out there.

Does anybody have statistics on how effective RFC2350 (Expectations
for Computer Security Incident Response) was?  Or RFC2502 (Anti-Spam
Recommendations for SMTP MTAs)? Or RFC2644 ( Changing the Default for
Directed Broadcasts in Routers)?  It would seem reasonable that moving
2267 to BCP should have a similar effectiveness...
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: [email-masked]
Date: Fri, 11 Feb 2000 17:24:04 -0500

---

From: Stephen Kent <[email-masked]>
Date: Fri, 11 Feb 2000 19:01:02 -0500

Paul,

I object to the characterization of my comments as "propagating FUD." 
One might equally well suggest that 2267 constitutes a naive model of 
how to prevent IP spoofing, but I was polite enough not to say that 
:-).

 From a security perspective, it is never desirable to rely on a 
mechanism that assumes that everyone else does "the right thing." 
When one suggests that a first tier ISP would not need to filter 
traffic from down stream providers, because IF they do the filtering, 
then the problem will not arise via those links, one is suggesting 
precisely this sort of model.

Edge filtering would often be helpful, but it is not a panacea, as 
pointed out by others in regard to the current set of attacks, nor is 
the performance impact trivial with most current routers. Because 
most routers are optimized for transit traffic forwarding, the 
ability to filter on the interface cards is limited, as I'm sure you 
know.  Also, several of the distributed DoS attacks we are seeing do 
not use fake source addresses from other sites, so simple filtering 
of the sort proposed in 2267 would not be effective in these cases.

Finally, I am aware of new routers for which this sort of filtering 
would be child's play, but they are not yet deployed.  One ought not 
suggest that edge filtering is not being applied simply because of 
laziness on the part of ISPs.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 11 Feb 2000 19:01:02 -0500

Paul,

Steve

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 20:02:44 -0500

Steve,

>mechanism that assumes that everyone else does "the right thing."

I agree. Every potential target network is not only responsible
for their own security, but in my opinion, they should be
conscientiously motivated to do the Right Things for the Internet
community at-large.

Of course, it doesn't always work out that way, sadly, and I'm not
delusional that it does.

>precisely this sort of model.

You're approaching this from the wrong perspective, in my opinion.

There is no assumption implied that RFC2267 filtering is needed --
it is required. What good is it if one or two or 300 people do
it, and another 157,000 do not?

Well, there is a little good, but the more people that do it, the
better off we all are.

The bottom line here is that RFC2267-style filtering (or unicast
RPF checks, or what have you) stops spoofed source address packets
from being transmitted into the Internet from places they have no
business being originated from to begin with.

In even the worst case, those conscientious network admins that
_do_ do it can say without remorse that they are doing their part,
and can at least be assured that DoS attacks using spoofed source
addresses are not being originated from their customer base.

And this is a Bad Thing?

>the performance impact trivial with most current routers.

It is negligible at the edge in most cases, but you really need to
define "edge" a little better. In some cases, it is very low speed
links, in others it is an OC-12.

>Because
>know.

No, I don't know that at all. _Backbone_routers_ are optimized for
packet forwarding -- I do know that.

>  Also, several of the distributed DoS attacks we are seeing do

Again, you're missing the point.

If attackers are limited to launching DoS attacks using traceable
addresses, then not only can their zombies be traced & found, but
so can their controller (the perpetrator himself). Of this, make no
mistake.

>laziness on the part of ISPs.

Steve, you said that -- I didn't. I think ISP's will do what their
customers pay them to do.

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 20:02:44 -0500

Steve,

And this is a Bad Thing?

- paul

---

From: Vijay Gill <[email-masked]>
Date: Fri, 11 Feb 2000 21:01:03 -0500 (EST)

CC'd to NANOG, maybe we can move this there.

> the case of these DDoS attacks), and the perpetrators to be traced

To make that easier, what is needed is something associated with a
downstream interface that is a part of the configuration itself, not a
separate access-list.  This makes it much easier to track on a large box
with many hundreds of customer links and so forth.

Something like so:

interface XXXm/n/p.q
description whatever customer
encaps ...
ip address x y
ip allow-source blocks-that-are-valid
ip allow-source ...more-blocks-

so on and so forth.

/vijay

---

From: Vijay Gill <[email-masked]>
Date: Fri, 11 Feb 2000 21:01:03 -0500 (EST)

Something like so:

interface XXXm/n/p.q

so on and so forth.

/vijay

---

From: Daniel Senie <[email-masked]>
Date: Fri, 11 Feb 2000 21:01:34 -0500

> 2267 to BCP should have a similar effectiveness...

Ever since Paul and I wrote 2267, I've heard from ISPs and equipment
vendors, letting me know they'd implemented our recommendations. Lots of
folks are doing it because they understand they should do their part.

As for 2644, that one has only been out there a short time. It's not
clear how many people have noticed it yet. This document has two target
audiences, vendors and ISPs/users.

Some vendors made the change even before I wrote the document.  Router
Requirements (1812) have mandated devices have an on/off switch for this
feature for a long time. I would hope that all manufacturers at least
provided the config option. I hope the vendors who haven't changed their
defaults will get to this soon.

Many clueful network operators also took the time to ensure their
networks were clean. The problem with directed broadcasts is that EVERY
routing device really has to be checked, since with CIDR you really
don't know what comprises a broadcast. Network operators, especially,
need to spend the time to check the configurations on their equipment.
Awareness of this issue needs to be raised. As with ingress filtering,
everyone needs to do their part. Unfortunately, it may be threats of
negligence lawsuits that ultimately motivates some to take heed.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.            http://www.amaranthnetworks.com

---

From: Daniel Senie <[email-masked]>
Date: Fri, 11 Feb 2000 21:01:34 -0500

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 21:09:47 -0500

Vijay,

We (at least cisco, anyways) already have a knob for this:

  [no] ip verify unicast reverse-path

We call it Unicast RPF.

See also:

Craig Huegen's very useful web page on minimizing the effects
of DoS attacks:
http://users.quadrunner.com/chuegen/smurf.cgi

Cisco: Distributed Denial of Service (DDoS) News Flash,
February 9, 2000
http://www.cisco.com/warp/public/707/newsflash.html

Dave Dittrich's (University of Washington) very good
analysis of the recent DDoS attack tools.
http://www.washington.edu/People/dad/

NIPC (National Infrstructure Protection Center),
TRINOO/Tribal Flood Net/tfn2k stuff:
http://www.fbi.gov/nipc/trinoo.htm

"Handling A Distributed Denial of Service Trojan
Infection: Step-by-Step."
http://www.sans.org/y2k/DDoS.htm

CERT (Computer Emergency Response Team at CMU)
http://www.cert.org/

Cisco: Internet Security Advisories
http://www.cisco.com/warp/public/707/advisory.html

Characterizing and Tracing Packet Floods Using
Cisco Routers
http://www.cisco.com/warp/public/707/22.html

Cisco Product Security Incident Response (PSIRT)
http://www.cisco.com/warp/public/707/sec_incident_response.shtml

"Essential IOS" - Features Every ISP Should Consider
http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip

Know your enemy: Script Kiddies
http://www.enteract.com/~lspitz/enemy.html

Cisco Flow Logs and Intrusion Detection at the Ohio
State University
http://www.usenix.org/publications/login/1999-9/osu.html

If anyone else has useful links (it doesn't matter who
is the vendor, whatever), please let me know.

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 21:09:47 -0500

Vijay,

We call it Unicast RPF.

See also:

- paul

---

From: Vijay Gill <[email-masked]>
Date: Fri, 11 Feb 2000 21:14:08 -0500 (EST)

>   [no] ip verify unicast reverse-path

This only works on single homed customers. Due to asymmetric routing, the
customer can source _valid_ ip addresses from an ip source address that is
not routed over that interface.  I too would prefer some sort of magic
unicast RPF, but the best compromise is the built-in access filter.  The
solution must be general enough to work for multihomed, defaulting out
customers with blocks from n providers,

/vijay

> >ip allow-source ...more-blocks-

Vijay Gill                         |The (paying) customer is always right.
[email-masked], [email-masked]  |                  - Piercarlo Grandi
http://www.gl.umbc.edu/~vijay      | Eagles may soar, but weasels don't get
These are my opinions only.        | sucked into jet engines.

---

From: Vijay Gill <[email-masked]>
Date: Fri, 11 Feb 2000 21:14:08 -0500 (EST)

/vijay

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 21:19:09 -0500

>customers with blocks from n providers,

No, that is a common misconception, or rather, an overstatement of
a pretty easily described situation. It only breaks things in transit
situations, and only in transit situations where you might not have
the same forwarding path back to the source as you would via the same
interface a packet came in on.

This is a small percentage, I would thing, since the percentage of
ISP's offering transit pales in comparison to all other "access"
ISP's that do not. And in cases where ISP's _do_ offer transit, or
have transit agreements, will they really do this on their transit
interfaces? I think not.

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Fri, 11 Feb 2000 21:19:09 -0500

- paul

---

From: [email-masked]
Date: Fri, 11 Feb 2000 23:33:14 -0500

>   [no] ip verify unicast reverse-path

Paul:

What are the chances of setting up "The Next Release" of IOS
so that for simple configs (for example, a customer backbone and
one upstream link to a provider) the knob would automagically default
to Doing The Right Thing?  I of course am writing as a non-expert on
the innnards of IOS, and I'm expecting flame-fests regarding "simple
config" and "Right Thing".

No, it's not a total fix.  It won't fix everything.  It may not
even be possible.  But it certainly would be nice. ;)

				Valdis Kletnieks

---

From: [email-masked]
Date: Fri, 11 Feb 2000 23:33:14 -0500

Paul:

				Valdis Kletnieks

---

From: Paul Ferguson <[email-masked]>
Date: Sat, 12 Feb 2000 00:16:14 -0500

>even be possible.  But it certainly would be nice. ;)

Something like "ip default clueless"? Just kidding. ;-)

Well, overwhelming support for any suggested default mod is
always considered. Really.

Overwhelming is the operative word here.

We (as do many other vendors, I would suggest) operate
under the "Principle of Least Astonishment": How many people
would we screw if we changed the defaults of a particular
command?

If overwhelming community support were to set the tone for a default
change, we would certainly not take it lightly. :-)

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Sat, 12 Feb 2000 00:16:14 -0500

- paul

---

From: Mark Prior <[email-masked]>
Date: Sat, 12 Feb 2000 23:18:54 +1030

We call it Unicast RPF.

And its well documented... NOT
and available on all routers/interfaces... NOT

If it was documented and available on things like PRIs then it would
be a lot easier to deploy. Also some of the bugs that turn off CEF
need to be addressed (or at least also cause "ip verify unicast
reverse-path" to be turned off too).

Mark.

---

From: Mark Prior <[email-masked]>
Date: Sat, 12 Feb 2000 23:18:54 +1030

We call it Unicast RPF.

Mark.

---

From: Mark Prior <[email-masked]>
Date: Sat, 12 Feb 2000 23:20:28 +1030

Maybe not as small as you think when simplex satellite is involved.

Mark.

---

From: Mark Prior <[email-masked]>
Date: Sat, 12 Feb 2000 23:20:28 +1030

Mark.

---

From: Stephen Kent <[email-masked]>
Date: Sat, 12 Feb 2000 16:33:59 -0500

Paul,

>addresses are not being originated from their customer base.

it is a bad thing if one bases defenses on the assumption that ALL 
the access points into the Internet will perform such filtering, and 
will do it consistently.  Even if all ISPs, and down stream providers 
performed the filtering, there is no guarantee that attackers could 
not circumvent the filter controls, either through direct attack on 
the routers, or through indirect attack on the management stations 
used to configure them.  I'm just saying that while edge filtering is 
potentially useful, it would not be a good idea to assume that it 
will be effective.

>links, in others it is an OC-12.

In talking with the operations folks at GTE-I, they expressed concern 
over the performance hit for many of their edge routers, based on the 
number of subscribers involved and other configuration 
characteristics.

>packet forwarding -- I do know that.

I would state that devices that examine IP headers and make routing 
decisions entirely on interface cards are optimized for traffic 
forwarding, vs. firewall-style devices that focus on header 
examination and ACL checking, and which typically do this by passing 
a packet through a general purpose processor, vs. in I/O interfaces. 
But, these are just generalizations.

>so can their controller (the perpetrator himself). Of this, make no

Not necessarily. The traffic from a controller to the clients may be 
sufficiently offset in time as to make tracing back to the controller 
hard.  I agree that tracing to the traffic sources (or at least to 
the sites where the traffic sources are) would be easier if edge 
filtering were in place, and if it were not compromised.

>customers pay them to do.

ISPs do what they perceive is appropriate to maintain and gain market 
share, consistent with their cost models and router product 
availability. Different ISPs have different ideas of how to deploy 
routers and switches to aggregate traffic, which are driven by their 
traffic models, by economics, and by vendors.

Note that this is an international problem, not just a domestic one. 
Our operations folks tell me that many attacks are traceable to 
foreign sources, where the ability to ensure adherence to policies 
such as edge filtering is rather difficult.  Also, from a national 
security perspective, one would hardly rely on other countries 
enforcing such policies in their ISP domains.  That's why I think the 
best, long term approach to these problems requires a combination of 
improved host security and monitoring for attacks near the hosts 
(both appropriate measures when the hosts are servers with a vested 
interest in maintaining availability), plus rapid, automated response 
to detected attacks, and an ability to activate and adjust filters at 
all ISP interfaces, not just at subscriber interfaces.  This 
combination of measures does not rely on every ISP in the world doing 
the right thing, although it would benefit from such behavior.  It 
embodies a notion of self-protection, both at the subscriber and ISP 
levels, in support of the principle of least privilege.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Sat, 12 Feb 2000 16:33:59 -0500

Paul,

Steve

---

From: "Perry E. Metzger" <[email-masked]>
Date: 13 Feb 2000 19:14:42 -0500

> community at large do to motivate the sites that still haven't

I think a simple motivation is appearing on the horizon. Lawyers are
revving up their word processors as we speak. I mean, here are all
these nice, deep-pocketed public companies that aren't taking an
action they fully know could reduce risk for third parties, and even
saying in public how it costs too much. Can you say "negligence suit
nirvana"? I knew you could.

As much as I hate the lawsharks, every once in a while they do some
good in motivating change.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 13 Feb 2000 19:14:42 -0500

Perry

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Mon, 14 Feb 2000 00:37:29 -0500

I think that making egress filtering a BCP, applying community
pressure, bringing law suites, etc., will be about as effective
at eliminating forged source address packets on the Internet as
similar measures have been in eliminating open SMTP relays...

They help, but not much.

Donald

From:  Paul Ferguson <[email-masked]>
Message-Id:  <[email-masked]>
Date:  Fri, 11 Feb 2000 16:35:18 -0500
To:  [email-masked]
Cc:  [email-masked]
In-Reply-To:  <[email-masked]>
References:  <Your message of "Fri, 11 Feb 2000 14:40:15 EST." <009E5826.5FC1D447.198
@process.com>
	     <[email-masked]>

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Mon, 14 Feb 2000 00:37:29 -0500

They help, but not much.

Donald

---

From: Robert Elz <[email-masked]>
Date: Mon, 14 Feb 2000 22:05:07 +1100

Date:        Mon, 14 Feb 2000 00:37:29 -0500
    From:        "Donald E. Eastlake 3rd" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think that making egress filtering a BCP, applying community
  | pressure, bringing law suites, etc., will be about as effective
  | at eliminating forged source address packets on the Internet as
  | similar measures have been in eliminating open SMTP relays...
  | 
  | They help, but not much.

I'm not sure there is a good analogy there.    There's no good purpose
in sending packets with incorrect source addresses I can think of, and
stopping the practice is the basic intent of the filters.  The only
justification for not doing it is cost - and then just just becomes a
part of the cost benefit analysis - will it cost us more or less to
implement this?

On the other hand, SMTP relays are not a problem anyone cares about of
themselves - just the contrary in fact, smtp relaying can be a very useful
function to have available (eg: you're travelling with your laptop
and have a bunch of mail waiting to go - you get a connection for a
few minutes between flights, but your normal home relay is unreachable
right now - being able to pick some other friendly relay and simply park
your mail on it can be a real advantage).   The thing to be fixed there
is the unwanted spam that is also using the services of the relay, that
is, it isn't the relay that is really the issue, it is the spam, if all
the spam went away, so-one would care about relays any more (other than now
to regret that whereas previously most sites would be happy to relay mail
now far fewer are).

Further, it isn't at all clear that preventing relaying will do much,
if anything, to stop spam - certainly blocking receiving mail from relays
will currently cut the amount of spam you receive a lot - but that's
because comparatively few people do that, and so the spammers are content
to ignore them and just continue making use of the relay services that
they can latch onto.   But should everyone stop relaying, does anyone really
believe that all the spammers are simply going to decide that there is
no point continuing, and all just go away?   Really?   Even if it means
that the spammers have to send all their mail directly, they'll do it
as long as the benefit from sending spam (at least appears to) outweigh
the costs.

So, the two issues are really not much alike - in one there's no good
purpose to be served by not blocking outgoing packets with bogus source
addresses, in the other there are lots of philosphical reasons for
not stopping relaying - hence there are some of us quite willing to do one
but not the other.

Spam is a social problem, and needs to be solved by social/legal means,
not technical ones (there is no technical difference between spam and
any other mailing list mail - it all looks the same - the only difference
is whether the recipient wanted to receive it or not.)  But we're
technocraats, all our tools are technical ones, so it is easy to see
how we grasp at any technical solution we think might help - the only
technical solution we've been able to find that seems like it might help
(a passing illusion really).  Unfortunately, the appearance of a technical
solution reduces the pressure on the social/legal types to come up with
a solution that really works - if we all would just admit that technically
there's nothing that can really be done ablut spam, and simply stopped
trying at all (allow it all through) the user pressure to get this
problem solved some other way would be much much greater...   On the other
hand, sending packets with an incorrect source address is a technical
problem - those packets don't meet the IP specs - what is supposed to be
in that field is the IP address of the sending node.   This is a problem
entirely open to a technical solution.

kre

---

From: Robert Elz <[email-masked]>
Date: Mon, 14 Feb 2000 22:05:07 +1100

kre

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 14 Feb 2000 15:41:09 -0800

Robert Elz wrote:

>                                             There's no good purpose
> stopping the practice is the basic intent of the filters.

Mobile IP would like to send out packets with the mobile node's
home address, while it is attached to a network in a foreign
domain.  The home address is likely to look "incorrect" from
the standpoint of such a filter.

Plus I don't think the gain is worth the pain.  I'd rather see
a technology that actually solves the problem instead of swatting
at gnats with a sledge hammer.

What if routers could preferentially keep track of things like SYN
packets and so on for a few seconds, and we had some traceback management
software and security associations with our neighbors enough to do
some automatic detection?

It might cost 2% more for the memory buffers, geez I don't know.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 14 Feb 2000 15:41:09 -0800

Regards,
Charlie P.

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 14 Feb 2000 19:22:45 -0500

>the standpoint of such a filter.

If I'm not mistaken (although my coauthor has tracked the mobile
ip cruft more than have I), there is some notion of a tunneling
mechanism from the first-hop mobile ip gateway, such that the
bogon source is really never seen in that fashion (as a bogon).

Again, I admit complete ignorance of mobile ip cruft.

>at gnats with a sledge hammer.

Well, right now, you get swatted. Figure out a better way, and
you'll stop getting swatted.

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 14 Feb 2000 19:22:45 -0500

- paul

---

From: Daniel Senie <[email-masked]>
Date: Mon, 14 Feb 2000 21:57:26 -0500

> the standpoint of such a filter.

Mobile IP took advantage of a convenient occurrence of the Internet as
it was, believing all routing would occur based on destination address
only. That is no longer a valid assumption. In response to this changing
world, the Mobile IP folks went back to the drawing board and created
RFC 2344. I suggest folks go implement it. Tunnels are the topologially
correct answer when you're trying to do something like Mobile IP.

Mobile IP also took advantage of directed broadcast in the original
designs, though it is less clear whether anyone actually implemented
using it. See the discussion on this topic in RFC 2644 for more details
on that.

> at gnats with a sledge hammer.

Routing based on source and destination address in combination is
already a possible approach for traffic shaping and firewalling
purposes.

> some automatic detection?

So, you'd prefer to have the routers on the Internet be stateful
devices? Somehow, I thought we really didn't want to go there. There are
known issues with some equipment which does fast switching based on
setting up "flows." A design that several folks have come up with relies
on a general purpose processor to program "flow" information into a
silicon-assisted fabric. Such implementations suffer greatly at the
hands of a DoS attack, where flows are coming in at extremely high rate.
State isn't necessarily the answer.

> It might cost 2% more for the memory buffers, geez I don't know.

The memory cost isn't the issue. You're going to pay more for a lot of
ASICs to be doing that operation at wire speed. The work to do what you
suggest adds considerably more complexity than doing filtering at wire
speeds in ASICs (a capability which is available on products shipping
today).

---

From: Daniel Senie <[email-masked]>
Date: Mon, 14 Feb 2000 21:57:26 -0500