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

[Jason Schiller]

Sounds to me like David and I are in agreement, WRT a close
coupling between ARIN WHOIS and ARIN IRR, and the autnum
and related objects need some real discussion here.

Before plunging into that I think it is worth while and solicit what
other's opinions
are WRT a tight coupling between  the ARIN IRR and ARIN WHOIS at least for
ARIN direct allocations, ARIN direct assignments, ARIN issued ASNs.

Looks like Tony is supportive of this approach.

Can others take a moment to comment on this particular question?

__Jason

On Fri, Jan 12, 2018 at 11:52 AM, David R Huberman <daveid at panix.com> wrote:

> 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
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20180116/70841f4c/attachment.html>