date:20101001

 -Original Message-
 From: Ronald F. Guilmette [mailto:r...@tristatelogic.com]
 Sent: Thursday, September 30, 2010 10:48 PM
 To: nanog@nanog.org
 Subject: Re: AS11296 -- Hijacked?

 63.247.172.3
   ns1.tooplacedomain10tht.info
 63.247.172.4
   ns2.tooplacedomain10tht.info
 63.247.181.3
   ns1.steadyvolumebandw57.info
 63.247.181.4
   ns2.steadyvolumebandw57.info
 63.247.185.19
   ns1.magnumfourcompkriel.info
 63.247.185.20
   ns2.magnumfourcompkriel.info

...

I would take more of an Occam's razor approach.  If you have an AS that
is supposedly an ISP in North Carolina or Ohio or wherever and first of
all have only one way into their network (are they an ISP or are they
simply reselling someone else's service?) and none of that connectivity
traces back to their region of operation, and particularly where their
name has been bought by or merged with someone else and that someone
else is not announcing their AS and address blocks, then that is
certainly cause for suspicion.Hijacking of defunct resources is
probably a widespread activity.  Finding the hijacked resources of
companies that liquidated in fairly public fashion is probably easier
than finding resources for a company that has been laundered through
several mergers over several years where the current company doesn't
even realize that they own the resources of a company bought by a
company they bought because of personnel turnover involved with layoffs
and such.

To the general population of this list:  Have you worked for a company
that has liquidated?  Are those Internet resource registrations still in
whois?  Maybe you should inform ARIN so those resources can be
reclaimed.  I did that when I noticed that a company I once worked for
that evaporated still had resources in the database.  That is just
ASKING for someone to announce those resources and nobody is probably
going to blink an eye because the upstreams rarely check to see if the
entity they are talking to are actually authorized to announce that
space.  You tell them the ASN and net blocks, the two jibe, upstream
says OK.  

How much address space is being wasted in this way?

G

Re: Using crypto auth for detecting corrupted IGP packets?

2010-10-01 Thread Dobbins, Roland


On Oct 1, 2010, at 11:07 AM, Manav Bhatia wrote:

 Buffering for 4-6 hours worth of control traffic is HUGE! 

If 4-6 hours of *control-plane* traffic on a given device is 'HUGE!', for some 
reasonable modern value of 'HUGE!', then there's definitely a problem on the 
network in question.

;

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

   Sell your computer and buy a guitar.

Re: Using crypto auth for detecting corrupted IGP packets?

2010-10-01 Thread Manav Bhatia


 Buffering for 4-6 hours worth of control traffic is HUGE!

 If 4-6 hours of *control-plane* traffic on a given device is 'HUGE!', for 
 some reasonable modern value of 'HUGE!', then there's definitely a problem on 
 the network in question.

With BFD alone (assuming 20 sessions, 50ms timer) you will have
400pps. In 6 hours you will have around 8000K BFD packets. Add OSPF,
RSVP, BGP, LACP (for lags), dot1AG, EFM and you would really get a
significant number of packets to buffer.

Cheers, Manav

Re: Using crypto auth for detecting corrupted IGP packets?

2010-10-01 Thread Dobbins, Roland


On Oct 1, 2010, at 1:01 PM, Manav Bhatia wrote:

  In 6 hours you will have around 8000K BFD packets. Add OSPF,
 RSVP, BGP, LACP (for lags), dot1AG, EFM and you would really get a
 significant number of packets to buffer.


Which isn't a 'HUGE!' amount of packets.

;

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

   Sell your computer and buy a guitar.

RE: First Data Corporation?

2010-10-01 Thread Ryan Finnesey

I am also looking for the same info.  Any luck finding a contact?
Cheers
Ryan

-Original Message-
From: Leo Woltz [mailto:leo.wo...@gmail.com] 
Sent: Wednesday, September 29, 2010 8:50 PM
To: nanog@nanog.org
Subject: First Data Corporation?

Anyone on the list from First Data Corporation or familar with there
network?

Re: (cisco, or any) acl reducers out there?

2010-10-01 Thread Andy Davidson


On 19 Aug 2010, at 04:23, George Michaelson wrote:

 something which can take a couple of hundred basic and extended ACLs and 
 tell you
 these ten don't work
 these twenty conflict
 the remaining x have a sequence and can reduce to this basic x-y set
 A reasonable call. Its probably where we'll be by default, because there 
 isn't anything there and I think first principles upward is better than 
 paring back.
 [...]
 I think its clear a tool like I asked doesn't exist, and very probably won't, 
 anytime soon.

Hello

[ I'm sorry this reply is so late, holiday season ]

I understand the problem and think that it is partly caused by the complexity 
of keeping the acl configuration on all edge ports in sync, and keeping the acl 
definitions/purpose documented.

The way around this, is to have a configuration management system that records 
the detail of the ACL (description / ticket number - along with the filter 
specification in generic terms), which generates the configuration - or even 
better uses flow-specification to distribute the rules.  Further procedures to 
review the data in this management system periodically help this scale.

For the config management, this would tend to have to be locally bespoke (but 
simple to produce) in order to fit with existing policy and procedure, but the 
glue to push these rules out to routers is easy as open source tools exist :- 
  
http://labs.ripe.net/Members/thomas_mangin/content-exabgp-new-tool-interact-bgp 
  http://bgp.exa.org.uk/

Andy

ARIN Fraud Reporting Form ... Don't waste your time


So ARIN put up on their web site this fancy schmancy web form that allows
a person to report fraud relating to ARIN number resources.  Here's what
the introduction to that page says, exactly as it appears on ARIN's web
site:

 This reporting process is to be used to notify ARIN of suspected
 Internet number resource abuse including the submission of falsified
 utilization or organization information, unauthorized changes to data
 in ARIN's WHOIS, hijacking of number resources in ARIN's database, or
 fraudulent transfers.

Well, that's what it says anyway.  And being naive, I actually believed that
the folks at ARIN might actually give a rat's ass about all these kinds of
fraud that they have enumerated above.  Boy was I wrong!

I just received the response attached below to one of my earlier reports using
that form.  And I gotta tell you, its an eye opener.

Apparently the fine folks at ARIN, clever bureaucrats that they are, have
subtly but substantially redefined the specific kinds of ``fraud'' they
care to hear about and/or investigate, so that contrary to the above, mere
hijacking of ASes or IP blocks isn't actually something that they want
to hear about, much less DO anything about.

Nope!  Apparently, ARIN's fraud reporting form is only to be used for
reporting cases where somebody has fiddled one of ARIN's whois records
in a fradulent way.  If somebody just waltzes in and starts announcing a
bunch of routes to a bunch of hijacked IP space from a hijacked ASN
(or two, or three) ARIN doesn't want to hear about it.  In those rare
cases where the perp is considerate enough to ALSO fiddle the relevant
WHOIS records in some fradulent way, THEN (apparently) ARIN will get
involved, but only to the extent of re-jiggering the WHOIS record(s).
Once that's been done, they will happily leave the perp to announce
all of the fradulent routes and hijacked space he wants, in perpetuity.

Apparently, they consider the hijacking itself as being totally out of
their charter to even look at or investigate.  ONLY if a WHOIS record
has been fiddled will they give a damn, and then the only one thing they
will give a damn about will be the WHOIS record... and the rest of the
net can go to hell, because hay!  Not our problem man!

Now I _know_ full well that by posting this rant here, the usual assortment
of knuckle-walker throwbacks who still yearn for the wonderful rule-less
frontier every-man-for-himself-and-no-sherrifs fun filled days of the
old 20th Century Internet, will pipe up immediately and say `Good!
Goddammit we don't want no steekin' ARIN to be ``policing'' anything
at all.  F**k that!  Total anarchy is the best of all possible systems.'

You know what?  I don't care.  Let them come.  Let them lumber around and
scream and pound their fists and try to tell me that because *I* didn't
get onto the Internet until 1983 (or because their router can beat up
my router) that they somehow magically outrank me, and that their opinions
are God and mine are worthless.  That's quite obviously horse shit.  How
do you have a pecking order anyway in a self-avowed anarchy?  Sorry, no.
The two are not compatible.  I've got as much right to an opinion as you
do.  And until proved otherwise, mine is as valid as your's.  And my
opinion is that this sucks.  ARIN's attitude sucks.  And they are apparently
redefining the word ``fraud'' in a way that will insure that they will
have to do minimal work, and that they'll never ever have to do anything
that might be ``hard'' in the sense of possibly being the lest bit contro-
versial, you know, like telling some hijacker ``Stop doing that.''

Yes, I'm sure that there are a lot of people here who will pipe up and say
that it's just wonderful that ARIN is useless and that ARIN will do nothing.
Their anachronistic anarchist philosophy is not a philosophy.  It's merely
an abdication of responsibility, and should be seen as such.  It is just
a lazy man's way of avoiding having to think about how a society should
be organized.  It is the coward's way of avoiding making rules that some
members of the group might find controversial.

On the net, hijacking of IP space is just about the deepest kind of
violation of the commonly accepted rules of how to behave in this shared
space that I can imagine.  And now, the people who _issue_ the IP space
assignments say that they don't care to _police_ the very assignments
that they themselves have made!  Well then what's the bleeping point of
even having them or their whole bloody allocation system then?  I say
let's disband the Federal Reserve *and* ARIN, because they are all just
a bunch of useless bureaucrats at this point who are serving nobody other
than themselves.  If we are going to have anarchy, then bring it on!
Let's not have this half-assed sort of anarchy that we have now.  Let's
have the real thing!  I'm going out tomorrow and I'm going to buy me the
biggest router than I can afford.  Then I'm going to get it colocated

Re: RIP Justification


On Sep 30, 2010, at 6:56 AM, Jack Bates wrote:

 On 9/30/2010 8:46 AM, Owen DeLong wrote:
 I have no NAT whatsoever in my home network. RIP is not at all useful in my 
 scenario.
 
 I have multiple routers in my home network. They use a combination of BGP 
 and OSPFv3.
 
 
 Except you must configure those things. The average home user cannot.
 
The average home user cannot configure RIP. What is your point?

 If your network is of a scale where it exceeds the utility of static, then, 
 it is almost certainly of a scale
 and topology where it exceeds the utility of RIP.
 
 While it is possible for a router to create static routes automatically based 
 on DHCPv6 assignment information, this has no loop prevention and is 
 suboptimal depending on the configuration that things get plugged in. I'm not 
 talking good network design here. I'm talking, buy box, plug in wherever it 
 fits. Things should work.
 
RIP has no loop prevention and is suboptimal depending on the configuration
that things get plugged in.

RIP breaks more often than DHCP in my experience.

Owen

Re: Using crypto auth for detecting corrupted IGP packets?

2010-10-01 Thread John Kristoff

On Fri, 1 Oct 2010 00:25:34 -0400
Jared Mauch ja...@puck.nether.net wrote:

 I really wish there was a good way to (generically) keep a 4-6 hour
 buffer of all control-plane traffic on devices. While you can do that
 with some, the forensic value is immense when you have a problem.

Not precisely what you're looking for, but you can monitor the OSPF
database in other ways.  See some of early OSPF work described here for
instance:

  http://www2.research.att.com/~ashaikh/presentations.php

I had written a simple utility to grab the LSA counts and checksum
values from a set of routers.when I converted a RIP network to OSPF.
The network consisted of about 25 routers and 300 routes.  It was
invaluable to as a sanity check to see if all routers were in
agreement.

Packet Design's Route Explorer may be a commercial implementation of
this sort of thing.  I've only an early version of that at an earlier
NANOG and have never used it.  It seemed like cool technology at the
time, but don't take that as an endorsement.

Ob op note: I do recall one older IOS router where it would never have
exactly the same checksum values as the other. After manually
inspecting the routes I had concluded that it was an artifact of the
IOS code being run, which was an old 11.x train and the only one in the
net at the time.

John

Re: ATT Dry Pairs?

Try asking for one of the following:

1.  Farmer Line
2.  Alarm Circuit

I think there are a few other ways to ask for a dry pair that might circumvent
the limited know-how of the people you are talking to, but, I don't recall
them off the top of my head.

Owen

On Sep 30, 2010, at 1:52 PM, Brandon Galbraith wrote:

 Has anyone had any luck lately getting dry pairs from ATT? I'm in the
 Chicago area attempting to get a dry pair between two buildings (100ft
 apart) for some equipment, but when speaking to several folks at ATT the
 response I get is You want ATT service without the service? That's not
 logical!. Had no problems 3-4 years ago getting these sorts of circuits,
 but it appears it's gone the way of the dodo now. Any emails off-list are
 appreciated.
 
 -- 
 Brandon Galbraith
 US Voice: 630.492.0464

Re: RIP Justification


On Sep 30, 2010, at 3:47 PM, Heath Jones wrote:

 On 30 September 2010 22:11, Jack Carrozzo j...@crepinc.com wrote:
 As it was explained to me, the main difference is that you can have $lots of
 prefixes in IS-IS without it falling over, whereas Dijkstra is far more
 resource-intensive and as such OSPF doesn't get too happy after $a_lot_less
 prefixes. Those numbers can be debated as you like, but I think if you were
 to redist bgp ospf on a lab machine you'd get the point.
 
 Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because
 of the ISO addressing. Atleast thats my take on it..
 
 RIPv2 is great for simple route injection. I'm talking really simple,
 just to avoid statics.

And there, my friend, is the crux of the matter. There's almost no place
imagineable where injecting routes from RIPv2 is superior to statics.

Owen

Re: RIP Justification

Why would you run dynamic to simple CPE at all?

Static route that stuff through DHCP or RADIUS and move on.

If you need dynamic routing across administrative boundaries, that's not a good 
place
for RIP, that's a good place for BGP.

Owen

On Sep 30, 2010, at 5:54 PM, Guerra, Ruben wrote:

 I am with Scott on this one.. I took the initial question as a focus on the 
 edge... not the CORE. RIP is perfect for the edge to commercial CPEs. Why 
 would want to run OSPF/ISIS at the edge. I would hope that it would be common 
 practice to not use RIP in the CORE
 
 peace
 --
 Ruben Guerra
 - Sent from my Nokia N900
 
 - Original message -
 Haha It's all good :)
 You are right about IS-IS being less resource intensive than OSPF, and
 that it scales better!
 
 
 
 On 30 September 2010 23:50, Jack Carrozzo 
 j...@crepinc.commailto:j...@crepinc.com wrote:
 
 
 Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because
 of the ISO addressing. Atleast thats my take on it..
 
 Sorry, my mistake. I'll go sit in my corner now...
 -Jack

Re: ARIN Fraud Reporting Form ... Don't waste your time

Ronald,

It's not so much a matter of whether ARIN cares or whether ARIN wants
to do something about your issue. It's more a matter of whether ARIN
is empowered to do anything at all about your issue.

ARIN is a registry. They don't run routers (outside of a small handfull
of them that provide certain ARIN infrastructure). They have no control
over BGP, the routing table, or anything that would be able to do anything
about your particular brand of issue.

What they can do something about is, indeed, things that got into the
registry data through fraud, deceit, error, omission, or other unintended
mechanism.

I'm sorry you're not satisfied with that fact. I'm sorry that you are obviously
clearly very upset by this experience. However, I think your issue stems
from a fundamental misunderstanding of the role ARIN plays in the
community vs. that of the ISPs.

It's kind of like asking a DMV representative to arrest an auto thief.
ARIN does registrations. They aren't the internet police.

Owen

On Oct 1, 2010, at 2:22 AM, Ronald F. Guilmette wrote:

 
 So ARIN put up on their web site this fancy schmancy web form that allows
 a person to report fraud relating to ARIN number resources.  Here's what
 the introduction to that page says, exactly as it appears on ARIN's web
 site:
 
 This reporting process is to be used to notify ARIN of suspected
 Internet number resource abuse including the submission of falsified
 utilization or organization information, unauthorized changes to data
 in ARIN's WHOIS, hijacking of number resources in ARIN's database, or
 fraudulent transfers.
 
 Well, that's what it says anyway.  And being naive, I actually believed that
 the folks at ARIN might actually give a rat's ass about all these kinds of
 fraud that they have enumerated above.  Boy was I wrong!
 
 I just received the response attached below to one of my earlier reports using
 that form.  And I gotta tell you, its an eye opener.
 
 Apparently the fine folks at ARIN, clever bureaucrats that they are, have
 subtly but substantially redefined the specific kinds of ``fraud'' they
 care to hear about and/or investigate, so that contrary to the above, mere
 hijacking of ASes or IP blocks isn't actually something that they want
 to hear about, much less DO anything about.
 
 Nope!  Apparently, ARIN's fraud reporting form is only to be used for
 reporting cases where somebody has fiddled one of ARIN's whois records
 in a fradulent way.  If somebody just waltzes in and starts announcing a
 bunch of routes to a bunch of hijacked IP space from a hijacked ASN
 (or two, or three) ARIN doesn't want to hear about it.  In those rare
 cases where the perp is considerate enough to ALSO fiddle the relevant
 WHOIS records in some fradulent way, THEN (apparently) ARIN will get
 involved, but only to the extent of re-jiggering the WHOIS record(s).
 Once that's been done, they will happily leave the perp to announce
 all of the fradulent routes and hijacked space he wants, in perpetuity.
 
 Apparently, they consider the hijacking itself as being totally out of
 their charter to even look at or investigate.  ONLY if a WHOIS record
 has been fiddled will they give a damn, and then the only one thing they
 will give a damn about will be the WHOIS record... and the rest of the
 net can go to hell, because hay!  Not our problem man!
 
 Now I _know_ full well that by posting this rant here, the usual assortment
 of knuckle-walker throwbacks who still yearn for the wonderful rule-less
 frontier every-man-for-himself-and-no-sherrifs fun filled days of the
 old 20th Century Internet, will pipe up immediately and say `Good!
 Goddammit we don't want no steekin' ARIN to be ``policing'' anything
 at all.  F**k that!  Total anarchy is the best of all possible systems.'
 
 You know what?  I don't care.  Let them come.  Let them lumber around and
 scream and pound their fists and try to tell me that because *I* didn't
 get onto the Internet until 1983 (or because their router can beat up
 my router) that they somehow magically outrank me, and that their opinions
 are God and mine are worthless.  That's quite obviously horse shit.  How
 do you have a pecking order anyway in a self-avowed anarchy?  Sorry, no.
 The two are not compatible.  I've got as much right to an opinion as you
 do.  And until proved otherwise, mine is as valid as your's.  And my
 opinion is that this sucks.  ARIN's attitude sucks.  And they are apparently
 redefining the word ``fraud'' in a way that will insure that they will
 have to do minimal work, and that they'll never ever have to do anything
 that might be ``hard'' in the sense of possibly being the lest bit contro-
 versial, you know, like telling some hijacker ``Stop doing that.''
 
 Yes, I'm sure that there are a lot of people here who will pipe up and say
 that it's just wonderful that ARIN is useless and that ARIN will do nothing.
 Their anachronistic anarchist philosophy is not a philosophy.  It's merely
 an

Re: AS11296 -- Hijacked?

On 1 October 2010 06:47, Ronald F. Guilmette r...@tristatelogic.com wrote:
 I hope this may ally some of the concern that has been expressed
 about me not being more forthcomeing about the details of this case.

Cheers Ron for coming forth with your reasoning, it is appreciated.
Your bit of trust in me/us has gone a long way, and its good to
understand your motivation and how you came to your conclusions.

I'm actually quite surprised that you have found so much spam coming
out of the US! I would have thought less developed countries where its
easy to obtain unregulated connections, with little legal repercussion
would be more popular. Then again, I personally have not done a lot of
research in the field.


Good luck with your endeavour.
Heath

Re: RIP Justification

 RIPv2 is great for simple route injection. I'm talking really simple,
 just to avoid statics.

 And there, my friend, is the crux of the matter. There's almost no place
 imagineable where injecting routes from RIPv2 is superior to statics.

Well, let me stimulate your imagination..

IPVPN cloud provided by carrier.
Head office is ethernet into cloud.
Remote sites are DSL, so terminating on LNS within cloud, and have one
or more prefixes behind CPE. Pretty simple stuff.

Now, when traffic comes from head office destined for a site prefix,
it hits the provider gear. That provider gear will need routing
information to head to a particular site. If you wanted to use
statics, you will need to fill out a form each time you add/remove a
prefix for a site and the provider must manage that. Its called a
'pain in the arse'.

Enter RIPv2.

Re: ARIN Fraud Reporting Form ... Don't waste your time


In message b3543192-fb22-4cdc-84d0-2944ea237...@delong.com, 
Owen DeLong o...@delong.com wrote:

It's not so much a matter of whether ARIN cares or whether ARIN wants
to do something about your issue. It's more a matter of whether ARIN
is empowered to do anything at all about your issue.

That is complete and utter horse shit, and you're just dodging the real
issue by trying to change the subject.  It isn't going to work.  People,
even people here, may be stupid, but I think that most can recognize sleight
of hand when they see it.

I'm sorry you're not satisfied with that fact. I'm sorry that you are =
obviously
clearly very upset by this experience. However, I think your issue stems
from a fundamental misunderstanding of the role ARIN plays in the
community vs. that of the ISPs.

No, it doesn't.  I think that *your* issue stems from a fundamental inability
to read what I wrote.

It's kind of like asking a DMV representative to arrest an auto thief.

No, it's kind of like asking the DMV whether the car belongs to the thief
or to someone else.  They keep the records for Christ's sake!  They *can*
take a position on that rudumentary, simple, and basic question, and they
should.  And that is all I ask or expect them to do.  But they don't
even want to do that miniscule amount of work, apparently.  They want to
be the Keeper of the Records, but then they want to roll over and play
dead, or ignorant, or agnostic, whenever somebody has the temerrity to
simply ask them what the f**king records they are keeping *mean* about
who actually owns what.

I already said it, but I'll say it again for the benefit of those with
low reading comprehension.  Nobody is asking ARIN to go out, with guns
drawn, and pull the plug themselves.  But they can and should take a
position on who owns what.  That is a judicial function, not a police
function.  If you don't understand the distinction, then you are dumber
than you think I think you are.


Regards,
rfg

Re: BGP next-hop

 Section 9.1.2.1 of RFC 4271 seems to address this.
 A few points from that section:
  - The BGP NEXT_HOP can not recursively resolve (directly or indirectly) 
 through the BGP route.
  - Only the longest matching route should be considered when resolving the 
 BGP NEXT_HOP.
  - Do not consider feasible routes that would become unresolvable if they 
 were installed.

There are 2 ways of reading that.. Perhaps i'll go and look at the it
in more details.
I'm trying to think of a scenario where following this or something
similar would break it:
- Don't use BGP prefixes to resolve next-hop.
- You can use 0/0 or any route with a lower administrative distance to
resolve the next-top.

With that in mind, I wonder if it works with Juniper (ad = 170 vs 20
from memory)..

Re: RIP Justification

2010-10-01 Thread Tim Franklin

 Now, when traffic comes from head office destined for a site prefix,
 it hits the provider gear. That provider gear will need routing
 information to head to a particular site. If you wanted to use
 statics, you will need to fill out a form each time you add/remove a
 prefix for a site and the provider must manage that. Its called a
 'pain in the arse'.
 
 Enter RIPv2.

Or BGP.  Why not?

Re: Using crypto auth for detecting corrupted IGP packets?

2010-10-01 Thread Jared Mauch


On Oct 1, 2010, at 3:49 AM, Dobbins, Roland wrote:

 
 On Oct 1, 2010, at 1:01 PM, Manav Bhatia wrote:
 
 In 6 hours you will have around 8000K BFD packets. Add OSPF,
 RSVP, BGP, LACP (for lags), dot1AG, EFM and you would really get a
 significant number of packets to buffer.
 
 
 Which isn't a 'HUGE!' amount of packets.
 
 ;


Yup, but when trying to figure out the root cause of some problem, having a few 
gigs of data would be helpful.

In the event people have not noticed, hard drives are semi-popular in routers 
now, so assuming you have some variable amount of disk space greater than 8MB 
for an image is feasible.

- Jared

Re: ARIN Fraud Reporting Form ... Don't waste your time

Come one mate, there's no need to be just outright insulting people.
Sure everyone disagrees on some things, but still...

Lets play out this scenario then. What would you recommend ARIN actually do?
I don't mean 'take a stance' or 'have an opinion', but rather what
process should in your mind they be following?

There are still other avenues. I mentioned in a previous email about
IETF or a working group to come up with ideas and methods to combat
spam and abuse. If you put as much time into one of them as you do
fighting with the spammers directly and ARIN, then you might actually
end up solving the problem at the core!

I really don't want to drag this anti-spam stuff out. There's been a
huge amount of posting these last few days over this (of which I am a
culprit also), but I do think its valuable to hit this nail on the
head. In other words, perhaps other people on this list are getting a
bit fed up with it, so lets just sort it out and quickly..

Re: RIP Justification

On 1 October 2010 12:19, Tim Franklin t...@pelican.org wrote:
 Or BGP.  Why not?

Of course, technically you could use almost any routing protocol.
OSPF and IS-IS would require more configuration and maintenance, BGP
even more still.

I think this is a pretty good example though of how RIPv2 is probably
the most appropriate for the job. It doesnt require further
configuration from the provider side as new sites are added and is
very simple to set up and maintain.

Re: AS11296 -- Hijacked?

2010-10-01 Thread Rich Kulawiec

On Thu, Sep 30, 2010 at 11:34:16PM -0700, George Bonser wrote:
 Hijacking of defunct resources is probably a widespread activity.

It is.  A number of individuals and entities have been involved in
tracking these over the years, and I've seen enough to figure out
that it's common because it's relatively easy, it's likely to be
undetected, it's likely to be ignored if detected, there are no
significant penalties, and even if it all goes south: it's easy
to start over and do it again.

 How much address space is being wasted in this way?

A lot.  Moreover, large chunks of address space are being wasted in this way:

1. Spammer sets up dummy front web-hosting/ISP company.
1a. (optional) Spammer sets up second-level dummy front.
2. Spammer gets ARIN et.al. to allocate a /20 or a /17 or whatever.
3. Spammer uses spammer-friendly registrar to purchase
   throwaway domains in bulk.  (Sometimes the registrar IS
   the spammer.  Cost-effective.)
4. Spammer populates the allocation with throwaway domains
   and commences snowshoe spamming.
4a. (optional) Spamming facilitates drive-by downloads, malware
injection, browser exploits, phishing, and other attacks.
5. Anti-spam resources notice this and blacklist the allocation.
   So do large numbers of individual network/system/mail admins.
6. Return to step 1.

It's instructive to consider who profits from each of these steps.

A quick check of my (local, incomplete, barely scratch-the-surface) list
of such things includes (and I've left out smaller and larger blocks,
thus this is a pretty much a snapshot of the middle of the curve):

/16's: 25
/17's: 20
/18's: 47
/19's: 73
/20's: 99
/21's: 88
/22's: 105
/23's: 198
/24's: 3245

for a total of about 6.6 million IP addresses.  My guess is that this
is likely a few percent, at best, of the real total: it just happens
to be the set that brought itself to my attention by being sufficiently
annoying to local resources.  So I wouldn't be at all surprised to find
that real total is in the 100M ballpark.

So I've concluded that there really isn't an IPv4 address space shortage.
Spammers have absolutely no problem getting allocation after allocation
after allocation, turning each one into scorched earth and moving on.
ARIN et.al. certainly have no interest in stopping them, and ICANN only
cares about registrar profits, so there's no help coming from either
of those.

---rsk

RE: Frontier DSL Contact

2010-10-01 Thread Tony Bunce

Thanks to everyone that contacted me off-list.

I was able to get the issue resolved with Frontier's help.

-Tony

Re: ARIN Fraud Reporting Form ... Don't waste your time

2010-10-01 Thread Jeffrey Lyon

I sent an abuse complaint to Mr. Curran and the abuse helpdesk about a
month or two ago. Took weeks to get an initial response from the
helpdesk and i'm not certain they have actually done anything yet.

Jeff


On Fri, Oct 1, 2010 at 3:58 PM, Heath Jones hj1...@gmail.com wrote:
 Come one mate, there's no need to be just outright insulting people.
 Sure everyone disagrees on some things, but still...

 Lets play out this scenario then. What would you recommend ARIN actually do?
 I don't mean 'take a stance' or 'have an opinion', but rather what
 process should in your mind they be following?

 There are still other avenues. I mentioned in a previous email about
 IETF or a working group to come up with ideas and methods to combat
 spam and abuse. If you put as much time into one of them as you do
 fighting with the spammers directly and ARIN, then you might actually
 end up solving the problem at the core!

 I really don't want to drag this anti-spam stuff out. There's been a
 huge amount of posting these last few days over this (of which I am a
 culprit also), but I do think its valuable to hit this nail on the
 head. In other words, perhaps other people on this list are getting a
 bit fed up with it, so lets just sort it out and quickly..





-- 
Jeffrey Lyon, Leadership Team
jeffrey.l...@blacklotus.net | http://www.blacklotus.net
Black Lotus Communications - AS32421
First and Leading in DDoS Protection Solutions

Re: AS11296 -- Hijacked?

On Fri, Oct 1, 2010 at 1:47 AM, Ronald F. Guilmette
r...@tristatelogic.com wrote:
 Oh yea, and the snail mail addresses given in the WHOIS records for the
 domains will usually/often be tracable to UPS Store rental P.O. boxes...
 those are standard spammer favorites, because...as they well know... us
 spamfighters can't find out who really controls any one of those boxes
 without a subpoena... unlike USPS boxes, for instance.  (All this is
 quite well known in the dank sleezy spammer undergound already, so I'm
 not hardly giving away any secrets here.)  And in a similar vein, the
 contact phone numbers given in the whois records will quite typically
 be 1-800 or 1-888 or 1-877 or 1-866 toll-free numbers.  No, the spammers
 are _not_ trying to save you money when you want to call them up to bitch
 to them about the fact that they sent you 8,372 spams in a row.  Nope,
 again, they use the toll-free numbers for a very specific purpose, which
 is again to make it more difficult for anyone trying to track them down
 to find their actual physical location.  Non-tollfree numbers are typically
 associated with a specific geographic vicinity (although even that is
 being substantially eroded by number portability).  But the toll free
 numbers are truly and always utterly geographically anonymous.  So
 spammers use them a lot, primarily in domain whois records.

 So here you are.  You've got this s**t load of highly ``fishy'' name servers,
 and they are all planted firmly into IP space that (a) appears to have been
 allocated to a reputable name brand company... such as Seiko, in this
 case... *and* (b) the block in question, based on the RegDate: and Updated:
 fields of the block's ARIN whois record, apparently hasn't been touched for
 years... maybe even a decade or more... thus implying that the former owners
 of the block either have abandoned it years ago, or else they themselves
 went belly up and ceased to exist, probably during the Great Dot Com Crash
 of 2000.  Add it all up and what does it spell?  No, not heartburn... Hijack.

Ron,

Let's try that without the diatribe:

I saw spam domains pop up associated with 199.241.95.253.
199.241.64.0/19 appears to be a defunct registration reannounced to
the Internet two weeks ago by an AS11296 -- an unregistered AS number.
A large quantity of spam domains popped up with the other addresses
recently announced by AS11296 as well. Accordingly, I suspect that as
we've seen many times before and all clearly understand, AS11296 and
the addresses it advertises have been hijacked by a spammer.

There. Now, would that have been so hard?

Your friend was right. We don't want a lengthy elaboration. Just a
simple, concise explanation of why you believe your claim to be true.

As for your secretive and ingenious detection, get over yourself.
We've seen this before. More than once.

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: ARIN Fraud Reporting Form ... Don't waste your time

2010-10-01 Thread bmanning

On Fri, Oct 01, 2010 at 04:10:12AM -0700, Ronald F. Guilmette wrote:
 
 No, it's kind of like asking the DMV whether the car belongs to the thief
 or to someone else.  They keep the records for Christ's sake!  They *can*
 take a position on that rudumentary, simple, and basic question, and they
 should.  And that is all I ask or expect them to do.  But they don't
 even want to do that miniscule amount of work, apparently.  They want to
 be the Keeper of the Records, but then they want to roll over and play
 dead, or ignorant, or agnostic, whenever somebody has the temerrity to
 simply ask them what the f**king records they are keeping *mean* about
 who actually owns what.
 
 I already said it, but I'll say it again for the benefit of those with
 low reading comprehension.  Nobody is asking ARIN to go out, with guns
 drawn, and pull the plug themselves.  But they can and should take a
 position on who owns what.  That is a judicial function, not a police
 function.  If you don't understand the distinction, then you are dumber
 than you think I think you are.
 
 
 Regards,
 rfg


R,
I have a couple of questions for you...

perhaps I am unclear here.  are you asserting that [natural/legal]
persons OWN address space?

Last I checked, ARIN records a binding between a person and a 
Right to Use agreement that is reflected in the ARIN database.

e.g.   

Bills Bait  Sushi has the right to use  168.254.0.0/16 
from 01oct1999 - current(*)   

* registration fees are current.

ARIN publishes reports from its database in two basic forms,
the WHOIS (et.al.) format and the [ip6/in-addr].arpa DNS format.

Are you suggesting that ARIN does _NOT_ publish data or that 
ARIN doesn't keep the data current, or something else?


--bill

Re: ATT Dry Pairs?

2010-10-01 Thread Curtis Maurand



I'd set up something wireless between them.  Just my $0.02.

--Curtis

On 9/30/2010 4:52 PM, Brandon Galbraith wrote:

Has anyone had any luck lately getting dry pairs from ATT? I'm in the
Chicago area attempting to get a dry pair between two buildings (100ft
apart) for some equipment, but when speaking to several folks at ATT the
response I get is You want ATT service without the service? That's not
logical!. Had no problems 3-4 years ago getting these sorts of circuits,
but it appears it's gone the way of the dodo now. Any emails off-list are
appreciated.

Re: ARIN Fraud Reporting Form ... Don't waste your time

2010-10-01 Thread David Miller



As to what ARIN can 'do' about addresses that are unused/abandoned and 
later hijacked...


ARIN delegates Reverse DNS for every allocation that they make.  Address 
blocks that are reported, investigated, and determined to be 
unused/abandoned could be delegated to special ARIN name servers that 
merely returned the following for any reverse DNS query:


z.y.x.w.in-addr.arpa.  172800  IN   PTR  
do.not.accept.anything.from.this.abandoned.address.space


This is something that ARIN *could* easily do technically.  Admittedly, 
this would require reporting and investigation that I am uncertain 
whether or not ARIN is empowered/funded to do.  This would also require 
a process be put in place for removing allocations from the delegation 
to the unused/abandoned reverse DNS servers...


-DM

On 10/1/2010 8:20 AM, Jeffrey Lyon wrote:

I sent an abuse complaint to Mr. Curran and the abuse helpdesk about a
month or two ago. Took weeks to get an initial response from the
helpdesk and i'm not certain they have actually done anything yet.

Jeff


On Fri, Oct 1, 2010 at 3:58 PM, Heath Joneshj1...@gmail.com  wrote:

Come one mate, there's no need to be just outright insulting people.
Sure everyone disagrees on some things, but still...

Lets play out this scenario then. What would you recommend ARIN actually do?
I don't mean 'take a stance' or 'have an opinion', but rather what
process should in your mind they be following?

There are still other avenues. I mentioned in a previous email about
IETF or a working group to come up with ideas and methods to combat
spam and abuse. If you put as much time into one of them as you do
fighting with the spammers directly and ARIN, then you might actually
end up solving the problem at the core!

I really don't want to drag this anti-spam stuff out. There's been a
huge amount of posting these last few days over this (of which I am a
culprit also), but I do think its valuable to hit this nail on the
head. In other words, perhaps other people on this list are getting a
bit fed up with it, so lets just sort it out and quickly..

Re: ARIN Fraud Reporting Form ... Don't waste your time

2010-10-01 Thread bmanning

On Fri, Oct 01, 2010 at 08:47:29AM -0400, David Miller wrote:
 
 As to what ARIN can 'do' about addresses that are unused/abandoned and 
 later hijacked...
 
 ARIN delegates Reverse DNS for every allocation that they make.  Address 
 blocks that are reported, investigated, and determined to be 
 unused/abandoned could be delegated to special ARIN name servers that 
 merely returned the following for any reverse DNS query:
 
 z.y.x.w.in-addr.arpa.  172800  IN   PTR  
 do.not.accept.anything.from.this.abandoned.address.space
 
 This is something that ARIN *could* easily do technically.  Admittedly, 
 this would require reporting and investigation that I am uncertain 
 whether or not ARIN is empowered/funded to do.  This would also require 
 a process be put in place for removing allocations from the delegation 
 to the unused/abandoned reverse DNS servers...
 
 -DM
 

Goodness me - I've seen that trick before.  Worked for 
about 15 minutes before I had legal camped out in the office.
Pulled it shortly there after.

I -think- what you are really after is the (fairly) new rPKI
pilot - where there are crypto-keys tied to each delegated
prefix.  If the keys are valid, then ARIN (or other RIR) has
sanctioned thier use.  No or Bad crypto, then the RIR has
some concerns about the resource.  

the downside to this is that the RIR can effectivey cut off 
someone who would otherwise be in good standing.  Sort of 
removes a level of independence in network operations.  Think
of what happens when (due to backhoe-fade, for instance) you
-can't- get to the RIR CA to validate your prefix crypto?  Do
you drop the routes?  Or would you prefer a more resilient
and robust solution?  YMMV here, depending on whom you are
willing to trust as both a reputation broker -AND- as the prefix
police.

The idea is that the crypto is harder to forge.  DNS forging
is almost as easy as prefix borrowing.


--bill

A New TransAtlantic Cable System

2010-10-01 Thread Rod Beck

http://finance.yahoo.com/news/Hibernia-Atlantic-to-bw-3184701710.html?x=0.v=1

Roderick S. Beck 
Director of European Sales 
Hibernia Atlantic 
Budapest, New York, and Paris 
http://www.hiberniaatlantic.com 
Landline: 36+1+784+7975
AOL Messenger: GlobalBandwidth 
rod.b...@hiberniaatlantic.com 
i...@globalwholesalebandwidth.com
 ``Unthinking respect for authority is the greatest enemy of truth.'' Albert 
Einstein.

Re: A New TransAtlantic Cable System

 http://finance.yahoo.com/news/Hibernia-Atlantic-to-bw-3184701710.html?x=0.v=1
 Roderick S. Beck
 Director of European Sales
 Hibernia Atlantic

Sales spam - but still - very close to minimum possible latency!
3471 miles @ 186,282 miles/s * 1.5 in glass * 2 round trip = 55.9ms.

Re: A New TransAtlantic Cable System

2010-10-01 Thread Valdis . Kletnieks

On Fri, 01 Oct 2010 15:01:25 BST, Heath Jones said:
  http://finance.yahoo.com/news/Hibernia-Atlantic-to-bw-3184701710.html?x=0.v=1

 Sales spam - but still - very close to minimum possible latency!
 3471 miles @ 186,282 miles/s * 1.5 in glass * 2 round trip = 55.9ms.

My first thought is that they've found a way to cheat on the 1.5. If you can
make it work at 1.4, you get down to 52.2ms - but get it *too* low and all
your photons leak out the sides.  Hmm.. Unless you have a magic core that
runs at 1.1 and a *cladding* that's up around 2.0?



pgptPpQq6miQN.pgp
Description: PGP signature

Re: A New TransAtlantic Cable System

2010-10-01 Thread Dorn Hetzel

Yeah, I wonder when we're gonna see cable that's pumped down to a vacuum in
the center? :)

On Fri, Oct 1, 2010 at 10:01 AM, Heath Jones hj1...@gmail.com wrote:

 
 http://finance.yahoo.com/news/Hibernia-Atlantic-to-bw-3184701710.html?x=0.v=1
  Roderick S. Beck
  Director of European Sales
  Hibernia Atlantic

 Sales spam - but still - very close to minimum possible latency!
 3471 miles @ 186,282 miles/s * 1.5 in glass * 2 round trip = 55.9ms.

Re: RIP Justification

2010-10-01 Thread Jack Bates


On 10/1/2010 4:21 AM, Owen DeLong wrote:

The average home user cannot configure RIP. What is your point?


Last linksys I looked at had a checkbox. All done.


RIP has no loop prevention and is suboptimal depending on the configuration
that things get plugged in.



Damn. You mean the split horizon stuff doesn't prevent loops? Granted, 
it's not optimal, but it works better than nothing in small homeuser 
networks as we roll v6 out and will need plug and play routing inside of 
a house.


It's also, as someone else pointed out, nice for l3vpn when customers 
don't support BGP (ie, the very small ones). Providers hate manually 
having to jack with routes when customers want to rework stuff in their 
private networks.



RIP breaks more often than DHCP in my experience.



I'm sure it does, but they are both useful for v6 in consumer grade 
routers where OSPF/IS-IS/BGP won't be found. These routers sometimes 
even get used in L3VPN. It's not the providers job to dictate what gear 
the customer wants to use. I rarely care about the stability of a 
customer network. I strictly care that my stuff works, it provides 
services to the customer, and the upkeep is as low as I can make it, 
especially for MPLS services.



Jack

Re: A New TransAtlantic Cable System

 Yeah, I wonder when we're gonna see cable that's pumped down to a vacuum in
 the center? :)

Start pumping.. :)

Actually, to my surprise, the refractive index in air is quite close
to a vacuum - so I figured we could set up a laser link between NY and
London, with 'yo mama' sitting in a boat in the middle of the Atlantic
to give it the required bend...


ps. that concludes my very poor attempt at humour.

Re: ARIN Fraud Reporting Form ... Don't waste your time

2010-10-01 Thread David Miller


 On 10/1/2010 9:07 AM, bmann...@vacation.karoshi.com  wrote:

On Fri, Oct 01, 2010 at 08:47:29AM -0400, David Miller wrote:

As to what ARIN can 'do' about addresses that are unused/abandoned and
later hijacked...

ARIN delegates Reverse DNS for every allocation that they make.  Address
blocks that are reported, investigated, and determined to be
unused/abandoned could be delegated to special ARIN name servers that
merely returned the following for any reverse DNS query:

z.y.x.w.in-addr.arpa.  172800  IN   PTR
do.not.accept.anything.from.this.abandoned.address.space

This is something that ARIN *could* easily do technically.  Admittedly,
this would require reporting and investigation that I am uncertain
whether or not ARIN is empowered/funded to do.  This would also require
a process be put in place for removing allocations from the delegation
to the unused/abandoned reverse DNS servers...

-DM


Goodness me - I've seen that trick before.  Worked for
about 15 minutes before I had legal camped out in the office.
Pulled it shortly there after.

I -think- what you are really after is the (fairly) new rPKI
pilot - where there are crypto-keys tied to each delegated
prefix.  If the keys are valid, then ARIN (or other RIR) has
sanctioned thier use.  No or Bad crypto, then the RIR has
some concerns about the resource.

the downside to this is that the RIR can effectivey cut off
someone who would otherwise be in good standing.  Sort of
removes a level of independence in network operations.  Think
of what happens when (due to backhoe-fade, for instance) you
-can't- get to the RIR CA to validate your prefix crypto?  Do
you drop the routes?  Or would you prefer a more resilient
and robust solution?  YMMV here, depending on whom you are
willing to trust as both a reputation broker -AND- as the prefix
police.

The idea is that the crypto is harder to forge.  DNS forging
is almost as easy as prefix borrowing.


--bill


I am not referring to DNS forging or crypto DNS validation or route 
announcement validation - which are certainly good topics that are 
worthy of further discussion.


I am merely refuting the statement, which I have heard many times in 
many different forums, that ARIN (or any RIR) makes address allocations 
and then walks away with no further active involvement in the use of 
these allocations.  This statement is simply not true.


These sorts of statements about an RIR having no ability to affect prior 
allocations are normally formed like:
1) RIRs have no control over the routing table or anything operationally 
in the path of evil people using IPs.
2) An RIR just makes allocations and then has nothing to do with IPs on 
a daily basis.
3) An RIR is powerless to affect anything operationally (other than 
reclaiming allocations) for allocations that have been made in the past.


These are all untrue statements.  The RIR's reverse DNS servers are 
queried all day every day for the reverse DNS delegations for every 
netblock that they allocate.  This means that RIRs are, in at least this 
way, actively operationally involved in the use of the allocations that 
they make.  This also means that an RIR has the technical vector to 
affect the active present use of the allocations that they have made in 
the past.


From ARIN's Number Resource Policy Manual [ 
https://www.arin.net/policy/nrpm.html ]:

...
3.6 Annual Whois POC Validation
  3.6.1 Method of Annual Verification
During ARINs annual Whois POC validation, an e-mail will be sent to 
every POC in the Whois database. Each POC will have a maximum of 60 days 
to respond with an affirmative that their Whois contact information is 
correct and complete. Unresponsive POC email addresses shall be marked 
as such in the database. If ARIN staff deems a POC to be completely and 
permanently abandoned or otherwise illegitimate, the POC record shall be 
marked invalid. ARIN will maintain, and make readily available to the 
community, a current list of number resources with no valid POC; this 
data will be subject to the current bulk Whois policy.

...
7. Reverse Mapping
  7.1 Maintaining IN-ADDRs
All ISPs receiving one or more distinct /16 CIDR blocks of IP 
addresses from ARIN will be responsible for maintaining all IN-ADDR.ARPA 
domain records for their respective customers. For blocks smaller than 
/16, and for the segment of larger blocks  smaller than /16, ARIN can 
maintain IN-ADDRs.


  7.2 Lame Delegations in IN-ADDR.ARPA
ARIN will actively identify lame DNS name server(s) for reverse 
address delegations associated with address blocks allocated, assigned 
or administered by ARIN. Upon identification of a lame delegation, ARIN 
shall attempt to contact the POC for that resource and resolve the 
issue. If, following due diligence, ARIN is unable to resolve the lame 
delegation, ARIN will

Re: AS11296 -- Hijacked?

On Fri, Oct 1, 2010 at 8:00 AM, Rich Kulawiec r...@gsp.org wrote:

 A quick check of my (local, incomplete, barely scratch-the-surface) list
 of such things includes (and I've left out smaller and larger blocks,
 thus this is a pretty much a snapshot of the middle of the curve):

        /16's: 25
        /17's: 20
        /18's: 47
        /19's: 73
        /20's: 99
        /21's: 88
        /22's: 105
        /23's: 198
        /24's: 3245

 for a total of about 6.6 million IP addresses.  My guess is that this
 is likely a few percent, at best, of the real total: it just happens

this is still less than a /8, which lasts ~3 months in ARIN region and
less if you could across RIR's...

Re: ARIN Fraud Reporting Form ... Don't waste your time

On Fri, Oct 1, 2010 at 9:07 AM,  bmann...@vacation.karoshi.com wrote:

\        I -think- what you are really after is the (fairly) new rPKI
        pilot - where there are crypto-keys tied to each delegated
        prefix.  If the keys are valid, then ARIN (or other RIR) has
        sanctioned thier use.  No or Bad crypto, then the RIR has

'or anyone else in the heirarchy of certificates' (nominally: IANA -
ARIN - LIR (uunet/701) - bmanning-inc - baitsushi (endsite) )

        some concerns about the resource.

or someone in the chain forgot to re-gen their cert, do the dance with
resigning and such. (there are a few failure modes, but in general
sure)


        the downside to this is that the RIR can effectivey cut off
        someone who would otherwise be in good standing.  Sort of

this depends entirely on the model that the network operators choose
to use when accepting routes. Presuming they can, on-router, decide
with policy what to do if a route origin (later hopefully route-path
as well as origin) is seen as invalid/non-validated/uncool/etc, there
could be many outcomes (local-pref change, community marking,
route-reject...) chosen.

        removes a level of independence in network operations.  Think
        of what happens when (due to backhoe-fade, for instance) you
        -can't- get to the RIR CA to validate your prefix crypto?  Do
        you drop the routes?  Or would you prefer a more resilient
        and robust solution?  YMMV here, depending on whom you are
        willing to trust as both a reputation broker -AND- as the prefix
        police.

hopefully the cache's you run are redundant (or the cache service you
pay for is redundant enough), as well the cache view is not
necessarily consistent (timing issues with updates and such), so some
flexibility is required in the end system policy. (end-system here is
the router, hopefully it is similar across an asn)

I think so far the models proposed in SIDR-wg include:
  o more than one cert tree (trust anchor)
  o the provision of the main cert heirarchy NOT necessarily be the
one I outlined above (iana-rir-lir-you)
  o operators have the ability to influence route marking based on
certificate validation outcomes
  o low on-router crypto work
  o local and supportable systems to do the crypto heavy lifting, kept
in sync with what seems like a reasonably well understood methodology
  o publication of the certification information for objects (asn's,
netblocks, subnets) via existing processes (plus some crypto marking
of course)

        The idea is that the crypto is harder to forge.  DNS forging
        is almost as easy as prefix borrowing.

and that the crypto/certificates will help us all better automate
validation of the routing information... sort of adding certificate
checking to rpsl? or, for whatever process you use to generate
prefix-lists today for customers, add some openssl certificate
validation as well.

The end state I hope is NOT just prefix-lists, but certificate
checking essentially in realtime with route acceptance in to
Adj-RIB-in...

I believe Randy Bush has presented some of this fodder at a previous
nanog meeting actually?

-chris

Verifying route origins and ownership (Was: ARIN Fraud Reporting Form ... Don't waste your time)

2010-10-01 Thread Jeroen Massar

On 2010-10-01 17:04, Christopher Morrow wrote:
[..]
 I think so far the models proposed in SIDR-wg include:
   o more than one cert tree (trust anchor)

Why not in a similar vain as RBLs: white and black lists.

One can then subscribe to the white  black lists that one trust and
give positive/negative points when an entry appears on one of those
lists, based on the points that a prefix/asnpath combo gets it is either
accepted, rejected or operator-warned.

And the good one of course is that you can setup your own repository and
give that out to your own systems or to other people's, then you just
score your system above the other lists and presto you can overrule
decisions which would be made otherwise.

If you have multiple sources you trust, you are effectively just adding
redundancy to your system, all problems solved. Works for spam, should
also work for this.

Greets,
 Jeroen

Re: Verifying route origins and ownership (Was: ARIN Fraud Reporting Form ... Don't waste your time)

On Fri, Oct 1, 2010 at 11:12 AM, Jeroen Massar jer...@unfix.org wrote:
 On 2010-10-01 17:04, Christopher Morrow wrote:
 [..]
 I think so far the models proposed in SIDR-wg include:
   o more than one cert tree (trust anchor)

 Why not in a similar vain as RBLs: white and black lists.


I'm sure someone will think it's a fine plan to set up a TA and sign
down ROA's that indicate 'badness' or 'invalid' or something similar.
There's nothing stopping that, similarly today you COULD subscribe to
a BGP feed of subnets of actually seen routes rewriting the next-hop
to dsc0/Null0/honeypot...

I don't think this sort of thing is in the SIDR-wg's charter though...
much like RBL's are not in DNS-EXT's charter?

-chris

Re: ATT Dry Pairs?

2010-10-01 Thread Andrew Carey

Or a (utility) telemetry circuit.

None of these will necessarily get you a dry copper loop, depending on the 
facilities serving your two locations. Also the circuit length will undoubtedly 
be longer than 100ft so keep that in mind for whatever you're planning to do 
with it. 

You might also try a local CLEC. They can get dry loops from ATT in different 
qualities that match your intended use from a simple dry voice grade loop to an 
unloaded DSL capable loop. Whether the CLEC provide it to you in that form is 
another matter. Even if they do so, the loops may not be straight copper all 
the way through. 


On Oct 1, 2010, at 3:25, Owen DeLong o...@delong.com wrote:

 Try asking for one of the following:
 
1.Farmer Line
2.Alarm Circuit
 
 I think there are a few other ways to ask for a dry pair that might circumvent
 the limited know-how of the people you are talking to, but, I don't recall
 them off the top of my head.
 
 Owen
 
 On Sep 30, 2010, at 1:52 PM, Brandon Galbraith wrote:
 
 Has anyone had any luck lately getting dry pairs from ATT? I'm in the
 Chicago area attempting to get a dry pair between two buildings (100ft
 apart) for some equipment, but when speaking to several folks at ATT the
 response I get is You want ATT service without the service? That's not
 logical!. Had no problems 3-4 years ago getting these sorts of circuits,
 but it appears it's gone the way of the dodo now. Any emails off-list are
 appreciated.
 
 -- 
 Brandon Galbraith
 US Voice: 630.492.0464

Re: ARIN Fraud Reporting Form ... Don't waste your time

2010-10-01 Thread Dave Sparro


On 10/1/2010 5:22 AM, Ronald F. Guilmette wrote:


really too much to ask?  They could say, to everyone involved, and to
the community as a whole, ``This ain't right.  *We* maintain the official
allocation records.  In most cases, *we* made the allocations, and that
guy should NOT be announcing routes to that IP space, and he shouldn't be
announcing anything at all via that AS number, because these things ain't
his.''



So what you're saying is that ARIN should publish data on the rightful 
users of the number resources in some online database?


(maybe they could call it WHOIS)

--
Dave

Visualizing Application Flows with xtractr

2010-10-01 Thread kowsik

One of the challenges of troubleshooting networks with packet captures
is that you quickly lose the bigger picture with the volume of data.
And static reports just don't do justice to the flurry of activity on
networks. We just posted a video on visualizing application flows
using xtractr. You can learn more about xtractr here:
http://www.pcapr.net/xtractr

http://labs.mudynamics.com/2010/09/30/visualizing-application-flows-with-xtractr

K.
---
http://www.pcapr.net
http://twitter.com/pcapr
http://labs.mudynamics.com

RE: RIP Justification

2010-10-01 Thread Guerra, Ruben

Tim hit the nail on the head. Maintaining statics on a large network would 
become a huge problem. Human error will eventually occur. The network scenario 
I am speaking of is DSL/Cable type setups, where a customer could move from 
router to router(DSLAM/CMTS) due to capacity re-combines. Utilizing a dynamic 
routing protocol makes these types of changes easier to digest.

Using BGP would be overkill for most. Many small commercial customers to not 
want the complexity of BGP or want to spend money on extra resources (routers 
that actually support it) Sure for someone that needs to announce their own 
space or wants multi-homed connection def use BGP. 

-Ruben




-Original Message-
From: Tim Franklin [mailto:t...@pelican.org] 
Sent: Friday, October 01, 2010 6:19 AM
To: nanog@nanog.org
Subject: Re: RIP Justification

 Now, when traffic comes from head office destined for a site prefix,
 it hits the provider gear. That provider gear will need routing
 information to head to a particular site. If you wanted to use
 statics, you will need to fill out a form each time you add/remove a
 prefix for a site and the provider must manage that. Its called a
 'pain in the arse'.
 
 Enter RIPv2.

Or BGP.  Why not?

RE: ARIN Fraud Reporting Form ... Don't waste your time

 
 So what you're saying is that ARIN should publish data on the rightful
 users of the number resources in some online database?
 
 (maybe they could call it WHOIS)
 
 --
 Dave

So ARIN is in the process of verifying their contacts database.
Organizations with an unreachable contact might be a good place to plant
a dig here sign.

Maybe when one of us retires, we could engage in a little research
project as a community service or something. A first step might be
matching ASN resources to unreachable contacts.  Then to collect the low
hanging fruit, find the ASNs found above that are NOT in the routing
table and attempt to match those up with organizations and see if those
organizations even still exist.  For the ones that obviously no longer
exist, create a report of the ASNs and any other number resources
associated with that organization and provide that information to the
registrar.  

Then you go through the ones that ARE in the routing table.  Any of
those organizations that are obviously defunct would be the next higher
level of fruit.  This would be particularly true if a historical look at
routing information shows the AS was in the table at some point,
disappeared after the organization went defunct, and then suddenly
appeared again in a completely different region of the planet with name
resources pointing to a completely different organization than the
number resources.  Then if a suspicious operator is discovered, it must
be reported to their upstream, the registrar with involved with the
number resources, and the community.

See how this goes?  It takes someone working on this that has access to
a lot of information and has the time to do it.  It also has to be
someone that isn't a loose cannon and can dig through it in a
methodical fashion and whether or not spam has come from the address
space really has no bearing on the process.  At least it has no bearing
on the process up to that point.  All that is being done is to weed
the database of defunct resources.  

So while the DMV doesn't go after car theft, this is more along the
lines of stealing a neighbor's license plate from that old car in the
back field, making a sticker to put on it, and driving around as if it
is a legitimate plate.  The DMV records would show who that license
plate belongs to and a police officer in a traffic stop would find out
in short order that the plate is defunct but the database available to
internet operators is so poor that there really is no way to be sure if
the data being returned is actionable or not.

G

Re: RIP Justification

2010-10-01 Thread Tim Franklin

- Ruben Guerra ruben.gue...@arrisi.com wrote:

 Using BGP would be overkill for most. Many small commercial customers
 to not want the complexity of BGP

This one keeps coming up.

Leaf-node BGP config is utterly trivial, and is much easier for the SP to 
configure the necessary safety devices on their side to stop you from shooting 
yourself in the foot and blowing up your networks - or worse, *their* network.  
Plus, if / when in the future you need to do something clever, you've already 
got the routing protocol with all the advanced knobs in place, ready for you to 
tweak as needed.

The Enterprise guys really need to get out of the blanket BGP is scary 
mindset - running BGP for an SP with multitudes of customers, peers, transits, 
aggregation, filters etc and getting it right needs expertise and experience.  
Announcing a /24 LAN and receiving a default on a single link, not so much.

 or want to spend money on extra
 resources (routers that actually support it)

This has a bit more weight to it, if you're at the really low end (certainly 
the consumer end).  But a BGP-capable Cisco 800-series is, what, £300?

Regards,
Tim.

RE: ATT Dry Pairs?

2010-10-01 Thread Scott Berkman

We order these all of the time ( as a CLEC) for EoC connections or DSL on our 
equipment.  The correct terminology is usually 2-wire or 4-wire copper loops.  
There will be specific NC/NCI codes depending on the iLEC region you are in and 
LEC you are working with.

 Within these loops, you will generally see at least the following types of 
circuits, normally these are really just different levels of qualifications the 
LEC is required to meet on the copper they provide (in terms of noise, 
attenuation, load coils, and # feet of bridge tap):
HDSL (best)
ADSL
UCL (Unbundled copper loop - worst)

Now the main issue is that these circuits are normally provisioned between a CO 
and an end-user location.  I don't know if you'd be able to get them directly 
between two sites that are not ATT facilities without going back to the CO 
first (greatly increasing total loop length and probably decreasing max DSL 
speeds).

The other thing to know is that in busy CO's, some of these line types 
(especially the higher quality loops) may be blacklisted meaning you either 
can't order them at all, or you can order them a different way at a much higher 
rate.

The last issue I can think of is that you may not be able to get these at all 
from ATT's retail or business side of the house.  If that is the case, find a 
local CLEC and see if they will help you out.

-Scott

-Original Message-
From: Brandon Galbraith [mailto:brandon.galbra...@gmail.com] 
Sent: Thursday, September 30, 2010 4:53 PM
To: nanog@nanog.org
Subject: ATT Dry Pairs?

Has anyone had any luck lately getting dry pairs from ATT? I'm in the Chicago 
area attempting to get a dry pair between two buildings (100ft
apart) for some equipment, but when speaking to several folks at ATT the 
response I get is You want ATT service without the service? That's not 
logical!. Had no problems 3-4 years ago getting these sorts of circuits, but 
it appears it's gone the way of the dodo now. Any emails off-list are 
appreciated.

--
Brandon Galbraith
US Voice: 630.492.0464

Followup and Thanks: ATT Dry Pairs?

2010-10-01 Thread Brandon Galbraith

I just wanted to follow up and say Thank You to everyone who responded to my
email regarding getting an alarm line from ATT. I've made some headway
once I reached someone with clue, and everyone was extremely helpful with
the information they provided.

-- 
Brandon Galbraith
US Voice: 630.492.0464

Re: ARIN Fraud Reporting Form ... Don't waste your time


In message 20101001123356.ga10...@vacation.karoshi.com., 
bmann...@vacation.karoshi.com wrote:

On Fri, Oct 01, 2010 at 04:10:12AM -0700, Ronald F. Guilmette wrote:
 
 No, it's kind of like asking the DMV whether the car belongs to the thief
 or to someone else.  They keep the records for Christ's sake!  They *can*
 take a position on that rudumentary, simple, and basic question, and they
 should.  And that is all I ask or expect them to do.  But they don't
 even want to do that miniscule amount of work, apparently.  They want to
 be the Keeper of the Records, but then they want to roll over and play
 dead, or ignorant, or agnostic, whenever somebody has the temerrity to
 simply ask them what the f**king records they are keeping *mean* about
 who actually owns what.
 
 I already said it, but I'll say it again for the benefit of those with
 low reading comprehension.  Nobody is asking ARIN to go out, with guns
 drawn, and pull the plug themselves.  But they can and should take a
 position on who owns what.  That is a judicial function, not a police
 function.  If you don't understand the distinction, then you are dumber
 than you think I think you are.

...

   Are you suggesting that ARIN does _NOT_ publish data or that 
   ARIN doesn't keep the data current, or something else?

I already said what I meant, twice, and quite clearly, I think.

If you don't get it after two repetitions, then I doubt that me trying
to rephrase it yet a third time is going to help your comprehension any.


Regards,
rfg

Re: RIP Justification

 Tim hit the nail on the head. Maintaining statics on a large network would 
 become a huge problem. Human error will eventually occur. The network 
 scenario I am speaking of is DSL/Cable type setups, where a customer could 
 move from router to router(DSLAM/CMTS) due to capacity re-combines. Utilizing 
 a dynamic routing protocol makes these types of changes easier to digest.


Just to be perfectly clear with the scenario I was referring to (L3VPN
with all remote sites hitting provider router) that Tim was responding
to.. The kit is all managed - customer has no access to it. I should
have mentioned that before, as it's a pretty key point to the example,
perhaps it was thought the customer could touch it?

What is needed is simply one step above statics so the provider does
not have to maintain them. Loops or hop count are a non-issue, and the
customer sites have no redundancy. It's not even a requirement to have
fast convergence.

All that is required is to have the CPE say 'here is 10.0.0/24', or at
a later date, '10.0.1/24' without any work on any other equipment.
Nice and easy. RIPv2.

Arguing that BGP should be used over RIPv2 in this scenario becomes
interesting, as BGP would offer no real advantages and requires
further configuration in most cases for each site deployed. It also
introduces more overhead for the carrier, the same with OSPF and
IS-IS.

In other scenarios - of course choose a different protocol - but for
this one, I think its a good example for the OP as to why RIPv2 is
still used.

Re: ARIN Fraud Reporting Form ... Don't waste your time

On Fri, Oct 1, 2010 at 10:32 AM, David Miller dmil...@tiggee.com wrote:
 I am merely refuting the statement, which I have heard many times in many
 different forums, that ARIN (or any RIR) makes address allocations and then
 walks away with no further active involvement in the use of these
 allocations.  This statement is simply not true.

David,

What *is* true is that ARIN's further involvement in the use of those
allocations is regulated by the policies that you and I wrote and
instructed ARIN to follow. Those policies include no actions to be
taken when a hijacker announces routes contrary to ARIN's registry
information. So long as ARIN's information has not been falsified,
forcing or not forcing folks to obey it is left for the ISPs to
resolve for themselves.

Do you think ARIN should should act as a clearinghouse for action with
respect to hijacked BGP announcements? Draft a policy proposal and
post it on the PPML. If your colleagues agree with you, that will
become one of ARIN's roles.

Until then, you criticize ARIN unfairly for doing what you and I have
told it to do.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

Re: ARIN Fraud Reporting Form ... Don't waste your time

2010-10-01 Thread bmanning

On Fri, Oct 01, 2010 at 11:07:58AM -0700, Ronald F. Guilmette wrote:
 
 In message 20101001123356.ga10...@vacation.karoshi.com., 
 bmann...@vacation.karoshi.com wrote:
 
 On Fri, Oct 01, 2010 at 04:10:12AM -0700, Ronald F. Guilmette wrote:
  
  No, it's kind of like asking the DMV whether the car belongs to the thief
  or to someone else.  They keep the records for Christ's sake!  They *can*
  take a position on that rudumentary, simple, and basic question, and they
  should.  And that is all I ask or expect them to do.  But they don't
  even want to do that miniscule amount of work, apparently.  They want to
  be the Keeper of the Records, but then they want to roll over and play
  dead, or ignorant, or agnostic, whenever somebody has the temerrity to
  simply ask them what the f**king records they are keeping *mean* about
  who actually owns what.
  
  I already said it, but I'll say it again for the benefit of those with
  low reading comprehension.  Nobody is asking ARIN to go out, with guns
  drawn, and pull the plug themselves.  But they can and should take a
  position on who owns what.  That is a judicial function, not a police
  function.  If you don't understand the distinction, then you are dumber
  than you think I think you are.
 
 ...
 
  Are you suggesting that ARIN does _NOT_ publish data or that 
  ARIN doesn't keep the data current, or something else?
 
 I already said what I meant, twice, and quite clearly, I think.
 
 If you don't get it after two repetitions, then I doubt that me trying
 to rephrase it yet a third time is going to help your comprehension any.
 
 
 Regards,
 rfg

Ok... thanks for the favor of your reply.

--bill

Re: ARIN Fraud Reporting Form ... Don't waste your time

On Oct 1, 2010, at 5:22 AM, Ronald F. Guilmette wrote:
 
 Nope!  Apparently, ARIN's fraud reporting form is only to be used for
 reporting cases where somebody has fiddled one of ARIN's whois records
 in a fradulent way.  If somebody just waltzes in and starts announcing a
 bunch of routes to a bunch of hijacked IP space from a hijacked ASN
 (or two, or three) ARIN doesn't want to hear about it.  

Ron - 
 
You note the following:

 They could say, to everyone involved, and to the community as a whole, 
 ``This ain't right.  *We* maintain the official allocation records.  
 In most cases, *we* made the allocations, and that guy should NOT be 
 announcing routes to that IP space, and he shouldn't be announcing 
 anything at all via that AS number, because these things ain't his.''

At present, ARIN doesn't review the routing of address space to see 
if an allocation made to party is being announced by another party. 
From your emails, I'm guess that you'd like ARIN to do so.

I've run several several ISPs and a hosting firm, and I'm not quite 
sure how ARIN can definitively know that any of the AS#'s involved 
should or should not be routing a given network block.  There are 
some heuristics that will suggest something is fishy about use of 
a network block, but are you actually suggesting that ARIN would 
revoke resources as a result of that?

 In those rare
 cases where the perp is considerate enough to ALSO fiddle the relevant
 WHOIS records in some fradulent way, THEN (apparently) ARIN will get
 involved, but only to the extent of re-jiggering the WHOIS record(s).
 Once that's been done, they will happily leave the perp to announce
 all of the fradulent routes and hijacked space he wants, in perpetuity.

Correct.  We will revoke the address space, but I'm uncertain what else
you suggest we do... could you elaborate here?

/John

John Curran
President and CEO
ARIN

Re: ARIN Fraud Reporting Form ... Don't waste your time

2010-10-01 Thread Justin M. Streiner


On Fri, 1 Oct 2010, Ronald F. Guilmette wrote:


Are you suggesting that ARIN does _NOT_ publish data or that
ARIN doesn't keep the data current, or something else?


I already said what I meant, twice, and quite clearly, I think.

If you don't get it after two repetitions, then I doubt that me trying
to rephrase it yet a third time is going to help your comprehension any.


Ok, it's clear that you're pretty upset about your recent dealings with 
ARIN.  I think you've made that abundantly clear.  Having said that, 
responding to people with snarky insults is not going to advance your 
position or motivate people to try to help you.


This is my first and only contribution to this thread.

jms

Weekly Routing Table Report

2010-10-01 Thread Routing Analysis Role Account

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.apnic.net.

If you have any comments please contact Philip Smith p...@cisco.com.

Routing Table Report   04:00 +10GMT Sat 02 Oct, 2010

Report Website: http://thyme.apnic.net
Detailed Analysis:  http://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  332569
Prefixes after maximum aggregation:  152883
Deaggregation factor:  2.18
Unique aggregates announced to Internet: 163430
Total ASes present in the Internet Routing Table: 34884
Prefixes per ASN:  9.53
Origin-only ASes present in the Internet Routing Table:   30253
Origin ASes announcing only one prefix:   14676
Transit ASes present in the Internet Routing Table:4631
Transit-only ASes present in the Internet Routing Table:102
Average AS path length visible in the Internet Routing Table:   3.6
Max AS path length visible:  24
Max AS path prepend of ASN (41664)   21
Prefixes from unregistered ASNs in the Routing Table:  3584
Unregistered ASNs in the Routing Table:1563
Number of 32-bit ASNs allocated by the RIRs:804
Prefixes from 32-bit ASNs in the Routing Table:1114
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:226
Number of addresses announced to Internet:   2276381248
Equivalent to 135 /8s, 174 /16s and 210 /24s
Percentage of available address space announced:   61.4
Percentage of allocated address space announced:   65.6
Percentage of available address space allocated:   93.7
Percentage of address space in use by end-sites:   85.0
Total number of prefixes smaller than registry allocations:  157088

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:81203
Total APNIC prefixes after maximum aggregation:   27834
APNIC Deaggregation factor:2.92
Prefixes being announced from the APNIC address blocks:   78077
Unique aggregates announced from the APNIC address blocks:34231
APNIC Region origin ASes present in the Internet Routing Table:4198
APNIC Prefixes per ASN:   18.60
APNIC Region origin ASes announcing only one prefix:   1168
APNIC Region transit ASes present in the Internet Routing Table:650
Average APNIC Region AS path length visible:3.7
Max APNIC Region AS path length visible: 15
Number of APNIC addresses announced to Internet:  551534112
Equivalent to 32 /8s, 223 /16s and 190 /24s
Percentage of available APNIC address space announced: 78.3

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079
   55296-56319, 131072-132095
APNIC Address Blocks 1/8,  14/8,  27/8,  43/8,  49/8,  58/8,  59/8,
60/8,  61/8, 101/8, 110/8, 111/8, 112/8, 113/8,
   114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8,
   121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8,
   175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8,
   211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8,
  

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:136044
Total ARIN prefixes after maximum aggregation:70193
ARIN Deaggregation factor: 1.94
Prefixes being announced from the ARIN address blocks:   108795
Unique aggregates announced from the ARIN address blocks: 43480
ARIN Region origin ASes present in the Internet Routing Table:13926
ARIN Prefixes per ASN: 7.81
ARIN Region origin ASes announcing only one prefix:5321
ARIN Region transit ASes present in the Internet Routing Table:1374
Average ARIN Region AS path length visible: 3.4
Max ARIN Region AS path length visible:  22

Re: AS11296 -- Hijacked?

On Oct 1, 2010, at 8:00 AM, Rich Kulawiec wrote:
 
 Spammers have absolutely no problem getting allocation after allocation
 after allocation, turning each one into scorched earth and moving on.

Materially correct, despite the fact that we look into 
the company registrations, principal parties involved,
and mailing addresses at the time of a new request.  It
is simply too easy to create a complete illusion of a 
valid organization.

 ARIN et.al. certainly have no interest in stopping them,

Hmm... An interesting assumption, and one that is quite incorrect.

Rich - How do suggest dealing with this problem?  If you can suggest
a straightforward way of vetting a new organization which the community
will support, I'll happily have it implemented asap.

/John

John Curran
President and CEO
ARIN

Re: ARIN Fraud Reporting Form ... Don't waste your time

2010-10-01 Thread Ricky Beam


On Fri, 01 Oct 2010 06:45:10 -0400, Owen DeLong o...@delong.com wrote:

It's not so much a matter of whether ARIN cares or whether ARIN wants
to do something about your issue. It's more a matter of whether ARIN
is empowered to do anything at all about your issue.


EXACTLY.

Ron, what exactly do you expect ARIN to do?  Where is the magic wand one  
would wave to erase routes from the internet?  ARIN (in fact NO ONE) has  
no actual means to block or recend any route announcement.  Do you suggest  
they sue whomever is involved?  That won't be very fast, or even an option  
outside the US.


The only reason this sort of shit happens is because of bad network  
operators who allow it and participate in it.  Responsible operators ask  
for and verify one's rights to address space before accepting it. (AS path  
and prefix filtering can only go so far.)


--Ricky

Re: ARIN Fraud Reporting Form ... Don't waste your time

2010-10-01 Thread David Miller


 On 10/1/2010 2:17 PM, William Herrin wrote:

On Fri, Oct 1, 2010 at 10:32 AM, David Millerdmil...@tiggee.com  wrote:

I am merely refuting the statement, which I have heard many times in many
different forums, that ARIN (or any RIR) makes address allocations and then
walks away with no further active involvement in the use of these
allocations.  This statement is simply not true.

David,

What *is* true is that ARIN's further involvement in the use of those
allocations is regulated by the policies that you and I wrote and
instructed ARIN to follow. Those policies include no actions to be
taken when a hijacker announces routes contrary to ARIN's registry
information. So long as ARIN's information has not been falsified,
forcing or not forcing folks to obey it is left for the ISPs to
resolve for themselves.

Do you think ARIN should should act as a clearinghouse for action with
respect to hijacked BGP announcements? Draft a policy proposal and
post it on the PPML. If your colleagues agree with you, that will
become one of ARIN's roles.

Until then, you criticize ARIN unfairly for doing what you and I have
told it to do.

Regards,
Bill Herrin



I apologize if I was unclear.

I stated in my first message regarding the possibility that RIRs could 
delegate abandoned/hijacked space to provide reverse DNS answers - This 
is something that ARIN *could* easily do technically.  Admittedly, this 
would require reporting and investigation that I am uncertain whether or 
not ARIN is empowered/funded to do.  This would also require a process 
be put in place for removing allocations from the delegation to the 
unused/abandoned reverse DNS servers...   The word 'could' was chosen 
by me instead of the word 'should' for a reason.


In my second message on this topic I in fact quoted the parts of ARIN's 
Number Resource Policy Manual regarding POC and reverse DNS delegation 
validation / removal.


I am well aware of ARIN's policies and the process for changing them.

To be clear, my point is merely that RIRs do not make address 
allocations and then walk away with no day to day involvement with these 
addresses on some technical level.  To reiterate:
The RIR's reverse DNS servers are queried all day every day for the 
reverse DNS delegations for every netblock that they allocate.  This 
means that RIRs are, in at least this way, actively operationally 
involved in the use of the allocations that they make.  This also means 
that an RIR has the technical vector to affect the active present use of 
the allocations that they have made in the past.


This was meant in no way to criticize RIRs (or any RIR in particular) or 
proscribe actions that I believe RIRs should take.  This was meant to 
correct anyone that incorrectly states that RIRs allocate addresses and 
then walk away or do nothing but maintain whois records.


Reverse DNS delegation is a technical vector that could be used by RIRs 
to affect the active present use of the allocations that they have made 
in the past.  I understand that reverse DNS would not affect route 
announcements/hijacks, but it would/could/might affect spam coming from 
these abandoned address spaces - which was the original topic for this 
discussion.


I agree that little/nothing is proscribed for RIRs at a policy level.  
The policies and procedures regarding this could be written.  I agree 
that these policies and procedures do not exist now.


-DM

RE: AS11296 -- Hijacked?

 -Original Message-
 From: Christopher Morrow 
 Sent: Friday, October 01, 2010 7:46 AM
 To: Rich Kulawiec
 Cc: nanog@nanog.org
 Subject: Re: AS11296 -- Hijacked?

 this is still less than a /8, which lasts ~3 months in ARIN region and
 less if you could across RIR's...

Which is sort of like saying:

Citizen: Hello, police?  There is a crate of M-16's and a truckload of
ammunition just sitting here on the corner
Police:  That is less than the Army goes through in 3 months ...
*click*

While true, it is orthogonal to the point being made which is if you
collect those resources and issue them to legitimate operators, those
are some 6.6 million unique hosts addresses than cannot be used for
various nefarious activities.

Re: AS11296 -- Hijacked?

On Fri, Oct 1, 2010 at 5:12 PM, George Bonser gbon...@seven.com wrote:
 this is still less than a /8, which lasts ~3 months in ARIN region and
 less if you could across RIR's...

 Which is sort of like saying:

 Citizen: Hello, police?  There is a crate of M-16's and a truckload of
 ammunition just sitting here on the corner
 Police:  That is less than the Army goes through in 3 months ...
 *click*

Death by IP address?

-Bill


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

RE: ARIN Fraud Reporting Form ... Don't waste your time

 -Original Message-
 From: Ricky Beam 
 Sent: Friday, October 01, 2010 1:00 PM
 To: nanog@nanog.org
 Subject: Re: ARIN Fraud Reporting Form ... Don't waste your time

 On Fri, 01 Oct 2010 06:45:10 -0400, Owen DeLong o...@delong.com
 wrote:
  It's not so much a matter of whether ARIN cares or whether ARIN
wants
  to do something about your issue. It's more a matter of whether ARIN
  is empowered to do anything at all about your issue.

 EXACTLY.

 Ron, what exactly do you expect ARIN to do?  Where is the magic wand
 one
 would wave to erase routes from the internet?  ARIN (in fact NO ONE)
 has
 no actual means to block or recend any route announcement.  Do you
 suggest
 they sue whomever is involved?  That won't be very fast, or even an
 option
 outside the US.

The problem as I see it is that ARIN is responsible for issuing number
resources but is not responsible for any maintenance of the number
space.  It seems they have no requirement/method/need to revoke
assignments once the assigned entity no longer exists.  I am not looking
for perfection but there should be some sort of diligence requirement
that the most obvious of the low hanging fruit (or fruit that falls
right off the tree into their lap) be dealt with in some way.  If an
entity liquidates, then their resources should be reclaimed.  

How many entities does ARIN have who have not made a payment for 2 or
more consecutive years but still have resources assigned?  It is my
personal opinion that ARIN (and the other registrars) must have the
authority and the mechanism to reclaim community resources when the
entity they were issued to disappears.  That seems like a fairly easy
concept.  Note I am not talking about misuse here, just the fact that if
a community resource is issued to an entity and that entity no longer
exists, those resources should be reclaimed by the community within some
reasonable amount of time.

G

RE: AS11296 -- Hijacked?



 -Original Message-
 From: wher...@gmail.com 
 Herrin
 Sent: Friday, October 01, 2010 2:27 PM
 To: George Bonser
 Cc: Christopher Morrow; nanog@nanog.org
 Subject: Re: AS11296 -- Hijacked?
 
 
 Death by IP address?
 
 -Bill

Quite possible if one is using it to distribute a virus. RE: Spanair
flight JK-5022

http://www.monstersandcritics.com/news/europe/news/article_1578877.php/C
omputer-viruses-may-have-contributed-to-Spanish-2008-plane-crash

Re: AS11296 -- Hijacked?

George -
   Full agreement; the next step is defining a deterministic process for 
identifying these specific resources which are hijacked, and then making a 
policy for ARIN to act.  We have a duty of stewardship, so addressing this 
problem is a priority if the community directs us to do so via policy.

/John

On Oct 1, 2010, at 5:12 PM, George Bonser gbon...@seven.com wrote:

 
 
 -Original Message-
 From: Christopher Morrow 
 Sent: Friday, October 01, 2010 7:46 AM
 To: Rich Kulawiec
 Cc: nanog@nanog.org
 Subject: Re: AS11296 -- Hijacked?
 
 this is still less than a /8, which lasts ~3 months in ARIN region and
 less if you could across RIR's...
 
 Which is sort of like saying:
 
 Citizen: Hello, police?  There is a crate of M-16's and a truckload of
 ammunition just sitting here on the corner
 Police:  That is less than the Army goes through in 3 months ...
 *click*
 
 While true, it is orthogonal to the point being made which is if you
 collect those resources and issue them to legitimate operators, those
 are some 6.6 million unique hosts addresses than cannot be used for
 various nefarious activities.

RE: AS11296 -- Hijacked?

Try this link instead http://tinyurl.com/2cngbx6

 -Original Message-
 From: George Bonser [mailto:gbon...@seven.com]
 Sent: Friday, October 01, 2010 2:32 PM
 To: William Herrin
 Cc: nanog@nanog.org
 Subject: RE: AS11296 -- Hijacked?
 
 
 
  -Original Message-
  From: wher...@gmail.com
  Herrin
  Sent: Friday, October 01, 2010 2:27 PM
  To: George Bonser
  Cc: Christopher Morrow; nanog@nanog.org
  Subject: Re: AS11296 -- Hijacked?
 
 
  Death by IP address?
 
  -Bill
 
 Quite possible if one is using it to distribute a virus. RE: Spanair
 flight JK-5022
 

http://www.monstersandcritics.com/news/europe/news/article_1578877.php/
 C
 omputer-viruses-may-have-contributed-to-Spanish-2008-plane-crash

Re: ARIN Fraud Reporting Form ... Don't waste your time

On Oct 1, 2010, at 5:27 PM, George Bonser gbon...@seven.com wrote:

 
 The problem as I see it is that ARIN is responsible for issuing number
 resources but is not responsible for any maintenance of the number
 space.  It seems they have no requirement/method/need to revoke
 assignments once the assigned entity no longer exists.  I am not looking
 for perfection but there should be some sort of diligence requirement
 that the most obvious of the low hanging fruit (or fruit that falls
 right off the tree into their lap) be dealt with in some way.  If an
 entity liquidates, then their resources should be reclaimed.

Resources being used by actual defunct organizations we will reclaim if 
reported.

  How many entities does ARIN have who have not made a payment for 2 or
 more consecutive years but still have resources assigned?  It is my
 personal opinion that ARIN (and the other registrars) must have the
 authority and the mechanism to reclaim community resources when the
 entity they were issued to disappears.  

We already do this type of reclamation.
 
 That seems like a fairly easy
 concept.  Note I am not talking about misuse here, just the fact that if
 a community resource is issued to an entity and that entity no longer
 exists, those resources should be reclaimed by the community within some
 reasonable amount of time

Agreed,
/John

John Curran
President and CEO
ARIN

Re: AS11296 -- Hijacked?

On Fri, Oct 1, 2010 at 5:31 PM, George Bonser gbon...@seven.com wrote:
 Quite possible if one is using it to distribute a virus. RE: Spanair
 flight JK-5022

 http://www.monstersandcritics.com/news/europe/news/article_1578877.php/C
 omputer-viruses-may-have-contributed-to-Spanish-2008-plane-crash

Hi George,

That's been debunked.

http://www.zdnet.com/blog/bott/fact-check-malware-did-not-bring-down-a-passenger-jet/2354?tag=nl.e550

A computer at the airline’s maintenance headquarters [...] was
infected with some sort of malware. [...] That same computer is used
to record incident reports submitted by mechanics and is programmed to
raise an alarm if the same problem occurs three times on the same
aircraft.

On the day of the crash, the plane returned to the gate after the crew
noticed a problem. The mechanics at the airport identified the issue
and cleared the plane for takeoff. They apparently didn’t know that
this was the third report of a similar problem in a two-day period.
But even if the headquarters office had maintained its PC perfectly,
the plane would still have taken off. The mechanics were still
entering their report at the time of the crash.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: http://bill.herrin.us/
Falls Church, VA 22042-3004

BGP Update Report

2010-10-01 Thread cidr-report

BGP Update Report
Interval: 23-Sep-10 -to- 30-Sep-10 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS815124582  2.3%  12.3 -- Uninet S.A. de C.V.
 2 - AS346421803  2.0% 484.5 -- ASC-NET - Alabama Supercomputer 
Network
 3 - AS32528   17249  1.6%2156.1 -- ABBOTT Abbot Labs
 4 - AS553615687  1.5% 146.6 -- Internet-Egypt
 5 - AS35931   13325  1.2%4441.7 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 6 - AS580012818  1.2%  59.3 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
 7 - AS8452 9632  0.9%   9.7 -- TE-AS TE-AS
 8 - AS3816 9132  0.9%  24.1 -- COLOMBIA TELECOMUNICACIONES 
S.A. ESP
 9 - AS106209023  0.8%   6.8 -- Telmex Colombia S.A.
10 - AS4771 8955  0.8%  25.7 -- NZTELECOM Netgate
11 - AS144208319  0.8%  13.7 -- CORPORACION NACIONAL DE 
TELECOMUNICACIONES - CNT EP
12 - AS277387444  0.7%  35.4 -- Ecuadortelecom S.A.
13 - AS2764 7225  0.7%  21.2 -- AAPT AAPT Limited
14 - AS7552 6856  0.6%  10.6 -- VIETEL-AS-AP Vietel Corporation
15 - AS3475 6692  0.6% 291.0 -- LANT-AFLOAT - Navy Network 
Information Center (NNIC)
16 - AS9498 6370  0.6%  14.1 -- BBIL-AP BHARTI Airtel Ltd.
17 - AS210176184  0.6% 618.4 -- VSI-AS VSI AS
18 - AS9829 6149  0.6%  24.0 -- BSNL-NIB National Internet 
Backbone
19 - AS153995871  0.6%  65.2 -- WANANCHI-KE
20 - AS369925846  0.6%  11.7 -- ETISALAT-MISR


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS35931   13325  1.2%4441.7 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 2 - AS32528   17249  1.6%2156.1 -- ABBOTT Abbot Labs
 3 - AS227531896  0.2%1896.0 -- REDHAT-STUTTGART REDHAT 
Stuttgart
 4 - AS535321037  0.1%1037.0 -- KINGMETALS - King Architectural 
Metals
 5 - AS45600 948  0.1% 948.0 -- UPM-AS-AP University of the 
Philippines, Manila
 6 - AS38531 828  0.1% 828.0 -- SULLCROM-HK Sullivan  Cromwell 
LLP, Hong Kong Site, International Law Firm.
 7 - AS11613 702  0.1% 702.0 -- U-SAVE - U-Save Auto Rental of 
America, Inc.
 8 - AS53327 685  0.1% 685.0 -- 
CO-OPERATIVE-INSURANCE-COMPANIES - Co-operative Insurance Companies, inc.
 9 - AS14294 638  0.1% 638.0 -- LIBERTYTEL - Liberty Telecom, 
LLC
10 - AS15984 622  0.1% 622.0 -- The Joint-Stock Commercial Bank 
CentroCredit.
11 - AS210176184  0.6% 618.4 -- VSI-AS VSI AS
12 - AS31055 579  0.1% 579.0 -- CONSULTIX-AS Consultix GmbH
13 - AS337754398  0.4% 549.8 -- NITEL-AS
14 - AS3 540  0.1% 333.0 -- STOFANET Stofa A/S
15 - AS27027 538  0.1% 538.0 -- ANBELL ASN-ANBELL
16 - AS346421803  2.0% 484.5 -- ASC-NET - Alabama Supercomputer 
Network
17 - AS372043385  0.3% 483.6 -- TELONE
18 - AS37065 462  0.0% 462.0 -- ZOOM-AS
19 - AS703   381  0.0% 381.0 -- UUNET - MCI Communications 
Services, Inc. d/b/a Verizon Business
20 - AS9556 1745  0.2% 349.0 -- ADAM-AS-AP Adam Internet Pty Ltd


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 129.66.0.0/17 10808  0.9%   AS3464  -- ASC-NET - Alabama Supercomputer 
Network
 2 - 129.66.128.0/17   10804  0.9%   AS3464  -- ASC-NET - Alabama Supercomputer 
Network
 3 - 130.36.34.0/24 8616  0.7%   AS32528 -- ABBOTT Abbot Labs
 4 - 130.36.35.0/24 8616  0.7%   AS32528 -- ABBOTT Abbot Labs
 5 - 201.134.18.0/248420  0.7%   AS8151  -- Uninet S.A. de C.V.
 6 - 63.211.68.0/22 7886  0.7%   AS35931 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 7 - 198.140.43.0/245327  0.5%   AS35931 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 8 - 190.65.228.0/225307  0.5%   AS3816  -- COLOMBIA TELECOMUNICACIONES 
S.A. ESP
 9 - 216.126.136.0/22   4645  0.4%   AS6316  -- AS-PAETEC-NET - PaeTec 
Communications, Inc.
10 - 148.204.141.0/24   4249  0.4%   AS8151  -- Uninet S.A. de C.V.
11 - 95.32.192.0/18 3326  0.3%   AS21017 -- VSI-AS VSI AS
12 - 206.184.16.0/243062  0.3%   AS174   -- COGENT Cogent/PSI
13 - 216.118.245.0/24   3008  0.3%   AS25747 -- VSC-SATELLITE-CO - VSC 
Satellite Co.
14 - 95.32.128.0/18 2824  0.2%   AS21017 -- VSI-AS VSI AS
15 - 202.92.235.0/242535  0.2%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
16 - 64.86.26.0/23  2473  0.2%   AS37204 -- TELONE
17 - 41.238.176.0/231985  0.2%   AS8452  -- TE-AS TE-AS
18 - 66.187.234.0/241896  0.2%   AS22753 -- REDHAT-STUTTGART REDHAT 
Stuttgart
19 - 138.116.134.0/24   1369  0.1%   AS7018  -- ATT-INTERNET4 - ATT

The Cidr Report

2010-10-01 Thread cidr-report

This report has been generated at Fri Oct  1 21:12:03 2010 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
24-09-10336850  207985
25-09-10336997  207887
26-09-10337000  208528
27-09-10337205  208311
28-09-10337437  208418
29-09-10337629  208515
30-09-10337929  208442
01-10-10337368  208582


AS Summary
 35515  Number of ASes in routing system
 15117  Number of ASes announcing only one prefix
  4480  Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
  96837376  Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 01Oct10 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 337851   208477   12937438.3%   All ASes

AS6389  3776  282 349492.5%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS4323  4480 1946 253456.6%   TWTC - tw telecom holdings,
   inc.
AS19262 1822  286 153684.3%   VZGNI-TRANSIT - Verizon Online
   LLC
AS4766  1861  519 134272.1%   KIXS-AS-KR Korea Telecom
AS22773 1199   66 113394.5%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS4755  1357  290 106778.6%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS17488 1347  297 105078.0%   HATHWAY-NET-AP Hathway IP Over
   Cable Internet
AS18566 1087   63 102494.2%   COVAD - Covad Communications
   Co.
AS5668  1080   95  98591.2%   AS-5668 - CenturyTel Internet
   Holdings, Inc.
AS10620 1324  344  98074.0%   Telmex Colombia S.A.
AS6478  1354  426  92868.5%   ATT-INTERNET3 - ATT WorldNet
   Services
AS1785  1796  962  83446.4%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS13343 1385  633  75254.3%   SCRR-13343 - Road Runner
   HoldCo LLC
AS7303   810  114  69685.9%   Telecom Argentina S.A.
AS8452  1009  345  66465.8%   TE-AS TE-AS
AS7545  1414  757  65746.5%   TPG-INTERNET-AP TPG Internet
   Pty Ltd
AS8151  1338  691  64748.4%   Uninet S.A. de C.V.
AS18101  882  247  63572.0%   RIL-IDC Reliance Infocom Ltd
   Internet Data Centre,
AS4808   936  303  63367.6%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS4804   665   75  59088.7%   MPX-AS Microplex PTY LTD
AS28573 1161  601  56048.2%   NET Servicos de Comunicao S.A.
AS7018  1488  959  52935.6%   ATT-INTERNET4 - ATT WorldNet
   Services
AS4780   706  180  52674.5%   SEEDNET Digital United Inc.
AS17676  607   81  52686.7%   GIGAINFRA Softbank BB Corp.
AS24560 1040  517  52350.3%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS7552   648  137  51178.9%   VIETEL-AS-AP Vietel
   Corporation
AS9443   575   77  49886.6%   INTERNETPRIMUS-AS-AP Primus
   Telecommunications
AS7011  1157  667  49042.4%   FRONTIER-AND-CITIZENS -
   Frontier Communications of
   America, Inc.
AS22047  561   82  47985.4%   VTR BANDA ANCHA S.A.
AS14420  564  102  46281.9%   CORPORACION NACIONAL DE

Re: ARIN Fraud Reporting Form ... Don't waste your time (more re: recovered resources)

On Oct 1, 2010, at 5:43 PM, John Curran wrote:
 
 Resources being used by actual defunct organizations we will reclaim if 
 reported.

Folks - 

It occurred to me that I could have been clearer, so here I am replying 
to myself...

When we at ARIN can readily determine that an organization is defunct 
and has no apparent successor, we will reclaim resources.  This generally 
happens because someone attempts a fraudulent transfer of those resources 
but can also be a result of other investigations.

We give a report of returned, revoked, and reclaimed number resources at 
each member meeting - last April's report can be found here: 
https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Wednesday/Nobile_RSD.pdf

Obviously, we'll be presenting updated statistics this upcoming week in 
Atlanta; there's been a bit of a surge of activity in this area.

/John

John Curran
President and CEO
ARIN

Re: ARIN Fraud Reporting Form ... Don't waste your time (more re: recovered resources)

2010-10-01 Thread John Springer


Thanks John,

On Fri, 1 Oct 2010, John Curran wrote:


On Oct 1, 2010, at 5:43 PM, John Curran wrote:


Resources being used by actual defunct organizations we will reclaim if 
reported.


Folks -

It occurred to me that I could have been clearer, so here I am replying
to myself...

When we at ARIN can readily determine that an organization is defunct
and has no apparent successor, we will reclaim resources.  This generally
happens because someone attempts a fraudulent transfer of those resources
but can also be a result of other investigations.

We give a report of returned, revoked, and reclaimed number resources at
each member meeting - last April's report can be found here:
https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Wednesday/Nobile_RSD.pdf


Is the information on Leslie's slide 5 at the above link available broken 
down by year? It might be informative to see any trends.


Thanks again,
John Springer


Obviously, we'll be presenting updated statistics this upcoming week in
Atlanta; there's been a bit of a surge of activity in this area.

/John

John Curran
President and CEO
ARIN

Re: AS11296 -- Hijacked?

2010-10-01 Thread Bryan Fields

On 10/1/2010 17:12, George Bonser wrote:
 Citizen: Hello, police?  There is a crate of M-16's and a truckload of
 ammunition just sitting here on the corner
 Police:  That is less than the Army goes through in 3 months ...
 *click*

You'd have better luck calling the ATF, they are the ones empowered to enforce
the tax on machine guns.  The local police do not have any authority to
enforce those taxes, and could get sued if they tried to.


-- 
Bryan Fields

727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net

RE: AS11296 -- Hijacked?

 -Original Message-
 From: wher...@gmail.com  On Behalf Of William
 Herrin
 Sent: Friday, October 01, 2010 2:50 PM
 To: George Bonser
 Cc: nanog@nanog.org
 Subject: Re: AS11296 -- Hijacked?

 On Fri, Oct 1, 2010 at 5:31 PM, George Bonser 
 wrote:
  Quite possible if one is using it to distribute a virus. RE: Spanair
  flight JK-5022

http://www.monstersandcritics.com/news/europe/news/article_1578877.php/
 C
  omputer-viruses-may-have-contributed-to-Spanish-2008-plane-crash

 Hi George,

 That's been debunked.

Good.  Ok, now shall we move on to Stuxnet which now seems to be
infiltrating China.  We don't know yet if that will cause any problems
or not.  The idea that there are fairly significant amounts of address
space that could be used for practically anything at any time is
probably a bigger issue in 2010 than it was in 1995 simply because we
have more infrastructure that is either directly or indirectly exposed
to it.  Malware distributed on the internet can find its way onto a
laptop and from there a thumb drive and from there to a computer used
for medical purposes or at a chemical plant is more plausible of a
scenario these days.  Why make it EASY to distribute such things?  

Why do you seem to be defending the idea that it is somehow good to have
lots of unaccounted for address space out there?  Do you use it for
something?

G

RE: AS11296 -- Hijacked?

2010-10-01 Thread Nathan Eisenberg

  Citizen: Hello, police?  There is a crate of M-16's and a truckload
  of ammunition just sitting here on the corner
  Police:  That is less than the Army goes through in 3 months ...
  *click*
 
 You'd have better luck calling the ATF, they are the ones empowered to
 enforce the tax on machine guns.  The local police do not have any authority
 to enforce those taxes, and could get sued if they tried to.

Why are we diverting the topic from 'draft a proposal to empower ARIN to deal 
with these sorts of problems' to 'arguing with meaningless analogies that do 
nothing except make the author feel good'?  This is an operations list, not a 
debate team.

Nathan

Re: AS11296 -- Hijacked?

2010-10-01 Thread JC Dill


Bryan Fields wrote:

On 10/1/2010 17:12, George Bonser wrote:
  

Citizen: Hello, police?  There is a crate of M-16's and a truckload of
ammunition just sitting here on the corner
Police:  That is less than the Army goes through in 3 months ...
*click*



You'd have better luck calling the ATF, they are the ones empowered to enforce
the tax on machine guns.  The local police do not have any authority to
enforce those taxes, and could get sued if they tried to.
  
Here's an incident where the local authorities didn't know what to do 
about a possibly very worrisome incident at SJC (San Jose International 
Airport):


http://forums.mercurynews.com/topic/two-men-armed-with-assault-weapons-barely-cause-a-stir-at-mineta-san-jose-international-airpor

The problem is that people don't *think* - they just follow orders, 
follow their training.  No one had thought about or trained for this 
type of incident.  Fortunately, in this case, the people were not 
terrorists.  Meanwhile, TSA confiscates bottles of shampoo and water.


jc

Re: AS11296 -- Hijacked?

On Oct 1, 2010, at 2:31 PM, George Bonser wrote:

 -Original Message-
 From: wher...@gmail.com 
 Herrin
 Sent: Friday, October 01, 2010 2:27 PM
 To: George Bonser
 Cc: Christopher Morrow; nanog@nanog.org
 Subject: Re: AS11296 -- Hijacked?

 Death by IP address?

 -Bill

 Quite possible if one is using it to distribute a virus. RE: Spanair
 flight JK-5022

 http://www.monstersandcritics.com/news/europe/news/article_1578877.php/C
 omputer-viruses-may-have-contributed-to-Spanish-2008-plane-crash

http://aircrewbuzz.com/2008/10/officials-release-preliminary-report-on.html

A more recent Interim report:

http://www.fomento.es/NR/rdonlyres/AADDBF93-690C-4186-983C-8D897F09EAA5/75736/2008_032_A_INTERINO_01_ENG.pdf

The crew apparently skipped the step where they were supposed to deploy
the slats/flaps prior to takeoff.

Additionally, the warning system on the aircraft which should have alerted
the crew to the failure to extend the flaps/slats also failed to sound.

A computer virus may have had a small contribution to the failure to detect
the warning system failure in the maintenance process, but, it did not cause
the accident.

The accident is clearly the result of pilot error, specifically the failure to
properly configure the aircraft for takeoff and failure to take remedial
action upon activation of the stall warning system during the initial
climb.

Owen (who is also a pilot with a commercial rating)

Re: Using crypto auth for detecting corrupted IGP packets?

On Fri, Oct 1, 2010 at 7:26 AM, Jared Mauch ja...@puck.nether.net wrote:

 On Oct 1, 2010, at 3:49 AM, Dobbins, Roland wrote:


 On Oct 1, 2010, at 1:01 PM, Manav Bhatia wrote:

 In 6 hours you will have around 8000K BFD packets. Add OSPF,
 RSVP, BGP, LACP (for lags), dot1AG, EFM and you would really get a
 significant number of packets to buffer.


 Which isn't a 'HUGE!' amount of packets.

 ;


 Yup, but when trying to figure out the root cause of some problem, having a 
 few gigs of data would be helpful.

 In the event people have not noticed, hard drives are semi-popular in routers 
 now, so assuming you have some variable amount of disk space greater than 8MB 
 for an image is feasible.

on at least one platform you can get some details with traceoptions, no?

Re: ARIN Fraud Reporting Form ... Don't waste your time

On Oct 1, 2010, at 2:27 PM, George Bonser wrote:

 -Original Message-
 From: Ricky Beam 
 Sent: Friday, October 01, 2010 1:00 PM
 To: nanog@nanog.org
 Subject: Re: ARIN Fraud Reporting Form ... Don't waste your time

 On Fri, 01 Oct 2010 06:45:10 -0400, Owen DeLong o...@delong.com
 wrote:
 It's not so much a matter of whether ARIN cares or whether ARIN
 wants
 to do something about your issue. It's more a matter of whether ARIN
 is empowered to do anything at all about your issue.

 EXACTLY.

 Ron, what exactly do you expect ARIN to do?  Where is the magic wand
 one
 would wave to erase routes from the internet?  ARIN (in fact NO ONE)
 has
 no actual means to block or recend any route announcement.  Do you
 suggest
 they sue whomever is involved?  That won't be very fast, or even an
 option
 outside the US.

 The problem as I see it is that ARIN is responsible for issuing number
 resources but is not responsible for any maintenance of the number
 space.  It seems they have no requirement/method/need to revoke
 assignments once the assigned entity no longer exists.  I am not looking

They do, indeed, for space that is/was issued by ARIN. That space is
subject to annual fees and there is a clear and consistent method
for doing so. The bigger problem is with legacy space (most of the
space listed in the complaint we are discussing, if not all).

In the case of legacy space, it's actually very hard for ARIN to even
identify the status of the organization in question, let alone take
any sort of action with respect to said space.

 for perfection but there should be some sort of diligence requirement
 that the most obvious of the low hanging fruit (or fruit that falls
 right off the tree into their lap) be dealt with in some way.  If an
 entity liquidates, then their resources should be reclaimed.  

Again, for space issued by ARIN, yes. For legacy space, this is a much
more complicated problem.

The good news is that this is limited to IPv4. Since there are no Pre-RIR
IPv6 allocations or assignments, it is a non-issue in IPv6.

 How many entities does ARIN have who have not made a payment for 2 or
 more consecutive years but still have resources assigned?  It is my

I suspect not many. (Unless you are including those organizations
that do not pay fees because of their legacy status).

Owen

Re: AS11296 -- Hijacked?

On Fri, Oct 1, 2010 at 5:12 PM, George Bonser gbon...@seven.com wrote:


 -Original Message-
 From: Christopher Morrow
 this is still less than a /8, which lasts ~3 months in ARIN region and
 less if you could across RIR's...

 Which is sort of like saying:


no, the point is/was that the number of addresses isn't likely the
really important point you don't care about reclaiming addresses
because of the size of the allocations. you care to reclaim because of
improper use/abuse and/or theft of the resource.

Nathan is correct though, propose some policy text that the community
can get behind? probably also do that on ppml

-Chris

-chris

Re: AS11296 -- Hijacked?

On Oct 1, 2010, at 3:48 PM, JC Dill wrote:

Bryan Fields wrote:
On 10/1/2010 17:12, George Bonser wrote:

Citizen: Hello, police? There is a crate of M-16's and a truckload of
ammunition just sitting here on the corner
Police: That is less than the Army goes through in 3 months ...
*click*

You'd have better luck calling the ATF, they are the ones empowered to
enforce
the tax on machine guns. The local police do not have any authority to
enforce those taxes, and could get sued if they tried to.

Here's an incident where the local authorities didn't know what to do about
a possibly very worrisome incident at SJC (San Jose International Airport):

http://forums.mercurynews.com/topic/two-men-armed-with-assault-weapons-barely-cause-a-stir-at-mineta-san-jose-international-airpor

The problem is that people don't *think* - they just follow orders, follow
their training. No one had thought about or trained for this type of
incident. Fortunately, in this case, the people were not terrorists.
Meanwhile, TSA confiscates bottles of shampoo and water.

Having now read that article, it really strikes me as much ado about nothing.

The men were not concealing the lawfully carried weapons.
They were carrying the weapons in a lawful manner.
I suspect that all of their permits were in order.
They did not shoot anyone.
No animals were harmed in the making of this farce.

Turns out they were legitimate armed guards from US DoE on legitimate business.

Frankly, I'd be much more worried about the safety of whatever was in that
man's luggage being on the flight than about the guards carrying assault
rifles in the non-secure area of the airport.

Heck, we let SJPD carry guns in that area, why shouldn't the general public?

Owen

Re: ARIN Fraud Reporting Form ... Don't waste your time

2010-10-01 Thread Franck Martin

A yearly challenge response for legacy space contacts, could be useful. I think 
there is a plan like this in some RIRs

- Original Message -
From: Owen DeLong o...@delong.com
To: George Bonser gbon...@seven.com
Cc: nanog@nanog.org
Sent: Friday, 1 October, 2010 4:03:56 PM
Subject: Re: ARIN Fraud Reporting Form ... Don't waste your time

On Oct 1, 2010, at 2:27 PM, George Bonser wrote:

 -Original Message-
 From: Ricky Beam 
 Sent: Friday, October 01, 2010 1:00 PM
 To: nanog@nanog.org
 Subject: Re: ARIN Fraud Reporting Form ... Don't waste your time

In the case of legacy space, it's actually very hard for ARIN to even
identify the status of the organization in question, let alone take
any sort of action with respect to said space.

Owen

Re: ARIN Fraud Reporting Form ... Don't waste your time


In message 608b18db-6e75-4b5e-ba42-d1f69ece4...@arin.net, 
John Curran wrote:

You note the following:

 They could say, to everyone involved, and to the community as a whole,
 ``This ain't right.  *We* maintain the official allocation records. 
 In most cases, *we* made the allocations, and that guy should NOT be
 announcing routes to that IP space, and he shouldn't be announcing
 anything at all via that AS number, because these things ain't his.''

At present, ARIN doesn't review the routing of address space to see
if an allocation made to party is being announced by another party.
From your emails, I'm guess that you'd like ARIN to do so.

John,

First, let me say thanks for your personal response.

Second let me also say that I am pleased to know, at least, that my serious
efforts to express myself clearly were not lost on everyone.  You have
grasped my meaning clearly.  (But not everyone here has done likewise.)

I've run several several ISPs and a hosting firm, and I'm not quite
sure how ARIN can definitively know that any of the AS#'s involved
should or should not be routing a given network block.

Please allow me to attempt to refute what you just said.  I think that
I can do so, briefly, in (at least) two different ways.

1)   You folks _are_ already (apparently) making some efforts... at least
as of this last summer, but perhaps also earlier... to ``validate'' (is
that the word you would use?) POC contacts.  I know because I've lately
seen quite a number of your POC contact records (from the WHOIS data base)
that have a very helpful annotation attached to them, saying quite
directly and explicitly, that ARIN has been unable to verify or make
contact with this POC or that POC.  So you are already passing judgement
on the validity and/or probable invalidity of things in your data base.
And more, you are making your determinations public, via the data base
itself.  I'm not quite sure how it constitutes such a big leap to merely
extend what you are already doing in the way of validating POCs and just
impute the exact same level of confidence, or lack thereof, to IP block
and/or AS records which are associated with unverifiable/uncontactable
POCs... a set which you are already making serious efforts to delineate
anyway.  If you can put an annotation into a whois records for a POC,
saying explicity that you can't get ahold of this person, then it would
seem to me to be a rather trivial matter of programming to transplant
a very similar sort of annotation into each and every IP block or AS
record that has that same specific POC record as one of its associated
POC records, either Admin, or Technical, or whatever.

You could just say, you know, something like ``We have been tring to contact
the Technical POC for this since XX-XX-2010, and we've been unable to do so.''
Well, not those words exactly, but I hope you get the general idea.  Just
take the determinations that you folks are _already_ making, for the POC
records, and just impute them to, and include them in, also, to the
relevant block and/or AS records.  Or alternatively, you could stop using
verbage altogether and just switch over to a system based on simple,
universally understood icons:

http://farm2.static.flickr.com/1082/820306671_6a0520fe17_m.jpg
http://farm2.static.flickr.com/1382/1263977902_d0e9a43821_o.jpg

Now, you may perhaps be tempted to quibble with my point here, and repeat
again what you said above, I.e. that ARIN cannot make ``definitive''
determinations.  Please don't yield to any such temptation.  Quite
frankly, to the best of my knowledge, no living human can reliably make
any truly ``definitive'' determinations about anything at all.  Only God
can do that.  (And frankly, I harbor lingering suspicions that even He
gets it wrong a fair percentage of the time.)

Nobody expects you to have the infallibility of God... or even of the
Pope.  And nobody is asking you to display such a level of infinite
perfection, least of all me.  But ya know, even in the abundant absence
of certainty in our day-to-day lives, we all still drag ourselves out
of bed in the morning and do the best that we can.  And that's all that
either I or anybody else has any right to ask of you/ARIN or to expect
of you/ARIN.  Just do the best you can.  Are your deteminations that
this POC or that POC cannot be contacted, or cannot currently be verified
``definitive''?  No, that's probably too stong a word.  But you/ARIN have
the good sense and the courtesy to publish the information you have gathered
regarding the contactability of POCs anyway, and it's appreciated.  It helps.
Please just do more of it.  This is not an all-or-nothing ``We can't say
anything definitively so we can't say anything at all, ever'' kind of
situation, I think.


2)  You are already (apparently) processing _some_ certain flavors of
``fraud reports''  that come in to you via that nice fancy web form you
folks built and put up on the ARIN web site... you know... the one with
the nice

RE: ARIN Fraud Reporting Form ... Don't waste your time

 -Original Message-
 From: Owen DeLong 
 Sent: Friday, October 01, 2010 4:04 PM
 To: George Bonser
 Cc: Ricky Beam; nanog@nanog.org
 Subject: Re: ARIN Fraud Reporting Form ... Don't waste your time

 On Oct 1, 2010, at 2:27 PM, George Bonser wrote:

 They do, indeed, for space that is/was issued by ARIN. That space is
 subject to annual fees and there is a clear and consistent method
 for doing so. The bigger problem is with legacy space (most of the
 space listed in the complaint we are discussing, if not all).

 In the case of legacy space, it's actually very hard for ARIN to even
 identify the status of the organization in question, let alone take
 any sort of action with respect to said space.

Maybe this is a teachable moment for me.  According to my reading of the
Legacy RSA:

 For purposes of this Legacy Agreement, the term Services may
include, without limitation, the inclusion of the legacy IP address
space, and/or Autonomous System numbers (ASNs) previously issued to
Legacy Applicant in the ARIN WHOIS database, inverse addressing on
network blocks, maintenance of resource records, and administration of
IP address space related to Included Number Resources issued prior to
ARIN's inception on December 22, 1997 in its service area. IP address
space and ASNs shall be defined as number resources. 

...

 If Legacy Applicant does not pay the Annual Legacy Maintenance Fee or
other fees that may be owed ARIN hereunder, ARIN shall provide written
notification to the Legacy Applicant approximately thirty (30) days
following the date on which the payment is not made. If Legacy Applicant
fails to make payment in response to the notice of delinquency, ARIN
shall provide Legacy Applicant with an additional written notice, by
certified or registered mail, return receipt requested, (as appropriate
in each country), and, when possible, by e-mail and telephone. If the
Legacy Applicant has not made payment within 12 months of the due date
and/or ARIN is unable to contact the Legacy Applicant during those 12
months, ARIN has the right to: (i) stop providing Services, or (ii)
terminate this Legacy Agreement and revoke the Included Number
Resources.

Or is this some other sort of legacy thing?

RE: ARIN Fraud Reporting Form ... Don't waste your time

 
 They do, indeed, for space that is/was issued by ARIN. That space is
 subject to annual fees and there is a clear and consistent method
 for doing so. The bigger problem is with legacy space (most of the
 space listed in the complaint we are discussing, if not all).
 
 In the case of legacy space, it's actually very hard for ARIN to even
 identify the status of the organization in question, let alone take
 any sort of action with respect to said space.

Ok, I think I have a solution that is workable.  A second database ...
call it whoisnt ... of number resources and their points of contact
that have not signed the legacy RSA and allow the community members to
decide individually if they wish to continue to provide unfettered
access from those resources.  It might also provide maybe even some
small amount of community pressure on the holders of those resources to
place them under the legacy RSA.

RE: AS11296 -- Hijacked?

Try this one on for size:

http://tinyurl.com/2aoqpmk

Sent from my somethingorother.


 -Original Message-
 From: On Behalf Of William
 Herrin
 Sent: Friday, October 01, 2010 2:50 PM
 To: George Bonser
 Cc: nanog@nanog.org
 Subject: Re: AS11296 -- Hijacked?
 

  Stuff about ip bullets or something ...

Re: ARIN Fraud Reporting Form ... Don't waste your time


In message 67ef8ee2-8b1e-45f9-892e-9e6b88adb...@arin.net, 
John Curran jcur...@arin.net wrote:

Resources being used by actual defunct organizations we will reclaim if
reported.

Well, fortunately, Joytel and some of their fellow travelers have just
recently gone 'round and identified a whole pantload of these for you:

24.230.0.0/19 NET-24-230-0-0-1  hijacked - empty
68.67.64.0/20 NET-68-67-64-0-1  legit -- GoRack, LLC (Jacksonville, FL)
192.100.5.0/24NET-192-100-5-0-1 hijacked - empty
192.100.88.0/24   NET-192-100-88-0-1hijacked - empty
192.100.134.0/24  NET-192-100-134-0-1   hijacked - empty
192.100.143.0/24  NET-192-100-143-0-1   hijacked - empty
192.101.177.0/24  NET-192-101-177-0-1   hijacked - empty
192.101.187.0/24  NET-192-101-187-0-1   hijacked - empty
...

Do you want me to repost the whole list, or have you seen it already?

Do I need to do something else to turn this into whatever qualifies at
your place as a formal report?  (Note:  The whole list is too long to
fit into the tiny little window you provide for fraud reporting on your
web site.  Should I print it all out as hardcopy and FedEx it to you
in a shoebox?)


Regards,
rfg

Re: ARIN Fraud Reporting Form ... Don't waste your time


In message 5a6d953473350c4b9995546afe9939ee0a52b...@rwc-ex1.corp.seven.com,
George Bonser gbon...@seven.com wrote:

So ARIN is in the process of verifying their contacts database.
Organizations with an unreachable contact might be a good place to plant
a dig here sign.


Fyi --

They (ARIN) already _are_ putting up ``dig here'' signs... in the POC records.

Unfortunately, it would now appear that the folks doing the digging in those
exact spots, are the hijackers, like Joytel.  (Unless I'm mistaken, every
last one of the blocks that Joytel grabbed had one of those little annotations
on the associated POC record(s)).

Talk about the Law of Unintended Conseqences!

Oh well.  It all comes out in the wash.  Those POC annotations may perhaps
have helped Joytel to identify easy takeover targets, but then they also
helped _me_ to find the specific blocks that Joytel had jacked.

On balance, I say it is better to have them than to not have them.  Even
if they might occasionally give those with sinister intent a small leg up.


Regards,
rfg


P.S.  I hope that everybody knows that the jerk behind Joytel also, apparently,
tried to screw the taxpayers out of about $11+ million of ``stimulus'' money...
undoubtedly for yet another useless make-work ``shovel ready'' project.

http://jacksonville.bizjournals.com/jacksonville/stories/2009/11/30/story1.html#

No word on whether he ever actually got his hoped-for $11.8 million payoff.
Knowing how ga-ga the Obama administration is over anything that has the
word ``broadband'' in it however, I wouldn't put it past them, and they
probably did give this schmuck the cash.  (They also really like the words
``young entrepreneur''.  Sounds great to the unwashed masses in a press
release.)

  If companies want to move here, they have a great labor force, great
  quality of life and affordable office space, said Mark Anthony Marques,
  Joytel president and CEO.  What we lack is a good enough connection to
  the Internet infrastructure.

  The company expects to know by mid-December whether it will receive
  funding for the project, which has the support of key players including
  Mayor John Peyton, U.S. Sen. Bill Nelson and U.S. Reps. Corrine Brown
  and Ander Crenshaw.

  About 400 gigabytes of high-speed Internet capacity will be available
  to providers by mid-2010 if funding is received. That is enough capacity
  to transfer the entire contents of the Library of Congress within five
  minutes.

... or alternatively, to spam every person on the planet, twice, in under
twenty minutes.

Re: ARIN Fraud Reporting Form ... (Resource listings yes, resource routing no)

On Oct 1, 2010, at 8:08 PM, Ronald F. Guilmette wrote:
 1)   You folks _are_ already (apparently) making some efforts... at least
 as of this last summer, but perhaps also earlier... to ``validate'' (is
 that the word you would use?) POC contacts.  I know because I've lately
 seen quite a number of your POC contact records (from the WHOIS data base)
 that have a very helpful annotation attached to them, saying quite
 directly and explicitly, that ARIN has been unable to verify or make
 contact with this POC or that POC.  So you are already passing judgement
 on the validity and/or probable invalidity of things in your data base.

Yes, we're attempting to validate contacts per the policy which the
community set (ARIN Network Resource Policy Manual, section 3.6 - 
https://www.arin.net/policy/nrpm.html#three6)

 And more, you are making your determinations public, via the data base
 itself.  I'm not quite sure how it constitutes such a big leap to merely
 extend what you are already doing in the way of validating POCs and just
 impute the exact same level of confidence, or lack thereof, to IP block
 and/or AS records which are associated with unverifiable/uncontactable
 POCs... a set which you are already making serious efforts to delineate
 anyway.

We will shortly be providing a list of number resources with no valid POC
for those who desire it (per the current bulk Whois policy.)

 If you can put an annotation into a whois records for a POC,
 saying explicity that you can't get ahold of this person, then it would
 seem to me to be a rather trivial matter of programming to transplant
 a very similar sort of annotation into each and every IP block or AS
 record that has that same specific POC record as one of its associated
 POC records, either Admin, or Technical, or whatever.

Also a nice idea, and one that I've taken as a formal suggestion for
improvement.

 ...
 
 2)  You are already (apparently) processing _some_ certain flavors of
 ``fraud reports''  that come in to you via that nice fancy web form you
 folks built and put up on the ARIN web site... you know... the one with
 the nice (and misleading) introduction that entices people like me to
 take the time to use it enter reports about incidents that have traditionally
 been called around these parts ``hijacking''.
 
 (Note:  That's the word that _you_ used on your web site to say what
 should be reported via the form.  Was I a fool to take you at your word?
 Let me be clear... I am *not* *not* *not* encouraging you to simply
 redact/delete that word from your web site.  No no!  Rather I hope to
 encourage you/ARIN to actually accept and at least investigate reports
 of _all_ flavors of what we around here used to call good old fashioned
 ``hijacking'', regardless of whether the perp was gracious enough to
 also make your choice clearer by dicking with the relevant WHOIS records
 or not.)

Your understanding of our fraud process is correct, and presently the only
form of hijacking which we have the ability to correct is address blocks
where the organization have been changed contrary to policy.  To address
your follow-on question, our determinations are indeed definitive and we
correct the WHOIS database accordingly.

 I think you can see where I'm going with this.  You have, I think, tried to
 demur (is that the right word?) on ARIN's behalf, from _either_ investigating
 or, subsequently, from issuing any kind of ``determination'' as regards to
 whether a given block is being routed by the party or parties who ought to
 be routing it, or by some uninvited interloper.

Incorrect.  We determine whether an entry for an address block in WHOIS has
been changed contrary to community-adopted policy.  This means carefully 
reviewing the information supplied on the associated change requests and
various corresponding public records.  *None of it related to whether a 
given party should be routing a given address block*

 ...
 So no, please *do not* go around ``revoking resources''... whatever the hell
 that means.  Certainly, if some half-dead, left-for-dead dot-bomb company
 has a /18, and if your records still say that they have a /18, then they still
 have a /18.  Period.  And if then, some hijacker punk criminal comes along
 and starts routing that /18... well... he's a shmuck, and ought to be dealt
 with.  But the old Dot-Bomb semi-defunct company still does ``own'' (please
 excuse my use of that terminology, which I'm sure you won't approve) that
 block.  So you shouldn't be ``revoking'' anything.  That's not what any of
 this is about.

Semi-defunct firms may hold address blocks, but address blocks assigned to 
fully defunct organizations are returned to the free pool per community 
policy.

 All I want from ARIN, and all I expect from ARIN, in cases like these are
 (a) at least some willingness and effort expended to investigate and (2)
 at least *some sort* of (perhaps minimalist) public statement to the effect
 of ``Look folks, we've looked at

RE: ARIN Fraud Reporting Form ... (Resource listings yes, resourcerouting no)



 We will shortly be providing a list of number resources with no valid
 POC
 for those who desire it (per the current bulk Whois policy.)
 
  If you can put an annotation into a whois records for a POC,
  saying explicity that you can't get ahold of this person, then it
 would
  seem to me to be a rather trivial matter of programming to
transplant
  a very similar sort of annotation into each and every IP block or AS
  record that has that same specific POC record as one of its
 associated
  POC records, either Admin, or Technical, or whatever.
 
 Also a nice idea, and one that I've taken as a formal suggestion for
 improvement.
 

Those two things would be enough for me for the numbers covered by
agreement, the legacy issue is a tougher nut.  There should be some sort
of requirement that any network being announced have a valid point of
contact. Whose jurisdiction that would fall under for a global Internet
beats me.

Re: ARIN Fraud Reporting Form ... (Resource listings yes, resource routing no)


John,

Let me thank you yet again for devoting your personal time (on a Friday
night no less) to responding to me concerns.  I may not always agree with
you, but I appreciate the effort, and the consideration.


In message 4db05053-fcd4-4459-b226-991435e90...@arin.net, 
John Curran jcur...@arin.net wrote:

We will shortly be providing a list of number resources with no valid POC
for those who desire it (per the current bulk Whois policy.)

But I think you understand that I was suggesting something that's readily
accessible, even to the Great Unwashed Masses, within the individual
WHOIS records... not exclusive to just your ordained bulk whois clientel.

You did get that, right?

 If you can put an annotation into a whois records for a POC,
 saying explicity that you can't get ahold of this person, then it would
 seem to me to be a rather trivial matter of programming to transplant
 a very similar sort of annotation into each and every IP block or AS
 record that has that same specific POC record as one of its associated
 POC records, either Admin, or Technical, or whatever.

Also a nice idea, and one that I've taken as a formal suggestion for
improvement.

Thank you.

Your understanding of our fraud process is correct, and presently the only
form of hijacking which we have the ability to correct...

Well, now, as Ronald Regan used to say ``There you go again!''

I've tried to be clear.  I'll try again.

Many many many people have told me, off-list, and even before this conver-
sation, that you folks can't change the routing table, and that even if
you could, most probably would never want you to exercise that authority.
So I do fully understand where the weight of public opinion falls along that
particular axis.  Believe me, I do.

But please do try to understand me. I was not asking you to ``correct''
any hijacking incident.  You can't.  So let's just agree on that, and
also agree that that is not what we are even talking about.

What I said was ``annotate'' and/or ``announce'' and/or ``make _some_
sort of public statement or comment''.  This, I think, would not be
straying so substantially outside of your charter than anybody would
ever beat you up over it, especially if you folks exercised the kind
of caution and careful investigation which I believe you are more than
capable of, and if you thence only made public ``This is really fishy
looking'' type comments when your internal investigations have shown that
yes, indeed, this one really looks, smells, and tastes pretty darn awful.
(And frankly, I think this would apply to all four of the cases I have
written about here recently.)

So have I been unambiguously clear now?  I neither want nor expect you
to ``correct'' anything.  That sort of thing, I would agree, is not
your job.  But I don't think that fact implies that either you personally,
or ARIN as an organization have any kind of formal responsibility to
behave as blind deaf mutes with no opinions whatsoever, at any time, about
anything.

Some people would tell you that its a free country, and that you have
a right to an opinion.  I guess what I'm saying is that when it comes to
ARIN, and allegations of hijacking of number resources that you have
been chartered to administer, you have not merely a right, but actually
a _responsibility_ to an opinion.  And you should formulate it, and state
it, publically, when the need arises, which is to say whenever you receive
a credible allegation of the misappropriation of number resources that
lie within your portfolio.

 I think you can see where I'm going with this.  You have, I think, tried to
 demur (is that the right word?) on ARIN's behalf, from _either_ investigating
 or, subsequently, from issuing any kind of ``determination'' as regards to
 whether a given block is being routed by the party or parties who ought to
 be routing it, or by some uninvited interloper.

Incorrect.  We determine whether an entry for an address block in WHOIS has
been changed contrary to community-adopted policy.  This means carefully
reviewing the information supplied on the associated change requests and
various corresponding public records.  *None of it related to whether a
given party should be routing a given address block*

Right. You may perhaps not have realized it, but I do believe that you
actually just _agreed_ completely with what I said just above.  At present,
you decline to even look at things that don't involve the fiddling of WHOIS
records.  Somebody could be murdered in the next room, and you would decline
to investigate that too, because the community hasn't explicitly chartered
you to do that.

I understand your position, and I think I may even understand what motivates
it... like maybe years and years of having your own constituency beat you
about the head and neck whenever you try to do even the smallest, kindest,
and most generous and well-meaning things if they... the herd of cats...
haven't explicity approved of you doing it, themselves, in writing,

Re: ARIN Fraud Reporting Form ... (Resource listings yes, resourcerouting no)