Sécurité du PCE
Path Computation Element - Rendre le réseau IP WAN programmable
TE7615 v1 Article de référence

Sécurité du PCE
Path Computation Element - Rendre le réseau IP WAN programmable

Auteur(s) : Stéphane LITKOWSKI

Date de publication : 10 nov. 2018 | Read in English

Logo Techniques de l'Ingenieur Cet article est réservé aux abonnés
Pour explorer cet article plus en profondeur Consulter l'extrait gratuit

Déjà abonné ?

Présentation

1 - D’un routage au mieux à l’ingénierie de trafic

2 - Ingénierie de trafic distribuée

3 - Le PCE pour une ingénierie de trafic centralisée

4 - Bases du protocole PCEP

5 - Acquisition topologique

6 - Gestion du multi-domaines ou multi-aires

7 - Besoin d’un PCE à gestion d’état

8 - Gestion de la redondance

9 - PCE dans les réseaux de transmission

  • 9.1 - GMPLS et PCE dans les réseaux de transmission
  • 9.2 - Dialogue IP – transmission : PCE multicouches ou multiples PCE

10 - Exemple de configuration d’un PCC

  • 10.1 - Configuration sur routeur Juniper
  • 10.2 - Configuration sur routeur Cisco IOS

11 - Pilotage du trafic

12 - Approche SDN avec le PCE

13 - Passage à l’échelle de l’architecture PCE

14 - Sécurité du PCE

  • 14.1 - Sécurité protocolaire
  • 14.2 - Sécurité vis-à-vis des PCC
  • 14.3 - Sécurité vis-à-vis des utilisateurs
  • 14.4 - Sécurité vis-à-vis des applications externes

15 - Mise en œuvre d’un PCE

16 - Produits du marché

  • 16.1 - Juniper Northstar
  • 16.2 - Nokia NSP
  • 16.3 - Cisco WAE
  • 16.4 - Cisco XTC
  • 16.5 - Opendaylight

17 - Conclusion

18 - Glossaire

Sommaire

Présentation

RÉSUMÉ

Historiquement basé sur un routage best-effort, les réseaux IPs ont dû évoluer pour supporter les contraintes de plus en plus importantes des applications. L’ingénierie de trafic distribuée est un outil fréquemment utilisé pour mettre en place un routage contraint. Cependant celle-ci ne permet pas de résoudre tous les problèmes d’optimisation. Une ingénierie de trafic centralisée utilisant un PCE (Path Computation Element) est alors nécessaire pour surmonter ces limitations et rendre le réseau programmable.

Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.

Lire l’article

Auteur(s)

INTRODUCTION

La mouvance vers le tout IP entraîne un portage d’applications de plus en plus critiques sur les réseaux IP. Les contraintes de ces applications en termes de bande passante, latence, gigue, etc. peuvent nécessiter la mise en œuvre d’une politique de routage différenciée dans le réseau là où le réseau IP utilise par défaut une politique unique de « plus court » chemin. La mise en œuvre de technique d’ingénierie de trafic à base de MPLS (Multi Protocol Label Switching) est souvent nécessaire afin d’ouvrir la possibilité de calcul de chemins contraints.

L’ingénierie de trafic n’est pas un nouveau concept en soit et était déjà utilisée dans des réseaux comme les réseaux ATM (Asynchronous Transfer Mode). Elle est également déployée de manière plus ou moins large au sein de réseaux IP afin d’adresser ce besoin de différentiation de routage pour différents types de trafic.

Dans cet article, nous allons rappeler dans un premier temps les concepts de base de l’ingénierie de trafic dans un réseau IP/MPLS, pour nous attarder ensuite sur les limitations de l’approche distribuée qui est actuellement déployée. Dans un second temps, cet article introduit l’architecture d’ingénierie de trafic centralisée utilisant un PCE (Path Computation Element) permettant de pallier ces limitations. Le fonctionnement du protocole de communication utilisé par le PCE est détaillé, ainsi que la mise en œuvre d’une architecture de routage utilisant un PCE. Cet article présente également l’analyse de plusieurs cas d’usage du PCE.

Nous abordons enfin les aspects sécurité liés à l’introduction du PCE et nous terminons par une vue non exhaustive du marché actuel.

Logo Techniques de l'Ingenieur

Cet article est réservé aux abonnés.
Il vous reste 93 % à découvrir.

Pour explorer cet article Consulter l'extrait gratuit

Déjà abonné ?


DOI (Digital Object Identifier)

https://doi.org/10.51257/a-v1-te7615

Lecture en cours
Présentation

Article inclus dans l'offre

"Réseaux Télécommunications"

(140 articles)

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques.

Des contenus enrichis

Quiz, médias, tableaux, formules, vidéos, etc.

Des modules pratiques

Opérationnels et didactiques, pour garantir l'acquisition des compétences transverses.

Des avantages inclus

Un ensemble de services exclusifs en complément des ressources.

Voir l'offre

14. Sécurité du PCE

Le PCE est un élément central du réseau. Le fait que le PCE puisse influer sur l’ensemble du routage du réseau rend nécessaire d’analyser sa sécurité.

En effet, si une personne malveillante accède au PCE, celle-ci pourra prendre le contrôle de tout ou partie du routage du réseau.

14.1 Sécurité protocolaire

Il est impératif de contrôler quel PCC se connecte au PCE. Des mécanismes de filtrage type liste d’accès ou pare-feu sont nécessaires afin d’identifier les plans d’adressage autorisés à se connecter au PCE.

Il est également impératif de s’assurer qu’un intrus ne se fasse pas passer pour un PCC existant. Des mécanismes d’authentification comme les fonctions de hashage peuvent être mis en place sur la session PCEP avec un secret partagé (SHA256, etc.), l’utilisation de TLS (Transport Layer Security défini dans la RFC 5246) est également possible via la RFC 8253 (on parle alors de PCEPS).

HAUT DE PAGE

14.2 Sécurité vis-à-vis des PCC

Même si, d’un point de vue protocolaire, les échanges entre le PCC et le PCE sont sécurisés, il se peut qu’un PCC soit corrompu et puisse nuire à la santé du PCE. Ainsi, il peut exister dans les PCE des mécanismes permettant de limiter le nombre d’état (de LSP) qu’un PCC peut envoyer ou déléguer. Il peut être aussi envisagé de limiter le nombre de requêtes de calcul sur une période donnée afin de garantir une bonne santé au PCE. Ces mécanismes de protection du PCE sont souvent dépendants de l’implémentation de l’industriel.

HAUT DE PAGE

14.3 Sécurité vis-à-vis des utilisateurs

Le PCE dispose d’une interface homme-machine. Il est important de limiter les droits des utilisateurs afin que seuls les personnes habilitées puissent effectuer des modifications. L’établissement de profils et groupes d’utilisateurs peut s’avérer nécessaire pour laisser la possibilité de certains...

Logo Techniques de l'Ingenieur

Cet article est réservé aux abonnés.
Il vous reste 95 % à découvrir.

Pour explorer cet article Consulter l'extrait gratuit

Déjà abonné ?


Lecture en cours
Sécurité du PCE

Article inclus dans l'offre

"Réseaux Télécommunications"

(140 articles)

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques.

Des contenus enrichis

Quiz, médias, tableaux, formules, vidéos, etc.

Des modules pratiques

Opérationnels et didactiques, pour garantir l'acquisition des compétences transverses.

Des avantages inclus

Un ensemble de services exclusifs en complément des ressources.

Voir l'offre

Sommaire
Sommaire

BIBLIOGRAPHIE

  • (1) - IETF – PCEP -   Extension for Distribution of Link-State and TE Information.  -  https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ (2018).

  • (2) - IETF – PCEP -   Extensions for GMPLS.  -  https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-pcep-extensions/ (2017).

  • (3) - IETF -   Path Computation Element communication Protocol extension for associating Policies and LSPs.  -  https://datatracker.ietf.org/doc/draft-ietf-pce-association-policy/ (2018).

  • (4) - IETF -   Path Computation Element communication Protocol extension for signaling LSP diversity constraint.  -  https://datatracker.ietf.org/doc/draft-ietf-pce-association-diversity/ (2018).

  • (5) - IETF – PCEP -   Extensions for Establishing Relationships Between Sets of LSPs.  -  https://datatracker.ietf.org/doc/draft-ietf-pce-association-group/ (2018).

NORMES

  • RSVP-TE : Extensions to RSVP for LSP Tunnels. - RFC 3209 - 2001

  • Traffic Engineering (TE) Extensions to OSPF Version 2. - RFC 3630 - 2003

  • The Transport Layer Security Protocol Version 1.2. - RFC 5246 - 2008

  • IS-IS Extensions for Traffic Engineering. - RFC 5305 - 2008

  • Traffic Engineering Extensions to OSPF Version 3. - RFC 5329 - 2008

  • Path Computation Element Communication Protocol. - RFC 5440 - 2009

  • A Backward-Recursive PCE-Based Computation Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths. - RFC 5441 - 2009

  • The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS. - RFC 6805 - 2012

  • ...

Logo Techniques de l'Ingenieur

Cet article est réservé aux abonnés.
Il vous reste 93 % à découvrir.

Pour explorer cet article Consulter l'extrait gratuit

Déjà abonné ?


Article inclus dans l'offre

"Réseaux Télécommunications"

(140 articles)

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques.

Des contenus enrichis

Quiz, médias, tableaux, formules, vidéos, etc.

Des modules pratiques

Opérationnels et didactiques, pour garantir l'acquisition des compétences transverses.

Des avantages inclus

Un ensemble de services exclusifs en complément des ressources.

Voir l'offre

Ressources documentaires

Software-Defined Network - Principes, architectures et mise en œuvre – partie 1

Les réseaux, IP bien qu’initialement sans garantie, ont été amenés à supporter de plus en plus de ...

Software-Defined Network - Principes, architectures et mise en œuvre – partie 2

Les réseaux IP, qui initialement étaient sans garantie, supportent plus de services à valeur ajoutée ...

Analyse de solutions opérationnelles d'applications DDS sur réseaux distants

Stimulées par la croissance de leur utilisation, tant dans le domaine militaire que dans le domaine ...