The PPP Encryption Control Protocol (ECP)
RFC 1968
|
Document |
Type |
|
RFC - Proposed Standard
(June 1996; No errata)
|
|
Author |
|
Gerry Meyer
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 1968 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group G. Meyer
Request for Comments: 1968 Spider Systems
Category: Standards Track June 1996
The PPP Encryption Control Protocol (ECP)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
also defines an extensible Link Control Protocol.
This document defines a method for negotiating data encryption over
PPP links.
Conventions
The following language conventions are used in the items of
specification in this document:
o MUST -- the item is an absolute requirement of the specification.
MUST is only used where it is actually required for interopera-
tion, not to try to impose a particular method on implementors
where not required for interoperability.
o SHOULD -- the item should be followed for all but exceptional cir-
cumstances.
o MAY or optional -- the item is truly optional and may be followed
or ignored according to the needs of the implementor.
The words "should" and "may" are also used, in lower case, in
their more ordinary senses.
Meyer Standards Track [Page 1]
RFC 1968 PPP Encryption June 1996
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
1. Introduction
In order to establish communications over a PPP link, each end of the
link must first send LCP packets to configure and test the data link
during Link Establishment phase. After the link has been
established, optional facilities may be negotiated as needed.
One such facility is data encryption. A wide variety of encryption
methods may be negotiated, although typically only one method is used
in each direction of the link.
A different encryption algorithm may be negotiated in each direction,
for speed, cost, memory or other considerations.
2. Encryption Control Protocol (ECP)
The Encryption Control Protocol (ECP) is responsible for configuring
and enabling data encryption algorithms on both ends of the point-
to-point link.
ECP uses the same packet exchange mechanism as the Link Control
Protocol (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.
The Encryption Control Protocol is exactly the same as LCP [1] with
the following exceptions:
Frame Modifications
The packet may utilise any modifications to the basic frame
format which have been negotiated during the Link Establishment
phase.
Meyer Standards Track [Page 2]
RFC 1968 PPP Encryption June 1996
Data Link Layer Protocol Field
Exactly one ECP packet is 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 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
Show full document text