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