10 Jun
2020
10 Jun
'20
12:45 p.m.
Tom,
It sounds like you're referring to delegated RPKI:
https://www.arin.net/resources/manage/rpki/delegated/
I assume this could be done, but it would still have to be set up
through ARIN first - just as in the case of hosted RPKI.
Regards,
Erik
KE5SAI
On Wed, Jun 10, 2020 at 11:26 AM Erik Seidel <erik(a)znsl.us> wrote:
Tom,
It sounds like you're referring to delegated RPKI:
https://www.arin.net/resources/manage/rpki/delegated/
I assume this could be done, but it would still have to be set up
through ARIN first - just as in the case of hosted RPKI.
Regards,
Erik
KE5SAI
On Wed, Jun 10, 2020 at 11:21 AM Tom Cardinal via 44Net
<44net(a)mailman.ampr.org> wrote:
>
> Cynthia,
>
> I only listed them as an example, my point was a having our own CA
> signed by a signing org that is trusted by RIRs. If that be ARIN then
> so be it. More importantly though, as you know, we have a legacy
> allocation. In my opinion we are equal to an RIR but with the ability
> to make global allocations from the 44.0/9 and 44.128/10 space.
>
> --ton/n2xu 44.98.63.0/29.
>
>
> On 6/10/20 7:38 AM, Cynthia Revström via 44Net wrote:
> > Tom,
> >
> > As Q already mentioned, Thawte or Comodo (now called Sectigo) are for Web
> > PKI, not RPKI, they have nothing to do with this.
> > And not to mention the huge requirements something like that would have,
> > and enormous fees.
> >
> > Not entirely sure what you mean by "act as an IR"?
> >
> >> They would have to accept it much like ARIN and RIPE trust each other
> > In the context of RPKI, ARIN and RIPE NCC do not trust each other, they
> > have their own Root CAs (TALs), which are independent of each other.
> > An RPKI validator has to use both of them.
> >
> > - Cynthia
> >
> >
> > On Wed, Jun 10, 2020 at 2:33 PM Q Misell via 44Net
<44net(a)mailman.ampr.org>
> > wrote:
> >
> >> CA's like Thawte or Comodo won't work for this, they're for web
PKI not
> >> resource PKI.
> >> The 44.0.0.0/9 cert would have to be signed by one of the RIR's trust
> >> anchors (probably ARIN since they have 44.0.0.0/8 assigned to them)
> >>
> >> Thanks,
> >> Q
> >>
> >>
> >> On Wed, 10 Jun 2020 at 13:28, Tom Cardinal via 44Net <
> >> 44net(a)mailman.ampr.org>
> >> wrote:
> >>
> >>> I've been monitoring this discussion. Since our space was
allocated by
> >>> Jon Postel, initially around 1981 (ish), why can't we create our
own
> >>> trust model (CA signed by a CA signing agency like Thawte or Comodo as
> >>> examples) and act as an IR for the 44.0/9 and 22.128/10 space
ourselves
> >>> and publish that trust model to the RIRs? They would have to accept it
> >>> much like ARIN and RIPE trust each other. Then RPKI would work for
> >>> AMPRNet and AMPRNet would control it's own destiny.
> >>>
> >>> --tom/n2xu 44.98.62.0/29
> >>>
> >>>
> >>> On 6/2/20 2:34 PM, Jonathan Lassoff via 44Net wrote:
> >>>> I can sympathize with the sentiment that RPKI and widespread RPKI
> >>>> adoption in its current form will really lock out and
disenfranchise
> >>>> smaller network operators.
> >>>>
> >>>> Now, *more than ever*, we need to enable an Internet that any
> >>>> organization (a natural person, a registered entity, a
hackerspace,
> >>>> etc.) can connect to, uniquely address itself, and begin
exchanging
> >>>> traffic.
> >>>>
> >>>> In order to enable such an open system to function, we also need
ways
> >>>> of ensuring that unicast addresses are unique and that there is
some
> >>>> public, verifiable way of claiming ownership of IP space. Without
> >>>> this, the entire network is open to disruption and abuse by almost
any
> >>>> operator. It's amazing we have gotten so far on the good will
of most
> >>>> operators.
> >>>>
> >>>> The RIR model of lawyers, paperwork, and public databases works for
a
> >>>> lot of people and organizations. IRR was the first step, but it
was
> >>>> complex and a bit clunky to use. I see RPKI for Origin Validation
as
> >>>> just the first/next step of extending this model of trust and
> >>>> numbering resource ownership into the routing protocol space more
> >>>> directly.
> >>>> From a technical standpoint, this logical extension of systems
makes a
> >>>> lot of sense and I don't have a problem with it.
> >>>>
> >>>> For commercial network operators, a RIR registration is just the
cost
> >>>> of doing business.
> >>>> But for many small nonprofits, regional amataur radio/network
> >>>> operators, or individuals, a few thousand dollars/euros a year is
a
> >>>> lot of money that makes Internet independence out of reach.
> >>>> They end up having to resort to the hegemony of their local
incumbent
> >>>> monopoly and chain themselves to the whims of their upstreams and
> >>>> regulators.
> >>>>
> >>>> I suspect many legacy resource holders find themselves in a
similar
> >>>> limbo-state of not wanting to participate in the RIR model and pay
> >>>> money for essentially nothing.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Echoing some similar earlier sentiments to want to create a CA for
> >>>> legacy address holders: How feasible would it be to create
something
> >>>> RIR-like, but noncommercial?
> >>>> A place for legacy address holders to coordinate and register
> >>>> resources seems like a natural fit. If we're going to operate
a
> >>>> database of ROAs, we're going to need some database of address
space
> >>>> ownership.
> >>>> For 44net use cases, this seems really straightforward, since we
have
> >>>> the Portal to draw from. But for other organizations, it gets a
bit
> >>>> more complicated to do properly. Given some random email
> >>>> address/account in some hypothetical legacy RIR, how can we really
> >>>> validate that they're authorized to take actions on behalf of
some
> >>>> organization?
> >>>> To take some random examples from the IANA IPv4 list: DISA, USPS,
> >>>> AT&T, Apple, etc. Doing this right is going to take some
process,
> >>>> record keeping, and well.... work.
> >>>> With this context, I can see how a lot of RIRs go commercial.
However,
> >>>> with a bit of automation, good documentation and records, and some
> >>>> dedicated volunteers, this seems like a really doable/achievable
thing
> >>>> in the netops community.
> >>>>
> >>>> I would be curious to know if anyone else shares these
views/dreams
> >>>> and would like to chat about it.
> >>>>
> >>>> Stay safe and sane out there.
> >>>>
> >>>> Cheers,
> >>>> jof
> >>>>
> >>>> On Tue, 2 Jun 2020 at 08:18, Job Snijders via 44Net
> >>>> <44net(a)mailman.ampr.org> wrote:
> >>>>> Thomas,
> >>>>>
> >>>>> You say
> >>>>>
> >>>>> On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via
44Net
> >> wrote:
> >>>>>> DO NOT participate in RPKI!
> >>>>> And ...
> >>>>>
> >>>>>> We should be protecting our Internet!! Just saying...
> >>>>> What are you really saying? These statements seem at odds with
each
> >>> other.
> >>>>> How do you protect your internet? Maybe I can learn some tricks
from
> >>> you?
> >>>>> Kind regards,
> >>>>>
> >>>>> Job
> >>>>> _________________________________________
> >>>>> 44Net mailing list
> >>>>> 44Net(a)mailman.ampr.org
> >>>>> https://mailman.ampr.org/mailman/listinfo/44net
> >>>> _________________________________________
> >>>> 44Net mailing list
> >>>> 44Net(a)mailman.ampr.org
> >>>> https://mailman.ampr.org/mailman/listinfo/44net
> >>>
> >>> _________________________________________
> >>> 44Net mailing list
> >>> 44Net(a)mailman.ampr.org
> >>> https://mailman.ampr.org/mailman/listinfo/44net
> >>>
> >> _________________________________________
> >> 44Net mailing list
> >> 44Net(a)mailman.ampr.org
> >> https://mailman.ampr.org/mailman/listinfo/44net
> >>
> > _________________________________________
> > 44Net mailing list
> > 44Net(a)mailman.ampr.org
> > https://mailman.ampr.org/mailman/listinfo/44net
>
>
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
10 Jun
10 Jun
12:49 p.m.
New subject: NSP bugging me to use RPKI for my /24 grant
Yes what your say is correct,
Delegated RPKI would be required if 44net where to further delegate to
assignees.
Thanks,
Q
Director
AS207960 Cyfyngedig
https://as207960.net
On Wed, 10 Jun 2020 at 17:47, Erik Seidel via 44Net <44net(a)mailman.ampr.org>
wrote:
Tom,
It sounds like you're referring to delegated RPKI:
https://www.arin.net/resources/manage/rpki/delegated/
I assume this could be done, but it would still have to be set up
through ARIN first - just as in the case of hosted RPKI.
Regards,
Erik
KE5SAI
On Wed, Jun 10, 2020 at 11:26 AM Erik Seidel <erik(a)znsl.us> wrote:
Tom,
It sounds like you're referring to delegated RPKI:
https://www.arin.net/resources/manage/rpki/delegated/
I assume this could be done, but it would still have to be set up
through ARIN first - just as in the case of hosted RPKI.
Regards,
Erik
KE5SAI
On Wed, Jun 10, 2020 at 11:21 AM Tom Cardinal via 44Net
<44net(a)mailman.ampr.org> wrote:
>
> Cynthia,
>
> I only listed them as an example, my point was a having our own CA
> signed by a signing org that is trusted by RIRs. If that be ARIN then
> so be it. More importantly though, as you know, we have a legacy
> allocation. In my opinion we are equal to an RIR but with the ability
> to make global allocations from the 44.0/9 and 44.128/10 space.
>
> --ton/n2xu 44.98.63.0/29.
>
>
> On 6/10/20 7:38 AM, Cynthia Revström via 44Net wrote:
> > Tom,
> >
> > As Q already mentioned, Thawte or Comodo (now called Sectigo) are
for
Web
> > PKI, not RPKI, they have nothing to do
with this.
> > And not to mention the huge requirements something like that would
have,
> > and enormous fees.
> >
> > Not entirely sure what you mean by "act as an IR"?
> >
> >> They would have to accept it much like ARIN and RIPE trust each
other
> > In the context of RPKI, ARIN and RIPE
NCC do not trust each other,
they
> > have their own Root CAs (TALs), which
are independent of each other.
> > An RPKI validator has to use both of them.
> >
> > - Cynthia
> >
> >
> > On Wed, Jun 10, 2020 at 2:33 PM Q Misell via 44Net <
44net(a)mailman.ampr.org>
> > wrote:
> >
> >> CA's like Thawte or Comodo won't work for this, they're for web
PKI
not
> >> resource PKI.
> >> The 44.0.0.0/9 cert would have to be signed by one of the RIR's
trust
> >> anchors (probably ARIN since they
have 44.0.0.0/8 assigned to them)
> >>
> >> Thanks,
> >> Q
> >>
> >>
> >> On Wed, 10 Jun 2020 at 13:28, Tom Cardinal via 44Net <
> >> 44net(a)mailman.ampr.org>
> >> wrote:
> >>
> >>> I've been monitoring this discussion. Since our space was
allocated by
> >>> Jon Postel, initially around
1981 (ish), why can't we create our
own
> >>> trust model (CA signed by a CA
signing agency like Thawte or
Comodo as
> >>> examples) and act as an IR for
the 44.0/9 and 22.128/10 space
ourselves
> >>> and publish that trust model to
the RIRs? They would have to
accept it
> >>> much like ARIN and RIPE trust
each other. Then RPKI would work for
> >>> AMPRNet and AMPRNet would control it's own destiny.
> >>>
> >>> --tom/n2xu 44.98.62.0/29
> >>>
> >>>
> >>> On 6/2/20 2:34 PM, Jonathan Lassoff via 44Net wrote:
> >>>> I can sympathize with the sentiment that RPKI and widespread RPKI
> >>>> adoption in its current form will really lock out and
disenfranchise
> >>>> smaller network operators.
> >>>>
> >>>> Now, *more than ever*, we need to enable an Internet that any
> >>>> organization (a natural person, a registered entity, a
hackerspace,
> >>>> etc.) can connect to,
uniquely address itself, and begin
exchanging
> >>>> traffic.
> >>>>
> >>>> In order to enable such an open system to function, we also need
ways
> >>>> of ensuring that unicast
addresses are unique and that there is
some
> >>>> public, verifiable way of
claiming ownership of IP space. Without
> >>>> this, the entire network is open to disruption and abuse by
almost any
> >>>> operator. It's amazing
we have gotten so far on the good will of
most
> >>>> operators.
> >>>>
> >>>> The RIR model of lawyers, paperwork, and public databases works
for a
> >>>> lot of people and
organizations. IRR was the first step, but it
was
> >>>> complex and a bit clunky to
use. I see RPKI for Origin Validation
as
> >>>> just the first/next step of
extending this model of trust and
> >>>> numbering resource ownership into the routing protocol space more
> >>>> directly.
> >>>> From a technical standpoint, this logical extension of systems
makes a
> >>>> lot of sense and I
don't have a problem with it.
> >>>>
> >>>> For commercial network operators, a RIR registration is just the
cost
> >>>> of doing business.
> >>>> But for many small nonprofits, regional amataur radio/network
> >>>> operators, or individuals, a few thousand dollars/euros a year is
a
> >>>> lot of money that makes
Internet independence out of reach.
> >>>> They end up having to resort to the hegemony of their local
incumbent
> >>>> monopoly and chain
themselves to the whims of their upstreams and
> >>>> regulators.
> >>>>
> >>>> I suspect many legacy resource holders find themselves in a
similar
> >>>> limbo-state of not wanting
to participate in the RIR model and pay
> >>>> money for essentially nothing.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Echoing some similar earlier sentiments to want to create a CA for
> >>>> legacy address holders: How feasible would it be to create
something
> >>>> RIR-like, but
noncommercial?
> >>>> A place for legacy address holders to coordinate and register
> >>>> resources seems like a natural fit. If we're going to operate
a
> >>>> database of ROAs, we're going to need some database of address
space
> >>>> ownership.
> >>>> For 44net use cases, this seems really straightforward, since we
have
> >>>> the Portal to draw from.
But for other organizations, it gets a
bit
> >>>> more complicated to do
properly. Given some random email
> >>>> address/account in some hypothetical legacy RIR, how can we really
> >>>> validate that they're authorized to take actions on behalf of
some
> >>>> organization?
> >>>> To take some random examples from the IANA IPv4 list: DISA, USPS,
> >>>> AT&T, Apple, etc. Doing this right is going to take some
process,
> >>>> record keeping, and well.... work.
> >>>> With this context, I can see how a lot of RIRs go commercial.
However,
> >>>> with a bit of automation,
good documentation and records, and some
> >>>> dedicated volunteers, this seems like a really doable/achievable
thing
> >>>> in the netops community.
> >>>>
> >>>> I would be curious to know if anyone else shares these
views/dreams
> >>>> and would like to chat
about it.
> >>>>
> >>>> Stay safe and sane out there.
> >>>>
> >>>> Cheers,
> >>>> jof
> >>>>
> >>>> On Tue, 2 Jun 2020 at 08:18, Job Snijders via 44Net
> >>>> <44net(a)mailman.ampr.org> wrote:
> >>>>> Thomas,
> >>>>>
> >>>>> You say
> >>>>>
> >>>>> On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via
44Net
> >> wrote:
> >>>>>> DO NOT participate in RPKI!
> >>>>> And ...
> >>>>>
> >>>>>> We should be protecting our Internet!! Just saying...
> >>>>> What are you really saying? These statements seem at odds with
each
> >>> other.
> >>>>> How do you protect your internet? Maybe I can learn some tricks
from
> >>> you?
> >>>>> Kind regards,
> >>>>>
> >>>>> Job
> >>>>> _________________________________________
> >>>>> 44Net mailing list
> >>>>> 44Net(a)mailman.ampr.org
> >>>>> https://mailman.ampr.org/mailman/listinfo/44net
> >>>> _________________________________________
> >>>> 44Net mailing list
> >>>> 44Net(a)mailman.ampr.org
> >>>> https://mailman.ampr.org/mailman/listinfo/44net
> >>>
> >>> _________________________________________
> >>> 44Net mailing list
> >>> 44Net(a)mailman.ampr.org
> >>> https://mailman.ampr.org/mailman/listinfo/44net
> >>>
> >> _________________________________________
> >> 44Net mailing list
> >> 44Net(a)mailman.ampr.org
> >> https://mailman.ampr.org/mailman/listinfo/44net
> >>
> > _________________________________________
> > 44Net mailing list
> > 44Net(a)mailman.ampr.org
> > https://mailman.ampr.org/mailman/listinfo/44net
>
>
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
2:34 p.m.
New subject: NSP bugging me to use RPKI for my /24 grant
The issue with delegated RPKI is that it requires ARDC to sign an ARIN
RSA and (I'm assuming) have to pay into the ARIN fee structure, which
for a /9 and /10 would be $64K/yr under the current ARIN fee schedule.
As far as I am aware, ARDC has not signed an ARIN RSA and is not
currently a member of ARIN.
The whole discussion around setting up an ARDC TAL was specifically to
avoid becoming an ARIN member and signing an RSA.
Chris
On 10/06/2020 09:49, Q Misell via 44Net wrote:
Yes what your say is correct,
Delegated RPKI would be required if 44net where to further delegate to
assignees.
Thanks,
Q
Director
AS207960 Cyfyngedig
https://as207960.net
On Wed, 10 Jun 2020 at 17:47, Erik Seidel via 44Net <44net(a)mailman.ampr.org>
wrote:
Tom,
It sounds like you're referring to delegated RPKI:
https://www.arin.net/resources/manage/rpki/delegated/
I assume this could be done, but it would still have to be set up
through ARIN first - just as in the case of hosted RPKI.
Regards,
Erik
KE5SAI
On Wed, Jun 10, 2020 at 11:26 AM Erik Seidel <erik(a)znsl.us> wrote:
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net Tom,
It sounds like you're referring to delegated RPKI:
https://www.arin.net/resources/manage/rpki/delegated/
I assume this could be done, but it would still have to be set up
through ARIN first - just as in the case of hosted RPKI.
Regards,
Erik
KE5SAI
On Wed, Jun 10, 2020 at 11:21 AM Tom Cardinal via 44Net
<44net(a)mailman.ampr.org> wrote:
> Cynthia,
>
> I only listed them as an example, my point was a having our own CA
> signed by a signing org that is trusted by RIRs. If that be ARIN then
> so be it. More importantly though, as you know, we have a legacy
> allocation. In my opinion we are equal to an RIR but with the ability
> to make global allocations from the 44.0/9 and 44.128/10 space.
>
> --ton/n2xu 44.98.63.0/29.
>
>
> On 6/10/20 7:38 AM, Cynthia Revström via 44Net wrote:
>> Tom,
>>
>> As Q already mentioned, Thawte or Comodo (now called Sectigo) are
for Web
>> PKI, not RPKI, they have nothing to do
with this.
>> And not to mention the huge requirements something like that would
have,
>> and enormous fees.
>>
>> Not entirely sure what you mean by "act as an IR"?
>>
>>> They would have to accept it much like ARIN and RIPE trust each
other
>> In the context of RPKI, ARIN and RIPE NCC
do not trust each other,
they
>> have their own Root CAs (TALs), which are
independent of each other.
>> An RPKI validator has to use both of them.
>>
>> - Cynthia
>>
>>
>> On Wed, Jun 10, 2020 at 2:33 PM Q Misell via 44Net <
44net(a)mailman.ampr.org>
>> wrote:
>>
>>> CA's like Thawte or Comodo won't work for this, they're for web
PKI
not
>>> resource PKI.
>>> The 44.0.0.0/9 cert would have to be signed by one of the RIR's
trust
>>> anchors (probably ARIN since they
have 44.0.0.0/8 assigned to them)
>>>
>>> Thanks,
>>> Q
>>>
>>>
>>> On Wed, 10 Jun 2020 at 13:28, Tom Cardinal via 44Net <
>>> 44net(a)mailman.ampr.org>
>>> wrote:
>>>
>>>> I've been monitoring this discussion. Since our space was
allocated by
>>>> Jon Postel, initially around 1981
(ish), why can't we create our
own
>>>> trust model (CA signed by a CA
signing agency like Thawte or
Comodo as
>>>> examples) and act as an IR for
the 44.0/9 and 22.128/10 space
ourselves
>>>> and publish that trust model to
the RIRs? They would have to
accept it
>>>> much like ARIN and RIPE trust
each other. Then RPKI would work for
>>>> AMPRNet and AMPRNet would control it's own destiny.
>>>>
>>>> --tom/n2xu 44.98.62.0/29
>>>>
>>>>
>>>> On 6/2/20 2:34 PM, Jonathan Lassoff via 44Net wrote:
>>>>> I can sympathize with the sentiment that RPKI and widespread RPKI
>>>>> adoption in its current form will really lock out and
disenfranchise
>>>>> smaller network operators.
>>>>>
>>>>> Now, *more than ever*, we need to enable an Internet that any
>>>>> organization (a natural person, a registered entity, a
hackerspace,
>>>>> etc.) can connect to,
uniquely address itself, and begin
exchanging
>>>>> traffic.
>>>>>
>>>>> In order to enable such an open system to function, we also need
ways
>>>>> of ensuring that unicast
addresses are unique and that there is
some
>>>>> public, verifiable way of
claiming ownership of IP space. Without
>>>>> this, the entire network is open to disruption and abuse by
almost any
>>>>> operator. It's amazing we
have gotten so far on the good will of
most
>>>>> operators.
>>>>>
>>>>> The RIR model of lawyers, paperwork, and public databases works
for a
>>>>> lot of people and
organizations. IRR was the first step, but it
was
>>>>> complex and a bit clunky to
use. I see RPKI for Origin Validation
as
>>>>> just the first/next step of
extending this model of trust and
>>>>> numbering resource ownership into the routing protocol space more
>>>>> directly.
>>>>> From a technical standpoint, this logical extension of systems
makes a
>>>>> lot of sense and I don't
have a problem with it.
>>>>>
>>>>> For commercial network operators, a RIR registration is just the
cost
>>>>> of doing business.
>>>>> But for many small nonprofits, regional amataur radio/network
>>>>> operators, or individuals, a few thousand dollars/euros a year is
a
>>>>> lot of money that makes
Internet independence out of reach.
>>>>> They end up having to resort to the hegemony of their local
incumbent
>>>>> monopoly and chain themselves
to the whims of their upstreams and
>>>>> regulators.
>>>>>
>>>>> I suspect many legacy resource holders find themselves in a
similar
>>>>> limbo-state of not wanting to
participate in the RIR model and pay
>>>>> money for essentially nothing.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Echoing some similar earlier sentiments to want to create a CA for
>>>>> legacy address holders: How feasible would it be to create
something
>>>>> RIR-like, but noncommercial?
>>>>> A place for legacy address holders to coordinate and register
>>>>> resources seems like a natural fit. If we're going to operate a
>>>>> database of ROAs, we're going to need some database of address
space
>>>>> ownership.
>>>>> For 44net use cases, this seems really straightforward, since we
have
>>>>> the Portal to draw from. But
for other organizations, it gets a
bit
>>>>> more complicated to do
properly. Given some random email
>>>>> address/account in some hypothetical legacy RIR, how can we really
>>>>> validate that they're authorized to take actions on behalf of
some
>>>>> organization?
>>>>> To take some random examples from the IANA IPv4 list: DISA, USPS,
>>>>> AT&T, Apple, etc. Doing this right is going to take some
process,
>>>>> record keeping, and well.... work.
>>>>> With this context, I can see how a lot of RIRs go commercial.
However,
>>>>> with a bit of automation,
good documentation and records, and some
>>>>> dedicated volunteers, this seems like a really doable/achievable
thing
>>>>> in the netops community.
>>>>>
>>>>> I would be curious to know if anyone else shares these
views/dreams
>>>>> and would like to chat about
it.
>>>>>
>>>>> Stay safe and sane out there.
>>>>>
>>>>> Cheers,
>>>>> jof
>>>>>
>>>>> On Tue, 2 Jun 2020 at 08:18, Job Snijders via 44Net
>>>>> <44net(a)mailman.ampr.org> wrote:
>>>>>> Thomas,
>>>>>>
>>>>>> You say
>>>>>>
>>>>>> On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via 44Net
>>> wrote:
>>>>>>> DO NOT participate in RPKI!
>>>>>> And ...
>>>>>>
>>>>>>> We should be protecting our Internet!! Just saying...
>>>>>> What are you really saying? These statements seem at odds with
each
>>>> other.
>>>>>> How do you protect your internet? Maybe I can learn some tricks
from
>>>> you?
>>>>>> Kind regards,
>>>>>>
>>>>>> Job
>>>>>> _________________________________________
>>>>>> 44Net mailing list
>>>>>> 44Net(a)mailman.ampr.org
>>>>>> https://mailman.ampr.org/mailman/listinfo/44net
>>>>> _________________________________________
>>>>> 44Net mailing list
>>>>> 44Net(a)mailman.ampr.org
>>>>> https://mailman.ampr.org/mailman/listinfo/44net
>>>> _________________________________________
>>>> 44Net mailing list
>>>> 44Net(a)mailman.ampr.org
>>>> https://mailman.ampr.org/mailman/listinfo/44net
>>>>
>>> _________________________________________
>>> 44Net mailing list
>>> 44Net(a)mailman.ampr.org
>>> https://mailman.ampr.org/mailman/listinfo/44net
>>>
>> _________________________________________
>> 44Net mailing list
>> 44Net(a)mailman.ampr.org
>> https://mailman.ampr.org/mailman/listinfo/44net
>
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
2:50 p.m.
New subject: NSP bugging me to use RPKI for my /24 grant
I am aware that NTT would support an ARDC TAL, so it's not an entirely
silly question.
I would also advise discussions with ARIN on delegated RPKI or possible
cross signing of an ARDC TAL.
Thanks,
Q
Director
AS207960 Cyfyngedig
https://as207960.net
On Wed, 10 Jun 2020 at 19:36, Christopher Munz-Michielin via 44Net <
44net(a)mailman.ampr.org> wrote:
The issue with delegated RPKI is that it requires ARDC
to sign an ARIN
RSA and (I'm assuming) have to pay into the ARIN fee structure, which
for a /9 and /10 would be $64K/yr under the current ARIN fee schedule.
As far as I am aware, ARDC has not signed an ARIN RSA and is not
currently a member of ARIN.
The whole discussion around setting up an ARDC TAL was specifically to
avoid becoming an ARIN member and signing an RSA.
Chris
On 10/06/2020 09:49, Q Misell via 44Net wrote:
Yes what your say is correct,
Delegated RPKI would be required if 44net where to further delegate to
assignees.
Thanks,
Q
Director
AS207960 Cyfyngedig
https://as207960.net
On Wed, 10 Jun 2020 at 17:47, Erik Seidel via 44Net <
44net(a)mailman.ampr.org>
wrote:
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
Tom,
It sounds like you're referring to delegated RPKI:
https://www.arin.net/resources/manage/rpki/delegated/
I assume this could be done, but it would still have to be set up
through ARIN first - just as in the case of hosted RPKI.
Regards,
Erik
KE5SAI
On Wed, Jun 10, 2020 at 11:26 AM Erik Seidel <erik(a)znsl.us> wrote:
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net Tom,
It sounds like you're referring to delegated RPKI:
https://www.arin.net/resources/manage/rpki/delegated/
I assume this could be done, but it would still have to be set up
through ARIN first - just as in the case of hosted RPKI.
Regards,
Erik
KE5SAI
On Wed, Jun 10, 2020 at 11:21 AM Tom Cardinal via 44Net
<44net(a)mailman.ampr.org> wrote:
> Cynthia,
>
> I only listed them as an example, my point was a having our own CA
> signed by a signing org that is trusted by RIRs. If that be ARIN then
> so be it. More importantly though, as you know, we have a legacy
> allocation. In my opinion we are equal to an RIR but with the ability
> to make global allocations from the 44.0/9 and 44.128/10 space.
>
> --ton/n2xu 44.98.63.0/29.
>
>
> On 6/10/20 7:38 AM, Cynthia Revström via 44Net wrote:
>> Tom,
>>
>> As Q already mentioned, Thawte or Comodo (now called Sectigo) are
for Web
>> PKI, not RPKI, they have nothing to do
with this.
>> And not to mention the huge requirements something like that would
have,
>> and enormous fees.
>>
>> Not entirely sure what you mean by "act as an IR"?
>>
>>> They would have to accept it much like ARIN and RIPE trust each
other
>> In the context of RPKI, ARIN and RIPE NCC
do not trust each other,
they
>> have their own Root CAs (TALs), which are
independent of each other.
>> An RPKI validator has to use both of them.
>>
>> - Cynthia
>>
>>
>> On Wed, Jun 10, 2020 at 2:33 PM Q Misell via 44Net <
44net(a)mailman.ampr.org>
>> wrote:
>>
>>> CA's like Thawte or Comodo won't work for this, they're for web
PKI
not
>>> resource PKI.
>>> The 44.0.0.0/9 cert would have to be signed by one of the RIR's
trust
>>> anchors (probably ARIN since they
have 44.0.0.0/8 assigned to them)
>>>
>>> Thanks,
>>> Q
>>>
>>>
>>> On Wed, 10 Jun 2020 at 13:28, Tom Cardinal via 44Net <
>>> 44net(a)mailman.ampr.org>
>>> wrote:
>>>
>>>> I've been monitoring this discussion. Since our space was
allocated by
>>>> Jon Postel, initially around 1981
(ish), why can't we create our
own
>>>> trust model (CA signed by a CA
signing agency like Thawte or
Comodo as
>>>> examples) and act as an IR for
the 44.0/9 and 22.128/10 space
ourselves
>>>> and publish that trust model to
the RIRs? They would have to
accept it
>>>> much like ARIN and RIPE trust
each other. Then RPKI would work for
>>>> AMPRNet and AMPRNet would control it's own destiny.
>>>>
>>>> --tom/n2xu 44.98.62.0/29
>>>>
>>>>
>>>> On 6/2/20 2:34 PM, Jonathan Lassoff via 44Net wrote:
>>>>> I can sympathize with the sentiment that RPKI and widespread RPKI
>>>>> adoption in its current form will really lock out and
disenfranchise
>>>>> smaller network operators.
>>>>>
>>>>> Now, *more than ever*, we need to enable an Internet that any
>>>>> organization (a natural person, a registered entity, a
hackerspace,
>>>>> etc.) can connect to,
uniquely address itself, and begin
exchanging
>>>>> traffic.
>>>>>
>>>>> In order to enable such an open system to function, we also need
ways
>>>>> of ensuring that unicast
addresses are unique and that there is
some
>>>>> public, verifiable way of
claiming ownership of IP space. Without
>>>>> this, the entire network is open to disruption and abuse by
almost any
>>>>> operator. It's amazing we
have gotten so far on the good will of
most
>>>>> operators.
>>>>>
>>>>> The RIR model of lawyers, paperwork, and public databases works
for a
>>>>> lot of people and
organizations. IRR was the first step, but it
was
>>>>> complex and a bit clunky to
use. I see RPKI for Origin Validation
as
>>>>> just the first/next step of
extending this model of trust and
>>>>> numbering resource ownership into the routing protocol space more
>>>>> directly.
>>>>> From a technical standpoint, this logical extension of systems
makes a
>>>>> lot of sense and I don't
have a problem with it.
>>>>>
>>>>> For commercial network operators, a RIR registration is just the
cost
>>>>> of doing business.
>>>>> But for many small nonprofits, regional amataur radio/network
>>>>> operators, or individuals, a few thousand dollars/euros a year is
a
>>>>> lot of money that makes
Internet independence out of reach.
>>>>> They end up having to resort to the hegemony of their local
incumbent
>>>>> monopoly and chain themselves
to the whims of their upstreams and
>>>>> regulators.
>>>>>
>>>>> I suspect many legacy resource holders find themselves in a
similar
>>>>> limbo-state of not wanting to
participate in the RIR model and pay
>>>>> money for essentially nothing.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Echoing some similar earlier sentiments to want to create a CA for
>>>>> legacy address holders: How feasible would it be to create
something
>>>>> RIR-like, but noncommercial?
>>>>> A place for legacy address holders to coordinate and register
>>>>> resources seems like a natural fit. If we're going to operate a
>>>>> database of ROAs, we're going to need some database of address
space
>>>>> ownership.
>>>>> For 44net use cases, this seems really straightforward, since we
have
>>>>> the Portal to draw from. But
for other organizations, it gets a
bit
>>>>> more complicated to do
properly. Given some random email
>>>>> address/account in some hypothetical legacy RIR, how can we really
>>>>> validate that they're authorized to take actions on behalf of
some
>>>>> organization?
>>>>> To take some random examples from the IANA IPv4 list: DISA, USPS,
>>>>> AT&T, Apple, etc. Doing this right is going to take some
process,
>>>>> record keeping, and well.... work.
>>>>> With this context, I can see how a lot of RIRs go commercial.
However,
>>>>> with a bit of automation,
good documentation and records, and some
>>>>> dedicated volunteers, this seems like a really doable/achievable
thing
>>>>> in the netops community.
>>>>>
>>>>> I would be curious to know if anyone else shares these
views/dreams
>>>>> and would like to chat about
it.
>>>>>
>>>>> Stay safe and sane out there.
>>>>>
>>>>> Cheers,
>>>>> jof
>>>>>
>>>>> On Tue, 2 Jun 2020 at 08:18, Job Snijders via 44Net
>>>>> <44net(a)mailman.ampr.org> wrote:
>>>>>> Thomas,
>>>>>>
>>>>>> You say
>>>>>>
>>>>>> On Tue, Jun 2, 2020, at 04:17, Thomas Jones - KG5ZI /8 via 44Net
>>> wrote:
>>>>>>> DO NOT participate in RPKI!
>>>>>> And ...
>>>>>>
>>>>>>> We should be protecting our Internet!! Just saying...
>>>>>> What are you really saying? These statements seem at odds with
each
>>>> other.
>>>>>> How do you protect your internet? Maybe I can learn some tricks
from
>>>> you?
>>>>>> Kind regards,
>>>>>>
>>>>>> Job
>>>>>> _________________________________________
>>>>>> 44Net mailing list
>>>>>> 44Net(a)mailman.ampr.org
>>>>>> https://mailman.ampr.org/mailman/listinfo/44net
>>>>> _________________________________________
>>>>> 44Net mailing list
>>>>> 44Net(a)mailman.ampr.org
>>>>> https://mailman.ampr.org/mailman/listinfo/44net
>>>> _________________________________________
>>>> 44Net mailing list
>>>> 44Net(a)mailman.ampr.org
>>>> https://mailman.ampr.org/mailman/listinfo/44net
>>>>
>>> _________________________________________
>>> 44Net mailing list
>>> 44Net(a)mailman.ampr.org
>>> https://mailman.ampr.org/mailman/listinfo/44net
>>>
>> _________________________________________
>> 44Net mailing list
>> 44Net(a)mailman.ampr.org
>> https://mailman.ampr.org/mailman/listinfo/44net
>
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
3:02 p.m.
New subject: NSP bugging me to use RPKI for my /24 grant
Hi,
On Wed, Jun 10, 2020 at 07:50:44PM +0100, Q Misell via 44Net wrote:
I am aware that NTT would support an ARDC TAL, so
it's not an entirely
silly question.
I think I said I'd *consider* supporting such a TAL, if and only if ARDC
produces and operates a Trust Anchor that meets a set of minimum
requirements. This is not the same as actual support, it means that if
ARDC produces something RPKI related I'm happy to take a look at what
was produced and analyse whether it is fit for some purpose.
I would also advise discussions with ARIN on delegated
RPKI or possible
cross signing of an ARDC TAL.
"cross signing" is not a term that makes sense in this context.
I think if ARDC wants delegated RPKI services from ARIN, ARDC will need
to become an ARIN member and bring/handover the 44net space to ARIN.
Kind regards,
Job
3:06 p.m.
New subject: NSP bugging me to use RPKI for my /24 grant
On 6/10/20 2:34 PM, Christopher Munz-Michielin via 44Net wrote:
The whole discussion around setting up an ARDC TAL was
specifically to
avoid becoming an ARIN member and signing an RSA.
The issue this brings up then is one of legitimacy and competency of ARDC and
the desire to make this happen. ARDC can't figure out DNSSEC, TAL and cert
signing is way beyond that.
RPKI is a nice to have, an additional way to secure networks, it's not the
only way, nor should it be. It's a nice to have, but there's got to be a
desire to make it happen.
73's
--
Bryan Fields
727-409-1194 - Voice
http://bryanfields.net
11 Jun
11 Jun
5:03 a.m.
New subject: NSP bugging me to use RPKI for my /24 grant
Hi,
I have a question under current situation.
If ARDC isn't doing this in a near future, under current framework, as a
LOA holder, can I setup my own RPKI and sign only my lease? It looks
like that in an foreseeable future it'd be increasingly difficult to
peer with people without RPKI.
73 de BH1XQV
On A2020/06/11 AM3:06, Bryan Fields via 44Net wrote:
On 6/10/20 2:34 PM, Christopher Munz-Michielin via
44Net wrote:
The whole discussion around setting up an ARDC
TAL was specifically to
avoid becoming an ARIN member and signing an RSA.
The issue this brings up then is
one of legitimacy and competency of ARDC and
the desire to make this happen. ARDC can't figure out DNSSEC, TAL and cert
signing is way beyond that.
RPKI is a nice to have, an additional way to secure networks, it's not the
only way, nor should it be. It's a nice to have, but there's got to be a
desire to make it happen.
73's
5:07 a.m.
New subject: NSP bugging me to use RPKI for my /24 grant
Hi,
Unfortunately you can't just set up your own RPKI, as there would be no
chain of trust to a trust anchor.
Thanks,
Q
Director
AS207960 Cyfyngedig
https://as207960.net
On Thu, 11 Jun 2020 at 10:05, Quan Zhou via 44Net <44net(a)mailman.ampr.org>
wrote:
Hi,
I have a question under current situation.
If ARDC isn't doing this in a near future, under current framework, as a
LOA holder, can I setup my own RPKI and sign only my lease? It looks
like that in an foreseeable future it'd be increasingly difficult to
peer with people without RPKI.
73 de BH1XQV
On A2020/06/11 AM3:06, Bryan Fields via 44Net wrote:
On 6/10/20 2:34 PM, Christopher Munz-Michielin
via 44Net wrote:
ARDC and
The whole discussion around setting up an ARDC
TAL was specifically to
avoid becoming an ARIN member and signing an RSA.
The issue this brings up then is
one of legitimacy and competency of the desire to make this happen. ARDC can't
figure out DNSSEC, TAL and
cert
signing is way beyond that.
RPKI is a nice to have, an additional way to secure networks, it's not
the
only way, nor should it be. It's a nice to
have, but there's got to be a
desire to make it happen.
73's
_________________________________________
44Net mailing list
44Net(a)mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net
12 Jun
12 Jun
3:31 p.m.
New subject: NSP bugging me to use RPKI for my /24 grant
If I remember correctly, the ARDC must have something north of $25M US
dollars in the bank (assuming the original sale to Amazon had a 40%+ tax
applied). If true, wouldn't it make sense to have the ARDC spend some
of this money to create some of these foundation technologies so we can
continue enjoying 44.x.x.x address space as the Internet continues to
evolve? Some of these technologies aren't simple and while there are
many brilliant people on this list, this is our hobby area.. not our day
job.
This seems like a potential good use of the ARDC money as long as the
effort is properly spec'ed, monitored, and audited. Once in place,
maybe we can have volunteers to help maintain the infrastructure.
Just my $0.02
--David
KI6ZHD
On 06/10/2020 12:06 PM, Bryan Fields via 44Net wrote:
On 6/10/20 2:34 PM, Christopher Munz-Michielin via
44Net wrote:
The whole discussion around setting up an ARDC
TAL was specifically to
avoid becoming an ARIN member and signing an RSA.
The issue this brings up then is
one of legitimacy and competency of ARDC and
the desire to make this happen. ARDC can't figure out DNSSEC, TAL and cert
signing is way beyond that.
RPKI is a nice to have, an additional way to secure networks, it's not the
only way, nor should it be. It's a nice to have, but there's got to be a
desire to make it happen.
73's
1434
days inactive
1436
days old
8 comments
7 participants
participants (7)
-
Bryan Fields -
Christopher Munz-Michielin -
David Ranch -
Erik Seidel -
Job Snijders -
Q Misell -
Quan Zhou