On 12 Jul 2017, at 5:00 AM, Randy Bush wrote:
>
>> FYI. While excellent progress is ongoing with the alternative
>> algorithm specified in draft-ietf-sidr-rpki-validation-reconsidered,
>> it is worth noting that the RIRs will presently be moving to all
>> resource RPKI TA’s to help mitigate the
eir current holdings to one that reflects all holdings (0/0), as
further detailed in the “All Resources Applicability Statement” dated 21
January 2017:
https://www.ietf.org/archive/id/draft-rir-rpki-allres-ta-app-statement-01.txt
… “
FYI,
/John
John Curran
Chair, Number Resource Organi
On Sep 14, 2016, at 4:56 AM, Tim Bruijnzeels wrote:
> ...
> I understand that this is the opinion of the authors. I still disagree. A
> weaker word such as "unwanted" or "anomalous" can also be used - it is less
> likely to confuse a reader, and can be equally clarified in the introduction.
>
>
bject to the terms of the RPA.
>
> To access the TAL, visit:
>
> www.arin.net/resources/rpki/tal.html<http://www.arin.net/resources/rpki/tal.html>
>
> Regards,
>
> John Curran
> President & CEO
> American Registry for Internet Numbers
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
On Mar 22, 2015, at 3:48 PM, Sandra Murphy wrote:
>
> Interesting answer. John, my understanding of what I've read on the ARIN web
> site about transfer was that address space to be transferred had to be unused.
>
> Did I read wrong?
There is no requirement that the address block be "unused"
On Mar 20, 2015, at 2:10 PM, Stephen Kent wrote:
>
> John,
> I agree that the frequency of v4 resources might change as a result of
> exhaustion
> of that space on a regional level. A cursory look at the transfers listed at
> the URL
> you provided would support that projection. But, I'm especi
n't see a lot of organizations running their
own CA, but clearly that could change in the future.
>- would most of the intra-ARIN transfers have ARIN as the common parent
Yes, I would expect that to be the case, at least for the immediate future
On Mar 19, 2015, at 11:00 AM, Stephen Kent wrote:
> ...
> For example, the importance of addressing this issue would be clearer if
> there were statistics detailing the number of INR transfers, by region, for
> the past few years.
Steve -
That information might indeed be useful in understand
On Aug 11, 2014, at 11:58 AM, Tim Bruijnzeels wrote:
> ...
> The *one* thing I (and I believe we..) challenge is whether the an
> overclaimed resource should invalidate a complete certificate, instead of
> invalidating just the resources at hand, but allowing the remainder.
> ...
> The following
On Apr 2, 2013, at 5:59 PM, Shane Amante wrote:
> Although, if the registry function remains "constrained", as it is today,
> then I'm not sure that meaningfully solves any concerns, given that function
> still remains an attractive 'target' for outside parties to (try to) exert
> pressure and
On Apr 2, 2013, at 2:59 PM, Shane Amante wrote:
> So, in the future of the RPKI, as a resource holder, how am I able to "shop
> around" as per the above, to mitigate one or more of the concerns that I've
> illustrated above? Hint: given the, at present, limited number of RIR's near
> the top o
On Apr 2, 2013, at 12:27 PM, Shane Amante wrote:
> IMO, there is still one key difference. ISP's are _directly_ involved in
> receiving such orders, evaluating them for validity, applicability and then
> carrying them out. This can also include providing a heads-up to operations
> teams, in
On Apr 2, 2013, at 10:53 AM, Shane Amante
wrote:
>> You keep repeating that assertion, but note that even in today's world
>> we could be ordered to reclaim and reassign a block with similar effect.
>> It may not be "real time" but there are plenty of folks who follow both
>> the daily issued fil
e does not
automatically mean we shouldn't deploy DNS, only that we should do so with
understanding of that potential (and the same could be said for RPKI...)
Thanks!
/John
John Curran
President and CEO
ARIN
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
On Apr 1, 2013, at 7:24 PM, Danny McPherson wrote:
> On 2013-04-01 14:37, John Curran wrote:
>
>> The present equivalent for the RIRs would be LEO's engaging in orders
>> to change the address holder associated with an IP block, and I am
>> happy to say that (at
LEO order to change a registrant on an IP block could be
rather problematic; there is some chance that I would end up needing a
toothbrush and good reading material depending on the country of the
registrant & nature of the circumstances.
FYI,
/John
John Curran
President and CEO
ARIN
On Mar 27, 2013, at 10:24 AM, "Murphy, Sandra" wrote:
> On Wednesday, March 27, 2013 9:53 AM, John Curran said:
>
>> I believe it is fine as an indicator of potential CA entities within +/- 50%,
>> but even that is simply the best estimate at this time.
>
&
On Mar 27, 2013, at 9:42 AM, Oleg Muravskiy wrote:
> Yes, we also have cases when multiple members belong to a single legal entity.
> But I think we are not interested in different organisations as such, but
> rather the number of CAs.
> So the actual question is whether the number of RPKI CAs w
On Mar 26, 2013, at 9:24 PM, Randy Bush wrote:
> sorry. it is not you, it is the arin database (personally, all the rir
> databases suck, they just suck differently:-). what the arin database
> considers to be an organization does not correspond to what you consider
> one,
Randy is correct - w
On Mar 21, 2013, at 12:48 PM, Sharon Goldberg wrote:
> Thanks for the interest in our work. We wanted to clarify a few points:
>
> -- We have a technical report, which contains motivation and details
> that the slide deck does not. See
> http://www.cs.bu.edu/~goldbe/papers/RPKImanip.pdf
Sharon
On Mar 20, 2013, at 2:26 PM, Russ White wrote:
>> I never argued with addressing the risks that might be posed; I was pointing
>> out that the risk does not equate (on its own) with a reachability event, as
>> alluded to by the paper.
>
> That all depends on the policy undertaken by each speci
On Mar 20, 2013, at 1:51 PM, Russ White wrote:
> How often do you think an attacker would bother with taking out a ROA
> without taking out the route as well?
Invert the question... Of the thousands of entities that could today
inject (hostile) routes and do a hijack today, how many of them wil
On Mar 20, 2013, at 1:10 PM, Russ White wrote:
> In response to a paper that says removing ROAs is a form of DoS, or that
> there are potential problems in the space of the relationship between
> the registry and the address owner, then we've moved from "unknown," to
> "contested." The response g
On Mar 20, 2013, at 7:21 AM, Danny McPherson wrote:
>> Danny - Is there really a "tight coupling" if providers are
>> following the recommend BGP origin validation best practices?
>
> I said BGPSEC...
Got it - the presentation suggests that RPKI poses risks to network
reachability due to att
On Mar 20, 2013, at 6:50 AM, Danny McPherson wrote:
> Interesting presentation here:
>
> http://www.cs.bu.edu/~goldbe/papers/Cooper_RPKI_BFOC.pdf
>
> "The RPKI (Resource Public Key Infrastructure) is a new infrastructure to
> secure Internet routing
> It’s been in deployment since ~2011 But, i
On Mar 11, 2013, at 1:14 PM, Randy Bush wrote:
> but, as stated previously, i have serious reservations about it. at a
> minimum, the sec cons must say that the uri can be an attack vector.
Such as the following?
"RPKI Certificates contain URIs, all of which have potential of being attack
ve
de others from including them so if they so desire.
Thanks!
/John
John Curran
President and CEO
ARIN
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
appropriately titled and are likely to have questionable
effort/payback ratios.
I apologize for sending these comments to the list rather than providing them
via remote
participation methods, but given the number and duration of sidr sessions
today, I cannot
be certain that I&
On Nov 7, 2012, at 10:39 PM, Randy Bush wrote:
>> This would leave Rama and hanuman dependent on the CA services but not
>> aware of the CPS term and conditions despite the explicit requirement
>> specified in the PKIX profile?
>
> OMG!!! my router forgot to call her lawyer! call the network p
On Nov 7, 2012, at 9:09 PM, Randy Bush
wrote:
>> In your example, is sita taking on this responsibility on behalf of rama
>> and hanuman?
>
> no need. this is object based security. rama and hanuman have tals and
> validate.
This would leave Rama and hanuman dependent on the CA services b
On Nov 7, 2012, at 8:33 PM, Randy Bush
wrote:
>>> sita has cache and has agreed to arin's silliness. rama, trying not to
>>> put load on CA publishers, rsyncs sita's cache and wants to validate it.
>>> hanuman rsyncs rama's cache, ...
>>
>> In the above circumstance, how do rama and hanuman fi
On Nov 7, 2012, at 6:17 PM, Randy Bush wrote:
>> which types of parties are expected to be subject to the relying party
>> agreement would also need to share the obtained information with
>> others? (others who would potentially be unaware of the RPA as well as
>> the CP and CPS, in all likelihoo
ays "feel
free to summarize our published data for such purposes." If we can find a
way to increment the RPA to safely exclude such status & reporting uses in
the future, we will do so.
Thanks!
/John
John Curran
President and CEO
ARIN
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
On Nov 4, 2009, at 11:52 AM, Randy Bush wrote:
otoh, i can see that an rpki-provider might want longer than a month
to
implement a new set of ops requirements. but does not the current
ietf
process provide years?
You can't invest in the deployment of some types of requirements
(liabili
On Nov 4, 2009, at 11:41 AM, Randy Bush wrote:
...
but, in that case, is not the largest part of the problem still
getting
the grandparent(s) to swing the covering resource set(s) to new
parent(s)? is not the cp-compliance issue but one very small part
of of
the criteria on which i and my
On Nov 4, 2009, at 10:05 AM, Randy Bush wrote:
...
seems to me thatm if my parent goes out of business, the scramble is
to
build the peerings with the parent(s) to which my grandparent swings
the
resources from which my resources are drawn.
Correct; I agree that's the desired result, rega
Steve -
In general, these changes are fine, and address the naming parent/
child/IANA/RIR/ISP name game issue.
One issue which is raised is that a RPKI service provider now may
be made subject (with one month's notice) to changes to the CP made by
the IETF. As the CP specifies operati
I also support the draft as a WG document.
/John
On Mar 26, 2009, at 8:50 AM, Stephen Kent wrote:
I support adoption of the TA draft as a SIDR WG document.
Steve
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
__
/John
On Mar 26, 2009, at 8:50 AM, Stephen Kent wrote:
I support adoption of the TA draft as a SIDR WG document.
Steve
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
___
On Dec 5, 2008, at 5:31 AM, Geoff Huston wrote:
...
I am arguing that the res-cert draft is appropriately phrased in
making no particular call on IANA to represent itself as the "root"
TA fpr the RPKI, and arguing that the draft is appropriate in that
it paints the picture that the selectio
On Nov 6, 2008, at 1:00 PM, Geoff Huston wrote:
Since Sandy's Last Call on this document there have been a few
changes to the document which I should note here.
...
Following advice from Steve Kent, the section on Trust Anchors was
revised (section 6). The change has concerned the terminology
On Dec 3, 2008, at 5:33 PM, David Conrad wrote:
...
Either IANA is acting in some capacity as a trust anchor and as a
result there ARE IANA considerations
- OR -
IANA is not acting in in some capacity as a trust anchor in which
case the absence of IANA considerations is appropriate, but sect
Andy Newton <[EMAIL PROTECTED]> wrote:
Steve, This explanation helps my understanding significantly. Thanks.
Regarding the rejection by complaint relying party software: this is
because the validation step includes looking for the specific OID
assigned by the CP draft? In other words, if ano
43 matches
Mail list logo
