Résumé

  • La RFC 2516 sépare la découverte, sans état de session, de la session PPP point à point ; les deux extrémités n’allouent les ressources d’interface virtuelle qu’après son établissement.
  • L’AC-Cookie facultatif permettait au concentrateur de vérifier le retour d’une valeur vers l’adresse source. Host-Uniq et Relay-Session-Id assuraient d’autres corrélations, sous le contrôle de l’hôte et du relais.
  • Ces jetons transportent un contexte de paquet limité. Aucun n’authentifie une personne ni ne prouve une configuration PPP, un trafic ou un service commercial ultérieur.

Un broadcast sans table de sessions

En février 1999, la RFC 2516 décrivait comment transporter PPP sur un Ethernet partagé entre plusieurs hôtes et concentrateurs d’accès. L’hôte diffusait un PADI ; les concentrateurs capables de répondre pouvaient envoyer un PADO. L’hôte choisissait une offre, adressait un PADR au concentrateur retenu, puis recevait un PADS confirmant le service accepté et l’identifiant de session. La spécification distinguait Découverte et Session PPP : la première restait sans état de session jusqu’à ce que la seconde soit établie. À cette transition, hôte et concentrateur devaient tous deux allouer les ressources d’une interface PPP virtuelle.

Cette frontière évitait de convertir chaque sollicitation adressée à un réseau partagé en engagement durable. Le document ne prétend pas que le traitement du paquet ne consomme aucune ressource : il reporte l’allocation de l’état propre à une session tant que le pair n’est pas sélectionné et que la session n’existe pas.

Une valeur devait revenir

Le concentrateur pouvait ajouter un tag AC-Cookie facultatif au PADO. L’hôte devait le renvoyer sans modification dans son PADR, sans interpréter ses octets. La RFC recommandait que le concentrateur puisse le régénérer à partir de l’adresse source du PADR. Ce mécanisme pouvait vérifier que l’adresse ayant reçu l’offre était joignable en retour et aider à limiter le nombre de sessions simultanées pour cette adresse.

La RFC cite, à titre d’exemple, un HMAC calculé sur l’adresse MAC de l’hôte avec une clé connue du seul concentrateur. Ni cet algorithme ni une protection universelle ne sont imposés ; le texte précise que le cookie ne bloque pas toutes les attaques par déni de service. Il diffère un engagement en ressources, sans certifier la personne derrière une adresse.

Les autres tags ont leurs propres responsables. Host-Uniq, choisi par l’hôte, l’aide à rattacher une réponse à sa demande ; le concentrateur le renvoie sans l’interpréter. Relay-Session-Id, éventuellement ajouté par un relais intermédiaire, reste opaque aux deux extrémités et doit être réfléchi sans changement. La corrélation n’est pas une identité.

PADS change l’état des ressources

Un PADS accepté contient un identifiant non nul et le nom du service accepté ; un refus de service renvoie un identifiant nul et un tag d’erreur. Le protocole définit la session par le triplet adresse MAC source, adresse MAC destination et SESSION_ID, pas par ce dernier seul.

PADS ouvre l’étape Session PPP. Il ne remplace ni la négociation LCP, ni l’authentification facultative, ni la configuration par les protocoles de contrôle réseau décrites dans la RFC 1661. Cette étude ne reprend pas la limite de taille ni les 1492 octets traités dans le voisin RFC 4638 : elle porte sur l’allocation de ressources et la portée de tags distincts, pas sur la livraison du service.

La RFC atteste un choix de conception et ses limites déclarées ; elle ne mesure pas les économies de mémoire, ne prouve pas l’usage actuel ni l’achèvement d’une authentification ou d’un trafic donné.

Sources : RFC 2516 ; RFC 1661 ; RFC 2104 ; RFC 4638 (limite de taille voisine, exclue de cet article).