Solution
de la RFC 3581
Le client a besoin de connaître l’adresse IP
et numéro de port que le routeur NAT lui a attribué
pour établir une communication. La RFC 3581 propose
d’insérer un nouveau paramètre au sommet
du champ en-tête Via. Ce paramètre est nommé
rport.
Dans le cas ou le client qui est soit un UAC ou un Proxy,
souhaite établir une connexion, va envoyer une requête
sur le protocole UDP à un serveur. Cette requête
contient dans le champ Via le paramètre "rport"
avec une valeur nulle pour déclarer que ce paramètre
est nécessaire pour la transaction. Le fait d'utiliser
le protocole UDP indique que le client est disposé
à recevoir la réponse sur l'adresse IP et
numéro de port source et le numéro de port
du paramètre "sent-by" de Via.
Le serveur va recevoir cette requête et l'analyser.
Il détecte le paramètre rport dans le champ
Via sans aucune valeur. Le fait que "rport" soit
vide, indique au serveur qu'il doit ajuter le numéro
de port source de la requête. Il doit également
ajouter l'adresse IP dans le paramètre "received".
Pour l'envoi de la réponse sur le protocole UDP,
le serveur va insérer l'adresse IP dans le paramètre
"received" et le numéro de port dans le
paramètre "rport". La réponse est
envoyée sur l'adresse IP et nu
Les serveurs écoutant sur plusieurs ports, ils doivent
se souvenir sur quel port a eu lieu la réception
de la requête. Tandis qu'un Proxy plein état
ce qui signifie qu'il mémorise la transaction n'aura
pas de difficulté à insérer le numéro
de port, un Proxy sans état, c'est à dire
qu'il ne sauvegarde pas la transaction va chiffrer, l'adresse
et le numéro de port de la destination. Une fois
la réponse parvenue, le Proxy va utiliser cette information
pour transmettre la réponse.
Syntaxe
La syntaxe suivante est celle de la RFC 3581 qui est utilisée
en incluant le paramètre rport pour récupérer
le numéro de port assigné par le routeur NAT.
reponse-port = « rport » [ÉGAL à
1*DIGIT]
BNF :
via-params = via-ttl / via-maddr
/ via-received / via-branch
/ response-port / via-extension
Beaucoup de paramètres sont utilisés dans
les différents champs du protocole SIP. Ci-dessous
sont présentés les paramètres de la
syntaxe de la RFC 3581 qui sont insérés dans
le champ via (Le champ via permet de "mapper"
le chemin de la requête).
via-params = via-ttl / via-maddr / via-received / via-branch
/ via-extension
via-ttl : correspond à ttl Time To Live qui détermine
la durée d'un paquet transmis dans le réseau.
via-maddr : correspond à Host (Hôte) qui
est un serveur sur lequel l'utilisateur se connecte pour
accéder au reste d'un réseau.
via-received : correspond à l'adresse IP reçue
en V4 ou V6.
via-branch : au numéro de la transaction
via-extension : correspond au paramètre générique
Sécurité
Dans le cadre d’une solution VoIP, bien des éléments
peuvent être attaqués : le téléphone,
le réseau, le système d’exploitation,
l’application, etc…
Un nombre trop important de message SIP INVITE peut créer
une situation de service non rendu. En effet, cela ouvre
la possibilité à des intrusions et à
des interceptions de communications par l’intermédiaire
du réseau de données.
Les techniques bien connues d’écoute de réseau
tel que l’homme du milieu «man in the middle»
(MITM) s’appliquent à l’interception.
La seule solution pour limiter l’interception est
l’usage de mécanismes cryptographiques pour
les flux de signalisation et de données (voix encodées).
Les informations reçues et retransmises par le serveur
Proxy se trouvent être des informations sensibles.
En effet, les requêtes et les réponses incluent
dans les champs «via» comportent les informations
telles que l’adresse IP et le port source. Cette vulnérabilité
entraîne la mise en place d’une solution pour
sécuriser les communications VoIP à savoir
SIP over TLS sur TCP. Dans le cas de fonctionnement particulier
de la RFC 3581, aucune fonction de cheminement de réponse
n’est assurée sur TCP. Seul les informations
sur le port source sont fournit comme vu précédemment
au niveau du serveur Proxy avec la valorisation du paramètre
«rport». Il est possible qu'un hacker puisse
essayer de perturber le service pour un client SIP en agissant
en tant que MITM, modifiant le paramètre de «rport»
dans l’en-tête «via» dans une requête
envoyée par un client. La modification de ce paramètre
empêchera des clients derrière un routeur NAT
de recevoir l’appel.
