From gert at space.net Wed Apr 1 03:52:31 2015 From: gert at space.net (Gert Doering) Date: Wed, 1 Apr 2015 09:52:31 +0200 Subject: [ARIN-consult] Community Consultation on IRR Route Validation. attorney client communication. In-Reply-To: References: <6ABC1C4F-5F28-4F6B-AC9E-66D8FA92FE1C@corp.arin.net> <4A3617FF-B259-4A38-85AB-248B2A0F4F13@akamai.com> <20150331205248.GM54385@Space.Net> Message-ID: <20150401075231.GO54385@Space.Net> Hi, On Tue, Mar 31, 2015 at 09:09:22PM +0000, John Curran wrote: > On Mar 31, 2015, at 4:52 PM, Gert Doering wrote: > > ... > > Now, I understand that you can buy a maintainer object, and thus protect > > your own address space - but as a user of the RADB, how can I see which > > objects are legitimate, and which (paid-for!) maintainers just put in > > stuff that does not belong to them? > > On a (slightly) related question... Are there organizations, e.g. security > or management service providers, that put entries in routing registries and > update them on behalf of their customers? I've heard folks mention this now > and then, but have no direct experience (and it could easily be relevant to > understanding goals and requirements for any changes) "Yes" :-) - I won't claim to know all particular cases, but we certainly have the case that a customer comes to us with a PI network (= portable addresses), asking us to route it for him, but is not really interested in the doing all technical details himself - so we maintain the RIPE DB for them - either pointing the route: object at our own AS, or at their AS and also updating their inetnum: object. In RIPE land, there is also the concept of "sponsoring LIR" for portable address space (PI), where the LIR is responsible for maintaining the ties between end user<->LIR<->RIPE NCC. In that case it's not unusual for the sponsoring LIR to also maintain the RIPE DB objects (inetnum, route) even if they are not providing transit connectivity. In the RIPE DB, this is fairly straightforward - central to authorization are the maintainers referenced by the inetnum: objects, so if a customer wants us to do something, they can either give us their maintainer credentials (not really recommended), or add our maintainer object to their inetnum: and aut-num: objects, so we can then proceed to do the necessary DB updates. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From andrew.dul at quark.net Wed Apr 1 10:43:41 2015 From: andrew.dul at quark.net (Andrew Dul) Date: Wed, 01 Apr 2015 07:43:41 -0700 Subject: [ARIN-consult] Community Consultation on IRR Route Validation. attorney client communication. In-Reply-To: References: <6ABC1C4F-5F28-4F6B-AC9E-66D8FA92FE1C@corp.arin.net> <4A3617FF-B259-4A38-85AB-248B2A0F4F13@akamai.com> <20150331205248.GM54385@Space.Net> Message-ID: <551C041D.8070109@quark.net> On 3/31/2015 2:09 PM, John Curran wrote: > On Mar 31, 2015, at 4:52 PM, Gert Doering wrote: >> ... >> Now, I understand that you can buy a maintainer object, and thus protect >> your own address space - but as a user of the RADB, how can I see which >> objects are legitimate, and which (paid-for!) maintainers just put in >> stuff that does not belong to them? > On a (slightly) related question... Are there organizations, e.g. security > or management service providers, that put entries in routing registries and > update them on behalf of their customers? I've heard folks mention this now > and then, but have no direct experience (and it could easily be relevant to > understanding goals and requirements for any changes) > > I have created IRR records on behalf of customers in the past. This is most often done for stub networks who are either singly homed to your network or multihomed with another network. The customer often doesn't have the experience and/or currently doesn't or doesn't want to maintain the technical expertise to manage these types of routing records. Andrew From jcurran at arin.net Wed Apr 1 10:47:43 2015 From: jcurran at arin.net (John Curran) Date: Wed, 1 Apr 2015 14:47:43 +0000 Subject: [ARIN-consult] Community Consultation on IRR Route Validation. attorney client communication. In-Reply-To: <551C041D.8070109@quark.net> References: <6ABC1C4F-5F28-4F6B-AC9E-66D8FA92FE1C@corp.arin.net> <4A3617FF-B259-4A38-85AB-248B2A0F4F13@akamai.com> <20150331205248.GM54385@Space.Net> <551C041D.8070109@quark.net> Message-ID: <459A869C-3C8C-4A38-8340-9F0F70B6775F@corp.arin.net> On Apr 1, 2015, at 10:43 AM, Andrew Dul wrote: > On 3/31/2015 2:09 PM, John Curran wrote: >> On Mar 31, 2015, at 4:52 PM, Gert Doering wrote: >>> ... >>> Now, I understand that you can buy a maintainer object, and thus protect >>> your own address space - but as a user of the RADB, how can I see which >>> objects are legitimate, and which (paid-for!) maintainers just put in >>> stuff that does not belong to them? >> On a (slightly) related question... Are there organizations, e.g. security >> or management service providers, that put entries in routing registries and >> update them on behalf of their customers? I've heard folks mention this now >> and then, but have no direct experience (and it could easily be relevant to >> understanding goals and requirements for any changes) >> > I have created IRR records on behalf of customers in the past. This is > most often done for stub networks who are either singly homed to your > network or multihomed with another network. The customer often doesn't > have the experience and/or currently doesn't or doesn't want to maintain > the technical expertise to manage these types of routing records. How often does that pose a problem when the customers move on to another provider? Is that a minor issue or do we end up with outdated cruft in the IRR as a result? /John From andrew.dul at quark.net Wed Apr 1 11:02:37 2015 From: andrew.dul at quark.net (Andrew Dul) Date: Wed, 01 Apr 2015 08:02:37 -0700 Subject: [ARIN-consult] Community Consultation on IRR Route Validation. attorney client communication. In-Reply-To: <459A869C-3C8C-4A38-8340-9F0F70B6775F@corp.arin.net> References: <6ABC1C4F-5F28-4F6B-AC9E-66D8FA92FE1C@corp.arin.net> <4A3617FF-B259-4A38-85AB-248B2A0F4F13@akamai.com> <20150331205248.GM54385@Space.Net> <551C041D.8070109@quark.net> <459A869C-3C8C-4A38-8340-9F0F70B6775F@corp.arin.net> Message-ID: <551C088D.8030404@quark.net> On 4/1/2015 7:47 AM, John Curran wrote: > On Apr 1, 2015, at 10:43 AM, Andrew Dul wrote: >> On 3/31/2015 2:09 PM, John Curran wrote: >>> On Mar 31, 2015, at 4:52 PM, Gert Doering wrote: >>>> ... >>>> Now, I understand that you can buy a maintainer object, and thus protect >>>> your own address space - but as a user of the RADB, how can I see which >>>> objects are legitimate, and which (paid-for!) maintainers just put in >>>> stuff that does not belong to them? >>> On a (slightly) related question... Are there organizations, e.g. security >>> or management service providers, that put entries in routing registries and >>> update them on behalf of their customers? I've heard folks mention this now >>> and then, but have no direct experience (and it could easily be relevant to >>> understanding goals and requirements for any changes) >>> >> I have created IRR records on behalf of customers in the past. This is >> most often done for stub networks who are either singly homed to your >> network or multihomed with another network. The customer often doesn't >> have the experience and/or currently doesn't or doesn't want to maintain >> the technical expertise to manage these types of routing records. > How often does that pose a problem when the customers move on > to another provider? Is that a minor issue or do we end up with > outdated cruft in the IRR as a result? I haven't seen it cause a problem, but I guess it could in some cases. Usually it just creates cruft. Although for some customers who have their own AS the old crufty record still has their origin AS and thus ends up working fine once, especially if the new provider adds that AS to their AS-SET. Andrew From Tony_Tauber at cable.comcast.com Wed Apr 1 11:05:22 2015 From: Tony_Tauber at cable.comcast.com (Tauber, Tony) Date: Wed, 1 Apr 2015 15:05:22 +0000 Subject: [ARIN-consult] Community Consultation on IRR Route Validation. attorney client communication. In-Reply-To: <459A869C-3C8C-4A38-8340-9F0F70B6775F@corp.arin.net> References: <6ABC1C4F-5F28-4F6B-AC9E-66D8FA92FE1C@corp.arin.net> <4A3617FF-B259-4A38-85AB-248B2A0F4F13@akamai.com> <20150331205248.GM54385@Space.Net> <551C041D.8070109@quark.net> <459A869C-3C8C-4A38-8340-9F0F70B6775F@corp.arin.net> Message-ID: On 4/1/15, 10:47 AM, "John Curran" wrote: >On Apr 1, 2015, at 10:43 AM, Andrew Dul wrote: >> >>> >> I have created IRR records on behalf of customers in the past. This is >> most often done for stub networks who are either singly homed to your >> network or multihomed with another network. The customer often doesn't >> have the experience and/or currently doesn't or doesn't want to maintain >> the technical expertise to manage these types of routing records. > >How often does that pose a problem when the customers move on >to another provider? Is that a minor issue or do we end up with >outdated cruft in the IRR as a result? All.the.time I?d venture to say that proxy registration is the source of most of the cruft. That said, managing IRR stuff should be at least as easy for ARIN to walk address-holders through on their portal as RPKI stuff including some alerting that the routing table has gone out of apparent alignment with the IRR. Thanks, Tony From scottleibrand at gmail.com Wed Apr 1 13:23:33 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 1 Apr 2015 10:23:33 -0700 Subject: [ARIN-consult] Community Consultation on IRR Route Validation. attorney client communication. In-Reply-To: <551C088D.8030404@quark.net> References: <6ABC1C4F-5F28-4F6B-AC9E-66D8FA92FE1C@corp.arin.net> <4A3617FF-B259-4A38-85AB-248B2A0F4F13@akamai.com> <20150331205248.GM54385@Space.Net> <551C041D.8070109@quark.net> <459A869C-3C8C-4A38-8340-9F0F70B6775F@corp.arin.net> <551C088D.8030404@quark.net> Message-ID: When Andrew and I were in the NOC at Internap (quite awhile ago now), we would create RADB and CWRR objects for customers who didn't do so themselves when accepting a new route from them (to make sure our transit providers who used IRRs would accept it). Occasionally we would get a request from a customer or former customer who wanted us to delete the proxy-registered object so they could create their own, which we of course did. But most of them, once created, probably never got removed. If someone is interested, you could go see how many objects still exist with sleibrand at internap.com on them. ;-) -Scott On Wed, Apr 1, 2015 at 8:02 AM, Andrew Dul wrote: > On 4/1/2015 7:47 AM, John Curran wrote: > > On Apr 1, 2015, at 10:43 AM, Andrew Dul wrote: > >> On 3/31/2015 2:09 PM, John Curran wrote: > >>> On Mar 31, 2015, at 4:52 PM, Gert Doering wrote: > >>>> ... > >>>> Now, I understand that you can buy a maintainer object, and thus > protect > >>>> your own address space - but as a user of the RADB, how can I see > which > >>>> objects are legitimate, and which (paid-for!) maintainers just put in > >>>> stuff that does not belong to them? > >>> On a (slightly) related question... Are there organizations, e.g. > security > >>> or management service providers, that put entries in routing > registries and > >>> update them on behalf of their customers? I've heard folks mention > this now > >>> and then, but have no direct experience (and it could easily be > relevant to > >>> understanding goals and requirements for any changes) > >>> > >> I have created IRR records on behalf of customers in the past. This is > >> most often done for stub networks who are either singly homed to your > >> network or multihomed with another network. The customer often doesn't > >> have the experience and/or currently doesn't or doesn't want to maintain > >> the technical expertise to manage these types of routing records. > > How often does that pose a problem when the customers move on > > to another provider? Is that a minor issue or do we end up with > > outdated cruft in the IRR as a result? > I haven't seen it cause a problem, but I guess it could in some cases. > Usually it just creates cruft. Although for some customers who have > their own AS the old crufty record still has their origin AS and thus > ends up working fine once, especially if the new provider adds that AS > to their AS-SET. > > Andrew > _______________________________________________ > 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: From gert at space.net Wed Apr 1 15:10:17 2015 From: gert at space.net (Gert Doering) Date: Wed, 1 Apr 2015 21:10:17 +0200 Subject: [ARIN-consult] Community Consultation on IRR Route Validation. attorney client communication. In-Reply-To: <3DB4C0B6-8621-441C-906F-B6B2F8FE3829@akamai.com> References: <6ABC1C4F-5F28-4F6B-AC9E-66D8FA92FE1C@corp.arin.net> <4A3617FF-B259-4A38-85AB-248B2A0F4F13@akamai.com> <20150331205248.GM54385@Space.Net> <3DB4C0B6-8621-441C-906F-B6B2F8FE3829@akamai.com> Message-ID: <20150401191017.GY54385@Space.Net> Hi, On Tue, Mar 31, 2015 at 09:47:55PM +0000, Hannigan, Martin wrote: > > On Mar 31, 2015, at 4:52 PM, Gert Doering wrote: > > > > On Tue, Mar 31, 2015 at 08:28:08PM +0000, Hannigan, Martin wrote: > >> AS 32787 and AS 20940 will continue to use and expand use of RADB for the foreseeable future. > > > > So, what do you suggest how the gaping security problems of RADB can be > > solved? > > The same as we would when they arise in any other IRR? Point fingers > of shame, get commitments to fix or go elsewhere? Well, let me rephrase that statement. What benefits do you see in RADB that an ARIN IRR DB does not have? > > Now, I understand that you can buy a maintainer object, and thus protect > > your own address space - but as a user of the RADB, how can I see which > > objects are legitimate, and which (paid-for!) maintainers just put in > > stuff that does not belong to them? > > How will that differ in an ARIN IRR? Well, in the context of this thread: ARIN would have to ensure that for ARIN-assigned space only persons authorized by whoever holds that space can modify the routing entries. This is not there yet, but this was precisely the question asked "should ARIN do this?". (For address space assigned by other RIRs, this remains to be solved - one answer could be "do not permit entry into ARIN DB if the space is not ARIN assigned, but mirror RIPE, APNIC, ... IRR DB entries, so a user can have a complete picture based on properly authorized data"). The issue of unauthorized route: objects needs solving, and I see no way how RADB can reasonably achieve this, except by forcing all resource holders world wide to maintain their data in their home RIR DB *and* in the RADB, paying merit for the privilege of doing so. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From gert at space.net Wed Apr 1 15:14:22 2015 From: gert at space.net (Gert Doering) Date: Wed, 1 Apr 2015 21:14:22 +0200 Subject: [ARIN-consult] Community Consultation on IRR Route Validation. attorney client communication. In-Reply-To: <459A869C-3C8C-4A38-8340-9F0F70B6775F@corp.arin.net> References: <6ABC1C4F-5F28-4F6B-AC9E-66D8FA92FE1C@corp.arin.net> <4A3617FF-B259-4A38-85AB-248B2A0F4F13@akamai.com> <20150331205248.GM54385@Space.Net> <551C041D.8070109@quark.net> <459A869C-3C8C-4A38-8340-9F0F70B6775F@corp.arin.net> Message-ID: <20150401191422.GZ54385@Space.Net> Hi, On Wed, Apr 01, 2015 at 02:47:43PM +0000, John Curran wrote: > How often does that pose a problem when the customers move on > to another provider? Is that a minor issue or do we end up with > outdated cruft in the IRR as a result? You'll end up with some amount outdated cruft, namely, route: objects authorizing the previous provider to announce a network in question. The RIPE DB solves this by permitting the resource holder to always *delete* a route: object, without authorization by the AS holder (creation needs authorization by network and AS holder, to avoid "spamming" someone's filter generation processes by generating tons of bogus route objects that point to a victim AS). I see the risk for abuse by this as fairly low, but some sort of garbage collection process ("dear network holder, we see that you have two route: objects, one recent one which matches what is in BGP and one 10+ year old one that seems to be stale, please clean up") would be reasonable to have. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From kre at ecix.net Sun Apr 12 07:51:05 2015 From: kre at ecix.net (Kay Rechthien) Date: Sun, 12 Apr 2015 13:51:05 +0200 Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: <550864CA.6030807@arin.net> References: <550864CA.6030807@arin.net> Message-ID: <7291D6A5-E816-4952-8262-412FEA4D2071@ecix.net> Hi ARIN & Community, > On 17 Mar 2015, at 18:30, ARIN wrote: > > * Should ARIN begin a new project to enable IRR route object validation > to the ARIN registry database? Yes. > * If this consultation results in support for moving forward in this > area of work, it will be taken under advisement by the ARIN Board of > Trustees for consideration as a new area of priority by the ARIN > organization. If approved, ARIN staff would participate in > community-driven initiatives in this area, and using information > gathered from these initiatives and this consultation, produce a > specific proposal to move forward. Yes > * If yes, should this effort be coordinated with other RIRs to help > facilitate cross-registry authentication? Yes. > * If yes, should this effort also support third party IRR route object > authentication? Yes An authoritative source for routing policies and origin authorisation is definitely needed for the arin region. Right now it is rather hard to get reliable filtering for ARIN IP space and we saw many abuse in the last years. It would be a great step forward and would lead to another reliable source for proper protection of peering sessions. Best Regards Kay From bill at herrin.us Sun Apr 12 12:28:51 2015 From: bill at herrin.us (William Herrin) Date: Sun, 12 Apr 2015 12:28:51 -0400 Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: References: <550864CA.6030807@arin.net> Message-ID: On Wed, Mar 18, 2015 at 8:59 AM, David Huberman wrote: > I believe ARIN should not spend any money on further > development of the IRR until there is a loud noise from the > operational community to do so. > > The RPKI efforts cost ARIN a lot of member money, and the > benefits the operational community are receiving from all that > work are neglible if not near zero. Howdy, I concur. Until ARIN can resolve the open publication legal quandary it encountered with RPKI, it should spend not spend another cent developing new routing databases. Absent open publication, such databases are without discernible value. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jcurran at arin.net Sun Apr 12 12:44:52 2015 From: jcurran at arin.net (John Curran) Date: Sun, 12 Apr 2015 16:44:52 +0000 Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: References: <550864CA.6030807@arin.net>

Message-ID: <0DD70F76-DFBC-4D73-A655-873F4A4ABC73@corp.arin.net> On Apr 12, 2015, at 9:28 AM, William Herrin wrote: > > On Wed, Mar 18, 2015 at 8:59 AM, David Huberman > wrote: >> I believe ARIN should not spend any money on further >> development of the IRR until there is a loud noise from the >> operational community to do so. >> >> The RPKI efforts cost ARIN a lot of member money, and the >> benefits the operational community are receiving from all that >> work are neglible if not near zero. > > Howdy, > > I concur. Until ARIN can resolve the open publication legal quandary > it encountered with RPKI, it should spend not spend another cent > developing new routing databases. Absent open publication, such > databases are without discernible value. Bill - Can you elaborate some on open publication legal quandary that you anticipate with IRR services? Thanks! /John From bill at herrin.us Sun Apr 12 12:54:05 2015 From: bill at herrin.us (William Herrin) Date: Sun, 12 Apr 2015 12:54:05 -0400 Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: <0DD70F76-DFBC-4D73-A655-873F4A4ABC73@corp.arin.net> References: <550864CA.6030807@arin.net>

<0DD70F76-DFBC-4D73-A655-873F4A4ABC73@corp.arin.net> Message-ID: On Sun, Apr 12, 2015 at 12:44 PM, John Curran wrote: > On Apr 12, 2015, at 9:28 AM, William Herrin wrote: >> Until ARIN can resolve the open publication legal quandary >> it encountered with RPKI, it should not spend another cent >> developing new routing databases. Absent open publication, such >> databases are without discernible value. > > Can you elaborate some on open publication legal quandary that > you anticipate with IRR services? Publication under contract. Any contract. -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From jrhett at netconsonance.com Sun Apr 12 13:10:23 2015 From: jrhett at netconsonance.com (Jo Rhett) Date: Sun, 12 Apr 2015 10:10:23 -0700 Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: References: <550864CA.6030807@arin.net>

Message-ID: <6CC13E4C-4BF2-430F-9049-0EFD45119766@netconsonance.com> On Apr 12, 2015, at 9:28 AM, William Herrin wrote: > I concur. Until ARIN can resolve the open publication legal quandary > it encountered with RPKI, it should spend not spend another cent > developing new routing databases. Absent open publication, such > databases are without discernible value. RPKI may have lacked an operational gain, or borne too high a cost for deployment within organizations. When an organization fails to provide data to RPKI, RPKI has less value to all subscribers. That has no basis on whether or not a validated IRR has meaning. RPKI is optionally used at the edge, IRR improves the central database. Totally different use case scenarios, and totally different requirements for gaining value for the user. The validated IRR has value to everyone whether you participate or not. The RPKI has value only when the source network participates. As numerous others have pointed out, other regional IRRs have been successful in similar efforts. FYI: sorry for not speaking up sooner. In case it isn?t obvious from this post, I vehemently support the idea of ARIN undertaking this effort to improve the ARIN IRR which I utilize at multiple organizations. Vote in favor. -- Jo Rhett +1 (415) 999-1798 Skype: jorhett Net Consonance : net philanthropy to improve open source and internet projects. From danny at tcb.net Thu Apr 16 23:41:00 2015 From: danny at tcb.net (Danny McPherson) Date: Thu, 16 Apr 2015 21:41:00 -0600 Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: <6CC13E4C-4BF2-430F-9049-0EFD45119766@netconsonance.com> References: <550864CA.6030807@arin.net>

<6CC13E4C-4BF2-430F-9049-0EFD45119766@netconsonance.com> Message-ID: <8c45be4177550c4be2b0a29699f9cff8@tcb.net> On 2015-04-12 11:10, Jo Rhett wrote: > As numerous others have pointed out, other regional IRRs have been successful in similar efforts. > > FYI: sorry for not speaking up sooner. In case it isn't obvious from this post, I vehemently support the idea of ARIN undertaking this effort to improve the ARIN IRR which I utilize at multiple organizations. Vote in favor. I agree with Jo and others here. If you can't squelch the cruft (especially the slew of proxied-registered stuff that mostly certainly exists, albeit much for good reason initially, but with bad long-term effects), then you at least need a mechanism to allow resources holders who actively maintain their IRR objects (wherever they live, however they're formatted) to provide an indicator to folks that they can find them there, and that their upstreams or peers can employ that information for control plane (&data plane) filtering. And because RIRs likely aren't ever going to be the only ones to operate IRRs (e.g., ISPs that use their own or other DB formats for internal and external routing provisioning functions) which is good and bad, methinks, solutions need to be developed to ensure that resource holders have the capability to specify precisely where the policy information associated with their number resources live (e.g., a URI, or something similar) - hence "validated", which could be nothing more than a pointer. Additionally, in this day and age there also really needs to be some sort of push (pub/sub) model so that relying parties that are using this information to develop policy can be informed when adds/mods/dels take place - they shouldn't have to continuously/periodically discover and enumerate all the structures in all the feasible IRRs to discover changes they might need to evaluate and effectuate in their routing policies. If you solve this issue then the stable and secure IRRs will gain market share, IRR hygiene issues will become more evident (RIRs should lead the pack in cleaniness because of RIPE-esque techniques), operators can use nearly all the existing configuration tooling, folks that operate their own IRRs (many for good reason) can continue, and the same control plane policies derived for routing can be used to develop feasible path anti-spoofing policies in the data plane (inter-domain) and help to automate a good chunk of the BCP38 difficulties that persist and enable reflective amplification and other attacks. Out of the gate you get origin validation in persistent storage on routers with no new router code or protocols, and can apply per-peer policies in the control and data plane like we did in the '90s (mostly the former because spoofing wasn't such an issue). All for linear solutions and reuse here, with mechanisms that help desk folks can debug, and some sensible means to implement sufficient operational buffers that protect our network (rather than tight coupling required by others solutions). -danny -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Fri Apr 17 12:44:28 2015 From: jschiller at google.com (Jason Schiller) Date: Fri, 17 Apr 2015 12:44:28 -0400 Subject: [ARIN-consult] COMMUNITY CONSULTATION ON IRR ROUTE VALIDATION Message-ID: I believe it would be in the best interest of the Internet community to have a well maintained IRR by ARIN. I believe ARIN is in a unique position to do this. ARIN has a direct relationship with the organizations to which it allocates number resources to, and a contact which is regularly billed (for resources under RSA) and POCs which are validated annually. Having an IRR which necessarily reflects this registration data (as SWIP does today) would be good for the community. Allowing resource holders to document downstream (proxy) registration details of their re-allocates or re-assignments would also be good. This could be closely coupled with SWIP or RWhois. Allowing holders of re-allocates or assignments to document their usage would be good to the extent ARIN can verify that are the authentic resource holder. Perhaps some of the RPKI machinery could be useful here. The other RIRs are in the same unique position as ARIN, and ARIN should work with them to ensure this service can be provided globally if they wish to participate. I do not believe ARIN should undertake work to establish or maintain an IRR which can be updated by anyone, nor should it mirror databases that do. If ARIN cannot determine who is an authentic resource holder (by virtue of their existing relationship with the resource holder) or if they cannot keep the IRR data closely coupled with the registry data, then they should not maintain an IRR. __Jason -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Fri Apr 17 13:39:58 2015 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 17 Apr 2015 10:39:58 -0700 Subject: [ARIN-consult] COMMUNITY CONSULTATION ON IRR ROUTE VALIDATION In-Reply-To: References: Message-ID: Well put. +1 -Scott On Fri, Apr 17, 2015 at 9:44 AM, Jason Schiller wrote: > I believe it would be in the best interest of the Internet community to > have a well maintained IRR by ARIN. > > I believe ARIN is in a unique position to do this. ARIN has a direct > relationship with the organizations to which it allocates number resources > to, and a contact which is regularly billed (for resources under RSA) and > POCs which are validated annually. > > Having an IRR which necessarily reflects this registration data (as SWIP > does today) would be good for the community. > > Allowing resource holders to document downstream (proxy) registration > details of their re-allocates or re-assignments would also be good. This > could be closely coupled with SWIP or RWhois. > > Allowing holders of re-allocates or assignments to document their usage > would be good to the extent ARIN can verify that are the authentic resource > holder. Perhaps some of the RPKI machinery could be useful here. > > > The other RIRs are in the same unique position as ARIN, and ARIN should > work with them to ensure this service can be provided globally if they wish > to participate. > > > I do not believe ARIN should undertake work to establish or maintain an > IRR which can be updated by anyone, nor should it mirror databases that do. > > If ARIN cannot determine who is an authentic resource holder (by virtue of > their existing relationship with the resource holder) or if they cannot > keep the IRR data closely coupled with the registry data, then they should > not maintain an IRR. > > __Jason > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > > > _______________________________________________ > 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: From jayb at braeburn.org Fri Apr 17 14:38:51 2015 From: jayb at braeburn.org (Jay Borkenhagen) Date: Fri, 17 Apr 2015 14:38:51 -0400 Subject: [ARIN-consult] COMMUNITY CONSULTATION ON IRR ROUTE VALIDATION In-Reply-To: References: Message-ID: <21809.21307.723467.924507@oz.mt.att.com> Thank you, Jason, for stating these thoughts so well and so succinctly. I agree with you 100%. To rephrase one of Jason's points just slightly for emphasis: in my opinion it makes no sense for ARIN to offer an IRR that permits publication of data disagreeing with ARIN's number resource allocations. I know that ARIN's IRR permits this today, but it should not. Thank you. Jay B. On 17-April-2015, Jason Schiller writes: > I believe it would be in the best interest of the Internet community to > have a well maintained IRR by ARIN. > > I believe ARIN is in a unique position to do this. ARIN has a direct > relationship with the organizations to which it allocates number resources > to, and a contact which is regularly billed (for resources under RSA) and > POCs which are validated annually. > > Having an IRR which necessarily reflects this registration data (as SWIP > does today) would be good for the community. > > Allowing resource holders to document downstream (proxy) registration > details of their re-allocates or re-assignments would also be good. This > could be closely coupled with SWIP or RWhois. > > Allowing holders of re-allocates or assignments to document their usage > would be good to the extent ARIN can verify that are the authentic resource > holder. Perhaps some of the RPKI machinery could be useful here. > > > The other RIRs are in the same unique position as ARIN, and ARIN should > work with them to ensure this service can be provided globally if they wish > to participate. > > > I do not believe ARIN should undertake work to establish or maintain an IRR > which can be updated by anyone, nor should it mirror databases that do. > > If ARIN cannot determine who is an authentic resource holder (by virtue of > their existing relationship with the resource holder) or if they cannot > keep the IRR data closely coupled with the registry data, then they should > not maintain an IRR. > > __Jason > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > _______________________________________________ > 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. From Dave.Cooper at Level3.com Fri Apr 17 15:01:30 2015 From: Dave.Cooper at Level3.com (Cooper, Dave) Date: Fri, 17 Apr 2015 19:01:30 +0000 Subject: [ARIN-consult] COMMUNITY CONSULTATION ON IRR ROUTE VALIDATION In-Reply-To: References: Message-ID: +1 Agree 100% From: arin-consult-bounces at arin.net [mailto:arin-consult-bounces at arin.net] On Behalf Of Jason Schiller Sent: Friday, April 17, 2015 9:44 AM To: arin-consult at arin.net Subject: [ARIN-consult] COMMUNITY CONSULTATION ON IRR ROUTE VALIDATION I believe it would be in the best interest of the Internet community to have a well maintained IRR by ARIN. I believe ARIN is in a unique position to do this. ARIN has a direct relationship with the organizations to which it allocates number resources to, and a contact which is regularly billed (for resources under RSA) and POCs which are validated annually. Having an IRR which necessarily reflects this registration data (as SWIP does today) would be good for the community. Allowing resource holders to document downstream (proxy) registration details of their re-allocates or re-assignments would also be good. This could be closely coupled with SWIP or RWhois. Allowing holders of re-allocates or assignments to document their usage would be good to the extent ARIN can verify that are the authentic resource holder. Perhaps some of the RPKI machinery could be useful here. The other RIRs are in the same unique position as ARIN, and ARIN should work with them to ensure this service can be provided globally if they wish to participate. I do not believe ARIN should undertake work to establish or maintain an IRR which can be updated by anyone, nor should it mirror databases that do. If ARIN cannot determine who is an authentic resource holder (by virtue of their existing relationship with the resource holder) or if they cannot keep the IRR data closely coupled with the registry data, then they should not maintain an IRR. __Jason -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Mon Apr 20 15:34:52 2015 From: info at arin.net (ARIN) Date: Mon, 20 Apr 2015 15:34:52 -0400 Subject: [ARIN-consult] Community Consultation on Election-related Bylaws Changes Message-ID: <553554DC.8080805@arin.net> On 13 April 2015, the ARIN Board of Trustees proposed changes to the ARIN Bylaws. Per Article X. Section 6.b. of the Bylaws, these changes require community notification and consultation before they can be adopted. ARIN is opening this community consultation to obtain feedback on the following Bylaws changes. 1. Article VIII. Section 4.a. Voting. Current bylaws language: Voting. Each General Member of record and in good standing on such date that is sixty (60) days before a ballot or election shall be eligible to vote (through its designated member representative voting contact) in such ballot or election? Proposed bylaws language change: Voting. Each General Member of record and in good standing on such date that is forty-five (45) days before a ballot or election shall be eligible to vote (through its voting contact) in such ballot or election? Rationale: a. Replacing the term ?designated member representative? with ?voting contact? throughout the Bylaws and in election-related documentation more clearly describes the function of this type of contact. b. ARIN suggests shortening the time between elections and the voter eligibility cutoff deadline in order to provide member organizations more time to update their voting contact information. 2. Article VIII. Section 4. b. Election Period. Current bylaws language: Election Period. The Election Period shall begin during the final Public Policy and Members Meeting of the year for general elections and as established by the President for other votes. The membership shall receive electronic notice at least 30 days in advance of the election and will have ten (10) calendar days after the Election Period opens to electronically cast their votes, provided that any such electronic transmission shall either set forth or be submitted with information from which it can be determined that the electronic transmission was authorized by the member. Votes received by ARIN after the close of the Election Period shall not be counted. Change To: Election Period. The Election Period shall begin during the final Public Policy and Members Meeting of the year for general elections and as established by the President for other votes. The membership shall receive electronic notice at least 30 days in advance of the election and will have at least seven (7) calendar days after the Election Period opens to electronically cast their votes, provided that any such electronic transmission shall either set forth or be submitted with information from which it can be determined that the electronic transmission was authorized by the member. Votes received by ARIN after the close of the Election Period shall not be counted. Rationale: Under the current meeting and election schedule the elections open on a Thursday and close on a Sunday. The change to at least 7 business days would mean election still open on Thursday, but could close the following Friday. Each year we receive the majority of votes the final Friday and very few the following Saturday and Sunday. Staff feels that being able to say voting closes today when making the last calls may have a positive impact on getting last minute voters to cast a ballot. Please provide comments to arin-consult at arin.net. This notification and consultation period will close at 5 PM EDT, 20 May 2015. Please contact us at info at arin.net if you have any questions. Regards, Nate Davis Chief Operating Officer American Registry for Internet Numbers (ARIN) From owen at delong.com Mon Apr 20 16:28:04 2015 From: owen at delong.com (Owen DeLong) Date: Mon, 20 Apr 2015 13:28:04 -0700 Subject: [ARIN-consult] Community Consultation on Election-related Bylaws Changes In-Reply-To: <553554DC.8080805@arin.net> References: <553554DC.8080805@arin.net> Message-ID: <6C90F493-6CC3-4922-A31B-2E11914CA47B@delong.com> Some thoughts? So long as we are changing the timing for Voting Representative Eligibility, wouldn?t it make sense to bring that timeframe in line with the election notice period? Shouldn?t we, perhaps, extend the election notice requirement so that members have time to make sure their voting contact is in order prior to the cutoff? Perhaps 60 days notice and 45 days (as proposed) eligibility cutoff? I would still like to see us find a way that resource holders can vote, whether that means automatic membership with resources, opt-in membership with resources, or some other mechanism. Finally, such emails as the one below should either come from arin-consult at arin.net, or, set Reply-To header to arin-consult at arin.net in order to conveniently direct replies as requested. Thanks, Owen > On Apr 20, 2015, at 12:34 PM, ARIN wrote: > > On 13 April 2015, the ARIN Board of Trustees proposed changes to the > ARIN Bylaws. Per Article X. Section 6.b. of the Bylaws, these changes > require community notification and consultation before they can be > adopted. ARIN is opening this community consultation to obtain feedback > on the following Bylaws changes. > > 1. Article VIII. Section 4.a. Voting. > > Current bylaws language: > > Voting. Each General Member of record and in good standing on such date > that is sixty (60) days before a ballot or election shall be eligible to > vote (through its designated member representative voting contact) in > such ballot or election? > > Proposed bylaws language change: > > Voting. Each General Member of record and in good standing on such date > that is forty-five (45) days before a ballot or election shall be > eligible to vote (through its voting contact) in such ballot or election? > > Rationale: > a. Replacing the term ?designated member representative? with > ?voting contact? throughout the Bylaws and in election-related > documentation more clearly describes the function of this type of contact. > b. ARIN suggests shortening the time between elections and the > voter eligibility cutoff deadline in order to provide member > organizations more time to update their voting contact information. > > > 2. Article VIII. Section 4. b. Election Period. > > Current bylaws language: > > Election Period. The Election Period shall begin during the final Public > Policy and Members Meeting of the year for general elections and as > established by the President for other votes. The membership shall > receive electronic notice at least 30 days in advance of the election > and will have ten (10) calendar days after the Election Period opens to > electronically cast their votes, provided that any such electronic > transmission shall either set forth or be submitted with information > from which it can be determined that the electronic transmission was > authorized by the member. Votes received by ARIN after the close of the > Election Period shall not be counted. > > Change To: > > Election Period. The Election Period shall begin during the final Public > Policy and Members Meeting of the year for general elections and as > established by the President for other votes. The membership shall > receive electronic notice at least 30 days in advance of the election > and will have at least seven (7) calendar days after the Election Period > opens to electronically cast their votes, provided that any such > electronic transmission shall either set forth or be submitted with > information from which it can be determined that the electronic > transmission was authorized by the member. Votes received by ARIN after > the close of the Election Period shall not be counted. > > Rationale: > > Under the current meeting and election schedule the elections open on a > Thursday and close on a Sunday. The change to at least 7 business days > would mean election still open on Thursday, but could close the > following Friday. Each year we receive the majority of votes the final > Friday and very few the following Saturday and Sunday. Staff feels that > being able to say voting closes today when making the last calls may > have a positive impact on getting last minute voters to cast a ballot. > > > Please provide comments to arin-consult at arin.net. > > This notification and consultation period will close at 5 PM EDT, 20 May > 2015. Please contact us at info at arin.net if you have any questions. > > > Regards, > > > Nate Davis > Chief Operating Officer > American Registry for Internet Numbers (ARIN) > > > _______________________________________________ > 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. From Marla.Azinger at FTR.com Mon Apr 20 19:08:44 2015 From: Marla.Azinger at FTR.com (Azinger, Marla) Date: Mon, 20 Apr 2015 23:08:44 +0000 Subject: [ARIN-consult] [arin-announce] IRR Route Validation Consultation Extended to 24 Message-ID: 1. Should ARIN begin a new project to enable IRR route object validation to the ARIN registry database? Only if ARIN takes on the role to try and help reduce old stagnant data. Otherwise having just yet another place for this is added noise. Marla Azinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Tue Apr 21 13:07:28 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 21 Apr 2015 13:07:28 -0400 Subject: [ARIN-consult] IRR Improvement Message-ID: <2F916753-E434-4899-AB96-529678ECEDF8@puck.nether.net> improvement in the ARIN IRR would be beneficial to the community if well scoped Upgrading the database software and commit to maintaining a recent version of the IRR database server for those within the ARIN region to use. o this should require rather minimal work o move to common software similar to what other IRR operators use, e.g.: https://github.com/irrdnet/irrd o provide accurate examples (As of about 2 weeks ago some examples were wrong or did not work properly, i?m not sure if these were corrected) on the website for creating IRR objects and adequate support via e-mail and telephone as appropriate for in-region resource holders Additional work might be: o Provide a web based interface to creating IRR objects from allocations o Provide a restful interface for managing IRR objects o determining what RPSL-types are out of scope o tie object authentication along similar trust lines as other methods, such as RPKI - Jared PS: There are many people who don?t use or like IRR for whatever reason, I would heavily discount their input in the process as there are many who successfully have operationalized this in their business practices. The key in my mind is having the ARIN IRR function as well or better than the free alternatives which in my opinion sprung up in response to the ARIN IRR not meeting the member needs. From ndavis at arin.net Tue Apr 21 15:34:56 2015 From: ndavis at arin.net (Nate Davis) Date: Tue, 21 Apr 2015 19:34:56 +0000 Subject: [ARIN-consult] Community Consultation on Election-related Bylaws Changes In-Reply-To: <6C90F493-6CC3-4922-A31B-2E11914CA47B@delong.com> References: <553554DC.8080805@arin.net> <6C90F493-6CC3-4922-A31B-2E11914CA47B@delong.com> Message-ID: On 4/20/15, 4:28 PM, "Owen DeLong" wrote: >Some thoughts? > >So long as we are changing the timing for Voting Representative >Eligibility, wouldn?t it make sense to bring that timeframe in line with >the election notice period? Shouldn?t we, perhaps, extend the election >notice requirement so that members have time to make sure their voting >contact is in order prior to the cutoff? Perhaps 60 days notice and 45 >days (as proposed) eligibility cutoff? Owen, for clarity - Regarding the election notice requirement, we?re assuming you are referencing ARIN Bylaws Article VII Section 4B which states: ?The membership shall receive electronic notice at least 30 days in advance of the election and will have ten (10) calendar days after the Election Period opens to electronically cast their votes?? ARIN has always sent this notice in advance of the voter slate cutoff, reminding voters of the upcoming elections as well as soliciting any possible updates to their designated voter. In 2014, ARIN sent these notifications in July for the elections that opened in October. As the language above reads ?at least 30 days in advance?, there appears to be no conflict, as ARIN will always send such notification in advance of the voter eligibility cutoff date. Nate _______________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: default.xml Type: application/xml Size: 3222 bytes Desc: default.xml URL: From owen at delong.com Tue Apr 21 17:14:45 2015 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Apr 2015 14:14:45 -0700 Subject: [ARIN-consult] Community Consultation on Election-related Bylaws Changes In-Reply-To: References: <553554DC.8080805@arin.net> <6C90F493-6CC3-4922-A31B-2E11914CA47B@delong.com> Message-ID: I agree that the current language ALLOWS ARIN to deliver the notice prior to cutoff. I would prefer that the bylaws REQUIRE ARIN to deliver the notice prior to the eligibility cutoff. So while there is no conflict per se, I do believe there is room for improvement. Owen > On Apr 21, 2015, at 12:34, Nate Davis wrote: > >> On 4/20/15, 4:28 PM, "Owen DeLong" wrote: >> >> Some thoughts? >> >> So long as we are changing the timing for Voting Representative >> Eligibility, wouldn?t it make sense to bring that timeframe in line with >> the election notice period? Shouldn?t we, perhaps, extend the election >> notice requirement so that members have time to make sure their voting >> contact is in order prior to the cutoff? Perhaps 60 days notice and 45 >> days (as proposed) eligibility cutoff? > > Owen, for clarity - > > Regarding the election notice requirement, we?re assuming > you are referencing ARIN Bylaws Article VII Section 4B which states: > > ?The membership shall receive electronic notice at least 30 days in > advance of the election and will > have ten (10) calendar days after the Election Period opens to > electronically cast their votes?? > > > ARIN has always sent this notice in advance of the voter slate cutoff, > reminding voters of the upcoming elections as well as soliciting > any possible updates to their designated voter. In 2014, ARIN sent these > notifications in July for the elections that opened in October. > > > As the language above reads ?at least 30 days in advance?, there appears > to be no conflict, as ARIN will always send such notification in > advance of the voter eligibility cutoff date. > > > Nate > > _______________________________________________ > 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. > > From ndavis at arin.net Tue Apr 21 18:05:55 2015 From: ndavis at arin.net (Nate Davis) Date: Tue, 21 Apr 2015 22:05:55 +0000 Subject: [ARIN-consult] Community Consultation on Election-related Bylaws Changes In-Reply-To: References: <553554DC.8080805@arin.net> <6C90F493-6CC3-4922-A31B-2E11914CA47B@delong.com>

Message-ID: On 4/21/15, 5:14 PM, "Owen DeLong" wrote: >I agree that the current language ALLOWS ARIN to deliver the notice prior >to cutoff. I would prefer that the bylaws REQUIRE ARIN to deliver the >notice prior to the eligibility cutoff. > >So while there is no conflict per se, I do believe there is room for >improvement. > >Owen Acknowledged - thanks for the input and additional clarity. Nate > >>_________ >> 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. >> >> From info at arin.net Mon Apr 27 09:35:24 2015 From: info at arin.net (ARIN) Date: Mon, 27 Apr 2015 09:35:24 -0400 Subject: [ARIN-consult] Consultation Closed: IRR Route Validation Message-ID: <553E3B1C.4000301@arin.net> On 24 April 2015, ARIN concluded its community consultation on the topic of validation between an Internet Routing Registry (IRR) and the ARIN registry database: https://www.arin.net/participate/acsp/community_consult/03-17-2015_irr.html ARIN thanks those that provided feedback during the consultation. ARIN staff will review the feedback provided and report back to the community as soon as possible with next steps. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN)