On Tue, 8 Oct 2002, Chris Wedgwood wrote:
> FWIW, almost nobody filters rfc1918 packets outbound and a good
> percentage of ISP customers bleed these something terrible
Actually, that's a good thing. This makes it trivial to detect which peers
aren't doing egress filtering. If people just filte
Let me see if I got this.
Route A:
unknown networks behind it
uses 10.10.10.2 as a neighbor to router B
Router B:
has a network 172.16.16/24
uses 10.10.10.1 as a neighbor to router A.
Router A's table shows
172.16.16/24 -> 10.10.10.2
You want Router
Please do NOT confuse PHYSICAL plumbing with LOGICAL plumbing.
Based on your description, router A and B ARE NOT on the same
broadcast domain, with respect to 172.16.16/24.
THey are on the same broadcast domain as 10.10.10.0/30
But thats it.
In otherwords, No it is NOT technically possibl
With the right MASK they could be local :)
On Mon, Oct 07, 2002 at 01:15:59AM +, Christopher L. Morrow wrote:
>
>
> On Sun, 6 Oct 2002, Ralph Doncaster wrote:
>
> >
> > > RD> When I setup a situation like the above, with Router B
> > > RD> advertising the 172.16.16.0/24 to router A, rou
Nope. As previously established, there are ISPs out there using RFC1918
networks in their infrastructure. Also, egress filtering is NOT easy, so
even those ISPs doing it may not be able to do it universally. Plus, lots
of attacks these days are mixing spoofed and legit traffic, or doing
limit
On Tuesday, Oct 8, 2002, at 10:21 Canada/Eastern, Kelly J. Cooper wrote:
> Nope. As previously established, there are ISPs out there using
> RFC1918
> networks in their infrastructure. Also, egress filtering is NOT easy,
What is difficult about dropping packets sourced from RFC1918 addresse
On Tue, 8 Oct 2002, Kelly J. Cooper wrote:
> Also, egress filtering is NOT easy,
I don't care. And it doesn't have to be egress filtering as such,
filtering packets you receive from your customers will work just as well.
> Plus, lots of attacks these days are mixing spoofed and legit traffic,
At 10:34 AM 08/10/2002 -0400, Joe Abley wrote:
>What is difficult about dropping packets sourced from RFC1918 addresses
>before they leave your network?
>
>I kind of assumed that people weren't doing it because they were lazy.
I am sure thats part of it. Also, it might be a CPU issue as well
Jason,
There're multiple answers depending on what you mean by "DNS server one
uses."
Whois on the domain will list the DNS servers of record. Some domains
also spread load over RNS servers so a dig, per a previous answer, will
give more specific announced servers currently in the zone files.
On Tue, 8 Oct 2002, Joe Abley wrote:
> Also, egress filtering is NOT easy,
> What is difficult about dropping packets sourced from RFC1918 addresses
> before they leave your network?
But what's the point?
That's like complaining that the door isn't locked while the house has no
walls.
>
> I am sure thats part of it. Also, it might be a CPU issue as well.
>
Unicast RPF is affordable CPU-wise even in the most mediocre
boxes people tend to have.
Pete
On Tuesday, Oct 8, 2002, at 10:45 Canada/Eastern, Iljitsch van Beijnum
wrote:
> On Tue, 8 Oct 2002, Joe Abley wrote:
>
>> Also, egress filtering is NOT easy,
>
>> What is difficult about dropping packets sourced from RFC1918
>> addresses
>> before they leave your network?
>
> But what's the p
On Tue, 8 Oct 2002, Joe Abley wrote:
> >> What is difficult about dropping packets sourced from RFC1918
> >> addresses before they leave your network?
> > But what's the point?
> Politeness, I guess. Seems rude to send traffic to peers when you
> absolutely know that the source address is inac
On Tue, 8 Oct 2002, Joe Abley wrote:
> What is difficult about dropping packets sourced from RFC1918 addresses
> before they leave your network?
>
> I kind of assumed that people weren't doing it because they were lazy.
I've checked the marketing stuff of several backbones, as far as I could
tel
IMHO, it's not too bad if you do it at your edges. Explicit
permits for valid source addrs is a well-known defense against
source spoofing which of course also addresses the RFC1918
leakage issue to some degree. It's not that hard to incorporate
this into customer installation and support proce
On Tue, Oct 08, 2002 at 11:09:10AM -0400, Sean Donelan wrote:
> If there is a magic solution, I would love to hear about it.
to drop the rfc1918 space, there is a close to magic
solution.
install this on all your internal, upstream, downstream
interfaces (cisco router) [cef requ
> If there is a magic solution, I would love to hear about it.
I strongly doubt any of the large providers perform dataplane source
address validation from peers. Heck, I doubt any perform explicit
route filtering on routes learned from peers at the control plane.
Ideally, one would first e
Hello,
If your company or a company that you know of provides dial-tone
service in 215/610/609 area codes and it is not Verizon, could you please
drop me a note off the list.
Should there be interest, I will post a summary.
Thanks,
Alex
--
> install this on all your internal, upstream, downstream
> interfaces (cisco router) [cef required]:
>
> "ip verify unicast source reachable-via any"
>
> This will drop all packets on the interface that do not
> have a way to return them in your routing table.
Of course, this is
On Tue, Oct 08, 2002 at 09:34:19AM -0600, Danny McPherson wrote:
>
>
> > install this on all your internal, upstream, downstream
> > interfaces (cisco router) [cef required]:
> >
> > "ip verify unicast source reachable-via any"
> >
> > This will drop all packets on the interface that
On Tue, 08 Oct 2002 11:09:10 EDT, Sean Donelan said:
> http://www.ipservices.att.com/backbone/techspecs.cfm
>
>AT&T has also implemented security features directly into the backbone.
>IP Source Address Assurance is implemented at every customer
>point-of-entry to guard against hacker
> > I am sure thats part of it. Also, it might be a CPU issue as well.
> >
> Unicast RPF is affordable CPU-wise even in the most mediocre
> boxes people tend to have.
In more cases than not, especially now adays with lots of networks
peering all over gods creation, RPF can have some pretty de
On Tue, 08 Oct 2002 09:34:19 MDT, Danny McPherson <[EMAIL PROTECTED]> said:
> > "ip verify unicast source reachable-via any"
> Of course, this is the IP RIB and may not include all the
> potential paths in the BGP Adj-RIBs-In, right? As such,
> you've still got the potential for asymmetric r
On Tue, Oct 08, 2002 at 11:52:27AM -0400, Jason Lixfeld wrote:
>
> > > I am sure thats part of it. Also, it might be a CPU issue as well.
> > >
> > Unicast RPF is affordable CPU-wise even in the most mediocre
> > boxes people tend to have.
>
> In more cases than not, especially now adays wit
On Tue, Oct 08, 2002 at 11:49:41AM -0400, Jared Mauch wrote:
> > Of course, this is the IP RIB and may not include all the
> > potential paths in the BGP Adj-RIBs-In, right? As such,
> > you've still got the potential for asymmetric routing to
> > break things.
>
> No, this is "if i ha
On Tue, Oct 08, 2002 at 12:09:56PM -0400, Jeff Aitken wrote:
> On Tue, Oct 08, 2002 at 11:49:41AM -0400, Jared Mauch wrote:
> > > Of course, this is the IP RIB and may not include all the
> > > potential paths in the BGP Adj-RIBs-In, right? As such,
> > > you've still got the potential for asy
> "reachable-via any" means you're only going to drop the packet if you
> don't have *ANY* route back to them.
What's a route? An IP RIB instance? A BGP Loc-RIB instance? An IGP LSDB
IP prefix entry? A BGP Adj-RIB-In instance?
I think you mean "if you don't have *ANY* **FIB** entry for th
There are two separate issues:
1. Making sure packets with falsified source addresses don't leave your
network
This can be done by having customer-specific filters on all
customer-facing interfaces. (And on interfaces connecting to any type of
hosts in case those are compromised.) Or use the pl
On Tue, Oct 08, 2002 at 10:15:28AM -0600, Danny McPherson wrote:
>
>
> > "reachable-via any" means you're only going to drop the packet if you
> > don't have *ANY* route back to them.
>
> What's a route? An IP RIB instance? A BGP Loc-RIB instance? An IGP LSDB
> IP prefix entry? A BGP Adj-
> Yes, but if i continue in my ideal situation of people
> (mostly) filter their bgp customers, so they won't announce the
> 1918 space, or similar. even the large peers filter out each other
> so they don't pick up 1918 announcements. Plus people use Robs
> "Secure IOS Template" to dr
On Tue, 8 Oct 2002, Jared Mauch wrote:
> install this on all your internal, upstream, downstream
> interfaces (cisco router) [cef required]:
>
> "ip verify unicast source reachable-via any"
>
> This will drop all packets on the interface that do not
> have a way to return them in your
Hello,
I am working for a service provider based in Europe that sells
Internet access, Hosting services,Metro Ethernet Transport
and IPSEC VPN (based on a mix of Cisco, Riverstone, and Nortel).
For the NMS, we are currently using HP OV
and public domain tools (MRTG, Netsaint, and some others)
I'd strongly recommend you look at SMARTS Incharge. http://www.smarts.com/
Its fantastic.
Regards,
Neil.
On Tue, 8 Oct 2002, Jason Lixfeld wrote:
> In more cases than not, especially now adays with lots of networks
> peering all over gods creation, RPF can have some pretty detrimental
> effects if your routing is somewhat asymmetrical.
actually RPF is extremely effective especially where its highly
> On Tue, 8 Oct 2002, Jason Lixfeld wrote:
> > In more cases than not, especially now adays with lots of networks
> > peering all over gods creation, RPF can have some pretty detrimental
> > effects if your routing is somewhat asymmetrical.
>
> actually RPF is extremely effective especially wher
It seems to reason that if people started filtering RFC-1918 on
their edge, we would see a noticable amount of traffic go away.
Simulation models I've been running show that an average of 12 to 18 percent
of a providers traffic would disappear if they filtered RFC-1918 sourced
packets. The pe
Those are reasons against.
We in the technical community need to develop or modify our tools to
make those tasks easier.
Hire a lazy but smart admin! :)
On Tue, Oct 08, 2002 at 02:45:22PM -0400, Jason Lixfeld wrote:
>
> > On Tue, 8 Oct 2002, Jason Lixfeld wrote:
> > > In more cases than not,
On Tue, 8 Oct 2002, Jason Lixfeld wrote:
> Sure, but to RPF so many customer facing edge ports in comparison to the
> far fewer number of egress ports makes the implementation procedure
> quite extensive. The more configuration, the more room for errors or
> "oops, forgot to configure that there
> Those are reasons against.
>
> We in the technical community need to develop or modify our tools to
> make those tasks easier.
My point, exactly.
> Hire a lazy but smart admin! :)
>
>
> On Tue, Oct 08, 2002 at 02:45:22PM -0400, Jason Lixfeld wrote:
> >
> > > On Tue, 8 Oct 2002, Jason Lixfe
> So why doesn't c.root-servers.net provider or its peers implement this
> "simple" solution? Its not a rhetorical question. If it was so simple,
> I assume they would have done it already. PSI wrote one of the original
> peering agreements that almost everyone else copied. If it was a
> conc
On Tue, 8 Oct 2002, John M. Brown wrote:
> It seems to reason that if people started filtering RFC-1918 on
> their edge, we would see a noticable amount of traffic go away.
> Simulation models I've been running show that an average of 12 to 18 percent
> of a providers traffic would disappear if
Why is it hard to believe that a large amount of RFC-1918 sourced
traffic is floating around the net?
Root name servers are just one "victim" of this trash. DOS, DDOS and
other just stupid configurations contribute to the pile.
My data is from various core servers, and various clients of ours
>
> In addition to the bandwidth savings, there is also a support cost
> reduction and together, I believe backbone providers can see this
> on the bottom line of their balance sheets.
If the backbone providers bill their customers for traffic, then filtering
out those packets would let them bi
On Tue, 8 Oct 2002, John M. Brown wrote:
> Why is it hard to believe that a large amount of RFC-1918 sourced
> traffic is floating around the net?
Because if 20% of all people generate this crap (which is a huge number)
it must be 90% of their traffic to get at 18%. How can someone generate so
On Tue, 8 Oct 2002 [EMAIL PROTECTED] wrote:
> They wont filter up until it would be more expensive not to filter.
Gross/Willfull negligence lawsuits? Im sure one of these days a large
corporation like ebay/m$/etc will be annoyed enough at backbone providers
spoof-DOSing them to file a lawsuit.
> > 2. Spoof filtering.
> > 3. Better tools to mitigate DOS/DDOS attacks. The technology exists
> >for say, cable providers to reduce port scans and DOS type attacks.
>
> I would happily kick anyone doing anything that is conclusively abusive
> off the net. But access providers aren't going
On Tue, 08 Oct 2002 22:06:12 +0200, Iljitsch van Beijnum said:
> Because if 20% of all people generate this crap (which is a huge number)
> it must be 90% of their traffic to get at 18%. How can someone generate so
> much useless traffic and keep doing it, too?
How much you want to bet that *all
At 11:51 AM 10/8/02 -0700, John M. Brown wrote:
>We in the technical community need to develop or modify our tools to
>make those tasks easier.
So right. I don't know what the fuss is all about. Not that our little ISP
matters in the grand scheme of things... but we've always blocked RFC1918
On Tue, 8 Oct 2002 [EMAIL PROTECTED] wrote:
> > Because if 20% of all people generate this crap (which is a huge number)
> > it must be 90% of their traffic to get at 18%. How can someone generate so
> > much useless traffic and keep doing it, too?
> How much you want to bet that *all* the inte
On Tue, 8 Oct 2002, Iljitsch van Beijnum wrote:
> Ok, but how do you generate megabits worth of traffic for which there is
> no return traffic?
spammers... smurfers... attackers...
> At some level, someone or something must be trying to do something
> _really hard_ but keep failing every time.
On Tue, 08 Oct 2002 22:57:42 +0200, Iljitsch van Beijnum said:
> Ok, but how do you generate megabits worth of traffic for which there is
> no return traffic? At some level, someone or something must be trying to
> do something _really hard_ but keep failing every time. It just doesn't
> make sen
On Tue, 8 Oct 2002, Sean Donelan wrote:
>
> On Tue, 8 Oct 2002, Jared Mauch wrote:
> > install this on all your internal, upstream, downstream
> > interfaces (cisco router) [cef required]:
> >
> > "ip verify unicast source reachable-via any"
> >
> > This will drop all packets on the in
* [EMAIL PROTECTED] (Neil J. McRae) [Tue 08 Oct 2002, 19:50 CEST]:
>
> I'd strongly recommend you look at SMARTS Incharge. http://www.smarts.com/
> Its fantastic.
Mostly. :-)
It's solid software, mostly. Not too secure (usernames and passwords
were only recently bolted on, and we all know fr
Irrd-discuss didn't have anything at all to say about this, so I thought
I'd bring it here for a different, practical perspective.
I'm wondering what the general concensus is with regards to IRR
implementation practices. I've done a little digging and have tried to
find practical exampl
>> What is difficult about dropping packets sourced from RFC1918 addresses
>> before they leave your network?
> But what's the point?
rfc 1918 sec 3
Because private addresses have no global meaning, routing information
about private networks shall not be propagated on inter-enterprise
At 10:34 PM 10/8/02 +0100, Stephen J. Wilcox wrote:
>Not all IP packets require a return, indeed only TCP requires it. It is quite
>possible to send data over the internet on UDP or ICMP with RFC1918 source
>addresses and for their to be no issue. Examples of this might be icmp
>fragments
>or UD
>> Why is it hard to believe that a large amount of RFC-1918 sourced
>> traffic is floating around the net?
> Because if 20% of all people generate this crap (which is a huge number)
> it must be 90% of their traffic to get at 18%. How can someone generate so
> much useless traffic and keep doing
--On Tuesday, October 8, 2002 2:56 PM -0600 Barb Dijker <[EMAIL PROTECTED]>
wrote:
...
> ISPs bill customers for traffic on the edge. If you filter one hop from
> the edge (interior of the edge router - fewer interfaces that way too) or
> at your border, then you can have your cake (money from
At 12:21 PM 10/6/2002, Ralph Doncaster wrote:
>I've already had several direct replies saying to manually configure the
>172.16 subnet on router A. Sure, that will work, but I'm looking for a
>solution that doesn't require manual configuration of all the routers
>involved.
Hey, where can I buy
Does anyone have any real references for Smarts? Seems like all they
have are partners and sales to companies that buy one of everything.
Any one willing to use their company email address and state that they
use Smarts? Saying that it is wonderful from bakker.net and domino.org
doesn't len
I believe the RFC states
SHALL NOT propigate these out to the global net.
SHOULD NOT != SHALL NOT
On Tue, Oct 08, 2002 at 10:34:51PM +0100, Stephen J. Wilcox wrote:
>
>
> On Tue, 8 Oct 2002, Sean Donelan wrote:
>
> >
> > On Tue, 8 Oct 2002, Jared Mauch wrote:
> > > install th
My question is this. The company I work for has a no spam policy.
Sometimes users do and of course we shut them off. My own feelings asside
its what is considered proper in the isp community so we do it with out
question. However, what is the best policy and procedure to prevent
people fr
Id post this to a different list.. NANOG has hashed spam to death
and its really no longer the place to post about it.
That aside
I'd set a policy and put it in your AUP, there is some legal
exposure for not doing that.
I'd also enforce your AUP equally each time, and you may wish
to put
[EMAIL PROTECTED] (Sean Donelan) writes:
> If there is a magic solution, I would love to hear about it.
>
> Unfortunately, the only solutions I've seen involve considerable work and
> resources to implement and maintain all the "exceptions" needed to do 100%
> source address validation.
I had
[EMAIL PROTECTED] (Sean Donelan) writes:
> If c.root-servers.net provider did this, they wouldn't see any RFC1918
> traffic because it would be dropped at their provider's border routers.
Right. But then I wouldn't be able to measure it, which would be bad.
> If c.root-servers.net provider's
65 matches
Mail list logo