11. Considérations de sécurité
Il existe des risques importants à permettre à des clients arbitraires d'établir un tunnel permettant l'envoi vers des hôtes arbitraires, que les tunnels soient limités à des hôtes spécifiques ou non. Des acteurs malveillants pourraient abuser de cette capacité pour envoyer du trafic et le faire attribuer au proxy IP. Les serveurs HTTP qui prennent en charge le proxy IP DEVRAIENT restreindre son utilisation aux utilisateurs authentifiés. Selon le déploiement, les mécanismes d'authentification possibles incluent le TLS mutuel entre les points de terminaison de proxy IP, l'authentification basée sur HTTP via l'en-tête HTTP Authorization [HTTP], ou même des jetons porteurs (bearer tokens). Les proxys peuvent appliquer des politiques pour les utilisateurs authentifiés afin de contraindre davantage le comportement du client ou de faire face à d'éventuels abus. Par exemple, les proxys peuvent limiter le débit des clients individuels qui envoient une quantité excessive de trafic via le proxy. Autre exemple, les proxys peuvent restreindre l'attribution d'adresses (préfixes) aux clients en fonction de certains attributs du client, tels que la situation géographique.
L'attribution d'adresses peut avoir des implications sur la confidentialité des points de terminaison. Par exemple, si un proxy partitionne son espace d'adressage en fonction du nombre de clients authentifiés, puis attribue des plages d'adresses distinctes à chaque client, les hôtes cibles pourraient utiliser ces informations pour déterminer quand les paquets IP correspondent au même client. Éviter de tels vecteurs de suivi peut être important pour certains déploiements de proxy. Les proxys DEVRAIENT éviter l'attribution persistante d'adresses (préfixes) par client lorsque cela est possible.
La falsification des adresses source IP dans le trafic envoyé a été courante pour les attaques par déni de service. Les implémentations de ce mécanisme doivent s'assurer qu'elles ne facilitent pas de telles attaques. En particulier, il existe des scénarios où un point de terminaison sait que son pair n'est autorisé à envoyer des paquets IP qu'à partir d'un préfixe donné. Par exemple, cela peut se produire via des informations de configuration hors bande ou lorsque les préfixes autorisés sont partagés via des capsules ADDRESS_ASSIGN. Dans de tels scénarios, les points de terminaison DOIVENT suivre les recommandations de [BCP38] pour empêcher l'usurpation d'adresse source.
La limitation de la portée de la requête (voir la section 4.6) permet à deux clients de partager l'une des adresses IP externes du proxy si leurs requêtes sont limitées à différents numéros de protocole Internet. Si le proxy reçoit un paquet ICMP destiné à cette adresse IP externe, il a la possibilité de le renvoyer aux clients. Cependant, certains de ces paquets ICMP transportent une partie du paquet IP d'origine qui a déclenché la réponse ICMP. Le transfert de tels paquets peut accidentellement divulguer des informations sur le trafic d'un client à un autre client. Pour éviter cela, les proxys qui transfèrent ICMP sur des adresses IP externes partagées DOIVENT inspecter le paquet invoquant inclus dans le paquet ICMP et transférer uniquement le paquet ICMP au client dont la portée correspond au paquet invoquant.
Les responsables de la mise en œuvre bénéficieront de la lecture des conseils de [TUNNEL-SECURITY]. Comme il existe des risques connus avec certains en-têtes d'extension IPv6 (par exemple, [ROUTING-HDR]), les responsables de la mise en œuvre doivent suivre les dernières directives concernant la gestion des en-têtes d'extension IPv6.
Le transfert des marquages DSCP des paquets internes vers les paquets externes (voir la section 10.3) expose les informations de niveau de flux de bout en bout à un observateur sur le chemin entre les points de terminaison de proxy IP. Cela peut potentiellement exposer un seul flux de bout en bout. Pour cette raison, une telle utilisation des DSCP dans des contextes sensibles à la confidentialité est NON RECOMMANDÉE.
L'envoi opportuniste de paquets IP (voir la section 7.1) n'est pas autorisé dans HTTP/1.x car un serveur pourrait rejeter la mise à niveau HTTP et tenter d'analyser les paquets IP comme une requête HTTP ultérieure, permettant des attaques de contrebande de requêtes (request smuggling) ; voir [OPTIMISTIC]. En particulier, un intermédiaire qui réencode une requête de HTTP/2 ou 3 vers HTTP/1.1 NE DOIT PAS transférer les capsules reçues tant qu'il n'a pas analysé une réponse de proxy IP réussie.