18 September 2017 - At ION Malta, Adam Peake discusses the IANA transition: The IANA transition was successfully completed in October 2016 creating strengthened relationships between the IETF (Internet protocols and standards), Regional Internet Registries RIRs (IP addresses), and ccTLD and gTLD operators and TLD community and ICANN. A new organisation, Public Technical Identifiers (PTI), an affiliate of ICANN, is now responsible for performing the IANA functions and delivering the IANA Services on behalf of ICANN. The session will discuss these new arrangements and how they have enhanced ICANN’s accountability and transparency to the global Internet community. The session will also describe how ICANN is preparing for the Root KSK Rollover.

1. | 1
IANA Transition – Enhanced
Roles and Accountability (+
KSK)
ION Malta
18 September 2017
Adam Peake, Civil Society / Academic Engagement ICANN

2. | 2| 2
ICANN mission,
partnerships and
multistakeholder community

3. | 3| 3
IANA Stewardship Transition
Focused on delivering a proposal to transition the stewardship of the
IANA functions to the multistakeholder community
Enhancing ICANN Accountability
Focused on ensuring that ICANN remains accountable in the
absence of its historical contractual relationship with the U.S.
Government
ICANN's Mission
Coordinates the allocation and assignment of
names in the root zone of the Domain Name
System
Facilitates the coordination of the operation and
evolution of the DNS root name server system
Coordinates the allocation and assignment at the
top-most level of Internet Protocol numbers and
Autonomous System numbers
1
4
Ensuring the stable and secure operation of the Internet's
unique identifier systems
Coordinates the development and implementation of
policies concerning the registration of second-level
domain names in generic top-level domains (gTLDs)
2
3

4. | 4| 4
Technical Partners
Coordinating with our technical partners,
we help make the Internet work
The Internet
Corporation
for Assigned
Names and
Numbers
Internet
Engineering
TaskForce
Domain
Name
System
Operators
Root
Server
Operators
African
Network
Information
Center
Asia Pacific
Network
Information
Centre
Latin America
and Caribbean
Network
Information
Center
International
Organization for
Standardization
World
Wide Web
Consortium
Institute of
Electrical and
Electronics
Engineers
American
Registry for
Internet
Numbers
Réseaux IP
Européens
Network
Coordination
Centre
Intern
Servi
Provi
net
ation
Reg

5. | 5| 5
Other Partners
We all work together in different ways
to help make the Internet work
The Anti-
Phishing
Working
Group
Organization
for Economic
Co-operation and
Development
United Nations
Educational,
Scientific and
Cultural
Organization
The Internet
Society
Internet
Governance
Forum
Messaging,
Malware
and Mobile
Anti-Abuse
Working
Group
The Internet
Corporation
for Assigned
Names and
Numbers
Diplo
Foundation
World
Intellectual
Property
Organization
International
Organisation of
La Francophone
Regional
Internet
Governance
Forums
Afri
Tel
Uni
United
Nations
Economic
and Social
Commission
of Western
Asia
rican
icatio
ssion
pean
ence
ostal
ions
ions

6. | 6| 6
What is the Multistakeholder Community?
A volunteer-based, open collection
of global stakeholders working
together through bottom-up
processes to give advice, develop
and make policy recommendations,
conduct reviews, and propose
implementation solutions for
common problems within ICANN’s
mission and scope.

7. | 7| 7
How Does the Multistakeholder Model Work?
Policy recommendations are
developed and refined by the
ICANN community through its
Supporting Organizations (SOs)
and influenced by Advisory
Committees (ACs).

8. | 8| 8
Address Supporting
Organization (ASO)
Country Code Names Supporting
Organization (ccNSO)
Generic Names Supporting
Organization (GNSO)
Supporting
Organizations (SOs)
ccNSO
The ccNSO (Council and members) works
on global policies relating to country code
top-level domain name (ccTLD) policies
(e.g., .mt, .uk).
ASO
The ASO Address Council is composed of 15
volunteers — 3 from each of the Regional
Internet Registries (RIRs) — who work on
global Internet Protocol (IP) Address Policy.
GNSO
The GNSO Council is composed of 21
members — divided into 2 houses (contracted
and non-contracted parties) — who work on
generic top-level domain name (gTLD) policies
(e.g., .com, new gTLDs).
Three SOs in the ICANN
community are responsible
for developing policy
recommendations in the
areas they represent.
Supporting Organizations (SOs)

9. | 9| 9
Advisory Committees (ACs)
ALAC
The ALAC voices the interests of the individual Internet user
and is composed of 15 members - 2 from each of the five
Regional At-Large Organizations (RALOs) and 5 appointed
by the ICANN Nominating Committee. It is supported by
over 200 At-Large Structures (ALSes) and volunteers.
GAC
The GAC provides advice on public policy issues,
particularly on interactions with policies and national laws
or international agreements.
RSSAC
The RSSAC advises the ICANN community and
Board on the operation, administration, security, and
integrity of the Internet's Root Server System.
SSAC
The SSAC advises on matters related to the security
and integrity of the Internet's naming and address
allocation systems.
At-Large Advisory
Committee (ALAC)
Governmental Advisory
Committee (GAC)
Root Server System Advisory
Committee (RSSAC)
Security and Stability
Advisory Committee
(SSAC)
Advisory
Committees (ACs)
Four ACs give advice and
make recommendations on
ICANN topics.

10. | 10| 10
IANA Stewardship Transition

11. | 11
Transition of the IANA functions
The IANA functions evolved in support of the Internet Engineering Task Force, and initially funded via
research projects supported by the U. S. Department of Defense, Advance Research Projects Agency
ICANN was created to perform the IANA functions and has did so pursuant to a no-cost contract with the
Department of Commerce for over 15 years
14 March 2014: U.S. Government announces intent to transition its
stewardship of the IANA functions to the global multistakeholder community
– Completed
30 September 2016
These functions include:
 The coordination of the
assignment of technical
Internet protocol parameters
 The administration of certain
responsibilities associated
with Internet DNS Root zone
management
 The allocation of Internet IP
addresses
Names Numbers Protocol Parameters
Internet Users
IANA
IANA CUSTOMERS SUBMIT REQUESTS

12. | 12| 12
Transition requirements
The community developed two parallel processes:
IANA Stewardship Transition
Focused on delivering a proposal to transition the stewardship
of the IANA functions to the multistakeholder community
Enhancing ICANN Accountability
Focus on ensuring ICANN remains accountable in the absence of its
historical contractual relationship with the U.S.Government
To drive the processes, the community created two open, transparent
and diverse working groups to foster discussion and develop proposals:
ICG Stewardship Transition Coordination Group, CCWG-Accountability

13. | 13
An Unprecedented Multistakeholder Effort

14. | 14
Post-transition accountability mechanisms
1 Enhanced Bylaws
3 Complaints Officer
5 Documented Relationships
2 Bylaws-Mandated
Redress Mechanism
4 Documentation for Board
of Directors
6
Empowered Community
Powers
7 External Laws 8 General ICANN
Operational Information
9 ICANN Board Selection
Process
Organizational Reviews
Ombudsman
10
11

15. | 15| 15
PTI Overview

16. | 16
What is PTI?
Created from the transition, Public Technical Identifiers (PTI) is an
affiliate of ICANN that is responsible for performing the IANA
functions and delivering the IANA Services, on behalf of ICANN
PTI implements agreed policies
and principles developed by the ICANN multistakeholder community
ICANN
IANA
functions
IANA
Department
Contract
PTI
IANA
functions
PTI
Staff

17. | 17
PTI Overview
Officers Staff
Legal Organization Operations
Board
 Nonprofit public benefit
corporation
 ICANN is sole member
 Domiciled in California
 501(c)(3) tax status
 5 directors appointed by
ICANN
 3 from ICANN/PTI staff
 Elected by ICANN
NomCom process
 President – Elise Gerich
 Treasurer – Becky Nash
 Secretary – Samantha
Eisner
 No change in personnel
performing the IANA
functions
 Existing IANA
department staff
seconded from ICANN
to PTI
 Annual budget developed
in consultation with the
community
 4-year strategic plan
updated annually
 Annual independent
financial audit of PTI
financials
 Perform name, protocol
parameters, and number
services via contract and
subcontract with ICANN
 All resources required to
perform services will be
provided by ICANN

18. | 18
What Stayed the Same?
IANA Department staff are
seconded to PTI
Individuals performing the work
Domain Names, Numbering
Resources, and Protocol Parameters
The registries related to names,
numbers and protocol parameters
The definition of the IANA functions
Methods for submitting changes or
updates to the registries
Location of the operational information The Operational reports of the IANA
services will remain on iana.org

19. | 19
ICANN Ecosystem with PTI
CSC
ICANN
PTI
Review
Committee
ASO
ICANN
(subcontracted to PTI) IAB and IETF
leadership
IETF
ICANN
(subcontracted to PTI)
Oversight Policy Operations

20. | 20
Relationship between IETF and PTI
ICANN
Board
PTI
Board
NomCo
m
SOs
ACs
CSC
RZERC
Verisign
RiRs
IETF
EC
IETF
Trust
Ombudsman
The 2000 Memorandum of
Understanding between
ICANN and IETF remains in
place for the performance of
the protocol parameters
services. Every year, ICANN
and IETF negotiate a
Supplemental Agreement. The
2016 version was signed at
ICANN56.
PTI
(Affiliate of ICANN)
ICANN
IANA Department
All Other Departments
As required by the
ICG proposal, ICANN
will subcontract the
performance of the
protocol parameters
services to PTI.
Oversight
Contract
Bylaws
Existing structure
New structure
ICANN will continue
to be accountable for
the performance of
the protocol
parameters services
to the IETF.

21. | 21
Relationship between RIRs and PTI
Oversight
Contract
Bylaws
ICANN
Board
PTI
Board
NomCo
m
SOs
ACs
CSC
RZERC
Verisig
n
RiRs
IETF
EC
IETF
Trust
Ombudsman
Existing structure
New structure
ICANN will be
accountable for the
performance of the
IANA number
services to the RIRs.
ICANN
IANA Department
All Other Departments
PTI
(Affiliate of ICANN)
As required by the
ICG proposal, ICANN
will subcontract the
performance of the
IANA number
services to PTI.
ICANN entered into a
Service Level
Agreement with the
RIRs for the
performance of the
IANA number
services.

22. | 22
Relationship between TLD community and PTI
ICANN
Board
PTI
Board
NomCo
m
SOs
ACs
CSC
RZERC
Verisign
RiRs
IETF
EC
IETF
Trust
Ombudsman
ICANN will
contract with PTI
for the
performance of
the IANA naming
services.
ICANN
IANA Department
All Other Departments
PTI
(Affiliate of ICANN)
The Customer
Standing Committee
(CSC) will provide
oversight of the
performance of the
IANA naming
services.
Oversight
Contract
Bylaws
Existing structure
New structure

23. | 23
Relationship between Verisign and PTI
ICANN
Board
PTI
Board
NomCo
m
SOs
ACs
CSC
RZERC
Verisign
RiRs
IETF
EC
IETF
Trust
Ombudsman
ICANN
IANA Department
All Other Departments
PTI
(Affiliate of ICANN)
The Root Zone
Maintainer
Agreement (RZMA)
will be
subcontracted to
PTI.
Oversight
Contract
Bylaws
Existing structure
New structure
ICANN will contract
with Verisign to
perform the root
zone maintainer
function (RZMA).

24. | 24
Relationship between ICANN and PTI
ICANN
Board
PTI
Board
NomCo
m
SOs
ACs
CSC
RZERC
Verisign
RiRs
IETF
EC
IETF
Trust
Ombudsman
PTI
(Affiliate of ICANN)
ICANN
IANA Department
All Other Departments
Oversight
Contract
Bylaws
Existing structure
New structure
There will be a Services
subcontracting agreement
between ICANN and PTI
that will specify the
services (HR, IT, etc.)
ICANN will provide to PTI
in order for it to perform
the IANA functions.

25. | 25
Lise Fuhr
Jonathan Robinson
Elise Gerich
Akram Atallah
David Conrad
Who is on the PTI Board?
ICANN Board appoints 5 Directors, 3 from ICANN/PTI staff and
2 selected by ICANN NomCom*
*Lise and Jonathan were selected by an interim selection process, not by the
NomCom, due to transition implementation planning/timing

26. | 26| 26
KSK Rollover

27. | 27
KSK Rollover: 11 October 2017
What we don't want 12 October?

28. | 28

29. | 29
What you need to know: changing the root key signing key
• ICANN is changing (rolling) the top cryptographic key used in
the DNS protocol
• a new cryptographic key pair will be generated, the new public
component distributed to DNSSEC validating resolvers
• if you don't use DNSSEC your system will not be affected by
the rollover
• if your software supports automated updates of DNSSEC trust
anchors, the root zone KSK will be updated automatically
• If you software does not support automated updates or not
configured to use it, manually update the software's trust
anchor – available here http://data.iana.org/root-anchors
• KSK rollover will occur 11 October 2017 – update anytime
before the rollover

30. | 30
Thank you and questions
• KSK more information: http://www.icann.org/kskroll
• Contact: globalsupport@icann.org (subject KSKrollover)
• Join & participate: https://www.icann.org/get-started
• ICANN and civil society:
https://www.icann.org/resources/pages/civil-society
• ICANN for business:
https://www.icann.org/resources/pages/business
• ICANN for tech:
https://www.icann.org/community#techsec
• Questions: adam.peake@icann.org

31. | 31

32. | 32| 32
KSK Rollover (additional
slides)

33. | 33
KSK Rollover: An Overview
 The Root Zone DNSSEC Key Signing
Key “KSK” is the top most cryptographic
key in the DNSSEC hierarchy
 The KSK is a cryptographic public-private
key pair:
o Public part: trusted starting point
for DNSSEC validation
o Private part: signs the Zone
Signing Key (ZSK)
 Builds a “chain of trust” of successive
keys and signatures to validate the
authenticity of any DNSSEC signed data
ICANN is in the process of performing a Root Zone DNS
Security Extensions (DNSSEC) Key Signing Key (KSK) rollover
DATA
Watch video:
https://www.youtube.com/wat
ch?v=d7H1AkC9PIw

34. | 34
Why is ICANN Rolling the KSK?
 As with passwords, the cryptographic keys used
in DNSSEC-signing DNS data should be changed
periodically
o Ensures infrastructure can support key
change in case of emergency
 This type of change has never before occurred at
the root level
o There has been one functional, operational
Root Zone DNSSEC KSK since 2010
 The KSK rollover must be widely and carefully
coordinated to ensure that it does not interfere
with normal operations

35. | 35
When Does the Rollover Take Place?
The KSK rollover is a process, not a single event
The following dates are key milestones in the process when end users may
experience interruption in Internet services:

36. | 36
DNS Software
Developers &
Distributors
Network
Operators
Root Server
Operators
Internet
Service
Providers
Who Will Be Impacted?
System
Integrators
End
Users
(if no action taken by
resolver operators)

37. | 37
Why You Need to Prepare
If you have enabled DNSSEC validation, you must update
your systems with the new KSK to help ensure trouble-free
Internet access for users
 Currently, 25 percent of global Internet users, or 750
million people, use DNSSEC-validating resolvers that
could be affected by the KSK rollover
 If these validating resolvers do not have the new key
when the KSK is rolled, end users relying on those
resolvers will encounter errors and be unable to
access the Internet

38. | 38
What Do Operators Need to Do?
Be aware whether DNSSEC is enabled in your servers
Be aware of how trust is evaluated in your operations
Test/verify your set ups
Inspect configuration files, are they (also) up to date?
If DNSSEC validation is enabled or planned in your system
o Have a plan for participating in the KSK rollover
o Know the dates, know the symptoms, solutions

39. | 39
How To Update Your System
If your software supports
automated updates of DNSSEC
trust anchors (RFC 5011):
 The KSK will be updated
automatically at the
appropriate time
 You do not need to take
additional action
o Devices that are offline
during the rollover will
have to be updated
manually if they are
brought online after the
rollover is finished
If your software does not
support automated updates
of DNSSEC trust anchors
(RFC 5011) or is not
configured to use it:
 The software’s trust anchor file
must be manually updated
 The new root zone KSK is now
available here after March 2017:
Root Anchors
data.iana.org/root-anchors

40. | 40
Check to See If Your Systems Are Ready
ICANN is offering a test bed for operators or any
interested parties to confirm that their systems handle
the automated update process correctly.
Check to make sure
your systems are ready by visiting:
go.icann.org/KSKtest

41. | 41
Three Steps to Recovery
Stop the tickets
It's OK to turn off DNSSEC validation while you fix (but
remember to turn it back on!)
Debug
If the problem is the trust anchor, find out why it isn't correct
o Did RFC 5011 fail? Did configuration tools fail to
update the key?
o If the problem is fragmentation related, make sure TCP
is enabled and/or make other transport adjustments
Test the recovery
Make sure your fixes take hold
If your DNSSEC validation fails after the key role:

42. | 42
For More Information
Join the conversation online
o Use the hashtag
#KeyRoll
o Sign up to the mailing list
https://mm.icann.org/
listinfo/ksk-rollover
Attend an event
o Visit
https://features.icann.org/
calendar to find upcoming
KSK rollover presentations in
your region
Ask a question to
globalsupport@icann.org
o Subject line: “KSK Rollover”
Learn more
https://icann.org/kskroll