Subject: Re: Internet SYN Flooding, spoofing attacks

From: "Anders Feder" <[email-masked]>
Date: Mon, 14 Feb 2000 22:50:19 +0100

Robert Elz <[email-masked]> wrote:
>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.

"In his early days at Intel, Andy Grove was approached by an employee who
suggested the company start work on a personal computer based on its chips.
Skeptical, he asked what a personal computer might do. The employee,
searching for a good example, said it could be used to store recipes. Grove
thought about the millions he'd have to spend on research, development, and
marketing, then considered the imperfect but steady quality of an
alphabetized loose-leaf binder. He finally passed on the idea and decided to
concentrate on the lucrative business of supplying chips for traffic
lights."

It is rarely very easy to see what requirements the future will bring and
particularly in this business you can't be sure what the technology of
tomorrow demands. And, agreed,  bogus source IPs _does_ at present time
look like nothing but the devils work. But in, say, 10 years a new flashy
techology could be requiring that you have the ability to stamp packets with
other IPs than your own. Unfortunately, back in year 2000, somebody put in
IP filters at all ISPs and now, 10 years after, these filters is so
integrated a part
of the ISP software that reprogramming would cost a fortune.
Also consider the size of the group of Internet users that send out packets
with incorrect source IPs. Using IP filters would be like illegalizing
coffee because a fraction of the people on the earth is allergic to
caffeine.

- Anders Feder

---

From: Phil Karn <[email-masked]>
Date: Mon, 14 Feb 2000 16:04:28 -0800 (PST)

>other IPs than your own. Unfortunately, back in year 2000, somebody put in

There already are some perfectly legitimate reasons to send packets
with "alien" IP source addresses. Mobile IP is the best example, but
various virtual private networking schemes also do this. For example,
I have a VPN set up over my cable modem so I can have a block of
static IP addresses for my home network. I had to do some work to
evade the $#@!! source IP address ingress filtering in my cable
network. I do it by tunneling the upstream packets through a machine
at work.

Being forced to tunnel not only increases the size of each packet, but
also entails suboptimum routing and reliance on yet more network
elements.  I use the new Linux policy routing mechanisms to tunnel
only those packets that have to be tunneled, which helps. But it would
sure be nice if I didn't have to tunnel my outbound packets at all.

Source address ingress filtering is one of those ideas that seems like
a good one when you first think about it, but it just doesn't pan out.
It interferes with some perfectly legitimate activities, it doesn't
really stop the bad guys, and it deflects attention away from the real
solutions.

In the case of MS-DOS (Multiple Source-Denial of Service) attacks like
the ones we saw last week, we need to deploy better inter-router
mechanisms to deal with congestion by moving the packet drop points as
far upstream as possible toward the senders. And if these mechanisms
can work for deliberate flooding attacks, they'll also deal with
non-deliberate congestion.

Phil

---

From: Phil Karn <[email-masked]>
Date: Mon, 14 Feb 2000 16:04:28 -0800 (PST)

Phil

---

From: Daniel Senie <[email-masked]>
Date: Mon, 14 Feb 2000 22:05:12 -0500

> network. I do it by tunneling the upstream packets through a machine

Yes, and you chose the CORRECT solution. Think about it... VPN in most
cases also means encryption, and at that probably back to a central
site.

Gabriel wrote RFC 2344 for reverse tunnels, and it does essentially what
you did.

> sure be nice if I didn't have to tunnel my outbound packets at all.

Sorry. You're at the point where technology meets policy. Fact is, your
host identifier in the IP stack is the source IP address. Enforcing the
validity of that identifier has become necessary.

> really stop the bad guys, and it deflects attention away from the real

The case for "legitimate use" of source spoofing has not been
sufficiently made. Operational reality is such that it's not
sustainable.

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

---

From: Daniel Senie <[email-masked]>
Date: Mon, 14 Feb 2000 22:05:12 -0500

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 15 Feb 2000 11:15:25 +0000 (GMT)

On Mon, 14 Feb 2000, Anders Feder wrote:

> >in sending packets with incorrect source addresses I can think of,

Crypto- and security-related, I should think. Randomising the source
address makes tracking the existence of communications between a given
source and a given destination that much harder; they know who they're
talking to based on encrypted message content, but no-one else has to.

A lot of surveillance can be based on 'if A is talking to B, then A
must be as guilty as B', and message content is irrelevant. This
helps counters that.

(This is vaguely analogous to OpenBSD using non-sequential packet IDs,
yes? Bet it's not in IPSEC.)

> tomorrow demands.

Indeed.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 15 Feb 2000 11:15:25 +0000 (GMT)

Indeed.

L.

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 15 Feb 2000 06:52:19 -0500

>must be as guilty as B', and message content is irrelevant. This

Well, get over it. ;-)

(Smiley included for the humor impaired.)

- paul

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 15 Feb 2000 06:52:19 -0500

Well, get over it. ;-)

- paul

---

From: John Hawkinson <[email-masked]>
Date: Tue, 15 Feb 2000 10:17:28 -0500

> From: Daniel Senie <[email-masked]>
> Phil Karn wrote:

...

> validity of that identifier has become necessary.

The correct "solution" here is for Phil to communicate with his
provider who presently does ingress filtering and notify them that he
is sourcing packets from a particular set of source addresses (because
of tunneling), and request they add these to the ingress filter list.

I think we recognize this may be politically infeasable for many
people to do, because tunneling is often used to circumvent
administrative restrictions, but that really is a different degree of
the problem.

More generally:

It seems to me that there has been a lot of wasted discussion on this
list on this topic. I think it is a well-accepted conclusion within
the provider community that ingress filtering is a necessary thing
(perhaps a "necessary evil" to some, perhaps a "good" to others).  In
the vast majority of cases, the router CPU resource consumption issues
are not relevent, either.

If people within the IETF feel differently, they should realize that
they are currently against recently-accepted-operational-practice.

I don't think everyone who has to date spoken is aware of that.

--jhawk

---

From: John Hawkinson <[email-masked]>
Date: Tue, 15 Feb 2000 10:17:28 -0500

...

More generally:

--jhawk

---

From: [email-masked]
Date: Tue, 15 Feb 2000 11:50:38 -0500

> really stop the bad guys, and it deflects attention away from the real

Well.. as soon as somebody presents us with "the real solution", we'll start
implementing.  In the meantime, filtering is the best we know how to do.

> non-deliberate congestion.

The problem here is that there is often a limit to how far away you
can move the detection.  In the case of multiple sources, it's
*probable* that the inbound packets will arrive on as many as 5 to 20
different links, and not get aggregated onto one path until the
last-hop link to the victim's site.

And if you have 20 inbound links into a routing swamp, each one will
only see a 5% fluctiation in load in order to cause a 100% congestion
on the victim link.  If you move the detection 2 hops out, you may be
trying to spot a 1% ripple in the traffic, if there's 100 different
paths that far out.

The more hops you try to move the detection away, the smaller the
"ripple" you need to be able to detect *without a high rate of false
positives*.

There's another issue, in that if you're trying to do this 2-3 hops
out, you will need *secure* *low-bandwidth* communications regarding
who is talking to whom, at what rates.  And you get transitivity
problems - some of our border routers are 3 hops from a vBNS gateway,
and therefor would need to talk to them, plus are 3 hops from other
routers that are probably NOT going to want the vBNS information.  So
you end up with a ugly mess of many overlapping "circles" containing
different subsets of routers.  This gets you into key management
issues, and the like....

I'm sure there's other issues that need to be solved as well, these are
just the first few problems that come to mind...

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

P.S.  Please note that MS-DOS is the trademark of a *SINGLE*-source vendor
of denial of service ;)

---

From: [email-masked]
Date: Tue, 15 Feb 2000 11:50:38 -0500

---

From: Phil Karn <[email-masked]>
Date: Wed, 16 Feb 2000 18:02:38 -0800

>cases also means encryption, and at that probably back to a central

Yes, I often use encryption, but not to a central site. Generally I
apply it at the application layer (SSH/SSL) so the peer is whoever I happen
to be talking to. However, this is irrelevant to the issue of upstream
IP address filtering.

>validity of that identifier has become necessary.

This makes no sense at all. I've shown both that there are legitimate
reasons to send packets that the ISP might consider "alien", and also
how easy it is to circumvent ingress filtering if you are so motivated.

By the way, ingress filtering breaks things other than Mobile IP.
Consider the DirecPC service, which gives you a one-way (forward)
satellite channel at 400 kb/s. Your return link is via local dialup
service provider. If the local ISP (or its upstream provider) does
source filtering, you can't send your perfectly legitimate packets
into the network over that ISP without tunneling them all through
DirecPC's own network connection, which may be on the other side of
the continent.

>sufficiently made. Operational reality is such that it's not

The operational reality is that you'll never be able to implement
ingress filtering widely enough to provide much of a benefit. Even if
you do, it'll be circumventable (consider the many Linux and Unix
boxes out there that support IP-in-IP tunneling). And the energy you
spend doing so will be energy that could have been better spent
implementing other mechanisms to defend the Internet against MS-DOS
(multiple source denial of service) attacks.

Phil

---

From: Phil Karn <[email-masked]>
Date: Wed, 16 Feb 2000 18:02:38 -0800

Phil

---

From: Phil Karn <[email-masked]>
Date: Wed, 16 Feb 2000 18:20:43 -0800

>administrative restrictions, but that really is a different degree of

Bingo. I tunnel because my cable modem provider requires residential
users to use DHCP to get IP addresses that can change at any time.  If
you want a static IP address, or additional IP addresses, you must pay
a considerable premium.

It's not because fixed addresses actually cost them more. Indeed,
another cable modem provider in the other part of town allocates fixed
addresses in an otherwise identical service that's $5/mo cheaper. No,
my provider does it simply because they can. They're a monopoly in
their service area.  Even if I could find somebody at their help desk
who understood a request to open up their filter to my own IP addresses,
they would have no incentive to do so.

This all boils down to a basic issue of who controls the Internet
address space -- the users, or the monopolies who have long controlled
the Internet's underlying transmission media and who are now moving up
the stack to aggressively control the IP layer and are imposing
restrictions on the content of their user's traffic.

Fortunately, secure tunneling protocols will always make it possible
for knowledgeable users to overcome these administrative restrictions
and to keep the carriers down at the physical level where they belong,
albeit with a loss in efficiency.

The question, then, is not whether users will be able to send packets
with arbitrary source addresses. They will. The question is whether we
get rid of the inefficiencies associated with a failed attempt to keep
them from doing so, and redirect our energies to better alternatives
for dealing with denial of service attacks.

Phil

---

From: Phil Karn <[email-masked]>
Date: Wed, 16 Feb 2000 18:20:43 -0800

Phil

---

From: Robert Elz <[email-masked]>
Date: Thu, 17 Feb 2000 14:59:59 +1100

Date:        Wed, 16 Feb 2000 18:20:43 -0800
    From:        Phil Karn <[email-masked]>
    Message-ID:  <[email-masked]>

  | Even if I could find somebody at their help desk
  | who understood a request to open up their filter to my own IP addresses,
  | they would have no incentive to do so.

In an earlier message you just told us that ingress filtering would
never become widespread enough to really matter - but it seems to
have managed to trap you...

  | This all boils down to a basic issue of who controls the Internet
  | address space -- the users, or the monopolies who have long controlled

The address space is controlled by the routing system - that's
what the addresses are for.

  | Fortunately, secure tunneling protocols will always make it possible
  | for knowledgeable users to overcome these administrative restrictions
  | and to keep the carriers down at the physical level where they belong,
  | albeit with a loss in efficiency.

Well not always - it is possible to imagine an ISP that only permits
connections via their proxies, and blocks everything else.  They could
even market it as a "premium extra secure internet service - no nasty
packets from outside will ever reach your system" ...

But aside from that nonsense, tunneling is not a problem for ingres
filtering, it isn't defeating it (or not its purpose) at all.
To tunnel, you need a remote tunnel endpoint - and then you can only
send source addresses through the tunnel (and from there to the
universe) with addresses from the remote-endpoint's address range
(assuming ingress filtering is being done there as well).

That's all fine then, you're just acting as if you were a node
at their location (which is the point, more or less), and packets
you send that way are attributed to them, just the same as any
other packet sent from there.

If some site is willing to decapsulate packets from any random source
and forward them, then they take the heat for any packets that are
sent that way.

kre

---

From: Robert Elz <[email-masked]>
Date: Thu, 17 Feb 2000 14:59:59 +1100

kre

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 17 Feb 2000 12:42:04 +0000 (GMT)

> restrictions on the content of their user's traffic.

There is no longer a single Internet address space.

We're going to have to start calling it the InterNAT.

L.

Hey, that means the Internet is InterNATional.

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 17 Feb 2000 12:42:04 +0000 (GMT)

L.

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 17 Feb 2000 09:02:35 +0000

>they would have no incentive to do so.

Phil,

The other cable provider in the other part of town also has Source IP
Address filters in place.  The cost of not having such filters is
too high to bear at our prices (and thin margin).  The vast majority
of users are comfortable with this.    As near as I can tell, most ISPs
(whether dialup, ISDN, DSL, or Cable) have Source IP Address filters in
place for the same reasons (i.e. controlling operational cost).

I am with those who thing that an encrypted VPN tunnel is the right answer 
to the telecommuter problem you've outlined, btw.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 17 Feb 2000 09:02:35 +0000

Phil,

Ran
[email-masked]

---

From: "Dick St.Peters" <[email-masked]>
Date: Thu, 17 Feb 2000 12:25:39 -0500 (EST)

> DirecPC's own network connection, which may be on the other side of

Filtering does not break my users' DirecPC.

It also does not break their VPN.

It does keep a lot of martian packets off my network, and in several
instances it has blocked spoofed-source-IP DoS attempts by my users.

--
Dick St.Peters, [email-masked] 
Gatekeeper, NetHeaven, Saratoga Springs, NY
Saratoga/Albany/Amsterdam/BoltonLanding/Cobleskill/Greenwich/
GlensFalls/LakePlacid/NorthCreek/Plattsburgh/...
    Oldest Internet service based in the Adirondack-Albany region

---

From: "Dick St.Peters" <[email-masked]>
Date: Thu, 17 Feb 2000 12:25:39 -0500 (EST)