[ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap

[David R Huberman]

> I have concerns that the text above suggests a less close coupling 
> between WHOIS data and IRR data that I had hoped for.  I think without a 
> close coupling the work to reform the IRR becomes a lot less meaningful.

I strongly agree.

The first level of abstraction is the start_ip and end_ip of inetnum 
objects. Rules I think must exist:

- inetnum objects must exactly match a NET object in ARIN Whois
- inet6num objects must exactly match a NET object in ARIN Whois

No inetnum or inet6num object may be asserted in ARIN IRR if it does not 
already exist in ARIN Whois. Why? Because this is how "bad actors" have 
abused RIPEdb and other wide open IRRs to perform one critical function of 
setting up a malevolent operation.

RIPE's db-wg has been having this discussion, and there is very clear 
consensus on the rules I propose above

The second level of abstraction is authorization. As Jason writes:

> For ARIN direct allocations, ARIN direct assignments,and ARIN assigned 
> ASes, the relationship is strongest. ARIN knows the OrgID, ARIN has 
> contact info, and ARIN interacts with the Organization at least once a 
> year for payment.  These resources can be managed by any ARIN Online 
> account linked to the Org.

A rule that I think would make sense:

- maintainer objects are always authorized by the ORG objects in Whois.

This is obvious.  What is less obvious is that you want to authorize 
scripting to ADD/UPDATE/DELETE objects under your maintainer. So something 
like:

- While authorized contacts can add NIC handles to maintainers, 
notifications (notify:) for the maintainer object must always be sent to 
the current ORG pocs to ensure they are aware of changes.

Now Jason brings up data integrity

> 1. First, there is some overlapping data in ARIN WHOIS and ARIN IRR. 
> It should be impossible for these to be out of sync.

Agreed.

> - If a resource's ARIN WHOIS information is updated, if there is IRR data
> it must also be updated.

Agreed. But with forewarning.

> - If a resource is revoked / marked stale in WHOIS , the IRR (if it 
> exists) must also be revoked / marked.

Absolutely, and obvious to everyone I hope.

> 2. ARIN knows who can manage the resources of a given OrgID based on 
> linked ARIN Online accounts and API keys those accounts have created. 
> These same accounts / API Keys should be the ones that can manage IRR 
> data either through ARIN online or a more traditional way that is tied 
> back to the ARIN online account.

Gotta speak up here for "more traditional".  Every operator I've ever 
been at still does this the old and reliable way: email, with cryto
signatures.   At scale, it makes sense to have an API for all this, and 
leverage the API KEY infrastructure already in ARIN Whois.  But for 
discrete changes (which affect the majority of IRR users), email needs to 
remain an option, in my opinion.

> - If a resource is transfered and that is reflected in the WHOIS, 
> ownership of the IRR data must like wise be transfered.

Ding ding ding!  Nice thinking, Jason.

> 3. When an IRR contains a relationship between two or more resources 
> that have different owners is authorization from both required? (i think 
> we have to sort this out a bit.  Please Help)

No.  There is no need for IRR to worry about multiple parties.  Just like 
SWIP, if authorization exists, authorization exists.

> 3.a. Should a route holder be able to to designate an origin AS that 
> they do not hold without the AS holder's acknowledgment?   (maybe)

The autnum and related objects need some real discussion here. Like Jason, 
I suspect the answer is maybe, but I don't know enough to know.  I can 
rope in experts into this thread if you need us to.

> 3.b. Should an AS holder be able to designate their AS as an origin for 
> a route they
>       do not hold with out the route holder's acknowledgement?
>       (no.  they can do all the work and just get the route holder to ack
> it though)

Disagree here, because if the route object is valid, the IRR doesn't need 
to authorize the AS relationship.  But that's all part of "the autnum and 
related objects need some real discussion here".

> 3.c. Should a route holder be able to remove an origin AS from their 
> route without the AS holder's acknowledgment? (yes)

Yes

>
> 3.d. Should a route holder be able to adjust the routing policy 
> associated with someone else's AS, but only with respect to their route without AS
> holders acknowledgment ?  (no)

Didn't grok the situation you're describing.

> 3.e. Should an AS holder be able to document a Peering relationship, 
> transit customer relationship, or transit provider relationship with another
> AS without that AS holder's approval? (maybe yes)

Yes but same as above.

David