OFTP2 — ODETTE File Transfer Protocol 2

Le protocole de transport historique de l'industrie automobile européenne, porté sur TCP/IP en 2007 avec sécurité de bout en bout, reprise sur interruption et accusés signés. Spécifié par la RFC 5024 (Informational).

Qu'est-ce qu'OFTP2 ?

OFTP a été défini en 1986 par le groupe de travail n°4 d'ODETTE (Organisation for Data Exchange by Tele Transmission in Europe) pour répondre aux besoins d'échange EDI de l'industrie automobile européenne (RFC 5024 §1.1). Là où l'Internet FTP est interactif et sans accusé, OFTP est conçu dès l'origine comme un protocole peer-to-peer pour le transfert automatique de fichiers entre applications, avec accusé fonctionnel obligatoire.

OFTP 1.x vivait sur X.25 et ISDN. OFTP2 (2007) porte le protocole sur TCP/IP tout en restant rétrocompatible — la même grammaire de commandes encapsulée différemment au niveau réseau. Les principaux apports d'OFTP2 sur OFTP 1.4 sont : chiffrement et authentification de session via TLS, chiffrement et signature au niveau fichier via CMS, accusés signés (signed EERP), taille maximale portée à 9 Po, description étendue du fichier virtuel et codes d'erreur enrichis (RFC 5024 §1.2).

Modèle de fichiers virtuels

Toute information échangée entre deux entités OFTP2 transite sous forme de Virtual File (RFC 5024 §1.5). Un Virtual File est défini par un jeu d'attributs et le mapping vers le fichier local de chaque côté est laissé à l'implémentation. Les attributs principaux :

Dataset Name — identifiant logique du fichier, convenu bilatéralement. C'est l'attribut métier utilisé pour retrouver l'expédition côté applicatif.
Date stamp (CCYYMMDD) et Time stamp (HHMMSScccc) — qualifient l'instant où le fichier a été rendu disponible. Les attributs Date et Time forment, avec le Dataset Name, l'identité unique du Virtual File, qu'aucun intermédiaire n'a le droit de modifier (§1.5.2).
Record Format — quatre formats possibles : Fixed (records de même longueur), Variable (longueurs variables), Unstructured (flux d'octets), Text (séquence ASCII délimitée par CR-LF, lignes < 2048 caractères) (§1.5.3).
Restart position — position de reprise négociée à l'ouverture du transfert (§1.5.4).

Commandes et phases de session

OFTP2 est un protocole à états avec une grammaire fixe de commandes ASCII. Les principales (RFC 5024 §5.2) :

Commande	Sens	Rôle
`SSRM`	Speaker / Listener	Start Session Ready Message — annonce de disponibilité
`SSID`	Initiateur	Start Session — ID partenaire, mot de passe, capacités, mode (Speaker / Listener / Both)
`SFID`	Speaker	Start File — dataset name, date, taille, position de reprise
`SFPA` / `SFNA`	Listener	Start File Positive / Negative Answer — accepte ou refuse
`DATA`	Speaker	Data Exchange Buffer — bloc de données segmenté en sous-buffers
`CDT`	Listener	Set Credit — fenêtre de flux contrôlée par crédits
`EFID`	Speaker	End File — fin de fichier avec nombre de records
`EFPA` / `EFNA`	Listener	End File Positive / Negative Answer — fichier persistant
`ESID`	Initiateur	End Session — fin normale ou anormale
`EERP`	Listener (différé)	End-to-End Response — accusé applicatif, signé CMS optionnel
`NERP`	Listener (différé)	Negative End Response — refus applicatif, signé CMS optionnel

plaintext oftp2-session.txt

Émetteur (Speaker)              Récepteur (Listener)
─────────────────              ────────────────────
  TLS Handshake ───────────────────────►
                                        ◄──────── TLS Ready
  SSRM Start Session Ready Msg ────────►
       ◄──────── SSID Start Session (Id, Pwd, mode, restart)
  SSID Start Session ──────────────────►
       ◄──────── SFID Start File (dataset, date, size, restart=0)
  SFID Start File ─────────────────────►
       ◄──────── SFPA Start File Positive Ack (answer count)
  DATA blocks (CDT credits) ───────────►
       ◄──────── CDT  Set Credit
  ...
  EFID End File (record count) ────────►
       ◄──────── EFPA End File Positive Ack
  ESID End Session (normal) ───────────►
       ◄──────── ESID End Session Echo
  TCP close
                              (later, sometimes much later)
                                        ───► EERP End-to-End Response (signed CMS)
       ◄──────── EERP Echoed

plaintext oftp2-restart.txt

# Reprise après interruption — sur un fichier non terminé.
# Le récepteur a déjà reçu N octets et les a persistés ; il offre
# une reprise à l'octet 1024 * N (bloc de 1024 octets, §1.5.4).

Speaker                              Listener
SFID dataset=ORDERS_2026_0514          ───►
                                       ◄─── SFPA answercount=512   (offset 512 ko)
DATA reprise depuis l'offset 512 ko    ───►
...
EFID End File                          ───►
                                       ◄─── EFPA
ESID End Session                       ───►
                                       ◄─── ESID Echo
TCP close

Sécurité — TLS, X.509, signature CMS

OFTP2 fournit cinq services de sécurité (RFC 5024 §1.7) : confidentialité, intégrité, non-répudiation de réception, non-répudiation d'origine, authentification sécurisée. Ils sont implémentés à deux niveaux superposables :

Session — chiffrement TLS et authentification par certificat X.509 au niveau de la connexion TCP. La distinction entre trafic sécurisé et non sécurisé se fait par le port (§1.7, §2.3).
Fichier — chiffrement et signature CMS (Cryptographic Message Syntax, RFC 3852) appliqués au contenu du Virtual File lui-même. Le chiffrement fichier garde la donnée chiffrée hors session, ce qui permet aux intermédiaires (VAN, hubs) de relayer un fichier que seul le destinataire final saura déchiffrer (§1.7).

Les certificats nominaux sont des X.509 RSA, typiquement à 2048 bits, avec SHA-256. La cinématique d'enrôlement entre deux partenaires consiste à s'échanger leurs certificats publics hors-bande, puis à les déposer dans le profil partenaire de leur station OFTP2 — exactement comme pour AS2. Côté algorithmes recommandés, les guides Odette 2024 préconisent TLS 1.2 minimum (TLS 1.3 quand l'éditeur le supporte) et la suite AES-256-GCM pour le chiffrement fichier.

EERP, NERP — les accusés signés

OFTP2 distingue deux niveaux d'accusé. L'EFPA (End File Positive Answer) est un accusé de réception au niveau protocole — le Listener confirme qu'il a bien persisté le fichier. C'est un signal technique qui ferme la phase de transfert.

Le véritable accusé applicatif est l'EERP (End-to-End Response), émis plus tard par le destinataire métier après que son application a effectivement consommé le fichier. L'EERP transporte le Dataset Name, les date/time d'origine, et, dans OFTP2, peut être signé en CMS. Cet EERP signé fournit la non-répudiation de réception cryptographique demandée par les contrats automobiles. En cas de refus métier, le destinataire émet un NERP (Negative End Response, ajout d'OFTP 1.4 conservé dans OFTP2) également signable.

L'EERP/NERP n'est pas tenu d'arriver dans la session de transfert d'origine : il peut être routé plus tard, voire via un troisième nœud (réseau Odette multi-saut). C'est cette désynchronisation entre réception technique et accusé applicatif signé qui donne à OFTP2 sa résilience face aux coupures de session.

Ports et infrastructure

OFTP2 utilise deux ports TCP enregistrés à l'IANA (RFC 5024 §2.4) :

3305 / TCP — service odette-ftp, session en clair. À éviter en production sur Internet, encore acceptable en VPN ou MPLS.
6619 / TCP — service odette-ftps, session OFTP2 sur TLS. Port standard pour tout déploiement Internet moderne.

Au-delà du peer-to-peer, OFTP2 supporte le routage multi-saut (§3.3) où un fichier traverse une succession de boîtes aux lettres intermédiaires (hubs Odette, VAN sectoriels) avant d'atteindre son destinataire final. Cette topologie est typique des chaînes de sous-traitance automobile à trois ou quatre rangs.

L'industrie automobile européenne

OFTP2 est mainstream dans l'automobile européenne. Selon les informations publiques d'Odette, les constructeurs qui l'imposent à leur supply chain incluent Audi, BMW, Daimler/Mercedes-Benz, Ford Europe, Hyundai, MAN, Scania, Skoda, Stellantis (PSA + FCA), Volkswagen et Volvo, ainsi que « la plupart des Tier 1 » (Bosch, Continental, Valeo, ZF, Magna, Faurecia/Forvia, Schaeffler).

Les flux transportés sont essentiellement des messages EDIFACT au format Odette (un subset d'EDIFACT) ou VDA (le subset allemand). Les plus fréquents :

DELFOR — prévisions de livraison glissantes émises par le constructeur, sur un horizon de 6 à 12 mois.
DELJIT — appels de livraison synchrones, granularité horaire pour les lignes JIT/JIS, déclenchés par le séquencement de production.
DESADV — avis d'expédition, indispensable pour le Goods Received automatique côté constructeur.
INVOIC — facture, avec parfois auto-facturation (self-billing) côté constructeur.

Hors automobile européenne, OFTP2 est marginal : les autres secteurs ont basculé sur AS2 (distribution), AS4 (PEPPOL) ou ne sont jamais sortis de SFTP. Pour cette raison, un fournisseur EDI qui adresse l'automobile DOIT supporter OFTP2 ; ailleurs c'est dispensable.

Pièges opérationnels

Mode « Both » mal négocié. Le mode SSID négociable entre Sender-only, Receiver-only et Both peut tomber sur une asymétrie inattendue (§3.2.1 du RFC 5024) — le partenaire pensait être en Both, l'autre l'a négocié en Receiver-only. Les fichiers ne partent jamais. Toujours fixer le mode dans le profil partenaire.
Restart Position perdue après crash. Si l'agent OFTP2 ne persiste pas régulièrement l'offset reçu, un crash en milieu de transfert annule la reprise et oblige à retransmettre depuis zéro. Critique pour les fichiers DELFOR multi-Go.
EERP attendu mais jamais signé. Sur un partenaire legacy OFTP 1.4, l'EERP n'est pas signable. Si le contrat exige une NRR cryptographique, basculer sur OFTP2 ou doubler le canal d'accusé.
Confusion certificat session vs certificat fichier. Comme AS4, OFTP2 utilise deux certificats distincts : TLS pour la session et X.509 séparé pour la signature/chiffrement CMS au niveau fichier. Les confondre crée des incidents d'authentification où l'on croit que « tout est bon parce que la session passe ».
Routage multi-saut et NRR. Si le fichier passe par un hub, le NRR doit remonter de bout en bout. Vérifier que le hub retransmet bien l'EERP signé du destinataire final, et ne génère pas son propre EERP intermédiaire.

Sources officielles

RFC 5024 — ODETTE File Transfer Protocol 2 (novembre 2007) — le texte canonique (276 953 octets, archivé localement dans content/_sources/rfc/rfc5024_OFTP2.txt).
RFC 2204 — ODETTE File Transfer Protocol (1997) — le prédécesseur sur X.25 et ISDN, obsolète mais utile pour comprendre la grammaire.
Odette OFTP2 Experts Group — le mainteneur officiel du protocole, qui publie les guides d'implémentation et la liste des produits conformes.
RFC 3852 — Cryptographic Message Syntax (CMS) — la base cryptographique des chiffrement et signature fichier d'OFTP2.

Pour aller plus loin

Comparaison des cinq familles de protocoles — pour positionner OFTP2 face à AS2, AS4, SFTP et VAN.
AS2 — l'alternative dominante hors automobile européenne.
AS4 — le profil OASIS retenu pour PEPPOL et eDelivery.
EDIFACT DELFOR D.96A et DELJIT D.96A — les payloads typiques d'OFTP2 dans l'automobile.

Fondamentaux

Standards

Messages phares

Outils