Hi all, does it seem to anyone else in this space that several other
networks are filtering still on the 69.0.0.0 boundary? We have
69.1.64.0/20 and get filtered one in a while. SPecifically digitalisland
and turner broadcasting which seems to be part of ans net in arin which I
assume is
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
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
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, router A sees a
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
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 point?
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 inaccurate.
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
tell
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
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
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
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 the IP
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 do not
have a
On Tue, 08 Oct 2002 11:09:10 EDT, Sean Donelan said:
http://www.ipservices.att.com/backbone/techspecs.cfm
ATT has also implemented security features directly into the backbone.
IP Source Address Assurance is implemented at every customer
point-of-entry to guard against hackers.
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
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 with lots of
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 have a path
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 asymmetric
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 the
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
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-RIB-In
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 drop
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 routing
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
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 where its
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
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,
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
concern, I
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 bill
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 to do
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 internal
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 sense.
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 interface that do
* [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 from
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
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 UDP
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 it,
--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 the
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
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 this on all
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
59 matches
Mail list logo
