[ppml] 2003-5 rwhois/reassignment info
Einar Bohlin
einar.bohlin at mci.com
Thu May 8 11:24:05 EDT 2003
> Suppose you have some spam or other abuse (hacking/attacking) issue with
> an IP belonging to one of "the big providers"...just for example, we'll
> say UUNet. Without public reassignment info, you'll have to send your
> complaint to UUNet...
That's how ISPs have said they want it to work, and how
it works today. Why do ISPs want to shield their
customers? Flip it around, how many companies
make public their entire customer base? The only
one that comes to my mind is the phone company.
But that's for contact purposes. It's not to
evaluate efficient utilization of phone numbers.
> Suppose some small network comes to you to buy a redundant connection and
> wants you to propogate a BGP route for their UUNet PA IP space. Do you
> trust the customer to not lie about their IP space?
Those would have to be swipped. I mentioned that in
another reply, about how a customer who is doing
BGP should have their own ASN and thus an org record.
We'd just be putting the net on their org record, as
we try to do today. But the difference is that the
org record is created and maintained by the customer,
not the ISP.
> I would hope that most ISP
> networks do have technical people on staff and there's no reason to make
> it harder to contact them.
I believe most ISPs who get their IPs from their upstream
do not have 24/7 staff. This is not my area, but
with abuse cases, you want quick resolution, right?
So seems to me you want to contact your upstream or your peer
where the abuse is coming from.
> Would you rather abolish public reassignment
> entirely and make ARIN the POC for all the address space they allocate?
Yes and no. I'm talking about reassignments/reallocations. Resources
directly from the registry should have all the necessary contact info.
> Did you ask them why they want you to submit all the info twice (via
> inetnums and a text file)? That seems like a waste of time/effort.
I intend to ask them why we bother to do the inetnums, especially
when their web-based text file upload system works so well.
> I'd be real happy with that. As I said, letting us swip /30's would
> seriously reduce the size and complexity of our additional space requests.
Would you want it optional or move it from /29 to /30? Why
stop at /30?
> ... If you have some automated
> system that would submit a text format to ARIN, you could just as easily
> have it generate and submit in the ARIN-REASSIGN-SIMPLE-3.0 format.
We have an automated system that does just that. But my
overall question here is what is the point of POC-less public
utilization records? And so far the only reason that's
come back is that it facilitates blacklisting.
Regards,
Einar Bohlin, IP Analyst
IP Team - Ashburn Virginia - MCI/UUNET
Phone: 703 886-7362 (VNET 806-7362)
email: einar.bohlin at mci.com
On Thu, 8 May 2003 jlewis at lewis.org wrote:
> On Wed, 7 May 2003, Einar Bohlin wrote:
>
> > I understand that there are good faith blacklisters,
> > but if things change for them, I'm sure they could
> > adapt. If utilization info is public these days solely
> > or primarily for blacklisters, then ISPs have to talk
> > about why utilization info is public. All this
> > effort by ISPs to create public utilization info is
> > to support blacklisting?
>
> No...that's just one group that relies heavily on it. Abuse related
> issues are the primary reason that comes to my mind though. Forgetting
> about DNSBLs for a moment, here are a few more examples supporting public
> reassignment info.
>
> Suppose you have some spam or other abuse (hacking/attacking) issue with
> an IP belonging to one of "the big providers"...just for example, we'll
> say UUNet. Without public reassignment info, you'll have to send your
> complaint to UUNet's (overloaded) abuse address, where it will surely be
> delayed if not discarded. With public reassignment info, you can send it
> to the smaller ISP customer of UUNet and at least know that the
> appropriate people got it, or perhaps even just call them on the phone.
> Why hide them behind UUNet?
>
> Suppose some small network comes to you to buy a redundant connection and
> wants you to propogate a BGP route for their UUNet PA IP space. Do you
> trust the customer to not lie about their IP space? Do you call UUNet,
> wade through their phone menus, and try to find someone who will talk to a
> non-customer and verify one of their customer's IP assignments, or would
> you rather just check with whois and see that the space is swipped to the
> customer?
>
> > That's not going to happen. The trend is that
> > ISPs are covering their customers, being the POC for
> > reassigned nets. It makes sense, contacting the cust
> > POC was mostly futile anyway. And I see that ARIN is
>
> That depends on the customer. Lots of smaller nets have no technical
> people on staff, and so even if you do get through on the phone, they may
> not understand why you're bothering them. I would hope that most ISP
> networks do have technical people on staff and there's no reason to make
> it harder to contact them. Would you rather abolish public reassignment
> entirely and make ARIN the POC for all the address space they allocate?
> Just send everything to abuse at arin.net and let them sort it out?
>
> > I'm truly glad we don't have to swip /30s, especially
> > the point to point nets. But what about the customer
> > who gets the /30 as you say for a firewall/NAT? Why
> > do they get special anonymity? Why is the cutoff /29,
> > and not, for example, /19? I'm serious.
> >
> > By the way, APNIC requires swip for /29 and larger nets,
> > just like ARIN, but at APNIC /32 to /30 are optional.
>
> I'd be real happy with that. As I said, letting us swip /30's would
> seriously reduce the size and complexity of our additional space requests.
> In my last one, there were lots of subnets where I had to arbitrarily make
> up a use category. i.e. there are lots of networks we've marked as
> reserved and then subnetted into /30's for customer connections or
> router/firewall pairs. Often, these networks include a collection of
> /30's for customers in different cities on different service types. ARIN
> wants all non-swipped assignments categorized as one of
> dial|isdn|web|leased|dsl|colo|wireless and some other categories that
> never apply to us and I've left out. How do you categorize a /24 that's a
> mix of /30 backbone router PTP interfaces, customer serial interfaces, and
> router/firewall ethernets for ISDN, DSL, and leased line customers??
> If the answer is, show each assignment individually, then just let us swip
> them.
>
> > Right now we do a swip for every net. What if there
> > was an approved text format, and then you'd be able to mail
> > or web input that for utilization, weekly, monthly or whatever?
> > That's aside from whether the info is public or not.
>
> They already accept a text format via email. If you have some automated
> system that would submit a text format to ARIN, you could just as easily
> have it generate and submit in the ARIN-REASSIGN-SIMPLE-3.0 format.
>
> > range from them. APNIC naturally wants all your swips
> > (inetnums) up to date. But then very interestingly, they
> > wanted a text file of all reassignments, in a specified
> > format, every single one. It wasn't that hard to do.
> > But it did make me wonder why we did all the inetnums
> > in the first place.
>
> Did you ask them why they want you to submit all the info twice (via
> inetnums and a text file)? That seems like a waste of time/effort.
>
> > One last thing, utilization info could always be
> > public, regardless of the authorized by ARIN
> > method, if the ISP wanted it to be that way.
>
> All but a few possible exceptions will choose not to unless forced to.
> Why spend the time and money making the info available if you're not
> required to?
>
> ----------------------------------------------------------------------
> Jon Lewis *jlewis at lewis.org*| I route
> System Administrator | therefore you are
> Atlantic Net |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>
>
More information about the ARIN-PPML
mailing list