Send ARIN-consult mailing list submissions to
arin-consult@arin.net
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-consult
or, via email, send a message with subject or body 'help' to
arin-consult-requ...@arin.net
You can reach the person managing the list at
arin-consult-ow...@arin.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-consult digest..."
Today's Topics:
1. Re: ACSP Consultation: ARIN Internet Routing Registry (IRR)
Roadmap (Jay Borkenhagen)
2. Re: ACSP Consultation: ARIN Internet Routing Registry (IRR)
Roadmap (Job Snijders)
3. Re: ACSP Consultation: ARIN Internet Routing Registry (IRR)
Roadmap (Tauber, Tony)
----------------------------------------------------------------------
Message: 1
Date: Wed, 17 Jan 2018 14:24:20 -0500
From: Jay Borkenhagen <j...@braeburn.org>
To: Jason Schiller <jschil...@google.com>, <arin-consult@arin.net>
Subject: Re: [ARIN-consult] ACSP Consultation: ARIN Internet Routing
Registry (IRR) Roadmap
Message-ID: <23135.41700.255674.336...@oz.mt.att.com>
Content-Type: text/plain; charset=us-ascii
The primary goal of this effort should be to utilize ARIN's unique
position in the Internet number resource management system to produce
the most reliable and most accurate IRR for ARIN-assigned resources.
"Tight coupling between ARIN WHOIS and ARIN IRR" seems like a nice,
concise wording for this concept, and I am 100% in favor of it.
Does anyone believe that "Tight coupling between ARIN WHOIS and ARIN
IRR" is *not* the primary goal of the current exercise? If so, please
speak up.
Thanks.
Jay B.
On 16-Jan-2018, Jason Schiller writes:
> 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 <dav...@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|jschil...@google.com|571-266-0006
> _______________________________________________
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN
> Consult Mailing
> List (ARIN-consult@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 i...@arin.net if you experience any issues.
------------------------------
Message: 2
Date: Wed, 17 Jan 2018 19:37:09 +0000
From: Job Snijders <j...@ntt.net>
To: Jason Schiller <jschil...@google.com>
Cc: David R Huberman <dav...@panix.com>, "<arin-consult@arin.net>"
<arin-consult@arin.net>, Jared Mauch <ja...@puck.nether.net>
Subject: Re: [ARIN-consult] ACSP Consultation: ARIN Internet Routing
Registry (IRR) Roadmap
Message-ID: <20180117193709.gw68...@vurt.meerval.net>
Content-Type: text/plain; charset=us-ascii
On Tue, Jan 16, 2018 at 01:21:16PM -0500, Jason Schiller wrote:
> 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.
Yes, agreed, that is a critical requirement to ensure that new IRR work
can assert a degree of authority, so people can trust the data. The
current ARIN IRR did not meet my expectations in that regard.
A note on non-ARIN resources in the new ARIN IRR framework, I can share
experience from the RIPE and APNIC region in that regard.
In the RIPE region non-RIPE objects were also allowed in the RIPE IRR.
This has led to much abuse and lack of clarity on the authoritative
status of objects. The RIPE Database WG has spend years trying to come
to a consensus on how to fix this. If I had been there at the time when
RIPE IRR originally started, I would've made sure that non-RIPE could
not exist in the RIPE IRR, it would've saved us tons of trouble. APNIC
got it right from day #1. In APNIC IRR only APNIC-managed space can
exist. Both RIRs have made provisions to accomodate resources that are
transferring in or out.
Kind regards,
Job
------------------------------
Message: 3
Date: Mon, 22 Jan 2018 20:21:16 +0000
From: "Tauber, Tony" <tony_tau...@comcast.com>
To: "<arin-consult@arin.net>" <arin-consult@arin.net>
Subject: Re: [ARIN-consult] ACSP Consultation: ARIN Internet Routing
Registry (IRR) Roadmap
Message-ID: <a05d82cc-a854-4786-8670-638d469ed...@cable.comcast.com>
Content-Type: text/plain; charset="utf-8"
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_tau...@cable.comcast.com>
Date: Tuesday, January 16, 2018 at 11:47 AM
To: David R Huberman <dav...@panix.com>, Jason Schiller <jschil...@google.com>
Cc: Jared Mauch <ja...@puck.nether.net>, "<arin-consult@arin.net>"
<arin-consult@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-boun...@arin.net> on behalf of David R
Huberman <dav...@panix.com>
Date: Friday, January 12, 2018 at 11:52 AM
To: Jason Schiller <jschil...@google.com>
Cc: Jared Mauch <ja...@puck.nether.net>, "<arin-consult@arin.net>"
<arin-consult@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@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 i...@arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-consult/attachments/20180122/cd6e8a45/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
ARIN-consult mailing list
ARIN-consult@arin.net
http://lists.arin.net/mailman/listinfo/arin-consult
------------------------------
End of ARIN-consult Digest, Vol 64, Issue 4
*******************************************
