Aspetti internazionali: la transizione IANA e i TLDs
A. Lazzaroni A. Del Soldato
Le funzioni IANA
Il modello multistakeholder di ICANN
Annuncio transizione IANA - 14 marzo 2014
Requisiti
Percorsi paralleli
Situazione attuale
Proposte di transizione
Transizione IANA: proposta !nale
• Sarà istituita una nuova entità giuridica denominata PTI (Post-Transition IANA) affiliata ad ICANN;
• ICANN stipulerà un contratto con PTI, trasferendo a quest’ultima entità diritti e obbligazioni per svolgere le funzioni IANA ed agire quale IANA Functions Operator (IFO).
• Sarà istituita una Commissione permanente (CSC Customer Standing Committee) che avrà il compito ai di monitorare le attività operative e il livello del servizio offerto da PTI rispetto ai SLE.
• Saranno proposti ed esaminati cambiamenti alla Root Zone e al rapporto con i maintainer della Root Zone.
La transizione IANA e i ccTLDs
Utilizzo dei ccTLDs come domini di I livello Costituzione di un gruppo di lavoro trasversale (Cross-Community WG on Use of Country & Territory Names and Codes as TLDs) che ha il compito di:
• esaminare lo stato attuale dei nomi a dominio geogra#ci, così come è implementato nelle attuali politiche di ICANN, nelle sue linee guida e nelle procedure;
• fornire consulenza per lo sviluppo di un insieme coerente ed uniforme di de#nizioni applicabili ai nomi di paesi e territori quali nomi a dominio di I livello.
• Concordare strategie comuni sull’uso di codici a 2 lettere, codici a 3 lettere, e nomi estesi di paesi e territori
La transizione IANA e i ccTLDs
Delegation and redelegation • Draft proposal del Dicembre 2014: proposta di adozione di un
meccanismo di ricorso/contestazione su decisioni riguardanti la delega dei ccTLDs;
• Sondaggio interno alla comunità dei ccTLD (solo 28 risposte);
• Partecipazione insufficiente per l’introduzione di un meccanismo di appello nella proposta di transizione IANA;
• Il 71% dei ccTLD intervistati ha indicato di non volere che tale meccanismo di ricorso possa ritardare il completamento della transizione di IANA.
La transizione IANA e i ccTLDs
Altre questioni (1): • Un numero limitato di registri ccTLD hanno un contratto
formale con ICANN anche se tutti contano sul servizio di gestione della root-zone coordinato da IANA;
• Non vi è alcun obbligo in termini #nanziari per poter
utilizzare il servizio di IANA; • Un numero signi#cativo di registri ccTLD non sono membri
del ccNSO di ICANN.
La transizione IANA e i ccTLDs
Altre questioni (2): • Le politiche dei ccTLD sono #ssate localmente in accordo con
la comunità Internet locale;
• le esigenze della comunità dei ccTLD sono uniche e peculiari;
• la transizione IANA deve cercare di non imporre ai ccTLD regole comuni o strutture prede#nite, se non espressamente legate alla sicurezza e stabilità del DNS e alla gestione della root-zone;
ICANN Accountability Final Draft Proposal on Work Stream 1 Recommendations 30 November 2015 Attualmente sottoposta ad un periodo
di public comments da parte della
comunità degli stakeholders !no al 21
Dicembre 2015
IANA Transition Timeline
ccTLD members of ccNSO Council approve CWG Draft Proposal
ICAN
N 53, Bue
nos A
ires Jun
e 2015
The Internet revolution
15 Dicembre 2015 ADRIANA LAZZARONI [email protected]
Esplosione dei gTLD e la TAS (TLD Application System)
Application
Submission
Period
Administrative
Completeness
Check
Initial
Evaluation
Transition to Delegation
Extended
Evaluation
Dispute
Resolution
String
Contention
Objection
Filing
Delegation
Execution
of RA Pre
Delegation Test
1930 (117 IDN)
1783
35
233
263
233 826
(64 IDN)
155
Jan: Open Registration & Application Submission 29 mar 2012: Close Registration 12 apr 2012: Close Application Submission
2012 2015 2017
209 (14 Auction)
Andamento deleghe nuovi gTLD
4
30
39
49
41 35
58
28 26
44
22
14
21
30
20
57
23
40
38
44
20
16 18
5 0
10
20
30
40
50
60
70 o:
-‐13
nov-‐13
dic-‐13
gen-‐14
feb-‐14
mar-‐14
apr-‐14
mag-‐14
giu-‐14
lug-‐14
ago-‐14
set-‐14
o:-‐14
nov-‐14
dic-‐14
gen-‐15
feb-‐15
mar-‐15
apr-‐15
mag-‐15
giu-‐15
lug-‐15
ago-‐15
set-‐15
o:-‐15
nov-‐15
dic-‐15
Gli italiani e la registrazione dei domini sotto i nuovi gTLD
Cross-Community WG: Use of Country & Territory Names as TLDs
Scopo del WG: • Rivedere lo stato attuale della rappresentazione dei nomi geogra#ci
e territoriali nelle politiche di ICANN nelle linee guida e nelle procedure
• Fornire una consulenza per la presentazione de#nitiva di un insieme di de#nizioni applicabili
Principali problematiche trattate: • Le problematiche di elegibilità dei codici a due e tre lettere
tenendo conto anche dell’IDN
• Le possibili difficoltà dell’utente #nale di distinguere tra un ccTLD e un gTLD a due o tre lettere
• La possibile discriminazione per i nuovi TLD dei paesi emergenti
Cross-Community WG: Use of Country & Territory Names as TLDs(cont)
Nel periodo di valutazione dell’applicazione di un TLD si controlla che la stringa non coincida con un nome geogra#co • Le regole nell’AGB (Application Guidebook) de#niscono inapplicabile un
gTLD se:
• è una stringa a due o tre lettere contenuta nell’ISO 3166-1 • è una stringa corrispondente al nome esteso o contratto di un
paese contenuta nell’ISO 3166-1 • è la traduzione di uno dei punti sopra in qualsiasi lingua • è un nome considerato eccezionalmente riservato nell’ISO 3166 • può essere ricondotta ad una delle stringhe sopra per
trasmutazione o permutazione togliendo spazi o inserendo numeri e/o articoli
• è il nome con il quale una nazione è comunemente conosciuta
Cross-Community WG: Use of Country & Territory Names as TLDs (cont)
Stato dell’arte • La discussione sui due caratteri si è conclusa dopo ICANN 53 (giu 2015): il
WG raccomanda il loro mantenimento come nomi riservati ai ccTLD, secondo le attuali politiche di ICANN
• Durante ICANN 54 (ott 2015) è stata aperta la discussione sui tre caratteri:
1. Devono tutti essere riservati ai ccTLD ed essere ineligibili per i gTLD?
2. Possono essere eleggibili se non in con$itto con le de#nizioni contenute nell’ISO 3166-1?
3. Sono eleggibili se vale il p.to 2. e non sussistono obiezioni da parte dei relativi Governi o Autorità Pubbliche?
4. Sono eleggibili se non in con$itto con i TLD esistenti o stringhe simili che hanno applicato?
5. Le stringhe IDN devono essere tutte eleggibili solo per i ccTLD?
Cross-Community WG: Use of Country & Territory Names as TLDs (cont)
Questioni aperte
• Le opinioni del GAC
• Short form e Long form dei Country and Territory Name
• Latin Letter e IDN
• La rappresentazione delle capitali e delle città
• Situazioni di con$itto: • Esempio: .com è un gTLD registrato, in con$itto con
Comores; .xyz è un gTLD a tre lettere registrato ma non è nell’ISO
Utilizzo dei Country e Territory Name al II livello dei gTLD
• La Speci!cation 5 – Section 4 del Registry Agreement indica che i Country e Territory Name:
• Dovrebbero rimanere riservati ma possono essere rilasciati: Previo accordo del Registry Operator (RO) con il Governo e il gestore del country-code di riferimennto e Dopo averne fatta esplicita richiesta di rilascio ad ICANN
• Il GAC ha pubblicato tre Noti!cation Requirements List per facilitare i RO nel processo di richiesta di rilascio:
• Lista di 82 paesi per il rilascio dei corrispondenti Country and Territory Name (63 richiedono la noti#ca per ogni richiesta, 10 rinunciano alla noti#ca per brand gTLD , 9 rinunciano ad ogni noti#ca)
• Elenco di 10 ccTLD i cui governi rinunciano alla noti#ca per il rilascio della stringa a due caratteri (.at, .ch, .dk, .ie, .nl, .de, .ro, .se, .uk, .us)
• Elenco di due ccTLD i cui governi rinunciano alla noti#ca per brand TLD (.es, .nz)
Utilizzo dei Country e Territory Name al II livello dei gTLD (cont)
Processo di valutazione delle richieste di rilascio delle stringhe a due caratteri di ICANN
• Il RO richiede l’autorizzazione sulla base delle misure adottate al #ne di evitare confusione col corrispondente Country Code:
• La richiesta viene validata da ICANN e pubblicata sul sito per 60 gg per essere valutata
• ICANN avvisa i governi della pubblicazione di ogni richiesta
• In assenza di obiezioni ICANN autorizza il rilascio al RO
• In caso di obiezioni ICANN avvia un processo di valutazione che prevede la richiesta di chiarimento delle obiezioni e l’avvio di un eventuale Mitigation Plan
ICANN e il nuovo Protocollo RDAP • L’RDAP (Registration Data Access Protocol) è un nuovo protocollo progettato
per sostituire l’Whois e de#nito negli RFC 7480-7484 (Marzo 2015)
• Perché serve un nuovo approccio?
Standard
• Non ha standard per query e risposte strutturate
• Non supporta l’internazionalizzazione
• Non fornisce un servizio differenziato
• Non è estensibile
• Non supporta funzionalità di sicurezza (meccanismo di autenticazione)
Caratteristiche RDAP
• Query e risposte strutturate
• (RESTful API, JSON responses)
• Supporta l’internazionalizzazione
• Funzionalità di autenticazione e autorizzazione
• E’ estensibile
• Fornisce un metodo $essibile per identi#care sorgenti autoritative
ICANN e il nuovo Protocollo RDAP (Cont)
Necessità dell’RDAP Pro#le
• Chiarire i requisiti necessari ai gTLD per una corretta implementazione dell’RDAP • Inserire le funzionalità che mancano all’RDAP per essere equivalente all’WHOIS
• (EPP status, RDAP DB last update, registrar expiration date, bolean search)
Monitoraggio
SLA Info sugli abuse
contacts DNSSEC HTTPS
.. ecc
IDN lookup
IPV4 e IPV6
Consistenza tra Whois e
RDAP
Estensioni RDAP a IANA’s RDAP
Extension Registry
Interazione Registro/Registrar
Procedure del Registro
ICANN e il nuovo Protocollo RDAP (Cont)
Timeline
Il protocollo RDAP e Registro .it
• Stiamo valutando i pro, i contro e i requisiti necessari per l’adozione dell’RDAP nel Registro .it • Il protocollo RDAP è stato disegnato per i gTLD
• Contratto diretto con ICANN e DNRD-DS ben speci#cato
• Analisi delle estensioni e modi#che implementate nell’Whois del Registro .it
• Esistenza di Whois con diverse estensioni e modi#che nei vari ccTLD • RFC 7485 – Inventory and Analysis of Whois Registration Objects – March 2015 (dati raccolti a luglio
2012!) • Difficoltà a trovare regole comuni per i ccTLD
ICANN e il nuovo Protocollo RDAP (Cont)
Altri temi trattati • ICANN: Root Zone KSK Rollover Plan
• Cambio della chiave (dal 2010) e aggiornamento dell’harware
• Public Comment Period (2 Ago – 5 Ott 2015) -> Excution Plan
• CWG – SLE Workin Group: SLE Update (post Transition) • Report approvato il 10 sett 2015
• La riservatezza e la sicurezza nei sistemi di gestione dei nomi a dominio • Verisign: RDAP federated authentication
• IETF Working Group DPRIVE: QNAME Minimization metodologia di interrogazione del DNS atta a fornire transazioni riservate
• Attacchi legati al monitoraggio pervasivo (RFC 7258)
15 Dicembre 2015 ARIANNA DEL SOLDATO [email protected]