Re: ROA mirror to IRR?

[Vincent Bernat]

 ❦ 26 October 2021 10:17 -10, Shawn:

> Curious if any IRR databases are mirroring/importing ROA data - creating
> route|6 objects from ROA?

This is a feature of IRRd 4: https://irrd.readthedocs.io/en/stable/admins/rpki/

> IRR questions:
> How do most large networks maintain (automate) their IRR records?
> Is it standard practice to accept more specifics (append IPv4 "le /24" and
> IPv6 "le /48")?
>  Or is it expected to have one IRR route per BGP announcement?

IMO, many accept more specifics, but you shouldn't rely on this under
normal circumnstance.
-- 
Make sure input cannot violate the limits of the program.
- The Elements of Programming Style (Kernighan & Plauger)

Re: . (was IPv6 and CDN's)

[John Levine]

It appears that Bryan Fields  said:
>Can you explain how it would work?  Say you have a root server operator who
>starts messing up, is there any ability to remove them?

Nope.  We are fortunate that for over 30 years the root servers have all been
competent and reliable.

>> It’s a hard question, but it isn't the folks at IANA who answer it.
>
>Who does?  Doesn't IANA designate root servers and the . zone?

The root servers are basically the people who have always run the root servers,
give or take a few changes due to mergers and a few additions over a decade ago
to get better geographic diversity.

R's,
John

FORT monitoring/visibility

[Randy Bush]

i run a FORT RPKI relying party instance.  i am looking for some
visibility into its operation.

  is it up: both ways, fetching and serving routers?

  from what CAs has it pulled, how recently and frequently with
  what success?

  what routers is it serving with rpki-rtr 323?

  blah blah blah

my old DRL RP instances produce MRTG graphs etc of the CA
fetching side, though nothing on the rpki-rtr side.

randy

---

https://seclists.org/nanog/2021/Jun/259 and ggm's excellent
decoding thereof,
https://blog.apnic.net/2021/07/15/some-handy-roa-advice-from-randy-bush/

Re: ROA mirror to IRR?

[Rubens Kuhl]

TC(bgp.net.br) is using IRRd 4.2, which has an RPKI pseudo-source with
exactly that. ROAs are downloaded from NTT. You can see how they look
like at:
https://bgp.net.br/whois/?q=-s%20RPKI%20200.160.0.0/20

But this is not used to create route(6) objects in the TC source, only
to invalidate route(6) objects that users create at TC. Mirrored IRRs
like RADB are not subject to RPKI validation, only to scope filter
(private IP addresses, private ASNs).


Rubens

On Tue, Oct 26, 2021 at 5:29 PM Shawn  wrote:
>
> Curious if any IRR databases are mirroring/importing ROA data - creating
> route|6 objects from ROA?
>
> LACNIC requires a route object to be created when creating a ROA.
> APNIC you create a route object, then may generate a ROA during that
> process.
> Other RIR's, curious if anything tries to bring the two together?
>
> Applicable for networks that only use IRR data (do not yet validate RPKI),
> they could benefit.
>
> IRR questions:
> How do most large networks maintain (automate) their IRR records?
> Is it standard practice to accept more specifics (append IPv4 "le /24" and
> IPv6 "le /48")?
>  Or is it expected to have one IRR route per BGP announcement?
>
>

Re: ROA mirror to IRR?

[George Michaelson]

On Wed, Oct 27, 2021 at 6:31 AM Shawn  wrote:
>
> Curious if any IRR databases are mirroring/importing ROA data - creating
> route|6 objects from ROA?
>
> LACNIC requires a route object to be created when creating a ROA.

> APNIC you create a route object, then may generate a ROA during that
> process.

This is a mis-characterisation of the situation. In APNIC, we have
implemented abstract routing management: you tell us the routes you
want to declare and have to elect to do ONLY route: object or ONLY ROA
-we make the ROA & route: objects aligned, to represent what you asked
for in the abstracted route. It's only if you specifically ask us to
make discrete, unaligned states in both worlds we do that. By default,
they mirror each other (modulo the limits of maxlen over the prefix at
hand: we don't make the "forest" of routes which would be needed
beyond a small distance maxlen - prefixlen)

Separately we kept the old whois object update path. you can elect to
make a route: object directly in the RPSL maintenance engine. If you
come into routes management, we flag the mis-alignment such as it is,
and you can make the ROA.

cheers

-George

> Other RIR's, curious if anything tries to bring the two together?
>
> Applicable for networks that only use IRR data (do not yet validate RPKI),
> they could benefit.
>
> IRR questions:
> How do most large networks maintain (automate) their IRR records?
> Is it standard practice to accept more specifics (append IPv4 "le /24" and
> IPv6 "le /48")?
>  Or is it expected to have one IRR route per BGP announcement?
>
>

Re: IPv6 and CDN's

[Tom Hill]

On 22/10/2021 17:08, t...@pelican.org wrote:
> I don't think it'll ever make money, but I think it will reduce
> costs.  CGNAT boxes cost money, operating them costs money, dealing
> with the support fallout from them costs money.  Especially in the
> residential space, where essentially if the customer calls you, ever,
> you just blew years' worth of margin.

There aren't enough folk thinking along these lines, so thank you for
writing it.

Every flow you can route exclusively with 6, is one flow you aren't
having to pay extra for so it can sit in a CGNAT state table.

... And that's before they call you, as Tim also rightly points out.

-- 
Tom

ROA mirror to IRR?

[Shawn]

Curious if any IRR databases are mirroring/importing ROA data - creating
route|6 objects from ROA?

LACNIC requires a route object to be created when creating a ROA.
APNIC you create a route object, then may generate a ROA during that
process.
Other RIR's, curious if anything tries to bring the two together?

Applicable for networks that only use IRR data (do not yet validate RPKI),
they could benefit.

IRR questions:
How do most large networks maintain (automate) their IRR records?
Is it standard practice to accept more specifics (append IPv4 "le /24" and
IPv6 "le /48")?
 Or is it expected to have one IRR route per BGP announcement?

Re: IPv6 and CDN's

[Mikael Abrahamsson via NANOG]

On Tue, 26 Oct 2021, David Conrad wrote:

Ah. Cogent. I suspect IPv6 peering policies. Somebody should bake a 
cake.


According to https://twitter.com/Benjojo12/status/1452673637606166536 
Cogent<->Google IPv6 now works. A cake is in order, but perhaps a 
celebratory one!?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: . (was IPv6 and CDN's)

[John Curran]

Bryan - 

One of the things that was clarified with the IANA Stewardship Transition is 
that ICANN has (at least) two distinct roles contained within it: one is 
coordination of the domain name community to develop Domain Name policy and the 
other is the IANA / Public Technical Identifiers (PTI) role serving as operator 
of the IANA functions (i.e. performing the administration of the various DNS, 
protocol registries, and the Internet numbers registries)

The IANA doesn’t set policy, but rather takes policy for each set of 
identifiers from the respective community: a) ICANN DNS Community for the DNS 
root zone, b) IETF for the protocol parameter registries, and c) the RIRs for 
the unicast IPv4, unicast IPv6, and ASN registries listed in IETF RFC 7249.   
David is definitely correct to say that determining what (if any) governance 
model should be utilized for the root server operators is a question outside 
the scope of the administrative/technical operations performed by the IANA/PTI, 
and rather a question that the various DNS stakeholders (DNS community, ICANN, 
IETF, and the Root Server Operators) must ponder. 
/John

On 26 Oct 2021, at 12:25 PM, Bryan Fields  wrote:
> 
> On 10/26/21 12:10 PM, David Conrad wrote:
>>> Surely IANA has the power to compel a root server operator to abide by
>>> policy or they lose the right to be a root server?
>> To compel? No. Not in the slightest. That is not how the root server system
>> works. This is a (very) common misconception.
> 
> Can you explain how it would work?  Say you have a root server operator who
> starts messing up, is there any ability to remove them?
> 
>> There has been some effort to create a governance model for the root server
>> system (see
>> https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf) but I
>> believe it has gotten bogged down in the question of “what do you do when a
>> root server operator isn’t doing the job ‘right’ (whatever that means and
>> after figuring out who decides) but doesn’t want to give up being a root
>> server operator?”. 
> 
> Seems like a good policy, 6.3 seems to cover how to fix technical issues with
> a root operator.
> 
>> It’s a hard question, but it isn't the folks at IANA who answer it.
> 
> Who does?  Doesn't IANA designate root servers and the . zone?
> 
> -- 
> Bryan Fields
> 
> 727-409-1194 - Voice
> http://bryanfields.net

Re: . (was IPv6 and CDN's)

[Bryan Fields]

On 10/26/21 12:10 PM, David Conrad wrote:
>> Surely IANA has the power to compel a root server operator to abide by
>> policy or they lose the right to be a root server?
> To compel? No. Not in the slightest. That is not how the root server system
> works. This is a (very) common misconception.

Can you explain how it would work?  Say you have a root server operator who
starts messing up, is there any ability to remove them?

> There has been some effort to create a governance model for the root server
> system (see
> https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf) but I
> believe it has gotten bogged down in the question of “what do you do when a
> root server operator isn’t doing the job ‘right’ (whatever that means and
> after figuring out who decides) but doesn’t want to give up being a root
> server operator?”. 

Seems like a good policy, 6.3 seems to cover how to fix technical issues with
a root operator.

> It’s a hard question, but it isn't the folks at IANA who answer it.

Who does?  Doesn't IANA designate root servers and the . zone?

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: IPv6 and CDN's

[David Conrad]

Bryan,

On Oct 23, 2021, at 5:56 PM, Bryan Fields  wrote:
>> Excepting temporary failures, they are as far as I am aware. Why do you
>> think they aren’t?
> 
> I can't reach C, 2001:500:2::c, from many places in v6 land.  My home and

> secondary data center can't reach it, but my backup VM's at another data
> center can.

Ah. Cogent. I suspect IPv6 peering policies. Somebody should bake a cake.

>> However, the IANA team is not the enforcement arm of the Internet. If a
>> root server operator chooses to not abide by RFC 7720, there is nothing the
>> IANA team can do unilaterally other than make the root server operator
>> aware of the fact.
> 
> Surely IANA has the power to compel a root server operator to abide by policy
> or they lose the right to be a root server?

To compel? No. Not in the slightest. That is not how the root server system 
works. This is a (very) common misconception.

There has been some effort to create a governance model for the root server 
system (see 
https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf) but I 
believe it has gotten bogged down in the question of “what do you do when a 
root server operator isn’t doing the job ‘right’ (whatever that means and after 
figuring out who decides) but doesn’t want to give up being a root server 
operator?”.  It’s a hard question, but it isn’t the folks at IANA who answer it.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Guam Private Line

[Robert DeVita]

Any recommendations for Private Line service into Guam from the US? 2 gigs?

Thanks

Rob

[photo]
[cid:image002.png@01D7CA4B.D0993B20]
Robert DeVita
CEO & Founder
[cid:image003.png@01D7CA4B.D0993B20]
[cid:image004.png@01D7CA4B.D0993B20]
[cid:image005.png@01D7CA4B.D0993B20] 469-581-2160
[cid:image006.png@01D7CA4B.D0993B20] 469-441-8864
[cid:image007.png@01D7CA4B.D0993B20] 
radev...@mejeticks.com
[cid:image008.png@01D7CA4B.D0993B20] www.mejeticks.com
[cid:image009.png@01D7CA4B.D0993B20]  3100 Carlisle St, 16-113, Dallas TX 75204

Re: question about enabling RPKI using Hosted mode

[Dale W. Carder]

Thus spake Edvinas Kairys (edvinas.em...@gmail.com) on Tue, Oct 26, 2021 at 
10:11:14AM +0300:
> 
> Also, about ROA expirations is it possible to configure an automatic ROA
> extension after it's expires ?

Well, you probably hit one of the next biggest operational issues, 
so congrats ;-).  

If you are in the ARIN region you might want to track the process
for ACSP Suggestion 2021.15 

https://www.arin.net/participate/community/acsp/suggestions/2021/2021-15/

If you are in another regions you can see the differences here:
https://rpki.readthedocs.io/en/latest/rpki/implementation-models.html?highlight=renew#functional-differences-across-rirs

Dale
 
> On Tue, Oct 26, 2021 at 12:35 AM Job Snijders  wrote:
> 
> > Dear Edvinas,
> >
> > On Mon, Oct 25, 2021 at 11:49:09PM +0300, Edvinas Kairys wrote:
> > > We're thinking of enabling BGP ROA, because more and more ISPs are using
> > > strict RPKI mode.
> > >
> > > Does enabling Hosted Mode (where it doesn't requires any additional
> > > configuration on client end) on RPKI could for some reason could cause a
> > > traffic loss ?
> > >
> > > The only disasterious scenario i could think of, is if we would enable
> > ROA
> > > with incorrect sub prefixes, maximum prefix length. Am i Right ?
> >
> > I think you correctly identified most of the potential pitfalls. Another
> > pitfall might be when a typo in the Origin AS value slips into the RPKI
> > ROA.
> >
> > For example, I originate 2001:67c:208c::/48 in the DFZ from AS 15562.
> > Should I'd accidentally modify the covering ROA to only permit AS 15563,
> > the planet's connectivity towards 2001:67c:208c::/48 would become
> > spotty.
> >
> > So... - BEFORE - creating RPKI ROAs, I recommend setting up a BGP/RPKI
> > monitoring tool. NTT's excellent BGPAlerter might be useful in this
> > context: https://github.com/nttgin/BGPalerter
> >
> > Don't deploy things without monitoring! :-)
> >
> > Kind regards,
> >
> > Job
> >

Re: question about enabling RPKI using Hosted mode

[Edvinas Kairys]

thanks, will keep in mind.

Also, about ROA expirations is it possible to configure an automatic ROA
extension after it's expires ?

On Tue, Oct 26, 2021 at 12:35 AM Job Snijders  wrote:

> Dear Edvinas,
>
> On Mon, Oct 25, 2021 at 11:49:09PM +0300, Edvinas Kairys wrote:
> > We're thinking of enabling BGP ROA, because more and more ISPs are using
> > strict RPKI mode.
> >
> > Does enabling Hosted Mode (where it doesn't requires any additional
> > configuration on client end) on RPKI could for some reason could cause a
> > traffic loss ?
> >
> > The only disasterious scenario i could think of, is if we would enable
> ROA
> > with incorrect sub prefixes, maximum prefix length. Am i Right ?
>
> I think you correctly identified most of the potential pitfalls. Another
> pitfall might be when a typo in the Origin AS value slips into the RPKI
> ROA.
>
> For example, I originate 2001:67c:208c::/48 in the DFZ from AS 15562.
> Should I'd accidentally modify the covering ROA to only permit AS 15563,
> the planet's connectivity towards 2001:67c:208c::/48 would become
> spotty.
>
> So... - BEFORE - creating RPKI ROAs, I recommend setting up a BGP/RPKI
> monitoring tool. NTT's excellent BGPAlerter might be useful in this
> context: https://github.com/nttgin/BGPalerter
>
> Don't deploy things without monitoring! :-)
>
> Kind regards,
>
> Job
>