[NANOG-announce] NANOG 83 Kicks-Off Monday + MORE

[Nanog News]

*NANOG 83 Kicks-Off on Monday   *
Register now to Connect Virtually +/or In-Person!

*Connecting with us virtually for NANOG 83? *

*WHERE TO WATCH:*  Go to nanog.org/nanog83 to watch incredible
presentations by industry leaders, participate in real-time Q + A sessions,
networking events, expo, games + more!

The hybrid conference will kick off next Monday, Nov. 1 - 3. Full details
are available for upcoming talks and keynote presentations on the agenda.
NANOG 83 will be available virtually +/or in-person in Minneapolis, MN.

*VIEW AGENDA  *

*VIDEO - Check out our New Web Series! *
"Internet Innovators" ft. the Stories of Internet Legends

The web series  "Internet Innovators"



explores
the heart behind the brightest + boldest tech minds of our time. Watch
every last Wed. of the month, as we release a new episode sharing the
stories of men + women to who we credit our greatest achievements in
Internet history.

WATCH NOW: Ep.1 + 2, with Ep.1 + 2, with legendary Internet pioneers Vint
Cerf

 + Geoff Huston.


Check out the  teaser
 of our upcoming interview
with Scott Bradner. Bradner has been involved with the design, operation,
and use of data networks at Harvard University since the early days of the
ARPANET.

*WATCH this teaser of Ep.3:* Bradner tells NANOG story producer, Elizabeth
Drolet, he knew the Internet was exploding when his mom started using it.

 Ep. 3 will be released Wednesday, Nov. 24.

*VIEW TEASER  *

*Don't Miss: Women in Tech  *
Opportunity for Networking + Finding Mentors

*Don't miss an opportunity to meet incredible women in tech.* Perfect for
any female engineers looking for mentors. The Women in Technology luncheon
will take place on Tues. Nov. 2nd from noon - 1 pm CDT in the Boundary
Waters D room.

*JOIN ZOOM MEETING*
https://nanog.zoom.us/j/88978845443?pwd=dGtpZ3hxTVh6UmVSZHk3YWxZUjNZUT09

Meeting ID: 889 7884 5443
Passcode: 383671
One tap mobile
+13126266799,,88978845443# US (Chicago)
+16468769923,,88978845443# US (New York)

*VIEW AGENDA * 
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

NANOG 83 Kicks-Off Monday + MORE

[Nanog News]

*NANOG 83 Kicks-Off on Monday   *
Register now to Connect Virtually +/or In-Person!

*Connecting with us virtually for NANOG 83? *

*WHERE TO WATCH:*  Go to nanog.org/nanog83 to watch incredible
presentations by industry leaders, participate in real-time Q + A sessions,
networking events, expo, games + more!

The hybrid conference will kick off next Monday, Nov. 1 - 3. Full details
are available for upcoming talks and keynote presentations on the agenda.
NANOG 83 will be available virtually +/or in-person in Minneapolis, MN.

*VIEW AGENDA  *

*VIDEO - Check out our New Web Series! *
"Internet Innovators" ft. the Stories of Internet Legends

The web series  "Internet Innovators"



explores
the heart behind the brightest + boldest tech minds of our time. Watch
every last Wed. of the month, as we release a new episode sharing the
stories of men + women to who we credit our greatest achievements in
Internet history.

WATCH NOW: Ep.1 + 2, with Ep.1 + 2, with legendary Internet pioneers Vint
Cerf

 + Geoff Huston.


Check out the  teaser
 of our upcoming interview
with Scott Bradner. Bradner has been involved with the design, operation,
and use of data networks at Harvard University since the early days of the
ARPANET.

*WATCH this teaser of Ep.3:* Bradner tells NANOG story producer, Elizabeth
Drolet, he knew the Internet was exploding when his mom started using it.

 Ep. 3 will be released Wednesday, Nov. 24.

*VIEW TEASER  *

*Don't Miss: Women in Tech  *
Opportunity for Networking + Finding Mentors

*Don't miss an opportunity to meet incredible women in tech.* Perfect for
any female engineers looking for mentors. The Women in Technology luncheon
will take place on Tues. Nov. 2nd from noon - 1 pm CDT in the Boundary
Waters D room.

*JOIN ZOOM MEETING*
https://nanog.zoom.us/j/88978845443?pwd=dGtpZ3hxTVh6UmVSZHk3YWxZUjNZUT09

Meeting ID: 889 7884 5443
Passcode: 383671
One tap mobile
+13126266799,,88978845443# US (Chicago)
+16468769923,,88978845443# US (New York)

*VIEW AGENDA * 

Re: . (was IPv6 and CDN's)

[Fred Baker]

> On Oct 26, 2021, at 9:25 AM, Bryan Fields  wrote:
> 
> 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?

You might look at 
https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf. Yes, 
there is a proposed way to remove an operator that is not working out.

Re: FORT monitoring/visibility

[Job Snijders via NANOG]

On Tue, Oct 26, 2021 at 04:58:20PM -0700, Randy Bush wrote:
> 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.

Have you taken a look at 'rtrmon' (RPKI-To-Router Monitor)

https://github.com/bgp/stayrtr#monitoring-rtr-and-json-endpoints

Kind regards,

Job

Re: Internet history

[Lixia Zhang]

> On Oct 21, 2021, at 12:47 PM, William Herrin  wrote:
> 
> On Thu, Oct 21, 2021 at 12:15 PM John Levine  wrote:
>> But it's definitely worth a visit, particularly if Len Kleinrock is around 
>> to give his spiel about "LO" the first message.
>> 
>> https://uclaconnectionlab.org/internet-museum/
> 
> Hi John,
> 
> Is it currently possible to visit? The web page doesn't say anything
> and Google Maps says the building is closed.

Boelter Hall (at UCLA, where the IMP is) is open now. 
This fall we largely do in-person teaching, the campus is full of students and 
visitors.

Lixia

General Survey about DNSSEC, DMARC and RPKI

[Akira Shibuya]

Dear nanog members,

We hope this message finds you safe and well.

Japan Network Information Center (JPNIC) is conducting a survey about the 
situation of the implementation of security technologies.

The Internet is spreading in a coordinated manner thanks to its openness and 
autonomous, distributed and cooperative architecture,  On the other hand, 
security technologies (DNSSEC, mail security such as DMARC, routing security 
such as RPKI), which need to be tackled in a coordinated manner, have been slow 
to spread in Japan.

We would like to know the situation and efforts made in your country/economy. 
We will be grateful if you could respond to the questionnaire below by November 
5th.

https://forms.gle/7s6s2oWmpTtPNecLA

If you have any questions, please let us know by sending an email to 
arch-i...@nic.ad.jp.

Sorry for bother you but thank you for your cooperation.

-
Akira Shibuya
(on behalf of JPNIC secretariat)

Re: ROA mirror to IRR?

[Laura Smith via NANOG]

‐‐‐ Original Message ‐‐‐
On Tuesday, October 26th, 2021 at 21:17, Shawn  
wrote:
> Is it standard practice to accept more specifics (append IPv4 "le /24" and  
> IPv6 "le /48")?


There was an blog post written somewhere (unfortunately I cannot locate it) 
that urged caution as to how you configure more specifics at RIRs and doing it 
the wrong way opened you up to spoofing or somesuch.

I seem to recall the obvious way (your suggested "append le/24" etc.) was very 
much not recommended.

No doubt some kind soul on list will have that blog post in their bookmarks 
and/or others may wish to comment on the concept.

Re: question about enabling RPKI using Hosted mode

[Edvinas Kairys]

Thanks, i'm happy that my RIR is RIPE. I hope other RIRs will make
auto-renew as well.

On Tue, Oct 26, 2021 at 4:30 PM Dale W. Carder  wrote:

> 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: FORT monitoring/visibility

[Jeroen Massar via NANOG]

> On 20211027, at 09:26, Lukas Tribus  wrote:
> 
> On Wed, 27 Oct 2021 at 08:47, Mark Tinka  wrote:
>> 
>> On 10/27/21 01:58, Randy Bush wrote:
>>> my old DRL RP instances produce MRTG graphs etc of the CA
>>> fetching side, though nothing on the rpki-rtr side.
>> 
>> Randy, I actually have an ongoing discussion with the Fort developers
>> about this after a BGPSec bug left me with stale VRP's for several days,
>> with no clear indication that Fort had "kind of" crashed and "not fully"
>> crashed (fair point, I need to work on better internal monitoring of
>> Fort, as well).
> 
> That's the reason I preached about stale RTR servers before:
> 
> https://labs.ripe.net/author/lukas_tribus/rpki-rov-about-stale-rtr-servers-and-how-to-monitor-them/
> https://github.com/lukastribus/rtrcheck
> https://gist.github.com/lukastribus/695c9e780d118755271519d4d3cb54f3
> (the latter is a check against IOS XR devices via NETCONF which makes
> some sanity checks, absolute and relative)

Lukas, thanks for these, will align my own checks with the details you check 
for.

Do tag your repo's with a "RPKI" tag and similar so that it is easier to find 
these kind of tools!


Tooling is severely lacking in the RPKI space, in numbers and quality, thus any 
tool like this helps.

Greets,
 Jeroen

Re: FORT monitoring/visibility

[Lukas Tribus]

On Wed, 27 Oct 2021 at 08:47, Mark Tinka  wrote:
>
> On 10/27/21 01:58, Randy Bush wrote:
> > my old DRL RP instances produce MRTG graphs etc of the CA
> > fetching side, though nothing on the rpki-rtr side.
>
> Randy, I actually have an ongoing discussion with the Fort developers
> about this after a BGPSec bug left me with stale VRP's for several days,
> with no clear indication that Fort had "kind of" crashed and "not fully"
> crashed (fair point, I need to work on better internal monitoring of
> Fort, as well).

That's the reason I preached about stale RTR servers before:

https://labs.ripe.net/author/lukas_tribus/rpki-rov-about-stale-rtr-servers-and-how-to-monitor-them/
https://github.com/lukastribus/rtrcheck
https://gist.github.com/lukastribus/695c9e780d118755271519d4d3cb54f3
(the latter is a check against IOS XR devices via NETCONF which makes
some sanity checks, absolute and relative)

However judging by the absolute zero feedback and support requests
from anyone (other than likes/thumbs up), I'm pretty sure no one
actually does this - other than where I set it up directly.


Fort is also working on a prometheus endpoint, which probably would
allow easier monitoring/integration:

https://github.com/NICMx/FORT-validator/issues/50


Lukas

Re: FORT monitoring/visibility

[Mark Tinka]

On 10/27/21 01:58, Randy Bush wrote:

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, I actually have an ongoing discussion with the Fort developers 
about this after a BGPSec bug left me with stale VRP's for several days, 
with no clear indication that Fort had "kind of" crashed and "not fully" 
crashed (fair point, I need to work on better internal monitoring of 
Fort, as well).


Will feedback once I have better info.

For now, if you haven't yet done so, recommend upgrading to 1.5.2 to 
avoid this specific issue.


The good news is this issue made the case for running different 
validation RP code, so your NLRI does not share fate, given it's the 
basis of the Internet.


Mark.

Re: ROA mirror to IRR?

[Ben Maddison via NANOG]

Hi Shawn,

On 10/26, Shawn wrote:
> 
> 
> 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?
> 
We (37271) use different policies depending on our relationship to the
neighbor.
From customers, we require an exactly matching route(6) object.
From peers, we accept more specifics up to /24 or /48.

The rationale for this is:
1.  We consider that we have a higher "duty of care" with respect to
routes that we intend to announce to the wider Internet; and
2.  Having a customer facing policy that is at least as strict as our
strictest neighbor helps eliminate hard to troubleshoot propagation
issues.

We've been doing things this way for several years now, and it seems to
be a good middle ground.

Cheers,

Ben


signature.asc
Description: PGP signature