10. Meccanismi di Sicurezza

Questa sezione descrive la generazione e l'elaborazione di messaggi RPL sicuri. Il bit di ordine superiore del codice del messaggio RPL identifica se un messaggio RPL è sicuro o meno. Oltre alle versioni sicure dei messaggi di controllo di base (DIS, DIO, DAO, DAO-ACK), RPL ha diversi messaggi che sono rilevanti solo nelle reti in cui la sicurezza è abilitata.

La complessità e la dimensione dell'implementazione sono una preoccupazione centrale per le LLN, tale che potrebbe essere economicamente o fisicamente impossibile includere disposizioni di sicurezza sofisticate in un'implementazione RPL. Inoltre, molte implementazioni possono utilizzare meccanismi di sicurezza a livello di collegamento o altri meccanismi per soddisfare i propri requisiti di sicurezza senza richiedere l'uso della sicurezza in RPL.

Pertanto, le funzionalità di sicurezza descritte in questo documento sono OPZIONALI da implementare. Una data implementazione PUÒ supportare un sottoinsieme (incluso l'insieme vuoto) delle funzionalità di sicurezza descritte, ad esempio, potrebbe supportare l'integrità e la riservatezza, ma non le firme. Un'implementazione DOVREBBE specificare chiaramente quali meccanismi di sicurezza sono supportati, ed è RACCOMANDATO che gli implementatori considerino attentamente i requisiti di sicurezza e la disponibilità di meccanismi di sicurezza nella loro rete.

10.1. Panoramica della Sicurezza

RPL supporta tre modalità di sicurezza:

• Non protetto (Unsecured): In questa modalità di sicurezza, RPL utilizza messaggi DIS, DIO, DAO e DAO-ACK di base, che non hanno sezioni di sicurezza. Poiché una rete potrebbe utilizzare altri meccanismi di sicurezza, come la sicurezza a livello di collegamento, la modalità non protetta non implica che tutti i messaggi siano inviati senza alcuna protezione.

• Preinstallato (Preinstalled): In questa modalità di sicurezza, RPL utilizza messaggi sicuri. Per unirsi a un'istanza RPL, un nodo deve avere una chiave preinstallata. I nodi utilizzano questo per fornire riservatezza, integrità e autenticità dei messaggi. Un nodo può, utilizzando questa chiave preinstallata, unirsi alla rete RPL sia come host che come router.

• Autenticato (Authenticated): In questa modalità di sicurezza, RPL utilizza messaggi sicuri. Per unirsi a un'istanza RPL, un nodo deve avere una chiave preinstallata. I nodi utilizzano questa chiave per fornire riservatezza, integrità e autenticità dei messaggi. Utilizzando questa chiave preinstallata, un nodo può unirsi alla rete solo come host. Per unirsi alla rete come router, un nodo deve ottenere una seconda chiave da un'autorità di chiave. Questa autorità di chiave può autenticare che il richiedente è autorizzato a essere un router prima di fornirgli la seconda chiave. La modalità autenticata non può essere supportata da algoritmi simmetrici. Al momento della stesura di questa specifica, RPL supporta solo algoritmi simmetrici: la modalità autenticata è inclusa a beneficio di potenziali primitive crittografiche future. Vedi Sezione 10.3.

Se l'istanza RPL utilizza o meno la modalità non protetta è segnalato dal fatto che utilizzi o meno messaggi RPL sicuri. Se una rete protetta utilizza la modalità preinstallata o autenticata è segnalato dal bit 'A' dell'opzione di configurazione DAG.

Questa specifica specifica CCM -- Counter with CBC-MAC (Cipher Block Chaining - Message Authentication Code) -- come base crittografica per la sicurezza RPL [RFC3610]. In questa specifica, CCM utilizza AES-128 come algoritmo crittografico sottostante. Ci sono bit riservati nella sezione Sicurezza per specificare altri algoritmi in futuro.

Tutti i messaggi RPL protetti hanno o un MAC o una firma. Opzionalmente, i messaggi RPL protetti hanno anche una protezione di crittografia per la riservatezza. I formati dei messaggi RPL protetti supportano sia schemi integrati di crittografia/autenticazione (ad esempio, CCM) sia schemi che crittografano e autenticano i pacchetti separatamente.

10.2. Unirsi a una Rete Sicura

La sicurezza RPL presuppone che un nodo che desidera unirsi a una rete protetta sia stato preconfigurato con una chiave condivisa per comunicare con i vicini e la radice RPL. Per unirsi a una rete RPL sicura, un nodo ascolta i DIO sicuri o attiva i DIO sicuri inviando un DIS sicuro. Oltre alle regole DIO/DIS nella Sezione 8, i messaggi DIO e DIS sicuri hanno queste regole:

1. Se inviato, questo DIS sicuro iniziale DEVE impostare il campo Key Identifier Mode a 0 (00) e DEVE impostare il campo Security Level a 1 (001). La chiave utilizzata DEVE essere la chiave di gruppo preconfigurata (Key Index 0x00).

2. Quando un nodo reimposta il suo timer Trickle in risposta a un DIS sicuro (Sezione 8.3), il prossimo DIO che trasmette DEVE essere un DIO sicuro con la stessa configurazione di sicurezza del DIS sicuro. Se un nodo riceve più messaggi DIS sicuri prima di trasmettere un DIO, il DIO sicuro DEVE avere la stessa configurazione di sicurezza dell'ultimo DIS a cui sta rispondendo.

3. Quando un nodo invia un DIO in risposta a un DIS sicuro unicast (Sezione 8.3), il DIO DEVE essere un DIO sicuro.

Le regole di cui sopra consentono a un nodo di unirsi a un'istanza RPL protetta utilizzando la chiave condivisa preconfigurata. Una volta che un nodo si è unito al DODAG utilizzando la chiave condivisa preconfigurata, il bit 'A' dell'opzione di Configurazione determina le sue capacità. Se il bit 'A' dell'opzione di Configurazione è azzerato, allora i nodi possono utilizzare questa chiave condivisa preinstallata per scambiare messaggi normalmente: può emettere DIO, DAO, ecc.

Se il bit 'A' dell'opzione di Configurazione è impostato e l'istanza RPL sta operando in modalità autenticata:

1. Un nodo NON DEVE annunciare un Rango diverso da INFINITE_RANK nei DIO sicuri protetti con Key Index 0x00. Durante l'elaborazione di messaggi DIO protetti con Key Index 0x00, un nodo di elaborazione DEVE considerare il Rango annunciato come INFINITE_RANK. Qualsiasi altro valore comporta lo scarto del messaggio.

2. I DAO sicuri che utilizzano un Key Index 0x00 NON DEVONO avere un'opzione RPL Target con un prefisso diverso dall'indirizzo del nodo. Se un nodo riceve un messaggio DAO protetto utilizzando la chiave condivisa preinstallata in cui l'opzione RPL Target non corrisponde all'indirizzo sorgente IPv6, DEVE scartare il messaggio DAO protetto senza ulteriore elaborazione.

Le regole di cui sopra significano che nelle istanze RPL in cui il bit 'A' è impostato, utilizzando Key Index 0x00, un nodo può unirsi all'istanza RPL come host ma non come router. Un nodo deve comunicare con un'autorità di chiave per ottenere una chiave che gli consentirà di agire come router.

10.3. Installazione delle Chiavi

La modalità autenticata richiede che un aspirante router installi dinamicamente nuove chiavi una volta che si è unito a una rete come host. Avendo aderito come host, il nodo utilizza la messaggistica IP standard per comunicare con un server di autorizzazione, che può fornire nuove chiavi.

Il protocollo per ottenere tali chiavi è fuori dall'ambito di questa specifica e sarà elaborato in specifiche future. Tale elaborazione è necessaria affinché RPL operi in modo sicuro in modalità autenticata.

10.4. Controlli di Coerenza

I nodi RPL inviano messaggi di Controllo di Coerenza (Consistency Check - CC) per proteggersi dagli attacchi di replay e sincronizzare i contatori.

1. Se un nodo riceve un messaggio CC unicast con il bit 'R' azzerato, ed è membro di o sta per unirsi al DODAG associato, DOVREBBE rispondere con un messaggio CC unicast al mittente. Questa risposta DEVE avere il bit 'R' impostato, e DEVE avere gli stessi campi CC nonce, RPLInstanceID e DODAGID del messaggio che ha ricevuto.

2. Se un nodo riceve un messaggio CC multicast, DEVE scartare il messaggio senza ulteriore elaborazione.

I messaggi di Controllo di Coerenza consentono ai nodi di emettere una sfida-risposta per convalidare il valore corrente del contatore di un nodo. Poiché il nonce CC è generato dallo sfidante, è improbabile che un avversario che riproduce i messaggi sia in grado di generare una risposta corretta. Il contatore nella risposta del Controllo di Coerenza consente allo sfidante di convalidare i valori del contatore che sente.

10.5. Contatori

Nel caso più semplice, il valore del contatore è un intero senza segno che un nodo incrementa di uno o più a ogni trasmissione RPL protetta. Il contatore PUÒ rappresentare un timestamp che ha le seguenti proprietà:

1. Il timestamp DEVE essere lungo almeno sei ottetti.

2. Il timestamp DEVE essere in granularità di 1024 Hz (millisecondo binario).

3. L'ora di inizio del timestamp DEVE essere il 1 gennaio 1970, 00:00:00 UTC.

4. Se il contatore rappresenta un timestamp, il valore del contatore DEVE essere un valore calcolato come segue. Sia T il timestamp, S l'ora di inizio della chiave in uso, ed E l'ora di fine della chiave in uso. Sia S che E sono rappresentati utilizzando le stesse tre regole del timestamp descritto sopra. Se E > T < S, allora il contatore non è valido e un nodo NON DEVE generare un pacchetto. Altrimenti, il valore del contatore è uguale a T-S.

5. Se il contatore rappresenta tale timestamp, un nodo PUÒ impostare il flag 'T' della sezione Sicurezza dei pacchetti RPL protetti.

6. Se il campo Counter non presenta tale timestamp, allora un nodo NON DEVE impostare il flag 'T'.

7. Se un nodo non ha un timestamp locale che soddisfa i requisiti di cui sopra, DEVE ignorare il flag 'T'.

Se un nodo supporta tali timestamp e riceve un messaggio con il flag 'T' impostato, PUÒ applicare il controllo temporale sul messaggio ricevuto descritto nella Sezione 10.7.1. Se un nodo riceve un messaggio senza il flag 'T' impostato, NON DEVE applicare questo controllo temporale. La politica di sicurezza di un nodo PUÒ, per motivi applicativi, includere il rifiuto di tutti i messaggi senza il flag 'T' impostato.

Il flag 'T' è presente perché molte LLN oggi mantengono già una sincronizzazione temporale globale a una granularità inferiore al millisecondo per sicurezza, applicazione e altri motivi. Consentire a RPL di sfruttare questa funzionalità esistente quando presente semplifica notevolmente le soluzioni ad alcuni problemi di sicurezza, come la protezione dai ritardi.

10.6. Trasmissione di Pacchetti in Uscita

Dato un pacchetto di controllo RPL in uscita e la protezione di sicurezza richiesta, questa sezione descrive come RPL genera il pacchetto protetto da trasmettere. Descrive anche l'ordine delle operazioni crittografiche per fornire la protezione richiesta.

Il requisito per la protezione di sicurezza e il livello di sicurezza da applicare a un pacchetto RPL in uscita sarà determinato dal database delle politiche di sicurezza del nodo. La configurazione di questo database delle politiche di sicurezza per l'elaborazione dei pacchetti in uscita è specifica dell'implementazione.

Ove i messaggi RPL protetti devono essere trasmessi, un nodo RPL DEVE impostare la sezione Sicurezza (T, Sec, KIM e LVL) nel pacchetto RPL in uscita per descrivere il livello di protezione e le impostazioni di sicurezza che sono applicate (vedi Sezione 6.1). Il bit del sottocampo Security del campo RPL Message Code DEVE essere impostato per indicare il messaggio RPL sicuro.

Il valore del contatore utilizzato nella costruzione del nonce AES-128 CCM (Figura 31) per proteggere il pacchetto in uscita DEVE essere un incremento dell'ultimo contatore trasmesso al particolare indirizzo di destinazione.

Ove la politica di sicurezza specifica l'applicazione della protezione dai ritardi, il contatore Timestamp utilizzato nella costruzione del nonce CCM per proteggere il pacchetto in uscita DEVE essere incrementato secondo le regole nella Sezione 10.5. Ove un contatore Timestamp è applicato (indicato con il flag 'T' impostato), il contatore Timestamp mantenuto localmente DEVE essere incluso come parte del messaggio RPL protetto trasmesso.

L'algoritmo crittografico utilizzato per proteggere il pacchetto in uscita sarà specificato dal database delle politiche di sicurezza del nodo e DEVE essere indicato nel valore del campo Sec impostato all'interno del messaggio in uscita.

La politica di sicurezza per il pacchetto in uscita determinerà il KIM applicabile e il Key Identifier che specifica la chiave di sicurezza da utilizzare per l'elaborazione crittografica del pacchetto, incluso l'uso opzionale di chiavi di firma (vedi Sezione 6.1). La politica di sicurezza specificherà anche l'algoritmo (Algorithm) e il livello di protezione (Level) sotto forma di autenticazione o autenticazione e crittografia, e il potenziale uso di firme che si applicheranno al pacchetto in uscita.

Ove la crittografia è applicata, un nodo DEVE sostituire il payload del pacchetto originale con quel payload crittografato utilizzando la protezione di sicurezza, la chiave e il nonce CCM specificati nella sezione Sicurezza del pacchetto.

Tutti i messaggi RPL protetti includono la protezione dell'integrità. Insieme all'elaborazione dell'algoritmo di sicurezza, un nodo deriva o un MAC o una firma che DEVE essere inclusa come parte del pacchetto RPL protetto in uscita.

10.7. Ricezione di Pacchetti in Entrata

Questa sezione descrive la ricezione e l'elaborazione di un pacchetto RPL protetto. Dato un pacchetto RPL protetto in entrata, in cui il bit del sottocampo Security del campo RPL Message Code è impostato, questa sezione descrive come RPL genera una variante non crittografata del pacchetto e ne convalida l'integrità.

Il ricevitore utilizza i campi di controllo di sicurezza RPL per determinare l'elaborazione di sicurezza del pacchetto necessaria. Se il livello di sicurezza descritto per il tipo di messaggio e l'originatore è sconosciuto o non soddisfa le politiche di sicurezza mantenute localmente, un nodo DEVE scartare il pacchetto senza ulteriore elaborazione, PUÒ sollevare un avviso di gestione, e NON DEVE inviare alcun messaggio in risposta. Queste politiche possono includere livelli di sicurezza, chiavi utilizzate, identificatori di sorgente, o la mancanza di contatori basati su timestamp (come indicato dal flag 'T'). La configurazione del database delle politiche di sicurezza per l'elaborazione dei pacchetti in entrata è fuori dall'ambito di questa specifica (può, ad esempio, essere definita tramite la Configurazione DIO o tramite la configurazione del router amministrativo fuori banda).

Ove il livello di sicurezza del messaggio (LVL) indica un messaggio RPL crittografato, il nodo utilizza le informazioni sulla chiave identificate tramite il campo KIM così come il nonce CCM come input per l'elaborazione di decrittografia del payload del messaggio. Il nonce CCM sarà derivato dal campo Counter del messaggio e da altre informazioni ricevute e mantenute localmente (vedi Sezione 10.9.1). Il contenuto del messaggio in testo normale sarà ottenuto invocando la modalità operativa crittografica inversa specificata dal campo Sec del pacchetto ricevuto.

Il ricevitore utilizzerà il nonce CCM e le informazioni sulla chiave identificate per controllare l'integrità del pacchetto in entrata. Se il controllo di integrità fallisce rispetto al MAC ricevuto, un nodo DEVE scartare il pacchetto.

Se il messaggio ricevuto ha un valore del contatore inizializzato (valore zero) e il ricevitore ha un contatore in entrata attualmente mantenuto per l'originatore del messaggio, il ricevitore DEVE avviare una risincronizzazione del contatore inviando un messaggio di risposta di Controllo di Coerenza (vedi Sezione 6.6) alla sorgente del messaggio. Il messaggio di risposta di Controllo di Coerenza sarà protetto con il contatore in uscita completo corrente mantenuto per il particolare indirizzo del nodo. Quel contatore in uscita sarà incluso all'interno della sezione di sicurezza del messaggio mentre il contatore in entrata sarà incluso all'interno del payload del messaggio di Controllo di Coerenza.

Sulla base della politica di sicurezza specificata, un nodo PUÒ applicare la protezione dai replay per un messaggio RPL ricevuto. Il controllo di replay DOVREBBE essere eseguito prima dell'autenticazione del pacchetto ricevuto. Il contatore, come ottenuto dal pacchetto in entrata, sarà confrontato con il watermark del contatore in entrata mantenuto per il dato indirizzo del nodo di origine. Se il valore del contatore del messaggio ricevuto è diverso da zero e inferiore al watermark del contatore in entrata mantenuto, è indicato un potenziale replay del pacchetto e il nodo DEVE scartare il pacchetto in entrata.

Se la protezione dai ritardi è specificata come parte dei controlli della politica di sicurezza del pacchetto in entrata, il contatore Timestamp viene utilizzato per convalidare la tempestività del messaggio RPL ricevuto. Se il valore del contatore Timestamp del messaggio in entrata indica un'ora di trasmissione del messaggio precedente al contatore dell'ora di trasmissione mantenuto localmente per l'indirizzo dell'originatore, è indicata una violazione di replay e il nodo DEVE scartare il pacchetto in entrata. Se il valore del contatore Timestamp ricevuto indica un'ora di trasmissione del messaggio che è precedente all'ora Corrente meno il ritardo del pacchetto accettabile, è indicata una violazione di ritardo e il nodo DEVE scartare il pacchetto in entrata.

Una volta che un messaggio è stato decrittografato, ove applicabile, e ha superato con successo il suo controllo di integrità, controllo di replay, e opzionalmente controlli di protezione dai ritardi, il nodo può aggiornare le sue informazioni di sicurezza locali, come il valore del contatore previsto della sorgente per il confronto di replay.

Un nodo NON DEVE aggiornare le sue informazioni di sicurezza alla ricezione di un messaggio che fallisce i controlli della politica di sicurezza o altri controlli di integrità, replay o ritardo applicati.

10.7.1. Controlli della Chiave Timestamp

Se il flag 'T' di un messaggio è impostato e un nodo ha un timestamp locale che segue i requisiti nella Sezione 10.5, allora un nodo PUÒ controllare la coerenza temporale del messaggio. Il nodo calcola l'ora di trasmissione del messaggio aggiungendo il valore del contatore all'ora di inizio della chiave associata. Se questa ora di trasmissione è oltre l'ora di fine della chiave, il nodo PUÒ scartare il messaggio senza ulteriore elaborazione. Se l'ora di trasmissione è troppo lontana nel passato o nel futuro rispetto all'ora locale sul ricevitore, PUÒ scartare il messaggio senza ulteriore elaborazione.

10.8. Copertura di Integrità e Riservatezza

Per un messaggio RPL ICMPv6, l'intero pacchetto è all'interno dell'ambito della sicurezza RPL.

I MAC e le firme sono calcolati sull'intero pacchetto IPv6 non protetto. Quando si calcolano MAC e firme, i campi IPv6 mutabili sono considerati riempiti con zeri, seguendo le regole nella Sezione 3.3.3.1 di [RFC4302] (IPsec Authenticated Header). I calcoli di MAC e firma sono eseguiti prima di qualsiasi compressione che i livelli inferiori possono applicare.

Quando un messaggio RPL ICMPv6 è crittografato, la crittografia inizia al primo byte dopo la sezione Sicurezza e continua fino all'ultimo byte del pacchetto. L'intestazione IPv6, l'intestazione ICMPv6 e il messaggio RPL fino alla fine della sezione Sicurezza non sono crittografati, poiché sono necessari per decrittografare correttamente il pacchetto.

Ad esempio, un nodo che invia un messaggio con LVL=1, KIM=0, e Algorithm=0 utilizza l'algoritmo CCM [RFC3610] per creare un pacchetto con attributi ENC-MAC-32: crittografa il pacchetto e appende un MAC a 32 bit. La chiave di cifratura a blocchi è determinata dal Key Index. Il nonce CCM è calcolato come descritto nella Sezione 10.9.1; il messaggio da autenticare e crittografare è il messaggio RPL che inizia al primo byte dopo la sezione Sicurezza e termina con l'ultimo byte del pacchetto. I dati di autenticazione aggiuntivi iniziano con l'inizio dell'intestazione IPv6 e terminano con l'ultimo byte della sezione Sicurezza RPL.

10.9. Modalità Operativa Crittografica

La modalità operativa crittografica descritta in questa specifica (Algorithm = 0) è basata su CCM e il cifrario a blocchi AES-128 [RFC3610]. Questa modalità operativa è ampiamente supportata dalle implementazioni esistenti. La modalità CCM richiede un nonce (nonce CCM).

10.9.1. Nonce CCM

Un nodo RPL costruisce un nonce CCM come segue:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                       Identificatore Sorgente                 +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Contatore                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |KIM|Resvd| LVL |
    +-+-+-+-+-+-+-+-+

                        Figura 31: Nonce CCM

• Identificatore Sorgente (Source Identifier): 8 byte. Source Identifier è impostato all'identificatore logico dell'originatore del pacchetto protetto.

• Contatore (Counter): 4 byte. Counter è impostato al valore (non compresso) del campo corrispondente nell'opzione Sicurezza del messaggio di controllo RPL.

• Key Identifier Mode (KIM): 2 bit. KIM è impostato al valore del campo corrispondente nell'opzione Sicurezza del messaggio di controllo RPL.

• Security Level (LVL): 3 bit. Security Level è impostato al valore del campo corrispondente nell'opzione Sicurezza del messaggio di controllo RPL.

I bit non assegnati del nonce CCM sono riservati. DEVONO essere impostati a zero quando si costruisce il nonce CCM.

Tutti i campi del nonce CCM sono rappresentati nell'ordine dell'ottetto più significativo e del bit più significativo per primo.

10.9.2. Firme

Se il KIM indica l'uso di firme (un valore di 3), allora un nodo appende una firma al payload dei dati del pacchetto. Il campo Security Level (LVL) descrive la lunghezza di questa firma. Lo schema di firma in RPL per la Modalità di Sicurezza 3 è un'istanziazione dell'algoritmo RSA (RSASSA-PSS) come definito nella Sezione 8.1 di [RFC3447]. Come chiave pubblica, utilizza la coppia (n,e), dove n è un modulo RSA a 2048 bit o 3072 bit e dove e=2^{16}+1. Utilizza la modalità CCM [RFC3610] come schema di crittografia con M=0 (come un cifrario a flusso). Nota che sebbene [RFC3610] non consenta la modalità CCM con M=0, RPL consente esplicitamente la modalità CCM con M=0 quando utilizzata insieme a una firma, perché la firma fornisce un'autenticazione dei dati sufficiente. Qui, la modalità CCM con M=0 è specificata come in [RFC3610], ma dove il campo M' nella Sezione 2.2 DEVE essere impostato a 0. Utilizza la funzione di hash SHA-256 specificata nella Sezione 6.2 di [FIPS180]. Utilizza le regole di codifica del messaggio della Sezione 8.1 di [RFC3447].

Sia 'a' una concatenazione di una rappresentazione di 6 byte del contatore e dell'intestazione del messaggio. Il payload del pacchetto è la concatenazione destra dei dati del pacchetto 'm' e della firma 's'. Questo schema di firma è invocato con la concatenazione destra delle parti del messaggio a e m, mentre la verifica della firma è invocata con la concatenazione destra delle parti del messaggio a e m e con la firma s.

Le firme RSA di questa forma forniscono una protezione sufficiente per le reti RPL. Se necessario, schemi di firma alternativi che producono firme più concise sono fuori dall'ambito di questa specifica e possono essere oggetto di una specifica futura.

Un'implementazione che supporta la firma RSA con firme a 2048 bit o 3072 bit DOVREBBE supportare la verifica di entrambe le firme RSA a 2048 bit e 3072 bit. Questo è in considerazione di fornire un percorso di aggiornamento per un'implementazione RPL.