On Oct 27, 2014, at 12:58 AM, Randy Bush wrote:
>
>> LACNIC numbers (as a percent) are quite good, but my question
>> was why only RIPE has the very impressive total count of ROAs.
>
> < conjecture follows >
>
> of course one can never know. but i conject
> o the are the largest registry act
> LACNIC numbers (as a percent) are quite good, but my question
> was why only RIPE has the very impressive total count of ROAs.
< conjecture follows >
of course one can never know. but i conject
o the are the largest registry actively promotin registration
o the ncc, particularly alex, tim
John
- it is not about RPK
I - our initial goal was to deploy some kind of certification to resources
allocated to our members
Dmitry
If we use for it some SIDR developments - may be - it is a mistake or
misentrepration - but what's true that we never thougy
On 26 Oct 2014, at 14:40, John Curr
it's just a consequence that our initial idea was just about to protect
allocations of our members - not about secure routing at all
On 26 Oct 2014, at 14:40, John Curran wrote:
> On Oct 26, 2014, at 6:46 AM, Randy Bush wrote:
>>
>> 20% coverage in lacnic low? how do ipv6 and dnssec compare
On Oct 26, 2014, at 6:46 AM, Randy Bush wrote:
>
> 20% coverage in lacnic low? how do ipv6 and dnssec compare (which is
> damned sad)? over 2,000 in ripe and over 8%? how does that compare to
> ipv6?
>
> arin, 388 and 0.7%, a joke.
LACNIC numbers (as a percent) are quite good, but my quest
john
> To what extent is the ROA growth rate in the RIPE region (on page 5 of
> the NANOG slides) enabled by the IRR practices of that region?
check out slide 3, lacnic has a 20% adoption rate. both ripe and lacnic
have put energy into their own systems, educating users, ... ripe's
curve would
On Oct 25, 2014, at 8:00 PM, Randy Bush wrote:
>
> you just happen to have the view from a third world country
> look at.
>http://archive.psg.com/141006.rpki-nanog.pdf slides 4 & 5
> or
> http://certification-stats.ripe.net/?type=roa-v4
Randy -
To what extent is the ROA growth rate in
On Sat, Oct 25, 2014 at 5:00 PM, Randy Bush wrote:
> you just happen to have the view from a third world country
> look at.
> http://archive.psg.com/141006.rpki-nanog.pdf slides 4 & 5
> or
> http://certification-stats.ripe.net/?type=roa-v4
>
> randy
>
I agree with Randy. RPKI is achievab
you just happen to have the view from a third world country
look at.
http://archive.psg.com/141006.rpki-nanog.pdf slides 4 & 5
or
http://certification-stats.ripe.net/?type=roa-v4
randy
On 2014-10-25 06:57, Sandra Murphy wrote:
Other RIR based RIRs have the same ability to protect prefixes in
their realm of control. (See RFC 2725 RPSS)(*) (I think that APNIC
is doing pretty much as RIPE is.)
Even RIPE is not secure for prefixes outside their region. (There's
one maintainer t
On 2014-10-25 08:25, John Curran wrote:
With respect to IRR support, the same answer applies. If the
community
is clear on direction, ARIN can strengthen the current IRR offerings,
phase them out and redirect folks to existing solutions, or any other
direction as desired. The hardest part is
On Oct 23, 2014, at 4:18 PM, Danny McPherson wrote:
>
> On 2014-10-23 12:33, Christopher Morrow wrote:
>
>> Sounds like you want to see the rirs make sure they get rpki work
>> dine and widely available with the least encumbrances on the network
>> operator community as possible.
>
> Or focus o
On Oct 25, 2014, at 9:38 PM, Danny McPherson wrote:
> On 2014-10-24 15:24, Christopher Morrow wrote:
>
>> it seems to me that there are a couple simple issues with IRR data
>> (historically):
>> 1) no authority for it (really, at least in the ARIN region)
>> 2) no common practice of keeping i
Other RIR based RIRs have the same ability to protect prefixes in their realm
of control. (See RFC 2725 RPSS)(*) (I think that APNIC is doing pretty much
as RIPE is.)
Even RIPE is not secure for prefixes outside their region. (There's one
maintainer that anyone can use to register anything
On 2014-10-24 15:24, Christopher Morrow wrote:
it seems to me that there are a couple simple issues with IRR data
(historically):
1) no authority for it (really, at least in the ARIN region)
2) no common practice of keeping it updated
3) proxy-registration issues (probably part of cleanup
The RIPE IRR is secure. Why not just copy that for the other regions?
Baldur
On Fri, Oct 24, 2014 at 8:23 AM, John Sweeting wrote:
>
>
> On Thu, Oct 23, 2014 at 4:18 PM, Danny McPherson wrote:
>>
>> On 2014-10-23 12:33, Christopher Morrow wrote:
>>
>>> Sounds like you want to see the rirs make sure they get rpki work
>>> dine and widely available with the least encumbranc
On Thu, Oct 23, 2014 at 4:18 PM, Danny McPherson wrote:
> On 2014-10-23 12:33, Christopher Morrow wrote:
>
> Sounds like you want to see the rirs make sure they get rpki work
>> dine and widely available with the least encumbrances on the network
>> operator community as possible.
>>
>
> Or focu
On 2014-10-23 15:02, Sandra Murphy wrote:
IRR usage, training, tools, and better hygiene, perhaps expressly
validated from resource certification from either RPKI
You might be interested in the draft-ietf-sidr-rpsl-sig-05.txt, which
suggests using RPKI to protect RPSL objects.
Yep, I'm aware
> IRR usage, training, tools, and better hygiene, perhaps expressly validated
> from resource certification from either RPKI
You might be interested in the draft-ietf-sidr-rpsl-sig-05.txt, which suggests
using RPKI to protect RPSL objects.
That would help solve the trust problem in the current
On 2014-10-23 12:33, Christopher Morrow wrote:
Sounds like you want to see the rirs make sure they get rpki work
dine and widely available with the least encumbrances on the network
operator community as possible.
Or focus on more short/intermediate term returns like fortifying all
the existi
On Oct 23, 2014 2:27 PM, "Danny McPherson" wrote:
>
>
>
> I think the routing system would be in a much happier [less bad] place if
only had a minor amount of the energy and resources that USG (and RIRs)
have been put towards RPKI and BGPSEC (i.e., IETF SIDR work) would have
been redirected to lo
I think the routing system would be in a much happier [less bad] place
if only had a minor amount of the energy and resources that USG (and
RIRs) have been put towards RPKI and BGPSEC (i.e., IETF SIDR work) would
have been redirected to lower hanging fruit and better recognizing /
leveraging
23 matches
Mail list logo
