B.1 Caratteristiche generali SNMP (Simple Network Management Protocol) è un protocollo a livello di applicazione definito per introdurre una semplice architettura per la gestione di reti basate sulla suite di protocolli UDP/IP. Questo protocollo definisce le modalità di scambio di informazioni tra apparecchiature di rete, consentendo agli amministratori di tenere sotto controllo le prestazione della rete e di accorgersi in tempo reale del manifestarsi di malfunzionamenti.
Attualmente il protocollo presenta tre definizioni successive: SNMPv1, SNMPv2, SNMPv3.
La versione più recente introduce nel protocollo alcune nuove funzionalità e correzioni, soprattutto nel campo della sicurezza.
Il protocollo SNMP è attualmente quello più diffuso per la gestione delle reti di calcolatori ed è supportato praticamente da tutti i produttori di hardware ed apparecchiature di rete. B.2 Architettura SNMP
L'architettura di cui il protocollo SNMP fa parte è detta Internet Network Management Framework (NMF) ed è mostrata in figura 24.
L'architettura consente di gestire degli elementi di rete usando degli agent, cioè moduli software che risiedono sulle apparecchiature da gestire. Tali agenti comunicano con un manager (Network Management Station) che, interagendo con i primi, può leggere o scrivere informazioni e raccogliere eventuali segnalazioni di errore.
Le informazioni o caratteristiche che è possibile gestire per una particolare apparecchiatura mediante il protocollo SNMP sono dette Management Objects. L'insieme di questi oggetti costituisce un'astrazione di database detta Management
Information Base (MIB ).
Gli oggetti MIB sono specificati utilizzati un linguaggio apposito per la definizione dei dati, chiamato Structure of Management Information (SMI). Figura 23: Schema logico di un'architettura SNMP Manager Agent MIB Agent MIB Agent MIB Agent MIB
B.3 Structure of Management Information
La struttura delle informazioni di gestione(SMI) è il linguaggio usato per definire le informazioni di gestione residenti in un'entità della rete da gestire. Questo linguaggio di definizione è necessario per assicurare che sintassi e semantica dei dati di gestione della rete siano ben definiti e privi di ambiguità. La SMI non definisce uno specifico campione di dati ma piuttosto il linguaggio con cui queste informazioni devono essere specificate.
Nella RFC 2578 vengono specificati i tipi di dati base nella SMI per il linguaggio di definizione dei moduli MIB. Sebbene la SMI sia basata sul linguaggio ASN.1 (Abstract Syntax Notation One), sono stati aggiunti una quantità di tipi di dati specifici per la SMI tale che essa potrebbe essere condiderata un linguaggio a sé per la parte riguardante la definizione dei dati.
Tipo di dati Descrizione
INTEGER Intero a 32 bit con valore tra 231 e 2311
Integer32 Intero a 32 bit con valore tra 231 e 2311 compreso
Unsigned32 Intero a 32 bit senza segno con valore tra 0 e 2321 compreso OCTET STRING Stringa di byte in formato ANS.1 che rappresenta dati arbitrari in forma binaria o di testo, lunghezza fino a 65535 byte. OBJECT IDENTIFIER nome strutturato IPaddress Indirizzo Internet a 32 bit
Counter32 Contatore a 32 bit che incrementa da 0 a 2321 e
ritorna a zero
Counter64 Contatore a 62 bit
Gauge32 Intero a 32 bit che quando decrementa o incrementa non supera il valore 232—1 e non scende sotto lo 0 TimeTicks Tempo misurato in centesimi al secondo a partire da un evento Opaque stringa ANS.1 non interpretata Tabella 2: Tipi di dati base della SMI Oltre ai tipi base il linguaggio di definizione dei dati della SMI fornisce anche un linguaggio di composizione di livello più alto.
Il costrutto OBJECTTIPE è usato per specificare il tipo di dati, lo stato e la semantica di un oggetto da gestire. Collettivamente, questi oggetti da gestire contengono i dati di gestione che sono situati nel nucleo di gestione della rete. Ci sono circa 10.000 oggetti definiti in diverse RFC relative a Internet[RFC 2570]. Il costrutto OBJECTTYPE specifica il tipo di dati base associato all'oggetto. La frase MAXACCESS specifica se l'oggetto da gestire può essere letto, scritto. creato o se ha il suo valore inserito in una notifica. La frase STATUS indica se la definizione di un oggetto è attuale e valida, obsoleta (nel qual caso esso non può essere implementato e la sua definizione è inserita solo per motivi storici) o recuperabile ( obsoleta ma implementabile).
La frase DESCRIPTION contiene una descrizione testuale dell'oggetto, questa documenta gli scopi dell'oggetto da gestire e dovrebbe fornire tutte le informazioni semantiche necessarie per implementarlo.
In figura 25 è mostrato un esempio del costrutto OBJECT TYPE.
Il costrutto MODULEIDENTITY permette di raggruppare gli oggetti affini all'interno di un “modulo”. Per esempio la RFC 4293 specifica il modulo MIB che definisce gli oggetti da
ipForwarding OBJECTTYPE SYNTAX INTEGER { forwarding(1), acting as a router notForwarding(2) NOT acting as a router } MAXACCESS readwrite STATUS current DESCRIPTION "The indication of whether this entity is acting as an IPv4 router in respect to the forwarding of datagrams received by, but not addressed to, this entity. IPv4 routers forward datagrams. IPv4 hosts do not (except those source routed via the host). When this object is written, the entity should save the change to nonvolatile storage and restore the object from nonvolatile storage upon reinitialization of the system. Note: a stronger requirement is not used because this object was previously defined." ::= { ip 1 } Figura 24: Esempio di costrutto OBJECTTYPE
gestire (compreso ipFowarding in figura 25) per l'implementazione della gestione del protocollo IP.
Oltre a contenere la definizione OBJECTTYPE degli oggetti da gestire all'interno di un modulo, il costrutto MODULE IDENTITY contiene frasi che documentano informazioni per contattare l'autore del modulo, la date dell'ultimo aggiornamento, la storia delle modifiche e una descrizione testuale del modulo. Come esempio, consideriamo la definizione del modulo per la gestione del protocollo IP mostrata in figura 26.
Il costrutto NOTIFICATIONTYPE è usato per specificare le informazioni relative ai messaggi “SNMPv2Trap” e “Information Request” generati da un agent o da un'entità di gestione.
Il costrutto MODULECOMPLIANCE definisce il set di oggetti da gestire all'interno di un modulo che un agente deve implementare.
ipMIB MODULEIDENTITY LASTUPDATED "200602020000Z" ORGANIZATION "IETF IPv6 MIB Revision Team" CONTACTINFO "Editor: Shawn A. Routhier Interworking Labs 108 Whispering Pines Dr. Suite 235 Scotts Valley, CA 95066 USA EMail: <sar@iwl.com>" DESCRIPTION "The MIB module for managing IP and ICMP implementations, but excluding their management of IP routes. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4293; see the RFC itself for full legal notices." REVISION "200602020000Z" DESCRIPTION "The IP version neutral revision with added IPv6 objects for ND, default routers, and router advertisements. As well as being the successor to RFC 2011, this MIB is also the successor to RFCs 2465 and 2466. Published as RFC 4293." REVISION "199411010000Z" DESCRIPTION "A separate MIB module (IPMIB) for IP and ICMP management objects. Published as RFC 2011." REVISION "199103310000Z" DESCRIPTION "The initial revision of this MIB module was part of MIBII, which was published as RFC 1213."
Il costrutto AGENTCAPABILITIES specifica le capacità degli agenti rispetto alla definizione delle notificazione e degli eventi.
B.4 Structure of Management Information
Si può pensare ai MIB come ad un deposito virtuale di informazioni che contiene gli oggetti da gestire i cui valori collettivamente riflettono lo “stato” attuale della rete. Questi valori possono essere richiesti e/o impostati da un'entità di gestione attraverso l'invio di messaggi SNMP all'agent che è in esecuzione sul nodo da gestire. Gli oggetti da gestire sono specificati usando il costrutto SMI OBJECTTYPE e sono raggruppati in moduli MIB usando il costrutto MODULEIDENTITY.
La IETF ha compiuto un lavoro di standardizzazione dei moduli MIB associati con router, host e altri equipaggiamenti di rete. Al momento del rilascio dell'SNMPv3 ( a metà del 1999) estistevano circa 100 standard basati sui moduli MIB e un numero anche superiore di specifiche private dei costruttori.
Con tutti questi standard IETF aveva la necessità di trovare un modo di identificare e battezzare i moduli standardizzati, così come gli oggetti da gestire all'interno di un modulo. La IETF adottò una struttura standardizzata per l'identificazione degli oggetti già utilizzata dall'International Organization for Standardization(ISO). La struttura di identificazione dell'oggetto adottata è parte del linguaggio ASN,1 mentre in figura 27 sono presentati i moduli MIB standardizzati. Come mostra la figura, nella struttura di denominazione ISO gli oggetti sono battezzati in modo gerarchico. Ciascun ramo dell'albero ha sia un nome sia un numero (tra parentesi); ciascun punto dell'albero è identificabile attraverso la sequenza di nomi o numeri che specificano il percorso dalla radice al punto di interesse.
Il livello più basso della gerarchia mostra alcuni dei più importanti moduli MIB orientati al software (system e interface) e alcuni dei moduli associati ai più importanti
protocolli Internet.
Figura 26: Albero di identificazione dell'oggetto ASN.1
B.5 Funzionamento del protocollo SNMP
informazioni MIB fra entità di gestione e agent che intervengono su una richiesta.
L'uso più comune dell'SNMP è nel modo richiestarisposta in cui un'entità di gestione SNMPv2 invia una richiesta ad un agent SNMPv2 che riceve la richiesta, compie alcune operazioni ed invia la risposta. Tipicamente, una richiesta sarà usata per chiedere o modificare i valori dell'oggetto MIB associati con un dispositivo da gestire.
Un secondo uso comune è quello in cui l'agent invia un messaggio non sollecitato, conosciuto come messaggio TRAP, ad un'entità di gestione. I messaggi trap sono usati per notificare ad un'entità di gestione una situazione eccezionale che ha portato a variazioni dei valori degli oggetti MIB,
L'SNMPv2 definisce sette tipi di messaggi, conosciuti genericamente come PDU (Protocol Data Unit) e vengono mostrati in tabella 2.
Tipo PDU SenderReceiver Descrizione
GetRequest ManagerAgent Riceve il valore di uno o più oggetti MIB in questione
GetNextRequest ManagerAgent Ottiene il valore del successivo oggetto MIB in questione nella lista o nella tabella
GetBulkRequest ManagerAgent Ottiene i valori di un grande blocco di dati, come una tabella
InformRequest ManagerManager informa l'entità di gestione dei valori MIB remoti per il suo accesso
SetRequest ManagerAgent Imposta il valore di uno o più oggetti MIB in questione. Response ManagerManager ManagerAgent Generato in risposta a: GetRequest,GetNextRequest, GetBulkRequest, SetRequest, InformRequest
SNMPv2Trap AgentManager Informa il manager di un evento eccezionale
Tabella 3: Tipi di PDU B.6 SNMPv3
I progettisti di SNMPv3 hanno detto che “SNMPv3 può essere pensato come un SNMPv2 con capacità di sicurezza e amministrazione[RFC2570]”. Infatti i cambiamenti più evidenti
riguardano riguardano proprio queste due aree. Il ruolo centrale della sicurezza era particolarmente importante nell'SNMPv3, perchè la mancanza di sicurezza adeguata faceva si che l'SNMP fosse usato soprattutto per il monitoraggio e raramente per il controllo (la funzione SerRequest è poco usata nell'SNMPv1). La sicurezza dell'SNMpv3 è nota come userbased security in cui c'è il tradizionale concetto dell'utente, identificato da un nome utente a cui sono associate le informazioni di sicurezza come una password, i valori chiave o gli accessi privilegiati. Sono implementati servizi di: ● cifratura: la PDU SNMP possono essere cifrate usando lo standard DES, ● autenticazione: si usano MD5 o SHA, ● protezione contro le repliche, ● controllo d'accesso .
Bibliografia
[1] Rosario G. Garroppo , Voice over IP (Voip) :aspetti architetturali e di progettazione, Didattica e ricerca, Manuali
[2] Angelo Taddeo, Prestazioni di un RTP proxy per servizi di Telefonia su IP basati sul protocollo SIP , Tesi di laurea specialistica in Ingegneria delle Telecomunicazioni
[3] J.Rosenberg et al., SIP: Session Initiation Protocol, IETF RFC 3261, Giugno 2002
[4] J. Rosenberg, G. Camarillo, Best Current Practices for NAT Traversal for SIP,SIPPING. Working Group InternetDraft