On Thu, Aug 14, 2008 at 08:03:28AM +0200, Mikael Abrahamsson wrote:
On Wed, 13 Aug 2008, Mikael Abrahamsson wrote:
How do we hinder this in the short term? I know there are a lot of long
term solutions that very few is implementing, but would the fact that
these mistakes are brought up
Yes, I was getting delayed messages from AIM - iPhone and back as well.
(via sms)..
On Thu, Aug 14, 2008 at 8:39 AM, Jack Bates [EMAIL PROTECTED] wrote:
As near as we could tell, ATT doesn't support TAP, so we've been
looking at alternatives (like a GSM modem). However, if the problem is
My thoughts on the prefix filtering issue would be that we need some kind
of system that works along the same principles as DNSSEC and SPF, ie a
holder of IP space can publish that they would like everybody to filter
in a certain way for announcements for that perticular prefix, and
On Wed, Aug 13, 2008 at 05:14:43PM -0400, Patrick W. Gilmore wrote:
Saying something is Operational (and on-topic for nanog) does not mean
you should de-peer them.
If it's active and persistent, it would qualify as operational.
Then I can classify the risk. I'm openly wondering if
ok, i can not hold my tongue. sorry.
might there be a formally rigorous approach to this problem? we keep
having it. perhaps there is something solid and real we could do, as
opposed to temp hack after temp hack.
randy
On Wed, Aug 13, 2008 at 07:50:22PM -0700, Joel Jaeggli wrote:
Text sent too att customers appear ok from tmob or via @txt.att.net...
I'm experiencing ~10 minute delays on texts originating on att handsets.
I see intermittent but very regular delays myself from my Nextel
Blackberry (MMS, not
bottom line: the irr is a hack, not a formal solution.
rand
On Aug 14, 2008, at 9:02 AM, Randy Bush wrote:
bottom line: the irr is a hack, not a formal solution.
I don't think the IRR is so much a hack (it's a tool), but we're
lacking the process and infrastructure to vet/validate that a given
ASN is *authorized* to originate a prefix, and all of
-Original Message-
From: brett watson [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 14, 2008 12:47 PM
To: nanog@nanog.org
Subject: Re: Public shaming list for ISPs announcing other ISPs IP
space bymistake
On Aug 14, 2008, at 9:02 AM, Randy Bush wrote:
bottom line: the irr
Hi Randy,
.-- My secret spy satellite informs me that at Thu, 07 Aug 2008, Randy Bush
wrote:
serious curiosity:
what is the proportion of bad stuff coming from unallocated space vs
allocated space? real measurements, please. and are there longitudinal
data on this?
are the uw folk,
On Thu, Aug 14, 2008 at 11:47 AM, brett watson [EMAIL PROTECTED] wrote:
We're lacking the authority and delegation model that DNS has, I think?
Depends who you ask. Some think applying the dns model to bgp (i.e.
within protocol) will ultimately place too great a burden on routing
hardware
On Aug 14, 2008, at 9:47 AM, brett watson wrote:
We're lacking the authority and delegation model that DNS has, I
think?
If one were to ignore layer 9 politics, it could be argued the
authority/delegation models between DNS and address space are quite
analogous.
DNS:
IANA maintains .
but, why wouldn't something like formally requiring
customers/peers/transits/etc to have radb objects as a 'requirement'
for peering/customer bgp services
Step 1 : Enforce IRR for customers *now*.
Step 2 : Enforce trusted replacement for IRR when available
Step 3 : Profit
Not progressing
but, why wouldn't something like formally requiring
customers/peers/transits/etc to have radb objects as a 'requirement'
for peering/customer bgp services
'Cause there ain't nobody out there to formally require this.
Other than ISPs, of course. And that means there will be umpteen
different
I don't think the IRR is so much a hack (it's a tool), but
we're lacking the process and infrastructure to vet/validate
that a given ASN is *authorized* to originate a prefix, and
all of the policy bits (which the IRR has if you use it)
associated with which ASNs should propagate the
Step 1 : Enforce IRR for customers *now*.
Step 2 : Enforce trusted replacement for IRR when available
Step 3 : Profit
Not progressing to step 1 today because you think IRR isn't the best
solution is like not deploying IPv6 because you sat on your arse not
deploying it all these years
On Aug 14, 2008, at 11:13 AM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
ARIN holds the top of that authority and delegation hierarchy
because they give out the ASnums and IP address blocks.
And here I thought IANA handed out ASnums and IP address blocks to
ARIN (and RIPE and LACNIC and
On Thu, Aug 14, 2008 at 11:32:28AM -0700, brett watson wrote:
On Aug 14, 2008, at 11:21 AM, David Freedman wrote:
but, why wouldn't something like formally requiring
customers/peers/transits/etc to have radb objects as a 'requirement'
for peering/customer bgp services
Step 1 : Enforce IRR
On Thu, Aug 14, 2008 at 10:07:30AM -0700, Mike Leber wrote:
FYI. There was some question here about whether PowerDNS was vulnerable
or not and what it was doing, so I asked Bert Hubert about it. Here is
his answer:
And my additional nuance:
By the way - just to nuance things, I'm sure
On Aug 14, 2008, at 11:13 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
ARIN holds the top of that authority and delegation
hierarchy because
they give out the ASnums and IP address blocks.
And here I thought IANA handed out ASnums and IP address
blocks to ARIN (and RIPE and
On Aug 14, 2008, at 12:15 PM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
And here I thought IANA handed out ASnums and IP address
blocks to ARIN (and RIPE and LACNIC and AfriNIC and APNIC and
the IETF for specific protocol requirements)...
We are talking Internet operations, not Internet
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello, folks,
The United Kingdom's Centre for the Protection of National Infrastructure
has just released the document Security Assessment of the Internet
Protocol, on which I have had the pleasure to work during the last year or
so.
The
Hi NANOG,
Our research group at Carnegie Mellon has created a new tool called
Perspectives to help authenticate remote hosts without requiring a
full-blown PKI. Given the increased vulnerability to
man-in-the-middle attacks due to the recent DNS issue, this tool
seems relevant to anyone using
ARIN encourages eligible members of the internet community to take part in
nominating and electing candidates for its Board of Trustees, Advisory
Council, and representatives on the Number Resource Organization Number
Council. Please take the time to nominate qualified candidates for these
Pardon my ignorance here, but wouldn't it be much simpler if the so
called tier 1 networks were to do the filtering work so that none of
downstream BGP peers would see the bad announcements ?
If some network in italy sends out some bogus route for a site, this
should be blocked by a few tier 1
On Thu, 14 Aug 2008 22:42:04 -0400
Jean-Fran__ois Mezei [EMAIL PROTECTED] wrote:
Pardon my ignorance here, but wouldn't it be much simpler if the so
called tier 1 networks were to do the filtering work so that none of
downstream BGP peers would see the bad announcements ?
If some network in
On Aug 14, 2008, at 11:30 AM, David Conrad wrote:
On Aug 14, 2008, at 9:47 AM, brett watson wrote:
We're lacking the authority and delegation model that DNS has, I
think?
If one were to ignore layer 9 politics, it could be argued the
authority/delegation models between DNS and address
On Aug 14, 2008, at 1:09 PM, Jared Mauch wrote:
You're missing a step:
janitor.
No really, the reason for some leaks isn't because so-and-so was
never a customer, they were. 5 years ago. nobody removed the
routes from
the IRR or AS-SET or insert method here and
On Aug 14, 2008, at 8:42 PM, Jean-François Mezei wrote:
Pardon my ignorance here, but wouldn't it be much simpler if the so
called tier 1 networks were to do the filtering work so that none of
downstream BGP peers would see the bad announcements ?
If some network in italy sends out some bogus
A sneak-peek at some (NOT FINAL) relevant data points from
the *ongoing* Infrastructure Security Survey related to this topic
(see below for participation information, if so inclined).
Draw your own conclusions, we'll make ours known in the final
report.
-danny
---
Self classified respondent
On Aug 6, 2008, at 9:01 AM, Randy Bush wrote:
serious curiosity:
what is the proportion of bad stuff coming from unallocated space vs
allocated space? real measurements, please. and are there
longitudinal
data on this?
are the uw folk, gatech, vern, ... measuring?
Some data from our
bogon block attacks % of attacks
0.0.0.0/7 65 0.01
2.0.0.0/8 3 0.00
5.0.0.0/8 3 0.00
10.0.0.0/8 87941.21
23.0.0.0/8 4 0.00
27.0.0.0/8 7 0.00
92.0.0.0/6 101 0.01
100.0.0.0/6 374 0.05
104.0.0.0/5 303
On Aug 6, 2008, at 12:01 PM, Sean Donelan wrote:
Attacks or misconfigured leaks?
Leaks of RFC1918 stuff is pretty common, just ask any of the root
server operators how many packets they see from RFC1918 leaking
networks or do a
traceroute across several residential cable network
Danny,
On Aug 14, 2008, at 8:29 PM, Danny McPherson wrote:
On Aug 14, 2008, at 9:47 AM, brett watson wrote:
We're lacking the authority and delegation model that DNS has, I
think?
If one were to ignore layer 9 politics, it could be argued the
authority/delegation models between DNS and
On Thu, 14 Aug 2008, Brandon Butterworth wrote:
Herein is the value, the RIR (RIPE) is also the holder of the policy.
With ARIN, this is not the case, there is RADB and a number of other RR's
that are out there for varying reasons, some personal and some business.
Yes, RIPE rock.
On Aug 14, 2008, at 10:59 PM, David Conrad wrote:
Yep. IANA does indeed have a limited operational role in the DNS
(in that currently IANA directly operates .int, ip6.arpa, urn.arpa,
uri.arpa, and iris.arpa) and no direct operational role in routing.
Of course, the statement was about
Yes, RIPE rock. Please make it all not suck.
Unfortunately, RIPE DB will allow anyone to add any route objects for
prefixes that are not under the RIPE management :-(. For example,
anyone could add route objects for most of DNS root server prefixes.
Little details get used to avoid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -- Danny McPherson [EMAIL PROTECTED] wrote:
OK, so we were talking past one another. I agree with everything
you said above, and simply meant to highlight the fact that RPKI
validation will change things (quite necessarily, IMO), and folks
need to
On Aug 14, 2008, at 11:37 PM, Paul Ferguson wrote:
Okay, I admit I haven't paid the closest attention to RPKI, but I
have to ask: Is this a two-way shared-key issue, or (worse) a case
where we need to rely on a central entity to be a key clearinghouse?
The reason why I mention this is
39 matches
Mail list logo
