Send ARIN-consult mailing list submissions to
        arin-consult@arin.net

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.arin.net/mailman/listinfo/arin-consult
or, via email, send a message with subject or body 'help' to
        arin-consult-requ...@arin.net

You can reach the person managing the list at
        arin-consult-ow...@arin.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-consult digest..."


Today's Topics:

   1. Re: Consultation on ARIN IRR Roadmap (Jay Borkenhagen)
   2. Re: Consultation on ARIN IRR Roadmap (John Curran)
   3. Re: Consultation on ARIN IRR Roadmap (Jay Borkenhagen)
   4. Re: Consultation on ARIN IRR Roadmap (Jason Schiller)


----------------------------------------------------------------------

Message: 1
Date: Fri, 23 Feb 2018 13:09:21 -0500
From: Jay Borkenhagen <j...@braeburn.org>
To: arin-consult@arin.net
Subject: Re: [ARIN-consult] Consultation on ARIN IRR Roadmap
Message-ID: <23184.22737.368242.869...@oz.mt.att.com>
Content-Type: text/plain; charset=us-ascii

David Farmer writes:
 > On Tuesday at NANOG there was a presentation on ARIN's IRR Roadmap.
 > 
 > https://youtu.be/tsWq_LgNS5s
 > 

Thanks for posting that link, David.


I have a couple questions for John and/or others from ARIN:

At around 16:30 in the youtube video, John made a statement along the
lines that information published in the rpki would "pre-empt
everything".  Those words could be interpreted in some very different
ways, so I'd like John/ARIN to clarify what he meant.

For example, John may have meant that the ARIN Online registry + RPKI
+ IRR system of the future system would enforce a rule whereby the
presence of ROAs placing the origin of a block of IPs in one or more
ASNs would make it impossible to register any route objects that
contradict the ROAs.  If so, I think that would be great.

On the other hand, some might interpret John to mean that by
publishing ROAs a resource holder could magically inform the world
that the IRR route objects for that space are no longer authoritative
causing them to no longer be used.  That's clearly not the case.


Also, at about 19:25, John mentioned that ARIN is enhancing its rpki
tools.  Where can a description of those enhancements be found?


Thank you.

                                                Jay B.





------------------------------

Message: 2
Date: Fri, 23 Feb 2018 18:27:24 +0000
From: John Curran <jcur...@arin.net>
To: Jay Borkenhagen <j...@braeburn.org>
Cc: "arin-consult@arin.net" <arin-consult@arin.net>
Subject: Re: [ARIN-consult] Consultation on ARIN IRR Roadmap
Message-ID: <7fbd50bb-96b9-4ea1-ab64-9cd245217...@arin.net>
Content-Type: text/plain; charset="us-ascii"

On 23 Feb 2018, at 1:09 PM, Jay Borkenhagen <j...@braeburn.org> wrote:
> 
> David Farmer writes:
>> On Tuesday at NANOG there was a presentation on ARIN's IRR Roadmap.
>> 
>> https://youtu.be/tsWq_LgNS5s
>> 
> 
> Thanks for posting that link, David.
> 
> I have a couple questions for John and/or others from ARIN:
> 
> At around 16:30 in the youtube video, John made a statement along the
> lines that information published in the rpki would "pre-empt
> everything".  Those words could be interpreted in some very different
> ways, so I'd like John/ARIN to clarify what he meant.
> 
> For example, John may have meant that the ARIN Online registry + RPKI
> + IRR system of the future system would enforce a rule whereby the
> presence of ROAs placing the origin of a block of IPs in one or more
> ASNs would make it impossible to register any route objects that
> contradict the ROAs.  If so, I think that would be great.

That was not the intent of my statement, but that can certainly be done if the 
community wishes that level of integration. 

> On the other hand, some might interpret John to mean that by
> publishing ROAs a resource holder could magically inform the world
> that the IRR route objects for that space are no longer authoritative
> causing them to no longer be used.  That's clearly not the case.

What I intended by the remark is simply that parties which rely upon RPKI will 
often more heavily weight local-preference based on the RPKI validation result. 
 This is not assured but is indeed probable. 

> Also, at about 19:25, John mentioned that ARIN is enhancing its rpki
> tools.  Where can a description of those enhancements be found?

We are continuing to enhance our RPKI tools, but no new functionality is being 
announced at this time.   If there is specific functionality that you seek, 
please submit a suggestion so that it can be prioritized.

Thanks!
/John

John Curran
President and CEO
ARIN




------------------------------

Message: 3
Date: Fri, 23 Feb 2018 15:36:46 -0500
From: Jay Borkenhagen <j...@braeburn.org>
To: <arin-consult@arin.net>
Subject: Re: [ARIN-consult] Consultation on ARIN IRR Roadmap
Message-ID: <23184.31582.759219.618...@oz.mt.att.com>
Content-Type: text/plain; charset=us-ascii

John Curran writes:
 > > For example, John may have meant that the ARIN Online registry + RPKI
 > > + IRR system of the future system would enforce a rule whereby the
 > > presence of ROAs placing the origin of a block of IPs in one or more
 > > ASNs would make it impossible to register any route objects that
 > > contradict the ROAs.  If so, I think that would be great.
 > 
 > That was not the intent of my statement, but that can certainly be done if 
 > the community wishes that level of integration. 

Thank you.  Please consider the suggestion recorded.  Other folk are
invited to comment.

 > What I intended by the remark is simply that parties which rely upon RPKI 
 > will often more heavily weight local-preference based on the RPKI validation 
 > result.  This is not assured but is indeed probable. 
 > 

It's about weighting only in a limited and temporary sense.  Breaking
it down:

Once a CIDR block is covered by a valid ROA (a "VRP" per
https://tools.ietf.org/html/rfc6811), that CIDR route and all its
more-specific routes can be either valid or invalid only -- no longer
can they be 'not found'.  Thus it does nothing to change local-pref of
'not found' routes relative to valid and invalid ones.

When a service provider first begins using validation state in their
routing policies, yes, they probably will give valid routes a higher
local-pref than the invalid ones.  But until they begin outright
blocking invalid routes, they will not be addressing the YouTube /
Pakistan Telecom case of more-specific hijacks.  So this phase should
be only temporary.

Networks that use validation state in their policies obviously need
valid ROAs to exist.  Networks that do not use validation state in
their routers directly can potentially still augment their current
IRR-based tools so they utilize RPKI information when generating
prefix list route filters, but I bet most will not do so.  For those
networks that do not, there is no pre-empting of IRR by RPKI.  (Other
than through the integration suggestion above.)


 > We are continuing to enhance our RPKI tools, but no new functionality is 
 > being announced at this time.   If there is specific functionality that you 
 > seek, please submit a suggestion so that it can be prioritized.
 > 

Thank you, I will.  Please announce ARIN's rpki enhancement plans
prior to beginning development.

                                                Jay B.




------------------------------

Message: 4
Date: Fri, 23 Feb 2018 15:46:46 -0500
From: Jason Schiller <jschil...@google.com>
To: Job Snijders <j...@ntt.net>
Cc: David Farmer <far...@umn.edu>, "<arin-consult@arin.net>"
        <arin-consult@arin.net>
Subject: Re: [ARIN-consult] Consultation on ARIN IRR Roadmap
Message-ID:
        <cac4yj2wqev251wfdkgxwevgkv7oawwgvjgkh21mk3wt+1vv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Job,

thank you for the clarification on source=ARIN, vs ARIN-OLD.

makes sense now.

I also agree we should stay away from unsing "Legacy"
unless we are trying to specificly note the resource is
"ARIN Legacy space" (meaning it is not currently under
any ARIN RSA, and therefor the provenance is not clear
to ARIN).

I like alignment.. so ARIN-NONAUTH seems like a good choice.



___Jason


On Fri, Feb 23, 2018 at 11:18 AM, Job Snijders <j...@ntt.net> wrote:

> On Thu, Feb 22, 2018 at 04:42:02PM -0600, David Farmer wrote:
> > On Thu, Feb 22, 2018 at 3:19 PM, Job Snijders <j...@ntt.net> wrote:
> >
> > > On Thu, Feb 22, 2018 at 04:06:28PM -0500, Jason Schiller wrote:
> > > > I am confused...
> > > >
> > > > the current ARIN IRR is rr.arin.net
> > >
> > > ARIN manages an IRR database called "ARIN" in a daemon running on host
> > > rr.arin.net. You can publish data from multiple databases via a single
> > > fqdn like 'rr.arin.net'. I think what David Farmer is talking about is
> > > the "source: ARIN" aspect of the data you show:
> > >
> > >     $ whois -h rr.arin.net 199.43.0.0/24 | grep source
> > >     source:         ARIN # Filtered
> > >
> > > RIPE is developing something similar, where non-authoritative data will
> > > be marked with "source: RIPE-NONAUTH" rather than "source: RIPE" to
> show
> > > which objects came into existance because of the chain of trust from
> the
> > > RIR data to the IRR data, and some didn't.
> > >
> > > With an example from the ARIN IRR:
> > >
> > >     job@vurt ~$ whois -h rr.arin.net -- "-B 192.0.2.0/24" | egrep
> > > "route:|source:"
> > >     route:          192.0.2.0/24
> > >     source:         ARIN
> > >     route:          192.0.2.0/24
> > >     source:         ARIN
> > >
> > > 192.0.2.0/24 is a Special Use IPv4 prefix (RFC 3330 / RFC 5735) and
> not
> > > owned by either of the organisations that created a route object for it
> > > in the ARIN IRR. It is crazy that there even are route objects for this
> > > prefix.
> > >
> > > In my opinion, IRR 'route:' objects covering prefixes like
> 192.0.2.0/24
> > > should either be purged from the ARIN IRR - or should be clearly marked
> > > by changing the "source: ARIN" to "source: ARIN-OLD" (or perhaps
> "source:
> > > ARIN-NONAUTHORITATIVE-LEGACY-GARBAGE" ;-))
> >
> > Yep, that is what I was trying to get at. I didn't know if "-" was a
> valid
> > character, since none of the current IRRs have a "-" in their source
> > field.  Therefore it was just easier to assume "-" wasn't valid.
> >
> > But if "-" is valid then "ARIN-OLD" is what I really thought of first,
> but
> > better yet is "ARIN-LEGACY" (and "ARIN-NONAUTHORITATIVE-LEGACY-GARBAGE"
> is
> > fine with me too;-)).
> >
> > And, then after a year or so all the "ARIN-NONAUTHORITATIVE-LEGACY-
> GARBAGE"
> >  magically just disappears.
>
> I'd avoid the term "LEGACY" as that may confuse some because we also
> have the concept of "Legacy IP space".
>
> Perhaps "ARIN-NONAUTH" to align somewhat with the work being done in
> RIPE?
>
> If a subset of the data in ARIN's IRR can be validated, and the set of
> objects that are not validated are tagged with "ARIN-NONAUTH" (since
> those objects are not authoritative due to lack of validation) - we'll
> be in much better shape.
>
> I maintain that no new "ARIN-NONAUTH" objects should be allowed to come
> into existence.
>
> Kind regards,
>
> Job
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschil...@google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.arin.net/pipermail/arin-consult/attachments/20180223/466a82bf/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
ARIN-consult mailing list
ARIN-consult@arin.net
http://lists.arin.net/mailman/listinfo/arin-consult

------------------------------

End of ARIN-consult Digest, Vol 65, Issue 4
*******************************************

Reply via email to