Ed,
I have seen over the past years many knee-jerk reactions to attacks that
essentially followed the model you are describing. An example is to cut
ICMP because it is used in some attacks; the proposal to "verify unicast
reverse-path" is another. The problem is that a number of these defenses
amount to cutting your nose in order to cure the common cold. For
example, cutting ICMP also suppresses efficient path MTU discovery;
random reverse path verification kills multi-homing and makes mobility
much harder. This is compelled by the evolutionary nature of the
attacks: many of the ICMP attacks can be replicated over UDP, and thus
you find sites cutting UDP as well -- and here goes voice over IP; in
fact, I could also mount attacks by sending TCP packets outside the
context of connections -- think of the consequences of various router
protections for that...
The "verify unicast" defense looks good on paper, but if you analyze it,
it requires quasi universal deployment to make a difference. This is not
simpler than deploying protection against forged addresses in the
potential targets, mostly large web servers. In fact, the number of
targets is probably lower than the number of "ingress routers" that
would have to be upgraded. But then, there are three important
differences.
First, modern servers actually include protection against the forged
address attacks that you mention -- proper handling of TCP context
creation and verification of the plausibility of sequence numbers
provide a first line of defense; SSL or IPSEC provide further protection
for critical systems. Routers don't include such protections today; they
would require modification to routing protocols to describe the
authorized source address in parallel to the allowed destinations,
possibly additional fast-path hardware, and certainly an increased
management load.
Second, the protection only works if it is implemented everywhere, and
is in any case partial. As long as I cannot be sure that all Internet
routers perform the filtering, I still have to implement adequate server
side protections. If the router can be hacked, the protection is
obviously ineffective. If the egress filtering operates on broad ranges,
say a university network, the hacker can stop using random addresses,
and instead pretend that all packets come from a single machine, e.g.
the university's web site.
Third, and most important, the network based defense places the defense
burden at the wrong side of the problem. The local network is not really
suffering from the attack; its administrators have only minor incentives
to fix it. The one who is suffering is a remote server; there, you have
a lot of incentives to fix the problem, fix the TCP stack, deploy IPSEC.
All in all, I wish we would not cut the node of our face. As servers get
hardened, the mode of attack will change. We don't want to maim the
network today to protect against an attack that will not be in much use
tomorrow.
-- Christian Huitema
> -----Original Message-----
> From: Edward Vielmetti [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 19, 2001 9:24 PM
> To: Christian Huitema
> Cc: Glenn Morrow; Michael Thomas; Thomas Eklund;
[EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: Source addresses, DDoS prevention and ingress filtering
>
> Christian,
>
> The specific threat model is a compromised host being directed under
> remote control to send a spray of packets with randomly forged source
> addresses to a victim host far away. Intelligently throwing your
local
> equivalent of "ip verify unicast reverse-path" as a check in at
logical
> choke points on the network will *in actual practice* drop a whole lot
of
> traffic that should be dropped. This has important implications for
> network operators.
>
> This is not a security or confidentiality problem, and thus IPSEC is
> irrelevant. It is a network integrity problem.
>
> Ed
>
> On Thu, 19 Apr 2001, Christian Huitema wrote:
>
> > I am not sure it is such a good idea.
> >
> > >From a security stand point, it is very weak. You are trusting that
> some
> > third party, at the other end of the network, will do the right
thing.
> > What happens if the "first hop" is compromised? And, by the way,
what
> > exactly is the first hop? The wireless LAN in my home? The Ethernet
> > backbone in the same home? If you want any form of security, you
really
> > have to build it yourself, e.g. by using IPSEC. The only form of
source
> > address control that has a prayer of working is local, i.e. refuse
to
> > accept inbound packets in your domain that pretend to already come
from
> > an inside address.
> >
> > It is also very weak from a routing stand point. Internet routing is
> > anything but symmetric. The exit path from a domain depends only on
the
> > destination address, not the source address; insisting on strict
control
> > of the source address basically breaks multi-homing. It also breaks
> > several forms of mobility...
> >
> >
> > > -----Original Message-----
> > > From: Edward Vielmetti [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, April 18, 2001 10:41 AM
> > > To: Glenn Morrow
> > > Cc: Michael Thomas; Thomas Eklund; '[EMAIL PROTECTED]';
'ietf-
> > > [EMAIL PROTECTED]'
> > > Subject: RE: Source addresses, DDoS prevention and ingress
filtering
> > >
> > > And you're going to mandate source filtering on the first hop
across
> > the
> > > entire internet, how? It's a great idea and a best common
practice
> > but
> > > not something that can be set by fiat.
> > >
> > > Ed
> > >
> > > On Wed, 18 Apr 2001, Glenn Morrow wrote:
> > >
> > > > Then again if source filtering is mandated on the first hop this
> > might
> > > > eliminate the need to do filtering on other hops and this would
> > > eliminate
> > > > the need to do subnet translation or tunneling by either the MN
or
> > the
> > > MR.
> > > >
> > > > -----Original Message-----
> > > > From: Morrow, Glenn [RICH2:C330:EXCH]
> > > > Sent: Wednesday, April 18, 2001 11:56 AM
> > > > To: 'Michael Thomas'
> > > > Cc: Michael Thomas; Thomas Eklund; '[EMAIL PROTECTED]';
> > > > '[EMAIL PROTECTED]'
> > > > Subject: RE: Source addresses, DDoS prevention and ingress
filtering
> > > >
> > > >
> > > > Oh, I see what you were concerned about. It seems to me that an
MR
> > will
> > > have
> > > > to tunnel or subnet translate unless it is on it's home subnet.
> > > >
> > > > -----Original Message-----
> > > > From: Michael Thomas [mailto:[EMAIL PROTECTED]]
> > > > Sent: Wednesday, April 18, 2001 9:49 AM
> > > > To: Morrow, Glenn [RICH2:C330:EXCH]
> > > > Cc: Michael Thomas; Thomas Eklund; '[EMAIL PROTECTED]';
> > > > '[EMAIL PROTECTED]'
> > > > Subject: RE: Source addresses, DDoS prevention and ingress
filtering
> > > >
> > > >
> > > > Glenn Morrow writes:
> > > > > If the node behind the MR obtained its home address from the
the
> > > mobile
> > > > > router's subnet, then the MN will use this as the source i.e.
the
> > > MN's
> > > > home
> > > > > subnet is the MR's subnet.
> > > >
> > > > Right, but when the MR's upstream router does an
> > > > RPF check... it will drop the SN's packets.
> > > >
> > > > > Either way (tunneling or subnet translation), the topological
> > > correctness
> > > > is
> > > > > still maintained.
> > > >
> > > > Well, that's sort of the problem. The SN doesn't
> > > > know that it's putting topologically incorrect
> > > > source address in the IP header.
> > > >
> > > > Mike
> > > >
> > >
> > >
> > >
--------------------------------------------------------------------
> > > IETF IPng Working Group Mailing List
> > > IPng Home Page:
http://playground.sun.com/ipng
> > > FTP archive:
ftp://playground.sun.com/pub/ipng
> > > Direct all administrative requests to
[EMAIL PROTECTED]
> > >
--------------------------------------------------------------------
> >
>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
