The PPP Encryption Control Protocol (ECP)
Extracted elements (28)
Compression is applied before encryption because this produces smaller ciphertext output and provides more secure encryption (compressing ciphertext is ineffective, so the order also resists certain attacks).
Unlike most LCP/NCP option negotiation that may accept multiple simultaneous options, ECP negotiation is intentionally designed to converge on exactly one encryption algorithm per direction, ensuring clarity about which algorithm is in use.
Vendors wishing to use proprietary encryption may use the OUI mechanism (option type 0) to negotiate without requesting an IANA-assigned option number. OUI is derived from the vendor's IEEE 802 Ethernet address.
The receiver MAY limit transmission of Reset-Requests (e.g., to one per second) while a Reset-Ack is outstanding, to avoid flooding with redundant requests when the link is busy and errors cascade.
All compliant ECP implementations SHOULD implement ECP option 1, the PPP DES Encryption Protocol (DESE).
An implementation MUST NOT transmit data until ECP negotiation has completed successfully. If ECP negotiation is not successful, the link SHOULD be brought down.
An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response during ECP negotiation.
If the Encrypter Configure-Rejects all offered ECP options and the Decrypter has no further options to offer, the Encrypter SHOULD take the link down.
If the Encrypter does not recognise or is unwilling to support an offered option, it MUST send a Configure-Reject for that option. Where multiple options are offered, the Encrypter SHOULD Configure-Reject all but a single preferred option.
If the Encrypter recognises an option but it is unacceptable due to parameter values, it MUST send a Configure-Nak with the option modified appropriately, and the Nak MUST contain only those options that will be acceptable.
On initial detection of a decryption failure, an ECP implementation SHOULD transmit an ECP packet with Code field set to 14 (Reset-Request). Once sent, encrypted packets received are discarded until a valid Reset-Ack is received.
On receipt of a Reset-Ack, the decrypter MUST be reset for each Reset-Ack that matches the currently expected identifier, since multiple Reset-Acks may be in flight.
The Identifier field in Reset-Request/Reset-Ack MUST be changed whenever the Data field content changes or a valid reply has been received. For retransmissions, the Identifier SHOULD remain unchanged.
To ensure interoperability, plain text MUST be first compressed, then encrypted. This order produces smaller output and more secure encryption.
Upon reception of a Reset-Request, the transmitting encrypter is reset to an initial state and an ECP packet MUST be transmitted with Code 15 (Reset-Ack), the Identifier copied from the Reset-Request, and any desired data.
ECP negotiation is expected to converge on a single mutually agreeable encryption algorithm per direction, or none. A different algorithm may be negotiated in each direction. Configuration Options indicate algorithms the receiver is willing to use to decrypt data.
ECP uses codes 1–7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack, Code-Reject) and optionally code 14 (Reset-Request) and code 15 (Reset-Ack). Other codes must be treated as unrecognised and result in Code-Rejects.
ECP uses the same packet exchange mechanism as LCP. ECP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase; packets received before this phase should be silently discarded.
If the encryption algorithm is likely to increase message size beyond the PPP Information field maximum, multilink SHOULD also be negotiated to allow frame fragmentation, even when using a single link.
Reset-Request (code 14) and Reset-Ack (code 15) provide a mechanism for indicating decryption failure in one direction without affecting traffic in the other direction. Some encryption algorithms may not require this mechanism.
ECP Option Type registry assigns type 0 to the OUI (proprietary) option and type 1 to DESE (PPP DES Encryption Protocol). All options other than OUI are registered by IANA; types 1–254 indicate publicly defined encryption protocols.
Complete security can only be obtained through end-to-end security between hosts. Link-layer encryption with ECP protects only the PPP link segment, not the full communication path.
ECP encryption provides protection against eavesdropping on the PPP link. The strength of this protection depends on both the encryption algorithm chosen and the care with which any secret (key material) used by that algorithm is protected.
ECP is encapsulated in the PPP Information field with PPP Protocol field type hex 8053. When individual link encryption is used in a multilink connection, the Protocol field is type hex 8055 (Individual Link ECP).
Encrypted datagrams are encapsulated in the PPP Information field with PPP Protocol field type hex 0053. On individual links within a multilink bundle where encryption is negotiated, the Protocol field MUST be type hex 0055.
Reset-Request and Reset-Ack packets contain a 1-octet Code field (14 or 15), a 1-octet Identifier, a 2-octet Length, and a variable-length Data field of zero or more octets up to the peer's MRU minus four.
The Proprietary Encryption OUI Configuration Option (Type 0) contains a 1-octet Type, 1-octet Length (>=6), 3-octet IEEE OUI, 1-octet vendor-specific Subtype, and zero or more Value octets.
The Publicly Available Encryption Types Configuration Option contains a 1-octet Type (1–254), 1-octet Length (>=2), and zero or more Value octets as determined by the encryption protocol.