No, I am not referring to AAA solutions. I am referring to server side
defenses. These defenses are effective against most DoS attacks. They
may not be effective against a complete saturation attack that floods
the server's access link, but I doubt that source address verification
would be the solution to that one; after all, activists can swamp a
phone bank today without hiding their calling numbers. Replicated server
at a number of diverse location is probably more effective than source
address verification. By the way, most "server flooding" today is caused
by "flash-crowd" phenomena with plain bona-fide clients. 

-- Christian Huitema 

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:owner-
> [EMAIL PROTECTED]] On Behalf Of Thomas Eklund
> Sent: Friday, April 20, 2001 4:26 AM
> To: Christian Huitema; 'Edward Vielmetti'; 'Glenn Morrow'
> Cc: 'Michael Thomas'; '[EMAIL PROTECTED]'; 'ietf-
> [EMAIL PROTECTED]'
> Subject: RE: Source addresses, DDoS prevention and ingress filtering
> 
> Hi Christian,
> I hope you not referring to the AAAv6 ideas? Because that is  just a
way
> to do access control and possibly combine it with the packet filters
that
> in most cases already sit in the router. It tells nothing about
mandating
> it everywhere - this is of course up to the service
provider/enterprise to
> use, but in the mobile systems there is a demand for AAA and this AAA
> draft could be a good start. And it does not break multihoming,
mobility!
> 
> Of course you can still use end-to end IPsec if you want that and at
the
> same time enforce authentication and authorazation towards the AAA
server
> and if the authentication suceeds, and then the router could update
the
> packet filter with the "authenticated" host's IP address (which could
be
> the CoA).
> 
> -- thomas
> 
> > -----Original Message-----
> > From: Christian Huitema [mailto:[EMAIL PROTECTED]]
> > Sent: den 20 april 2001 01:11
> > To: Edward Vielmetti; Glenn Morrow
> > Cc: Michael Thomas; Thomas Eklund; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]
> > Subject: RE: Source addresses, DDoS prevention and ingress filtering
> >
> >
> > 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]
--------------------------------------------------------------------

Reply via email to