RFC 1968

The PPP Encryption Control Protocol (ECP)

📅 published June 1996, from ietf

RFC 1968: The PPP Encryption Control Protocol (ECP) 🎀

okay bestie, here's the title block first 💖

Stream: Network Working Group 🌸 Author: G. Meyer of Spider Systems ✨ Category: Standards Track 🦋 Date: June 1996 🍓 Obsoletes / Updates: nothing is listed in the header, so it doesn't obsolete or update anything else 🧚

Status of this Memo ✨

this is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🗣️. If you want to know where this protocol stands in standardisation, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.

Conventions 🧚

okay so these are the language conventions used for the items of specification in this doc:

  • MUST: the item is an absolute requirement of the specification, no wiggle room 🔥. MUST is only used where it's actually required for interoperability, not to force implementors into one particular method when interoperability doesn't need it 💅.
  • SHOULD: the item is meant to be followed for all but exceptional circumstances 🫶.
  • MAY or optional: truly optional 🦋. You can follow it or ignore it, depending on what your implementation needs.

fun fact 🤓: the lowercase "should" and "may" show up too, but only in their everyday meanings, not as the spec terms.

Table of Contents 📖

      1. Introduction ...........................................  2
      2. Encryption Control Protocol (ECP) ......................  2
          2.1 Sending Encrypted Datagrams .......................  3
      3. Additional Packets .....................................  4
          3.1 Reset-Request and Reset-Ack .......................  5
      4. ECP Configuration Options ..............................  6
          4.1 Proprietary Encryption OUI ........................  7
          4.2 Publicly Available Encryption Types ...............  8
          4.3 Negotiating an Encryption Algorithm ...............  9
      5. Security Considerations ................................ 10

Abstract 📝

PPP [1] gives us a standard way to transport multi-protocol datagrams over point-to-point links 🚀. It also defines an extensible Link Control Protocol, which is so cute 🎀.

This document defines a method for negotiating data encryption over PPP links 🔐. Main character energy.

1. Introduction 🌷

okay so, to talk over a PPP link, each end has to send LCP packets first to configure and test the data link during the Link Establishment phase 🔧. After the link is up, optional facilities can be negotiated as needed ✨.

one of those facilities is data encryption 🔐. A whole bunch of encryption methods can be negotiated, though typically only one method gets used in each direction of the link 💜.

each direction can even use a different encryption algorithm, depending on speed, cost, memory or other considerations 🦋. Iconic flexibility.

2. Encryption Control Protocol (ECP) 💅

the Encryption Control Protocol (ECP) is in charge of configuring and enabling data encryption algorithms on both ends of the point-to-point link 👑.

ECP uses the same packet exchange mechanism as LCP. ECP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase 🙈. ECP packets received before this phase is reached should be silently discarded 💀.

ECP is exactly the same as LCP [1], with the following exceptions:

Frame Modifications

The packet may utilise any modifications to the basic frame format that were negotiated during the Link Establishment phase ✨.

Exactly one ECP packet gets encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 8053 (Encryption Control Protocol) 🧚.

when individual link data encryption is used in a multiple link connection to a single destination [2], the PPP Protocol field indicates type hex 8055 (Individual link Encryption Control Protocol) 🫶.

Code Field

ECP uses (decimal) codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject) 🔢. And it may also use code 14 (Reset-Request) and code 15 (Reset-Ack) 💖. Other codes should be treated as unrecognised and should result in Code-Rejects 🙅‍♀️.

Negotiation

ECP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase 🙈. An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before it times out waiting for a Configure-Ack or other response ⏳.

An implementation MUST NOT transmit data until ECP negotiation has completed successfully 🚫. If ECP negotiation is not successful, the link SHOULD be brought down 📉.

Configuration Option Types

ECP has a distinct set of Configuration Options 🎀.

2.1 Sending Encrypted Datagrams 🔐

before any encrypted packets can be communicated, PPP must reach the Network-Layer Protocol phase, and the Encryption Control Protocol must reach the Opened state 🔓.

an encrypted packet gets encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 0053 (Encrypted datagram) 🎁.

when using multiple PPP links to a single destination [2], there are two methods of employing data encryption 🌈:

  • The first method is to encrypt the data before it's sent out through the multiple links 🔒.

The PPP Protocol field MUST indicate type hex 0053.

  • The second is to treat each link as a separate connection, which may or may not have encryption enabled 🦋.

On links which have negotiated encryption, the PPP Protocol field MUST be type hex 0055 (Individual link encrypted datagram).

only one encryption algorithm in each direction is in use at a time, and it gets negotiated before the first encrypted frame is sent 🔑. The PPP Protocol field of the encrypted datagram shows that the frame is encrypted, but not which algorithm was used to encrypt it 🕵️‍♀️.

the maximum length of an encrypted packet sent over a PPP link is the same as the maximum length of the Information field of a PPP encapsulated packet 📏. If the encryption algorithm is likely to push the message beyond that, multilink should also be negotiated so the frames can be fragmented (even if only using a single link) 🧩.

if the encryption algorithm carries history between frames, it must supply a way of determining whether it's passing data reliably, or it must require the use of a reliable transport such as LAPB [3] 🤔.

compression may also be negotiated using the Compression Control Protocol [5]. To ensure interoperability, plain text MUST be:

  • First compressed.
  • Then encrypted.

this order was chosen since it should result in smaller output and more secure encryption 🧠💜.

4.1 Proprietary Encryption OUI ✨

Description

okay so this Configuration Option is how you negotiate a proprietary encryption protocol 🔐 basically a vendor's own secret sauce 💅

vendors are told apart by an Organisationally Unique Identifier (OUI) 🦋 which is just the first three octets of a Vendor's Ethernet address, assigned by IEEE 802 🌸

since the first matching encryption is the one that gets used, it is recommended that any known OUI encryption options be transmitted first 🎀 before the common options show up 🫶

before accepting this option, the implementation must verify that the OUI identifies a proprietary algorithm it can decrypt, and that any vendor specific negotiation values are fully understood 🙈 no skipping this part bestie 😭

here's the Proprietary Encryption OUI Configuration Option format 📐 the fields go left to right:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |       OUI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      OUI       |    Subtype    |  Values...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

the Type is 0 🍓

Length

the Length is >= 6 🧚

IEEE OUI

the IEEE OUI is the most significant three octets of an Ethernet Physical Address, assigned to the vendor by IEEE 802 🌈 this is what says "this option belongs to this vendor" 💜 the bits within the octet are in canonical order, and the most significant octet is transmitted first ✨

Subtype

this field is specific to each OUI and tells you which encryption type that OUI is using 🦋 there is no standardisation for it, so each OUI gets to pick its own values 💅

Values

this field is zero or more octets of extra data, decided by the vendor's encryption protocol 🎀

4.2 Publicly Available Encryption Types 🌸

Description

these Configuration Options let you negotiate a publicly defined encryption algorithm 🫶

these protocols should be made available to interested parties 💖 but they may have certain licencing or export restrictions attached 😬 for more info, check the encryption protocol documents that define each encryption type 📚

here's the Encryption Type Configuration Option format 📐 again, left to right:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |  Values...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

the Type is 1 to 254, and it says which encryption protocol option is being negotiated 🦋 DESE [6] is option type 1 💜 for the other encryption protocols, look at the latest Assigned Numbers RFC 🧚

Length

the Length is >= 2 🍓

Values

this field is zero or more octets of extra data, decided by the encryption protocol 🌈

4.3 Negotiating an Encryption Algorithm 🔥

ECP uses LCP option negotiation techniques to negotiate encryption algorithms 🧠 here's the tea ☕ most other LCP or NCP negotiation of multiple options ends up with several options agreed on, but ECP negotiation is expected to converge on a single mutually agreeable option (encryption algorithm), or none at all 🙅‍♀️ encryption SHOULD be negotiated in both directions 💫 but the algorithms MAY be different 🦋

an implementation that is willing to decrypt using a particular encryption algorithm (or one of a set of algorithms) offers that algorithm (or those algorithms) as an option (or options) in an ECP Configure-Request 🎀 we call this end the Decrypter, and we call the peer the Encrypter 💖

a Decrypter that supports more than one encryption algorithm may send a Configure-Request containing either:

  • an ordered list of options, with the most-preferred encryption algorithm coming first 👑
  • or it may just offer its preferred (not already Rejected) option 💅

an Encrypter that wants to accept the first option (of several) MAY Configure-Ack ALL Options to show complete acceptance of the first-listed, preferred, algorithm ✨

otherwise, if the Encrypter doesn't recognise an option, or is unwilling to support it, it MUST send a Configure-Reject for that option 🙅‍♀️ where more than one option is offered, the Encrypter SHOULD Configure-Reject all but a single preferred option 🫶

if the Encrypter Configure-Rejects ALL offered ECP options, and the Decrypter has no further (non-rejected) options it can offer in a Configure-Request, the Encrypter SHOULD take the link down 💀

if the Encrypter recognises an option, but it isn't acceptable because of values in the request (or optional parameters not in the request), it MUST send a Configure-Nak with the option modified appropriately 🙈 the Configure-Nak MUST contain only those options that will be acceptable 🔥 the Decrypter SHOULD send a new Configure-Request with only the single preferred option, adjusted as specified in the Configure-Nak 🌸

5. Security Considerations 🔐

Negotiation of encryption using PPP is designed to provide protection against eavesdropping on that link 👀 how strong that protection is depends on the encryption algorithm used, and on how carefully any 'secret' used by the encryption algorithm is protected 😭 guard those secrets like your diary 📖💜

it must be recognised that complete security can only be obtained through end-to-end security between hosts 🚨 this link-level protection is not the whole story, bestie 💀

References 📚

[1] Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994.

[2] Sklower, K., Lloyd, B., McGregor, G. and and D. Carr, "The PPP Multilink Protocol (MP)", RFC 1717, University of California, Berkeley, November 1994.

[3] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July 1994.

[4] Reynolds, J., and Postel, J.; "ASSIGNED NUMBERS", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.

[5] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, Novell, June 1996.

[6] Sklower, K., and G. Meyer, "The PPP DES Encryption Protocol (DESE)", RFC 1969, University of California, Berkeley, June 1996.

Acknowledgements 🫶

The style and approach of this proposal owes much to the work on the Compression CP [5] ✨

Chair's Address 🎀

The working group can be contacted via the current chair:

  • Karl Fox
  • Ascend Communications
  • 3518 Riverside Drive, Suite 101
  • Columbus, Ohio 43221
  • EMail: karl@ascend.com

Author's Address 🖋️

  • Gerry Meyer
  • Spider Systems
  • Stanwell Street
  • Edinburgh EH6 5NG
  • Scotland, UK
  • Phone: (UK) 131 554 9424
  • Fax: (UK) 131 554 0649
  • EMail: gerry@spider.co.uk
📦 where this page comes from