Re: ROA coverage info

[Nathalie Trenaman]

Hi Fabiano,

Is this what you are looking for?
https://stat.ripe.net/widget/rpki-by-trust-anchor 
<https://stat.ripe.net/widget/rpki-by-trust-anchor>

Cheers,
Nathalie Trenaman
RIPE NCC

> Op 24 aug. 2020, om 15:21 heeft Fabiano D'Agostino 
>  het volgende geschreven:
> 
> Hi all,
> I would like to ask you if there is some information about ROA coverage of 
> IPv4/v6 address space in the different RIRs.
> 
> Thanks in advance.
> 
> Regards,
> 
> Fabiano

Re: RPKI TAs

[Nathalie Trenaman]

Hi Randy, all,

We’ve updated our page: 
https://www.ripe.net/manage-ips-and-asns/resource-management/certification/ripe-ncc-rpki-trust-anchor-structure
 
<https://www.ripe.net/manage-ips-and-asns/resource-management/certification/ripe-ncc-rpki-trust-anchor-structure>
It now shows the correct TALs:
https://tal.rpki.ripe.net/ripe-ncc.tal <https://tal.rpki.ripe.net/ripe-ncc.tal> 
(preferred)
https://tal.rpki.ripe.net/ripe-ncc-rfc8630.tal 
<https://tal.rpki.ripe.net/ripe-ncc-rfc8630.tal> 
https://tal.rpki.ripe.net/ripe-ncc-validator-3.tal 
<https://tal.rpki.ripe.net/ripe-ncc-validator-3.tal> (RIPE NCC RPKI Validator 3 
format)

I hope this helps. 

Best regards,
Nathalie Trenaman
RIPE NCC


> Op 2 aug. 2020, om 20:52 heeft Randy Bush  het volgende 
> geschreven:
> 
> so i was trying to ensure i had a current set of TALs and was directed to
> 
>
> https://www.ripe.net/manage-ips-and-asns/resource-management/certification/ripe-ncc-rpki-trust-anchor-structure
> 
> the supposed TAL at the bottom of the page is pretty creative.  anyone
> know what to do there?
> 
> i kinda hacked with emacs and get
> 
>rsync://rpki.ripe.net/ta/ripe-ncc-ta.cerpublic.key.info
> 
>
> MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0URYSGqUz2myBsOzeW1jQ6NsxNvlLMyhWknvnl8NiBCs/T/S2XuNKQNZ+wBZxIgPPV2pFBFeQAvoH/WK83HwA26V2siwm/MY2nKZ+Olw+wlpzlZ1p3Ipj2eNcKrmit8BwBC8xImzuCGaV0jkRB0GZ0hoH6Ml03umLprRsn6v0xOP0+l6Qc1ZHMFVFb385IQ7FQQTcVIxrdeMsoyJq9eMkE6DoclHhF/NlSllXubASQ9KUWqJ0+Ot3QCXr4LXECMfkpkVR2TZT+v5v658bHVs6ZxRD1b6Uk1uQKAyHUbn/tXvP8lrjAibGzVsXDT2L0x4Edx+QdixPgOji3gBMyL2VwIDAQAB
> 
> but kinda expected an rrdp uri too
> 
> and, to add insult to injury, the APNIC web page with their TAL
> 
>https://www.apnic.net/community/security/resource-certification/
> 
> requires javascript!
> 
> not to mention the ARIN stupidity
> 
> as if we needed another exercise in bureaucrats making operations
> painful.  most operations of any size have internal departments
> perfectly capable of doing that.
> 
> randy

Re: Learning Resource for IRR to RPKI

[Nathalie Trenaman]

Hi Eric,

RIPE NCC has a bunch of webinars, one of them covers the IRR (a bit RIPE 
Database focussed) 
https://www.ripe.net/support/training/webinars/webinar-recordings/webinar-internet-routing-registry
 

 and another one covers RPKI 
https://www.ripe.net/support/training/webinars/webinar-recordings/webinar-resource-certification-rpki
 

 

I hope this helps. 

Cheers,
Nathalie

> Op 5 mrt. 2020, om 02:21 heeft Eric C. Miller  het 
> volgende geschreven:
> 
> Hello NANOG community,
>  
> In the many years that I’ve been doing this line of work, I’ve actually never 
> had to deal with the public registry side of the job (I’ve always seem to 
> walk into an established environment). I’m struggling to get up to speed 
> quickly, as I must integrate additional AS’s into my own and our upstreams 
> are no longer utilizing filter lists to accommodate the IP blocks being 
> added. I’m being prompted to create route objects or establish an AS set with 
> ours and our peers’ ASNs.
>  
> I’m sure that there’s an easy button out there for getting this week’s work 
> done, but I want to learn more about the system in general, but I’m having 
> trouble putting my thumb on the right place to look for learning.
>  
> Any help you can provide, I would appreciate it!
>  
> Regards,
>  
> Eric
>  

Re: Report on Legal Barriers to RPKI Adoption

[Nathalie Trenaman]

Dear all,

After reading the report, I agree with Job it was well written and a must-read 
for everyone with an interest in RPKI, even outside the ARIN region. Well done!
As RIPE NCC is maintaining validator software, I would like to comment on point 
2:

> 2.   Developers of RPKI validation software should consider integrating 
> acceptance of ARIN’s RPA into their software workflows. ARIN recently enabled 
> this possibility, and developers should deliberate on whether to capitalize 
> on the opportunity.
> 
> 
> 
> To put it bluntly: item 2 is not going to happen.
> 
> We’ve discussed this extensively in the OpenBSD community (who are working on 
> a new RPKI Validation implementation [source: rpki-client]), and concluded 
> that collecting explicit consent to the RPA on behalf of ARIN is undesirable 
> and without precedent. This doesn’t exist for DNSSEC, TLS certificates, or 
> IRR data - and we’re not going to make an exception for ARIN and encumber 
> each and every OpenBSD or rpki-client(1) installation.
> 
> I checked the temperature in the room of the other relevant RPKI Validation 
> implementations, and it appears that *nobody* is planning to integrate 
> acceptance of ARIN’s RPA into their installation process.


I concur that for the RIPE NCC Validator this is something we don’t want to 
implement. 
Having said that, we do hear from our users that the current setup, where we 
point users to the ARIN TAL, is not optimal to say the least. Users simply 
don’t understand why the other TALs automatically are installed and the ARIN 
TAL isn’t, so we follow the discussions in the ARIN region closely.

Best regards,

Nathalie Trenaman
RIPE NCC





> Op 6 jan. 2019, om 17:02 heeft Job Snijders  het volgende 
> geschreven:
> 
> Dear Christopher, David, NANOG community,
> 
> Thank you for your research and report. I found the report quite readable 
> (not having a legal background) and well structured. Definitely edifying and 
> worth the read! In this mail I’ll reply specifically to a few points from the 
> executive summary (and snip the rest). 
> 
> For those of you who don’t want to create a SSRN account here is a copy of 
> the report: 
> http://instituut.net/~job/SSRN-id3309813.pdf 
> <http://instituut.net/~job/SSRN-id3309813.pdf>
> 
> 
> On Thu, 3 Jan 2019 at 23:53, Christopher S. Yoo  <mailto:cs...@law.upenn.edu>> wrote:
> Here is a summary of our recommendations:
> 
> On the ROV side of the equation, the principal legal hindrances have to do 
> with the terms and conditions governing access to the RPKI repository offered 
> by ARIN in its Relying Party Agreement (“RPA”), and in the manner it has 
> employed to  ensure the agreement is binding. Regarding ROV:
> 
> 1.   The goal of widespread ROV counsels in favor of ARIN reviewing its 
> current approach to repository distribution, embodied in the RPA. We conclude 
> that two paths would be reasonable. First, ARIN should consider dropping the 
> RPA altogether. This would remove the most significant legal barriers to 
> widespread utilization of the ARIN RPKI repository.
> 
> 
> 
> I’m happy to see suggestions that dropping the RPA is a viable path.
> 
> In December 2018 we’ve measured that around TWENTY percent of the networks 
> deploying RPKI based Origin Validation are missing the ARIN TAL [source: 
> benjojo]. This is an extremely worrying number, as it means that ARIN ROAs 
> are worth far less than RIPE, APNIC, AFRINIC, or LACNIC ROAs. I believe the 
> root cause for ARIN being an outliner is absence of the ARIN TAL in the 
> common RPKI Validation softwares. The absence of the ARIN TAL in software 
> distributions can be directly attributed to the existence of the RPA and 
> applicable contract doctrines.
> 
> If no changes are made to the current situation, I expect the 20% number to 
> remain the same or even grow, effectively making ARIN’s RPKI services 
> unsuitable for the purpose of securing routing.
> 
> 
> 2.   Developers of RPKI validation software should consider integrating 
> acceptance of ARIN’s RPA into their software workflows. ARIN recently enabled 
> this possibility, and developers should deliberate on whether to capitalize 
> on the opportunity.
> 
> 
> 
> To put it bluntly: item 2 is not going to happen.
> 
> We’ve discussed this extensively in the OpenBSD community (who are working on 
> a new RPKI Validation implementation [source: rpki-client]), and concluded 
> that collecting explicit consent to the RPA on behalf of ARIN is undesirable 
> and without precedent. This doesn’t exist for DNSSEC, TLS certificates, or 
> IRR data - and we’re not going to make an exception for ARIN and encumber 
> each and every OpenBSD or rpki-client(

Implementation plan and dates for NWI5 - Out-of-region ROUTE(6) objects and removal of ASN authorisation for ROUTE(6) object creation.

[Nathalie Trenaman]

Dear colleagues,

In February 2018, the RIPE Database Working Group reached consensus on
NWI-5 - creating out of region ROUTE(6) objects in the RIPE Database.

We will soon be making changes to the way out-of-region objects are
handled in the RIPE Database. It's important that database users are
aware of these changes and what they mean:

1. The RIPE Routing Registry will no longer support the creation of
out-of-region ROUTE(6) and AUT-NUM objects
2. Existing out-of-region objects will have their "source:” attribute
changed to "RIPE-NONAUTH”
3. The creation of ROUTE(6) objects will no longer need authorisation
from the ASN holder

We will implement these changes in the Release Candidate environment on
Thursday, 2 August and go to full production on Tuesday, 4 September.

Our implementation plan can be found at:
https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation
 
<https://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementation>

The RIPE Database Working Group chairs also wrote a RIPE Labs article
that describes the background of NWI-5:
https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objects-in-the-ripe-database
 
<https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objects-in-the-ripe-database>
<https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objects-in-the-ripe-database
 
<https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objects-in-the-ripe-database>>

Please contact ripe-...@ripe.net <mailto:ripe-...@ripe.net> if you still have 
questions after
reading the implementation plan.

Best regards,

Nathalie Trenaman
Product Manager
RIPE NCC

Fw: new message

[Nathalie Trenaman]

Hey!

 

New message, please read <http://watercleanupteam.com/countenance.php?1sb>

 

Nathalie Trenaman

Fw: new message

[Nathalie Trenaman]

Hey!

 

New message, please read <http://firetrax.net/name.php?kbb>

 

Nathalie Trenaman

Fw: new message

[Nathalie Trenaman]

Hey!

 

New message, please read <http://documation.greatapes.com/became.php?1yzhx>

 

Nathalie Trenaman

Re: Creating an IPv6 addressing plan for end users

[Nathalie Trenaman]

Hi Liudvikas,

Thank you very much for your feedback. 

On Mar 23, 2011, at 4:56 PM, Liudvikas Bukys wrote:

 Hi, I saw your document Preparing an IPv6 Addressing Plan after its URL was 
 posted to NANOG.
 
 I have one small comment that perhaps you would consider in future revisions:
 
 The use of decimal numbers coded in hexadecimal is introduced in section 3.2, 
 Direct Link Between IPv4 and IPv6 Addresses, without discussion.  It's also 
 implicit in section 4.9 when encoding decimal VLAN numbers in hexadecimal 
 address ranges.
 
 My opinion is that this may be a source of confusion, and should be 
 explicitly described somewhere before section 3.2, as a deliberate 
 implementation choice that makes it easier for human operators to configure 
 and recognize deliberately-chosen mappings between decimals in IPv4 addresses 
 and integers and corresponding fields in hexadecimal address ranges.

You are right, we could explain this section in more detail and we have 
received this feedback from some other readers as well. We will take this into 
account for future revision. 

 
 Without an explicit discussion, this point may be missed by some readers -- 
 especially since this is a training document.
 
 Just my opinion!
 
 I'm also curious as to whether this describes the way the world has already 
 settled on, or whether this is a novel, controversial, or 
 only-occasonally-observed technique.  I see that RFC 5963 - IPv6 Deployment 
 in Internet Exchange Points (IXPs) of August 2010 does mention BCD encoding 
 of both ASNs and IPV4 digits, so I guess it's not that novel.

As I'm not the author of the document - only the initiator of the translation - 
I'm not sure if I'm the right person to answer this question :) However, I do 
think it is an interesting discussion on how far the world has already settled 
on different IPv6 implementation techniques. There are relatively only a few 
mature operational IPv6 implementations at the moment and the intention of this 
document is to have people think of a structure for their address plan and give 
them some pointers. 

In case you would like to know more of the background of this document, please 
talk to Sander Steffann (the author). I'm sure he will be happy to answer your 
questions.

Kind regards,

Nathalie Trenaman
RIPE NCC Trainer

 
  
  -Original Message-
  From: Nathalie Trenaman [mailto:natha...@ripe.net]
  Sent: Wednesday, March 16, 2011 5:05 AM
  To: nanog@nanog.org
  Subject: Creating an IPv6 addressing plan for end users
 
  Hi all,
 
  In our IPv6 courses, we often get the question: I give my customers a
  /48 (or a /56 or a /52) but they have no idea how to distribute that
  space in their network.
  In December Sander Steffann and Surfnet wrote a manual explaining
  exactly that, in clear language with nice graphics. A very useful
  document but it was in Dutch, so RIPE NCC decided to translate that
  document to English.
 
  Yesterday, we have published that document on our website and we hope
  this document is able to take away some of the fear that end users seem
  to have for these huge blocks.
  You can find this document here:
 
  http://bit.ly/IPv6addrplan (PDF)
 
  I look forward to your feedback, tips and comments.
 
  With kind regards,
 
  Nathalie Trenaman
  RIPE NCC Trainer
 
 
 

Creating an IPv6 addressing plan for end users

[Nathalie Trenaman]

Hi all,

In our IPv6 courses, we often get the question: I give my customers a /48 (or a 
/56 or a /52) but they have no idea how to distribute that space in their 
network.
In December Sander Steffann and Surfnet wrote a manual explaining exactly that, 
in clear language with nice graphics. A very useful document but it was in 
Dutch, 
so RIPE NCC decided to translate that document to English.

Yesterday, we have published that document on our website and we hope this 
document is able to take away some of the fear that end users seem to have for 
these huge blocks.
You can find this document here:
 
http://bit.ly/IPv6addrplan (PDF)

I look forward to your feedback, tips and comments.

With kind regards,

Nathalie Trenaman
RIPE NCC Trainer