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? 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.
I could s
On Thu, 10 Oct 2002, Jared Mauch wrote:
[People using RFC 1918 addresses for routers that terminate tunnels which
breaks path MTU discovery when RFC 1918 source addresses are filtered
elsewere.]
> People number out of 1918 space primarily for a few
> reasons, be them good or not:
>
On Thu, 10 Oct 2002, Greg A. Woods wrote:
> [ On Thursday, October 10, 2002 at 11:53:18 (-0400), Richard A Steenbergen wrote: ]
> > Subject: Re: Who does source address validation? (was Re: what's that smell?)
> >
> >
> > I'm sure we can all agree on at le
Title: RE: Who does source address validation? (was Re: what's that smell?)
> -Original Message-
> From: Jared Mauch [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 10, 2002 12:59 PM
> To: Iljitsch van Beijnum
> Cc: Richard A Steenbergen; [EMAIL PROTECTED
On Thu, Oct 10, 2002 at 06:36:33PM +0200, Iljitsch van Beijnum wrote:
> So what then if someone runs a secure tunnel over wireless over a PPPoE
> over ADSL using mobile IPv6 that runs over a tunnel or two ad nauseum
> until the headers get bigger than 374 bytes? Then you'll have your problem
> ri
On Thu, 10 Oct 2002, Richard A Steenbergen wrote:
> Even Windows 2000+ includes blackhole detection which will eventually
> remove the DF bit if packets aren't getting through and ICMP messages
> aren't coming back, something many unixes lack.
Wow, now I'm impressed. And what about the 1999 oth
On Thu, Oct 10, 2002 at 01:06:15AM -0400, [EMAIL PROTECTED] wrote:
> On Wed, 09 Oct 2002 23:05:59 BST, "Stephen J. Wilcox" said:
>
> > On a related issue (pMTU) I recently discovered that using a link with MTU <
> > 1500 breaks a massive chunk of the net - specifically mail and webservers who
>
[EMAIL PROTECTED] wrote:
>
> My personal pet peeve is the opposite - we'll try to use pMTU, some
> provider
> along the way sees fit to run it through a tunnel, so the MTU there is
> 1460
> instead of 1500 - and the chuckleheads number the tunnel endpoints out
> of
> 1918 space - so the 'ICMP Fr
On Wed, 09 Oct 2002 23:05:59 BST, "Stephen J. Wilcox" said:
> On a related issue (pMTU) I recently discovered that using a link with MTU <
> 1500 breaks a massive chunk of the net - specifically mail and webservers who
> block all inbound icmp.. the servers assume 1500, send out the packets with
/swconfig55-interfaces.pdf
Cheers,
--
steve
Date:
Tue,
8 Oct 2002 12:29:48
-0400
From:
Jared Mauch
<[EMAIL PROTECTED]>
Subject:
Re: Who does source address validation? (was Re:
what's that smell?)
On
Tue,
Oct 08, 2002 at 10:15:28AM
-0600, Danny McPherson wrote:
>
>
&
> >>>would be interesting to hear details.
>
> >>Loss of ICMP packets generated by links with endpoints numbered in
> >>RFC1918
> >>space. Holes in traceroutes, broken PMTU detection.
>
> >Why do those links have endpoints in RFC1918 space to begin with?
> >
> >Alex
>
> Because some
On Wed, 9 Oct 2002 15:53:40 -0400 (EDT), [EMAIL PROTECTED] wrote:
>>>Do you have experience of such breakage from your own customers? It
>>>would be interesting to hear details.
>>Loss of ICMP packets generated by links with endpoints numbered in
>>RFC1918
>>space. Holes in traceroutes, br
On Wed, 9 Oct 2002, Joe Abley wrote:
>
>
> On Wednesday, Oct 9, 2002, at 11:36 Canada/Eastern, Stephen J. Wilcox
> wrote:
>
> > On Tue, 8 Oct 2002, Greg A. Woods wrote:
> >
> >> Such things REALLY _NEEED_ to be broken, and the sooner the better as
> >> then perhaps the offenders will fix suc
> Just out of interest how do you co-ordinate use of RFC 1918 addresses
> and routes amongst your customers? Do you run a registry for them, or
> do you just let them fight it out and the one with the biggest packets
> wins or something like that?
there's a registry. we also maintain IN-ADDR z
> >Do you have experience of such breakage from your own customers? It
> >would be interesting to hear details.
>
> Loss of ICMP packets generated by links with endpoints numbered in RFC1918
> space. Holes in traceroutes, broken PMTU detection.
Why do those links have endpoints in RFC1918
> Loss of ICMP packets generated by links with endpoints numbered in RFC1918
> space. Holes in traceroutes, broken PMTU detection.
Sherman, set the Way-Back Machine for August:
To: David Schwartz <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: NSPs filter?
In-reply-to:
On Wed, 9 Oct 2002, Joe Abley wrote:
> What services require transport of packets with RFC1918 source
> addresses across the public network?
>
> I can think of esoteric examples of things it would be possible to do,
> but nothing that a real-world user might need (or have occasion to
> complain
>>Ok but real world calling. I have tried this and when customers find
>>something
>>doesnt work on your network but it does on your competitor you make it
>>work even
>>if that means breaking rules.
>
>What services require transport of packets with RFC1918 source
>addresses across the public n
On Wednesday, Oct 9, 2002, at 11:36 Canada/Eastern, Stephen J. Wilcox
wrote:
> On Tue, 8 Oct 2002, Greg A. Woods wrote:
>
>> Such things REALLY _NEEED_ to be broken, and the sooner the better as
>> then perhaps the offenders will fix such things sooner too, because
>> they
>> are by definitio
On Tue, 8 Oct 2002, Greg A. Woods wrote:
> [ On Tuesday, October 8, 2002 at 22:34:51 (+0100), Stephen J. Wilcox wrote: ]
> > Subject: Re: Who does source address validation? (was Re: what's that smell?)
> >
> >
> > So I guess you may argue block RFC1918 tcp
On Tue, 8 Oct 2002, John M. Brown wrote:
> 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 percentage ranges scale with the size of the provider.
> Smaller providers, less impa
[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
[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
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
--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
>> 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
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
>> 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
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
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, 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, 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
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, 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
> > 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, 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.
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
>
> 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
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
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
> 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
> 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
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.
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,
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
> 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
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, 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
> 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, 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-
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
> "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
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
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 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, 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
> > 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 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
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
> 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
> 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
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
ubject: Who does source address validation? (was Re: what's that
> smell?)
>
>
>
> 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 assume
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
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 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
>
> 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 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.
PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Jason Lixfeld
Sent: Monday, October 07, 2002 4:15 PM
To: 'Dan Hollis'
Cc: 'Stephen J. Wilcox'; 'Paul Vixie'; [EMAIL PROTECTED]
Subject: RE: what's that smell?
Hope this doesn't come across as DNS-101, bu
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
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,
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
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 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
-BEGIN PGP SIGNED MESSAGE-
Hash: MD5
Hello Jason,
Monday, October 7, 2002, 7:14:41 PM, you wrote:
JL> Hope this doesn't come across as DNS-101, but is there some way to tell
JL> what DNS server one uses? Kinda like telnetting to port 80 or 25? I
JL> know if it is possible, it's just
27;Stephen J. Wilcox'; 'Paul Vixie'; [EMAIL PROTECTED]
> Subject: RE: what's that smell?
>
>
>
> On Mon, 7 Oct 2002, Jason Lixfeld wrote:
> > And to that end, I wonder how many of the bad queries are
> coming from MS
> > DNS servers.
>
>
On Mon, 7 Oct 2002, Jason Lixfeld wrote:
> And to that end, I wonder how many of the bad queries are coming from MS
> DNS servers.
to that end, i wonder how many of the bad queries are coming directly from
microsoft campus.
-Dan
--
[-] Omae no subete no kichi wa ore no mono da. [-]
OTECTED]
> Subject: Re: what's that smell?
>
>
>
> to that end why doesnt bind ship with default zone files for
> rfc1918 space as
> well as 127.0.0.0 ?
>
> Steve
>
>
> On Mon, 7 Oct 2002, Paul Vixie wrote:
>
> >
> > since the last time
to that end why doesnt bind ship with default zone files for rfc1918 space as
well as 127.0.0.0 ?
Steve
On Mon, 7 Oct 2002, Paul Vixie wrote:
>
> since the last time we cleared the firewall statistics on c.root-servers.net,
> 1895GB of udp/53 input has led to 6687GB of udp/53 output, but, an
79 matches
Mail list logo
