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

Tauber, Tony Tony_Tauber at comcast.com
Mon Jan 22 15:21:16 EST 2018 

Forwarding to the list as there was some problem last week when I sent it first, though the cc’d folks received it.

Thanks,
Tony

From: Tony Tauber <Tony_Tauber at cable.comcast.com>
Date: Tuesday, January 16, 2018 at 11:47 AM
To: David R Huberman <daveid at panix.com>, Jason Schiller <jschiller at google.com>
Cc: Jared Mauch <jared at puck.nether.net>, "<arin-consult at arin.net>" <arin-consult at arin.net>
Subject: Re: [ARIN-consult] ACSP Consultation: ARIN Internet Routing Registry (IRR) Roadmap


Mark, John, et. al.,



Count me in (like Job and Jay) to help.



In my mind, and there are likely many wrinkles and cases I’m not thinking of, it goes something like this:

At least for resources it’s assigned directly, ARIN already has the data to pro-actively publish plausible AS origin data based on OrgID.



Their XML REST API already brings these things together.

For instance, the OrgID record for MIT<https://whois.arin.net/rest/org/MIT-2.html> shows “Related Networks<https://whois.arin.net/rest/org/MIT-2/nets>” and “Related ASNs<https://whois.arin.net/rest/org/MIT-2/asns>”.

How about if ARIN would publish in IRR/RPSL format route and route6 objects which link each related network with each related AS as a plausible origin?

It would create more records that absolutely necessary, but it seems all would be “possible” and could be done proactively so as to not require explicit action on everyone’s part.

ARIN online could be used to manage records beyond that.



Personally, I don’t know that the “email method” needs to be maintained and is really archaic by most measures.

Asking new personnel to create plain-text emails and make sure there are no invisible characters and line termination just so is really a bit much to ask these days.

Don’t get me started on management of shared passwords that aren’t bound to any specific individual(s).

If there’s a need for bulk/automated operation, APIs with key or other modern authentication approaches should be used.



I don’t know enough about details of ARIN to predict how legacy assignments would be treated.



The existing ARIN IRR data should be decommissioned at some point where data can’t be aligned with the new methods.



I would like to see other RIRs follow suit and hammer out any necessary interworking.



I’m not sure what the usefulness of non-RIR IRR repositories would then be (i.e., ones with weaker/no authorization models), but that’s not for ARIN to decide.



I’m sure there may be a host of things I’m not considering but that’s my idea of how things could/would work sanely that would provide improved confidence for all.



Tony



-----Original Message-----

From: ARIN-consult <arin-consult-bounces at arin.net> on behalf of David R Huberman <daveid at panix.com>

Date: Friday, January 12, 2018 at 11:52 AM

To: Jason Schiller <jschiller at google.com>

Cc: Jared Mauch <jared at puck.nether.net>, "<arin-consult at arin.net>" <arin-consult at arin.net>

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



    > 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

    _______________________________________________

    ARIN-Consult

    You are receiving this message because you are subscribed to the ARIN Consult Mailing

    List (ARIN-consult at arin.net).

    Unsubscribe or manage your mailing list subscription at:

    http://lists.arin.net/mailman/listinfo/arin-consult Please contact the ARIN Member Services

    Help Desk at info at arin.net if you experience any issues.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20180122/cd6e8a45/attachment.html>

More information about the ARIN-consult mailing list