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 Adriana.Lazzaroni@iit.cnr.it

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 Arianna.DelSoldato@iit.cnr.it