Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN72 Virtual Annual General Meeting

[Jacques Latour]

Hello NANOG!
This is the CfP for our next DNSSEC & Security workshop @ ICANN72.
Jacques

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN72 
Virtual Annual General Meeting

In cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
we are planning a DNSSEC and Security Workshop for the ICANN72 Annual General 
Meeting being held virtually from 23-28 October 2021 in the Pacific Daylight 
Time Zone (UTC -7). This workshop date will be determined once ICANN creates a 
block schedule for us to follow; then we will be able to request a day and 
time. The DNSSEC and Security Workshop has been a part of ICANN meetings for 
several years and has provided a forum for both experienced and new people to 
meet, present and discuss current and future DNSSEC deployments.  For 
reference, the most recent session was held at the ICANN71 Virtual Meeting on 
14 June 2021. The presentations and transcripts are available at 
https://71.schedule.icann.org/meetings/3q22SHqif9XF5nFqG and 
https://71.schedule.icann.org/meetings/vv7XkuePvghwFaLgt

The DNSSEC Workshop Program Committee is developing a program.  Proposals will 
be considered for the following topic areas and included if space permits.  In 
addition, we welcome suggestions for additional topics either for inclusion in 
the ICANN72 workshop, or for consideration for future workshops.

1.  Global DNSSEC Activities Panel
For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment as well as from those who have not deployed DNSSEC but who 
have a keen interest in the challenges and benefits of deployment, including 
Root Key Signing Key (KSK) Rollover activities and plans.

2.  DNSSEC Best Practice
Now that DNSSEC has become an operational norm for many registries, registrars, 
and ISPs, what have we learned about how we manage DNSSEC?  Do you still 
submit/accept DS records with Digest Type 1? What is the best practice around 
key roll-overs?  What about Algorithm roll-overs? Do you use and support DNSKEY 
Algorithms 13-16? How often do you review your disaster recovery procedures? Is 
there operational familiarity within your customer support teams? What 
operational statistics have we gathered about DNSSEC? Are there experiences 
being documented in the form of best practices, or something similar, for 
transfer of signed zones?  Activities and issues related to DNSSEC in the DNS 
Root Zone are also desired.

3. DNSSEC Deployment Challenges
The program committee is seeking input from those that are interested in 
implementation of DNSSEC but have general or particular concerns with DNSSEC.  
In particular, we are seeking input from individuals that would be willing to 
participate in a panel that would discuss questions of the following nature:
- Are there any policies directly or indirectly impeding your DNSSEC 
deployment? (RRR model, CDS/CDNSKEY automation)
- What are your most significant concerns with DNSSEC, e.g., complexity, 
training, implementation, operation or something else?
- What do you expect DNSSEC to do for you and what doesn't it do?
- What do you see as the most important trade-offs with respect to doing or not 
doing DNSSEC?

4. Security Panel
The program committee is looking for presentations on DNS and Routing topics 
that could impact the security and/or stability of the internet. .
- DoH and DoT implementation issues, challenges and opportunities
- RPKI adoption and implementation  issues, challenges and opportunities
- BGP/routing/hijack issues, challenges and opportunities
- MANRS implementation challenges and opportunities
- Emerging threats that could impact (real or perceived)  the security and/or 
stability of the internet
- Domain hacking/hijacking prevention, best practice and techniques
- Browser related security implementations
- DMARC Challenges, opportunities and Best Practices
- BGP Flowspec challenges, opportunities and Best Practices

If you are interested in participating, please send a brief (1-2 sentence) 
description of your proposed presentation to dnssec-security-works...@icann.org 
by Friday, 10 September 2021

Thank you,
Kathy and Andrew
On behalf of the DNSSEC Workshop Program Committee:
Mark Elkins, DNS/ZACR
Jacques Latour, .CA
Russ Mundy, Parsons
Ondrej Filip, CZ.NIC
Yoshiro Yoneya, JPRS
Fred Baker, ISC
Dan York, Internet Society

RE: [EXT] Re: russian prefixes

[Jacques Latour]

Perhaps it's the result of a successful table top exercise 😉





> -Original Message-

> From: NANOG  On

> Behalf Of Randy Bush

> Sent: July 29, 2021 1:47 PM

> To: Alexandre Snarskii 

> Cc: North American Network Operators' Group 

> Subject: [EXT] Re: russian prefixes

>

> > Looks like it did shown on news only.

>

> :)

>

> i wondered

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN72 Virtual Annual General Meeting

[Jacques Latour]

Hi all 😊

Hope you all had a great summer!!!  Let us know if you’re interested in 
presenting something DNSSEC or security related.

Thanks,

Jacques



Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN72 
Virtual Annual General Meeting

In cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
we are planning a DNSSEC and Security Workshop for the ICANN72 Annual General 
Meeting being held virtually from 25-28 October 2021 in the Pacific Daylight 
Time Zone (UTC -7). This workshop date will be determined once ICANN creates a 
block schedule for us to follow; then we will be able to request a day and 
time. The DNSSEC and Security Workshop has been a part of ICANN meetings for 
several years and has provided a forum for both experienced and new people to 
meet, present and discuss current and future DNSSEC deployments.  For 
reference, the most recent session was held at the ICANN71 Virtual Meeting on 
14 June 2021. The presentations and transcripts are available at 
https://71.schedule.icann.org/meetings/3q22SHqif9XF5nFqG<https://urldefense.com/v3/__https:/71.schedule.icann.org/meetings/3q22SHqif9XF5nFqG__;!!PtGJab4!oAQ-129Jzgxij14pqi3cSBO4DW2X5hS0YRGk36fwsaeufPsYkYNSD3XfawHUh811t8SNk9G8jw$>
 and 
https://71.schedule.icann.org/meetings/vv7XkuePvghwFaLgt<https://urldefense.com/v3/__https:/71.schedule.icann.org/meetings/vv7XkuePvghwFaLgt__;!!PtGJab4!oAQ-129Jzgxij14pqi3cSBO4DW2X5hS0YRGk36fwsaeufPsYkYNSD3XfawHUh811t8SRN0Wj9w$>

The DNSSEC Workshop Program Committee is developing a program.  Proposals will 
be considered for the following topic areas and included if space permits.  In 
addition, we welcome suggestions for additional topics either for inclusion in 
the ICANN72 workshop, or for consideration for future workshops.

1.  Global DNSSEC Activities Panel
For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment as well as from those who have not deployed DNSSEC but who 
have a keen interest in the challenges and benefits of deployment, including 
Root Key Signing Key (KSK) Rollover activities and plans.

2.  DNSSEC Best Practice
Now that DNSSEC has become an operational norm for many registries, registrars, 
and ISPs, what have we learned about how we manage DNSSEC?  Do you still 
submit/accept DS records with Digest Type 1? What is the best practice around 
key roll-overs?  What about Algorithm roll-overs? Do you use and support DNSKEY 
Algorithms 13-16? How often do you review your disaster recovery procedures? Is 
there operational familiarity within your customer support teams? What 
operational statistics have we gathered about DNSSEC? Are there experiences 
being documented in the form of best practices, or something similar, for 
transfer of signed zones?  Activities and issues related to DNSSEC in the DNS 
Root Zone are also desired.

3. DNSSEC Deployment Challenges
The program committee is seeking input from those that are interested in 
implementation of DNSSEC but have general or particular concerns with DNSSEC.  
In particular, we are seeking input from individuals that would be willing to 
participate in a panel that would discuss questions of the following nature:
- Are there any policies directly or indirectly impeding your DNSSEC 
deployment? (RRR model, CDS/CDNSKEY automation)
- What are your most significant concerns with DNSSEC, e.g., complexity, 
training, implementation, operation or something else?
- What do you expect DNSSEC to do for you and what doesn't it do?
- What do you see as the most important trade-offs with respect to doing or not 
doing DNSSEC?

4. Security Panel
The program committee is looking for presentations on DNS and Routing topics 
that could impact the security and/or stability of the internet. .
- DoH and DoT implementation issues, challenges and opportunities
- RPKI adoption and implementation  issues, challenges and opportunities
- BGP/routing/hijack issues, challenges and opportunities
- MANRS implementation challenges and opportunities
- Emerging threats that could impact (real or perceived)  the security and/or 
stability of the internet
- Domain hacking/hijacking prevention, best practice and techniques
- Browser related security implementations
- DMARC Challenges, opportunities and Best Practices
- BGP Flowspec challenges, opportunities and Best Practices

If you are interested in participating, please send a brief (1-2 sentence) 
description of your proposed presentation to 
dnssec-security-works...@icann.org<mailto:dnssec-security-works...@icann.org> 
by Friday, 17 September 2021

Thank you,
Kathy and Andrew
On behalf of the DNSSEC Workshop Program Committee:
Mark Elkins, DNS/ZACR
Jacques Latour, .CA
Russ Mundy, Parsons
Ondrej Filip, CZ.NIC
Yoshiro Yoneya, JPRS
Fred Baker, ISC
Dan York, Internet Society

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN73 Community Forum

[Jacques Latour]

Hi all,
Happy new year!
8 weeks left before the next virtual ICANN DNSSEC & Security workshop. Let us 
know if you are interested to present.
Jacques

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN73  
Community Forum

In cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
we are planning a DNSSEC and Security Workshop for the ICANN73 Community Forum 
being held virtually from 05-10 March 2022 in the Atlantic Standard  Time Zone 
(UTC -4). This workshop date will be determined once ICANN creates a block 
schedule for us to follow; then we will be able to request a day and time. The 
DNSSEC and Security Workshop has been a part of ICANN meetings for several 
years and has provided a forum for both experienced and new people to meet, 
present and discuss current and future DNSSEC deployments.  For reference, the 
most recent session was held at the ICANN72 Annual General Meeting on Wednesday 
27 October 2021. The presentations and transcripts are available at 
https://72.schedule.icann.org/meetings/M24SJN375N2rcupnS,  
https://72.schedule.icann.org/meetings/NQMcvSwdLbpdGPaz6, and 
https://72.schedule.icann.org/meetings/9g4P3ceRA8FGS34Ei.

The DNSSEC Workshop Program Committee is developing a program.  Proposals will 
be considered for the following topic areas and included if space permits.  In 
addition, we welcome suggestions for additional topics either for inclusion in 
the ICANN72 workshop, or for consideration for future workshops.

1.  Global DNSSEC Activities Panel
For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment as well as from those who have not deployed DNSSEC but who 
have a keen interest in the challenges and benefits of deployment, including 
Root Key Signing Key (KSK) Rollover activities and plans.

2.  DNSSEC Best Practice
Now that DNSSEC has become an operational norm for many registries, registrars, 
and ISPs, what have we learned about how we manage DNSSEC?


  *   Do you still submit/accept DS records with Digest Type 1?
  *   What is the best practice around key roll-overs?
  *   What about Algorithm roll-overs?
  *   Do you use and support DNSKEY Algorithms 13-16?
  *   How often do you review your disaster recovery procedures?
  *   Is there operational familiarity within your customer support teams?
  *   What operational statistics have we gathered about DNSSEC?
  *   Are there experiences being documented in the form of best practices, or 
something similar, for transfer of signed zones?

Activities and issues related to DNSSEC in the DNS Root Zone are also desired.

3. DNSSEC Deployment Challenges
The program committee is seeking input from those that are interested in 
implementation of DNSSEC but have general or particular concerns with DNSSEC.  
In particular, we are seeking input from individuals that would be willing to 
participate in a panel that would discuss questions of the following nature:


  *   Are there any policies directly or indirectly impeding your DNSSEC 
deployment? (RRR model, CDS/CDNSKEY automation)
  *   What are your most significant concerns with DNSSEC, e.g., complexity, 
training, implementation, operation or something else?
  *   What do you expect DNSSEC to do for you and what doesn't it do?
  *   What do you see as the most important trade-offs with respect to doing or 
not doing DNSSEC?

4. Security Panel
The program committee is looking for presentations on DNS, DNSSEC and Routing 
topics that could impact the security and/or stability of the internet.

We are looking for presentations that cover implementation issues, challenges, 
opportunities and best practices for:


  *   Emerging threats that could impact the security and/or stability of the 
internet
  *   DoH and DoT
  *   RPKI (Resource Public Key Infrastructure)
  *   BGP routing & secure implementations
  *   MANRS ( Mutually Agreed Norms for Routing Security)
  *   Browser security – DNS, DNSSEC, DoH
  *   EMAIL & DNS related security – DMARC, DKIM, TLSA, etc…

If you are interested in participating, please send a brief (1-2 sentence) 
description of your proposed presentation to 
dnssec-security-works...@icann.org<mailto:dnssec-security-works...@icann.org> 
by COB Friday, January 21 2022

Thank you,

Kathy and Andrew
On behalf of the DNSSEC Workshop Program Committee:
Steve Crocker, Shinkuro
Mark Elkins, DNS/ZACR
Jacques Latour, .CA
Russ Mundy, Parsons
Ondrej Filip, CZ.NIC
Yoshiro Yoneya, JPRS
Fred Baker, ISC
Dan York, Internet Society

IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6 still not supported re: 202203261833.AYC

[Jacques Latour]

So, in 25, 50 or 100 years from now, are we still going to be dual stack 
IPv4/IPv6?
When are we going to give up on IPv4?
People can run IPv4 all they want inside their networks for 1000s of years.
What will it take to be IPv6 only?

😊

From: NANOG  On Behalf Of Owen 
DeLong via NANOG
Sent: March 29, 2022 3:52 PM
To: Abraham Y. Chen 
Cc: NANOG 
Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not supported re: 
202203261833.AYC

Submit an Internet draft, same as any other IP related enhancement gets 
introduced.

What you’re really complaining about is that it’s been virtually impossible to 
gain consensus to move anything IPv4 related forward in the IETF since at least 
2015.

Well… It’s a consensus process. If your idea isn’t getting consensus, then 
perhaps it’s simply that the group you are seeking consensus from doesn’t like 
your idea.

Your inability to convince the members of the various working groups that your 
idea has merit isn’t necessarily a defect in the IETF process… It might simply 
be a lack of merit in your ideas.

Owen



On Mar 26, 2022, at 15:43 , Abraham Y. Chen 
mailto:ayc...@avinta.com>> wrote:

Hi, Justin:

1)"... no one is stopping anyone from working on IPv4 ... ":   After 
all these discussions, are you still denying this basic issue? For example, 
there has not been any straightforward way to introduce IPv4 enhancement ideas 
to IETF since at least 2015. If you know the way, please make it public. I am 
sure that many are eager to learn about it. Thanks.

Regards,


Abe (2022-03-26 18:42)




On 2022-03-26 11:20, Justin Streiner wrote:
While the Internet is intended to allow the free exchange of information, the 
means of getting that information from place to place is and has to be defined 
by protocols that are implemented in a consistent manner (see: BGP, among many 
other examples).  It's important to separate the ideas from the plumbing.

That said, no one is stopping anyone from working on IPv4, so what personal 
freedoms are being impacted by working toward deploying IPv6, with an eye 
toward sunsetting IPv4 in the future?

Keep in mind that IPv4 started out as an experiment that found its way into 
wider use.  It's a classic case of a test deployment that suddenly mutated into 
a production service.  Why should we continue to expend effort to perpetuate 
the sins of the past, rather work toward getting v6 into wider use?

Is IPv6 a perfect protocol?  Absolutely not, but it addresses the key pain 
point of IPv4 - address space exhaustion.

Thank you
jms

On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen 
mailto:ayc...@avinta.com>> wrote:

3)Re: Ur. Pts. 5) & 6):I believe that there is a philosophic / logic 
baseline that we need to sort out, first. That is, we must keep in mind that 
the Internet community strongly promotes "personal freedom". Assuming that by 
stopping others from working on IPv4 will shift their energy to IPv6 is totally 
contradicting such a principle. A project attracts contributors by its own 
merits, not by relying on artificial barriers to the competitions. Based on my 
best understanding, IPv6 failed right after the decision of "not emphasizing 
the backward compatibility with IPv4". It broke one of the golden rules in the 
system engineering discipline. After nearly three decades, still evading such 
fact, but defusing IPv6 issues by various tactics is the real impedance to 
progress, not only to IPv4 but also to IPv6.

Re: IPv6 Only

[Jacques Latour]

Exactly what I was asking, when and how will we collectively turn off the 
lights on IPv4?

> -Original Message-
> From: NANOG  On
> Behalf Of Mark Andrews
> Sent: March 30, 2022 7:29 PM
> To: NANOG 
> Subject: [EXT] Re: IPv6 Only - was Re: Let's Focus on Moving Forward Re: V6
> still not supported re: 202203261833.AYC
> 
> Sites looking at the traffic they get and saying, you know what all our
> customers connect to us over IPv6 with some of them also connecting over
> IPv4.  I think we can stop supporting IPv4 now.
> 
> ISP’s saying this IPv4aaS isn’t getting much traffic anymore lets out source 
> it
> for the few customers that are still using it.  Lots of ISPs are well down the
> path leading to this point by turning off IPv4 on the access networks.
> 
> Home / enterprise networks.  All my gear is IPv6 capable and supports
> IPv4aaS for the few legacy
> IPv4 sites I need to connect to.  This is happening today.
> 
> In the end almost all the IPv4 traffic with be with the third party IPv4aaS
> providers and collectively they will decide to turn off the lights.
> 
> > On 30 Mar 2022, at 07:53, Jacques Latour  wrote:
> >
> > So, in 25, 50 or 100 years from now, are we still going to be dual stack
> IPv4/IPv6?
> > When are we going to give up on IPv4?
> > People can run IPv4 all they want inside their networks for 1000s of years.
> > What will it take to be IPv6 only?
> >
> > 😊
> >
> > From: NANOG  On
> Behalf
> > Of Owen DeLong via NANOG
> > Sent: March 29, 2022 3:52 PM
> > To: Abraham Y. Chen 
> > Cc: NANOG 
> > Subject: [EXT] Re: Let's Focus on Moving Forward Re: V6 still not
> > supported re: 202203261833.AYC
> >
> > Submit an Internet draft, same as any other IP related enhancement gets
> introduced.
> >
> > What you’re really complaining about is that it’s been virtually impossible
> to gain consensus to move anything IPv4 related forward in the IETF since at
> least 2015.
> >
> > Well… It’s a consensus process. If your idea isn’t getting consensus, then
> perhaps it’s simply that the group you are seeking consensus from doesn’t
> like your idea.
> >
> > Your inability to convince the members of the various working groups that
> your idea has merit isn’t necessarily a defect in the IETF process… It might
> simply be a lack of merit in your ideas.
> >
> > Owen
> >
> >
> >
> > On Mar 26, 2022, at 15:43 , Abraham Y. Chen 
> wrote:
> >
> > Hi, Justin:
> >
> > 1)"... no one is stopping anyone from working on IPv4 ... ":   
> > After all
> these discussions, are you still denying this basic issue? For example, there
> has not been any straightforward way to introduce IPv4 enhancement ideas
> to IETF since at least 2015. If you know the way, please make it public. I am
> sure that many are eager to learn about it. Thanks.
> >
> > Regards,
> >
> >
> > Abe (2022-03-26 18:42)
> >
> >
> >
> >
> > On 2022-03-26 11:20, Justin Streiner wrote:
> > While the Internet is intended to allow the free exchange of information,
> the means of getting that information from place to place is and has to be
> defined by protocols that are implemented in a consistent manner (see: BGP,
> among many other examples).  It's important to separate the ideas from the
> plumbing.
> >
> > That said, no one is stopping anyone from working on IPv4, so what
> personal freedoms are being impacted by working toward deploying IPv6,
> with an eye toward sunsetting IPv4 in the future?
> >
> > Keep in mind that IPv4 started out as an experiment that found its way
> into wider use.  It's a classic case of a test deployment that suddenly
> mutated into a production service.  Why should we continue to expend
> effort to perpetuate the sins of the past, rather work toward getting v6 into
> wider use?
> >
> > Is IPv6 a perfect protocol?  Absolutely not, but it addresses the key pain
> point of IPv4 - address space exhaustion.
> >
> > Thank you
> > jms
> >
> > On Sat, Mar 26, 2022 at 9:35 AM Abraham Y. Chen 
> wrote:
> >
> > 3)Re: Ur. Pts. 5) & 6):I believe that there is a philosophic / logic
> baseline that we need to sort out, first. That is, we must keep in mind that
> the Internet community strongly promotes "personal freedom". Assuming
> that by stopping others from working on IPv4 will shift their energy to IPv6 
> is
> totally contradicting such a principle. A project attracts contributors by its
> own merits, not by relying on artificial barriers to the competitions. Based 
> on
> my best understanding, IPv6 failed right after the decision of "not
> emphasizing the backward compatibility with IPv4". It broke one of the
> golden rules in the system engineering discipline. After nearly three decades,
> still evading such fact, but defusing IPv6 issues by various tactics is the 
> real
> impedance to progress, not only to IPv4 but also to IPv6.
> 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: IPv6 Only

[Jacques Latour]

Is there a status page for this initiative?

  *   M-21-07 
(whitehouse.gov)<https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf>
  *   SUBJECT: Completing the Transition to Internet Protocol Version 6 (IPv6)

“Develop an IPv6 implementation plan by the end of FY 2021, and update the 
Information Resources Management (IRM) Strategic Plan as appropriate, to update 
all networked Federal information systems (and the IP-enabled assets associated 
with these systems) to fully enable native IPv6 operation. The plan shall 
describe the agency transition process and include the following milestones and 
actions:

  *   At least 20% of IP-enabled assets on Federal networks are operating in 
IPv6-only environments by the end of FY 2023;
  *   At least 50% of IP-enabled assets on Federal networks are operating in 
IPv6-only environments by the end of FY 2024;
  *   At least 80% of IP-enabled assets on Federal networks are operating in 
IPv6-only environments by the end of FY 2025;”

“Cisco IT is Customer Zero for IPv6-only inside our networks” - Transitioning 
to IPv6 for Simplicity, Efficiency, and Modernization - Cisco 
Blogs<https://blogs.cisco.com/networking/transitioning-to-ipv6-for-simplicity-efficiency-and-modernization>





From: Matthew Petach 
Sent: March 31, 2022 2:54 PM
To: Jacques Latour 
Cc: Mark Andrews ; NANOG 
Subject: [EXT] Re: IPv6 Only



On Thu, Mar 31, 2022 at 5:36 AM Jacques Latour 
mailto:jacques.lat...@cira.ca>> wrote:
Exactly what I was asking, when and how will we collectively turn off the 
lights on IPv4?

Working on the World IPv6 Launch {day|week|forever} efforts,
I noticed an interesting pattern of companies that put up IPv6
resources, with all the associated quad-As, and patted themselves
on the back for making themselves available via IPv6; but I couldn't
request those quad-A records via anything but IPv4 transport to their
DNS servers.

I've seen similar behaviour with hardware vendors.  They have great
IPv6 support, their boxes forward and accept IPv6 packets just fine;
but, the deeper you dig, the more you find oddities, like syslog host
destinations that only accept v4 IP addresses, or a requirement for
an IPv4 router ID to be configured.

I don't think we fully grasp just how wide the chasm is between
"we support IPv6" and "we can fully turn off IPv4".

There's a whole lot of "we support IPv6" in the world right now that
comes with lingering IPv4 tendrils that are often under the surface,
or in the darker corners of the config, that just keep working because
most of the IPv6 world is still either dual-stacked, or has a translation
layer that allows the lurking v4 bits to not cause issues.

I don't think we'll be nearly as close to being ready to turn off the lights
on IPv4 as we think we are, not just because of old customer CPE and
legacy boxes, but because of embedded assumptions deep in software
and firmware stacks.  For example, let's take a relatively modern
enterprise wireless platform:

https://www.arubanetworks.com/techdocs/AOS-CX/10.07/HTML/5200-7852/Content/Chp_ZTP/ztp-sup-aos-cx-10.htm
"

  *   ZTP operations are supported over IPv4 connections only. IPv6 connections 
are not supported for ZTP operations."
 Sure, the devices pass IPv6 traffic just fine; but you'd better keep your IPv4
network around so the devices can configure themselves after powering on.

There's a *lot* of code out there that's been carried forward for years,
with dark corners that haven't been touched for a while.  I think we're
going to be stumbling over "can't do that over IPv6 yet" areas for years
and years to come, not because of any willful myopia around the migration
from IPv4 to IPv6, but simply because it's code that doesn't get used very
often, and in dual-stack networks, it just keeps working the few times it
gets exercised.  The only time it would run into a problem is in a pure
IPv6-only network; and how many of those really exist in the world to
flag it as an issue?

And yet, in order to "turn off the lights on IPv4", we're going to have to
root through all those dark corners of code that haven't been touched
in years to update them to work in an IPv6-only world; and that's *really*
pushing the rock uphill, because that's work that isn't going to see any
cost recovery for it at all.  No customer is going to say "I won't buy your
product until you've rooted out every bit of IPv4-only code in your software".
So, there's really no financial incentive for companies to work towards
getting their software ready for an IPv6-only world.

So--the tl;dr version of my answer to you?
"when" is likely to be "not in any of our lifetimes"--because the "how"
requires completely non-monetizable effort on the part of companies
that have legacy codebases they're carrying forward.

Thanks!

Matt

RE: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

[Jacques Latour]

Job,
What other partitioning like this exists?
Jack


From: NANOG  On Behalf Of Job Snijders
Sent: December 20, 2018 2:11 PM
To: Matthew Kaufman 
Cc: nanog@nanog.org
Subject: Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

At this moment it appears there are multiple rifts in the IPv6 default-free 
zone (that don’t exist in the IPv4 realm), between various organizations. 
Focusing on one particular partitioning may not help address the other issues.

Kind regards,

Job

Call for Participation -- ICANN DNSSEC Workshop at ICANN64 Kobe, Japan

[Jacques Latour]

Call for Participation -- ICANN DNSSEC Workshop at ICANN64 Kobe, Japan



The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, 
in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
are planning a DNSSEC Workshop during the ICANN64 meeting held from 09-14 March 
2019 in Kobe, Japan. The DNSSEC Workshop has been a part of ICANN meetings for 
several years and has provided a forum for both experienced and new people to 
meet, present and discuss current and future DNSSEC deployments. For reference, 
the most recent session was held at the ICANN Annual General Meeting in 
Barcelona, Spain, on 24 October 2018. The presentations and transcripts are 
available at: https://63.schedule.icann.org/meetings/901549, and 
https://63.schedule.icann.org/meetings/901554, and 
https://63.schedule.icann.org/meetings/901555.



At ICANN64 we are particularly interested in live demonstrations of uses of 
DNSSEC, DS automation or DANE. Examples might include:

* DNSSEC automation and deployment using CDS, CDNSKEY, and CSYNC

* DNSSEC/DANE validation in browsers and in applications

* Secure email / email encryption using DNSSEC, OPENPGPKEY, or S/MIME

* DNSSEC signing solutions and innovation (monitoring, managing, 
validation)

* Tools for automating the generation of DNSSEC/DANE records

* Extending DNSSEC/DANE with authentication, SSH, XMPP, SMTP, S/MIME or 
PGP/GPG and other protocols



Our interest is to provide current examples of the state of development and to 
show real-world examples of how DNSSEC and DANE related innovation can be used 
to increase the overall security of the Internet.

We are open to presentations and demonstrations related to any topic associated 
with DNSSEC and DANE. Examples of the types of topics we are seeking include:



1. DNSSEC Panel (Regional and Global)



For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment in the region and also from those who have not deployed 
DNSSEC but who have a keen interest in the challenges and benefits of 
deployment. In particular, we will consider the following questions: Are you 
interested in reporting on DNSSEC validation of your ISPs? What can DNSSEC do 
for you? What doesn't it do? What are the internal tradeoffs to implementing 
DNSSEC? What did you learn in your deployment of DNSSEC? We are interested in 
presentations from both people involved with the signing of domains and people 
involved with the deployment of DNSSEC-validating DNS resolvers.



2. DS Automation



We are looking at innovative ways to automate the parent child synchronization 
CDS / CDNSKEY and methods to bootstrap new or existing domains.  We are also 
interested in development or plans related to CSYNC, which are aimed at keeping 
the glue up to date.

We would like to hear from DNS Operators what their current thoughts on 
CDS/CDNSKEY automation are.



3. DNSSEC/DANE Support in the browsers



We would be interested in hearing from browser develop what their plans are in 
terms of supporting DNSSEC/DANE validation.



4. DANE Automation



For DNSSEC to reach massive deployment levels it is clear that a higher level 
of automation is required than is currently available. There also is strong 
interest for DANE usage within web transactions as well as for securing email 
and Voice-over-IP (VoIP). We are seeking presentations on topics such as:



* How can the industry use DANE and other DNSSEC applications as a 
mechanism for creating a more secure Internet?

* What tools, systems and services are available to help automate 
DNSSEC key management?

* Can you provide an analysis of current tools/services and identify 
gaps?

* What are some of the new and innovative uses of DANE and other DNSSEC 
applications in new areas or industries?

* What tools and services are now available that can support DANE usage?



We would be particularly interested in any live demonstrations of DNSSEC / DANE 
application automation and services. Demonstrations of new tools that make the 
setup of DNSSEC or DANE more automated would also be welcome.



If you are interested in participating, please send a brief (1-2 sentence) 
description of your proposed presentation to  dnssec-k...@isoc.org' before ** 
07 February 2019 **



We hope that you can join us.

Thank you,

Jacques Latour



On behalf of the DNSSEC Workshop Program Committee:

Jean Robert Hountomey, AfricaCERT

Jacques Latour, .CA

Russ Mundy, Parsons

Ondřej Filip, CZ.NIC

Yoshiro Yoneya, JPRS

Dan York, Internet Society

Mark Elkins, DNS/ZACR

RE: A Deep Dive on the Recent Widespread DNS Hijacking

[Jacques Latour]

DNSSEC should of never been part of the domain registration process, it was 
because we didn’t have the CDS/CDNSKEY channel to automated the DS maintenance 
and bootstrap. But if you keep DNSSEC maintenance outside the registrar control 
then it can be effective tool (amongst other) in identifying hijacks.  Taking 
away he ability of the bad actors to disable DNSSEC via registrar control panel.

This is what happens when you have all your eggs in one basket and you loose 
the keys to your kingdom.


From: NANOG  On Behalf Of Bill Woodcock
Sent: February 26, 2019 4:57 AM
To: Hank Nussbacher 
Cc: nanog@nanog.org
Subject: Re: A Deep Dive on the Recent Widespread DNS Hijacking



> On Feb 24, 2019, at 10:03 PM, Hank Nussbacher 
> mailto:h...@efes.iucc.ac.il>> wrote:
> Did you have a CAA record defined and if not, why not?

It’s something we’d been planning to do but, ironically, we’d been in the 
process of switching to Let’s Encrypt, and they were one of the two CAs whose 
process vulnerabilities the attackers were exploiting.  So, in this particular 
case, it wouldn’t have helped.

I guess the combination of CAA with a very expensive, or very manual, CA, might 
be an improvement.  But it’s still a band-aid on a bankrupt system.

We need to get switched over to DANE as quickly as possible, and stop wasting 
effort trying to keep the CA system alive with ever-hackier band-aids.

-Bill

Call for Presentations ICANN65 Marrakesh - June 24, 2019

[Jacques Latour]

Hi all!



Call for Presentations ICANN65 Marrakesh



 Call for Presentations

  39th TechDay

  at ICANN 65

 in Marrakesh



The ICANN Tech Working Group is again planning a technical workshop at

the ICANN 65 meeting in Marrakesh on Monday 2019-06-24, Blocks 3-5,

starting 13:30.



The TechDay workshop has been a part of ICANN meetings since 2006 and

has provided a forum for both experienced and new people to meet,

present and discuss technical topics related to registry and DNS work

and security.



We are specially interested in:



1. IDN



2. Disaster Planning and Mitigation



3. Techniques for fighting abuse



4. DNSSEC In particular: Getting Africa signed)



5. RDAP - what is it, implementing, authentication, challenges



6. IDNA2008 - emoji



7. In addition, we welcome suggestions for additional topics.





If you are interested in presenting, please email

ccnso-tech...@icann.org



We hope that you can join us and request that you disseminate this

Request to other lists where it might of interest.



Greetings,

Jacques, on behalf of the TechDay program Committee

Call for Participation -- ICANN DNSSEC Workshop at ICANN65, Marrakech, Morocco.

[Jacques Latour]

Call for Participation -- ICANN DNSSEC Workshop at ICANN65, Marrakech, Morocco.

The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, 
in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
are planning a DNSSEC Workshop during the ICANN65 meeting held from 24-27 June 
2019 in Marrakech, Morocco.  The DNSSEC Workshop has been a part of ICANN 
meetings for several years and has provided a forum for both experienced and 
new people to meet, present and discuss current and future DNSSEC deployments.  
For reference, the most recent session was held at the ICANN Community Forum in 
Kobe, Japan on 13 March 2019. The presentations and transcripts are available 
at:  https://64.schedule.icann.org/meetings/961937, 
https://64.schedule.icann.org/meetings/961938,
and https://64.schedule.icann.org/meetings/961939.

The DNSSEC Workshop Program Committee is developing a 3-hour program.  
Proposals will be considered for the following topic areas and included if 
space permits.  In addition, we welcome suggestions for additional topics 
either for inclusion in the ICANN65 workshop, or for consideration for future 
workshops.

1.  DNSSEC Activities Panel (Regional and global)
For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment in the region and also from those who have not deployed 
DNSSEC but who have a keen interest in the challenges and benefits of 
deployment, including Root Key Signing Key (KSK) Rollover activities.   Now 
that DNSSEC has become an operational norm for many registries, registrars, and 
ISPs, what have we learned about how we manage DNSSEC? What is the best 
practice around key rollovers? How often do you review your disaster recovery 
procedures? Is there operational familiarity within your customer support 
teams? What operational statistics have we gathered about DNSSEC? Are there 
experiences being documented in the form of best practices, or something 
similar, for transfer of signed zones?
If you have a specific concern about the Root Key Rollover, or believe you have 
a method or solution to help address impacts, we would like to hear from you.

2. DNSSEC Deployment Challenges
The program committee is seeking input from those that are interested in 
implementation of DNSSEC but have general or particular concerns with DNSSEC.  
In particular, we are seeking input from individuals that would be willing to 
participate in a panel that would discuss questions of the nature:
- Are there any policies directly or indirectly impeding your DNSSEC 
deployment? (RRR model, CDS/CDNSKEY automation)
- What are your most significant concerns with DNSSEC, e.g., complexity, 
training, implementation, operation or something else?
- What do you expect DNSSEC to do for you and what doesn't it do?
- What do you see as the most important trade-offs with respect to doing or not 
doing DNSSEC?

We are interested in presentations related to any aspect of DNSSEC such as zone 
signing, DNS response validation, applications use of DNSSEC, 
registry/registrar DNSSEC activities, etc.  In addition, we welcome suggestions 
for additional topics.

If you are interested in participating, please send a brief (1-2 sentence) 
description of your proposed presentation to 
dnssec-marrak...@isoc.org<mailto:dnssec-marrak...@isoc.org> by **Friday, 17 May 
2019**

Thank you,
Jacques

On behalf of the DNSSEC Workshop Program Committee:
Mark Elkins, DNS/ZACR
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Xiaodong Lee, Chinese Academy of Sciences (CAS)
Russ Mundy, Parsons
Ondrej Filip, CZ.NIC
Yoshiro Yoneya, JPRS
Dan York, Internet Society

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN74 Policy Forum

[Jacques Latour]

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN74  
Policy Forum

In cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
we are planning a DNSSEC and Security Workshop for the ICANN74 Public Forum 
being held as a hybrid meeting  from 13-16 June 2022 in the Central European 
Time Zone (UTC +1). This workshop date will be determined once ICANN creates a 
block schedule for us to follow; then we will be able to request a day and 
time. The DNSSEC and Security Workshop has been a part of ICANN meetings for 
several years and has provided a forum for both experienced and new people to 
meet, present and discuss current and future DNSSEC deployments.  For 
reference, the most recent session was held at the ICANN73 Community Forum on 
Wednesday 09 March 2022. The presentations and transcripts are available at 
https://73.schedule.icann.org/meetings/qGWqRxCjbWHqdGLxN,
https://73.schedule.icann.org/meetings/pm4Zz3yN3CgjoTXp2 and 
https://73.schedule.icann.org/meetings/qiGweLr2MS7zJwy8o.

The DNSSEC Workshop Program Committee is developing a program for the upcoming 
meeting.  Proposals will be considered for the following topic areas and 
included if space permits.  In addition, we welcome suggestions for additional 
topics either for inclusion in the ICANN74 workshop, or for consideration for 
future workshops.

1.  Global DNSSEC Activities Panel
For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment as well as from those who have not deployed DNSSEC but who 
have a keen interest in the challenges and benefits of deployment, including 
Root Key Signing Key (KSK) Rollover activities and plans.

2.  DNSSEC Best Practice
Now that DNSSEC has become an operational norm for many registries, registrars, 
and ISPs, what have we learned about how we manage DNSSEC?


  *   Do you still submit/accept DS records with Digest Type 1?
  *   What is the best practice around key rollovers?
  *   What about Algorithm rollovers?
  *   Do you use and support DNSKEY Algorithms 13-16?
  *   How often do you review your disaster recovery procedures?
  *   Is there operational familiarity within your customer support teams?
  *   What operational statistics have been gathered about DNSSEC?
  *   Are there experiences being documented in the form of best practices, or 
something similar, for transfer of signed zones?

Activities and issues related to DNSSEC in the DNS Root Zone are also desired.

3. DNSSEC Deployment Challenges
The program committee is seeking input from those that are interested in 
implementation of DNSSEC but have general or particular concerns with DNSSEC.  
In particular, we are seeking input from individuals that would be willing to 
participate in a panel that would discuss questions of the following nature:


  *   Are there any policies directly or indirectly impeding your DNSSEC 
deployment? (RRR model, CDS/CDNSKEY automation)
  *   What are your most significant concerns with DNSSEC, e.g., complexity, 
training, implementation, operation or something else?
  *   What do you expect DNSSEC to do for you and what doesn't it do?
  *   What do you see as the most important trade-offs with respect to doing or 
not doing DNSSEC?

4. Security Panel
The program committee is looking for presentations on DNS, DNSSEC, routing and 
other topics that could impact the security and/or stability of the Internet.

We are looking for presentations that cover implementation issues, challenges, 
opportunities and best practices for:


  *   Emerging threats that could impact the security and/or stability of the 
Internet
  *   DoH and DoT
  *   RPKI (Resource Public Key Infrastructure)
  *   BGP routing & secure implementations
  *   MANRS ( Mutually Agreed Norms for Routing Security)
  *   Browser security – DNS, DNSSEC, DoH
  *   EMAIL & DNS related security – DMARC, DKIM, TLSA, etc…

If you are interested in participating, please send a brief (1-3 sentence) 
description of your proposed presentation to 
dnssec-security-works...@icann.org<mailto:dnssec-security-works...@icann.org> 
by COB Friday, 29 April  2022.

Thank you,
Kathy and Andrew
On behalf of the DNSSEC Workshop Program Committee:
Steve Crocker, Shinkuro
Mark Elkins, DNS/ZACR
Jacques Latour, .CA
Russ Mundy, Parsons
Ondrej Filip, CZ.NIC
Yoshiro Yoneya, JPRS
Fred Baker, ISC
Dan York, Internet Society

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN75 Annual General Meeting

[Jacques Latour]

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN75  
Annual General Meeting

In cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
we are planning a DNSSEC and Security Workshop for the ICANN75 Annual General 
Meeting being held as a hybrid meeting from 17-22 September 2022 in the 
Malaysian Time Zone (UTC +8). This workshop date will be determined once ICANN 
creates a block schedule for us to follow; then we will be able to request a 
day and time. The DNSSEC and Security Workshop has been a part of ICANN 
meetings for several years and has provided a forum for both experienced and 
new people to meet, present and discuss current and future DNSSEC deployments.  
For reference, the most recent session was held at the ICANN74 Public Forum on 
Monday, 13 June 2022. The presentations and transcripts are available at 
https://74.schedule.icann.org/meetings/BCyJbniR9TpSCohBp#/, and
https://74.schedule.icann.org/meetings/WiPRZ59cBZDvj5ws2

The DNSSEC Workshop Program Committee is developing a program for the upcoming 
meeting.  Proposals will be considered for the following topic areas and 
included if space permits.  In addition, we welcome suggestions for additional 
topics either for inclusion in the ICANN75 workshop, or for consideration for 
future workshops.

1.  Global DNSSEC Activities Panel
For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment as well as from those who have not deployed DNSSEC but who 
have a keen interest in the challenges and benefits of deployment, including 
Root Key Signing Key (KSK) Rollover activities and plans.

2.  DNSSEC Best Practice
Now that DNSSEC has become an operational norm for many registries, registrars, 
and ISPs, what have we learned about how we manage DNSSEC?



  *   Do you still submit/accept DS records with Digest Type 1?
  *   What is the best practice around key roll-overs?
  *   What about Algorithm roll-overs?
  *   Do you use and support DNSKEY Algorithms 13-16?
  *   How often do you review your disaster recovery procedures?
  *   Is there operational familiarity within your customer support teams?
  *   What operational statistics have been gathered about DNSSEC?
  *   Are there experiences being documented in the form of best practices, or 
something similar, for transfer of signed zones?

Activities and issues related to DNSSEC in the DNS Root Zone are also desired.

3. DNSSEC Deployment Challenges
The program committee is seeking input from those that are interested in 
implementation of DNSSEC but have general or particular concerns with DNSSEC.  
In particular, we are seeking input from individuals that would be willing to 
participate in a panel that would discuss questions of the following nature:



  *   Are there any policies directly or indirectly impeding your DNSSEC 
deployment? (RRR model, CDS/CDNSKEY automation)
  *   What are your most significant concerns with DNSSEC, e.g., complexity, 
training, implementation, operation or something else?
  *   What do you expect DNSSEC to do for you and what doesn't it do?
  *   What do you see as the most important trade-offs with respect to doing or 
not doing DNSSEC?

4. Security Panel
The program committee is looking for presentations on DNS, DNSSEC, routing and 
other topics that could impact the security and/or stability of the Internet.

We are looking for presentations that cover implementation issues, challenges, 
opportunities and best practices for:



  *   Emerging threats that could impact the security and/or stability of the 
Internet
  *   DoH and DoT
  *   RPKI (Resource Public Key Infrastructure)
  *   BGP routing & secure implementations
  *   MANRS ( Mutually Agreed Norms for Routing Security)
  *   Browser security – DNS, DNSSEC, DoH
  *   EMAIL & DNS related security – DMARC, DKIM, TLSA, etc…

If you are interested in participating, please send a brief (1-3 sentence) 
description of your proposed presentation to 
dnssec-security-works...@icann.org<mailto:dnssec-security-works...@icann.org> 
by COB Friday, 12 August 2022.

Thank you,
Kathy and Andrew
On behalf of the DNSSEC Workshop Program Committee:
Steve Crocker, Shinkuro
Mark Elkins, DNS/ZACR
Jacques Latour, .CA
Russ Mundy, Parsons
Ondrej Filip, CZ.NIC
Yoshiro Yoneya, JPRS
Fred Baker, ISC
Dan York, Internet Society

BGP Visualization with Software Galaxies

[Jacques Latour]

I was looking for a functional version of a BGP visualisation tool like the one 
at NTT http://as2914.net/, it does not seem to work or be updated.

Is there a public facing functional tool somewhere? I like this tool to show 
the complexity of our internet from a spaceship point of view COOL 😊


  *   
https://github.com/anvaka/pm/tree/master/about#software-galaxies-documentation

Thanks!

Jacques

CfP - ICANN DNSSEC and Security Workshop for ICANN76 Community Forum in Cancún

[Jacques Latour]

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN76 
Community Forum

In cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
we are planning a DNSSEC and Security Workshop for the ICANN76 Community Forum 
being held as a hybrid meeting from 11-16 March 2023 in the Eastern Time Zone 
(GMT -5). This workshop date will be determined once ICANN creates a block 
schedule for us to follow; then we will be able to request a day and time. The 
DNSSEC and Security Workshop has been a part of ICANN meetings for several 
years and has provided a forum for both experienced and new people to meet, 
present and discuss current and future DNSSEC deployments.  For reference, the 
most recent sessions were held at the ICANN75 Annual General Meeting on 
Wednesday, 21 September 2022. The presentations and transcripts are available 
at https://75.schedule.icann.org/meetings/hvW7BbDtvbw4hoSTx, 
https://75.schedule.icann.org/meetings/WLtBZqEydncda7Dsr, and 
https://75.schedule.icann.org/meetings/8jcmXcKTEoPTr3NQw.

 The DNSSEC Workshop Program Committee is developing a program for the upcoming 
meeting.  Proposals will be considered for the following topic areas and 
included if space permits.  In addition, we welcome suggestions for additional 
topics either for inclusion in the ICANN75 workshop, or for consideration for 
future workshops.

1.  Global DNSSEC Activities Panel
For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment as well as from those who have not deployed DNSSEC but who 
have a keen interest in the challenges and benefits of deployment, including 
Root Key Signing Key (KSK) Rollover activities and plans.

2.  DNSSEC Best Practice
Now that DNSSEC has become an operational norm for many registries, registrars, 
and ISPs, what have we learned about how we manage DNSSEC?


  *   Do you still submit/accept DS records with Digest Type 1?
  *   What is the best practice around key roll-overs?
  *   What about Algorithm roll-overs?
  *   Do you use and support DNSKEY Algorithms 13-16?
  *   How often do you review your disaster recovery procedures?
  *   Is there operational familiarity within your customer support teams?
  *   What operational statistics have been gathered about DNSSEC?
  *   Are there experiences being documented in the form of best practices, or 
something similar, for transfer of signed zones?

Activities and issues related to DNSSEC in the DNS Root Zone are also desired.

3. DNSSEC Deployment Challenges
The program committee is seeking input from those that are interested in 
implementation of DNSSEC but have general or particular concerns with DNSSEC.  
In particular, we are seeking input from individuals that would be willing to 
participate in a panel that would discuss questions of the following nature:


  *   Are there any policies directly or indirectly impeding your DNSSEC 
deployment? (RRR model, CDS/CDNSKEY automation)
  *   What are your most significant concerns with DNSSEC, e.g., complexity, 
training, implementation, operation or something else?
  *   What do you expect DNSSEC to do for you and what doesn't it do?
  *   What do you see as the most important trade-offs with respect to doing or 
not doing DNSSEC?

4. Security Panel
The program committee is looking for presentations on DNS, DNSSEC, routing and 
other topics that could impact the security and/or stability of the Internet.

We are looking for presentations that cover implementation issues, challenges, 
opportunities and best practices for:


  *   Emerging threats that could impact the security and/or stability of the 
Internet
  *   DoH and DoT
  *   RPKI (Resource Public Key Infrastructure)
  *   BGP routing & secure implementations
  *   MANRS ( Mutually Agreed Norms for Routing Security)
  *   Browser security - DNS, DNSSEC, DoH
  *   EMAIL & DNS related security - DMARC, DKIM, TLSA, etc...

If you are interested in participating, please send a brief (1-3 sentence) 
description of your proposed presentation to 
dnssec-security-works...@icann.org<mailto:dnssec-security-works...@icann.org> 
by COB Friday, 20 January 2023.

Thank you,
Jacques
On behalf of the DNSSEC Workshop Program Committee:
Steve Crocker, Shinkuro
Mark Elkins, DNS/ZACR
Jacques Latour, .CA
Russ Mundy, Parsons
Ondrej Filip, CZ.NIC
Yoshiro Yoneya, JPRS
Fred Baker, ISC
Dan York, Internet Society

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN77 Policy Forum

[Jacques Latour]

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN77 Policy 
Forum



In cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
we are planning a DNSSEC and Security Workshop for the ICANN77 Policy Forum 
being held in Washington, DC and as a hybrid meeting from 12-15 June 2023 in 
the Eastern Time Zone (UTC -4). This workshop date will be determined once 
ICANN creates a block schedule for us to follow; then we will be able to 
request a day and time. The DNSSEC and Security Workshop has been a part of 
ICANN meetings for several years and has provided a forum for both experienced 
and new people to meet, present and discuss current and future DNSSEC 
deployments.  For reference, the most recent session was held at the ICANN76 
Community Forum on Wednesday,  15 March 2023. The presentations and transcripts 
are available at: 
https://icann76.sched.com/event/1J2JA/dnssec-and-security-workshop-1-of-3,

https://icann76.sched.com/event/1J2JD/dnssec-and-security-workshop-2-of-3 and

https://icann76.sched.com/event/1J2JE/dnssec-and-security-workshop-3-of-3.


The DNSSEC Workshop Program Committee is developing a program for the upcoming 
meeting.  Proposals will be considered for the following topic areas and 
included if space permits.  In addition, we welcome suggestions for additional 
topics either for inclusion in the ICANN77 workshop, or for consideration for 
future workshops.



1.  Global DNSSEC Activities Panel

For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment as well as from those who have not deployed DNSSEC but who 
have a keen interest in the challenges and benefits of deployment, including 
Root Key Signing Key (KSK) Rollover activities and plans.



2.  DNSSEC Best Practice

Now that DNSSEC has become an operational norm for many registries, registrars, 
and ISPs, what have we learned about how we manage DNSSEC?


  *   Do you still submit/accept DS records with Digest Type 1?
  *   What is the best practice around key roll-overs?
  *   What about Algorithm roll-overs?
  *   Do you use and support DNSKEY Algorithms 13-16?
  *   How often do you review your disaster recovery procedures?
  *   Is there operational familiarity within your customer support teams?
  *   What operational statistics have been gathered about DNSSEC?
  *   Are there experiences being documented in the form of best practices, or 
something similar, for transfer of signed zones?



Activities and issues related to DNSSEC in the DNS Root Zone are also desired.



3. DNSSEC Deployment Challenges

The program committee is seeking input from those that are interested in 
implementation of DNSSEC but have general or particular concerns with DNSSEC.  
In particular, we are seeking input from individuals that would be willing to 
participate in a panel that would discuss questions of the following nature:


  *   Are there any policies directly or indirectly impeding your DNSSEC 
deployment? (RRR model, CDS/CDNSKEY automation)
  *   What are your most significant concerns with DNSSEC, e.g., complexity, 
training, implementation, operation or something else?
  *   What do you expect DNSSEC to do for you and what doesn't it do?
  *   What do you see as the most important trade-offs with respect to doing or 
not doing DNSSEC?



4. Security Panel

The program committee is looking for presentations on DNS, DNSSEC, routing and 
other topics that could impact the security and/or stability of the Internet.



We are looking for presentations that cover implementation issues, challenges, 
opportunities and best practices for:


  *   Emerging threats that could impact the security and/or stability of the 
Internet
  *   DoH and DoT
  *   RPKI (Resource Public Key Infrastructure)
  *   BGP routing & secure implementations
  *   MANRS ( Mutually Agreed Norms for Routing Security)
  *   Browser security - DNS, DNSSEC, DoH
  *   EMAIL & DNS related security - DMARC, DKIM, TLSA, etc...



If you are interested in participating, please send a brief (1-3 sentence) 
description of your proposed presentation to 
dnssec-security-works...@icann.org<mailto:dnssec-security-works...@icann.org> 
by Friday, 12 May 2023.



Thank you,

Jacques

On behalf of the DNSSEC Workshop Program Committee:

Steve Crocker, Shinkuro

Mark Elkins, DNS/ZACR

Jacques Latour, .CA

Russ Mundy, Parsons

Ondrej Filip, CZ.NIC

Yoshiro Yoneya, JPRS

Fred Baker, ISC

Dan York, Internet Society

RE: IPv6 deployment excuses - IPv6 only resources

[Jacques Latour]

Is there a list of IPv6 only ISP or services?  I'd be curious to trend that 
somehow, by geography, service type, etc... if any.

>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mark Andrews
>Sent: July-04-16 9:49 AM
>To: Matt Hoppes
>Cc: Tore Anderson; nanog@nanog.org
>Subject: Re: IPv6 deployment excuses
>
>
>In message c2ae05bcc...@rivervalleyinternet.net>, Matt  Hoppes writes:
>> I disagree. Any data center or hosting provider is going to continue
>> to offer IPv4 lest they island themselves from subscribers who have
>> IPv4 only - which no data center is going to do.
>>
>> One can not run IPv6 only because there are sites that are only IPv4.
>>
>> Thus, as an ISP you can safely continue to run IPv4. Ipv4 won't be
>> going away for at least ten years or more - if ever.
>>
>> I'm not saying don't be ready for IPv6. I'm not saying don't
>> understand how it works. But doomsday isn't here.
>
>There are ISP's that are essentially IPv6 only today as they do not have enough
>IPv4 addresses to give all their customers a public
>IPv4 address.
>
>Once you need to run a GGN you may as well run DS-Lite, MAP* or
>(shudder) DNS64/NAT64 as NAT444.  There is no need to talk IPv4 to your
>customers today.  You still need a small number of IPv4 address to talk to
>legacy IPv4 servers on the internet.  Just because there owners don't know they
>are legacy servers doesn't mean they aren't.
>
>Mark
>--
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

RE: Speedtest.net not accessible in Chrome due to deceptive ads

[Jacques Latour]

In that case, for Canadians, go to http://performance.cira.ca, it's MLAB-NDT 
based and checks IPv6 and DNSSEC :-)

100% ad free

>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ishmael Rufus
>Sent: July-20-16 10:33 AM
>To: Janusz Jezowicz
>Cc: NANOG list
>Subject: Re: Speedtest.net not accessible in Chrome due to deceptive ads
>
>http://www.measurementlab.net/tools/ndt/
>
>100% ad free.
>
>On Wed, Jul 20, 2016 at 7:55 AM, Janusz Jezowicz 
>wrote:
>
>> It seems that some users reporting the site is back. I am counting 6+
>> hours of outage.
>>
>> Alan - what you describe is something normal user will never do. When
>> user sees red screen like that, he runs screaming. So in theory yes,
>> it was accessible, but ... wasn't.
>>
>> Its hard to avoid Google nanny when they offer so many useful services
>>
>>
>>
>> On 20 July 2016 at 14:09,  wrote:
>>
>> > Hi,
>> >
>> > > Since this morning Speedtest.net is not accessible in Chrome
>> > > Reason:
>> > >
>> >
>> https://www.google.com/transparencyreport/safebrowsing/diagnostic/#url
>> =c.speedtest.net
>> >
>> > someones complained about the URL based on them stupidly installing
>> > 'cleanmymac' or such?
>> >
>> > use the non flash junk HTML5 version instead
>> >
>> > http://beta.speedtest.net/
>> >
>> > still bleats about "Deceptive site ahead"
>> >
>> > and PS "is not accessible in Chrome" - not true.
>> >
>> > click DETAILS,  then click on
>> >
>> > visit this unsafe site.
>> >
>> > (with the pre-condition of " if you understand the risks to your
>> security"
>> >
>> >
>> > I personally dont want or need Google to start being my nanny on the
>> > internet  :/
>> >
>> >
>> > alan
>> >
>> > PS you may have other interests involved here given your affiliation
>> > to speedchecker.xyz
>> >
>>

Re: Speedtest.net not accessible in Chrome due to deceptive ads

[Jacques Latour]

Yup, websocket implementations across all browsers not equal

On 2016-07-20, 2:56 PM, "NANOG on behalf of David"
 wrote:

>On 2016-07-20 12:52 PM, Jacques Latour wrote:
>> In that case, for Canadians, go to http://performance.cira.ca, it's
>>MLAB-NDT based and checks IPv6 and DNSSEC :-)
>>
>> 100% ad free
>>
>
>And on the flip side, refuses to work with Safari.

RE: Speedtest.net not accessible in Chrome due to deceptive ads

[Jacques Latour]

Good point, we would need a piece of websocket code to run before or after NDT 
that figures out MAX speed so end users we can compare with other speed tests.
NDT is about the quality of a connection, not absolute maximum quantity that 
can be jammed on a link irrespective of errors and all.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Livingood,
>Jason
>Sent: July-22-16 8:33 AM
>To: Collin Anderson; Antonio Querubin
>Cc: NANOG list
>Subject: Re: Speedtest.net not accessible in Chrome due to deceptive ads
>
>And work on accurate measurement of higher link speeds. ;-)
>
>On 7/20/16, 11:42 PM, "NANOG on behalf of Collin Anderson" boun...@nanog.org on behalf of col...@averysmallbird.com> wrote:
>
>On Wed, Jul 20, 2016 at 5:00 PM, Antonio Querubin 
>wrote:
>
>> Feedback:  needs IPv6 connectivity and support.
>>
>
>Point well taken. The vast majority of M-Lab sites have IPv6 connectivity,
>and we have enabled it for NDT at times, but I believe there was a concern
>at one point about an issue with error handling on the IPv6 side that lead
>to it being disabled temporarily. We will follow through on this.
>
>
>--
>*Collin David Anderson*
>averysmallbird.com | @cda | Washington, D.C.
>
>

Call For Presentations - DNS-OARC Workshop 27, San Jose, CA, USA, 29-30 September 2017

[Jacques Latour]

[with apologies to those who see this on multiple lists]

Call For Presentations

The DNS-OARC 27th Workshop will take place in San Jose, CA, USA
on September 29th and 30th 2017, the Friday and Saturday preceding
NANOG 71.  The Workshop's Program Committee is now requesting proposals
for presentations.  All DNS-related subjects are welcome.

If you are an OARC member, and have a sensitive topic you would like to
present for members-only, we can accommodate those talks during the
Members Only session on the morning of September 29th.  A timeslot will
also be available for lightning talks (5-10 minutes) on Saturday September
30th, for which submissions will be accepted during Friday 29th.

Workshop Milestones:

  26 May 2017, Call for Presentations posted and open for submissions
  28 July 2017, Deadline for submission
  11 August 2017, Draft Programme published
  01 September 2017, Final Program published
  15 September 2017, Final deadline for slideset submission

Details for presentation submission will be published here:

https://indico.dns-oarc.net/event/27/call-for-abstracts/

The workshop presentations will be organized by common themes, depending
on the topics and the timing of each presentation. There are 30-minute
and 15-minute slots, let us know your preference in your submission.

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides.  Draft slides are acceptable on submission.

If you have questions or concerns you can contact the Programme Committee:

https://www.dns-oarc.net/oarc/programme

via 

Ray Bellis, for the OARC Programme Committee

OARC depends on sponorship to fund its workshops and associated social
events.  Please contact  if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)

RE: Canada and IPv6 (& DNSSEC)

[Jacques Latour]

At .ca, we see a very low IPv6 adoption rate in .ca domains and slow 
progression rate. See last ~3 years trends at www.cira.ca/radarv6

Just as an indicator, we have 316 .ca domains with IPv6 glue records :-(

***
Can the major Canadian ISP reply back with their plans/timelines/costs on IPv6 
offerings for commercial and residential services?  CIRA could compile this 
info somewhere for reference.
***

BTW, while at it, we have a lot of work to do for DNSSEC validation in Canada; 
some stats filtered with more than 4000 clients as measured early 2014 by 
APNIC, Geoff Huston. (thanks Geoff!)

Canada is #96   :-(

AS Name RankASN Total End 
Clients   % DNSSEC validation
--- 
--- --  ---
TEKSAVVY-TOR TekSavvy Solutions Inc. Toronto156 56454804
82.56
COGECOWAVE - Cogeco Cable   923 79925424
17.02
ROGERS-CABLE - Rogers Cable Communications Inc. 3115812 28884   
1.39
SHAW - Shaw Communications Inc. 3270632729083   
1.18
ASN852 - TELUS Communications Inc.  3497852 22994   
0.93
VIDEOTRON - Videotron Telecom Ltee  351257699669
0.91
BACOM - Bell Canada 3517577 28392   
0.9
CANET-ASN-4 - Bell Aliant Regional Communications   3753855 4053
0.64


Jack


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Alejandro Acosta
Sent: June-19-14 11:47 PM
To: nanog@nanog.org
Subject: Re: Canada and IPv6

Not residential IPv6 connectivity but today I got this news:

http://www.ourmidland.com/prweb/cirrushosting-to-support-ipv-on-canadian-vps-and-cloud-hosting/article_4d28a39c-1c3f-5209-939b-10d8cf310564.html


El 6/18/2014 7:46 PM, Sadiq Saif escribió:
> On 6/18/2014 14:25, Lee Howard wrote:
>> Canada is way behind, just 0.4% deployment.
> 
> Any Canadian ISP folk in here want to shine a light on this dearth of 
> residential IPv6 connectivity?
> 
> Is there any progress being made on this front?
> 

.ca anycast expansion

[Jacques Latour]

Hi all!

At .ca, we're currently working on expanding our .ca anycast infrastructure 
(any.ca-servers.ca) on ASN 55195 - 199.4.144.0/24.  For now, we're looking to 
expand in colocation centers (IXP connected) in the following locations:


-  NOTA - NAP of the Americas Miami, FL

-  CoreSite - Any2 California - Los Angeles, CA

-  AMSIX - Amsterdam

-  Equinix Singapore

Looking for ½ rack and ability to connect to HE transit and IXP x-connect.

Please reply off-list,

Thanks,

Jack

RE: Vancouver IXP - VanTX - BCNet

[Jacques Latour]

The main reason we are collecting feedback for Vancouver is that both VANTX and 
PIX are not member based IXP organizations, VANTX is owned and operated by 
BCnet, a R&E organization, and PIX is owned and operated by Peer1.

We heard from a few people in Vancouver that they would like to have a true 
open, neutral and member based IXP, the idea for the town hall meeting is to 
build the community around a Vancouver IXP.  BCnet has a good story to tell 
about VANTX, community support and IXPs across the province.

If you care about Vancouver, then let us know.  I'll see what I can do about 
the poutine :-)


From: Bill Woodcock [wo...@pch.net]
Sent: August 20, 2013 11:14 PM
To: North American Network Operators' Group
Subject: Re: Vancouver IXP - VanTX - BCNet

On Aug 20, 2013, at 8:02 PM, Christopher Morrell 
 wrote:
> In Winnipeg, isn't there also the WPGIX? Do you have two competing IXPs in 
> Winnipeg?

There are nominally competing efforts in Winnipeg (MBIX and WPGIX), Calgary 
(YYCIX and AlbertaIX), Montreal (QIX and Peer1), Vancouver (BCIX and Peer1), 
and even Toronto (TorIX, Peer1, CANIX, and IIX).

I would not characterize more than one of those in each city as a going 
concern, however.

https://pch.net/ixpdir

-Bill

RE: Vancouver IXP - VanTX - BCNet

[Jacques Latour]

Bill, not true.

Following on our vision for Canada to have an IXP in every major city, 
specifically for Calgary, CIRA worked with CYBERA to organize a town hall 
meeting in Calgary, on September 14, 2013.  At the meeting, we had interested 
members of the community (Content delivery, ISP, government, R&E, CIRA, others) 
together to start the development of a new IXP in Calgary.

Cybera being local, they took the lead in working with the community members in 
setting up governance, technical architecture, location, etc...  CIRA actively 
participated in the various committees.

CIRA is planning the deployment of equipment for the IXP, a .ca DNS Anycast 
stack, NTP servers and space for M-Lab nodes.  We also work with PCH to have a 
PCH anycast stack installed in Calgary.  We talked to Akamai and Google to be 
part of the Calgary IXP.  HE actually did build to Data Hive (Preferred data 
center in Calgary).  Doing our part in trying to get as much content, ISP, 
eyeballs, core internet services to be present at IXP.  The AlbertaIX is cash 
poor at that moment in time so CIRA was looking at options to fund equipment or 
provide start-up grants, nothing was done up to now with respect to providing 
equipment or funds.

Note: CIRA's job is not to go in and put a switch and leave.  CIRA works with 
the community to get the IXP up and running.  We have criteria to participate,  
the IXP must be a member based, vendor neutral non-profit organization with a 
viable trusted community to operate and sustain an IXP.  CIRA is acting as a 
catalyst, not a doer. The community is the doer.  Ask the people in Winnipeg 
www.mbix.ca and Montreal qix.ca . We are planning the launch of mbix this 
September as well.  This is an example where the IXP build was successful.

Back to Calgary, something special occurred, while we were all working on 
setting up AlbertaIX (we started fast but the pace slowed down significantly), 
a new IXP came to 'life' YYCIX in Data Hive, yycix.ca.  Long story short, CIRA 
is waiting for things to settle before we continue providing more support and 
invest in deployment our .CA infrastructure.  When the "dust" settles, we will 
deploy our .ca infrastructure and be a member of the communities (peer).

There's a chance we're going to have two IXPs in Calgary, hopefully they would 
be in the same data center to leverage our investment,  if we have two, then 
it's going to make it confusing for the new potential peers to pick the right 
one or both.

All in all, CIRA's objective was to have 1 IXP in Calgary, we have one now, 
perhaps 2 in the future, so mission accomplished.  It's up to the community to 
get their act together (no pun intended), and if they need our help, then we're 
there to help with governance, funding, technical expertise, etc...

Also, we're doing our best with our limited resources,

Jack

(NOTE: English not my first language, if you're not sure what I mean, ask me, 
don't assume)



> -Original Message-
> From: Bill Reid [mailto:b...@mbix.ca]
> Sent: August-23-13 11:55 AM
> To: nanog@nanog.org
> Subject: Re: Vancouver IXP - VanTX - BCNet
> 
> On 23/08/13 09:56, Mark Leonard wrote:
> > On Tue, Aug 20, 2013 at 6:52 AM, Joe Abley  wrote:
> >
> >> What CIRA is doing is providing support in the areas where previous
> >> efforts have struggled, providing hardware, accounts payable, legal,
> >> help with incorporation and forming sensible bylaws and stimulating
> >> local discussion and interest. My perspective is that they have done
> >> a great job in Calgary and Montréal. It sounds like the approach in
> >> Vancouver (engage with existing efforts, see where CIRA can help) is
> following the same path.
> >>
> >
> > What has CIRA done in Calgary?
> >
> CIRA has done a great job in Winnipeg and Montreal. Nothing in Calgary.

RE: Hotels/Airports with IPv6

[Jacques Latour]

Just turn IPv6 on when you can.

> We manage 65+ hotels in Canada and the topic of IPv6 for guest internet
> connectivity has never been brought up, except by me. It's not a discussion 
> our
> vendors or the hotel brands have opened either.

I would argue customers never asked an IPv4 connection either, they asked for 
an Internet connection.  The Internet is IPv4 and IPv6.

> > I working on a large airport WiFi deployment right now. IPv6 is
> > "allowed for in the future" but not configured in the short term. With
> > less than
> > 10,000 ephemeral users, we don't expect users to demand IPv6 until
> > most mobile devices and apps come ready to use IPv6 by default.

End users will never demand IPv6, turn it on :-)

RE: Dual stack IPv6 for IPv4 depletion

[Jacques Latour]

Hi,

Dual stack is where we need to go 'now', but we need to think about the future 
where we run an IPv6 only stack and stop thinking how to leverage, extend, 
expand and create ugly IPv4 solutions. IPv4 is done; it served its purpose 
well, thank you. We need a date where IPv4 is no longer routed on the Internet. 
I am suggesting 4/4/2024. Whatever the timeline, we need to agree on the date 
and drive toward a common goal for a better Internet.

My 2 Canadian cents :-)

Jack


> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Joe Maimon
> Sent: July-16-15 11:24 AM
> To: Doug Barton; nanog@nanog.org
> Subject: Re: Dual stack IPv6 for IPv4 depletion
> 
> 
> 
> Doug Barton wrote:
> 
> >
> > Joe,
> >
> > In this post, and in your many other posts today, you seem to be
> > asserting that this would work if "$THEY" would just get out of the
> > way, and let it work. You've also said explicitly that you believe
> > that this is an example of top-down dictates. I know you may find this
> > hard to believe, but neither of these ideas turn out to be accurate. A
> > little history ...
> >
> > In 2004 I was the manager of the IANA. Tony Hain came to me and said
> > that he'd been crunching some numbers and his preliminary research
> > indicated that the burn rate on IPv4 was increasing fairly
> > dramatically, and that runout was likely to happen a lot sooner than
> > folks expected it would. Various people started doing their own
> > research along similar lines and confirmed Tony's findings.
> >
> > So amongst many others, I started taking various steps to "get ready"
> > for IPv4 runout. One of those steps was to talk to folks about the
> > feasibility of utilizing Class E space. Now keep in mind that I have
> > no dog in this hunt. I've never been part of an RIR, I've never worked
> > for a network gear company, I'm a DNS guy. To me, bits are bits.
> >
> > I was told, universally, that there was no way to make Class E space
> > work, in the public Internet or private networks (because the latter
> > was being considered as an expansion of 1918). There are just too many
> > barriers, not the least of which is the overwhelming number of
> > person-years it would take to rewrite all the software that has
> > assumptions about Class E space hard coded.
> >
> > Further, the vendors we spoke to said that they had no intention of
> > putting one minute's worth of work into that project, because the ROI
> > was basically zero. In order for address space to "work" the standard
> > is universal acceptance ... and that was simply never going to happen.
> > There are literally hundreds of millions of devices in active use
> > right now that would never work with Class E space because they cannot
> > be updated.
> >
> > Of course it's also true that various folks, particularly the IETF
> > leadership, were/are very gung ho that IPv6 is the right answer, so
> > any effort put into making Class E space work is wasted effort; which
> > should be spent on deploying IPv6. On a *personal* level I agree with
> > that sentiment, but (to the extent I'm capable of being objective) I
> > didn't let that feeling color my effort to get an honest answer from
> > the many folks I talked to about this.
> >
> > But all that said, nothing is stopping YOU from working on it. :)  The
> > IETF can't stop you, the vendors can't stop you, no one can stop you ...
> > if you think you can make it work, by all means, prove us all wrong. :)
> >   Find some others that agree with you, work on the code, do the
> > interoperability tests, and present your work. You never know what
> > might happen.
> >
> > In the meantime, please stop saying that not using this space was
> > dictated from the top down, or that any one party/cabal/etc. is
> > holding you back, because neither of those are accurate.
> >
> > Good luck,
> >
> > Doug
> >
> 
> 
> Thanks for the this.
> 
> To clarify, my criticism of top down is specifically in response to the 
> rationale
> presented that it is a valid objective to prevent, hinder and refuse to enable
> efforts that "compete" with ipv6 world-takeover resources.
> 
> I have no intention of using Class E. I have no intention of developing code 
> that
> uses Classe E. I will note that the code involved that is publicly searchable
> appears to be simple and small, the task that is large is adoption spread.
> 
> But perhaps we can all agree that standards should be accurate and should not
> be used to advance uninvolved agenda. And class E experimental status is
> inaccurate. And keeping that status serves nobody, except those who believe it
> helps marshal efforts away from IPv4. And that is top down.
> 
> Burn rate is specious. Applying liberally constrained green-field burn-rate 
> as a
> projection of ROI on brownfield space likely to be heavily constrained by
> market force if nothing else is wholly inapplicable and inaccurate.
> 
> Joe

RE: Another Big day for IPv6 - 10% native penetration

[Jacques Latour]

Great news and even more impressive is that Canada is the fastest adopter with 
~8% IPv6 penetration, growing from almost 0.5% to 8% in 3 months!!!.  See 
http://stats.labs.apnic.net/ipv6/CA

Telus is making a big difference in Canada as the IPv6 adoption leader @ ~45% 
IPv6 adoption.http://stats.labs.apnic.net/ipv6/AS852?c=CA&g=&w=1&x=1

Hint, hint, subliminal message here for all Canadian ISPs, IPv6 works  ;-)

So let's shutdown IPv4 on April 4, 2024 

Bonne Année!



> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jared Mauch
> Sent: January-04-16 11:28 AM
> To: Ca By
> Cc: nanog@nanog.org
> Subject: Re: Another Big day for IPv6 - 10% native penetration
> 
> 
> > On Jan 4, 2016, at 11:09 AM, Ca By  wrote:
> >
> >> On Mon, Jan 4, 2016 at 3:26 AM, Neil Harris 
> wrote:
> >>
> >>> On 02/01/16 15:35, Tomas Podermanski wrote:
> >>>
> >>> Hi,
> >>>
> >>> according to Google's statistics
> >>> (https://www.google.com/intl/en/ipv6/statistics.html) on 31st
> >>> December
> >>> 2015 the IPv6 penetration reached 10% for the very first time. Just
> >>> a little reminder. On 20th Nov 2012 the number was 1%. In December
> >>> we also celebrated the 20th anniversary of IPv6 standardization - RFC
> 1883.
> >>>
> >>> I'm wondering when we reach another significant milestone - 50% :-)
> >>>
> >>> Tomas
> >> Given the recent doubling growth, and assuming this trend is
> >> following a logistic function, then, rounding the numbers a bit for
> neatness, I get:
> >>
> >> Jan 2016: 10%
> >> Jan 2017: 20%
> >> Jan 2018: 33%
> >> Jan 2019: 50%
> >> Jan 2020: 67%
> >> Jan 2021: 80%
> >> Jan 2022: 90%
> >>
> >> with IPv4 traffic then halving year by year from then on, and IPv4
> >> switch-off (ie. traffic < 1%) around 2027.
> >>
> >> Neil
> > Just a reminder, that 10% is a global number.
> >
> > The number in the USA is 25% today in general, is 37% for mobile devices.
> >
> > Furthermore, forecasting is a dark art that frequently simply extends
> > the past onto the future.  It does not account for purposeful
> > engineering design like the "world IPv6 launch" or iOS updates.
> >
> > For example, once Apple cleanses the app store of IPv4 apps in 2016 as
> > they have committed and pushes one of their ubiquitous iOS updates,
> > you may see substantial jumps over night in IPv6 eyeballs, possibly
> > meaningful moving that 37% number to over 50% in a few shorts weeks.
> >
> > This will squarely make it clear that IPv4 is minority legacy protocol
> > for all of mobile, and thusly the immediate future of the internet.
> 
> I for one welcome the iOS update that brings v6 APN native access to my
> phone, or at least v4v6 APN setting.
> 
> I keep hearing rumors it is "coming soon".
> 
> This could have a similar step function in the traffic and graphs.

Pinging TELUS: Another Big day for IPv6 - 10% native penetration

[Jacques Latour]

Hi,
Can someone from Telus ping me off-list re:IPv6 deployment.
Jack

> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jacques
> Latour
> Sent: January-04-16 11:45 AM
> To: Jared Mauch; Ca By; nanog@nanog.org
> Subject: RE: Another Big day for IPv6 - 10% native penetration
> 
> Great news and even more impressive is that Canada is the fastest adopter
> with ~8% IPv6 penetration, growing from almost 0.5% to 8% in 3 months!!!.
> See http://stats.labs.apnic.net/ipv6/CA
> 
> Telus is making a big difference in Canada as the IPv6 adoption leader @
> ~45% IPv6 adoption.
> http://stats.labs.apnic.net/ipv6/AS852?c=CA&g=&w=1&x=1
> 
> Hint, hint, subliminal message here for all Canadian ISPs, IPv6 works  ;-)
> 
> So let's shutdown IPv4 on April 4, 2024
> 
> Bonne Année!
> 
> 
> 
> > -Original Message-
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jared
> Mauch
> > Sent: January-04-16 11:28 AM
> > To: Ca By
> > Cc: nanog@nanog.org
> > Subject: Re: Another Big day for IPv6 - 10% native penetration
> >
> >
> > > On Jan 4, 2016, at 11:09 AM, Ca By  wrote:
> > >
> > >> On Mon, Jan 4, 2016 at 3:26 AM, Neil Harris
> > >> 
> > wrote:
> > >>
> > >>> On 02/01/16 15:35, Tomas Podermanski wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> according to Google's statistics
> > >>> (https://www.google.com/intl/en/ipv6/statistics.html) on 31st
> > >>> December
> > >>> 2015 the IPv6 penetration reached 10% for the very first time.
> > >>> Just a little reminder. On 20th Nov 2012 the number was 1%. In
> > >>> December we also celebrated the 20th anniversary of IPv6
> > >>> standardization - RFC
> > 1883.
> > >>>
> > >>> I'm wondering when we reach another significant milestone - 50%
> > >>> :-)
> > >>>
> > >>> Tomas
> > >> Given the recent doubling growth, and assuming this trend is
> > >> following a logistic function, then, rounding the numbers a bit for
> > neatness, I get:
> > >>
> > >> Jan 2016: 10%
> > >> Jan 2017: 20%
> > >> Jan 2018: 33%
> > >> Jan 2019: 50%
> > >> Jan 2020: 67%
> > >> Jan 2021: 80%
> > >> Jan 2022: 90%
> > >>
> > >> with IPv4 traffic then halving year by year from then on, and IPv4
> > >> switch-off (ie. traffic < 1%) around 2027.
> > >>
> > >> Neil
> > > Just a reminder, that 10% is a global number.
> > >
> > > The number in the USA is 25% today in general, is 37% for mobile devices.
> > >
> > > Furthermore, forecasting is a dark art that frequently simply
> > > extends the past onto the future.  It does not account for
> > > purposeful engineering design like the "world IPv6 launch" or iOS updates.
> > >
> > > For example, once Apple cleanses the app store of IPv4 apps in 2016
> > > as they have committed and pushes one of their ubiquitous iOS
> > > updates, you may see substantial jumps over night in IPv6 eyeballs,
> > > possibly meaningful moving that 37% number to over 50% in a few shorts
> weeks.
> > >
> > > This will squarely make it clear that IPv4 is minority legacy
> > > protocol for all of mobile, and thusly the immediate future of the 
> > > internet.
> >
> > I for one welcome the iOS update that brings v6 APN native access to
> > my phone, or at least v4v6 APN setting.
> >
> > I keep hearing rumors it is "coming soon".
> >
> > This could have a similar step function in the traffic and graphs.

RE: Call For Presentations - DNS-OARC Workshop 27, San Jose, CA, USA, 29-30 September 2017

[Jacques Latour]

Hi All!

> DNS-OARC Workshop 27, San Jose, CA, USA, 29-30 September 2017

Seems like a good time to send a reminder that we still have some presentation 
slots available.

> https://indico.dns-oarc.net/event/27/call-for-abstracts/

Jacques
 

> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jacques
> Latour
> Sent: Friday, May 26, 2017 9:43 AM
> To: nanog@nanog.org
> Subject: Call For Presentations - DNS-OARC Workshop 27, San Jose, CA, USA,
> 29-30 September 2017
> 
> [with apologies to those who see this on multiple lists]
> 
> Call For Presentations
> 
> The DNS-OARC 27th Workshop will take place in San Jose, CA, USA on
> September 29th and 30th 2017, the Friday and Saturday preceding NANOG
> 71.  The Workshop's Program Committee is now requesting proposals for
> presentations.  All DNS-related subjects are welcome.
> 
> If you are an OARC member, and have a sensitive topic you would like to
> present for members-only, we can accommodate those talks during the
> Members Only session on the morning of September 29th.  A timeslot will
> also be available for lightning talks (5-10 minutes) on Saturday September
> 30th, for which submissions will be accepted during Friday 29th.
> 
> Workshop Milestones:
> 
>   26 May 2017, Call for Presentations posted and open for submissions
>   28 July 2017, Deadline for submission
>   11 August 2017, Draft Programme published
>   01 September 2017, Final Program published
>   15 September 2017, Final deadline for slideset submission
> 
> Details for presentation submission will be published here:
> 
> https://indico.dns-oarc.net/event/27/call-for-abstracts/
> 
> The workshop presentations will be organized by common themes,
> depending on the topics and the timing of each presentation. There are 30-
> minute and 15-minute slots, let us know your preference in your submission.
> 
> To allow the Programme Committee to make objective assessments of
> submissions, so as to ensure the quality of the workshop, submissions
> SHOULD include slides.  Draft slides are acceptable on submission.
> 
> If you have questions or concerns you can contact the Programme
> Committee:
> 
> https://www.dns-oarc.net/oarc/programme
> 
> via 
> 
> Ray Bellis, for the OARC Programme Committee
> 
> OARC depends on sponorship to fund its workshops and associated social
> events.  Please contact  if your organization is
> interested in becoming a sponsor.
> 
> (Please note that OARC is run on a non-profit basis, and is not in a position 
> to
> reimburse expenses or time for speakers at its meetings.)

Call for Participation -- ICANN DNSSEC Workshop at ICANN60 in Abu Dhabi, UAE

[Jacques Latour]

fy gaps?
* What are some of the new and innovative uses of DANE and other DNSSEC 
applications in new areas or industries?
* What tools and services are now available that can support DANE usage?

We would be particularly interested in any live demonstrations of DNSSEC / DANE 
application automation and services.  Demonstrations of new tools that make the 
setup of DNSSEC or DANE more automated would also be welcome.

6.  DNSSEC and DANE in the enterprise and in the enterprise tool set

Enterprises and enterprise software can play a critical role in both providing 
DNSSEC validation to their internal networks and also through signing of the 
domains owned by the enterprise. We are seeking presentations from enterprises 
and enterprise software providers that have implemented DNSSEC on validation 
and/or signing processes and can address questions such as:
* What enterprise software support or plan do you have to support DNSSEC?
* What are the benefits to enterprises of rolling out DNSSEC validation? And 
how do they do so?
* What are the challenges to deployment for these organizations and how could 
DANE and other DNSSEC applications address those challenges?
* How should an enterprise best prepare its IT staff and network to implement 
DNSSEC?
* What enterprise tools and systems are available to assist enterprises in the 
deployment of DNSSEC?
* How can the DANE protocol be used within an enterprise to bring a higher 
level of security to transactions using SSL/TLS certificates?

7.  Implementing DNSSEC validation at Internet Service Providers (ISPs)

Internet Service Providers (ISPs) play a critical role by enabling DNSSEC 
validation for the caching DNS resolvers used by their customers.  We have now 
seen massive rollouts of DNSSEC validation within large North American ISPs and 
at ISPs around the world.  We are interested in presentations on topics such as:
* Can you describe your experiences with negative Trust Anchors and operational 
realities?
* What does an ISP need to do to prepare its network for implementing DNSSEC 
validation?
* How does an ISP need to prepare its support staff and technical staff for the 
rollout of DNSSEC validation?
* Can you provide results and/or impacts of the impact of root key rollover?
* What rollover technique do you use, i.e., RFC 5011 or other?

In addition, we welcome suggestions for additional topics.

If you are interested in participating, please send a brief (1-2 sentence) 
description of your proposed presentation to 
dnssec-abudh...@isoc.org<mailto:dnssec-abudh...@isoc.org> by **08 September 
2017**

We hope that you can join us.

Thank you,

Julie Hedlund

On behalf of the DNSSEC Workshop Program Committee:
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Xiaodong Lee, CNNIC
Russ Mundy, Parsons
Ondřej Filip, CZ.NIC
Yoshiro Yoneya, JPRS
Dan York, Internet Society
Mark Elkins, DNS/ZACR

Question about Customer Population by ASN for Canada

[Jacques Latour]

Hi all!

I'm working on our IPv6 and DNSSEC adoption report for Canada and the data I 
use comes largely from APNIC (https://stats.labs.apnic.net/dnssec/CA) and 
(https://stats.labs.apnic.net/ipv6/CA).

Labs.APNIC has a pretty cool system to measure this kind of stuff by deploying 
specially crafted google ads, see "How Big is that Network?"  
https://labs.apnic.net/?p=526, and APNIC is able to assess the population 
behind a network based on ad placement distribution. See 
https://stats.labs.apnic.net/cgi-bin/aspop?c=CA for Canada.

The question I have is why does OVH come #6 with an estimated population of 
1,480,927 behind its ASN? Remember these are actual placement of ads.  Should I 
count those users as part of my stats?

RankASN AS Name CC  Users (est.)% of country% of Internet   
Samples
1   AS812   ROGERS-CABLE - Rogers Cable Communications Inc. 
CA 5,420,034   16.72   
0.16555,718
2   AS577   BACOM - Bell Canada 
CA 4,474,012   13.8
0.132   458,722
3   AS6327  SHAW - Shaw Communications Inc. 
CA 3,708,414   11.44   
0.109   380,225
4   AS852   ASN852 - TELUS Communications Inc.  
CA 2,914,405   8.99
0.086   298,815
5   AS5769  VIDEOTRON - Videotron Telecom Ltee  
CA 2,189,946   6.76
0.065   224,536
6   AS16276 OVH CA 
1,480,927   4.570.044   151,840
7   AS15290 ALLST-15290 - Allstream Corp.   
CA 1,272,374   3.93
0.038   130,457
8   AS855   CANET-ASN-4 - Bell Aliant Regional Communications, Inc. 
CA 1,211,485   3.74
0.036   124,214
9   AS7992  COGECOWAVE - Cogeco Cable   
CA 1,112,002   3.43
0.033   114,014
10  AS5645  TEKSAVVY - TekSavvy Solutions, Inc. 
CA 967,401 2.980.029   
99,188
11  AS11260 EASTLINK-HSI - EastLink 
CA 695,598 2.150.021   
71,320
12  AS47027 SEASIDE-COMM - Seaside Communications, Inc. 
CA 425,561 1.310.013   
43,633
13  AS803   SASKTEL - Saskatchewan Telecommunications   
CA 392,186 1.210.012   
40,211
14  AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD.   
CA 370,348 1.140.011   
37,972

Jack

RE: Question about Customer Population by ASN for Canada

[Jacques Latour]

Right, forgot to mention, it's population, not IP addresses, the average is 2.2 
person / household in Canada I believe.

> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Harald
> Koch
> Sent: October 2, 2017 4:34 PM
> To: NANOG list 
> Subject: Re: Question about Customer Population by ASN for Canada
> 
> On 2 October 2017 at 16:17, Eric Dugas 
> wrote:
> >
> >
> > e.g. Teksavvy at 937,855 estimated users. How can they have 937,855
> > users if they "only" have 686,848 IPv4 (https://bgp.he.net/AS5645)?
> >
> 
> I have one IPv4 and five users in my household...
> 
> --
> Harald
> (teksavvy customer)

Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover

[Jacques Latour]

Hi,

Does anyone know if there's fibre resiliency between Calgary and Toronto over 
the Great lakes, I thinking redundancy could be achieved by using two paths one 
following the railroad and the other following the Trans-Canadian highway.  
Does anyone know if there is fibre following the Trans-Canadian highway and who 
owns it?

Is this achievable?

Thanks,

Jacques
CTO, CIRA

RE: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover

[Jacques Latour]

 
> Since the Trans Canada highway in that part of Ontario is actually a 2 lane
> rural road, I am not sure people would have laid fibre along it knowing the
> progressive work to widen it might require frequent relocation of the fibre.

That's a good point,  what about along the Trans-Canadian pipeline? 
https://www.transcanada.com/en/operations/maps/  Anyone know if there's fibre 
there?

RE: Puerto Rico: Lack of electricity threatens telephone and internet services

[Jacques Latour]

Here's a fact, the next ICANN meeting in March is still a go in San Juan PR.  
Hopefully bringing 2000 people will have a positive impact on the local economy.


> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Todd
> Underwood
> Sent: October 19, 2017 7:56 PM
> To: Jean-Francois Mezei 
> Cc: NANOG list 
> Subject: Re: Puerto Rico: Lack of electricity threatens telephone and internet
> services
> 
> This thread is mostly full of idle speculation, is at the least insensitive 
> and
> verges on offensive.
> 
> If you have operational information about Puerto Rico (see Sean Donelan's
> posts rather than these responses), please go ahead. If you would like to
> allocate blame, please go somewhere else to do it. The Internet is full of
> people who are blaming Puerto Rico for getting hit by a hurricane. I don't
> need it here.
> 
> Thanks,
> 
> T
> (From Humacao)
> 
> El 19 oct. 2017 19:45, "Jean-Francois Mezei"
> 
> escribió:
> 
> On 2017-10-19 18:18, Wayne Bouchard wrote:
> > Well, the problem as I understand it is that the infrastructure was
> > not all that great to begin with. Much of it was damaged in the first
> > storm and when this second one came through, what remained basically
> > disappeared.
> 
> 
> Being hit with a Cat 5 hurricane/cyclone in a caribeean island that hasn't
> been a direct hit from severe storms in decades will cause extensive damage
> no matter what state its infrastructure was in before.
> 
> Vegetation that does not regular storms to "prune" it will grow to a point
> where it will cause major damage when a big storm hits.
> 
> And a caribbean island who has never been "rich" will not have had, as a
> priority, increasing building codes to widthstand hurricanes. Building codes
> get updated after a big devastating hurricane, whether it is for Darwin in
> 1974 (Tracy) or ones like Andrew in Florida.
> 
> It's easy for a state the size of Texas to send all of its electrical utility 
> trucks
> to the Houson area to repair damage. But they too would be stretched thin if
> all of Texas had been leveled.
> 
> If buildings were not built to widthstand a 5 or a 4, then the building itself
> becomes destructor of infrastructure as its materials become high speed
> projectiles throuwn at other buildings and especially teleohone/electrical
> lines.
> 
> I went through a category 4 (Olivia, Australia 1996). While the town and
> building I was in (Karatha) were built to new standards and had little damage,
> I witnessed the power of it, and I can totally understand Puerto Rico being
> destroyed.
> 
> I know a politician with tendancy to skew facts points to Puerto Rico having
> had terrible infrastructure. But consider that Darwin, a "rich"
> town" was wiped out in 1974 by Tracy.
> 
> https://www.youtube.com/watch?v=B89wBGydSvs
> 
> Tracy was a 4. Maria was a 5.
> (note the alert sound at start of video still sends shivers down my spine
> because it was the same as I heard before Olivia hit).
> 
> The population was evacuated by 747s because there was nothing there to
> support it. The road link to is (Stuart Highway) is so long that Darwin is
> tantamount to an island. (especially since Stuart wasn't fully paved back
> then).
> 
> 
> Also note: in Florida, the utilities positioned all their equipment in safe 
> places
> so it could survive storm and be deployed when needed. But what happens
> when there is no safe place, or the safe places become isolated because
> roads become impassable?
> 
> 
> It is one thing when a state has some areas with high level of destruction.
> But when the whole state is destroyed, it is a truly different situation 
> because
> its economy is also destroyed. Florida Power still has plenty of revenues from
> undamaged areas to pay for the repairs in damaged areas. The Utility in
> Puerto Rico doesn't. (and if it was finacially weak before, it makes things
> worse).
> 
> When you see other states' utilities coming to help in a highly damaged area,
> don't think for a minute they do this for free. The local utility stll gets a 
> bill at
> the end of the day for the work done. If the Puerto Rico company has no
> cash to pay, don't exopect other utilities to send crews.

Re: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover

[Jacques Latour]

JF, c¹est bon ça!

This is good point JF, according to
http://www.acwr.com/economic-development/rail-maps/canadian-national we
seem to have a single rail on top of Lac Superior. Other than that, it¹s
diverse. Is there diverse train routes and associated fibre routes? Which
provider follow CP and CN??

Jacques


On 2017-10-11, 3:04 PM, "NANOG on behalf of Jean-Francois Mezei"
 wrote:

>On 2017-10-11 11:40, Jacques Latour wrote:
>> Does anyone know if there's fibre resiliency between Calgary and
>>Toronto over the Great lakes, I thinking redundancy could be achieved by
>>using two paths one following the railroad and the other following the
>>Trans-Canadian highway.  Does anyone know if there is fibre following
>>the Trans-Canadian highway and who owns it?
>
>
>More than likely one around lake Superior on CP Rail tracks, and the
>other along the CN tracks further north.
>
>Zayo in Canada is formerly CNCP telecommunications, and they are likely
>first to have fibre along tracks.
>
>Since the Trans Canada highway in that part of Ontario is actually a 2
>lane rural road, I am not sure people would have laid fibre along it
>knowing the progressive work to widen it might require frequent
>relocation of the fibre.

RE: Definition of ISP vs Transit provider

[Jacques Latour]

ISP: Anybody offering services over the internet, including Transit Providers.
Transit Provider:  An internet service "transit" where the whole Internet can 
reach your advertised network addresses.

:-)

 Jack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Miles Fidelman
Sent: November 22, 2017 11:29 PM
To: Luke Guillory 
Cc: nanog@nanog.org
Subject: Re: Definition of ISP vs Transit provider

Well yes, but functionally, how is IP transport sufficiently different 
to make it an "information service" rather than a "telecommunications 
service?"  At least that's the argument I'd make against reclassifying 
access services.

Miles


On 11/22/17 9:24 PM, Luke Guillory wrote:
>
> Those normally come with ASRs and a tariff from the regulated side of 
> things. At least from my experience anyway.
>
> Sent from my iPad
>
> On Nov 22, 2017, at 10:08 PM, Miles Fidelman 
> mailto:mfidel...@meetinghouse.net>> wrote:
>
>> On 11/22/17 2:50 PM, William Herrin wrote:
>>
>>> On Wed, Nov 22, 2017 at 3:35 PM, Jean-Francois Mezei <
>>> jfmezei_na...@vaxination.ca > wrote:
 The FCC is about to reclassify "Broadband Internet Access Service" 
 as an
 information service instead of Telecommunications Service. This
 prombpted the following question which isn't about the FCC action 
 per say.

 This is about how does one define Transit provider vs ISP ?
>> For that matter, how does one distinguish between someone delivering 
>> IP packets, vs. someone offering frame relay, or ATM - which are 
>> clearly telecom services?
>>
>> Miles Fidelman
>>
>> -- 
>> In theory, there is no difference between theory and practice.
>> In practice, there is.   Yogi Berra
>>
>>
> Luke Guillory
> Vice President – Technology and Innovation
>
>   
> Tel:  985.536.1212
> Fax:  985.536.0300
> Email:lguill...@reservetele.com
> Web:  www.rtconline.com
>
>
>   Reserve Telecommunications
> 100 RTC Dr
> Reserve, LA 70084
>
>
> *Disclaimer:*
> The information transmitted, including attachments, is intended only 
> for the person(s) or entity to which it is addressed and may contain 
> confidential and/or privileged material which should not disseminate, 
> distribute or be copied. Please notify Luke Guilloryimmediately by 
> e-mail if you have received this e-mail by mistake and delete this 
> e-mail from your system. E-mail transmission cannot be guaranteed to 
> be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or contain 
> viruses. Luke Guillorytherefore does not accept liability for any 
> errors or omissions in the contents of this message, which arise as a 
> result of e-mail transmission.
>

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

RE: ccTLDs - Become a Registrar

[Jacques Latour]

That's why we're working on DNSSEC automation, to let the DNS Operator sign the 
zone and automate the provisioning of DS record into the registry without 
registrant or registrar intervention.  Multiple methods and approach being work 
on.  

API for DNS Operator: 
https://tools.ietf.org/html/draft-ietf-regext-dnsoperator-to-rrr-protocol-04
Registry full zone polling: 
https://en.blog.nic.cz/2017/06/21/lets-make-dns-great-again/

Jacques


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Rubens Kuhl
Sent: December 1, 2017 2:36 PM
To: Christopher Morrow 
Cc: nanog@nanog.org
Subject: Re: ccTLDs - Become a Registrar

http://rick.eng.br/dnssecstat/ is more on topic of we what discussing,
although the monitor is interesting too.


Rubens


On Fri, Dec 1, 2017 at 5:35 PM, Rubens Kuhl  wrote:

>
>
> On Fri, Dec 1, 2017 at 5:20 PM, Christopher Morrow <
> morrowc.li...@gmail.com> wrote:
>
>>
>>
>> On Fri, Dec 1, 2017 at 1:45 PM, Rubens Kuhl  wrote:
>>
>>>
>>> .br also has such requirements. OpenSRS reference chart has a good hint
>>> of
>>> which ccTLDs have such requirements:
>>> http://bit.ly/OpenSRS_TLD_Reference_Chart
>>
>>
>> wow, 256 of 539 report "no" for DNSSEC.
>>
>
> For DNSSEC this one is more reliable:
> http://rick.eng.br/mon/
>
>
> Rubens
>
>
>

Call for Participation -- ICANN DNSSEC Workshop at ICANN61 San Juan, Puerto Rico

[Jacques Latour]

SSEC to reach massive deployment levels it is clear that a higher level 
of automation is required than is currently available. There also is strong 
interest for DANE usage within web transactions as well as for securing email 
and Voice-over-IP (VoIP). We are seeking presentations on topics such as:
* How can the industry use DANE and other DNSSEC applications as a mechanism 
for creating a more secure Internet?
* What tools, systems and services are available to help automate DNSSEC key 
management?
* Can you provide an analysis of current tools/services and identify gaps?
* What are some of the new and innovative uses of DANE and other DNSSEC 
applications in new areas or industries?
* What tools and services are now available that can support DANE usage?

We would be particularly interested in any live demonstrations of DNSSEC / DANE 
application automation and services.  Demonstrations of new tools that make the 
setup of DNSSEC or DANE more automated would also be welcome.

6.  DNSSEC and DANE in the enterprise and in the enterprise tool set

Enterprises and enterprise software can play a critical role in both providing 
DNSSEC validation to their internal networks and also through signing of the 
domains owned by the enterprise. We are seeking presentations from enterprises 
and enterprise software providers that have implemented DNSSEC on validation 
and/or signing processes and can address questions such as:
* What enterprise software support or plan do you have to support DNSSEC?
* What are the benefits to enterprises of rolling out DNSSEC validation? And 
how do they do so?
* What are the challenges to deployment for these organizations and how could 
DANE and other DNSSEC applications address those challenges?
* How should an enterprise best prepare its IT staff and network to implement 
DNSSEC?
* What enterprise tools and systems are available to assist enterprises in the 
deployment of DNSSEC?
* How can the DANE protocol be used within an enterprise to bring a higher 
level of security to transactions using SSL/TLS certificates?

7.  Implementing DNSSEC validation at Internet Service Providers (ISPs)

Internet Service Providers (ISPs) play a critical role by enabling DNSSEC 
validation for the caching DNS resolvers used by their customers.  We have now 
seen massive rollouts of DNSSEC validation within large North American ISPs and 
at ISPs around the world.  We are interested in presentations on topics such as:
* Can you describe your experiences with negative Trust Anchors and operational 
realities?
* What does an ISP need to do to prepare its network for implementing DNSSEC 
validation?
* How does an ISP need to prepare its support staff and technical staff for the 
rollout of DNSSEC validation?
* Can you provide results and/or impacts of the impact of root key rollover?
* What rollover technique do you use, i.e., RFC 5011 or other?

In addition, we welcome suggestions for additional topics.

If you are interested in participating, please send a brief (1-2 sentence) 
description of your proposed presentation to 
dnssec-sanj...@isoc.org<mailto:dnssec-sanj...@isoc.org> by **03 January 2017**

We hope that you can join us.

Thank you,

Kathy Schnitt

On behalf of the DNSSEC Workshop Program Committee:
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Xiaodong Lee, CNNIC
Russ Mundy, Parsons
Ondřej Filip, CZ.NIC
Yoshiro Yoneya, JPRS
Dan York, Internet Society
Mark Elkins, DNS/ZACR





Jacques Latour, CTO
Canadian Internet Registration Authority (CIRA)  cira.ca<http://www.cira.ca/>
Tel.: (613) 237-5335 x294

ICANN 61 San Juan - TechDay Call for Presentations

[Jacques Latour]

   Call for Presentations
  TechDay
at ICANN 61
  in San Juan, PR

The ICANN Tech Working Group is again planning a technical workshop at
the ICANN 61 meeting on Monday 2018-03-12 in San Juan, Puerto Rico.

The TechDay workshop has been a part of ICANN meetings for several
years and has provided a forum for both experienced and new people to
meet, present and discuss technical topics related to registry and DNS
work and security.

We are specially interested in:

1. Continuity of Operations

   Preparedness and Mitigation

2. In addition, we welcome suggestions for additional topics, such as;

* Registry security, services and systems
* DNS & anycast security, services and systems
* Big Data & associated data analysis
* IETF DNS protocol updates (Privacy, Encryption)
* (Recent) DDOS Attacks and Mitigation

If you are interested in presenting, please email ccnso-tech...@icann.org

We hope that you can join us and request that you disseminate this
Request to other lists where it might of interest.

Jacques

Regards,

On behalf of the TechDay Planning Committee

Call for presentations TechDay at ICANN 62

[Jacques Latour]

Call for Presentations

   35th TechDay

   at ICANN 62

 in Panama City



The ICANN Tech Working Group is again planning a technical workshop at

the ICANN 62 meeting in Panama City on Monday 2018-06-25 after the

DNSSEC Lunch.



The TechDay workshop has been a part of ICANN meetings since 2006 and

has provided a forum for both experienced and new people to meet,

present and discuss technical topics related to registry and DNS work

and security.



We are specially interested in:



1. Emerging Threats



2. In addition, we welcome suggestions for additional topics, such as;



* Registry security, services and systems

* DNS & anycast security, services and systems

* Big Data & associated data analysis

* IETF DNS protocol updates (Privacy, Encryption)

* (Recent) DDOS Attacks and Mitigation



If you are interested in presenting, please email 
ccnso-tech...@icann.org



Regards,



Jacques



On behalf of the TechDay Planning Committee

Announcement - Joint CENTR-Tech / DNS-OARC Workshop, Amsterdam, NL, 13th/14th October 2018

[Jacques Latour]

Hi all!

The 29th DNS-OARC Workshop will be a joint workshop combined with
CENTR-Tech and will take place at the Hotel Okura, Amsterdam,
Netherlands, on October 13th and 14th 2018.

Workshop Milestones:

- 01 May 2018 - Workshop Announcement
- 01 Jun 2018 - Submissions and Registrations open via Indico
- 13 Jul 2018 - Deadline for submission
- 17 Aug 2018 - Contribution list published
- 14 Sep 2018 - Full agenda published
- 06 Oct 2018 - Deadline for slideset submission
- 13 Oct 2018 - Workshop

Jacques , on behalf of the joint Programme Committee

OARC depends on sponsorship to fund its workshops and associated social
events.  Please contact  if your organization is
interested in becoming a sponsor.

REMINDER: Call for Participation -- ICANN DNSSEC Workshop at ICANN62 Panama City, Panama - June 25, 2018

[Jacques Latour]

resentations related to any aspect of DNSSEC such as zone 
signing, DNS response validation, applications use of DNSSEC, 
registry/registrar DNSSEC activities, etc.  In addition, we welcome suggestions 
for additional topics.

If you are interested in participating, please send a brief (1-2 sentence) 
description of your proposed presentation to  
dnssec-panamac...@isoc.org<mailto:dnssec-panamac...@isoc.org> by **Friday, 18 
May 2018**

Thank you,
Kathy and Julie
On behalf of the DNSSEC Workshop Program Committee:
Mark Elkins, DNS/ZACR
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Xiaodong Lee, Chinese Academy of Sciences (CAS)
Russ Mundy, Parsons
Ondrej Filip, CZ.NIC
Yoshiro Yoneya, JPRS
Dan York, Internet Society





___
dns-operations mailing list
dns-operati...@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-operations mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Call For Presentations - Joint CENTR-Tech / DNS-OARC Workshop, Amsterdam, NL, 13th/14th October 2018

[Jacques Latour]

Hi All!

The 29th DNS-OARC Workshop will be a joint workshop combined with
CENTR-Tech and will take place at the Hotel Okura, Amsterdam,
Netherlands, on October 13th and 14th 2018.

The Workshop's Program Committee is now requesting proposals for
presentations.  All DNS-related subjects are welcome.

A timeslot will also be available for lightning talks (5-10 minutes)
on day two of the workshop for which submissions will be accepted
on the first day of the workshop, until 4pm.

The second afternoon of the workshop will start with a Members-only
session which will include reports on DNS-OARC's activities.  If you
are an OARC member and have a sensitive topic that you wish to present
during that session those can be accommodated.  The Members-only session
will be followed by the AGM.

Workshop Milestones:


*15 Jun 2018 - Submissions and Registrations open via Indico

*13 Jul 2018 - Deadline for submission

*17 Aug 2018 - Contribution list published

*14 Sep 2018 - Full agenda published

*06 Oct 2018 - Deadline for slideset submission

*13 Oct 2018 - Workshop

Details for presentation submission are published here:

https://indico.dns-oarc.net/event/29/call-for-abstracts/

The workshop presentations will be organized by common themes, depending
on the topics and the timing of each presentation. There are 30-minute
and 15-minute slots, let us know your preference in your submission.

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides.  Draft slides are acceptable on submission.

OARC depends on sponsorship to fund its workshops and associated social
events.  Please contact  if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)

If you have questions or concerns you can contact the Programme Committee:

https://www.dns-oarc.net/oarc/programme

via submissi...@dns-oarc.net

Jacques, for the joint Programme Committee

Finally some common sense - No to blocking DNS

[Jacques Latour]

This is good news for the internet up here! It's unconstitutional to block DNS 
access!!! JF must be happy :)
https://www.theglobeandmail.com/canada/article-court-rejects-quebecs-bid-to-ban-citizens-access-to-private-online-2/

Court rejects Quebec's bid to ban citizens' access to private online gaming 
sites
THE CANADIAN PRESS
PUBLISHED JULY 24, 2018UPDATED 18 HOURS AGO
Quebec's attempt to ban its citizens' access to online gaming websites 
unauthorized by the state-run gambling corporation is unconstitutional because 
it infringes upon federal jurisdiction, indicated a recent Superior Court 
ruling...

Call for Participation -- ICANN DNSSEC Workshop at ICANN63 Barcelona, Spain

[Jacques Latour]

 please send a brief (1-2 sentence) 
description of your proposed presentation to 
dnssec-barcel...@isoc.org<mailto:dnssec-barcel...@isoc.org>**07 September 2018 
**

We hope that you can join us.
Thank you,
Jacques Latour

On behalf of the DNSSEC Workshop Program Committee:
Jean Robert Hountomey, AfricaCERT
Jacques Latour, .CA
Russ Mundy, Parsons
Ondřej Filip, CZ.NIC
Yoshiro Yoneya, JPRS
Dan York, Internet Society
Mark Elkins, DNS/ZACR
dnssec-barcel...@isoc.org<mailto:dnssec-barcel...@isoc.org> 
mailto:dnssec-barcel...@isoc.org>>

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN78

[Jacques Latour via NANOG]

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN7 Annual 
General Meeting



In cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
we are planning a DNSSEC and Security Workshop for the ICANN78 Annual General 
Meeting being held as a hybrid meeting from 21-26 October 2023 Hamburg, Germany 
in the Central European Summer Time Zone (UTC +2). This workshop date will be 
determined once ICANN creates a block schedule for us to follow; then we will 
be able to request a day and time. The DNSSEC and Security Workshop has been a 
part of ICANN meetings for several years and has provided a forum for both 
experienced and new people to meet, present and discuss current and future 
DNSSEC deployments.  For reference, the most recent session was held at the 
ICANN77 Policy Forum on Monday, 12 June 2023. The presentations and transcripts 
are available at: https://meetings.icann.org/en/icann77.


The DNSSEC Workshop Program Committee is developing a program for the

upcoming meeting.  Proposals will be considered for the following topic areas 
and included if space permits.  In addition, we welcome suggestions for 
additional topics either for inclusion in the ICANN78 workshop, or for 
consideration for future workshops.



1.  Global DNSSEC Activities Panel

For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment as well as from those who have not deployed DNSSEC but who 
have a keen interest in the challenges and benefits of deployment, including 
Root Key Signing Key (KSK) Rollover activities and plans.



2.  DNSSEC Best Practice

Now that DNSSEC has become an operational norm for many registries, registrars, 
and ISPs, what have we learned about how we manage DNSSEC?

  *   Do you still submit/accept DS records with Digest Type 1?
  *   What is the best practice around key roll-overs?
  *   What about Algorithm roll-overs?
  *   Do you use and support DNSKEY Algorithms 13-16?
  *   How often do you review your disaster recovery procedures?
  *   Is there operational familiarity within your customer support teams?
  *   What operational statistics have been gathered about DNSSEC?
  *   Are there experiences being documented in the form of best practices, or 
something similar, for transfer of signed zones?



Activities and issues related to DNSSEC in the DNS Root Zone are also desired.



3. DNSSEC Deployment Challenges

The program committee is seeking input from those that are interested in 
implementation of DNSSEC but have general or particular concerns with DNSSEC.  
In particular, we are seeking input from individuals that would be willing to 
participate in a panel that would discuss questions of the following nature:

  *   Are there any policies directly or indirectly impeding your DNSSEC 
deployment? (RRR model, CDS/CDNSKEY automation)
  *   What are your most significant concerns with DNSSEC, e.g., complexity, 
training, implementation, operation or something else?
  *   What do you expect DNSSEC to do for you and what doesn't it do?
  *   What do you see as the most important trade-offs with respect to doing or 
not doing DNSSEC?



4. Security Panel

The program committee is looking for presentations on DNS, DNSSEC, routing and 
other topics that could impact the security and/or stability of the Internet.



We are looking for presentations that cover implementation issues, challenges, 
opportunities, and best practices for:

  *   Emerging threats that could impact the security and/or stability of the 
Internet
  *   DoH and DoT
  *   RPKI (Resource Public Key Infrastructure)
  *   BGP routing & secure implementations
  *   MANRS ( Mutually Agreed Norms for Routing Security)
  *   Browser security - DNS, DNSSEC, DoH
  *   EMAIL & DNS related security - DMARC, DKIM, TLSA, etc...



If you are interested in participating, please send a brief (1-3 sentence) 
description of your proposed presentation to 
dnssec-security-works...@icann.org<mailto:dnssec-security-works...@icann.org> 
by COB Friday, 15 September 2023.



Thank you,

Kathy and Andrew

On behalf of the DNSSEC Workshop Program Committee:

Fred Baker, ISC

Steve Crocker, Edgemoor Research Institute

Mark Elkins, DNS/ZARC

Jacques Latour, .CA

Russ Mundy, Tislabs

Yoshiro Yoneya, JPRS

Dan York, Internet Society






CLASSIFICATION:CONFIDENTIAL

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN79 Community Forum

[Jacques Latour via NANOG]

Call for Participation – ICANN DNSSEC and Security Workshop for ICANN79 
Community Forum



In cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
we are planning a DNSSEC and Security Workshop for the ICANN79 Community Forum 
being held as a hybrid meeting from 02-07 March 2024 San Juan, Puerto Rico in 
the Atlantic Standard Time - AST (UTC-4). This workshop date will be determined 
once ICANN creates a block schedule for us to follow; then we will be able to 
request a day and time. The DNSSEC and Security Workshop has been a part of 
ICANN meetings for several years and has provided a forum for both experienced 
and new people to meet, present and discuss current and future DNSSEC 
deployments.  For reference, the most recent session was held at the ICANN78 
The Annual General Meeting on Wednesday, 25 October 2023. The presentations and 
transcripts are available at: https://icann78.sched.com/.


The DNSSEC Workshop Program Committee is developing a program for the

upcoming meeting.  Proposals will be considered for the following topic areas 
and included if space permits.  In addition, we welcome suggestions for 
additional topics either for inclusion in the ICANN78 workshop, or for 
consideration for future workshops.



1.  Global DNSSEC Activities Panel

For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment as well as from those who have not deployed DNSSEC but who 
have a keen interest in the challenges and benefits of deployment, including 
Root Key Signing Key (KSK) Rollover activities and plans.



2.  DNSSEC Best Practice

Now that DNSSEC has become an operational norm for many registries, registrars, 
and ISPs, what have we learned about how we manage DNSSEC?

  *   Do you still submit/accept DS records with Digest Type 1?
  *   What is the best practice around key roll-overs?
  *   What about Algorithm roll-overs?
  *   Do you use and support DNSKEY Algorithms 13-16?
  *   How often do you review your disaster recovery procedures?
  *   Is there operational familiarity within your customer support teams?
  *   What operational statistics have been gathered about DNSSEC?
  *   Are there experiences being documented in the form of best practices, or 
something similar, for transfer of signed zones?



Activities and issues related to DNSSEC in the DNS Root Zone are also desired.



3. DNSSEC Deployment Challenges

The program committee is seeking input from those that are interested in 
implementation of DNSSEC but have general or particular concerns with DNSSEC.  
In particular, we are seeking input from individuals that would be willing to 
participate in a panel that would discuss questions of the following nature:


  *   Are there any policies directly or indirectly impeding your DNSSEC 
deployment? (RRR model, CDS/CDNSKEY automation)
  *   What are your most significant concerns with DNSSEC, e.g., complexity, 
training, implementation, operation or something else?
  *   What do you expect DNSSEC to do for you and what doesn't it do?
  *   What do you see as the most important trade-offs with respect to doing or 
not doing DNSSEC?



4. Security Panel

The program committee is looking for presentations on DNS, DNSSEC, routing and 
other topics that could impact the security and/or stability of the Internet.



We are looking for presentations that cover implementation issues, challenges, 
opportunities and best practices for:


  *   Emerging threats that could impact the security and/or stability of the 
Internet
  *   DoH and DoT
  *   RPKI (Resource Public Key Infrastructure)
  *   BGP routing & secure implementations
  *   MANRS ( Mutually Agreed Norms for Routing Security)
  *   Browser security – DNS, DNSSEC, DoH
  *   EMAIL & DNS related security – DMARC, DKIM, TLSA, etc…



If you are interested in participating, please send a brief (1-3 sentence) 
description of your proposed presentation to 
dnssec-security-works...@icann.org<mailto:dnssec-security-works...@icann.org> 
by COB Friday, 19 January 2024.



Thank you,

Kim and Kathy

On behalf of the DNSSEC Workshop Program Committee:

Steve Crocker, Edgemoor Research Institute

Mark Elkins, DNS/ZARC

Jacques Latour, .CA

Russ Mundy, Tislabs

Yoshiro Yoneya

Dan York, Internet Society







CLASSIFICATION:PUBLIC

Call for Participation -- ICANN81 DNSSEC and Security Workshop for ICANN Policy Forum

[Jacques Latour via NANOG]

Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN Policy 
Forum



In cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
we are planning a DNSSEC and Security Workshop for the ICANN80 Policy Forum 
being held as a hybrid meeting from 10-13 June 2024 Kigali, Rwanda in the 
Central Africa Time - CAT (UTC +2). This workshop date will be determined once 
ICANN creates a block schedule for us to follow; then we will be able to 
request a day and time. The DNSSEC and Security Workshop has been a part of 
ICANN meetings for several years and has provided a forum for both experienced 
and new people to meet, present and discuss current and future DNSSEC 
deployments.  For reference, the most recent session was held at the ICANN79 
The Community Forum on Wednesday, 06 March 2024. The presentations and 
transcripts are available at: https://icann79.sched.com/.


The DNSSEC Workshop Program Committee is developing a program for the

upcoming meeting.  Proposals will be considered for the following topic areas 
and included if space permits.  In addition, we welcome suggestions for 
additional topics either for inclusion in the ICANN78 workshop, or for 
consideration for future workshops.



1.  Global DNSSEC Activities Panel

For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment as well as from those who have not deployed DNSSEC but who 
have a keen interest in the challenges and benefits of deployment, including 
Root Key Signing Key (KSK) Rollover activities and plans.



2.  DNSSEC Best Practice

Now that DNSSEC has become an operational norm for many registries, registrars, 
and ISPs, what have we learned about how we manage DNSSEC?



  *   Do you still submit/accept DS records with Digest Type 1?
  *   What is the best practice around key roll-overs?
  *   What about Algorithm roll-overs?
  *   Do you use and support DNSKEY Algorithms 13-16?
  *   How often do you review your disaster recovery procedures?
  *   Is there operational familiarity within your customer support teams?
  *   What operational statistics have been gathered about DNSSEC?
  *   Are there experiences being documented in the form of best practices, or 
something similar, for transfer of signed zones?



Activities and issues related to DNSSEC in the DNS Root Zone are also desired.



3. DNSSEC Deployment Challenges

The program committee is seeking input from those that are interested in 
implementation of DNSSEC but have general or concerns with DNSSEC.  We are 
seeking input from individuals that would be willing to participate in a panel 
that would discuss questions of the following nature:


  *   Are there any policies directly or indirectly impeding your DNSSEC 
deployment? (RRR model, CDS/CDNSKEY automation)
  *   What are your most significant concerns with DNSSEC, e.g., complexity, 
training, implementation, operation, or something else?
  *   What do you expect DNSSEC to do for you and what doesn't it do?
  *   What do you see as the most important trade-offs with respect to doing or 
not doing DNSSEC?



4. Security Panel

The program committee is looking for presentations on DNS, DNSSEC, routing and 
other topics that could impact the security and/or stability of the Internet.



We are looking for presentations that cover implementation issues, challenges, 
opportunities, and best practices for:


  *   Emerging threats that could impact the security and/or stability of the 
Internet
  *   DoH and DoT
  *   RPKI (Resource Public Key Infrastructure)
  *   BGP routing & secure implementations
  *   MANRS ( Mutually Agreed Norms for Routing Security)
  *   Browser security – DNS, DNSSEC, DoH
  *   EMAIL & DNS related security – DMARC, DKIM, TLSA, etc…



If you are interested in participating, please send a brief (1-3 sentence) 
description of your proposed presentation to 
dnssec-security-works...@icann.org<mailto:dnssec-security-works...@icann.org> 
by COB Friday, 10 May 2024.



Thank you,

Jacques

On behalf of the DNSSEC Workshop Program Committee:

Steve Crocker, Edgemoor Research Institute

Mark Elkins, DNS/ZARC

Jacques Latour, .CA

Russ Mundy, Tislabs

Yoshiro Yoneya

Dan York, Internet Society

REMINDER: Call for Participation -- ICANN81 DNSSEC and Security Workshop

[Jacques Latour via NANOG]

Hi all!

We still have a few openings in our schedule.

Thanks,

Jacques





Call for Participation -- ICANN DNSSEC and Security Workshop for ICANN Annual 
General Meeting



In cooperation with the ICANN Security and Stability Advisory Committee (SSAC), 
we are planning a DNSSEC and Security Workshop for the ICANN81 Annual General 
Meeting being held as a hybrid meeting from 09-14 November 2024 in Istanbul, 
Türkiyea in the Turkey Time TRT- (UTC +3). This workshop date will be 
determined once ICANN creates a block schedule for us to follow; then we will 
be able to request a day and time. The DNSSEC and Security Workshop has been a 
part of ICANN meetings for several years and has provided a forum for both 
experienced and new people to meet, present and discuss current and future 
DNSSEC deployments.  For reference, the most recent session was held at the 
ICANN80 The Policy Forum on Monday, 10 June 2024. The presentations and 
transcripts are available at: 
https://icann80.sched.com/<https://urldefense.com/v3/__https:/icann80.sched.com/__;!!PtGJab4!7Vwf_nce_rPxRjD_jP1wRhuny_oTUzM3I0Qc9MRXSeo2_SUo-grj_9Sd6k3mOAc3XIhjKx9KJTIzPA7TckRlZNz7gW214I3n3w$>.


The DNSSEC Workshop Program Committee is developing a program for the

upcoming meeting.  Proposals will be considered for the following topic areas 
and included if space permits.  In addition, we welcome suggestions for 
additional topics either for inclusion in the ICANN78 workshop, or for 
consideration for future workshops.



1.  Global DNSSEC Activities Panel

For this panel, we are seeking participation from those who have been involved 
in DNSSEC deployment as well as from those who have not deployed DNSSEC but who 
have a keen interest in the challenges and benefits of deployment, including 
Root Key Signing Key (KSK) Rollover activities and plans.



2.  DNSSEC Best Practice

Now that DNSSEC has become an operational norm for many registries, registrars, 
and ISPs, what have we learned about how we manage DNSSEC?



  *   Do you still submit/accept DS records with Digest Type 1?
  *   What is the best practice around key roll-overs?
  *   What about Algorithm roll-overs?
  *   Do you use and support DNSKEY Algorithms 13-16?
  *   How often do you review your disaster recovery procedures?
  *   Is there operational familiarity within your customer support teams?
  *   What operational statistics have been gathered about DNSSEC?
  *   Are there experiences being documented in the form of best practices, or 
something similar, for transfer of signed zones?



Activities and issues related to DNSSEC in the DNS Root Zone are also desired.



3. DNSSEC Deployment Challenges

The program committee is seeking input from those that are interested in 
implementation of DNSSEC but have general or particular concerns with DNSSEC.  
In particular, we are seeking input from individuals that would be willing to 
participate in a panel that would discuss questions of the following nature:


  *   Are there any policies directly or indirectly impeding your DNSSEC 
deployment? (RRR model, CDS/CDNSKEY automation)
  *   What are your most significant concerns with DNSSEC, e.g., complexity, 
training, implementation, operation or something else?
  *   What do you expect DNSSEC to do for you and what doesn't it do?
  *   What do you see as the most important trade-offs with respect to doing or 
not doing DNSSEC?



4. Security Panel

The program committee is looking for presentations on DNS, DNSSEC, routing and 
other topics that could impact the security and/or stability of the Internet.



We are looking for presentations that cover implementation issues, challenges, 
opportunities and best practices for:

  *   Emerging threats that could impact the security and/or stability of the 
Internet
  *   DoH and DoT
  *   RPKI (Resource Public Key Infrastructure)
  *   BGP routing & secure implementations
  *   MANRS ( Mutually Agreed Norms for Routing Security)
  *   Browser security - DNS, DNSSEC, DoH
  *   EMAIL & DNS related security - DMARC, DKIM, TLSA, etc...



If you are interested in participating, please send a brief (1-3 sentence) 
description of your proposed presentation to 
dnssec-security-works...@icann.org<mailto:dnssec-security-works...@icann.org> 
by Friday, 13 September 2024.



Thank you,

Kim and Kathy

On behalf of the DNSSEC Workshop Program Committee:

Gautam Akiwate, Stanford University

Steve Crocker, Edgemoor Research Institute

Mark Elkins, DNS/ZARC

Jacques Latour, .CA

Ram Mohan, Identity Digital

Russ Mundy, Tislabs

Yoshiro Yoneya

Dan York, Internet Society