OFTP

The Odette File Transfer Protocol (RFC 2204) currently provides a standard communications base for sending and receiving EDI messages throughout Europe and most of the world. Whilst being designed with the automotive industry sector in mind, it has been adopted by a wealth of industry sectors including retail, white goods, manufacturing, government, transport, insurance, banking and both chemical and petrochemical industries to name but a few.

Today, it also provides the common element for the large number of VANs available. In particular it is supported by DINET, Easylink (previously AT&T), GXS (previously GEIS), Tradanet, IBM IE, BT EDI*Net, Inovis/OCS, Azertia (previously Teleinformatica), EDIServ and Telefónica.

This section provides the background to this universally accepted communications standard, as well as defining the enhancements and future of the protocol.

The OFTP Protocol

The OFTP is a high level protocol, applied to the way in which files and messages are sent. It is not involved in defining the physical communications channel across which they travel.

The OFTP allows for the transfer of several different types of file. They may be either ASCII (or EBCDIC) or binary files. In addition they may be formatted with fixed length records, variable length records, unformatted or text format.

Benefits of OFTP

  • The OFTP is an extremely simple protocol that consists of just fourteen commands.
  • The OFTP is extremely efficient, allowing large transmission windows to be utilised whilst incorporating file restart, data compression and security.
  • The routing capability allows messages to travel via a number of third party intermediaries e.g. VANs.
  • OFTP can happily support multiple communications sessions within or across international boundaries.
  • OFTP has been designed to allow companies to communicate directly with one another, or via a third party as in the popular use of VANs.
  • OFTP removes any need for knowledge about the remote user’s computer system.

OFTP Commands

The following is a list of all the OFTP commands used in OFTP 1.4. The two commands highlighted in red (SFNA and EFNA) indicate problems in the exchange of data.

SSRM Start Session Ready Message The first command to be sent after a session has been physically made. It indicates to the person who initiated the session that he is communicating with another OFTP capable machine.
SSID Start Session IDentification Contains User ID/Password information to identify the session partner, together with indication of session capabilities. These capabilities are in the form of session negotiation information that allows the partners to request / accept /deny the use of special logic, compression and restart.
SFID Start File IDentification A request to send a file. It contains such information as the destination code for the file, the file name and file size.
SFPA Start File Positive Acknowledge This command is returned in response to an SFID and it gives the confirmation that the file may be sent.
SFNA Start File Negative Acknowledge This command is returned in response to an SFID and it refuses permission to send a file. The SFNA command should indicate whether origin or destination of the file is unrecognised.
DATA The actual file data
CDT CreDiT Sent in response to a number of data blocks. This depends on the OFTP window size which defaults to 7. This means that 7 data blocks are sent before a CDT is sent in response. If the window size is too low, the machine sending data has to wait excessively for CDTs. Too high and there will be problems.
EFID End of File IDentification This command is sent after file data transfer has completed for an individual file to indicate the End of File condition. It also contains control totals to ensure the integrity of the sent file.
EFPA End of File Positive Acknowledge Sent in response to an EFID to indicate successful receipt of a file.
EFNA End of File Negative Acknowledge Sent in response to an EFID to indicate unsuccessful receipt of a file. Corrective actions will be taken. This usually occurs when the two systems cannot agree on the status of the file (usually after restarting).
EERP End to End ResPonse An EERP command is sent when a file reaches its ultimate destination. This is sent to the originator of the file to tell them that the file has been received.
RTR Ready To Receive This command is sent in response to an EERP. It just passes control of the session back to the sender of the EERP (in case they have anything else to send).
CD Change Direction Sent when no more files or EERPs are available to be sent to the trading partner. It assigns control of the session to the trading partner who may then send files or EERPs etc. If the recipient of the CD also has nothing to send, then they will issue an ESID.
ESID End of Session IDentification Requests that the session be terminated and disconnected.An error code is also generated. 00 indicates that the session ended successfully. Anything other error code may indicate that both systems did not send all of their files.

An OFTP Session

The following example demonstrates a very simple OFTP session, using arrows to indicate the direction of the command flow.

An OFTP session in progress
  • Company A makes a call out to Company B.
  • Company B responds with an SSRM stating that they are ready to start using the OFTP protocol.
  • The companies then swap SSID commands. (This is the equivalent of telling each other their identity).
  • Company A then sends an SFID stating that they have a file to send.
  • Company B responds with an SFPA stating that they are willing to accept that file.
  • Company A proceeds to send the data.
  • After 4 data blocks, Company B sends back a CDT. (This is the equivalent of making a small response to indicate you are still on the line).
  • At the end of the file, Company A sends an EFID to state that this is the end of the file.
  • Company B then sends back an EFPA stating that the file was successfully received.
  • Company A has no more files to send, so now gives Company B the opportunity to send their files, by sending a CD (Change Direction command).
  • The process then starts again (there is no need to sign on again with the SSRM and SSIDs), and Company A receives a file from Company B.
  • At the end of the file, they change direction again with a CD command.
  • Company A acknowledges the file by sending an EERP.
  • Company B acknowledges the receipt of the EERP by sending the RTR.
  • Company A has nothing more to say so passes control to Company B.
  • Company B also has nothing to say and so sends an ESID, on receipt of which Company A hangs up the line.

Advantages of OFTP

Some form of standardisation is required for the lower levels of communication carried out between the computer systems and network facilities used by different trading partners. The reason is that many companies communicating across a network have widely differing computer hardware platforms.

A single dedicated conversion between one system and another is fine while there are only two systems trying to communicate. When there are interconnections between several companies, things get more complicated.

A company which connects with several trading partners will need to set up appropriate conversion facilities for each of them if they all have different computer systems.

This problem can be reduced if the companies involved use a communications method that shares a common standard, and therein lies the advantage of the OFTP to users who support direct connections.

In addition, it has advantages for the VAN providers as it simplifies the networking aspects of their services. However, it also allows customers to sign onto new networks without having to change their hardware and software.

OFTP Authentication (EDI Codes)

The term “EDI code” should be used carefully as it could cover one (or more) of the 3 codes used in OFTP to identify a given party.

SSID Code/Network Node

The SSID code is sent to a trading partner at the start of an OFTP communication session. It informs them who the sender is, as a company. The SSID command includes the SSID code and also an OFTP password. The recipient then sends back their SSID code and OFTP password in another SSID command. Either party can terminate the session if they do not recognise the contents of an SSID command.

SFID Code/File Node

Once the session is established, an SFID command is sent. This is a request for permission to send a file. It includes the SFID code of the origin and the destination. In the most simple case the SFID code will be the same as the SSID code, but if a company has multiple entities, they may have a different SFID for each entity within the company. The recipient of the SFID can then either accept the file (send back an SFPA command), or reject it (send back an SFNA command) if they do not recognise the origin or destination.

Message Level EDI Code/Message Node

Inside each EDI message is yet another EDI Code. The first record in each EDI message contains the origin and destination of the message. Depending on the format of the file this could be referred to as something else, such as ANA number for ANSI X12, or UNB code for EDIFACT/ODETTE. Again, this often refers to an entity within an organisation, although it could be the same as the SFID code, if a company has a different SFID code for each entity.

OFTP Security

The latest step in the evolution of the OFTP protocol entails the addition of full security.

In theory, any method of communication is open to the threat of infiltration, either by amateurs or professionals. Even ISDN lines can be tapped if a determined party obtains the necessary information to do so.

However, it is the increasing use of TCP/IP communications that has led to the demand for a means of maintaining the security of the data being exchanged. In particular, the automotive industry requires that ENGDAT data, containing highly sensitive design documents, should be exchanged in a totally secure manner.

OFTP in its original form offered no real security. User IDs and passwords were utilised but, although useful for identification purposes, were human-readable and thus open to possible manipulation.

To overcome this failing, the existing OFTP protocol has been reviewed and extended to rise to this security challenge, resulting in the release of OFTP version 1.5. A handful of minor programmatic changes have been made, including the addition of the following:

  • Authentication protocol data units
  • File encryption data unit header
  • Some additional ESID header codes
  • New version level in the SSID

New sign-on commands

There has also been an extension to the existing OFTP sign-on commands with several new challenge/response data units, as shown below.

An OFTP session showing the challenge response mechanism

These new OFTP commands cover the exchange of extra introductory details. If either party wishes to end the session because they are not satisfied with the contents of any of these commands, they will use the ESID command to do so.

SECD Security Change Direction Contains a single character “N”, to indicate this is an SECD command.
AUCH Authentication Challenge Contains a single character “A”, to indicate this is an AUCH command, and a 16 digit random number uniquely generated each time an AUCH is sent.
AURP Authentication Response Contains a single character “S”, to indicate this is an AURP command, and a variable length field that is the challenge from the AUCH signed with the private key of the sender of the AURP and encoded into a CMS/PKCS #7 message.

The requestor of the session sends Security Change Direction (SECD) to which the responder replies with an Authentication Challenge (AUCH). The AUCH contains a randomly generated 16-byte number so that it is unique each time. Using his private key, the requestor returns the signed challenge in an Authentication Response (AURP). Using the requestor's public key, the responder verifies the requestor's identity and replies with an Security Change Direction (SECD), beginning the complementary process of verifying the responder to the requestor.

PKI security

OFTP security makes full use of the encryption technologies provided by PKI security to meet the security objectives of:

  • Authentication – the process of proving one’s identity
  • Confidentiality – ensuring that nobody can read the message except for the intended recipient
  • Integrity – assuring the recipient that the received message has not been altered in any way from the original
  • Non-Repudiation – a mechanism to prove that the sender/recipient really sent/received a message

Session Authentication is achieved during the process of exchanging the OFTP security challenges and responses. Each partner takes it in turn to send a piece of plain text (a human-readable 16-byte random number) to their partner.

This is then signed by their partner’s private key and returned to the sender, where the original sender then decrypts it using their partner’s public key.

If the plain text is identical to that sent originally, the originator can be confident that their partner is who they claim to be.

If either partner is not satisfied about the identity of the other, they will end the session by sending an ESID command containing a code 16 to indicate that session authentication failed (code 16 indicates that an incorrect challenge was received).

Authentication of file origin is ensured by use of a digital signature.

Encryption of the file ensures Confidentiality is achieved.

Integrity is ensured via the use of a message digest and a signature.

Non-Repudiation is achieved via the signing and encryption of the EERP that is returned to the sender to indicate receipt of the file.

Security levels

There are 2 different levels of security – Session security and File security – and it is possible to implement one without the other.

Session security, which will only be available for TCP/IP communications, is achieved using SSL (Secure Socket Layer). SSL is the most common form of Internet security and is used in particular for HTTPS transactions over the Internet.

File security involves the encryption of the file itself, as described in the section on PKI security.

To avoid the use of smart cards and HSMs, private key certificates will be held on the user’s machine in a certificate store.

OFTP support in DI products

All Data Interchange communications products provide OFTP support. OFTP security is currently available in ODEX Enterprise.