[ apologies for the long post ]
On 2003-03-11 19:57:04 +, [EMAIL PROTECTED] wrote:
Also, on a side rant hereWhy do all the RIR's have to give out
whois data in different, incompatible, referal-breaking formats?
The reason for the different formats is partly historical, and
partially
On Mon, 10 Mar 2003, Todd A. Blank wrote:
I continue to agree that moving critical resources (see below) to these
new blocks is the best approach I have seen or heard in the months since
I made the original post. This approach punishes the clueless instead
of the people that already know
From: Iljitsch van Beijnum
Fortunately, in this particular case there is a solution on the horizon:
S-BGP or soBGP. These BGP extensions authenticate all prefix
announcements, so there is no longer any need to perform bogon filtering
on routing information. uRPF can then be used to filter
Well Jon,
I spent some time reading your message below, and trying to look
at if I experienced the issue, just what I would have done differently, or
what would have been more meaningful in your initial email blast... Here
are some of my thoughts...
First since you are taking
Thanks for your support Jim. I've gotten mixed feedback to my proposal
here for a centralized bogon filter from the RIRs via BGP, but I will
say there's been more support than opposition. (Most of the support has
been sent to me, not the list, while most of the opposition has been
to the list,
On Tue, 11 Mar 2003, Jack Bates wrote:
Fortunately, in this particular case there is a solution on the horizon:
S-BGP or soBGP. These BGP extensions authenticate all prefix
announcements, so there is no longer any need to perform bogon filtering
on routing information. uRPF can then be
If all routes in the routing table are good (which soBGP and S-BGP can
do for you) and routers filter based on the contents of the routing
table, hosts will not see any bogon packets except locally generated
ones so they shouldn't have bogon filters of their own. So this will
indeed solve
Thus spake Ray Bellis [EMAIL PROTECTED]
Most people seem to think it would be impractical to put the root name
servers in 69.0.0.0/8
Why not persuade ARIN to put whois.arin.net in there instead? It
shouldn't take the people with the broken filters *too* long to figure
out why they can't do
On Tue, 11 Mar 2003, Peter Galbavy wrote:
If all routes in the routing table are good (which soBGP and S-BGP can
do for you) and routers filter based on the contents of the routing
table, hosts will not see any bogon packets except locally generated
ones so they shouldn't have bogon
On Mon, 10 Mar 2003, Ray Bellis wrote:
Most people seem to think it would be impractical to put the root name
servers in 69.0.0.0/8
Why not persuade ARIN to put whois.arin.net in there instead? It
shouldn't take the people with the broken filters *too* long to figure
out why they can't
From: Iljitsch van Beijnum
I don't see your point. Packets with bogon sources are just one class of
spoofed packets. As I've explained earlier S-BGP or soBGP with uRPF will
get rid of bogons. Neither this or bogon filters on the host will do
anything against non-bogon spoofed packets.
What surprises me most about this entire thread is the lack of centralized
filtering.
Since most service providers should be thinking about a sink hole network
for security auditing (and backscatter), why not have ONE place where you
advertise all unreachable, or better yet -- a default (ie
MS Date: Mon, 10 Mar 2003 10:27:35 -0500
MS From: Mark Segal
MS Since most service providers should be thinking about a sink
MS hole network for security auditing (and backscatter), why
MS not have ONE place where you advertise all unreachable, or
MS better yet -- a default (ie everything NOT
Since most service providers should be thinking about a sink hole network
for security auditing (and backscatter), why not have ONE place where you
advertise all unreachable, or better yet -- a default (ie everything NOT
learned through BGP peers), and just forward the packets to a bit
From: E.B. Dreger [mailto:[EMAIL PROTECTED]
The problem with only a default: Think when a rogue ISP
decides to advertise an unused netblock and utilize that IP
space for malicious purposes. A route exists... do we trust it?
But that kinda filtering should be done at BGP
Perhaps I should have been more clear on what I was saying.. Sorry about
that..
What I really meant by single pt. of failure was... problems of losing the
filtering list if the central system is down... Granted, this would not
cause any network issues..
-hc
On Mon, 10 Mar 2003, Mark Segal
On Monday, Mar 10, 2003, at 10:54 Canada/Eastern, Haesu wrote:
Since most service providers should be thinking about a sink hole
network
for security auditing (and backscatter), why not have ONE place
where you
advertise all unreachable, or better yet -- a default (ie everything
NOT
learned
On Mon, 10 Mar 2003, Mark Segal wrote:
What surprises me most about this entire thread is the lack of centralized
filtering.
Central as in 'ALL INTERNET USES MY FILTERING SERVICE' or... 'My network
uses my filter service and your network uses yours'?
Since most service providers should
interesting idea, enable it by default, with the option to turn it off
(i hope)...
my-big-fat-router# conf t
my-big-fat-router(config)# no ip clueless
Joe Abley [EMAIL PROTECTED] wrote:
On Monday, Mar 10, 2003, at 10:54 Canada/Eastern, Haesu wrote:
Since most service providers should
CLM Date: Mon, 10 Mar 2003 17:30:27 + (GMT)
CLM From: Christopher L. Morrow
CLM This can be VERY dangerous, the default part atleast. At one
CLM point we, as an experiment in stupidity (it turns out)
CLM announced 0/1 (almost default). We quickly recieved well
CLM over 600kpps to that
On Mon, 10 Mar 2003, E.B. Dreger wrote:
Now, how can we force that? Sufficient reward for doing so, or
pain for failure. Evidently some people can't reach you isn't
enough pain, and having full reachability isn't enough reward.
I think the only way that's relatively guaranteed to be
I don't think ARIN can help the situation. ISPs just need to remove
the
access lists from each router in the network and centralize them.
I totally agree with you. However, as always, centralized systems, while
ease management and scalability, everything becomes a trust issue and a
single
What I really meant by single pt. of failure was... problems of losing
the
filtering list if the central system is down... Granted, this would not
cause any network issues..
We know how to set up central authorities without central systems or
obvious single points of failure. For instance, the
Hi, NANOGers.
] But they all know what LDAP is...
I don't know that I'd say that. I'll bet they all are more familiar
with HTTP and DNS (both have bogon feeds available). I view LDAP as
yet another way to share the data, not the ultimate way to share the
data. I'm not trying to start a flame
I can think of two organisations which could probably take care of a
good chunk of the problem, if people were prepared to leave it up to
them. The routing system is already largely dependent on the
interoperability of bugs produced by these people, and so arguably no
additional trust would
Monday, March 10, 2003, 9:52:06 AM, you wrote:
jlo I think the only way that's relatively guaranteed to be effective is to
jlo move a critical resource (like the gtld-servers) into new IP blocks when
jlo previously reserved blocks are assigned to RIR's.
I agree with you. But then since I've
From: Mark Segal
Since most service providers should be thinking about a sink hole network
for security auditing (and backscatter), why not have ONE place where you
advertise all unreachable, or better yet -- a default (ie everything NOT
learned through BGP peers), and just forward the
CLM From: Christopher L. Morrow
CLM This can be VERY dangerous, the default part atleast. At one
CLM point we, as an experiment in stupidity (it turns out)
CLM announced 0/1 (almost default). We quickly recieved well
CLM over 600kpps to that announcement. This in a very steady
I saw it version of this earlier:
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#ip route clueless
No seriously..
What if that customer has a VPN design with a dial backup behind their firewall.
Using BGP to suck down a default route from the provider,
when that
From: McBurnett, Jim
No seriously..
What if that customer has a VPN design with a dial backup behind their
firewall.
Using BGP to suck down a default route from the provider,
when that default route goes away, then the internal router initiates the
dial
backup solution to the remote
SNIP
Oh, I agree that there are times when BGP is used in a single uplink
scenario, but it is not common. However, someone pointed me to
ip verify
unicast source reachable-via any which seems to be available
on some of the
cisco Service provider releases. It's an interesting concept
and I'm
Jon et al,
First I appreciate your message that you sent to us at NASA late Friday
regarding a new address block that you received from ARIN. In that message
you suggest that the issue was a BOGON route filter that had not been
updated. Then without allowing sufficient time to respond to your
BRG Date: Mon, 10 Mar 2003 11:17:55 -0800
BRG From: Barry Raveendran Greene
BRG EBD Announced via IGP or BGP? I hope/assume the former,
BRG EBD but am somewhat surprised at the traffic volume... even
BRG EBD for UUNet.
BRG I'm not surprised. My experience with defaults in ISPs is
BRG the
On Mon, 10 Mar 2003, Michael Whisenant wrote:
First I appreciate your message that you sent to us at NASA late Friday
regarding a new address block that you received from ARIN. In that message
you suggest that the issue was a BOGON route filter that had not been
updated. Then without
On Mon, Mar 10, 2003 at 01:39:26PM -0600, Jack Bates wrote:
Oh, I agree that there are times when BGP is used in a single uplink
scenario, but it is not common. However, someone pointed me to ip verify
unicast source reachable-via any which seems to be available on some of the
cisco Service
we should suggest that ARIN also host some of their stuff on this
block :-)
Todd
IPOutlet LLC
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, March 10, 2003 12:52 PM
To: E.B. Dreger
Cc: [EMAIL PROTECTED]
Subject: RE: 69/8...this sucks -- Centralizing
On Mon, Mar 10, 2003 at 08:28:23PM +, E.B. Dreger wrote:
Assuming one's upstreams and peers lack 'deny le 7'.
Can you point out where the rule is written that noone is to
announce a prefix with length le 7? Just we don't see it now
doesn't mean we won't see it sometime in the future...
On Mon, 10 Mar 2003, Todd A. Blank wrote:
I continue to agree that moving critical resources (see below) to these
new blocks is the best approach I have seen or heard in the months since
I made the original post. This approach punishes the clueless instead
of the people that already know
DR Date: Mon, 10 Mar 2003 23:10:35 +0100
DR From: Daniel Roesen
DR Can you point out where the rule is written that noone is to
DR announce a prefix with length le 7? Just we don't see it now
DR doesn't mean we won't see it sometime in the future...
Ditto ge 25. I might have missed the RFC
From: Simon Lyall
Could someone publish a name of a valid resource (or even pingable ip) in
69/8 space? This would allow people to test their (and their upsteams)
filters quickly while we wait for the list to come out.
The BrightNet nameservers are both in 69.8.2.0/24 for now.
On Tue, 11 Mar 2003, Simon Lyall wrote:
Could someone publish a name of a valid resource (or even pingable ip) in
69/8 space? This would allow people to test their (and their upsteams)
filters quickly while we wait for the list to come out.
69.atlantic.net (69.28.64.8) is a loopback on our
SL Date: Tue, 11 Mar 2003 11:28:55 +1300 (NZDT)
SL From: Simon Lyall
SL After this 69.0.0.0/8 thing is sorted out I guess we can move
SL the critical resources over to 202.0.0.0/7 to track down
SL all the idiots blocking that range (trying to decide if I
SL should put a smilie here).
Agree.
I
After this 69.0.0.0/8 thing is sorted out I guess
we can move the critical resources over to 202.0.0.0/7
to track down all the idiots blocking that range (trying
to decide if I should put a smilie here).
I nominate the arin.net nameservers.
Most people seem to think it would be
From: Ray Bellis
Why not persuade ARIN to put whois.arin.net in there instead? It
shouldn't take the people with the broken filters *too* long to figure
out why they can't do IP assignment lookups...
You are presuming that people are doing IP assignment lookups from the
affected network,
Once upon a time, Michael Whisenant [EMAIL PROTECTED] said:
You could reach MANY NASA locations, but those at one particular center,
and that issue was related to a firewall update at ONLY one particular
center. This filter was placed in after August when the cental bogon was
removed at the
From Chris Adams:
This isn't meant to be a pick on you (we've got some SWIPs filed
incorrectly that we are working on). I've just run into more and more
cases where ARIN (or other RIR, but I'm typically interested in ARIN
info) info is out of date. Maybe ARIN should periodically
send an
On Mon, 10 Mar 2003 23:19:38 -0500, McBurnett, Jim wrote:
If you read PPML, there is a HUGE push via Owen DeLong's Policy
2003-1a to help with some aspects of the whois Contact..
his policy is mainly based on the abuse contact, But I think may
get extended to all contacts eventually...
Owen-
47 matches
Mail list logo
