Un brin de réseau — PPP vs DHCP (IPoX)

PPP vs DHCP (IPoX)

Cet article est comme une conclusion à la série d'articles sur PPP. J'ai souhaité l'écrire afin de donner une vision concrète et actuelle de PPP qui est de plus en plus remplacé par DHCP. Noter que je ne suis pas pro-PPP ni pro-DHCP. Si je devais choisir entre l'un ou l'autre, ce serait sans doute DHCP plus en vogue, qui permet de réduire les coûts matériels et qui permet tout autant de choses que PPP. Le fait est que PPP a introduit nombre de mécanismes imité dans les architectures IPoX—voilà pourquoi beaucoup de sections sont consacrées à PPP. La compréhension des architectures IPoX en découlent assez intuitivement.

PPP aujourd'hui

PPP est un protocole vieillissant, certes, mais bien actuel et qui a encore des années devant lui. Les « lignes séries » traditionnelles ayant tendance à disparaître au profit des VPN, PPP n'est plus vraiment utilisé sur ces lignes mais plutôt pour fournir des services L3 aux particuliers et aux professionnels. Sont entendus par services L3 : l'accès Internet, la VoIP et le L3VPN (pour les professionnels)—autrement dit, tout ce qui implique le transport de paquets IP. Les services L2 (L2VPN inter-sites ou L2VPN de collecte entre opérateurs) ne sont pas concernés par PPP qui encapsule de l'IP et non de l'Ethernet.

Dans quelle partie du réseau est utilisé PPP ?

PPP est utilisé entre les CPE (Customer-Premises Equipment)—une box pour un particulier, un routeur plus performant pour un professionnel—et le BAS (Broadband Access Server) de l'opérateur. Le rôle du BAS est d'agréger les accès des CPE en vue de leur fournir les services L3. Conceptuellement, cela se comprend très bien :


                             +-----+     +------------+
    [CPE]----- PPP link -----|     |     |            |-----[Internet]
    [CPE]----- PPP link -----| BAS |-----| NSP router |-----[VoIP]
    [CPE]----- PPP link -----|     |     |            |-----[L3VPN]
                             +-----+     +------------+
                                              NSP =
                                    Network Service Provider

En effet, ce schéma représente un enjeu assez intuitif : centraliser sur un même équipement—redondé à des fins de haute disponibilité—les accès distincts de plusieurs CPE. La gestion est ainsi facilitée : savoir qui est en ligne, depuis combien de temps, couper des accès si besoin, etc. L'idée de centralisation est rendue possible par le BAS. L'idée d'accès distincts est rendue possible par PPP : les liens PPP sont des liens logiques isolés établis sur un même réseau d'accès physique (comme si chaque client était raccordé directement au BAS via un câble dédié). Ils sont établis sur des réseaux d'accès généralement Ethernet aujourd'hui (via PPPoE) mais aussi ATM (via PPPoA ou PPPoEoA) ou IP (via L2TP).

Par « réseau d'accès IP » est entendue la partie LAC dans le cadre de l'architecture L2TP over UDP/IP (cf. la troisème partie sur PPP). Le réseau d'accès IP (réseau d'un opérateur tiers typiquement) comprend lui-même un réseau d'accès L2 (Ethernet ou ATM) avant la connectivité IP proprement dite avec le LNS.

Et après le BAS ?

PPP n'est plus. Le BAS représente la passerelle (la route par défaut) pour chaque CPE. Un paquet IP d'un client qui arrive au BAS, encapsulé dans le lien PPP correspondant, est extrait puis routé vers le routeur NSP. Le rôle de ce dernier est dédié à la livraison proprement dite des services L3—autrement dit, il possède les routes nécessaires vers Internet, les plateformes VoIP ou les sites distants pour du L3VPN. Dans le sens retour, le BAS devra retrouver le lien PPP associé (mécanisme non détaillé ici). Il est courant qu'un même équipement assure les deux fonctions BAS et NSP, comme il n'est pas rare que ce soient deux équipements dissociés (par exemple, dans le cas d'une interconnexion entre opérateurs). Entre le BAS et le NSP et au-delà du NSP, le réseau sous-jacent est souvent un backbone IP/MPLS sur lequel sont configurées des VRF (Virtual Routing and Forwarding) pour des questions de cloisonnement de trafic L3.

En image

Il est intéressant de constater que cette architecture avait été formalisée en 1999 dans la spécification TR-025 du Broadband Forum. Les termes Ethernet et MPLS n'y apparaissent pas encore mais les concepts restent valables, comme rappelé en début de document :


    This text does not
    assume ATM is the only transport technology, although ATM has been increasingly deployed in this
    infrastructure to provide broadband connectivity

Plus tard dans le document, deux architectures communes sont décrites même si les noms ne sont pas très répandus :

Il s'agit de l'architecture présentée plus haut avec les rôles de BAS et de NSP.

tr025-pta — De nos jours, PPP est configuré sur les CPE et non les équipements des utilisateurs finaux. Les CPE et le BAS sont connectés en L2 via Ethernet souvent ou ATM qui est encore bien actuel pour les accès cuivre non EFM (Ethernet in the First Mile) des particuliers et des professionnels. Avant le BAS, les CPE sont agrégés sur des switch Ethernet ou sur des DSLAM. Au-delà du BAS, PPP n'est plus et le routage du paquet IP continue pour fournir les services L3 via un backbone IP/MPLS (et non ATM ou Frame Relay, précurseurs de MPLS).

Il s'agit de l'architecture L2TP abordée dans la troisème partie sur PPP. Nous retrouvons les rôles de BAS et de NSP. Contrairement à ce que certains articles peuvent affirmer, le rôle de BAS n'est pas exclusivement assuré par le LAC ou le LNS. Il est réparti sur les deux équipements en ce que le LAC termine les sessions PPPoX et le LNS les liens PPP. Remarquer d'ailleurs que le terme BAS (Broadband Access Server) se retrouve à moitié dans LAC (L2TP Access Concentrator) et à moitié dans LNS (L2TP Network Server)—ce n'est pas par hasard.

tr025-laa — De même que l'architecture PTA, les CPE et le LAC sont connectés en L2 via Ethernet ou ATM. Entre le LAC et le LNS sont transportés les liens PPP dans un tunnel L2TP over UDP/IP en général (plus anciennement L2TP over ATM ou L2TPoA). Une fois sur le NSP, PPP n'est plus et le routage continue pour fournir les services L3.

Des liens PPP réellement isolés (spoofing attack) ?

Avant d'aborder DHCP, un aparté qui relève de la sécurité des communications. Considérer l'architecture suivante :


              +----------+     +-----+
    [CPE]-----| Ethernet |     |     |
    [CPE]-----|  access  |-----| BAS |.....
    [CPE]-----|  switch  |     |     |
              +----------+     +-----+

Il s'agit d'un schéma classique avec un réseau d'accès Ethernet. Aussi, des sessions PPPoE sont établies entre les CPE et le BAS, sessions dans lesquelles sont ensuite montés les liens PPP respectifs.

Non sans passer par le BAS. Chaque CPE est cloisonné dans son lien PPP : point de vue L3, un paquet IP est forcément routé vers le BAS (pour peu qu'il y ait la route adéquate sur les CPE) ; point de vue L2, la trame sous-jacente est forcément unicast en raison de l'utilisation de PPP (pas d'ARP ni de trame broadcast). Par la suite, le BAS, s'il a été configuré pour, pourra router le paquet vers un autre CPE—c'est comparable au routage inter-VLAN.

Cela est très peu probable mais possible. Comme rappelé dans la réponse précédente, toutes les trames véhiculant les liens PPP sont unicast. Deux cas sont à considérer :

Dans le sens montant (CPE → BAS). Si une trame d'un CPE arrive au switch d'accès et que ce dernier ne connaît plus l'adresse MAC du BAS, la trame du CPE sera diffusée sur tous les autres ports (et pourra donc être capturée avec du man-in-the-middle). Pour éviter ceci, la fonctionnalité de port isolation existe. Elle consistera ici à isoler les ports d'accès entre eux : une trame entrante sur un port d'accès ne sera ainsi jamais envoyée sur un autre port d'accès mais uniquement sur les ports non isolés (en l'occurrence, le seul port d'uplink vers le BAS).
Dans le sens descendant (CPE ← BAS). Le même problème se pose et le port isolation ne pourra ici pas le régler. En effet, si le port d'uplink et les ports d'accès sont isolés entre eux, il n'y a plus de communication du tout entre les CPE et le BAS. Le problème ne peut être qu'accepté. Toutefois, cela est très peu probable du fait des communications PPP permanentes entre les CPE et le BAS qui maintiennent les entrées adéquates dans la table MAC du switch. Ces communications permanentes incluent les keepalives PPP et le trafic client (Internet, par exemple).

Oui sans port isolation des ports d'accès. En réalité, toutes les trames ne sont pas unicast. Lors de l'établissement de la session PPPoE d'un CPE, la première trame transportant le PADI est broadcast. Sans port isolation, tous les autres CPE recevraient cette trame et un malveillant pourrait se faire passer pour le serveur PPPoE (le BAS) et ainsi intercepter toutes les autres trames du CPE en question—on parle d'ARP spoofing ou de PPPoE spoofing. Ce problème n'est pas si rare chez les opérateurs et souvent négligé à tort.

Je n'ai pas abordé le cas de PPPoA n'ayant pas assez pratiqué ATM. Toutefois, j'imagine que ces questions ne se posent pas avec ATM car, contrairement à Ethernet de nature multipoint, ATM peut être configuré en mode point-à-point nativement. Les liens PPP transportés se retrouvent ainsi réellement isolés. En ce qui concerne PPPoEoA, les mêmes questions se posent mais au-delà du DSLAM (là où ATM est désencapsulé et Ethernet de nouveau présent).

Migration vers DHCP

DHCP ou IPoX ?

PPP tend à être remplacé par DHCP, plus simple à l'implémentation, notamment pour les CPE—un CPE ne supportant que DHCP est en général moins onéreux qu'un CPE supportant PPP (en ce qui concerne les BAS, ils sont de toute façon assez onéreux et supportent donc souvent PPP). Après tout, PPP est surtout utilisé pour l'authentification des CPE et l'assignation d'adresses IP. Ce dernier point est le cœur même de DHCP qui permet en réalité aussi l'authentification en se basant sur l'adresse MAC des CPE ou via des options (option 60 ou 82). Parce que le BAS implémente ces mécanismes d'authentification en plus de la fonction de base DHCP, nous parlons d'accès IPoX et non simplement d'accès DHCP. Ici aussi, le Broadband Forum avait vu juste en 2001 déjà dans sa spécification TR-043 qui dresse les différentes stacks possibles sur les interfaces WAN des CPE :

tr043-stacks — Nous retrouvons les anciennes stacks PPPoA et PPPoEoA ainsi que les nouvelles IPoA et IPoEoA. Les stacks PPPoE et IPoE ne sont pas mentionnées directement mais sont bien valables et sont d'ailleurs les plus utilisés aujourd'hui. Laisser de côté L2TPoA non pertinent ici.

Le rapport entre IPoX et les architectures PPP

L'architecture LAA étant exclusivement liée à PPP, il n'y a pas de rapport avec IPoX. Néanmoins, IPoX est directement lié à l'architecture PTA. Comme mentionné précédemment, le concept est assez intuitif, à savoir centraliser les CPE sur un BAS via des liens d'accès distincts. L'idée est de reproduire ce schéma avec IPoX, comme illustré ci-dessous.


                              +-----+     +------------+
    [CPE]----- IPoX link -----|     |     |            |-----[Internet]
    [CPE]----- IPoX link -----| BAS |-----| NSP router |-----[VoIP]
    [CPE]----- IPoX link -----|     |     |            |-----[L3VPN]
                              +-----+     +------------+
                                              NSP =
                                    Network Service Provider

La centralisation des CPE n'est pas un problème pour le BAS qui sait jouer le rôle de serveur DHCP pour des milliers de CPE. En ce qui concerne la notion d'accès distincts, cela diffère de PPP.

Des liens IPoE isolés (spoofing attack) ?

Reprenons l'architecture utilisée plus haut avec un réseau d'accès Ethernet :


              +----------+     +-----+
    [CPE]-----| Ethernet |     |     |
    [CPE]-----|  access  |-----| BAS |.....
    [CPE]-----|  switch  |     |     |
              +----------+     +-----+

Oui et sans passer par le BAS (contrairement à PPP). Avec IPoE, les CPE (clients DHCP) se voient attribuer une adresse IP par le BAS (serveur DHCP) et sont tous dans le même subnet—1.0.0.0/24 par exemple. Si un CPE A tente de joindre un CPE B, une requête ARP sera envoyée via une trame broadcast. Si le CPE B existe, il répondra à cette requête ARP. Le port isolation des ports d'accès permet d'éviter ceci car la requête ARP sera alors uniquement forwardée vers le BAS. Si la connectivité IP entre CPE est souhaitée tout en ayant du port isolation (pour des questions de sécurité), le BAS doit être proxy ARP. Il répondra ainsi à toutes les requêtes ARP émises par les CPE. Par la suite, il pourra router les paquets entre CPE. Finalement, ceci reproduit le fonctionnement natif de PPP décrit plus haut.

Comme précédemment, deux cas sont à considérer :

Dans le sens montant (CPE → BAS). Si une trame broadcast d'un CPE arrive au switch d'accès (ou une trame unicast dont la destination n'est pas connue), la trame du CPE sera diffusée sur tous les autres ports (et pourra donc être capturée avec du man-in-the-middle). Pour éviter ceci, la fonctionnalité de port isolation existe. Elle consistera ici à isoler les ports d'accès entre eux : une trame entrante sur un port d'accès ne sera ainsi jamais envoyée sur un autre port d'accès mais uniquement sur les ports non isolés (en l'occurrence, le seul port d'uplink vers le BAS).
Dans le sens descendant (CPE ← BAS). Le même problème se pose et le port isolation ne pourra ici pas le régler. En effet, si le port d'uplink et les ports d'accès sont isolés entre eux, il n'y a plus de communication du tout entre les CPE et le BAS. Le problème ne peut être qu'accepté. Toutefois, cela est très peu probable du fait des communications permanentes entre les CPE et le BAS qui maintiennent les entrées adéquates dans la table MAC du switch. Ces communications permanentes incluent les probes ARP et le trafic client (Internet, par exemple).

Oui sans port isolation des ports d'accès. Lorsqu'un CPE recherche un serveur DHCP, la première trame transportant le DHCPDISCOVER est broadcast. Sans port isolation, tous les autres CPE recevraient cette trame et un malveillant pourrait se faire passer pour le serveur DHCP (le BAS) et ainsi intercepter toutes les autres trames du CPE en question—on parle d'ARP spoofing ou de DHCP spoofing. Ce problème n'est pas si rare chez les opérateurs et souvent négligé à tort.

Je n'ai pas abordé le cas de IPoA n'ayant pas assez pratiqué ATM. Se référer à l'explication donnée dans le cas PPP.

Comment gérer le cycle de vie des liens IPoX ?

Si PPP inclut nativement un mécanisme de keepalive permettant de tester l'état du lien, ce n'est pas le cas de DHCP. Avec PPP, et plus précisément avec les messages LCP, si le BAS ne reçoit plus de Echo-Reply suite à plusieurs Echo-Request consécutifs, ce dernier déduira que le lien PPP est down (même déduction côté CPE). Cela est très pratique pour réagir rapidement face à la perte de connectivité d'un CPE.

Avec DHCP, comment le BAS sait-il si un CPE est toujours en état après lui avoir attribué une adresse IP ? Il y a bien le lease DHCP mais cela n'est souvent pas autant réactif : il faut attendre l'expiration du lease et si ce dernier a été configuré avec inattention ou que le CPE n'a pas la même heure, l'attente peut être longue (plusieurs jours…). Pour pallier cela, le probing ARP (RFC 5227) peut être utilisé : le BAS envoie plusieurs requêtes ARP consécutives à un CPE donné et si ce dernier n'y répond pas, le BAS le considère down. Cependant, cela ne force pas le CPE à réémettre sa demande DHCP.