Re: Where is the edge of the Internet? Re: no ip forged-source-address

[bdragon]

> fine now? u can put "loose"...its NO USE!! thats what i said..there will
> always be a route to the sourceall u may drop is 10.x/192.168 and
> 172/16-31..that too if ur network isnt internally using it

Oh, and if this ends up being the case, what's wrong with that? Less RFC1918
crap leaking between enterprises.

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[bdragon]

> fine now? u can put "loose"...its NO USE!! thats what i said..there will
> always be a route to the sourceall u may drop is 10.x/192.168 and
> 172/16-31..that too if ur network isnt internally using it
> 
> and if u end up putting "loose" an OSPF router ull drop valid traffic if ur
> not redistributing bgp etc..and if u are redistributing...well again the
> above argument holds true...every registered network will be there in BGP
> .
> 
> -rgds
> Alok

Since you appear to have not looked into the various implementations of
RPF, I'll help you out.

RPF uses the FIB, the FIB is populated by all the RIBS, therefore OSPF
vs. BGP is a red herring.

In the case you describe, you can use semi-strict RPF, populated with all
of the networks associated with the customer. This would allow sources
from the customer, regardless of path back to those sources, still drop other
paths from which there is no path back to the source via the customer, is
more efficient than acls, and you already have the data if you are filtering
their route announcements.

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[bdragon]

> One of my clients is currently a victim of an over-zealous ISP
> recklessly trying to implement rpf.  

Assuming the provider is doing the right thing by filtering routing
announcements, and assuming the customer has done the right thing
by informing their provider of the blocks they _might_ announce
(either via irr or email, depending on provider) it appears the provider
is _not_ doing the right thing by adding exceptions to rpf to make
it semi-strict based upon this data. With this sort of setup, it wouldn't
matter if the customer actually was announcing the routes or not.

Anything, when used incorrectly can have bad impact.
The various implementations of RPF that I've seen allow for these
situations, they can't however hold the provider or customer's hand.

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[bdragon]

> > Sounds like you're trying to either shoot yourself in the foot, or design a
> > new too-clever-by-half way of building a VPN.
> 
> It is called a one-way ip over satellite link to places like Australia, New
> Zeland or Middle East. So it is not like we are talking about little bit of
> traffic.
> 
> Alex

semi-strict (strict with exceptions) or loose would still work in
this scenario.

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[Valdis . Kletnieks]

On Fri, 08 Nov 2002 01:55:03 +0530, alok said:

> take a simple scenario
> AS-1 , AS-2 and AS-3 and as-4
> 
> AS-2 and as-3  in the middle, as-1 and as-4 multihome on them and are on
> either side of as-2 and as-3..they dont peer with each other ...(though as-2
> and as-3 mebbe)
> 
> as-1 advertises a  network x.y.z.w  via as-2 only.
> as-4 sees this and knows that to go back to x.y.z.w he has to go via as-2

Ahh.. but in your example, all 4 as have *SOME* route. So loose RPF would
still work.

Now let's consider this example:

AS-1 advertises to *ONLY* as-2, and as-3 filters as-2's announcement, so they
have *no* route to as-1. as-4 gets a route to as-1 via as-2. as-1 packets come
in to as-3 *anyhow* on their way to as-4, and return packets go 4-2-1.  This
still works, as long as as-3 doesn't do loose-RPF because they'll drop the
packets due to lack of a route.

Of course, if any customer of as-3 wants to actually talk to as-1, you're
going to be opening a trouble ticket.
-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg06541/pgp0.pgp
Description: PGP signature

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[alok]

if what u mean by loose is "exist only" then yes on a bgp running router
probably the WHOLE INTERNET IS EXIST ONLY...that surely gives u enuf ips to
spoof with?? how do u block by source?

you could only know that "frrom that link between as-1 and as-2 there will
be some traffic from a network IP of AS-1" etc...which still is a huge
network..enuf to spoof lots of IPs.

=> for clarification.i mean "any *registered* netowrk of AS-1 can
uplink via this link" ...this link may not be the downlink for this network
into AS-1 but can still be an uplink.

fine now? u can put "loose"...its NO USE!! thats what i said..there will
always be a route to the sourceall u may drop is 10.x/192.168 and
172/16-31..that too if ur network isnt internally using it

and if u end up putting "loose" an OSPF router ull drop valid traffic if ur
not redistributing bgp etc..and if u are redistributing...well again the
above argument holds true...every registered network will be there in BGP
.



-rgds
Alok

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[alok]

If loose rpf  doesn't work, you're about to start dropping packets *anyhow*.

Unless, of course, you *INTENDED* to have a topology where you're accepting
traffic from another AS and forwarding it, and you don't have a return path
yourself, but the destination *does* have an assymetric path.

Oh.. and you have to consider it acceptable that if any OTHER customer,
connected
to that part of your AS that doesn't have a route, tries to contact the
source, that they can't get there.

Sounds like you're trying to either shoot yourself in the foot, or design a
new too-clever-by-half way of building a VPN.



>

take a simple scenario
AS-1 , AS-2 and AS-3 and as-4

AS-2 and as-3  in the middle, as-1 and as-4 multihome on them and are on
either side of as-2 and as-3..they dont peer with each other ...(though as-2
and as-3 mebbe)

as-1 advertises a  network x.y.z.w  via as-2 only.
as-4 sees this and knows that to go back to x.y.z.w he has to go via as-2


as-4 advertises  a network a.b.c.d via as-3 only as-1 sees this too

traffic has to go between x.y.z.w and a.b.c.d

please tell me what symmetry u see here?...

and this doesnt happen on the net??

now what do u do in AS-2 and AS-3? if u say as-2 and as-3 will learn the
networks via as-1 and as-4 resp or by their own peering, then thats the
whole pointthey know the "network" exists ..they dont know which set of
traffic goes via thm and which doesnt... coz u cant...u never know what
"source IP goes via you"...u know that it will be destined somewhere and u
will know the destination if all routing on the net is proper..thats
all...yo u may know the source too...but ur paath to the source wont be the
path from where the packet came to you from the source...


if what u mean by loose is "exist only" then yes on a bgp running router
probably the WHOLE INTERNET IS EXIST ONLY...that surely gives u enuf ips to
spoof with?? how do u block by source?

you could only know that "frrom that link between as-1 and as-2 there will
be some traffic from a network IP of AS-1" etc...which still is a huge
network..enuf to spoof lots of IPs.

jusst got a stinker from bdragon too.mebbe i am dumb and you could do as
u please... im not questioning ur argument here...but i simply dont see
it...??

this is what i saw and i mentioned it

-gudnite

Alok

RE: Where is the edge of the Internet? Re: no ip forged-source-address

[H. Michael Smith, Jr.]

One of my clients is currently a victim of an over-zealous ISP
recklessly trying to implement rpf.  

One (of two) ISPs are trying to monitor my customer's circuit by
watching the serial interface (IP address) of the cpe (customer owned
and controlled) router (IP address is from ISP's block).  Due to the
fact that this customer has a T1 to one ISP and a DS-3 to another ISP,
the return path of this monitoring traffic is sent via the 2nd ISP's
link.  This 2nd ISP (DS-3) is dropping the packets because they are
being sourced from the serial interface (IP address of 1st ISP).

Advertised routes != valid source addresses is this not obvious?  I
can think of MANY examples of different sets of prefixes being
advertised across different links, while the routing decision for
outbound packets does not consider what routes are being advertised.

-Original Message-
From: [EMAIL PROTECTED] [mailto:owner-nanog@;merit.edu] On Behalf Of
alok
Sent: Thursday, November 07, 2002 3:00 PM
To: Majdi S. Abbas; [EMAIL PROTECTED]
Subject: Re: Where is the edge of the Internet? Re: no ip
forged-source-address



On Fri, Nov 08, 2002 at 01:01:33AM +0530, alok wrote:
> there was a comment from chris saying..."never possible to knw what
networks
> an bgp customer uplinks via you" which is very true.. ..so i assume u
mean
> non-bgp customers? loose or strict, rpf will not work for
aasymterically
> connected bgp neighbouring AS

How does loose not work in this scenario?

If it's not in the global tables -at all-, it's not reachable, and
might as well be discarded.

--> the scenario is this... a BGP customer uplinks network a.b.c.d
via
me, but advertises it via some place else (some other network he peers
with)
and some other bgp peer/router to bring that traffic back into his AS...

this can also happen mainly due to BGP metrics blah blah

now, essentially a.b.c.d can be anything...and he need not tell me what
he
uplinks from me, all he tells me are the networks he downlinks via me so
as
to tell me what routemaps to put with acls for bgp advertisements from
him..

infact people tend to use this very often (also a way of providing link
failure etc by multihoming) ..and they have the choice to uplink
anything
from anywhere and downlink it from another location...they certainly
dont
need to tell you what they uplink..as far as i know...

now the point is that if you use loose rfp here what are u filtering
on?
you dont even know what he is uplinking to you...

i assume the subject is still DDoS attacks...using spoofed ips...

now when u dont know what he is uplinking from ur networks, how do u
even
know what to block?

if u say "loose" simply means check if the entry for the network is
there in
the routing table..then the entire internet is there in the routing
table...(thanks to bgp)so it certainly work on bgp based "edges"

the other point u made about not reachable...well not reachaable from
where?
from a ospf running node which uses 0.0.0.0 ? a lot of ones own networks
etc
may not be reachable from there i guess...as they are covered in default
routes...

for a bgp running router...all valid internet addresses are "reachable"
,
for an ospf routerall is reachable either via 0.0.0.0, and if u
remove
default any, it doesnt even know what the customer networks are.so a
lot
"isnt" reachable

i think as was rightly defined...the edge is the place where the end
user/host gets onto the net...

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[alex]

> Sounds like you're trying to either shoot yourself in the foot, or design a
> new too-clever-by-half way of building a VPN.

It is called a one-way ip over satellite link to places like Australia, New
Zeland or Middle East. So it is not like we are talking about little bit of
traffic.

Alex

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[bdragon]

> Ok, so I'll respond to one more of the messages I missed yesterday.
> 
> On Mon, 4 Nov 2002, Matt Buford wrote:
> > On Mon, 4 Nov 2002 [EMAIL PROTECTED] wrote:
> > > The only equipment I'm heard here which has serious issues related to
> > > feature availability is the 12000 (which was never a particularly good
> > > aggregation device to begin with). RPF works fine on 7200, 7500, and
> > > 6500, from my experience. I've not used 12000's for customer aggregation
> > > since they historically haven't been designed for or adequate in that
> > > respect.

The above was actually me, not Sean, iirc.

> Alot of large providers have 'all 12000' or 'alot of 12000' devices, so
> this is a hint at the problem :( Most large, where large == continental,
> providers  don't have very many 7200/6500 gear in their network.

Someone else just mentioned running RPF on 12000 without issue, except
for SRP rings. I can't confirm that myself, as we avoided using 12000
for customer aggregation due to their poor performance in that arena.

RPF on ubr7200, 7200vxr, 7500, and 6500 all seem to work fine.

> Keep in mind that sometimes what platform you choose 12 months ago you may
> get stuck with in a longer term than originally anticipated. That platform
> may have been chosen because it was the only viable platform at the
> initial buy time :(

Definately understandable.

> > > As such, I can understand providers not being able to apply RPF
> > immediately
> > > on 12000's, at least unless they are acquiring E3 cards for new installs.
> >

> Wow, by E3 I assume you mean: Engine 3... This is a VERY BAD PLAN, if my
> experience with them is anything to judge from. Both E2 and E3 cards have
> some serious limitations when it comes to access lists and uRPF. For
> instance, I've been in config mode where:
> 
> int blah1/0.123
> ip access
> 
> yields nothing... in other words, 'ip access-group 123 out' is not even in
> the valid config for these cards :( even more depressing is the hope that
> it'll work and the unfortunate reality that it'll apply to the interface
> and never access list any traffic at all :(

Yes, I meant Engine 3, which are the ISE cards. I don't yet have any, but
I'ld be surprised if they don't support acls on subints. Perhaps you meant
E1 and E2? Even if they don't support acls, I'ld be surprised if they
didn't support RPF.


> >From what I've heard, I haven't yet tested these, the E4+ cards are
> supposed to answer alot of the existing acl issues. One thing to keep in
> mind is that your FIB is limited to ~225k prefixes if you want to use PSA
> acls (hardware acls)on a 12000... Supposedly, if you remove PSA acl
> functionality you can punt the acl work to the linecard CPU, in reality
> the punting never happens and the traffic isn't acl'd :(

Interesting, but shouldn't affect RPF, correct?

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[Valdis . Kletnieks]

On Fri, 08 Nov 2002 01:01:33 +0530, alok said:

> there was a comment from chris saying..."never possible to knw what networks
> an bgp customer uplinks via you" which is very true.. ..so i assume u mean
> non-bgp customers? loose or strict, rpf will not work for aasymterically
> connected bgp neighbouring AS

If loose rpf  doesn't work, you're about to start dropping packets *anyhow*.

Unless, of course, you *INTENDED* to have a topology where you're accepting
traffic from another AS and forwarding it, and you don't have a return path
yourself, but the destination *does* have an assymetric path.

Oh.. and you have to consider it acceptable that if any OTHER customer, connected
to that part of your AS that doesn't have a route, tries to contact the
source, that they can't get there.

Sounds like you're trying to either shoot yourself in the foot, or design a
new too-clever-by-half way of building a VPN.
-- 
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech




msg06535/pgp0.pgp
Description: PGP signature

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[alok]

On Fri, Nov 08, 2002 at 01:01:33AM +0530, alok wrote:
> there was a comment from chris saying..."never possible to knw what
networks
> an bgp customer uplinks via you" which is very true.. ..so i assume u mean
> non-bgp customers? loose or strict, rpf will not work for aasymterically
> connected bgp neighbouring AS

How does loose not work in this scenario?

If it's not in the global tables -at all-, it's not reachable, and
might as well be discarded.

--> the scenario is this... a BGP customer uplinks network a.b.c.d via
me, but advertises it via some place else (some other network he peers with)
and some other bgp peer/router to bring that traffic back into his AS...

this can also happen mainly due to BGP metrics blah blah

now, essentially a.b.c.d can be anything...and he need not tell me what he
uplinks from me, all he tells me are the networks he downlinks via me so as
to tell me what routemaps to put with acls for bgp advertisements from
him..

infact people tend to use this very often (also a way of providing link
failure etc by multihoming) ..and they have the choice to uplink anything
from anywhere and downlink it from another location...they certainly dont
need to tell you what they uplink..as far as i know...

now the point is that if you use loose rfp here what are u filtering on?
you dont even know what he is uplinking to you...

i assume the subject is still DDoS attacks...using spoofed ips...

now when u dont know what he is uplinking from ur networks, how do u even
know what to block?

if u say "loose" simply means check if the entry for the network is there in
the routing table..then the entire internet is there in the routing
table...(thanks to bgp)so it certainly work on bgp based "edges"

the other point u made about not reachable...well not reachaable from where?
from a ospf running node which uses 0.0.0.0 ? a lot of ones own networks etc
may not be reachable from there i guess...as they are covered in default
routes...

for a bgp running router...all valid internet addresses are "reachable" ,
for an ospf routerall is reachable either via 0.0.0.0, and if u remove
default any, it doesnt even know what the customer networks are.so a lot
"isnt" reachable

i think as was rightly defined...the edge is the place where the end
user/host gets onto the net...

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[Majdi S. Abbas]

On Fri, Nov 08, 2002 at 01:01:33AM +0530, alok wrote:
> there was a comment from chris saying..."never possible to knw what networks
> an bgp customer uplinks via you" which is very true.. ..so i assume u mean
> non-bgp customers? loose or strict, rpf will not work for aasymterically
> connected bgp neighbouring AS

How does loose not work in this scenario?

If it's not in the global tables -at all-, it's not reachable, and
might as well be discarded.

--msa

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[alok]

there was a comment from chris saying..."never possible to knw what networks
an bgp customer uplinks via you" which is very true.. ..so i assume u mean
non-bgp customers? loose or strict, rpf will not work for aasymterically
connected bgp neighbouring AS

- Original Message -
From: <[EMAIL PROTECTED]>
To: alok <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, November 08, 2002 12:41 AM
Subject: Re: Where is the edge of the Internet? Re: no ip
forged-source-address



> > I'm opposed to some of the suggestions where to put source address
> > filters, especially placing them in "non-edge" locations.  E.g.
requiring
> > address filters at US border crossings is a *bad* idea, worthy of an
> > official visit from the bad idea fairy.
>
> What is bad about filtering facing non-customers, if loose rpf is
> used? I'm assuming this is what you mean by "border crossings" rather than
> the literal.
>
> ->makes sense on the edge/aggregation but if you do it further up
in
> the network.there maybe some cases where we have assymetric routing,
> where the path of uplink is never the path the same as the downlink, and
> infact the source network of the packet may never be present in the
routing
> table(it is possible, after all its a packet switched network and the
> routing is destination IP based) ...

Right, which is why I specifically mentioned loose rpf, vs. strict rpf.

Even further up the customer chain, you'll still have a list of customer
networks (assuming folks are doing the right thing by filtering customer
bgp announcements) which could be used as an input to strict rpf.

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[bdragon]

> > I'm opposed to some of the suggestions where to put source address
> > filters, especially placing them in "non-edge" locations.  E.g. requiring
> > address filters at US border crossings is a *bad* idea, worthy of an
> > official visit from the bad idea fairy.
> 
> What is bad about filtering facing non-customers, if loose rpf is
> used? I'm assuming this is what you mean by "border crossings" rather than
> the literal.
> 
> ->makes sense on the edge/aggregation but if you do it further up in
> the network.there maybe some cases where we have assymetric routing,
> where the path of uplink is never the path the same as the downlink, and
> infact the source network of the packet may never be present in the routing
> table(it is possible, after all its a packet switched network and the
> routing is destination IP based) ...

Right, which is why I specifically mentioned loose rpf, vs. strict rpf.

Even further up the customer chain, you'll still have a list of customer
networks (assuming folks are doing the right thing by filtering customer
bgp announcements) which could be used as an input to strict rpf.

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[Christopher L. Morrow]

Ok, so I'll respond to one more of the messages I missed yesterday.

On Mon, 4 Nov 2002, Matt Buford wrote:

>
> On Mon, 4 Nov 2002 [EMAIL PROTECTED] wrote:
> > The only equipment I'm heard here which has serious issues related to
> > feature availability is the 12000 (which was never a particularly good
> > aggregation device to begin with). RPF works fine on 7200, 7500, and
> > 6500, from my experience. I've not used 12000's for customer aggregation
> > since they historically haven't been designed for or adequate in that
> > respect.

Alot of large providers have 'all 12000' or 'alot of 12000' devices, so
this is a hint at the problem :( Most large, where large == continental,
providers  don't have very many 7200/6500 gear in their network.

Keep in mind that sometimes what platform you choose 12 months ago you may
get stuck with in a longer term than originally anticipated. That platform
may have been chosen because it was the only viable platform at the
initial buy time :(

> >
> > As such, I can understand providers not being able to apply RPF
> immediately
> > on 12000's, at least unless they are acquiring E3 cards for new installs.
>

Wow, by E3 I assume you mean: Engine 3... This is a VERY BAD PLAN, if my
experience with them is anything to judge from. Both E2 and E3 cards have
some serious limitations when it comes to access lists and uRPF. For
instance, I've been in config mode where:

int blah1/0.123
ip access

yields nothing... in other words, 'ip access-group 123 out' is not even in
the valid config for these cards :( even more depressing is the hope that
it'll work and the unfortunate reality that it'll apply to the interface
and never access list any traffic at all :(

To Cisco's credit they are now addressing the intricacies of the 12000
platform, the combinations of linecard, IOS, config bits, routing
situations... This is a complex beast, and its not known anywhere near as
well as  it should be.

>From what I've heard, I haven't yet tested these, the E4+ cards are
supposed to answer alot of the existing acl issues. One thing to keep in
mind is that your FIB is limited to ~225k prefixes if you want to use PSA
acls (hardware acls)on a 12000... Supposedly, if you remove PSA acl
functionality you can punt the acl work to the linecard CPU, in reality
the punting never happens and the traffic isn't acl'd :(

> 6500s can do it, but enabling it doubles the size of the FIB, and the FIB
> can only hold 244,000 unicast entries.  So, with RPF enabled on any
> interface, your limit is now 122,000 routes.  With a full BGP view, you're
> probably dangerously close to this number.
>

This seems like the same issue as the FIB limits on the 12000 linecards :(

> You're supposed to be able to exceed that number and simply end up with some
> networks being software switched, however, I've seen a number of 6509s
> running native software either fall over or experience serious bugs (not
> fixed as of 12.1(13)E) when exceeding this limit.
>

On the 12000, the routes are just lost... and magically the attack
'stops', so does traffic to some randomly large number of destinations too
:( So this is 'suboptimal' to say the least.

BTW, Cisco has been made aware of these issues so its again, on deck for a
fix in the e5/6/7 linecard...

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[Christopher L. Morrow]

Sean puts this very nicely... I was away today so I missed the rest of the
traffic and looking it over alot of it was not relevant. I'll put in some
comments here though.

On Mon, 4 Nov 2002, Sean Donelan wrote:

>
> On Mon, 4 Nov 2002 [EMAIL PROTECTED] wrote:
> > What about the other large isps? What would it take for you to do
> > something? Chris is gracious enough to show up and participate, at
> > least even if it does mean he has to wear nomex.
>
> I'm in favor of source address filtering at the edges.
>

Sure, so are most operators, including me. Define the edge the right way,
as Sean says, though. The edge is the customer CPE, or even the LAN router
inside the customer network. As close as possible to actual hosts that
can spoof.

> I'm opposed to some of the suggestions where to put source address
> filters, especially placing them in "non-edge" locations.  E.g. requiring
> address filters at US border crossings is a *bad* idea, worthy of an
> official visit from the bad idea fairy.
>

In general, knowing what ips a 'peer' is going to send you is very
difficult. One would hope that all peers would have all customers
implement filtering as close to their hosts as possible. This isn't a
reality today :(

Putting filtering, of any type, in a 'core' spot is asking for trouble.
Doing much other than routing at the core is a bad plan. In the future
perhaps filtering and other magic would be possible in the core, but in
reality it will almost always be a tough thing to do. :(

> Our networks, and our customer bases, are not identical.  This is good
> and bad. Not to make excuses, the ease with which this can technically be
> done depends on your network and type of customer connections.  Or more
> precisely how you aggregate customer connections.
>

This is a good point. If you are aggregating customers on gear where the
uRPF filtering is done in software you will severely impact performance
with anything over oc3 rates :(

Do not confuse acls with uRPF, acls on t1 aggragation isn't workable
unless your 'network' lives in your basement. uRPF is only feasible in
some small circumstances.

Making the assumption that because your network works with uRPF and thus
Sean's or Ryan's or Paul's will isn't really valid. I would like to
believe that the majority of NSP/ISP operators have atleast considered
uRPF, or some kind of mitigation techniques. We have, and for us the
current possibilities aren't feasible :( for a number of technical reasons
which the respective's vendors are aware.

> IMHO the edge is generally the best place to do source address filtering.
> After traffic is aggregated its more difficult. Some folks have already
> identified the technical limitations of some types equipment.  And with
> the market, we're going to be stuck with that equipment for a while.  In
> hindsight, if every provider and every equipment vendor did it from day 1,
> we would be in great shape.
>

Yes, filter at the 'edge', where 'edge' == 'as close to the host as
possible'. Possibly this could be accomplished by a config default in
IOS/JunOS... something akin to 'no ip directed broadcast'... or atleast
that possibility was raised at the NANOG Security BOF.

This won't solve any problems in the short term, but it is a move in the
right direction.

> Does that mean I can wave my magic wand and fix everything tomorrow? No.
>
> Can I work on standards, vendors and purchasing agents to change this over
> time? Yes.  Will yelling at me make it happen faster? I doubt it, but I
> know you will anyway.
>
>

This is the tact that we are taking inside UUNET today. We are trying to
work on a consensus document for 'Network Equipment Requirements'. This
effort is being headed up by Mr. George Jones, I believe this document is
headed out for IETF work and possibly additions to BCP 38 ? Barry Greene
is helping out on this along with some folks from Merit.

The focus of this is to get everyone possible asking for the same thing
from their vendors. For a long time every vendor through the door would
say: "security what?", "Filtering what?", "You are the ONLY person asking
for this capability." This was the response to: Radius authentication for
management access, tacacs auth for management access, auth for management
access, filtering, filtering at line rate, filtering on all interfaces...
the list goes on of things that one would assume are 'standard' on any
network gear. UUNET, atleast, has been asking all vendors we
see/speak-with/test for the list of things in George's document for the
last 2 years.

-Chris "Nomex, whats that?" Morrow.

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[alok]

> I'm opposed to some of the suggestions where to put source address
> filters, especially placing them in "non-edge" locations.  E.g. requiring
> address filters at US border crossings is a *bad* idea, worthy of an
> official visit from the bad idea fairy.

What is bad about filtering facing non-customers, if loose rpf is
used? I'm assuming this is what you mean by "border crossings" rather than
the literal.

->makes sense on the edge/aggregation but if you do it further up in
the network.there maybe some cases where we have assymetric routing,
where the path of uplink is never the path the same as the downlink, and
infact the source network of the packet may never be present in the routing
table(it is possible, after all its a packet switched network and the
routing is destination IP based) ...

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[Matt Buford]

On Mon, 4 Nov 2002 [EMAIL PROTECTED] wrote:
> The only equipment I'm heard here which has serious issues related to
> feature availability is the 12000 (which was never a particularly good
> aggregation device to begin with). RPF works fine on 7200, 7500, and
> 6500, from my experience. I've not used 12000's for customer aggregation
> since they historically haven't been designed for or adequate in that
> respect.
>
> As such, I can understand providers not being able to apply RPF
immediately
> on 12000's, at least unless they are acquiring E3 cards for new installs.

6500s can do it, but enabling it doubles the size of the FIB, and the FIB
can only hold 244,000 unicast entries.  So, with RPF enabled on any
interface, your limit is now 122,000 routes.  With a full BGP view, you're
probably dangerously close to this number.

You're supposed to be able to exceed that number and simply end up with some
networks being software switched, however, I've seen a number of 6509s
running native software either fall over or experience serious bugs (not
fixed as of 12.1(13)E) when exceeding this limit.

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[bdragon]

> On Mon, 4 Nov 2002 [EMAIL PROTECTED] wrote:
> > What about the other large isps? What would it take for you to do
> > something? Chris is gracious enough to show up and participate, at
> > least even if it does mean he has to wear nomex.
> 
> I'm in favor of source address filtering at the edges.

Here we agree, I believe the difference might be that you don't consider
the edge of your network to be the edge. If the edge only encompasses
where "Joe Bob" connects, then we have no belt and suspenders for when
things go wrong. It also allows the largest isps to continue doing
nothing or very little.

> I'm opposed to some of the suggestions where to put source address
> filters, especially placing them in "non-edge" locations.  E.g. requiring
> address filters at US border crossings is a *bad* idea, worthy of an
> official visit from the bad idea fairy.

What is bad about filtering facing non-customers, if loose rpf is
used? I'm assuming this is what you mean by "border crossings" rather than
the literal.

> Our networks, and our customer bases, are not identical.  This is good
> and bad. Not to make excuses, the ease with which this can technically be
> done depends on your network and type of customer connections.  Or more
> precisely how you aggregate customer connections.

Is there anywhere you can apply rpf today, while working towards the rest
for tomorrow? I can't speak for everyone, but I like it when people
do what they can.

I don't personally have RPF deployed "everywhere" in the network I run,
but I am deploying it, piece by piece.

"Progress, not perfection" as the saying goes.

> IMHO the edge is generally the best place to do source address filtering.
> After traffic is aggregated its more difficult. Some folks have already
> identified the technical limitations of some types equipment.  And with
> the market, we're going to be stuck with that equipment for a while.  In
> hindsight, if every provider and every equipment vendor did it from day 1,
> we would be in great shape.

The only equipment I'm heard here which has serious issues related to
feature availability is the 12000 (which was never a particularly good
aggregation device to begin with). RPF works fine on 7200, 7500, and
6500, from my experience. I've not used 12000's for customer aggregation
since they historically haven't been designed for or adequate in that
respect.

As such, I can understand providers not being able to apply RPF immediately
on 12000's, at least unless they are acquiring E3 cards for new installs.

> Does that mean I can wave my magic wand and fix everything tomorrow? No.
> 
> Can I work on standards, vendors and purchasing agents to change this over
> time? Yes.  Will yelling at me make it happen faster? I doubt it, but I
> know you will anyway.

All I asked for in my last message was whether folks were making progress,
and if they weren't to point out the trouble areas so we could all pool
our collective resources to address the stoppage.
This doesn't mean full deployment must occur by tomorrow (I'ld fail), but
that it be something each network is working towards.

However, we never hear "we're working on deploying rpf, but having snags"
but hear instead "rpf won't work for us". The latter always feels
more philosophical than technical, even if there are real technical issues
at play. If there are technical issues, I want to help in getting them
addressed (short of buying folks gear appropriate for customer aggregation,
sorry I don't have money to donate).

So, in this vein, is there gear other than old 12000 linecards that
can't do RPF? Is anyone still using 2500's or 4500's?

What non-hardware reasons are there not to do some flavor of rpf? Is
there a situation where even loose rpf will not work?

Re: Where is the edge of the Internet? Re: no ip forged-source-address

[Daniel Senie]

At 06:18 PM 11/4/2002, Sean Donelan wrote:


On Mon, 4 Nov 2002 [EMAIL PROTECTED] wrote:
> What about the other large isps? What would it take for you to do
> something? Chris is gracious enough to show up and participate, at
> least even if it does mean he has to wear nomex.

I'm in favor of source address filtering at the edges.

I'm opposed to some of the suggestions where to put source address
filters, especially placing them in "non-edge" locations.


No argument there. Bogon filtering could (should?) be done everywhere, but 
ingress is best when done close to, well, the ingress point.

  E.g. requiring
address filters at US border crossings is a *bad* idea, worthy of an
official visit from the bad idea fairy.


This would be a bad idea even if it were possible to clearly delineate 
border crossings somewhere. Many foreign ISPs collocate routers in the USA, 
leading to all kinds of fun questions of where borders lie in cyberspace.


Our networks, and our customer bases, are not identical.  This is good
and bad. Not to make excuses, the ease with which this can technically be
done depends on your network and type of customer connections.  Or more
precisely how you aggregate customer connections.


Doing absolutely nothing, in any part of one's network seems unreasonable. 
For the large backbone providers, they might consider adding 
terms-of-service requirements for their downstreams, if they themselves 
can't implement on their equipment. UUNet was able to impose something like 
that with port 25 blocking, requiring their wholesale POP customers to add 
that to their RADIUS server configs.

Even the Cisco RPF check that looks to see if there is ANY route to a net 
would be helpful. That would squelch out the packets with 0.0.0.0 source 
addresses and other such bogons. Cisco claims that's not even high 
overhead. Perhaps turning that on in the backbone routers would be worthwhile?


IMHO the edge is generally the best place to do source address filtering.
After traffic is aggregated its more difficult.


Clearly. The question is the definition of aggregation. Is it the customer 
premesis router that must do the work,  the aggregation router at the local 
ISP? The backbone vendor's aggregation router that regional ISPs attach to?

 Some folks have already
identified the technical limitations of some types equipment.  And with
the market, we're going to be stuck with that equipment for a while.  In
hindsight, if every provider and every equipment vendor did it from day 1,
we would be in great shape.

Does that mean I can wave my magic wand and fix everything tomorrow? No.

Can I work on standards, vendors and purchasing agents to change this over
time? Yes.  Will yelling at me make it happen faster? I doubt it, but I
know you will anyway.


When I first got involved in this back in 1996, this was my answer to those 
who complained their routers would melt. "Add it to your requirements 
document for your next round of purchasing" was a common comment. If you 
don't tell your vendors you need a feature, they won't spend their time on 
it. Cisco, to their credit, has been working on this issue. Their automated 
solutions have shortcomings, but they seem to be working on improvements. 
In edge cases with single-homed customers, there's really no excuse not to 
have an ACL to take care of the issue. The extra few lines of config 
(probably script generated anyway) would not hurt. Seems some folks won't 
even do that.

Where is the edge of the Internet? Re: no ip forged-source-address

[Sean Donelan]

On Mon, 4 Nov 2002 [EMAIL PROTECTED] wrote:
> What about the other large isps? What would it take for you to do
> something? Chris is gracious enough to show up and participate, at
> least even if it does mean he has to wear nomex.

I'm in favor of source address filtering at the edges.

I'm opposed to some of the suggestions where to put source address
filters, especially placing them in "non-edge" locations.  E.g. requiring
address filters at US border crossings is a *bad* idea, worthy of an
official visit from the bad idea fairy.

Our networks, and our customer bases, are not identical.  This is good
and bad. Not to make excuses, the ease with which this can technically be
done depends on your network and type of customer connections.  Or more
precisely how you aggregate customer connections.

IMHO the edge is generally the best place to do source address filtering.
After traffic is aggregated its more difficult. Some folks have already
identified the technical limitations of some types equipment.  And with
the market, we're going to be stuck with that equipment for a while.  In
hindsight, if every provider and every equipment vendor did it from day 1,
we would be in great shape.

Does that mean I can wave my magic wand and fix everything tomorrow? No.

Can I work on standards, vendors and purchasing agents to change this over
time? Yes.  Will yelling at me make it happen faster? I doubt it, but I
know you will anyway.

Re: no ip forged-source-address

[bdragon]

> On Wed, 30 Oct 2002, Charles D Hammonds wrote:
> 
> > analogy games are fun, but it boils down to this... If I know the real
> > source of an attack, I can stop it within minutes. I'm sure that my
> > customers appreciate that fact. Noone will ever completely stop attacks, the
> > point is to minimize their impact. that is my concern as a service provider.
> > also, from the victim's perspective, you have someone to hold accountable.
> 
> again, spoofed or non, at the egress to the customer you just need to make
> the traffic stop. Whether they are spoofed isn't an issue.

It is a lot easier to stop when you know whom you have to stop.

Why is uunet so opposed to uRPF? If performance concerns, what effort
has been made to address them with the vendor? Why is it that others
(I believe ATT was mentioned) can do it with no apparent performance
impact? Is it philosophical, and nothing would get you to change? What
about financial, more dos traffic equals more revenue and bad sources
means complaints may go elsewhere deflecting cost from the abuse/security
budget? Do you just not like us?

Let's solve whatever issues you believe to exist, so we can do _something_
rather than sitting around not doing anything all the time. What would
it take to get uunet to do something?

What about the other large isps? What would it take for you to do
something? Chris is gracious enough to show up and participate, at
least even if it does mean he has to wear nomex.

Re: no ip forged-source-address

[bdragon]

> On Wed, 30 Oct 2002 [EMAIL PROTECTED] wrote:
> RPF checking can only go so far.  You would need RPF checking down to the
> host level and I haven't heard anyone discuss that yet.

Is this a reason not to do what we can now?

> -Hank

Let's start with getting it going in the right direction, at least.

Re: no ip forged-source-address

[bdragon]

> On Wed, Oct 30, 2002 at 03:44:12PM +, [EMAIL PROTECTED] wrote:
> 
> > Therefore, would it be a reasonable suggestion to ask router vendors to
> > source address filtering in as an option[1] on the interface and then move
> > it to being the default setting[2] after a period of time?
> 
> Cannot be done, I certainly doesn't want RPF check to be default enabled
> on all interfaces on my routers, think for a second about asymmetric
> routing WITHIN the ISP network.
> 
> /Jesper

in cisco parlance,
ip verify unicast source reachable-via any allow-default allow-self-ping
would be fine in the core, and as a default setting.

Would still need to enable strict settings on applicable borders,
which would probably be skipped by the clue impaired, but
some of the crap would be caught, which is better than none.

Re: no ip forged-source-address

[Bob Martinez]

Richard:


Just my $0.02,


May not be enough money.  You present a solution to an unclearly defined 
problem.  Never fear, the IETF has a packet sampling working group now, but 
one vendor has RFC3176 sFlow today (yesterday).  I've got sFlow running on 
1GbE links today and I'm planning on a 10GbE upgrade next year with sFlow 
support for the core.  Same product I bought 2 years ago.

http://www.sflow.org/participants.htm

List is growing.

You can't make decisions about your network if you don't really know your 
network.  An sFlow collector will give you accounting and monitoring to take 
any action you so desire to fix your problems in real time.  Can't wait 
until this WG produces a standards based product though.  IPFIX was started 
after sFlow.  IPFIX is short of the mark for L2 networks.

A very happy sFlow (www.ietf.org/rfc/rfc3176.txt) user...

Bobby





_
Internet access plans that fit your lifestyle -- join MSN. 
http://resourcecenter.msn.com/access/plans/default.asp

Re: no ip forged-source-address

[David Howe]

at Thursday, October 31, 2002 1:22 PM, Randy Bush <[EMAIL PROTECTED]> was
seen to say:
>> analogy games are fun, but it boils down to this... If I know the
>> real source of an attack, I can stop it within minutes.
>
> the real source of the attack is the skript kitty who zombied the
> 10,000 hosts which are sourcing packets at you.  the intermediate
> sources are the 10,000 zombies, and trying to deal with them at the
> source just does not scale.
really you only need four or five though - if you can monitor the tcp/ip
links each have, you should find a common node that is the control node
(assuming the current situation where the bots remain connected during
the attack; a simple change could alter this to disconnect immediately
after orders are issued and not reconnect for a random time spanning
hours or days, but even then, unless the kiddie wishes to discard his
entire botnet after a single attack, they should eventually reconnect to
a control channel (probably an irc channel or similar) - at least
theoretically, an irc server network could be tapped to determine who is
the controller in a bot room, or the bot room could be discontinued
(which again, would only halt the current state of the art; the bots
could easily have a different network or a distributed networking
capability to recover the botnet after loss of a control room; actually,
I would be surprised if bots didn't already have some similar provision
now)

RE: no ip forged-source-address

[Randy Bush]

> analogy games are fun, but it boils down to this... If I know the real
> source of an attack, I can stop it within minutes.

the real source of the attack is the skript kitty who zombied the 10,000
hosts which are sourcing packets at you.  the intermediate sources are the
10,000 zombies, and trying to deal with them at the source just does not
scale.  though i sympathize with the frustration the attack victim feels,
i find the net.vigilanteeism amusing at best and misdirecting of people's
efforts at worst.  the places where the counter-attack is scalable are
at the real perp and at the attacked site.  finding the former is still
a matter of research.  the known scalable counter to the latter is still
.

randy

Re: no ip forged-source-address

[Sean Donelan]

On Thu, 31 Oct 2002, Christopher L. Morrow wrote:
> I think the spoofed source filtering is more a red-herring than anything
> else. Its not the fix for anything related to this problem of attacks on
> the internet. Spoofed or non, I can forward 1,000,000pps at your network and
> it will die (most times).

I agree, but

> This is like trying to fix a rotten decayed tooth with trident.

Wouldn't you rather the dentist know which tooth to drill, instead of
randomly drilling all of of your teeth hoping to get the cavity?

I can pretty much predict, after source address validation becomes
widely used someone will come up with the idea of blackholing attacking
hosts. Of course, since many of these systems use DHCP, the zombies will
just release and get new addresses.

Re: no ip forged-source-address

[Jim Forster]

On 10/30/02 11:26 AM, "Hank Nussbacher" <[EMAIL PROTECTED]> wrote:

> If every router in the world did this I could still use spoofed IP
> addresses and DDOS someone.  My little program could determine what subnet
> I am on, check what other hosts are alive on the subnet and then when it
> decides to attack, it would use some neighbor's IP.  The subnet I am on is
> a /24 and there very well may be a few dozen hosts.  I could be real
> sneaky and alter my IP randomly to be any of my neighbors for every packet
> I send out.
> 
> Traceback would get me instantly back to the offending subnet but then it
> would take a bit of digging on the network admin to track me down and
> applying RPF checking won't help.
> 
> RPF checking can only go so far.  You would need RPF checking down to the
> host level and I haven't heard anyone discuss that yet.

That's what we can do on our DOCSIS CMTS -- verify that the source IP
address is that which was issued with DHCP over the same DOCSIS SID.  It's
not possible to spoof using your neighbor's PC, even if they're on the same
subnet, as their CM has a different DOCSIS SID. Otherwise the typical RPF
checking would be pretty ineffective, with up to a 1000 or even 2000 CM's on
a single interface/subnet.

So if the operator had this feature turned on your little program would not
succeed on PC's behind cable modems.

  -- Jim

RE: no ip forged-source-address

[Christopher L. Morrow]

On Wed, 30 Oct 2002, Charles D Hammonds wrote:

> analogy games are fun, but it boils down to this... If I know the real
> source of an attack, I can stop it within minutes. I'm sure that my
> customers appreciate that fact. Noone will ever completely stop attacks, the
> point is to minimize their impact. that is my concern as a service provider.
> also, from the victim's perspective, you have someone to hold accountable.

again, spoofed or non, at the egress to the customer you just need to make
the traffic stop. Whether they are spoofed isn't an issue.

>
> Charles
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:owner-nanog@;merit.edu]On Behalf Of
> Christopher L. Morrow
> Sent: Wednesday, October 30, 2002 10:47 PM
> To: [EMAIL PROTECTED]
> Cc: Christopher L. Morrow; [EMAIL PROTECTED]
> Subject: Re: no ip forged-source-address
>
>
>
>
>
> On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote:
>
> > On Thu, 31 Oct 2002 06:21:00 GMT, "Christopher L. Morrow" said:
> >
> > > I'm confused.. its still a DoS attack, eh??
> >
> > It's the difference between:
> >
> > A) Going out to your car at the end of a too-long day and finding a
> > broken taillight.
> >
> > B) Going out to your car at the end of a too-long day and finding a
> > broken taillight and a business card under the windshield wiper that
> > has "Sorry - call me and I'll pay for it" written on the back.
> >
>
> I think the spoofed source filtering is more a red-herring than anything
> else. Its not the fix for anything related to this problem of attacks on
> the internet. Spoofed or non, I can forward 1,000,000pps at your network and
> it will die (most times).
>
> This is like trying to fix a rotten decayed tooth with trident.
>
>

RE: no ip forged-source-address

[Charles D Hammonds]

analogy games are fun, but it boils down to this... If I know the real
source of an attack, I can stop it within minutes. I'm sure that my
customers appreciate that fact. Noone will ever completely stop attacks, the
point is to minimize their impact. that is my concern as a service provider.
also, from the victim's perspective, you have someone to hold accountable.

Charles

-Original Message-
From: [EMAIL PROTECTED] [mailto:owner-nanog@;merit.edu]On Behalf Of
Christopher L. Morrow
Sent: Wednesday, October 30, 2002 10:47 PM
To: [EMAIL PROTECTED]
Cc: Christopher L. Morrow; [EMAIL PROTECTED]
Subject: Re: no ip forged-source-address





On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote:

> On Thu, 31 Oct 2002 06:21:00 GMT, "Christopher L. Morrow" said:
>
> > I'm confused.. its still a DoS attack, eh??
>
> It's the difference between:
>
> A) Going out to your car at the end of a too-long day and finding a
> broken taillight.
>
> B) Going out to your car at the end of a too-long day and finding a
> broken taillight and a business card under the windshield wiper that
> has "Sorry - call me and I'll pay for it" written on the back.
>

I think the spoofed source filtering is more a red-herring than anything
else. Its not the fix for anything related to this problem of attacks on
the internet. Spoofed or non, I can forward 1,000,000pps at your network and
it will die (most times).

This is like trying to fix a rotten decayed tooth with trident.

Re: no ip forged-source-address

[Hank Nussbacher]

At 01:36 AM 31-10-02 -0500, [EMAIL PROTECTED] wrote:


It's the difference between:

A) Going out to your car at the end of a too-long day and finding a
broken taillight.

B) Going out to your car at the end of a too-long day and finding a
broken taillight and a business card under the windshield wiper that
has "Sorry - call me and I'll pay for it" written on the back.


It is better than not having it but we should not get our hopes up that DOS 
attacks would stop.  Remember when 60% of the Internet mail servers were 
open mail relays?  We all thought closing them up would stop spam.  Today 
it is less than 1% but I would say that the amount of spam has not dropped 
proportionality.  See:
http://www.nwfusion.com/columnists/2002/1014buzz.html
for reference.

-Hank

Re: no ip forged-source-address

[Christopher L. Morrow]

On Thu, 31 Oct 2002 [EMAIL PROTECTED] wrote:

> On Thu, 31 Oct 2002 06:21:00 GMT, "Christopher L. Morrow" said:
>
> > I'm confused.. its still a DoS attack, eh??
>
> It's the difference between:
>
> A) Going out to your car at the end of a too-long day and finding a
> broken taillight.
>
> B) Going out to your car at the end of a too-long day and finding a
> broken taillight and a business card under the windshield wiper that
> has "Sorry - call me and I'll pay for it" written on the back.
>

I think the spoofed source filtering is more a red-herring than anything
else. Its not the fix for anything related to this problem of attacks on
the internet. Spoofed or non, I can forward 1,000,000pps at your network and
it will die (most times).

This is like trying to fix a rotten decayed tooth with trident.

Re: no ip forged-source-address

[Valdis . Kletnieks]

On Thu, 31 Oct 2002 06:21:00 GMT, "Christopher L. Morrow" said:

> I'm confused.. its still a DoS attack, eh??

It's the difference between:

A) Going out to your car at the end of a too-long day and finding a
broken taillight.

B) Going out to your car at the end of a too-long day and finding a
broken taillight and a business card under the windshield wiper that
has "Sorry - call me and I'll pay for it" written on the back.




msg06365/pgp0.pgp
Description: PGP signature

RE: no ip forged-source-address

[H. Michael Smith, Jr.]

If you go back to the thread, you'll see that I was responding to the
idea that using src-addr verification would not prevent someone from
spoofing addresses on his/own own subnet.  Others pointed out that while
this might hide the true offender, it would still make the DoS attack
easier to mitigate because the src addresses would indicate the network
from which the attack originated (if not the actual hosts).  Some folks
didn't seem to appreciate the value here, therefore I asserted that
there is a specific difference between packets with virtually random src
addrs, and packets that passed through src-addr filters.  The first set
are not traceable and src addresses generally useless, while the 2nd set
have src addresses that can be used to trace to at least the attack's
source network.

As for your confusion, I am not sure that I can help with that. :-)



-Original Message-
From: Christopher L. Morrow [mailto:chris@;UU.NET] 
Sent: Thursday, October 31, 2002 1:21 AM
To: H. Michael Smith, Jr.
Cc: 'Hank Nussbacher'; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: no ip forged-source-address



On Wed, 30 Oct 2002, H. Michael Smith, Jr. wrote:

>
> A fundamental effect of spoofing addresses from your local subnet is
> that when the packets reach their target, the source addresses are
> meaningful.  I realize that the traceability of these packets has
> already been mentioned, but I want to point out the profound
difference
> between a DDoS attack with meaningful vs. meaningless source
addresses.
>

I'm confused.. its still a DoS attack, eh??

RE: no ip forged-source-address

[Christopher L. Morrow]

On Wed, 30 Oct 2002, H. Michael Smith, Jr. wrote:

>
> A fundamental effect of spoofing addresses from your local subnet is
> that when the packets reach their target, the source addresses are
> meaningful.  I realize that the traceability of these packets has
> already been mentioned, but I want to point out the profound difference
> between a DDoS attack with meaningful vs. meaningless source addresses.
>

I'm confused.. its still a DoS attack, eh??

Re: no ip forged-source-address

[Christopher L. Morrow]

I was trying to keep my mouth shut... but alas that was too tough ;(

First, the ip addresses used in the attack are completely disconnected
from the problem of the attack. If you get attacked, its really not
relevant what ips are used, spoofed or not someone needs to stop it for
you. The real problem that needs to be addressed is 'how to make the
attacks stop' in the first place.

Anyway, on to the comments :)


On Wed, 30 Oct 2002, Daniel Senie wrote:

>
> At 12:09 PM 10/30/2002, you wrote:
> >  "daniel" == Daniel Senie <[EMAIL PROTECTED]> writes:
> >
> >daniel> If the government or other large buyers require network-wide
> >daniel> ingress filtering in any supplier they buy from (something I
> >daniel> suggested to the folks at eBay, Schwab, etc. in our phone
> >daniel> calls after the attacks a few years ago), or if there were
> >daniel> legal incentive, there might be a chance ISPs would find a
> >daniel> financial motive to implement BCP 38. As it is, there's no
> >daniel> incentive, so the path of least resistance is to do nothing.
> >
> >I find it interesting that you suggest that the legal incentive should
> >be toward having the ISPs come up with a magic solution and not toward
> >having the customers do egress filtering at the edge(s) of their
> >network and actually perform something resembling security on the
> >hosts on their networks.
>
> What I suggested was a financial OR legal incentive.
>
>
> >After all, it is not usually a security failing of the ISP that causes
> >a DoS or DDoS attack, but utter incompetence or neglect by someone at
> >the edge of the network.
>
> That's a question of perspective. Arguably both the ISP and the end user
> are responsible. The ISP is often in the role of managing the CPE router,
> and thereby has control over the router where ingress/egress filtering is
> most easily implemented with simple access control lists.
>

Wow, this is an overreaching assumption you are making. There are quite a
few ISP's that manage a small minority of their customers. I'd think that
number at UUNET, for example, manages less than 1% of its customer CPE.
Sprint is apparently managing a bit more, given that almost all sprintlink
customers I talked to have managed cpe... ATT I don't know about for
this argument. The point here is that assuming that "all isps manage their
customer's cpe" isn't safe.

>
> >I'm not saying I don't think ISPs should filter where feasible, I'm
> >just saying that if we're going to hold someone responsible, it should
> >be the people who are responsible, not the people who are convenient.
>
> I find it interesting that some ISPs have no trouble taking care of ingress
> filtering, while others bellyache about how hard and expensive it is.
> Another nanog participant commented ATT implemented this starting in 1995.
> A UUNet person was the most vocal opponent to the draft that became RFC
> 2267 (over concern that the Cisco 7000's in use then would not handle the
> load). Six years later, ATT's network seems to do OK. Did UUNet ever do
> anything about it? Buy gear sized properly to do it? UUNet gives away
> 2610's with leased lines. Do they come pre-configured to do ingress
> filtering even?

Yes, this has been part of the standard customer router config for
sometime now... Technically its 'egress' not 'ingress' filters, but the
same effect is in place.

>
> The question for the ISP is how it will defend itself when summoned to
> court. The ISP had the tools to ensure spoof attacks could not come from
> its network, yet chose not to. The customer likely would also face the

This is entirely NOT the case. The 'tools' being 'urpf' works in limited
cases, there are some spectacular failures though. Access-lists on INGRESS
at the ISP, except in small ISP examples are a massive scale problem.. not
to mention the functionality issues :)

Re: no ip forged-source-address

[Jared Mauch]

On Wed, Oct 30, 2002 at 03:34:40PM -0600, Craig A. Huegen wrote:
> 
> On Wed, Oct 30, 2002 at 09:26:30PM +0200, Hank Nussbacher wrote:
> 
> ==>Traceback would get me instantly back to the offending subnet but then it
> ==>would take a bit of digging on the network admin to track me down and
> ==>applying RPF checking won't help.
> 
> I think the issue we need to tackle is ensuring that packets originate,
> at minimum, from the organization who holds the address space in the
> source address.

And i wish all telemarketers generated caller-id.  But the
lack of it doesn't mean i won't answer the phone.

> I'm happy getting it down to the organizational level (note that in a
> larger enterprise organization it may not even be to subnet level).  At
> least then we have an accountable party.

Exactly.  This isn't in attempt to stop all DoS attacks, just
help validate that when someone is attacking from the ip of www.example.com,
there will be a good chance that www.example.com is 0wned.

- jared

-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

RE: no ip forged-source-address

[Tony Hain]

Petri Helenius wrote:
> 
> > decides to attack, it would use some neighbor's IP.  The 
> subnet I am 
> > on is a /24 and there very well may be a few dozen hosts.  
> I could be 
> > real sneaky and alter my IP randomly to be any of my neighbors for 
> > every packet I send out.
> > 
> This gets a lot sneakier when you got your /64 on the subnet. 
> Specially 
> if people start to build significantly larger subnets by default.

Just stop. This nonsense about spoofing is easier because the IPv6
address space is bigger is bogus and wasting everyone's time. When each
customer is assigned a unique /48-/64 they are traceable to the
accountable entity no matter what low order bits they use. If they are
assigned something longer than a /64, they are likely to keep using
tunneling technologies like 6to4 until they can dump the provider that
is cluelessly hoarding a resource that is not scarce. 

Tony

RE: no ip forged-source-address

[H. Michael Smith, Jr.]

A fundamental effect of spoofing addresses from your local subnet is
that when the packets reach their target, the source addresses are
meaningful.  I realize that the traceability of these packets has
already been mentioned, but I want to point out the profound difference
between a DDoS attack with meaningful vs. meaningless source addresses.


-Original Message-
From: [EMAIL PROTECTED] [mailto:owner-nanog@;merit.edu] On Behalf Of
Hank Nussbacher
Sent: Wednesday, October 30, 2002 2:27 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: no ip forged-source-address


On Wed, 30 Oct 2002 [EMAIL PROTECTED] wrote:

If every router in the world did this I could still use spoofed IP
addresses and DDOS someone.  My little program could determine what
subnet
I am on, check what other hosts are alive on the subnet and then when it
decides to attack, it would use some neighbor's IP.  The subnet I am on
is
a /24 and there very well may be a few dozen hosts.  I could be real
sneaky and alter my IP randomly to be any of my neighbors for every
packet
I send out.

Traceback would get me instantly back to the offending subnet but then
it
would take a bit of digging on the network admin to track me down and
applying RPF checking won't help.

RPF checking can only go so far.  You would need RPF checking down to
the
host level and I haven't heard anyone discuss that yet.

-Hank

> 
> Hi,
> 
> I've been following the discussion on DDoS attacks over the last few
weeks
> and our network has also recently been the target of a sustained DDoS
> attack.I'm not alone in believing that source address filters are the
> simplest way to prevent the types of DDoS traffic that we have all
been
> seeing with increasing regularity.Reading the comments on this list
have
> lead me to believe that there is a lot of inertia involved in applying
> what appears to me as very simple filters.
> 
> As with the smurf attacks a few years ago, best practice documents and
> RFC's don't appear to be effective.I realise that configuring and
> applying a source address filter is trivial, but not enough network
admins
> seem to be taking the time to lock this down.If the equipment had
> sensible defaults (with the option to bypass them if required), then
> perhaps this would be less of an issue.
> 
> Therefore, would it be a reasonable suggestion to ask router vendors
to
> source address filtering in as an option[1] on the interface and then
move
> it to being the default setting[2] after a period of time?This
appeared
> to have some success with reducing the number of networks that
forwarded
> broadcast packets (as with "no ip directed-broadcast").
> 
> Just my $0.02,
> 
> 
> Richard Morrell
> edNET
> 
> [1] For example, an IOS config might be:
> 
> interface fastethernet 1/0
>  no ip forged-source-address
> 
> [2] Network admins would still have the option of turning it off, but
this
> would have to be explicitly configured.
> 
> 
> 

Re: no ip forged-source-address

[Daniel Senie]

At 12:09 PM 10/30/2002, you wrote:

 "daniel" == Daniel Senie <[EMAIL PROTECTED]> writes:

daniel> If the government or other large buyers require network-wide
daniel> ingress filtering in any supplier they buy from (something I
daniel> suggested to the folks at eBay, Schwab, etc. in our phone
daniel> calls after the attacks a few years ago), or if there were
daniel> legal incentive, there might be a chance ISPs would find a
daniel> financial motive to implement BCP 38. As it is, there's no
daniel> incentive, so the path of least resistance is to do nothing.

I find it interesting that you suggest that the legal incentive should
be toward having the ISPs come up with a magic solution and not toward
having the customers do egress filtering at the edge(s) of their
network and actually perform something resembling security on the
hosts on their networks.


What I suggested was a financial OR legal incentive.



After all, it is not usually a security failing of the ISP that causes
a DoS or DDoS attack, but utter incompetence or neglect by someone at
the edge of the network.


That's a question of perspective. Arguably both the ISP and the end user 
are responsible. The ISP is often in the role of managing the CPE router, 
and thereby has control over the router where ingress/egress filtering is 
most easily implemented with simple access control lists.

  The problem is that it's those same people
who have the money needed to keep the ISPs in business.  Unless
all ISPs decided to hold the customers responsible, they'd just move
to another ISP.


Or unless customers refuse to buy from anyone who doesn't do ingress 
filtering, resulting in a financial incentive for the ISP.


I'm not saying I don't think ISPs should filter where feasible, I'm
just saying that if we're going to hold someone responsible, it should
be the people who are responsible, not the people who are convenient.


I find it interesting that some ISPs have no trouble taking care of ingress 
filtering, while others bellyache about how hard and expensive it is. 
Another nanog participant commented ATT implemented this starting in 1995. 
A UUNet person was the most vocal opponent to the draft that became RFC 
2267 (over concern that the Cisco 7000's in use then would not handle the 
load). Six years later, ATT's network seems to do OK. Did UUNet ever do 
anything about it? Buy gear sized properly to do it? UUNet gives away 
2610's with leased lines. Do they come pre-configured to do ingress 
filtering even?

The question for the ISP is how it will defend itself when summoned to 
court. The ISP had the tools to ensure spoof attacks could not come from 
its network, yet chose not to. The customer likely would also face the 
negligence charge. The plaintiff would be the customer of another ISP whose 
business was severely injured. The question is whether you want to, in 
court, tell the judge "my customer was an idiot. Blame them, it's not my 
fault." You might even get away with it, but I suspect you would lose your 
customer base pretty quickly thereafter.

The S in ISP stands for SERVICE. You're providing a service to your 
customers. Helping those customers stay out of trouble, whether it's by 
selling them a firewall service, or managing their CPE router, or just 
providing ingress filtering, is part of what service is about.

I'm not surprised that major backbone providers still complain about 
ingress filtering. I am a bit surprised no lawsuits have get cited BCP 38.

Re: no ip forged-source-address

[Petri Helenius]

> decides to attack, it would use some neighbor's IP.  The subnet I am on is
> a /24 and there very well may be a few dozen hosts.  I could be real
> sneaky and alter my IP randomly to be any of my neighbors for every packet
> I send out.
> 
This gets a lot sneakier when you got your /64 on the subnet. Specially 
if people start to build significantly larger subnets by default.

Pete

Re: no ip forged-source-address

[Daniel Senie]

At 02:26 PM 10/30/2002, you wrote:


On Wed, 30 Oct 2002 [EMAIL PROTECTED] wrote:

If every router in the world did this I could still use spoofed IP
addresses and DDOS someone.  My little program could determine what subnet
I am on, check what other hosts are alive on the subnet and then when it
decides to attack, it would use some neighbor's IP.  The subnet I am on is
a /24 and there very well may be a few dozen hosts.  I could be real
sneaky and alter my IP randomly to be any of my neighbors for every packet
I send out.


And the company being attacked would be able to find out what network you 
are on.


Traceback would get me instantly back to the offending subnet but then it
would take a bit of digging on the network admin to track me down and
applying RPF checking won't help.


While that traceback is happening, your upstream ISP would be quite able to 
cut connectivity to your /24 while investigating which machine was causing 
the problem. It's a question of accountability. If that /24 is used by one 
company, it's now possible to know that company is your target when you 
file your court papers.


RPF checking can only go so far.  You would need RPF checking down to the
host level and I haven't heard anyone discuss that yet.


Getting to the subnet is sufficient bring the problem to the local entity 
involved. I think that's quite reasonable. If the /24 is a cable network, a 
packet analyzer in use by the local cable ISP will find the culprit.

-Hank

>
> Hi,
>
> I've been following the discussion on DDoS attacks over the last few weeks
> and our network has also recently been the target of a sustained DDoS
> attack.I'm not alone in believing that source address filters are the
> simplest way to prevent the types of DDoS traffic that we have all been
> seeing with increasing regularity.Reading the comments on this list have
> lead me to believe that there is a lot of inertia involved in applying
> what appears to me as very simple filters.
>
> As with the smurf attacks a few years ago, best practice documents and
> RFC's don't appear to be effective.I realise that configuring and
> applying a source address filter is trivial, but not enough network admins
> seem to be taking the time to lock this down.If the equipment had
> sensible defaults (with the option to bypass them if required), then
> perhaps this would be less of an issue.
>
> Therefore, would it be a reasonable suggestion to ask router vendors to
> source address filtering in as an option[1] on the interface and then move
> it to being the default setting[2] after a period of time?This appeared
> to have some success with reducing the number of networks that forwarded
> broadcast packets (as with "no ip directed-broadcast").
>
> Just my $0.02,
>
>
> Richard Morrell
> edNET
>
> [1] For example, an IOS config might be:
>
> interface fastethernet 1/0
>  no ip forged-source-address
>
> [2] Network admins would still have the option of turning it off, but this
> would have to be explicitly configured.
>
>
>

RE: no ip forged-source-address

[Daniel Senie]

At 12:29 PM 10/30/2002, Tony Hain wrote:


To reiterate the comment I made during the session yesterday, the places
where strict rpf will be most effective are at the very edge interfaces
without explicit management (SOHO). This also tends to be the place
where there is insufficient clue to turn it on.


This is also an area where NAT boxes are prevalent. One would HOPE the NAT 
boxes would take care of rejecting bogus source addresses sinec they do 
have to do translation on whatever comes in. So encouraging NAT boxes in 
the SOHO world is perhaps not so bad...

For the SOHO cases without NAT boxes, cable, dsl and dialup from a single 
computer, it would make a great deal of sense for the ISP to take care of 
this issue (in the cable head-end router, DSLAM, or NAS).

Re: no ip forged-source-address

[Craig A. Huegen]

On Wed, Oct 30, 2002 at 09:26:30PM +0200, Hank Nussbacher wrote:

==>Traceback would get me instantly back to the offending subnet but then it
==>would take a bit of digging on the network admin to track me down and
==>applying RPF checking won't help.

I think the issue we need to tackle is ensuring that packets originate,
at minimum, from the organization who holds the address space in the
source address.

I'm happy getting it down to the organizational level (note that in a
larger enterprise organization it may not even be to subnet level).  At
least then we have an accountable party.

/cah

Re: no ip forged-source-address

[Barney Wolff]

On Wed, Oct 30, 2002 at 09:26:30PM +0200, Hank Nussbacher wrote:
> 
> Traceback would get me instantly back to the offending subnet but then it
> would take a bit of digging on the network admin to track me down and
> applying RPF checking won't help.

Sure.  But do you really want to give up a 95% solution just because
it doesn't get you the last inch?  We have no solution that will do
that.  Being able instantly to identify the subnets from which DDoS
traffic is coming would make shutting off those subnets during the
attack possible*, and that in turn would motivate the subnet owners
to clean up their hosts.

* I suspect that an attack that actually comes from 1000 compromised
hosts does not come from nearly that many subnets.  Is there any data?

As a historical note, I put SAA in the filters for the ATT Worldnet
dialup network from its very start in 1995.  Work by smb on the
dangers of spoofed source addresses was already public then.  It's
long past time for the rest of the world to catch up.

-- 
Barney Wolff http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

Re: no ip forged-source-address

[Hank Nussbacher]

On Wed, 30 Oct 2002 [EMAIL PROTECTED] wrote:

If every router in the world did this I could still use spoofed IP
addresses and DDOS someone.  My little program could determine what subnet
I am on, check what other hosts are alive on the subnet and then when it
decides to attack, it would use some neighbor's IP.  The subnet I am on is
a /24 and there very well may be a few dozen hosts.  I could be real
sneaky and alter my IP randomly to be any of my neighbors for every packet
I send out.

Traceback would get me instantly back to the offending subnet but then it
would take a bit of digging on the network admin to track me down and
applying RPF checking won't help.

RPF checking can only go so far.  You would need RPF checking down to the
host level and I haven't heard anyone discuss that yet.

-Hank

> 
> Hi,
> 
> I've been following the discussion on DDoS attacks over the last few weeks
> and our network has also recently been the target of a sustained DDoS
> attack.I'm not alone in believing that source address filters are the
> simplest way to prevent the types of DDoS traffic that we have all been
> seeing with increasing regularity.Reading the comments on this list have
> lead me to believe that there is a lot of inertia involved in applying
> what appears to me as very simple filters.
> 
> As with the smurf attacks a few years ago, best practice documents and
> RFC's don't appear to be effective.I realise that configuring and
> applying a source address filter is trivial, but not enough network admins
> seem to be taking the time to lock this down.If the equipment had
> sensible defaults (with the option to bypass them if required), then
> perhaps this would be less of an issue.
> 
> Therefore, would it be a reasonable suggestion to ask router vendors to
> source address filtering in as an option[1] on the interface and then move
> it to being the default setting[2] after a period of time?This appeared
> to have some success with reducing the number of networks that forwarded
> broadcast packets (as with "no ip directed-broadcast").
> 
> Just my $0.02,
> 
> 
> Richard Morrell
> edNET
> 
> [1] For example, an IOS config might be:
> 
> interface fastethernet 1/0
>  no ip forged-source-address
> 
> [2] Network admins would still have the option of turning it off, but this
> would have to be explicitly configured.
> 
> 
> 

Re: no ip forged-source-address

[Jared Mauch]

On Wed, Oct 30, 2002 at 08:02:13PM +0100, Lars Erik Gullerud wrote:
> 
> On Wed, 2002-10-30 at 16:44, [EMAIL PROTECTED] wrote:
> 
> > Therefore, would it be a reasonable suggestion to ask router vendors to
> > source address filtering in as an option[1] on the interface and then move
> > it to being the default setting[2] after a period of time?  This appeared
> > to have some success with reducing the number of networks that forwarded
> > broadcast packets (as with "no ip directed-broadcast").
> [snip] 
> 
> > [1] For example, an IOS config might be:
> > 
> > interface fastethernet 1/0
> >  no ip forged-source-address
> 
> Well, this already exists, doesn't it? Try the following on your
> customer-facing interface:
> 
> ip verify unicast source reachable-via rx
> 
> > [2] Network admins would still have the option of turning it off, but this 
> > would have to be explicitly configured.
> 
> I have a feeling that having strict uRPF as the default setting on an
> interface would be very badly received by a lot of ISP's. I know I
> certainly wouldn't like it very much.
> 
> Is it really the job of router vendors to protect the net from
> lazy/incompetent/ignorant network admins?

No, but I can't enable these features on all
my router interfaces without causing delays/drops due to poor
inital design quality and lack of long-term vision for linecards
manufactured.

The rush for time-to-market can cause you to lose in
the long-term due to lack of features.

- jared

-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: no ip forged-source-address

[Lars Erik Gullerud]

On Wed, 2002-10-30 at 16:44, [EMAIL PROTECTED] wrote:

> Therefore, would it be a reasonable suggestion to ask router vendors to
> source address filtering in as an option[1] on the interface and then move
> it to being the default setting[2] after a period of time?  This appeared
> to have some success with reducing the number of networks that forwarded
> broadcast packets (as with "no ip directed-broadcast").
[snip] 

> [1] For example, an IOS config might be:
> 
> interface fastethernet 1/0
>  no ip forged-source-address

Well, this already exists, doesn't it? Try the following on your
customer-facing interface:

ip verify unicast source reachable-via rx

> [2] Network admins would still have the option of turning it off, but this 
> would have to be explicitly configured.

I have a feeling that having strict uRPF as the default setting on an
interface would be very badly received by a lot of ISP's. I know I
certainly wouldn't like it very much.

Is it really the job of router vendors to protect the net from
lazy/incompetent/ignorant network admins?

/leg

Re: no ip forged-source-address

[Jesper Skriver]

On Wed, Oct 30, 2002 at 06:02:44PM +, [EMAIL PROTECTED] wrote:
> On Wed, 30 Oct 2002, Jesper Skriver wrote:
> 
> > Cannot be done, I certainly doesn't want RPF check to be default enabled
> > on all interfaces on my routers, think for a second about asymmetric
> > routing WITHIN the ISP network.
> 
> Turn it off for backbone interfaces.

What's the difference then, the person who doesn't understand what it's
about will then just disable it throughout ...

The current solution about enabling it manually works fine.

/Jesper

-- 
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456
Senior network engineer @ AS3292, TDC Tele Danmark

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.

Re: no ip forged-source-address

[[EMAIL PROTECTED]]

On Wed, 30 Oct 2002, Jesper Skriver wrote:

> Cannot be done, I certainly doesn't want RPF check to be default enabled
> on all interfaces on my routers, think for a second about asymmetric
> routing WITHIN the ISP network.

Turn it off for backbone interfaces.

Regards,


Rich

RE: no ip forged-source-address

[Tony Hain]

To reiterate the comment I made during the session yesterday, the places
where strict rpf will be most effective are at the very edge interfaces
without explicit management (SOHO). This also tends to be the place
where there is insufficient clue to turn it on. One hopes that in the
nanog community there is sufficient clue to recognize the case where
having it on will create a problem and turn it off.

This has been a case where money has been talking, and those with enough
clue to comment on it are saying they don't want it, while those that
really need it are not asking. If the community believes this technique
is the best tool for regaining visibility into where attacks are coming
from, there are two explicit steps to making it happen. First, demand
that all vendors make it the default. Second, be willing to turn it off
rather than simply complain that it doesn't work in the ISP network. 

Tony 


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:owner-nanog@;merit.edu] On 
> Behalf Of [EMAIL PROTECTED]
> Sent: Wednesday, October 30, 2002 8:21 AM
> To: [EMAIL PROTECTED]
> Subject: Re: no ip forged-source-address
> 
> 
> 
> On Wed, 30 Oct 2002, Daniel Senie wrote:
> 
> > BCP 38 is quite explicit in the need for all networks to do their 
> > part. The
> > document is quite effective provided there's cooperation.
> 
> Doesn't seem to be working.
>  
> > Which interface would you filter on?
> 
> Customer ingress ports on the ISP side, which I suspect are 
> the majority of ports in ISP networks.  Hopefully engineers 
> on the backbone will be clueful enough to turn it off.
> 
> > If we're talking about a router at the customer premesis, 
> the filters 
> > should be on the link to the ISP (the customer may well have more 
> > subnets internally). At the ISP end, doing the filtering 
> you suggest 
> > would not work, since it'd permit only the IP addresses of the link 
> > between the customer and user.
> 
> The routing table of the router should be used to build up a list of 
> prefixes that you should see through the interface.  In this way, you 
> could apply it to BGP customers too without having to create 
> filters by 
> hand.
> 
> Regards,
> 
> 
> Rich
> 

Re: no ip forged-source-address

[Michael Lamoureux]

 "daniel" == Daniel Senie <[EMAIL PROTECTED]> writes:

daniel> If the government or other large buyers require network-wide
daniel> ingress filtering in any supplier they buy from (something I
daniel> suggested to the folks at eBay, Schwab, etc. in our phone
daniel> calls after the attacks a few years ago), or if there were
daniel> legal incentive, there might be a chance ISPs would find a
daniel> financial motive to implement BCP 38. As it is, there's no
daniel> incentive, so the path of least resistance is to do nothing.

I find it interesting that you suggest that the legal incentive should
be toward having the ISPs come up with a magic solution and not toward
having the customers do egress filtering at the edge(s) of their
network and actually perform something resembling security on the
hosts on their networks.

After all, it is not usually a security failing of the ISP that causes
a DoS or DDoS attack, but utter incompetence or neglect by someone at
the edge of the network.  The problem is that it's those same people
who have the money needed to keep the ISPs in business.  Unless
all ISPs decided to hold the customers responsible, they'd just move
to another ISP.

I'm not saying I don't think ISPs should filter where feasible, I'm
just saying that if we're going to hold someone responsible, it should
be the people who are responsible, not the people who are convenient.


but my opinions are probably worthless,
Michael

Re: no ip forged-source-address

[[EMAIL PROTECTED]]

On Wed, 30 Oct 2002, Daniel Senie wrote:

> BCP 38 is quite explicit in the need for all networks to do their part. The 
> document is quite effective provided there's cooperation.

Doesn't seem to be working.
 
> Which interface would you filter on? 

Customer ingress ports on the ISP side, which I suspect are the majority
of ports in ISP networks.  Hopefully engineers on the backbone will be
clueful enough to turn it off.

> If we're talking about a router at the customer premesis, the filters
> should be on the link to the ISP (the customer may well have more
> subnets internally). At the ISP end, doing the filtering you suggest
> would not work, since it'd permit only the IP addresses of the link
> between the customer and user.

The routing table of the router should be used to build up a list of 
prefixes that you should see through the interface.  In this way, you 
could apply it to BGP customers too without having to create filters by 
hand.

Regards,


Rich

Re: no ip forged-source-address

[Jesper Skriver]

On Wed, Oct 30, 2002 at 03:44:12PM +, [EMAIL PROTECTED] wrote:

> Therefore, would it be a reasonable suggestion to ask router vendors to
> source address filtering in as an option[1] on the interface and then move
> it to being the default setting[2] after a period of time?

Cannot be done, I certainly doesn't want RPF check to be default enabled
on all interfaces on my routers, think for a second about asymmetric
routing WITHIN the ISP network.

/Jesper

-- 
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456
Senior network engineer @ AS3292, TDC Tele Danmark

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.

Re: no ip forged-source-address

[Daniel Senie]

At 10:44 AM 10/30/2002, [EMAIL PROTECTED] wrote:


Hi,

I've been following the discussion on DDoS attacks over the last few weeks
and our network has also recently been the target of a sustained DDoS
attack.  I'm not alone in believing that source address filters are the
simplest way to prevent the types of DDoS traffic that we have all been
seeing with increasing regularity.  Reading the comments on this list have
lead me to believe that there is a lot of inertia involved in applying
what appears to me as very simple filters.

As with the smurf attacks a few years ago, best practice documents and
RFC's don't appear to be effective.


BCP 38 is quite explicit in the need for all networks to do their part. The 
document is quite effective provided there's cooperation.

 I realise that configuring and
applying a source address filter is trivial, but not enough network admins
seem to be taking the time to lock this down.  If the equipment had
sensible defaults (with the option to bypass them if required), then
perhaps this would be less of an issue.

Therefore, would it be a reasonable suggestion to ask router vendors to
source address filtering in as an option[1] on the interface and then move
it to being the default setting[2] after a period of time?  This appeared
to have some success with reducing the number of networks that forwarded
broadcast packets (as with "no ip directed-broadcast").


So you're suggesting the router vendors provide default configurations 
which the ISPs will overwrite with their current configurations anyway? 
Which interface would you filter on? If we're talking about a router at the 
customer premesis, the filters should be on the link to the ISP (the 
customer may well have more subnets internally). At the ISP end, doing the 
filtering you suggest would not work, since it'd permit only the IP 
addresses of the link between the customer and user.

For dialups, such filtering can and should be done, and should be automatic 
in the NAS boxes.

But the #1 question I have to ask you is, how are you going to have any 
more luck enforcing ingress filtering with what you propose, than what we 
have in the BCP on the subject?

If the government or other large buyers require network-wide ingress 
filtering in any supplier they buy from (something I suggested to the folks 
at eBay, Schwab, etc. in our phone calls after the attacks a few years 
ago), or if there were legal incentive, there might be a chance ISPs would 
find a financial motive to implement BCP 38. As it is, there's no 
incentive, so the path of least resistance is to do nothing.