[dbwg] ReferralServer and ASNs

[william at elan.net]

On Tue, 19 Aug 2003, Dave Diller wrote:

> I suspect that, since the tag is attached to the ORG itself, that it displays 
> as part of the 'standard dump' that whois returns when a query is run.  IE
> ask for info on a bit of data and it pulls the ORG info followed by the 
> specifics of the query.  ReferralServer is simply included as part of 
> the normal "return this when asked about something belonging to a 
> particular ORG".  Most likely *ANY* ORG with a ReferralServer will 
> return it when the ASN is queried.

That is exactly right, I'm sure it has to do with how ARIN implemented
its whois server and as I said this was unexpected accurance. They can 
probably override it just for ASN output (in fact my own completewhois had 
similar problem as the code for asn lookups is exactly same as ip blocks 
and when it began to see this "referralserver" it naturally started 
doing rwhois lookups, so now I have to override this behavior and/or 
separate ASN lookup to its own code)

This is a part of the problem of which I warned ARIN about (mostly in
private emails) especially when I heard they decided to do it with 
ReferralServer being attribute of only ORG. The problem is that some ISPs 
may not necessarily want to use rwhois for each and every ip block as 
they may have difference policies for different parts of organization,
(especially if they bought another company and have to integrate it)
On the other hand its a lot better if rwhois server (and its name being 
common to number of nets) could be controlled from the same place for 
entire isp (or even more then one). The above situation means that when 
database is normalized a new table needs to be setup for referral server
(and since we need way to control access, it would need to have poc contact,
but if you look closer at the situation its just easier to actually make a
special contact). ARIN has good enough database engineers to know about this
all as well, the problem is that they considered that it would take longer
to implement it that way and it would be more complex for them as well as 
for users then just adding field to ORG or NET tables (even if it means 
database is not normalized) and this leads to problems we have right now.

So what happened is when ARIN actually did a conversion if at least one ip 
block under ORG had listed rwhois server - they used that for ORG, that 
leads to some blocks that do not have working rwhois server - and that is 
at the time when we want to setup new policy (see policy proposal 2003-5)
to require working rwhois server for any isp that has it listed in whois.
What would that do to those isps that did not want it done for particular
ip block - there is no way for them to opt out of rwhois now just for one 
of their blocks (or opt-in and use rwhois just for one block as for example
cogent now has working rwhois for number of ips in 38.0.0.0/8, but not for 
any other blocks listed under PSI orgid)!

There are several ways to deal with this database problem now, one is to 
add ReferralServer field as attribute to NET and decide what to do if both 
ORG and NET have them (this leads to even less "normalized" database as it 
would have repeating data), the other is to allow ISPs to move some of 
their IP blocks into separate ORGs and allow way to know which orgs are 
connected to which other ones i.e. parent ORG idea I proposed in one of
my earlier posts to dbwg (BTW - this would also lead to repeating data and 
database is also not normalized; it really is that the only way to do it 
"right" is to have referral server attribute in its own table or POC with 
references to that from netblocks). 

I hope people at ARIN read this all and will tell us what they intend to 
do about the above referenced problem.

> >   I'm thinking its not exactly a bad idea to allow ISPs to display information
> > about its ASN and its routing policies (i.e. like route server entry but 
> > on the ISP side, rather then directly at radb), but I have reservations 
> > about if rwhois can be used for this (and we do have standard RPSL for 
> > such routing database and in fact several large ISPs do have their own 
> > routedb servers). 
> 
> Even if some "routing policy" features were implemented in rwhois, I 
> seriously doubt we'd ever use them.  There are enough other 
> implementations out there that are more or less complete that I don't 
> see the need to try and incorporate it into RWHOIS.  Neat idea, lot of 
> work, and no real benefit since the functionality already exists in 
> numerous places.

I don't think its a good idea to use RWHOIS to display ASN routing 
policies either (in my view rwhois is obsolute protocol anyway, but we 
still need to wait for CRISP to be formalized before we have any good 
alternative), luckily for us we do have standard RPSL for whois routing
data view. So my question was more general, if its a good idea to allow 
ISPs to display which routing database server they use as part of the ASN 
display in ARIN whois. Right now we have situation that different ISPs 
use different routing servers to display their policies and routing info 
(some isps like CW and L3 run their own routing servers too). Some of 
these routing servers are mirrored, i.e. merit radb and arin routing 
server - but we can not really rely that routing databases would be 
mirrored forewer (arin and merit may have break in their relationship in 
the future - lets hope not, though...) nor all of them are as for example 
altdb is not.

So in general I think having ReferralServer display as part of ASN is not 
bad - but this would be DIFFERENT referralserver then one the used for 
netblocks, it would not be rwhois, but instead would most likely be whois 
display to proper radb server isp uses. Of course, with current relationship
between ASNs and ORGs this can not be easily implemented either, eventhough
its pretty simple.

So to summarize my proposal to deal with this particular problem (that 
referral server listed in ORG is being displayed when queried for ASN) is
to add "ReferralServer" field to ASN table and have it blanked out (not 
NULL, but something else indicating "do not display this atribute"
in whois) by default for all ASNs right now. But also inform everybody of 
existance of this atribute and those ISPs that want should be allowed
to enter it (and this should not be restricated to rwhois, but can be 
regular whois pointing to proper routing database whois server).

Similar way should be done netblocks - a ReferralServer attribute should 
be added there with possible values actual rwhois referral server or
NULL (i.e. display whatever it is in the ORG - this would be default), 
or special "Blank" - i.e. do not display ReferralServer attribute from 
ORG when somebody does whois on this netblock (this is basicly opt-out).

And above would mean ARIN can continue to use substantially the same
code for Netblocks and ASNs and everything would also be more or less 
standard - but it does mean more work for ARIN to actually get things
right this time and not hurry up and just do it quickly.

P.S. Sorry all for long email. It happens with me...

-- 
William Leibzon
Elan Networks
william at elan.net