I am well aware of the threat model. I still believe that we have to
find a solution that does not "cut our nose to cure the cold." I have
specifically discussed how the attack can be fought by other means, and
how the attacker can in fact move from "spray" to other disguises and
still continue causing the problem. We have to find a solution that does
not prohibit mobile IP or multihoming.
-- Christian Huitema
> -----Original Message-----
> From: Edward Vielmetti [mailto:[EMAIL PROTECTED]]
>
> 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]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
