From info at arin.net Tue Mar 17 13:30:50 2015 From: info at arin.net (ARIN) Date: Tue, 17 Mar 2015 13:30:50 -0400 Subject: [ARIN-consult] Community Consultation on IRR Route Validation Message-ID: <550864CA.6030807@arin.net> The following suggestions submitted via the ARIN Consultation and Suggestion Process (ACSP) are related to the topic of validation between an Internet Routing Registry (IRR) and the ARIN registry database. * 2015.3: Tie Route Objects in IRR to Netblocks of RIR Database * 2014.30: Reflect Returns in IRR Data * 2008.14: Construct Validated IRR Data These suggestions may be found at: https://www.arin.net/participate/acsp/index.html In addition to these open suggestions, ARIN has noted recent increased feedback from customers on this topic. This feedback includes direct communications with ARIN customers on the topic and open discussions by operator groups. ARIN is opening this community consultation to obtain feedback on the following questions: * Should ARIN begin a new project to enable IRR route object validation to the ARIN registry database? * 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. * If yes, should this effort be coordinated with other RIRs to help facilitate cross-registry authentication? * If yes, should this effort also support third party IRR route object authentication? Please provide comments to arin-consult at arin.net. This consultation will remain open through 5:00 PM EDT on Friday, 16 April 2015. For Background and Consideration: ARIN's current IRR offering is based on an old version of RIPE codebase supplemented by custom scripts written by ARIN to work with our systems. This older codebase is no longer supported by RIPE NCC, as they moved to a new codebase several years ago. The current ARIN IRR does not offer route object validation of any sort. If ARIN staff were to enable IRR route object validation against the ARIN registry database, it would likely require abandoning the current ARIN IRR and moving to a completely new codebase. Creating a new ARIN IRR with route object validation and solid synchronization with the ARIN registry database would require a significant resource effort by ARIN. It should be noted that an ARIN-only IRR project would not provide route object validation across RIR registry databases, and there appears to be a strong desire for cross-registry authentication. The idea of enabling third party IRR route object authentication has also been raised. This would allow non-RIR operated IRRs to conduct route object authentication with the RIR registry database If you have any questions, please contact us at info at arin.net. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) From job at ntt.net Tue Mar 17 14:16:40 2015 From: job at ntt.net (Job Snijders) Date: Tue, 17 Mar 2015 19:16:40 +0100 Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: <550864CA.6030807@arin.net> References: <550864CA.6030807@arin.net> Message-ID: <20150317181640.GB93039@Vurt.local> Dear ARIN & operators, On Tue, Mar 17, 2015 at 01:30:50PM -0400, ARIN wrote: > The following suggestions submitted via the ARIN Consultation and > Suggestion Process (ACSP) are related to the topic of validation between > an Internet Routing Registry (IRR) and the ARIN registry database. > > * 2015.3: Tie Route Objects in IRR to Netblocks of RIR Database > * 2014.30: Reflect Returns in IRR Data > * 2008.14: Construct Validated IRR Data > > * Should ARIN begin a new project to enable IRR route object > validation to the ARIN registry database? Yes! > * If yes, should this effort be coordinated with other RIRs to help > facilitate cross-registry authentication? Yes, without doubt. > * If yes, should this effort also support third party IRR route object > authentication? The moment ARIN's IRR would become the de-facto, reliable place to store IRR objects related to ARIN space, a registry like NTTCOM (currently second largest registry on the planet) could consider to offload authorisation/validation checks to ARIN instead of taking things at face-value. We have a lot to gain! Kind regards, Job From babydr at baby-dragons.com Tue Mar 17 14:28:55 2015 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Tue, 17 Mar 2015 10:28:55 -0800 (AKDT) Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: <20150317181640.GB93039@Vurt.local> References: <550864CA.6030807@arin.net> <20150317181640.GB93039@Vurt.local> Message-ID: Hello All , Not that my word means anything , Yes ... Tia , JimL On Tue, 17 Mar 2015, Job Snijders wrote: > Dear ARIN & operators, > > On Tue, Mar 17, 2015 at 01:30:50PM -0400, ARIN wrote: >> The following suggestions submitted via the ARIN Consultation and >> Suggestion Process (ACSP) are related to the topic of validation between >> an Internet Routing Registry (IRR) and the ARIN registry database. >> >> * 2015.3: Tie Route Objects in IRR to Netblocks of RIR Database >> * 2014.30: Reflect Returns in IRR Data >> * 2008.14: Construct Validated IRR Data >> >> * Should ARIN begin a new project to enable IRR route object >> validation to the ARIN registry database? > > Yes! > >> * If yes, should this effort be coordinated with other RIRs to help >> facilitate cross-registry authentication? > > Yes, without doubt. > >> * If yes, should this effort also support third party IRR route object >> authentication? > > The moment ARIN's IRR would become the de-facto, reliable place to store > IRR objects related to ARIN space, a registry like NTTCOM (currently > second largest registry on the planet) could consider to offload > authorisation/validation checks to ARIN instead of taking things at > face-value. > > We have a lot to gain! > > Kind regards, > > Job > _______________________________________________ > 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. > -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 3237 Holden Road | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | +------------------------------------------------------------------+ From David.Huberman at microsoft.com Wed Mar 18 08:59:56 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Wed, 18 Mar 2015 12:59:56 +0000 Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: <550864CA.6030807@arin.net> References: <550864CA.6030807@arin.net> Message-ID: 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. David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: arin-consult-bounces at arin.net [mailto:arin-consult- > bounces at arin.net] On Behalf Of ARIN > Sent: Tuesday, March 17, 2015 10:31 AM > To: arin-consult at arin.net > Subject: [ARIN-consult] Community Consultation on IRR Route Validation > > The following suggestions submitted via the ARIN Consultation and > Suggestion Process (ACSP) are related to the topic of validation between an > Internet Routing Registry (IRR) and the ARIN registry database. > > * 2015.3: Tie Route Objects in IRR to Netblocks of RIR Database > * 2014.30: Reflect Returns in IRR Data > * 2008.14: Construct Validated IRR Data > > These suggestions may be found at: > https://www.arin.net/participate/acsp/index.html > > In addition to these open suggestions, ARIN has noted recent increased > feedback from customers on this topic. This feedback includes direct > communications with ARIN customers on the topic and open discussions by > operator groups. > > ARIN is opening this community consultation to obtain feedback on the > following questions: > > * Should ARIN begin a new project to enable IRR route object validation to > the ARIN registry database? > * 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. > * If yes, should this effort be coordinated with other RIRs to help facilitate > cross-registry authentication? > * If yes, should this effort also support third party IRR route object > authentication? > > Please provide comments to arin-consult at arin.net. > > This consultation will remain open through 5:00 PM EDT on Friday, 16 April > 2015. > > For Background and Consideration: > > ARIN's current IRR offering is based on an old version of RIPE codebase > supplemented by custom scripts written by ARIN to work with our systems. > This older codebase is no longer supported by RIPE NCC, as they moved to a > new codebase several years ago. The current ARIN IRR does not offer route > object validation of any sort. > > If ARIN staff were to enable IRR route object validation against the ARIN > registry database, it would likely require abandoning the current ARIN IRR > and moving to a completely new codebase. Creating a new ARIN IRR with > route object validation and solid synchronization with the ARIN registry > database would require a significant resource effort by ARIN. > > It should be noted that an ARIN-only IRR project would not provide route > object validation across RIR registry databases, and there appears to be a > strong desire for cross-registry authentication. > > The idea of enabling third party IRR route object authentication has also been > raised. This would allow non-RIR operated IRRs to conduct route object > authentication with the RIR registry database If you have any questions, > please contact us at info at arin.net. > > Regards, > > John Curran > President and CEO > 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 jcurran at arin.net Wed Mar 18 09:07:44 2015 From: jcurran at arin.net (John Curran) Date: Wed, 18 Mar 2015 13:07:44 +0000 Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: References: <550864CA.6030807@arin.net> Message-ID: <2B7D92A9-FC42-428C-BFBF-8FD60BD44DA5@corp.arin.net> On 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. Agreed, but note that the consultation is specifically to determine if there is such interest in further development. > 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. The consultation is with regarding ARIN's IRR services, and does not relate to our RPKI efforts in any manner. If you have a viewpoint regarding whether ARIN should further develop IRR services per the consultation, please make it known. Thanks! /John John Curran President and CEO ARIN From David.Huberman at microsoft.com Wed Mar 18 09:15:37 2015 From: David.Huberman at microsoft.com (David Huberman) Date: Wed, 18 Mar 2015 13:15:37 +0000 Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: <2B7D92A9-FC42-428C-BFBF-8FD60BD44DA5@corp.arin.net> References: <550864CA.6030807@arin.net> <2B7D92A9-FC42-428C-BFBF-8FD60BD44DA5@corp.arin.net> Message-ID: My viewpoint is AS8075 will not use it. Like hundreds|thousands of others operators, we use RADB (a paid service with an SLA that works) for our IRR entries. My viewpoint is ARIN should not offer an IRR anymore, as there is too much garbage data in it, and the cost of re-development efforts strongly outweighs the benefits to the operational community. My viewpoint is the ARIN board should be tight-fisted with ARIN member money, and ensure that every development dollar that is spent has measurable benefit to ARIN's customers on a broad scale. My viewpoint is the RPKI money spent is a lesson that the board should keep at the forefront of this decision making process: millions (?) were spent, for little measurable benefit. David R Huberman Principal, Global IP Addressing Microsoft Corporation > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Sent: Wednesday, March 18, 2015 6:08 AM > To: David Huberman > Cc: arin-consult at arin.net > Subject: Re: [ARIN-consult] Community Consultation on IRR Route Validation > > On 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. > > Agreed, but note that the consultation is specifically to determine if there is > such interest in further development. > > > 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. > > The consultation is with regarding ARIN's IRR services, and does not relate to > our RPKI efforts in any manner. If you have a viewpoint regarding whether > ARIN should further develop IRR services per the consultation, please make > it known. > > Thanks! > /John > > John Curran > President and CEO > ARIN > From job at ntt.net Wed Mar 18 11:36:27 2015 From: job at ntt.net (Job Snijders) Date: Wed, 18 Mar 2015 16:36:27 +0100 Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: References: <550864CA.6030807@arin.net> <2B7D92A9-FC42-428C-BFBF-8FD60BD44DA5@corp.arin.net> Message-ID: <20150318153627.GA29531@Hanna.local> Hi David, On Wed, Mar 18, 2015 at 01:15:37PM +0000, David Huberman wrote: > My viewpoint is AS8075 will not use it. Like hundreds|thousands of > others operators, we use RADB (a paid service with an SLA that works) > for our IRR entries. Which part works? You realise that anybody can register anything for any prefix in RADB right? ARIN now has a chance to step their game up and make it possible to offer better quality data. Why should anybody else then Microsoft, be allowed to create route-objects that cover Microsoft space? > My viewpoint is ARIN should not offer an IRR anymore, as there is too > much garbage data in it, and the cost of re-development efforts > strongly outweighs the benefits to the operational community. This is one example how RADB can be abused: http://www.bgpmon.net/using-bgp-data-to-find-spammers/ Tying together RIR & IRR data allows operators to programmatically assess which parts of IRR we subsume into route-filters, and which parts we ignore because there is zero guarantee that the information is authorised. Third party IRRs like RADB (or NTTCOM) cannot verify who is authorised to create route-objects or not. Regarding cost: ARIN could be the fourth RIR to do RIR<>IRR coupling, after, other RIRs who offer this today: Afrinic, APNIC & RIPE. This is not a new concept and code already exists. An undertaking like this of course has a pricetag, however I'd be hesitant to claim that the cost will outweight the benefits. Kind regards, Job From SRyan at mwe.com Wed Mar 18 11:41:52 2015 From: SRyan at mwe.com (Ryan, Stephen) Date: Wed, 18 Mar 2015 15:41:52 +0000 Subject: [ARIN-consult] Community Consultation on IRR Route Validation. attorney client communication. Message-ID: Counsel's Note: Participants in this discussion are respectfully requested and directed to confine the discussion to 'policy' issues. The reference to individual plans of a company, i.e. MS here, are unwelcome unless absolutely necessary, something I cannot yet judge. Please exercise caution and refrain from references to the business plans of individual companies. Steve Ryan Stephen M. Ryan Partner McDermott Will & Emery LLP The McDermott Building | 500 North Capitol Street, N.W. | Washington, DC 20001 Tel +1 202 756 8333 Mobile +1 202 251 5343 Fax +1 202 756 8087 http://www.mwe.com -----Original Message----- From: arin-consult-bounces at arin.net [mailto:arin-consult-bounces at arin.net] On Behalf Of Job Snijders Sent: Wednesday, March 18, 2015 11:36 AM To: David Huberman Cc: arin-consult at arin.net Subject: Re: [ARIN-consult] Community Consultation on IRR Route Validation Hi David, On Wed, Mar 18, 2015 at 01:15:37PM +0000, David Huberman wrote: > My viewpoint is AS8075 will not use it. Like hundreds|thousands of > others operators, we use RADB (a paid service with an SLA that works) > for our IRR entries. Which part works? You realise that anybody can register anything for any prefix in RADB right? ARIN now has a chance to step their game up and make it possible to offer better quality data. Why should anybody else then Microsoft, be allowed to create route-objects that cover Microsoft space? > My viewpoint is ARIN should not offer an IRR anymore, as there is too > much garbage data in it, and the cost of re-development efforts > strongly outweighs the benefits to the operational community. This is one example how RADB can be abused: http://www.bgpmon.net/using-bgp-data-to-find-spammers/ Tying together RIR & IRR data allows operators to programmatically assess which parts of IRR we subsume into route-filters, and which parts we ignore because there is zero guarantee that the information is authorised. Third party IRRs like RADB (or NTTCOM) cannot verify who is authorised to create route-objects or not. Regarding cost: ARIN could be the fourth RIR to do RIR<>IRR coupling, after, other RIRs who offer this today: Afrinic, APNIC & RIPE. This is not a new concept and code already exists. An undertaking like this of course has a pricetag, however I'd be hesitant to claim that the cost will outweight the benefits. Kind regards, Job _______________________________________________ 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. ******************************************************************************************************************* This message is a PRIVILEGED AND CONFIDENTIAL communication. This message and all attachments are a private communication sent by a law firm and may be confidential or protected by privilege. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the information contained in or attached to this message is strictly prohibited. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you. ******************************************************************************************************************* Please visit http://www.mwe.com/ for more information about our Firm. From owen at delong.com Wed Mar 18 16:44:23 2015 From: owen at delong.com (Owen DeLong) Date: Wed, 18 Mar 2015 13:44:23 -0700 Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: <2B7D92A9-FC42-428C-BFBF-8FD60BD44DA5@corp.arin.net> References: <550864CA.6030807@arin.net> <2B7D92A9-FC42-428C-BFBF-8FD60BD44DA5@corp.arin.net> Message-ID: <6E12D4E3-5B37-422D-82EE-CDB93B3EAB33@delong.com> > On Mar 18, 2015, at 06:07 , John Curran wrote: > > On 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. > > Agreed, but note that the consultation is specifically to determine if there > is such interest in further development. > >> 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. > > The consultation is with regarding ARIN's IRR services, and does not relate to > our RPKI efforts in any manner. If you have a viewpoint regarding whether ARIN > should further develop IRR services per the consultation, please make it known. It doesn?t relate as a service, but it directly relates as an example of something lots of people said they wanted, followed by hardly anyone actually using it once it was deployed. Owen From jcurran at arin.net Wed Mar 18 18:13:42 2015 From: jcurran at arin.net (John Curran) Date: Wed, 18 Mar 2015 22:13:42 +0000 Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: <6E12D4E3-5B37-422D-82EE-CDB93B3EAB33@delong.com> References: <550864CA.6030807@arin.net> <2B7D92A9-FC42-428C-BFBF-8FD60BD44DA5@corp.arin.net> <6E12D4E3-5B37-422D-82EE-CDB93B3EAB33@delong.com> Message-ID: <225E9F13-9F23-497E-8DE1-91EB2012D0FF@arin.net> On Mar 18, 2015, at 4:44 PM, Owen DeLong wrote: >> On Mar 18, 2015, at 06:07 , John Curran wrote: >> ... >> The consultation is with regarding ARIN's IRR services, and does not relate to >> our RPKI efforts in any manner. If you have a viewpoint regarding whether ARIN >> should further develop IRR services per the consultation, please make it known. > > It doesn?t relate as a service, but it directly relates as an example of something lots of people said they wanted, followed by hardly anyone actually using it once it was deployed. Owen - It's still far too early to tell, given that RPKI is an infrastructure service (i.e. "hardly anyone actually using it once it was deployed" was equally applicable to both DNSSEC and IPv6 for their first 10 years...) /John John Curran President and CEO ARIN From Tony_Tauber at cable.comcast.com Thu Mar 19 10:16:54 2015 From: Tony_Tauber at cable.comcast.com (Tauber, Tony) Date: Thu, 19 Mar 2015 14:16:54 +0000 Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: <20150317181640.GB93039@Vurt.local> References: <550864CA.6030807@arin.net> <20150317181640.GB93039@Vurt.local> Message-ID: On 3/17/15, 2:16 PM, "Job Snijders" wrote: >Dear ARIN & operators, > >On Tue, Mar 17, 2015 at 01:30:50PM -0400, ARIN wrote: >> The following suggestions submitted via the ARIN Consultation and >> Suggestion Process (ACSP) are related to the topic of validation between >> an Internet Routing Registry (IRR) and the ARIN registry database. >> >> * 2015.3: Tie Route Objects in IRR to Netblocks of RIR Database >> * 2014.30: Reflect Returns in IRR Data >> * 2008.14: Construct Validated IRR Data >> >> * Should ARIN begin a new project to enable IRR route object >> validation to the ARIN registry database? > >Yes! > >> * If yes, should this effort be coordinated with other RIRs to help >> facilitate cross-registry authentication? > >Yes, without doubt. > >> * If yes, should this effort also support third party IRR route object >> authentication? I agree and vote ?yes? to all three also but would like to confirm what standard(s) would used to do these things. Thanks, Tony From jcurran at arin.net Thu Mar 19 10:34:46 2015 From: jcurran at arin.net (John Curran) Date: Thu, 19 Mar 2015 14:34:46 +0000 Subject: [ARIN-consult] Community Consultation on IRR Route Validation. attorney client communication. In-Reply-To: References: Message-ID: <6ABC1C4F-5F28-4F6B-AC9E-66D8FA92FE1C@corp.arin.net> ARIN-Consult Community - For clarity, ARIN's General Counsel Steve Ryan was responding to the question "Why should anybody else then Microsoft, be allowed to create route-objects that cover Microsoft space?" that was being asked, as it seemed to be soliciting some detailed information about Microsoft's business & services. Folks are free to provide information about whether their company would find specific ARIN services useful or not, but refrain from questioning each other (even incidentally) about your business plans and service details, as in some contexts questions those are sort of question that can raise anti-trust issues. In this particular case, Job was just pointing out the rather wide-open nature of the present IRR service and anyone's ability to add objects, not really asking Microsoft specifics of its plans... It's good to see the our General Counsel in action, and his diligence in picking up on a remark that without clear context could be the sort that raises concern. Please continue to discuss merits and issues with the present IRR services and possible future direction - it has been most informative. :-) Thanks! /John John Curran President and CEO ARIN > On Mar 18, 2015, at 11:41 AM, Ryan, Stephen wrote: > > Counsel's Note: > > Participants in this discussion are respectfully requested and directed to confine the discussion to 'policy' issues. The reference to individual plans of a company, i.e. MS here, are unwelcome unless absolutely necessary, something I cannot yet judge. Please exercise caution and refrain from references to the business plans of individual companies. > > Steve Ryan > > Stephen M. Ryan > Partner > McDermott Will & Emery LLP > The McDermott Building | 500 North Capitol Street, N.W. | Washington, DC 20001 > Tel +1 202 756 8333 > Mobile +1 202 251 5343 > Fax +1 202 756 8087 > http://www.mwe.com > > > > -----Original Message----- > From: arin-consult-bounces at arin.net [mailto:arin-consult-bounces at arin.net] On Behalf Of Job Snijders > Sent: Wednesday, March 18, 2015 11:36 AM > To: David Huberman > Cc: arin-consult at arin.net > Subject: Re: [ARIN-consult] Community Consultation on IRR Route Validation > > Hi David, > > On Wed, Mar 18, 2015 at 01:15:37PM +0000, David Huberman wrote: >> My viewpoint is AS8075 will not use it. Like hundreds|thousands of >> others operators, we use RADB (a paid service with an SLA that works) >> for our IRR entries. > > Which part works? You realise that anybody can register anything for any prefix in RADB right? ARIN now has a chance to step their game up and make it possible to offer better quality data. > > Why should anybody else then Microsoft, be allowed to create route-objects that cover Microsoft space? > >> My viewpoint is ARIN should not offer an IRR anymore, as there is too >> much garbage data in it, and the cost of re-development efforts >> strongly outweighs the benefits to the operational community. > > This is one example how RADB can be abused: > http://www.bgpmon.net/using-bgp-data-to-find-spammers/ > > Tying together RIR & IRR data allows operators to programmatically assess which parts of IRR we subsume into route-filters, and which parts we ignore because there is zero guarantee that the information is authorised. > > Third party IRRs like RADB (or NTTCOM) cannot verify who is authorised to create route-objects or not. > > Regarding cost: ARIN could be the fourth RIR to do RIR<>IRR coupling, after, other RIRs who offer this today: Afrinic, APNIC & RIPE. This is not a new concept and code already exists. An undertaking like this of course has a pricetag, however I'd be hesitant to claim that the cost will outweight the benefits. > > Kind regards, > > Job > _______________________________________________ > 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. > > > ******************************************************************************************************************* > This message is a PRIVILEGED AND CONFIDENTIAL communication. This message and all attachments are a private communication sent by a law firm and may be confidential or protected by privilege. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the information contained in or attached to this message is strictly prohibited. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you. > ******************************************************************************************************************* > > Please visit http://www.mwe.com/ for more information about our Firm. > _______________________________________________ > 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 gert at space.net Sun Mar 22 08:31:19 2015 From: gert at space.net (Gert Doering) Date: Sun, 22 Mar 2015 13:31:19 +0100 Subject: [ARIN-consult] Community Consultation on IRR Route Validation In-Reply-To: <550864CA.6030807@arin.net> References: <550864CA.6030807@arin.net> Message-ID: <20150322123119.GK54385@Space.Net> Hello ARIN, On Tue, Mar 17, 2015 at 01:30:50PM -0400, ARIN wrote: > The following suggestions submitted via the ARIN Consultation and > Suggestion Process (ACSP) are related to the topic of validation between > an Internet Routing Registry (IRR) and the ARIN registry database. > > * 2015.3: Tie Route Objects in IRR to Netblocks of RIR Database [..] > ARIN is opening this community consultation to obtain feedback on the > following questions: > > * Should ARIN begin a new project to enable IRR route object validation > to the ARIN registry database? Yes, please. Some of you might know that I'm not from the ARIN region, but I think that this is an important necessity for the Global Internet to be sustainable in the future, so I'm speaking up here. We see an increased number of cases where Spammers find network blocks that are not actively used (for whatever reason), register "route"-Objeckts for them in a database that does not protect against unauthorized creation of objects (like, in our most recent case, the RA DB), and then announce this address space as "theirs". The fake route: objects will circumvent BGP prefix filters if built from an IRR DB that does not properly check authorization for route object creation, thus enabling the spammer to have wide reach with their announcement. (In case one wants to check: 185.54.188.0/22 is one of our prefixes that was abused that way - announced for just under one hour, but sufficiently long to send enough spam so the complaints hit our abuse desk and made me investigate. The bogus entry is still in RA DB, as they do not consider it their duty to remove it. *sigh*) Cross-Registry authorization will still remain a not easily solved problem, but at least every region should have a IRR DB that has strongly authorized data in it concerning their own members' resources - and the RIR in question is the only entity that can state with certainity whether or not a resource holder is authorized to put in routing information for a given network, or not. [..] > * If yes, should this effort be coordinated with other RIRs to help > facilitate cross-registry authentication? > * If yes, should this effort also support third party IRR route object > authentication? Yes, and yes. And I understand that this is much harder, but is also of crucial importance if we want to give users of the database(s) a chance to build proper prefix filters for customers that happen to be authorized to announce networks coming from different regions. Which happens often enough to be relevant :-) 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 danny at tcb.net Mon Mar 23 16:52:45 2015 From: danny at tcb.net (Danny McPherson) Date: Mon, 23 Mar 2015 14:52:45 -0600 Subject: [ARIN-consult] Community Consultation on IRR Route Validation Message-ID: <8b1eff72b81e092a99adb8891a5b856e@tcb.net> I agree with Job and Gert on this. As a member (VRSN) I'd like to see ARIN undertake this work as it's much more incremental and my company would like to see ARIN invest in fortifying and leveraging incumbent infrastructure and tools as opposed to longer term research projects. Re: Job's comment: "Third party IRRs like RADB (or NTTCOM) cannot verify who is authorised to create route objects or not." and Gert's comment: "Cross-Registry authorization will still remain a not easily solved problem, but at least every region should have a IRR DB that has strongly authorized data in it concerning their own members' resources - and the RIR in question is the only entity that can state with certainity whether or not a resource holder is authorized to put in routing information for a given network, or not." I completely agree. They either need to be able to validate it, or resource holders need to have a mechanism to specify where their resources are located -- then if data is stale or old cruft folks can ignore it. Some other IRR issues are captured here: https://tools.ietf.org/html/draft-ietf-grow-irr-routing-policy-considerations-05 Thanks for the consideration of this, I think it's important! -danny From marty at akamai.com Tue Mar 31 16:28:08 2015 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 31 Mar 2015 20:28:08 +0000 Subject: [ARIN-consult] Community Consultation on IRR Route Validation. attorney client communication. In-Reply-To: <6ABC1C4F-5F28-4F6B-AC9E-66D8FA92FE1C@corp.arin.net> References: <6ABC1C4F-5F28-4F6B-AC9E-66D8FA92FE1C@corp.arin.net> Message-ID: <4A3617FF-B259-4A38-85AB-248B2A0F4F13@akamai.com> AS 32787 and AS 20940 will continue to use and expand use of RADB for the foreseeable future. Best, -M< > On Mar 19, 2015, at 10:34 AM, John Curran wrote: > > ARIN-Consult Community - > > For clarity, ARIN's General Counsel Steve Ryan was responding to the question > "Why should anybody else then Microsoft, be allowed to create route-objects > that cover Microsoft space?" that was being asked, as it seemed to be > soliciting some detailed information about Microsoft's business & services. > > Folks are free to provide information about whether their company would > find specific ARIN services useful or not, but refrain from questioning > each other (even incidentally) about your business plans and service > details, as in some contexts questions those are sort of question that > can raise anti-trust issues. > > In this particular case, Job was just pointing out the rather wide-open > nature of the present IRR service and anyone's ability to add objects, > not really asking Microsoft specifics of its plans... It's good to see > the our General Counsel in action, and his diligence in picking up on a > remark that without clear context could be the sort that raises concern. > > Please continue to discuss merits and issues with the present IRR services > and possible future direction - it has been most informative. :-) > > Thanks! > /John > > John Curran > President and CEO > ARIN > >> On Mar 18, 2015, at 11:41 AM, Ryan, Stephen wrote: >> >> Counsel's Note: >> >> Participants in this discussion are respectfully requested and directed to confine the discussion to 'policy' issues. The reference to individual plans of a company, i.e. MS here, are unwelcome unless absolutely necessary, something I cannot yet judge. Please exercise caution and refrain from references to the business plans of individual companies. >> >> Steve Ryan >> >> Stephen M. Ryan >> Partner >> McDermott Will & Emery LLP >> The McDermott Building | 500 North Capitol Street, N.W. | Washington, DC 20001 >> Tel +1 202 756 8333 >> Mobile +1 202 251 5343 >> Fax +1 202 756 8087 >> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mwe.com&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=XDN_BIPGnpb6V0w5M9FADw&m=XtXSprAaWeMBEhujNfH3sjTUY70nIP1Bpm0voLpIkh4&s=65_kFgl8PQRTwzqxS6mvlIZAFb47tn9yMTel2cesJ6k&e= >> >> >> >> -----Original Message----- >> From: arin-consult-bounces at arin.net [mailto:arin-consult-bounces at arin.net] On Behalf Of Job Snijders >> Sent: Wednesday, March 18, 2015 11:36 AM >> To: David Huberman >> Cc: arin-consult at arin.net >> Subject: Re: [ARIN-consult] Community Consultation on IRR Route Validation >> >> Hi David, >> >> On Wed, Mar 18, 2015 at 01:15:37PM +0000, David Huberman wrote: >>> My viewpoint is AS8075 will not use it. Like hundreds|thousands of >>> others operators, we use RADB (a paid service with an SLA that works) >>> for our IRR entries. >> >> Which part works? You realise that anybody can register anything for any prefix in RADB right? ARIN now has a chance to step their game up and make it possible to offer better quality data. >> >> Why should anybody else then Microsoft, be allowed to create route-objects that cover Microsoft space? >> >>> My viewpoint is ARIN should not offer an IRR anymore, as there is too >>> much garbage data in it, and the cost of re-development efforts >>> strongly outweighs the benefits to the operational community. >> >> This is one example how RADB can be abused: >> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bgpmon.net_using-2Dbgp-2Ddata-2Dto-2Dfind-2Dspammers_&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=XDN_BIPGnpb6V0w5M9FADw&m=XtXSprAaWeMBEhujNfH3sjTUY70nIP1Bpm0voLpIkh4&s=WJXYf7V-2XT2iOEIjVCeGkFHjR7ZZPx29s6LqWo3A9k&e= >> >> Tying together RIR & IRR data allows operators to programmatically assess which parts of IRR we subsume into route-filters, and which parts we ignore because there is zero guarantee that the information is authorised. >> >> Third party IRRs like RADB (or NTTCOM) cannot verify who is authorised to create route-objects or not. >> >> Regarding cost: ARIN could be the fourth RIR to do RIR<>IRR coupling, after, other RIRs who offer this today: Afrinic, APNIC & RIPE. This is not a new concept and code already exists. An undertaking like this of course has a pricetag, however I'd be hesitant to claim that the cost will outweight the benefits. >> >> Kind regards, >> >> Job >> _______________________________________________ >> 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: >> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.arin.net_mailman_listinfo_arin-2Dconsult&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=XDN_BIPGnpb6V0w5M9FADw&m=XtXSprAaWeMBEhujNfH3sjTUY70nIP1Bpm0voLpIkh4&s=HwBrKxmAOwfYI0FvzHOEq8NI1M27uDXuFo3HQuUcOcQ&e= Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. >> >> >> ******************************************************************************************************************* >> This message is a PRIVILEGED AND CONFIDENTIAL communication. This message and all attachments are a private communication sent by a law firm and may be confidential or protected by privilege. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the information contained in or attached to this message is strictly prohibited. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you. >> ******************************************************************************************************************* >> >> Please visit https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mwe.com_&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=XDN_BIPGnpb6V0w5M9FADw&m=XtXSprAaWeMBEhujNfH3sjTUY70nIP1Bpm0voLpIkh4&s=hr2XSHqcyif3jdF1zxyEF7CXcKrX6YrkD7J5MZwTxHo&e= for more information about our Firm. >> _______________________________________________ >> 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: >> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.arin.net_mailman_listinfo_arin-2Dconsult&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=XDN_BIPGnpb6V0w5M9FADw&m=XtXSprAaWeMBEhujNfH3sjTUY70nIP1Bpm0voLpIkh4&s=HwBrKxmAOwfYI0FvzHOEq8NI1M27uDXuFo3HQuUcOcQ&e= Please contact the ARIN Member Services >> Help Desk at info at arin.net if you experience any issues. > > _______________________________________________ > 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: > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.arin.net_mailman_listinfo_arin-2Dconsult&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=XDN_BIPGnpb6V0w5M9FADw&m=XtXSprAaWeMBEhujNfH3sjTUY70nIP1Bpm0voLpIkh4&s=HwBrKxmAOwfYI0FvzHOEq8NI1M27uDXuFo3HQuUcOcQ&e= Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. From gert at space.net Tue Mar 31 16:52:48 2015 From: gert at space.net (Gert Doering) Date: Tue, 31 Mar 2015 22:52:48 +0200 Subject: [ARIN-consult] Community Consultation on IRR Route Validation. attorney client communication. In-Reply-To: <4A3617FF-B259-4A38-85AB-248B2A0F4F13@akamai.com> References: <6ABC1C4F-5F28-4F6B-AC9E-66D8FA92FE1C@corp.arin.net> <4A3617FF-B259-4A38-85AB-248B2A0F4F13@akamai.com> Message-ID: <20150331205248.GM54385@Space.Net> Hi, 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? 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? I point to our own hijacked route entry again - 185.54.188.0/22, registered and maintained by "MAINT-AS197329", very obviously not legitimate (since a RADB query also shows the RIPE DB object where this address space belongs to!). The RADB maintainers do not think there is a problem and they should maybe remove it (but expect me to go chase whoever put it in). Building routing filters from a data source this quality might give people a warm and fuzzy feeling, but someone who wants to announce other people's address space will not be hindered the least by that. 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 jcurran at arin.net Tue Mar 31 17:09:22 2015 From: jcurran at arin.net (John Curran) Date: Tue, 31 Mar 2015 21:09:22 +0000 Subject: [ARIN-consult] Community Consultation on IRR Route Validation. attorney client communication. In-Reply-To: <20150331205248.GM54385@Space.Net> References: <6ABC1C4F-5F28-4F6B-AC9E-66D8FA92FE1C@corp.arin.net> <4A3617FF-B259-4A38-85AB-248B2A0F4F13@akamai.com> <20150331205248.GM54385@Space.Net> Message-ID: 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) Thoughts? /John John Curran President and CEO ARIN From marty at akamai.com Tue Mar 31 17:47:55 2015 From: marty at akamai.com (Hannigan, Martin) Date: Tue, 31 Mar 2015 21:47:55 +0000 Subject: [ARIN-consult] Community Consultation on IRR Route Validation. attorney client communication. In-Reply-To: <20150331205248.GM54385@Space.Net> References: <6ABC1C4F-5F28-4F6B-AC9E-66D8FA92FE1C@corp.arin.net> <4A3617FF-B259-4A38-85AB-248B2A0F4F13@akamai.com> <20150331205248.GM54385@Space.Net> Message-ID: <3DB4C0B6-8621-441C-906F-B6B2F8FE3829@akamai.com> > On Mar 31, 2015, at 4:52 PM, Gert Doering wrote: > > Hi, > > 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? > > 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? Best, -M< From Tony_Tauber at cable.comcast.com Tue Mar 31 23:20:41 2015 From: Tony_Tauber at cable.comcast.com (Tauber, Tony) Date: Wed, 1 Apr 2015 03:20:41 +0000 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: On 3/31/15, 5:47 PM, "Hannigan, Martin" > wrote: On Mar 31, 2015, at 4:52 PM, Gert Doering > wrote: Hi, 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? A couple of weeks ago I posted in this thread: http://lists.arin.net/pipermail/arin-consult/2015-March/000597.html to ask which Standards would be used to achieve what was in the original proposal: https://www.arin.net/participate/acsp/suggestions/2015-3.html * 2015.3: Tie Route Objects in IRR to Netblocks of RIR Database One way to do this might be RPSL authorization such as described in RFC2725. I believe something like that is what RIPE does, but haven?t had any response to my particular query. It is something that can happen where the address assignment is aligned with the RR (which ARIN didn?t do with their existing RR). I don?t see a way for RADB or operator-based RRs to do it, but I may lack imagination. Tony 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? Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: