You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.1

Routing Working Group

Threaded
Collapse

[routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)

User Image

Petrit Hasani

2020-02-20 15:39:26 CET

RIPE NCC staff member

Dear colleagues,

Policy proposal 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space", is now in the Review Phase.

The goal of the proposal is to ask the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control.

The proposal has been updated following the last round of discussion. Version 2 of the proposal includes a specification for the RIPE NCC to create all AS0 ROAs under a specific Trust Anchor.

The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion.

You can find the proposal and impact analysis at:
https://www.ripe.net/participate/policies/proposals/2019-08
https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis

And the draft documents at:
https://www.ripe.net/participate/policies/proposals/2019-08/draft

As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.

At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.

We encourage you to read the proposal, impact analysis and draft document and send any comments to <routing-wg _at_ ripe _dot_ net> before 20 March 2020.

Kind regards,

--
Petrit Hasani
Policy Officer
RIPE NCC





User Image

Jordi Palet Martinez

2020-02-21 04:22:40 CET

Hi Petrit, all,

I support the proposal.

For the information of the WG, this is the way APNIC is also implementing it.

This week in the APNIC meeting, there has been a lot of activity regarding this proposal, which reached consensus there already some time ago, and it is being implemented.

If you want to follow those presentations/discussions, here they are:

1) Policy meeting proposal implementation report:

Video:
https://www.youtube.com/watch?v=yACx-wJV6FA#t=25m

Slides (prop-132 Implementation plan):
https://2020.apricot.net/assets/files/APAE432/prop-132-implementation-plan.pdf

2) I was asked do a short presentation about the status in other RIRs, so this provides a summary of the situation:

Video:
https://www.youtube.com/watch?v=NGm5Ha-T_EY#t=1h19m30s

Slides:
https://2020.apricot.net/assets/files/APAE432/as0-roa-for-bogons-policy-status-in-other-rirs.pdf

Regards,
Jordi
@jordipalet
 
 

El 21/2/20 1:39, "routing-wg en nombre de Petrit Hasani" <routing-wg-bounces _at_ ripe _dot_ net en nombre de phasani _at_ ripe _dot_ net> escribió:

    Dear colleagues,
    
    Policy proposal 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space", is now in the Review Phase.
    
    The goal of the proposal is to ask the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control.
    
    The proposal has been updated following the last round of discussion. Version 2 of the proposal includes a specification for the RIPE NCC to create all AS0 ROAs under a specific Trust Anchor.
    
    The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion.
    
    You can find the proposal and impact analysis at:
    https://www.ripe.net/participate/policies/proposals/2019-08
    https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis
    
    And the draft documents at:
    https://www.ripe.net/participate/policies/proposals/2019-08/draft
    
    As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
    
    At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
    
    We encourage you to read the proposal, impact analysis and draft document and send any comments to <routing-wg _at_ ripe _dot_ net> before 20 March 2020.
    
    Kind regards,
    
    --
    Petrit Hasani
    Policy Officer
    RIPE NCC
    
    
    
    
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.





Job Snijders

2020-02-21 04:53:45 CET

Dear working group,

On Thu, Feb 20, 2020 at 04:39:26PM +0200, Petrit Hasani wrote:
> The goal of the proposal is to ask the RIPE NCC to create ROAs with
> origin AS0 for all unallocated and unassigned address space under its
> control.
> 
> The proposal has been updated following the last round of discussion.
> Version 2 of the proposal includes a specification for the RIPE NCC to
> create all AS0 ROAs under a specific Trust Anchor.
> 
> The RIPE NCC has prepared an impact analysis on this latest proposal
> version to support the community’s discussion.
> 
> You can find the proposal and impact analysis at:
> https://www.ripe.net/participate/policies/proposals/2019-08
> https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis

I oppose the policy proposal. I think this is a Bad Idea [tm].

The cost/benefit analysis seems to show that substantial cost is
involved to achieve what appears to be a very minor benefit at best, and
a great potential for issues down the road. Our community could use that
money for far more rewarding work.

It should also be noted that anyone wishing to reject unallocated and
unassigned address space can easily do so by converting the data
available at https://ftp.ripe.net/pub/stats/ripencc/ into BGP
prefix-filters. There are many ways to suppress the propagation of
routing information related to not-yet-assigned space, using the RPKI
seems far too big of a hammer.

The moment address space is assigned by the RIPE NCC to an end user or
LIR, that entity will be able to create RPKI ROAs (if they wish to do
so) to glean the very same benefits that AS 0 ROAs for unassigned space
would provide up front. But that that point in time it'll be the end
users choice to do so. Shifting that moment forward in time doesn't
seem to have tangible benefits to me.

Nobody has been able to show me that what operational issues arise from
the presence of a handful of unassigned prefixes in the BGP Default-Free
Zone. The numer is so low, the prefixes involved don't really seem to
pop up on threat radars. I asked the same question in APNIC's policy
development community and no answer was provided.

Perhaps a different direction can be taken? One of the authors of
2019-08 experimented with generating a SLURM file based on the list of
unassigned / unallocated address space, which can easily be incorporated
into Origin Validation pipelines. I'm in support of modifying the
proposal to not instantiate a new TAL, but rather have the RIPE NCC
publish a SLURM [RFC 8416] file. This approach would yield the exact
same results at a much lower cost.

Kind regards,

Job

George Michaelson

2020-02-21 05:03:42 CET

For your information, we are producing a SLURM file as part of our
implementation. This is noted in the slides.

Purely as an informational and with no intent to otherwise engage in
your policy proposal process, It has been my intention to bring our
implementation report to the RIPE meeting in Berlin and present it in
the routing WG.

Please let me know if this would be useful or interesting, or is not helpful.

-George

On Fri, Feb 21, 2020 at 2:54 PM Job Snijders <job _at_ ntt _dot_ net> wrote:
>
> Dear working group,
>
> On Thu, Feb 20, 2020 at 04:39:26PM +0200, Petrit Hasani wrote:
> > The goal of the proposal is to ask the RIPE NCC to create ROAs with
> > origin AS0 for all unallocated and unassigned address space under its
> > control.
> >
> > The proposal has been updated following the last round of discussion.
> > Version 2 of the proposal includes a specification for the RIPE NCC to
> > create all AS0 ROAs under a specific Trust Anchor.
> >
> > The RIPE NCC has prepared an impact analysis on this latest proposal
> > version to support the community’s discussion.
> >
> > You can find the proposal and impact analysis at:
> > https://www.ripe.net/participate/policies/proposals/2019-08
> > https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis
>
> I oppose the policy proposal. I think this is a Bad Idea [tm].
>
> The cost/benefit analysis seems to show that substantial cost is
> involved to achieve what appears to be a very minor benefit at best, and
> a great potential for issues down the road. Our community could use that
> money for far more rewarding work.
>
> It should also be noted that anyone wishing to reject unallocated and
> unassigned address space can easily do so by converting the data
> available at https://ftp.ripe.net/pub/stats/ripencc/ into BGP
> prefix-filters. There are many ways to suppress the propagation of
> routing information related to not-yet-assigned space, using the RPKI
> seems far too big of a hammer.
>
> The moment address space is assigned by the RIPE NCC to an end user or
> LIR, that entity will be able to create RPKI ROAs (if they wish to do
> so) to glean the very same benefits that AS 0 ROAs for unassigned space
> would provide up front. But that that point in time it'll be the end
> users choice to do so. Shifting that moment forward in time doesn't
> seem to have tangible benefits to me.
>
> Nobody has been able to show me that what operational issues arise from
> the presence of a handful of unassigned prefixes in the BGP Default-Free
> Zone. The numer is so low, the prefixes involved don't really seem to
> pop up on threat radars. I asked the same question in APNIC's policy
> development community and no answer was provided.
>
> Perhaps a different direction can be taken? One of the authors of
> 2019-08 experimented with generating a SLURM file based on the list of
> unassigned / unallocated address space, which can easily be incorporated
> into Origin Validation pipelines. I'm in support of modifying the
> proposal to not instantiate a new TAL, but rather have the RIPE NCC
> publish a SLURM [RFC 8416] file. This approach would yield the exact
> same results at a much lower cost.
>
> Kind regards,
>
> Job
>

Job Snijders

2020-02-21 05:13:24 CET

On Fri, Feb 21, 2020 at 03:03:42PM +1100, George Michaelson wrote:
> For your information, we are producing a SLURM file as part of our
> implementation. This is noted in the slides.
> 
> Purely as an informational and with no intent to otherwise engage in
> your policy proposal process, It has been my intention to bring our
> implementation report to the RIPE meeting in Berlin and present it in
> the routing WG.
> 
> Please let me know if this would be useful or interesting, or is not
> helpful.



Consider your request noted. Please submit slides! :-)

Kind regards,

Job

User Image

Carlos Friacas

2020-02-21 09:55:18 CET


Hi Job, Petrit, All,
(please see inline)


On Fri, 21 Feb 2020, Job Snijders wrote:

> Dear working group,
>
> On Thu, Feb 20, 2020 at 04:39:26PM +0200, Petrit Hasani wrote:
>> The goal of the proposal is to ask the RIPE NCC to create ROAs with
>> origin AS0 for all unallocated and unassigned address space under its
>> control.
>>
>> The proposal has been updated following the last round of discussion.
>> Version 2 of the proposal includes a specification for the RIPE NCC to
>> create all AS0 ROAs under a specific Trust Anchor.
>>
>> The RIPE NCC has prepared an impact analysis on this latest proposal
>> version to support the community?s discussion.
>>
>> You can find the proposal and impact analysis at:
>> https://www.ripe.net/participate/policies/proposals/2019-08
>> https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis
>
> I oppose the policy proposal. I think this is a Bad Idea [tm].
>
> The cost/benefit analysis seems to show that substantial cost is
> involved to achieve what appears to be a very minor benefit at best, and
> a great potential for issues down the road.

Which issues exactly do you have in mind?



> Our community could use that money for far more rewarding work.

Such as...?



> It should also be noted that anyone wishing to reject unallocated and
> unassigned address space can easily do so by converting the data
> available at https://ftp.ripe.net/pub/stats/ripencc/ into BGP
> prefix-filters.

Yes, it's possible, but not as practical as having it embedded in RPKI 
-- some may think.



> There are many ways to suppress the propagation of
> routing information related to not-yet-assigned space, using the RPKI
> seems far too big of a hammer.

It improves RPKI usage, imho, though.



> The moment address space is assigned by the RIPE NCC to an end user or
> LIR, that entity will be able to create RPKI ROAs (if they wish to do
> so) to glean the very same benefits that AS 0 ROAs for unassigned space
> would provide up front. But that that point in time it'll be the end
> users choice to do so. Shifting that moment forward in time doesn't
> seem to have tangible benefits to me.

I do see a significant benefit in marking invalids as "INVALID" instead 
of "UNKNOWN".



> Nobody has been able to show me that what operational issues arise from
> the presence of a handful of unassigned prefixes in the BGP Default-Free
> Zone.

...and over peerings/IXs.



> The numer is so low, the prefixes involved don't really seem to
> pop up on threat radars.

Prefixes (especially those which were not legitimately allocated) can come 
and go, once they have served their purpose........


> I asked the same question in APNIC's policy development community and no 
> answer was provided.

Maybe not the best audience to ask about what's on threat radars?


> Perhaps a different direction can be taken? One of the authors of
> 2019-08 experimented with generating a SLURM file based on the list of
> unassigned / unallocated address space, which can easily be incorporated
> into Origin Validation pipelines. I'm in support of modifying the
> proposal to not instantiate a new TAL, but rather have the RIPE NCC
> publish a SLURM [RFC 8416] file. This approach would yield the exact
> same results at a much lower cost.

That would mitigate the "will have to duplicate the entire current RPKI 
infrastructure..." phrase on the impact analysis, right? :-)


I do support 2019-08 as it is, but i can easily support a version 3 with 
the above suggestion.


Cheers,
Carlos


> Kind regards,
>
> Job
>

Nick Hilliard

2020-02-21 14:45:15 CET

Petrit Hasani wrote on 20/02/2020 14:39:
> The goal of the proposal is to ask the RIPE NCC to create ROAs with
> origin AS0 for all unallocated and unassigned address space under its
> control.

There is one of proposals which is likely to cause political splash 
damage. I don't think it should go ahead.

Nick


User Image

Erik Bais

2020-02-22 17:13:29 CET

I agree with Job Snijders his remarks on this ML on the topic.  

I don't think this is a good way forward. Please keep the RIPE NCC away from injecting invalids into the RPKI system. 

I applaud the authors for their work, but I don't think that the downside, cost projection and possible future scope creep is worth going down this rabbit hole.  

I oppose this policy. 

regards,
Erik Bais 

On 20/02/2020, 15:40, "routing-wg on behalf of Petrit Hasani" <routing-wg-bounces _at_ ripe _dot_ net on behalf of phasani _at_ ripe _dot_ net> wrote:

    Dear colleagues,
    
    Policy proposal 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space", is now in the Review Phase.
    
    The goal of the proposal is to ask the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control.
    
    The proposal has been updated following the last round of discussion. Version 2 of the proposal includes a specification for the RIPE NCC to create all AS0 ROAs under a specific Trust Anchor.
    
    The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion.
    
    You can find the proposal and impact analysis at:
    https://www.ripe.net/participate/policies/proposals/2019-08
    https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis
    
    And the draft documents at:
    https://www.ripe.net/participate/policies/proposals/2019-08/draft
    
    As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
    
    At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
    
    We encourage you to read the proposal, impact analysis and draft document and send any comments to <routing-wg _at_ ripe _dot_ net> before 20 March 2020.
    
    Kind regards,
    
    --
    Petrit Hasani
    Policy Officer
    RIPE NCC
    
    
    
    
    
    

User Image

Jordi Palet Martinez

2020-02-23 14:06:55 CET

Hi Erik,

I don't think is objective to say that the proposal as asking the NCC to "inject" invalids.

The proposal is providing the information of the invalids (in this case unallocated/unassigned) by means of RPKI.

Furthermore, because this is done via a specific TAL, operators can choose to use it or not.

Regards,
Jordi
@jordipalet
 
 

El 22/2/20 17:13, "routing-wg en nombre de Erik Bais" <routing-wg-bounces _at_ ripe _dot_ net en nombre de ebais _at_ a2b-internet _dot_ com> escribió:

    I agree with Job Snijders his remarks on this ML on the topic.  
    
    I don't think this is a good way forward. Please keep the RIPE NCC away from injecting invalids into the RPKI system. 
    
    I applaud the authors for their work, but I don't think that the downside, cost projection and possible future scope creep is worth going down this rabbit hole.  
    
    I oppose this policy. 
    
    regards,
    Erik Bais 
    
    On 20/02/2020, 15:40, "routing-wg on behalf of Petrit Hasani" <routing-wg-bounces _at_ ripe _dot_ net on behalf of phasani _at_ ripe _dot_ net> wrote:
    
        Dear colleagues,
        
        Policy proposal 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space", is now in the Review Phase.
        
        The goal of the proposal is to ask the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control.
        
        The proposal has been updated following the last round of discussion. Version 2 of the proposal includes a specification for the RIPE NCC to create all AS0 ROAs under a specific Trust Anchor.
        
        The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion.
        
        You can find the proposal and impact analysis at:
        https://www.ripe.net/participate/policies/proposals/2019-08
        https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis
        
        And the draft documents at:
        https://www.ripe.net/participate/policies/proposals/2019-08/draft
        
        As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
        
        At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
        
        We encourage you to read the proposal, impact analysis and draft document and send any comments to <routing-wg _at_ ripe _dot_ net> before 20 March 2020.
        
        Kind regards,
        
        --
        Petrit Hasani
        Policy Officer
        RIPE NCC
        
        
        
        
        
        
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.





Nick Hilliard

2020-02-23 14:45:34 CET

JORDI PALET MARTINEZ via routing-wg wrote on 23/02/2020 13:06:
> I don't think is objective to say that the proposal as asking the NCC
> to "inject" invalids.
> 
> The proposal is providing the information of the invalids (in this
> case unallocated/unassigned) by means of RPKI.

Jordi,

You're splitting hairs here.  The end result is the same.

Nick

User Image

Jordi Palet Martinez

2020-02-23 14:51:22 CET

I don't think is the same, because some people may read it as "the NCC" is forcing us to do some routing thing, which is not the case.


El 23/2/20 14:46, "routing-wg en nombre de Nick Hilliard" <routing-wg-bounces _at_ ripe _dot_ net en nombre de nick _at_ foobar _dot_ org> escribió:

    JORDI PALET MARTINEZ via routing-wg wrote on 23/02/2020 13:06:
    > I don't think is objective to say that the proposal as asking the NCC
    > to "inject" invalids.
    > 
    > The proposal is providing the information of the invalids (in this
    > case unallocated/unassigned) by means of RPKI.
    
    Jordi,
    
    You're splitting hairs here.  The end result is the same.
    
    Nick
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.





User Image

Hank Nussbacher

2020-02-23 14:59:16 CET

On 20/02/2020 16:39, Petrit Hasani wrote:

I support this proposal.  Should have been done a long time ago.

Regards,
Hank

> Dear colleagues,
>
> Policy proposal 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space", is now in the Review Phase.
>
> The goal of the proposal is to ask the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control.
>
> The proposal has been updated following the last round of discussion. Version 2 of the proposal includes a specification for the RIPE NCC to create all AS0 ROAs under a specific Trust Anchor.
>
> The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion.
>
> You can find the proposal and impact analysis at:
> https://www.ripe.net/participate/policies/proposals/2019-08
> https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis
>
> And the draft documents at:
> https://www.ripe.net/participate/policies/proposals/2019-08/draft
>
> As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
>
> At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
>
> We encourage you to read the proposal, impact analysis and draft document and send any comments to <routing-wg _at_ ripe _dot_ net> before 20 March 2020.
>
> Kind regards,
>
> --
> Petrit Hasani
> Policy Officer
> RIPE NCC
>
>
>
>
>


User Image

Jared Mauch

2020-02-23 15:17:07 CET


> On Feb 23, 2020, at 8:45 AM, Nick Hilliard <nick _at_ foobar _dot_ org> wrote:
> 
> JORDI PALET MARTINEZ via routing-wg wrote on 23/02/2020 13:06:
>> I don't think is objective to say that the proposal as asking the NCC
>> to "inject" invalids.
>> The proposal is providing the information of the invalids (in this
>> case unallocated/unassigned) by means of RPKI.
> 
> Jordi,
> 
> You're splitting hairs here.  The end result is the same.

I’m cornered about something like this as we’ve been down this road before with bogon lists, etc and even though it’s well intentioned by smart people(tm), the distributed legacy and cleanup has often taken years to recover.

- Jared
User Image

Roufique Hossain

2020-02-23 16:01:05 CET

Hi

On Sun, Feb 23, 2020, 9:17 AM Jared Mauch <jared _at_ puck.nether _dot_ net> wrote:

>
>
> > On Feb 23, 2020, at 8:45 AM, Nick Hilliard <nick _at_ foobar _dot_ org> wrote:
> >
> > JORDI PALET MARTINEZ via routing-wg wrote on 23/02/2020 13:06:
> >> I don't think is objective to say that the proposal as asking the NCC
> >> to "inject" invalids.
> >> The proposal is providing the information of the invalids (in this
> >> case unallocated/unassigned) by means of RPKI.
> >
> > Jordi,
> >
> > You're splitting hairs here.  The end result is the same.
>
> I’m cornered about something like this as we’ve been down this road before
> with bogon lists, etc and even though it’s well intentioned by smart
> people(tm), the distributed legacy and cleanup has often taken years to
> recover.
>
> - Jared
>
User Image

Randy Bush

2020-02-24 01:10:36 CET

> I don't think is objective to say that the proposal as asking the NCC
> to "inject" invalids.
> 
> The proposal is providing the information of the invalids (in this
> case unallocated/unassigned) by means of RPKI.

ok.  i was kind of on the fence.  but american press has made me
oversensitive to fake language such as this; so it threw me over the
edge.  i do not support the proposal.

randy

User Image

Massimiliano Stucchi

2020-02-25 20:30:21 CET

Hi everyone,

On 20/02/2020 15:39, Petrit Hasani wrote:

> As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
> 
> At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.

Today, me and the other proposers of this policy change had a meeting to
discuss the feedback we have been receiving on the list.

We understand that many people find this proposal controversial, and
many have expressed themselves against it in the past days.

We would like to encourage discussion and provide us with a bit of
guidance on how the community would like to proceed.  At present we have
identified three ways of progressing:

A) We can try to go ahead with this proposal, although it will be hard
to get consensus;

B) We can drop the proposal, and leave everything as is;

C) We can change the proposal to a different ask for RIPE NCC.  The idea
could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC
does), so that single users can decide if they want to feed it to their
validators.

From what we gathered in the discussions, I think B) could be the most
sought-after decision, but we would like to propose C) as the way
forward.  It would give the possibility to those who want to implement
this solution to do it in a lightweight fashion.  It would for sure be
much much cheaper to implement.

In any case, as Job already pointed out, I prepared a simple tool to
generate a SLURM file using either the Team Cymru bogons list, or
considering any unassigned space from the NRO delegated stats file.
RIPE NCC has kindly provided help and patches to improve it.  If you
want to give it a go, you can find it here:

https://github.com/stucchimax/rpki-as0-bogons

Thank you for any suggestion or any discussion around this.

Ciao!
-- 
Massimiliano Stucchi
MS16801-RIPE
Twitter/Telegram: @stucchimax

George Michaelson

2020-02-26 07:27:06 CET

If people would like to look at an AS0 state,

APNIC's AS0 testbed TAL:

https://registry-testbed.apnic.net/as0-test-ta.tal

APNIC's AS0 testbed SLURM file:

https://registry-testbed.apnic.net/as0-test-slurm.json

~3500 objects, we do not publish one ROA per prefix to avoid a large
object set, we do not publish one ROA for all AS0 to avoid a single
large object parsing burden.

~65000 prefixes, because of sparse V6 allocation outcomes fragmenting
the allocattion spaces.

User Image

Jordi Palet Martinez

2020-02-26 08:47:31 CET

Hi Max,

I think is too early to take a decision, and in fact I don't think we are yet in case A.

Consensus is about justified objections. I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent.

The only justification that I can see is from Job about possible cost. However, I don't see figures about how much it cost to develop this AS0 + how much it cost the operators to use it (if they want) vs developing the SLURM + making sure it is secure as RPKI + how much ti cost the operators to use it.

And by the way, the AS0 is compatible with the SLURM, so opeartors can choose.

Regards,
Jordi
@jordipalet
 
 

El 25/2/20 20:30, "routing-wg en nombre de Massimiliano Stucchi" <routing-wg-bounces _at_ ripe _dot_ net en nombre de max _at_ stucchi _dot_ ch> escribió:

    
    Hi everyone,
    
    On 20/02/2020 15:39, Petrit Hasani wrote:
    
    > As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
    > 
    > At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
    
    Today, me and the other proposers of this policy change had a meeting to
    discuss the feedback we have been receiving on the list.
    
    We understand that many people find this proposal controversial, and
    many have expressed themselves against it in the past days.
    
    We would like to encourage discussion and provide us with a bit of
    guidance on how the community would like to proceed.  At present we have
    identified three ways of progressing:
    
    A) We can try to go ahead with this proposal, although it will be hard
    to get consensus;
    
    B) We can drop the proposal, and leave everything as is;
    
    C) We can change the proposal to a different ask for RIPE NCC.  The idea
    could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC
    does), so that single users can decide if they want to feed it to their
    validators.
    
    From what we gathered in the discussions, I think B) could be the most
    sought-after decision, but we would like to propose C) as the way
    forward.  It would give the possibility to those who want to implement
    this solution to do it in a lightweight fashion.  It would for sure be
    much much cheaper to implement.
    
    In any case, as Job already pointed out, I prepared a simple tool to
    generate a SLURM file using either the Team Cymru bogons list, or
    considering any unassigned space from the NRO delegated stats file.
    RIPE NCC has kindly provided help and patches to improve it.  If you
    want to give it a go, you can find it here:
    
    https://github.com/stucchimax/rpki-as0-bogons
    
    Thank you for any suggestion or any discussion around this.
    
    Ciao!
    -- 
    Massimiliano Stucchi
    MS16801-RIPE
    Twitter/Telegram: @stucchimax
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.





User Image

Carlos Friacas

2020-02-26 09:18:19 CET

Hi,

Any clue if APNIC has duplicated the infrastructure (and cost) as it is
foreseen in the NCC's impact analysis...?

Carlos



On Wed, 26 Feb 2020, JORDI PALET MARTINEZ via routing-wg wrote:

> Hi Max,
>
> I think is too early to take a decision, and in fact I don't think we are yet in case A.
>
> Consensus is about justified objections. I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent.
>
> The only justification that I can see is from Job about possible cost. However, I don't see figures about how much it cost to develop this AS0 + how much it cost the operators to use it (if they want) vs developing the SLURM + making sure it is secure as RPKI + how much ti cost the operators to use it.
>
> And by the way, the AS0 is compatible with the SLURM, so opeartors can choose.
>
> Regards,
> Jordi
> @jordipalet
>
>
>
> El 25/2/20 20:30, "routing-wg en nombre de Massimiliano Stucchi" <routing-wg-bounces _at_ ripe _dot_ net en nombre de max _at_ stucchi _dot_ ch> escribió:
>
>
>    Hi everyone,
>
>    On 20/02/2020 15:39, Petrit Hasani wrote:
>
>    > As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
>    >
>    > At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
>
>    Today, me and the other proposers of this policy change had a meeting to
>    discuss the feedback we have been receiving on the list.
>
>    We understand that many people find this proposal controversial, and
>    many have expressed themselves against it in the past days.
>
>    We would like to encourage discussion and provide us with a bit of
>    guidance on how the community would like to proceed.  At present we have
>    identified three ways of progressing:
>
>    A) We can try to go ahead with this proposal, although it will be hard
>    to get consensus;
>
>    B) We can drop the proposal, and leave everything as is;
>
>    C) We can change the proposal to a different ask for RIPE NCC.  The idea
>    could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC
>    does), so that single users can decide if they want to feed it to their
>    validators.
>
>    From what we gathered in the discussions, I think B) could be the most
>    sought-after decision, but we would like to propose C) as the way
>    forward.  It would give the possibility to those who want to implement
>    this solution to do it in a lightweight fashion.  It would for sure be
>    much much cheaper to implement.
>
>    In any case, as Job already pointed out, I prepared a simple tool to
>    generate a SLURM file using either the Team Cymru bogons list, or
>    considering any unassigned space from the NRO delegated stats file.
>    RIPE NCC has kindly provided help and patches to improve it.  If you
>    want to give it a go, you can find it here:
>
>    https://github.com/stucchimax/rpki-as0-bogons
>
>    Thank you for any suggestion or any discussion around this.
>
>    Ciao!
>    --
>    Massimiliano Stucchi
>    MS16801-RIPE
>    Twitter/Telegram: @stucchimax
>
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>
>
>
>
>
User Image

Jordi Palet Martinez

2020-02-26 09:25:49 CET

In my email the other day, I provided the links to the recent presentation, here is it again:

Video:
https://www.youtube.com/watch?v=yACx-wJV6FA#t=25m

Slides (prop-132 Implementation plan):
https://2020.apricot.net/assets/files/APAE432/prop-132-implementation-plan.pdf

I recall George mention about low cost, but is only from top of my head. I suggest to look at the video and slides, and probably George can tell something else :-) if they already have more data. I'm guessing that the same infrastructure can handle it and if you increase the infrastructure it can be done in such way that has the advantage to make more resilient the existing one, so it is about the existing RPKI service also.

Of course, some development, but I don't think it is that much.

Regards,
Jordi
@jordipalet
 
 

El 26/2/20 9:18, "routing-wg en nombre de Carlos Friaças via routing-wg" <routing-wg-bounces _at_ ripe _dot_ net en nombre de routing-wg _at_ ripe _dot_ net> escribió:

    
    Hi,
    
    Any clue if APNIC has duplicated the infrastructure (and cost) as it is
    foreseen in the NCC's impact analysis...?
    
    Carlos
    
    
    
    On Wed, 26 Feb 2020, JORDI PALET MARTINEZ via routing-wg wrote:
    
    > Hi Max,
    >
    > I think is too early to take a decision, and in fact I don't think we are yet in case A.
    >
    > Consensus is about justified objections. I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent.
    >
    > The only justification that I can see is from Job about possible cost. However, I don't see figures about how much it cost to develop this AS0 + how much it cost the operators to use it (if they want) vs developing the SLURM + making sure it is secure as RPKI + how much ti cost the operators to use it.
    >
    > And by the way, the AS0 is compatible with the SLURM, so opeartors can choose.
    >
    > Regards,
    > Jordi
    > @jordipalet
    >
    >
    >
    > El 25/2/20 20:30, "routing-wg en nombre de Massimiliano Stucchi" <routing-wg-bounces _at_ ripe _dot_ net en nombre de max _at_ stucchi _dot_ ch> escribió:
    >
    >
    >    Hi everyone,
    >
    >    On 20/02/2020 15:39, Petrit Hasani wrote:
    >
    >    > As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
    >    >
    >    > At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
    >
    >    Today, me and the other proposers of this policy change had a meeting to
    >    discuss the feedback we have been receiving on the list.
    >
    >    We understand that many people find this proposal controversial, and
    >    many have expressed themselves against it in the past days.
    >
    >    We would like to encourage discussion and provide us with a bit of
    >    guidance on how the community would like to proceed.  At present we have
    >    identified three ways of progressing:
    >
    >    A) We can try to go ahead with this proposal, although it will be hard
    >    to get consensus;
    >
    >    B) We can drop the proposal, and leave everything as is;
    >
    >    C) We can change the proposal to a different ask for RIPE NCC.  The idea
    >    could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC
    >    does), so that single users can decide if they want to feed it to their
    >    validators.
    >
    >    From what we gathered in the discussions, I think B) could be the most
    >    sought-after decision, but we would like to propose C) as the way
    >    forward.  It would give the possibility to those who want to implement
    >    this solution to do it in a lightweight fashion.  It would for sure be
    >    much much cheaper to implement.
    >
    >    In any case, as Job already pointed out, I prepared a simple tool to
    >    generate a SLURM file using either the Team Cymru bogons list, or
    >    considering any unassigned space from the NRO delegated stats file.
    >    RIPE NCC has kindly provided help and patches to improve it.  If you
    >    want to give it a go, you can find it here:
    >
    >    https://github.com/stucchimax/rpki-as0-bogons
    >
    >    Thank you for any suggestion or any discussion around this.
    >
    >    Ciao!
    >    --
    >    Massimiliano Stucchi
    >    MS16801-RIPE
    >    Twitter/Telegram: @stucchimax
    >
    >
    >
    >
    >
    > **********************************************
    > IPv4 is over
    > Are you ready for the new Internet ?
    > http://www.theipv6company.com
    > The IPv6 Company
    >
    > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
    >
    >
    >
    >
    >



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.





User Image

Gert Doering

2020-02-26 18:12:53 CET

Hi,

On Wed, Feb 26, 2020 at 08:47:31AM +0100, JORDI PALET MARTINEZ via routing-wg wrote:
> I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent.

This assertion is not correct per RIPE PDP rules, except in last call.

Gert Doering
        -- who happens to judge consensus every now and then.
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
User Image

Jordi Palet Martinez

2020-02-26 18:37:58 CET

Hi Gert,

Unfortunately, our PDP doesn't have any definition of consensus (I was miss-recalling a reference to the relevant RFC about "rough consensus") and after re-reading again several times our PDP (RIPE-710).

However, in the discussion phase, it is explicitly called for "rough consensus", same in the following phases.

What it is clear in any case, is that all the objections must be justified.

According to that, I still think that having 10 or 100 (just an example) "no", only count if each one clearly justified (and not refuted by authors or the community), and is still consensus even if you have only a couple of "yes".

Regards,
Jordi
@jordipalet
 
 

El 26/2/20 18:13, "routing-wg en nombre de Gert Doering" <routing-wg-bounces _at_ ripe _dot_ net en nombre de gert _at_ space _dot_ net> escribió:

    Hi,
    
    On Wed, Feb 26, 2020 at 08:47:31AM +0100, JORDI PALET MARTINEZ via routing-wg wrote:
    > I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent.
    
    This assertion is not correct per RIPE PDP rules, except in last call.
    
    Gert Doering
            -- who happens to judge consensus every now and then.
    -- 
    have you enabled IPv6 on something today...?
    
    SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
    Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
    D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
    Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.





George Michaelson

2020-02-26 23:33:26 CET

At this time, no. we have not. We have joined RIPE in the exploration
of RPKI resiliency but so far it has been a joint legal review of the
CPS (still underway) and discussions about the RIPE model. I have been
trying to promote resiliency in public visibility of RPKI products,
which is long-hand for "deploy RRDP to a CDN" which in fact other RIR
do. This cooperation was actively promoted by the RIPE and APNIC EC as
I understand it, and so far has been very beneficial if also
lightweight.

Duplicate HSM is a very high cost burden. I am not saying its wrong or
inappropriate, I am only saying that it needs to be understood for its
risk/return benefits. It goes almost completely to risk/consequence
side, we don't have enough signing events high in the root that the
volume needs duplication. We do have backup keystore for the TA, and
we do have spare parts policy and alternate HSM we can consider
cold-backup. Full duplication hasn't been architected.

I agree that for what we are discussing, and what RIPE are exploring,
it has a very strong case. As do various M of N procedures, and (with
some reluctance because of past statements) TCR type public visibility
of some functional acts on the HSM.

-G

On Wed, Feb 26, 2020 at 6:18 PM Carlos Friaças via routing-wg
<routing-wg _at_ ripe _dot_ net> wrote:
>
>
> Hi,
>
> Any clue if APNIC has duplicated the infrastructure (and cost) as it is
> foreseen in the NCC's impact analysis...?
>
> Carlos
>
>
>
> On Wed, 26 Feb 2020, JORDI PALET MARTINEZ via routing-wg wrote:
>
> > Hi Max,
> >
> > I think is too early to take a decision, and in fact I don't think we are yet in case A.
> >
> > Consensus is about justified objections. I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent.
> >
> > The only justification that I can see is from Job about possible cost. However, I don't see figures about how much it cost to develop this AS0 + how much it cost the operators to use it (if they want) vs developing the SLURM + making sure it is secure as RPKI + how much ti cost the operators to use it.
> >
> > And by the way, the AS0 is compatible with the SLURM, so opeartors can choose.
> >
> > Regards,
> > Jordi
> > @jordipalet
> >
> >
> >
> > El 25/2/20 20:30, "routing-wg en nombre de Massimiliano Stucchi" <routing-wg-bounces _at_ ripe _dot_ net en nombre de max _at_ stucchi _dot_ ch> escribió:
> >
> >
> >    Hi everyone,
> >
> >    On 20/02/2020 15:39, Petrit Hasani wrote:
> >
> >    > As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
> >    >
> >    > At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
> >
> >    Today, me and the other proposers of this policy change had a meeting to
> >    discuss the feedback we have been receiving on the list.
> >
> >    We understand that many people find this proposal controversial, and
> >    many have expressed themselves against it in the past days.
> >
> >    We would like to encourage discussion and provide us with a bit of
> >    guidance on how the community would like to proceed.  At present we have
> >    identified three ways of progressing:
> >
> >    A) We can try to go ahead with this proposal, although it will be hard
> >    to get consensus;
> >
> >    B) We can drop the proposal, and leave everything as is;
> >
> >    C) We can change the proposal to a different ask for RIPE NCC.  The idea
> >    could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC
> >    does), so that single users can decide if they want to feed it to their
> >    validators.
> >
> >    From what we gathered in the discussions, I think B) could be the most
> >    sought-after decision, but we would like to propose C) as the way
> >    forward.  It would give the possibility to those who want to implement
> >    this solution to do it in a lightweight fashion.  It would for sure be
> >    much much cheaper to implement.
> >
> >    In any case, as Job already pointed out, I prepared a simple tool to
> >    generate a SLURM file using either the Team Cymru bogons list, or
> >    considering any unassigned space from the NRO delegated stats file.
> >    RIPE NCC has kindly provided help and patches to improve it.  If you
> >    want to give it a go, you can find it here:
> >
> >    https://github.com/stucchimax/rpki-as0-bogons
> >
> >    Thank you for any suggestion or any discussion around this.
> >
> >    Ciao!
> >    --
> >    Massimiliano Stucchi
> >    MS16801-RIPE
> >    Twitter/Telegram: @stucchimax
> >
> >
> >
> >
> >
> > **********************************************
> > IPv4 is over
> > Are you ready for the new Internet ?
> > http://www.theipv6company.com
> > The IPv6 Company
> >
> > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> >
> >
> >
> >
> >

George Michaelson

2020-02-27 23:51:01 CET

Anton pointed out I may have both misunderstood and not answered your question.

The testbed is a soft TA. In deployment, people will have to move to a
new (as yet not created) TAL for AS0, as long as it runs independently
of the mainline TAL.

We intend running a distinct TA for AS0 until we get a clear signal
our community wants it integrated. We have stated concerns about the
automatic adoption of ASO products worldwide without visible agreement
of this activity, a separate TAL turns the activity from opt-out to
opt-in.

We are duplicating the software signing infrastructure, but with lower
costs overall given commonalities.

We are still discussing if we can run the offline-TA HSM and the
online production key HSM for both activities, or if we need a
distinct infrastructure for AS0 and mainline. Duplication overall is
not in APNIC's model, we rely on spares and alternate use of the HSM,
but production signing systems are single instances. I believe they
are capable of some virtualisation or segmentation but that skirts the
underlying physical risk/dependency.

Sorry for not being clearer before

-George

On Wed, Feb 26, 2020 at 6:18 PM Carlos Friaças via routing-wg
<routing-wg _at_ ripe _dot_ net> wrote:
>
>
> Hi,
>
> Any clue if APNIC has duplicated the infrastructure (and cost) as it is
> foreseen in the NCC's impact analysis...?
>
> Carlos
>
>
>
> On Wed, 26 Feb 2020, JORDI PALET MARTINEZ via routing-wg wrote:
>
> > Hi Max,
> >
> > I think is too early to take a decision, and in fact I don't think we are yet in case A.
> >
> > Consensus is about justified objections. I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent.
> >
> > The only justification that I can see is from Job about possible cost. However, I don't see figures about how much it cost to develop this AS0 + how much it cost the operators to use it (if they want) vs developing the SLURM + making sure it is secure as RPKI + how much ti cost the operators to use it.
> >
> > And by the way, the AS0 is compatible with the SLURM, so opeartors can choose.
> >
> > Regards,
> > Jordi
> > @jordipalet
> >
> >
> >
> > El 25/2/20 20:30, "routing-wg en nombre de Massimiliano Stucchi" <routing-wg-bounces _at_ ripe _dot_ net en nombre de max _at_ stucchi _dot_ ch> escribió:
> >
> >
> >    Hi everyone,
> >
> >    On 20/02/2020 15:39, Petrit Hasani wrote:
> >
> >    > As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
> >    >
> >    > At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
> >
> >    Today, me and the other proposers of this policy change had a meeting to
> >    discuss the feedback we have been receiving on the list.
> >
> >    We understand that many people find this proposal controversial, and
> >    many have expressed themselves against it in the past days.
> >
> >    We would like to encourage discussion and provide us with a bit of
> >    guidance on how the community would like to proceed.  At present we have
> >    identified three ways of progressing:
> >
> >    A) We can try to go ahead with this proposal, although it will be hard
> >    to get consensus;
> >
> >    B) We can drop the proposal, and leave everything as is;
> >
> >    C) We can change the proposal to a different ask for RIPE NCC.  The idea
> >    could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC
> >    does), so that single users can decide if they want to feed it to their
> >    validators.
> >
> >    From what we gathered in the discussions, I think B) could be the most
> >    sought-after decision, but we would like to propose C) as the way
> >    forward.  It would give the possibility to those who want to implement
> >    this solution to do it in a lightweight fashion.  It would for sure be
> >    much much cheaper to implement.
> >
> >    In any case, as Job already pointed out, I prepared a simple tool to
> >    generate a SLURM file using either the Team Cymru bogons list, or
> >    considering any unassigned space from the NRO delegated stats file.
> >    RIPE NCC has kindly provided help and patches to improve it.  If you
> >    want to give it a go, you can find it here:
> >
> >    https://github.com/stucchimax/rpki-as0-bogons
> >
> >    Thank you for any suggestion or any discussion around this.
> >
> >    Ciao!
> >    --
> >    Massimiliano Stucchi
> >    MS16801-RIPE
> >    Twitter/Telegram: @stucchimax
> >
> >
> >
> >
> >
> > **********************************************
> > IPv4 is over
> > Are you ready for the new Internet ?
> > http://www.theipv6company.com
> > The IPv6 Company
> >
> > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> >
> >
> >
> >
> >

Thiago da Cruz

2020-03-02 11:11:25 CET

RIPE NCC staff member

Hi all,

Many of you might not know me, but I’m part of RIPE’s software engineering team that takes care of RPKI.

I’ve been following this discussion closely and I've noticed some lack of clarity about our decision to duplicate our RPKI infrastructure.
So I think it’s important for us to tell a few things about our approach. 

First what we have today in production:
- TA software (offline box)
- HSM for the TA (plus backups and spare parts)
- A few application servers running our RPKI software - I’ll call it RPKI-Core
- Redundant HSMs used by RPKI-Core
- RRDP publication service (cloud)
- Some rsync nodes (internal infra)

Something like the diagram below.

For testing environment we have practically the same infra. 
And for public test (localcert) we use ‘soft' keys and no HSMs.


About the new AS0 TA, yes, we could simplify our infra.
One option would be to use ‘soft’ keys all around or use a HSM for TA only.
We could also use third-party software for TA, Core and publication service.
It crossed my mind, for a fraction of a second, to skip AS0 TA instances for our internal and/or public test environments.

But I don’t think we should treat it as a "second class citizen".   
If we provide another TA, it’s worthy of receiving as much TLC as our production TA; meaning that it would also require the same (or similar) process around it as our production TA does. That includes keeping track of HSM card holders, defining a proper admin and operator quorum, scheduling periodical resigning sessions, etc…

I’m not here to advocate against nor in favour of AS0 TA. 
But when discussing our implementation, this was our rationale to duplicate the infrastructure. 
And that’s why it would cost us a lot to implement it. 

Let me know you need more info about this subject.

Kind regards, 
Thiago da Cruz 
Sr. software engineer - RPKI Team
RIPE NCC


            +---------------------+
            |                     |            +-------+
            |    TA (offline)     +------------+  HSM  |
            |                     |            +-------+
            +---------------------+




                                                                                                            +------------------------+
                                                                                                            |                        |
                                                                                             +----------->  |    RRDP publication    |
                                                                                             |              |                        |
                                                                                             |              |        (cloud)         |
                                                                                             |              |                        |
     +-------------------+             +-------------------+                                 |              +------------------------+
     |                   |             |                   |          Publication            |
     |    RPKI-Core 1    |    (...)    |    RPKI-Core n    |     ---------------------->  * +>
     |                   |             |                   |                                 |
     +--+-----+----+-----+             +--+------+-------+-+                                 |              +----------------------------+
        |     |    |                      |      |       |                                   |              |                            |
        |     |    +---------------+      |      |       |                                   |              |    Rsync publication       |
        |     |                    |      |      |       +----+                              +----------->  |                            |
  +-----+     +-----------+     +---------+      |            |                                             | (internal infra - x nodes) |
  |                       |     |  |             |            |                                             |                            |
  |                       |     |  +-------------------+      |                                             |                            |
  |    +-----------------------------------------+     |      |                                             +----------------------------+
  |    |                  |     |                      |      |
+-+----+--+               +     +                    +-+------++
|  HSM 1  |         (......................)         |  HSM m  |
+---------+                                          +---------+






> On 27 Feb 2020, at 23:51, George Michaelson <ggm _at_ algebras _dot_ org> wrote:
> 
> Anton pointed out I may have both misunderstood and not answered your question.
> 
> The testbed is a soft TA. In deployment, people will have to move to a
> new (as yet not created) TAL for AS0, as long as it runs independently
> of the mainline TAL.
> 
> We intend running a distinct TA for AS0 until we get a clear signal
> our community wants it integrated. We have stated concerns about the
> automatic adoption of ASO products worldwide without visible agreement
> of this activity, a separate TAL turns the activity from opt-out to
> opt-in.
> 
> We are duplicating the software signing infrastructure, but with lower
> costs overall given commonalities.
> 
> We are still discussing if we can run the offline-TA HSM and the
> online production key HSM for both activities, or if we need a
> distinct infrastructure for AS0 and mainline. Duplication overall is
> not in APNIC's model, we rely on spares and alternate use of the HSM,
> but production signing systems are single instances. I believe they
> are capable of some virtualisation or segmentation but that skirts the
> underlying physical risk/dependency.
> 
> Sorry for not being clearer before
> 
> -George
> 
> On Wed, Feb 26, 2020 at 6:18 PM Carlos Friaças via routing-wg
> <routing-wg _at_ ripe _dot_ net> wrote:
>> 
>> 
>> Hi,
>> 
>> Any clue if APNIC has duplicated the infrastructure (and cost) as it is
>> foreseen in the NCC's impact analysis...?
>> 
>> Carlos
>> 
>> 
>> 
>> On Wed, 26 Feb 2020, JORDI PALET MARTINEZ via routing-wg wrote:
>> 
>>> Hi Max,
>>> 
>>> I think is too early to take a decision, and in fact I don't think we are yet in case A.
>>> 
>>> Consensus is about justified objections. I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent.
>>> 
>>> The only justification that I can see is from Job about possible cost. However, I don't see figures about how much it cost to develop this AS0 + how much it cost the operators to use it (if they want) vs developing the SLURM + making sure it is secure as RPKI + how much ti cost the operators to use it.
>>> 
>>> And by the way, the AS0 is compatible with the SLURM, so opeartors can choose.
>>> 
>>> Regards,
>>> Jordi
>>> @jordipalet
>>> 
>>> 
>>> 
>>> El 25/2/20 20:30, "routing-wg en nombre de Massimiliano Stucchi" <routing-wg-bounces _at_ ripe _dot_ net en nombre de max _at_ stucchi _dot_ ch> escribió:
>>> 
>>> 
>>>   Hi everyone,
>>> 
>>>   On 20/02/2020 15:39, Petrit Hasani wrote:
>>> 
>>>> As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
>>>> 
>>>> At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
>>> 
>>>   Today, me and the other proposers of this policy change had a meeting to
>>>   discuss the feedback we have been receiving on the list.
>>> 
>>>   We understand that many people find this proposal controversial, and
>>>   many have expressed themselves against it in the past days.
>>> 
>>>   We would like to encourage discussion and provide us with a bit of
>>>   guidance on how the community would like to proceed.  At present we have
>>>   identified three ways of progressing:
>>> 
>>>   A) We can try to go ahead with this proposal, although it will be hard
>>>   to get consensus;
>>> 
>>>   B) We can drop the proposal, and leave everything as is;
>>> 
>>>   C) We can change the proposal to a different ask for RIPE NCC.  The idea
>>>   could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC
>>>   does), so that single users can decide if they want to feed it to their
>>>   validators.
>>> 
>>>   From what we gathered in the discussions, I think B) could be the most
>>>   sought-after decision, but we would like to propose C) as the way
>>>   forward.  It would give the possibility to those who want to implement
>>>   this solution to do it in a lightweight fashion.  It would for sure be
>>>   much much cheaper to implement.
>>> 
>>>   In any case, as Job already pointed out, I prepared a simple tool to
>>>   generate a SLURM file using either the Team Cymru bogons list, or
>>>   considering any unassigned space from the NRO delegated stats file.
>>>   RIPE NCC has kindly provided help and patches to improve it.  If you
>>>   want to give it a go, you can find it here:
>>> 
>>>   https://github.com/stucchimax/rpki-as0-bogons
>>> 
>>>   Thank you for any suggestion or any discussion around this.
>>> 
>>>   Ciao!
>>>   --
>>>   Massimiliano Stucchi
>>>   MS16801-RIPE
>>>   Twitter/Telegram: @stucchimax
>>> 
>>> 
>>> 
>>> 
>>> 
>>> **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.theipv6company.com
>>> The IPv6 Company
>>> 
>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>>> 
>>> 
>>> 
>>> 
>>> 
> 

User Image

Melchior Aelmans

2020-03-02 18:04:05 CET

Thanks for this very valuable feedback Thiago! Much appreciated!

Cheers,
Melchior

On Mon, Mar 2, 2020 at 11:11 AM Thiago da Cruz <tdacruz _at_ ripe _dot_ net> wrote:

> Hi all,
>
> Many of you might not know me, but I’m part of RIPE’s software
> engineering team that takes care of RPKI.
>
> I’ve been following this discussion closely and I've noticed some lack of
> clarity about our decision to duplicate our RPKI infrastructure.
> So I think it’s important for us to tell a few things about our approach.
>
> First what we have today in production:
> - TA software (offline box)
> - HSM for the TA (plus backups and spare parts)
> - A few application servers running our RPKI software - I’ll call it
> RPKI-Core
> - Redundant HSMs used by RPKI-Core
> - RRDP publication service (cloud)
> - Some rsync nodes (internal infra)
>
> Something like the diagram below.
>
> For testing environment we have practically the same infra.
> And for public test (localcert) we use ‘soft' keys and no HSMs.
>
>
> About the new AS0 TA, yes, we could simplify our infra.
> One option would be to use ‘soft’ keys all around or use a HSM for TA only.
> We could also use third-party software for TA, Core and publication
> service.
> It crossed my mind, for a fraction of a second, to skip AS0 TA instances
> for our internal and/or public test environments.
>
> But I don’t think we should treat it as a "second class citizen".
> If we provide another TA, it’s worthy of receiving as much TLC as our
> production TA; meaning that it would also require the same (or similar) process
> around it as our production TA does. That includes keeping track of HSM
> card holders, defining a proper admin and operator quorum, scheduling
> periodical resigning sessions, etc…
>
> I’m not here to advocate against nor in favour of AS0 TA.
> But when discussing our implementation, this was our rationale to
> duplicate the infrastructure.
> And that’s why it would cost us a lot to implement it.
>
> Let me know you need more info about this subject.
>
> Kind regards,
> Thiago da Cruz
> Sr. software engineer - RPKI Team
> RIPE NCC
>
>
>             +---------------------+
>             |                     |            +-------+
>             |    TA (offline)     +------------+  HSM  |
>             |                     |            +-------+
>             +---------------------+
>
>
>
>
>
>                                   +------------------------+
>
>                                   |                        |
>
>                    +----------->  |    RRDP publication    |
>
>                    |              |                        |
>
>                    |              |        (cloud)         |
>
>                    |              |                        |
>      +-------------------+             +-------------------+
>                   |              +------------------------+
>      |                   |             |                   |
>  Publication            |
>      |    RPKI-Core 1    |    (...)    |    RPKI-Core n    |
> ---------------------->  * +>
>      |                   |             |                   |
>                   |
>      +--+-----+----+-----+             +--+------+-------+-+
>                   |              +----------------------------+
>         |     |    |                      |      |       |
>                   |              |                            |
>         |     |    +---------------+      |      |       |
>                   |              |    Rsync publication       |
>         |     |                    |      |      |       +----+
>                    +----------->  |                            |
>   +-----+     +-----------+     +---------+      |            |
>                                   | (internal infra - x nodes) |
>   |                       |     |  |             |            |
>                                   |                            |
>   |                       |     |  +-------------------+      |
>                                   |                            |
>   |    +-----------------------------------------+     |      |
>                                   +----------------------------+
>   |    |                  |     |                      |      |
> +-+----+--+               +     +                    +-+------++
> |  HSM 1  |         (......................)         |  HSM m  |
> +---------+                                          +---------+
>
>
>
>
>
>
> On 27 Feb 2020, at 23:51, George Michaelson <ggm _at_ algebras _dot_ org> wrote:
>
> Anton pointed out I may have both misunderstood and not answered your
> question.
>
> The testbed is a soft TA. In deployment, people will have to move to a
> new (as yet not created) TAL for AS0, as long as it runs independently
> of the mainline TAL.
>
> We intend running a distinct TA for AS0 until we get a clear signal
> our community wants it integrated. We have stated concerns about the
> automatic adoption of ASO products worldwide without visible agreement
> of this activity, a separate TAL turns the activity from opt-out to
> opt-in.
>
> We are duplicating the software signing infrastructure, but with lower
> costs overall given commonalities.
>
> We are still discussing if we can run the offline-TA HSM and the
> online production key HSM for both activities, or if we need a
> distinct infrastructure for AS0 and mainline. Duplication overall is
> not in APNIC's model, we rely on spares and alternate use of the HSM,
> but production signing systems are single instances. I believe they
> are capable of some virtualisation or segmentation but that skirts the
> underlying physical risk/dependency.
>
> Sorry for not being clearer before
>
> -George
>
> On Wed, Feb 26, 2020 at 6:18 PM Carlos Friaças via routing-wg
> <routing-wg _at_ ripe _dot_ net> wrote:
>
>
>
> Hi,
>
> Any clue if APNIC has duplicated the infrastructure (and cost) as it is
> foreseen in the NCC's impact analysis...?
>
> Carlos
>
>
>
> On Wed, 26 Feb 2020, JORDI PALET MARTINEZ via routing-wg wrote:
>
> Hi Max,
>
> I think is too early to take a decision, and in fact I don't think we are
> yet in case A.
>
> Consensus is about justified objections. I can see also people in favor
> and I understand, as we usually do in any proposal discussion, that
> non-objection is consent.
>
> The only justification that I can see is from Job about possible cost.
> However, I don't see figures about how much it cost to develop this AS0 +
> how much it cost the operators to use it (if they want) vs developing the
> SLURM + making sure it is secure as RPKI + how much ti cost the operators
> to use it.
>
> And by the way, the AS0 is compatible with the SLURM, so opeartors can
> choose.
>
> Regards,
> Jordi
> @jordipalet
>
>
>
> El 25/2/20 20:30, "routing-wg en nombre de Massimiliano Stucchi" <
> routing-wg-bounces _at_ ripe _dot_ net en nombre de max _at_ stucchi _dot_ ch> escribió:
>
>
>   Hi everyone,
>
>   On 20/02/2020 15:39, Petrit Hasani wrote:
>
> As per the RIPE Policy Development Process (PDP), the purpose of this four
> week Review Phase is to continue discussion of the proposal, taking the
> impact analysis into consideration, and to review the full draft RIPE
> Policy Document.
>
> At the end of the Review Phase, the Working Group (WG) Chairs will
> determine whether the WG has reached rough consensus. It is therefore
> important to provide your opinion, even if it is simply a restatement of
> your input from the previous phase.
>
>
>   Today, me and the other proposers of this policy change had a meeting to
>   discuss the feedback we have been receiving on the list.
>
>   We understand that many people find this proposal controversial, and
>   many have expressed themselves against it in the past days.
>
>   We would like to encourage discussion and provide us with a bit of
>   guidance on how the community would like to proceed.  At present we have
>   identified three ways of progressing:
>
>   A) We can try to go ahead with this proposal, although it will be hard
>   to get consensus;
>
>   B) We can drop the proposal, and leave everything as is;
>
>   C) We can change the proposal to a different ask for RIPE NCC.  The idea
>   could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC
>   does), so that single users can decide if they want to feed it to their
>   validators.
>
>   From what we gathered in the discussions, I think B) could be the most
>   sought-after decision, but we would like to propose C) as the way
>   forward.  It would give the possibility to those who want to implement
>   this solution to do it in a lightweight fashion.  It would for sure be
>   much much cheaper to implement.
>
>   In any case, as Job already pointed out, I prepared a simple tool to
>   generate a SLURM file using either the Team Cymru bogons list, or
>   considering any unassigned space from the NRO delegated stats file.
>   RIPE NCC has kindly provided help and patches to improve it.  If you
>   want to give it a go, you can find it here:
>
>   https://github.com/stucchimax/rpki-as0-bogons
>
>   Thank you for any suggestion or any discussion around this.
>
>   Ciao!
>   --
>   Massimiliano Stucchi
>   MS16801-RIPE
>   Twitter/Telegram: @stucchimax
>
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>
>
>
>
>
>
User Image

Ehsan Ghazizadeh

2020-03-02 18:21:09 CET

Hi guys

I support this proposal, I don't think this costs so much money and effort.

On Mon, Mar 2, 2020 at 8:34 PM Melchior Aelmans <melchior _at_ aelmans _dot_ eu> wrote:

> Thanks for this very valuable feedback Thiago! Much appreciated!
>
> Cheers,
> Melchior
>
> On Mon, Mar 2, 2020 at 11:11 AM Thiago da Cruz <tdacruz _at_ ripe _dot_ net> wrote:
>
>> Hi all,
>>
>> Many of you might not know me, but I’m part of RIPE’s software
>> engineering team that takes care of RPKI.
>>
>> I’ve been following this discussion closely and I've noticed some lack of
>> clarity about our decision to duplicate our RPKI infrastructure.
>> So I think it’s important for us to tell a few things about our approach.
>>
>> First what we have today in production:
>> - TA software (offline box)
>> - HSM for the TA (plus backups and spare parts)
>> - A few application servers running our RPKI software - I’ll call it
>> RPKI-Core
>> - Redundant HSMs used by RPKI-Core
>> - RRDP publication service (cloud)
>> - Some rsync nodes (internal infra)
>>
>> Something like the diagram below.
>>
>> For testing environment we have practically the same infra.
>> And for public test (localcert) we use ‘soft' keys and no HSMs.
>>
>>
>> About the new AS0 TA, yes, we could simplify our infra.
>> One option would be to use ‘soft’ keys all around or use a HSM for TA
>> only.
>> We could also use third-party software for TA, Core and publication
>> service.
>> It crossed my mind, for a fraction of a second, to skip AS0 TA instances
>> for our internal and/or public test environments.
>>
>> But I don’t think we should treat it as a "second class citizen".
>> If we provide another TA, it’s worthy of receiving as much TLC as our
>> production TA; meaning that it would also require the same (or similar) process
>> around it as our production TA does. That includes keeping track of HSM
>> card holders, defining a proper admin and operator quorum, scheduling
>> periodical resigning sessions, etc…
>>
>> I’m not here to advocate against nor in favour of AS0 TA.
>> But when discussing our implementation, this was our rationale to
>> duplicate the infrastructure.
>> And that’s why it would cost us a lot to implement it.
>>
>> Let me know you need more info about this subject.
>>
>> Kind regards,
>> Thiago da Cruz
>> Sr. software engineer - RPKI Team
>> RIPE NCC
>>
>>
>>             +---------------------+
>>             |                     |            +-------+
>>             |    TA (offline)     +------------+  HSM  |
>>             |                     |            +-------+
>>             +---------------------+
>>
>>
>>
>>
>>
>>                                   +------------------------+
>>
>>                                   |                        |
>>
>>                    +----------->  |    RRDP publication    |
>>
>>                    |              |                        |
>>
>>                    |              |        (cloud)         |
>>
>>                    |              |                        |
>>      +-------------------+             +-------------------+
>>                     |              +------------------------+
>>      |                   |             |                   |
>>  Publication            |
>>      |    RPKI-Core 1    |    (...)    |    RPKI-Core n    |
>> ---------------------->  * +>
>>      |                   |             |                   |
>>                     |
>>      +--+-----+----+-----+             +--+------+-------+-+
>>                     |              +----------------------------+
>>         |     |    |                      |      |       |
>>                     |              |                            |
>>         |     |    +---------------+      |      |       |
>>                     |              |    Rsync publication       |
>>         |     |                    |      |      |       +----+
>>                    +----------->  |                            |
>>   +-----+     +-----------+     +---------+      |            |
>>                                   | (internal infra - x nodes) |
>>   |                       |     |  |             |            |
>>                                   |                            |
>>   |                       |     |  +-------------------+      |
>>                                   |                            |
>>   |    +-----------------------------------------+     |      |
>>                                   +----------------------------+
>>   |    |                  |     |                      |      |
>> +-+----+--+               +     +                    +-+------++
>> |  HSM 1  |         (......................)         |  HSM m  |
>> +---------+                                          +---------+
>>
>>
>>
>>
>>
>>
>> On 27 Feb 2020, at 23:51, George Michaelson <ggm _at_ algebras _dot_ org> wrote:
>>
>> Anton pointed out I may have both misunderstood and not answered your
>> question.
>>
>> The testbed is a soft TA. In deployment, people will have to move to a
>> new (as yet not created) TAL for AS0, as long as it runs independently
>> of the mainline TAL.
>>
>> We intend running a distinct TA for AS0 until we get a clear signal
>> our community wants it integrated. We have stated concerns about the
>> automatic adoption of ASO products worldwide without visible agreement
>> of this activity, a separate TAL turns the activity from opt-out to
>> opt-in.
>>
>> We are duplicating the software signing infrastructure, but with lower
>> costs overall given commonalities.
>>
>> We are still discussing if we can run the offline-TA HSM and the
>> online production key HSM for both activities, or if we need a
>> distinct infrastructure for AS0 and mainline. Duplication overall is
>> not in APNIC's model, we rely on spares and alternate use of the HSM,
>> but production signing systems are single instances. I believe they
>> are capable of some virtualisation or segmentation but that skirts the
>> underlying physical risk/dependency.
>>
>> Sorry for not being clearer before
>>
>> -George
>>
>> On Wed, Feb 26, 2020 at 6:18 PM Carlos Friaças via routing-wg
>> <routing-wg _at_ ripe _dot_ net> wrote:
>>
>>
>>
>> Hi,
>>
>> Any clue if APNIC has duplicated the infrastructure (and cost) as it is
>> foreseen in the NCC's impact analysis...?
>>
>> Carlos
>>
>>
>>
>> On Wed, 26 Feb 2020, JORDI PALET MARTINEZ via routing-wg wrote:
>>
>> Hi Max,
>>
>> I think is too early to take a decision, and in fact I don't think we are
>> yet in case A.
>>
>> Consensus is about justified objections. I can see also people in favor
>> and I understand, as we usually do in any proposal discussion, that
>> non-objection is consent.
>>
>> The only justification that I can see is from Job about possible cost.
>> However, I don't see figures about how much it cost to develop this AS0 +
>> how much it cost the operators to use it (if they want) vs developing the
>> SLURM + making sure it is secure as RPKI + how much ti cost the operators
>> to use it.
>>
>> And by the way, the AS0 is compatible with the SLURM, so opeartors can
>> choose.
>>
>> Regards,
>> Jordi
>> @jordipalet
>>
>>
>>
>> El 25/2/20 20:30, "routing-wg en nombre de Massimiliano Stucchi" <
>> routing-wg-bounces _at_ ripe _dot_ net en nombre de max _at_ stucchi _dot_ ch> escribió:
>>
>>
>>   Hi everyone,
>>
>>   On 20/02/2020 15:39, Petrit Hasani wrote:
>>
>> As per the RIPE Policy Development Process (PDP), the purpose of this
>> four week Review Phase is to continue discussion of the proposal, taking
>> the impact analysis into consideration, and to review the full draft RIPE
>> Policy Document.
>>
>> At the end of the Review Phase, the Working Group (WG) Chairs will
>> determine whether the WG has reached rough consensus. It is therefore
>> important to provide your opinion, even if it is simply a restatement of
>> your input from the previous phase.
>>
>>
>>   Today, me and the other proposers of this policy change had a meeting to
>>   discuss the feedback we have been receiving on the list.
>>
>>   We understand that many people find this proposal controversial, and
>>   many have expressed themselves against it in the past days.
>>
>>   We would like to encourage discussion and provide us with a bit of
>>   guidance on how the community would like to proceed.  At present we have
>>   identified three ways of progressing:
>>
>>   A) We can try to go ahead with this proposal, although it will be hard
>>   to get consensus;
>>
>>   B) We can drop the proposal, and leave everything as is;
>>
>>   C) We can change the proposal to a different ask for RIPE NCC.  The idea
>>   could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC
>>   does), so that single users can decide if they want to feed it to their
>>   validators.
>>
>>   From what we gathered in the discussions, I think B) could be the most
>>   sought-after decision, but we would like to propose C) as the way
>>   forward.  It would give the possibility to those who want to implement
>>   this solution to do it in a lightweight fashion.  It would for sure be
>>   much much cheaper to implement.
>>
>>   In any case, as Job already pointed out, I prepared a simple tool to
>>   generate a SLURM file using either the Team Cymru bogons list, or
>>   considering any unassigned space from the NRO delegated stats file.
>>   RIPE NCC has kindly provided help and patches to improve it.  If you
>>   want to give it a go, you can find it here:
>>
>>   https://github.com/stucchimax/rpki-as0-bogons
>>
>>   Thank you for any suggestion or any discussion around this.
>>
>>   Ciao!
>>   --
>>   Massimiliano Stucchi
>>   MS16801-RIPE
>>   Twitter/Telegram: @stucchimax
>>
>>
>>
>>
>>
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> The IPv6 Company
>>
>> This electronic message contains information which may be privileged or
>> confidential. The information is intended to be for the exclusive use of
>> the individual(s) named above and further non-explicilty authorized
>> disclosure, copying, distribution or use of the contents of this
>> information, even if partially, including attached files, is strictly
>> prohibited and will be considered a criminal offense. If you are not the
>> intended recipient be aware that any disclosure, copying, distribution or
>> use of the contents of this information, even if partially, including
>> attached files, is strictly prohibited, will be considered a criminal
>> offense, so you must reply to the original sender to inform about this
>> communication and delete it.
>>
>>
>>
>>
>>
>>
>>
>>

-- 
http://about.me/AphroditeEmpire

Thiago da Cruz

2020-03-02 20:07:17 CET

RIPE NCC staff member

Hi Jordi, 

I’m not the budget guy, so I’m going to distance myself from the euros. 
When I say “it would cost us a lot to implement it” I mean in effort when compared with other options.   

Kind regards,
Thiago da Cruz 
Sr. software engineer - RPKI Team
RIPE NCC


> On 2 Mar 2020, at 18:25, JORDI PALET MARTINEZ via routing-wg <routing-wg _at_ ripe _dot_ net> wrote:
> 
> Hi Thiago,
>  
> The question here, I think, is to understand how much in euros is “a lot”?
>  
> Regards,
> Jordi
> 
> @jordipalet
> 
>  
> 
>  
>  
> El 2/3/20 11:11, "routing-wg en nombre de Thiago da Cruz" <routing-wg-bounces _at_ ripe _dot_ net routing-wg-bounces _at_ ripe _dot_ net> en nombre de tdacruz _at_ ripe _dot_ net tdacruz _at_ ripe _dot_ net>> escribió:
>  
> Hi all,
>  
> Many of you might not know me, but I’m part of RIPE’s software engineering team that takes care of RPKI.
>  
> I’ve been following this discussion closely and I've noticed some lack of clarity about our decision to duplicate our RPKI infrastructure.
> So I think it’s important for us to tell a few things about our approach. 
>  
> First what we have today in production:
> - TA software (offline box)
> - HSM for the TA (plus backups and spare parts)
> - A few application servers running our RPKI software - I’ll call it RPKI-Core
> - Redundant HSMs used by RPKI-Core
> - RRDP publication service (cloud)
> - Some rsync nodes (internal infra)
>  
> Something like the diagram below.
>  
> For testing environment we have practically the same infra. 
> And for public test (localcert) we use ‘soft' keys and no HSMs.
>  
>  
> About the new AS0 TA, yes, we could simplify our infra.
> One option would be to use ‘soft’ keys all around or use a HSM for TA only.
> We could also use third-party software for TA, Core and publication service.
> It crossed my mind, for a fraction of a second, to skip AS0 TA instances for our internal and/or public test environments.
>  
> But I don’t think we should treat it as a "second class citizen".   
> If we provide another TA, it’s worthy of receiving as much TLC as our production TA; meaning that it would also require the same (or similar) process around it as our production TA does. That includes keeping track of HSM card holders, defining a proper admin and operator quorum, scheduling periodical resigning sessions, etc…
>  
> I’m not here to advocate against nor in favour of AS0 TA. 
> But when discussing our implementation, this was our rationale to duplicate the infrastructure. 
> And that’s why it would cost us a lot to implement it. 
>  
> Let me know you need more info about this subject.
>  
> Kind regards, 
> Thiago da Cruz 
> Sr. software engineer - RPKI Team
> RIPE NCC
>  
>  
>             +---------------------+
>             |                     |            +-------+
>             |    TA (offline)     +------------+  HSM  |
>             |                     |            +-------+
>             +---------------------+
>  
>  
>  
>  
>                                                                                                             +------------------------+
>                                                                                                             |                        |
>                                                                                              +----------->  |    RRDP publication    |
>                                                                                              |              |                        |
>                                                                                              |              |        (cloud)         |
>                                                                                              |              |                        |
>      +-------------------+             +-------------------+                                 |              +------------------------+
>      |                   |             |                   |          Publication            |
>      |    RPKI-Core 1    |    (...)    |    RPKI-Core n    |     ---------------------->  * +>
>      |                   |             |                   |                                 |
>      +--+-----+----+-----+             +--+------+-------+-+                                 |              +----------------------------+
>         |     |    |                      |      |       |                                   |              |                            |
>         |     |    +---------------+      |      |       |                                   |              |    Rsync publication       |
>         |     |                    |      |      |       +----+                              +----------->  |                            |
>   +-----+     +-----------+     +---------+      |            |                                             | (internal infra - x nodes) |
>   |                       |     |  |             |            |                                             |                            |
>   |                       |     |  +-------------------+      |                                             |                            |
>   |    +-----------------------------------------+     |      |                                             +----------------------------+
>   |    |                  |     |                      |      |
> +-+----+--+               +     +                    +-+------++
> |  HSM 1  |         (......................)         |  HSM m  |
> +---------+                                          +---------+
>  
>  
>  
>  
>  
> 
> 
>> On 27 Feb 2020, at 23:51, George Michaelson <ggm _at_ algebras _dot_ org ggm _at_ algebras _dot_ org>> wrote:
>>  
>> Anton pointed out I may have both misunderstood and not answered your question.
>> 
>> The testbed is a soft TA. In deployment, people will have to move to a
>> new (as yet not created) TAL for AS0, as long as it runs independently
>> of the mainline TAL.
>> 
>> We intend running a distinct TA for AS0 until we get a clear signal
>> our community wants it integrated. We have stated concerns about the
>> automatic adoption of ASO products worldwide without visible agreement
>> of this activity, a separate TAL turns the activity from opt-out to
>> opt-in.
>> 
>> We are duplicating the software signing infrastructure, but with lower
>> costs overall given commonalities.
>> 
>> We are still discussing if we can run the offline-TA HSM and the
>> online production key HSM for both activities, or if we need a
>> distinct infrastructure for AS0 and mainline. Duplication overall is
>> not in APNIC's model, we rely on spares and alternate use of the HSM,
>> but production signing systems are single instances. I believe they
>> are capable of some virtualisation or segmentation but that skirts the
>> underlying physical risk/dependency.
>> 
>> Sorry for not being clearer before
>> 
>> -George
>> 
>> On Wed, Feb 26, 2020 at 6:18 PM Carlos Friaças via routing-wg
>> <routing-wg _at_ ripe _dot_ net routing-wg _at_ ripe _dot_ net>> wrote:
>> 
>>> 
>>> 
>>> Hi,
>>> 
>>> Any clue if APNIC has duplicated the infrastructure (and cost) as it is
>>> foreseen in the NCC's impact analysis...?
>>> 
>>> Carlos
>>> 
>>> 
>>> 
>>> On Wed, 26 Feb 2020, JORDI PALET MARTINEZ via routing-wg wrote:
>>> 
>>> 
>>>> Hi Max,
>>>> 
>>>> I think is too early to take a decision, and in fact I don't think we are yet in case A.
>>>> 
>>>> Consensus is about justified objections. I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent.
>>>> 
>>>> The only justification that I can see is from Job about possible cost. However, I don't see figures about how much it cost to develop this AS0 + how much it cost the operators to use it (if they want) vs developing the SLURM + making sure it is secure as RPKI + how much ti cost the operators to use it.
>>>> 
>>>> And by the way, the AS0 is compatible with the SLURM, so opeartors can choose.
>>>> 
>>>> Regards,
>>>> Jordi
>>>> @jordipalet
>>>> 
>>>> 
>>>> 
>>>> El 25/2/20 20:30, "routing-wg en nombre de Massimiliano Stucchi" <routing-wg-bounces _at_ ripe _dot_ net routing-wg-bounces _at_ ripe _dot_ net> en nombre de max _at_ stucchi _dot_ ch max _at_ stucchi _dot_ ch>> escribió:
>>>> 
>>>> 
>>>>   Hi everyone,
>>>> 
>>>>   On 20/02/2020 15:39, Petrit Hasani wrote:
>>>> 
>>>> 
>>>>> As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
>>>>> 
>>>>> At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
>>>> 
>>>>   Today, me and the other proposers of this policy change had a meeting to
>>>>   discuss the feedback we have been receiving on the list.
>>>> 
>>>>   We understand that many people find this proposal controversial, and
>>>>   many have expressed themselves against it in the past days.
>>>> 
>>>>   We would like to encourage discussion and provide us with a bit of
>>>>   guidance on how the community would like to proceed.  At present we have
>>>>   identified three ways of progressing:
>>>> 
>>>>   A) We can try to go ahead with this proposal, although it will be hard
>>>>   to get consensus;
>>>> 
>>>>   B) We can drop the proposal, and leave everything as is;
>>>> 
>>>>   C) We can change the proposal to a different ask for RIPE NCC.  The idea
>>>>   could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC
>>>>   does), so that single users can decide if they want to feed it to their
>>>>   validators.
>>>> 
>>>>   From what we gathered in the discussions, I think B) could be the most
>>>>   sought-after decision, but we would like to propose C) as the way
>>>>   forward.  It would give the possibility to those who want to implement
>>>>   this solution to do it in a lightweight fashion.  It would for sure be
>>>>   much much cheaper to implement.
>>>> 
>>>>   In any case, as Job already pointed out, I prepared a simple tool to
>>>>   generate a SLURM file using either the Team Cymru bogons list, or
>>>>   considering any unassigned space from the NRO delegated stats file.
>>>>   RIPE NCC has kindly provided help and patches to improve it.  If you
>>>>   want to give it a go, you can find it here:
>>>> 
>>>>   https://github.com/stucchimax/rpki-as0-bogons 
>>>> 
>>>>   Thank you for any suggestion or any discussion around this.
>>>> 
>>>>   Ciao!
>>>>   --
>>>>   Massimiliano Stucchi
>>>>   MS16801-RIPE
>>>>   Twitter/Telegram: @stucchimax
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> **********************************************
>>>> IPv4 is over
>>>> Are you ready for the new Internet ?
>>>> http://www.theipv6company.com 
>>>> The IPv6 Company
>>>> 
>>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>  
> 
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com 
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Job Snijders

2020-03-02 20:15:18 CET

Dear Massimiliano,

Thank you for the overview and proposing possible paths forward.

On Tue, Feb 25, 2020 at 08:30:21PM +0100, Massimiliano Stucchi wrote:
> C) We can change the proposal to a different ask for RIPE NCC.  The idea
> could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC
> does), so that single users can decide if they want to feed it to their
> validators.

I would be in favor of option C - generation of a SLURM file.

It appears cheap to implement and efficient in its purpose, it is
opt-in. A good balance.

Kind regards,

Job

User Image

Petrit Hasani

2020-03-03 13:15:55 CET

RIPE NCC staff member

Dear Jordi,

I would like to clarify that the financial cost approximation of a proposal is not part of the Impact Analysis and the Policy Development Process, so we have not made a calculation.

As too many factors have to be taken into account that we can't estimate realistically at this stage of the PDP.

Our software department provided an estimation of the worked involved for the implementation of the proposal which is explained in the impact analysis.


Kind regards,
—
Petrit Hasani
Policy Officer
RIPE NCC





> On 2 Mar 2020, at 20:22, JORDI PALET MARTINEZ via routing-wg <routing-wg _at_ ripe _dot_ net> wrote:
> 
> Hi Thiago,
> 
> Yeah, I understand that … So, my question is re-directed to the policy officer for providing an approximation of what is the cost.
> 
> Regards,
> Jordi
> 
> @jordipalet
> 
> 
> 
> 
> 
> El 2/3/20 20:07, "Thiago da Cruz" <tdacruz _at_ ripe _dot_ net> escribió:
> 
> Hi Jordi,
> 
> I’m not the budget guy, so I’m going to distance myself from the euros.
> When I say “it would cost us a lot to implement it” I mean in effort when compared with other options.
> 
> Kind regards,
> Thiago da Cruz
> Sr. software engineer - RPKI Team
> RIPE NCC
> 
> 
> 
>> On 2 Mar 2020, at 18:25, JORDI PALET MARTINEZ via routing-wg <routing-wg _at_ ripe _dot_ net> wrote:
>> 
>> Hi Thiago,
>> 
>> The question here, I think, is to understand how much in euros is “a lot”?
>> 
>> Regards,
>> Jordi
>> 
>> @jordipalet
>> 
>> 
>> 
>> 
>> 
>> El 2/3/20 11:11, "routing-wg en nombre de Thiago da Cruz" <routing-wg-bounces _at_ ripe _dot_ net en nombre de tdacruz _at_ ripe _dot_ net> escribió:
>> 
>> Hi all,
>> 
>> Many of you might not know me, but I’m part of RIPE’s software engineering team that takes care of RPKI.
>> 
>> I’ve been following this discussion closely and I've noticed some lack of clarity about our decision to duplicate our RPKI infrastructure.
>> So I think it’s important for us to tell a few things about our approach.
>> 
>> First what we have today in production:
>> - TA software (offline box)
>> - HSM for the TA (plus backups and spare parts)
>> - A few application servers running our RPKI software - I’ll call it RPKI-Core
>> - Redundant HSMs used by RPKI-Core
>> - RRDP publication service (cloud)
>> - Some rsync nodes (internal infra)
>> 
>> Something like the diagram below.
>> 
>> For testing environment we have practically the same infra.
>> And for public test (localcert) we use ‘soft' keys and no HSMs.
>> 
>> 
>> About the new AS0 TA, yes, we could simplify our infra.
>> One option would be to use ‘soft’ keys all around or use a HSM for TA only.
>> We could also use third-party software for TA, Core and publication service.
>> It crossed my mind, for a fraction of a second, to skip AS0 TA instances for our internal and/or public test environments.
>> 
>> But I don’t think we should treat it as a "second class citizen".
>> If we provide another TA, it’s worthy of receiving as much TLC as our production TA; meaning that it would also require the same (or similar) process around it as our production TA does. That includes keeping track of HSM card holders, defining a proper admin and operator quorum, scheduling periodical resigning sessions, etc…
>> 
>> I’m not here to advocate against nor in favour of AS0 TA.
>> But when discussing our implementation, this was our rationale to duplicate the infrastructure.
>> And that’s why it would cost us a lot to implement it.
>> 
>> Let me know you need more info about this subject.
>> 
>> Kind regards,
>> Thiago da Cruz
>> Sr. software engineer - RPKI Team
>> RIPE NCC
>> 
>> 
>>             +---------------------+
>>             |                     |            +-------+
>>             |    TA (offline)     +------------+  HSM  |
>>             |                     |            +-------+
>>             +---------------------+
>> 
>> 
>> 
>> 
>>                                                                                                             +------------------------+
>>                                                                                                             |                        |
>>                                                                                              +----------->  |    RRDP publication    |
>>                                                                                              |              |                        |
>>                                                                                              |              |        (cloud)         |
>>                                                                                              |              |                        |
>>      +-------------------+             +-------------------+                                 |              +------------------------+
>>      |                   |             |                   |          Publication            |
>>      |    RPKI-Core 1    |    (...)    |    RPKI-Core n    |     ---------------------->  * +>
>>      |                   |             |                   |                                 |
>>      +--+-----+----+-----+             +--+------+-------+-+                                 |              +----------------------------+
>>         |     |    |                      |      |       |                                   |              |                            |
>>         |     |    +---------------+      |      |       |                                   |              |    Rsync publication       |
>>         |     |                    |      |      |       +----+                              +----------->  |                            |
>>   +-----+     +-----------+     +---------+      |            |                                             | (internal infra - x nodes) |
>>   |                       |     |  |             |            |                                             |                            |
>>   |                       |     |  +-------------------+      |                                             |                            |
>>   |    +-----------------------------------------+     |      |                                             +----------------------------+
>>   |    |                  |     |                      |      |
>> +-+----+--+               +     +                    +-+------++
>> |  HSM 1  |         (......................)         |  HSM m  |
>> +---------+                                          +---------+
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On 27 Feb 2020, at 23:51, George Michaelson <ggm _at_ algebras _dot_ org> wrote:
>>> 
>>> Anton pointed out I may have both misunderstood and not answered your question.
>>> 
>>> The testbed is a soft TA. In deployment, people will have to move to a
>>> new (as yet not created) TAL for AS0, as long as it runs independently
>>> of the mainline TAL.
>>> 
>>> We intend running a distinct TA for AS0 until we get a clear signal
>>> our community wants it integrated. We have stated concerns about the
>>> automatic adoption of ASO products worldwide without visible agreement
>>> of this activity, a separate TAL turns the activity from opt-out to
>>> opt-in.
>>> 
>>> We are duplicating the software signing infrastructure, but with lower
>>> costs overall given commonalities.
>>> 
>>> We are still discussing if we can run the offline-TA HSM and the
>>> online production key HSM for both activities, or if we need a
>>> distinct infrastructure for AS0 and mainline. Duplication overall is
>>> not in APNIC's model, we rely on spares and alternate use of the HSM,
>>> but production signing systems are single instances. I believe they
>>> are capable of some virtualisation or segmentation but that skirts the
>>> underlying physical risk/dependency.
>>> 
>>> Sorry for not being clearer before
>>> 
>>> -George
>>> 
>>> On Wed, Feb 26, 2020 at 6:18 PM Carlos Friaças via routing-wg
>>> <routing-wg _at_ ripe _dot_ net> wrote:
>>> 
>>> 
>>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> Any clue if APNIC has duplicated the infrastructure (and cost) as it is
>>>> foreseen in the NCC's impact analysis...?
>>>> 
>>>> Carlos
>>>> 
>>>> 
>>>> 
>>>> On Wed, 26 Feb 2020, JORDI PALET MARTINEZ via routing-wg wrote:
>>>> 
>>>> 
>>>> 
>>>>> Hi Max,
>>>>> 
>>>>> I think is too early to take a decision, and in fact I don't think we are yet in case A.
>>>>> 
>>>>> Consensus is about justified objections. I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent.
>>>>> 
>>>>> The only justification that I can see is from Job about possible cost. However, I don't see figures about how much it cost to develop this AS0 + how much it cost the operators to use it (if they want) vs developing the SLURM + making sure it is secure as RPKI + how much ti cost the operators to use it.
>>>>> 
>>>>> And by the way, the AS0 is compatible with the SLURM, so opeartors can choose.
>>>>> 
>>>>> Regards,
>>>>> Jordi
>>>>> @jordipalet
>>>>> 
>>>>> 
>>>>> 
>>>>> El 25/2/20 20:30, "routing-wg en nombre de Massimiliano Stucchi" <routing-wg-bounces _at_ ripe _dot_ net en nombre de max _at_ stucchi _dot_ ch> escribió:
>>>>> 
>>>>> 
>>>>>   Hi everyone,
>>>>> 
>>>>>   On 20/02/2020 15:39, Petrit Hasani wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
>>>>>> 
>>>>>> At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
>>>>> 
>>>>>   Today, me and the other proposers of this policy change had a meeting to
>>>>>   discuss the feedback we have been receiving on the list.
>>>>> 
>>>>>   We understand that many people find this proposal controversial, and
>>>>>   many have expressed themselves against it in the past days.
>>>>> 
>>>>>   We would like to encourage discussion and provide us with a bit of
>>>>>   guidance on how the community would like to proceed.  At present we have
>>>>>   identified three ways of progressing:
>>>>> 
>>>>>   A) We can try to go ahead with this proposal, although it will be hard
>>>>>   to get consensus;
>>>>> 
>>>>>   B) We can drop the proposal, and leave everything as is;
>>>>> 
>>>>>   C) We can change the proposal to a different ask for RIPE NCC.  The idea
>>>>>   could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC
>>>>>   does), so that single users can decide if they want to feed it to their
>>>>>   validators.
>>>>> 
>>>>>   From what we gathered in the discussions, I think B) could be the most
>>>>>   sought-after decision, but we would like to propose C) as the way
>>>>>   forward.  It would give the possibility to those who want to implement
>>>>>   this solution to do it in a lightweight fashion.  It would for sure be
>>>>>   much much cheaper to implement.
>>>>> 
>>>>>   In any case, as Job already pointed out, I prepared a simple tool to
>>>>>   generate a SLURM file using either the Team Cymru bogons list, or
>>>>>   considering any unassigned space from the NRO delegated stats file.
>>>>>   RIPE NCC has kindly provided help and patches to improve it.  If you
>>>>>   want to give it a go, you can find it here:
>>>>> 
>>>>>   https://github.com/stucchimax/rpki-as0-bogons
>>>>> 
>>>>>   Thank you for any suggestion or any discussion around this.
>>>>> 
>>>>>   Ciao!
>>>>>   --
>>>>>   Massimiliano Stucchi
>>>>>   MS16801-RIPE
>>>>>   Twitter/Telegram: @stucchimax
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> **********************************************
>>>>> IPv4 is over
>>>>> Are you ready for the new Internet ?
>>>>> http://www.theipv6company.com
>>>>> The IPv6 Company
>>>>> 
>>>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
>> 
>> 
>> 
>> 
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> The IPv6 Company
>> 
>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

User Image

Jordi Palet Martinez

2020-03-03 19:20:48 CET

Hi Petrit,

I understand that, but I think it may be easy to get an idea, not exact cost.

The reason why this is needed is because one of the arguments against this proposal is about the cost.

This can't be judged as a valid objection for reaching consensus if we don't have that cost (approximate).

Regards,
Jordi
@jordipalet
 
 

El 3/3/20 13:16, "routing-wg en nombre de Petrit Hasani" <routing-wg-bounces _at_ ripe _dot_ net en nombre de phasani _at_ ripe _dot_ net> escribió:

    Dear Jordi,
    
    I would like to clarify that the financial cost approximation of a proposal is not part of the Impact Analysis and the Policy Development Process, so we have not made a calculation.
    
    As too many factors have to be taken into account that we can't estimate realistically at this stage of the PDP.
    
    Our software department provided an estimation of the worked involved for the implementation of the proposal which is explained in the impact analysis.
    
    
    Kind regards,
    —
    Petrit Hasani
    Policy Officer
    RIPE NCC
    
    
    
    
    
    > On 2 Mar 2020, at 20:22, JORDI PALET MARTINEZ via routing-wg <routing-wg _at_ ripe _dot_ net> wrote:
    > 
    > Hi Thiago,
    > 
    > Yeah, I understand that … So, my question is re-directed to the policy officer for providing an approximation of what is the cost.
    > 
    > Regards,
    > Jordi
    > 
    > @jordipalet
    > 
    > 
    > 
    > 
    > 
    > El 2/3/20 20:07, "Thiago da Cruz" <tdacruz _at_ ripe _dot_ net> escribió:
    > 
    > Hi Jordi,
    > 
    > I’m not the budget guy, so I’m going to distance myself from the euros.
    > When I say “it would cost us a lot to implement it” I mean in effort when compared with other options.
    > 
    > Kind regards,
    > Thiago da Cruz
    > Sr. software engineer - RPKI Team
    > RIPE NCC
    > 
    > 
    > 
    >> On 2 Mar 2020, at 18:25, JORDI PALET MARTINEZ via routing-wg <routing-wg _at_ ripe _dot_ net> wrote:
    >> 
    >> Hi Thiago,
    >> 
    >> The question here, I think, is to understand how much in euros is “a lot”?
    >> 
    >> Regards,
    >> Jordi
    >> 
    >> @jordipalet
    >> 
    >> 
    >> 
    >> 
    >> 
    >> El 2/3/20 11:11, "routing-wg en nombre de Thiago da Cruz" <routing-wg-bounces _at_ ripe _dot_ net en nombre de tdacruz _at_ ripe _dot_ net> escribió:
    >> 
    >> Hi all,
    >> 
    >> Many of you might not know me, but I’m part of RIPE’s software engineering team that takes care of RPKI.
    >> 
    >> I’ve been following this discussion closely and I've noticed some lack of clarity about our decision to duplicate our RPKI infrastructure.
    >> So I think it’s important for us to tell a few things about our approach.
    >> 
    >> First what we have today in production:
    >> - TA software (offline box)
    >> - HSM for the TA (plus backups and spare parts)
    >> - A few application servers running our RPKI software - I’ll call it RPKI-Core
    >> - Redundant HSMs used by RPKI-Core
    >> - RRDP publication service (cloud)
    >> - Some rsync nodes (internal infra)
    >> 
    >> Something like the diagram below.
    >> 
    >> For testing environment we have practically the same infra.
    >> And for public test (localcert) we use ‘soft' keys and no HSMs.
    >> 
    >> 
    >> About the new AS0 TA, yes, we could simplify our infra.
    >> One option would be to use ‘soft’ keys all around or use a HSM for TA only.
    >> We could also use third-party software for TA, Core and publication service.
    >> It crossed my mind, for a fraction of a second, to skip AS0 TA instances for our internal and/or public test environments.
    >> 
    >> But I don’t think we should treat it as a "second class citizen".
    >> If we provide another TA, it’s worthy of receiving as much TLC as our production TA; meaning that it would also require the same (or similar) process around it as our production TA does. That includes keeping track of HSM card holders, defining a proper admin and operator quorum, scheduling periodical resigning sessions, etc…
    >> 
    >> I’m not here to advocate against nor in favour of AS0 TA.
    >> But when discussing our implementation, this was our rationale to duplicate the infrastructure.
    >> And that’s why it would cost us a lot to implement it.
    >> 
    >> Let me know you need more info about this subject.
    >> 
    >> Kind regards,
    >> Thiago da Cruz
    >> Sr. software engineer - RPKI Team
    >> RIPE NCC
    >> 
    >> 
    >>             +---------------------+
    >>             |                     |            +-------+
    >>             |    TA (offline)     +------------+  HSM  |
    >>             |                     |            +-------+
    >>             +---------------------+
    >> 
    >> 
    >> 
    >> 
    >>                                                                                                             +------------------------+
    >>                                                                                                             |                        |
    >>                                                                                              +----------->  |    RRDP publication    |
    >>                                                                                              |              |                        |
    >>                                                                                              |              |        (cloud)         |
    >>                                                                                              |              |                        |
    >>      +-------------------+             +-------------------+                                 |              +------------------------+
    >>      |                   |             |                   |          Publication            |
    >>      |    RPKI-Core 1    |    (...)    |    RPKI-Core n    |     ---------------------->  * +>
    >>      |                   |             |                   |                                 |
    >>      +--+-----+----+-----+             +--+------+-------+-+                                 |              +----------------------------+
    >>         |     |    |                      |      |       |                                   |              |                            |
    >>         |     |    +---------------+      |      |       |                                   |              |    Rsync publication       |
    >>         |     |                    |      |      |       +----+                              +----------->  |                            |
    >>   +-----+     +-----------+     +---------+      |            |                                             | (internal infra - x nodes) |
    >>   |                       |     |  |             |            |                                             |                            |
    >>   |                       |     |  +-------------------+      |                                             |                            |
    >>   |    +-----------------------------------------+     |      |                                             +----------------------------+
    >>   |    |                  |     |                      |      |
    >> +-+----+--+               +     +                    +-+------++
    >> |  HSM 1  |         (......................)         |  HSM m  |
    >> +---------+                                          +---------+
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    >> 
    >>> On 27 Feb 2020, at 23:51, George Michaelson <ggm _at_ algebras _dot_ org> wrote:
    >>> 
    >>> Anton pointed out I may have both misunderstood and not answered your question.
    >>> 
    >>> The testbed is a soft TA. In deployment, people will have to move to a
    >>> new (as yet not created) TAL for AS0, as long as it runs independently
    >>> of the mainline TAL.
    >>> 
    >>> We intend running a distinct TA for AS0 until we get a clear signal
    >>> our community wants it integrated. We have stated concerns about the
    >>> automatic adoption of ASO products worldwide without visible agreement
    >>> of this activity, a separate TAL turns the activity from opt-out to
    >>> opt-in.
    >>> 
    >>> We are duplicating the software signing infrastructure, but with lower
    >>> costs overall given commonalities.
    >>> 
    >>> We are still discussing if we can run the offline-TA HSM and the
    >>> online production key HSM for both activities, or if we need a
    >>> distinct infrastructure for AS0 and mainline. Duplication overall is
    >>> not in APNIC's model, we rely on spares and alternate use of the HSM,
    >>> but production signing systems are single instances. I believe they
    >>> are capable of some virtualisation or segmentation but that skirts the
    >>> underlying physical risk/dependency.
    >>> 
    >>> Sorry for not being clearer before
    >>> 
    >>> -George
    >>> 
    >>> On Wed, Feb 26, 2020 at 6:18 PM Carlos Friaças via routing-wg
    >>> <routing-wg _at_ ripe _dot_ net> wrote:
    >>> 
    >>> 
    >>>> 
    >>>> 
    >>>> Hi,
    >>>> 
    >>>> Any clue if APNIC has duplicated the infrastructure (and cost) as it is
    >>>> foreseen in the NCC's impact analysis...?
    >>>> 
    >>>> Carlos
    >>>> 
    >>>> 
    >>>> 
    >>>> On Wed, 26 Feb 2020, JORDI PALET MARTINEZ via routing-wg wrote:
    >>>> 
    >>>> 
    >>>> 
    >>>>> Hi Max,
    >>>>> 
    >>>>> I think is too early to take a decision, and in fact I don't think we are yet in case A.
    >>>>> 
    >>>>> Consensus is about justified objections. I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent.
    >>>>> 
    >>>>> The only justification that I can see is from Job about possible cost. However, I don't see figures about how much it cost to develop this AS0 + how much it cost the operators to use it (if they want) vs developing the SLURM + making sure it is secure as RPKI + how much ti cost the operators to use it.
    >>>>> 
    >>>>> And by the way, the AS0 is compatible with the SLURM, so opeartors can choose.
    >>>>> 
    >>>>> Regards,
    >>>>> Jordi
    >>>>> @jordipalet
    >>>>> 
    >>>>> 
    >>>>> 
    >>>>> El 25/2/20 20:30, "routing-wg en nombre de Massimiliano Stucchi" <routing-wg-bounces _at_ ripe _dot_ net en nombre de max _at_ stucchi _dot_ ch> escribió:
    >>>>> 
    >>>>> 
    >>>>>   Hi everyone,
    >>>>> 
    >>>>>   On 20/02/2020 15:39, Petrit Hasani wrote:
    >>>>> 
    >>>>> 
    >>>>> 
    >>>>>> As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document.
    >>>>>> 
    >>>>>> At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase.
    >>>>> 
    >>>>>   Today, me and the other proposers of this policy change had a meeting to
    >>>>>   discuss the feedback we have been receiving on the list.
    >>>>> 
    >>>>>   We understand that many people find this proposal controversial, and
    >>>>>   many have expressed themselves against it in the past days.
    >>>>> 
    >>>>>   We would like to encourage discussion and provide us with a bit of
    >>>>>   guidance on how the community would like to proceed.  At present we have
    >>>>>   identified three ways of progressing:
    >>>>> 
    >>>>>   A) We can try to go ahead with this proposal, although it will be hard
    >>>>>   to get consensus;
    >>>>> 
    >>>>>   B) We can drop the proposal, and leave everything as is;
    >>>>> 
    >>>>>   C) We can change the proposal to a different ask for RIPE NCC.  The idea
    >>>>>   could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC
    >>>>>   does), so that single users can decide if they want to feed it to their
    >>>>>   validators.
    >>>>> 
    >>>>>   From what we gathered in the discussions, I think B) could be the most
    >>>>>   sought-after decision, but we would like to propose C) as the way
    >>>>>   forward.  It would give the possibility to those who want to implement
    >>>>>   this solution to do it in a lightweight fashion.  It would for sure be
    >>>>>   much much cheaper to implement.
    >>>>> 
    >>>>>   In any case, as Job already pointed out, I prepared a simple tool to
    >>>>>   generate a SLURM file using either the Team Cymru bogons list, or
    >>>>>   considering any unassigned space from the NRO delegated stats file.
    >>>>>   RIPE NCC has kindly provided help and patches to improve it.  If you
    >>>>>   want to give it a go, you can find it here:
    >>>>> 
    >>>>>   https://github.com/stucchimax/rpki-as0-bogons
    >>>>> 
    >>>>>   Thank you for any suggestion or any discussion around this.
    >>>>> 
    >>>>>   Ciao!
    >>>>>   --
    >>>>>   Massimiliano Stucchi
    >>>>>   MS16801-RIPE
    >>>>>   Twitter/Telegram: @stucchimax
    >>>>> 
    >>>>> 
    >>>>> 
    >>>>> 
    >>>>> 
    >>>>> **********************************************
    >>>>> IPv4 is over
    >>>>> Are you ready for the new Internet ?
    >>>>> http://www.theipv6company.com
    >>>>> The IPv6 Company
    >>>>> 
    >>>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
    >>>>> 
    >>>>> 
    >>>>> 
    >>>>> 
    >>>>> 
    >>>>> 
    >>> 
    >> 
    >> 
    >> 
    >> 
    >> **********************************************
    >> IPv4 is over
    >> Are you ready for the new Internet ?
    >> http://www.theipv6company.com
    >> The IPv6 Company
    >> 
    >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
    > 
    > 
    > **********************************************
    > IPv4 is over
    > Are you ready for the new Internet ?
    > http://www.theipv6company.com
    > The IPv6 Company
    > 
    > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.





User Image

Jordi Palet Martinez

2020-03-03 19:31:57 CET

Hi Job,

I don't think I'm the one that should calculate that. However, if we have an alternative proposal with the SLURM file,  it can be calculated (approximately) as part of the analysis impact that will be needed as well, right?

May be anyone from the community that already has done that job and integrated the SLURM in their routers, can provide an estimate cost, and then multiply it for the number of all the RIRs members?

I believe (I may be wrong) that the AS0 is much cheaper to implement by RIPE NCC even if it is several thousand euros, than the number of worldwide folks that will need to use the SLURM in addition to RPKI (for non-AS0).

Regards,
Jordi
@jordipalet
 
 

El 3/3/20 19:23, "Job Snijders" <job _at_ sobornost _dot_ net> escribió:

    Hi Jordi,
    
    On Tue, Mar 3, 2020, at 19:20, JORDI PALET MARTINEZ via routing-wg wrote:
    > I understand that, but I think it may be easy to get an idea, not exact cost.
    > 
    > The reason why this is needed is because one of the arguments against 
    > this proposal is about the cost.
    > 
    > This can't be judged as a valid objection for reaching consensus if we 
    > don't have that cost (approximate).
    
    Can you provide us with an estimate of the cost to the collective community if this proposal is *not* implemented as RPKI ROAs but just as SLURM file instead?
    
    Kind regards,
    
    Job
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.





User Image

Job Snijders

2020-03-03 19:41:44 CET

Hi,

On Tue, Mar 3, 2020, at 19:31, JORDI PALET MARTINEZ via routing-wg wrote:
> I don't think I'm the one that should calculate that. However, if we 
> have an alternative proposal with the SLURM file,  it can be calculated 
> (approximately) as part of the analysis impact that will be needed as 
> well, right?
> 
> May be anyone from the community that already has done that job and 
> integrated the SLURM in their routers, can provide an estimate cost, 
> and then multiply it for the number of all the RIRs members?
> 
> I believe (I may be wrong) that the AS0 is much cheaper to implement by 
> RIPE NCC even if it is several thousand euros, than the number of 
> worldwide folks that will need to use the SLURM in addition to RPKI 
> (for non-AS0).

Let me rephrase: what is the cost to the community of no implementation of 2019-08 at all?

It has been mentioned before that 2019-08 in its current shape seems way too big of a hammer for the problem it claims to solve. I personally consider a SLURM file a good middle-ground, but if it boils down either using the RPKI for this or nothing, the latter option is what I support.

Kind regards,

Job

Nick Hilliard

2020-03-03 20:03:38 CET

Job Snijders wrote on 03/03/2020 18:41:
> Let me rephrase: what is the cost to the community of no
> implementation of 2019-08 at all?
> 
> [...] but if it
> boils down either using the RPKI for this or nothing, the latter
> option is what I support.

Pretty much that.

They've made it clear that the costs will be substantial, including:

- duplication of the entire RPKI infrastructure
- 6m wall clock time for some of the software team
- additional internal / external processes + documentation

This isn't a small undertaking - it's substantial. Set against that, the 
benefit to the proposal is marginal at best, and harmful in some 
important respects.

On top of that, it isn't reasonable for people to hit the RIPE NCC with 
requests to do more and more ground work on an impact analysis for 
proposals where it's far from clear that's any consensus to start with.

Nick

User Image

Randy Bush

2020-03-03 22:34:15 CET

>> Let me rephrase: what is the cost to the community of no
>> implementation of 2019-08 at all?
>> 
>> [...] but if it boils down either using the RPKI for this or nothing,
>> the latter option is what I support.
> 
> Pretty much that.

yep

but ...

> They've made it clear that the costs will be substantial, including:
> - duplication of the entire RPKI infrastructure
> - 6m wall clock time for some of the software team
> - additional internal / external processes + documentation

would this duplication of infrastructure actually be needed or useful?
the american idiom is "making a mountain out of a molehill"

randy

George Michaelson

2020-03-04 02:30:42 CET

As a point of information, APNIC secretariat is  still considering
what to do here, having direction from the membership to run AS0 but
open issues around how we do that operationally.

We got to a split TA. The community seemed ok with that. We got to the
model of how we're deploying. We have a testbed. What actual "live"
deployment looks like is still a bit un-baked.

HSM: Back the AS0 on a real HSM or not (ie "soft" TA keypair)
pro: things we say in AS0 should be considered as important as things
we see on mainline
con: its a huge investment for something the community is considering
marginal value compared to e.g. SLURM file. Soft TA may simply be more
appropriate.

Shared HSM vs independent HSM: Do we duplicate systems or re-use the
same platform?
pro: cheaper to share.
con: shared fate! if you operationally mistake things on the AS0
"side" of the shared systems, and its in FIPS mode, is the non-AS0
side now lost because of it ? that is bad.

I tend to saying "if we HSM, and cannot ensure its a virtual slice
with no real risk of information/key loss, then re-using the same HSM
is a higher risk than I like" which drives to a higher cost, but more
safe.

Overall I prefer less interaction on the TA. I want to do as little on
the TA as sensible. I don't want to share fate if I can avoid it,
purely from a risk management perspective.

If I got feedback in my community they don't feel this needs HSM
backing, I can avoid the problem.

I probably need to go seek that in the right space for APNIC but I
welcome the consensus emerging here, it is very helpful to me.

-George

On Wed, Mar 4, 2020 at 7:34 AM Randy Bush <randy _at_ psg _dot_ com> wrote:
>
> >> Let me rephrase: what is the cost to the community of no
> >> implementation of 2019-08 at all?
> >>
> >> [...] but if it boils down either using the RPKI for this or nothing,
> >> the latter option is what I support.
> >
> > Pretty much that.
>
> yep
>
> but ...
>
> > They've made it clear that the costs will be substantial, including:
> > - duplication of the entire RPKI infrastructure
> > - 6m wall clock time for some of the software team
> > - additional internal / external processes + documentation
>
> would this duplication of infrastructure actually be needed or useful?
> the american idiom is "making a mountain out of a molehill"
>
> randy
>

User Image

Randy Bush

2020-03-04 05:13:03 CET

but, ggm, you did not actualy respond to the message to which you were
replying.

>> would this duplication of infrastructure actually be needed or useful?
>> the american idiom is "making a mountain out of a molehill"

randy

User Image

Carlos Friacas

2020-03-04 08:23:08 CET


George, many thanks for your input.
(please see inline)


On Wed, 4 Mar 2020, George Michaelson wrote:

> As a point of information, APNIC secretariat is  still considering
> what to do here, having direction from the membership to run AS0 but
> open issues around how we do that operationally.

Unfortunately, you will only "run AS0" over non-distributed APNIC space.

If you were able to do it for the full problem space, those who will 
continue to explore this weakness in the global routing system would not 
have an excellent alternative by simply choosing to abuse non-distributed 
space by the other RIRs...



> We got to a split TA. The community seemed ok with that. We got to the
> model of how we're deploying. We have a testbed. What actual "live"
> deployment looks like is still a bit un-baked.
>
> HSM: Back the AS0 on a real HSM or not (ie "soft" TA keypair)
> pro: things we say in AS0 should be considered as important as things
> we see on mainline
> con: its a huge investment for something the community is considering
> marginal value compared to e.g. SLURM file. Soft TA may simply be more
> appropriate.

Maybe the SLURM file trade-off is a good one (and it's availability seems 
inevitably positive), but if RPKI's takeup is slow, the SLURM file 
usage will be even slower... :-(



> Shared HSM vs independent HSM: Do we duplicate systems or re-use the
> same platform?
> pro: cheaper to share.
> con: shared fate! if you operationally mistake things on the AS0
> "side" of the shared systems, and its in FIPS mode, is the non-AS0
> side now lost because of it ? that is bad.
>
> I tend to saying "if we HSM, and cannot ensure its a virtual slice
> with no real risk of information/key loss, then re-using the same HSM
> is a higher risk than I like" which drives to a higher cost, but more
> safe.

Fully agree.
"Safe" (or "safer") generally comes with a price tag...



> Overall I prefer less interaction on the TA. I want to do as little on
> the TA as sensible. I don't want to share fate if I can avoid it,
> purely from a risk management perspective.
>
> If I got feedback in my community they don't feel this needs HSM
> backing, I can avoid the problem.
>
> I probably need to go seek that in the right space for APNIC but I
> welcome the consensus emerging here, it is very helpful to me.

Will abstain to comment about consensus :-)


Regards,
Carlos


> -George
>

User Image

Robert Kisteleki

2020-03-04 10:49:11 CET

RIPE NCC staff member

> If I got feedback in my community they don't feel this needs HSM
> backing, I can avoid the problem.

That sounds logical. It leads me to the question: what's the threat
model for protecting the "RIR AS0 key"? In other words what happens if
an attacker can sign stuff (CAs, ROAs, ...) of their choosing with it
[1]? Depending on the severity of scenarios in the answer [2], the use
of HSM for the TA may or may not make a difference.

Robert

[1] note that in order to "sign stuff of their choosing" does not mean
they need to get the key (which is of course harder when using an HSM).
They only need to convince the system to sign the attacker's blobs,
which is a very different problem.

[2] random ideas:
* does the AS0 TA cover 0/0 or only the unallocated space?
* If someone makes a non-AS0 ROA under this TA, how does that interact
with a ROA from under a different TA?
* does this whole thing matter if some address space (ie. from other
RIRs) is not covered by an AS0 TA anyway?

User Image

Robert Kisteleki

2020-03-04 10:57:40 CET

RIPE NCC staff member


On 2020-03-04 08:23, Carlos Friaças via routing-wg wrote:

> Maybe the SLURM file trade-off is a good one (and it's availability
> seems inevitably positive), but if RPKI's takeup is slow, the SLURM file
> usage will be even slower... :-(

I'm more optimistic. If SLURM is the chosen path, then support for it
only need to materialise in RPKI software -- which I'm pretty sure it
will, since maintainers of said software know what they are doing and
they are generally responsive to user needs.

Robert

User Image

Carlos Friacas

2020-03-04 11:22:22 CET

Hi Robert, All,

My main issue was about every netadmin (i.e. each ASN) having to do 
something alongside RPKI. If the info about unallocated/unassigned can be 
kicked-in at the RPKI software level, that will make life easier for each 
ASN-admin -- i.e. only need to worry about running RPKI and fine 
tune it...

Thanks for raising my optimism!

Cheers,
Carlos


On Wed, 4 Mar 2020, Robert Kisteleki wrote:

>
>
> On 2020-03-04 08:23, Carlos Friaças via routing-wg wrote:
>
>> Maybe the SLURM file trade-off is a good one (and it's availability
>> seems inevitably positive), but if RPKI's takeup is slow, the SLURM file
>> usage will be even slower... :-(
>
> I'm more optimistic. If SLURM is the chosen path, then support for it
> only need to materialise in RPKI software -- which I'm pretty sure it
> will, since maintainers of said software know what they are doing and
> they are generally responsive to user needs.
>
> Robert
>

Nick Hilliard

2020-03-04 12:36:55 CET

Carlos Friaças via routing-wg wrote on 04/03/2020 07:23:
> Unfortunately, you will only "run AS0" over non-distributed APNIC space.
> 
> If you were able to do it for the full problem space, those who will 
> continue to explore this weakness in the global routing system would not 
> have an excellent alternative by simply choosing to abuse 
> non-distributed space by the other RIRs...

Carlos,

are you seriously suggesting that APNIC or any other RIR should use a 
TAL for 0/0 to claim authority over unallocated space from other RIRs?

This would be an extraordinary breach of trust in the RIR community.

Nick

Nick Hilliard

2020-03-04 12:45:54 CET

Randy Bush wrote on 03/03/2020 21:34:
> would this duplication of infrastructure actually be needed or useful?
> the american idiom is "making a mountain out of a molehill"

would the TAL be for 0/0 and ::/0?  What's the PKI trust model for this 
arrangement?

Nick

Job Snijders

2020-03-04 12:56:10 CET

On Wed, Mar 04, 2020 at 11:36:55AM +0000, Nick Hilliard wrote:
> Carlos Friaças via routing-wg wrote on 04/03/2020 07:23:
> > Unfortunately, you will only "run AS0" over non-distributed APNIC space.
> > 
> > If you were able to do it for the full problem space, those who will
> > continue to explore this weakness in the global routing system would not
> > have an excellent alternative by simply choosing to abuse
> > non-distributed space by the other RIRs...
> 
> are you seriously suggesting that APNIC or any other RIR should use a TAL
> for 0/0 to claim authority over unallocated space from other RIRs?
> 
> This would be an extraordinary breach of trust in the RIR community.

Should any RIR would start interfering with potentially unassigned or
unallocated resources from another RIR in such a manner, I'd consider
the RIR CA akin to compromised and suggest to remove the associated TAL
from our RPKI Cache Validators. Thus the outlined approach would result
in negative impact for the NIRs and LIRs under that RIR CA in the
affected region, but probably outweighs the complications of one RIR
claiming space is Unassigned/Unallocated while the actual managing RIR
might think otherwise.

In short, this would be a misuse of the current certificate structure
that that implemented 0.0.0.0/0 + ::/0 to facilitate inter-RIR
transfers. That mechanism was not intended to help RIRs step on each
other's toes.

Let's continue to focus on deploying RPKI Origin Validation as-is on all
Internet EBGP sessions first. At best it seems premature to overload the
functionality of the RPKI in this way.

Kind regards,

Job

User Image

Randy Bush

2020-03-04 17:38:31 CET

>> would this duplication of infrastructure actually be needed or
>> useful?  the american idiom is "making a mountain out of a molehill"
> would the TAL be for 0/0 and ::/0?

in their arrogance, the rirs already do that :(

randy

Nick Hilliard

2020-03-04 17:45:11 CET

Randy Bush wrote on 04/03/2020 16:38:
> in their arrogance, the rirs already do that :(

this is the problem.  If the TAL covers all address space then it needs 
to be handled carefully and Thiago's email from a couple of days ago 
outlined their rationale why.

If TAL doesn't cover all address space then it's much easier, but that 
makes transfers difficult.

Nick

User Image

Randy Bush

2020-03-04 18:01:14 CET

>> in their arrogance, the rirs already do that :(
> 
> this is the problem.  If the TAL covers all address space then it
> needs to be handled carefully and Thiago's email from a couple of days
> ago outlined their rationale why.
> 
> If TAL doesn't cover all address space then it's much easier, but that
> makes transfers difficult.

not exactly.  what makes transfers (and this) difficult is the rirs
pissing contest with the iana.  more arrogance, on both parts; to the
detriment of the internet.

randy

User Image

Randy Bush

2020-03-04 20:21:38 CET

while i am tempted toward the slurm approach, i wonder what
authenticates the slurm file(s)?

randy

User Image

Carlos Friacas

2020-03-04 21:28:29 CET

On Wed, 4 Mar 2020, Nick Hilliard wrote:

> Carlos Friaças via routing-wg wrote on 04/03/2020 07:23:
>> Unfortunately, you will only "run AS0" over non-distributed APNIC space.
>> 
>> If you were able to do it for the full problem space, those who will 
>> continue to explore this weakness in the global routing system would not 
>> have an excellent alternative by simply choosing to abuse non-distributed 
>> space by the other RIRs...
>
> Carlos,
>
> are you seriously suggesting that APNIC or any other RIR should use a TAL for 
> 0/0 to claim authority over unallocated space from other RIRs?

Nick, All,

What did cross my mind was that if *one* RIR was going to double the 
not-so-cheap infrastructure, maybe, with enough levels of coordination 
with other RIRs (and a cost-sharing model), the cost could be (globally) 
smaller.

i.e. ((1+1) x 5 RIRs) vs. ((1 x 5 RIRs) + 1 by APNIC).


> This would be an extraordinary breach of trust in the RIR community.

Between RIR communities?

I wonder what would happen if *one* community at some point decides to ask 
their RIR to "please throw in also the unallocated/unassigned blocks 
(junk) from other RIRs, while you are at it" :-)


Carlos


> Nick
>

Nick Hilliard

2020-03-04 22:06:36 CET

Carlos Friaças wrote on 04/03/2020 20:28:
> I wonder what would happen if *one* community at some point decides to 
> ask their RIR to "please throw in also the unallocated/unassigned blocks 
> (junk) from other RIRs, while you are at it" :-)

apart from causing a political supernova at all the other RIRs?

Job answered this question earlier today.

Nick

User Image

Jordi Palet Martinez

2020-03-04 22:42:13 CET

Hi Job,

If someone want to ignore people using bogons for bad things, then of course, they have "no cost", but in general I believe most of the operators use someway to filter bogons.

RPKI can help on that. RPKI is a secure and automated way to have that information.

The SLURM file is not secure. We can of course find the way to secure it, but that keep increasing the cost of using it (and publishing it).

El 3/3/20 19:42, "routing-wg en nombre de Job Snijders" <routing-wg-bounces _at_ ripe _dot_ net en nombre de job _at_ instituut _dot_ net> escribió:

    Hi,
    
    On Tue, Mar 3, 2020, at 19:31, JORDI PALET MARTINEZ via routing-wg wrote:
    > I don't think I'm the one that should calculate that. However, if we 
    > have an alternative proposal with the SLURM file,  it can be calculated 
    > (approximately) as part of the analysis impact that will be needed as 
    > well, right?
    > 
    > May be anyone from the community that already has done that job and 
    > integrated the SLURM in their routers, can provide an estimate cost, 
    > and then multiply it for the number of all the RIRs members?
    > 
    > I believe (I may be wrong) that the AS0 is much cheaper to implement by 
    > RIPE NCC even if it is several thousand euros, than the number of 
    > worldwide folks that will need to use the SLURM in addition to RPKI 
    > (for non-AS0).
    
    Let me rephrase: what is the cost to the community of no implementation of 2019-08 at all?
    
    It has been mentioned before that 2019-08 in its current shape seems way too big of a hammer for the problem it claims to solve. I personally consider a SLURM file a good middle-ground, but if it boils down either using the RPKI for this or nothing, the latter option is what I support.
    
    Kind regards,
    
    Job
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.





User Image

Jordi Palet Martinez

2020-03-04 22:50:50 CET

In my presentation in APNIC, I suggested that as a possible option.

Why not? There is a lot of cooperation among the RIRs, and this may be one more way to do so.

Or this may be run somehow via the NRO, or we can ask IANA to do it for the NRO.

If we don't trust in the cooperation among the RIRs, then is better we close the doors of all the RIRs and go to the wild west.

I also suggested one more action.

Even if all the 5 RIRs adopt this policy, there is space still unallocated space on the hands of IANA, specially for IPv6. I'm considering drafting a global policy for that. This global policy in fact, could be done even if the policy is not adopted in all the RIRs, but of course I think it will be then more difficult to reach consensus.

Another possible alternative is doing it from the IETF (so the IETF instructs IANA to do it).



 

El 4/3/20 12:37, "routing-wg en nombre de Nick Hilliard" <routing-wg-bounces _at_ ripe _dot_ net en nombre de nick _at_ foobar _dot_ org> escribió:

    Carlos Friaças via routing-wg wrote on 04/03/2020 07:23:
    > Unfortunately, you will only "run AS0" over non-distributed APNIC space.
    > 
    > If you were able to do it for the full problem space, those who will 
    > continue to explore this weakness in the global routing system would not 
    > have an excellent alternative by simply choosing to abuse 
    > non-distributed space by the other RIRs...
    
    Carlos,
    
    are you seriously suggesting that APNIC or any other RIR should use a 
    TAL for 0/0 to claim authority over unallocated space from other RIRs?
    
    This would be an extraordinary breach of trust in the RIR community.
    
    Nick
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.