diff options
| author | Kozlov Dmitry <dima@server> | 2010-10-06 16:43:14 +0400 |
|---|---|---|
| committer | Kozlov Dmitry <dima@server> | 2010-10-06 16:43:14 +0400 |
| commit | b6a1268714671904e96a49b88680dc3ff07aaa1c (patch) | |
| tree | 60424372b94312710b9f583b1bcc641de4020316 /rfc | |
| parent | 5cf93f33f2350ed3b92f73ead1d2829a6883810a (diff) | |
| download | accel-ppp-b6a1268714671904e96a49b88680dc3ff07aaa1c.tar.gz accel-ppp-b6a1268714671904e96a49b88680dc3ff07aaa1c.zip | |
project cleanup and prepare to release
Diffstat (limited to 'rfc')
36 files changed, 58827 insertions, 0 deletions
diff --git a/rfc/README b/rfc/README new file mode 100644 index 00000000..a76719b1 --- /dev/null +++ b/rfc/README @@ -0,0 +1,15 @@ +In this directory are the various standards documents implemented in +the pptp package. + +rfc791.txt Internet Protocol (IP). +rfc793.txt Transmission Control Protocol (TCP). +rfc1661.txt The Point-to-Point Protocol (PPP). +rfc1662.txt PPP in HDLC-like Framing. (serial encoding). +rfc1701.txt Generic Routing Encapsulation (GRE). +rfc1702.txt Generic Routing Encapsulation over IPv4 networks. +rfc1990.txt The PPP Multilink Protocol (MP). +ms-chap.txt Microsoft PPP CHAP extensions. +pptp-draft.txt July 1997 draft of the PPTP standard. + +rfc1990 is currently unimplemented in pptp + CSA, 12/12/97 diff --git a/rfc/README.Reference b/rfc/README.Reference new file mode 100644 index 00000000..a76719b1 --- /dev/null +++ b/rfc/README.Reference @@ -0,0 +1,15 @@ +In this directory are the various standards documents implemented in +the pptp package. + +rfc791.txt Internet Protocol (IP). +rfc793.txt Transmission Control Protocol (TCP). +rfc1661.txt The Point-to-Point Protocol (PPP). +rfc1662.txt PPP in HDLC-like Framing. (serial encoding). +rfc1701.txt Generic Routing Encapsulation (GRE). +rfc1702.txt Generic Routing Encapsulation over IPv4 networks. +rfc1990.txt The PPP Multilink Protocol (MP). +ms-chap.txt Microsoft PPP CHAP extensions. +pptp-draft.txt July 1997 draft of the PPTP standard. + +rfc1990 is currently unimplemented in pptp + CSA, 12/12/97 diff --git a/rfc/ms-chap.txt b/rfc/ms-chap.txt new file mode 100644 index 00000000..f009400b --- /dev/null +++ b/rfc/ms-chap.txt @@ -0,0 +1,1139 @@ +
+
+
+
+
+
+Network Working Group S. Cobb
+Informational Memo Microsoft
+Revision 1.3 March 1997
+
+
+ Microsoft PPP CHAP Extensions
+
+
+Status of this Memo
+
+ This document has no official Internet Engineering Task Force
+ status. It is submitted as an example of one vendor's working
+ solution to several authentication issues not yet standardized by
+ the Point-to-Point Working Group.
+
+ The protocol described is implemented in Microsoft Windows NT 3.5
+ and 3.51 and in Microsoft Windows95. Differences between the
+ platforms are noted in the text. This information, plus that in
+ the references, is believed sufficient to implement an
+ interoperating peer.
+
+ 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 defines an extensible Link Control Protocol and a
+ family of Network Control Protocols (NCPs) for establishing and
+ configuring different network-layer protocols.
+
+ This document describes Microsoft's PPP CHAP dialect (MS-CHAP),
+ which extends the user authentication functionality provided on
+ Windows networks to remote workstations. MS-CHAP is closely
+ derived from the PPP Challenge/Handshake Authentication Protocol
+ described in RFC 1334 [2], which the reader should have at hand.
+
+
+History
+
+ Rev 1.21: (Sect 6) Fix error in implicit challenge description
+ Rev 1.22: (Sect 7) Fix error in sub-field table ordering
+ Rev 1.3: (Sect 10) Added hash example section
+
+
+
+
+
+
+
+
+Cobb [Page 1]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+Table Of Contents
+
+ 1. Introduction................................................3
+ 2. LCP Configuration...........................................4
+ 3. Challenge Packet............................................4
+ 4. Response Packet.............................................4
+ 5. Success Packet..............................................8
+ 6. Failure Packet..............................................8
+ 7. Change Password Packet (version 1)..........................9
+ 8. Change Password Packet (version 2).........................12
+ 9. Negotiation Examples.......................................16
+ 10. Hash Example...............................................16
+
+ REFERENCES.....................................................18
+ CHAIR'S ADDRESS................................................19
+ AUTHOR'S ADDRESS...............................................19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 2]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+1. Introduction
+
+ Microsoft created MS-CHAP to authenticate remote Windows
+ workstations, providing the functionality to which LAN-based users
+ are accustomed.
+
+ The closest fit available in standard PPP is CHAP which is
+ primarily used for mutual secure authentication between WAN-aware
+ routers. Unfortunately, CHAP is not widely used in support of
+ remote workstations where providers commonly require an insecure
+ text login session in place of PPP authentication protocols. To
+ date, several remote workstation issues have not been adequately
+ addressed in CHAP. MS-CHAP addresses these issues and also
+ integrates the encryption and hashing algorithms used on Windows
+ networks.
+
+ Where possible, MS-CHAP is consistent with standard CHAP, and the
+ differences are easily modularized. Microsoft implements MS-CHAP
+ as extensions to it's standard CHAP code base. Briefly,
+ differences between MS-CHAP and standard CHAP are:
+
+ * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP
+ option 3, Authentication Protocol.
+
+ * The MS-CHAP Response packet is in a format designed for
+ compatibility with Microsoft Windows NT 3.5 and 3.51,
+ Microsoft Windows95, and Microsoft LAN Manager 2.x networking
+ products. The MS-CHAP format does not require the
+ authenticator to store a clear or reversibly encrypted
+ password.
+
+ * MS-CHAP provides an authenticator controlled authentication
+ retry mechanism.
+
+ * MS-CHAP provides an authenticator controlled change password
+ mechanism.
+
+ * MS-CHAP defines a set of reason-for-failure codes returned in
+ the Failure packet Message field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 3]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+2. LCP Configuration
+
+ The LCP configuration for MS-CHAP is identical to that for
+ standard CHAP, except that the Algorithm field has value 0x80,
+ rather than the MD5 value 0x05. Non-MS-CHAP-aware implementations
+ that correctly implement LCP Config-Rej have no problem dealing
+ with this non-standard option.
+
+ Microsoft currently negotiates authentication only on the
+ server->workstation configuration. Mutual authentication may be
+ supported in the future.
+
+
+3. Challenge Packet
+
+ The MS-CHAP Challenge packet is identical in format to the
+ standard CHAP Challenge packet.
+
+ MS-CHAP authenticators send an 8-octet challenge Value field. It
+ is not necessary for peers to duplicate Microsoft's algorithm for
+ selecting the 8-octet value, but the CHAP guidelines on randomness
+ should be observed.
+
+ Microsoft authenticators do not currently provide information in
+ the Name field. This may change in the future.
+
+
+4. Response Packet
+
+ The MS-CHAP Response packet is identical in format to the standard
+ CHAP Response packet. However, the Value field is sub-formatted
+ differently as follows:
+
+ 24 octets: LAN Manager compatible challenge response
+ 24 octets: Windows NT compatible challenge response
+ 1 octet : "Use Windows NT compatible challenge response" flag
+
+ The LAN Manager compatible challenge response is an encoded
+ function of the password and the received challenge as output by
+ the pseudo-code routine LmChallengeResponse below. LAN Manager
+ passwords are limited to 14 case-insensitive OEM characters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 4]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ LmChallengeResponse(
+ IN 8-octet Challenge,
+ IN 0-to-14-oem-char Password,
+ OUT 24-octet Response )
+ {
+ LmPasswordHash(
+ Password,
+ giving PasswordHash )
+
+ ChallengeResponse(
+ Challenge,
+ PasswordHash,
+ giving Response )
+ }
+
+ LmPasswordHash(
+ IN 0-to-14-oem-char Password,
+ OUT 16-octet PasswordHash )
+ {
+ Set UcasePassword to the uppercased Password
+ Zero pad UcasePassword to 14 characters
+
+ DesHash(
+ 1st 7-octets of UcasePassword,
+ giving 1st 8-octets of PasswordHash )
+
+ DesHash(
+ 2nd 7-octets of UcasePassword,
+ giving 2nd 8-octets of PasswordHash )
+ }
+
+ DesHash(
+ IN 7-octet Clear,
+ OUT 8-octet Cypher )
+ {
+ Make Cypher an irreversibly encrypted form of Clear by
+ encrypting known text [6] using Clear as the secret key,
+ that is...
+
+ DesEncrypt(
+ StdText,
+ Clear,
+ giving Cypher )
+ }
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 5]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ DesEncrypt(
+ IN 8-octet Clear,
+ IN 7-octet Key,
+ OUT 8-octet Cypher )
+ {
+ Use the DES encryption algorithm [3] to encrypt Clear into
+ Cypher such that Cypher can only be decrypted back to
+ Clear by providing Key. Note that the DES algorithm takes
+ as input a 64-bit stream where the 8th, 16th, 24th, etc
+ bits are parity bits ignored by the encrypting algorithm.
+ Unless you write your own DES to accept 56-bit input
+ without parity, you will need to insert the parity bits
+ yourself.
+ }
+
+ ChallengeResponse(
+ IN 8-octet Challenge,
+ IN 16-octet PasswordHash,
+ OUT 24-octet Response )
+ {
+ Set ZPasswordHash to PasswordHash zero padded to 21 octets
+
+ DesEncrypt(
+ Challenge,
+ 1st 7-octets of ZPasswordHash,
+ giving 1st 8-octets of Response )
+
+ DesEncrypt(
+ Challenge,
+ 2nd 7-octets of ZPasswordHash,
+ giving 2nd 8-octets of Response )
+
+ DesEncrypt(
+ Challenge,
+ 3rd 7-octets of ZPasswordHash,
+ giving 3rd 8-octets of Response )
+ }
+
+
+ The Windows NT compatible challenge response is an encoded
+ function of the password and the received challenge as output by
+ the NtChallengeResponse routine below. The Windows NT password is
+ a string of 0 to (theoretically) 256 case-sensitive Unicode
+ characters. Current versions of Windows NT limit passwords to 14
+ characters, mainly for compatibility reasons, though this may
+ change in the future.
+
+
+
+
+
+
+
+
+
+Cobb [Page 6]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ NtChallengeResponse(
+ IN 8-octet Challenge,
+ IN 0-to-256-unicode-char Password,
+ OUT 24-octet Response )
+ {
+ NtPasswordHash(
+ Password,
+ giving PasswordHash )
+
+ ChallengeResponse(
+ Challenge,
+ PasswordHash,
+ giving Response )
+ }
+
+ NtPasswordHash(
+ IN 0-to-256-unicode-char Password,
+ OUT 16-octet PasswordHash )
+ {
+ Use the MD4 algorithm [4] to irreversibly hash Password
+ into PasswordHash. Only the password is hashed without
+ including any terminating 0.
+ }
+
+ The "use Windows NT compatible challenge response" flag, if 1,
+ indicates that the Windows NT response is provided and should be
+ used in preference to the LAN Manager response. The LAN Manager
+ response will still be used if the account does not have a Windows
+ NT password hash, e.g. if the password has not been changed since
+ the account was uploaded from a LAN Manager 2.x account database.
+ The LAN Manager response need not be provided (set to 0's) if the
+ implementation expects all user accounts to be stored only in
+ fresh Windows NT account databases or ones where all uploaded
+ passwords have been changed. However, doing so may sacrifice
+ downward compatibility with non-Windows-NT servers.
+
+ If the flag is 0, the Windows NT response is ignored and the LAN
+ Manager response is used. If the password is LAN Manager
+ compatible, interoperability may be achieved without providing the
+ Windows NT challenge response (set to 0's), and providing only the
+ LAN Manager response. This is what Microsoft Windows95 does,
+ though this may change in the future. Doing so may sacrifice
+ interoperability with OEM-specific versions of Windows NT designed
+ for maximum security in Windows-NT-only networks.
+
+ Implementors seeking the broadest possible interoperability are
+ advised to supply both responses when the password is LAN Manager
+ compatible. This is what Microsoft Windows NT does.
+
+
+
+
+
+
+
+Cobb [Page 7]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ The Name field identifies the authenticatee's user account name.
+ The Windows NT domain name may prefix the user's account name in
+ the typical Windows NT format, e.g. "redmond\stevec" where
+ "redmond" is a Windows NT domain containing the user account
+ "stevec". If a domain is not provided, the backslash should also
+ be omitted, e.g. "stevec".
+
+
+5. Success Packet
+
+ The Success packet is identical in format to the standard CHAP
+ Success packet.
+
+
+6. Failure Packet
+
+ The Failure packet is identical in format to the standard CHAP
+ Failure packet. There is, however, formatted text stored in the
+ Message field which, contrary to the standard CHAP rules, does
+ affect the protocol. The Message field format is:
+
+ "E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv"
+
+ where
+
+ The "eeeeeeeeee" is the decimal error code (need not be 10
+ digits) corresponding to one of those listed below, though
+ implementations should deal with codes not on this list
+ gracefully.
+
+ 646 ERROR_RESTRICTED_LOGON_HOURS
+ 647 ERROR_ACCT_DISABLED
+ 648 ERROR_PASSWD_EXPIRED
+ 649 ERROR_NO_DIALIN_PERMISSION
+ 691 ERROR_AUTHENTICATION_FAILURE
+ 709 ERROR_CHANGING_PASSWORD
+
+ The "r" is a flag set to "1" if a retry is allowed, and "0" if
+ not. When authenticator sets this flag to "1" it disables
+ short timeouts, expecting the authenticatee to prompt the user
+ for new credentials and resubmit the response.
+
+ The "cccccccccccccccc" is 16 hex digits representing an ASCII
+ representation of a new challenge value. This field is
+ optional. If it is not sent, authenticator expects the
+ resubmitted response to be calculated based on the previous
+ challenge value plus decimal 23 in the first octet, i.e. the
+ one immediately following the Value Size field. Windows95
+ authenticators may send this field. Windows NT authenticators
+ do not, but may in the future. Both systems implement
+ authenticatee support of this field.
+
+
+
+
+Cobb [Page 8]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ The "vvvvvvvvvv" is the decimal version code (need not be 10
+ digits) indicating the MS-CHAP protocol version supported on
+ the server. Currently, this is interesting only in selecting
+ a Change Password packet type. If the field is not present
+ the version should be assumed 1.
+
+ Implementations should accept but ignore additional text they do
+ not recognize.
+
+
+7. Change Password Packet (version 1)
+
+ The version 1 Change Password packet does not appear in standard
+ CHAP. It allows the authenticatee to change the password on the
+ account specified in the previous Response packet. The version 1
+ Change Password packet should be sent only if the authenticator
+ reports ERROR_PASSWD_EXPIRED (E=648) in the Message field of the
+ Failure packet.
+
+ This packet type is supported by Windows NT 3.5 and 3.51. It is
+ not supported by Windows95, though this may change in the future.
+ See also Change Password Packet (version 2).
+
+ The format of this packet is as follows:
+
+ 1 octet : Code (=5)
+ 1 octet : Identifier
+ 2 octets: Length (=72)
+ 16 octets: Encrypted LAN Manager Old password Hash
+ 16 octets: Encrypted LAN Manager New Password Hash
+ 16 octets: Encrypted Windows NT Old Password Hash
+ 16 octets: Encrypted Windows NT New Password Hash
+ 2 octets: Password Length
+ 2 octets: Flags
+
+
+ Code
+
+ 5
+
+
+ Identifier
+
+ The Identifier field is one octet and aids in matching
+ requests and replies. The value is the Identifier of the
+ received Failure packet to which this packet responds plus 1.
+
+
+ Length
+
+ 72
+
+
+
+
+Cobb [Page 9]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ Encrypted LAN Manager New Password Hash
+ Encrypted LAN Manager Old Password Hash
+
+ These fields contain the LAN Manager password hash of the new
+ and old passwords encrypted with an 8-octet key value [6], as
+ output by the pseudo-code routine LmEncryptedPasswordHash
+ below.
+
+ LmEncryptedPasswordHash(
+ IN 0-to-14-oem-char Password,
+ IN 8-octet KeyValue,
+ OUT 16-octet Cypher )
+ {
+ LmPasswordHash(
+ Password,
+ giving PasswordHash )
+
+ PasswordHashEncryptedWithBlock(
+ PasswordHash,
+ KeyValue,
+ giving Cypher )
+ }
+
+ PasswordHashEncryptedWithBlock(
+ IN 16-octet PasswordHash,
+ IN 7-octet Block,
+ OUT 16-octet Cypher )
+ {
+ DesEncrypt(
+ 1st 8-octets PasswordHash,
+ 1st 7-octets Block,
+ giving 1st 8-octets Cypher )
+
+ DesEncrypt(
+ 2nd 8-octets PasswordHash,
+ 1st 7-octets Block,
+ giving 2nd 8-octets Cypher )
+ }
+
+
+ Encrypted Windows NT New Password Hash
+ Encrypted Windows NT Old Password Hash
+
+ These fields contain the Windows NT password hash of the new
+ and old passwords encrypted with an 8-octet key value [6], as
+ output by the pseudo-code routine NtEncryptedPasswordHash
+ below.
+
+
+
+
+
+
+
+
+Cobb [Page 10]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ NtEncryptedPasswordHash(
+ IN 0-to-14-oem-char Password
+ IN 8-octet Challenge
+ OUT 16-octet Cypher )
+ {
+ NtPasswordHash(
+ Password,
+ giving PasswordHash )
+
+ PasswordHashEncryptedWithBlock(
+ PasswordHash,
+ Challenge,
+ giving Cypher )
+ }
+
+
+ Password Length
+
+ The length in octets of the LAN Manager compatible form of the
+ new password. If this value is less than or equal to 14 it is
+ assumed that the encrypted LAN Manager password hash fields
+ are valid. Otherwise, it is assumed these fields are not
+ valid, in which case the Windows NT compatible passwords must
+ be provided.
+
+
+ Flags
+
+ Bit field of option flags where 0 is the least significant bit
+ of the 16-bit quantity:
+
+ 0 : Set 1 indicates that the encrypted Windows NT
+ hashed passwords are valid and should be used. If
+ 0, the Windows NT fields are not used and the LAN
+ Manager fields must be provided.
+
+ For the broadest possible interoperability,
+ implementations are encouraged to provide both the
+ Windows NT and LAN Manager fields when the password
+ is LAN Manager compatible. This is what Windows NT
+ does.
+
+ 1-15 : Reserved, always set 0.
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 11]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+8. Change Password Packet (version 2)
+
+ The version 2 Change Password packet does not appear in standard
+ CHAP. It allows the authenticatee to change the password on the
+ account specified in the previous Response packet. The version 2
+ Change Password packet should be sent only if the authenticator
+ reports ERROR_PASSWD_EXPIRED (E=648) and a version of 2 or more in
+ the Message field of the Failure packet.
+
+ This packet type is supported by Windows NT 3.51. It is not
+ supported by Windows NT 3.5 or Windows95, though the latter may
+ change in the future. The version 2 change password packet type
+ is preferable to the version 1 type and should be offered and
+ accepted where possible.
+
+ The format of this packet is as follows:
+
+ 1 octet : Code (=6)
+ 1 octet : Identifier
+ 2 octet : Length (=1070)
+ 516 octets : Password Encrypted with Old NT Hash
+ 16 octets : Old NT Hash Encrypted with New NT Hash
+ 516 octets : Password Encrypted with Old LM Hash
+ 16 octets : Old LM Hash Encrypted With New NT Hash
+ 24 octets : LAN Manager compatible challenge response
+ 24 octets : Windows NT compatible challenge response
+ 2-octet : Flags
+
+
+ Code
+
+ 6
+
+
+ Identifier
+
+ The Identifier field is one octet and aids in matching
+ requests and replies. The value is the Identifier of the
+ received Failure packet to which this packet responds plus 1.
+
+
+ Length
+
+ 1118
+
+
+ Password Encrypted with Old NT Hash
+
+ This field contains the PWBLOCK form of the new Windows NT
+ password encrypted with the old Windows NT password hash, as
+ output by the NewPasswordEncryptedWithOldNtPasswordHash
+ routine below:
+
+
+
+Cobb [Page 12]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ datatype-PWBLOCK
+ {
+ 256-unicode-char Password
+ 4-octets PasswordLength
+ }
+
+ NewPasswordEncryptedWithOldNtPasswordHash(
+ IN 0-to-256-unicode-char NewPassword,
+ IN 0-to-256-unicode-char OldPassword,
+ OUT datatype-PWBLOCK EncryptedPwBlock )
+ {
+ NtPasswordHash(
+ OldPassword,
+ giving PasswordHash )
+
+ EncryptPwBlockWithPasswordHash(
+ NewPassword,
+ PasswordHash,
+ giving EncryptedPwBlock )
+ }
+
+ EncryptPwBlockWithPasswordHash(
+ IN 0-to-256-unicode-char Password,
+ IN 16-octet PasswordHash,
+ OUT datatype-PWBLOCK PwBlock )
+ {
+ Fill ClearPwBlock with random octet values
+ lstrcpyW( to ClearPwBlock.Password, from Password )
+ ClearPwBlock.PasswordLength = lstrlenW( Password )
+
+ Rc4Encrypt(
+ ClearPwBlock,
+ sizeof( ClearPwBlock ),
+ PasswordHash,
+ sizeof( PasswordHash ),
+ giving PwBlock )
+ }
+
+ Rc4Encrypt(
+ IN x-octet Clear,
+ IN integer ClearLength,
+ IN y-octet Key,
+ IN integer KeyLength,
+ OUT x-octet Cypher )
+ {
+ Use the RC4 encryption algorithm [5] to encrypt Clear of
+ length ClearLength octets into a Cypher of the same length
+ such that the Cypher can only be decrypted back to Clear
+ by providing a Key of length KeyLength octets.
+ }
+
+
+
+
+
+Cobb [Page 13]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ Old NT Hash Encrypted with New NT Hash
+
+ This field contains the old Windows NT password hash encrypted
+ with the new Windows NT password hash, as output by the
+ OldNtPasswordHashEncryptedWithNewNtPasswordHash routine below:
+
+ OldNtPasswordHashEncryptedWithNewNtPasswordHash(
+ IN 0-to-256-unicode-char NewPassword,
+ IN 0-to-256-unicode-char OldPassword,
+ OUT 16-octet EncryptedPasswordHash )
+ {
+ NtPasswordHash(
+ OldPassword,
+ giving OldPasswordHash )
+
+ NtPasswordHash(
+ NewPassword,
+ giving NewPasswordHash )
+
+ PasswordHashEncryptedWithBlock(
+ OldPasswordHash,
+ NewPasswordHash,
+ giving EncrytptedPasswordHash )
+ }
+
+
+ Password Encrypted with Old LM Hash
+
+ This field contains the PWBLOCK form of the new Windows NT
+ password encrypted with the old LAN Manager password hash, as
+ output by the NewPasswordEncryptedWithOldLmPasswordHash
+ routine below:
+
+ NewPasswordEncryptedWithOldLmPasswordHash(
+ IN 0-to-256-unicode-char NewPassword,
+ IN 0-to-256-unicode-char OldPassword,
+ OUT datatype-PWBLOCK EncryptedPwBlock )
+ {
+ LmPasswordHash(
+ OldPassword,
+ giving PasswordHash )
+
+ EncryptPwBlockWithPasswordHash(
+ NewPassword,
+ PasswordHash,
+ giving EncryptedPwBlock )
+ }
+
+
+
+
+
+
+
+
+Cobb [Page 14]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ Old LM Hash Encrypted with New NT Hash
+
+ This field contains the old LAN Manager password hash encrypted
+ with the new Windows NT password hash, as output by the
+ OldLmPasswordHashEncryptedWithNewNtPasswordHash routine below:
+
+ OldLmPasswordHashEncryptedWithNewNtPasswordHash(
+ IN 0-to-256-unicode-char NewPassword,
+ IN 0-to-256-unicode-char OldPassword,
+ OUT 16-octet EncryptedPasswordHash )
+ {
+ LmPasswordHash(
+ OldPassword,
+ giving OldPasswordHash )
+
+ NtPasswordHash(
+ NewPassword,
+ giving NewPasswordHash )
+
+ PasswordHashEncryptedWithBlock(
+ OldPasswordHash,
+ NewPasswordHash,
+ giving EncrytptedPasswordHash )
+ }
+
+
+ LAN Manager compatible challenge response
+ Windows NT compatible challenge response
+
+ The challenge response fields as described in the Response
+ packet description, but calculated on the new password and the
+ same challenge used in the last response.
+
+
+ Flags
+
+ Bit field of option flags:
+
+ 0 : The "use Windows NT compatible challenge response"
+ flag as described in the Response packet.
+
+ 1 : Set 1 indicates that the "Password Encrypted with
+ Old LM Hash" and "Old LM Hash Encrypted With New NT
+ Hash" fields are valid and should be used. Set 0
+ indicates these fields are not valid.
+
+ For the broadest possible interoperability,
+ implementations are encouraged to provide both the
+ Windows NT and LAN Manager fields when the password
+ is LAN Manager compatible. This is what Windows NT
+ does.
+
+ 2-15 : Reserved, always set 0.
+
+
+Cobb [Page 15]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+9. Negotiation Examples
+
+ Here are some examples of typical negotiations. The authenticatee
+ is on the left and the authenticator is on the right.
+
+ The packet sequence ID is incremented on each authentication retry
+ Response and on the change password response. All cases where the
+ packet sequence ID is updated are noted below.
+
+ Response retry is never allowed after either Change Password.
+ Change Password may occur after Response retry. The implied
+ challenge form is shown in the examples, though all cases of
+ "first challenge+23" should be replaced by the
+ "C=cccccccccccccccc" challenge if authenticator supplies it in the
+ Failure packet.
+
+
+ Successful authentication
+
+ <- Challenge
+ Response ->
+ <- Success
+
+
+ Failed authentication with no retry allowed
+
+ <- Challenge
+ Response ->
+ <- Failure (E=691 R=0)
+
+
+ Successful authentication after retry
+
+ <- Challenge
+ Response ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to first challenge+23 ->
+ <- Success
+
+
+ Failed hack attack with 3 attempts allowed
+
+ <- Challenge
+ Response ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to first challenge+23 ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to first challenge+23+23 ->
+ <- Failure (E=691 R=0)
+
+
+
+
+
+
+Cobb [Page 16]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+ Successful authentication with password change
+
+ <- Challenge
+ Response ->
+ <- Failure (E=648 R=0), disable short timeout
+ ChangePassword (++ID) to first challenge ->
+ <- Success
+
+ Successful authentication with retry and password change
+
+ <- Challenge
+ Response ->
+ <- Failure (E=691 R=1), disable short timeout
+ Response (++ID) to first challenge+23 ->
+ <- Failure (E=648 R=0), disable short timeout
+ ChangePassword (++ID) to first challenge+23 ->
+ <- Success
+
+
+10. Hash Example
+
+ Intermediate values for password "MyPw".
+
+ 8-octet Challenge:
+ 10 2D B5 DF 08 5D 30 41
+
+ 0-to-14-oem-char LmPassword:
+ 4D 59 50 57
+
+ 16-octet LmPasswordHash:
+ 75 BA 30 19 8E 6D 19 75 AA D3 B4 35 B5 14 04 EE
+
+ 24-octet LmChallengeResponse:
+ 91 88 1D 01 52 AB 0C 33 C5 24 13 5E C2 4A 95 EE
+ 64 E2 3C DC 2D 33 34 7D
+
+ 0-to-256-unicode-char NtPassword:
+ 4D 00 79 00 50 00 77 00
+
+ 16-octet NtPasswordHash:
+ FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
+
+ 24-octet NtChallengeResponse:
+ 4E 9D 3C 8F 9C FD 38 5D 5B F4 D3 24 67 91 95 6C
+ A4 C3 51 AB 40 9A 3D 61
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 17]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+REFERENCES
+
+ [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
+ Daydreamer, May 1992
+
+ [2] LLoyd, B and Simpson, W., "PPP Authentication Protocols",
+ RFC 1334, L&A and Daydreamer respectively, Octobet 1992
+
+ [3] "Data Encryption Standard (DES)" is Federal Information
+ Processing Standard publication 46, National Institute of
+ Standard and Techology.
+
+ [4] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, MIT
+ Laboratory for Computer Science and RSA Data Security, Inc.,
+ April 1992.
+
+ [5] RC4 is an encryption standard available from RSA Data Security
+ Inc.
+
+ [6] The 8-octet StdText string used in the LAN Manager compatible
+ password hashing and the 8-octet KeyValue used in the Change
+ Password (version 1) packet are not available for public
+ distribution at this time. Contact the Microsoft Developer
+ Relations group (at time of writing dbeaver@microsoft.com) for
+ details on obtaining these values. On this particular point
+ the author can't help you.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 18]
+
+Memo Microsoft PPP CHAP Extensions March 1997
+
+
+CHAIR'S ADDRESS
+
+ The working group can be contacted via the current chair:
+
+ Fred Baker
+ Email: fred@cisco.com
+
+
+
+AUTHOR'S ADDRESS
+
+ The author is a developer in Microsoft's Windows NT
+ Internetworking group, which monitors the ietf-ppp@merit.edu
+ discussions. Questions can also be directed as below, where email
+ is preferred.
+
+ Steve Cobb
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052-6399
+
+ Email: stevec@microsoft.com
+
+ The author maintains an informal mailing list of persons
+ interested in MS-CHAP and other news regarding Windows NT support
+ for PPP authentication protocols. Send email if interested.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cobb [Page 19]
diff --git a/rfc/pptp-draft.txt b/rfc/pptp-draft.txt new file mode 100644 index 00000000..f58701b3 --- /dev/null +++ b/rfc/pptp-draft.txt @@ -0,0 +1,3472 @@ + +Internet Draft Kory Hamzeh + Ascend Communications + Gurdeep Singh Pall + Microsoft Corporation + William Verthein + U.S. Robotics/3Com + Jeff Taarud + Copper Mountain Networks + W. Andrew Little + ECI Telematics +July 1997 +Expire in six months + + + Point-to-Point Tunneling Protocol--PPTP + draft-ietf-pppext-pptp-02.txt + +Status of this Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + To learn the current status of any Internet-Draft, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), + munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or + ftp.isi.edu (US West Coast). + +Abstract + + This document specifies a protocol which allows the Point + to Point Protocol (PPP) to be tunneled through an IP + network. PPTP does not specify any changes to the PPP + protocol but rather describes a new vehicle for carrying + PPP. A client-server architecture is defined in order to + decouple functions which exist in current Network Access + Servers (NAS) and support Virtual Private Networks (VPNs). + The PPTP Network Server (PNS) is envisioned to run on a + general purpose operating system while the client, referred + to as a PPTP Access Concentrator (PAC) operates on a dial + access platform. PPTP specifies a call-control and + + + +Hamzeh, et al [Page 1] + +Internet Draft PPTP July 1997 + + + management protocol which allows the server to control + access for dial-in circuit switched calls originating from + a PSTN or ISDN or to initiate outbound circuit-switched + connections. PPTP uses an enhanced GRE (Generic Routing + Encapsulation) mechanism to provide a flow- and + congestion-controlled encapsulated datagram service for + carrying PPP packets. + +1. Introduction + + PPTP allows existing Network Access Server (NAS) functions to be + separated using a client-server architecture. Traditionally, the + following functions are implemented by a NAS: + + 1) Physical native interfacing to PSTN or ISDN and control of + external modems or terminal adapters. + + A NAS may interface directly to a telco analog or digital circuit + or attach via an external modem or terminal adapter. Control of a + circuit-switched connection is accomplished with either modem + control or DSS1 ISDN call control protocols. + + The NAS, in conjunction with the modem or terminal adapters, may + perform rate adaption, analog to digital conversion, sync to async + conversion or a number of other alterations of data streams. + + 2) Logical termination of a Point-to-Point-Protocol (PPP) Link + Control Protocol (LCP) session. + + 3) Participation in PPP authentication protocols [3]. + + 4) Channel aggregation and bundle management for PPP Multilink + Protocol. + + 5) Logical termination of various PPP network control protocols + (NCP). + + 6) Multiprotocol routing and bridging between NAS interfaces. + + PPTP divides these functions between the PAC and PNS. The PAC is + responsible for functions 1, 2, and possibly 3. The PNS may be + responsible for function 3 and is responsible for functions 4, 5, and + 6. The protocol used to carry PPP protocol data units (PDUs) between + the PAC and PNS, as well as call control and management is addressed + by PPTP. + + The decoupling of NAS functions offers these benefits: + + + + +Hamzeh, et al [Page 2] + +Internet Draft PPTP July 1997 + + + Flexible IP address management. Dial-in users may maintain a + single IP address as they dial into different PACs as long as they + are served from a common PNS. If an enterprise network uses + unregistered addresses, a PNS associated with the enterprise + assigns addresses meaningful to the private network. + + Support of non-IP protocols for dial networks behind IP networks. + This allows Appletalk and IPX, for example to be tunneled through + an IP-only provider. The PAC need not be capable of processing + these protocols. + + A solution to the "multilink hunt-group splitting" problem. + Multilink PPP, typically used to aggregate ISDN B channels, + requires that all of the channels composing a multilink bundle be + grouped at a single NAS. Since a multilink PPP bundle can be + handled by a single PNS, the channels comprising the bundle may be + spread across multiple PACs. + + +1.1 Protocol Goals and Assumptions + + The PPTP protocol is implemented only by the PAC and PNS. No other + systems need to be aware of PPTP. Dial networks may be connected to a + PAC without being aware of PPTP. Standard PPP client software should + continue to operate on tunneled PPP links. + + PPTP can also be used to tunnel a PPP session over an IP network. In + this configuration the PPTP tunnel and the PPP session runs between + the same two machines with the caller acting as a PNS. + + It is envisioned that there will be a many-to-many relationship + between PACs and PNSs. A PAC may provide service to many PNSs. For + example, an Internet service provider may choose to support PPTP for + a number of private network clients and create VPNs for them. Each + private network may operate one or more PNSs. A single PNS may + associate with many PACs to concentrate traffic from a large number + of geographically diverse sites. + + PPTP uses an extended version of GRE to carry user PPP packets. These + enhancements allow for low-level congestion and flow control to be + provided on the tunnels used to carry user data between PAC and PNS. + This mechanism allows for efficient use of the bandwidth available + for the tunnels and avoids unnecessary retransmisions and buffer + overruns. PPTP does not dictate the particular algorithms to be used + for this low level control but it does define the parameters that + must be communicated in order to allow such algorithms to work. + Suggested algorithms are included in Appendix A. + + +1.2 Terminology + + +Hamzeh, et al [Page 3] + +Internet Draft PPTP July 1997 + + + Analog Channel + + A circuit-switched communication path which is intended to + carry 3.1 Khz audio in each direction. + + Digital Channel + + A circuit-switched communication path which is intended to + carry digital information in each direction. + + Call + + A connection or attempted connection between two terminal + endpoints on a PSTN or ISDN--for example, a telephone call + between two modems. + + Control Connection + + A control connection is created for each PAC, PNS pair and + operates over TCP [4]. The control connection governs aspects + of the tunnel and of sessions assigned to the tunnel. + + Dial User + + An end-system or router attached to an on-demand PSTN or ISDN + which is either the initiator or recipient of a call. + + Network Access Server (NAS) + + A device providing temporary, on-demand network access to + users. This access is point-to-point using PSTN or ISDN lines. + + PPTP Access Concentrator (PAC) + + A device attached to one or more PSTN or ISDN lines capable of + PPP operation and of handling the PPTP protocol. The PAC need + only implement TCP/IP to pass traffic to one or more PNSs. It + may also tunnel non-IP protocols. + + PPTP Network Server (PNS) + + A PNS is envisioned to operate on general-purpose + computing/server platforms. The PNS handles the server side of + the PPTP protocol. Since PPTP relies completely on TCP/IP and + is independent of the interface hardware, the PNS may use any + combination of IP interface hardware including LAN and WAN + devices. + + + + +Hamzeh, et al [Page 4] + +Internet Draft PPTP July 1997 + + + Session + + PPTP is connection-oriented. The PNS and PAC maintain state for + each user that is attached to a PAC. A session is created when + end-to-end PPP connection is attempted between a dial user and + the PNS. The datagrams related to a session are sent over the + tunnel between the PAC and PNS. + + Tunnel + + A tunnel is defined by a PNS-PAC pair. The tunnel protocol is + defined by a modified version of GRE [1,2]. The tunnel carries + PPP datagrams between the PAC and the PNS. Many sessions are + multiplexed on a single tunnel. A control connection operating + over TCP controls the establishment, release, and maintenance + of sessions and of the tunnel itself. + +1.3 Protocol Overview + + There are two parallel components of PPTP: 1) a Control Connection + between each PAC-PNS pair operating over TCP and 2) an IP tunnel + operating between the same PAC-PNS pair which is used to transport + GRE encapsulated PPP packets for user sessions between the pair. + +1.3.1 Control Connection Overview + + Before PPP tunneling can occur between a PAC and PNS, a control + connection must be established between them. The control connection + is a standard TCP session over which PPTP call control and management + information is passed. The control session is logically associated + with, but separate from, the sessions being tunneled through a PPTP + tunnel. For each PAC-PNS pair both a tunnel and a control connection + exist. The control connection is responsible for establishment, + management, and release of sessions carried through the tunnel. It is + the means by which a PNS is notified of an incoming call at an + associated PAC, as well as the means by which a PAC is instructed to + place an outgoing dial call. + + A control connection can be established by either the PNS or the PAC. + Following the establishment of the required TCP connection, the PNS + and PAC establish the control connection using the Start-Control- + Connection-Request and -Reply messages. These messages are also used + to exchange information about basic operating capabilities of the PAC + and PNS. Once the control connection is established, the PAC or PNS + may initiate sessions by requesting outbound calls or responding to + inbound requests. The control connection may communicate changes in + operating characteristics of an individual user session with a Set- + Link-Info message. Individual sessions may be released by either the + + + +Hamzeh, et al [Page 5] + +Internet Draft PPTP July 1997 + + + PAC or PNS, also through Control Connection messages. + + The control connection itself is maintained by keep-alive echo + messages. This ensures that a connectivity failure between the PNS + and the PAC can be detected in a timely manner. Other failures can be + reported via the Wan-Error-Notify message, also on the control + connection. + + It is intended that the control connection will also carry management + related messages in the future, such as a message allowing the PNS to + request the status of a given PAC; these message types have not yet + been defined. + +1.3.2 Tunnel Protocol Overview + + PPTP requires the establishment of a tunnel for each communicating + PNS-PAC pair. This tunnel is used to carry all user session PPP + packets for sessions involving a given PNS-PAC pair. A key which is + present in the GRE header indicates which session a particular PPP + packet belongs to. In this manner, PPP packets are multiplexed and + demultiplexed over a single tunnel between a given PNS-PAC pair. The + value to use in the key field is established by the call + establishment procedure which takes place on the control connection. + + The GRE header also contains acknowledgment and sequencing + information that is used to perform some level of congestion-control + and error detection over the tunnel. Again the control connection is + used to determine rate and buffering parameters that are used to + regulate the flow of PPP packets for a particular session over the + tunnel. PPTP does not specify the particular algorithms to use for + congestion-control and flow-control. Suggested algorithms for the + determination of adaptive time-outs to recover from dropped data or + acknowledgments on the tunnel are included in Appendix A of this + document. + +1.4 Specification Language + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST This word, or the adjective "required", means + that the definition is an absolute requirement + of the specification. + + MUST NOT This phrase means that the definition is an + absolute prohibition of the specification. + + SHOULD This word, or the adjective "recommended", + + + +Hamzeh, et al [Page 6] + +Internet Draft PPTP July 1997 + + + means that, in some circumstances, valid + reasons may exist to ignore this item, but the + full implications must be understood and + carefully weighed before choosing a different + course. Unexpected results may result + otherwise. + + MAY This word, or the adjective "optional", means + that this item is one of an allowed set of + alternatives. An implementation which does + not include this option MUST be prepared to + interoperate with another implementation which + does include the option. + + silently discard The implementation discards the datagram + without further processing, and without + indicating an error to the sender. The + implementation SHOULD provide the capability + of logging the error, including the contents + of the discarded datagram, and SHOULD record + the event in a statistics counter. + + +1.5 Message Format and Protocol Extensibility + + PPTP defines a set of messages sent as TCP data on the control + connection between a PNS and a given PAC. The TCP session for the + control connection is established by initiating a TCP connection to + port 1723 [6]. The source port is assigned to any unused port number. + + Each PPTP Control Connection message begins with an 8 octet fixed + header portion. This fixed header contains the following: the total + length of the message, the PPTP Message Type indicator, and a "Magic + Cookie". + + Two Control Connection message types are indicated by the PPTP + Message Type field: + + 1 - Control Message + 2 - Management Message + + Management messages are currently not defined. + + The Magic Cookie is always sent as the constant 0x1A2B3C4D. Its + basic purpose is to allow the receiver to ensure that it is properly + synchronized with the TCP data stream. It should not be used as a + means for resynchronizing the TCP data stream in the event that a + transmitter issues an improperly formatted message. Loss of + + + +Hamzeh, et al [Page 7] + +Internet Draft PPTP July 1997 + + + synchronization must result in immediate closing of the control + connection's TCP session. + + For clarity, all Control Connection message templates in the next + section include the entire PPTP Control Connection message header. + Numbers preceded by 0x are hexadecimal values. + + The currently defined Control Messages, grouped by function, are: + + Control Message Message Code + + (Control Connection Management) + + Start-Control-Connection-Request 1 + Start-Control-Connection-Reply 2 + Stop-Control-Connection-Request 3 + Stop-Control-Connection-Reply 4 + Echo-Request 5 + Echo-Reply 6 + + (Call Management) + + Outgoing-Call-Request 7 + Outgoing-Call-Reply 8 + Incoming-Call-Request 9 + Incoming-Call-Reply 10 + Incoming-Call-Connected 11 + Call-Clear-Request 12 + Call-Disconnect-Notify 13 + + (Error Reporting) + + WAN-Error-Notify 14 + + (PPP Session Control) + + Set-Link-Info 15 + + + The Start-Control-Connection-Request and -Reply messages determine + which version of the Control Connection protocol will be used. The + version number field carried in these messages consists of a version + number in the high octet and a revision number in the low octet. + Version handling is described in Section 3. The current value of the + version number field is 0x0100 for version 1, revision 0. + + The use of the GRE-like header for the encapsulation of PPP user + packets is specified in Section 4. + + + +Hamzeh, et al [Page 8] + +Internet Draft PPTP July 1997 + + + The MTU for the user data packets encapsulated in GRE is 1532 octets, + not including the IP and GRE headers. + +2.0 Control Connection Protocol Specification + + + Control Connection messages are used to establish and clear user + sessions. The first set of Control Connection messages are used to + maintain the control connection itself. The control connection is + initiated by either the PNS or PAC after they establish the + underlying TCP connection. The procedure and configuration + information required to determine which TCP connections are + established is not covered by this protocol. + + The following Control Connection messages are all sent as user data + on the established TCP connection between a given PNS-PAC pair. Note + that care has been taken to ensure that all word (2 octet) and + longword (4 octet) values begin on appropriate boundaries. All data + is sent in network order (high order octets first). Any "reserved" + fields MUST be sent as 0 values to allow for protocol extensibility. + + The TCP header is followed by the PPTP fields shown in the following: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al [Page 9] + +Internet Draft PPTP July 1997 + + +2.1 Start-Control-Connection-Request + + The Start-Control-Connection-Request is a PPTP control message used + to establish the control connection between a PNS and a PAC. Each + PNS-PAC pair requires a dedicated control connection to be + established. A control connection must be established before any + other PPTP messages can be issued. The establishment of the control + connection can be initiated by either the PNS or PAC. A procedure + which handles the occurrence of a collision between PNS and PAC + Start-Control-Connection-Requests is described in Section 3. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Protocol Version | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Capabilities | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Bearer Capabilities | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum Channels | Firmware Revision | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Host Name (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Vendor String (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. This constant value is used + as a sanity check on received messages + (see Section 1.5). + + + +Hamzeh, et al [Page 10] + +Internet Draft PPTP July 1997 + + + Control Message Type 1 for Start-Control-Connection-Request. + + Reserved0 This field MUST be 0. + + Protocol Version The version of the PPTP protocol that the + sender wishes to use. + + Reserved1 This field MUST be 0. + + Framing Capabilities A set of bits indicating the type of + framing that the sender of this message + can provide. The currently defined bit + settings are: + + 1 - Asynchronous Framing supported + + 2 - Synchronous Framing supported + + Bearer Capabilities A set of bits indicating the bearer + capabilities that the sender of this + message can provide. The currently + defined bit settings are: + + 1 - Analog access supported + + 2 - Digital access supported + + Maximum Channels The total number of individual PPP + sessions this PAC can support. In + Start-Control-Connection-Requests issued + by the PNS, this value SHOULD be set to + 0. It MUST be ignored by the PAC. + + Firmware Revision This field contains the firmware revision + number of the issuing PAC, when issued by + the PAC, or the version of the PNS PPTP + driver if issued by the PNS. + + Host Name A 64 octet field containing the DNS name + of the issuing PAC or PNS. If less than + 64 octets in length, the remainder of + this field SHOULD be filled with octets + of value 0. + + Vendor Name A 64 octet field containing a vendor + specific string describing the type of + PAC being used, or the type of PNS + software being used if this request is + + + +Hamzeh, et al [Page 11] + +Internet Draft PPTP July 1997 + + + issued by the PNS. If less than 64 + octets in length, the remainder of this + field SHOULD be filled with octets of + value 0. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al [Page 12] + +Internet Draft PPTP July 1997 + + +2.2 Start-Control-Connection-Reply + + The Start-Control-Connection-Reply is a PPTP control message sent in + reply to a received Start-Control-Connection-Request message. This + message contains a result code indicating the result of the control + connection establishment attempt. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Protocol Version | Result Code | Error Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Capability | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Bearer Capability | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum Channels | Firmware Revision | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Host Name (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Vendor String (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 2 for Start-Control-Connection-Reply. + + Reserved0 This field MUST be 0. + + Protocol Version The version of the PPTP protocol that the + + + +Hamzeh, et al [Page 13] + +Internet Draft PPTP July 1997 + + + sender wishes to use. + + Result Code Indicates the result of the command + channel establishment attempt. Current + valid Result Code values are: + + 1 - Successful channel establishment + + 2 - General error -- Error Code + indicates the problem + + 3 - Command channel already exists; + + 4 - Requester is not authorized to + establish a command channel + + 5 - The protocol version of the + requester is not supported + + Error Code This field is set to 0 unless a "General + Error" exists, in which case Result Code + is set to 2 and this field is set to the + value corresponding to the general error + condition as specified in Section 2.16. + + Framing Capabilities A set of bits indicating the type of + framing that the sender of this message + can provide. The currently defined bit + settings are: + + 1 - Asynchronous Framing supported + + 2 - Synchronous Framing supported. + + Bearer Capabilities A set of bits indicating the bearer + capabilities that the sender of this + message can provide. The currently + defined bit settings are: + + 1 - Analog access supported + + 2 - Digital access supported + + Maximum Channels The total number of individual PPP + sessions this PAC can support. In a + Start-Control-Connection-Reply issued by + the PNS, this value SHOULD be set to 0 + and it must be ignored by the PAC. The + + + +Hamzeh, et al [Page 14] + +Internet Draft PPTP July 1997 + + + PNS MUST NOT use this value to try to + track the remaining number of PPP + sessions that the PAC will allow. + + Firmware Revision This field contains the firmware revision + number of the issuing PAC, or the version + of the PNS PPTP driver if issued by the + PNS. + + Host Name A 64 octet field containing the DNS name + of the issuing PAC or PNS. If less than + 64 octets in length, the remainder of + this field SHOULD be filled with octets + of value 0. + + Vendor Name A 64 octet field containing a vendor + specific string describing the type of + PAC being used, or the type of PNS + software being used if this request is + issued by the PNS. If less than 64 + octets in length, the remainder of this + field SHOULD be filled with octets of + value 0. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al [Page 15] + +Internet Draft PPTP July 1997 + + +2.3 Stop-Control-Connection-Request + + The Stop-Control-Connection-Request is a PPTP control message sent by + one peer of a PAC-PNS control connection to inform the other peer + that the control connection should be closed. In addition to closing + the control connection, all active user calls are implicitly cleared. + The reason for issuing this request is indicated in the Reason field. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reason | Reserved1 | Reserved2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 3 for Stop-Control-Connection-Request. + + Reserved0 This field MUST be 0. + + Reason Indicates the reason for the control + connection being closed. Current valid + Reason values are: + + 1 (None) - General request to clear + control connection + + 2 (Stop-Protocol) - Can't support + peer's version of the protocol + + 3 (Stop-Local-Shutdown) - Requester is + being shut down + + Reserved1, Reserved2 These fields MUST be 0. + + + +Hamzeh, et al [Page 16] + +Internet Draft PPTP July 1997 + + +2.4 Stop-Control-Connection-Reply + + The Stop-Control-Connection-Reply is a PPTP control message sent by + one peer of a PAC-PNS control connection upon receipt of a Stop- + Control-Connection-Request from the other peer. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | Error Code | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 4 for Stop-Control-Connection-Reply. + + Reserved0 This field MUST be 0. + + Result Code Indicates the result of the attempt to + close the control connection. Current + valid Result Code values are: + + 1 (OK) - Control connection closed + + 2 (General Error) - Control connection + not closed for reason indicated in + Error Code + + Error Code This field is set to 0 unless a "General + Error" exists, in which case Result Code + is set to 2 and this field is set to the + value corresponding to the general error + condition as specified in Section 2.16. + + Reserved1 This field MUST be 0. + + + +Hamzeh, et al [Page 17] + +Internet Draft PPTP July 1997 + + +2.5 Echo-Request + + The Echo-Request is a PPTP control message sent by either peer of a + PAC-PNS control connection. This control message is used as a "keep- + Alive" for the control connection. The receiving peer issues an + Echo-Reply to each Echo-Request received. As specified in Section 3, + if the sender does not receive an Echo Reply in response to an Echo- + Request, it will eventually clear the control connection. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 5 for Echo-Request. + + Reserved0 This field MUST be 0. + + Identifier A value set by the sender of the Echo- + Request that is used to match the reply + with the corresponding request. + + + + + + + + + + + + + + +Hamzeh, et al [Page 18] + +Internet Draft PPTP July 1997 + + +2.6 Echo-Reply + + The Echo-Reply is a PPTP control message sent by either peer of a + PAC-PNS control connection in response to the receipt of an Echo- + Request. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | Error Code | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 6 for Echo-Reply. + + Reserved0 This field MUST be 0. + + Identifier The contents of the identify field from + the received Echo-Request is copied to + this field. + + Result Code Indicates the result of the receipt of + the Echo-Request. Current valid Result + Code values are: + + 1 (OK) - The Echo-Reply is valid + + 2 (General Error) - Echo-Request not + accepted for the reason indicated in + Error Code + + Error Code This field is set to 0 unless a "General + + + +Hamzeh, et al [Page 19] + +Internet Draft PPTP July 1997 + + + Error" condition exists, in which case + Result Code is set to 2 and this field is + set to the value corresponding to the + general error condition as specified in + Section 2.16. + + Reserved1 This field MUST be 0. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al [Page 20] + +Internet Draft PPTP July 1997 + + +2.7 Outgoing-Call-Request + + The Outgoing-Call-Request is a PPTP control message sent by the PNS + to the PAC to indicate that an outbound call from the PAC is to be + established. This request provides the PAC with information required + to make the call. It also provides information to the PAC that is + used to regulate the transmission of data to the PNS for this session + once it is established. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Call Serial Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Minimum BPS | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum BPS | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Bearer Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Recv. Window Size | Packet Processing Delay | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Phone Number Length | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Phone Number (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Subaddress (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + + + +Hamzeh, et al [Page 21] + +Internet Draft PPTP July 1997 + + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 7 for Outgoing-Call-Request. + + Reserved0 This field MUST be 0. + + Call ID A unique identifier, unique to a + particular PAC-PNS pair assigned by the + PNS to this session. It is used to + multiplex and demultiplex data sent over + the tunnel between the PNS and PAC + involved in this session. + + Call Serial Number An identifier assigned by the PNS to this + session for the purpose of identifying + this particular session in logged session + information. Unlike the Call ID, both + the PNS and PAC associate the same Call + Serial Number with a given session. The + combination of IP address and call serial + number SHOULD be unique. + + Minimum BPS The lowest acceptable line speed (in + bits/second) for this session. + + Maximum BPS The highest acceptable line speed (in + bits/second) for this session. + + Bearer Type A value indicating the bearer capability + required for this outgoing call. The + currently defined values are: + + 1 - Call to be placed on an analog + channel + + 2 - Call to be placed on a digital + channel + + 3 - Call can be placed on any type of + channel + + Framing Type A value indicating the type of PPP + framing to be used for this outgoing + call. + + 1 - Call to use Asynchronous framing + + 2 - Call to use Synchronous framing + + + +Hamzeh, et al [Page 22] + +Internet Draft PPTP July 1997 + + + 3 - Call can use either type of + framing + + Packet Recv. Window Size The number of received data packets the + PNS will buffer for this session. + + Packet Processing Delay A measure of the packet processing delay + that might be imposed on data sent to the + PNS from the PAC. This value is + specified in units of 1/10 seconds. For + the PNS this number should be very small. + See appendix A for a description of how + this value is determined and used. + + Phone Number Length The actual number of valid digits in the + Phone Number field. + + Reserved1 This field MUST be 0. + + Phone Number The number to be dialed to establish the + outgoing session. For ISDN and analog + calls this field is an ASCII string. If + the Phone Number is less than 64 octets + in length, the remainder of this field is + filled with octets of value 0. + + Subaddress A 64 octet field used to specify + additional dialing information. If the + subaddress is less than 64 octets long, + the remainder of this field is filled + with octets of value 0. + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al [Page 23] + +Internet Draft PPTP July 1997 + + +2.8 Outgoing-Call-Reply + + The Outgoing-Call-Reply is a PPTP control message sent by the PAC to + the PNS in response to a received Outgoing-Call-Request message. The + reply indicates the result of the outgoing call attempt. It also + provides information to the PNS about particular parameters used for + the call. It provides information to allow the PNS to regulate the + transmission of data to the PAC for this session. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Peer's Call ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | Error Code | Cause Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Connect Speed | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Recv. Window Size | Packet Processing Delay | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Physical Channel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 8 for Outgoing-Call-Reply. + + Reserved0 This field MUST be 0. + + Call ID A unique identifier for the tunnel, + assigned by the PAC to this session. It + is used to multiplex and demultiplex data + sent over the tunnel between the PNS and + PAC involved in this session. + + + + +Hamzeh, et al [Page 24] + +Internet Draft PPTP July 1997 + + + Peer's Call ID This field is set to the value received + in the Call ID field of the corresponding + Outgoing-Call-Request message. It is + used by the PNS to match the Outgoing- + Call-Reply with the Outgoing-Call-Request + it issued. It also is used as the value + sent in the GRE header for mux/demuxing. + + Result Code This value indicates the result of the + Outgoing-Call-Request attempt. Currently + valid values are: + + 1 (Connected) - Call established with + no errors + + 2 (General Error) - Outgoing Call not + established for the reason indicated + in Error Code + + 3 (No Carrier) - Outgoing Call failed + due to no carrier detected + + 4 (Busy) - Outgoing Call failed due to + detection of a busy signal + + 5 (No Dial Tone) - Outgoing Call + failed due to lack of a dial tone + + 6 (Time-out) - Outgoing Call was not + established within time allotted by + PAC + + 7 (Do Not Accept) - Outgoing Call + administratively prohibited + + Error Code This field is set to 0 unless a "General + Error" condition exists, in which case + Result Code is set to 2 and this field is + set to the value corresponding to the + general error condition as specified in + Section 2.16. + + Cause Code This field gives additional failure + information. Its value can vary + depending upon the type of call + attempted. For ISDN call attempts it is + the Q.931 cause code. + + + + +Hamzeh, et al [Page 25] + +Internet Draft PPTP July 1997 + + + Connect Speed The actual connection speed used, in + bits/second. + + Packet Recv. Window Size The number of received data packets the + PAC will buffer for this session. + + Packet Processing Delay A measure of the packet processing delay + that might be imposed on data sent to the + PAC from the PNS. This value is + specified in units of 1/10 seconds. For + the PAC, this number is related to the + size of the buffer used to hold packets + to be sent to the client and to the speed + of the link to the client. This value + should be set to the maximum delay that + can normally occur between the time a + packet arrives at the PAC and is + delivered to the client. See Appendix A + for an example of how this value is + determined and used. + + Physical Channel ID This field is set by the PAC in a + vendor-specific manner to the physical + channel number used to place this call. + It is used for logging purposes only. + + + + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al [Page 26] + +Internet Draft PPTP July 1997 + + +2.9 Incoming-Call-Request + + The Incoming-Call-Request is a PPTP control message sent by the PAC + to the PNS to indicate that an inbound call is to be established from + the PAC. This request provides the PNS with parameter information + for the incoming call. + + This message is the first in the "three-way handshake" used by PPTP + for establishing incoming calls. The PAC may defer answering the + call until it has received an Incoming-Call-Reply from the PNS + indicating that the call should be established. This mechanism allows + the PNS to obtain sufficient information about the call before it is + answered to determine whether the call should be answered or not. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Call Serial Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call Bearer Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Physical Channel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Dialed Number Length | Dialing Number Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Dialed Number (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Dialing Number (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Subaddress (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + + +Hamzeh, et al [Page 27] + +Internet Draft PPTP July 1997 + + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 9 for Incoming-Call-Request. + + Reserved0 This field MUST be 0. + + Call ID A unique identifier for this tunnel, + assigned by the PAC to this session. It + is used to multiplex and demultiplex data + sent over the tunnel between the PNS and + PAC involved in this session. + + Call Serial Number An identifier assigned by the PAC to this + session for the purpose of identifying + this particular session in logged session + information. Unlike the Call ID, both + the PNS and PAC associate the same Call + Serial Number to a given session. The + combination of IP address and call serial + number should be unique. + + Bearer Type A value indicating the bearer capability + used for this incoming call. Currently + defined values are: + + 1 - Call is on an analog channel + + 2 - Call is on a digital channel + + Physical Channel ID This field is set by the PAC in a + vendor-specific manner to the number of + the physical channel this call arrived + on. + + Dialed Number Length The actual number of valid digits in the + Dialed Number field. + + Dialing Number Length The actual number of valid digits in the + Dialing Number field. + + Dialed Number The number that was dialed by the caller. + For ISDN and analog calls this field is + an ASCII string. If the Dialed Number is + less than 64 octets in length, the + remainder of this field is filled with + octets of value 0. + + + +Hamzeh, et al [Page 28] + +Internet Draft PPTP July 1997 + + + Dialing Number The number from which the call was + placed. For ISDN and analog calls this + field is an ASCII string. If the Dialing + Number is less than 64 octets in length, + the remainder of this field is filled + with octets of value 0. + + Subaddress A 64 octet field used to specify + additional dialing information. If the + subaddress is less than 64 octets long, + the remainder of this field is filled + with octets of value 0. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al [Page 29] + +Internet Draft PPTP July 1997 + + +2.10 Incoming-Call-Reply + + The Incoming-Call-Reply is a PPTP control message sent by the PNS to + the PAC in response to a received Incoming-Call-Request message. The + reply indicates the result of the incoming call attempt. It also + provides information to allow the PAC to regulate the transmission of + data to the PNS for this session. + + This message is the second in the three-way handshake used by PPTP + for establishing incoming calls. It indicates to the PAC whether the + call should be answered or not. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Peer's Call ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | Error Code | Packet Recv. Window Size | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Transmit Delay | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 10 for Incoming-Call-Reply. + + Reserved0 This field MUST be 0. + + Call ID A unique identifier for this tunnel + assigned by the PAC to this session. It + is used to multiplex and demultiplex data + sent over the tunnel between the PNS and + PAC involved in this session. + + Peer's Call ID This field is set to the value received + + + +Hamzeh, et al [Page 30] + +Internet Draft PPTP July 1997 + + + in the Call ID field of the corresponding + Incoming-Call-Request message. It is used + by the PAC to match the Incoming-Call- + Reply with the Incoming-Call-Request it + issued. This value is included in the GRE + header of transmitted data packets for + this session. + + Result Code This value indicates the result of the + Incoming-Call-Request attempt. Current + valid Result Code values are: + + 1 (Connect) - The PAC should answer + the incoming call + + 2 (General Error) - The Incoming Call + should not be established due to the + reason indicated in Error Code + + 3 (Do Not Accept) - The PAC should not + accept the incoming call. It should + hang up or issue a busy indication + + Error Code This field is set to 0 unless a "General + Error" condition exists, in which case + Result Code is set to 2 and this field is + set to the value corresponding to the + general error condition as specified in + Section 2.16. + + Packet Recv. Window Size The number of received data packets the + PAC will buffer for this session. + + Packet Transmit Delay A measure of the packet processing delay + that might be imposed on data sent to the + PAC from the PNS. This value is + specified in units of 1/10 seconds. See + Appendix A for a description of how this + value is determined and used. + + Reserved1 This field MUST be 0. + + + + + + + + + + +Hamzeh, et al [Page 31] + +Internet Draft PPTP July 1997 + + +2.11 Incoming-Call-Connected + + The Incoming-Call-Connected message is a PPTP control message sent by + the PAC to the PNS in response to a received Incoming-Call-Reply. It + provides information to the PNS about particular parameters used for + the call. It also provides information to allow the PNS to regulate + the transmission of data to the PAC for this session. + + This message is the third in the three-way handshake used by PPTP for + establishing incoming calls. It provides a mechanism for providing + the PNS with additional information about the call that cannot, in + general, be obtained at the time the Incoming-Call-Request is issued + by the PAC. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer's Call ID | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Connect Speed | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Recv. Window Size | Packet Transmit Delay | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 11 for Incoming-Call-Connected. + + Reserved0 This field MUST be 0. + + Peer's Call ID This field is set to the value received + in the Call ID field of the corresponding + Incoming-Call-Reply message. It is used + + + +Hamzeh, et al [Page 32] + +Internet Draft PPTP July 1997 + + + by the PNS to match the Incoming-Call- + Connected with the Incoming-Call-Reply it + issued. + + Connect Speed The actual connection speed used, in + bits/second. + + Packet Recv. Window Size The number of received data packets the + PAC will buffer for this session. + + Packet Transmit Delay A measure of the packet processing delay + that might be imposed on data sent to the + PAC from the PNS. This value is + specified in units of 1/10 seconds. See + Appendix A for a description of how this + value is determined and used. + + Framing Type A value indicating the type of PPP + framing being used by this incoming call. + + 1 - Call uses asynchronous framing + + 2 - Call uses synchronous framing + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al [Page 33] + +Internet Draft PPTP July 1997 + + +2.12 Call-Clear-Request + + The Call-Clear-Request is a PPTP control message sent by the PNS to + the PAC indicating that a particular call is to be disconnected. The + call being cleared can be either an incoming or outgoing call, in any + state. The PAC responds to this message with a Call-Disconnect- + Notify message. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 12 for Call-Clear-Request. + + Reserved0 This field MUST be 0. + + Call ID The Call ID assigned by the PNS to this + call. This value is used instead of the + Peer's Call ID because the latter may not + be known to the PNS if the call must be + aborted during call establishment. + + Reserved1 This field MUST be 0. + + + + + + + + + + + +Hamzeh, et al [Page 34] + +Internet Draft PPTP July 1997 + + +2.13 Call-Disconnect-Notify + + The Call-Disconnect-Notify message is a PPTP control message sent by + the PAC to the PNS. It is issued whenever a call is disconnected, + due to the receipt by the PAC of a Call-Clear-Request or for any + other reason. Its purpose is to inform the PNS of both the + disconnection and the reason for it. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Result Code | Error Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cause Code | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Call Statistics (128 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 13 for Call-Disconnect-Notify. + + Reserved0 This field MUST be 0. + + Call ID The value of the Call ID assigned by the + PAC to this call. This value is used + instead of the Peer's Call ID because the + latter may not be known to the PNS if the + call must be aborted during call + establishment. + + Result Code This value indicates the reason for the + disconnect. Current valid Result Code + + + +Hamzeh, et al [Page 35] + +Internet Draft PPTP July 1997 + + + values are: + + 1 (Lost Carrier) - Call disconnected + due to loss of carrier + + 2 (General Error) - Call disconnected + for the reason indicated in Error + Code + + 3 (Admin Shutdown) - Call disconnected + for administrative reasons + + 4 (Request) - Call disconnected due to + received Call-Clear-Request + + Error Code This field is set to 0 unless a "General + Error" condition exists, in which case + the Result Code is set to 2 and this + field is set to the value corresponding + to the general error condition as + specified in Section 2.16. + + Cause Code This field gives additional disconnect + information. Its value varies depending + on the type of call being disconnected. + For ISDN calls it is the Q.931 cause + code. + + Call Statistics This field is an ASCII string containing + vendor-specific call statistics that can + be logged for diagnostic purposes. If + the length of the string is less than + 128, the remainder of the field is filled + with octets of value 0. + + + + + + + + + + + + + + + + + +Hamzeh, et al [Page 36] + +Internet Draft PPTP July 1997 + + +2.14 WAN-Error-Notify + + The WAN-Error-Notify message is a PPTP control message sent by the + PAC to the PNS to indicate WAN error conditions (conditions that + occur on the interface supporting PPP). The counters in this message + are cumulative. This message should only be sent when an error + occurs, and not more than once every 60 seconds. The counters are + reset when a new call is established. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer's Call ID | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CRC Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hardware Overruns | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Buffer Overruns | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Time-out Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Alignment Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 14 for WAN-Error-Notify. + + Reserved0 This field MUST be 0. + + Peer's Call ID Th Call ID assigned by the PNS to this + call. + + + +Hamzeh, et al [Page 37] + +Internet Draft PPTP July 1997 + + + CRC Errors Number of PPP frames received with CRC + errors since session was established. + + Framing Errors Number of improperly framed PPP packets + received. + + Hardware Overruns Number of receive buffer over-runs since + session was established. + + Buffer Overruns Number of buffer over-runs detected since + session was established. + + Time-out Errors Number of time-outs since call was + established. + + Alignment Errors Number of alignment errors since call was + established. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al [Page 38] + +Internet Draft PPTP July 1997 + + +2.15 Set-Link-Info + + The Set-Link-Info message is a PPTP control message sent by the PNS + to the PAC to set PPP-negotiated options. Because these options can + change at any time during the life of the call, the PAC must be able + to update its internal call information dynamically and perform PPP + negotiation on an active PPP session. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer's Call ID | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Send ACCM | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Receive ACCM | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 15 for Set-Link-Info. + + Reserved0 This field MUST be 0. + + Peer's Call ID The value of the Call ID assigned by the + PAC to this call. + + Reserved1 This field MUST be 0. + + Send ACCM The send ACCM value the client should use + to process outgoing PPP packets. The + default value used by the client until + this message is received is 0XFFFFFFFF. + See [7]. + + + + +Hamzeh, et al [Page 39] + +Internet Draft PPTP July 1997 + + + Receive ACCM The receive ACCM value the client should + use to process incoming PPP packets. The + default value used by the client until + this message is received is 0XFFFFFFFF. + See [7]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al [Page 40] + +Internet Draft PPTP July 1997 + + +2.16 General Error Codes + + General error codes pertain to types of errors which are not specific + to any particular PPTP request, but rather to protocol or message + format errors. If a PPTP reply indicates in its Result Code that a + general error occurred, the General Error value should be examined to + determined what the error was. The currently defined General Error + codes and their meanings are: + + 0 (None) - No general error + + 1 (Not-Connected) - No control connection exists yet for this + PAC-PNS pair + + 2 (Bad-Format) - Length is wrong or Magic Cookie value is + incorrect + + 3 (Bad-Value) - One of the field values was out of range or + reserved field was non-zero + + 4 (No-Resource) - Insufficient resources to handle this command + now + + 5 (Bad-Call ID) - The Call ID is invalid in this context + + 6 (PAC-Error) - A generic vendor-specific error occurred in + the PAC + + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al [Page 41] + +Internet Draft PPTP July 1997 + + +3.0 Control Connection Protocol Operation + + This section describes the operation of various PPTP control + connection functions and the Control Connection messages which are + used to support them. The protocol operation of the control + connection is simplified because TCP is used to provide a reliable + transport mechanism. + Ordering and retransmission of messages is not a concern at this + level. The TCP connection itself, however, can close at any time and + an appropriate error recovery mechanism must be provided to handle + this case. + + Some error recovery procedures are common to all states of the + control connection. If an expected reply does not arrive within 60 + seconds, the control connection is closed, unless otherwise + specified. Appropriate logging should be implemented for easy + determination of the problems and the reasons for closing the control + connection. + + Receipt of an invalid or malformed Control Connection message should + be logged appropriately, and the control connection should be closed + and restarted to ensure recovery into a known state. + + +3.1 Control Connection States + + The control connection relies on a standard TCP connection for its + service. The PPTP control connection protocol is not distinguishable + between the PNS and PAC, but is distinguishable between the + originator and receiver. The originating peer is the one which first + attempts the TCP open. Since either PAC or PNS may originate a + connection, it is possible for a TCP collision to occur. See Section + 3.1.3 for a description of this situation. + + + + + + + + + + + + + + + + + + +Hamzeh, et al [Page 42] + +Internet Draft PPTP July 1997 + + +3.1.1 Control Connection Originator (may be PAC or PNS) + + TCP Open Indication + /Send Start Control + Connection Request +-----------------+ + +------------------------------------>| wait_ctl_reply | + | +-----------------+ + | Collision/See (3.1.3) Close TCP V V V Receive Start Ctl + | +-------------------------------+ | | Connection Reply + | | | | Version OK + ^ V | V + +-----------------+ Receive Start Ctl | +-----------------+ + | idle | Connection Reply | | established | + +-----------------+ Version Not OK | +-----------------+ + ^ | V Local Terminate + | Receive Stop Control | | /Send Stop + | Connection Request | | Control Request + | /Send Stop Control Reply V V + | Close TCP +-----------------+ + +-------------------------------------| wait_stop_reply | + +-----------------+ + + + + idle + + The control connection originator attempts to open a TCP connection + to the peer during idle state. When the TCP connection is open, the + originator transmits a send Start-Control-Connection-Request and then + enters the wait_ctl_reply state. + + wait_ctl_reply + + The originator checks to see if another TCP connection has been + requested from the same peer, and if so, handles the collision + situation described in Section 3.1.3. + + When a Start-Control-Connection-Reply is received, it is examined for + a compatible version. If the version of the reply is lower than the + version sent in the request, the older (lower) version should be used + provided it is supported. If the version in the reply is earlier and + supported, the originator moves to the established state. If the + version is earlier and not supported, a Stop-Control-Connection- + Request SHOULD be sent to the peer and the originator moves into the + wait_stop_reply state. + + + + + + +Hamzeh, et al [Page 43] + +Internet Draft PPTP July 1997 + + + established + + An established connection may be terminated by either a local + condition or the receipt of a Stop-Control-Connection-Request. In the + event of a local termination, the originator MUST send a Stop- + Control-Connection-Request and enter the wait_stop_reply state. + + If the originator receives a Stop-Control-Connection-Request it + SHOULD send a Stop-Control-Connection-Reply and close the TCP + connection making sure that the final TCP information has been + "pushed" properly. + + wait_stop_reply + + If a Stop-Control-Connection-Reply is received, the TCP connection + SHOULD be closed and the control connection becomes idle. + +3.1.2 Control connection Receiver (may be PAC or PNS) + + + Receive Start Control Connection Request + Version Not OK/Send Start Control Connection + Reply with Error + +--------+ + | | Receive Control Connection Request Version OK + | | /Send Start Control Connection Reply + | | +----------------------------------------+ + ^ V ^ V + +-----------------+ Receive Start Ctl +-----------------+ + | Idle | Connection Request | Established | + +-----------------+ /Send Stop Reply +-----------------+ + ^ ^ Close TCP V V Local Terminate + | +-------------------------------------+ | /Send Stop + | | Control Conn. + | V Request + | +-----------------+ + +-------------------------------------| Wait-Stop-Reply | + Receive Stop Control +-----------------+ + Connection Reply + /Close TCP + + idle + + The control connection receiver waits for a TCP open attempt on port + 1723. When notified of an open TCP connection, it should prepare to + receive PPTP messages. When a Start-Control-Connection-Request is + received its version field should be examined. If the version is + earlier than the receiver's version and the earlier version can be + + + +Hamzeh, et al [Page 44] + +Internet Draft PPTP July 1997 + + + supported by the receiver, the receiver SHOULD send a Start-Control- + Connection-Reply. If the version is earlier than the receiver's + version and the version cannot be supported, the receiver SHOULD send + a Start- Connection-Reply message, close the TCP connection and + remain in the idle state. If the receiver's version is the same as + earlier than the peer's, the receiver SHOULD send a Start-Control- + Connection-Reply with the receiver's version and enter the + established state. + + established + + An established connection may be terminated by either a local + condition or the reception of a Stop-Control-Connection-Request. In + the event of a local termination, the originator MUST send a Stop- + Control-Connection-Request and enter the wait_stop_reply state. + + If the originator receives a Stop-Control-Connection-Request it + SHOULD send a Stop-Control-Connection-Reply and close the TCP + connection, making sure that the final TCP information has been + "pushed" properly. + + wait_stop_reply + + If a Stop-Control-Connection-Reply is received, the TCP connection + SHOULD be closed and the control connection becomes idle. + +3.1.3 Start Control Connection Initiation Request Collision + + A PAC and PNS must have only one control connection between them. It + is possible, however, for a PNS and a PAC to simultaneously attempt + to establish a control connection to each other. When a Start- + Control-Connection-Request is received on one TCP connection and + another Start-Control-Connection-Request has already been sent on + another TCP connection to the same peer, a collision has occurred. + + The "winner" of the initiation race is the peer with the higher IP + address (compared as 32 bit unsigned values, network number more + significant). For example, if the peers 192.33.45.17 and 192.33.45.89 + collide, the latter will be declared the winner. + + The loser will immediately close the TCP connection it initiated, + without sending any further PPTP control messages on it and will + respond to the winner's request with a Start-Control-Connection-Reply + message. The winner will wait for the Start-Control-Connection-Reply + on the connection it initiated and also wait for a TCP termination + indication on the connection the loser opened. The winner MUST NOT + send any messages on the connection the loser initiated. + + + + +Hamzeh, et al [Page 45] + +Internet Draft PPTP July 1997 + + +3.1.3 Keep Alives and Timers + + A control connection SHOULD be closed by closing the underlying TCP + connection under the following circumstances: + + 1. If a control connection is not in the established state (i.e., + Start-Control-Connection-Request and Start-Control-Connection- + Reply have not been exchanged), a control connection SHOULD be + closed after 60 seconds by a peer waiting for a Start-Control- + Connection-Request or Start-Control-Connection-Reply message. + + 2. If a peer's control connection is in the established state and has + not received a control message for 60 seconds, it SHOULD send a + Echo-Request message. If an Echo-Reply is not received 60 seconds + after the Echo-Request message transmission, the control + connection SHOULD be closed. + +3.2 Call States + +3.2.1 Timing considerations + + Because of the real-time nature of telephone signaling, both the PNS + and PAC should be implemented with multi-threaded architectures such + that messages related to multiple calls are not serialized and + blocked. The transit delay between the PAC and PNS should not exceed + one second. The call and connection state figures do not specify + exceptions caused by timers. The implicit assumption is that since + the TCP-based control connection is being verified with keep-alives, + there is less need to maintain strict timers for call control + messages. + + Establishing outbound international calls, including the modem + training and negotiation sequences, may take in excess of 1 minute so + the use of short timers is discouraged. + + If a state transition does not occur within 1 minute (except for + connections in the idle or established states), the integrity of the + protocol processing between the peers is suspect and the ENTIRE + CONTROL CONNECTION should be closed and restarted. All Call IDs are + logically released whenever a control connection is started. This + presumably also helps in preventing toll calls from being "lost" and + never cleared. + +3.2.2 Call ID values + + Each peer assigns a Call ID value to each user session it requests or + accepts. This Call ID value MUST be unique for the tunnel between the + PNS and PAC to which it belongs. Tunnels to other peers can use the + + + +Hamzeh, et al [Page 46] + +Internet Draft PPTP July 1997 + + + same Call ID number so the receiver of a packet on a tunnel needs to + associate a user session with a particular tunnel and Call ID. It is + suggested that the number of potential Call ID values for each tunnel + be at least twice as large as the maximum number of calls expected on + a given tunnel. + + A session is defined by the triple (PAC, PNS, Call ID). + +3.2.3 Incoming calls + + An Incoming-Call-Request message is generated by the PAC when an + associated telephone line rings. The PAC selects a Call ID and serial + number and indicates the call bearer type. Modems should always + indicate analog call type. ISDN calls should indicate digital when + unrestricted digital service or rate adaption is used and analog if + digital modems are involved. Dialing number, dialed number, and + subaddress may be included in the message if they are available from + the telephone network. + + Once the PAC sends the Incoming-Call-Request, it waits for a response + from the PNS but does not answer the call from the telephone network. + The PNS may choose not to accept the call if: + + - No resources are available to handle more sessions + + - The dialed, dialing, or subaddress fields are not indicative of + an authorized user + + - The bearer service is not authorized or supported + + If the PNS chooses to accept the call, it responds with an Outgoing- + Call-Reply which also indicates window sizes (see Appendix B). When + the PAC receives the Outgoing-Call-Reply, it attempts to connect the + call, assuming the calling party has not hung up. A final call + connected message from the PAC to the PNS indicates that the call + states for both the PAC and the PNS should enter the established + state. + + When the dialed-in client hangs up, the call is cleared normally and + the PAC sends a Call-Disconnect-Notify message. If the PNS wishes to + clear a call, it sends a Call-Clear-Request message and then waits + for a Call-Disconnect-Notify. + + + + + + + + + +Hamzeh, et al [Page 47] + +Internet Draft PPTP July 1997 + + +3.2.3.1 PAC Incoming Call States + + + Ring/Send Incoming Call Request +-----------------+ + +----------------------------------------->| wait_reply | + | +-----------------+ + | Receive Incoming Call Reply V V V + | Not Accepting | | | Receive Incoming + | +--------------------------------+ | | Call Reply Accepting + | | +------------------------------+ | /Answer call; Send + | | | Abort/Send Call | Call Connected + ^ V V Disconnect Notify V + +-----------------+ +-----------------+ + | idle |<-----------------------------| established | + +-----------------+ Receive Clear Call Request +-----------------+ + or telco call dropped + or local disconnect + /Send Call Disconnect Notify + + + + The states associated with the PAC for incoming calls are: + + idle + + The PAC detects an incoming call on one of its telco interfaces. + Typically this means an analog line is ringing or an ISDN TE has + detected an incoming Q.931 SETUP message. The PAC sends an Incoming- + Call-Request message and moves to the wait_reply state. + + wait_reply + + The PAC receives an Incoming-Call-Reply message indicating non- + willingness to accept the call (general error or don't accept) and + moves back into the idle state. If the reply message indicates that + the call is accepted, the PAC sends an Incoming-Call-Connected + message and enters the established state. + + established + + Data is exchanged over the tunnel. The call may be cleared following: + + An event on the telco connection. The PAC sends a Call- + Disconnect-Notify message + + Receipt of a Call-Clear-Request. The PAC sends a Call-Disconnect- + Notify message + + + + +Hamzeh, et al [Page 48] + +Internet Draft PPTP July 1997 + + + A local reason. The PAC sends a Call-Disconnect-Notify message. + +3.2.3.2 PNS Incoming Call States + + + + Receive Incoming Call Request + /Send Incoming Call Reply +-----------------+ + Not Accepting if Error | Wait-Connect | + +-----+ +-----------------+ + | | Receive Incoming Call Req. ^ V V + | | /Send Incoming Call Reply OK | | | Receive Incoming + | | +--------------------------------+ | | Call Connect + ^ V ^ V------------------------------+ V + +-----------------+ Receive Call Disconnect +-----------------+ + | Idle | Notify +- | Established | + +-----------------+ | +-----------------+ + ^ ^ | V Local Terminate + | +----------------------------+ | /Send Call Clear + | Receive Call Disconnect | Request + | Notify V + | +-----------------+ + +--------------------------------------| Wait-Disconnect | + Receive Call Disconnect +-----------------+ + Notify + + + + The states associated with the PNS for incoming calls are: + + idle + + An Incoming-Call-Request message is received. If the request is not + acceptable, an Incoming-Call-Reply is sent back to the PAC and the + PNS remains in the idle state. If the Incoming-Call-Request message + is acceptable, an Incoming-Call-Reply is sent indicating accept in + the result code. The session moves to the wait_connect state. + + wait_connect + + If the session is connected on the PAC, the PAC sends an incoming + call connect message to the PNS which then moves into established + state. The PAC may send a Call-Disconnect-Notify to indicate that the + incoming caller could not be connected. This could happen, for + example, if a telephone user accidently places a standard voice call + to a PAC resulting in a handshake failure on the called modem. + + + + + +Hamzeh, et al [Page 49] + +Internet Draft PPTP July 1997 + + + established + + The session is terminated either by receipt of a Call-Disconnect- + Notify message from the PAC or by sending a Call-Clear-Request. Once + a Call-Clear-Request has been sent, the session enters the + wait_disconnect state. + + wait_disconnect + + Once a Call-Disconnect-Notify is received the session moves back to + the idle state. + +3.2.4 Outgoing calls + + Outgoing messages are initiated by a PNS and instruct a PAC to place + a call on a telco interface. There are only two messages for outgoing + calls: Outgoing-Call-Request and Outgoing-Call-Reply. The PNS sends + an Outgoing-Call-Request specifying the dialed party phone number and + subaddress as well as speed and window parameters. The PAC MUST + respond to the Outgoing-Call-Request message with an Outgoing-Call- + Reply message once the PAC determines that: + + The call has been successfully connected + + A call failure has occurred for reasons such as: no interfaces are + available for dial-out, the called party is busy or does not + answer, or no dial tone is detected on the interface chosen for + dialing + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al [Page 50] + +Internet Draft PPTP July 1997 + + +3.2.4.1 PAC Outgoing Call States + + + + Receive Outgoing Call Request in Error + /Send Outgoing Call Reply with Error + |--------+ + | | Receive Outgoing Call Request No Error + | | /Off Hook; Dial + | | +----------------------------------------- + ^ V ^ V + +-----------------+ Incomplete Call +-----------------+ + | idle | /Send Outgoing Call | wait_cs_ans | + +-----------------+ Reply with Error +-----------------+ + ^ ^ or Recv. Call Clear Req. V V Telco Answer + | | /Send Disconnect Notify| | /Send Outgoing + | +-------------------------------------+ | Call Reply. + | V + | +-----------------+ + +-------------------------------------| established | + Receive Call Clear Request +-----------------+ + or local terminate + or telco disconnect + /Hangup call and send + Call Disconnect Notify + + + + The states associated with the PAC for outgoing calls are: + + idle + + Received Outgoing-Call-Request. If this is received in error, respond + with an Outgoing-Call-Reply with error condition set. Otherwise, + allocate physical channel to dial on. Place the outbound call, wait + for a connection, and move to the wait_cs_ans state. + + wait_cs_ans + + If the call is incomplete, send an Outgoing-Call-Reply with a non- + zero Error Code. If a timer expires on an outbound call, send back an + Outgoing-Call-Reply with a non-zero Error Code. If a circuit switched + connection is established, send an Outgoing-Call-Reply indicating + success. + + established + + If a Call-Clear-Request is received, the telco call SHOULD be + + + +Hamzeh, et al [Page 51] + +Internet Draft PPTP July 1997 + + + released via appropriate mechanisms and a Call-Disconnect-Notify + message SHOULD BE sent to the PNS. If the call is disconnected by the + client or by the telco interface, a Call-Disconnect-Notify message + SHOULD be sent to the PNS. + +3.2.4.2 PNS Outgoing Call States + + + Open Indication Abort/Send + /Send Outgoing Call Call Clear + Request +-----------------+ Request + +-------------------------------->| Wait-Reply |------------+ + | +-----------------+ | + | Receive Outgoing Call Reply V V Receive Outgoing | + | with Error | | Call Reply | + | +-------------------------------+ | No Error | + ^ V V | + +-----------------+ +-----------------+ | + | Idle |<-----------------------------| Established | | + +-----------------+ Receive Call Disconnect +-----------------+ | + ^ Notify V Local Terminate | + | | /Send Call Clear | + | | Request | + | Receive Call Disconnect V | + | Notify +-----------------+ | + +---------------------------------| Wait-Disconnect |<-----------+ + +-----------------+ + + + The states associated with the PNS for outgoing calls are: + + idle + + An Outgoing-Call-Request message is sent to the PAC and the session + moves into the wait_reply state. + + wait_reply + + An Outgoing-Call-Reply is received which indicates an error. The + session returns to idle state. No telco call is active. If the + Outgoing-Call-Reply does not indicate an error, the telco call is + connected and the session moves to the established state. + + established + + If a Call-Disconnect-Notify is received, the telco call has been + terminated for the reason indicated in the Result and Cause Codes. + The session moves back to the idle state. If the PNS chooses to + + + +Hamzeh, et al [Page 52] + +Internet Draft PPTP July 1997 + + + terminate the session, it sends a Call-Clear-Request to the PAC and + then enters the wait_disconnect state. + + wait_disconnect + + A session disconnection is waiting to be confirmed by the PAC. Once + the PNS receives the Call-Disconnect-Notify message, the session + enters idle state. + +4.0 Tunnel Protocol Operation + + The user data carried by the PPTP protocol are PPP data packets. PPP + packets are carried between the PAC and PNS, encapsulated in GRE + packets which in turn are carried over IP. The encapsulated PPP + packets are essentially PPP data packets less any media specific + framing elements. No HDLC flags, bit insertion, control characters, + or control character escapes are included. No CRCs are sent through + the tunnel. The IP packets transmitted over the tunnels between a PAC + and PNS has the following general structure: + + +--------------------------------+ + | Media Header | + +--------------------------------+ + | IP Header | + +--------------------------------+ + | GRE Header | + +--------------------------------+ + | PPP Packet | + +--------------------------------+ + + +4.1 Enhanced GRE header + + The GRE header used in PPTP is enhanced slightly from that specified + in the current GRE protocol specification [1,2]. The main difference + involves the definition of a new Acknowledgment Number field, used to + determine if a particular GRE packet or set of packets has arrived at + the remote end of the tunnel. This Acknowledgment capability is not + used in conjunction with any retransmission of user data packets. It + is used instead to determine the rate at which user data packets are + to be transmitted over the tunnel for a given user session. + + The format of the enhanced GRE header is as follows: + + + + + + + + +Hamzeh, et al [Page 53] + +Internet Draft PPTP July 1997 + + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key (HW) Payload Length | Key (LW) Call ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number (Optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Acknowledgment Number (Optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + C (Bit 0) Checksum Present. Set to zero + (0). + + R (Bit 1) Routing Present. Set to zero + (0). + + K (Bit 2) Key Present. Set to one (1). + + S (Bit 3) Sequence Number Present. Set to + one (1) if a payload (data) packet is + present. Set to zero (0) if payload is + not present (GRE packet is an + Acknowledgment only). + + s (Bit 4) Strict source route present. Set + to zero (0). + + Recur (Bits 5-7) Recursion control. Set to + zero (0). + + A (Bit 8) Acknowledgment sequence number + present. Set to one (1) if packet + contains Acknowledgment Number to be used + for acknowledging previously transmitted + data. + + Flags (Bits 9-12) Must be set to zero (0). + + Ver (Bits 13-15) Must contain 1 (enhanced + GRE). + + Protocol Type Set to hex 880B [8]. + + Key Use of the Key field is up to the + + + +Hamzeh, et al [Page 54] + +Internet Draft PPTP July 1997 + + + implementation. + PPTP uses it as follows: + + Payload Length + (High 2 octets of Key) Size of the + payload, not including the GRE header + + Call ID + (Low 2 octets) Contains the Peer's + Call ID for the session to which this + packet belongs. + + Sequence Number Contains the sequence number of the + payload. Present if S bit (Bit 3) is one + (1). + + Acknowledgment Number Contains the sequence number of the + highest numbered GRE packet received by + the sending peer for this user session. + Present if A bit (Bit 8) is one (1). + + The payload section contains a PPP data packet without any media + specific framing elements. + + The sequence numbers involved are per packet sequence numbers. The + sequence number for each user session is set to zero at session + startup. Each packet sent for a given user session which contains a + payload (and has the S bit (Bit 3) set to one) is assigned the next + consecutive sequence number for that session. + + This protocol allows acknowledgments to be carried with the data and + makes the overall protocol more efficient, which in turn requires + less buffering of packets. + + +4.2 Sliding Window Protocol + + The sliding window protocol used on the PPTP data path is used for + flow control by each side of the data exchange. The enhanced GRE + protocol allows packet acknowledgments to be piggybacked on data + packets. Acknowledgments can also be sent separately from data + packets. Again, the main purpose of the sliding window protocol is + for flow control--retransmissions are not performed by the tunnel + peers. + + + + + + + +Hamzeh, et al [Page 55] + +Internet Draft PPTP July 1997 + + +4.3 Multi Packet Acknowledgment + + One feature of the PPTP sliding window protocol is that it allows the + acknowledgment of multiple packets with a single acknowledgment. All + outstanding packets with a sequence number lower or equal to the + acknowledgment number are considered acknowledged. Time-out + calculations are performed using the time the packet corresponding to + the highest sequence number being acknowledged was transmitted. + + + Adaptive time-out calculations are only performed when an + Acknowledgment is received. When multi-packet acknowledgments are + used, the overhead of the adaptive time-out algorithm is reduced. The + PAC is not required to transmit multi-packet acknowledgments; it can + instead acknowledge each packet individually as it is delivered to + the PPP client. + +4.4 Out-of-Sequence Packets + + Occasionally packets lose their sequencing across a complicated + internetwork. Say, for example that a PNS sends packets 0 to 5 to a + PAC. Because of rerouting in the internetwork, packet 4 arrives at + the PAC before packet 3. The PAC acknowledges packet 4, and may + assume packet 3 is lost. This acknowledgment grants window credit + beyond packet 4. + + When the PAC does receive packet 3, it MUST not attempt to transmit + it to the corresponding PPP client. To do so could cause problems, + as proper PPP protocol operation is premised upon receiving packets + in sequence. PPP does properly deal with the loss of packets, but + not with reordering so out of sequence packets between the PNS and + PAC MUST be silently discarded, or they may be reordered by the + receiver. When packet 5 comes in, it is acknowledged by the PAC + since it has a higher sequence number than 4, which was the last + highest packet acknowledged by the PAC. Packets with duplicate + sequence numbers should never occur since the PAC and PNS never + retransmit GRE packets. A robust implementation will silently + discard duplicate GRE packets, should it receive any. + +5.0 Security Considerations + + Security issues are not addressed in this document. End to end + security is addressed by PPP. Further security considerations will be + addressed by the next version of PPTP. + + + + + + + +Hamzeh, et al [Page 56] + +Internet Draft PPTP July 1997 + + +6.0 Authors' Addresses + + + Kory Hamzeh + Ascend Communications + 1275 Harbor Bay Parkway + Alameda, CA 94502 + Email: kory@ascend.com + + Gurdeep Singh Pall + Microsoft Corporation + Redmond, WA + Email: gurdeep@microsoft.com + + William Verthein + U.S. Robotics/3Com + + Jeff Taarud + Copper Mountain Networks + + W. Andrew Little + ECI Telematics + +7.0 References + + [1] Hanks, S. Li, T., Farinacci, D. Traina, P., "Generic Routing + Encapsulation (GRE)", RFC 1701, October 1994. + + [2] Hanks, S. Li, T., Farinacci, D. Traina, P., "Generic Routing + Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994. + + [3] Lloyd, B. Simpson, W., "PPP Authentication Protocols", RFC 1334, + October 1992. + + [4] Postel, J. B., "Transmission Control Protocol", RFC 791, + September 1981 + + [5] Postel, J. B., "User Data Protocol", RFC 768, August 1980. + + [6] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, October, + 1994. + + [7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", RFC + 1661, July 1994. + + [8] Ethertype for PPP, Reserved with Xerox Corporation. + + + + + +Hamzeh, et al [Page 57] + +Internet Draft PPTP July 1997 + + +Appendix A. Acknowledgment Time-Outs + + + PPTP uses sliding windows and time-outs to provide both user session + flow-control across the internetwork and to perform efficient data + buffering to keep the PAC-PNS data channels full without causing + receive buffer overflow. PPTP requires that a time-out be used to + recover from dropped data or acknowledgment packets. The exact + implementation of the time-out is vendor-specific. It is suggested + that an adaptive time-out be implemented with backoff for congestion + control. The time-out mechanism proposed here has the following + properties: + + Independent time-outs for each session. A device (PAC or PNS) will + have to maintain and calculate time-outs for every active session. + + An administrator-adjustable maximum time-out, MaxTimeOut, unique + to each device. + + An adaptive time-out mechanism that compensates for changing + throughput. To reduce packet processing overhead, vendors may + choose not to recompute the adaptive time-out for every received + acknowledgment. The result of this overhead reduction is that the + time-out will not respond as quickly to rapid network changes. + + Timer backoff on time-out to reduce congestion. The backed-off + timer value is limited by the configurable maximum time-out value. + Timer backoff is done every time an acknowledgment time-out + occurs. + + In general, this mechanism has the desirable behavior of quickly + backing off upon a time-out and of slowly decreasing the time-out + value as packets are delivered without time-outs. + + Some definitions: + + Packet Processing Delay (PPD) is the amount of time required for + each side to process the maximum amount of data buffered in their + receive packet sliding window. The PPD is the value exchanged + between the PAC and PNS when a call is established. For the PNS, + this number should be small. For a PAC making modem connections, + this number could be significant. + + Sample is the actual amount of time incurred receiving an + acknowledgment for a packet. The Sample is measured, not + calculated. + + Round-Trip Time (RTT) is the estimated round-trip time for an + + + +Hamzeh, et al [Page 58] + +Internet Draft PPTP July 1997 + + + Acknowledgment to be received for a given transmitted packet. When + the network link is a local network, this delay will be minimal + (if not zero). When the network link is the Internet, this delay + could be substantial and vary widely. RTT is adaptive: it will + adjust to include the PPD and whatever shifting network delays + contribute to the time between a packet being transmitted and + receiving its acknowledgment. + + Adaptive Time-Out (ATO) is the time that must elapse before an + acknowledgment is considered lost. After a time-out, the sliding + window is partially closed and the ATO is backed off. + + +Packet Processing Delay (PPD) + + The PPD parameter is a 16-bit word exchanged during the Call Control + phase that represents tenths of a second (64 means 6.4 seconds). The + protocol only specifies that the parameter is exchanged, it does not + specify how it is calculated. The way values for PPD are calculated + is implementation-dependent and need not be variable (static time- + outs are allowed). The PPD must be exchanged in the call connect + sequences, even if it remains constant in an implementation. One + possible way to calculate the PPD is: + + PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate + PPD = PPD' + PACFudge + + Header is the total size of the IP and GRE headers, which is 36. The + MTU is the overall MTU for the internetwork link between the PAC and + PNS. WindowSize represents the number of packets in the sliding + window, and is implementation-dependent. The latency of the + internetwork could be used to pick a window size sufficient to keep + the current session's pipe full. The constant 8 converts octets to + bits (assuming ConnectRate is in bits per second). If ConnectRate is + in bytes per second, omit the 8. PACFudge is not required but can be + used to take overall processing overhead of the PAC into account. + + The value of PPD is used to seed the adaptive algorithm with the + initial RTT[n-1] value. + +Sample + + Sample is the actual measured time for a returned acknowledgment. + +Round-Trip Time (RTT) + + The RTT value represents an estimate of the average time it takes for + an acknowledgment to be received after a packet is sent to the remote + + + +Hamzeh, et al [Page 59] + +Internet Draft PPTP July 1997 + + + end of the tunnel. + + +A.1 Calculating Adaptive Acknowledgment Time-Out + + We still must decide how much time to allow for acknowledgments to + return. If the time-out is set too high, we may wait an unnecessarily + long time for dropped packets. If the time-out is too short, we may + time out just before the acknowledgment arrives. The acknowledgment + time-out should also be reasonable and responsive to changing network + conditions. + + The suggested adaptive algorithm detailed below is based on the TCP + 1989 implementation and is explained in Richard Steven's book TCP/IP + Illustrated, Volume 1 (page 300). 'n' means this iteration of the + calculation, and 'n-1' refers to values from the last calculation. + + DIFF[n] = SAMPLE[n] - RTT[n-1] + DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) + RTT[n] = RTT[n-1] + (alpha * DIFF[n]) + ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) + + DIFF represents the error between the last estimated round-trip + time and the measured time. DIFF is calculated on each iteration. + + DEV is the estimated mean deviation. This approximates the + standard deviation. DEV is calculated on each iteration and + stored for use in the next iteration. Initially, it is set to 0. + + RTT is the estimated round-trip time of an average packet. RTT is + calculated on each iteration and stored for use in the next + iteration. Initially, it is set to PPD. + + ATO is the adaptive time-out for the next transmitted packet. ATO + is calculated on each iteration. Its value is limited, by the MIN + function, to be a maximum of the configured MaxTimeOut value. + + Alpha is the gain for the average and is typically 1/8 (0.125). + + Beta is the gain for the deviation and is typically 1/4 (0.250). + + Chi is the gain for the time-out and is typically set to 4. + + To eliminate division operations for fractional gain elements, the + entire set of equations can be scaled. With the suggested gain + constants, they should be scaled by 8 to eliminate all division. To + simplify calculations, all gain values are kept to powers of two so + that shift operations can be used in place of multiplication or + + + +Hamzeh, et al [Page 60] + +Internet Draft PPTP July 1997 + + + division. + + +A.2 Congestion Control: Adjusting for Time-Out + + This section describes how the calculation of ATO is modified in the + case where a time-out does occur. When a time-out occurs, the time- + out value should be adjusted rapidly upward. Although the GRE + packets are not retransmitted when a time-out occurs, the time-out + should be adjusted up toward a maximum limit. To compensate for + shifting internetwork time delays, a strategy must be employed to + increase the time-out when it expires. A simple formula called + Karn's Algorithm is used in TCP implementations and may be used in + implementing the backoff timers for the PNS or the PAC. Notice that + in addition to increasing the time-out, we are also shrinking the + size of the window as described in the next section. + + Karn's timer backoff algorithm, as used in TCP, is: + + + NewTIMEOUT = delta * TIMEOUT + + Adapted to our time-out calculations, for an interval in which a + time-out occurs, the new ATO is calculated as: + + RTT[n] = delta * RTT[n-1] + DEV[n] = DEV[n-1] + ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut) + + In this modified calculation of ATO, only the two values that + contribute to ATO and that are stored for the next iteration are + calculated. RTT is scaled by chi, and DEV is unmodified. DIFF is not + carried forward and is not used in this scenario. A value of 2 for + Delta, the time-out gain factor for RTT, is suggested. + +Appendix B. Acknowledgment Time-Out and Window Adjustment + +B.1 Initial Window Size + + Although each side has indicated the maximum size of its receive + window, it is recommended that a slow start method be used to begin + transmitting data. The initial window size on the transmitter is set + to half the maximum size the receiver requested, with a minimum size + of one packet. The transmitter stops sending packets when the number + of packets awaiting acknowledgment is equal to the current window + size. As the receiver successfully digests each window, the window + size on the transmitter is bumped up by one packet until the maximum + is reached. This method prevents a system from flooding an already + + + +Hamzeh, et al [Page 61] + +Internet Draft PPTP July 1997 + + + congested network because no history has been established. + +B.2 Closing the Window + + When a time-out does occur on a packet, the sender adjusts the size + of the transmit window down to one half its value when it failed. + Fractions are rounded up, and the minimum window size is one. + +B.3 Opening the Window + + With every successful transmission of a window's worth of packets + without a time-out, the transmit window size is increased by one + packet until it reaches the maximum window size that was sent by the + other side when the call was connected. As stated earlier, no + retransmission is done on a time-out. After a time-out, the + transmission resumes with the window starting at one half the size of + the transmit window when the time-out occurred and adjusting upward + by one each time the transmit window is filled with packets that are + all acknowledged without time-outs. + +B.4 Window Overflow + + When a receiver's window overflows with too many incoming packets, + excess packets are thrown away. This situation should not arise if + the sliding window procedures are being properly followed by the + transmitter and receiver. It is assumed that, on the transmit side, + packets are buffered for transmission and are no longer accepted from + the packet source when the transmit buffer fills. + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al [Page 62] + + diff --git a/rfc/rfc1172.txt b/rfc/rfc1172.txt new file mode 100644 index 00000000..53076407 --- /dev/null +++ b/rfc/rfc1172.txt @@ -0,0 +1,2312 @@ + + + + + + +Network Working Group D. Perkins +Request for Comments: 1172 CMU + R. Hobby + UC Davis + July 1990 + + + + The Point-to-Point Protocol (PPP) Initial Configuration Options + + + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community. + + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + + This proposal is the product of the Point-to-Point Protocol Working + Group of the Internet Engineering Task Force (IETF). Comments on + this memo should be submitted to the IETF Point-to-Point Protocol + Working Group chair. + + Distribution of this memo is unlimited. + +Abstract + + The Point-to-Point Protocol (PPP) provides a method for transmitting + datagrams over serial point-to-point links. PPP is composed of + + 1) a method for encapsulating datagrams over serial links, + 2) an extensible Link Control Protocol (LCP), and + 3) a family of Network Control Protocols (NCP) for establishing + and configuring different network-layer protocols. + + The PPP encapsulating scheme, the basic LCP, and an NCP for + controlling and establishing the Internet Protocol (IP) (called the + IP Control Protocol, IPCP) are defined in The Point-to-Point Protocol + (PPP) [1]. + + This document defines the intial options used by the LCP and IPCP. It + also defines a method of Link Quality Monitoring and a simple + authentication scheme. + + + + + + +Perkins & Hobby [Page i] + +RFC 1172 PPP Initial Options July 1990 + + + Table of Contents + + + 1. Introduction .......................................... 1 + + 2. Link Control Protocol (LCP) Configuration Options ..... 1 + 2.1 Maximum-Receive-Unit ............................ 2 + 2.2 Async-Control-Character-Map ..................... 3 + 2.3 Authentication-Type ............................. 5 + 2.4 Magic-Number .................................... 7 + 2.5 Link-Quality-Monitoring ......................... 10 + 2.6 Protocol-Field-Compression ...................... 11 + 2.7 Address-and-Control-Field-Compression ........... 13 + + 3. Link Quality Monitoring ............................... 15 + 3.1 Design Motivation ............................... 15 + 3.2 Design Overview ................................. 15 + 3.3 Processes ....................................... 16 + 3.4 Counters ........................................ 18 + 3.5 Measurements, Calculations, State Variables ..... 19 + 3.6 Link-Quality-Report Packet Format ............... 21 + 3.7 Policy Suggestions .............................. 25 + 3.8 Example ......................................... 25 + + 4. Password Authentication Protocol ...................... 27 + 4.1 Packet Format ................................... 27 + 4.2 Authenticate .................................... 29 + 4.3 Authenticate-Ack ................................ 31 + 4.4 Authenticate-Nak ................................ 32 + + 5. IP Control Protocol (IPCP) Configuration Options ...... 33 + 5.1 IP-Addresses .................................... 34 + 5.2 Compression-Type ................................ 36 + + REFERENCES ................................................... 37 + + SECURITY CONSIDERATIONS ...................................... 37 + + AUTHOR'S ADDRESS ............................................. 37 + + + + + + + + + + + + +Perkins & Hobby [Page ii] + +RFC 1172 PPP Initial Options July 1990 + + +1. Introduction + + The Point-to-Point Protocol (PPP) [1] proposes a standard method of + encapsulating IP datagrams, and other Network Layer protocol + information, over point-to-point links. PPP also proposes an + extensible Option Negotiation Protocol. [1] specifies only the + protocol itself; the initial set of Configuration Options are + described in this document. These Configuration Options allow MTUs + to be changed, IP addresses to be dynamically assigned, header + compression to be enabled, and much more. + + This memo is divided into several sections. Section 2 describes + Configuration Options for the Link Control Protocol. Section 3 + specifies the use of the Link Quality Monitoring option. Section 4 + defines a simple Password Authentication Protocol. Finally, Section 5 + specifies Configuration Options for the IP Control Protocol. + +2. Link Control Protocol (LCP) Configuration Options + + As described in [1], LCP Configuration Options allow modifications to + the standard characteristics of a point-to-point link to be + negotiated. Negotiable modifications proposed in this document + include such things as the maximum receive unit, async control + character mapping, the link authentication method, etc. + + The initial proposed values for the LCP Configuration Option Type + field (see [1]) are assigned as follows: + + 1 Maximum-Receive-Unit + 2 Async-Control-Character-Map + 3 Authentication-Type + 4 NOT ASSIGNED + 5 Magic-Number + 6 Link-Quality-Monitoring + 7 Protocol-Field-Compression + 8 Address-and-Control-Field-Compression + + + + + + + + + + + + + + + +Perkins & Hobby [Page 1] + +RFC 1172 PPP Initial Options July 1990 + + +2.1. Maximum-Receive-Unit + + Description + + This Configuration Option provides a way to negotiate the maximum + packet size used across one direction of a link. By default, all + implementations must be able to receive frames with 1500 octets of + Information. + + This Configuration Option may be sent to inform the remote end + that you can receive larger frames, or to request that the remote + end send you smaller frames. If smaller frames are requested, an + implementation MUST still be able to receive 1500 octet frames in + case link synchronization is lost. + + A summary of the Maximum-Receive-Unit Configuration Option format is + shown below. The fields are transmitted from 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 | Maximum-Receive-Unit | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 1 + + Length + + 4 + + Maximum-Receive-Unit + + The Maximum-Receive-Unit field is two octets and indicates the new + maximum receive unit. The Maximum-Receive-Unit covers only the + Data Link Layer Information field but not the header, trailer or + any transparency bits or bytes. + + Default + + 1500 + + + + + + + + + +Perkins & Hobby [Page 2] + +RFC 1172 PPP Initial Options July 1990 + + +2.2. Async-Control-Character-Map + + Description + + This Configuration Option provides a way to negotiate the use of + control character mapping on asynchronous links. By default, PPP + maps all control characters into an appropriate two character + sequence. However, it is rarely necessary to map all control + characters and often times it is unnecessary to map any + characters. A PPP implementation may use this Configuration + Option to inform the remote end which control characters must + remain mapped and which control characters need not remain mapped + when the remote end sends them. The remote end may still send + these control characters in mapped format if it is necessary + because of constraints at its (the remote) end. This option does + not solve problems for communications links that can send only 7- + bit characters or that can not send all non-control characters. + + There may be some use of synchronous-to-asynchronous converters + (some built into modems) in Point-to-point links resulting in a + synchronous PPP implementation on one end of a link and an + asynchronous implemention on the other. It is the responsibility + of the converter to do all mapping conversions during operation. + To enable this functionality, synchronous PPP implementations MUST + always accept a Async-Control-Character-Map Configuration Option + (it MUST always respond to an LCP Configure-Request specifying + this Configuration Option with an LCP Configure-Ack). However, + acceptance of this Configuration Option does not imply that the + synchronous implementation will do any character mapping, since + synchronous PPP uses bit-stuffing rather than character-stuffing. + Instead, all such character mapping will be performed by the + asynchronous-to-synchronous converter. + + A summary of the Async-Control-Character-Map Configuration Option + format is shown below. The fields are transmitted from 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 | Async-Control-Character-Map + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 2 + + + +Perkins & Hobby [Page 3] + +RFC 1172 PPP Initial Options July 1990 + + + Length + + 6 + + Async-Control-Character-Map + + The Async-Control-Character-Map field is four octets and indicates + the new async control character map. The map is encoded in big- + endian fashion where each numbered bit corresponds to the ASCII + control character of the same value. If the bit is cleared to + zero, then that ASCII control character need not be mapped. If + the bit is set to one, then that ASCII control character must + remain mapped. E.g., if bit 19 is set to zero, then the ASCII + control character 19 (DC3, Control-S) may be sent in the clear. + + Default + + All ones (0xffffffff). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 4] + +RFC 1172 PPP Initial Options July 1990 + + +2.3. Authentication-Type + + Description + + On some links it may be desirable to require a peer to + authenticate itself before allowing Network Layer protocol data to + be exchanged. This Configuration Option provides a way to + negotiate the use of a specific authentication protocol. By + default, authentication is not necessary. If an implementation + requires that the remote end authenticate with some specific + authentication protocol, then it should negotiate the use of that + authentication protocol with this Configuration Option. + + Successful negotiation of the Authentication-Type option adds an + additional Authentication phase to the Link Control Protocol. + This phase is after the Link Quality Determination phase, and + before the Network Layer Protocol Configuration Negotiation phase. + Advancement from the Authentication phase to the Network Layer + Protocol Configuration Negotiation phase may not occur until the + peer is successfully authenticated using the negotiated + authentication protocol. + + An implementation may allow the remote end to pick from more than + one authentication protocol. To achieve this, it may include + multiple Authentication-Type Configuration Options in its + Configure-Request packets. An implementation receiving a + Configure-Request specifying multiple Authentication-Types may + accept at most one of the negotiable authentication protocols and + should send a Configure-Reject specifying all of the other + specified authentication protocols. + + It is recommended that each PPP implementation support + configuration of authentication parameters at least on a per- + interface basis, if not a per peer entity basis. The parameters + should specify which authetication techniques are minimally + required as a prerequisite to establishment of a PPP connection, + either for the specified interface or for the specified peer + entity. Such configuration facilities are necessary to prevent an + attacker from negotiating a reduced security authentication + protocol, or no authentication at all, in an attempt to circumvent + this authentication facility. + + If an implementation sends a Configure-Ack with this Configuration + Option, then it is agreeing to authenticate with the specified + protocol. An implementation receiving a Configure-Ack with this + Configuration Option should expect the remote end to authenticate + with the acknowledged protocol. + + + + +Perkins & Hobby [Page 5] + +RFC 1172 PPP Initial Options July 1990 + + + There is no requirement that authentication be full duplex or that + the same authentication protocol be used in both directions. It + is perfectly acceptable for different authentication protocols to + be used in each direction. This will, of course, depend on the + specific authentication protocols negotiated. + + This document defines a simple Password Authentication Protocol in + Section 4. Development of other more secure protocols is + encouraged. + + A summary of the Authentication-Type Configuration Option format is + shown below. The fields are transmitted from 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 | Authentication-Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Type + + 3 + + Length + + >= 4 + + Authentication-Type + + The Authentication-Type field is two octets and indicates the type + of authentication protocol desired. Values for the + Authentication-Type are always the same as the PPP Data Link Layer + Protocol field values for that same authentication protocol. The + most up-to-date values of the Authentication-Type field are + specified in "Assigned Numbers" [2]. Initial values are assigned + as follows: + + Value (in hex) Protocol + + c023 Password Authentication Protocol + + Data + + The Data field is zero or more octets and contains additional data + as determined by the particular authentication protocol. + + + + +Perkins & Hobby [Page 6] + +RFC 1172 PPP Initial Options July 1990 + + + Default + + No authentication protocol necessary. + + +2.4. Magic-Number + + Description + + This Configuration Option provides a way to detect looped-back + links and other Data Link Layer anomalies. This Configuration + Option may be required by some other Configuration Options such as + the Link-Quality-Monitoring Configuration Option. + + Before this Configuration Option is requested, an implementation + must choose its Magic-Number. It is recommended that the Magic- + Number be chosen in the most random manner possible in order to + guarantee with very high probability that an implementation will + arrive at a unique number. A good way to choose a unique random + number is to start with an unique seed. Suggested sources of + uniqueness include machine serial numbers, other network hardware + addresses, time-of-day clocks, etc. Particularly good random + number seeds are precise measurements of the inter-arrival time of + physical events such as packet reception on other connected + networks, server response time, or the typing rate of a human + user. It is also suggested that as many sources as possible be + used simultaneously. + + When a Configure-Request is received with a Magic-Number + Configuration Option, the received Magic-Number should be compared + with the Magic-Number of the last Configure-Request sent to the + peer. If the two Magic-Numbers are different, then the link is + not looped-back, and the Magic-Number should be acknowledged. If + the two Magic-Numbers are equal, then it is possible, but not + certain, that the link is looped-back and that this Configure- + Request is actually the one last sent. To determine this, a + Configure-Nak should be sent specifying a different Magic-Number + value. A new Configure-Request should not be sent to the peer + until normal processing would cause it to be sent (i.e., until a + Configure-Nak is received or the Restart timer runs out). + + Reception of a Configure-Nak with a Magic-Number different from + that of the last Configure-Nak sent to the peer proves that a link + is not looped-back, and indicates a unique Magic-Number. If the + Magic-Number is equal to the one sent in the last Configure-Nak, + the possibility of a loop-back is increased, and a new Magic- + Number should be chosen. In either case, a new Configure-Request + should be sent with the new Magic-Number. + + + +Perkins & Hobby [Page 7] + +RFC 1172 PPP Initial Options July 1990 + + + If the link is indeed looped-back, this sequence (transmit + Configure-Request, receive Configure-Request, transmit Configure- + Nak, receive Configure-Nak) will repeat over and over again. If + the link is not looped-back, this sequence may occur a few times, + but it is extremely unlikely to occur repeatedly. More likely, + the Magic-Numbers chosen at either end will quickly diverge, + terminating the sequence. The following table shows the + probability of collisions assuming that both ends of the link + select Magic-Numbers with a perfectly uniform distribution: + + Number of Collisions Probability + -------------------- --------------------- + 1 1/2**32 = 2.3 E-10 + 2 1/2**32**2 = 5.4 E-20 + 3 1/2**32**3 = 1.3 E-29 + + Good sources of uniqueness or randomness are required for this + divergence to occur. If a good source of uniqueness cannot be + found, it is recommended that this Configuration Option not be + enabled; Configure-Requests with the option should not be + transmitted and any Magic-Number Configuration Options which the + peer sends should be either acknowledged or rejected. In this + case, loop-backs cannot be reliably detected by the + implementation, although they may still be detectable by the peer. + + If an implementation does transmit a Configure-Request with a + Magic-Number Configuration Option, then it MUST NOT respond with a + Configure-Reject if its peer also transmits a Configure-Request + with a Magic-Number Configuration Option. That is, if an + implementation desires to use Magic Numbers, then it MUST also + allow its peer to do so. If an implementation does receive a + Configure-Reject in response to a Configure-Request, it can only + mean that the link is not looped-back, and that its peer will not + be using Magic-Numbers. In this case, an implementation may act + as if the negotiation had been successful (as if it had instead + received a Configure-Ack). + + The Magic-Number also may be used to detect looped-back links + during normal operation as well as during Configuration Option + negotiation. All Echo-Request, Echo-Reply, Discard-Request, and + Link-Quality-Report LCP packets have a Magic-Number field which + MUST normally be transmitted as zero, and MUST normally be ignored + on reception. However, once a Magic-Number has been successfully + negotiated, an LCP implementation MUST begin transmitting these + packets with the Magic-Number field set to its negotiated Magic- + Number. Additionally, the Magic-Number field of these packets may + be inspected on reception. All received Magic-Number fields should + be equal to either zero or the peer's unique Magic-Number, + + + +Perkins & Hobby [Page 8] + +RFC 1172 PPP Initial Options July 1990 + + + depending on whether or not the peer negotiated one. Reception of + a Magic-Number field equal to the negotiated local Magic-Number + indicates a looped-back link. Reception of a Magic-Number other + than the negotiated local Magic-Number or or the peer's negotiated + Magic-Number, or zero if the peer didn't negotiate one, indicates + a link which has been (mis)configured for communications with a + different peer. + + Procedures for recovery from either case are unspecified and may + vary from implementation to implementation. A somewhat + pessimistic procedure is to assume an LCP Physical-Layer-Down + event and make an immediate transition to the Closed state. A + further Active-Open event will begin the process of re- + establishing the link, which can't complete until the loop-back + condition is terminated and Magic-Numbers are successfully + negotiated. A more optimistic procedure (in the case of a loop- + back) is to begin transmitting LCP Echo-Request packets until an + appropriate Echo-Reply is received, indicating a termination of + the loop-back condition. + + A summary of the Magic-Number Configuration Option format is shown + below. The fields are transmitted from 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 | Magic-Number + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Magic-Number (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 5 + + Length + + 6 + + Magic-Number + + The Magic-Number field is four octets and indicates a number which + is very likely to be unique to one end of the link. A Magic- + Number of zero is illegal and must not be sent. + + Default + + None. + + + +Perkins & Hobby [Page 9] + +RFC 1172 PPP Initial Options July 1990 + + +2.5. Link-Quality-Monitoring + + Description + + On some links it may be desirable to determine when, and how + often, the link is dropping data. This process is called Link + Quality Monitoring and is implemented by periodically transmitting + Link-Quality-Report packets as described in Section 3. The Link- + Quality-Monitoring Configuration Option provides a way to enable + the use of Link-Quality-Report packets, and also to negotiate the + rate at which they are transmitted. By default, Link Quality + Monitoring and the use of Link-Quality-Report packets is disabled. + + A summary of the Link-Quality-Monitoring Configuration Option format + is shown below. The fields are transmitted from 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 | Reporting-Period + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Reporting-Period (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 6 + + Length + + 6 + + Reporting-Period + + The Reporting-Period field is four octets and indicates the + maximum time in micro-seconds that the remote end should wait + between transmission of LCP Link-Quality-Report packets. A value + of zero is illegal and should always be nak'd or rejected. An LCP + implementation is always free to transmit LCP Link-Quality-Report + packets at a faster rate than that which was requested by, and + acknowledged to, the remote end. + + Default + + None + + + + + + +Perkins & Hobby [Page 10] + +RFC 1172 PPP Initial Options July 1990 + + +2.6. Protocol-Field-Compression + + Description + + This Configuration Option provides a way to negotiate the + compression of the Data Link Layer Protocol field. By default, + all implementations must transmit standard PPP frames with two + octet Protocol fields. However, PPP Protocol field numbers are + chosen such that some values may be compressed into a single octet + form which is clearly distinguishable from the two octet form. + This Configuration Option may be sent to inform the remote end + that you can receive compressed single octet Protocol fields. + Compressed Protocol fields may not be transmitted unless this + Configuration Option has been received. + + As previously mentioned, the Protocol field uses an extension + mechanism consistent with the ISO 3309 extension mechanism for the + Address field; the Least Significant Bit (LSB) of each octet is + used to indicate extension of the Protocol field. A binary "0" as + the LSB indicates that the Protocol field continues with the + following octet. The presence of a binary "1" as the LSB marks + the last octet of the Protocol field. Notice that any number of + "0" octets may be prepended to the field, and will still indicate + the same value (consider the two representations for 3, 00000011 + and 00000000 00000011). + + In the interest of simplicity, the standard PPP frame uses this + fact and always sends Protocol fields with a two octet + representation. Protocol field values less than 256 (decimal) are + prepended with a single zero octet even though transmission of + this, the zero and most significant octet, is unnecessary. + + However, when using low speed links, it is desirable to conserve + bandwidth by sending as little redundant data as possible. The + Protocol Compression Configuration Option allows a trade-off + between implementation simplicity and bandwidth efficiency. If + successfully negotiated, the ISO 3309 extension mechanism may be + used to compress the Protocol field to one octet instead of two. + The large majority of frames are compressible since data protocols + are typically assigned with Protocol field values less than 256. + + To guarantee unambiguous recognition of LCP packets, the Protocol + field must never be compressed when sending any LCP packet. In + addition, PPP implementations must continue to be robust and MUST + accept PPP frames with double-octet, as well as single-octet, + Protocol fields, and MUST NOT distinguish between them. + + When a Protocol field is compressed, the Data Link Layer FCS field + + + +Perkins & Hobby [Page 11] + +RFC 1172 PPP Initial Options July 1990 + + + is calculated on the compressed frame, not the original + uncompressed frame. + + A summary of the Protocol-Field-Compression Configuration Option + format is shown below. The fields are transmitted from left to + right. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 7 + + Length + + 2 + + Default + + Disabled. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 12] + +RFC 1172 PPP Initial Options July 1990 + + +2.7. Address-and-Control-Field-Compression + + Description + + This Configuration Option provides a way to negotiate the + compression of the Data Link Layer Address and Control fields. By + default all implementations must transmit frames with Address and + Control fields and must use the hexadecimal values 0xff and 0x03 + respectively. Since these fields have constant values, they are + easily compressed. this Configuration Option may be used to + inform the remote end that you can receive compressed Address and + Control fields. + + Compressed Address and Control fields are formed by simply + omitting them in all non-ambiguous cases. Ambiguous frames may + not be compressed. Ambiguous cases result when the two octets + following the Address and Control fields have values that could be + interpreted as valid Address and Control fields (i.e., 0xff, + 0x03). This can happen when Protocol-Field-Compression is enabled + and the Protocol field is compressed to one octet. If the + Protocol value is 0xff, and the first octet of the Information + field is 0x03, the result is ambiguous and the Address and Control + fields must not be compressed on transmission. + + On reception, the Address and Control fields are decompressed by + examining the first two octets. If they contain the values 0xff + and 0x03, they are assumed to be the Address and Control fields. + If not, it is assumed that the fields were compressed and were not + transmitted. + + One additional case in which the Address and Control fields must + never be compressed is when sending any LCP packet. This rule + guarantees unambiguous recognition of LCP packets. + + When the Address and Control fields are compressed, the Data Link + Layer FCS field is calculated on the compressed frame, not the + original uncompressed frame. + + A summary of the Address-and-Control-Field-Compression configuration + option format is shown below. The fields are transmitted from left + to right. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Perkins & Hobby [Page 13] + +RFC 1172 PPP Initial Options July 1990 + + + Type + + 8 + + Length + + 2 + + Default + + Not compressed. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 14] + +RFC 1172 PPP Initial Options July 1990 + + +3. Link Quality Monitoring + + Data communications links are rarely perfect. Packets can be dropped + or corrupted for various reasons (line noise, equipment failure, + buffer overruns, etc.). Sometimes, it is desirable to determine + when, and how often, the link is dropping data. Routers, for + example, may want to temporarily allow another route to take + precedence. An implementation may also have the option of + disconnecting and switching to an alternate link. The process of + determining data loss is called "Link Quality Monitoring". + +3.1. Design Motivation + + There are many different ways to measure link quality, and even more + ways to react to it. Rather than specifying a single scheme, Link + Quality Monitoring is divided into a "mechanism" and a "policy". PPP + fully specifies the "mechanism" for Link Quality Monitoring by + defining the LCP Link-Quality-Report (LQR) packet and specifying a + procedure for its use. PPP does NOT specify a Link Quality + Monitoring "policy" -- how to judge link quality or what to do when + it is inadequate. That is left as an implementation decision, and + can be different at each end of the link. Implementations are + allowed, and even encouraged, to experiment with various link quality + policies. The Link Quality Monitoring mechanism specification + insures that two implementations with different policies may + communicate and interoperate. + + To allow flexible policies to be implemented, the PPP Link Quality + Monitoring mechanism measures data loss in units of packets, octets, + and Link-Quality-Reports. Each measurement is made separately for + each half of the link, both inbound and outbound. All measurements + are communicated to both ends of the link so that each end of the + link can implement its own link quality policy for both its outbound + and inbound links. + + Finally, the Link Quality Monitoring protocol is designed to be + implementable on many different kinds of systems. Although it may be + common to implement PPP (and especially Link Quality Monitoring) as a + single software process, multi-process implementations with hardware + support are also envisioned. The PPP Link Quality Monitoring + mechanism provides for this by careful definition of the Link- + Quality-Report packet format, and by specifiying reference points for + all data transmission and reception measurements. + +3.2. Design Overview + + Each Link Quality Monitoring implementation maintains counts of the + number of packets and octets transmitted and successfully received, + + + +Perkins & Hobby [Page 15] + +RFC 1172 PPP Initial Options July 1990 + + + and periodically transmits this information to its peer in a Link- + Quality-Report packet. These packets contain three sections: a + Header section, a Counters section, and a Measurements section. + + The Header section of the packet consists of the normal LCP Link + Maintenance packet header including Code, Identifier, Length and + Magic-Number fields. + + The Counters section of the packet consists of four counters, and + provides the information necessary to measure the quality of the + link. The LQR transmitter fills in two of these counters: Out-Tx- + Packets-Ctr and Out-Tx-Octets-Ctr (described later). The LQR + receiver fills in the two remaining counters: In-Rx-Packets-Ctr and + In-Rx-Octets-Ctr (described later). These counters are similar to + sequence numbers; they are constantly increasing to give a "relative" + indication of the number of packets and octets communicated across + the outbound link. By comparing the values in successive Link- + Quality-Reports, an LQR receiver can compute the "absolute" number of + packets and octets communicated across its inbound link. Comparing + these absolute numbers then gives an indication of an inbound link's + quality. Relative numbers, rather than absolute, are transmitted + because they greatly simplify link synchronization; an implementation + merely waits to receive two LQR packets. + + The Measurements section of the packet consists of six state + variables: In-Tx-LQRs, Last-In-Id, In-Tx-Packets, In-Tx-Octets, In- + Rx-Packets, and In-Rx-Octets (described later). This section allows + an implementation to report inbound link quality measurements to its + peer (for which the report will instead indicate outbound link + quality) by transmitting the absolute, rather than relative, number + of LQRs, packets, and octets communicated across the inbound link. + These values are calculated by observing the Counters section of the + Link-Quality-Report packets received on the inbound link. Absolute + numbers may be used in this section without synchronization problems + because it is necessary to receive only one LQR packet to have valid + information. + + Link Quality Monitoring is described in more detail in the following + sections. First, a description of the processes comprising the Link + Quality Monitoring mechanism is presented. This is followed by the + packet and byte counters maintained; the measurements, calculations, + and state variables used; the format of the Link-Quality-Report + packet; some policy suggestions; and, finally, an example link + quality calculation. + +3.3. Processes + + The PPP Link Quality Monitoring mechanism is described using a + + + +Perkins & Hobby [Page 16] + +RFC 1172 PPP Initial Options July 1990 + + + "logical process" model. As shown below, there are five logical + processes duplicated at each end of the duplex link. + + +---------+ +-------+ +----+ Outbound + | |-->| Mux |-->| Tx |=========> + | Link- | +-------+ +----+ + | Manager | + | | +-------+ +----+ Inbound + | |<--| Demux |<--| Rx |<========= + +---------+ +-------+ +----+ + + Link-Manager + + The Link-Manager process transmits and receives Link-Quality- + Reports, and implements the desired link quality policy. LQR + packets are transmitted at a constant rate, which is negotiated by + the LCP Link-Quality-Monitoring Configuration Option. The Link- + Manager process fills in only the Header and Measurements sections + of the packet; the Counters section of the packet is filled in by + the Tx and Rx processes. + + Mux + + The Mux process multiplexes packets from the various protocols + (e.g., LCP, IP, XNS, etc.) into a single, sequential, and + prioritized stream of packets. Link-Quality-Report packets MUST + be given the highest possible priority to insure that link quality + information is communicated in a timely manner. + + Tx + + The Tx process maintains the counters Out-Tx-Packets-Ctr and Out- + Tx-Octets-Ctr which are used to measure the amount of data which + is transmitted on the outbound link. When Tx processes a Link- + Quality-Report packet, it inserts the values of these counters + into the Counters section of the packet. Because these counters + represent relative, rather than absolute, values, the question of + when to update the counters, before or after they are inserted + into a Link-Quality-Report packet, is left as an implementation + decision. However, an implementation MUST make this decision the + same way every time. The Tx process MUST follow the Mux process + so that packets are counted in the order transmitted to the link. + + Rx + + The Rx process maintains the counters In-Rx-Packets-Ctr and In- + Rx-Octets-Ctr which are used to measure the amount of data which + is received by the inbound link. When Rx processes a Link- + + + +Perkins & Hobby [Page 17] + +RFC 1172 PPP Initial Options July 1990 + + + Quality-Report packet, it inserts the values of these counters + into the Counters section of the packet. Again, the question of + when to update the counters, before or after they are inserted + into a Link-Quality-Report packet, is left as an implementation + decision which MUST be made consistently the same way. + + Demux + + The Demux process demultiplexes packets for the various protocols. + The Demux process MUST follow the Rx process so that packets are + counted in the order received from the link. + +3.4. Counters + + In order to fill in the Counters section of a Link-Quality-Report + packet, Link Quality Monitoring requires the implementation of one + 8-bit unsigned, and four 32-bit unsigned, monotonically increasing + counters. These counters may be reset to any initial value before + the first Link-Quality-Report is transmitted, but MUST NOT be reset + again until LCP has left the Open state. Counters wrap to zero when + their maximum value is reached (for 32 bit counters: 0xffffffff + 1 = + 0). + + Out-Identifier-Ctr + + Out-Identifier-Ctr is an 8-bit counter maintained by the Link- + Manager process which increases by one for each transmitted Link- + Quality-Report packet. + + Out-Tx-Packets-Ctr + + Out-Tx-Packets-Ctr is a 32-bit counter maintained by the Tx + process which increases by one for each transmitted Data Link + Layer packet. + + Out-Tx-Octets-Ctr + + Out-Tx-Octets-Ctr is a 32-bit counter maintained by the Tx process + which increases by one for each octet in a transmitted Data Link + Layer packet. All octets which are included in the FCS + calculation MUST be counted, as should the FCS octets themselves. + All other octets MUST NOT be counted. + + In-Rx-Packets-Ctr + + In-Rx-Packets-Ctr is a 32-bit counter maintained by the Rx process + which increases by one for each successfully received Data Link + Layer packet. Packets with incorrect FCS fields or other problems + + + +Perkins & Hobby [Page 18] + +RFC 1172 PPP Initial Options July 1990 + + + MUST not be counted. + + In-Rx-Octets-Ctr + + In-Rx-Octets-Ctr is a 32-bit counter maintained by the Rx process + which increases by one for each octet in a successfully received + Data Link Layer packet. All octets which are included in an FCS + calculation MUST be counted, as should the FCS octets themselves. + All other octets MUST NOT be counted. + +3.5. Measurements, Calculations, State Variables + + In order to fill in the Measurements section of a Link-Quality-Report + packet, Link Quality Monitoring requires the Link-Manager process to + make a number of calculations and keep a number of state variables. + These calculations are made, and these state variables updated, each + time a Link-Quality-Report packet is received from the inbound link. + + In-Tx-LQRs + + In-Tx-LQRs is an 8-bit state variable which indicates the number + of Link-Quality-Report packets which the peer had to transmit in + order for the local end to receive exactly one LQR. In-Tx-LQRs + defines the length of the "period" over which In-Tx-Packets, In- + Tx-Octets, In-Rx-Packets, and In-Rx-Octets were measured. In-Tx- + LQRs is calculated by subtracting Last-In-Id from the received + Identifier. If more than 255 LQRs in a row are lost, In-Tx-LQRs + will be ambiguous since the Identifier field and all state + variables based on it are only 8 bits. It is assumed that the + Link Quality Monitoring policy will be robust enough to handle + this case (it should probably close down the link long before this + happens). + + Last-In-Id + + Last-In-Id is an 8-bit state variable which stores the value of + the last received Identifier. Last-In-Id should be updated after + In-Tx-LQRs has been calculated. + + In-Tx-Packets + + In-Tx-Packets is a 32-bit state variable which indicates the + number of packets which were transmitted on the inbound link + during the last period. In-Tx-Packets is calculated by + subtracting Last-Out-Tx-Packets-Ctr from the received Out-Tx- + Packets-Ctr. + + + + + +Perkins & Hobby [Page 19] + +RFC 1172 PPP Initial Options July 1990 + + + Last-Out-Tx-Packets-Ctr + + Last-Out-Tx-Packets-Ctr is a 32-bit state variable which stores + the value of the last received Out-Tx-Packets-Ctr. Last-Out-Tx- + Packets-Ctr should be updated after In-Tx-Packets has been + calculated. + + In-Tx-Octets + + In-Tx-Octets is a 32-bit state variable which indicates the number + of octets which were transmitted on the inbound link during the + last period. In-Tx-Octets is calculated by subtracting Last-Out- + Tx-Octets-Ctr from the received Out-Tx-Octets-Ctr. + + Last-Out-Tx-Octets-Ctr + + Last-Out-Tx-Octets-Ctr is a 32-bit state variable which stores the + value of the last received Out-Tx-Octets-Ctr. Last-Out-Tx- + Octets-Ctr should be updated after In-Tx-Octets has been + calculated. + + In-Rx-Packets + + In-Rx-Packets is a 32-bit state variable which indicates the + number of packets which were received on the inbound link during + the last period. In-Rx-Packets is calculated by subtracting + Last-In-Rx-Packets-Ctr from the received In-Rx-Packets-Ctr. + + Last-In-Rx-Packets-Ctr + + Last-In-Rx-Packets-Ctr is a 32-bit state variable which stores the + value of the last received In-Rx-Packets-Ctr. Last-In-Rx- + Packets-Ctr should be updated after In-Rx-Packets has been + calculated. + + In-Rx-Octets + + In-Rx-Octets is a 32-bit state variable which indicates the number + of octets which were received on the inbound link during the last + period. In-Rx-Octets is calculated by subtracting Last-In-Rx- + Octets-Ctr from the received In-Rx-Octets-Ctr. + + Last-In-Rx-Octets-Ctr + + Last-In-Rx-Octets-Ctr is a 32-bit state variable which stores the + value of the last received In-Rx-Octets-Ctr. Last-In-Rx-Octets- + Ctr should be updated after In-Rx-Octets has been calculated. + + + + +Perkins & Hobby [Page 20] + +RFC 1172 PPP Initial Options July 1990 + + + Measurements-Valid + + Measurements-Valid is a 1-bit boolean state variable which + indicates whether or not the In-Tx-Packets, In-Tx-Octets, In-Rx- + Packets, and In-Rx-Octets state variables contain valid + measurements. These measurements cannot be considered valid until + two or more Link-Quality-Report packets have been received on the + inbound link. This bit should be reset when LCP reaches the Open + state and should be set after the receipt of exactly two LQRs. + +3.6. Link-Quality-Report Packet Format + + A Summary of the Link-Quality-Report packet format is shown below. + The fields are transmitted from left to right. The Code, Identifier, + Length, and Magic-Number fields make up the normal LCP Link + Maintenance packet header; the In-Tx-LQRS, Last-In-Id, V, In-Tx- + Packets, In-Tx-Octets, In-Rx-Packets, In-Rx-Octets fields contain + digested absolute measurements; and the Out-Tx-Packets-Ctr, Out-Tx- + Octets-Ctr, In-Rx-Packets-Ctr, and In-Rx-Octets-Ctr fields contain + raw relative counts. Note that as transmitted over the link, this + packet format does not include the In-Rx-Packets-Ctr and In-Rx- + Octets-Ctr fields which are logically appended to the packet by the + Rx process after reception on the inbound link. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 21] + +RFC 1172 PPP Initial Options July 1990 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic-Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | In-Tx-LQRs | Last-In-Id | Reserved |V| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | In-Tx-Packets | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | In-Tx-Octets | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | In-Rx-Packets | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | In-Rx-Octets | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Out-Tx-Packets-Ctr | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Out-Tx-Octets-Ctr | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / + / + / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | In-Rx-Packets-Ctr | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | In-Rx-Octets-Ctr | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 12 for Link-Quality-Report. + + Identifier + + The Identifier field is one octet and indicates the sequence + number for this Link-Quality-Report. The Identifier field is + copied from the Out-Identifier-Ctr counter on transmission. On + reception, the Identifier field is used to calculate In-Tx-LQRs + and is then stored in Last-In-Id. + + The Link-Quality-Report Identifier sequence number space MUST be + separate from that of all other LCP packets; for example, + transmission of an LCP Echo-Request must not cause the Out- + Identifier-Ctr counter to be incremented. + + + + + +Perkins & Hobby [Page 22] + +RFC 1172 PPP Initial Options July 1990 + + + Length + + The Length field is two octets and indicates the length of the LQM + packet including the Code, Identifier, Length and all defined + fields. Octets outside the range of the length field should be + treated as Data Link Layer padding and should be ignored on + reception. In order for the correct In-Tx-Octets and In-Rx-Octets + values to be calculated, Link-Quality-Reports MUST be consistently + transmitted with the same amount of padding. + + Magic-Number + + The Magic-Number field is four octets and aids in detecting + looped-back links. Unless modified by a Configuration Option, the + Magic-Number MUST always be transmitted as zero and MUST always be + ignored on reception. If Magic-Numbers have been negotiated, + incoming LQM packets should be checked to make sure that the local + end is not seeing its own Magic-Number and thus a looped-back + link. + + In-Tx-LQRs + + The In-Tx-LQRs field is one octet and indicates the number of + periods covered by the Measurements section of this Link-Quality- + Report. The In-Tx-LQRs field is copied from the In-Tx-LQRs state + variable on transmission. + + Last-In-Id + + The Prev-In-Id field is one octet and indicates the age of the + Measurements section of this Link-Quality-Report. The Last-In-Id + field is copied from the Last-In-Id field on transmission. On + reception, the Last-In-Id field may be compared with the Out- + Identifier-Ctr to determine how many, if any, outbound Link- + Quality-Reports have been lost. + + V + + The V field is 1 bit and indicates whether or not the Measurements + section of this Link-Quality-Report is valid. The V field is + copied from the Measurements-Valid state variable on transmission. + If the V field is not set to 1, then the In-Tx-LQRs, Last-In-Id, + In-Tx-Packets, In-Tx-Octets, In-Rx-Packets and In-Rx-Octets fields + should be ignored. + + Reserved + + The Reserved field is 15 bits and is intended to pad the remaining + + + +Perkins & Hobby [Page 23] + +RFC 1172 PPP Initial Options July 1990 + + + packet fields to even four-octet boundaries for the convenience of + hardware implementations. The Reserved field should always be + transmitted as zero and ignored on reception. + + In-Tx-Packets + + The In-Tx-Packets field is four octets and indicates the number of + packets transmitted on the inbound link of the Link-Quality-Report + transmitter during the last measured period. The In-Tx-Packets + field is copied from the In-Tx-Packets state variable on + transmission. + + In-Tx-Octets + + The In-Tx-Octets field is four octets and indicates the number of + octets transmitted on the inbound link of the Link-Quality-Report + transmitter during the last measured period. The In-Tx-Octets + field is copied from the In-Tx-Octets state variable on + transmission. + + In-Rx-Packets + + The In-Rx-Packets field is four octets and indicates the number of + packets received on the inbound link of the Link-Quality-Report + transmitter during the last measured period. The In-Rx-Packets + field is copied from the In-Rx-Packets state variable on + transmission. + + In-Rx-Octets + + The In-Rx-Octets field is four octets and indicates the number of + octets received on the inbound link of the Link-Quality-Report + transmitter during the last measured period. The In-Rx-Octets + field is copied from the In-Rx-Octets state variable on + transmission. + + Out-Tx-Packets + + The Out-Tx-Packets field is four octets and is used to calculate + the number of packets transmitted on the outbound link of the + Link-Quality-Report transmitter during a period. The Out-Tx- + Packets field is copied from the Out-Tx-Packets-Ctr counter on + transmission. + + Out-Tx-Octets + + The Out-Tx-Octets field is four octets and is used to calculate + the number of octets transmitted on the outbound link of the + + + +Perkins & Hobby [Page 24] + +RFC 1172 PPP Initial Options July 1990 + + + Link-Quality-Report transmitter during a period. The Out-Tx- + Octets field is copied from the Out-Tx-Octets-Ctr counter on + transmission. + + In-Rx-Packets + + The In-Rx-Packets field is four octets and is used to calculate + the number of packets received on the inbound link of the Link- + Quality-Report receiver during a period. The In-Rx-Packets field + is copied from the In-Rx-Packets-Ctr counter on reception. The + In-Rx-Packets is not shown because it is not actually transmitted + over the link. Rather, it is logically appended (in an + implementation dependent manner) to the packet by the + implementation's Rx process. + + In-Rx-Octets + + The In-Rx-Octets field is four octets and is used to calculate the + number of octets received on the inbound link of the Link- + Quality-Report receiver during a period. The In-Rx-Octets field + is copied from the In-Rx-Octets-Ctr counter on reception. The + In-Rx-Octets is not shown because it is not actually transmitted + over the link. Rather, it is logically appended (in an + implementation dependent manner) to the packet by the + implementation's Rx process. + +3.7. Policy Suggestions + + Link-Quality-Report packets provide a mechanism to determine the link + quality, but it is up to each implementation to decide when the link + is usable. It is recommended that this policy implement some amount + of hysteresis so that the link does not bounce up and down. A + particularly good policy is to use a K out of N algorithm. In such + an algorithm, there must be K successes out of the last N periods for + the link to be considered of good quality. + + Procedures for recovery from poor quality links are unspecified and + may vary from implementation to implementation. A suggested approach + is to immediately close all other Network-Layer protocols (i.e., + cause IPCP to transmit a Terminate-Req), but to continue transmitting + Link-Quality-Reports. Once the link quality again reaches an + acceptable level, Network-Layer protocols can be reconfigured. + +3.8. Example + + An example may be helpful. Assume that Link-Manager implementation A + transmits a Link-Quality-Report which is received by Link-Manager + implementation B at time t0 with the following values: + + + +Perkins & Hobby [Page 25] + +RFC 1172 PPP Initial Options July 1990 + + + Out-Tx-Packets 5 + Out-Tx-Octets 100 + In-Rx-Packets 3 + In-Rx-Octets 70 + + Assume that A then transmits 20 IP packets with 200 octets, of which + 15 packets and 150 octets are received by B. At time t1, A transmits + another LQR which is received by B as follows: + + Out-Tx-Packets 26 (5 old, plus 20 IP, plus 1 LQR) + Out-Tx-Octets 342 (42 for LQR) + In-Rx-Packets 19 + In-Rx-Octets 262 + + Implementation B can now calculate the number of packets and octets + transmitted, received and lost on its inbound link as follows: + + In-Tx-Packets = 26 - 5 = 21 + In-Tx-Octets = 342 - 100 = 242 + In-Rx-Packets = 10 - 3 = 16 + In-Rx-Octets = 262 - 70 = 192 + In-Lost-Packets = 21 - 16 = 5 + In-Lost-Octets = 242 - 192 = 50 + + After doing these calculations, B evaluates the measurements in what + ever way its implemented policy specifies. Also, the next time that + B transmits an LQR to A, it will report these values in the + Measurements section, thereby allowing A to evaluate these same + measurements. + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 26] + +RFC 1172 PPP Initial Options July 1990 + + +4. Password Authentication Protocol + + The Password Authentication Protocol (PAP) may be used to + authenticate a peer by verifying the identity of the remote end of + the link. Use of the PAP must first be negotiated using the LCP + Authentication-Type Configuration Option. Successful negotiation + adds an additional Authentication phase to the Link Control Protocol, + after the Link Quality Determination phase, and before the Network + Layer Protocol Configuration Negotiation phase. PAP packets received + before the Authentication phase is reached should be silently + discarded. The Authentication phase is exited once an Authenticate- + Ack packet is sent or received. + + PAP is intended for use primarily by hosts and routers that connect + via switched circuits or dial-up lines to a PPP network server. The + server can then use the identification of the connecting host or + router in the selection of options for network layer negotiations or + failing authentication, drop the connection. + + Note that PAP is not a strong authentication method. Passwords are + passed over the circuit in the clear and there is no protection from + repeated trial and error attacks. Work is currently underway on more + secure authentication methods for PPP and other protocols. It is + strongly recommended to switch to these methods when they become + available. + + +4.1. Packet Format + + Exactly one Password Authentication Protocol packet is encapsulated + in the Information field of PPP Data Link Layer frames where the + protocol field indicates type hex c023 (Password Authentication + Protocol). A summary of the Password Authentication Protocol packet + format is shown below. The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Code + + The Code field is one octet and identifies the type of PAP packet. + PAP Codes are assigned as follows: + + + +Perkins & Hobby [Page 27] + +RFC 1172 PPP Initial Options July 1990 + + + 1 Authenticate + 2 Authenticate-Ack + 3 Authenticate-Nak + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. + + Length + + The Length field is two octets and indicates the length of the PAP + packet including the Code, Identifier, Length and Data fields. + Octets outside the range of the Length field should be treated as + Data Link Layer padding and should be ignored on reception. + + Data + + The Data field is zero or more octets. The format of the Data + field is determined by the Code field. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 28] + +RFC 1172 PPP Initial Options July 1990 + + +4.2. Authenticate + + Description + + The Authenticate packet is used to begin the Password + Authentication Protocol. An implementation having sent a LCP + Configure-Ack packet with an Authentication-Type Configuration + Option further specifying the Password Authentication Protocol + must send an Authenticate packet during the Authentication phase. + An implementation receiving a Configure-Ack with said + Configuration Option should expect the remote end to send an + Authenticate packet during this phase. + + An Authenticate packet is sent with the Code field set to 1 + (Authenticate) and the Peer-ID and Password fields filled as + desired. + + Upon reception of an Authenticate, some type of Authenticate reply + MUST be transmitted. + + A summary of the Authenticate packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer-ID Length| Peer-Id ... + +-+-+-+-+-+-+-+-+-+-+-+-+ + | Passwd-Length | Password ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 1 for Authenticate. + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. The Identifier field should be changed each time a + Authenticate is transmitted which is different from the preceding + request. + + Peer-ID-Length + + The Peer-ID-Length field is one octet and indicates the length of + the Peer-ID field + + + +Perkins & Hobby [Page 29] + +RFC 1172 PPP Initial Options July 1990 + + + Peer-ID + + The Peer-ID field is zero or more octets and indicates the name of + the peer to be authenticated. + + Passwd-Length + + The Passwd-Length field is one octet and indicates the length of + the Password field + + Password + + The Password field is zero or more octets and indicates the + password to be used for authentication. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 30] + +RFC 1172 PPP Initial Options July 1990 + + +4.3. Authenticate-Ack + + Description + + If the Peer-ID/Password pair received in an Authenticate is both + recognizable and acceptable, then a PAP implementation should + transmit a PAP packet with the Code field set to 2 (Authenticate- + Ack), the Identifier field copied from the received Authenticate, + and the Message field optionally filled with an ASCII message. + + A summary of the Authenticate-Ack packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Msg-Length | Message ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 2 for Authenticate-Ack. + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. The Identifier field MUST be copied from the + Identifier field of the Authenticate which caused this + Authenticate-Ack. + + Msg-Length + + The Msg-Length field is one octet and indicates the length of the + Message field + + Message + + The Message field is zero or more octets and indicates an ASCII + message. + + + + + + + + + + +Perkins & Hobby [Page 31] + +RFC 1172 PPP Initial Options July 1990 + + +4.4. Authenticate-Nak + + Description + + If the Peer-ID/Password pair received in a Authenticate is not + recognizable or acceptable, then a PAP implementation should + transmit a PAP packet with the Code field set to 3 (Authenticate- + Nak), the Identifier field copied from the received Authenticate, + and the Message field optionally filled with an ASCII message. + + A summary of the Authenticate-Nak packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Msg-Length | Message ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 3 for Authenticate-Nak. + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. The Identifier field MUST be copied from the + Identifier field of the Authenticate which caused this + Authenticate-Nak. + + Msg-Length + + The Msg-Length field is one octet and indicates the length of the + Message field + + Message + + The Message field is zero or more octets and indicates an ASCII + message. + + + + + + + + + + +Perkins & Hobby [Page 32] + +RFC 1172 PPP Initial Options July 1990 + + +5. IP Control Protocol (IPCP) Configuration Options + +IPCP Configuration Options allow negotiatiation of desirable Internet +Protocol parameters. Negotiable modifications proposed in this document +include IP addresses and compression protocols. + +The initial proposed values for the IPCP Configuration Option Type field +(see [1]) are assigned as follows: + + 1 IP-Addresses + 2 Compression-Type + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 33] + +RFC 1172 PPP Initial Options July 1990 + + +5.1. IP-Addresses + + Description + + This Configuration Option provides a way to negotiate the IP + addresses to be used on each end of the link. By default, no IP + addresses are assigned to either end. An address specified as + zero shall be interpreted as requesting the remote end to specify + the address. If an implementation allows the assignment of + multiple IP addresses, then it may include multiple IP Address + Configuration Options in its Configure-Request packets. An + implementation receiving a Configure-Request specifying multiple + IP Address Configuration Options may send a Configure-Reject + specifying one or more of the specified IP Addresses. An + implementation which desires that no IP addresses be assigned + (such as a "half-gateway") may reject all IP Address Configuration + Options. + + A summary of the IP-Addresses Configuration Option format is shown + below. The fields are transmitted from 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 | Source-IP-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Source-IP-Address (cont) | Destination-IP-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Destination-IP-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 1 + + Length + + 10 + + Source-IP-Address + + The four octet Source-IP-Address is the desired local address of + the sender of a Configure-Request. In a Configure-Ack, + Configure-Nak or Configure-Reject, the Source-IP-Address is the + remote address of the sender, and is thus a local address with + respect to the Configuration Option receiver. + + + + + +Perkins & Hobby [Page 34] + +RFC 1172 PPP Initial Options July 1990 + + + Destination-IP-Address + + The four octet Destination-IP-Address is the remote address with + respect to the sender of a Configure-Request. In a Configure-Ack, + Configure-Nak or Configure-Reject, the Destination-IP-Address is + the local address of the sender, and is thus a remote address with + respect to the Configuration Option receiver. + + Default + + No IP addresses assigned. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 35] + +RFC 1172 PPP Initial Options July 1990 + + +5.2. Compression-Type + + Description + + This Configuration Option provides a way to negotiate the use of a + specific compression protocol. By default, compression is not + enabled. + + A summary of the Compression-Type Configuration Option format is + shown below. The fields are transmitted from 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 | Compression-Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Type + + 2 + + Length + + >= 4 + + Compression-Type + + The Compression-Type field is two octets and indicates the type of + compression protocol desired. Values for the Compression-Type are + always the same as the PPP Data Link Layer Protocol field values + for that same compression protocol. The most up-to-date values of + the Compression-Type field are specified in "Assigned Numbers" + [2]. Initial values are assigned as follows: + + Value (in hex) Protocol + + 0037 Van Jacobson Compressed TCP/IP + + Data + + The Data field is zero or more octets and contains additional data + as determined by the compression protocol indicated in the + Compression-Type field. + + + + + + +Perkins & Hobby [Page 36] + +RFC 1172 PPP Initial Options July 1990 + + + Default + + No compression protocol enabled. + + +References + + [1] Perkins, D., "The Point-to-Point Protocol for the Transmission + of Multi-Protocol of Datagrams Over Point-to-Point Links", RFC + 1171, July, 1990. + + [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, + USC/Information Sciences Institute, March 1990. + + +Security Considerations + + Security issues are discussed in Section 2.3. + + +Author's Address + + This proposal is the product of the Point-to-Point Protocol Working + Group of the Internet Engineering Task Force (IETF). The working + group can be contacted via the chair: + + Russ Hobby + UC Davis + Computing Services + Davis, CA 95616 + + Phone: (916) 752-0236 + + EMail: rdhobby@ucdavis.edu + + Questions about this memo can also be directed to: + + Drew D. Perkins + Carnegie Mellon University + Networking and Communications + Pittsburgh, PA 15213 + + Phone: (412) 268-8576 + + EMail: ddp@andrew.cmu.edu + + + + + + +Perkins & Hobby [Page 37] + +RFC 1172 PPP Initial Options July 1990 + + +Acknowledgments + + Many people spent significant time helping to develop the Point-to- + Point Protocol. The complete list of people is too numerous to list, + but the following people deserve special thanks: Ken Adelman (TGV), + Craig Fox (NSC), Phill Gross (NRI), Russ Hobby (UC Davis), David + Kaufman (Proteon), John LoVerso (Xylogics), Bill Melohn (Sun + Microsystems), Mike Patton (MIT), Drew Perkins (CMU), Greg Satz + (cisco systems) and Asher Waldfogel (Wellfleet). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 38] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/rfc/rfc1332.txt b/rfc/rfc1332.txt new file mode 100644 index 00000000..3e120425 --- /dev/null +++ b/rfc/rfc1332.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group G. McGregor +Request for Comments: 1332 Merit +Obsoletes: RFC 1172 May 1992 + + + + The PPP Internet Protocol Control Protocol (IPCP) + + + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" 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 of + encapsulating Network Layer protocol information over point-to-point + links. PPP also defines an extensible Link Control Protocol, and + proposes a family of Network Control Protocols (NCPs) for + establishing and configuring different network-layer protocols. + + This document defines the NCP for establishing and configuring the + Internet Protocol [2] over PPP, and a method to negotiate and use Van + Jacobson TCP/IP header compression [3] with PPP. + + This RFC is a product of the Point-to-Point Protocol Working Group of + the Internet Engineering Task Force (IETF). + + + + + + + + + + + + + + + + + + + +McGregor [Page i] + +RFC 1332 PPP IPCP May 1992 + + +Table of Contents + + + 1. Introduction .......................................... 1 + + 2. A PPP Network Control Protocol (NCP) for IP ........... 2 + 2.1 Sending IP Datagrams ............................ 2 + + 3. IPCP Configuration Options ............................ 4 + 3.1 IP-Addresses .................................... 5 + 3.2 IP-Compression-Protocol ......................... 6 + 3.3 IP-Address ...................................... 8 + + 4. Van Jacobson TCP/IP header compression ................ 9 + 4.1 Configuration Option Format ..................... 9 + + APPENDICES ................................................... 11 + + A. IPCP Recommended Options .............................. 11 + + SECURITY CONSIDERATIONS ...................................... 11 + + REFERENCES ................................................... 11 + + ACKNOWLEDGEMENTS ............................................. 11 + + CHAIR'S ADDRESS .............................................. 12 + + AUTHOR'S ADDRESS ............................................. 12 + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page ii] + +RFC 1332 PPP IPCP May 1992 + + +1. Introduction + + PPP has three main components: + + 1. A method for encapsulating datagrams over serial links. + + 2. A Link Control Protocol (LCP) for establishing, configuring, + and testing the data-link connection. + + 3. A family of Network Control Protocols (NCPs) for establishing + and configuring different network-layer protocols. + + In order to establish communications over a point-to-point link, each + end of the PPP link must first send LCP packets to configure and test + the data link. After the link has been established and optional + facilities have been negotiated as needed by the LCP, PPP must send + NCP packets to choose and configure one or more network-layer + protocols. Once each of the chosen network-layer protocols has been + configured, datagrams from each network-layer protocol can be sent + over the link. + + The link will remain configured for communications until explicit LCP + or NCP packets close the link down, or until some external event + occurs (an inactivity timer expires or network administrator + intervention). + + + + + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 1] + +RFC 1332 PPP IPCP May 1992 + + +2. A PPP Network Control Protocol (NCP) for IP + + The IP Control Protocol (IPCP) is responsible for configuring, + enabling, and disabling the IP protocol modules on both ends of the + point-to-point link. IPCP uses the same packet exchange machanism as + the Link Control Protocol (LCP). IPCP packets may not be exchanged + until PPP has reached the Network-Layer Protocol phase. IPCP packets + received before this phase is reached should be silently discarded. + + The IP Control Protocol is exactly the same as the Link Control + Protocol [1] with the following exceptions: + + Data Link Layer Protocol Field + + Exactly one IPCP packet is encapsulated in the Information field + of PPP Data Link Layer frames where the Protocol field indicates + type hex 8021 (IP Control Protocol). + + Code field + + Only Codes 1 through 7 (Configure-Request, Configure-Ack, + Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack + and Code-Reject) are used. Other Codes should be treated as + unrecognized and should result in Code-Rejects. + + Timeouts + + IPCP 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 timing out waiting for a Configure-Ack or other + response. It is suggested that an implementation give up only + after user intervention or a configurable amount of time. + + Configuration Option Types + + IPCP has a distinct set of Configuration Options, which are + defined below. + +2.1. Sending IP Datagrams + + Before any IP packets may be communicated, PPP must reach the + Network-Layer Protocol phase, and the IP Control Protocol must reach + the Opened state. + + Exactly one IP packet is encapsulated in the Information field of PPP + Data Link Layer frames where the Protocol field indicates type hex + 0021 (Internet Protocol). + + + +McGregor [Page 2] + +RFC 1332 PPP IPCP May 1992 + + + The maximum length of an IP packet transmitted over a PPP link is the + same as the maximum length of the Information field of a PPP data + link layer frame. Larger IP datagrams must be fragmented as + necessary. If a system wishes to avoid fragmentation and reassembly, + it should use the TCP Maximum Segment Size option [4], and MTU + discovery [5]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 3] + +RFC 1332 PPP IPCP May 1992 + + +3. IPCP Configuration Options + +IPCP Configuration Options allow negotiatiation of desirable Internet +Protocol parameters. IPCP uses the same Configuration Option format +defined for LCP [1], with a separate set of Options. + +The most up-to-date values of the IPCP Option Type field are specified +in the most recent "Assigned Numbers" RFC [6]. Current values are +assigned as follows: + + 1 IP-Addresses + 2 IP-Compression-Protocol + 3 IP-Address + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 4] + +RFC 1332 PPP IPCP May 1992 + + +3.1. IP-Addresses + + Description + + The use of the Configuration Option IP-Addresses has been + deprecated. It has been determined through implementation + experience that it is difficult to ensure negotiation convergence + in all cases using this option. RFC 1172 [7] provides information + for implementations requiring backwards compatability. The IP- + Address Configuration Option replaces this option, and its use is + preferred. + + This option SHOULD NOT be sent in a Configure-Request if a + Configure-Request has been received which includes either an IP- + Addresses or IP-Address option. This option MAY be sent if a + Configure-Reject is received for the IP-Address option, or a + Configure-Nak is received with an IP-Addresses option as an + appended option. + + Support for this option MAY be removed after the IPCP protocol + status advances to Internet Draft Standard. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 5] + +RFC 1332 PPP IPCP May 1992 + + +3.2. IP-Compression-Protocol + + Description + + This Configuration Option provides a way to negotiate the use of a + specific compression protocol. By default, compression is not + enabled. + + A summary of the IP-Compression-Protocol Configuration Option format + is shown below. The fields are transmitted from 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 | IP-Compression-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Type + + 2 + + Length + + >= 4 + + IP-Compression-Protocol + + The IP-Compression-Protocol field is two octets and indicates the + compression protocol desired. Values for this field are always + the same as the PPP Data Link Layer Protocol field values for that + same compression protocol. + + The most up-to-date values of the IP-Compression-Protocol field + are specified in the most recent "Assigned Numbers" RFC [6]. + Current values are assigned as follows: + + Value (in hex) Protocol + + 002d Van Jacobson Compressed TCP/IP + + Data + + The Data field is zero or more octets and contains additional data + as determined by the particular compression protocol. + + + + + +McGregor [Page 6] + +RFC 1332 PPP IPCP May 1992 + + + Default + + No compression protocol enabled. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 7] + +RFC 1332 PPP IPCP May 1992 + + +3.3. IP-Address + + Description + + This Configuration Option provides a way to negotiate the IP + address to be used on the local end of the link. It allows the + sender of the Configure-Request to state which IP-address is + desired, or to request that the peer provide the information. The + peer can provide this information by NAKing the option, and + returning a valid IP-address. + + If negotiation about the remote IP-address is required, and the + peer did not provide the option in its Configure-Request, the + option SHOULD be appended to a Configure-Nak. The value of the + IP-address given must be acceptable as the remote IP-address, or + indicate a request that the peer provide the information. + + By default, no IP address is assigned. + + A summary of the IP-Address Configuration Option format is shown + below. The fields are transmitted from 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 | IP-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + IP-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 3 + + Length + + 6 + + IP-Address + + The four octet IP-Address is the desired local address of the + sender of a Configure-Request. If all four octets are set to + zero, it indicates a request that the peer provide the IP-Address + information. + + Default + + No IP address is assigned. + + + +McGregor [Page 8] + +RFC 1332 PPP IPCP May 1992 + + +4. Van Jacobson TCP/IP header compression + +Van Jacobson TCP/IP header compression reduces the size of the TCP/IP +headers to as few as three bytes. This can be a significant improvement +on slow serial lines, particularly for interactive traffic. + +The IP-Compression-Protocol Configuration Option is used to indicate the +ability to receive compressed packets. Each end of the link must +separately request this option if bi-directional compression is desired. + +The PPP Protocol field is set to the following values when transmitting +IP packets: + + Value (in hex) + + 0021 Type IP. The IP protocol is not TCP, or the packet is a + fragment, or cannot be compressed. + + 002d Compressed TCP. The TCP/IP headers are replaced by the + compressed header. + + 002f Uncompressed TCP. The IP protocol field is replaced by + the slot identifier. + +4.1. Configuration Option Format + + A summary of the IP-Compression-Protocol Configuration Option format + to negotiate Van Jacobson TCP/IP header compression is shown below. + The fields are transmitted from 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 | IP-Compression-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Max-Slot-Id | Comp-Slot-Id | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 2 + + Length + + 6 + + + + + + +McGregor [Page 9] + +RFC 1332 PPP IPCP May 1992 + + + IP-Compression-Protocol + + 002d (hex) for Van Jacobson Compressed TCP/IP headers. + + Max-Slot-Id + + The Max-Slot-Id field is one octet and indicates the maximum slot + identifier. This is one less than the actual number of slots; the + slot identifier has values from zero to Max-Slot-Id. + + Note: There may be implementations that have problems with only + one slot (Max-Slot-Id = 0). See the discussion in reference + [3]. The example implementation in [3] will only work with 3 + through 254 slots. + + Comp-Slot-Id + + The Comp-Slot-Id field is one octet and indicates whether the slot + identifier field may be compressed. + + 0 The slot identifier must not be compressed. All compressed + TCP packets must set the C bit in every change mask, and + must include the slot identifier. + + 1 The slot identifer may be compressed. + + The slot identifier must not be compressed if there is no ability + for the PPP link level to indicate an error in reception to the + decompression module. Synchronization after errors depends on + receiving a packet with the slot identifier. See the discussion + in reference [3]. + + + + + + + + + + + + + + + + + + + + +McGregor [Page 10] + +RFC 1332 PPP IPCP May 1992 + + +A. IPCP Recommended Options + + The following Configurations Options are recommended: + + IP-Compression-Protocol -- with at least 4 slots, usually 16 + slots. + + IP-Address -- only on dial-up lines. + + +Security Considerations + + Security issues are not discussed in this memo. + + +References + + [1] Simpson, W., "The Point-to-Point Protocol", RFC 1331, May 1992. + + [2] Postel, J., "Internet Protocol", RFC 791, USC/Information + Sciences Institute, September 1981. + + [3] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, January + 1990. + + [4] Postel, J., "The TCP Maximum Segment Size Option and Related + Topics", RFC 879, USC/Information Sciences Institute, November + 1983. + + [5] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, + November 1990. + + [6] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, + USC/Information Sciences Institute, March 1990. + + [7] Perkins, D., and R. Hobby, "Point-to-Point Protocol (PPP) + initial configuration options", RFC 1172, August 1990. + + +Acknowledgments + + Some of the text in this document is taken from RFCs 1171 & 1172, by + Drew Perkins of Carnegie Mellon University, and by Russ Hobby of the + University of California at Davis. + + Information leading to the expanded IP-Compression option provided by + Van Jacobson at SIGCOMM '90. + + + + +McGregor [Page 11] + +RFC 1332 PPP IPCP May 1992 + + + Bill Simpson helped with the document formatting. + + +Chair's Address + + The working group can be contacted via the current chair: + + Brian Lloyd + Lloyd & Associates + 3420 Sudbury Road + Cameron Park, California 95682 + + Phone: (916) 676-1147 + + EMail: brian@ray.lloyd.com + + + +Author's Address + + Questions about this memo can also be directed to: + + Glenn McGregor + Merit Network, Inc. + 1071 Beal Avenue + Ann Arbor, MI 48109-2103 + + Phone: (313) 763-1203 + + EMail: Glenn.McGregor@Merit.edu + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 12] + diff --git a/rfc/rfc1334.txt b/rfc/rfc1334.txt new file mode 100644 index 00000000..6051f480 --- /dev/null +++ b/rfc/rfc1334.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group B. Lloyd +Request for Comments: 1334 L&A + W. Simpson + Daydreamer + October 1992 + + + PPP Authentication Protocols + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" 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 of + encapsulating Network Layer protocol information over point-to-point + links. PPP also defines an extensible Link Control Protocol, which + allows negotiation of an Authentication Protocol for authenticating + its peer before allowing Network Layer protocols to transmit over the + link. + + This document defines two protocols for Authentication: the Password + Authentication Protocol and the Challenge-Handshake Authentication + Protocol. This memo is the product of the Point-to-Point Protocol + Working Group of the Internet Engineering Task Force (IETF). + Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu + mailing list. + +Table of Contents + + 1. Introduction ............................................... 2 + 1.1 Specification Requirements ................................. 2 + 1.2 Terminology ................................................ 3 + 2. Password Authentication Protocol ............................ 3 + 2.1 Configuration Option Format ................................ 4 + 2.2 Packet Format .............................................. 5 + 2.2.1 Authenticate-Request ..................................... 5 + 2.2.2 Authenticate-Ack and Authenticate-Nak .................... 7 + 3. Challenge-Handshake Authentication Protocol.................. 8 + 3.1 Configuration Option Format ................................ 9 + 3.2 Packet Format .............................................. 10 + 3.2.1 Challenge and Response ................................... 11 + 3.2.2 Success and Failure ...................................... 13 + + + +Lloyd & Simpson [Page 1] + +RFC 1334 PPP Authentication October 1992 + + + SECURITY CONSIDERATIONS ........................................ 14 + REFERENCES ..................................................... 15 + ACKNOWLEDGEMENTS ............................................... 16 + CHAIR'S ADDRESS ................................................ 16 + AUTHOR'S ADDRESS ............................................... 16 + +1. Introduction + + PPP has three main components: + + 1. A method for encapsulating datagrams over serial links. + + 2. A Link Control Protocol (LCP) for establishing, configuring, + and testing the data-link connection. + + 3. A family of Network Control Protocols (NCPs) for establishing + and configuring different network-layer protocols. + + In order to establish communications over a point-to-point link, each + end of the PPP link must first send LCP packets to configure the data + link during Link Establishment phase. After the link has been + established, PPP provides for an optional Authentication phase before + proceeding to the Network-Layer Protocol phase. + + By default, authentication is not mandatory. If authentication of + the link is desired, an implementation MUST specify the + Authentication-Protocol Configuration Option during Link + Establishment phase. + + These authentication protocols are intended for use primarily by + hosts and routers that connect to a PPP network server via switched + circuits or dial-up lines, but might be applied to dedicated links as + well. The server can use the identification of the connecting host + or router in the selection of options for network layer negotiations. + + This document defines the PPP authentication protocols. The Link + Establishment and Authentication phases, and the Authentication- + Protocol Configuration Option, are defined in The Point-to-Point + Protocol (PPP) [1]. + +1.1. Specification Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST + This word, or the adjective "required", means that the definition + is an absolute requirement of the specification. + + + +Lloyd & Simpson [Page 2] + +RFC 1334 PPP Authentication October 1992 + + + MUST NOT + This phrase means that the definition is an absolute prohibition + of the specification. + + SHOULD + This word, or the adjective "recommended", means that there may + exist valid reasons in particular circumstances to ignore this + item, but the full implications should be understood and carefully + weighed before choosing a different course. + + MAY + This word, or the adjective "optional", means that this item is + one of an allowed set of alternatives. An implementation which + does not include this option MUST be prepared to interoperate with + another implementation which does include the option. + +1.2. Terminology + + This document frequently uses the following terms: + + authenticator + The end of the link requiring the authentication. The + authenticator specifies the authentication protocol to be used in + the Configure-Request during Link Establishment phase. + + peer + The other end of the point-to-point link; the end which is being + authenticated by the authenticator. + + silently discard + This means the implementation discards the packet without further + processing. The implementation SHOULD provide the capability of + logging the error, including the contents of the silently + discarded packet, and SHOULD record the event in a statistics + counter. + +2. Password Authentication Protocol + + The Password Authentication Protocol (PAP) provides a simple method + for the peer to establish its identity using a 2-way handshake. This + is done only upon initial link establishment. + + After the Link Establishment phase is complete, an Id/Password pair + is repeatedly sent by the peer to the authenticator until + authentication is acknowledged or the connection is terminated. + + PAP is not a strong authentication method. Passwords are sent over + the circuit "in the clear", and there is no protection from playback + + + +Lloyd & Simpson [Page 3] + +RFC 1334 PPP Authentication October 1992 + + + or repeated trial and error attacks. The peer is in control of the + frequency and timing of the attempts. + + Any implementations which include a stronger authentication method + (such as CHAP, described below) MUST offer to negotiate that method + prior to PAP. + + This authentication method is most appropriately used where a + plaintext password must be available to simulate a login at a remote + host. In such use, this method provides a similar level of security + to the usual user login at the remote host. + + Implementation Note: It is possible to limit the exposure of the + plaintext password to transmission over the PPP link, and avoid + sending the plaintext password over the entire network. When the + remote host password is kept as a one-way transformed value, and + the algorithm for the transform function is implemented in the + local server, the plaintext password SHOULD be locally transformed + before comparison with the transformed password from the remote + host. + +2.1. Configuration Option Format + + A summary of the Authentication-Protocol Configuration Option format + to negotiate the Password Authentication Protocol is shown below. + The fields are transmitted from 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 | Authentication-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 3 + + Length + + 4 + + Authentication-Protocol + + c023 (hex) for Password Authentication Protocol. + + Data + + There is no Data field. + + + +Lloyd & Simpson [Page 4] + +RFC 1334 PPP Authentication October 1992 + + +2.2. Packet Format + + Exactly one Password Authentication Protocol packet is encapsulated + in the Information field of a PPP Data Link Layer frame where the + protocol field indicates type hex c023 (Password Authentication + Protocol). A summary of the PAP packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Code + + The Code field is one octet and identifies the type of PAP packet. + PAP Codes are assigned as follows: + + 1 Authenticate-Request + 2 Authenticate-Ack + 3 Authenticate-Nak + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. + + Length + + The Length field is two octets and indicates the length of the PAP + packet including the Code, Identifier, Length and Data fields. + Octets outside the range of the Length field should be treated as + Data Link Layer padding and should be ignored on reception. + + Data + + The Data field is zero or more octets. The format of the Data + field is determined by the Code field. + +2.2.1. Authenticate-Request + + Description + + The Authenticate-Request packet is used to begin the Password + Authentication Protocol. The link peer MUST transmit a PAP packet + + + +Lloyd & Simpson [Page 5] + +RFC 1334 PPP Authentication October 1992 + + + with the Code field set to 1 (Authenticate-Request) during the + Authentication phase. The Authenticate-Request packet MUST be + repeated until a valid reply packet is received, or an optional + retry counter expires. + + The authenticator SHOULD expect the peer to send an Authenticate- + Request packet. Upon reception of an Authenticate-Request packet, + some type of Authenticate reply (described below) MUST be + returned. + + Implementation Note: Because the Authenticate-Ack might be + lost, the authenticator MUST allow repeated Authenticate- + Request packets after completing the Authentication phase. + Protocol phase MUST return the same reply Code returned when + the Authentication phase completed (the message portion MAY be + different). Any Authenticate-Request packets received during + any other phase MUST be silently discarded. + + When the Authenticate-Nak is lost, and the authenticator + terminates the link, the LCP Terminate-Request and Terminate- + Ack provide an alternative indication that authentication + failed. + + A summary of the Authenticate-Request packet format is shown below. + The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer-ID Length| Peer-Id ... + +-+-+-+-+-+-+-+-+-+-+-+-+ + | Passwd-Length | Password ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 1 for Authenticate-Request. + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. The Identifier field MUST be changed each time an + Authenticate-Request packet is issued. + + + + + + +Lloyd & Simpson [Page 6] + +RFC 1334 PPP Authentication October 1992 + + + Peer-ID-Length + + The Peer-ID-Length field is one octet and indicates the length of + the Peer-ID field. + + Peer-ID + + The Peer-ID field is zero or more octets and indicates the name of + the peer to be authenticated. + + Passwd-Length + + The Passwd-Length field is one octet and indicates the length of + the Password field. + + Password + + The Password field is zero or more octets and indicates the + password to be used for authentication. + +2.2.2. Authenticate-Ack and Authenticate-Nak + + Description + + If the Peer-ID/Password pair received in an Authenticate-Request + is both recognizable and acceptable, then the authenticator MUST + transmit a PAP packet with the Code field set to 2 (Authenticate- + Ack). + + If the Peer-ID/Password pair received in a Authenticate-Request is + not recognizable or acceptable, then the authenticator MUST + transmit a PAP packet with the Code field set to 3 (Authenticate- + Nak), and SHOULD take action to terminate the link. + + A summary of the Authenticate-Ack and Authenticate-Nak packet format + is shown below. The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Msg-Length | Message ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 2 for Authenticate-Ack; + + + +Lloyd & Simpson [Page 7] + +RFC 1334 PPP Authentication October 1992 + + + 3 for Authenticate-Nak. + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. The Identifier field MUST be copied from the + Identifier field of the Authenticate-Request which caused this + reply. + + Msg-Length + + The Msg-Length field is one octet and indicates the length of the + Message field. + + Message + + The Message field is zero or more octets, and its contents are + implementation dependent. It is intended to be human readable, + and MUST NOT affect operation of the protocol. It is recommended + that the message contain displayable ASCII characters 32 through + 126 decimal. Mechanisms for extension to other character sets are + the topic of future research. + +3. Challenge-Handshake Authentication Protocol + + The Challenge-Handshake Authentication Protocol (CHAP) is used to + periodically verify the identity of the peer using a 3-way handshake. + This is done upon initial link establishment, and MAY be repeated + anytime after the link has been established. + + After the Link Establishment phase is complete, the authenticator + sends a "challenge" message to the peer. The peer responds with a + value calculated using a "one-way hash" function. The authenticator + checks the response against its own calculation of the expected hash + value. If the values match, the authentication is acknowledged; + otherwise the connection SHOULD be terminated. + + CHAP provides protection against playback attack through the use of + an incrementally changing identifier and a variable challenge value. + The use of repeated challenges is intended to limit the time of + exposure to any single attack. The authenticator is in control of + the frequency and timing of the challenges. + + This authentication method depends upon a "secret" known only to the + authenticator and that peer. The secret is not sent over the link. + This method is most likely used where the same secret is easily + accessed from both ends of the link. + + + + +Lloyd & Simpson [Page 8] + +RFC 1334 PPP Authentication October 1992 + + + Implementation Note: CHAP requires that the secret be available in + plaintext form. To avoid sending the secret over other links in + the network, it is recommended that the challenge and response + values be examined at a central server, rather than each network + access server. Otherwise, the secret SHOULD be sent to such + servers in a reversably encrypted form. + + The CHAP algorithm requires that the length of the secret MUST be at + least 1 octet. The secret SHOULD be at least as large and + unguessable as a well-chosen password. It is preferred that the + secret be at least the length of the hash value for the hashing + algorithm chosen (16 octets for MD5). This is to ensure a + sufficiently large range for the secret to provide protection against + exhaustive search attacks. + + The one-way hash algorithm is chosen such that it is computationally + infeasible to determine the secret from the known challenge and + response values. + + The challenge value SHOULD satisfy two criteria: uniqueness and + unpredictability. Each challenge value SHOULD be unique, since + repetition of a challenge value in conjunction with the same secret + would permit an attacker to reply with a previously intercepted + response. Since it is expected that the same secret MAY be used to + authenticate with servers in disparate geographic regions, the + challenge SHOULD exhibit global and temporal uniqueness. Each + challenge value SHOULD also be unpredictable, least an attacker trick + a peer into responding to a predicted future challenge, and then use + the response to masquerade as that peer to an authenticator. + Although protocols such as CHAP are incapable of protecting against + realtime active wiretapping attacks, generation of unique + unpredictable challenges can protect against a wide range of active + attacks. + + A discussion of sources of uniqueness and probability of divergence + is included in the Magic-Number Configuration Option [1]. + +3.1. Configuration Option Format + + A summary of the Authentication-Protocol Configuration Option format + to negotiate the Challenge-Handshake Authentication Protocol is shown + below. The fields are transmitted from left to right. + + + + + + + + + +Lloyd & Simpson [Page 9] + +RFC 1334 PPP Authentication October 1992 + + + 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 | Authentication-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Algorithm | + +-+-+-+-+-+-+-+-+ + + Type + + 3 + + Length + + 5 + + Authentication-Protocol + + c223 (hex) for Challenge-Handshake Authentication Protocol. + + Algorithm + + The Algorithm field is one octet and indicates the one-way hash + method to be used. The most up-to-date values of the CHAP + Algorithm field are specified in the most recent "Assigned + Numbers" RFC [2]. Current values are assigned as follows: + + 0-4 unused (reserved) + 5 MD5 [3] + +3.2. Packet Format + + Exactly one Challenge-Handshake Authentication Protocol packet is + encapsulated in the Information field of a PPP Data Link Layer frame + where the protocol field indicates type hex c223 (Challenge-Handshake + Authentication Protocol). A summary of the CHAP packet format is + shown below. The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + + + + +Lloyd & Simpson [Page 10] + +RFC 1334 PPP Authentication October 1992 + + + Code + + The Code field is one octet and identifies the type of CHAP + packet. CHAP Codes are assigned as follows: + + 1 Challenge + 2 Response + 3 Success + 4 Failure + + Identifier + + The Identifier field is one octet and aids in matching challenges, + responses and replies. + + Length + + The Length field is two octets and indicates the length of the + CHAP packet including the Code, Identifier, Length and Data + fields. Octets outside the range of the Length field should be + treated as Data Link Layer padding and should be ignored on + reception. + + Data + + The Data field is zero or more octets. The format of the Data + field is determined by the Code field. + +3.2.1. Challenge and Response + + Description + + The Challenge packet is used to begin the Challenge-Handshake + Authentication Protocol. The authenticator MUST transmit a CHAP + packet with the Code field set to 1 (Challenge). Additional + Challenge packets MUST be sent until a valid Response packet is + received, or an optional retry counter expires. + + A Challenge packet MAY also be transmitted at any time during the + Network-Layer Protocol phase to ensure that the connection has not + been altered. + + The peer SHOULD expect Challenge packets during the Authentication + phase and the Network-Layer Protocol phase. Whenever a Challenge + packet is received, the peer MUST transmit a CHAP packet with the + Code field set to 2 (Response). + + Whenever a Response packet is received, the authenticator compares + + + +Lloyd & Simpson [Page 11] + +RFC 1334 PPP Authentication October 1992 + + + the Response Value with its own calculation of the expected value. + Based on this comparison, the authenticator MUST send a Success or + Failure packet (described below). + + Implementation Note: Because the Success might be lost, the + authenticator MUST allow repeated Response packets after + completing the Authentication phase. To prevent discovery of + alternative Names and Secrets, any Response packets received + having the current Challenge Identifier MUST return the same + reply Code returned when the Authentication phase completed + (the message portion MAY be different). Any Response packets + received during any other phase MUST be silently discarded. + + When the Failure is lost, and the authenticator terminates the + link, the LCP Terminate-Request and Terminate-Ack provide an + alternative indication that authentication failed. + + A summary of the Challenge and Response packet format is shown below. + The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value-Size | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Name ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 1 for Challenge; + + 2 for Response. + + Identifier + + The Identifier field is one octet. The Identifier field MUST be + changed each time a Challenge is sent. + + The Response Identifier MUST be copied from the Identifier field + of the Challenge which caused the Response. + + Value-Size + + This field is one octet and indicates the length of the Value + field. + + + +Lloyd & Simpson [Page 12] + +RFC 1334 PPP Authentication October 1992 + + + Value + + The Value field is one or more octets. The most significant octet + is transmitted first. + + The Challenge Value is a variable stream of octets. The + importance of the uniqueness of the Challenge Value and its + relationship to the secret is described above. The Challenge + Value MUST be changed each time a Challenge is sent. The length + of the Challenge Value depends upon the method used to generate + the octets, and is independent of the hash algorithm used. + + The Response Value is the one-way hash calculated over a stream of + octets consisting of the Identifier, followed by (concatenated + with) the "secret", followed by (concatenated with) the Challenge + Value. The length of the Response Value depends upon the hash + algorithm used (16 octets for MD5). + + Name + + The Name field is one or more octets representing the + identification of the system transmitting the packet. There are + no limitations on the content of this field. For example, it MAY + contain ASCII character strings or globally unique identifiers in + ASN.1 syntax. The Name should not be NUL or CR/LF terminated. + The size is determined from the Length field. + + Since CHAP may be used to authenticate many different systems, the + content of the name field(s) may be used as a key to locate the + proper secret in a database of secrets. This also makes it + possible to support more than one name/secret pair per system. + +3.2.2. Success and Failure + + Description + + If the Value received in a Response is equal to the expected + value, then the implementation MUST transmit a CHAP packet with + the Code field set to 3 (Success). + + If the Value received in a Response is not equal to the expected + value, then the implementation MUST transmit a CHAP packet with + the Code field set to 4 (Failure), and SHOULD take action to + terminate the link. + + A summary of the Success and Failure packet format is shown below. + The fields are transmitted from left to right. + + + + +Lloyd & Simpson [Page 13] + +RFC 1334 PPP Authentication October 1992 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 3 for Success; + + 4 for Failure. + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. The Identifier field MUST be copied from the + Identifier field of the Response which caused this reply. + + Message + + The Message field is zero or more octets, and its contents are + implementation dependent. It is intended to be human readable, + and MUST NOT affect operation of the protocol. It is recommended + that the message contain displayable ASCII characters 32 through + 126 decimal. Mechanisms for extension to other character sets are + the topic of future research. The size is determined from the + Length field. + +Security Considerations + + Security issues are the primary topic of this RFC. + + The interaction of the authentication protocols within PPP are + highly implementation dependent. This is indicated by the use of + SHOULD throughout the document. + + For example, upon failure of authentication, some implementations + do not terminate the link. Instead, the implementation limits the + kind of traffic in the Network-Layer Protocols to a filtered + subset, which in turn allows the user opportunity to update + secrets or send mail to the network administrator indicating a + problem. + + There is no provision for re-tries of failed authentication. + However, the LCP state machine can renegotiate the authentication + protocol at any time, thus allowing a new attempt. It is + + + +Lloyd & Simpson [Page 14] + +RFC 1334 PPP Authentication October 1992 + + + recommended that any counters used for authentication failure not + be reset until after successful authentication, or subsequent + termination of the failed link. + + There is no requirement that authentication be full duplex or that + the same protocol be used in both directions. It is perfectly + acceptable for different protocols to be used in each direction. + This will, of course, depend on the specific protocols negotiated. + + In practice, within or associated with each PPP server, there is a + database which associates "user" names with authentication + information ("secrets"). It is not anticipated that a particular + named user would be authenticated by multiple methods. This would + make the user vulnerable to attacks which negotiate the least + secure method from among a set (such as PAP rather than CHAP). + Instead, for each named user there should be an indication of + exactly one method used to authenticate that user name. If a user + needs to make use of different authentication method under + different circumstances, then distinct user names SHOULD be + employed, each of which identifies exactly one authentication + method. + + Passwords and other secrets should be stored at the respective + ends such that access to them is as limited as possible. Ideally, + the secrets should only be accessible to the process requiring + access in order to perform the authentication. + + The secrets should be distributed with a mechanism that limits the + number of entities that handle (and thus gain knowledge of) the + secret. Ideally, no unauthorized person should ever gain + knowledge of the secrets. It is possible to achieve this with + SNMP Security Protocols [4], but such a mechanism is outside the + scope of this specification. + + Other distribution methods are currently undergoing research and + experimentation. The SNMP Security document also has an excellent + overview of threats to network protocols. + +References + + [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331, + Daydreamer, May 1992. + + [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1340, + USC/Information Sciences Institute, July 1992. + + + + + + +Lloyd & Simpson [Page 15] + +RFC 1334 PPP Authentication October 1992 + + + [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", MIT + Laboratory for Computer Science and RSA Data Security, Inc. RFC + 1321, April 1992. + + [4] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security + Protocols", Trusted Information Systems, Inc., Hughes LAN + Systems, Inc., MIT Laboratory for Computer Science, RFC 1352, + July 1992. + +Acknowledgments + + Some of the text in this document is taken from RFC 1172, by Drew + Perkins of Carnegie Mellon University, and by Russ Hobby of the + University of California at Davis. + + Special thanks to Dave Balenson, Steve Crocker, James Galvin, and + Steve Kent, for their extensive explanations and suggestions. Now, + if only we could get them to agree with each other. + +Chair's Address + + The working group can be contacted via the current chair: + + Brian Lloyd + Lloyd & Associates + 3420 Sudbury Road + Cameron Park, California 95682 + + Phone: (916) 676-1147 + + EMail: brian@lloyd.com + +Author's Address + + Questions about this memo can also be directed to: + + William Allen Simpson + Daydreamer + Computer Systems Consulting Services + P O Box 6205 + East Lansing, MI 48826-6205 + + EMail: Bill.Simpson@um.cc.umich.edu + + + + + + + + +Lloyd & Simpson [Page 16] +
\ No newline at end of file diff --git a/rfc/rfc1548.txt b/rfc/rfc1548.txt new file mode 100644 index 00000000..7b8a33a2 --- /dev/null +++ b/rfc/rfc1548.txt @@ -0,0 +1,2971 @@ + + + + + + +Network Working Group W. Simpson +Request for Comments: 1548 Daydreamer +Obsoletes: RFC 1331 December 1993 +Category: Standards Track + + + The Point-to-Point Protocol (PPP) + +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) provides a standard method for + transporting multi-protocol datagrams over point-to-point links. PPP + is comprised of three main components: + + 1. A method for encapsulating multi-protocol datagrams. + + 2. A Link Control Protocol (LCP) for establishing, configuring, + and testing the data-link connection. + + 3. A family of Network Control Protocols (NCPs) for establishing + and configuring different network-layer protocols. + + This document defines the PPP organization and methodology, and the + PPP encapsulation, together with an extensible option negotiation + mechanism which is able to negotiate a rich assortment of + configuration parameters and provides additional management + functions. The PPP Link Control Protocol (LCP) is described in terms + of this mechanism. + + This document is the product of the Point-to-Point Protocol Working + Group of the Internet Engineering Task Force (IETF). Comments should + be submitted to the ietf-ppp@ucdavis.edu mailing list. + + + + + + + + + + + +Simpson [Page 1] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +Table of Contents + + 1. Introduction ................................................3 + 1.1 Specification of Requirements ...............................4 + 1.2 Terminology .................................................5 + 2. PPP Encapsulation ...........................................5 + 3. PPP Link Operation ..........................................8 + 3.1 Overview ....................................................8 + 3.2 Phase Diagram ...............................................8 + 3.3 Link Dead (physical-layer not ready) ........................9 + 3.4 Link Establishment Phase ....................................9 + 3.5 Authentication Phase ........................................9 + 3.6 Network-Layer Protocol Phase ................................10 + 3.7 Link Termination Phase ......................................10 + 4. The Option Negotiation Automaton ............................11 + 4.1 State Diagram ...............................................12 + 4.2 State Transition Table ......................................14 + 4.3 A Day in the Life ...........................................15 + 4.4 States ......................................................16 + 4.5 Events ......................................................19 + 4.6 Actions .....................................................23 + 4.7 Loop Avoidance ..............................................26 + 4.8 Counters and Timers .........................................26 + 5. LCP Packet Formats ..........................................27 + 5.1 Configure-Request ...........................................29 + 5.2 Configure-Ack ...............................................30 + 5.3 Configure-Nak ...............................................31 + 5.4 Configure-Reject ............................................33 + 5.5 Terminate-Request and Terminate-Ack .........................34 + 5.6 Code-Reject .................................................35 + 5.7 Protocol-Reject .............................................36 + 5.8 Echo-Request and Echo-Reply .................................37 + 5.9 Discard-Request .............................................39 + 6. LCP Configuration Options ...................................40 + 6.1 Maximum-Receive-Unit ........................................41 + 6.2 Async-Control-Character-Map .................................42 + 6.3 Authentication-Protocol .....................................43 + 6.4 Quality-Protocol ............................................45 + 6.5 Magic-Number ................................................46 + 6.6 Protocol-Field-Compression ..................................49 + 6.7 Address-and-Control-Field-Compression .......................50 + APPENDIX A. LCP Recommended Options ..............................51 + SECURITY CONSIDERATIONS ..........................................51 + REFERENCES .......................................................52 + ACKNOWLEDGEMENTS .................................................52 + CHAIR'S ADDRESS ..................................................52 + EDITOR'S ADDRESS .................................................53 + + + + +Simpson [Page 2] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +1. Introduction + + Encapsulation + + The PPP encapsulation provides for multiplexing of different + network-layer protocols simultaneously over the same link. It is + intended that PPP provide a common solution for easy connection of + a wide variety of hosts, bridges and routers [1]. + + The PPP encapsulation has been carefully designed to retain + compatibility with most commonly used supporting hardware. + + Only 8 additional octets are necessary to form the encapsulation + when used with the default HDLC framing. In environments where + bandwidth is at a premium, the encapsulation and framing may be + shortened to 2 or 4 octets. + + To support high speed implementations, the default encapsulation + uses only simple fields, only one of which needs to be examined + for demultiplexing. The default header and information fields + fall on 32-bit boundaries, and the trailer may be padded to an + arbitrary boundary. + + Link Control Protocol + + In order to be sufficiently versatile to be portable to a wide + variety of environments, PPP provides a Link Control Protocol + (LCP). The LCP is used to automatically agree upon the + encapsulation format options, handle varying limits on sizes of + packets, authenticate the identity of its peer on the link, + determine when a link is functioning properly and when it is + defunct, detect a looped-back link and other common + misconfiguration errors, and terminate the link. + + Network Control Protocols + + Point-to-Point links tend to exacerbate many problems with the + current family of network protocols. For instance, assignment and + management of IP addresses, which is a problem even in LAN + environments, is especially difficult over circuit-switched + point-to-point links (such as dial-up modem servers). These + problems are handled by a family of Network Control Protocols + (NCPs), which each manage the specific needs required by their + respective network-layer protocols. These NCPs are defined in + companion documents. + + + + + + +Simpson [Page 3] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Configuration + + It is intended that PPP links be easy to configure. By design, + the standard defaults handle all common configurations. The + implementor can specify improvements to the default configuration, + which are automatically communicated to the peer without operator + intervention. Finally, the operator may explicitly configure + options for the link which enable the link to operate in + environments where it would otherwise be impossible. + + This self-configuration is implemented through an extensible + option negotiation mechanism, wherein each end of the link + describes to the other its capabilities and requirements. + Although the option negotiation mechanism described in this + document is specified in terms of the Link Control Protocol (LCP), + the same facilities are designed to be used by other control + protocols, especially the family of NCPs. + +1.1 Specification of Requirements + + In this document, several words are used to signify the + requirements of the specification. These words are often + capitalized. + + MUST + + This word, or the adjective "required", means that the definition + is an absolute requirement of the specification. + + MUST NOT + + This phrase means that the definition is an absolute prohibition + of the specification. + + SHOULD + + This word, or the adjective "recommended", means that there may + exist valid reasons in particular circumstances to ignore this + item, but the full implications must be understood and carefully + weighed before choosing a different course. + + MAY + + This word, or the adjective "optional", means that this item is + one of an allowed set of alternatives. An implementation which + does not include this option MUST be prepared to interoperate with + another implementation which does include the option. + + + + +Simpson [Page 4] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +1.2 Terminology + + This document frequently uses the following terms: + + datagram + + The unit of transmission in the network layer (such as IP). A + datagram may be encapsulated in one or more packets passed to the + data link layer. + + frame + + The unit of transmission at the data link layer. A frame may + include a header and/or a trailer, along with some number of units + of data. + + packet + + The basic unit of encapsulation, which is passed across the + interface between the network layer and the data link layer. A + packet is usually mapped to a frame; the exceptions are when data + link layer fragmentation is being performed, or when multiple + packets are incorporated into a single frame. + + peer + + The other end of the point-to-point link. + + silently discard + + This means the implementation discards the packet without further + processing. The implementation SHOULD provide the capability of + logging the error, including the contents of the silently + discarded packet, and SHOULD record the event in a statistics + counter. + +2. PPP Encapsulation + + The PPP encapsulation is used to disambiguate multiprotocol + datagrams. This encapsulation requires framing to indicate the + beginning and end of the encapsulation. Methods of providing framing + are specified in companion documents. + + + + + + + + + +Simpson [Page 5] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + A summary of the PPP encapsulation is shown below. The fields are + transmitted from left to right. + + +----------+-------------+---------+ + | Protocol | Information | Padding | + | 16 bits | * | * | + +----------+-------------+---------+ + + Protocol Field + + The Protocol field is two octets and its value identifies the + datagram encapsulated in the Information field of the packet. The + field is transmitted and received most significant octet first. + + The structure of this field is consistent with the ISO 3309 + extension mechanism for address fields. All Protocols MUST be + odd; the least significant bit of the least significant octet MUST + equal "1". Also, all Protocols MUST be assigned such that the + least significant bit of the most significant octet equals "0". + Frames received which don't comply with these rules MUST be + treated as having an unrecognized Protocol. + + Protocol field values in the "0***" to "3***" range identify the + network-layer protocol of specific packets, and values in the + "8***" to "b***" range identify packets belonging to the + associated Network Control Protocols (NCPs), if any. + + Protocol field values in the "4***" to "7***" range are used for + protocols with low volume traffic which have no associated NCP. + Protocol field values in the "c***" to "f***" range identify + packets as link-layer Control Protocols (such as LCP). + + Up-to-date values of the Protocol field are specified in the most + recent "Assigned Numbers" RFC [2]. Current values are assigned as + follows: + + Value (in hex) Protocol Name + + 0001 Padding Protocol + 0003 to 001f reserved (transparency inefficient) + 0021 Internet Protocol + 0023 OSI Network Layer + 0025 Xerox NS IDP + 0027 DECnet Phase IV + 0029 Appletalk + 002b Novell IPX + 002d Van Jacobson Compressed TCP/IP + 002f Van Jacobson Uncompressed TCP/IP + + + +Simpson [Page 6] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 0031 Bridging PDU + 0033 Stream Protocol (ST-II) + 0035 Banyan Vines + 0037 unused + 0039 AppleTalk EDDP + 003b AppleTalk SmartBuffered + 003d Multi-Link + 005d reserved (compression inefficient) + 00cf reserved (PPP NLPID) + 00fd 1st choice compression + 00ff reserved (compression inefficient) + + 0201 802.1d Hello Packets + 0203 IBM Source Routing BPDU + 0231 Luxcom + 0233 Sigma Network Systems + + 8021 Internet Protocol Control Protocol + 8023 OSI Network Layer Control Protocol + 8025 Xerox NS IDP Control Protocol + 8027 DECnet Phase IV Control Protocol + 8029 Appletalk Control Protocol + 802b Novell IPX Control Protocol + 802d Reserved + 802f Reserved + 8031 Bridging NCP + 8033 Stream Protocol Control Protocol + 8035 Banyan Vines Control Protocol + 8037 unused + 8039 Reserved + 803b Reserved + 803d Multi-Link Control Protocol + 80fd Compression Control Protocol + 80ff Reserved + + c021 Link Control Protocol + c023 Password Authentication Protocol + c025 Link Quality Report + c223 Challenge Handshake Authentication Protocol + + Developers of new protocols MUST obtain a number from the Internet + Assigned Numbers Authority (IANA), at IANA@isi.edu. + + Information Field + + The Information field is zero or more octets. The Information + field contains the datagram for the protocol specified in the + Protocol field. + + + +Simpson [Page 7] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + The maximum length for the Information field, including Padding, + is termed the Maximum Receive Unit (MRU), which defaults to 1500 + octets. By negotiation, consenting PPP implementations may use + other values for the MRU. + + Padding + + On transmission, the Information field MAY be padded with an + arbitrary number of octets up to the MRU. It is the + responsibility of each protocol to distinguish padding octets from + real information. + +3. PPP Link Operation + +3.1 Overview + + In order to establish communications over a point-to-point link, each + end of the PPP link MUST first send LCP packets to configure and test + the data link. After the link has been established, the peer MAY be + authenticated. Then, PPP MUST send NCP packets to choose and + configure one or more network-layer protocols. Once each of the + chosen network-layer protocols has been configured, datagrams from + each network-layer protocol can be sent over the link. + + The link will remain configured for communications until explicit LCP + or NCP packets close the link down, or until some external event + occurs (an inactivity timer expires or network administrator + intervention). + +3.2 Phase Diagram + + In the process of configuring, maintaining and terminating the + point-to-point link, the PPP link goes through several distinct + phases: + + +------+ +-----------+ +--------------+ + | | UP | | OPENED | | SUCCESS/NONE + | Dead |------->| Establish |---------->| Authenticate |--+ + | | | | | | | + +------+ +-----------+ +--------------+ | + ^ FAIL | FAIL | | + +<--------------+ +----------+ | + | | | + | +-----------+ | +---------+ | + | DOWN | | | CLOSING | | | + +------------| Terminate |<---+<----------| Network |<-+ + | | | | + +-----------+ +---------+ + + + +Simpson [Page 8] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +3.3 Link Dead (physical-layer not ready) + + The link necessarily begins and ends with this phase. When an + external event (such as carrier detection or network administrator + configuration) indicates that the physical-layer is ready to be used, + PPP will proceed to the Link Establishment phase. + + During this phase, the LCP automaton (described below) will be in the + Initial or Starting states. The transition to the Link Establishment + phase will signal an Up event to the automaton. + + Implementation Note: + + Typically, a link will return to this phase automatically after + the disconnection of a modem. In the case of a hard-wired line, + this phase may be extremely short -- merely long enough to detect + the presence of the device. + +3.4 Link Establishment Phase + + The Link Control Protocol (LCP) is used to establish the connection + through an exchange of Configure packets. This exchange is complete, + and the LCP Opened state entered, once a Configure-Ack packet + (described below) has been both sent and received. + + All Configuration Options are assumed to be at default values unless + altered by the configuration exchange. See the section on LCP + Configuration Options for further discussion. + + It is important to note that only Configuration Options which are + independent of particular network-layer protocols are configured by + LCP. Configuration of individual network-layer protocols is handled + by separate Network Control Protocols (NCPs) during the Network-Layer + Protocol phase. + + Any non-LCP packets received during this phase MUST be silently + discarded. + +3.5 Authentication Phase + + On some links it may be desirable to require a peer to authenticate + itself before allowing network-layer protocol packets to be + exchanged. + + By default, authentication is not mandatory. If an implementation + desires that the peer authenticate with some specific authentication + protocol, then it MUST negotiate the use of that authentication + protocol during Link Establishment phase. + + + +Simpson [Page 9] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Authentication SHOULD take place as soon as possible after link + establishment. However, link quality determination MAY occur + concurrently. An implementation MUST NOT allow the exchange of link + quality determination packets to delay authentication indefinitely. + + Advancement from the Authentication phase to the Network-Layer + Protocol phase MUST NOT occur until authentication has completed, + using the negotiated authentication protocol. If authentication + fails, PPP SHOULD proceed instead to the Link Termination phase. + + Any Network Control Protocol or network-layer protocol packets + received during this phase MUST be silently discarded. + +3.6 Network-Layer Protocol Phase + + Once PPP has finished the previous phases, each network-layer + protocol (such as IP, IPX, or AppleTalk) MUST be separately + configured by the appropriate Network Control Protocol (NCP). + + Each NCP MAY be Opened and Closed at any time. + + Implementation Note: + + Because an implementation may initially use a significant amount + of time for link quality determination, implementations SHOULD + avoid fixed timeouts when waiting for their peers to configure a + NCP. + + After a NCP has reached the Opened state, PPP will carry the + corresponding network-layer protocol packets. Any network-layer + protocol packets received when the corresponding NCP is not in the + Opened state MUST be silently discarded. + + Implementation Note: + + There is an exception to the preceding paragraphs, due to the + availability of the LCP Protocol-Reject (described below). While + LCP is in the Opened state, any protocol packet which is + unsupported by the implementation MUST be returned in a Protocol- + Reject. Only protocols which are supported are silently + discarded. + + During this phase, link traffic consists of any possible + combination of LCP, NCP, and network-layer protocol packets. + +3.7 Link Termination Phase + + PPP can terminate the link at any time. This might happen because of + + + +Simpson [Page 10] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + the loss of carrier, authentication failure, link quality failure, + the expiration of an idle-period timer, or the administrative closing + of the link. LCP is used to close the link through an exchange of + Terminate packets. When the link is closing, PPP informs the + network-layer protocols so that they may take appropriate action. + + After the exchange of Terminate packets, the implementation SHOULD + signal the physical-layer to disconnect in order to enforce the + termination of the link, particularly in the case of an + authentication failure. The sender of the Terminate-Request SHOULD + disconnect after receiving a Terminate-Ack, or after the Restart + counter expires. The receiver of a Terminate-Request SHOULD wait for + the peer to disconnect, and MUST NOT disconnect until at least one + Restart time has passed after sending a Terminate-Ack. PPP SHOULD + proceed to the Link Dead phase. + + Any non-LCP packets received during this phase MUST be silently + discarded. + + Implementation Note: + + The closing of the link by LCP is sufficient. There is no need + for each NCP to send a flurry of Terminate packets. Conversely, + the fact that one NCP has Closed is not sufficient reason to cause + the termination of the PPP link, even if that NCP was the only NCP + currently in the Opened state. + +4. The Option Negotiation Automaton + + The finite-state automaton is defined by events, actions and state + transitions. Events include reception of external commands such as + Open and Close, expiration of the Restart timer, and reception of + packets from a peer. Actions include the starting of the Restart + timer and transmission of packets to the peer. + + Some types of packets -- Configure-Naks and Configure-Rejects, or + Code-Rejects and Protocol-Rejects, or Echo-Requests, Echo-Replies and + Discard-Requests -- are not differentiated in the automaton + descriptions. As will be described later, these packets do indeed + serve different functions. However, they always cause the same + transitions. + +Events Actions + +Up = lower layer is Up tlu = This-Layer-Up +Down = lower layer is Down tld = This-Layer-Down +Open = administrative Open tls = This-Layer-Started +Close= administrative Close tlf = This-Layer-Finished + + + +Simpson [Page 11] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +TO+ = Timeout with counter > 0 irc = Initialize-Restart-Counter +TO- = Timeout with counter expired zrc = Zero-Restart-Counter + +RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-Request +RCR- = Receive-Configure-Request (Bad) +RCA = Receive-Configure-Ack sca = Send-Configure-Ack +RCN = Receive-Configure-Nak/Rej scn = Send-Configure-Nak/Rej + +RTR = Receive-Terminate-Request str = Send-Terminate-Request +RTA = Receive-Terminate-Ack sta = Send-Terminate-Ack + +RUC = Receive-Unknown-Code scj = Send-Code-Reject +RXJ+ = Receive-Code-Reject (permitted) + or Receive-Protocol-Reject +RXJ- = Receive-Code-Reject (catastrophic) + or Receive-Protocol-Reject +RXR = Receive-Echo-Request ser = Send-Echo-Reply + or Receive-Echo-Reply + or Receive-Discard-Request + +4.1 State Diagram + + The simplified state diagram which follows describes the sequence of + events for reaching agreement on Configuration Options (opening the + PPP link) and for later termination of the link. + + This diagram is not a complete representation of the automaton. + Implementation MUST be done by consulting the actual state transition + table. + + Events are in upper case. Actions are in lower case. For these + purposes, the state machine is initially in the Closed state. Once + the Opened state has been reached, both ends of the link have met the + requirement of having both sent and received a Configure-Ack packet. + + + + + + + + + + + + + + + + + +Simpson [Page 12] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + RCR TO+ + +--sta-->+ +------->+ + | | | | + +-------+ | RTA +-------+ | Close +-------+ + | |<-----+<------| |<-str-+<------| | + |Closed | |Closing| |Opened | + | | Open | | | | + | |------+ | | | | + +-------+ | +-------+ +-------+ + | ^ + | | + | +-sca----------------->+ + | | ^ + RCN,TO+ V RCR+ | RCR- RCA | RCN,TO+ + +------->+ | +------->+ | +--scr-->+ + | | | | | | | | + +-------+ | TO+ +-------+ | +-------+ | + | |<-scr-+<------| |<-scn-+ | |<-----+ + | Req- | | Ack- | | Ack- | + | Sent | RCA | Rcvd | | Sent | + +-scn->| |------------->| | +-sca->| | + | +-------+ +-------+ | +-------+ + | RCR- | | RCR+ | RCR+ | | RCR- + | | +------------------------------->+<-------+ | + | | | + +<-------+<------------------------------------------------+ + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 13] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +4.2 State Transition Table + + The complete state transition table follows. States are indicated + horizontally, and events are read vertically. State transitions and + actions are represented in the form action/new-state. Multiple + actions are separated by commas, and may continue on succeeding lines + as space requires; multiple actions may be implemented in any + convenient order. The state may be followed by a letter, which + indicates an explanatory footnote. The dash ('-') indicates an + illegal transition. + + + | State + | 0 1 2 3 4 5 + Events| Initial Starting Closed Stopped Closing Stopping + ------+----------------------------------------------------------- + Up | 2 irc,scr/6 - - - - + Down | - - 0 tls/1 0 1 + Open | tls/1 1 irc,scr/6 3r 5r 5r + Close| 0 0 2 2 4 4 + | + TO+ | - - - - str/4 str/5 + TO- | - - - - tlf/2 tlf/3 + | + RCR+ | - - sta/2 irc,scr,sca/8 4 5 + RCR- | - - sta/2 irc,scr,scn/6 4 5 + RCA | - - sta/2 sta/3 4 5 + RCN | - - sta/2 sta/3 4 5 + | + RTR | - - sta/2 sta/3 sta/4 sta/5 + RTA | - - 2 3 tlf/2 tlf/3 + | + RUC | - - scj/2 scj/3 scj/4 scj/5 + RXJ+ | - - 2 3 4 5 + RXJ- | - - tlf/2 tlf/3 tlf/2 tlf/3 + | + RXR | - - 2 3 4 5 + + + + + + + + + + + + + + +Simpson [Page 14] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + | State + | 6 7 8 9 + Events| Req-Sent Ack-Rcvd Ack-Sent Opened + ------+----------------------------------------- + Up | - - - - + Down | 1 1 1 tld/1 + Open | 6 7 8 9r + Close|irc,str/4 irc,str/4 irc,str/4 tld,irc,str/4 + | + TO+ | scr/6 scr/6 scr/8 - + TO- | tlf/3p tlf/3p tlf/3p - + | + RCR+ | sca/8 sca,tlu/9 sca/8 tld,scr,sca/8 + RCR- | scn/6 scn/7 scn/6 tld,scr,scn/6 + RCA | irc/7 scr/6x irc,tlu/9 tld,scr/6x + RCN |irc,scr/6 scr/6x irc,scr/8 tld,scr/6x + | + RTR | sta/6 sta/6 sta/6 tld,zrc,sta/5 + RTA | 6 6 8 tld,scr/6 + | + RUC | scj/6 scj/7 scj/8 scj/9 + RXJ+ | 6 6 8 9 + RXJ- | tlf/3 tlf/3 tlf/3 tld,irc,str/5 + | + RXR | 6 7 8 ser/9 + + The states in which the Restart timer is running are identifiable by + the presence of TO events. Only the Send-Configure-Request, Send- + Terminate-Request and Zero-Restart-Counter actions start or re-start + the Restart timer. The Restart timer is stopped when transitioning + from any state where the timer is running to a state where the timer + is not running. + + [p] Passive option; see Stopped state discussion. + + [r] Restart option; see Open event discussion. + + [x] Crossed connection; see RCA event discussion. + +4.3 A Day in the Life + + Here is an example of how a typical implementation might use the + automaton to implement LCP in a dial-up environment: + + - The Network Access Server is powered on (Initial state, Link Dead + phase). + + - A configuration file indicates that a particular link is to be + + + +Simpson [Page 15] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + used for PPP access (Open: tls/Starting). The This-Layer-Started + event turns on DTR to a modem, readying it for accepting calls. + + - An incoming call is answered. The modem CD triggers configuration + negotiation (Up: irc,scr/Req-Sent, Link Establishment phase). + + - A Configure-Request is received, which is acknowleged (RCR+: + sca/Ack-Sent). + + - The Request is acknowleged (RCA: irc,tlu/Opened). The This- + Layer-Up event starts authentication and quality monitoring + protocols (Authentication phase). + + - When authentication and quality monitoring are satisfied, they + send an Up event to start the available NCPs (Network-Layer + Protocol phase). + + - Later, the peer is finished, and closes the link. A Terminate- + Request arrives (RTR: tld,zrc,sta/Stopping, Termination phase). + The This-Layer-Down action sends the Down event to any NCPs, while + the Terminate-Ack is sent. The Zero-Restart-Counter action causes + the link to wait for the peer to process the Terminate-Ack, with + no retries. + + - When the Restart Timer times out (TO-: tlf/Stopped), the This- + Layer-Finished action signals the modem to hang up by dropping + DTR. + + - When the CD from the modem drops (Down: tls/Starting), the This- + Layer-Started action raises DTR again, readying it for the next + call (returning to the Link Dead phase). + +4.4 States + + Following is a more detailed description of each automaton state. + + Initial + + In the Initial state, the lower layer is unavailable (Down), and + no Open has occurred. The Restart timer is not running in the + Initial state. + + Starting + + The Starting state is the Open counterpart to the Initial state. + An administrative Open has been initiated, but the lower layer is + still unavailable (Down). The Restart timer is not running in the + Starting state. + + + +Simpson [Page 16] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + When the lower layer becomes available (Up), a Configure-Request + is sent. + + Closed + + In the Closed state, the link is available (Up), but no Open has + occurred. The Restart timer is not running in the Closed state. + + Upon reception of Configure-Request packets, a Terminate-Ack is + sent. Terminate-Acks are silently discarded to avoid creating a + loop. + + Stopped + + The Stopped state is the Open counterpart to the Closed state. It + is entered when the automaton is waiting for a Down event after + the This-Layer-Finished action, or after sending a Terminate-Ack. + The Restart timer is not running in the Stopped state. + + Upon reception of Configure-Request packets, an appropriate + response is sent. Upon reception of other packets, a Terminate- + Ack is sent. Terminate-Acks are silently discarded to avoid + creating a loop. + + Rationale: + + The Stopped state is a junction state for link termination, link + configuration failure, and other automaton failure modes. These + potentially separate states have been combined. + + There is a race condition between the Down event response (from + the This-Layer-Finished action) and the Receive-Configure- Request + event. When a Configure-Request arrives before the Down event, + the Down event will supercede by returning the automaton to the + Starting state. This prevents attack by repetition. + + Implementation Option: + + After the peer fails to respond to Configure-Requests, an + implementation MAY wait passively for the peer to send Configure- + Requests. In this case, the This-Layer-Finished action is not + used for the TO- event in states Req-Sent, Ack- Rcvd and Ack-Sent. + + This option is useful for dedicated circuits, or circuits which + have no status signals available, but SHOULD NOT be used for + switched circuits. + + + + + +Simpson [Page 17] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Closing + + In the Closing state, an attempt is made to terminate the + connection. A Terminate-Request has been sent and the Restart + timer is running, but a Terminate-Ack has not yet been received. + + Upon reception of a Terminate-Ack, the Closed state is entered. + Upon the expiration of the Restart timer, a new Terminate-Request + is transmitted and the Restart timer is restarted. After the + Restart timer has expired Max-Terminate times, this action may be + skipped, and the Closed state may be entered. + + Stopping + + The Stopping state is the Open counterpart to the Closing state. + A Terminate-Request has been sent and the Restart timer is + running, but a Terminate-Ack has not yet been received. + + Rationale: + + The Stopping state provides a well defined opportunity to + terminate a link before allowing new traffic. After the link has + terminated, a new configuration may occur via the Stopped or + Starting states. + + Request-Sent + + In the Request-Sent state an attempt is made to configure the + connection. A Configure-Request has been sent and the Restart + timer is running, but a Configure-Ack has not yet been received + nor has one been sent. + + Ack-Received + + In the Ack-Received state, a Configure-Request has been sent and a + Configure-Ack has been received. The Restart timer is still + running since a Configure-Ack has not yet been sent. + + Ack-Sent + + In the Ack-Sent state, a Configure-Request and a Configure-Ack + have both been sent but a Configure-Ack has not yet been received. + The Restart timer is always running in the Ack-Sent state. + + Opened + + In the Opened state, a Configure-Ack has been both sent and + received. The Restart timer is not running in the Opened state. + + + +Simpson [Page 18] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + When entering the Opened state, the implementation SHOULD signal + the upper layers that it is now Up. Conversely, when leaving the + Opened state, the implementation SHOULD signal the upper layers + that it is now Down. + +4.5 Events + + Transitions and actions in the automaton are caused by events. + + Up + + The Up event occurs when a lower layer indicates that it is ready + to carry packets. + + Typically, this event is used by a modem handling or calling + process, or by some other coupling of the PPP link to the physical + media, to signal LCP that the link is entering Link Establishment + phase. + + It also can be used by LCP to signal each NCP that the link is + entering Network-Layer Protocol phase. That is, the This-Layer-Up + action from LCP triggers the Up event in the NCP. + + Down + + The Down event occurs when a lower layer indicates that it is no + longer ready to carry packets. + + Typically, this event is used by a modem handling or calling + process, or by some other coupling of the PPP link to the physical + media, to signal LCP that the link is entering Link Dead phase. + + It also can be used by LCP to signal each NCP that the link is + leaving Network-Layer Protocol phase. That is, the This-Layer- + Down action from LCP triggers the Down event in the NCP. + + Open + + The Open event indicates that the link is administratively + available for traffic; that is, the network administrator (human + or program) has indicated that the link is allowed to be Opened. + When this event occurs, and the link is not in the Opened state, + the automaton attempts to send configuration packets to the peer. + + If the automaton is not able to begin configuration (the lower + layer is Down, or a previous Close event has not completed), the + establishment of the link is automatically delayed. + + + + +Simpson [Page 19] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + When a Terminate-Request is received, or other events occur which + cause the link to become unavailable, the automaton will progress + to a state where the link is ready to re-open. No additional + administrative intervention is necessary. + + Implementation Option: + + Experience has shown that users will execute an additional Open + command when they want to renegotiate the link. This might + indicate that new values are to be negotiated. + + Since this is not the meaning of the Open event, it is suggested + that when an Open user command is executed in the Opened, Closing, + Stopping, or Stopped states, the implementation issue a Down + event, immediately followed by an Up event. This will cause the + renegotiation of the link, without any harmful side effects. + + Close + + The Close event indicates that the link is not available for + traffic; that is, the network administrator (human or program) has + indicated that the link is not allowed to be Opened. When this + event occurs, and the link is not in the Closed state, the + automaton attempts to terminate the connection. Futher attempts + to re-configure the link are denied until a new Open event occurs. + + Implementation Note: + + When authentication fails, the link SHOULD be terminated, to + prevent attack by repetition and denial of service to other users. + Since the link is administratively available (by definition), this + can be accomplished by simulating a Close event to the LCP, + immediately followed by an Open event. + + The Close followed by an Open will cause an orderly termination of + the link, by progressing from the Closing to the Stopping state, + and the This-Layer-Finished action can disconnect the link. The + automaton waits in the Stopped or Starting states for the next + connection attempt. + + Timeout (TO+,TO-) + + This event indicates the expiration of the Restart timer. The + Restart timer is used to time responses to Configure-Request and + Terminate-Request packets. + + The TO+ event indicates that the Restart counter continues to be + greater than zero, which triggers the corresponding Configure- + + + +Simpson [Page 20] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Request or Terminate-Request packet to be retransmitted. + + The TO- event indicates that the Restart counter is not greater + than zero, and no more packets need to be retransmitted. + + Receive-Configure-Request (RCR+,RCR-) + + This event occurs when a Configure-Request packet is received from + the peer. The Configure-Request packet indicates the desire to + open a connection and may specify Configuration Options. The + Configure-Request packet is more fully described in a later + section. + + The RCR+ event indicates that the Configure-Request was + acceptable, and triggers the transmission of a corresponding + Configure-Ack. + + The RCR- event indicates that the Configure-Request was + unacceptable, and triggers the transmission of a corresponding + Configure-Nak or Configure-Reject. + + Implementation Note: + + These events may occur on a connection which is already in the + Opened state. The implementation MUST be prepared to immediately + renegotiate the Configuration Options. + + Receive-Configure-Ack (RCA) + + The Receive-Configure-Ack event occurs when a valid Configure-Ack + packet is received from the peer. The Configure-Ack packet is a + positive response to a Configure-Request packet. An out of + sequence or otherwise invalid packet is silently discarded. + + Implementation Note: + + Since the correct packet has already been received before reaching + the Ack-Rcvd or Opened states, it is extremely unlikely that + another such packet will arrive. As specified, all invalid + Ack/Nak/Rej packets are silently discarded, and do not affect the + transitions of the automaton. + + However, it is not impossible that a correctly formed packet will + arrive through a coincidentally-timed cross-connection. It is + more likely to be the result of an implementation error. At the + very least, this occurance SHOULD be logged. + + + + + +Simpson [Page 21] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Receive-Configure-Nak/Rej (RCN) + + This event occurs when a valid Configure-Nak or Configure-Reject + packet is received from the peer. The Configure-Nak and + Configure-Reject packets are negative responses to a Configure- + Request packet. An out of sequence or otherwise invalid packet is + silently discarded. + + Implementation Note: + + Although the Configure-Nak and Configure-Reject cause the same + state transition in the automaton, these packets have + significantly different effects on the Configuration Options sent + in the resulting Configure-Request packet. + + Receive-Terminate-Request (RTR) + + The Receive-Terminate-Request event occurs when a Terminate- + Request packet is received. The Terminate-Request packet + indicates the desire of the peer to close the connection. + + Implementation Note: + + This event is not identical to the Close event (see above), and + does not override the Open commands of the local network + administrator. The implementation MUST be prepared to receive a + new Configure-Request without network administrator intervention. + + Receive-Terminate-Ack (RTA) + + The Receive-Terminate-Ack event occurs when a Terminate-Ack packet + is received from the peer. The Terminate-Ack packet is usually a + response to a Terminate-Request packet. The Terminate-Ack packet + may also indicate that the peer is in Closed or Stopped states, + and serves to re-synchronize the link configuration. + + Receive-Unknown-Code (RUC) + + The Receive-Unknown-Code event occurs when an un-interpretable + packet is received from the peer. A Code-Reject packet is sent in + response. + + Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-) + + This event occurs when a Code-Reject or a Protocol-Reject packet + is received from the peer. + + The RXJ+ event arises when the rejected value is acceptable, such + + + +Simpson [Page 22] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + as a Code-Reject of an extended code, or a Protocol-Reject of a + NCP. These are within the scope of normal operation. The + implementation MUST stop sending the offending packet type. + + The RXJ- event arises when the rejected value is catastrophic, + such as a Code-Reject of Configure-Request, or a Protocol-Reject + of LCP! This event communicates an unrecoverable error that + terminates the connection. + + Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request + (RXR) + + This event occurs when an Echo-Request, Echo-Reply or Discard- + Request packet is received from the peer. The Echo-Reply packet is + a response to a Echo-Request packet. There is no reply to an Echo- + Reply or Discard-Request packet. + +4.6 Actions + + Actions in the automaton are caused by events and typically indicate + the transmission of packets and/or the starting or stopping of the + Restart timer. + + Illegal-Event (-) + + This indicates an event that cannot occur in a properly + implemented automaton. The implementation has an internal error, + which should be reported and logged. No transition is taken, and + the implementation SHOULD NOT reset or freeze. + + This-Layer-Up (tlu) + + This action indicates to the upper layers that the automaton is + entering the Opened state. + + Typically, this action is used by the LCP to signal the Up event + to a NCP, Authentication Protocol, or Link Quality Protocol, or + MAY be used by a NCP to indicate that the link is available for + its network layer traffic. + + This-Layer-Down (tld) + + This action indicates to the upper layers that the automaton is + leaving the Opened state. + + Typically, this action is used by the LCP to signal the Down event + to a NCP, Authentication Protocol, or Link Quality Protocol, or + MAY be used by a NCP to indicate that the link is no longer + + + +Simpson [Page 23] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + available for its network layer traffic. + + This-Layer-Started (tls) + + This action indicates to the lower layers that the automaton is + entering the Starting state, and the lower layer is needed for the + link. The lower layer SHOULD respond with an Up event when the + lower layer is available. + + Implementation Note: + + This results of this action are highly implementation dependent. + + The transitions where this event is indicated are defined + according to a message passing architecture, rather than a + signalling architecture. If the action is desired to control + specific signals (such as DTR), other transitions for the action + are likely to be required (Open in Closed, RCR in Stopped). + + This-Layer-Finished (tlf) + + This action indicates to the lower layers that the automaton is + entering the Stopped or Closed states, and the lower layer is no + longer needed for the link. The lower layer SHOULD respond with a + Down event when the lower layer has terminated. + + Typically, this action MAY be used by the LCP to advance to the + Link Dead phase, or MAY be used by a NCP to indicate to the LCP + that the link may terminate when there are no other NCPs open. + + Implementation Note: + + This results of this action are highly implementation dependent. + + The transitions where this event is indicated are defined + according to a message passing architecture, rather than a + signalling architecture. If the action is desired to control + specific signals (such as DTR), other transitions for the action + are likely to be required (Close in Starting, Down in Closing). + + Initialize-Restart-Counter (irc) + + This action sets the Restart counter to the appropriate value + (Max-Terminate or Max-Configure). The counter is decremented for + each transmission, including the first. + + + + + + +Simpson [Page 24] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Implementation Note: + + In addition to setting the Restart counter, the implementation + MUST set the timeout period to the initial value when Restart + timer backoff is used. + + Zero-Restart-Counter (zrc) + + This action sets the Restart counter to zero. + + Implementation Note: + + This action enables the FSA to pause before proceeding to the + desired final state, allowing traffic to be processed by the peer. + In addition to zeroing the Restart counter, the implementation + MUST set the timeout period to an appropriate value. + + Send-Configure-Request (scr) + + The Send-Configure-Request action transmits a Configure-Request + packet. This indicates the desire to open a connection with a + specified set of Configuration Options. The Restart timer is + started when the Configure-Request packet is transmitted, to guard + against packet loss. The Restart counter is decremented each time + a Configure-Request is sent. + + Send-Configure-Ack (sca) + + The Send-Configure-Ack action transmits a Configure-Ack packet. + This acknowledges the reception of a Configure-Request packet with + an acceptable set of Configuration Options. + + Send-Configure-Nak (scn) + + The Send-Configure-Nak action transmits a Configure-Nak or + Configure-Reject packet, as appropriate. This negative response + reports the reception of a Configure-Request packet with an + unacceptable set of Configuration Options. Configure-Nak packets + are used to refuse a Configuration Option value, and to suggest a + new, acceptable value. Configure-Reject packets are used to + refuse all negotiation about a Configuration Option, typically + because it is not recognized or implemented. The use of + Configure-Nak versus Configure-Reject is more fully described in + the section on LCP Packet Formats. + + Send-Terminate-Request (str) + + The Send-Terminate-Request action transmits a Terminate-Request + + + +Simpson [Page 25] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + packet. This indicates the desire to close a connection. The + Restart timer is started when the Terminate-Request packet is + transmitted, to guard against packet loss. The Restart counter is + decremented each time a Terminate-Request is sent. + + Send-Terminate-Ack (sta) + + The Send-Terminate-Ack action transmits a Terminate-Ack packet. + This acknowledges the reception of a Terminate-Request packet or + otherwise serves to synchronize the state machines. + + Send-Code-Reject (scj) + + The Send-Code-Reject action transmits a Code-Reject packet. This + indicates the reception of an unknown type of packet. + + Send-Echo-Reply (ser) + + The Send-Echo-Reply action transmits an Echo-Reply packet. This + acknowledges the reception of an Echo-Request packet. + +4.7 Loop Avoidance + + The protocol makes a reasonable attempt at avoiding Configuration + Option negotiation loops. However, the protocol does NOT guarantee + that loops will not happen. As with any negotiation, it is possible + to configure two PPP implementations with conflicting policies that + will never converge. It is also possible to configure policies which + do converge, but which take significant time to do so. Implementors + should keep this in mind and SHOULD implement loop detection + mechanisms or higher level timeouts. + + +4.8 Counters and Timers + + Restart Timer + + There is one special timer used by the automaton. The Restart + timer is used to time transmissions of Configure-Request and + Terminate- Request packets. Expiration of the Restart timer + causes a Timeout event, and retransmission of the corresponding + Configure-Request or Terminate-Request packet. The Restart timer + MUST be configurable, but SHOULD default to three (3) seconds. + + Implementation Note: + + The Restart timer SHOULD be based on the speed of the link. The + default value is designed for low speed (2,400 to 9,600 bps), high + + + +Simpson [Page 26] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + switching latency links (typical telephone lines). Higher speed + links, or links with low switching latency, SHOULD have + correspondingly faster retransmission times. + + Instead of a constant value, the Restart timer MAY begin at an + initial small value and increase to the configured final value. + Each successive value less than the final value SHOULD be at least + twice the previous value. The initial value SHOULD be large + enough to account for the size of the packets, twice the round + trip time for transmission at the link speed, and at least an + additional 100 milliseconds to allow the peer to process the + packets before responding. Some circuits add another 200 + milliseconds of satellite delay. Round trip times for modems + operating at 14,400 bps have been measured in the range of 160 to + more than 600 milliseconds. + + Max-Terminate + + There is one required restart counter for Terminate-Requests. + Max- Terminate indicates the number of Terminate-Request packets + sent without receiving a Terminate-Ack before assuming that the + peer is unable to respond. Max-Terminate MUST be configurable, + but SHOULD default to two (2) transmissions. + + Max-Configure + + A similar counter is recommended for Configure-Requests. Max- + Configure indicates the number of Configure-Request packets sent + without receiving a valid Configure-Ack, Configure-Nak or + Configure- Reject before assuming that the peer is unable to + respond. Max- Configure MUST be configurable, but SHOULD default + to ten (10) transmissions. + + Max-Failure + + A related counter is recommended for Configure-Nak. Max-Failure + indicates the number of Configure-Nak packets sent without sending + a Configure-Ack before assuming that configuration is not + converging. Any further Configure-Nak packets are converted to + Configure-Reject packets. Max-Failure MUST be configurable, but + SHOULD default to ten (10) transmissions. + +5. LCP Packet Formats + + There are three classes of LCP packets: + + 1. Link Configuration packets used to establish and configure a + link (Configure-Request, Configure-Ack, Configure-Nak and + + + +Simpson [Page 27] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Configure-Reject). + + 2. Link Termination packets used to terminate a link (Terminate- + Request and Terminate-Ack). + + 3. Link Maintenance packets used to manage and debug a link + (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, and + Discard-Request). + + This document describes Version 1 of the Link Control Protocol. In + the interest of simplicity, there is no version field in the LCP + packet. If a new version of LCP is necessary in the future, the + intention is that a new PPP Protocol field value will be used to + differentiate Version 1 LCP from all other versions. A correctly + functioning Version 1 LCP implementation will always respond to + unknown Protocols (including other versions) with an easily + recognizable Version 1 packet, thus providing a deterministic + fallback mechanism for implementations of other versions. + + Regardless of which Configuration Options are enabled, all LCP Link + Configuration, Link Termination, and Code-Reject packets (codes 1 + through 7) are always sent as if no Configuration Options were + enabled. This ensures that such LCP packets are always recognizable + even when one end of the link mistakenly believes the link to be + open. + + Implementation Note: + + In particular, the Async-Control-Character-Map (ACCM) default for + the type of link is used, and no address, control, or protocol + field compression is allowed. + + Exactly one LCP packet is encapsulated in the PPP Information + field, where the PPP Protocol field indicates type hex c021 (Link + Control Protocol). + + A summary of the Link Control Protocol packet format is shown below. + The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + + + +Simpson [Page 28] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Code + + The Code field is one octet and identifies the kind of LCP packet. + When a packet is received with an invalid Code field, a Code- + Reject packet is transmitted. + + Up-to-date values of the LCP Code field are specified in the most + recent "Assigned Numbers" RFC [2]. This specification concerns + the following values: + + 1 Configure-Request + 2 Configure-Ack + 3 Configure-Nak + 4 Configure-Reject + 5 Terminate-Request + 6 Terminate-Ack + 7 Code-Reject + 8 Protocol-Reject + 9 Echo-Request + 10 Echo-Reply + 11 Discard-Request + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. When a packet is received with an invalid Identifier + field, the packet is silently discarded. + + Length + + The Length field is two octets and indicates the length of the LCP + packet including the Code, Identifier, Length and Data fields. + Octets outside the range of the Length field are treated as + padding and are ignored on reception. When a packet is received + with an invalid Length field, the packet is silently discarded. + + Data + + The Data field is zero or more octets as indicated by the Length + field. The format of the Data field is determined by the Code + field. + +5.1 Configure-Request + + Description + + An implementation wishing to open a connection MUST transmit a LCP + packet with the Code field set to 1 (Configure-Request), and the + + + +Simpson [Page 29] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Options field filled with any desired changes to the link + defaults. Configuration Options SHOULD NOT be included with + default values. + + Upon reception of a Configure-Request, an appropriate reply MUST + be transmitted. + + A summary of the Configure-Request packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+ + + Code + + 1 for Configure-Request. + + Identifier + + The Identifier field MUST be changed whenever the content of the + Options field changes, and whenever a valid reply has been + received for a previous request. For retransmissions, the + Identifier MAY remain unchanged. + + Options + + The options field is variable in length and contains the list of + zero or more Configuration Options that the sender desires to + negotiate. All Configuration Options are always negotiated + simultaneously. The format of Configuration Options is further + described in a later section. + +5.2 Configure-Ack + + Description + + If every Configuration Option received in a Configure-Request is + recognizable and all values are acceptable, then the + implementation MUST transmit a LCP packet with the Code field set + to 2 (Configure-Ack), the Identifier field copied from the + received Configure-Request, and the Options field copied from the + received Configure-Request. The acknowledged Configuration + Options MUST NOT be reordered or modified in any way. + + + +Simpson [Page 30] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + On reception of a Configure-Ack, the Identifier field MUST match + that of the last transmitted Configure-Request. Additionally, the + Configuration Options in a Configure-Ack MUST exactly match those + of the last transmitted Configure-Request. Invalid packets are + silently discarded. + + A summary of the Configure-Ack packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+ + + Code + + 2 for Configure-Ack. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Configure-Request which caused this Configure-Ack. + + Options + + The Options field is variable in length and contains the list of + zero or more Configuration Options that the sender is + acknowledging. All Configuration Options are always acknowledged + simultaneously. + +5.3 Configure-Nak + + Description + + If every element of the received Configuration Options is + recognizable but some values are not acceptable, then the + implementation MUST transmit a LCP packet with the Code field set + to 3 (Configure-Nak), the Identifier field copied from the + received Configure-Request, and the Options field filled with only + the unacceptable Configuration Options from the Configure-Request. + All acceptable Configuration Options are filtered out of the + Configure-Nak, but otherwise the Configuration Options from the + Configure-Request MUST NOT be reordered. + + Options which have no value fields (boolean options) MUST use the + + + +Simpson [Page 31] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Configure-Reject reply instead. + + Each Configuration Option which is allowed only a single instance + MUST be modified to a value acceptable to the Configure-Nak + sender. The default value MAY be used, when this differs from the + requested value. + + When a particular type of Configuration Option can be listed more + than once with different values, the Configure-Nak MUST include a + list of all values for that option which are acceptable to the + Configure-Nak sender. This includes acceptable values that were + present in the Configure-Request. + + Finally, an implementation may be configured to request the + negotiation of a specific Configuration Option. If that option is + not listed, then that option MAY be appended to the list of Nak'd + Configuration Options in order to prompt the peer to include that + option in its next Configure-Request packet. Any value fields for + the option MUST indicate values acceptable to the Configure-Nak + sender. + + On reception of a Configure-Nak, the Identifier field MUST match + that of the last transmitted Configure-Request. Invalid packets + are silently discarded. + + Reception of a valid Configure-Nak indicates that a new + Configure-Request MAY be sent with the Configuration Options + modified as specified in the Configure-Nak. When multiple + instances of a Configuration Option are present, the peer SHOULD + select a single value to include in its next Configure-Request + packet. + + Some Configuration Options have a variable length. Since the + Nak'd Option has been modified by the peer, the implementation + MUST be able to handle an Option length which is different from + the original Configure-Request. + + A summary of the Configure-Nak packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+ + + + + +Simpson [Page 32] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Code + + 3 for Configure-Nak. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Configure-Request which caused this Configure-Nak. + + Options + + The Options field is variable in length and contains the list of + zero or more Configuration Options that the sender is Nak'ing. + All Configuration Options are always Nak'd simultaneously. + +5.4 Configure-Reject + + Description + + If some Configuration Options received in a Configure-Request are + not recognizable or are not acceptable for negotiation (as + configured by a network administrator), then the implementation + MUST transmit a LCP packet with the Code field set to 4 + (Configure-Reject), the Identifier field copied from the received + Configure-Request, and the Options field filled with only the + unacceptable Configuration Options from the Configure-Request. + All recognizable and negotiable Configuration Options are filtered + out of the Configure-Reject, but otherwise the Configuration + Options MUST NOT be reordered or modified in any way. + + On reception of a Configure-Reject, the Identifier field MUST + match that of the last transmitted Configure-Request. + Additionally, the Configuration Options in a Configure-Reject MUST + be a proper subset of those in the last transmitted Configure- + Request. Invalid packets are silently discarded. + + Reception of a valid Configure-Reject indicates that a new + Configure-Request SHOULD be sent which does not include any of the + Configuration Options listed in the Configure-Reject. + + A summary of the Configure-Reject packet format is shown below. The + fields are transmitted from left to right. + + + + + + + + + +Simpson [Page 33] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+ + + Code + + 4 for Configure-Reject. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Configure-Request which caused this Configure-Reject. + + Options + + The Options field is variable in length and contains the list of + zero or more Configuration Options that the sender is rejecting. + All Configuration Options are always rejected simultaneously. + +5.5 Terminate-Request and Terminate-Ack + + Description + + LCP includes Terminate-Request and Terminate-Ack Codes in order to + provide a mechanism for closing a connection. + + A LCP implementation wishing to close a connection SHOULD transmit + a LCP packet with the Code field set to 5 (Terminate-Request), and + the Data field filled with any desired data. Terminate-Request + packets SHOULD continue to be sent until Terminate-Ack is + received, the lower layer indicates that it has gone down, or a + sufficiently large number have been transmitted such that the peer + is down with reasonable certainty. + + Upon reception of a Terminate-Request, a LCP packet MUST be + transmitted with the Code field set to 6 (Terminate-Ack), the + Identifier field copied from the Terminate-Request packet, and the + Data field filled with any desired data. + + Reception of an unelicited Terminate-Ack indicates that the peer + is in the Closed or Stopped states, or is otherwise in need of + re-negotiation. + + A summary of the Terminate-Request and Terminate-Ack packet formats + + + +Simpson [Page 34] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + is shown below. The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Code + + 5 for Terminate-Request; + + 6 for Terminate-Ack. + + Identifier + + On transmission, the Identifier field MUST be changed whenever the + content of the Data field changes, and whenever a valid reply has + been received for a previous request. For retransmissions, the + Identifier MAY remain unchanged. On reception, the Identifier + field of the Terminate-Request is copied into the Identifier field + of the Terminate-Ack packet. + + Data + + The Data field is zero or more octets and contains uninterpreted + data for use by the sender. The data may consist of any binary + value and may be of any length from zero to the peer's established + MRU minus four. + + +5.6 Code-Reject + + Description + + Reception of a LCP packet with an unknown Code indicates that one + of the communicating LCP implementations is faulty or incomplete. + This error MUST be reported back to the sender of the unknown Code + by transmitting a LCP packet with the Code field set to 7 (Code- + Reject), and the inducing packet copied to the Rejected- + Information field. + + Upon reception of a Code-Reject, the implementation SHOULD report + the error, since it is unlikely that the situation can be + rectified automatically. + + + + +Simpson [Page 35] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + A summary of the Code-Reject packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Rejected-Packet ... + +-+-+-+-+-+-+-+-+ + + Code + + 7 for Code-Reject. + + Identifier + + The Identifier field MUST be changed for each Code-Reject sent. + + Rejected-Information + + The Rejected-Information field contains a copy of the LCP packet + which is being rejected. It begins with the Information field, + and does not include any Data Link Layer headers nor an FCS. The + Rejected-Information MUST be truncated to comply with the peer's + established MRU. + + +5.7 Protocol-Reject + + Description + + Reception of a PPP packet with an unknown Protocol field indicates + that the peer is attempting to use a protocol which is + unsupported. This usually occurs when the peer attempts to + configure a new protocol. If the LCP state machine is in the + Opened state, then this error MUST be reported back to the peer by + transmitting a LCP packet with the Code field set to 8 (Protocol- + Reject), the Rejected-Protocol field set to the received Protocol, + and the inducing packet copied to the Rejected-Information field. + + Upon reception of a Protocol-Reject, the implementation MUST stop + sending packets of the indicated protocol at the earliest + opportunity. + + Protocol-Reject packets can only be sent in the LCP Opened state. + Protocol-Reject packets received in any state other than the LCP + Opened state SHOULD be silently discarded. + + + +Simpson [Page 36] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + A summary of the Protocol-Reject packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Rejected-Protocol | Rejected-Information ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 8 for Protocol-Reject. + + Identifier + + The Identifier field MUST be changed for each Protocol-Reject + sent. + + Rejected-Protocol + + The Rejected-Protocol field is two octets and contains the PPP + Protocol field of the packet which is being rejected. + + Rejected-Information + + The Rejected-Information field contains a copy of the packet which + is being rejected. It begins with the Information field, and does + not include any Data Link Layer headers nor an FCS. The + Rejected-Information MUST be truncated to comply with the peer's + established MRU. + +5.8 Echo-Request and Echo-Reply + + Description + + LCP includes Echo-Request and Echo-Reply Codes in order to provide + a Data Link Layer loopback mechanism for use in exercising both + directions of the link. This is useful as an aid in debugging, + link quality determination, performance testing, and for numerous + other functions. + + An Echo-Request sender transmits a LCP packet with the Code field + set to 9 (Echo-Request), the Identifier field set, the local + Magic-Number (if any) inserted, and the Data field filled with any + desired data, but not exceeding the peer's established MRU minus + eight. + + + +Simpson [Page 37] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Upon reception of an Echo-Request, a LCP packet MUST be + transmitted with the Code field set to 10 (Echo-Reply), the + Identifier field copied from the received Echo-Request, the local + Magic-Number (if any) inserted, and the Data field copied from the + Echo-Request, truncating as necessary to avoid exceeding the + peer's established MRU. + + Echo-Request and Echo-Reply packets may only be sent in the LCP + Opened state. Echo-Request and Echo-Reply packets received in any + state other than the LCP Opened state SHOULD be silently + discarded. + + A summary of the Echo-Request and Echo-Reply packet formats is shown + below. The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic-Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Code + + 9 for Echo-Request; + + 10 for Echo-Reply. + + Identifier + + On transmission, the Identifier field MUST be changed whenever the + content of the Data field changes, and whenever a valid reply has + been received for a previous request. For retransmissions, the + Identifier MAY remain unchanged. + + On reception, the Identifier field of the Echo-Request is copied + into the Identifier field of the Echo-Reply packet. + + Magic-Number + + The Magic-Number field is four octets and aids in detecting links + which are in the looped-back condition. Until the Magic-Number + Configuration Option has been successfully negotiated, the Magic- + Number MUST be transmitted as zero. See the Magic-Number + Configuration Option for further explanation. + + + +Simpson [Page 38] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Data + + The Data field is zero or more octets and contains uninterpreted + data for use by the sender. The data may consist of any binary + value and may be of any length from zero to the peer's established + MRU minus eight. + +5.9 Discard-Request + + Description + + LCP includes a Discard-Request Code in order to provide a Data + Link Layer sink mechanism for use in exercising the local to + remote direction of the link. This is useful as an aid in + debugging, performance testing, and for numerous other functions. + + The sender transmits a LCP packet with the Code field set to 11 + (Discard-Request), the Identifier field set, the local Magic- + Number (if any) inserted, and the Data field filled with any + desired data, but not exceeding the peer's established MRU minus + eight. + + Discard-Request packets may only be sent in the LCP Opened state. + On reception, the receiver MUST simply throw away any Discard- + Request that it receives. + + A summary of the Discard-Request packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic-Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + Code + + 11 for Discard-Request. + + Identifier + + The Identifier field MUST be changed for each Discard-Request + sent. + + + +Simpson [Page 39] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Magic-Number + + The Magic-Number field is four octets and aids in detecting links + which are in the looped-back condition. Until the Magic-Number + Configuration Option has been successfully negotiated, the Magic- + Number MUST be transmitted as zero. See the Magic-Number + Configuration Option for further explanation. + + Data + + The Data field is zero or more octets and contains uninterpreted + data for use by the sender. The data may consist of any binary + value and may be of any length from zero to the peer's established + MRU minus four. + +6. LCP Configuration Options + + LCP Configuration Options allow negotiation of modifications to the + default characteristics of a point-to-point link. If a Configuration + Option is not included in a Configure-Request packet, the default + value for that Configuration Option is assumed. + + Some Configuration Options MAY be listed more than once. The effect + of this is Configuration Option specific, and is specified by each + such Configuration Option description. (None of the Configuration + Options in this specification can be listed more than once.) + + The end of the list of Configuration Options is indicated by the + length of the LCP packet. + + Unless otherwise specified, all Configuration Options apply in a + half-duplex fashion; typically, in the receive direction of the link + from the point of view of the Configure-Request sender. + + A summary of the Configuration Option format is shown below. The + fields are transmitted from left to right. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Data ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + The Type field is one octet and indicates the type of + Configuration Option. Up-to-date values of the LCP Option Type + field are specified in the most recent "Assigned Numbers" RFC [2]. + + + +Simpson [Page 40] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + This specification concerns the following values: + + 1 Maximum-Receive-Unit + 2 Async-Control-Character-Map + 3 Authentication-Protocol + 4 Quality-Protocol + 5 Magic-Number + 6 RESERVED + 7 Protocol-Field-Compression + 8 Address-and-Control-Field-Compression + + Length + + The Length field is one octet and indicates the length of this + Configuration Option including the Type, Length and Data fields. + If a negotiable Configuration Option is received in a Configure- + Request but with an invalid Length, a Configure-Nak SHOULD be + transmitted which includes the desired Configuration Option with + an appropriate Length and Data. + + Data + + The Data field is zero or more octets and information specific to + the Configuration Option. The format and length of the Data field + is determined by the Type and Length fields. + +6.1 Maximum-Receive-Unit + + Description + + This Configuration Option may be sent to inform the peer that the + implementation can receive larger packets, or to request that the + peer send smaller packets. + + The default value is 1500 octets. If smaller packets are + requested, an implementation MUST still be able to receive the + full 1500 octet information field in case link synchronization is + lost. + + Implementation Note: + + This option is used to indicate an implementation capability. The + peer is not required to maximize the use of the capacity. For + example, when a MRU is indicated which is 2048 octets, the peer is + not required to send any packet with 2048 octets. The peer need + not Configure-Nak to indicate that it will only send smaller + packets, since the implementation will always require support for + at least 1500 octets. + + + +Simpson [Page 41] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + A summary of the Maximum-Receive-Unit Configuration Option format is + shown below. The fields are transmitted from 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 | Maximum-Receive-Unit | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 1 + + Length + + 4 + + Maximum-Receive-Unit + + The Maximum-Receive-Unit field is two octets, and specifies the + maximum number of octets in the Information and Padding fields. + It does not include the framing, Protocol field, FCS, nor any + transparency bits or bytes. + +6.2 Async-Control-Character-Map + + Description + + This Configuration Option provides a method to negotiate the use + of control character transparency on asynchronous links. + + For asynchronous links, the default value is 0xffffffff, which + causes all octets less than 0x20 to be mapped into an appropriate + two octet sequence. For most other links, the default value is 0, + since there is no need for mapping. + + However, it is rarely necessary to map all control characters, and + often it is unnecessary to map any control characters. The + Configuration Option is used to inform the peer which control + characters MUST remain mapped when the peer sends them. + + The peer MAY still send any other octets in mapped format, if it + is necessary because of constraints known to the peer. The peer + SHOULD Configure-Nak with the logical union of the sets of mapped + octets, so that when such octets are spuriously introduced they + can be ignored on receipt. + + + + +Simpson [Page 42] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + A summary of the Async-Control-Character-Map Configuration Option + format is shown below. The fields are transmitted from 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 | Async-Control-Character-Map + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ACCM (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 2 + + Length + + 6 + + Async-Control-Character-Map + + The Async-Control-Character-Map field is four octets and indicates + the set of control characters to be mapped. The map is sent most + significant octet first. + + Each numbered bit corresponds to the octet of the same value. If + the bit is cleared to zero, then that octet need not be mapped. + If the bit is set to one, then that octet MUST remain mapped. For + example, if bit 19 is set to zero, then the ASCII control + character 19 (DC3, Control-S) MAY be sent in the clear. + + Note: The least significant bit of the least significant octet + (the final octet transmitted) is numbered bit 0, and would map + to the ASCII control character NUL. + +6.3 Authentication-Protocol + + Description + + On some links it may be desirable to require a peer to + authenticate itself before allowing network-layer protocol packets + to be exchanged. + + This Configuration Option provides a method to negotiate the use + of a specific authentication protocol. By default, authentication + is not required. + + + + +Simpson [Page 43] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + An implementation MUST NOT include multiple Authentication- + Protocol Configuration Options in its Configure-Request packets. + Instead, it SHOULD attempt to configure the most desirable + protocol first. If that protocol is Configure-Nak'd, then the + implementation SHOULD attempt the next most desirable protocol in + the next Configure-Request. + + If an implementation sends a Configure-Ack with this Configuration + Option, then it is agreeing to authenticate with the specified + protocol. An implementation receiving a Configure-Ack with this + Configuration Option SHOULD expect the peer to authenticate with + the acknowledged protocol. + + There is no requirement that authentication be full duplex or that + the same protocol be used in both directions. It is perfectly + acceptable for different protocols to be used in each direction. + This will, of course, depend on the specific protocols negotiated. + + A summary of the Authentication-Protocol Configuration Option format + is shown below. The fields are transmitted from 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 | Authentication-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Type + + 3 + + Length + + >= 4 + + Authentication-Protocol + + The Authentication-Protocol field is two octets and indicates the + authentication protocol desired. Values for this field are always + the same as the PPP Protocol field values for that same + authentication protocol. + + Up-to-date values of the Authentication-Protocol field are + specified in the most recent "Assigned Numbers" RFC [2]. Current + values are assigned as follows: + + + + +Simpson [Page 44] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Value (in hex) Protocol + + c023 Password Authentication Protocol + c223 Challenge Handshake Authentication Protocol + + Data + + The Data field is zero or more octets and contains additional data + as determined by the particular protocol. + +6.4 Quality-Protocol + + Description + + On some links it may be desirable to determine when, and how + often, the link is dropping data. This process is called link + quality monitoring. + + This Configuration Option provides a method to negotiate the use + of a specific protocol for link quality monitoring. By default, + link quality monitoring is disabled. + + There is no requirement that quality monitoring be full duplex or + that the same protocol be used in both directions. It is + perfectly acceptable for different protocols to be used in each + direction. This will, of course, depend on the specific protocols + negotiated. + + A summary of the Quality-Protocol Configuration Option format is + shown below. The fields are transmitted from 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 | Quality-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Type + + 4 + + Length + + >= 4 + + + + + +Simpson [Page 45] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Quality-Protocol + + The Quality-Protocol field is two octets and indicates the link + quality monitoring protocol desired. Values for this field are + always the same as the PPP Protocol field values for that same + monitoring protocol. + + Up-to-date values of the Quality-Protocol field are specified in + the most recent "Assigned Numbers" RFC [2]. Current values are + assigned as follows: + + Value (in hex) Protocol + + c025 Link Quality Report + + Data + + The Data field is zero or more octets and contains additional data + as determined by the particular protocol. + +6.5 Magic-Number + + Description + + This Configuration Option provides a method to detect looped-back + links and other Data Link Layer anomalies. This Configuration + Option MAY be required by some other Configuration Options such as + the Quality-Protocol Configuration Option. By default, the + Magic-Number is not negotiated, and zero is inserted where a + Magic-Number might otherwise be used. + + Before this Configuration Option is requested, an implementation + MUST choose its Magic-Number. It is recommended that the Magic- + Number be chosen in the most random manner possible in order to + guarantee with very high probability that an implementation will + arrive at a unique number. A good way to choose a unique random + number is to start with an unique seed. Suggested sources of + uniqueness include machine serial numbers, other network hardware + addresses, time-of-day clocks, etc. Particularly good random + number seeds are precise measurements of the inter-arrival time of + physical events such as packet reception on other connected + networks, server response time, or the typing rate of a human + user. It is also suggested that as many sources as possible be + used simultaneously. + + When a Configure-Request is received with a Magic-Number + Configuration Option, the received Magic-Number is compared with + the Magic-Number of the last Configure-Request sent to the peer. + + + +Simpson [Page 46] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + If the two Magic-Numbers are different, then the link is not + looped-back, and the Magic-Number SHOULD be acknowledged. If the + two Magic-Numbers are equal, then it is possible, but not certain, + that the link is looped-back and that this Configure-Request is + actually the one last sent. To determine this, a Configure-Nak + MUST be sent specifying a different Magic-Number value. A new + Configure-Request SHOULD NOT be sent to the peer until normal + processing would cause it to be sent (that is, until a Configure- + Nak is received or the Restart timer runs out). + + Reception of a Configure-Nak with a Magic-Number different from + that of the last Configure-Nak sent to the peer proves that a link + is not looped-back, and indicates a unique Magic-Number. If the + Magic-Number is equal to the one sent in the last Configure-Nak, + the possibility of a looped-back link is increased, and a new + Magic-Number MUST be chosen. In either case, a new Configure- + Request SHOULD be sent with the new Magic-Number. + + If the link is indeed looped-back, this sequence (transmit + Configure-Request, receive Configure-Request, transmit Configure- + Nak, receive Configure-Nak) will repeat over and over again. If + the link is not looped-back, this sequence might occur a few + times, but it is extremely unlikely to occur repeatedly. More + likely, the Magic-Numbers chosen at either end will quickly + diverge, terminating the sequence. The following table shows the + probability of collisions assuming that both ends of the link + select Magic-Numbers with a perfectly uniform distribution: + + Number of Collisions Probability + -------------------- --------------------- + 1 1/2**32 = 2.3 E-10 + 2 1/2**32**2 = 5.4 E-20 + 3 1/2**32**3 = 1.3 E-29 + + Good sources of uniqueness or randomness are required for this + divergence to occur. If a good source of uniqueness cannot be + found, it is recommended that this Configuration Option not be + enabled; Configure-Requests with the option SHOULD NOT be + transmitted and any Magic-Number Configuration Options which the + peer sends SHOULD be either acknowledged or rejected. In this + case, loop-backs cannot be reliably detected by the + implementation, although they may still be detectable by the peer. + + If an implementation does transmit a Configure-Request with a + Magic-Number Configuration Option, then it MUST NOT respond with a + Configure-Reject if it receives a Configure-Request with a Magic- + Number Configuration Option. That is, if an implementation + desires to use Magic Numbers, then it MUST also allow its peer to + + + +Simpson [Page 47] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + do so. If an implementation does receive a Configure-Reject in + response to a Configure-Request, it can only mean that the link is + not looped-back, and that its peer will not be using Magic- + Numbers. In this case, an implementation SHOULD act as if the + negotiation had been successful (as if it had instead received a + Configure-Ack). + + The Magic-Number also may be used to detect looped-back links + during normal operation as well as during Configuration Option + negotiation. All LCP Echo-Request, Echo-Reply, and Discard- + Request packets have a Magic-Number field. If Magic-Number has + been successfully negotiated, an implementation MUST transmit + these packets with the Magic-Number field set to its negotiated + Magic-Number. + + The Magic-Number field of these packets SHOULD be inspected on + reception. All received Magic-Number fields MUST be equal to + either zero or the peer's unique Magic-Number, depending on + whether or not the peer negotiated a Magic-Number. Reception of a + Magic-Number field equal to the negotiated local Magic-Number + indicates a looped-back link. Reception of a Magic- Number other + than the negotiated local Magic-Number or the peer's negotiated + Magic-Number, or zero if the peer didn't negotiate one, indicates + a link which has been (mis)configured for communications with a + different peer. + + Procedures for recovery from either case are unspecified and may + vary from implementation to implementation. A somewhat + pessimistic procedure is to assume a LCP Down event. A further + Open event will begin the process of re-establishing the link, + which can't complete until the loop-back condition is terminated + and Magic-Numbers are successfully negotiated. A more optimistic + procedure (in the case of a loop-back) is to begin transmitting + LCP Echo-Request packets until an appropriate Echo-Reply is + received, indicating a termination of the loop-back condition. + + A summary of the Magic-Number Configuration Option format is shown + below. The fields are transmitted from 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 | Magic-Number + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic-Number (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + +Simpson [Page 48] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Type + + 5 + + Length + + 6 + + Magic-Number + + The Magic-Number field is four octets and indicates a number which + is very likely to be unique to one end of the link. A Magic- + Number of zero is illegal and MUST always be Nak'd, if it is not + Rejected outright. + +6.6 Protocol-Field-Compression + + Description + + This Configuration Option provides a method to negotiate the + compression of the PPP Protocol field. By default, all + implementations MUST transmit packets with two octet PPP Protocol + fields. + + PPP Protocol field numbers are chosen such that some values may be + compressed into a single octet form which is clearly + distinguishable from the two octet form. This Configuration + Option is sent to inform the peer that the implementation can + receive such single octet Protocol fields. + + As previously mentioned, the Protocol field uses an extension + mechanism consistent with the ISO 3309 extension mechanism for the + Address field; the Least Significant Bit (LSB) of each octet is + used to indicate extension of the Protocol field. A binary "0" as + the LSB indicates that the Protocol field continues with the + following octet. The presence of a binary "1" as the LSB marks + the last octet of the Protocol field. Notice that any number of + "0" octets may be prepended to the field, and will still indicate + the same value (consider the two binary representations for 3, + 00000011 and 00000000 00000011). + + When using low speed links, it is desirable to conserve bandwidth + by sending as little redundant data as possible. The Protocol- + Field-Compression Configuration Option allows a trade-off between + implementation simplicity and bandwidth efficiency. If + successfully negotiated, the ISO 3309 extension mechanism may be + used to compress the Protocol field to one octet instead of two. + The large majority of packets are compressible since data + + + +Simpson [Page 49] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + protocols are typically assigned with Protocol field values less + than 256. + + Compressed Protocol fields MUST NOT be transmitted unless this + Configuration Option has been negotiated. When negotiated, PPP + implementations MUST accept PPP packets with either double-octet + or single-octet Protocol fields, and MUST NOT distinguish between + them. + + The Protocol field is never compressed when sending any LCP + packet. This rule guarantees unambiguous recognition of LCP + packets. + + When a Protocol field is compressed, the Data Link Layer FCS field + is calculated on the compressed frame, not the original + uncompressed frame. + + A summary of the Protocol-Field-Compression Configuration Option + format is shown below. The fields are transmitted from left to + right. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 7 + + Length + + 2 + +6.7 Address-and-Control-Field-Compression + + Description + + This Configuration Option provides a method to negotiate the + compression of the Data Link Layer Address and Control fields. By + default, all implementations MUST transmit frames with Address and + Control fields appropriate to the link framing. + + Since these fields usually have constant values for point-to-point + links, they are easily compressed. This Configuration Option is + sent to inform the peer that the implementation can receive + compressed Address and Control fields. + + + +Simpson [Page 50] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + If a compressed frame is received when Address-and-Control-Field- + Compression has not been negotiated, the implementation MAY + silently discard the frame. + + The Address and Control fields MUST NOT be compressed when sending + any LCP packet. This rule guarantees unambiguous recognition of + LCP packets. + + When the Address and Control fields are compressed, the Data Link + Layer FCS field is calculated on the compressed frame, not the + original uncompressed frame. + + A summary of the Address-and-Control-Field-Compression configuration + option format is shown below. The fields are transmitted from left + to right. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 8 + + Length + + 2 + +A. LCP Recommended Options + + The following Configurations Options are recommended: + + SYNC LINES + + Magic Number Link Quality Monitoring No Address and Control Field + Compression No Protocol Field Compression + + ASYNC LINES + + Async Control Character Map Magic Number Address and Control Field + Compression Protocol Field Compression + +Security Considerations + + Security issues are briefly discussed in sections concerning the + Authentication Phase, the Close event, and the Authentication- + + + +Simpson [Page 51] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Protocol Configuration Option. Further discussion is in a companion + document entitled PPP Authentication Protocols. + + +References + + [1] Perkins, D., "Requirements for an Internet Standard + Point-to-Point Protocol", RFC 1547, December 1993. + + [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, + USC/Information Sciences Institute, July 1992. + +Acknowledgments + + Much of the text in this document is taken from the WG Requirements, + and RFCs 1171 & 1172, by Drew Perkins of Carnegie Mellon University, + and by Russ Hobby of the University of California at Davis. + + Many people spent significant time helping to develop the Point-to- + Point Protocol. The complete list of people is too numerous to list, + but the following people deserve special thanks: Rick Adams (UUNET), + Ken Adelman (TGV), Fred Baker (ACC), Mike Ballard (Telebit), Craig + Fox (Network Systems), Karl Fox (Morning Star Technologies), Phill + Gross (AN&S), former WG chair Russ Hobby (UC Davis), David Kaufman + (Proteon), former WG chair Steve Knowles (FTP Software), former WG + chair Brian Lloyd (L&A), John LoVerso (Xylogics), Bill Melohn (Sun + Microsystems), Mike Patton (MIT), former WG chair Drew Perkins + (Fore), Greg Satz (cisco systems), John Shriver (Proteon), Vernon + Schryver (Silicon Graphics), and Asher Waldfogel (Wellfleet). + + The "Day in the Life" example was instigated by Kory Hamzeh (Avatar). + In this version, improvements in wording were also provided by Scott + Ginsburg, Mark Moraes, and Timon Sloan, as they worked on + implementations. + + Special thanks to Morning Star Technologies for providing computing + resources and network access support for writing this specification. + +Chair's Address + + The working group can be contacted via the current chair: + + Fred Baker + Advanced Computer Communications + 315 Bollay Drive + Santa Barbara, California, 93111 + + EMail: fbaker@acc.com + + + +Simpson [Page 52] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +Editor's Address + + Questions about this memo can also be directed to: + + William Allen Simpson + Daydreamer + Computer Systems Consulting Services + 1384 Fontaine + Madison Heights, Michigan 48071 + + EMail: Bill.Simpson@um.cc.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 53] + diff --git a/rfc/rfc1570.txt b/rfc/rfc1570.txt new file mode 100644 index 00000000..edda5d99 --- /dev/null +++ b/rfc/rfc1570.txt @@ -0,0 +1,1057 @@ + + + + + + +Network Working Group W. Simpson, Editor +Request for Comments: 1570 Daydreamer +Updates: 1548 January 1994 +Category: Standards Track + + + PPP LCP Extensions + +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 + defines an extensible Link Control Protocol (LCP) for establishing, + configuring, and testing the data-link connection. This document + defines several additional LCP features which have been suggested + over the past few years. + + This document is the product of the Point-to-Point Protocol Working + Group of the Internet Engineering Task Force (IETF). Comments should + be submitted to the ietf-ppp@ucdavis.edu mailing list. + +Table of Contents + + 1. Additional LCP Packets ................................ 1 + 1.1 Identification .................................. 1 + 1.2 Time-Remaining .................................. 3 + 2. Additional LCP Configuration Options .................. 6 + 2.1 FCS-Alternatives ................................ 6 + 2.1.1 LCP considerations .............................. 7 + 2.1.2 Null FCS ........................................ 8 + 2.2 Self-Describing-Padding ......................... 9 + 2.3 Callback ........................................ 11 + 2.4 Compound-Frames ................................. 12 + 2.4.1 LCP considerations .............................. 14 + APPENDICES ................................................... 15 + A. Fast Frame Check Sequence (FCS) Implementation ........ 15 + A.1 32-bit FCS Computation Method ................... 15 + SECURITY CONSIDERATIONS ...................................... 17 + REFERENCES ................................................... 17 + ACKNOWLEDGEMENTS ............................................. 18 + CHAIR'S ADDRESS .............................................. 18 + EDITOR'S ADDRESS ............................................. 18 + + + + + + + + +Simpson [Page i] + RFC 1570 PPP LCP extensions January 1994 + + +1. Additional LCP Packets + + The Packet format and basic facilities are already defined for LCP + [1]. + + Up-to-date values of the LCP Code field are specified in the most + recent "Assigned Numbers" RFC [2]. This specification concerns the + following values: + + 12 Identification + 13 Time-Remaining + + + + +1.1. Identification + + Description + + This Code provides a method for an implementation to identify + itself to its peer. This Code might be used for many diverse + purposes, such as link troubleshooting, license enforcement, etc. + + Identification is a Link Maintenance packet. Identification + packets MAY be sent at any time, including before LCP has reached + the Opened state. + + The sender transmits a LCP packet with the Code field set to 12 + (Identification), the Identifier field set, the local Magic-Number + (if any) inserted, and the Message field filled with any desired + data, but not exceeding the default MRU minus eight. + + Receipt of an Identification packet causes the RXR or RUC event. + There is no response to the Identification packet. + + Receipt of a Code-Reject for the Identification packet SHOULD + generate the RXJ+ (permitted) event. + + Rationale: + + This feature is defined as part of LCP, rather than as a + separate PPP Protocol, in order that its benefits may be + available during the earliest possible stage of the Link + Establishment phase. It allows an operator to learn the + identification of the peer even when negotiation is not + converging. Non-LCP packets cannot be sent during the Link + Establishment phase. + + + + +Simpson [Page 1] + RFC 1570 PPP LCP extensions January 1994 + + + This feature is defined as a separate LCP Code, rather than a + Configuration-Option, so that the peer need not include it with + other items in configuration packet exchanges, and handle + "corrected" values or "rejection", since its generation is both + rare and in one direction. It is recommended that + Identification packets be sent whenever a Configure-Reject is + sent or received, as a final message when negotiation fails to + converge, and when LCP reaches the Opened state. + + A summary of the Identification packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic-Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message ... + +-+-+-+-+-+-+-+-+ + + + Code + + 12 for Identification + + Identifier + + The Identifier field MUST be changed for each Identification sent. + + Length + + >= 8 + + Magic-Number + + The Magic-Number field is four octets and aids in detecting links + which are in the looped-back condition. Until the Magic-Number + Configuration Option has been successfully negotiated, the Magic- + Number MUST be transmitted as zero. See the Magic-Number + Configuration Option for further explanation. + + Message + + The Message field is zero or more octets, and its contents are + implementation dependent. It is intended to be human readable, + and MUST NOT affect operation of the protocol. It is recommended + + + +Simpson [Page 2] + RFC 1570 PPP LCP extensions January 1994 + + + that the message contain displayable ASCII characters 32 through + 126 decimal. Mechanisms for extension to other character sets are + the topic of future research. The size is determined from the + Length field. + + Implementation Note: + + The Message will usually contain such things as the sender's + hardware type, PPP software revision level, and PPP product + serial number, MIB information such as link speed and interface + name, and any other information that the sender thinks might be + useful in debugging connections. The format is likely to be + different for each implementor, so that those doing serial + number tracking can validate their numbers. A robust + implementation SHOULD treat the Message as displayable text, + and SHOULD be able to receive and display a very long Message. + + + +1.2. Time-Remaining + + Description + + This Code provides a mechanism for notifying the peer of the time + remaining in this session. + + The nature of this information is advisory only. It is intended + that only one side of the connection will send this packet + (generally a "network access server"). The session is actually + concluded by the Terminate-Request packet. + + Time-Remaining is a Link Maintenance packet. Time-Remaining + packets may only be sent in the LCP Opened state. + + The sender transmits a LCP packet with the Code field set to 13 + (Time-Remaining), the Identifier field set, the local Magic-Number + (if any) inserted, and the Message field filled with any desired + data, but not exceeding the peer's established MRU minus twelve. + + Receipt of an Time-Remaining packet causes the RXR or RUC event. + There is no response to the Time-Remaining packet. + + Receipt of a Code-Reject for the Time-Remaining packet SHOULD + generate the RXJ+ (permitted) event. + + Rationale: + + This notification is defined as a separate LCP Code, rather + + + +Simpson [Page 3] + RFC 1570 PPP LCP extensions January 1994 + + + than a Configuration-Option, in order that changes and warning + messages may occur dynamically during the session, and that the + information might be determined after Authentication has + occurred. Typically, this packet is sent when the link enters + Network-Layer Protocol phase, and at regular intervals + throughout the session, particularly near the end of the + session. + + A summary of the Time-Remaining packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic-Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Seconds-Remaining | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message ... + +-+-+-+-+-+-+-+-+ + + + Code + + 13 for Time-Remaining + + Identifier + + The Identifier field MUST be changed for each Time-Remaining sent. + + Length + + >= 12 + + Magic-Number + + The Magic-Number field is four octets and aids in detecting links + which are in the looped-back condition. Until the Magic-Number + Configuration Option has been successfully negotiated, the Magic- + Number MUST be transmitted as zero. See the Magic-Number + Configuration Option for further explanation. + + Seconds-Remaining + + The Seconds-Remaining field is four octets and indicates the + number of integral seconds remaining in this session. This 32 bit + + + +Simpson [Page 4] + RFC 1570 PPP LCP extensions January 1994 + + + unsigned value is sent most significant octet first. A value of + 0xffffffff (all ones) represents no timeout, or "forever". + + Message + + The Message field is zero or more octets, and its contents are + implementation dependent. It is intended to be human readable, + and MUST NOT affect operation of the protocol. It is recommended + that the message contain displayable ASCII characters 32 through + 126 decimal. Mechanisms for extension to other character sets are + the topic of future research. The size is determined from the + Length field. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 5] + RFC 1570 PPP LCP extensions January 1994 + + +2. Additional LCP Configuration Options + + The Configuration Option format and basic options are already defined + for LCP [1]. + + Up-to-date values of the LCP Option Type field are specified in the + most recent "Assigned Numbers" RFC [2]. This document concerns the + following values: + + 9 FCS-Alternatives + 10 Self-Describing-Padding + 13 Callback + 15 Compound-Frames + + + + +2.1. FCS-Alternatives + + Description + + This Configuration Option provides a method for an implementation + to specify another FCS format to be sent by the peer, or to + negotiate away the FCS altogether. + + This option is negotiated separately in each direction. However, + it is not required that an implementation be capable of + concurrently generating a different FCS on each side of the link. + + The negotiated FCS values take effect only during Authentication + and Network-Layer Protocol phases. Frames sent during any other + phase MUST contain the default FCS. + + A summary of the FCS-Alternatives Configuration Option format is + shown below. The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Options | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 9 + + + + + +Simpson [Page 6] + RFC 1570 PPP LCP extensions January 1994 + + + Length + + 3 + + Options + + This field is one octet, and is comprised of the "logical or" of + the following values: + + 1 Null FCS + 2 CCITT 16-bit FCS + 4 CCITT 32-bit FCS + + + Implementation Note: + + For most PPP HDLC framed links, the default FCS is the CCITT 16- + bit FCS. Some framing techniques and high speed links may use + another format as the default FCS. + + +2.1.1. LCP considerations + + The link can be subject to loss of state, and the LCP can re- + negotiate at any time. When the LCP begins renegotiation or + termination, it is recommended that the LCP Configure-Request or + Terminate-Request packet be sent with the last negotiated FCS, then + change to the default FCS, and a duplicate LCP packet is sent with + the default FCS. The Identifier field SHOULD NOT be incremented for + each such duplicate packet. + + On receipt of a LCP Configure-Request or Terminate-Request packet, + the implementation MUST change to the default FCS for both + transmission and reception. If a Request packet is received which + contains a duplicate Identifier field, a new reply MUST be generated. + + Implementation Notes: + + The need to send two packets is only necessary after the + Alternative-FCS has already been negotiated. It need not occur + during state transitions when there is a natural indication that + the default FCS is in effect, such as the Down and Up events. It + is necessary to send two packets in the Ack-Sent and Opened + states, since the peer could mistakenly believe that the link has + Opened. + + It is possible to send a single 48-bit FCS which is a combination + of the 16-bit and 32-bit FCS. This may be sent instead of sending + + + +Simpson [Page 7] + RFC 1570 PPP LCP extensions January 1994 + + + the two packets described above. We have not standardized this + procedure because of intellectual property concerns. If such a + 48-bit FCS is used, it MUST only be used for LCP packets. + + +2.1.2. Null FCS + + The Null FCS SHOULD only be used for those network-layer and + transport protocols which have an end-to-end checksum available, such + as TCP/IP, or UDP/IP with the checksum enabled. That is, the Null + FCS option SHOULD be negotiated together with another non-null FCS + option in a heterogeneous environment. + + When a configuration (LCP or NCP) or authentication packet is sent, + the FCS MUST be included. When a configuration (LCP or NCP) or + authentication packet is received, the FCS MUST be verified. + + There are several cases to be considered: + + Null FCS alone + + The sender generates the FCS for those frames which require the + FCS before sending the frame. + + When a frame is received, it is not necessary to check the FCS + before demultiplexing. Any FCS is treated as padding. + + Receipt of an Authentication or Control packet would be discovered + after passing the frame to the demultiplexer. Verification of the + FCS can easily be accomplished using one of the software + algorithms defined in "PPP in HDLC Framing" [3] (16-bit FCS) and + Appendix A (32-bit FCS). + + Null FCS with another FCS, using software + + This is similar to the above case. + + Those packets which are required to have the FCS (Authentication, + Control, or Network-Protocols lacking a checksum) are checked + using software after demultiplexing. Packets which fail the FCS + test are discarded as usual. + + Null FCS with another FCS, using hardware + + A flag is passed with the frame, indicating whether or not it has + passed the hardware FCS check. The incorrect FCS MUST be passed + with the rest of the data. The frame MUST NOT be discarded until + after demultiplexing, and only those frames that require the FCS + + + +Simpson [Page 8] + RFC 1570 PPP LCP extensions January 1994 + + + are discarded. + + All three FCS forms (Null, 16 and 32) may be used concurrently on + different frames when using software. That is probably not possible + with most current hardware. + + + +2.2. Self-Describing-Padding + + Description + + This Configuration Option provides a method for an implementation + to indicate to the peer that it understands self-describing pads + when padding is added at the end of the PPP Information field. + + This option is most likely to be used when some protocols, such as + network-layer or compression protocols, are configured which + require detection and removal of any trailing padding. Such + special protocols are identified in their respective documents. + + If the option is Rejected, the peer MUST NOT add any padding to + the identified special protocols, but MAY add padding to other + protocols. + + If the option is Ack'd, the peer MUST follow the procedures for + adding self-describing pads, but only to the specifically + identified protocols. The peer is not required to add any padding + to other protocols. + + Implementation Notes: + + This is defined so that the Reject handles either case where + the peer does not generate self-describing pads. When the peer + never generates padding, it may safely Reject the option. When + the peer does not understand the option, it also will not + successfully configure a special protocol which requires + elimination of pads. + + While some senders might only be capable of adding padding to + every protocol or not adding padding to any protocol, by design + the receiver need not examine those protocols which do not need + the padding stripped. + + To avoid unnecessary configuration handshakes, an + implementation which generates padding, and has a protocol + configured which requires the padding to be known, SHOULD + include this Option in its Configure-Request, and SHOULD + + + +Simpson [Page 9] + RFC 1570 PPP LCP extensions January 1994 + + + Configure-Nak with this Option when it is not present in the + peer's Request. + + Each octet of self-describing pad contains the index of that + octet. The first pad octet MUST contain the value one (1), which + indicates the Padding Protocol to the Compound-Frames option. + After removing the FCS, the final pad octet indicates the number + of pad octets to remove. For example, three pad octets would + contain the values 1, 2, 3. + + The Maximum-Pad-Value (MPV) is also negotiated. Only the values 1 + through MPV are used. When no padding would otherwise be + required, but the final octet of the PPP Information field + contains the value 1 through MPV, at least one self-describing pad + octet MUST be added to the frame. If the final octet is greater + than MPV, no additional padding is required. + + Implementation Notes: + + If any of the pad octets contain an incorrect index value, the + entire frame SHOULD be silently discarded. This is intended to + prevent confusion with the FCS-Alternatives option, but might + not be necessary in robust implementations. + + Since this option is intended to support compression protocols, + the Maximum-Pad-Value is specified to limit the likelihood that + a frame may actually become longer. + + A summary of the Self-Describing-Padding Configuration Option format + is shown below. The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Maximum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 10 + + Length + + 3 + + + + + + +Simpson [Page 10] + RFC 1570 PPP LCP extensions January 1994 + + + Maximum + + This field specifies the largest number of padding octets which + may be added to the frame. The value may range from 1 to 255, but + values of 2, 4, or 8 are most likely. + + + +2.3. Callback + + Description + + This Configuration Option provides a method for an implementation + to request a dial-up peer to call back. This option might be used + for many diverse purposes, such as savings on toll charges. + + When Callback is successfully negotiated, and authentication is + complete, the Authentication phase proceeds directly to the + Termination phase, and the link is disconnected. + + Then, the peer re-establishes the link, without negotiating + Callback. + + Implementation Notes: + + A peer which agrees to this option SHOULD request the + Authentication-Protocol Configuration Option. The user + information learned during authentication can be used to + determine the user location, or to limit a user to certain + locations, or merely to determine whom to bill for the service. + + Authentication SHOULD be requested in turn by the + implementation when it is called back, if mutual authentication + is desired. + + A summary of the Callback Option format is shown below. The fields + are transmitted from 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 | Operation | Message ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 13 + + + +Simpson [Page 11] + RFC 1570 PPP LCP extensions January 1994 + + + Length + + >= 3 + + Operation + + The Operation field is one octet and indicates the contents of the + Message field. + + 0 location is determined by user authentication + + 1 Dialing string, the format and contents of which assumes + configuration knowledge of the specific device which is + making the callback. + + 2 Location identifier, which may or may not be human + readable, to be used together with the authentication + information for a database lookup to determine the + callback location. + + 3 E.164 number. + + 4 Distinguished name. + + Message + + The Message field is zero or more octets, and its general contents + are determined by the Operation field. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + The size is determined from the Length field. + + It is intended that only an authorized user will have correct site + specific information to make use of the Callback. The + codification of the range of allowed usage of this field is + outside the scope of this specification. + + + +2.4. Compound-Frames + + Description + + This Configuration Option provides a method for an implementation + to send multiple PPP encapsulated packets within the same frame. + This option might be used for many diverse purposes, such as + savings on toll charges. + + + + +Simpson [Page 12] + RFC 1570 PPP LCP extensions January 1994 + + + Only those PPP Protocols which have determinate lengths or + integral length fields may be aggregated into a compound frame. + + When Compound-Frames is successfully negotiated, the sender MAY + add additional packets to the same frame. Each packet is + immediately followed by another Protocol field, with its attendant + datagram. + + When padding is added to the end of the Information field, the + procedure described in Self-Describing-Padding is used. + Therefore, this option MUST be negotiated together with the Self- + Describing-Padding option. + + If the FCS-Alternatives option has been negotiated, self + describing padding MUST always be added. That is, the final + packet MUST be followed by a series of octets, the first of which + contains the value one (1). + + On receipt, the first Protocol field is examined, and the packet + is processed as usual. For those datagrams which have a + determinate length, the remainder of the frame is returned to the + demultiplexor. Each succeeding Protocol field is processed as a + separate packet. This processing is complete when a packet is + processed which does not have a determinate length, when the + remainder of the frame is empty, or when the Protocol field is + determined to have a value of one (1). + + The PPP Protocol value of one (1) is reserved as the Padding + Protocol. Any following octets are removed as padding. + + A summary of the Compound-Frames Option format is shown below. The + fields are transmitted from left to right. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 15 + + Length + + 2 + + + + +Simpson [Page 13] + RFC 1570 PPP LCP extensions January 1994 + + +2.4.1. LCP considerations + + During initial negotiation, the Compound-Frames option can be used to + minimize the negotiation latency, by reducing the number of frames + exchanged. + + The first LCP Configure-Request packet is sent as usual in a single + frame, including the Self-Describing-Padding and Compound-Frames + options. + + The peer SHOULD respond with a Configure-Ack, followed in a compound + frame by its LCP Configure-Request, and any NCP Configure-Requests + desired. + + Upon receipt, the local implementation SHOULD process the Configure- + Ack as usual. Since the peer has agreed to send compound frames, the + implementation MUST examine the remainder of the frame for additional + packets. If the peer also specified the Self-Describing-Padding and + Compound-Frames options in its Configure-Request, the local + implementation SHOULD retain its Configure-Ack, and further NCP + configuration packets SHOULD be added to the return frame. + + Together with the peer's final return frame, the minimum number of + frames to complete configuration is 4. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 14] + RFC 1570 PPP LCP extensions January 1994 + + +A. Fast Frame Check Sequence (FCS) Implementation + +A.1. 32-bit FCS Computation Method + + The following code provides a table lookup computation for + calculating the 32-bit Frame Check Sequence as data arrives at the + interface. + + /* + * u32 represents an unsigned 32-bit number. Adjust the typedef for + * your hardware. + */ + typedef unsigned long u32; + + static u32 fcstab_32[256] = + { + 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, + 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3, + 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988, + 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91, + 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de, + 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, + 0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, + 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5, + 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172, + 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b, + 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, + 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59, + 0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, + 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f, + 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924, + 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, + 0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a, + 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433, + 0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818, + 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01, + 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, + 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457, + 0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c, + 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65, + 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, + 0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb, + 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0, + 0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9, + 0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086, + 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f, + 0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, + 0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad, + + + +Simpson [Page 15] + RFC 1570 PPP LCP extensions January 1994 + + + 0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a, + 0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683, + 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8, + 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1, + 0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe, + 0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7, + 0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc, + 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5, + 0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252, + 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b, + 0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60, + 0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79, + 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236, + 0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, + 0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04, + 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d, + 0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a, + 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713, + 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38, + 0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, + 0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e, + 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777, + 0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c, + 0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45, + 0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2, + 0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db, + 0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0, + 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9, + 0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, + 0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf, + 0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94, + 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d + }; + + #define PPPINITFCS32 0xffffffff /* Initial FCS value */ + #define PPPGOODFCS32 0xdebb20e3 /* Good final FCS value */ + + /* + * Calculate a new FCS given the current FCS and the new data. + */ + u32 pppfcs32(fcs, cp, len) + register u32 fcs; + register unsigned char *cp; + register int len; + { + ASSERT(sizeof (u32) == 4); + ASSERT(((u32) -1) > 0); + while (len--) + + + +Simpson [Page 16] + RFC 1570 PPP LCP extensions January 1994 + + + fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]); + + return (fcs); + } + + /* + * How to use the fcs + */ + tryfcs32(cp, len) + register unsigned char *cp; + register int len; + { + u32 trialfcs; + + /* add on output */ + trialfcs = pppfcs32( PPPINITFCS32, cp, len ); + trialfcs ^= 0xffffffff; /* complement */ + cp[len] = (trialfcs & 0x00ff); /* Least significant byte first */ + cp[len+1] = ((trialfcs >>= 8) & 0x00ff); + cp[len+2] = ((trialfcs >>= 8) & 0x00ff); + cp[len+3] = ((trialfcs >> 8) & 0x00ff); + + /* check on input */ + trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 ); + if ( trialfcs == PPPGOODFCS32 ) + printf("Good FCS\n"); + } + + +Security Considerations + + Security issues are briefly discussed in sections concerning the + Callback Configuration Option. + + +References + + [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC + 1548, Daydreamer, December 1993. + + [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, + RFC 1340, USC/Information Sciences Institute, July 1992. + + [3] Simpson, W., Editor, "PPP in HDLC Framing", RFC 1549, + Daydreamer, December 1993. + + + + + + +Simpson [Page 17] + RFC 1570 PPP LCP extensions January 1994 + + +Acknowledgments + + The Identification feature was suggested by Bob Sutterfield (Morning + Star Technologies). + + The Time-Remaining feature was suggested by Brad Parker (FCR). + + Some of the original text for FCS-Alternatives was provided by Arthur + Harvey (then of DEC). The Null FCS was requested by Peter Honeyman + (UMich). The 32-bit FCS example code was provided by Karl Fox + (Morning Star Technologies). + + Self-Describing-Padding was suggested and named by Fred Baker (ACC). + + Compound-Frames was suggested by Keith Sklower (Berkeley). + + Special thanks to Morning Star Technologies for providing computing + resources and network access support for writing this specification. + + +Chair's Address + + The working group can be contacted via the current chair: + + Fred Baker + Advanced Computer Communications + 315 Bollay Drive + Santa Barbara, California 93117 + + EMail: fbaker@acc.com + + +Editor's Address + + Questions about this memo can also be directed to: + + William Allen Simpson + Daydreamer + Computer Systems Consulting Services + 1384 Fontaine + Madison Heights, Michigan 48071 + + EMail: Bill.Simpson@um.cc.umich.edu + bsimpson@MorningStar.com + + + + + + + +Simpson [Page 18] + + diff --git a/rfc/rfc1661.txt b/rfc/rfc1661.txt new file mode 100644 index 00000000..02112bd2 --- /dev/null +++ b/rfc/rfc1661.txt @@ -0,0 +1,2976 @@ + + + + + + +Network Working Group W. Simpson, Editor +Request for Comments: 1661 Daydreamer +STD: 51 July 1994 +Obsoletes: 1548 +Category: Standards Track + + + The Point-to-Point Protocol (PPP) + + + +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) provides a standard method for + transporting multi-protocol datagrams over point-to-point links. PPP + is comprised of three main components: + + 1. A method for encapsulating multi-protocol datagrams. + + 2. A Link Control Protocol (LCP) for establishing, configuring, + and testing the data-link connection. + + 3. A family of Network Control Protocols (NCPs) for establishing + and configuring different network-layer protocols. + + This document defines the PPP organization and methodology, and the + PPP encapsulation, together with an extensible option negotiation + mechanism which is able to negotiate a rich assortment of + configuration parameters and provides additional management + functions. The PPP Link Control Protocol (LCP) is described in terms + of this mechanism. + + +Table of Contents + + + 1. Introduction .......................................... 1 + 1.1 Specification of Requirements ................... 2 + 1.2 Terminology ..................................... 3 + + 2. PPP Encapsulation ..................................... 4 + + +Simpson [Page i] + RFC 1661 Point-to-Point Protocol July 1994 + + + 3. PPP Link Operation .................................... 6 + 3.1 Overview ........................................ 6 + 3.2 Phase Diagram ................................... 6 + 3.3 Link Dead (physical-layer not ready) ............ 7 + 3.4 Link Establishment Phase ........................ 7 + 3.5 Authentication Phase ............................ 8 + 3.6 Network-Layer Protocol Phase .................... 8 + 3.7 Link Termination Phase .......................... 9 + + 4. The Option Negotiation Automaton ...................... 11 + 4.1 State Transition Table .......................... 12 + 4.2 States .......................................... 14 + 4.3 Events .......................................... 16 + 4.4 Actions ......................................... 21 + 4.5 Loop Avoidance .................................. 23 + 4.6 Counters and Timers ............................. 24 + + 5. LCP Packet Formats .................................... 26 + 5.1 Configure-Request ............................... 28 + 5.2 Configure-Ack ................................... 29 + 5.3 Configure-Nak ................................... 30 + 5.4 Configure-Reject ................................ 31 + 5.5 Terminate-Request and Terminate-Ack ............. 33 + 5.6 Code-Reject ..................................... 34 + 5.7 Protocol-Reject ................................. 35 + 5.8 Echo-Request and Echo-Reply ..................... 36 + 5.9 Discard-Request ................................. 37 + + 6. LCP Configuration Options ............................. 39 + 6.1 Maximum-Receive-Unit (MRU) ...................... 41 + 6.2 Authentication-Protocol ......................... 42 + 6.3 Quality-Protocol ................................ 43 + 6.4 Magic-Number .................................... 45 + 6.5 Protocol-Field-Compression (PFC) ................ 48 + 6.6 Address-and-Control-Field-Compression (ACFC) + + SECURITY CONSIDERATIONS ...................................... 51 + REFERENCES ................................................... 51 + ACKNOWLEDGEMENTS ............................................. 51 + CHAIR'S ADDRESS .............................................. 52 + EDITOR'S ADDRESS ............................................. 52 + + + + + + + + + + +Simpson [Page ii] + RFC 1661 Point-to-Point Protocol July 1994 + + +1. Introduction + + The Point-to-Point Protocol is designed for simple links which + transport packets between two peers. These links provide full-duplex + simultaneous bi-directional operation, and are assumed to deliver + packets in order. It is intended that PPP provide a common solution + for easy connection of a wide variety of hosts, bridges and routers + [1]. + + Encapsulation + + The PPP encapsulation provides for multiplexing of different + network-layer protocols simultaneously over the same link. The + PPP encapsulation has been carefully designed to retain + compatibility with most commonly used supporting hardware. + + Only 8 additional octets are necessary to form the encapsulation + when used within the default HDLC-like framing. In environments + where bandwidth is at a premium, the encapsulation and framing may + be shortened to 2 or 4 octets. + + To support high speed implementations, the default encapsulation + uses only simple fields, only one of which needs to be examined + for demultiplexing. The default header and information fields + fall on 32-bit boundaries, and the trailer may be padded to an + arbitrary boundary. + + Link Control Protocol + + In order to be sufficiently versatile to be portable to a wide + variety of environments, PPP provides a Link Control Protocol + (LCP). The LCP is used to automatically agree upon the + encapsulation format options, handle varying limits on sizes of + packets, detect a looped-back link and other common + misconfiguration errors, and terminate the link. Other optional + facilities provided are authentication of the identity of its peer + on the link, and determination when a link is functioning properly + and when it is failing. + + Network Control Protocols + + Point-to-Point links tend to exacerbate many problems with the + current family of network protocols. For instance, assignment and + management of IP addresses, which is a problem even in LAN + environments, is especially difficult over circuit-switched + point-to-point links (such as dial-up modem servers). These + problems are handled by a family of Network Control Protocols + (NCPs), which each manage the specific needs required by their + + + +Simpson [Page 1] + RFC 1661 Point-to-Point Protocol July 1994 + + + respective network-layer protocols. These NCPs are defined in + companion documents. + + Configuration + + It is intended that PPP links be easy to configure. By design, + the standard defaults handle all common configurations. The + implementor can specify improvements to the default configuration, + which are automatically communicated to the peer without operator + intervention. Finally, the operator may explicitly configure + options for the link which enable the link to operate in + environments where it would otherwise be impossible. + + This self-configuration is implemented through an extensible + option negotiation mechanism, wherein each end of the link + describes to the other its capabilities and requirements. + Although the option negotiation mechanism described in this + document is specified in terms of the Link Control Protocol (LCP), + the same facilities are designed to be used by other control + protocols, especially the family of NCPs. + + + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST This word, or the adjective "required", means that the + definition is an absolute requirement of the specification. + + MUST NOT This phrase means that the definition is an absolute + prohibition of the specification. + + SHOULD This word, or the adjective "recommended", means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications must be + understood and carefully weighed before choosing a + different course. + + MAY This word, or the adjective "optional", means that this + item is one of an allowed set of alternatives. An + implementation which does not include this option MUST be + prepared to interoperate with another implementation which + does include the option. + + + + + + +Simpson [Page 2] + RFC 1661 Point-to-Point Protocol July 1994 + + +1.2. Terminology + + This document frequently uses the following terms: + + datagram The unit of transmission in the network layer (such as IP). + A datagram may be encapsulated in one or more packets + passed to the data link layer. + + frame The unit of transmission at the data link layer. A frame + may include a header and/or a trailer, along with some + number of units of data. + + packet The basic unit of encapsulation, which is passed across the + interface between the network layer and the data link + layer. A packet is usually mapped to a frame; the + exceptions are when data link layer fragmentation is being + performed, or when multiple packets are incorporated into a + single frame. + + peer The other end of the point-to-point link. + + silently discard + The implementation discards the packet without further + processing. The implementation SHOULD provide the + capability of logging the error, including the contents of + the silently discarded packet, and SHOULD record the event + in a statistics counter. + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 3] + RFC 1661 Point-to-Point Protocol July 1994 + + +2. PPP Encapsulation + + The PPP encapsulation is used to disambiguate multiprotocol + datagrams. This encapsulation requires framing to indicate the + beginning and end of the encapsulation. Methods of providing framing + are specified in companion documents. + + A summary of the PPP encapsulation is shown below. The fields are + transmitted from left to right. + + +----------+-------------+---------+ + | Protocol | Information | Padding | + | 8/16 bits| * | * | + +----------+-------------+---------+ + + + Protocol Field + + The Protocol field is one or two octets, and its value identifies + the datagram encapsulated in the Information field of the packet. + The field is transmitted and received most significant octet + first. + + The structure of this field is consistent with the ISO 3309 + extension mechanism for address fields. All Protocols MUST be + odd; the least significant bit of the least significant octet MUST + equal "1". Also, all Protocols MUST be assigned such that the + least significant bit of the most significant octet equals "0". + Frames received which don't comply with these rules MUST be + treated as having an unrecognized Protocol. + + Protocol field values in the "0***" to "3***" range identify the + network-layer protocol of specific packets, and values in the + "8***" to "b***" range identify packets belonging to the + associated Network Control Protocols (NCPs), if any. + + Protocol field values in the "4***" to "7***" range are used for + protocols with low volume traffic which have no associated NCP. + Protocol field values in the "c***" to "f***" range identify + packets as link-layer Control Protocols (such as LCP). + + + + + + + + + + + +Simpson [Page 4] + RFC 1661 Point-to-Point Protocol July 1994 + + + Up-to-date values of the Protocol field are specified in the most + recent "Assigned Numbers" RFC [2]. This specification reserves + the following values: + + Value (in hex) Protocol Name + + 0001 Padding Protocol + 0003 to 001f reserved (transparency inefficient) + 007d reserved (Control Escape) + 00cf reserved (PPP NLPID) + 00ff reserved (compression inefficient) + + 8001 to 801f unused + 807d unused + 80cf unused + 80ff unused + + c021 Link Control Protocol + c023 Password Authentication Protocol + c025 Link Quality Report + c223 Challenge Handshake Authentication Protocol + + Developers of new protocols MUST obtain a number from the Internet + Assigned Numbers Authority (IANA), at IANA@isi.edu. + + + Information Field + + The Information field is zero or more octets. The Information + field contains the datagram for the protocol specified in the + Protocol field. + + The maximum length for the Information field, including Padding, + but not including the Protocol field, is termed the Maximum + Receive Unit (MRU), which defaults to 1500 octets. By + negotiation, consenting PPP implementations may use other values + for the MRU. + + + Padding + + On transmission, the Information field MAY be padded with an + arbitrary number of octets up to the MRU. It is the + responsibility of each protocol to distinguish padding octets from + real information. + + + + + + +Simpson [Page 5] + RFC 1661 Point-to-Point Protocol July 1994 + + +3. PPP Link Operation + +3.1. Overview + + In order to establish communications over a point-to-point link, each + end of the PPP link MUST first send LCP packets to configure and test + the data link. After the link has been established, the peer MAY be + authenticated. + + Then, PPP MUST send NCP packets to choose and configure one or more + network-layer protocols. Once each of the chosen network-layer + protocols has been configured, datagrams from each network-layer + protocol can be sent over the link. + + The link will remain configured for communications until explicit LCP + or NCP packets close the link down, or until some external event + occurs (an inactivity timer expires or network administrator + intervention). + + + +3.2. Phase Diagram + + In the process of configuring, maintaining and terminating the + point-to-point link, the PPP link goes through several distinct + phases which are specified in the following simplified state diagram: + + +------+ +-----------+ +--------------+ + | | UP | | OPENED | | SUCCESS/NONE + | Dead |------->| Establish |---------->| Authenticate |--+ + | | | | | | | + +------+ +-----------+ +--------------+ | + ^ | | | + | FAIL | FAIL | | + +<--------------+ +----------+ | + | | | + | +-----------+ | +---------+ | + | DOWN | | | CLOSING | | | + +------------| Terminate |<---+<----------| Network |<-+ + | | | | + +-----------+ +---------+ + + Not all transitions are specified in this diagram. The following + semantics MUST be followed. + + + + + + + +Simpson [Page 6] + RFC 1661 Point-to-Point Protocol July 1994 + + +3.3. Link Dead (physical-layer not ready) + + The link necessarily begins and ends with this phase. When an + external event (such as carrier detection or network administrator + configuration) indicates that the physical-layer is ready to be used, + PPP will proceed to the Link Establishment phase. + + During this phase, the LCP automaton (described later) will be in the + Initial or Starting states. The transition to the Link Establishment + phase will signal an Up event to the LCP automaton. + + Implementation Note: + + Typically, a link will return to this phase automatically after + the disconnection of a modem. In the case of a hard-wired link, + this phase may be extremely short -- merely long enough to detect + the presence of the device. + + + +3.4. Link Establishment Phase + + The Link Control Protocol (LCP) is used to establish the connection + through an exchange of Configure packets. This exchange is complete, + and the LCP Opened state entered, once a Configure-Ack packet + (described later) has been both sent and received. + + All Configuration Options are assumed to be at default values unless + altered by the configuration exchange. See the chapter on LCP + Configuration Options for further discussion. + + It is important to note that only Configuration Options which are + independent of particular network-layer protocols are configured by + LCP. Configuration of individual network-layer protocols is handled + by separate Network Control Protocols (NCPs) during the Network-Layer + Protocol phase. + + Any non-LCP packets received during this phase MUST be silently + discarded. + + The receipt of the LCP Configure-Request causes a return to the Link + Establishment phase from the Network-Layer Protocol phase or + Authentication phase. + + + + + + + + +Simpson [Page 7] + RFC 1661 Point-to-Point Protocol July 1994 + + +3.5. Authentication Phase + + On some links it may be desirable to require a peer to authenticate + itself before allowing network-layer protocol packets to be + exchanged. + + By default, authentication is not mandatory. If an implementation + desires that the peer authenticate with some specific authentication + protocol, then it MUST request the use of that authentication + protocol during Link Establishment phase. + + Authentication SHOULD take place as soon as possible after link + establishment. However, link quality determination MAY occur + concurrently. An implementation MUST NOT allow the exchange of link + quality determination packets to delay authentication indefinitely. + + Advancement from the Authentication phase to the Network-Layer + Protocol phase MUST NOT occur until authentication has completed. If + authentication fails, the authenticator SHOULD proceed instead to the + Link Termination phase. + + Only Link Control Protocol, authentication protocol, and link quality + monitoring packets are allowed during this phase. All other packets + received during this phase MUST be silently discarded. + + Implementation Notes: + + An implementation SHOULD NOT fail authentication simply due to + timeout or lack of response. The authentication SHOULD allow some + method of retransmission, and proceed to the Link Termination + phase only after a number of authentication attempts has been + exceeded. + + The implementation responsible for commencing Link Termination + phase is the implementation which has refused authentication to + its peer. + + + +3.6. Network-Layer Protocol Phase + + Once PPP has finished the previous phases, each network-layer + protocol (such as IP, IPX, or AppleTalk) MUST be separately + configured by the appropriate Network Control Protocol (NCP). + + Each NCP MAY be Opened and Closed at any time. + + + + + +Simpson [Page 8] + RFC 1661 Point-to-Point Protocol July 1994 + + + Implementation Note: + + Because an implementation may initially use a significant amount + of time for link quality determination, implementations SHOULD + avoid fixed timeouts when waiting for their peers to configure a + NCP. + + After a NCP has reached the Opened state, PPP will carry the + corresponding network-layer protocol packets. Any supported + network-layer protocol packets received when the corresponding NCP is + not in the Opened state MUST be silently discarded. + + Implementation Note: + + While LCP is in the Opened state, any protocol packet which is + unsupported by the implementation MUST be returned in a Protocol- + Reject (described later). Only protocols which are supported are + silently discarded. + + During this phase, link traffic consists of any possible combination + of LCP, NCP, and network-layer protocol packets. + + + +3.7. Link Termination Phase + + PPP can terminate the link at any time. This might happen because of + the loss of carrier, authentication failure, link quality failure, + the expiration of an idle-period timer, or the administrative closing + of the link. + + LCP is used to close the link through an exchange of Terminate + packets. When the link is closing, PPP informs the network-layer + protocols so that they may take appropriate action. + + After the exchange of Terminate packets, the implementation SHOULD + signal the physical-layer to disconnect in order to enforce the + termination of the link, particularly in the case of an + authentication failure. The sender of the Terminate-Request SHOULD + disconnect after receiving a Terminate-Ack, or after the Restart + counter expires. The receiver of a Terminate-Request SHOULD wait for + the peer to disconnect, and MUST NOT disconnect until at least one + Restart time has passed after sending a Terminate-Ack. PPP SHOULD + proceed to the Link Dead phase. + + Any non-LCP packets received during this phase MUST be silently + discarded. + + + + +Simpson [Page 9] + RFC 1661 Point-to-Point Protocol July 1994 + + + Implementation Note: + + The closing of the link by LCP is sufficient. There is no need + for each NCP to send a flurry of Terminate packets. Conversely, + the fact that one NCP has Closed is not sufficient reason to cause + the termination of the PPP link, even if that NCP was the only NCP + currently in the Opened state. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 10] + RFC 1661 Point-to-Point Protocol July 1994 + + +4. The Option Negotiation Automaton + + The finite-state automaton is defined by events, actions and state + transitions. Events include reception of external commands such as + Open and Close, expiration of the Restart timer, and reception of + packets from a peer. Actions include the starting of the Restart + timer and transmission of packets to the peer. + + Some types of packets -- Configure-Naks and Configure-Rejects, or + Code-Rejects and Protocol-Rejects, or Echo-Requests, Echo-Replies and + Discard-Requests -- are not differentiated in the automaton + descriptions. As will be described later, these packets do indeed + serve different functions. However, they always cause the same + transitions. + + Events Actions + + Up = lower layer is Up tlu = This-Layer-Up + Down = lower layer is Down tld = This-Layer-Down + Open = administrative Open tls = This-Layer-Started + Close= administrative Close tlf = This-Layer-Finished + + TO+ = Timeout with counter > 0 irc = Initialize-Restart-Count + TO- = Timeout with counter expired zrc = Zero-Restart-Count + + RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-Request + RCR- = Receive-Configure-Request (Bad) + RCA = Receive-Configure-Ack sca = Send-Configure-Ack + RCN = Receive-Configure-Nak/Rej scn = Send-Configure-Nak/Rej + + RTR = Receive-Terminate-Request str = Send-Terminate-Request + RTA = Receive-Terminate-Ack sta = Send-Terminate-Ack + + RUC = Receive-Unknown-Code scj = Send-Code-Reject + RXJ+ = Receive-Code-Reject (permitted) + or Receive-Protocol-Reject + RXJ- = Receive-Code-Reject (catastrophic) + or Receive-Protocol-Reject + RXR = Receive-Echo-Request ser = Send-Echo-Reply + or Receive-Echo-Reply + or Receive-Discard-Request + + + + + + + + + + +Simpson [Page 11] + RFC 1661 Point-to-Point Protocol July 1994 + + +4.1. State Transition Table + + The complete state transition table follows. States are indicated + horizontally, and events are read vertically. State transitions and + actions are represented in the form action/new-state. Multiple + actions are separated by commas, and may continue on succeeding lines + as space requires; multiple actions may be implemented in any + convenient order. The state may be followed by a letter, which + indicates an explanatory footnote. The dash ('-') indicates an + illegal transition. + + | State + | 0 1 2 3 4 5 +Events| Initial Starting Closed Stopped Closing Stopping +------+----------------------------------------------------------- + Up | 2 irc,scr/6 - - - - + Down | - - 0 tls/1 0 1 + Open | tls/1 1 irc,scr/6 3r 5r 5r + Close| 0 tlf/0 2 2 4 4 + | + TO+ | - - - - str/4 str/5 + TO- | - - - - tlf/2 tlf/3 + | + RCR+ | - - sta/2 irc,scr,sca/8 4 5 + RCR- | - - sta/2 irc,scr,scn/6 4 5 + RCA | - - sta/2 sta/3 4 5 + RCN | - - sta/2 sta/3 4 5 + | + RTR | - - sta/2 sta/3 sta/4 sta/5 + RTA | - - 2 3 tlf/2 tlf/3 + | + RUC | - - scj/2 scj/3 scj/4 scj/5 + RXJ+ | - - 2 3 4 5 + RXJ- | - - tlf/2 tlf/3 tlf/2 tlf/3 + | + RXR | - - 2 3 4 5 + + + + + + + + + + + + + + + +Simpson [Page 12] + RFC 1661 Point-to-Point Protocol July 1994 + + + + | State + | 6 7 8 9 +Events| Req-Sent Ack-Rcvd Ack-Sent Opened +------+----------------------------------------- + Up | - - - - + Down | 1 1 1 tld/1 + Open | 6 7 8 9r + Close|irc,str/4 irc,str/4 irc,str/4 tld,irc,str/4 + | + TO+ | scr/6 scr/6 scr/8 - + TO- | tlf/3p tlf/3p tlf/3p - + | + RCR+ | sca/8 sca,tlu/9 sca/8 tld,scr,sca/8 + RCR- | scn/6 scn/7 scn/6 tld,scr,scn/6 + RCA | irc/7 scr/6x irc,tlu/9 tld,scr/6x + RCN |irc,scr/6 scr/6x irc,scr/8 tld,scr/6x + | + RTR | sta/6 sta/6 sta/6 tld,zrc,sta/5 + RTA | 6 6 8 tld,scr/6 + | + RUC | scj/6 scj/7 scj/8 scj/9 + RXJ+ | 6 6 8 9 + RXJ- | tlf/3 tlf/3 tlf/3 tld,irc,str/5 + | + RXR | 6 7 8 ser/9 + + + The states in which the Restart timer is running are identifiable by + the presence of TO events. Only the Send-Configure-Request, Send- + Terminate-Request and Zero-Restart-Count actions start or re-start + the Restart timer. The Restart timer is stopped when transitioning + from any state where the timer is running to a state where the timer + is not running. + + The events and actions are defined according to a message passing + architecture, rather than a signalling architecture. If an action is + desired to control specific signals (such as DTR), additional actions + are likely to be required. + + [p] Passive option; see Stopped state discussion. + + [r] Restart option; see Open event discussion. + + [x] Crossed connection; see RCA event discussion. + + + + + + +Simpson [Page 13] + RFC 1661 Point-to-Point Protocol July 1994 + + +4.2. States + + Following is a more detailed description of each automaton state. + + Initial + + In the Initial state, the lower layer is unavailable (Down), and + no Open has occurred. The Restart timer is not running in the + Initial state. + + Starting + + The Starting state is the Open counterpart to the Initial state. + An administrative Open has been initiated, but the lower layer is + still unavailable (Down). The Restart timer is not running in the + Starting state. + + When the lower layer becomes available (Up), a Configure-Request + is sent. + + Closed + + In the Closed state, the link is available (Up), but no Open has + occurred. The Restart timer is not running in the Closed state. + + Upon reception of Configure-Request packets, a Terminate-Ack is + sent. Terminate-Acks are silently discarded to avoid creating a + loop. + + Stopped + + The Stopped state is the Open counterpart to the Closed state. It + is entered when the automaton is waiting for a Down event after + the This-Layer-Finished action, or after sending a Terminate-Ack. + The Restart timer is not running in the Stopped state. + + Upon reception of Configure-Request packets, an appropriate + response is sent. Upon reception of other packets, a Terminate- + Ack is sent. Terminate-Acks are silently discarded to avoid + creating a loop. + + Rationale: + + The Stopped state is a junction state for link termination, + link configuration failure, and other automaton failure modes. + These potentially separate states have been combined. + + There is a race condition between the Down event response (from + + + +Simpson [Page 14] + RFC 1661 Point-to-Point Protocol July 1994 + + + the This-Layer-Finished action) and the Receive-Configure- + Request event. When a Configure-Request arrives before the + Down event, the Down event will supercede by returning the + automaton to the Starting state. This prevents attack by + repetition. + + Implementation Option: + + After the peer fails to respond to Configure-Requests, an + implementation MAY wait passively for the peer to send + Configure-Requests. In this case, the This-Layer-Finished + action is not used for the TO- event in states Req-Sent, Ack- + Rcvd and Ack-Sent. + + This option is useful for dedicated circuits, or circuits which + have no status signals available, but SHOULD NOT be used for + switched circuits. + + Closing + + In the Closing state, an attempt is made to terminate the + connection. A Terminate-Request has been sent and the Restart + timer is running, but a Terminate-Ack has not yet been received. + + Upon reception of a Terminate-Ack, the Closed state is entered. + Upon the expiration of the Restart timer, a new Terminate-Request + is transmitted, and the Restart timer is restarted. After the + Restart timer has expired Max-Terminate times, the Closed state is + entered. + + Stopping + + The Stopping state is the Open counterpart to the Closing state. + A Terminate-Request has been sent and the Restart timer is + running, but a Terminate-Ack has not yet been received. + + Rationale: + + The Stopping state provides a well defined opportunity to + terminate a link before allowing new traffic. After the link + has terminated, a new configuration may occur via the Stopped + or Starting states. + + Request-Sent + + In the Request-Sent state an attempt is made to configure the + connection. A Configure-Request has been sent and the Restart + timer is running, but a Configure-Ack has not yet been received + + + +Simpson [Page 15] + RFC 1661 Point-to-Point Protocol July 1994 + + + nor has one been sent. + + Ack-Received + + In the Ack-Received state, a Configure-Request has been sent and a + Configure-Ack has been received. The Restart timer is still + running, since a Configure-Ack has not yet been sent. + + Ack-Sent + + In the Ack-Sent state, a Configure-Request and a Configure-Ack + have both been sent, but a Configure-Ack has not yet been + received. The Restart timer is running, since a Configure-Ack has + not yet been received. + + Opened + + In the Opened state, a Configure-Ack has been both sent and + received. The Restart timer is not running. + + When entering the Opened state, the implementation SHOULD signal + the upper layers that it is now Up. Conversely, when leaving the + Opened state, the implementation SHOULD signal the upper layers + that it is now Down. + + + +4.3. Events + + Transitions and actions in the automaton are caused by events. + + Up + + This event occurs when a lower layer indicates that it is ready to + carry packets. + + Typically, this event is used by a modem handling or calling + process, or by some other coupling of the PPP link to the physical + media, to signal LCP that the link is entering Link Establishment + phase. + + It also can be used by LCP to signal each NCP that the link is + entering Network-Layer Protocol phase. That is, the This-Layer-Up + action from LCP triggers the Up event in the NCP. + + Down + + This event occurs when a lower layer indicates that it is no + + + +Simpson [Page 16] + RFC 1661 Point-to-Point Protocol July 1994 + + + longer ready to carry packets. + + Typically, this event is used by a modem handling or calling + process, or by some other coupling of the PPP link to the physical + media, to signal LCP that the link is entering Link Dead phase. + + It also can be used by LCP to signal each NCP that the link is + leaving Network-Layer Protocol phase. That is, the This-Layer- + Down action from LCP triggers the Down event in the NCP. + + Open + + This event indicates that the link is administratively available + for traffic; that is, the network administrator (human or program) + has indicated that the link is allowed to be Opened. When this + event occurs, and the link is not in the Opened state, the + automaton attempts to send configuration packets to the peer. + + If the automaton is not able to begin configuration (the lower + layer is Down, or a previous Close event has not completed), the + establishment of the link is automatically delayed. + + When a Terminate-Request is received, or other events occur which + cause the link to become unavailable, the automaton will progress + to a state where the link is ready to re-open. No additional + administrative intervention is necessary. + + Implementation Option: + + Experience has shown that users will execute an additional Open + command when they want to renegotiate the link. This might + indicate that new values are to be negotiated. + + Since this is not the meaning of the Open event, it is + suggested that when an Open user command is executed in the + Opened, Closing, Stopping, or Stopped states, the + implementation issue a Down event, immediately followed by an + Up event. Care must be taken that an intervening Down event + cannot occur from another source. + + The Down followed by an Up will cause an orderly renegotiation + of the link, by progressing through the Starting to the + Request-Sent state. This will cause the renegotiation of the + link, without any harmful side effects. + + Close + + This event indicates that the link is not available for traffic; + + + +Simpson [Page 17] + RFC 1661 Point-to-Point Protocol July 1994 + + + that is, the network administrator (human or program) has + indicated that the link is not allowed to be Opened. When this + event occurs, and the link is not in the Closed state, the + automaton attempts to terminate the connection. Futher attempts + to re-configure the link are denied until a new Open event occurs. + + Implementation Note: + + When authentication fails, the link SHOULD be terminated, to + prevent attack by repetition and denial of service to other + users. Since the link is administratively available (by + definition), this can be accomplished by simulating a Close + event to the LCP, immediately followed by an Open event. Care + must be taken that an intervening Close event cannot occur from + another source. + + The Close followed by an Open will cause an orderly termination + of the link, by progressing through the Closing to the Stopping + state, and the This-Layer-Finished action can disconnect the + link. The automaton waits in the Stopped or Starting states + for the next connection attempt. + + Timeout (TO+,TO-) + + This event indicates the expiration of the Restart timer. The + Restart timer is used to time responses to Configure-Request and + Terminate-Request packets. + + The TO+ event indicates that the Restart counter continues to be + greater than zero, which triggers the corresponding Configure- + Request or Terminate-Request packet to be retransmitted. + + The TO- event indicates that the Restart counter is not greater + than zero, and no more packets need to be retransmitted. + + Receive-Configure-Request (RCR+,RCR-) + + This event occurs when a Configure-Request packet is received from + the peer. The Configure-Request packet indicates the desire to + open a connection and may specify Configuration Options. The + Configure-Request packet is more fully described in a later + section. + + The RCR+ event indicates that the Configure-Request was + acceptable, and triggers the transmission of a corresponding + Configure-Ack. + + The RCR- event indicates that the Configure-Request was + + + +Simpson [Page 18] + RFC 1661 Point-to-Point Protocol July 1994 + + + unacceptable, and triggers the transmission of a corresponding + Configure-Nak or Configure-Reject. + + Implementation Note: + + These events may occur on a connection which is already in the + Opened state. The implementation MUST be prepared to + immediately renegotiate the Configuration Options. + + Receive-Configure-Ack (RCA) + + This event occurs when a valid Configure-Ack packet is received + from the peer. The Configure-Ack packet is a positive response to + a Configure-Request packet. An out of sequence or otherwise + invalid packet is silently discarded. + + Implementation Note: + + Since the correct packet has already been received before + reaching the Ack-Rcvd or Opened states, it is extremely + unlikely that another such packet will arrive. As specified, + all invalid Ack/Nak/Rej packets are silently discarded, and do + not affect the transitions of the automaton. + + However, it is not impossible that a correctly formed packet + will arrive through a coincidentally-timed cross-connection. + It is more likely to be the result of an implementation error. + At the very least, this occurance SHOULD be logged. + + Receive-Configure-Nak/Rej (RCN) + + This event occurs when a valid Configure-Nak or Configure-Reject + packet is received from the peer. The Configure-Nak and + Configure-Reject packets are negative responses to a Configure- + Request packet. An out of sequence or otherwise invalid packet is + silently discarded. + + Implementation Note: + + Although the Configure-Nak and Configure-Reject cause the same + state transition in the automaton, these packets have + significantly different effects on the Configuration Options + sent in the resulting Configure-Request packet. + + Receive-Terminate-Request (RTR) + + This event occurs when a Terminate-Request packet is received. + The Terminate-Request packet indicates the desire of the peer to + + + +Simpson [Page 19] + RFC 1661 Point-to-Point Protocol July 1994 + + + close the connection. + + Implementation Note: + + This event is not identical to the Close event (see above), and + does not override the Open commands of the local network + administrator. The implementation MUST be prepared to receive + a new Configure-Request without network administrator + intervention. + + Receive-Terminate-Ack (RTA) + + This event occurs when a Terminate-Ack packet is received from the + peer. The Terminate-Ack packet is usually a response to a + Terminate-Request packet. The Terminate-Ack packet may also + indicate that the peer is in Closed or Stopped states, and serves + to re-synchronize the link configuration. + + Receive-Unknown-Code (RUC) + + This event occurs when an un-interpretable packet is received from + the peer. A Code-Reject packet is sent in response. + + Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-) + + This event occurs when a Code-Reject or a Protocol-Reject packet + is received from the peer. + + The RXJ+ event arises when the rejected value is acceptable, such + as a Code-Reject of an extended code, or a Protocol-Reject of a + NCP. These are within the scope of normal operation. The + implementation MUST stop sending the offending packet type. + + The RXJ- event arises when the rejected value is catastrophic, + such as a Code-Reject of Configure-Request, or a Protocol-Reject + of LCP! This event communicates an unrecoverable error that + terminates the connection. + + Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request + (RXR) + + This event occurs when an Echo-Request, Echo-Reply or Discard- + Request packet is received from the peer. The Echo-Reply packet + is a response to an Echo-Request packet. There is no reply to an + Echo-Reply or Discard-Request packet. + + + + + + +Simpson [Page 20] + RFC 1661 Point-to-Point Protocol July 1994 + + +4.4. Actions + + Actions in the automaton are caused by events and typically indicate + the transmission of packets and/or the starting or stopping of the + Restart timer. + + Illegal-Event (-) + + This indicates an event that cannot occur in a properly + implemented automaton. The implementation has an internal error, + which should be reported and logged. No transition is taken, and + the implementation SHOULD NOT reset or freeze. + + This-Layer-Up (tlu) + + This action indicates to the upper layers that the automaton is + entering the Opened state. + + Typically, this action is used by the LCP to signal the Up event + to a NCP, Authentication Protocol, or Link Quality Protocol, or + MAY be used by a NCP to indicate that the link is available for + its network layer traffic. + + This-Layer-Down (tld) + + This action indicates to the upper layers that the automaton is + leaving the Opened state. + + Typically, this action is used by the LCP to signal the Down event + to a NCP, Authentication Protocol, or Link Quality Protocol, or + MAY be used by a NCP to indicate that the link is no longer + available for its network layer traffic. + + This-Layer-Started (tls) + + This action indicates to the lower layers that the automaton is + entering the Starting state, and the lower layer is needed for the + link. The lower layer SHOULD respond with an Up event when the + lower layer is available. + + This results of this action are highly implementation dependent. + + This-Layer-Finished (tlf) + + This action indicates to the lower layers that the automaton is + entering the Initial, Closed or Stopped states, and the lower + layer is no longer needed for the link. The lower layer SHOULD + respond with a Down event when the lower layer has terminated. + + + +Simpson [Page 21] + RFC 1661 Point-to-Point Protocol July 1994 + + + Typically, this action MAY be used by the LCP to advance to the + Link Dead phase, or MAY be used by a NCP to indicate to the LCP + that the link may terminate when there are no other NCPs open. + + This results of this action are highly implementation dependent. + + Initialize-Restart-Count (irc) + + This action sets the Restart counter to the appropriate value + (Max-Terminate or Max-Configure). The counter is decremented for + each transmission, including the first. + + Implementation Note: + + In addition to setting the Restart counter, the implementation + MUST set the timeout period to the initial value when Restart + timer backoff is used. + + Zero-Restart-Count (zrc) + + This action sets the Restart counter to zero. + + Implementation Note: + + This action enables the FSA to pause before proceeding to the + desired final state, allowing traffic to be processed by the + peer. In addition to zeroing the Restart counter, the + implementation MUST set the timeout period to an appropriate + value. + + Send-Configure-Request (scr) + + A Configure-Request packet is transmitted. This indicates the + desire to open a connection with a specified set of Configuration + Options. The Restart timer is started when the Configure-Request + packet is transmitted, to guard against packet loss. The Restart + counter is decremented each time a Configure-Request is sent. + + Send-Configure-Ack (sca) + + A Configure-Ack packet is transmitted. This acknowledges the + reception of a Configure-Request packet with an acceptable set of + Configuration Options. + + Send-Configure-Nak (scn) + + A Configure-Nak or Configure-Reject packet is transmitted, as + appropriate. This negative response reports the reception of a + + + +Simpson [Page 22] + RFC 1661 Point-to-Point Protocol July 1994 + + + Configure-Request packet with an unacceptable set of Configuration + Options. + + Configure-Nak packets are used to refuse a Configuration Option + value, and to suggest a new, acceptable value. Configure-Reject + packets are used to refuse all negotiation about a Configuration + Option, typically because it is not recognized or implemented. + The use of Configure-Nak versus Configure-Reject is more fully + described in the chapter on LCP Packet Formats. + + Send-Terminate-Request (str) + + A Terminate-Request packet is transmitted. This indicates the + desire to close a connection. The Restart timer is started when + the Terminate-Request packet is transmitted, to guard against + packet loss. The Restart counter is decremented each time a + Terminate-Request is sent. + + Send-Terminate-Ack (sta) + + A Terminate-Ack packet is transmitted. This acknowledges the + reception of a Terminate-Request packet or otherwise serves to + synchronize the automatons. + + Send-Code-Reject (scj) + + A Code-Reject packet is transmitted. This indicates the reception + of an unknown type of packet. + + Send-Echo-Reply (ser) + + An Echo-Reply packet is transmitted. This acknowledges the + reception of an Echo-Request packet. + + + +4.5. Loop Avoidance + + The protocol makes a reasonable attempt at avoiding Configuration + Option negotiation loops. However, the protocol does NOT guarantee + that loops will not happen. As with any negotiation, it is possible + to configure two PPP implementations with conflicting policies that + will never converge. It is also possible to configure policies which + do converge, but which take significant time to do so. Implementors + should keep this in mind and SHOULD implement loop detection + mechanisms or higher level timeouts. + + + + + +Simpson [Page 23] + RFC 1661 Point-to-Point Protocol July 1994 + + +4.6. Counters and Timers + + Restart Timer + + There is one special timer used by the automaton. The Restart + timer is used to time transmissions of Configure-Request and + Terminate-Request packets. Expiration of the Restart timer causes + a Timeout event, and retransmission of the corresponding + Configure-Request or Terminate-Request packet. The Restart timer + MUST be configurable, but SHOULD default to three (3) seconds. + + Implementation Note: + + The Restart timer SHOULD be based on the speed of the link. + The default value is designed for low speed (2,400 to 9,600 + bps), high switching latency links (typical telephone lines). + Higher speed links, or links with low switching latency, SHOULD + have correspondingly faster retransmission times. + + Instead of a constant value, the Restart timer MAY begin at an + initial small value and increase to the configured final value. + Each successive value less than the final value SHOULD be at + least twice the previous value. The initial value SHOULD be + large enough to account for the size of the packets, twice the + round trip time for transmission at the link speed, and at + least an additional 100 milliseconds to allow the peer to + process the packets before responding. Some circuits add + another 200 milliseconds of satellite delay. Round trip times + for modems operating at 14,400 bps have been measured in the + range of 160 to more than 600 milliseconds. + + Max-Terminate + + There is one required restart counter for Terminate-Requests. + Max-Terminate indicates the number of Terminate-Request packets + sent without receiving a Terminate-Ack before assuming that the + peer is unable to respond. Max-Terminate MUST be configurable, + but SHOULD default to two (2) transmissions. + + Max-Configure + + A similar counter is recommended for Configure-Requests. Max- + Configure indicates the number of Configure-Request packets sent + without receiving a valid Configure-Ack, Configure-Nak or + Configure-Reject before assuming that the peer is unable to + respond. Max-Configure MUST be configurable, but SHOULD default + to ten (10) transmissions. + + + + +Simpson [Page 24] + RFC 1661 Point-to-Point Protocol July 1994 + + + Max-Failure + + A related counter is recommended for Configure-Nak. Max-Failure + indicates the number of Configure-Nak packets sent without sending + a Configure-Ack before assuming that configuration is not + converging. Any further Configure-Nak packets for peer requested + options are converted to Configure-Reject packets, and locally + desired options are no longer appended. Max-Failure MUST be + configurable, but SHOULD default to five (5) transmissions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 25] + RFC 1661 Point-to-Point Protocol July 1994 + + +5. LCP Packet Formats + + There are three classes of LCP packets: + + 1. Link Configuration packets used to establish and configure a + link (Configure-Request, Configure-Ack, Configure-Nak and + Configure-Reject). + + 2. Link Termination packets used to terminate a link (Terminate- + Request and Terminate-Ack). + + 3. Link Maintenance packets used to manage and debug a link + (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, and + Discard-Request). + + In the interest of simplicity, there is no version field in the LCP + packet. A correctly functioning LCP implementation will always + respond to unknown Protocols and Codes with an easily recognizable + LCP packet, thus providing a deterministic fallback mechanism for + implementations of other versions. + + Regardless of which Configuration Options are enabled, all LCP Link + Configuration, Link Termination, and Code-Reject packets (codes 1 + through 7) are always sent as if no Configuration Options were + negotiated. In particular, each Configuration Option specifies a + default value. This ensures that such LCP packets are always + recognizable, even when one end of the link mistakenly believes the + link to be open. + + Exactly one LCP packet is encapsulated in the PPP Information field, + where the PPP Protocol field indicates type hex c021 (Link Control + Protocol). + + A summary of the Link Control Protocol packet format is shown below. + The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + Code + + The Code field is one octet, and identifies the kind of LCP + + + +Simpson [Page 26] + RFC 1661 Point-to-Point Protocol July 1994 + + + packet. When a packet is received with an unknown Code field, a + Code-Reject packet is transmitted. + + Up-to-date values of the LCP Code field are specified in the most + recent "Assigned Numbers" RFC [2]. This document concerns the + following values: + + 1 Configure-Request + 2 Configure-Ack + 3 Configure-Nak + 4 Configure-Reject + 5 Terminate-Request + 6 Terminate-Ack + 7 Code-Reject + 8 Protocol-Reject + 9 Echo-Request + 10 Echo-Reply + 11 Discard-Request + + + Identifier + + The Identifier field is one octet, and aids in matching requests + and replies. When a packet is received with an invalid Identifier + field, the packet is silently discarded without affecting the + automaton. + + Length + + The Length field is two octets, and indicates the length of the + LCP packet, including the Code, Identifier, Length and Data + fields. The Length MUST NOT exceed the MRU of the link. + + Octets outside the range of the Length field are treated as + padding and are ignored on reception. When a packet is received + with an invalid Length field, the packet is silently discarded + without affecting the automaton. + + Data + + The Data field is zero or more octets, as indicated by the Length + field. The format of the Data field is determined by the Code + field. + + + + + + + + +Simpson [Page 27] + RFC 1661 Point-to-Point Protocol July 1994 + + +5.1. Configure-Request + + Description + + An implementation wishing to open a connection MUST transmit a + Configure-Request. The Options field is filled with any desired + changes to the link defaults. Configuration Options SHOULD NOT be + included with default values. + + Upon reception of a Configure-Request, an appropriate reply MUST + be transmitted. + + A summary of the Configure-Request packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+ + + + Code + + 1 for Configure-Request. + + Identifier + + The Identifier field MUST be changed whenever the contents of the + Options field changes, and whenever a valid reply has been + received for a previous request. For retransmissions, the + Identifier MAY remain unchanged. + + Options + + The options field is variable in length, and contains the list of + zero or more Configuration Options that the sender desires to + negotiate. All Configuration Options are always negotiated + simultaneously. The format of Configuration Options is further + described in a later chapter. + + + + + + + + + +Simpson [Page 28] + RFC 1661 Point-to-Point Protocol July 1994 + + +5.2. Configure-Ack + + Description + + If every Configuration Option received in a Configure-Request is + recognizable and all values are acceptable, then the + implementation MUST transmit a Configure-Ack. The acknowledged + Configuration Options MUST NOT be reordered or modified in any + way. + + On reception of a Configure-Ack, the Identifier field MUST match + that of the last transmitted Configure-Request. Additionally, the + Configuration Options in a Configure-Ack MUST exactly match those + of the last transmitted Configure-Request. Invalid packets are + silently discarded. + + A summary of the Configure-Ack packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+ + + + Code + + 2 for Configure-Ack. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Configure-Request which caused this Configure-Ack. + + Options + + The Options field is variable in length, and contains the list of + zero or more Configuration Options that the sender is + acknowledging. All Configuration Options are always acknowledged + simultaneously. + + + + + + + + +Simpson [Page 29] + RFC 1661 Point-to-Point Protocol July 1994 + + +5.3. Configure-Nak + + Description + + If every instance of the received Configuration Options is + recognizable, but some values are not acceptable, then the + implementation MUST transmit a Configure-Nak. The Options field + is filled with only the unacceptable Configuration Options from + the Configure-Request. All acceptable Configuration Options are + filtered out of the Configure-Nak, but otherwise the Configuration + Options from the Configure-Request MUST NOT be reordered. + + Options which have no value fields (boolean options) MUST use the + Configure-Reject reply instead. + + Each Configuration Option which is allowed only a single instance + MUST be modified to a value acceptable to the Configure-Nak + sender. The default value MAY be used, when this differs from the + requested value. + + When a particular type of Configuration Option can be listed more + than once with different values, the Configure-Nak MUST include a + list of all values for that option which are acceptable to the + Configure-Nak sender. This includes acceptable values that were + present in the Configure-Request. + + Finally, an implementation may be configured to request the + negotiation of a specific Configuration Option. If that option is + not listed, then that option MAY be appended to the list of Nak'd + Configuration Options, in order to prompt the peer to include that + option in its next Configure-Request packet. Any value fields for + the option MUST indicate values acceptable to the Configure-Nak + sender. + + On reception of a Configure-Nak, the Identifier field MUST match + that of the last transmitted Configure-Request. Invalid packets + are silently discarded. + + Reception of a valid Configure-Nak indicates that when a new + Configure-Request is sent, the Configuration Options MAY be + modified as specified in the Configure-Nak. When multiple + instances of a Configuration Option are present, the peer SHOULD + select a single value to include in its next Configure-Request + packet. + + Some Configuration Options have a variable length. Since the + Nak'd Option has been modified by the peer, the implementation + MUST be able to handle an Option length which is different from + + + +Simpson [Page 30] + RFC 1661 Point-to-Point Protocol July 1994 + + + the original Configure-Request. + + A summary of the Configure-Nak packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+ + + + Code + + 3 for Configure-Nak. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Configure-Request which caused this Configure-Nak. + + Options + + The Options field is variable in length, and contains the list of + zero or more Configuration Options that the sender is Nak'ing. + All Configuration Options are always Nak'd simultaneously. + + + +5.4. Configure-Reject + + Description + + If some Configuration Options received in a Configure-Request are + not recognizable or are not acceptable for negotiation (as + configured by a network administrator), then the implementation + MUST transmit a Configure-Reject. The Options field is filled + with only the unacceptable Configuration Options from the + Configure-Request. All recognizable and negotiable Configuration + Options are filtered out of the Configure-Reject, but otherwise + the Configuration Options MUST NOT be reordered or modified in any + way. + + On reception of a Configure-Reject, the Identifier field MUST + match that of the last transmitted Configure-Request. + Additionally, the Configuration Options in a Configure-Reject MUST + + + +Simpson [Page 31] + RFC 1661 Point-to-Point Protocol July 1994 + + + be a proper subset of those in the last transmitted Configure- + Request. Invalid packets are silently discarded. + + Reception of a valid Configure-Reject indicates that when a new + Configure-Request is sent, it MUST NOT include any of the + Configuration Options listed in the Configure-Reject. + + A summary of the Configure-Reject packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+ + + + Code + + 4 for Configure-Reject. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Configure-Request which caused this Configure-Reject. + + Options + + The Options field is variable in length, and contains the list of + zero or more Configuration Options that the sender is rejecting. + All Configuration Options are always rejected simultaneously. + + + + + + + + + + + + + + + + + + +Simpson [Page 32] + RFC 1661 Point-to-Point Protocol July 1994 + + +5.5. Terminate-Request and Terminate-Ack + + Description + + LCP includes Terminate-Request and Terminate-Ack Codes in order to + provide a mechanism for closing a connection. + + An implementation wishing to close a connection SHOULD transmit a + Terminate-Request. Terminate-Request packets SHOULD continue to + be sent until Terminate-Ack is received, the lower layer indicates + that it has gone down, or a sufficiently large number have been + transmitted such that the peer is down with reasonable certainty. + + Upon reception of a Terminate-Request, a Terminate-Ack MUST be + transmitted. + + Reception of an unelicited Terminate-Ack indicates that the peer + is in the Closed or Stopped states, or is otherwise in need of + re-negotiation. + + A summary of the Terminate-Request and Terminate-Ack packet formats + is shown below. The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + Code + + 5 for Terminate-Request; + + 6 for Terminate-Ack. + + Identifier + + On transmission, the Identifier field MUST be changed whenever the + content of the Data field changes, and whenever a valid reply has + been received for a previous request. For retransmissions, the + Identifier MAY remain unchanged. + + On reception, the Identifier field of the Terminate-Request is + copied into the Identifier field of the Terminate-Ack packet. + + + + +Simpson [Page 33] + RFC 1661 Point-to-Point Protocol July 1994 + + + Data + + The Data field is zero or more octets, and contains uninterpreted + data for use by the sender. The data may consist of any binary + value. The end of the field is indicated by the Length. + + + +5.6. Code-Reject + + Description + + Reception of a LCP packet with an unknown Code indicates that the + peer is operating with a different version. This MUST be reported + back to the sender of the unknown Code by transmitting a Code- + Reject. + + Upon reception of the Code-Reject of a code which is fundamental + to this version of the protocol, the implementation SHOULD report + the problem and drop the connection, since it is unlikely that the + situation can be rectified automatically. + + A summary of the Code-Reject packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Rejected-Packet ... + +-+-+-+-+-+-+-+-+ + + + Code + + 7 for Code-Reject. + + Identifier + + The Identifier field MUST be changed for each Code-Reject sent. + + Rejected-Packet + + The Rejected-Packet field contains a copy of the LCP packet which + is being rejected. It begins with the Information field, and does + not include any Data Link Layer headers nor an FCS. The + Rejected-Packet MUST be truncated to comply with the peer's + + + +Simpson [Page 34] + RFC 1661 Point-to-Point Protocol July 1994 + + + established MRU. + + + +5.7. Protocol-Reject + + Description + + Reception of a PPP packet with an unknown Protocol field indicates + that the peer is attempting to use a protocol which is + unsupported. This usually occurs when the peer attempts to + configure a new protocol. If the LCP automaton is in the Opened + state, then this MUST be reported back to the peer by transmitting + a Protocol-Reject. + + Upon reception of a Protocol-Reject, the implementation MUST stop + sending packets of the indicated protocol at the earliest + opportunity. + + Protocol-Reject packets can only be sent in the LCP Opened state. + Protocol-Reject packets received in any state other than the LCP + Opened state SHOULD be silently discarded. + + A summary of the Protocol-Reject packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Rejected-Protocol | Rejected-Information ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Code + + 8 for Protocol-Reject. + + Identifier + + The Identifier field MUST be changed for each Protocol-Reject + sent. + + Rejected-Protocol + + The Rejected-Protocol field is two octets, and contains the PPP + Protocol field of the packet which is being rejected. + + + +Simpson [Page 35] + RFC 1661 Point-to-Point Protocol July 1994 + + + Rejected-Information + + The Rejected-Information field contains a copy of the packet which + is being rejected. It begins with the Information field, and does + not include any Data Link Layer headers nor an FCS. The + Rejected-Information MUST be truncated to comply with the peer's + established MRU. + + + +5.8. Echo-Request and Echo-Reply + + Description + + LCP includes Echo-Request and Echo-Reply Codes in order to provide + a Data Link Layer loopback mechanism for use in exercising both + directions of the link. This is useful as an aid in debugging, + link quality determination, performance testing, and for numerous + other functions. + + Upon reception of an Echo-Request in the LCP Opened state, an + Echo-Reply MUST be transmitted. + + Echo-Request and Echo-Reply packets MUST only be sent in the LCP + Opened state. Echo-Request and Echo-Reply packets received in any + state other than the LCP Opened state SHOULD be silently + discarded. + + + A summary of the Echo-Request and Echo-Reply packet formats is shown + below. The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic-Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + Code + + 9 for Echo-Request; + + 10 for Echo-Reply. + + + +Simpson [Page 36] + RFC 1661 Point-to-Point Protocol July 1994 + + + Identifier + + On transmission, the Identifier field MUST be changed whenever the + content of the Data field changes, and whenever a valid reply has + been received for a previous request. For retransmissions, the + Identifier MAY remain unchanged. + + On reception, the Identifier field of the Echo-Request is copied + into the Identifier field of the Echo-Reply packet. + + Magic-Number + + The Magic-Number field is four octets, and aids in detecting links + which are in the looped-back condition. Until the Magic-Number + Configuration Option has been successfully negotiated, the Magic- + Number MUST be transmitted as zero. See the Magic-Number + Configuration Option for further explanation. + + Data + + The Data field is zero or more octets, and contains uninterpreted + data for use by the sender. The data may consist of any binary + value. The end of the field is indicated by the Length. + + + +5.9. Discard-Request + + Description + + LCP includes a Discard-Request Code in order to provide a Data + Link Layer sink mechanism for use in exercising the local to + remote direction of the link. This is useful as an aid in + debugging, performance testing, and for numerous other functions. + + Discard-Request packets MUST only be sent in the LCP Opened state. + On reception, the receiver MUST silently discard any Discard- + Request that it receives. + + + + + + + + + + + + + +Simpson [Page 37] + RFC 1661 Point-to-Point Protocol July 1994 + + + A summary of the Discard-Request packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic-Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Code + + 11 for Discard-Request. + + Identifier + + The Identifier field MUST be changed for each Discard-Request + sent. + + Magic-Number + + The Magic-Number field is four octets, and aids in detecting links + which are in the looped-back condition. Until the Magic-Number + Configuration Option has been successfully negotiated, the Magic- + Number MUST be transmitted as zero. See the Magic-Number + Configuration Option for further explanation. + + Data + + The Data field is zero or more octets, and contains uninterpreted + data for use by the sender. The data may consist of any binary + value. The end of the field is indicated by the Length. + + + + + + + + + + + + + + + + +Simpson [Page 38] + RFC 1661 Point-to-Point Protocol July 1994 + + +6. LCP Configuration Options + + LCP Configuration Options allow negotiation of modifications to the + default characteristics of a point-to-point link. If a Configuration + Option is not included in a Configure-Request packet, the default + value for that Configuration Option is assumed. + + Some Configuration Options MAY be listed more than once. The effect + of this is Configuration Option specific, and is specified by each + such Configuration Option description. (None of the Configuration + Options in this specification can be listed more than once.) + + The end of the list of Configuration Options is indicated by the + Length field of the LCP packet. + + Unless otherwise specified, all Configuration Options apply in a + half-duplex fashion; typically, in the receive direction of the link + from the point of view of the Configure-Request sender. + + Design Philosophy + + The options indicate additional capabilities or requirements of + the implementation that is requesting the option. An + implementation which does not understand any option SHOULD + interoperate with one which implements every option. + + A default is specified for each option which allows the link to + correctly function without negotiation of the option, although + perhaps with less than optimal performance. + + Except where explicitly specified, acknowledgement of an option + does not require the peer to take any additional action other than + the default. + + It is not necessary to send the default values for the options in + a Configure-Request. + + + A summary of the Configuration Option format is shown below. The + fields are transmitted from left to right. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Data ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + +Simpson [Page 39] + RFC 1661 Point-to-Point Protocol July 1994 + + + Type + + The Type field is one octet, and indicates the type of + Configuration Option. Up-to-date values of the LCP Option Type + field are specified in the most recent "Assigned Numbers" RFC [2]. + This document concerns the following values: + + 0 RESERVED + 1 Maximum-Receive-Unit + 3 Authentication-Protocol + 4 Quality-Protocol + 5 Magic-Number + 7 Protocol-Field-Compression + 8 Address-and-Control-Field-Compression + + + Length + + The Length field is one octet, and indicates the length of this + Configuration Option including the Type, Length and Data fields. + + If a negotiable Configuration Option is received in a Configure- + Request, but with an invalid or unrecognized Length, a Configure- + Nak SHOULD be transmitted which includes the desired Configuration + Option with an appropriate Length and Data. + + Data + + The Data field is zero or more octets, and contains information + specific to the Configuration Option. The format and length of + the Data field is determined by the Type and Length fields. + + When the Data field is indicated by the Length to extend beyond + the end of the Information field, the entire packet is silently + discarded without affecting the automaton. + + + + + + + + + + + + + + + + +Simpson [Page 40] + RFC 1661 Point-to-Point Protocol July 1994 + + +6.1. Maximum-Receive-Unit (MRU) + + Description + + This Configuration Option may be sent to inform the peer that the + implementation can receive larger packets, or to request that the + peer send smaller packets. + + The default value is 1500 octets. If smaller packets are + requested, an implementation MUST still be able to receive the + full 1500 octet information field in case link synchronization is + lost. + + Implementation Note: + + This option is used to indicate an implementation capability. + The peer is not required to maximize the use of the capacity. + For example, when a MRU is indicated which is 2048 octets, the + peer is not required to send any packet with 2048 octets. The + peer need not Configure-Nak to indicate that it will only send + smaller packets, since the implementation will always require + support for at least 1500 octets. + + A summary of the Maximum-Receive-Unit Configuration Option format is + shown below. The fields are transmitted from 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 | Maximum-Receive-Unit | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 1 + + Length + + 4 + + Maximum-Receive-Unit + + The Maximum-Receive-Unit field is two octets, and specifies the + maximum number of octets in the Information and Padding fields. + It does not include the framing, Protocol field, FCS, nor any + transparency bits or bytes. + + + + +Simpson [Page 41] + RFC 1661 Point-to-Point Protocol July 1994 + + +6.2. Authentication-Protocol + + Description + + On some links it may be desirable to require a peer to + authenticate itself before allowing network-layer protocol packets + to be exchanged. + + This Configuration Option provides a method to negotiate the use + of a specific protocol for authentication. By default, + authentication is not required. + + An implementation MUST NOT include multiple Authentication- + Protocol Configuration Options in its Configure-Request packets. + Instead, it SHOULD attempt to configure the most desirable + protocol first. If that protocol is Configure-Nak'd, then the + implementation SHOULD attempt the next most desirable protocol in + the next Configure-Request. + + The implementation sending the Configure-Request is indicating + that it expects authentication from its peer. If an + implementation sends a Configure-Ack, then it is agreeing to + authenticate with the specified protocol. An implementation + receiving a Configure-Ack SHOULD expect the peer to authenticate + with the acknowledged protocol. + + There is no requirement that authentication be full-duplex or that + the same protocol be used in both directions. It is perfectly + acceptable for different protocols to be used in each direction. + This will, of course, depend on the specific protocols negotiated. + + A summary of the Authentication-Protocol Configuration Option format + is shown below. The fields are transmitted from 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 | Authentication-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + Type + + 3 + + + + + +Simpson [Page 42] + RFC 1661 Point-to-Point Protocol July 1994 + + + Length + + >= 4 + + Authentication-Protocol + + The Authentication-Protocol field is two octets, and indicates the + authentication protocol desired. Values for this field are always + the same as the PPP Protocol field values for that same + authentication protocol. + + Up-to-date values of the Authentication-Protocol field are + specified in the most recent "Assigned Numbers" RFC [2]. Current + values are assigned as follows: + + Value (in hex) Protocol + + c023 Password Authentication Protocol + c223 Challenge Handshake Authentication Protocol + + + Data + + The Data field is zero or more octets, and contains additional + data as determined by the particular protocol. + + + +6.3. Quality-Protocol + + Description + + On some links it may be desirable to determine when, and how + often, the link is dropping data. This process is called link + quality monitoring. + + This Configuration Option provides a method to negotiate the use + of a specific protocol for link quality monitoring. By default, + link quality monitoring is disabled. + + The implementation sending the Configure-Request is indicating + that it expects to receive monitoring information from its peer. + If an implementation sends a Configure-Ack, then it is agreeing to + send the specified protocol. An implementation receiving a + Configure-Ack SHOULD expect the peer to send the acknowledged + protocol. + + There is no requirement that quality monitoring be full-duplex or + + + +Simpson [Page 43] + RFC 1661 Point-to-Point Protocol July 1994 + + + that the same protocol be used in both directions. It is + perfectly acceptable for different protocols to be used in each + direction. This will, of course, depend on the specific protocols + negotiated. + + A summary of the Quality-Protocol Configuration Option format is + shown below. The fields are transmitted from 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 | Quality-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + Type + + 4 + + Length + + >= 4 + + Quality-Protocol + + The Quality-Protocol field is two octets, and indicates the link + quality monitoring protocol desired. Values for this field are + always the same as the PPP Protocol field values for that same + monitoring protocol. + + Up-to-date values of the Quality-Protocol field are specified in + the most recent "Assigned Numbers" RFC [2]. Current values are + assigned as follows: + + Value (in hex) Protocol + + c025 Link Quality Report + + + Data + + The Data field is zero or more octets, and contains additional + data as determined by the particular protocol. + + + + + + +Simpson [Page 44] + RFC 1661 Point-to-Point Protocol July 1994 + + +6.4. Magic-Number + + Description + + This Configuration Option provides a method to detect looped-back + links and other Data Link Layer anomalies. This Configuration + Option MAY be required by some other Configuration Options such as + the Quality-Protocol Configuration Option. By default, the + Magic-Number is not negotiated, and zero is inserted where a + Magic-Number might otherwise be used. + + Before this Configuration Option is requested, an implementation + MUST choose its Magic-Number. It is recommended that the Magic- + Number be chosen in the most random manner possible in order to + guarantee with very high probability that an implementation will + arrive at a unique number. A good way to choose a unique random + number is to start with a unique seed. Suggested sources of + uniqueness include machine serial numbers, other network hardware + addresses, time-of-day clocks, etc. Particularly good random + number seeds are precise measurements of the inter-arrival time of + physical events such as packet reception on other connected + networks, server response time, or the typing rate of a human + user. It is also suggested that as many sources as possible be + used simultaneously. + + When a Configure-Request is received with a Magic-Number + Configuration Option, the received Magic-Number is compared with + the Magic-Number of the last Configure-Request sent to the peer. + If the two Magic-Numbers are different, then the link is not + looped-back, and the Magic-Number SHOULD be acknowledged. If the + two Magic-Numbers are equal, then it is possible, but not certain, + that the link is looped-back and that this Configure-Request is + actually the one last sent. To determine this, a Configure-Nak + MUST be sent specifying a different Magic-Number value. A new + Configure-Request SHOULD NOT be sent to the peer until normal + processing would cause it to be sent (that is, until a Configure- + Nak is received or the Restart timer runs out). + + Reception of a Configure-Nak with a Magic-Number different from + that of the last Configure-Nak sent to the peer proves that a link + is not looped-back, and indicates a unique Magic-Number. If the + Magic-Number is equal to the one sent in the last Configure-Nak, + the possibility of a looped-back link is increased, and a new + Magic-Number MUST be chosen. In either case, a new Configure- + Request SHOULD be sent with the new Magic-Number. + + If the link is indeed looped-back, this sequence (transmit + Configure-Request, receive Configure-Request, transmit Configure- + + + +Simpson [Page 45] + RFC 1661 Point-to-Point Protocol July 1994 + + + Nak, receive Configure-Nak) will repeat over and over again. If + the link is not looped-back, this sequence might occur a few + times, but it is extremely unlikely to occur repeatedly. More + likely, the Magic-Numbers chosen at either end will quickly + diverge, terminating the sequence. The following table shows the + probability of collisions assuming that both ends of the link + select Magic-Numbers with a perfectly uniform distribution: + + Number of Collisions Probability + -------------------- --------------------- + 1 1/2**32 = 2.3 E-10 + 2 1/2**32**2 = 5.4 E-20 + 3 1/2**32**3 = 1.3 E-29 + + + Good sources of uniqueness or randomness are required for this + divergence to occur. If a good source of uniqueness cannot be + found, it is recommended that this Configuration Option not be + enabled; Configure-Requests with the option SHOULD NOT be + transmitted and any Magic-Number Configuration Options which the + peer sends SHOULD be either acknowledged or rejected. In this + case, looped-back links cannot be reliably detected by the + implementation, although they may still be detectable by the peer. + + If an implementation does transmit a Configure-Request with a + Magic-Number Configuration Option, then it MUST NOT respond with a + Configure-Reject when it receives a Configure-Request with a + Magic-Number Configuration Option. That is, if an implementation + desires to use Magic Numbers, then it MUST also allow its peer to + do so. If an implementation does receive a Configure-Reject in + response to a Configure-Request, it can only mean that the link is + not looped-back, and that its peer will not be using Magic- + Numbers. In this case, an implementation SHOULD act as if the + negotiation had been successful (as if it had instead received a + Configure-Ack). + + The Magic-Number also may be used to detect looped-back links + during normal operation, as well as during Configuration Option + negotiation. All LCP Echo-Request, Echo-Reply, and Discard- + Request packets have a Magic-Number field. If Magic-Number has + been successfully negotiated, an implementation MUST transmit + these packets with the Magic-Number field set to its negotiated + Magic-Number. + + The Magic-Number field of these packets SHOULD be inspected on + reception. All received Magic-Number fields MUST be equal to + either zero or the peer's unique Magic-Number, depending on + whether or not the peer negotiated a Magic-Number. + + + +Simpson [Page 46] + RFC 1661 Point-to-Point Protocol July 1994 + + + Reception of a Magic-Number field equal to the negotiated local + Magic-Number indicates a looped-back link. Reception of a Magic- + Number other than the negotiated local Magic-Number, the peer's + negotiated Magic-Number, or zero if the peer didn't negotiate one, + indicates a link which has been (mis)configured for communications + with a different peer. + + Procedures for recovery from either case are unspecified, and may + vary from implementation to implementation. A somewhat + pessimistic procedure is to assume a LCP Down event. A further + Open event will begin the process of re-establishing the link, + which can't complete until the looped-back condition is + terminated, and Magic-Numbers are successfully negotiated. A more + optimistic procedure (in the case of a looped-back link) is to + begin transmitting LCP Echo-Request packets until an appropriate + Echo-Reply is received, indicating a termination of the looped- + back condition. + + A summary of the Magic-Number Configuration Option format is shown + below. The fields are transmitted from 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 | Magic-Number + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Magic-Number (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 5 + + Length + + 6 + + Magic-Number + + The Magic-Number field is four octets, and indicates a number + which is very likely to be unique to one end of the link. A + Magic-Number of zero is illegal and MUST always be Nak'd, if it is + not Rejected outright. + + + + + + + +Simpson [Page 47] + RFC 1661 Point-to-Point Protocol July 1994 + + +6.5. Protocol-Field-Compression (PFC) + + Description + + This Configuration Option provides a method to negotiate the + compression of the PPP Protocol field. By default, all + implementations MUST transmit packets with two octet PPP Protocol + fields. + + PPP Protocol field numbers are chosen such that some values may be + compressed into a single octet form which is clearly + distinguishable from the two octet form. This Configuration + Option is sent to inform the peer that the implementation can + receive such single octet Protocol fields. + + As previously mentioned, the Protocol field uses an extension + mechanism consistent with the ISO 3309 extension mechanism for the + Address field; the Least Significant Bit (LSB) of each octet is + used to indicate extension of the Protocol field. A binary "0" as + the LSB indicates that the Protocol field continues with the + following octet. The presence of a binary "1" as the LSB marks + the last octet of the Protocol field. Notice that any number of + "0" octets may be prepended to the field, and will still indicate + the same value (consider the two binary representations for 3, + 00000011 and 00000000 00000011). + + When using low speed links, it is desirable to conserve bandwidth + by sending as little redundant data as possible. The Protocol- + Field-Compression Configuration Option allows a trade-off between + implementation simplicity and bandwidth efficiency. If + successfully negotiated, the ISO 3309 extension mechanism may be + used to compress the Protocol field to one octet instead of two. + The large majority of packets are compressible since data + protocols are typically assigned with Protocol field values less + than 256. + + Compressed Protocol fields MUST NOT be transmitted unless this + Configuration Option has been negotiated. When negotiated, PPP + implementations MUST accept PPP packets with either double-octet + or single-octet Protocol fields, and MUST NOT distinguish between + them. + + The Protocol field is never compressed when sending any LCP + packet. This rule guarantees unambiguous recognition of LCP + packets. + + When a Protocol field is compressed, the Data Link Layer FCS field + is calculated on the compressed frame, not the original + + + +Simpson [Page 48] + RFC 1661 Point-to-Point Protocol July 1994 + + + uncompressed frame. + + A summary of the Protocol-Field-Compression Configuration Option + format is shown below. The fields are transmitted from left to + right. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 7 + + Length + + 2 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 49] + RFC 1661 Point-to-Point Protocol July 1994 + + +6.6. Address-and-Control-Field-Compression (ACFC) + + Description + + This Configuration Option provides a method to negotiate the + compression of the Data Link Layer Address and Control fields. By + default, all implementations MUST transmit frames with Address and + Control fields appropriate to the link framing. + + Since these fields usually have constant values for point-to-point + links, they are easily compressed. This Configuration Option is + sent to inform the peer that the implementation can receive + compressed Address and Control fields. + + If a compressed frame is received when Address-and-Control-Field- + Compression has not been negotiated, the implementation MAY + silently discard the frame. + + The Address and Control fields MUST NOT be compressed when sending + any LCP packet. This rule guarantees unambiguous recognition of + LCP packets. + + When the Address and Control fields are compressed, the Data Link + Layer FCS field is calculated on the compressed frame, not the + original uncompressed frame. + + A summary of the Address-and-Control-Field-Compression configuration + option format is shown below. The fields are transmitted from left + to right. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 8 + + Length + + 2 + + + + + + + +Simpson [Page 50] + RFC 1661 Point-to-Point Protocol July 1994 + + +Security Considerations + + Security issues are briefly discussed in sections concerning the + Authentication Phase, the Close event, and the Authentication- + Protocol Configuration Option. + + + +References + + [1] Perkins, D., "Requirements for an Internet Standard Point-to- + Point Protocol", RFC 1547, Carnegie Mellon University, + December 1993. + + [2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC + 1340, USC/Information Sciences Institute, July 1992. + + +Acknowledgements + + This document is the product of the Point-to-Point Protocol Working + Group of the Internet Engineering Task Force (IETF). Comments should + be submitted to the ietf-ppp@merit.edu mailing list. + + Much of the text in this document is taken from the working group + requirements [1]; and RFCs 1171 & 1172, by Drew Perkins while at + Carnegie Mellon University, and by Russ Hobby of the University of + California at Davis. + + William Simpson was principally responsible for introducing + consistent terminology and philosophy, and the re-design of the phase + and negotiation state machines. + + Many people spent significant time helping to develop the Point-to- + Point Protocol. The complete list of people is too numerous to list, + but the following people deserve special thanks: Rick Adams, Ken + Adelman, Fred Baker, Mike Ballard, Craig Fox, Karl Fox, Phill Gross, + Kory Hamzeh, former WG chair Russ Hobby, David Kaufman, former WG + chair Steve Knowles, Mark Lewis, former WG chair Brian Lloyd, John + LoVerso, Bill Melohn, Mike Patton, former WG chair Drew Perkins, Greg + Satz, John Shriver, Vernon Schryver, and Asher Waldfogel. + + Special thanks to Morning Star Technologies for providing computing + resources and network access support for writing this specification. + + + + + + + +Simpson [Page 51] + RFC 1661 Point-to-Point Protocol July 1994 + + +Chair's Address + + The working group can be contacted via the current chair: + + Fred Baker + Advanced Computer Communications + 315 Bollay Drive + Santa Barbara, California 93117 + + fbaker@acc.com + + + +Editor's Address + + Questions about this memo can also be directed to: + + William Allen Simpson + Daydreamer + Computer Systems Consulting Services + 1384 Fontaine + Madison Heights, Michigan 48071 + + Bill.Simpson@um.cc.umich.edu + bsimpson@MorningStar.com + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 52] + + diff --git a/rfc/rfc1662.txt b/rfc/rfc1662.txt new file mode 100644 index 00000000..5a5b214c --- /dev/null +++ b/rfc/rfc1662.txt @@ -0,0 +1,1436 @@ + + + + + + + +Network Working Group W. Simpson, Editor +Request for Comments: 1662 Daydreamer +STD: 51 July 1994 +Obsoletes: 1549 +Category: Standards Track + + + PPP in HDLC-like Framing + + +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. + + This document describes the use of HDLC-like framing for PPP + encapsulated packets. + + +Table of Contents + + + 1. Introduction .......................................... 1 + 1.1 Specification of Requirements ................... 2 + 1.2 Terminology ..................................... 2 + + 2. Physical Layer Requirements ........................... 3 + + 3. The Data Link Layer ................................... 4 + 3.1 Frame Format .................................... 5 + 3.2 Modification of the Basic Frame ................. 7 + + 4. Octet-stuffed framing ................................. 8 + 4.1 Flag Sequence ................................... 8 + 4.2 Transparency .................................... 8 + 4.3 Invalid Frames .................................. 9 + 4.4 Time Fill ....................................... 9 + 4.4.1 Octet-synchronous ............................... 9 + 4.4.2 Asynchronous .................................... 9 + 4.5 Transmission Considerations ..................... 10 + 4.5.1 Octet-synchronous ............................... 10 + 4.5.2 Asynchronous .................................... 10 + + +Simpson [Page i] +RFC 1662 HDLC-like Framing July 1994 + + + 5. Bit-stuffed framing ................................... 11 + 5.1 Flag Sequence ................................... 11 + 5.2 Transparency .................................... 11 + 5.3 Invalid Frames .................................. 11 + 5.4 Time Fill ....................................... 11 + 5.5 Transmission Considerations ..................... 12 + + 6. Asynchronous to Synchronous Conversion ................ 13 + + 7. Additional LCP Configuration Options .................. 14 + 7.1 Async-Control-Character-Map (ACCM) .............. 14 + + APPENDICES ................................................... 17 + A. Recommended LCP Options ............................... 17 + B. Automatic Recognition of PPP Frames ................... 17 + C. Fast Frame Check Sequence (FCS) Implementation ........ 18 + C.1 FCS table generator ............................. 18 + C.2 16-bit FCS Computation Method ................... 19 + C.3 32-bit FCS Computation Method ................... 21 + + SECURITY CONSIDERATIONS ...................................... 24 + REFERENCES ................................................... 24 + ACKNOWLEDGEMENTS ............................................. 25 + CHAIR'S ADDRESS .............................................. 25 + EDITOR'S ADDRESS ............................................. 25 + + + + +1. Introduction + + This specification provides for framing over both bit-oriented and + octet-oriented synchronous links, and asynchronous links with 8 bits + of data and no parity. These links MUST be full-duplex, but MAY be + either dedicated or circuit-switched. + + An escape mechanism is specified to allow control data such as + XON/XOFF to be transmitted transparently over the link, and to remove + spurious control data which may be injected into the link by + intervening hardware and software. + + Some protocols expect error free transmission, and either provide + error detection only on a conditional basis, or do not provide it at + all. PPP uses the HDLC Frame Check Sequence for error detection. + This is commonly available in hardware implementations, and a + software implementation is provided. + + + + + + +Simpson [Page 1] +RFC 1662 HDLC-like Framing July 1994 + + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST This word, or the adjective "required", means that the + definition is an absolute requirement of the specification. + + MUST NOT This phrase means that the definition is an absolute + prohibition of the specification. + + SHOULD This word, or the adjective "recommended", means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications must be + understood and carefully weighed before choosing a + different course. + + MAY This word, or the adjective "optional", means that this + item is one of an allowed set of alternatives. An + implementation which does not include this option MUST be + prepared to interoperate with another implementation which + does include the option. + + +1.2. Terminology + + This document frequently uses the following terms: + + datagram The unit of transmission in the network layer (such as IP). + A datagram may be encapsulated in one or more packets + passed to the data link layer. + + frame The unit of transmission at the data link layer. A frame + may include a header and/or a trailer, along with some + number of units of data. + + packet The basic unit of encapsulation, which is passed across the + interface between the network layer and the data link + layer. A packet is usually mapped to a frame; the + exceptions are when data link layer fragmentation is being + performed, or when multiple packets are incorporated into a + single frame. + + peer The other end of the point-to-point link. + + silently discard + The implementation discards the packet without further + processing. The implementation SHOULD provide the + capability of logging the error, including the contents of + the silently discarded packet, and SHOULD record the event + in a statistics counter. + + +Simpson [Page 2] +RFC 1662 HDLC-like Framing July 1994 + + +2. Physical Layer Requirements + + PPP is capable of operating across most DTE/DCE interfaces (such as, + EIA RS-232-E, EIA RS-422, and CCITT V.35). The only absolute + requirement imposed by PPP is the provision of a full-duplex circuit, + either dedicated or circuit-switched, which can operate in either an + asynchronous (start/stop), bit-synchronous, or octet-synchronous + mode, transparent to PPP Data Link Layer frames. + + Interface Format + + PPP presents an octet interface to the physical layer. There is + no provision for sub-octets to be supplied or accepted. + + Transmission Rate + + PPP does not impose any restrictions regarding transmission rate, + other than that of the particular DTE/DCE interface. + + Control Signals + + PPP does not require the use of control signals, such as Request + To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and + Data Terminal Ready (DTR). + + When available, using such signals can allow greater functionality + and performance. In particular, such signals SHOULD be used to + signal the Up and Down events in the LCP Option Negotiation + Automaton [1]. When such signals are not available, the + implementation MUST signal the Up event to LCP upon + initialization, and SHOULD NOT signal the Down event. + + Because signalling is not required, the physical layer MAY be + decoupled from the data link layer, hiding the transient details + of the physical transport. This has implications for mobility in + cellular radio networks, and other rapidly switching links. + + When moving from cell to cell within the same zone, an + implementation MAY choose to treat the entire zone as a single + link, even though transmission is switched among several + frequencies. The link is considered to be with the central + control unit for the zone, rather than the individual cell + transceivers. However, the link SHOULD re-establish its + configuration whenever the link is switched to a different + administration. + + Due to the bursty nature of data traffic, some implementations + have choosen to disconnect the physical layer during periods of + + + +Simpson [Page 3] +RFC 1662 HDLC-like Framing July 1994 + + + inactivity, and reconnect when traffic resumes, without informing + the data link layer. Robust implementations should avoid using + this trick over-zealously, since the price for decreased setup + latency is decreased security. Implementations SHOULD signal the + Down event whenever "significant time" has elapsed since the link + was disconnected. The value for "significant time" is a matter of + considerable debate, and is based on the tariffs, call setup + times, and security concerns of the installation. + + + +3. The Data Link Layer + + PPP uses the principles described in ISO 3309-1979 HDLC frame + structure, most recently the fourth edition 3309:1991 [2], which + specifies modifications to allow HDLC use in asynchronous + environments. + + The PPP control procedures use the Control field encodings described + in ISO 4335-1979 HDLC elements of procedures, most recently the + fourth edition 4335:1991 [4]. + + This should not be construed to indicate that every feature of the + above recommendations are included in PPP. Each feature included + is explicitly described in the following sections. + + To remain consistent with standard Internet practice, and avoid + confusion for people used to reading RFCs, all binary numbers in the + following descriptions are in Most Significant Bit to Least + Significant Bit order, reading from left to right, unless otherwise + indicated. Note that this is contrary to standard ISO and CCITT + practice which orders bits as transmitted (network bit order). Keep + this in mind when comparing this document with the international + standards documents. + + + + + + + + + + + + + + + + + +Simpson [Page 4] +RFC 1662 HDLC-like Framing July 1994 + + +3.1. Frame Format + + A summary of the PPP HDLC-like frame structure is shown below. This + figure does not include bits inserted for synchronization (such as + start and stop bits for asynchronous links), nor any bits or octets + inserted for transparency. The fields are transmitted from left to + right. + + +----------+----------+----------+ + | Flag | Address | Control | + | 01111110 | 11111111 | 00000011 | + +----------+----------+----------+ + +----------+-------------+---------+ + | Protocol | Information | Padding | + | 8/16 bits| * | * | + +----------+-------------+---------+ + +----------+----------+----------------- + | FCS | Flag | Inter-frame Fill + |16/32 bits| 01111110 | or next Address + +----------+----------+----------------- + + The Protocol, Information and Padding fields are described in the + Point-to-Point Protocol Encapsulation [1]. + + Flag Sequence + + Each frame begins and ends with a Flag Sequence, which is the + binary sequence 01111110 (hexadecimal 0x7e). All implementations + continuously check for this flag, which is used for frame + synchronization. + + Only one Flag Sequence is required between two frames. Two + consecutive Flag Sequences constitute an empty frame, which is + silently discarded, and not counted as a FCS error. + + Address Field + + The Address field is a single octet, which contains the binary + sequence 11111111 (hexadecimal 0xff), the All-Stations address. + Individual station addresses are not assigned. The All-Stations + address MUST always be recognized and received. + + The use of other address lengths and values may be defined at a + later time, or by prior agreement. Frames with unrecognized + Addresses SHOULD be silently discarded. + + + + + + +Simpson [Page 5] +RFC 1662 HDLC-like Framing July 1994 + + + Control Field + + The Control field is a single octet, which contains the binary + sequence 00000011 (hexadecimal 0x03), the Unnumbered Information + (UI) command with the Poll/Final (P/F) bit set to zero. + + The use of other Control field values may be defined at a later + time, or by prior agreement. Frames with unrecognized Control + field values SHOULD be silently discarded. + + Frame Check Sequence (FCS) Field + + The Frame Check Sequence field defaults to 16 bits (two octets). + The FCS is transmitted least significant octet first, which + contains the coefficient of the highest term. + + A 32-bit (four octet) FCS is also defined. Its use may be + negotiated as described in "PPP LCP Extensions" [5]. + + The use of other FCS lengths may be defined at a later time, or by + prior agreement. + + The FCS field is calculated over all bits of the Address, Control, + Protocol, Information and Padding fields, not including any start + and stop bits (asynchronous) nor any bits (synchronous) or octets + (asynchronous or synchronous) inserted for transparency. This + also does not include the Flag Sequences nor the FCS field itself. + + When octets are received which are flagged in the Async- + Control-Character-Map, they are discarded before calculating + the FCS. + + For more information on the specification of the FCS, see the + Appendices. + + The end of the Information and Padding fields is found by locating + the closing Flag Sequence and removing the Frame Check Sequence + field. + + + + + + + + + + + + + +Simpson [Page 6] +RFC 1662 HDLC-like Framing July 1994 + + +3.2. Modification of the Basic Frame + + The Link Control Protocol can negotiate modifications to the standard + HDLC-like frame structure. However, modified frames will always be + clearly distinguishable from standard frames. + + Address-and-Control-Field-Compression + + When using the standard HDLC-like framing, the Address and Control + fields contain the hexadecimal values 0xff and 0x03 respectively. + When other Address or Control field values are in use, Address- + and-Control-Field-Compression MUST NOT be negotiated. + + On transmission, compressed Address and Control fields are simply + omitted. + + On reception, the Address and Control fields are decompressed by + examining the first two octets. If they contain the values 0xff + and 0x03, they are assumed to be the Address and Control fields. + If not, it is assumed that the fields were compressed and were not + transmitted. + + By definition, the first octet of a two octet Protocol field + will never be 0xff (since it is not even). The Protocol field + value 0x00ff is not allowed (reserved) to avoid ambiguity when + Protocol-Field-Compression is enabled and the first Information + field octet is 0x03. + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 7] +RFC 1662 HDLC-like Framing July 1994 + + +4. Octet-stuffed framing + + This chapter summarizes the use of HDLC-like framing with 8-bit + asynchronous and octet-synchronous links. + + + +4.1. Flag Sequence + + The Flag Sequence indicates the beginning or end of a frame. The + octet stream is examined on an octet-by-octet basis for the value + 01111110 (hexadecimal 0x7e). + + + +4.2. Transparency + + An octet stuffing procedure is used. The Control Escape octet is + defined as binary 01111101 (hexadecimal 0x7d), most significant bit + first. + + As a minimum, sending implementations MUST escape the Flag Sequence + and Control Escape octets. + + After FCS computation, the transmitter examines the entire frame + between the two Flag Sequences. Each Flag Sequence, Control Escape + octet, and any octet which is flagged in the sending Async-Control- + Character-Map (ACCM), is replaced by a two octet sequence consisting + of the Control Escape octet followed by the original octet + exclusive-or'd with hexadecimal 0x20. + + This is bit 5 complemented, where the bit positions are numbered + 76543210 (the 6th bit as used in ISO numbered 87654321 -- BEWARE + when comparing documents). + + Receiving implementations MUST correctly process all Control Escape + sequences. + + On reception, prior to FCS computation, each octet with value less + than hexadecimal 0x20 is checked. If it is flagged in the receiving + ACCM, it is simply removed (it may have been inserted by intervening + data communications equipment). Each Control Escape octet is also + removed, and the following octet is exclusive-or'd with hexadecimal + 0x20, unless it is the Flag Sequence (which aborts a frame). + + A few examples may make this more clear. Escaped data is transmitted + on the link as follows: + + + + +Simpson [Page 8] +RFC 1662 HDLC-like Framing July 1994 + + + + 0x7e is encoded as 0x7d, 0x5e. (Flag Sequence) + 0x7d is encoded as 0x7d, 0x5d. (Control Escape) + 0x03 is encoded as 0x7d, 0x23. (ETX) + + Some modems with software flow control may intercept outgoing DC1 and + DC3 ignoring the 8th (parity) bit. This data would be transmitted on + the link as follows: + + 0x11 is encoded as 0x7d, 0x31. (XON) + 0x13 is encoded as 0x7d, 0x33. (XOFF) + 0x91 is encoded as 0x7d, 0xb1. (XON with parity set) + 0x93 is encoded as 0x7d, 0xb3. (XOFF with parity set) + + + + +4.3. Invalid Frames + + Frames which are too short (less than 4 octets when using the 16-bit + FCS), or which end with a Control Escape octet followed immediately + by a closing Flag Sequence, or in which octet-framing is violated (by + transmitting a "0" stop bit where a "1" bit is expected), are + silently discarded, and not counted as a FCS error. + + + +4.4. Time Fill + +4.4.1. Octet-synchronous + + There is no provision for inter-octet time fill. + + The Flag Sequence MUST be transmitted during inter-frame time fill. + + +4.4.2. Asynchronous + + Inter-octet time fill MUST be accomplished by transmitting continuous + "1" bits (mark-hold state). + + Inter-frame time fill can be viewed as extended inter-octet time + fill. Doing so can save one octet for every frame, decreasing delay + and increasing bandwidth. This is possible since a Flag Sequence may + serve as both a frame end and a frame begin. After having received + any frame, an idle receiver will always be in a frame begin state. + + + + +Simpson [Page 9] +RFC 1662 HDLC-like Framing July 1994 + + + Robust transmitters should avoid using this trick over-zealously, + since the price for decreased delay is decreased reliability. Noisy + links may cause the receiver to receive garbage characters and + interpret them as part of an incoming frame. If the transmitter does + not send a new opening Flag Sequence before sending the next frame, + then that frame will be appended to the noise characters causing an + invalid frame (with high reliability). + + It is suggested that implementations will achieve the best results by + always sending an opening Flag Sequence if the new frame is not + back-to-back with the last. Transmitters SHOULD send an open Flag + Sequence whenever "appreciable time" has elapsed after the prior + closing Flag Sequence. The maximum value for "appreciable time" is + likely to be no greater than the typing rate of a slow typist, about + 1 second. + + + +4.5. Transmission Considerations + +4.5.1. Octet-synchronous + + The definition of various encodings and scrambling is the + responsibility of the DTE/DCE equipment in use, and is outside the + scope of this specification. + + +4.5.2. Asynchronous + + All octets are transmitted least significant bit first, with one + start bit, eight bits of data, and one stop bit. There is no + provision for seven bit asynchronous links. + + + + + + + + + + + + + + + + + + +Simpson [Page 10] +RFC 1662 HDLC-like Framing July 1994 + + +5. Bit-stuffed framing + + This chapter summarizes the use of HDLC-like framing with bit- + synchronous links. + + + +5.1. Flag Sequence + + The Flag Sequence indicates the beginning or end of a frame, and is + used for frame synchronization. The bit stream is examined on a + bit-by-bit basis for the binary sequence 01111110 (hexadecimal 0x7e). + + The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT be + used. When not avoidable, such an implementation MUST ensure that + the first Flag Sequence detected (the end of the frame) is promptly + communicated to the link layer. Use of the shared zero mode hinders + interoperability with bit-synchronous to asynchronous and bit- + synchronous to octet-synchronous converters. + + + +5.2. Transparency + + After FCS computation, the transmitter examines the entire frame + between the two Flag Sequences. A "0" bit is inserted after all + sequences of five contiguous "1" bits (including the last 5 bits of + the FCS) to ensure that a Flag Sequence is not simulated. + + On reception, prior to FCS computation, any "0" bit that directly + follows five contiguous "1" bits is discarded. + + + +5.3. Invalid Frames + + Frames which are too short (less than 4 octets when using the 16-bit + FCS), or which end with a sequence of more than six "1" bits, are + silently discarded, and not counted as a FCS error. + + + +5.4. Time Fill + + There is no provision for inter-octet time fill. + + The Flag Sequence SHOULD be transmitted during inter-frame time fill. + However, certain types of circuit-switched links require the use of + + + +Simpson [Page 11] +RFC 1662 HDLC-like Framing July 1994 + + + mark idle (continuous ones), particularly those that calculate + accounting based on periods of bit activity. When mark idle is used + on a bit-synchronous link, the implementation MUST ensure at least 15 + consecutive "1" bits between Flags during the idle period, and that + the Flag Sequence is always generated at the beginning of a frame + after an idle period. + + This differs from practice in ISO 3309, which allows 7 to 14 bit + mark idle. + + + +5.5. Transmission Considerations + + All octets are transmitted least significant bit first. + + The definition of various encodings and scrambling is the + responsibility of the DTE/DCE equipment in use, and is outside the + scope of this specification. + + While PPP will operate without regard to the underlying + representation of the bit stream, lack of standards for transmission + will hinder interoperability as surely as lack of data link + standards. At speeds of 56 Kbps through 2.0 Mbps, NRZ is currently + most widely available, and on that basis is recommended as a default. + + When configuration of the encoding is allowed, NRZI is recommended as + an alternative, because of its relative immunity to signal inversion + configuration errors, and instances when it MAY allow connection + without an expensive DSU/CSU. Unfortunately, NRZI encoding + exacerbates the missing x1 factor of the 16-bit FCS, so that one + error in 2**15 goes undetected (instead of one in 2**16), and triple + errors are not detected. Therefore, when NRZI is in use, it is + recommended that the 32-bit FCS be negotiated, which includes the x1 + factor. + + At higher speeds of up to 45 Mbps, some implementors have chosen the + ANSI High Speed Synchronous Interface [HSSI]. While this experience + is currently limited, implementors are encouraged to cooperate in + choosing transmission encoding. + + + + + + + + + + + +Simpson [Page 12] +RFC 1662 HDLC-like Framing July 1994 + + +6. Asynchronous to Synchronous Conversion + + There may be some use of asynchronous-to-synchronous converters (some + built into modems and cellular interfaces), resulting in an + asynchronous PPP implementation on one end of a link and a + synchronous implementation on the other. It is the responsibility of + the converter to do all stuffing conversions during operation. + + To enable this functionality, synchronous PPP implementations MUST + always respond to the Async-Control-Character-Map Configuration + Option with the LCP Configure-Ack. However, acceptance of the + Configuration Option does not imply that the synchronous + implementation will do any ACCM mapping. Instead, all such octet + mapping will be performed by the asynchronous-to-synchronous + converter. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 13] +RFC 1662 HDLC-like Framing July 1994 + + +7. Additional LCP Configuration Options + + The Configuration Option format and basic options are already defined + for LCP [1]. + + Up-to-date values of the LCP Option Type field are specified in the + most recent "Assigned Numbers" RFC [10]. This document concerns the + following values: + + 2 Async-Control-Character-Map + + + + +7.1. Async-Control-Character-Map (ACCM) + + Description + + This Configuration Option provides a method to negotiate the use + of control character transparency on asynchronous links. + + Each end of the asynchronous link maintains two Async-Control- + Character-Maps. The receiving ACCM is 32 bits, but the sending + ACCM may be up to 256 bits. This results in four distinct ACCMs, + two in each direction of the link. + + For asynchronous links, the default receiving ACCM is 0xffffffff. + The default sending ACCM is 0xffffffff, plus the Control Escape + and Flag Sequence characters themselves, plus whatever other + outgoing characters are flagged (by prior configuration) as likely + to be intercepted. + + For other types of links, the default value is 0, since there is + no need for mapping. + + The default inclusion of all octets less than hexadecimal 0x20 + allows all ASCII control characters [6] excluding DEL (Delete) + to be transparently communicated through all known data + communications equipment. + + The transmitter MAY also send octets with values in the range 0x40 + through 0xff (except 0x5e) in Control Escape format. Since these + octet values are not negotiable, this does not solve the problem + of receivers which cannot handle all non-control characters. + Also, since the technique does not affect the 8th bit, this does + not solve problems for communications links that can send only 7- + bit characters. + + + + +Simpson [Page 14] +RFC 1662 HDLC-like Framing July 1994 + + + Note that this specification differs in detail from later + amendments, such as 3309:1991/Amendment 2 [3]. However, such + "extended transparency" is applied only by "prior agreement". + Use of the transparency methods in this specification + constitute a prior agreement with respect to PPP. + + For compatibility with 3309:1991/Amendment 2, the transmitter + MAY escape DEL and ACCM equivalents with the 8th (most + significant) bit set. No change is required in the receiving + algorithm. + + Following ACCM negotiation, the transmitter SHOULD cease + escaping DEL. + + However, it is rarely necessary to map all control characters, and + often it is unnecessary to map any control characters. The + Configuration Option is used to inform the peer which control + characters MUST remain mapped when the peer sends them. + + The peer MAY still send any other octets in mapped format, if it + is necessary because of constraints known to the peer. The peer + SHOULD Configure-Nak with the logical union of the sets of mapped + octets, so that when such octets are spuriously introduced they + can be ignored on receipt. + + A summary of the Async-Control-Character-Map Configuration Option + format is shown below. The fields are transmitted from 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 | ACCM + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ACCM (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 2 + + Length + + 6 + + + + + + +Simpson [Page 15] +RFC 1662 HDLC-like Framing July 1994 + + + ACCM + + The ACCM field is four octets, and indicates the set of control + characters to be mapped. The map is sent most significant octet + first. + + Each numbered bit corresponds to the octet of the same value. If + the bit is cleared to zero, then that octet need not be mapped. + If the bit is set to one, then that octet MUST remain mapped. For + example, if bit 19 is set to zero, then the ASCII control + character 19 (DC3, Control-S) MAY be sent in the clear. + + Note: The least significant bit of the least significant octet + (the final octet transmitted) is numbered bit 0, and would map + to the ASCII control character NUL. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 16] +RFC 1662 HDLC-like Framing July 1994 + + +A. Recommended LCP Options + + The following Configurations Options are recommended: + + High Speed links + + Magic Number + Link Quality Monitoring + No Address and Control Field Compression + No Protocol Field Compression + + + Low Speed or Asynchronous links + + Async Control Character Map + Magic Number + Address and Control Field Compression + Protocol Field Compression + + + +B. Automatic Recognition of PPP Frames + + It is sometimes desirable to detect PPP frames, for example during a + login sequence. The following octet sequences all begin valid PPP + LCP frames: + + 7e ff 03 c0 21 + 7e ff 7d 23 c0 21 + 7e 7d df 7d 23 c0 21 + + Note that the first two forms are not a valid username for Unix. + However, only the third form generates a correctly checksummed PPP + frame, whenever 03 and ff are taken as the control characters ETX and + DEL without regard to parity (they are correct for an even parity + link) and discarded. + + Many implementations deal with this by putting the interface into + packet mode when one of the above username patterns are detected + during login, without examining the initial PPP checksum. The + initial incoming PPP frame is discarded, but a Configure-Request is + sent immediately. + + + + + + + + + +Simpson [Page 17] +RFC 1662 HDLC-like Framing July 1994 + + +C. Fast Frame Check Sequence (FCS) Implementation + + The FCS was originally designed with hardware implementations in + mind. A serial bit stream is transmitted on the wire, the FCS is + calculated over the serial data as it goes out, and the complement of + the resulting FCS is appended to the serial stream, followed by the + Flag Sequence. + + The receiver has no way of determining that it has finished + calculating the received FCS until it detects the Flag Sequence. + Therefore, the FCS was designed so that a particular pattern results + when the FCS operation passes over the complemented FCS. A good + frame is indicated by this "good FCS" value. + + + +C.1. FCS table generator + + The following code creates the lookup table used to calculate the + FCS-16. + + /* + * Generate a FCS-16 table. + * + * Drew D. Perkins at Carnegie Mellon University. + * + * Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier. + */ + + /* + * The FCS-16 generator polynomial: x**0 + x**5 + x**12 + x**16. + */ + #define P 0x8408 + + + main() + { + register unsigned int b, v; + register int i; + + printf("typedef unsigned short u16;\n"); + printf("static u16 fcstab[256] = {"); + for (b = 0; ; ) { + if (b % 8 == 0) + printf("\n"); + + v = b; + for (i = 8; i--; ) + + + +Simpson [Page 18] +RFC 1662 HDLC-like Framing July 1994 + + + v = v & 1 ? (v >> 1) ^ P : v >> 1; + + printf("\t0x%04x", v & 0xFFFF); + if (++b == 256) + break; + printf(","); + } + printf("\n};\n"); + } + + + +C.2. 16-bit FCS Computation Method + + The following code provides a table lookup computation for + calculating the Frame Check Sequence as data arrives at the + interface. This implementation is based on [7], [8], and [9]. + + /* + * u16 represents an unsigned 16-bit number. Adjust the typedef for + * your hardware. + */ + typedef unsigned short u16; + + /* + * FCS lookup table as calculated by the table generator. + */ + static u16 fcstab[256] = { + 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, + 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, + 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e, + 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876, + 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd, + 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5, + 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c, + 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974, + 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb, + 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3, + 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a, + 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72, + 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9, + 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1, + 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738, + 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70, + 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7, + 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff, + 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036, + 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e, + + + +Simpson [Page 19] +RFC 1662 HDLC-like Framing July 1994 + + + 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5, + 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd, + 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134, + 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c, + 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3, + 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb, + 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232, + 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a, + 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1, + 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9, + 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330, + 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78 + }; + + #define PPPINITFCS16 0xffff /* Initial FCS value */ + #define PPPGOODFCS16 0xf0b8 /* Good final FCS value */ + + /* + * Calculate a new fcs given the current fcs and the new data. + */ + u16 pppfcs16(fcs, cp, len) + register u16 fcs; + register unsigned char *cp; + register int len; + { + ASSERT(sizeof (u16) == 2); + ASSERT(((u16) -1) > 0); + while (len--) + fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff]; + + return (fcs); + } + + /* + * How to use the fcs + */ + tryfcs16(cp, len) + register unsigned char *cp; + register int len; + { + u16 trialfcs; + + /* add on output */ + trialfcs = pppfcs16( PPPINITFCS16, cp, len ); + trialfcs ^= 0xffff; /* complement */ + cp[len] = (trialfcs & 0x00ff); /* least significant byte first */ + cp[len+1] = ((trialfcs >> 8) & 0x00ff); + + + + +Simpson [Page 20] +RFC 1662 HDLC-like Framing July 1994 + + + /* check on input */ + trialfcs = pppfcs16( PPPINITFCS16, cp, len + 2 ); + if ( trialfcs == PPPGOODFCS16 ) + printf("Good FCS\n"); + } + + + +C.3. 32-bit FCS Computation Method + + The following code provides a table lookup computation for + calculating the 32-bit Frame Check Sequence as data arrives at the + interface. + + /* + * The FCS-32 generator polynomial: x**0 + x**1 + x**2 + x**4 + x**5 + * + x**7 + x**8 + x**10 + x**11 + x**12 + x**16 + * + x**22 + x**23 + x**26 + x**32. + */ + + /* + * u32 represents an unsigned 32-bit number. Adjust the typedef for + * your hardware. + */ + typedef unsigned long u32; + + static u32 fcstab_32[256] = + { + 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, + 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3, + 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988, + 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91, + 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de, + 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, + 0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, + 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5, + 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172, + 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b, + 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, + 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59, + 0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, + 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f, + 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924, + 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, + 0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a, + 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433, + 0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818, + 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01, + + + +Simpson [Page 21] +RFC 1662 HDLC-like Framing July 1994 + + + 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, + 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457, + 0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c, + 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65, + 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, + 0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb, + 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0, + 0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9, + 0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086, + 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f, + 0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, + 0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad, + 0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a, + 0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683, + 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8, + 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1, + 0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe, + 0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7, + 0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc, + 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5, + 0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252, + 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b, + 0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60, + 0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79, + 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236, + 0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, + 0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04, + 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d, + 0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a, + 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713, + 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38, + 0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, + 0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e, + 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777, + 0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c, + 0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45, + 0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2, + 0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db, + 0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0, + 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9, + 0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, + 0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf, + 0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94, + 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d + }; + + #define PPPINITFCS32 0xffffffff /* Initial FCS value */ + #define PPPGOODFCS32 0xdebb20e3 /* Good final FCS value */ + + + +Simpson [Page 22] +RFC 1662 HDLC-like Framing July 1994 + + + /* + * Calculate a new FCS given the current FCS and the new data. + */ + u32 pppfcs32(fcs, cp, len) + register u32 fcs; + register unsigned char *cp; + register int len; + { + ASSERT(sizeof (u32) == 4); + ASSERT(((u32) -1) > 0); + while (len--) + fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]); + + return (fcs); + } + + /* + * How to use the fcs + */ + tryfcs32(cp, len) + register unsigned char *cp; + register int len; + { + u32 trialfcs; + + /* add on output */ + trialfcs = pppfcs32( PPPINITFCS32, cp, len ); + trialfcs ^= 0xffffffff; /* complement */ + cp[len] = (trialfcs & 0x00ff); /* least significant byte first */ + cp[len+1] = ((trialfcs >>= 8) & 0x00ff); + cp[len+2] = ((trialfcs >>= 8) & 0x00ff); + cp[len+3] = ((trialfcs >> 8) & 0x00ff); + + /* check on input */ + trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 ); + if ( trialfcs == PPPGOODFCS32 ) + printf("Good FCS\n"); + } + + + + + + + + + + + + + +Simpson [Page 23] +RFC 1662 HDLC-like Framing July 1994 + + +Security Considerations + + As noted in the Physical Layer Requirements section, the link layer + might not be informed when the connected state of the physical layer + has changed. This results in possible security lapses due to over- + reliance on the integrity and security of switching systems and + administrations. An insertion attack might be undetected. An + attacker which is able to spoof the same calling identity might be + able to avoid link authentication. + + + +References + + [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", + STD 50, RFC 1661, Daydreamer, July 1994. + + [2] ISO/IEC 3309:1991(E), "Information Technology - + Telecommunications and information exchange between systems - + High-level data link control (HDLC) procedures - Frame + structure", International Organization For Standardization, + Fourth edition 1991-06-01. + + [3] ISO/IEC 3309:1991/Amd.2:1992(E), "Information Technology - + Telecommunications and information exchange between systems - + High-level data link control (HDLC) procedures - Frame + structure - Amendment 2: Extended transparency options for + start/stop transmission", International Organization For + Standardization, 1992-01-15. + + [4] ISO/IEC 4335:1991(E), "Information Technology - + Telecommunications and information exchange between systems - + High-level data link control (HDLC) procedures - Elements of + procedures", International Organization For Standardization, + Fourth edition 1991-09-15. + + [5] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, + Daydreamer, January 1994. + + [6] ANSI X3.4-1977, "American National Standard Code for + Information Interchange", American National Standards + Institute, 1977. + + [7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June 1983. + + [8] Morse, G., "Calculating CRC's by Bits and Bytes", Byte, + September 1986. + + + + +Simpson [Page 24] +RFC 1662 HDLC-like Framing July 1994 + + + [9] LeVan, J., "A Fast CRC", Byte, November 1987. + + [10] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC + 1340, USC/Information Sciences Institute, July 1992. + + + +Acknowledgements + + This document is the product of the Point-to-Point Protocol Working + Group of the Internet Engineering Task Force (IETF). Comments should + be submitted to the ietf-ppp@merit.edu mailing list. + + This specification is based on previous RFCs, where many + contributions have been acknowleged. + + The 32-bit FCS example code was provided by Karl Fox (Morning Star + Technologies). + + Special thanks to Morning Star Technologies for providing computing + resources and network access support for writing this specification. + + + +Chair's Address + + The working group can be contacted via the current chair: + + Fred Baker + Advanced Computer Communications + 315 Bollay Drive + Santa Barbara, California 93117 + + fbaker@acc.com + + +Editor's Address + + Questions about this memo can also be directed to: + + William Allen Simpson + Daydreamer + Computer Systems Consulting Services + 1384 Fontaine + Madison Heights, Michigan 48071 + + Bill.Simpson@um.cc.umich.edu + bsimpson@MorningStar.com + + +Simpson [Page 25] diff --git a/rfc/rfc1701.txt b/rfc/rfc1701.txt new file mode 100644 index 00000000..60a0e9b9 --- /dev/null +++ b/rfc/rfc1701.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group S. Hanks +Request for Comments: 1701 NetSmiths, Ltd. +Category: Informational T. Li + D. Farinacci + P. Traina + cisco Systems + October 1994 + + + Generic Routing Encapsulation (GRE) + +Status of this Memo + + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This document specifies a protocol for performing encapsulation of an + arbitrary network layer protocol over another arbitrary network layer + protocol. + +Introduction + + A number of different proposals [RFC 1234, RFC 1226] currently exist + for the encapsulation of one protocol over another protocol. Other + types of encapsulations [RFC 1241, SDRP, RFC 1479] have been proposed + for transporting IP over IP for policy purposes. This memo describes + a protocol which is very similar to, but is more general than, the + above proposals. In attempting to be more general, many protocol + specific nuances have been ignored. The result is that this proposal + is may be less suitable for a situation where a specific "X over Y" + encapsulation has been described. It is the attempt of this protocol + to provide a simple, general purpose mechanism which is reduces the + problem of encapsulation from its current O(n^2) problem to a more + manageable state. This proposal also attempts to provide a + lightweight encapsulation for use in policy based routing. This memo + explicitly does not address the issue of when a packet should be + encapsulated. This memo acknowledges, but does not address problems + with mutual encapsulation [RFC 1326]. + + In the most general case, a system has a packet that needs to be + encapsulated and routed. We will call this the payload packet. The + payload is first encapsulated in a GRE packet, which possibly also + includes a route. The resulting GRE packet can then be encapsulated + in some other protocol and then forwarded. We will call this outer + + + +Hanks, Li, Farinacci & Traina [Page 1] + +RFC 1701 Generic Routing Encapsulation (GRE) October 1994 + + + protocol the delivery protocol. The algorithms for processing this + packet are discussed later. + +Overall packet + + The entire encapsulated packet would then have the form: + + --------------------------------- + | | + | Delivery Header | + | | + --------------------------------- + | | + | GRE Header | + | | + --------------------------------- + | | + | Payload packet | + | | + --------------------------------- + +Packet header + + The GRE packet header has the form: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |C|R|K|S|s|Recur| Flags | Ver | Protocol Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Checksum (optional) | Offset (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Routing (optional) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Flags and version (2 octets) + + The GRE flags are encoded in the first two octets. Bit 0 is the + most significant bit, bit 15 is the least significant bit. Bits + 13 through 15 are reserved for the Version field. Bits 5 through + 12 are reserved for future use and MUST be transmitted as zero. + + + + + + +Hanks, Li, Farinacci & Traina [Page 2] + +RFC 1701 Generic Routing Encapsulation (GRE) October 1994 + + + Checksum Present (bit 0) + + If the Checksum Present bit is set to 1, then the Checksum field + is present and contains valid information. + + If either the Checksum Present bit or the Routing Present bit are + set, BOTH the Checksum and Offset fields are present in the GRE + packet. + + Routing Present (bit 1) + + If the Routing Present bit is set to 1, then it indicates that the + Offset and Routing fields are present and contain valid + information. + + If either the Checksum Present bit or the Routing Present bit are + set, BOTH the Checksum and Offset fields are present in the GRE + packet. + + Key Present (bit 2) + + If the Key Present bit is set to 1, then it indicates that the Key + field is present in the GRE header. Otherwise, the Key field is + not present in the GRE header. + + Sequence Number Present (bit 3) + + If the Sequence Number Present bit is set to 1, then it indicates + that the Sequence Number field is present. Otherwise, the + Sequence Number field is not present in the GRE header. + + Strict Source Route (bit 4) + + The meaning of the Strict Source route bit is defined in other + documents. It is recommended that this bit only be set to 1 if + all of the the Routing Information consists of Strict Source + Routes. + + Recursion Control (bits 5-7) + + Recursion control contains a three bit unsigned integer which + contains the number of additional encapsulations which are + permissible. This SHOULD default to zero. + + Version Number (bits 13-15) + + The Version Number field MUST contain the value 0. Other values + are outside of the scope of this document. + + + +Hanks, Li, Farinacci & Traina [Page 3] + +RFC 1701 Generic Routing Encapsulation (GRE) October 1994 + + + Protocol Type (2 octets) + + The Protocol Type field contains the protocol type of the payload + packet. In general, the value will be the Ethernet protocol type + field for the packet. Currently defined protocol types are listed + below. Additional values may be defined in other documents. + + Offset (2 octets) + + The offset field indicates the octet offset from the start of the + Routing field to the first octet of the active Source Route Entry + to be examined. This field is present if the Routing Present or + the Checksum Present bit is set to 1, and contains valid + information only if the Routing Present bit is set to 1. + + Checksum (2 octets) + + The Checksum field contains the IP (one's complement) checksum of + the GRE header and the payload packet. This field is present if + the Routing Present or the Checksum Present bit is set to 1, and + contains valid information only if the Checksum Present bit is set + to 1. + + Key (4 octets) + + The Key field contains a four octet number which was inserted by + the encapsulator. It may be used by the receiver to authenticate + the source of the packet. The techniques for determining + authenticity are outside of the scope of this document. The Key + field is only present if the Key Present field is set to 1. + + Sequence Number (4 octets) + + The Sequence Number field contains an unsigned 32 bit integer + which is inserted by the encapsulator. It may be used by the + receiver to establish the order in which packets have been + transmitted from the encapsulator to the receiver. The exact + algorithms for the generation of the Sequence Number and the + semantics of their reception is outside of the scope of this + document. + + Routing (variable) + + The Routing field is optional and is present only if the Routing + Present bit is set to 1. + + + + + + +Hanks, Li, Farinacci & Traina [Page 4] + +RFC 1701 Generic Routing Encapsulation (GRE) October 1994 + + + The Routing field is a list of Source Route Entries (SREs). Each + SRE has the form: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Address Family | SRE Offset | SRE Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Routing Information ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The routing field is terminated with a "NULL" SRE containing an + address family of type 0x0000 and a length of 0. + + Address Family (2 octets) + + The Address Family field contains a two octet value which indicates + the syntax and semantics of the Routing Information field. The + values for this field and the corresponding syntax and semantics for + Routing Information are defined in other documents. + + SRE Offset (1 octet) + + The SRE Offset field indicates the octet offset from the start of the + Routing Information field to the first octet of the active entry in + Source Route Entry to be examined. + + SRE Length (1 octet) + + The SRE Length field contains the number of octets in the SRE. If + the SRE Length is 0, this indicates this is the last SRE in the + Routing field. + + Routing Information (variable) + + The Routing Information field contains data which may be used in + routing this packet. The exact semantics of this field is defined in + other documents. + +Forwarding of GRE packets + + Normally, a system which is forwarding delivery layer packets will + not differentiate GRE packets from other packets in any way. + However, a GRE packet may be received by a system. In this case, the + system should use some delivery-specific means to determine that this + is a GRE packet. Once this is determined, the Key, Sequence Number + and Checksum fields if they contain valid information as indicated by + the corresponding flags may be checked. If the Routing Present bit + + + +Hanks, Li, Farinacci & Traina [Page 5] + +RFC 1701 Generic Routing Encapsulation (GRE) October 1994 + + + is set to 1, then the Address Family field should be checked to + determine the semantics and use of the SRE Length, SRE Offset and + Routing Information fields. The exact semantics for processing a SRE + for each Address Family is defined in other documents. + + Once all SREs have been processed, then the source route is complete, + the GRE header should be removed, the payload's TTL MUST be + decremented (if one exists) and the payload packet should be + forwarded as a normal packet. The exact forwarding method depends on + the Protocol Type field. + +Current List of Protocol Types + + The following are currently assigned protocol types for GRE. Future + protocol types must be taken from DIX ethernet encoding. For + historical reasons, a number of other values have been used for some + protocols. The following table of values MUST be used to identify + the following protocols: + + Protocol Family PTYPE + --------------- ----- + Reserved 0000 + SNA 0004 + OSI network layer 00FE + PUP 0200 + XNS 0600 + IP 0800 + Chaos 0804 + RFC 826 ARP 0806 + Frame Relay ARP 0808 + VINES 0BAD + VINES Echo 0BAE + VINES Loopback 0BAF + DECnet (Phase IV) 6003 + Transparent Ethernet Bridging 6558 + Raw Frame Relay 6559 + Apollo Domain 8019 + Ethertalk (Appletalk) 809B + Novell IPX 8137 + RFC 1144 TCP/IP compression 876B + IP Autonomous Systems 876C + Secure Data 876D + Reserved FFFF + + See the IANA list of Ether Types for the complete list of these + values. + + URL = ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers. + + + +Hanks, Li, Farinacci & Traina [Page 6] + +RFC 1701 Generic Routing Encapsulation (GRE) October 1994 + + +References + + RFC 1479 + Steenstrup, M. "Inter-Domain Policy Routing Protocol + Specification: Version 1", RFC1479, BBN Systems and Technologies, + July 1993. + + RFC 1226 + Kantor, B. "Internet Protocol Encapsulation of AX.25 Frames", RFC + 1226, University of California, San Diego, May 1991. + + RFC 1234 + Provan, D. "Tunneling IPX Traffic through IP Networks", RFC 1234, + Novell, Inc., June 1991. + + RFC 1241 + Woodburn, R., and D. Mills, "Scheme for an Internet Encapsulation + Protocol: Version 1", RFC 1241, SAIC, University of Delaware, July + 1991. + + RFC 1326 + Tsuchiya, P., "Mutual Encapsulation Considered Dangerous", RFC + 1326, Bellcore, May 1992. + + SDRP + Estrin, D., Li, T., and Y. Rekhter, "Source Demand Routing + Protocol Specification (Version 1)", Work in Progress. + + RFC 1702 + Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing + Encapsulation over IPv4 networks", RFC 1702, NetSmiths, Ltd., + cisco Systems, October 1994. + +Security Considerations + + Security issues are not discussed in this memo. + + + + + + + + + + + + + + + +Hanks, Li, Farinacci & Traina [Page 7] + +RFC 1701 Generic Routing Encapsulation (GRE) October 1994 + + +Acknowledgements + + The authors would like to acknowledge Yakov Rekhter (IBM) and Deborah + Estrin (USC) for their advice, encouragement and insightful comments. + +Authors' Addresses + + Stan Hanks + NetSmiths, Ltd. + 2025 Lincoln Highway + Edison NJ, 08817 + + EMail: stan@netsmiths.com + + + Tony Li + cisco Systems, Inc. + 1525 O'Brien Drive + Menlo Park, CA 94025 + + EMail: tli@cisco.com + + + Dino Farinacci + cisco Systems, Inc. + 1525 O'Brien Drive + Menlo Park, CA 94025 + + EMail: dino@cisco.com + + + Paul Traina + cisco Systems, Inc. + 1525 O'Brien Drive + Menlo Park, CA 94025 + + EMail: pst@cisco.com + + + + + + + + + + + + + + +Hanks, Li, Farinacci & Traina [Page 8] + diff --git a/rfc/rfc1702.txt b/rfc/rfc1702.txt new file mode 100644 index 00000000..50b57ae3 --- /dev/null +++ b/rfc/rfc1702.txt @@ -0,0 +1,227 @@ + + + + + + +Network Working Group S. Hanks +Request for Comments: 1702 NetSmiths, Ltd. +Category: Informational T. Li + D. Farinacci + P. Traina + cisco Systems + October 1994 + + + Generic Routing Encapsulation over IPv4 networks + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Introduction + + In an earlier memo [RFC 1701], we described GRE, a mechanism for + encapsulating arbitrary packets within an arbitrary transport + protocol. This is a companion memo which describes the use of GRE + with IP. This memo addresses the case of using IP as the delivery + protocol or the payload protocol and the special case of IP as both + the delivery and payload. This memo also describes using IP + addresses and autonomous system numbers as part of a GRE source + route. + +IP as a delivery protocol + + GRE packets which are encapsulated within IP will use IP protocol + type 47. + +IP as a payload protocol + + IP packets will be encapsulated with a Protocol Type field of 0x800. + + For the Address Family value of 0x800, the Routing Information field + will consist of a list of IP addresses and indicates an IP source + route. The first octet of the Routing Information field constitute a + 8 bit integer offset from the start of the Source Route Entry (SRE), + called the SRE Offset. The SRE Offset indicates the first octet of + the next IP address. The SRE Length field consists of the total + length of the IP Address List in octets. + + + + + + + +Hanks, Li, Farinacci & Traina [Page 1] + +RFC 1702 GRE over IPv4 networks October 1994 + + + This has the form: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Address Family | SRE Offset | SRE Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IP Address List ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + For the Address Family value of 0xfffe, the Routing Information field + will consist of a list of Autonomous System numbers and indicates an + AS source route. The third octet of the Routing Information field + contains an 8 bit unsigned integer offset from the start of the + Source Route Entry (SRE), called the SRE Offset. The SRE Offset + indicates the first octet of the next AS number. THe SRE Length + field consists of the total length of the AS Number list in octets. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Address Family | SRE Offset | SRE Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AS Number List ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +IP as both delivery and payload protocol + + When IP is encapsulated in IP, the TTL, TOS, and IP security options + MAY be copied from the payload packet into the same fields in the + delivery packet. The payload packet's TTL MUST be decremented when + the packet is decapsulated to insure that no packet lives forever. + +IP source routes + + When a system is processing a SRE with an Address Family indicating + an IP source route, it MUST use the SRE Offset to determine the next + destination IP address. If the next IP destination is this system, + the SRE Offset field should be increased by four (the size of an IP + address). If the SRE Offset is equal to the SRE Length in this SRE, + then the Offset field in the GRE header should be adjusted to point + to the next SRE (if any). This should be repeated until the next IP + destination is not this system or until the entire SRE has been + processed. + + If the source route is incomplete, then the Strict Source Route bit + is checked. If the source route is a strict source route and the + next IP destination is NOT an adjacent system, the packet MUST be + + + +Hanks, Li, Farinacci & Traina [Page 2] + +RFC 1702 GRE over IPv4 networks October 1994 + + + dropped. Otherwise, the system should use the IP address indicated + by the Offset field to replace the destination address in the + delivery header and forward the packet. + +Autonomous system source routes + + When a system is processing a SRE with an Address Family indicating + an AS source route, it MUST use the SRE Offset field to determine the + next autonomous system. If the next autonomous system is the local + autonomous system, the SRE Offset field should be increased by two + (the size of an autonomous system number). If the SRE Offset is + equal to the SRE Length in this SRE, then the Offset field in the GRE + header should be adjusted to point to the next SRE (if any). This + should be repeated until the next autonomous system number is not + equal to the local autonomous system number or until the entire SRE + has been processed. + + If the source route is incomplete, then the Strict Source Route bit + is checked. If the source route is a strict source route and the + next autonomous system is NOT an adjacent autonomous system, the + packet should be dropped. Otherwise, the system should use the + autonomous system number indicated by the SRE Offset field to replace + the destination address in the delivery header and forward the + packet. The exact mechanism for determining the next delivery + destination address given the AS number is outside of the scope of + this document. + +Security Considerations + + Security issues are not discussed in this memo. + + + + + + + + + + + + + + + + + + + + + +Hanks, Li, Farinacci & Traina [Page 3] + +RFC 1702 GRE over IPv4 networks October 1994 + + +Authors' Addresses + + Stan Hanks + NetSmiths, Ltd. + 2025 Lincoln Highway + Edison, NJ 08817 + + EMail: stan@netsmiths.com + + + Tony Li + cisco Systems, Inc. + 1525 O'Brien Drive + Menlo Park, CA 94025 + + EMail: tli@cisco.com + + + Dino Farinacci + cisco Systems, Inc. + 1525 O'Brien Drive + Menlo Park, CA 94025 + + EMail: dino@cisco.com + + + Paul Traina + cisco Systems, Inc. + 1525 O'Brien Drive + Menlo Park, CA 94025 + + EMail: pst@cisco.com + +References + + RFC 1701 + Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing + Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco Systems, + October 1994. + + + + + + + + + + + + +Hanks, Li, Farinacci & Traina [Page 4] + diff --git a/rfc/rfc1877.txt b/rfc/rfc1877.txt new file mode 100644 index 00000000..843c15c4 --- /dev/null +++ b/rfc/rfc1877.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group S. Cobb +Request for Comments: 1877 Microsoft +Category: Informational December 1995 + + + PPP Internet Protocol Control Protocol Extensions for + Name Server Addresses + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. 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 + defines an extensible Link Control Protocol and a family of Network + Control Protocols (NCPs) for establishing and configuring different + network-layer protocols. + + This document extends the NCP for establishing and configuring the + Internet Protocol over PPP [2], defining the negotiation of primary + and secondary Domain Name System (DNS) [3] and NetBIOS Name Server + (NBNS) [4] addresses. + +Table of Contents + + 1. Additional IPCP Configuration options ................. 1 + 1.1 Primary DNS Server Address .................... 2 + 1.2 Primary NBNS Server Address ................... 3 + 1.3 Secondary DNS Server Address .................. 4 + 1.4 Secondary NBNS Server Address ................. 5 + REFRENCES .................................................... 6 + SECURITY CONSIDERATIONS ...................................... 6 + CHAIR'S ADDRESS .............................................. 6 + AUTHOR'S ADDRESS ............................................. 6 + +1. Additional IPCP Configuration Options + + The four name server address configuration options, 129 to 132, + provide a method of obtaining the addresses of Domain Name System + (DNS) servers and (NetBIOS Name Server (NBNS) nodes on the remote + network. + + + + + + +Cobb Informational [Page 1] + +RFC 1877 PPP IPCP Extensions December 1995 + + + Primary and secondary addresses are negotiated independently. They + serve identical purposes, except that when both are present an + attempt SHOULD be made to resolve names using the primary address + before using the secondary address. + + For implementational convenience, these options are designed to be + identical in format and behavior to option 3 (IP-Address) which is + already present in most IPCP implementations. + + Since the usefulness of name server address information is dependent + on the topology of the remote network and local peer's application, + it is suggested that these options not be included in the list of + "IPCP Recommended Options". + +1.1. Primary DNS Server Address + + Description + + This Configuration Option defines a method for negotiating with + the remote peer the address of the primary DNS server to be used + on the local end of the link. If local peer requests an invalid + server address (which it will typically do intentionally) the + remote peer specifies the address by NAKing this option, and + returning the IP address of a valid DNS server. + + By default, no primary DNS address is provided. + + A summary of the Primary DNS Address Configuration Option format is + shown below. The fields are transmitted from 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 | Primary-DNS-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Primary-DNS-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 129 + + Length + + 6 + + + + + + +Cobb Informational [Page 2] + +RFC 1877 PPP IPCP Extensions December 1995 + + + Primary-DNS-Address + + The four octet Primary-DNS-Address is the address of the primary + DNS server to be used by the local peer. If all four octets are + set to zero, it indicates an explicit request that the peer + provide the address information in a Config-Nak packet. + + Default + + No address is provided. + +1.2. Primary NBNS Server Address + + Description + + This Configuration Option defines a method for negotiating with + the remote peer the address of the primary NBNS server to be used + on the local end of the link. If local peer requests an invalid + server address (which it will typically do intentionally) the + remote peer specifies the address by NAKing this option, and + returning the IP address of a valid NBNS server. + + By default, no primary NBNS address is provided. + + A summary of the Primary NBNS Address Configuration Option format is + shown below. The fields are transmitted from 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 | Primary-NBNS-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Primary-NBNS-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 130 + + Length + + 6 + + Primary-NBNS-Address + + The four octet Primary-NBNS-Address is the address of the primary + NBNS server to be used by the local peer. If all four octets are + set to zero, it indicates an explicit request that the peer + + + +Cobb Informational [Page 3] + +RFC 1877 PPP IPCP Extensions December 1995 + + + provide the address information in a Config-Nak packet. + + Default + + No address is provided. + +1.3. Secondary DNS Server Address + + Description + + This Configuration Option defines a method for negotiating with + the remote peer the address of the secondary DNS server to be used + on the local end of the link. If local peer requests an invalid + server address (which it will typically do intentionally) the + remote peer specifies the address by NAKing this option, and + returning the IP address of a valid DNS server. + + By default, no secondary DNS address is provided. + + A summary of the Secondary DNS Address Configuration Option format is + shown below. The fields are transmitted from 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 | Secondary-DNS-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Secondary-DNS-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 131 + + Length + + 6 + + Secondary-DNS-Address + + The four octet Secondary-DNS-Address is the address of the primary + NBNS server to be used by the local peer. If all four octets are + set to zero, it indicates an explicit request that the peer + provide the address information in a Config-Nak packet. + + Default + + No address is provided. + + + +Cobb Informational [Page 4] + +RFC 1877 PPP IPCP Extensions December 1995 + + +1.4. Secondary NBNS Server Address + + Description + + This Configuration Option defines a method for negotiating with + the remote peer the address of the secondary NBNS server to be + used on the local end of the link. If local peer requests an + invalid server address (which it will typically do intentionally) + the remote peer specifies the address by NAKing this option, and + returning the IP address of a valid NBNS server. + + By default, no secondary NBNS address is provided. + + A summary of the Secondary NBNS Address Configuration Option format + is shown below. The fields are transmitted from 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 | Secondary-NBNS-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Secondary-NBNS-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 132 + + Length + + 6 + + Secondary-NBNS-Address + + The four octet Secondary-NBNS-Address is the address of the + secondary NBNS server to be used by the local peer. If all + four octets are set to zero, it indicates an explicit request + that the peer provide the address information in a Config-Nak + packet. + + Default + + No address is provided. + + + + + + + + +Cobb Informational [Page 5] + +RFC 1877 PPP IPCP Extensions December 1995 + + +References + + [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, + RFC 1661, Daydreamer, July 1994. + + [2] McGregor, G., "PPP Internet Control Protocol", RFC 1332, Merit, + May 1992. + + [3] Auerbach, K., and A. Aggarwal, "Protocol Standard for a NetBIOS + Service on a TCP/UDP Transport", STD 19, RFCs 1001 and 1002, + March 1987. + + [4] Mockapetris, P., "Domain Names - Concepts and Facilities", STD + 13, RFC 1034, USC/Information Sciences Institute, November 1987. + + [5] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, USC/Information Sciences + Institute, November 1987. + +Security Considerations + + Security issues are not discussed in this memo. + +Chair's Address + + The working group can be contacted via the current chair: + + Fred Baker + Cisco Systems + 519 Lado Drive + Santa Barbara, California 93111 + + EMail: fred@cisco.com + +Author's Address + + Questions about this memo can also be directed to: + + Steve Cobb + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052-6399 + + Phone: (206) 882-8080 + + EMail: stevec@microsoft.com + + + + + +Cobb Informational [Page 6] + diff --git a/rfc/rfc1962.txt b/rfc/rfc1962.txt new file mode 100644 index 00000000..fc9b47d3 --- /dev/null +++ b/rfc/rfc1962.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group D. Rand +Request for Comments: 1962 Novell +Category: Standards Track June 1996 + + + The PPP Compression Control Protocol (CCP) + +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 compression over + PPP links. + +Table of Contents + + 1. Introduction .......................................... 1 + 2. Compression Control Protocol (CCP) .................... 2 + 2.1 Sending Compressed Datagrams .................... 3 + 3. Additional Packets .................................... 4 + 3.1 Reset-Request and Reset-Ack ..................... 4 + 4. CCP Configuration Options ............................. 5 + 4.1 Proprietary Compression OUI ..................... 7 + 4.2 Other Compression Types ......................... 8 + SECURITY CONSIDERATIONS ...................................... 9 + REFERENCES ................................................... 9 + ACKNOWLEDGEMENTS ............................................. 9 + CHAIR'S ADDRESS .............................................. 9 + AUTHOR'S ADDRESS ............................................. 9 + +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. + + + + + +Rand Standards Track [Page 1] + +RFC 1962 PPP Compression June 1996 + + + One such facility is data compression. A wide variety of compression + methods may be negotiated, although typically only one method is used + in each direction of the link. + + A different compression algorithm may be negotiated in each + direction, for speed, cost, memory or other considerations, or only + one direction may be compressed. + +2. Compression Control Protocol (CCP) + + The Compression Control Protocol (CCP) is responsible for + configuring, enabling, and disabling data compression algorithms on + both ends of the point-to-point link. It is also used to signal a + failure of the compression/decompression mechanism in a reliable + manner. + + CCP uses the same packet exchange mechanism as the Link Control + Protocol (LCP). CCP packets may not be exchanged until PPP has + reached the Network-Layer Protocol phase. CCP packets received + before this phase is reached should be silently discarded. + + The Compression Control Protocol is exactly the same as the Link + Control Protocol [1] with the following exceptions: + + Frame Modifications + + The packet may utilize any modifications to the basic frame format + which have been negotiated during the Link Establishment phase. + + Data Link Layer Protocol Field + + Exactly one CCP packet is encapsulated in the PPP Information + field, where the PPP Protocol field indicates type hex 80FD + (Compression Control Protocol). + + When individual link data compression is used in a multiple link + connection to a single destination, the PPP Protocol field + indicates type hex 80FB (Individual link Compression Control + Protocol). + + Code field + + In addition to Codes 1 through 7 (Configure-Request, Configure- + Ack, Configure-Nak, Configure-Reject, Terminate-Request, + Terminate-Ack and Code-Reject), two additional Codes 14 and 15 + (Reset-Request and Reset-Ack) are defined for this protocol. + Other Codes should be treated as unrecognized and should result in + Code-Rejects. + + + +Rand Standards Track [Page 2] + +RFC 1962 PPP Compression June 1996 + + + Timeouts + + CCP 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 timing out waiting for a Configure-Ack or other + response. It is suggested that an implementation give up only + after user intervention or a configurable amount of time. + + Configuration Option Types + + CCP has a distinct set of Configuration Options. + +2.1. Sending Compressed Datagrams + + Before any compressed packets may be communicated, PPP must reach the + Network-Layer Protocol phase, and the Compression Control Protocol + must reach the Opened state. + + One or more compressed packets are encapsulated in the PPP + Information field, where the PPP Protocol field indicates type hex + 00FD (Compressed datagram). Each of the compression algorithms may + use a different mechanism to indicate the inclusion of more than one + uncompressed packet in a single Data Link Layer frame. + + When using multiple PPP links to a single destination, there are two + methods of employing data compression. The first method is to + compress the data prior to sending it out through the multiple links. + The second is to treat each link as a separate connection, that may + or may not have compression enabled. In the second case, the PPP + Protocol field MUST be type hex 00FB (Individual link compressed + datagram). + + Only one primary algorithm in each direction is in use at a time, and + that is negotiated prior to sending the first compressed frame. The + PPP Protocol field of the compressed datagram indicates that the + frame is compressed, but not the algorithm with which it was + compressed. + + The maximum length of a compressed packet transmitted over a PPP link + is the same as the maximum length of the Information field of a PPP + encapsulated packet. Larger datagrams (presumably the result of the + compression algorithm increasing the size of the message in some + cases) may be sent uncompressed, using its standard form, or may be + sent in multiple datagrams, if the compression algorithm supports it. + + Each of the compression algorithms must supply a way of determining + if they are passing data reliably, or they must require the use of a + + + +Rand Standards Track [Page 3] + +RFC 1962 PPP Compression June 1996 + + + reliable transport such as LAPB [3]. Vendors are strongly encouraged + to employ a method of validating the compressed data, or recognizing + out-of-sync compressor/decompressor pairs. + +3. Additional Packets + + The Packet format and basic facilities are already defined for LCP + [1]. + + Up-to-date values of the CCP Code field are specified in the most + recent "Assigned Numbers" RFC [2]. This specification concerns the + following values: + + 14 Reset-Request + 15 Reset-Ack + +3.1. Reset-Request and Reset-Ack + + Description + + CCP includes Reset-Request and Reset-Ack Codes in order to provide + a mechanism for indicating a decompression failure in one + direction of a compressed link without affecting traffic in the + other direction. A decompression failure may be determined by + periodically passing a hash value, performing a CRC check on the + decompressed data, or other mechanism. It is strongly suggested + that some mechanism be available in all compression algorithms to + validate the decompressed data before passing the data on to the + rest of the system. + + A CCP implementation wishing to indicate a decompression failure + SHOULD transmit a CCP packet with the Code field set to 14 + (Reset-Request), and the Data field filled with any desired data. + Once a Reset-Request has been sent, any Compressed packets + received are discarded, and another Reset-Request is sent with the + same Identifier, until a valid Reset-Ack is received. + + Upon reception of a Reset-Request, the transmitting compressor is + reset to an initial state. This may include clearing a + dictionary, resetting hash codes, or other mechanisms. A CCP + packet MUST be transmitted with the Code field set to 15 (Reset- + Ack), the Identifier field copied from the Reset-Request packet, + and the Data field filled with any desired data. + + On receipt of a Reset-Ack, the receiving decompressor is reset to + an initial state. This may include clearing a dictionary, + resetting hash codes, or other mechanisms. Since there may be + several Reset-Acks in the pipe, the decompressor MUST be reset for + + + +Rand Standards Track [Page 4] + +RFC 1962 PPP Compression June 1996 + + + each Reset-Ack which matches the currently expected identifier. + + A summary of the Reset-Request and Reset-Ack packet formats is shown + below. The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + Code + + 14 for Reset-Request; + + 15 for Reset-Ack. + + Identifier + + On transmission, the Identifier field MUST be changed whenever the + content of the Data field changes, and whenever a valid reply has + been received for a previous request. For retransmissions, the + Identifier MAY remain unchanged. + + On reception, the Identifier field of the Reset-Request is copied + into the Identifier field of the Reset-Ack packet. + + Data + + The Data field is zero or more octets and contains uninterpreted + data for use by the sender. The data may consist of any binary + value and may be of any length from zero to the peer's established + MRU minus four. + +4. CCP Configuration Options + + CCP Configuration Options allow negotiation of compression algorithms + and their parameters. CCP uses the same Configuration Option format + defined for LCP [1], with a separate set of Options. + + Configuration Options, in this protocol, indicate algorithms that the + receiver is willing or able to use to decompress data sent by the + sender. As a result, it is to be expected that systems will offer to + accept several algorithms, and negotiate a single one that will be + used. + + + +Rand Standards Track [Page 5] + +RFC 1962 PPP Compression June 1996 + + + There is the possibility of not being able to agree on a compression + algorithm. In that case, no compression will be used, and the link + will continue to operate without compression. If link reliability + has been separately negotiated, then it will continue to be used, + until the LCP is re-negotiated. + + We expect that many vendors will want to use proprietary compression + algorithms, and have made a mechanism available to negotiate these + without encumbering the Internet Assigned Number Authority with + proprietary number requests. + + The LCP option negotiation techniques are used. If an option is + unrecognized, a Configure-Reject MUST be sent. If all protocols the + sender implements are Configure-Rejected by the receiver, then no + compression is enabled in that direction of the link. + + If an option is recognized, but not acceptable due to values in the + request (or optional parameters not in the request), a Configure-NAK + MUST be sent with the option modified appropriately. The Configure- + NAK MUST contain only those options that will be acceptable. A new + Configure-Request SHOULD be sent with only the single preferred + option, adjusted as specified in the Configure-Nak. + + Up-to-date values of the CCP Option Type field are specified in the + most recent "Assigned Numbers" RFC [2]. Current values are assigned + as follows: + + CCP Option Compression type + 0 OUI + 1 Predictor type 1 + 2 Predictor type 2 + 3 Puddle Jumper + 4-15 unassigned + 16 Hewlett-Packard PPC + 17 Stac Electronics LZS + 18 Microsoft PPC + 19 Gandalf FZA + 20 V.42bis compression + 21 BSD LZW Compress + 255 Reserved + + The unassigned values 4-15 are intended to be assigned to other + freely available compression algorithms that have no license fees. + + + + + + + + +Rand Standards Track [Page 6] + +RFC 1962 PPP Compression June 1996 + + +4.1. Proprietary Compression OUI + + Description + + This Configuration Option provides a way to negotiate the use of a + proprietary compression protocol. + + Since the first matching compression will be used, it is + recommended that any known OUI compression options be transmitted + first, before the common options are used. + + Before accepting this option, the implementation must verify that + the Organization Unique Identifier identifies a proprietary + algorithm that the implementation can decompress, and that any + vendor specific negotiation values are fully understood. + + A summary of the Proprietary Compression OUI Configuration Option + format is shown below. The fields are transmitted from 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 + + 0 + + Length + + >= 6 + + IEEE OUI + + The vendor's IEEE Organization Unique Identifier (OUI), which is + the most significant three octets of an Ethernet Physical Address, + assigned to the vendor by IEEE 802. This identifies the option as + being proprietary to the indicated vendor. The bits within the + octet are in canonical order, and the most significant octet is + transmitted first. + + + + + + +Rand Standards Track [Page 7] + +RFC 1962 PPP Compression June 1996 + + + Subtype + + This field is specific to each OUI, and indicates a compression + type for that OUI. There is no standardization for this field. + Each OUI implements its own values. + + Values + + This field is zero or more octets, and contains additional data as + determined by the vendor's compression protocol. + +4.2. Other Compression Types + + Description + + These Configuration Options provide a way to negotiate the use of + a publicly defined compression algorithm. Many compression + algorithms are specified. No particular compression technique has + arisen as an Internet Standard. + + These protocols will be made available to all interested parties, + but may have certain licensing restrictions associated with them. + For additional information, refer to the compression protocol + documents that define each of the compression types. + + A summary of the Compression Type Configuration Option format is + shown below. The fields are transmitted from 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 + + 1 to 254 + + Length + + >= 2 + + Values + + This field is zero or more octets, and contains additional data as + determined by the compression protocol. + + + +Rand Standards Track [Page 8] + +RFC 1962 PPP Compression June 1996 + + +Security Considerations + + Security issues are not discussed in this memo. + +References + + [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + [2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC + 1700, USC/Information Sciences Institute, October 1994. + + [3] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994. + +Acknowledgments + + Bill Simpson helped with the document formatting. + +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 + + Questions about this memo can also be directed to: + + Dave Rand + Novell, Inc. + 2180 Fortune Drive + San Jose, CA 95131 + + +1 408 321-1259 + + EMail: dlr@daver.bungi.com + + + + + + + + + + +Rand Standards Track [Page 9] + diff --git a/rfc/rfc1979.txt b/rfc/rfc1979.txt new file mode 100644 index 00000000..7a95cd3b --- /dev/null +++ b/rfc/rfc1979.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group J. Woods +Request for Comments: 1979 Proteon, Inc. +Category: Informational August 1996 + + + PPP Deflate Protocol + +Status of This Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. 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. + + The PPP Compression Control Protocol [2] provides a method to + negotiate and utilize compression protocols over PPP encapsulated + links. + + This document describes the use of the PPP Deflate compression + protocol for compressing PPP encapsulated packets. + +Table of Contents + + 1. Introduction ...................................... 2 + 1.1 Licensing ................................... 2 + 2. PPP Deflate Packets ............................... 3 + 2.1 Packet Format ............................... 6 + 3. Configuration Option Format ....................... 8 + SECURITY CONSIDERATIONS .................................. 9 + REFERENCES ............................................... 9 + ACKNOWLEDGEMENTS ......................................... 9 + CHAIR'S ADDRESS .......................................... 10 + AUTHOR'S ADDRESS ......................................... 10 + + + + + + + + + + + + + + +Woods Informational [Page 1] + +RFC 1979 PPP Deflate August 1996 + + +1. Introduction + +The 'deflate' compression format[3], as used by the PKZIP and gzip +compressors and as embodied in the freely and widely distributed +zlib[4] library source code, has the following features: + + - an apparently unencumbered encoding and compression + algorithm, with an open and publically-available + specification. + + - low-overhead escape mechanism for incompressible data. The + PPP Deflate specification offers options to reduce that + overhead further. + + - heavily used for many years in networks, on modem and other + point-to-point links to transfer files for personal computers + and workstations. + + - easily achieves 2:1 compression on the Calgary corpus[5] + using less than 64KBytes of memory on both sender and + receive. + +1.1. Licensing + + The zlib source is widely and freely available, subject to the + following copyright: + + (C) 1995 Jean-Loup Gailly and Mark Adler + + This software is provided 'as-is', without any express or implied + warranty. In no event will the authors be held liable for any + damages arising from the use of this software. + + Permission is granted to anyone to use this software for any + purpose, including commercial applications, and to alter it and + redistribute it freely, subject to the following restrictions: + + 1. The origin of this software must not be misrepresented; you + must not claim that you wrote the original software. If you + use this software in a product, an acknowledgment in the + product documentation would be appreciated but is not + required. + + 2. Altered source versions must be plainly marked as such, and + must not be misrepresented as being the original software. + + + + + + +Woods Informational [Page 2] + +RFC 1979 PPP Deflate August 1996 + + + 3. This notice may not be removed or altered from any source + distribution. + + Jean-Loup Gailly Mark Adler + gzip@prep.ai.mit.edu madler@alumni.caltech.edu + + If you use the zlib library in a product, we would appreciate + *not* receiving lengthy legal documents to sign. The sources are + provided for free but without warranty of any kind. The library + has been entirely written by Jean-Loup Gailly and Mark Adler; it + does not include third-party code. + + The deflate format and compression algorithm are based on Lempel-Ziv + LZ77 compression; extensive research has been done by the GNU Project + and the Portable Network Graphics working group supporting its patent + free status. + +2. PPP Deflate Packets + + Before any PPP Deflate packets may be communicated, PPP must reach + the Network-Layer Protocol phase, and the CCP Control Protocol must + reach the Opened state. + + Exactly one PPP Deflate datagram is encapsulated in the PPP + Information field, where the PPP Protocol field contains 0xFD or + 0xFB. 0xFD is used when the PPP multilink protocol is not used or + "above" multilink. 0xFB is used "below" multilink, to compress + independently on individual links of a multilink bundle. + + The maximum length of the PPP Deflate datagram transmitted over a PPP + link is the same as the maximum length of the Information field of a + PPP encapsulated packet. + + Only packets with PPP Protocol numbers in the range 0x0000 to 0x3FFF + and neither 0xFD nor 0xFB are compressed. Other PPP packets are + always sent uncompressed. Control packets are infrequent and should + not be compressed for robustness. + + Padding + + PPP Deflate packets require the previous negotiation of the Self- + Describing-Padding Configuration Option [6] if padding is added to + packets. If no padding is added, than Self-Describing-Padding is + not required. + + + + + + + +Woods Informational [Page 3] + +RFC 1979 PPP Deflate August 1996 + + + Reliability and Sequencing + + PPP Deflate requires the packets to be delivered in sequence. It + relies on Reset-Request and Reset-Ack LCP packets or on + renegotiation of the Compression Control Protocol [2] to indicate + loss of synchronization between the transmitter and receiver. The + LCP FCS detects corrupted packets and the normal mechanisms + discard them. Missing or out of order packets are detected by the + sequence number in each packet. The packet sequence number ought + to be checked before decoding the packet. + + Instead of transmitting a Reset-Request packet when detecting a + sequence error, the receiver MAY momentarily force CCP to drop out + of the Opened state by transmitting a new CCP Configure-Request. + This method is more expensive than using Reset-Requests. + + When the receiver first encounters an unexpected sequence number + it SHOULD send a Reset-Request LCP packet as defined in the + Compression Control Protocol. When the transmitter sends the + Reset-Ack or when the receiver receives a Reset-ACK, they must + reset the sequence number to zero, clear the compression + dictionary, and resume sending and receiving compressed packets. + The receiver MUST discard all compressed packets after detecting + an error and until it receives a Reset-Ack. This strategy can be + thought of as abandoning the transmission of one "file" and + starting the transmission of a new "file." + + The transmitter must clear its compression history and respond + with a Reset-Ack each time it receives a Reset-Request, because it + cannot know if previous Reset-Acks reached the receiver. The + receiver need not do anything to its history when it receives a + Reset-Ack, because the transmitter will simply not refer to any + prior history ('deflate' is a sliding-window compressor). + + When the link is busy, one decompression error is usually followed + by several more before the Reset-Ack can be received. It is + undesirable to transmit Reset-Requests more frequently than the + round-trip-time of the link, because redundant Reset-Requests + cause unnecessary compression dictionary clearing. The receiver + MAY transmit an additional Reset-Request each time it receives a + compressed or uncompressed packet until it finally receives a + Reset-Ack, but the receiver ought not transmit another Reset- + Request until the Reset-Ack for the previous one is late. The + receiver MUST transmit enough Reset-Request packets to ensure that + the transmitter receives at least one. For example, the receiver + might choose to not transmit another Reset-Request until after one + second (or, of course, a Reset-Ack has been received and + decompression resumed). + + + +Woods Informational [Page 4] + +RFC 1979 PPP Deflate August 1996 + + + Data Expansion + + 'Deflate', as used in this standard, expands incompressible data + by approximately 14-18 bytes (8 bytes worst-case at the 'deflate' + level, two further bytes for the 'deflate' end-of-block and the + zero-length synchronization block header, two bytes of sequence + number, and two bytes to account for adding the PPP Protocol Field + to the transmitted data unit). + + The BSD Compress draft proposal[7] describes an escape mechanism + for incompressible data that trades off a layering violation for + the irritating complications of variable and potentially + unpredictable effective MRU lengths. That direct escape mechanism + (and much of the text of its description) is used here as well. + + If an incompressible data packet does not fit within the MRU of + the link, the packet MUST be sent in its original form without CCP + encapsulation; PPP packets with significant data expansion that do + not exceed the MRU of the link SHOULD be sent in their original + form without CCP encapsulation. In both of these cases, the + transmitter must increment the sequence number, as future + encapsulated packets will depend on the correct reception of some + number of unencapsulated packets. + + When a PPP packet is received with PPP Protocol numbers in the + range 0x0000 to 0x3FFF, (except, of course, 0xFD and 0xFB) it is + assumed that the packet would have caused expansion. The packet + is locally added to the compression history. (Given the + definition of the 'deflate' format, a convenient method of doing + this is to locally "decompress" a stored-block header of the + appropriate length, followed by the actual data block; or the data + can simply be appended to the receiver's history, depending on + implementation details.) + + Sending incompressible packets in their native encapsulation + avoids maximum transmission unit complications. If uncompressed + packets could be larger than their native form, then it would be + necessary for the upper layers of an implementation to treat the + PPP link as if it had a smaller MTU, to ensure that compressed + incompressible packets are never larger than the negotiated PPP + MTU. + + Using native encapsulation for incompressible packets complicates + the implementation. The transmitter and the receiver must start + putting information into the compression dictionary starting with + the same packets, without relying upon seeing a compressed packet + for synchronization. The first few packets after clearing the + dictionary are usually incompressible, and so are likely to sent + + + +Woods Informational [Page 5] + +RFC 1979 PPP Deflate August 1996 + + + in their native encapsulation, just like packets before + compression is turned on. If CCP or LCP packets are handled + separately from Network-Layer packets (e.g. a "daemon" for control + packets and "kernel code" for data packets), care must be taken to + ensure that the transmitter synchronizes clearing the dictionary + with the transmission of the configure-ACK or Reset-Ack that + starts compression, and the receiver must similarly ensure that + its dictionary is cleared before it processes the next packet. + +2.1. Packet Format + + A summary of the PPP Deflate packet format is shown below. + + The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PPP Protocol | Sequence | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+-+-+-+-+ + + + PPP Protocol + + The PPP Protocol field is described in the Point-to-Point Protocol + Encapsulation [1]. + + When the PPP Deflate compression protocol is successfully + negotiated by the PPP Compression Control Protocol [2], the value + of the protocol field is 0xFD or 0xFB. This value MAY be + compressed when Protocol-Field-Compression is negotiated. + + Sequence + + The sequence number is sent most significant octet first. It + starts at 0 when the dictionary is cleared, and is incremented by + 1 for each packet, including uncompressed packets. The sequence + number after 65535 is zero. In other words, the sequence number + "wraps" in the usual way. + + The sequence number ensures that lost or out of order packets do + not cause the compression databases of the peers to become + unsynchronized. When an unexpected sequence number is + encountered, the dictionaries must be resynchronized with a CCP + Reset-Request or Configure-Request. The packet sequence number + can be checked before a compressed packet is decoded. + + + +Woods Informational [Page 6] + +RFC 1979 PPP Deflate August 1996 + + + Data + + The compressed PPP encapsulated packet, consisting of the Protocol + and Data fields of the original, uncompressed packet follows. + + The Protocol field compression MUST be applied to the protocol + field in the original packet before the sequence number is + computed or the entire packet is compressed, regardless of whether + the PPP protocol field compression has been negotiated. Thus, if + the original protocol number was less than 0x100, it must be + compressed to a single byte. + + The basic format of the compressed data is precisely described by + the 'Deflate' Compressed Data Format Specification[3]. Each + transmitted packet must begin at a 'deflate' block boundary, to + ensure synchronization when incompressible data resets the + transmitter's state; to ensure this, each transmitted packet must + be terminated with a zero-length 'deflate' non-compressed block + (BTYPE of 00). This means that the last four bytes of the + compressed format must be 0x00 0x00 0xFF 0xFF. These bytes MUST + be removed before transmission; the receiver can reinsert them if + required by the implementation. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woods Informational [Page 7] + +RFC 1979 PPP Deflate August 1996 + + +3. Configuration Option Format + + + Description + + The CCP PPP Deflate Configuration Option negotiates the use of PPP + Deflate on the link. By default or ultimate disagreement, no + compression is used. + + A summary of the PPP Deflate Configuration Option format is shown + below. The fields are transmitted from 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 |Window | Method| MBZ |Chk| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 26 for PPP Deflate. + + Length + + 3 + + Window + + Represents the maximum window size the decompressor is willing to + allocate; expressed as the base-2 logarithm of the LZ77 window + size, minus 8. 'Deflate' compliant decompressors must be willing + to accept the maximum 32KB window size, represented by a value of + 7. A 'deflate' compliant compressor is at liberty to use a + reduced window size, so a PPP Deflate compressor MUST either honor + the restriction requested or reject the option. + + Method + + Must be the binary number 1000. Represents the 'zlib' Compression + Method identifier of '8' for 'deflate' compression with up to 32K + window size. + + MBZ + + Must be all 0 bits. + + + + + +Woods Informational [Page 8] + +RFC 1979 PPP Deflate August 1996 + + + Chk + + Must be 00 to specify sequence number check method. + +Security Considerations + + Security issues are not discussed in this memo. + +References + + [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, + RFC 1661, July 1994. + + [2] Rand, D., "The PPP Compression Control Protocol (CCP)", + RFC 1962, June 1996. + + [3] Deutsch, L.P., "'Deflate' Compressed Data Format + Specification", draft available in + ftp.uu.net:/pub/archiving/zip/doc/deflate-1.1.doc. + + [4] Gailly, J.-L., "Zlib 0.95 beta". + + [5] Bell, T.C., Cleary, G. G. and Witten, I.H., "Text Compression", + Prentice_Hall, Englewood Cliffs NJ, 1990. The compression + corpus itself can be found in ftp.uu.net:/pub/archiving/zip/. + + [6] Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994. + + [7] Schryver, V., "PPP BSD Compression Protocol", RFC 1977, + August 1996. + +Acknowledgments + + William Simpson provided the very valuable idea of not using any + additional header bytes for incompressible packets. + + + + + + + + + + + + + + + + +Woods Informational [Page 9] + +RFC 1979 PPP Deflate August 1996 + + +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 + + Questions about this memo can also be directed to: + + John Woods + Proteon, Inc. + 9 Technology Drive + Westborough MA 01581-1799 + + (508) 898-2800 ext. 2651 + EMail: jfw@funhouse.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woods Informational [Page 10] + diff --git a/rfc/rfc1990.txt b/rfc/rfc1990.txt new file mode 100644 index 00000000..a4f7ffef --- /dev/null +++ b/rfc/rfc1990.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group K. Sklower +Request for Comments: 1990 University of California, Berkeley +Obsoletes: 1717 B. Lloyd +Category: Standards Track G. McGregor + Lloyd Internetworking + D. Carr + Newbridge Networks Corporation + T. Coradetti + Sidewalk Software + August 1996 + + + The PPP Multilink Protocol (MP) + + +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 + + This document proposes a method for splitting, recombining and + sequencing datagrams across multiple logical data links. This work + was originally motivated by the desire to exploit multiple bearer + channels in ISDN, but is equally applicable to any situation in which + multiple PPP links connect two systems, including async links. This + is accomplished by means of new PPP [2] options and protocols. + + The differences between the current PPP Multilink specification (RFC + 1717) and this memo are explained in Section 11. Any system + implementing the additional restrictions required by this memo will + be backwards compatible with conforming RFC 1717 implementations. + +Acknowledgements + + The authors specifically wish to thank Fred Baker of ACC, Craig Fox + of Network Systems, Gerry Meyer of Spider Systems, Dan Brennan of + Penril Datability Networks, Vernon Schryver of SGI (for the + comprehensive discussion of padding), and the members of the IP over + Large Public Data Networks and PPP Extensions working groups, for + much useful discussion on the subject. + + + + + + +Sklower, et. al. Standards Track [Page 1] + +RFC 1990 PPP Multilink August 1996 + + +Table of Contents + + 1. Introduction ................................................ 2 + 1.1. Motivation ................................................ 2 + 1.2. Functional Description .................................... 3 + 1.3. Conventions ............................................... 4 + 2. General Overview ............................................ 4 + 3. Packet Formats .............................................. 7 + 3.1. Padding Considerations .................................... 10 + 4. Trading Buffer Space Against Fragment Loss .................. 10 + 4.1. Detecting Fragment Loss ................................... 11 + 4.2. Buffer Space Requirements ................................. 12 + 5. PPP Link Control Protocol Extensions ........................ 13 + 5.1. Configuration Option Types ................................ 13 + 5.1.1. Multilink MRRU LCP option ............................... 14 + 5.1.2. Short Sequence Number Header Format Option .............. 15 + 5.1.3. Endpoint Discriminator Option ........................... 15 + 6. Initiating use of Multilink Headers ......................... 19 + 7. Closing Member links ........................................ 20 + 8. Interaction with Other Protocols ............................ 20 + 9. Security Considerations ..................................... 21 + 10. References ................................................. 21 + 11. Differences from RFC 1717 .................................. 22 + 11.1. Negotiating Multilink, per se ............................ 22 + 11.2. Initial Sequence Number defined .......................... 22 + 11.3. Default Value of the MRRU ................................ 22 + 11.4. Config-Nak of EID prohibited ............................. 22 + 11.5. Uniformity of Sequence Space ............................. 22 + 11.6. Commencing and Abating use of Multilink Headers .......... 23 + 11.7. Manual Configuration and Bundle Assignment ............... 23 + 12. Authors' Addresses ......................................... 24 + +1. Introduction + +1.1. Motivation + + Basic Rate and Primary Rate ISDN both offer the possibility of + opening multiple simultaneous channels between systems, giving users + additional bandwidth on demand (for additional cost). Previous + proposals for the transmission of internet protocols over ISDN have + stated as a goal the ability to make use of this capability, (e.g., + Leifer et al., [1]). + + There are proposals being advanced for providing synchronization + between multiple streams at the bit level (the BONDING proposals); + such features are not as yet widely deployed, and may require + additional hardware for end system. Thus, it may be useful to have a + purely software solution, or at least an interim measure. + + + +Sklower, et. al. Standards Track [Page 2] + +RFC 1990 PPP Multilink August 1996 + + + There are other instances where bandwidth on demand can be exploited, + such as using a dialup async line at 28,800 baud to back up a leased + synchronous line, or opening additional X.25 SVCs where the window + size is limited to two by international agreement. + + The simplest possible algorithms of alternating packets between + channels on a space available basis (which might be called the Bank + Teller's algorithm) may have undesirable side effects due to + reordering of packets. + + By means of a four-byte sequencing header, and simple synchronization + rules, one can split packets among parallel virtual circuits between + systems in such a way that packets do not become reordered, or at + least the likelihood of this is greatly reduced. + +1.2. Functional Description + + The method discussed here is similar to the multilink protocol + described in ISO 7776 [4], but offers the additional ability to split + and recombine packets, thereby reducing latency, and potentially + increase the effective maximum receive unit (MRU). Furthermore, + there is no requirement here for acknowledged-mode operation on the + link layer, although that is optionally permitted. + + Multilink is based on an LCP option negotiation that permits a system + to indicate to its peer that it is capable of combining multiple + physical links into a "bundle". Only under exceptional conditions + would a given pair of systems require the operation of more than one + bundle connecting them. + + Multilink is negotiated during the initial LCP option negotiation. A + system indicates to its peer that it is willing to do multilink by + sending the multilink option as part of the initial LCP option + negotiation. This negotiation indicates three things: + + 1. The system offering the option is capable of combining multiple + physical links into one logical link; + + 2. The system is capable of receiving upper layer protocol data + units (PDU) fragmented using the multilink header (described + later) and reassembling the fragments back into the original PDU + for processing; + + 3. The system is capable of receiving PDUs of size N octets where N + is specified as part of the option even if N is larger than the + maximum receive unit (MRU) for a single physical link. + + + + + +Sklower, et. al. Standards Track [Page 3] + +RFC 1990 PPP Multilink August 1996 + + + Once multilink has been successfully negotiated, the sending system + is free to send PDUs encapsulated and/or fragmented with the + multilink header. + +1.3. Conventions + + The following language conventions are used in the items of + specification in this document: + + o MUST, SHALL or MANDATORY -- the item is an absolute requirement + of the specification. + + o SHOULD or RECOMMENDED -- the item should generally be followed + for all but exceptional circumstances. + + o MAY or OPTIONAL -- the item is truly optional and may be + followed or ignored according to the needs of the implementor. + +2. General Overview + + In order to establish communications over a point-to-point link, each + end of the PPP link must first send LCP packets to configure the data + link during Link Establishment phase. After the link has been + established, PPP provides for an Authentication phase in which the + authentication protocols can be used to determine identifiers + associated with each system connected by the link. + + The goal of multilink operation is to coordinate multiple independent + links between a fixed pair of systems, providing a virtual link with + greater bandwidth than any of the constituent members. The aggregate + link, or bundle, is named by the pair of identifiers for two systems + connected by the multiple links. A system identifier may include + information provided by PPP Authentication [3] and information + provided by LCP negotiation. The bundled links can be different + physical links, as in multiple async lines, but may also be instances + of multiplexed links, such as ISDN, X.25 or Frame Relay. The links + may also be of different kinds, such as pairing dialup async links + with leased synchronous links. + + We suggest that multilink operation can be modeled as a virtual PPP + link-layer entity wherein packets received over different physical + link-layer entities are identified as belonging to a separate PPP + network protocol (the Multilink Protocol, or MP) and recombined and + sequenced according to information present in a multilink + fragmentation header. All packets received over links identified as + belonging to the multilink arrangement are presented to the same + network-layer protocol processing machine, whether they have + multilink headers or not. + + + +Sklower, et. al. Standards Track [Page 4] + +RFC 1990 PPP Multilink August 1996 + + + The packets to be transmitted using the multilink procedure are + encapsulated according to the rules for PPP where the following + options would have been manually configured: + + o No async control character Map + o No Magic Number + o No Link Quality Monitoring + o Address and Control Field Compression + o Protocol Field Compression + o No Compound Frames + o No Self-Describing-Padding + + According to the rules specified in RFC1661, this means that an + implementation MUST accept reassembled packets with and without + leading zeroes present in the Protocol Field of the reassembled + packet. Although it is explicitly forbidden below to include the + Address and Control fields (usually, the two bytes FF 03) in the + material to be fragmented, it is a good defensive programming + practice to accept the packet anyway, ignoring the two bytes if + present, as that is what RFC1661 specifies. + + As a courtesy to implementations that perform better when certain + alignment obtains, it is suggested that a determination be made when + a bundle is created on whether to transmit leading zeroes by + examining whether PFC has been negotiated on the first link admitted + into a bundle. This determination should be kept in force so long as + a bundle persists. + + Of course, individual links are permitted to have different settings + for these options. As described below, member links SHOULD negotiate + Self-Describing-Padding, even though pre-fragmented packets MUST NOT + be padded. Since the Protocol Field Compression mode on the member + link allows a sending system to include a leading byte of zero or not + at its discretion, this is an alternative mechanism for generating + even-length packets. + + LCP negotiations are not permitted on the bundle itself. An + implementation MUST NOT transmit LCP Configure-Request, -Reject, + -Ack, -Nak, Terminate-Request or -Ack packets via the multilink + procedure, and an implementation receiving them MUST silently discard + them. (By "silently discard" we mean to not generate any PPP packets + in response; an implementation is free to generate a log entry + registering the reception of the unexpected packet). By contrast, + other LCP packets having control functions not associated with + changing the defaults for the bundle itself are permitted. An + implementation MAY transmit LCP Code-Reject, Protocol-Reject, Echo- + Request, Echo-Reply and Discard-Request Packets. + + + + +Sklower, et. al. Standards Track [Page 5] + +RFC 1990 PPP Multilink August 1996 + + + The effective MRU for the logical-link entity is negotiated via an + LCP option. It is irrelevant whether Network Control Protocol + packets are encapsulated in multilink headers or not, or even over + which link they are sent, once that link identifies itself as + belonging to a multilink arrangement. + + Note that network protocols that are not sent using multilink headers + cannot be sequenced. (And consequently will be delivered in any + convenient way). + + For example, consider the case in Figure 1. Link 1 has negotiated + network layers NL 1, NL 2, and MP between two systems. The two + systems then negotiate MP over Link 2. + + Frames received on link 1 are demultiplexed at the data link layer + according the PPP network protocol identifier and can be sent to NL + 1, NL 2, or MP. Link 2 will accept frames with all network protocol + identifiers that Link 1 does. + + Frames received by MP are further demultiplexed at the network layer + according to the PPP network protocol identifier and sent to NL 1 or + NL 2. Any frames received by MP for any other network layer + protocols are rejected using the normal protocol reject mechanism. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sklower, et. al. Standards Track [Page 6] + +RFC 1990 PPP Multilink August 1996 + + + Figure 1. Multilink Overview. + + Network Layer + ------------- + ______ ______ + / \ / \ + | NL 1 | | NL 2 | + \______/ \______/ + | | | | | | + | | +-------------o-o-o-+ + | +------+ +-----+ | | | + | | | | | | + | +------o--o-------+ + | + | | |__|_ | | + | | / \ | | + | | | MLCP | <--- Link Layer + | | \______/ Demultiplexing + | | | | | + | | | | | + | | | <--- Virtual Link + | | | | | + | | | | | + | | | | | + | | + | | + ___|_| | ___|_| + / \ | / \ + | LCP |------+-----| LCP | <--- Link Layer + \______/ \______/ Demultiplexing + | | + | | + Link 1 Link 2 + +3. Packet Formats + + In this section we describe the layout of individual fragments, which + are the "packets" in the Multilink Protocol. Network Protocol + packets are first encapsulated (but not framed) according to normal + PPP procedures, and large packets are broken up into multiple + segments sized appropriately for the multiple physical links. + Although it would otherwise be permitted by the PPP spec, + implementations MUST NOT include the Address and Control Field in the + logical entity to be fragmented. A new PPP header consisting of the + Multilink Protocol Identifier, and the Multilink header is inserted + before each section. (Thus the first fragment of a multilink packet + in PPP will have two headers, one for the fragment, followed by the + header for the packet itself). + + + + + +Sklower, et. al. Standards Track [Page 7] + +RFC 1990 PPP Multilink August 1996 + + + Systems implementing the multilink procedure are not required to + fragment small packets. There is also no requirement that the + segments be of equal sizes, or that packets must be broken up at all. + A possible strategy for contending with member links of differing + transmission rates would be to divide the packets into segments + proportion to the transmission rates. Another strategy might be to + divide them into many equal fragments and distribute multiple + fragments per link, the numbers being proportional to the relative + speeds of the links. + + PPP multilink fragments are encapsulated using the protocol + identifier 0x00-0x3d. Following the protocol identifier is a four + byte header containing a sequence number, and two one bit fields + indicating that the fragment begins a packet or terminates a packet. + After negotiation of an additional PPP LCP option, the four byte + header may be optionally replaced by a two byte header with only a 12 + bit sequence space. Address & Control and Protocol ID compression + are assumed to be in effect. Individual fragments will, therefore, + have the following format: + + Figure 2: Long Sequence Number Fragment Format. + + + +---------------+---------------+ + PPP Header: | Address 0xff | Control 0x03 | + +---------------+---------------+ + | PID(H) 0x00 | PID(L) 0x3d | + +-+-+-+-+-+-+-+-+---------------+ + MP Header: |B|E|0|0|0|0|0|0|sequence number| + +-+-+-+-+-+-+-+-+---------------+ + | sequence number (L) | + +---------------+---------------+ + | fragment data | + | . | + | . | + | . | + +---------------+---------------+ + PPP FCS: | FCS | + +---------------+---------------+ + + + + + + + + + + + + +Sklower, et. al. Standards Track [Page 8] + +RFC 1990 PPP Multilink August 1996 + + + Figure 3: Short Sequence Number Fragment Format. + + + +---------------+---------------+ + PPP Header: | Address 0xff | Control 0x03 | + +---------------+---------------+ + | PID(H) 0x00 | PID(L) 0x3d | + +-+-+-+-+-------+---------------+ + MP Header: |B|E|0|0| sequence number | + +-+-+-+-+-------+---------------+ + | fragment data | + | . | + | . | + | . | + +---------------+---------------+ + PPP FCS: | FCS | + +---------------+---------------+ + + The (B)eginning fragment bit is a one bit field set to 1 on the first + fragment derived from a PPP packet and set to 0 for all other + fragments from the same PPP packet. + + The (E)nding fragment bit is a one bit field set to 1 on the last + fragment and set to 0 for all other fragments. A fragment may have + both the (B)eginning and (E)nding fragment bits set to 1. + + The sequence field is a 24 bit or 12 bit number that is incremented + for every fragment transmitted. By default, the sequence field is 24 + bits long, but can be negotiated to be only 12 bits with an LCP + configuration option described below. + + Between the (E)nding fragment bit and the sequence number is a + reserved field, whose use is not currently defined, which MUST be set + to zero. It is 2 bits long when the use of short sequence numbers + has been negotiated, 6 bits otherwise. + + In this multilink protocol, a single reassembly structure is + associated with the bundle. The multilink headers are interpreted in + the context of this structure. + + The FCS field shown in the diagram is inherited from the normal + framing mechanism from the member link on which the packet is + transmitted. There is no separate FCS applied to the reconstituted + packet as a whole if transmitted in more than one fragment. + + + + + + + +Sklower, et. al. Standards Track [Page 9] + +RFC 1990 PPP Multilink August 1996 + + +3.1. Padding Considerations + + Systems that support the multilink protocol SHOULD implement Self- + Describing-Padding. A system that implements self-describing-padding + by definition will either include the padding option in its initial + LCP Configure-Requests, or (to avoid the delay of a Configure-Reject) + include the padding option after receiving a NAK containing the + option. + + A system that must pad its own transmissions but does not use Self- + Describing-Padding when not using multilink, MAY continue to not use + Self-Describing-Padding if it ensures by careful choice of fragment + lengths that only (E)nding fragments of packets are padded. A system + MUST NOT add padding to any packet that cannot be recognized as + padded by the peer. Non-terminal fragments MUST NOT be padded with + trailing material by any other method than Self-Describing-Padding. + + A system MUST ensure that Self-Describing-Padding as described in RFC + 1570 [11] is negotiated on the individual link before transmitting + any multilink data packets if it might pad non-terminal fragments or + if it would use network or compression protocols that are vulnerable + to padding, as described in RFC 1570. If necessary, the system that + adds padding MUST use LCP Configure-NAK's to elicit a Configure- + Request for Self-Describing-Padding from the peer. + + Note that LCP Configure-Requests can be sent at any time on any link, + and that the peer will always respond with a Configure-Request of its + own. A system that pads its transmissions but uses no protocols + other than multilink that are vulnerable to padding MAY delay + ensuring that the peer has Configure-Requested Self-Describing- + Padding until it seems desireable to negotiate the use of Multilink + itself. This permits the interoperability of a system that pads with + older peers that support neither Multilink nor Self-Describing- + Padding. + +4. Trading Buffer Space Against Fragment Loss + + In a multilink procedure one channel may be delayed with respect to + the other channels in the bundle. This can lead to fragments being + received out of order, thus increasing the difficulty in detecting + the loss of a fragment. The task of estimating the amount of space + required for buffering on the receiver becomes more complex because + of this. In this section we discuss a technique for declaring that a + fragment is lost, with the intent of minimizing the buffer space + required, yet minimizing the number of avoidable packet losses. + + + + + + +Sklower, et. al. Standards Track [Page 10] + +RFC 1990 PPP Multilink August 1996 + + +4.1. Detecting Fragment Loss + + On each member link in a bundle, the sender MUST transmit fragments + with strictly increasing sequence numbers (modulo the size of the + sequence space). This requirement supports a strategy for the + receiver to detect lost fragments based on comparing sequence + numbers. The sequence number is not reset upon each new PPP packet, + and a sequence number is consumed even for those fragments which + contain an entire PPP packet, i.e., one in which both the (B)eginning + and (E)nding bits are set. + + An implementation MUST set the sequence number of the first fragment + transmited on a newly-constructed bundle to zero. (Joining a + secondary link to an exisiting bundle is invisible to the protocol, + and an implementation MUST NOT reset the sequence number space in + this situation). + + The receiver keeps track of the incoming sequence numbers on each + link in a bundle and maintains the current minimum of the most + recently received sequence number over all the member links in the + bundle (call this M). The receiver detects the end of a packet when + it receives a fragment bearing the (E)nding bit. Reassembly of the + packet is complete if all sequence numbers up to that fragment have + been received. + + A lost fragment is detected when M advances past the sequence number + of a fragment bearing an (E)nding bit of a packet which has not been + completely reassembled (i.e., not all the sequence numbers between + the fragment bearing the (B)eginning bit and the fragment bearing the + (E)nding bit have been received). This is because of the increasing + sequence number rule over the bundle. Any sequence number so + detected is assumed to correspond to a fragment which has been lost. + + An implementation MUST assume that if a fragment bears a (B)eginning + bit, that the previously numbered fragment bore an (E)nding bit. + Thus if a packet is lost bearing the (E)nding bit, and the packet + whose fragment number is M contains a (B)eginning bit, the + implementation MUST discard fragments for all unassembled packets + through M-1, but SHOULD NOT discard the fragment bearing the new + (B)eginning bit on this basis alone. + + The detection of a lost fragment, whose sequence number was deduced + to be U, causes the receiver to discard all fragments up to the + lowest numbered fragment with an ending bit (possibly deduced) + greater than or equal to U. However, the quantity M may jump into + the middle of a chain of packets which can be successful completed. + + + + + +Sklower, et. al. Standards Track [Page 11] + +RFC 1990 PPP Multilink August 1996 + + + Fragments may be lost due to corruption of individual packets or + catastrophic loss of the link (which may occur only in one + direction). This version of the multilink protocol mandates no + specific procedures for the detection of failed links. The PPP link + quality management facility, or the periodic issuance of LCP echo- + requests could be used to achieve this. + + Senders SHOULD avoid keeping any member links idle to maximize early + detection of lost fragments by the receiver, since the value of M is + not incremented on idle links. Senders SHOULD rotate traffic among + the member links if there isn't sufficient traffic to overflow the + capacity of one link to avoid idle links. + + Loss of the final fragment of a transmission can cause the receiver + to stall until new packets arrive. The likelihood of this may be + decreased by sending a null fragment on each member link in a bundle + that would otherwise become idle immediately after having transmitted + a fragment bearing the (E)nding bit, where a null fragment is one + consisting only of a multilink header bearing both the (B)egin and + (E)nding bits (i.e., having no payload). Implementations concerned + about either wasting bandwidth or per packet costs are not required + to send null fragments and may elect to defer sending them until a + timer expires, with the marginally increased possibility of lengthier + stalls in the receiver. The receiver SHOULD implement some type of + link idle timer to guard against indefinite stalls. + + The increasing sequence per link rule prohibits the reallocation of + fragments queued up behind a failing link to a working one, a + practice which is not unusual for implementations of ISO multilink + over LAPB [4]. + +4.2. Buffer Space Requirements + + There is no amount of buffering that will guarantee correct detection + of fragment loss, since an adversarial peer may withhold a fragment + on one channel and send arbitrary amounts on the others. For the + usual case where all channels are transmitting, you can show that + there is a minimum amount below which you could not correctly detect + packet loss. The amount depends on the relative delay between the + channels, (D[channel-i,channel-j]), the data rate of each channel, + R[c], the maximum fragment size permitted on each channel, F[c], and + the total amount of buffering the transmitter has allocated amongst + the channels. + + When using PPP, the delay between channels could be estimated by + using LCP echo request and echo reply packets. (In the case of links + of different transmission rates, the round trip times should be + adjusted to take this into account.) The slippage for each channel + + + +Sklower, et. al. Standards Track [Page 12] + +RFC 1990 PPP Multilink August 1996 + + + is defined as the bandwidth times the delay for that channel relative + to the channel with the longest delay, S[c] = R[c] * D[c,c-worst]. + (S[c-worst] will be zero, of course!) + + A situation which would exacerbate sequence number skew would be one + in which there is extremely bursty traffic (almost allowing all + channels to drain), and then where the transmitter would first queue + up as many consecutively numbered packets on one link as it could, + then queue up the next batch on a second link, and so on. Since + transmitters must be able to buffer at least a maximum- sized + fragment for each link (and will usually buffer up at least two) A + receiver that allocates any less than S[1] + S[2] + ... + S[N] + F[1] + + ... + F[N], will be at risk for incorrectly assuming packet loss, + and therefore, SHOULD allocate at least twice that. + +5. PPP Link Control Protocol Extensions + + If reliable multilink operation is desired, PPP Reliable Transmission + [6] (essentially the use of ISO LAPB) MUST be negotiated prior to the + use of the Multilink Protocol on each member link. + + Whether or not reliable delivery is employed over member links, an + implementation MUST present a signal to the NCP's running over the + multilink arrangement that a loss has occurred. + + Compression may be used separately on each member link, or run over + the bundle (as a logical group link). The use of multiple + compression streams under the bundle (i.e., on each link separately) + is indicated by running the Compression Control Protocol [5] but with + an alternative PPP protocol ID. + +5.1. Configuration Option Types + + The Multilink Protocol introduces the use of additional LCP + Configuration Options: + + o Multilink Maximum Received Reconstructed Unit + o Multilink Short Sequence Number Header Format + o Endpoint Discriminator + + + + + + + + + + + + +Sklower, et. al. Standards Track [Page 13] + +RFC 1990 PPP Multilink August 1996 + + +5.1.1. Multilink MRRU LCP option + + Figure 4: Multilink MRRU LCP option + + 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 = 17 | Length = 4 | Max-Receive-Reconstructed-Unit| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The presence of this LCP option indicates that the system sending it + implements the PPP Multilink Protocol. If not rejected, the system + will construe all packets received on this link as being able to be + processed by a common protocol machine with any other packets + received from the same peer on any other link on which this option + has been accepted. + + The Max-Receive-Reconstructed unit field is two octets, and specifies + the maximum number of octets in the Information fields of reassembled + packets. A system MUST be able to receive the full 1500 octet + Information field of any reassembled PPP packet although it MAY + attempt to negotiate a smaller, or larger value. The number 1500 + here comes from the specification for the MRU LCP option in PPP; if + this requirement is changed in a future version of RFC 1661, the same + rules will apply here. + + A system MUST include the LCP MRRU option in every LCP negotiation + intended to instantiate a bundle or to join an existing bundle. If + the LCP MRRU option is offered on a link which is intended to join an + existing bundle, a system MUST offer the same Max-Receive- + Reconstruct-Unit value previously negotiated for the bundle. + + A system MUST NOT send any multilink packets on any link unless its + peer has offered the MMRU LCP option and the system has configure- + Ack'ed it during the most recent LCP negotiation on that link. A + system MAY include the MMRU LCP option in a configure-NAK, if its + peer has not offered it (until, according to PPP rules, the peer + configure-Reject's it). + + Note: the MRRU value conveyed im this option corresponds to the MRU + of the bundle when conceptualized as a PPP entity; but the rules for + the Multilink MRRU option are different from the LCP MRU option, as + some value MUST be offered in every LCP negotiation, and that + confirmation of this option is required prior to multilink + interpretation. + + + + + + +Sklower, et. al. Standards Track [Page 14] + +RFC 1990 PPP Multilink August 1996 + + +5.1.2. Short Sequence Number Header Format Option + + Figure 5: Short Sequence Number Header Format Option + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 18 | Length = 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + This option advises the peer that the implementation wishes to + receive fragments with short, 12 bit sequence numbers. When a peer + system configure-Ack's this option, it MUST transmit all multilink + packets on all links of the bundle with 12 bit sequence numbers or + configure-Reject the option. If 12 bit sequence numbers are desired, + this option MUST be negotiated when the bundle is instantiated, and + MUST be explicitly included in every LCP configure request offered by + a system when the system intends to include that link in an existing + bundle using 12 bit sequence numbers. If this option is never + negotiated during the life of a bundle, sequence numbers are 24 bits + long. + + An implementation wishing to transmit multilink fragments with short + sequence numbers MAY include the multilink short sequence number in a + configure-NAK to ask that the peer respond with a request to receive + short sequence numbers. The peer is not compelled to respond with + the option. + +5.1.3. Endpoint Discriminator Option + + Figure 7: Endpoint Discriminator Option + + 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 = 19 | Length | Class | Address ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Endpoint Discriminator Option represents identification of the + system transmitting the packet. This option advises a system that + the peer on this link could be the same as the peer on another + existing link. If the option distinguishes this peer from all + others, a new bundle MUST be established from the link being + negotiated. If this option matches the class and address of some + other peer of an existing link, the new link MUST be joined to the + bundle containing the link to the matching peer or MUST establish a + new bundle, depending on the decision tree shown in (1) through (4) + below. + + + +Sklower, et. al. Standards Track [Page 15] + +RFC 1990 PPP Multilink August 1996 + + + To securely join an existing bundle, a PPP authentication protocol + [3] must be used to obtain authenticated information from the peer to + prevent a hostile peer from joining an existing bundle by presenting + a falsified discriminator option. + + This option is not required for multilink operation. If a system + does not receive the Multilink MRRU option, but does receive the + Endpoint Discriminator Option, and there is no manual configuration + providing outside information, the implementation MUST NOT assume + that multilink operation is being requested on this basis alone. + + As there is also no requirement for authentication, there are four + sets of scenarios: + + (1) No authentication, no discriminator: + All new links MUST be joined to one bundle, unless + there is manual configuration to the contrary. + It is also permissible to have more than one manually + configured bundle connecting two given systems. + + (2) Discriminator, no authentication: + Discriminator match -> MUST join matching bundle, + discriminator mismatch -> MUST establish new bundle. + + (3) No discriminator, authentication: + Authenticated match -> MUST join matching bundle, + authenticated mismatch -> MUST establish new bundle. + + (4) Discriminator, authentication: + Discriminator match and authenticated match -> MUST join bundle, + discriminator mismatch -> MUST establish new bundle, + authenticated mismatch -> MUST establish new bundle. + + The option contains a Class which selects an identifier address space + and an Address which selects a unique identifier within the class + address space. + + This identifier is expected to refer to the mechanical equipment + associated with the transmitting system. For some classes, + uniqueness of the identifier is global and is not bounded by the + scope of a particular administrative domain. Within each class, + uniqueness of address values is controlled by a class dependent + policy for assigning values. + + Each endpoint may chose an identifier class without restriction. + Since the objective is to detect mismatches between endpoints + erroneously assumed to be alike, mismatch on class alone is + sufficient. Although no one class is recommended, classes which have + + + +Sklower, et. al. Standards Track [Page 16] + +RFC 1990 PPP Multilink August 1996 + + + universally unique values are preferred. + + This option is not required to be supported either by the system or + the peer. If the option is not present in a Configure-Request, the + system MUST NOT generate a Configure-Nak of this option for any + reason; instead it SHOULD behave as if it had received the option + with Class = 0, Address = 0. If a system receives a Configure-Nak or + Configure-Reject of this option, it MUST remove it from any + additional Configure-Request. + + The size is determined from the Length field of the element. For + some classes, the length is fixed, for others the length is variable. + The option is invalid if the Length field indicates a size below the + minimum for the class. + + An implementation MAY use the Endpoint Discriminator to locate + administration or authentication records in a local database. Such + use of this option is incidental to its purpose and is deprecated + when a PPP Authentication protocol [3] can be used instead. Since + some classes permit the peer to generate random or locally assigned + address values, use of this option as a database key requires prior + agreement between peer administrators. + + The specification of the subfields are: + + Type + 19 = for Endpoint Discriminator + + Length + 3 + length of Address + + Class + The Class field is one octet and indicates the identifier + address space. The most up-to-date values of the LCP Endpoint + Discriminator Class field are specified in the most recent + "Assigned Numbers" RFC [7]. Current values are assigned as + follows: + + 0 Null Class + + 1 Locally Assigned Address + + 2 Internet Protocol (IP) Address + + 3 IEEE 802.1 Globally Assigned MAC Address + + 4 PPP Magic-Number Block + + + + +Sklower, et. al. Standards Track [Page 17] + +RFC 1990 PPP Multilink August 1996 + + + 5 Public Switched Network Directory Number + + Address + The Address field is one or more octets and indicates the + identifier address within the selected class. The length and + content depend on the value of the Class as follows: + + Class 0 - Null Class + + Maximum Length: 0 + + Content: + This class is the default value if the option is not + present in a received Configure-Request. + + Class 1 - Locally Assigned Address + + Maximum Length: 20 + + Content: + + This class is defined to permit a local assignment in the + case where use of one of the globally unique classes is not + possible. Use of a device serial number is suggested. The + use of this class is deprecated since uniqueness is not + guaranteed. + + Class 2 - Internet Protocol (IP) Address + + Fixed Length: 4 + + Content: + + An address in this class contains an IP host address as + defined in [8]. + + Class 3 - IEEE 802.1 Globally Assigned MAC Address + + Fixed Length: 6 + + Content: + + An address in this class contains an IEEE 802.1 MAC address + in canonical (802.3) format [9]. The address MUST have the + global/local assignment bit clear and MUST have the + multicast/specific bit clear. Locally assigned MAC + addresses should be represented using Class 1. + + + + +Sklower, et. al. Standards Track [Page 18] + +RFC 1990 PPP Multilink August 1996 + + + Class 4 - PPP Magic-Number Block + + Maximum Length: 20 + + Content: + + This is not an address but a block of 1 to 5 concatenated + 32 bit PPP Magic-Numbers as defined in [2]. This class + provides for automatic generation of a value likely but not + guaranteed to be unique. The same block MUST be used by an + endpoint continuously during any period in which at least + one link is in the LCP Open state. The use of this class + is deprecated. + + Note that PPP Magic-Numbers are used in [2] to detect + unexpected loopbacks of a link from an endpoint to itself. + There is a small probability that two distinct endpoints + will generate matching magic-numbers. This probability is + geometrically reduced when the LCP negotiation is repeated + in search of the desired mismatch, if a peer can generate + uncorrelated magic-numbers. + + As used here, magic-numbers are used to determine if two + links are in fact from the same peer endpoint or from two + distinct endpoints. The numbers always match when there is + one endpoint. There is a small probability that the + numbers will match even if there are two endpoints. To + achieve the same confidence that there is not a false match + as for LCP loopback detection, several uncorrelated magic- + numbers can be combined in one block. + + Class 5 - Public Switched Network Directory Number + + Maximum Length: 15 + + Content: + + An address in this class contains an octet sequence as + defined by I.331 (E.164) representing an international + telephone directory number suitable for use to access the + endpoint via the public switched telephone network [10]. + +6. Initiating use of Multilink Headers + + When the use of the Multilink protocol has been negotiated on a link + (say Y), and the link is being added to a bundle which currently + contains a single existing link (say X), a system MUST transmit a + Multilink-encapsulated packet on X before transmitting any Multilink- + + + +Sklower, et. al. Standards Track [Page 19] + +RFC 1990 PPP Multilink August 1996 + + + encapsulated packets on Y. + + Since links may be added and removed from a bundle without destroying + the state associated with it, the fragment should be assigned the + appropriate (next) fragment number. As noted earlier, the first + fragment transmitted in the life of a bundle is assigned fragment + number 0. + +7. Closing Member links + + Member links may be terminated according to normal PPP LCP procedures + using LCP Terminate-Request and Terminate-Ack packets on that member + link. Since it is assumed that member links usually do not reorder + packets, receipt of a terminate ack is sufficient to assume that any + multilink protocol packets ahead of it are at no special risk of + loss. + + Receipt of an LCP Terminate-Request on one link does not conclude the + procedure on the remaining links. + + So long as any member links in the bundle are active, the PPP state + for the bundle persists as a separate entity. However, if the there + is a unique link in the bundle, and all the other links were closed + gracefully (with Terminate-Ack), an implementation MAY cease using + multilink + headers. + + If the multilink procedure is used in conjunction with PPP reliable + transmission, and a member link is not closed gracefully, the + implementation should expect to receive packets which violate the + increasing sequence number rule. + +8. Interaction with Other Protocols + + In the common case, LCP, and the Authentication Control Protocol + would be negotiated over each member link. The Network Protocols + themselves and associated control exchanges would normally have been + conducted once, on the bundle. + + In some instances it may be desirable for some Network Protocols to + be exempted from sequencing requirements, and if the MRU sizes of the + link did not cause fragmentation, those protocols could be sent + directly over the member links. + + Although explicitly discouraged above, if there were several member + links connecting two implementations, and independent sequencing of + two protocol sets were desired, but blocking of one by the other was + not, one could describe two multilink procedures by assigning + + + +Sklower, et. al. Standards Track [Page 20] + +RFC 1990 PPP Multilink August 1996 + + + multiple endpoint identifiers to a given system. Each member link, + however, would only belong to one bundle. One could think of a + physical router as housing two logically separate implementations, + each of which is independently configured. + + A simpler solution would be to have one link refuse to join the + bundle, by sending a Configure-Reject in response to the Multilink + LCP option. + +9. Security Considerations + + Operation of this protocol is no more and no less secure than + operation of the PPP authentication protocols [3]. The reader is + directed there for further discussion. + +10. References + + [1] Leifer, D., Sheldon, S., and B. Gorsline, "A Subnetwork Control + Protocol for ISDN Circuit-Switching", University of Michigan + (unpublished), March 1991. + + [2] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, + RFC 1661, Daydreamer, July 1994. + + [3] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC + 1334, Lloyd Internetworking, Daydreamer, October 1992. + + [4] International Organisation for Standardization, "HDLC - + Description of the X.25 LAPB-Compatible DTE Data Link + Procedures", International Standard 7776, 1988 + + [5] Rand, D., "The PPP Compression Control Protocol (CCP)", PPP + Extensions Working Group, RFC 1962, June 1996. + + [6] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July + 1994 + + [7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, + USC/Information Sciences Institute, October 1994. + + [8] Postel, J., Editor, "Internet Protocol - DARPA Internet Program + Protocol Specification", STD 5, RFC 791, USC/Information Sciences + Institute, September 1981. + + [9] Institute of Electrical and Electronics Engineers, Inc., "IEEE + Local and Metropolitan Area Networks: Overview and Architecture", + IEEE Std. 802-1990, 1990. + + + + +Sklower, et. al. Standards Track [Page 21] + +RFC 1990 PPP Multilink August 1996 + + + [10] The International Telegraph and Telephone Consultative Committee + (CCITT), "Numbering Plan for the ISDN Area", Recommendation I.331 + (E.164), 1988. + + [11] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer, + January 1994. + +11. Differences from RFC 1717 + + This section documents differences from RFC 1717. There are + restrictions placed on implementations that were absent in RFC 1717; + systems obeying these restrictions are fully interoperable with RFC + 1717 - compliant systems. + +11.1. Negotiating Multilink, per se + + RFC 1717 permitted either the use of the Short Sequence Number Header + Format (SSNHF) or the Maximum Reconstructed Receive Unit (MRRU) + options by themselves to indicate the intent to negotiate multilink. + This specification forbids the use of the SSNHF option by itself; but + does permit the specific of both options together. Any + implementation which otherwise conforms to rfc1717 and also obeys + this restriction will interoperate with any RFC 1717 implementation. + +11.2. Initial Sequence Number defined + + This specification requires that the first sequence number + transmitted after the virtual link has reached to open state be 0. + +11.3. Default Value of the MRRU + + This specfication removes the default value for the MRRU, (since it + must always be negotiated with some value), and specifies that an + implementation must be support an MRRU with same value as the default + MRU size for PPP. + +11.4. Config-Nak of EID prohibited + + This specification forbids the config-Naking of an EID for any + reason. + +11.5. Uniformity of Sequence Space + + This specification requires that the same sequence format be employed + on all links in a bundle. + + + + + + +Sklower, et. al. Standards Track [Page 22] + +RFC 1990 PPP Multilink August 1996 + + +11.6. Commencing and Abating use of Multilink Headers + + This memo specifies how one should start the use of Multilink Headers + when a link is added, and under what circumstances it is safe to + discontinue their use. + +11.7. Manual Configuration and Bundle Assignment + + The document explicitly permits multiple bundles to be manually + configured in the absence of both the Endpoint Descriminator and any + form of authentication. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sklower, et. al. Standards Track [Page 23] + +RFC 1990 PPP Multilink August 1996 + + +13. Authors' Addresses + + Keith Sklower + Computer Science Department + 384 Soda Hall, Mail Stop 1776 + University of California + Berkeley, CA 94720-1776 + + Phone: (510) 642-9587 + EMail: sklower@CS.Berkeley.EDU + + + Brian Lloyd + Lloyd Internetworking + 3031 Alhambra Drive + Cameron Park, CA 95682 + + Phone: (916) 676-1147 + EMail: brian@lloyd.com + + + Glenn McGregor + Lloyd Internetworking + 3031 Alhambra Drive + Cameron Park, CA 95682 + + Phone: (916) 676-1147 + EMail: glenn@lloyd.com + + + Dave Carr + Newbridge Networks Corporation + 600 March Road + P.O. Box 13600 + Kanata, Ontario, + Canada, K2K 2E6 + + Phone: (613) 591-3600 + EMail: dcarr@Newbridge.COM + + + Tom Coradetti + Sidewalk Software + 1190 Josephine Road + Roseville, MN 55113 + + Phone: (612) 490 7856 + EMail: 70761.1664@compuserve.com + + + +Sklower, et. al. Standards Track [Page 24] + diff --git a/rfc/rfc1994.txt b/rfc/rfc1994.txt new file mode 100644 index 00000000..e4a553e5 --- /dev/null +++ b/rfc/rfc1994.txt @@ -0,0 +1,732 @@ + + + + + + +Network Working Group W. Simpson +Request for Comments: 1994 DayDreamer +Obsoletes: 1334 August 1996 +Category: Standards Track + + + PPP Challenge Handshake Authentication Protocol (CHAP) + + +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, which allows + negotiation of an Authentication Protocol for authenticating its peer + before allowing Network Layer protocols to transmit over the link. + + This document defines a method for Authentication using PPP, which + uses a random Challenge, with a cryptographically hashed Response + which depends upon the Challenge and a secret key. + +Table of Contents + + 1. Introduction .......................................... 1 + 1.1 Specification of Requirements ................... 1 + 1.2 Terminology ..................................... 2 + 2. Challenge-Handshake Authentication Protocol ........... 2 + 2.1 Advantages ...................................... 3 + 2.2 Disadvantages ................................... 3 + 2.3 Design Requirements ............................. 4 + 3. Configuration Option Format ........................... 5 + 4. Packet Format ......................................... 6 + 4.1 Challenge and Response .......................... 7 + 4.2 Success and Failure ............................. 9 + SECURITY CONSIDERATIONS ...................................... 10 + ACKNOWLEDGEMENTS ............................................. 11 + REFERENCES ................................................... 12 + CONTACTS ..................................................... 12 + + + + +Simpson [Page i] + +RFC 1994 PPP CHAP August 1996 + + +1. Introduction + + In order to establish communications over a point-to-point link, each + end of the PPP link must first send LCP packets to configure the data + link during Link Establishment phase. After the link has been + established, PPP provides for an optional Authentication phase before + proceeding to the Network-Layer Protocol phase. + + By default, authentication is not mandatory. If authentication of + the link is desired, an implementation MUST specify the + Authentication-Protocol Configuration Option during Link + Establishment phase. + + These authentication protocols are intended for use primarily by + hosts and routers that connect to a PPP network server via switched + circuits or dial-up lines, but might be applied to dedicated links as + well. The server can use the identification of the connecting host + or router in the selection of options for network layer negotiations. + + This document defines a PPP authentication protocol. The Link + Establishment and Authentication phases, and the Authentication- + Protocol Configuration Option, are defined in The Point-to-Point + Protocol (PPP) [1]. + + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST This word, or the adjective "required", means that the + definition is an absolute requirement of the specification. + + MUST NOT This phrase means that the definition is an absolute + prohibition of the specification. + + SHOULD This word, or the adjective "recommended", means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications must be + understood and carefully weighed before choosing a + different course. + + MAY This word, or the adjective "optional", means that this + item is one of an allowed set of alternatives. An + implementation which does not include this option MUST be + prepared to interoperate with another implementation which + does include the option. + + + + +Simpson [Page 1] + +RFC 1994 PPP CHAP August 1996 + + +1.2. Terminology + + This document frequently uses the following terms: + + authenticator + The end of the link requiring the authentication. The + authenticator specifies the authentication protocol to be + used in the Configure-Request during Link Establishment + phase. + + peer The other end of the point-to-point link; the end which is + being authenticated by the authenticator. + + silently discard + This means the implementation discards the packet without + further processing. The implementation SHOULD provide the + capability of logging the error, including the contents of + the silently discarded packet, and SHOULD record the event + in a statistics counter. + + + + +2. Challenge-Handshake Authentication Protocol + + The Challenge-Handshake Authentication Protocol (CHAP) is used to + periodically verify the identity of the peer using a 3-way handshake. + This is done upon initial link establishment, and MAY be repeated + anytime after the link has been established. + + 1. After the Link Establishment phase is complete, the + authenticator sends a "challenge" message to the peer. + + 2. The peer responds with a value calculated using a "one-way + hash" function. + + 3. The authenticator checks the response against its own + calculation of the expected hash value. If the values match, + the authentication is acknowledged; otherwise the connection + SHOULD be terminated. + + 4. At random intervals, the authenticator sends a new challenge to + the peer, and repeats steps 1 to 3. + + + + + + + + +Simpson [Page 2] + +RFC 1994 PPP CHAP August 1996 + + +2.1. Advantages + + CHAP provides protection against playback attack by the peer through + the use of an incrementally changing identifier and a variable + challenge value. The use of repeated challenges is intended to limit + the time of exposure to any single attack. The authenticator is in + control of the frequency and timing of the challenges. + + This authentication method depends upon a "secret" known only to the + authenticator and that peer. The secret is not sent over the link. + + Although the authentication is only one-way, by negotiating CHAP in + both directions the same secret set may easily be used for mutual + authentication. + + Since CHAP may be used to authenticate many different systems, name + fields may be used as an index to locate the proper secret in a large + table of secrets. This also makes it possible to support more than + one name/secret pair per system, and to change the secret in use at + any time during the session. + + +2.2. Disadvantages + + CHAP requires that the secret be available in plaintext form. + Irreversably encrypted password databases commonly available cannot + be used. + + It is not as useful for large installations, since every possible + secret is maintained at both ends of the link. + + Implementation Note: To avoid sending the secret over other links + in the network, it is recommended that the challenge and response + values be examined at a central server, rather than each network + access server. Otherwise, the secret SHOULD be sent to such + servers in a reversably encrypted form. Either case requires a + trusted relationship, which is outside the scope of this + specification. + + + + + + + + + + + + + +Simpson [Page 3] + +RFC 1994 PPP CHAP August 1996 + + +2.3. Design Requirements + + The CHAP algorithm requires that the length of the secret MUST be at + least 1 octet. The secret SHOULD be at least as large and + unguessable as a well-chosen password. It is preferred that the + secret be at least the length of the hash value for the hashing + algorithm chosen (16 octets for MD5). This is to ensure a + sufficiently large range for the secret to provide protection against + exhaustive search attacks. + + The one-way hash algorithm is chosen such that it is computationally + infeasible to determine the secret from the known challenge and + response values. + + Each challenge value SHOULD be unique, since repetition of a + challenge value in conjunction with the same secret would permit an + attacker to reply with a previously intercepted response. Since it + is expected that the same secret MAY be used to authenticate with + servers in disparate geographic regions, the challenge SHOULD exhibit + global and temporal uniqueness. + + Each challenge value SHOULD also be unpredictable, least an attacker + trick a peer into responding to a predicted future challenge, and + then use the response to masquerade as that peer to an authenticator. + + Although protocols such as CHAP are incapable of protecting against + realtime active wiretapping attacks, generation of unique + unpredictable challenges can protect against a wide range of active + attacks. + + A discussion of sources of uniqueness and probability of divergence + is included in the Magic-Number Configuration Option [1]. + + + + + + + + + + + + + + + + + + + +Simpson [Page 4] + +RFC 1994 PPP CHAP August 1996 + + +3. Configuration Option Format + + A summary of the Authentication-Protocol Configuration Option format + to negotiate the Challenge-Handshake Authentication Protocol is shown + below. The fields are transmitted from left to right. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Authentication-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Algorithm | + +-+-+-+-+-+-+-+-+ + + Type + + 3 + + Length + + 5 + + Authentication-Protocol + + c223 (hex) for Challenge-Handshake Authentication Protocol. + + Algorithm + + The Algorithm field is one octet and indicates the authentication + method to be used. Up-to-date values are specified in the most + recent "Assigned Numbers" [2]. One value is required to be + implemented: + + 5 CHAP with MD5 [3] + + + + + + + + + + + + + + + + + + + +Simpson [Page 5] + +RFC 1994 PPP CHAP August 1996 + + +4. Packet Format + + Exactly one Challenge-Handshake Authentication Protocol packet is + encapsulated in the Information field of a PPP Data Link Layer frame + where the protocol field indicates type hex c223 (Challenge-Handshake + Authentication Protocol). A summary of the CHAP packet format is + shown below. The fields are transmitted from left to right. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Code + + The Code field is one octet and identifies the type of CHAP + packet. CHAP Codes are assigned as follows: + + 1 Challenge + 2 Response + 3 Success + 4 Failure + + Identifier + + The Identifier field is one octet and aids in matching challenges, + responses and replies. + + Length + + The Length field is two octets and indicates the length of the + CHAP packet including the Code, Identifier, Length and Data + fields. Octets outside the range of the Length field should be + treated as Data Link Layer padding and should be ignored on + reception. + + Data + + The Data field is zero or more octets. The format of the Data + field is determined by the Code field. + + + + + + + + + + +Simpson [Page 6] + +RFC 1994 PPP CHAP August 1996 + + +4.1. Challenge and Response + + Description + + The Challenge packet is used to begin the Challenge-Handshake + Authentication Protocol. The authenticator MUST transmit a CHAP + packet with the Code field set to 1 (Challenge). Additional + Challenge packets MUST be sent until a valid Response packet is + received, or an optional retry counter expires. + + A Challenge packet MAY also be transmitted at any time during the + Network-Layer Protocol phase to ensure that the connection has not + been altered. + + The peer SHOULD expect Challenge packets during the Authentication + phase and the Network-Layer Protocol phase. Whenever a Challenge + packet is received, the peer MUST transmit a CHAP packet with the + Code field set to 2 (Response). + + Whenever a Response packet is received, the authenticator compares + the Response Value with its own calculation of the expected value. + Based on this comparison, the authenticator MUST send a Success or + Failure packet (described below). + + Implementation Notes: Because the Success might be lost, the + authenticator MUST allow repeated Response packets during the + Network-Layer Protocol phase after completing the + Authentication phase. To prevent discovery of alternative + Names and Secrets, any Response packets received having the + current Challenge Identifier MUST return the same reply Code + previously returned for that specific Challenge (the message + portion MAY be different). Any Response packets received + during any other phase MUST be silently discarded. + + When the Failure is lost, and the authenticator terminates the + link, the LCP Terminate-Request and Terminate-Ack provide an + alternative indication that authentication failed. + + + + + + + + + + + + + + +Simpson [Page 7] + +RFC 1994 PPP CHAP August 1996 + + + A summary of the Challenge and Response packet format is shown below. + The fields are transmitted from left to right. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value-Size | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Name ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 1 for Challenge; + + 2 for Response. + + Identifier + + The Identifier field is one octet. The Identifier field MUST be + changed each time a Challenge is sent. + + The Response Identifier MUST be copied from the Identifier field + of the Challenge which caused the Response. + + Value-Size + + This field is one octet and indicates the length of the Value + field. + + Value + + The Value field is one or more octets. The most significant octet + is transmitted first. + + The Challenge Value is a variable stream of octets. The + importance of the uniqueness of the Challenge Value and its + relationship to the secret is described above. The Challenge + Value MUST be changed each time a Challenge is sent. The length + of the Challenge Value depends upon the method used to generate + the octets, and is independent of the hash algorithm used. + + The Response Value is the one-way hash calculated over a stream of + octets consisting of the Identifier, followed by (concatenated + with) the "secret", followed by (concatenated with) the Challenge + Value. The length of the Response Value depends upon the hash + algorithm used (16 octets for MD5). + + + + +Simpson [Page 8] + +RFC 1994 PPP CHAP August 1996 + + + Name + + The Name field is one or more octets representing the + identification of the system transmitting the packet. There are + no limitations on the content of this field. For example, it MAY + contain ASCII character strings or globally unique identifiers in + ASN.1 syntax. The Name should not be NUL or CR/LF terminated. + The size is determined from the Length field. + + +4.2. Success and Failure + + Description + + If the Value received in a Response is equal to the expected + value, then the implementation MUST transmit a CHAP packet with + the Code field set to 3 (Success). + + If the Value received in a Response is not equal to the expected + value, then the implementation MUST transmit a CHAP packet with + the Code field set to 4 (Failure), and SHOULD take action to + terminate the link. + + A summary of the Success and Failure packet format is shown below. + The fields are transmitted from left to right. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 3 for Success; + + 4 for Failure. + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. The Identifier field MUST be copied from the + Identifier field of the Response which caused this reply. + + + + + + + + +Simpson [Page 9] + +RFC 1994 PPP CHAP August 1996 + + + Message + + The Message field is zero or more octets, and its contents are + implementation dependent. It is intended to be human readable, + and MUST NOT affect operation of the protocol. It is recommended + that the message contain displayable ASCII characters 32 through + 126 decimal. Mechanisms for extension to other character sets are + the topic of future research. The size is determined from the + Length field. + + + +Security Considerations + + Security issues are the primary topic of this RFC. + + The interaction of the authentication protocols within PPP are highly + implementation dependent. This is indicated by the use of SHOULD + throughout the document. + + For example, upon failure of authentication, some implementations do + not terminate the link. Instead, the implementation limits the kind + of traffic in the Network-Layer Protocols to a filtered subset, which + in turn allows the user opportunity to update secrets or send mail to + the network administrator indicating a problem. + + There is no provision for re-tries of failed authentication. + However, the LCP state machine can renegotiate the authentication + protocol at any time, thus allowing a new attempt. It is recommended + that any counters used for authentication failure not be reset until + after successful authentication, or subsequent termination of the + failed link. + + There is no requirement that authentication be full duplex or that + the same protocol be used in both directions. It is perfectly + acceptable for different protocols to be used in each direction. + This will, of course, depend on the specific protocols negotiated. + + The secret SHOULD NOT be the same in both directions. This allows an + attacker to replay the peer's challenge, accept the computed + response, and use that response to authenticate. + + In practice, within or associated with each PPP server, there is a + database which associates "user" names with authentication + information ("secrets"). It is not anticipated that a particular + named user would be authenticated by multiple methods. This would + make the user vulnerable to attacks which negotiate the least secure + method from among a set (such as PAP rather than CHAP). If the same + + + +Simpson [Page 10] + +RFC 1994 PPP CHAP August 1996 + + + secret was used, PAP would reveal the secret to be used later with + CHAP. + + Instead, for each user name there should be an indication of exactly + one method used to authenticate that user name. If a user needs to + make use of different authentication methods under different + circumstances, then distinct user names SHOULD be employed, each of + which identifies exactly one authentication method. + + Passwords and other secrets should be stored at the respective ends + such that access to them is as limited as possible. Ideally, the + secrets should only be accessible to the process requiring access in + order to perform the authentication. + + The secrets should be distributed with a mechanism that limits the + number of entities that handle (and thus gain knowledge of) the + secret. Ideally, no unauthorized person should ever gain knowledge + of the secrets. Such a mechanism is outside the scope of this + specification. + + +Acknowledgements + + David Kaufman, Frank Heinrich, and Karl Auerbach used a challenge + handshake at SDC when designing one of the protocols for a "secure" + network in the mid-1970s. Tom Bearson built a prototype Sytek + product ("Poloneous"?) on the challenge-response notion in the 1982- + 83 timeframe. Another variant is documented in the various IBM SNA + manuals. Yet another variant was implemented by Karl Auerbach in the + Telebit NetBlazer circa 1991. + + Kim Toms and Barney Wolff provided useful critiques of earlier + versions of this document. + + Special thanks to Dave Balenson, Steve Crocker, James Galvin, and + Steve Kent, for their extensive explanations and suggestions. Now, + if only we could get them to agree with each other. + + + + + + + + + + + + + + +Simpson [Page 11] + +RFC 1994 PPP CHAP August 1996 + + +References + + [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD + 51, RFC 1661, DayDreamer, July 1994. + + [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC + 1700, USC/Information Sciences Institute, October 1994. + + [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", + MIT Laboratory for Computer Science and RSA Data Security, + Inc., RFC 1321, April 1992. + + + +Contacts + + Comments should be submitted to the ietf-ppp@merit.edu mailing list. + + This document was reviewed by the Point-to-Point Protocol Working + Group of the Internet Engineering Task Force (IETF). The working + group can be contacted via the current chair: + + Karl Fox + Ascend Communications + 3518 Riverside Drive, Suite 101 + Columbus, Ohio 43221 + + karl@MorningStar.com + karl@Ascend.com + + + Questions about this memo can also be directed to: + + William Allen Simpson + DayDreamer + Computer Systems Consulting Services + 1384 Fontaine + Madison Heights, Michigan 48071 + + wsimpson@UMich.edu + wsimpson@GreenDragon.com (preferred) + + + + + + + + + + +Simpson [Page 12] + + diff --git a/rfc/rfc2138.txt b/rfc/rfc2138.txt new file mode 100644 index 00000000..9f4a86d3 --- /dev/null +++ b/rfc/rfc2138.txt @@ -0,0 +1,3643 @@ + + + + + + +Network Working Group C. Rigney +Request for Comments: 2138 Livingston +Obsoletes: 2058 A. Rubens +Category: Standards Track Merit + W. Simpson + Daydreamer + S. Willens + Livingston + April 1997 + + + Remote Authentication Dial In User Service (RADIUS) + +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 + + This document describes a protocol for carrying authentication, + authorization, and configuration information between a Network Access + Server which desires to authenticate its links and a shared + Authentication Server. + +Implementation Note + + This memo documents the RADIUS protocol. There has been some + confusion in the assignment of port numbers for this protocol. The + early deployment of RADIUS was done using the erroneously chosen port + number 1645, which conflicts with the "datametrics" service. The + officially assigned port number for RADIUS is 1812. + +Table of Contents + + 1. Introduction .......................................... 3 + 1.1 Specification of Requirements ................... 4 + 1.2 Terminology ..................................... 5 + 2. Operation ............................................. 5 + 2.1 Challenge/Response .............................. 7 + 2.2 Interoperation with PAP and CHAP ................ 7 + 2.3 Why UDP? ........................................ 8 + 3. Packet Format ......................................... 10 + 4. Packet Types .......................................... 13 + 4.1 Access-Request .................................. 13 + + + +Rigney, et. al. Standards Track [Page 1] + +RFC 2138 RADIUS April 1997 + + + 4.2 Access-Accept ................................... 14 + 4.3 Access-Reject ................................... 15 + 4.4 Access-Challenge ................................ 17 + 5. Attributes ............................................ 18 + 5.1 User-Name ....................................... 21 + 5.2 User-Password ................................... 22 + 5.3 CHAP-Password ................................... 23 + 5.4 NAS-IP-Address .................................. 24 + 5.5 NAS-Port ........................................ 25 + 5.6 Service-Type .................................... 26 + 5.7 Framed-Protocol ................................. 28 + 5.8 Framed-IP-Address ............................... 29 + 5.9 Framed-IP-Netmask ............................... 29 + 5.10 Framed-Routing .................................. 30 + 5.11 Filter-Id ....................................... 31 + 5.12 Framed-MTU ...................................... 32 + 5.13 Framed-Compression .............................. 33 + 5.14 Login-IP-Host ................................... 33 + 5.15 Login-Service ................................... 34 + 5.16 Login-TCP-Port .................................. 35 + 5.17 (unassigned) .................................... 36 + 5.18 Reply-Message ................................... 36 + 5.19 Callback-Number ................................. 37 + 5.20 Callback-Id ..................................... 38 + 5.21 (unassigned) .................................... 38 + 5.22 Framed-Route .................................... 39 + 5.23 Framed-IPX-Network .............................. 40 + 5.24 State ........................................... 40 + 5.25 Class ........................................... 41 + 5.26 Vendor-Specific ................................. 42 + 5.27 Session-Timeout ................................. 44 + 5.28 Idle-Timeout .................................... 44 + 5.29 Termination-Action .............................. 45 + 5.30 Called-Station-Id ............................... 46 + 5.31 Calling-Station-Id .............................. 47 + 5.32 NAS-Identifier .................................. 48 + 5.33 Proxy-State ..................................... 48 + 5.34 Login-LAT-Service ............................... 49 + 5.35 Login-LAT-Node .................................. 50 + 5.36 Login-LAT-Group ................................. 51 + 5.37 Framed-AppleTalk-Link ........................... 52 + 5.38 Framed-AppleTalk-Network ........................ 53 + 5.39 Framed-AppleTalk-Zone ........................... 54 + 5.40 CHAP-Challenge .................................. 55 + 5.41 NAS-Port-Type ................................... 55 + 5.42 Port-Limit ...................................... 56 + 5.43 Login-LAT-Port .................................. 57 + 5.44 Table of Attributes ............................. 58 + + + +Rigney, et. al. Standards Track [Page 2] + +RFC 2138 RADIUS April 1997 + + + 6. Examples .............................................. 59 + 6.1 User Telnet to Specified Host ................... 60 + 6.2 Framed User Authenticating with CHAP ............ 60 + 6.3 User with Challenge-Response card ............... 61 + Security Considerations ...................................... 63 + References ................................................... 64 + Acknowledgements ............................................. 64 + Chair's Address .............................................. 65 + Author's Addresses ........................................... 65 + +1. Introduction + + Managing dispersed serial line and modem pools for large numbers of + users can create the need for significant administrative support. + Since modem pools are by definition a link to the outside world, they + require careful attention to security, authorization and accounting. + This can be best achieved by managing a single "database" of users, + which allows for authentication (verifying user name and password) as + well as configuration information detailing the type of service to + deliver to the user (for example, SLIP, PPP, telnet, rlogin). + + Key features of RADIUS are: + + Client/Server Model + + A Network Access Server (NAS) operates as a client of RADIUS. The + client is responsible for passing user information to designated + RADIUS servers, and then acting on the response which is returned. + + RADIUS servers are responsible for receiving user connection + requests, authenticating the user, and then returning all + configuration information necessary for the client to deliver + service to the user. + + A RADIUS server can act as a proxy client to other RADIUS servers + or other kinds of authentication servers. + + Network Security + + Transactions between the client and RADIUS server are + authenticated through the use of a shared secret, which is never + sent over the network. In addition, any user passwords are sent + encrypted between the client and RADIUS server, to eliminate the + possibility that someone snooping on an unsecure network could + determine a user's password. + + + + + + +Rigney, et. al. Standards Track [Page 3] + +RFC 2138 RADIUS April 1997 + + + Flexible Authentication Mechanisms + + The RADIUS server can support a variety of methods to authenticate + a user. When it is provided with the user name and original + password given by the user, it can support PPP PAP or CHAP, UNIX + login, and other authentication mechanisms. + + Extensible Protocol + + All transactions are comprised of variable length Attribute- + Length-Value 3-tuples. New attribute values can be added without + disturbing existing implementations of the protocol. + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST This word, or the adjective "required", means that the + definition is an absolute requirement of the specification. + + MUST NOT This phrase means that the definition is an absolute + prohibition of the specification. + + SHOULD This word, or the adjective "recommended", means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications must be + understood and carefully weighed before choosing a + different course. + + MAY This word, or the adjective "optional", means that this + item is one of an allowed set of alternatives. An + implementation which does not include this option MUST be + prepared to interoperate with another implementation which + does include the option. + + + + + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 4] + +RFC 2138 RADIUS April 1997 + + +1.2. Terminology + + This document frequently uses the following terms: + + service The NAS provides a service to the dial-in user, such as PPP + or Telnet. + + session Each service provided by the NAS to a dial-in user + constitutes a session, with the beginning of the session + defined as the point where service is first provided and + the end of the session defined as the point where service + is ended. A user may have multiple sessions in parallel or + series if the NAS supports that. + + silently discard + This means the implementation discards the packet without + further processing. The implementation SHOULD provide the + capability of logging the error, including the contents of + the silently discarded packet, and SHOULD record the event + in a statistics counter. + +2. Operation + + When a client is configured to use RADIUS, any user of the client + presents authentication information to the client. This might be + with a customizable login prompt, where the user is expected to enter + their username and password. Alternatively, the user might use a + link framing protocol such as the Point-to-Point Protocol (PPP), + which has authentication packets which carry this information. + + Once the client has obtained such information, it may choose to + authenticate using RADIUS. To do so, the client creates an "Access- + Request" containing such Attributes as the user's name, the user's + password, the ID of the client and the Port ID which the user is + accessing. When a password is present, it is hidden using a method + based on the RSA Message Digest Algorithm MD5 [1]. + + The Access-Request is submitted to the RADIUS server via the network. + If no response is returned within a length of time, the request is + re-sent a number of times. The client can also forward requests to + an alternate server or servers in the event that the primary server + is down or unreachable. An alternate server can be used either after + a number of tries to the primary server fail, or in a round-robin + fashion. Retry and fallback algorithms are the topic of current + research and are not specified in detail in this document. + + + + + + +Rigney, et. al. Standards Track [Page 5] + +RFC 2138 RADIUS April 1997 + + + Once the RADIUS server receives the request, it validates the sending + client. A request from a client for which the RADIUS server does not + have a shared secret should be silently discarded. If the client is + valid, the RADIUS server consults a database of users to find the + user whose name matches the request. The user entry in the database + contains a list of requirements which must be met to allow access for + the user. This always includes verification of the password, but can + also specify the client(s) or port(s) to which the user is allowed + access. + + The RADIUS server MAY make requests of other servers in order to + satisfy the request, in which case it acts as a client. + + If any condition is not met, the RADIUS server sends an "Access- + Reject" response indicating that this user request is invalid. If + desired, the server MAY include a text message in the Access-Reject + which MAY be displayed by the client to the user. No other + Attributes are permitted in an Access-Reject. + + If all conditions are met and the RADIUS server wishes to issue a + challenge to which the user must respond, the RADIUS server sends an + "Access-Challenge" response. It MAY include a text message to be + displayed by the client to the user prompting for a response to the + challenge, and MAY include a State attribute. If the client receives + an Access-Challenge and supports challenge/response it MAY display + the text message, if any, to the user, and then prompt the user for a + response. The client then re-submits its original Access-Request + with a new request ID, with the User-Password Attribute replaced by + the response (encrypted), and including the State Attribute from the + Access-Challenge, if any. Only 0 or 1 instances of the State + Attributes should be present in a request. The server can respond to + this new Access-Request with either an Access-Accept, an Access- + Reject, or another Access-Challenge. + + If all conditions are met, the list of configuration values for the + user are placed into an "Access-Accept" response. These values + include the type of service (for example: SLIP, PPP, Login User) and + all necessary values to deliver the desired service. For SLIP and + PPP, this may include values such as IP address, subnet mask, MTU, + desired compression, and desired packet filter identifiers. For + character mode users, this may include values such as desired + protocol and host. + + + + + + + + + +Rigney, et. al. Standards Track [Page 6] + +RFC 2138 RADIUS April 1997 + + +2.1. Challenge/Response + + In challenge/response authentication, the user is given an + unpredictable number and challenged to encrypt it and give back the + result. Authorized users are equipped with special devices such as + smart cards or software that facilitate calculation of the correct + response with ease. Unauthorized users, lacking the appropriate + device or software and lacking knowledge of the secret key necessary + to emulate such a device or software, can only guess at the response. + + The Access-Challenge packet typically contains a Reply-Message + including a challenge to be displayed to the user, such as a numeric + value unlikely ever to be repeated. Typically this is obtained from + an external server that knows what type of authenticator should be in + the possession of the authorized user and can therefore choose a + random or non-repeating pseudorandom number of an appropriate radix + and length. + + The user then enters the challenge into his device (or software) and + it calculates a response, which the user enters into the client which + forwards it to the RADIUS server via a second Access-Request. If the + response matches the expected response the RADIUS server replies with + an Access-Accept, otherwise an Access-Reject. + + Example: The NAS sends an Access-Request packet to the RADIUS Server + with NAS-Identifier, NAS-Port, User-Name, User-Password (which may + just be a fixed string like "challenge" or ignored). The server + sends back an Access-Challenge packet with State and a Reply-Message + along the lines of "Challenge 12345678, enter your response at the + prompt" which the NAS displays. The NAS prompts for the response and + sends a NEW Access-Request to the server (with a new ID) with NAS- + Identifier, NAS-Port, User-Name, User-Password (the response just + entered by the user, encrypted), and the same State Attribute that + came with the Access-Challenge. The server then sends back either an + Access-Accept or Access-Reject based on whether the response matches + what it should be, or it can even send another Access-Challenge. + +2.2. Interoperation with PAP and CHAP + + For PAP, the NAS takes the PAP ID and password and sends them in an + Access-Request packet as the User-Name and User-Password. The NAS MAY + include the Attributes Service-Type = Framed-User and Framed-Protocol + = PPP as a hint to the RADIUS server that PPP service is expected. + + For CHAP, the NAS generates a random challenge (preferably 16 octets) + and sends it to the user, who returns a CHAP response along with a + CHAP ID and CHAP username. The NAS then sends an Access-Request + packet to the RADIUS server with the CHAP username as the User-Name + + + +Rigney, et. al. Standards Track [Page 7] + +RFC 2138 RADIUS April 1997 + + + and with the CHAP ID and CHAP response as the CHAP-Password + (Attribute 3). The random challenge can either be included in the + CHAP-Challenge attribute or, if it is 16 octets long, it can be + placed in the Request Authenticator field of the Access-Request + packet. The NAS MAY include the Attributes Service-Type = Framed- + User and Framed-Protocol = PPP as a hint to the RADIUS server that + PPP service is expected. + + The RADIUS server looks up a password based on the User-Name, + encrypts the challenge using MD5 on the CHAP ID octet, that password, + and the CHAP challenge (from the CHAP-Challenge attribute if present, + otherwise from the Request Authenticator), and compares that result + to the CHAP-Password. If they match, the server sends back an + Access-Accept, otherwise it sends back an Access-Reject. + + If the RADIUS server is unable to perform the requested + authentication it should return an Access-Reject. For example, CHAP + requires that the user's password be available in cleartext to the + server so that it can encrypt the CHAP challenge and compare that to + the CHAP response. If the password is not available in cleartext to + the RADIUS server then the server MUST send an Access-Reject to the + client. + +2.3. Why UDP? + + A frequently asked question is why RADIUS uses UDP instead of TCP as + a transport protocol. UDP was chosen for strictly technical reasons. + + There are a number of issues which must be understood. RADIUS is a + transaction based protocol which has several interesting + characteristics: + + 1. If the request to a primary Authentication server fails, a + secondary server must be queried. + + To meet this requirement, a copy of the request must be kept + above the transport layer to allow for alternate transmission. + This means that retransmission timers are still required. + + 2. The timing requirements of this particular protocol are + significantly different than TCP provides. + + At one extreme, RADIUS does not require a "responsive" + detection of lost data. The user is willing to wait several + seconds for the authentication to complete. The generally + aggressive TCP retransmission (based on average round trip + time) is not required, nor is the acknowledgement overhead of + TCP. + + + +Rigney, et. al. Standards Track [Page 8] + +RFC 2138 RADIUS April 1997 + + + At the other extreme, the user is not willing to wait several + minutes for authentication. Therefore the reliable delivery of + TCP data two minutes later is not useful. The faster use of an + alternate server allows the user to gain access before giving + up. + + 3. The stateless nature of this protocol simplifies the use of UDP. + + Clients and servers come and go. Systems are rebooted, or are + power cycled independently. Generally this does not cause a + problem and with creative timeouts and detection of lost TCP + connections, code can be written to handle anomalous events. + UDP however completely eliminates any of this special handling. + Each client and server can open their UDP transport just once + and leave it open through all types of failure events on the + network. + + 4. UDP simplifies the server implementation. + + In the earliest implementations of RADIUS, the server was + single threaded. This means that a single request was + received, processed, and returned. This was found to be + unmanageable in environments where the back-end security + mechanism took real time (1 or more seconds). The server + request queue would fill and in environments where hundreds of + people were being authenticated every minute, the request + turn-around time increased to longer that users were willing to + wait (this was especially severe when a specific lookup in a + database or over DNS took 30 or more seconds). The obvious + solution was to make the server multi-threaded. Achieving this + was simple with UDP. Separate processes were spawned to serve + each request and these processes could respond directly to the + client NAS with a simple UDP packet to the original transport + of the client. + + It's not all a panacea. As noted, using UDP requires one thing + which is built into TCP: with UDP we must artificially manage + retransmission timers to the same server, although they don't + require the same attention to timing provided by TCP. This one + penalty is a small price to pay for the advantages of UDP in + this protocol. + + Without TCP we would still probably be using tin cans connected + by string. But for this particular protocol, UDP is a better + choice. + + + + + + +Rigney, et. al. Standards Track [Page 9] + +RFC 2138 RADIUS April 1997 + + +3. Packet Format + + Exactly one RADIUS packet is encapsulated in the UDP Data field [2], + where the UDP Destination Port field indicates 1812 (decimal). + + When a reply is generated, the source and destination ports are + reversed. + + This memo documents the RADIUS protocol. There has been some + confusion in the assignment of port numbers for this protocol. The + early deployment of RADIUS was done using the erroneously chosen port + number 1645, which conflicts with the "datametrics" service. The + officially assigned port number for RADIUS is 1812. + + A summary of the RADIUS data format is shown below. The fields are + transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + +Code + + The Code field is one octet, and identifies the type of RADIUS + packet. When a packet is received with an invalid Code field, it is + silently discarded. + + RADIUS Codes (decimal) are assigned as follows: + + 1 Access-Request + 2 Access-Accept + 3 Access-Reject + 4 Accounting-Request + 5 Accounting-Response + 11 Access-Challenge + 12 Status-Server (experimental) + 13 Status-Client (experimental) + 255 Reserved + + + + +Rigney, et. al. Standards Track [Page 10] + +RFC 2138 RADIUS April 1997 + + + Codes 4 and 5 are covered in the RADIUS Accounting document [9], and + are not further mentioned here. Codes 12 and 13 are reserved for + possible use, but are not further mentioned here. + +Identifier + + The Identifier field is one octet, and aids in matching requests and + replies. + +Length + + The Length field is two octets. It indicates the length of the + packet including the Code, Identifier, Length, Authenticator and + Attribute fields. Octets outside the range of the Length field + should be treated as padding and should be ignored on reception. If + the packet is shorter than the Length field indicates, it should be + silently discarded. The minimum length is 20 and maximum length is + 4096. + +Authenticator + + The Authenticator field is sixteen (16) octets. The most significant + octet is transmitted first. This value is used to authenticate the + reply from the RADIUS server, and is used in the password hiding + algorithm. + +Request Authenticator + + In Access-Request Packets, the Authenticator value is a 16 octet + random number, called the Request Authenticator. The value SHOULD + be unpredictable and unique over the lifetime of a secret (the + password shared between the client and the RADIUS server), since + repetition of a request value in conjunction with the same secret + would permit an attacker to reply with a previously intercepted + response. Since it is expected that the same secret MAY be used + to authenticate with servers in disparate geographic regions, the + Request Authenticator field SHOULD exhibit global and temporal + uniqueness. + + The Request Authenticator value in an Access-Request packet SHOULD + also be unpredictable, lest an attacker trick a server into + responding to a predicted future request, and then use the + response to masquerade as that server to a future Access-Request. + + + + + + + + +Rigney, et. al. Standards Track [Page 11] + +RFC 2138 RADIUS April 1997 + + + Although protocols such as RADIUS are incapable of protecting + against theft of an authenticated session via realtime active + wiretapping attacks, generation of unique unpredictable requests + can protect against a wide range of active attacks against + authentication. + + The NAS and RADIUS server share a secret. That shared secret + followed by the Request Authenticator is put through a one-way MD5 + hash to create a 16 octet digest value which is xored with the + password entered by the user, and the xored result placed in the + User-Password attribute in the Access-Request packet. See the + entry for User-Password in the section on Attributes for a more + detailed description. + + Response Authenticator + + The value of the Authenticator field in Access-Accept, Access- + Reject, and Access-Challenge packets is called the Response + Authenticator, and contains a one-way MD5 hash calculated over a + stream of octets consisting of: the RADIUS packet, beginning with + the Code field, including the Identifier, the Length, the Request + Authenticator field from the Access-Request packet, and the + response Attributes, followed by the shared secret. That is, + ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret) + where + denotes concatenation. + +Administrative Note + + The secret (password shared between the client and the RADIUS server) + SHOULD be at least as large and unguessable as a well-chosen + password. It is preferred that the secret be at least 16 octets. + This is to ensure a sufficiently large range for the secret to + provide protection against exhaustive search attacks. A RADIUS + server SHOULD use the source IP address of the RADIUS UDP packet to + decide which shared secret to use, so that RADIUS requests can be + proxied. + + When using a forwarding proxy, the proxy must be able to alter the + packet as it passes through in each direction - when the proxy + forwards the request, the proxy can add a Proxy-State Attribute, and + when the proxy forwards a response, it removes the Proxy-State + Attribute. Since Access-Accept and Access-Reject replies are + authenticated on the entire packet contents, the stripping of the + Proxy-State attribute would invalidate the signature in the packet - + so the proxy has to re-sign it. + + Further details of RADIUS proxy implementation are outside the scope + of this document. + + + +Rigney, et. al. Standards Track [Page 12] + +RFC 2138 RADIUS April 1997 + + +Attributes + + Many Attributes may have multiple instances, in such a case the order + of Attributes of the same Type SHOULD be preserved. The order of + Attributes of different Types is not required to be preserved. + + In the section below on "Attributes" where the text refers to which + packets an attribute is allowed in, only packets with Codes 1, 2, 3 + and 11 and attributes defined in this document are covered in this + document. A summary table is provided at the end of the "Attributes" + section. To determine which Attributes are allowed in packets with + codes 4 and 5 refer to the RADIUS Accounting document [9]. + +4. Packet Types + + The RADIUS Packet type is determined by the Code field in the first + octet of the Packet. + +4.1. Access-Request + + Description + + Access-Request packets are sent to a RADIUS server, and convey + information used to determine whether a user is allowed access to + a specific NAS, and any special services requested for that user. + An implementation wishing to authenticate a user MUST transmit a + RADIUS packet with the Code field set to 1 (Access-Request). + + Upon receipt of an Access-Request from a valid client, an + appropriate reply MUST be transmitted. + + An Access-Request MUST contain a User-Name attribute. It SHOULD + contain either a NAS-IP-Address attribute or NAS-Identifier + attribute (or both, although that is not recommended). It MUST + contain either a User-Password attribute or CHAP-Password + attribute. It SHOULD contain a NAS-Port or NAS-Port-Type + attribute or both unless the type of access being requested does + not involve a port or the NAS does not distinguish among its + ports. + + An Access-Request MAY contain additional attributes as a hint to + the server, but the server is not required to honor the hint. + + When a User-Password is present, it is hidden using a method based + on the RSA Message Digest Algorithm MD5 [1]. + + A summary of the Access-Request packet format is shown below. The + fields are transmitted from left to right. + + + +Rigney, et. al. Standards Track [Page 13] + +RFC 2138 RADIUS April 1997 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Request Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 1 for Access-Request. + + Identifier + + The Identifier field MUST be changed whenever the content of the + Attributes field changes, and whenever a valid reply has been + received for a previous request. For retransmissions, the + Identifier MUST remain unchanged. + + Request Authenticator + + The Request Authenticator value MUST be changed each time a new + Identifier is used. + + Attributes + + The Attribute field is variable in length, and contains the list + of Attributes that are required for the type of service, as well + as any desired optional Attributes. + +4.2. Access-Accept + + Description + + Access-Accept packets are sent by the RADIUS server, and provide + specific configuration information necessary to begin delivery of + service to the user. If all Attribute values received in an + Access-Request are acceptable then the RADIUS implementation MUST + transmit a packet with the Code field set to 2 (Access-Accept). + + + + + + + +Rigney, et. al. Standards Track [Page 14] + +RFC 2138 RADIUS April 1997 + + + On reception of an Access-Accept, the Identifier field is matched + with a pending Access-Request. Additionally, the Response + Authenticator field MUST contain the correct response for the + pending Access-Request. Invalid packets are silently discarded. + + A summary of the Access-Accept packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 2 for Access-Accept. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Access-Request which caused this Access-Accept. + + Response Authenticator + + The Response Authenticator value is calculated from the Access- + Request value, as described earlier. + + Attributes + + The Attribute field is variable in length, and contains a list of + zero or more Attributes. + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 15] + +RFC 2138 RADIUS April 1997 + + +4.3. Access-Reject + + Description + + If any value of the received Attributes is not acceptable, then + the RADIUS server MUST transmit a packet with the Code field set + to 3 (Access-Reject). It MAY include one or more Reply-Message + Attributes with a text message which the NAS MAY display to the + user. + + A summary of the Access-Reject packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 3 for Access-Reject. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Access-Request which caused this Access-Reject. + + Response Authenticator + + The Response Authenticator value is calculated from the Access- + Request value, as described earlier. + + Attributes + + The Attribute field is variable in length, and contains a list of + zero or more Attributes. + + + + + + + +Rigney, et. al. Standards Track [Page 16] + +RFC 2138 RADIUS April 1997 + + +4.4. Access-Challenge + + Description + + If the RADIUS server desires to send the user a challenge + requiring a response, then the RADIUS server MUST respond to the + Access-Request by transmitting a packet with the Code field set to + 11 (Access-Challenge). + + The Attributes field MAY have one or more Reply-Message + Attributes, and MAY have a single State Attribute, or none. No + other Attributes are permitted in an Access-Challenge. + + On receipt of an Access-Challenge, the Identifier field is matched + with a pending Access-Request. Additionally, the Response + Authenticator field MUST contain the correct response for the + pending Access-Request. Invalid packets are silently discarded. + + If the NAS does not support challenge/response, it MUST treat an + Access-Challenge as though it had received an Access-Reject + instead. + + If the NAS supports challenge/response, receipt of a valid + Access-Challenge indicates that a new Access-Request SHOULD be + sent. The NAS MAY display the text message, if any, to the user, + and then prompt the user for a response. It then sends its + original Access-Request with a new request ID and Request + Authenticator, with the User-Password Attribute replaced by the + user's response (encrypted), and including the State Attribute + from the Access-Challenge, if any. Only 0 or 1 instances of the + State Attribute can be present in an Access-Request. + + A NAS which supports PAP MAY forward the Reply-Message to the + dialin client and accept a PAP response which it can use as though + the user had entered the response. If the NAS cannot do so, it + should treat the Access-Challenge as though it had received an + Access-Reject instead. + + + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 17] + +RFC 2138 RADIUS April 1997 + + + A summary of the Access-Challenge packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 11 for Access-Challenge. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Access-Request which caused this Access-Challenge. + + Response Authenticator + + The Response Authenticator value is calculated from the Access- + Request value, as described earlier. + + Attributes + + The Attributes field is variable in length, and contains a list of + zero or more Attributes. + +5. Attributes + + RADIUS Attributes carry the specific authentication, authorization, + information and configuration details for the request and reply. + + Some Attributes MAY be included more than once. The effect of this + is Attribute specific, and is specified in each Attribute + description. + + The end of the list of Attributes is indicated by the Length of the + RADIUS packet. + + + + + +Rigney, et. al. Standards Track [Page 18] + +RFC 2138 RADIUS April 1997 + + + A summary of the Attribute format is shown below. The fields are + transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + The Type field is one octet. Up-to-date values of the RADIUS Type + field are specified in the most recent "Assigned Numbers" RFC [3]. + Values 192-223 are reserved for experimental use, values 224-240 + are reserved for implementation-specific use, and values 241-255 + are reserved and should not be used. This specification concerns + the following values: + + A RADIUS server MAY ignore Attributes with an unknown Type. + + A RADIUS client MAY ignore Attributes with an unknown Type. + + 1 User-Name + 2 User-Password + 3 CHAP-Password + 4 NAS-IP-Address + 5 NAS-Port + 6 Service-Type + 7 Framed-Protocol + 8 Framed-IP-Address + 9 Framed-IP-Netmask + 10 Framed-Routing + 11 Filter-Id + 12 Framed-MTU + 13 Framed-Compression + 14 Login-IP-Host + 15 Login-Service + 16 Login-TCP-Port + 17 (unassigned) + 18 Reply-Message + 19 Callback-Number + 20 Callback-Id + 21 (unassigned) + 22 Framed-Route + 23 Framed-IPX-Network + 24 State + 25 Class + 26 Vendor-Specific + + + +Rigney, et. al. Standards Track [Page 19] + +RFC 2138 RADIUS April 1997 + + + 27 Session-Timeout + 28 Idle-Timeout + 29 Termination-Action + 30 Called-Station-Id + 31 Calling-Station-Id + 32 NAS-Identifier + 33 Proxy-State + 34 Login-LAT-Service + 35 Login-LAT-Node + 36 Login-LAT-Group + 37 Framed-AppleTalk-Link + 38 Framed-AppleTalk-Network + 39 Framed-AppleTalk-Zone + 40-59 (reserved for accounting) + 60 CHAP-Challenge + 61 NAS-Port-Type + 62 Port-Limit + 63 Login-LAT-Port + + Length + + The Length field is one octet, and indicates the length of this + Attribute including the Type, Length and Value fields. If an + Attribute is received in an Access-Request but with an invalid + Length, an Access-Reject SHOULD be transmitted. If an Attribute + is received in an Access-Accept, Access-Reject or Access-Challenge + packet with an invalid length, the packet MUST either be treated + an Access-Reject or else silently discarded. + + Value + + The Value field is zero or more octets and contains information + specific to the Attribute. The format and length of the Value + field is determined by the Type and Length fields. + + Note that a "string" in RADIUS does not require termination by an + ASCII NUL because the Attribute already has a length field. + + + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 20] + +RFC 2138 RADIUS April 1997 + + + The format of the value field is one of four data types. + + string 0-253 octets + + address 32 bit value, most significant octet first. + + integer 32 bit value, most significant octet first. + + time 32 bit value, most significant octet first -- seconds + since 00:00:00 GMT, January 1, 1970. The standard + Attributes do not use this data type but it is presented + here for possible use within Vendor-Specific attributes. + + +5.1. User-Name + + Description + + This Attribute indicates the name of the user to be authenticated. + It is only used in Access-Request packets. + + A summary of the User-Name Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 1 for User-Name. + + Length + + >= 3 + + String + + The String field is one or more octets. The NAS may limit the + maximum length of the User-Name but the ability to handle at least + 63 octets is recommended. + + + + + + + + +Rigney, et. al. Standards Track [Page 21] + +RFC 2138 RADIUS April 1997 + + + The format of the username MAY be one of several forms: + + monolithic Consisting only of alphanumeric characters. This + simple form might be used to locally manage a NAS. + + simple Consisting only of printable ASCII characters. + + name@fqdn SMTP address. The Fully Qualified Domain Name (with or + without trailing dot) indicates the realm in which the + name part applies. + + distinguished name + A name in ASN.1 form used in Public Key authentication + systems. + +5.2. User-Password + + Description + + This Attribute indicates the password of the user to be + authenticated, or the user's input following an Access-Challenge. + It is only used in Access-Request packets. + + On transmission, the password is hidden. The password is first + padded at the end with nulls to a multiple of 16 octets. A one- + way MD5 hash is calculated over a stream of octets consisting of + the shared secret followed by the Request Authenticator. This + value is XORed with the first 16 octet segment of the password and + placed in the first 16 octets of the String field of the User- + Password Attribute. + + If the password is longer than 16 characters, a second one-way MD5 + hash is calculated over a stream of octets consisting of the + shared secret followed by the result of the first xor. That hash + is XORed with the second 16 octet segment of the password and + placed in the second 16 octets of the String field of the User- + Password Attribute. + + If necessary, this operation is repeated, with each xor result + being used along with the shared secret to generate the next hash + to xor the next segment of the password, to no more than 128 + characters. + + The method is taken from the book "Network Security" by Kaufman, + Perlman and Speciner [4] pages 109-110. A more precise + explanation of the method follows: + + + + + +Rigney, et. al. Standards Track [Page 22] + +RFC 2138 RADIUS April 1997 + + + Call the shared secret S and the pseudo-random 128-bit Request + Authenticator RA. Break the password into 16-octet chunks p1, p2, + etc. with the last one padded at the end with nulls to a 16-octet + boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need + intermediate values b1, b2, etc. + + b1 = MD5(S + RA) c(1) = p1 xor b1 + b2 = MD5(S + c(1)) c(2) = p2 xor b2 + . . + . . + . . + bi = MD5(S + c(i-1)) c(i) = pi xor bi + + The String will contain c(1)+c(2)+...+c(i) where + denotes + concatenation. + + On receipt, the process is reversed to yield the original + password. + + A summary of the User-Password Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 2 for User-Password. + + Length + + At least 18 and no larger than 130. + + String + + The String field is between 16 and 128 octets long, inclusive. + +5.3. CHAP-Password + + Description + + This Attribute indicates the response value provided by a PPP + Challenge-Handshake Authentication Protocol (CHAP) user in + response to the challenge. It is only used in Access-Request + packets. + + + +Rigney, et. al. Standards Track [Page 23] + +RFC 2138 RADIUS April 1997 + + + The CHAP challenge value is found in the CHAP-Challenge Attribute + (60) if present in the packet, otherwise in the Request + Authenticator field. + + A summary of the CHAP-Password Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | CHAP Ident | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 3 for CHAP-Password. + + Length + + 19 + + CHAP Ident + + This field is one octet, and contains the CHAP Identifier from the + user's CHAP Response. + + String + + The String field is 16 octets, and contains the CHAP Response from + the user. + +5.4. NAS-IP-Address + + Description + + This Attribute indicates the identifying IP Address of the NAS + which is requesting authentication of the user. It is only used + in Access-Request packets. Either NAS-IP-Address or NAS- + Identifier SHOULD be present in an Access-Request packet. + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 24] + +RFC 2138 RADIUS April 1997 + + + A summary of the NAS-IP-Address Attribute format is shown below. The + fields are transmitted from 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 4 for NAS-IP-Address. + + Length + + 6 + + Address + + The Address field is four octets. + +5.5. NAS-Port + + Description + + This Attribute indicates the physical port number of the NAS which + is authenticating the user. It is only used in Access-Request + packets. Note that this is using "port" in its sense of a + physical connection on the NAS, not in the sense of a TCP or UDP + port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD + be present in an Access-Request packet, if the NAS differentiates + among its ports. + + A summary of the NAS-Port Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 25] + +RFC 2138 RADIUS April 1997 + + + 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 5 for NAS-Port. + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 0 to 65535. + +5.6. Service-Type + + Description + + This Attribute indicates the type of service the user has + requested, or the type of service to be provided. It MAY be used + in both Access-Request and Access-Accept packets. A NAS is not + required to implement all of these service types, and MUST treat + unknown or unsupported Service-Types as though an Access-Reject + had been received instead. + + A summary of the Service-Type Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 6 for Service-Type. + + + + + +Rigney, et. al. Standards Track [Page 26] + +RFC 2138 RADIUS April 1997 + + + Length + + 6 + + Value + + The Value field is four octets. + + 1 Login + 2 Framed + 3 Callback Login + 4 Callback Framed + 5 Outbound + 6 Administrative + 7 NAS Prompt + 8 Authenticate Only + 9 Callback NAS Prompt + + + The service types are defined as follows when used in an Access- + Accept. When used in an Access-Request, they should be considered + to be a hint to the RADIUS server that the NAS has reason to + believe the user would prefer the kind of service indicated, but + the server is not required to honor the hint. + + Login The user should be connected to a host. + + Framed A Framed Protocol should be started for the + User, such as PPP or SLIP. + + Callback Login The user should be disconnected and called + back, then connected to a host. + + Callback Framed The user should be disconnected and called + back, then a Framed Protocol should be started + for the User, such as PPP or SLIP. + + Outbound The user should be granted access to outgoing + devices. + + Administrative The user should be granted access to the + administrative interface to the NAS from which + privileged commands can be executed. + + NAS Prompt The user should be provided a command prompt + on the NAS from which non-privileged commands + can be executed. + + + + +Rigney, et. al. Standards Track [Page 27] + +RFC 2138 RADIUS April 1997 + + + Authenticate Only Only Authentication is requested, and no + authorization information needs to be returned + in the Access-Accept (typically used by proxy + servers rather than the NAS itself). + + Callback NAS Prompt The user should be disconnected and called + back, then provided a command prompt on the + NAS from which non-privileged commands can be + executed. + +5.7. Framed-Protocol + + Description + + This Attribute indicates the framing to be used for framed access. + It MAY be used in both Access-Request and Access-Accept packets. + + A summary of the Framed-Protocol Attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 7 for Framed-Protocol. + + Length + + 6 + + Value + + The Value field is four octets. + + 1 PPP + 2 SLIP + 3 AppleTalk Remote Access Protocol (ARAP) + 4 Gandalf proprietary SingleLink/MultiLink protocol + 5 Xylogics proprietary IPX/SLIP + + + + + + +Rigney, et. al. Standards Track [Page 28] + +RFC 2138 RADIUS April 1997 + + +5.8. Framed-IP-Address + + Description + + This Attribute indicates the address to be configured for the + user. It MAY be used in Access-Accept packets. It MAY be used in + an Access-Request packet as a hint by the NAS to the server that + it would prefer that address, but the server is not required to + honor the hint. + + A summary of the Framed-IP-Address Attribute format is shown below. + The fields are transmitted from 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 8 for Framed-IP-Address. + + Length + + 6 + + Address + + The Address field is four octets. The value 0xFFFFFFFF indicates + that the NAS should allow the user to select an address (e.g. + Negotiated). The value 0xFFFFFFFE indicates that the NAS should + select an address for the user (e.g. Assigned from a pool of + addresses kept by the NAS). Other valid values indicate that the + NAS should use that value as the user's IP address. + +5.9. Framed-IP-Netmask + + Description + + This Attribute indicates the IP netmask to be configured for the + user when the user is a router to a network. It MAY be used in + Access-Accept packets. It MAY be used in an Access-Request packet + as a hint by the NAS to the server that it would prefer that + netmask, but the server is not required to honor the hint. + + + + +Rigney, et. al. Standards Track [Page 29] + +RFC 2138 RADIUS April 1997 + + + A summary of the Framed-IP-Netmask Attribute format is shown below. + The fields are transmitted from 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 9 for Framed-IP-Netmask. + + Length + + 6 + + Address + + The Address field is four octets specifying the IP netmask of the + user. + +5.10. Framed-Routing + + Description + + This Attribute indicates the routing method for the user, when the + user is a router to a network. It is only used in Access-Accept + packets. + + A summary of the Framed-Routing Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 10 for Framed-Routing. + + + + + +Rigney, et. al. Standards Track [Page 30] + +RFC 2138 RADIUS April 1997 + + + Length + + 6 + + Value + + The Value field is four octets. + + 0 None + 1 Send routing packets + 2 Listen for routing packets + 3 Send and Listen + +5.11. Filter-Id + + Description + + This Attribute indicates the name of the filter list for this + user. Zero or more Filter-Id attributes MAY be sent in an + Access-Accept packet. + + Identifying a filter list by name allows the filter to be used on + different NASes without regard to filter-list implementation + details. + + A summary of the Filter-Id Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 11 for Filter-Id. + + Length + + >= 3 + + + + + + + + + + +Rigney, et. al. Standards Track [Page 31] + +RFC 2138 RADIUS April 1997 + + + String + + The String field is one or more octets, and its contents are + implementation dependent. It is intended to be human readable and + MUST NOT affect operation of the protocol. It is recommended that + the message contain displayable ASCII characters from the range 32 + through 126 decimal. + +5.12. Framed-MTU + + Description + + This Attribute indicates the Maximum Transmission Unit to be + configured for the user, when it is not negotiated by some other + means (such as PPP). It is only used in Access-Accept packets. + + A summary of the Framed-MTU Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 12 for Framed-MTU. + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 64 to 65535. + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 32] + +RFC 2138 RADIUS April 1997 + + +5.13. Framed-Compression + + Description + + This Attribute indicates a compression protocol to be used for the + link. It MAY be used in Access-Accept packets. It MAY be used in + an Access-Request packet as a hint to the server that the NAS + would prefer to use that compression, but the server is not + required to honor the hint. + + More than one compression protocol Attribute MAY be sent. It is + the responsibility of the NAS to apply the proper compression + protocol to appropriate link traffic. + + A summary of the Framed-Compression Attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 13 for Framed-Compression. + + Length + + 6 + + Value + + The Value field is four octets. + + 0 None + 1 VJ TCP/IP header compression [5] + 2 IPX header compression + +5.14. Login-IP-Host + + Description + + This Attribute indicates the system with which to connect the + user, when the Login-Service Attribute is included. It MAY be + used in Access-Accept packets. It MAY be used in an Access- + + + +Rigney, et. al. Standards Track [Page 33] + +RFC 2138 RADIUS April 1997 + + + Request packet as a hint to the server that the NAS would prefer + to use that host, but the server is not required to honor the + hint. + + A summary of the Login-IP-Host Attribute format is shown below. The + fields are transmitted from 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 14 for Login-IP-Host. + + Length + + 6 + + Address + + The Address field is four octets. The value 0xFFFFFFFF indicates + that the NAS SHOULD allow the user to select an address. The + value 0 indicates that the NAS SHOULD select a host to connect the + user to. Other values indicate the address the NAS SHOULD connect + the user to. + +5.15. Login-Service + + Description + + This Attribute indicates the service which should be used to + connect the user to the login host. It is only used in Access- + Accept packets. + + A summary of the Login-Service Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + + + + + +Rigney, et. al. Standards Track [Page 34] + +RFC 2138 RADIUS April 1997 + + + 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 15 for Login-Service. + + Length + + 6 + + Value + + The Value field is four octets. + + 0 Telnet + 1 Rlogin + 2 TCP Clear + 3 PortMaster (proprietary) + 4 LAT + +5.16. Login-TCP-Port + + Description + + This Attribute indicates the TCP port with which the user is to be + connected, when the Login-Service Attribute is also present. It + is only used in Access-Accept packets. + + A summary of the Login-TCP-Port Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 16 for Login-TCP-Port. + + + +Rigney, et. al. Standards Track [Page 35] + +RFC 2138 RADIUS April 1997 + + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 0 to 65535. + +5.17. (unassigned) + + Description + + ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED. + +5.18. Reply-Message + + Description + + This Attribute indicates text which MAY be displayed to the user. + + When used in an Access-Accept, it is the success message. + + When used in an Access-Reject, it is the failure message. It MAY + indicate a dialog message to prompt the user before another + Access-Request attempt. + + When used in an Access-Challenge, it MAY indicate a dialog message + to prompt the user for a response. + + Multiple Reply-Message's MAY be included and if any are displayed, + they MUST be displayed in the same order as they appear in the + packet. + + A summary of the Reply-Message Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + Type + + 18 for Reply-Message. + + + + +Rigney, et. al. Standards Track [Page 36] + +RFC 2138 RADIUS April 1997 + + + Length + + >= 3 + + String + + The String field is one or more octets, and its contents are + implementation dependent. It is intended to be human readable, + and MUST NOT affect operation of the protocol. It is recommended + that the message contain displayable ASCII characters from the + range 10, 13, and 32 through 126 decimal. Mechanisms for + extension to other character sets are beyond the scope of this + specification. + +5.19. Callback-Number + + Description + + This Attribute indicates a dialing string to be used for callback. + It MAY be used in Access-Accept packets. It MAY be used in an + Access-Request packet as a hint to the server that a Callback + service is desired, but the server is not required to honor the + hint. + + A summary of the Callback-Number Attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 19 for Callback-Number. + + Length + + >= 3 + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 37] + +RFC 2138 RADIUS April 1997 + + + String + + The String field is one or more octets. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.20. Callback-Id + + Description + + This Attribute indicates the name of a place to be called, to be + interpreted by the NAS. It MAY be used in Access-Accept packets. + + A summary of the Callback-Id Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 20 for Callback-Id. + + Length + + >= 3 + + String + + The String field is one or more octets. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.21. (unassigned) + + Description + + ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED. + + + + + +Rigney, et. al. Standards Track [Page 38] + +RFC 2138 RADIUS April 1997 + + +5.22. Framed-Route + + Description + + This Attribute provides routing information to be configured for + the user on the NAS. It is used in the Access-Accept packet and + can appear multiple times. + + A summary of the Framed-Route Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 22 for Framed-Route. + + Length + + >= 3 + + String + + The String field is one or more octets, and its contents are + implementation dependent. It is intended to be human readable and + MUST NOT affect operation of the protocol. It is recommended that + the message contain displayable ASCII characters from the range 32 + through 126 decimal. + + For IP routes, it SHOULD contain a destination prefix in dotted + quad form optionally followed by a slash and a decimal length + specifier stating how many high order bits of the prefix should be + used. That is followed by a space, a gateway address in dotted + quad form, a space, and one or more metrics separated by spaces. + For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length + specifier may be omitted in which case it should default to 8 bits + for class A prefixes, 16 bits for class B prefixes, and 24 bits + for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". + + Whenever the gateway address is specified as "0.0.0.0" the IP + address of the user SHOULD be used as the gateway address. + + + + + + +Rigney, et. al. Standards Track [Page 39] + +RFC 2138 RADIUS April 1997 + + +5.23. Framed-IPX-Network + + Description + + This Attribute indicates the IPX Network number to be configured + for the user. It is used in Access-Accept packets. + + A summary of the Framed-IPX-Network Attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 23 for Framed-IPX-Network. + + Length + + 6 + + Value + + The Value field is four octets. The value 0xFFFFFFFE indicates + that the NAS should select an IPX network for the user (e.g. + assigned from a pool of one or more IPX networks kept by the NAS). + Other values should be used as the IPX network for the link to the + user. + +5.24. State + + Description + + This Attribute is available to be sent by the server to the client + in an Access-Challenge and MUST be sent unmodified from the client + to the server in the new Access-Request reply to that challenge, + if any. + + + + + + + + + +Rigney, et. al. Standards Track [Page 40] + +RFC 2138 RADIUS April 1997 + + + This Attribute is available to be sent by the server to the client + in an Access-Accept that also includes a Termination-Action + Attribute with the value of RADIUS-Request. If the NAS performs + the Termination-Action by sending a new Access-Request upon + termination of the current session, it MUST include the State + attribute unchanged in that Access-Request. + + In either usage, no interpretation by the client should be made. + A packet may have only one State Attribute. Usage of the State + Attribute is implementation dependent. + + A summary of the State Attribute format is shown below. The fields + are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 24 for State. + + Length + + >= 3 + + String + + The String field is one or more octets. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.25. Class + + Description + + This Attribute is available to be sent by the server to the client + in an Access-Accept and should be sent unmodified by the client to + the accounting server as part of the Accounting-Request packet if + accounting is supported. No interpretation by the client should + be made. + + + + + +Rigney, et. al. Standards Track [Page 41] + +RFC 2138 RADIUS April 1997 + + + A summary of the Class Attribute format is shown below. The fields + are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 25 for Class. + + Length + + >= 3 + + String + + The String field is one or more octets. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.26. Vendor-Specific + + Description + + This Attribute is available to allow vendors to support their own + extended Attributes not suitable for general usage. It MUST not + affect the operation of the RADIUS protocol. + + Servers not equipped to interpret the vendor-specific information + sent by a client MUST ignore it (although it may be reported). + Clients which do not receive desired vendor-specific information + SHOULD make an attempt to operate without it, although they may do + so (and report they are doing so) in a degraded mode. + + A summary of the Vendor-Specific Attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + + +Rigney, et. al. Standards Track [Page 42] + +RFC 2138 RADIUS April 1997 + + + 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 | Vendor-Id + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Vendor-Id (cont) | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 26 for Vendor-Specific. + + Length + + >= 7 + + Vendor-Id + + The high-order octet is 0 and the low-order 3 octets are the SMI + Network Management Private Enterprise Code of the Vendor in + network byte order, as defined in the Assigned Numbers RFC [3]. + + String + + The String field is one or more octets. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + + It SHOULD be encoded as a sequence of vendor type / vendor length + / value fields, as follows. The Attribute-Specific field is + dependent on the vendor's definition of that attribute. An + example encoding of the Vendor-Specific attribute using this + method follows: + + 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 | Vendor-Id + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Vendor-Id (cont) | Vendor type | Vendor length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute-Specific... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + + + +Rigney, et. al. Standards Track [Page 43] + +RFC 2138 RADIUS April 1997 + + +5.27. Session-Timeout + + Description + + This Attribute sets the maximum number of seconds of service to be + provided to the user before termination of the session or prompt. + This Attribute is available to be sent by the server to the client + in an Access-Accept or Access-Challenge. + + A summary of the Session-Timeout Attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 27 for Session-Timeout. + + Length + + 6 + + Value + + The field is 4 octets, containing a 32-bit unsigned integer with + the maximum number of seconds this user should be allowed to + remain connected by the NAS. + +5.28. Idle-Timeout + + Description + + This Attribute sets the maximum number of consecutive seconds of + idle connection allowed to the user before termination of the + session or prompt. This Attribute is available to be sent by the + server to the client in an Access-Accept or Access-Challenge. + + + + + + + + + +Rigney, et. al. Standards Track [Page 44] + +RFC 2138 RADIUS April 1997 + + + A summary of the Idle-Timeout Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 28 for Idle-Timeout. + + Length + + 6 + + Value + + The field is 4 octets, containing a 32-bit unsigned integer with + the maximum number of consecutive seconds of idle time this user + should be permitted before being disconnected by the NAS. + +5.29. Termination-Action + + Description + + This Attribute indicates what action the NAS should take when the + specified service is completed. It is only used in Access-Accept + packets. + + A summary of the Termination-Action Attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 29 for Termination-Action. + + + + +Rigney, et. al. Standards Track [Page 45] + +RFC 2138 RADIUS April 1997 + + + Length + + 6 + + Value + + The Value field is four octets. + + 0 Default + 1 RADIUS-Request + + If the Value is set to RADIUS-Request, upon termination of the + specified service the NAS MAY send a new Access-Request to the + RADIUS server, including the State attribute if any. + +5.30. Called-Station-Id + + Description + + This Attribute allows the NAS to send in the Access-Request packet + the phone number that the user called, using Dialed Number + Identification (DNIS) or similar technology. Note that this may be + different from the phone number the call comes in on. It is only + used in Access-Request packets. + + A summary of the Called-Station-Id Attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + Type + + 30 for Called-Station-Id. + + Length + + >= 3 + + String + + The String field is one or more octets, containing the phone + number that the user's call came in on. + + + + +Rigney, et. al. Standards Track [Page 46] + +RFC 2138 RADIUS April 1997 + + + The actual format of the information is site or application + specific. Printable ASCII is recommended, but a robust + implementation SHOULD support the field as undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.31. Calling-Station-Id + + Description + + This Attribute allows the NAS to send in the Access-Request packet + the phone number that the call came from, using Automatic Number + Identification (ANI) or similar technology. It is only used in + Access-Request packets. + + A summary of the Calling-Station-Id Attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 31 for Calling-Station-Id. + + Length + + >= 3 + + String + + The String field is one or more octets, containing the phone + number that the user placed the call from. + + The actual format of the information is site or application + specific. Printable ASCII is recommended, but a robust + implementation SHOULD support the field as undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + + + + + + + +Rigney, et. al. Standards Track [Page 47] + +RFC 2138 RADIUS April 1997 + + +5.32. NAS-Identifier + + Description + + This Attribute contains a string identifying the NAS originating + the Access-Request. It is only used in Access-Request packets. + Either NAS-IP-Address or NAS-Identifier SHOULD be present in an + Access-Request packet. + + A summary of the NAS-Identifier Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 32 for NAS-Identifier. + + Length + + >= 3 + + String + + The String field is one or more octets, and should be unique to + the NAS within the scope of the RADIUS server. For example, a + fully qualified domain name would be suitable as a NAS-Identifier. + + The actual format of the information is site or application + specific, and a robust implementation SHOULD support the field as + undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.33. Proxy-State + + Description + + This Attribute is available to be sent by a proxy server to + another server when forwarding an Access-Request and MUST be + returned unmodified in the Access-Accept, Access-Reject or + Access-Challenge. This attribute should be removed by the proxy + server before the response is forwarded to the NAS. + + + +Rigney, et. al. Standards Track [Page 48] + +RFC 2138 RADIUS April 1997 + + + Usage of the Proxy-State Attribute is implementation dependent. A + description of its function is outside the scope of this + specification. + + A summary of the Proxy-State Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 33 for Proxy-State. + + Length + + >= 3 + + String + + The String field is one or more octets. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.34. Login-LAT-Service + + Description + + This Attribute indicates the system with which the user is to be + connected by LAT. It MAY be used in Access-Accept packets, but + only when LAT is specified as the Login-Service. It MAY be used + in an Access-Request packet as a hint to the server, but the + server is not required to honor the hint. + + Administrators use the service attribute when dealing with + clustered systems, such as a VAX or Alpha cluster. In such an + environment several different time sharing hosts share the same + resources (disks, printers, etc.), and administrators often + configure each to offer access (service) to each of the shared + resources. In this case, each host in the cluster advertises its + services through LAT broadcasts. + + + + +Rigney, et. al. Standards Track [Page 49] + +RFC 2138 RADIUS April 1997 + + + Sophisticated users often know which service providers (machines) + are faster and tend to use a node name when initiating a LAT + connection. Alternately, some administrators want particular + users to use certain machines as a primitive form of load + balancing (although LAT knows how to do load balancing itself). + + A summary of the Login-LAT-Service Attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + Type + + 34 for Login-LAT-Service. + + Length + + >= 3 + + String + + The String field is one or more octets, and contains the identity + of the LAT service to use. The LAT Architecture allows this + string to contain $ (dollar), - (hyphen), . (period), _ + (underscore), numerics, upper and lower case alphabetics, and the + ISO Latin-1 character set extension [6]. All LAT string + comparisons are case insensitive. + +5.35. Login-LAT-Node + + Description + + This Attribute indicates the Node with which the user is to be + automatically connected by LAT. It MAY be used in Access-Accept + packets, but only when LAT is specified as the Login-Service. It + MAY be used in an Access-Request packet as a hint to the server, + but the server is not required to honor the hint. + + A summary of the Login-LAT-Node Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + +Rigney, et. al. Standards Track [Page 50] + +RFC 2138 RADIUS April 1997 + + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 35 for Login-LAT-Node. + + Length + + >= 3 + + String + + The String field is one or more octets, and contains the identity + of the LAT Node to connect the user to. The LAT Architecture + allows this string to contain $ (dollar), - (hyphen), . (period), + _ (underscore), numerics, upper and lower case alphabetics, and + the ISO Latin-1 character set extension. All LAT string + comparisons are case insensitive. + +5.36. Login-LAT-Group + + Description + + This Attribute contains a string identifying the LAT group codes + which this user is authorized to use. It MAY be used in Access- + Accept packets, but only when LAT is specified as the Login- + Service. It MAY be used in an Access-Request packet as a hint to + the server, but the server is not required to honor the hint. + + LAT supports 256 different group codes, which LAT uses as a form + of access rights. LAT encodes the group codes as a 256 bit + bitmap. + + Administrators can assign one or more of the group code bits at + the LAT service provider; it will only accept LAT connections that + have these group codes set in the bit map. The administrators + assign a bitmap of authorized group codes to each user; LAT gets + these from the operating system, and uses these in its requests to + the service providers. + + + + + + + + +Rigney, et. al. Standards Track [Page 51] + +RFC 2138 RADIUS April 1997 + + + A summary of the Login-LAT-Group Attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 36 for Login-LAT-Group. + + Length + + 34 + + String + + The String field is a 32 octet bit map, most significant octet + first. A robust implementation SHOULD support the field as + undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.37. Framed-AppleTalk-Link + + Description + + This Attribute indicates the AppleTalk network number which should + be used for the serial link to the user, which is another + AppleTalk router. It is only used in Access-Accept packets. It + is never used when the user is not another router. + + A summary of the Framed-AppleTalk-Link Attribute format is shown + below. The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Rigney, et. al. Standards Track [Page 52] + +RFC 2138 RADIUS April 1997 + + + Type + + 37 for Framed-AppleTalk-Link. + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 0 to 65535. The special value of 0 indicates + that this is an unnumbered serial link. A value of 1-65535 means + that the serial line between the NAS and the user should be + assigned that value as an AppleTalk network number. + +5.38. Framed-AppleTalk-Network + + Description + + This Attribute indicates the AppleTalk Network number which the + NAS should probe to allocate an AppleTalk node for the user. It + is only used in Access-Accept packets. It is never used when the + user is another router. Multiple instances of this Attribute + indicate that the NAS may probe using any of the network numbers + specified. + + A summary of the Framed-AppleTalk-Network Attribute format is shown + below. The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 38 for Framed-AppleTalk-Network. + + Length + + 6 + + + + + + +Rigney, et. al. Standards Track [Page 53] + +RFC 2138 RADIUS April 1997 + + + Value + + The Value field is four octets. Despite the size of the field, + values range from 0 to 65535. The special value 0 indicates that + the NAS should assign a network for the user, using its default + cable range. A value between 1 and 65535 (inclusive) indicates + the AppleTalk Network the NAS should probe to find an address for + the user. + +5.39. Framed-AppleTalk-Zone + + Description + + This Attribute indicates the AppleTalk Default Zone to be used for + this user. It is only used in Access-Accept packets. Multiple + instances of this attribute in the same packet are not allowed. + + A summary of the Framed-AppleTalk-Zone Attribute format is shown + below. The fields are transmitted from left to right. + + 0 1 2 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 39 for Framed-AppleTalk-Zone. + + Length + + >= 3 + + String + + The name of the Default AppleTalk Zone to be used for this user. + A robust implementation SHOULD support the field as + undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + + + + + + + + + +Rigney, et. al. Standards Track [Page 54] + +RFC 2138 RADIUS April 1997 + + +5.40. CHAP-Challenge + + Description + + This Attribute contains the CHAP Challenge sent by the NAS to a + PPP Challenge-Handshake Authentication Protocol (CHAP) user. It + is only used in Access-Request packets. + + If the CHAP challenge value is 16 octets long it MAY be placed in + the Request Authenticator field instead of using this attribute. + + A summary of the CHAP-Challenge Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 60 for CHAP-Challenge. + + Length + + >= 7 + + String + + The String field contains the CHAP Challenge. + +5.41. NAS-Port-Type + + Description + + This Attribute indicates the type of the physical port of the NAS + which is authenticating the user. It can be used instead of or in + addition to the NAS-Port (5) attribute. It is only used in + Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or + both SHOULD be present in an Access-Request packet, if the NAS + differentiates among its ports. + + + + + + + + + +Rigney, et. al. Standards Track [Page 55] + +RFC 2138 RADIUS April 1997 + + + A summary of the NAS-Port-Type Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 61 for NAS-Port-Type. + + Length + + 6 + + Value + + The Value field is four octets. "Virtual" refers to a connection + to the NAS via some transport protocol, instead of through a + physical port. For example, if a user telnetted into a NAS to + authenticate himself as an Outbound-User, the Access-Request might + include NAS-Port-Type = Virtual as a hint to the RADIUS server + that the user was not on a physical port. + + 0 Async + 1 Sync + 2 ISDN Sync + 3 ISDN Async V.120 + 4 ISDN Async V.110 + 5 Virtual + +5.42. Port-Limit + + Description + + This Attribute sets the maximum number of ports to be provided to + the user by the NAS. This Attribute MAY be sent by the server to + the client in an Access-Accept packet. It is intended for use in + conjunction with Multilink PPP [7] or similar uses. It MAY also + be sent by the NAS to the server as a hint that that many ports + are desired for use, but the server is not required to honor the + hint. + + + + + +Rigney, et. al. Standards Track [Page 56] + +RFC 2138 RADIUS April 1997 + + + A summary of the Port-Limit Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 62 for Port-Limit. + + Length + + 6 + + Value + + The field is 4 octets, containing a 32-bit unsigned integer with + the maximum number of ports this user should be allowed to connect + to on the NAS. + +5.43. Login-LAT-Port + + Description + + This Attribute indicates the Port with which the user is to be + connected by LAT. It MAY be used in Access-Accept packets, but + only when LAT is specified as the Login-Service. It MAY be used + in an Access-Request packet as a hint to the server, but the + server is not required to honor the hint. + + A summary of the Login-LAT-Port Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 63 for Login-LAT-Port. + + + + +Rigney, et. al. Standards Track [Page 57] + +RFC 2138 RADIUS April 1997 + + + Length + + >= 3 + + String + + The String field is one or more octets, and contains the identity + of the LAT port to use. The LAT Architecture allows this string + to contain $ (dollar), - (hyphen), . (period), _ (underscore), + numerics, upper and lower case alphabetics, and the ISO Latin-1 + character set extension. All LAT string comparisons are case + insensitive. + +5.44. Table of Attributes + + The following table provides a guide to which attributes may be found + in which kinds of packets, and in what quantity. + + Request Accept Reject Challenge # Attribute + 1 0 0 0 1 User-Name + 0-1 0 0 0 2 User-Password [Note 1] + 0-1 0 0 0 3 CHAP-Password [Note 1] + 0-1 0 0 0 4 NAS-IP-Address + 0-1 0 0 0 5 NAS-Port + 0-1 0-1 0 0 6 Service-Type + 0-1 0-1 0 0 7 Framed-Protocol + 0-1 0-1 0 0 8 Framed-IP-Address + 0-1 0-1 0 0 9 Framed-IP-Netmask + 0 0-1 0 0 10 Framed-Routing + 0 0+ 0 0 11 Filter-Id + 0 0-1 0 0 12 Framed-MTU + 0+ 0+ 0 0 13 Framed-Compression + 0+ 0+ 0 0 14 Login-IP-Host + 0 0-1 0 0 15 Login-Service + 0 0-1 0 0 16 Login-TCP-Port + 0 0+ 0+ 0+ 18 Reply-Message + 0-1 0-1 0 0 19 Callback-Number + 0 0-1 0 0 20 Callback-Id + 0 0+ 0 0 22 Framed-Route + 0 0-1 0 0 23 Framed-IPX-Network + 0-1 0-1 0 0-1 24 State + 0 0+ 0 0 25 Class + 0+ 0+ 0 0+ 26 Vendor-Specific + 0 0-1 0 0-1 27 Session-Timeout + 0 0-1 0 0-1 28 Idle-Timeout + 0 0-1 0 0 29 Termination-Action + 0-1 0 0 0 30 Called-Station-Id + 0-1 0 0 0 31 Calling-Station-Id + + + +Rigney, et. al. Standards Track [Page 58] + +RFC 2138 RADIUS April 1997 + + + 0-1 0 0 0 32 NAS-Identifier + 0+ 0+ 0+ 0+ 33 Proxy-State + 0-1 0-1 0 0 34 Login-LAT-Service + 0-1 0-1 0 0 35 Login-LAT-Node + 0-1 0-1 0 0 36 Login-LAT-Group + 0 0-1 0 0 37 Framed-AppleTalk-Link + 0 0+ 0 0 38 Framed-AppleTalk-Network + 0 0-1 0 0 39 Framed-AppleTalk-Zone + 0-1 0 0 0 60 CHAP-Challenge + 0-1 0 0 0 61 NAS-Port-Type + 0-1 0-1 0 0 62 Port-Limit + 0-1 0-1 0 0 63 Login-LAT-Port + + + Request Accept Reject Challenge # Attribute + + + [Note 1] An Access-Request MUST contain either a User-Password or a + CHAP-Password, and MUST NOT contain both. + + The following table defines the meaning of the above table entries. + + 0 This attribute MUST NOT be present in packet. + 0+ Zero or more instances of this attribute MAY be present in packet. + 0-1 Zero or one instance of this attribute MAY be present in packet. + 1 Exactly one instance of this attribute MUST be present in packet. + +6. Examples + + A few examples are presented to illustrate the flow of packets and + use of typical attributes. These examples are not intended to be + exhaustive, many others are possible. + + + + + + + + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 59] + +RFC 2138 RADIUS April 1997 + + +6.1. User Telnet to Specified Host + + The NAS at 192.168.1.16 sends an Access-Request UDP packet to the + RADIUS Server for a user named nemo logging in on port 3. + + Code = 1 (Access-Request) + ID = 0 + Length = 56 + Request Authenticator = {16 octet random number} + Attributes: + User-Name = "nemo" + User-Password = {16 octets of Password padded at end with nulls, + XORed with MD5(shared secret|Request Authenticator)} + NAS-IP-Address = 192.168.1.16 + NAS-Port = 3 + + The RADIUS server authenticates nemo, and sends an Access-Accept UDP + packet to the NAS telling it to telnet nemo to host 192.168.1.3. + + Code = 2 (Access-Accept) + ID = 0 (same as in Access-Request) + Length = 38 + Response Authenticator = {16-octet MD-5 checksum of the code (2), + id (0), Length (38), the Request Authenticator from + above, the attributes in this reply, and the shared + secret} + Attributes: + Service-Type = Login-User + Login-Service = Telnet + Login-Host = 192.168.1.3 + +6.2. Framed User Authenticating with CHAP + + The NAS at 192.168.1.16 sends an Access-Request UDP packet to the + RADIUS Server for a user named flopsy logging in on port 20 with PPP, + authenticating using CHAP. The NAS sends along the Service-Type and + Framed-Protocol attributes as a hint to the RADIUS server that this + user is looking for PPP, although the NAS is not required to do so. + + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 60] + +RFC 2138 RADIUS April 1997 + + + Code = 1 (Access-Request) + ID = 1 + Length = 71 + Request Authenticator = {16 octet random number also used as + CHAP challenge} + Attributes: + User-Name = "flopsy" + CHAP-Password = {1 octet CHAP ID followed by 16 octet + CHAP response} + NAS-IP-Address = 192.168.1.16 + NAS-Port = 20 + Service-Type = Framed-User + Framed-Protocol = PPP + + The RADIUS server authenticates flopsy, and sends an Access-Accept + UDP packet to the NAS telling it to start PPP service and assign an + address for the user out of its dynamic address pool. + + Code = 2 (Access-Accept) + ID = 1 (same as in Access-Request) + Length = 56 + Response Authenticator = {16-octet MD-5 checksum of the code (2), + id (1), Length (56), the Request Authenticator from + above, the attributes in this reply, and the shared + secret} + Attributes: + Service-Type = Framed-User + Framed-Protocol = PPP + Framed-IP-Address = 255.255.255.254 + Framed-Routing = None + Framed-Compression = 1 (VJ TCP/IP Header Compression) + Framed-MTU = 1500 + +6.3. User with Challenge-Response card + + The NAS at 192.168.1.16 sends an Access-Request UDP packet to the + RADIUS Server for a user named mopsy logging in on port 7. + + Code = 1 (Access-Request) + ID = 2 + Length = 57 + Request Authenticator = {16 octet random number} + Attributes: + User-Name = "mopsy" + User-Password = {16 octets of Password padded at end with nulls, + XORed with MD5(shared secret|Request Authenticator)} + NAS-IP-Address = 192.168.1.16 + NAS-Port = 7 + + + +Rigney, et. al. Standards Track [Page 61] + +RFC 2138 RADIUS April 1997 + + + The RADIUS server decides to challenge mopsy, sending back a + challenge string and looking for a response. The RADIUS server + therefore and sends an Access-Challenge UDP packet to the NAS. + + Code = 11 (Access-Challenge} + ID = 2 (same as in Access-Request) + Length = 78 + Response Authenticator = {16-octet MD-5 checksum of the code (11), + id (2), length (78), the Request Authenticator from + above, the attributes in this reply, and the shared + secret} + Attributes: + Reply-Message = "Challenge 32769430. Enter response at prompt." + State = {Magic Cookie to be returned along with user's response; + in this example 8 octets of data} + + The user enters his response, and the NAS send a new Access-Request + with that response, and includes the State Attribute. + + Code = 1 (Access-Request) + ID = 3 (Note that this changes) + Length = 67 + Request Authenticator = {NEW 16 octet random number} + Attributes: + User-Name = "mopsy" + User-Password = {16 octets of Response padded at end with + nulls, XORed with MD5 checksum of shared secret + plus above Request Authenticator} + NAS-IP-Address = 192.168.1.16 + NAS-Port = 7 + State = {Magic Cookie from Access-Challenge packet, unchanged} + + The Response was incorrect, so the RADIUS server tells the NAS to + reject the login attempt. + + Code = 3 (Access-Reject) + ID = 3 (same as in Access-Request) + Length = 20 + Response Authenticator = {16-octet MD-5 checksum of the code (3), + id (3), length(20), the Request Authenticator from + above, the attributes in this reply if any, and the + shared secret} + Attributes: + (none, although a Reply-Message could be sent) + + + + + + + +Rigney, et. al. Standards Track [Page 62] + +RFC 2138 RADIUS April 1997 + + +Security Considerations + + Security issues are the primary topic of this document. + + In practice, within or associated with each RADIUS server, there is a + database which associates "user" names with authentication + information ("secrets"). It is not anticipated that a particular + named user would be authenticated by multiple methods. This would + make the user vulnerable to attacks which negotiate the least secure + method from among a set. Instead, for each named user there should + be an indication of exactly one method used to authenticate that user + name. If a user needs to make use of different authentication + methods under different circumstances, then distinct user names + SHOULD be employed, each of which identifies exactly one + authentication method. + + Passwords and other secrets should be stored at the respective ends + such that access to them is as limited as possible. Ideally, the + secrets should only be accessible to the process requiring access in + order to perform the authentication. + + The secrets should be distributed with a mechanism that limits the + number of entities that handle (and thus gain knowledge of) the + secret. Ideally, no unauthorized person should ever gain knowledge + of the secrets. It is possible to achieve this with SNMP Security + Protocols [8], but such a mechanism is outside the scope of this + specification. + + Other distribution methods are currently undergoing research and + experimentation. The SNMP Security document [8] also has an + excellent overview of threats to network protocols. + + + + + + + + + + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 63] + +RFC 2138 RADIUS April 1997 + + +References + + [1] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", + RFC 1321, MIT Laboratory for Computer Science, RSA Data + Security Inc., April 1992. + + [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + USC/Information Sciences Institute, August 1980. + + [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC + 1700, USC/Information Sciences Institute, October 1994. + + [4] Kaufman, C., Perlman, R., and Speciner, M., "Network Security: + Private Communications in a Public World", Prentice Hall, March + 1995, ISBN 0-13-061466-1. + + [5] Jacobson, V., "Compressing TCP/IP headers for low-speed serial + links", RFC 1144, Lawrence Berkeley Laboratory, February 1990. + + [6] ISO 8859. International Standard -- Information Processing -- + 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin + Alphabet No. 1, ISO 8859-1:1987. + <URL:http://www.iso.ch/cate/d16338.html> + + [7] Sklower, K., Lloyd, B., McGregor, G., and Carr, D., "The PPP + Multilink Protocol (MP)", RFC 1717, University of California + Berkeley, Lloyd Internetworking, Newbridge Networks + Corporation, November 1994. + + [8] Galvin, J., McCloghrie, K., and Davin, J., "SNMP Security + Protocols", RFC 1352, Trusted Information Systems, Inc., Hughes + LAN Systems, Inc., MIT Laboratory for Computer Science, July + 1992. + + [9] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. + +Acknowledgments + + RADIUS was originally developed by Livingston Enterprises for their + PortMaster series of Network Access Servers. + + + + + + + + + + + +Rigney, et. al. Standards Track [Page 64] + +RFC 2138 RADIUS April 1997 + + +Chair's Address + + The working group can be contacted via the current chair: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + Phone: +1 510 426 0770 + EMail: cdr@livingston.com + +Authors' Addresses + + Questions about this memo can also be directed to: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + Phone: +1 510 426 0770 + EMail: cdr@livingston.com + + Allan C. Rubens + Merit Network, Inc. + 4251 Plymouth Road + Ann Arbor, Michigan 48105-2785 + + EMail: acr@merit.edu + + William Allen Simpson + Daydreamer + Computer Systems Consulting Services + 1384 Fontaine + Madison Heights, Michigan 48071 + + EMail: wsimpson@greendragon.com + + Steve Willens + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + EMail: steve@livingston.com + + + + + + +Rigney, et. al. Standards Track [Page 65] + diff --git a/rfc/rfc2139.txt b/rfc/rfc2139.txt new file mode 100644 index 00000000..88c5af8d --- /dev/null +++ b/rfc/rfc2139.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group C. Rigney +Request for Comments: 2139 Livingston +Obsoletes: 2059 April 1997 +Category: Informational + + + RADIUS Accounting + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This document describes a protocol for carrying accounting + information between a Network Access Server and a shared Accounting + Server. + +Implementation Note + + This memo documents the RADIUS Accounting protocol. There has been + some confusion in the assignment of port numbers for this protocol. + The early deployment of RADIUS Accounting was done using the + erroneously chosen port number 1646, which conflicts with the "sa- + msg-port" service. The officially assigned port number for RADIUS + Accounting is 1813. + +Table of Contents + + 1. Introduction .......................................... 2 + 1.1 Specification of Requirements ................... 3 + 1.2 Terminology ..................................... 3 + 2. Operation ............................................. 4 + 3. Packet Format ......................................... 5 + 4. Packet Types .......................................... 7 + 4.1 Accounting-Request .............................. 7 + 4.2 Accounting-Response ............................. 8 + 5. Attributes ............................................ 10 + 5.1 Acct-Status-Type ................................ 11 + 5.2 Acct-Delay-Time ................................. 12 + 5.3 Acct-Input-Octets ............................... 13 + 5.4 Acct-Output-Octets .............................. 14 + 5.5 Acct-Session-Id ................................. 14 + 5.6 Acct-Authentic .................................. 15 + 5.7 Acct-Session-Time ............................... 16 + 5.8 Acct-Input-Packets .............................. 16 + + + +Rigney Informational [Page 1] + +RFC 2139 RADIUS Accounting April 1997 + + + 5.9 Acct-Output-Packets ............................. 17 + 5.10 Acct-Terminate-Cause ............................ 18 + 5.11 Acct-Multi-Session-Id ........................... 20 + 5.12 Acct-Link-Count ................................. 21 + 5.13 Table of Attributes ............................. 22 + Security Considerations ...................................... 24 + References ................................................... 24 + Acknowledgements ............................................. 24 + Chair's Address .............................................. 24 + Author's Address ............................................. 25 + +1. Introduction + + Managing dispersed serial line and modem pools for large numbers of + users can create the need for significant administrative support. + Since modem pools are by definition a link to the outside world, they + require careful attention to security, authorization and accounting. + This can be best achieved by managing a single "database" of users, + which allows for authentication (verifying user name and password) as + well as configuration information detailing the type of service to + deliver to the user (for example, SLIP, PPP, telnet, rlogin). + + The RADIUS (Remote Authentication Dial In User Service) document [4] + specifies the RADIUS protocol used for Authentication and + Authorization. This memo extends the use of the RADIUS protocol to + cover delivery of accounting information from the Network Access + Server (NAS) to a RADIUS accounting server. + + Key features of RADIUS Accounting are: + + Client/Server Model + + A Network Access Server (NAS) operates as a client of the + RADIUS accounting server. The client is responsible for + passing user accounting information to a designated RADIUS + accounting server. + + The RADIUS accounting server is responsible for receiving the + accounting request and returning a response to the client + indicating that it has successfully received the request. + + The RADIUS accounting server can act as a proxy client to other + kinds of accounting servers. + + + + + + + + +Rigney Informational [Page 2] + +RFC 2139 RADIUS Accounting April 1997 + + + Network Security + + Transactions between the client and RADIUS accounting server + are authenticated through the use of a shared secret, which is + never sent over the network. + + Extensible Protocol + + All transactions are comprised of variable length Attribute- + Length-Value 3-tuples. New attribute values can be added + without disturbing existing implementations of the protocol. + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST This word, or the adjective "required", means that the + definition is an absolute requirement of the specification. + + MUST NOT This phrase means that the definition is an absolute + prohibition of the specification. + + SHOULD This word, or the adjective "recommended", means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications must be + understood and carefully weighed before choosing a + different course. + + MAY This word, or the adjective "optional", means that this + item is one of an allowed set of alternatives. An + implementation which does not include this option MUST be + prepared to interoperate with another implementation which + does include the option. + +1.2. Terminology + + This document uses the following terms: + + service The NAS provides a service to the dial-in user, such as PPP + or Telnet. + + + + + + + + + + +Rigney Informational [Page 3] + +RFC 2139 RADIUS Accounting April 1997 + + + session Each service provided by the NAS to a dial-in user + constitutes a session, with the beginning of the session + defined as the point where service is first provided and + the end of the session defined as the point where service + is ended. A user may have multiple sessions in parallel or + series if the NAS supports that, with each session + generating a separate start and stop accounting record with + its own Acct-Session-Id. + + silently discard + This means the implementation discards the packet without + further processing. The implementation SHOULD provide the + capability of logging the error, including the contents of + the silently discarded packet, and SHOULD record the event + in a statistics counter. + +2. Operation + + When a client is configured to use RADIUS Accounting, at the start of + service delivery it will generate an Accounting Start packet + describing the type of service being delivered and the user it is + being delivered to, and will send that to the RADIUS Accounting + server, which will send back an acknowledgement that the packet has + been received. At the end of service delivery the client will + generate an Accounting Stop packet describing the type of service + that was delivered and optionally statistics such as elapsed time, + input and output octets, or input and output packets. It will send + that to the RADIUS Accounting server, which will send back an + acknowledgement that the packet has been received. + + The Accounting-Request (whether for Start or Stop) is submitted to + the RADIUS accounting server via the network. It is recommended that + the client continue attempting to send the Accounting-Request packet + until it receives an acknowledgement, using some form of backoff. If + no response is returned within a length of time, the request is re- + sent a number of times. The client can also forward requests to an + alternate server or servers in the event that the primary server is + down or unreachable. An alternate server can be used either after a + number of tries to the primary server fail, or in a round-robin + fashion. Retry and fallback algorithms are the topic of current + research and are not specified in detail in this document. + + The RADIUS accounting server MAY make requests of other servers in + order to satisfy the request, in which case it acts as a client. + + If the RADIUS accounting server is unable to successfully record the + accounting packet it MUST NOT send an Accounting-Response + acknowledgment to the client. + + + +Rigney Informational [Page 4] + +RFC 2139 RADIUS Accounting April 1997 + + +3. Packet Format + + Exactly one RADIUS Accounting packet is encapsulated in the UDP Data + field [1], where the UDP Destination Port field indicates 1813 + (decimal). + + When a reply is generated, the source and destination ports are + reversed. + + This memo documents the RADIUS Accounting protocol. There has been + some confusion in the assignment of port numbers for this protocol. + The early deployment of RADIUS Accounting was done using the + erroneously chosen port number 1646, which conflicts with the "sa- + msg-port" service. The officially assigned port number for RADIUS + Accounting is 1813. + + A summary of the RADIUS data format is shown below. The fields are + transmitted from 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Code | Identifier | Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +| Authenticator | +| | +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attributes ... ++-+-+-+-+-+-+-+-+-+-+-+-+- + + +Code + + The Code field is one octet, and identifies the type of RADIUS + packet. When a packet is received with an invalid Code field, it is + silently discarded. + + RADIUS Accounting Codes (decimal) are assigned as follows: + + 4 Accounting-Request + 5 Accounting-Response + +Identifier + + The Identifier field is one octet, and aids in matching requests and + replies. + + + +Rigney Informational [Page 5] + +RFC 2139 RADIUS Accounting April 1997 + + +Length + + The Length field is two octets. It indicates the length of the + packet including the Code, Identifier, Length, Authenticator and + Attribute fields. Octets outside the range of the Length field + should be treated as padding and should be ignored on reception. If + the packet is shorter than the Length field indicates, it should be + silently discarded. The minimum length is 20 and maximum length is + 4096. + +Authenticator + + The Authenticator field is sixteen (16) octets. The most significant + octet is transmitted first. This value is used to authenticate the + messages between the client and RADIUS accounting server. + +Request Authenticator + + In Accounting-Request Packets, the Authenticator value is a 16 octet + MD5 [3] checksum, called the Request Authenticator. + + The NAS and RADIUS accounting server share a secret. The Request + Authenticator field in Accounting-Request packets contains a one- way + MD5 hash calculated over a stream of octets consisting of the Code + + Identifier + Length + 16 zero octets + request attributes + shared + secret (where + indicates concatenation). The 16 octet MD5 hash + value is stored in the Authenticator field of the Accounting-Request + packet. + + Note that the Request Authenticator of an Accounting-Request can + not be done the same way as the Request Authenticator of a RADIUS + Access-Request, because there is no User-Password attribute in an + Accounting-Request. + +Response Authenticator + + The Authenticator field in an Accounting-Response packet is called + the Response Authenticator, and contains a one-way MD5 hash + calculated over a stream of octets consisting of the Accounting- + Response Code, Identifier, Length, the Request Authenticator field + from the Accounting-Request packet being replied to, and the response + attributes if any, followed by the shared secret. The resulting 16 + octet MD5 hash value is stored in the Authenticator field of the + Accounting-Response packet. + + + + + + + +Rigney Informational [Page 6] + +RFC 2139 RADIUS Accounting April 1997 + + +Attributes + + Attributes may have multiple instances, in such a case the order of + attributes of the same type SHOULD be preserved. The order of + attributes of different types is not required to be preserved. + +4. Packet Types + + The RADIUS packet type is determined by the Code field in the first + octet of the packet. + +4.1. Accounting-Request + + Description + + Accounting-Request packets are sent from a client (typically a + Network Access Server or its proxy) to a RADIUS accounting server, + and convey information used to provide accounting for a service + provided to a user. The client transmits a RADIUS packet with the + Code field set to 4 (Accounting-Request). + + Upon receipt of an Accounting-Request, the server MUST transmit an + Accounting-Response reply if it successfully records the + accounting packet, and MUST NOT transmit any reply if it fails to + record the accounting packet. + + Any attribute valid in a RADIUS Access-Request or Access-Accept + packet is valid in a RADIUS Accounting-Request packet, except that + the following attributes MUST NOT be present in an Accounting- + Request: User-Password, CHAP-Password, Reply-Message, State. + Either NAS-IP-Address or NAS-Identifier MUST be present in a + RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS- + Port-Type attribute or both unless the service does not involve a + port or the NAS does not distinguish among its ports. + + A summary of the Accounting-Request packet format is shown below. + The fields are transmitted from left to right. + + + + + + + + + + + + + + +Rigney Informational [Page 7] + +RFC 2139 RADIUS Accounting April 1997 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Request Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 4 for Accounting-Request. + + Identifier + + The Identifier field MUST be changed whenever the content of the + Attributes field changes, and whenever a valid reply has been + received for a previous request. For retransmissions where the + contents are identical, the Identifier MUST remain unchanged. + + Note that if Acct-Delay-Time is included in the attributes of an + Accounting-Request then the Acct-Delay-Time value will be updated + when the packet is retransmitted, changing the content of the + Attributes field and requiring a new Identifier and Request + Authenticator. + + Request Authenticator + + The Request Authenticator of an Accounting-Request contains a 16- + octet MD5 hash value calculated according to the method described + in "Request Authenticator" above. + + Attributes + + The Attributes field is variable in length, and contains a list of + Attributes. + +4.2. Accounting-Response + + Description + + Accounting-Response packets are sent by the RADIUS accounting + server to the client to acknowledge that the Accounting-Request + has been received and recorded successfully. If the Accounting- + + + +Rigney Informational [Page 8] + +RFC 2139 RADIUS Accounting April 1997 + + + Request was recorded successfully then the RADIUS accounting + server MUST transmit a packet with the Code field set to 5 + (Accounting-Response). On reception of an Accounting-Response by + the client, the Identifier field is matched with a pending + Accounting-Request. Invalid packets are silently discarded. + + A RADIUS Accounting-Response is not required to have any + attributes in it. + + A summary of the Accounting-Response packet format is shown below. + The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 5 for Accounting-Response. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Accounting-Request which caused this Accounting-Response. + + Response Authenticator + + The Response Authenticator of an Accounting-Response contains a + 16-octet MD5 hash value calculated according to the method + described in "Response Authenticator" above. + + Attributes + + The Attributes field is variable in length, and contains a list of + zero or more Attributes. + + + + + + + +Rigney Informational [Page 9] + +RFC 2139 RADIUS Accounting April 1997 + + +5. Attributes + + RADIUS Attributes carry the specific authentication, authorization + and accounting details for the request and response. + + Some attributes MAY be included more than once. The effect of this + is attribute specific, and is specified in each attribute + description. + + The end of the list of attributes is indicated by the Length of the + RADIUS packet. + + A summary of the attribute format is shown below. The fields are + transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + The Type field is one octet. Up-to-date values of the RADIUS Type + field are specified in the most recent "Assigned Numbers" RFC [2]. + Values 192-223 are reserved for experimental use, values 224-240 + are reserved for implementation-specific use, and values 241-255 + are reserved and should not be used. This specification concerns + the following values: + + 1-39 (refer to RADIUS document [4]) + 40 Acct-Status-Type + 41 Acct-Delay-Time + 42 Acct-Input-Octets + 43 Acct-Output-Octets + 44 Acct-Session-Id + 45 Acct-Authentic + 46 Acct-Session-Time + 47 Acct-Input-Packets + 48 Acct-Output-Packets + 49 Acct-Terminate-Cause + 50 Acct-Multi-Session-Id + 51 Acct-Link-Count + 60+ (refer to RADIUS document [4]) + + + + + + + +Rigney Informational [Page 10] + +RFC 2139 RADIUS Accounting April 1997 + + + Length + + The Length field is one octet, and indicates the length of this + attribute including the Type, Length and Value fields. If an + attribute is received in an Accounting-Request with an invalid + Length, the entire request should be silently discarded. + + Value + + The Value field is zero or more octets and contains information + specific to the attribute. The format and length of the Value + field is determined by the Type and Length fields. + + The format of the value field is one of four data types. + + string 0-253 octets + + address 32 bit value, most significant octet first. + + integer 32 bit value, most significant octet first. + + time 32 bit value, most significant octet first -- seconds + since 00:00:00 GMT, January 1, 1970. The standard + Attributes do not use this data type but it is presented + here for possible use within Vendor-Specific attributes. + +5.1. Acct-Status-Type + + Description + + This attribute indicates whether this Accounting-Request marks the + beginning of the user service (Start) or the end (Stop). + + It MAY be used by the client to mark the start of accounting (for + example, upon booting) by specifying Accounting-On and to mark the + end of accounting (for example, just before a scheduled reboot) by + specifying Accounting-Off. + + A summary of the Acct-Status-Type attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Rigney Informational [Page 11] + +RFC 2139 RADIUS Accounting April 1997 + + + Type + + 40 for Acct-Status-Type. + + Length + + 6 + + Value + + The Value field is four octets. + + 1 Start + 2 Stop + 7 Accounting-On + 8 Accounting-Off + +5.2. Acct-Delay-Time + + Description + + This attribute indicates how many seconds the client has been + trying to send this record for, and can be subtracted from the + time of arrival on the server to find the approximate time of the + event generating this Accounting-Request. (Network transit time + is ignored.) + + Note that changing the Acct-Delay-Time causes the Identifier to + change; see the discussion under Identifier above. + + A summary of the Acct-Delay-Time attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 41 for Acct-Delay-Time. + + Length + + 6 + + + +Rigney Informational [Page 12] + +RFC 2139 RADIUS Accounting April 1997 + + + Value + + The Value field is four octets. + +5.3. Acct-Input-Octets + + Description + + This attribute indicates how many octets have been received from + the port over the course of this service being provided, and can + only be present in Accounting-Request records where the Acct- + Status-Type is set to Stop. + + A summary of the Acct-Input-Octets attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 42 for Acct-Input-Octets. + + Length + + 6 + + Value + + The Value field is four octets. + +5.4. Acct-Output-Octets + + Description + + This attribute indicates how many octets have been sent to the + port in the course of delivering this service, and can only be + present in Accounting-Request records where the Acct-Status-Type + is set to Stop. + + A summary of the Acct-Output-Octets attribute format is shown below. + The fields are transmitted from left to right. + + + + +Rigney Informational [Page 13] + +RFC 2139 RADIUS Accounting April 1997 + + + 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 43 for Acct-Output-Octets. + + Length + + 6 + + Value + + The Value field is four octets. + +5.5. Acct-Session-Id + + Description + + This attribute is a unique Accounting ID to make it easy to match + start and stop records in a log file. The start and stop records + for a given session MUST have the same Acct-Session-Id. It is + strongly recommended that the Acct-Session-Id be a printable ASCII + string. + + For example, one implementation uses a string with an 8-digit + upper case hexadecimal number, the first two digits increment on + each reboot (wrapping every 256 reboots) and the next 6 digits + counting from 0 for the first person logging in after a reboot up + to 2^24-1, about 16 million. Other encodings are possible. + + A summary of the Acct-Session-Id attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + + + + + + +Rigney Informational [Page 14] + +RFC 2139 RADIUS Accounting April 1997 + + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 44 for Acct-Session-Id. + + Length + + >= 3 + + String + + The String field SHOULD be a string of printable ASCII characters. + +5.6. Acct-Authentic + + Description + + This attribute MAY be included in an Accounting-Request to + indicate how the user was authenticated, whether by RADIUS, the + NAS itself, or another remote authentication protocol. Users who + are delivered service without being authenticated SHOULD NOT + generate Accounting records. + + A summary of the Acct-Authentic attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 45 for Acct-Authentic. + + Length + + 6 + + + + + +Rigney Informational [Page 15] + +RFC 2139 RADIUS Accounting April 1997 + + + Value + + The Value field is four octets. + + 1 RADIUS + 2 Local + 3 Remote + +5.7. Acct-Session-Time + + Description + + This attribute indicates how many seconds the user has received + service for, and can only be present in Accounting-Request records + where the Acct-Status-Type is set to Stop. + + A summary of the Acct-Session-Time attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 46 for Acct-Session-Time. + + Length + + 6 + + Value + + The Value field is four octets. + +5.8. Acct-Input-Packets + + Description + + This attribute indicates how many packets have been received from + the port over the course of this service being provided to a + Framed User, and can only be present in Accounting-Request records + where the Acct-Status-Type is set to Stop. + + + + +Rigney Informational [Page 16] + +RFC 2139 RADIUS Accounting April 1997 + + + A summary of the Acct-Input-packets attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 47 for Acct-Input-Packets. + + Length + + 6 + + Value + + The Value field is four octets. + +5.9. Acct-Output-Packets + + Description + + This attribute indicates how many packets have been sent to the + port in the course of delivering this service to a Framed User, + and can only be present in Accounting-Request records where the + Acct-Status-Type is set to Stop. + + A summary of the Acct-Output-Packets attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 48 for Acct-Output-Packets. + + + + + +Rigney Informational [Page 17] + +RFC 2139 RADIUS Accounting April 1997 + + + Length + + 6 + + Value + + The Value field is four octets. + +5.10. Acct-Terminate-Cause + + Description + + This attribute indicates how the session was terminated, and can + only be present in Accounting-Request records where the Acct- + Status-Type is set to Stop. + + A summary of the Acct-Terminate-Cause attribute format is shown + below. The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 49 for Acct-Terminate-Cause + + Length + + 6 + + + + + + + + + + + + + + + + + +Rigney Informational [Page 18] + +RFC 2139 RADIUS Accounting April 1997 + + + Value + + The Value field is four octets, containing an integer specifying + the cause of session termination, as follows: + + 1 User Request + 2 Lost Carrier + 3 Lost Service + 4 Idle Timeout + 5 Session Timeout + 6 Admin Reset + 7 Admin Reboot + 8 Port Error + 9 NAS Error + 10 NAS Request + 11 NAS Reboot + 12 Port Unneeded + 13 Port Preempted + 14 Port Suspended + 15 Service Unavailable + 16 Callback + 17 User Error + 18 Host Request + + + + The termination causes are as follows: + + User Request User requested termination of service, for + example with LCP Terminate or by logging out. + + Lost Carrier DCD was dropped on the port. + + Lost Service Service can no longer be provided; for + example, user's connection to a host was + interrupted. + + Idle Timeout Idle timer expired. + + Session Timeout Maximum session length timer expired. + + Admin Reset Administrator reset the port or session. + + Admin Reboot Administrator is ending service on the NAS, + for example prior to rebooting the NAS. + + Port Error NAS detected an error on the port which + required ending the session. + + + +Rigney Informational [Page 19] + +RFC 2139 RADIUS Accounting April 1997 + + + NAS Error NAS detected some error (other than on the + port) which required ending the session. + + NAS Request NAS ended session for a non-error reason not + otherwise listed here. + + NAS Reboot The NAS ended the session in order to reboot + non-administratively ("crash"). + + Port Unneeded NAS ended session because resource usage fell + below low-water mark (for example, if a + bandwidth-on-demand algorithm decided that + the port was no longer needed). + + Port Preempted NAS ended session in order to allocate the + port to a higher priority use. + + Port Suspended NAS ended session to suspend a virtual + session. + + Service Unavailable NAS was unable to provide requested service. + + Callback NAS is terminating current session in order + to perform callback for a new session. + + User Error Input from user is in error, causing + termination of session. + + Host Request Login Host terminated session normally. + +5.11. Acct-Multi-Session-Id + + Description + + This attribute is a unique Accounting ID to make it easy to link + together multiple related sessions in a log file. Each session + linked together would have a unique Acct-Session-Id but the same + Acct-Multi-Session-Id. It is strongly recommended that the Acct- + Multi-Session-Id be a printable ASCII string. + + A summary of the Acct-Session-Id attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Rigney Informational [Page 20] + +RFC 2139 RADIUS Accounting April 1997 + + + Type + + 50 for Acct-Multi-Session-Id. + + Length + + >= 3 + + String + + The String field SHOULD be a string of printable ASCII characters. + +5.12. Acct-Link-Count + + Description + + This attribute gives the count of links which are known to have + been in a given multilink session at the time the accounting + record is generated. The NAS MAY include the Acct-Link-Count + attribute in any Accounting-Request which might have multiple + links. + + A summary of the Acct-Link-Count attribute format is show below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 51 for Acct-Link-Count. + + Length + + 6 + + Value + + The Value field is four octets, and contains the number of links + seen so far in this Multilink Session. + + + + + + +Rigney Informational [Page 21] + +RFC 2139 RADIUS Accounting April 1997 + + + It may be used to make it easier for an accounting server to know + when it has all the records for a given Multilink session. When + the number of Accounting-Requests received with Acct-Status-Type = + Stop and the same Acct-Multi-Session-Id and unique Acct-Session- + Id's equals the largest value of Acct-Link-Count seen in those + Accounting-Requests, all Stop Accounting-Requests for that + Multilink Session have been received. + + An example showing 8 Accounting-Requests should make things + clearer. For clarity only the relevant attributes are shown, but + additional attributes containing accounting information will also + be present in the Accounting-Request. + + Multi-Session-Id Session-Id Status-Type Link-Count + "10" "10" Start 1 + "10" "11" Start 2 + "10" "11" Stop 2 + "10" "12" Start 3 + "10" "13" Start 4 + "10" "12" Stop 4 + "10" "13" Stop 4 + "10" "10" Stop 4 + +5.13. Table of Attributes + + The following table provides a guide to which attributes may be found + in Accounting-Request packets. No attributes should be found in + Accounting-Response packets except Proxy-State and possibly Vendor- + Specific. + + # Attribute + 0-1 User-Name + 0 User-Password + 0 CHAP-Password + 0-1 NAS-IP-Address [5] + 0-1 NAS-Port + 0-1 Service-Type + 0-1 Framed-Protocol + 0-1 Framed-IP-Address + 0-1 Framed-IP-Netmask + 0-1 Framed-Routing + 0+ Filter-Id + 0-1 Framed-MTU + 0+ Framed-Compression + 0+ Login-IP-Host + 0-1 Login-Service + 0-1 Login-TCP-Port + 0 Reply-Message + + + +Rigney Informational [Page 22] + +RFC 2139 RADIUS Accounting April 1997 + + + 0-1 Callback-Number + 0-1 Callback-Id + 0+ Framed-Route + 0-1 Framed-IPX-Network + 0 State + 0+ Class + 0+ Vendor-Specific + 0-1 Session-Timeout + 0-1 Idle-Timeout + 0-1 Termination-Action + 0-1 Called-Station-Id + 0-1 Calling-Station-Id + 0-1 NAS-Identifier [4] + 0+ Proxy-State + 0-1 Login-LAT-Service + 0-1 Login-LAT-Node + 0-1 Login-LAT-Group + 0-1 Framed-AppleTalk-Link + 0-1 Framed-AppleTalk-Network + 0-1 Framed-AppleTalk-Zone + 1 Acct-Status-Type + 0-1 Acct-Delay-Time + 0-1 Acct-Input-Octets + 0-1 Acct-Output-Octets + 1 Acct-Session-Id + 0-1 Acct-Authentic + 0-1 Acct-Session-Time + 0-1 Acct-Input-Packets + 0-1 Acct-Output-Packets + 0-1 Acct-Terminate-Cause + 0+ Acct-Multi-Session-Id + 0+ Acct-Link-Count + 0 CHAP-Challenge + 0-1 NAS-Port-Type + 0-1 Port-Limit + 0-1 Login-LAT-Port + + + [5] An Accounting-Request MUST contain either a NAS-IP-Address or a + NAS-Identifier, and it is permitted (but not recommended) for it to + contain both. + + The following table defines the above table entries. + + 0 This attribute MUST NOT be present + 0+ Zero or more instances of this attribute MAY be present. + 0-1 Zero or one instance of this attribute MAY be present. + 1 Exactly one instance of this attribute MUST be present. + + + +Rigney Informational [Page 23] + +RFC 2139 RADIUS Accounting April 1997 + + +Security Considerations + + Security issues are briefly discussed in sections concerning the + authenticator included in accounting requests and responses, using a + shared secret which is never sent over the network. + +References + + [1] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + USC/Information Sciences Institute, August 1980. + + [2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC + 1700, USC/Information Sciences Institute, October 1994. + + [3] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm", + RFC 1321, MIT Laboratory for Computer Science, RSA Data + Security Inc., April 1992. + + [4] Rigney, C., Rubens, A., Simpson, W., and Willens, S., "Remote + Authentication Dial In User Service (RADIUS)", RFC 2138, + April 1997. + +Acknowledgments + + RADIUS and RADIUS Accounting were originally developed by Livingston + Enterprises for their PortMaster series of Network Access Servers. + +Chair's Address + + The RADIUS working group can be contacted via the current chair: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + Phone: +1 510 426 0770 + EMail: cdr@livingston.com + + + + + + + + + + + + + +Rigney Informational [Page 24] + +RFC 2139 RADIUS Accounting April 1997 + + +Author's Address + + Questions about this memo can also be directed to: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + EMail: cdr@livingston.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rigney Informational [Page 25] + diff --git a/rfc/rfc2284.txt b/rfc/rfc2284.txt new file mode 100644 index 00000000..99405629 --- /dev/null +++ b/rfc/rfc2284.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group L. Blunk +Request for Comments: 2284 J. Vollbrecht +Category: Standards Track Merit Network, Inc. + March 1998 + + + + + PPP Extensible Authentication Protocol (EAP) + + +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. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +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, which allows + negotiation of an Authentication Protocol for authenticating its peer + before allowing Network Layer protocols to transmit over the link. + + This document defines the PPP Extensible Authentication Protocol. + +Table of Contents + + 1. Introduction .......................................... 2 + 1.1 Specification of Requirements ................... 2 + 1.2 Terminology ..................................... 2 + 2. PPP Extensible Authentication Protocol (EAP) .......... 3 + 2.1 Configuration Option Format ..................... 4 + 2.2 Packet Format ................................... 6 + 2.2.1 Request and Response ............................ 6 + 2.2.2 Success and Failure ............................. 7 + 3. Initial EAP Request/Response Types .................... 8 + 3.1 Identity ........................................ 9 + 3.2 Notification .................................... 10 + 3.3 Nak ............................................. 10 + + + +Blunk & Vollbrecht Standards Track [Page 1] + +RFC 2284 EAP March 1998 + + + 3.4 MD5-Challenge ................................... 11 + 3.5 One-Time Password (OTP) ......................... 11 + 3.6 Generic Token Card .............................. 12 + REFERENCES ................................................... 13 + ACKNOWLEDGEMENTS ............................................. 14 + CHAIR'S ADDRESS .............................................. 14 + AUTHORS' ADDRESSES ........................................... 14 + Full Copyright Statement ..................................... 15 + +1. Introduction + + In order to establish communications over a point-to-point link, each + end of the PPP link must first send LCP packets to configure the data + link during Link Establishment phase. After the link has been + established, PPP provides for an optional Authentication phase before + proceeding to the Network-Layer Protocol phase. + + By default, authentication is not mandatory. If authentication of + the link is desired, an implementation MUST specify the + Authentication-Protocol Configuration Option during Link + Establishment phase. + + These authentication protocols are intended for use primarily by + hosts and routers that connect to a PPP network server via switched + circuits or dial-up lines, but might be applied to dedicated links as + well. The server can use the identification of the connecting host + or router in the selection of options for network layer negotiations. + + This document defines the PPP Extensible Authentication Protocol + (EAP). The Link Establishment and Authentication phases, and the + Authentication-Protocol Configuration Option, are defined in The + Point-to-Point Protocol (PPP) [1]. + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. The key + words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document + are to be interpreted as described in RFC 2119 [6]. + +1.2. Terminology + + This document frequently uses the following terms: + + + + + + + +Blunk & Vollbrecht Standards Track [Page 2] + +RFC 2284 EAP March 1998 + + + authenticator + The end of the link requiring the authentication. The + authenticator specifies the authentication protocol to be + used in the Configure-Request during Link Establishment + phase. + + peer + The other end of the point-to-point link; the end which is + being authenticated by the authenticator. + + silently discard + This means the implementation discards the packet without + further processing. The implementation SHOULD provide the + capability of logging the error, including the contents of + the silently discarded packet, and SHOULD record the event + in a statistics counter. + + displayable message + This is interpreted to be a human readable string of + characters, and MUST NOT affect operation of the protocol. + The message encoding MUST follow the UTF-8 transformation + format [5]. + +2. PPP Extensible Authentication Protocol (EAP) + + The PPP Extensible Authentication Protocol (EAP) is a general + protocol for PPP authentication which supports multiple + authentication mechanisms. EAP does not select a specific + authentication mechanism at Link Control Phase, but rather postpones + this until the Authentication Phase. This allows the authenticator + to request more information before determining the specific + authentication mechanism. This also permits the use of a "back-end" + server which actually implements the various mechanisms while the PPP + authenticator merely passes through the authentication exchange. + + 1. After the Link Establishment phase is complete, the authenticator + sends one or more Requests to authenticate the peer. The Request + has a type field to indicate what is being requested. Examples of + Request types include Identity, MD5-challenge, One-Time + Passwords, Generic Token Card, etc. The MD5-challenge type + corresponds closely to the CHAP authentication protocol. + Typically, the authenticator will send an initial Identity Request + followed by one or more Requests for authentication information. + However, an initial Identity Request is not required, and MAY be + bypassed in cases where the identity is presumed (leased lines, + dedicated dial-ups, etc.). + + + + + +Blunk & Vollbrecht Standards Track [Page 3] + +RFC 2284 EAP March 1998 + + + 2. The peer sends a Response packet in reply to each Request. As + with the Request packet, the Response packet contains a type field + which corresponds to the type field of the Request. + + 3. The authenticator ends the authentication phase with a Success or + Failure packet. + +Advantages + + The EAP protocol can support multiple authentication mechanisms + without having to pre-negotiate a particular one during LCP Phase. + + Certain devices (e.g. a NAS) do not necessarily have to understand + each request type and may be able to simply act as a passthrough + agent for a "back-end" server on a host. The device only need look + for the success/failure code to terminate the authentication phase. + +Disadvantages + + EAP does require the addition of a new authentication type to LCP and + thus PPP implementations will need to be modified to use it. It also + strays from the previous PPP authentication model of negotiating a + specific authentication mechanism during LCP. + +2.1. Configuration Option Format + + A summary of the Authentication-Protocol Configuration Option format + to negotiate the EAP Authentication Protocol is shown below. The + fields are transmitted from 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 | Authentication-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 3 + + Length + + 4 + + Authentication-Protocol + + C227 (Hex) for PPP Extensible Authentication Protocol (EAP) + + + +Blunk & Vollbrecht Standards Track [Page 4] + +RFC 2284 EAP March 1998 + + +2.2. Packet Format + + Exactly one PPP EAP packet is encapsulated in the Information field + of a PPP Data Link Layer frame where the protocol field indicates + type hex C227 (PPP EAP). A summary of the EAP packet format is shown + below. The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + Code + + The Code field is one octet and identifies the type of EAP packet. + EAP Codes are assigned as follows: + + 1 Request + 2 Response + 3 Success + 4 Failure + + Identifier + + The Identifier field is one octet and aids in matching + responses with requests. + + Length + + The Length field is two octets and indicates the length of the + EAP packet including the Code, Identifier, Length and Data + fields. Octets outside the range of the Length field should + be treated as Data Link Layer padding and should be ignored on + reception. + + Data + + The Data field is zero or more octets. The format of the Data + field is determined by the Code field. + + + + + + + + +Blunk & Vollbrecht Standards Track [Page 5] + +RFC 2284 EAP March 1998 + + +2.2.1. Request and Response + + Description + + The Request packet is sent by the authenticator to the peer. Each + Request has a type field which serves to indicate what is being + requested. The authenticator MUST transmit an EAP packet with the + Code field set to 1 (Request). Additional Request packets MUST be + sent until a valid Response packet is received, or an optional + retry counter expires. Retransmitted Requests MUST be sent with + the same Identifier value in order to distinguish them from new + Requests. The contents of the data field is dependent on the + Request type. The peer MUST send a Response packet in reply to a + Request packet. Responses MUST only be sent in reply to a + received Request and never retransmitted on a timer. The + Identifier field of the Response MUST match that of the Request. + + Implementation Note: Because the authentication process will + often involve user input, some care must be taken when deciding + upon retransmission strategies and authentication timeouts. It + is suggested a retransmission timer of 6 seconds with a maximum + of 10 retransmissions be used as default. One may wish to make + these timeouts longer in certain cases (e.g. where Token Cards + are involved). Additionally, the peer must be prepared to + silently discard received retransmissions while waiting for + user input. + + A summary of the Request and Response packet format is shown below. + The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Type-Data ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + Code + + 1 for Request; + + 2 for Response. + + + + + + + +Blunk & Vollbrecht Standards Track [Page 6] + +RFC 2284 EAP March 1998 + + + Identifier + + The Identifier field is one octet. The Identifier field MUST be + the same if a Request packet is retransmitted due to a timeout + while waiting for a Response. Any new (non-retransmission) + Requests MUST modify the Identifier field. If a peer recieves a + duplicate Request for which it has already sent a Response, it + MUST resend it's Response. If a peer receives a duplicate Request + before it has sent a Response to the initial Request (i.e. it's + waiting for user input), it MUST silently discard the duplicate + Request. + + Length + + The Length field is two octets and indicates the length of the EAP + packet including the Code, Identifier, Length, Type, and Type-Data + fields. Octets outside the range of the Length field should be + treated as Data Link Layer padding and should be ignored on + reception. + + Type + + The Type field is one octet. This field indicates the Type of + Request or Response. Only one Type MUST be specified per EAP + Request or Response. Normally, the Type field of the Response + will be the same as the Type of the Request. However, there is + also a Nak Response Type for indicating that a Request type is + unacceptable to the peer. When sending a Nak in response to a + Request, the peer MAY indicate an alternative desired + authentication Type which it supports. An initial specification of + Types follows in a later section of this document. + + Type-Data + + The Type-Data field varies with the Type of Request and the + associated Response. + +2.2.2. Success and Failure + + Description + + The Success packet is sent by the authenticator to the peer to + acknowledge successful authentication. The authenticator MUST + transmit an EAP packet with the Code field set to 3 (Success). + + If the authenticator cannot authenticate the peer (unacceptable + Responses to one or more Requests) then the implementation MUST + transmit an EAP packet with the Code field set to 4 (Failure). An + + + +Blunk & Vollbrecht Standards Track [Page 7] + +RFC 2284 EAP March 1998 + + + authenticator MAY wish to issue multiple Requests before sending a + Failure response in order to allow for human typing mistakes. + + Implementation Note: Because the Success and Failure packets + are not acknowledged, they may be potentially lost. A peer + MUST allow for this circumstance. The peer can use a Network + Protocol packet as an alternative indication of Success. + Likewise, the receipt of a LCP Terminate-Request can be taken + as a Failure. + + A summary of the Success and Failure packet format is shown below. + The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Code + + 3 for Success; + + 4 for Failure. + + Identifier + + The Identifier field is one octet and aids in matching replies to + Responses. The Identifier field MUST match the Indentifier field + of the Response packet that it is sent in response to. + + Length + + 4 + +3. Initial EAP Request/Response Types + + This section defines the initial set of EAP Types used in + Request/Response exchanges. More Types may be defined in follow-on + documents. The Type field is one octet and identifies the structure + of an EAP Request or Response packet. The first 3 Types are + considered special case Types. The remaining Types define + authentication exchanges. The Nak Type is valid only for Response + packets, it MUST NOT be sent in a Request. The Nak Type MUST only be + + + + + + +Blunk & Vollbrecht Standards Track [Page 8] + +RFC 2284 EAP March 1998 + + + sent in repsonse to a Request which uses an authentication Type code. + All EAP implementatins MUST support Types 1-4. These Types, as well + as types 5 and 6, are defined in this document. Follow-on RFCs will + define additional EAP Types. + + 1 Identity + 2 Notification + 3 Nak (Response only) + 4 MD5-Challenge + 5 One-Time Password (OTP) (RFC 1938) + 6 Generic Token Card + +3.1. Identity + + Description + + The Identity Type is used to query the identity of the peer. + Generally, the authenticator will issue this as the initial + Request. An optional displayable message MAY be included to + prompt the peer in the case where there expectation of interaction + with a user. A Response MUST be sent to this Request with a Type + of 1 (Identity). + + Implementation Note: The peer MAY obtain the Identity via user + input. It is suggested that the authenticator retry the + Indentity Request in the case of an invalid Identity or + authentication failure to allow for potential typos on the part + of the user. It is suggested that the Identity Request be + retried a minimum of 3 times before terminating the + authentication phase with a Failure reply. The Notification + Request MAY be used to indicate an invalid authentication + attempt prior to transmitting a new Identity Request + (optionally, the failure MAY be indicated within the message of + the new Identity Request itself). + + Type + + 1 + + Type-Data + + This field MAY contain a displayable message in the Request. The + Response uses this field to return the Identity. If the Identity + is unknown, this field should be zero bytes in length. The field + MUST NOT be null terminated. The length of this field is derived + from the Length field of the Request/Response packet and hence a + null is not required. + + + + +Blunk & Vollbrecht Standards Track [Page 9] + +RFC 2284 EAP March 1998 + + +3.2. Notification + + Description + + The Notification Type is optionally used to convey a displayable + message from the authenticator to the peer. The peer SHOULD + display this message to the user or log it if it cannot be + displayed. It is intended to provide an acknowledged notification + of some imperative nature. Examples include a password with an + expiration time that is about to expire, an OTP sequence integer + which is nearing 0, an authentication failure warning, etc. In + most circumstances, notification should not be required. + + Type + + 2 + + Type-Data + + The Type-Data field in the Request contains a displayable message + greater than zero octets in length. The length of the message is + determined by Length field of the Request packet. The message + MUST not be null terminated. A Response MUST be sent in reply to + the Request with a Type field of 2 (Notification). The Type-Data + field of the Response is zero octets in length. The Response + should be sent immediately (independent of how the message is + displayed or logged). + +3.3. Nak + + Description + + The Nak Type is valid only in Response messages. It is sent in + reply to a Request where the desired authentication Type is + unacceptable. Authentication Types are numbered 4 and above. + The Response contains the authentication Type desired by the peer. + + Type + + 3 + + Type-Data + + This field MUST contain a single octet indicating the desired + authentication type. + + + + + + +Blunk & Vollbrecht Standards Track [Page 10] + +RFC 2284 EAP March 1998 + + +3.4. MD5-Challenge + + Description + + The MD5-Challenge Type is analagous to the PPP CHAP protocol [3] + (with MD5 as the specified algorithm). The PPP Challenge + Handshake Authentication Protocol RFC [3] should be referred to + for further implementation specifics. The Request contains a + "challenge" message to the peer. A Repsonse MUST be sent in reply + to the Request. The Response MAY be either of Type 4 (MD5- + Challenge) or Type 3 (Nak). The Nak reply indicates the peer's + desired authentication mechanism Type. All EAP implementations + MUST support the MD5-Challenge mechanism. + + Type + + 4 + + Type-Data + + The contents of the Type-Data field is summarized below. For + reference on the use of this fields see the PPP Challenge + Handshake Authentication Protocol [3]. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value-Size | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Name ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +3.5. One-Time Password (OTP) + + Description + + The One-Time Password system is defined in "A One-Time Password + System" [4]. The Request contains a displayable message + containing an OTP challenge. A Repsonse MUST be sent in reply to + the Request. The Response MUST be of Type 5 (OTP) or Type 3 + (Nak). The Nak reply indicates the peer's desired authentication + mechanism Type. + + Type + + 5 + + + + + +Blunk & Vollbrecht Standards Track [Page 11] + +RFC 2284 EAP March 1998 + + + Type-Data + + The Type-Data field contains the OTP "challenge" as a displayable + message in the Request. In the Response, this field is used for + the 6 words from the OTP dictionary [4]. The messages MUST not be + null terminated. The length of the field is derived from the + Length field of the Request/Reply packet. + +3.6. Generic Token Card + + Description + + The Generic Token Card Type is defined for use with various Token + Card implementations which require user input. The Request + contains an ASCII text message and the Reply contains the Token + Card information necessary for authentication. Typically, this + would be information read by a user from the Token card device and + entered as ASCII text. + + Type + + 6 + + Type-Data + + The Type-Data field in the Request contains a displayable message + greater than zero octets in length. The length of the message is + determined by Length field of the Request packet. The message + MUST not be null terminated. A Response MUST be sent in reply to + the Request with a Type field of 6 (Generic Token Card). The + Response contains data from the Token Card required for + authentication. The length is of the data is determined by the + Length field of the Response packet. + +Security Considerations + + Security issues are the primary topic of this RFC. + + The interaction of the authentication protocols within PPP are highly + implementation dependent. + + For example, upon failure of authentication, some implementations do + not terminate the link. Instead, the implementation limits the kind + of traffic in the Network-Layer Protocols to a filtered subset, which + in turn allows the user opportunity to update secrets or send mail to + the network administrator indicating a problem. + + + + + +Blunk & Vollbrecht Standards Track [Page 12] + +RFC 2284 EAP March 1998 + + + There is no provision for retries of failed authentication. However, + the LCP state machine can renegotiate the authentication protocol at + any time, thus allowing a new attempt. It is recommended that any + counters used for authentication failure not be reset until after + successful authentication, or subsequent termination of the failed + link. + + There is no requirement that authentication be full duplex or that + the same protocol be used in both directions. It is perfectly + acceptable for different protocols to be used in each direction. + This will, of course, depend on the specific protocols negotiated. + + In practice, within or associated with each PPP server, it is not + anticipated that a particular named user would be authenticated by + multiple methods. This would make the user vulnerable to attacks + which negotiate the least secure method from among a set (such as PAP + rather than EAP). Instead, for each named user there should be an + indication of exactly one method used to authenticate that user name. + If a user needs to make use of different authentication methods under + different circumstances, then distinct identities SHOULD be employed, + each of which identifies exactly one authentication method. + +References + + [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, + RFC 1661, July 1994. + + [2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, + RFC 1700, October 1994. + + [3] Simpson, W., "PPP Challenge Handshake Authentication Protocol + (CHAP)", RFC 1994, August 1996. + + [4] Haller, N. and C. Metz, "A One-Time Password System", RFC 1938, + May 1996. + + [5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO + 10646", RFC 2044, October 1996. + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + + + + + + + + + + +Blunk & Vollbrecht Standards Track [Page 13] + +RFC 2284 EAP March 1998 + + +Acknowledgments + + This protocol derives much of its inspiration from Dave Carrel's AHA + draft as well as the PPP CHAP protocol [3]. Bill Simpson provided + much of the boilerplate used throughout this document. Al Rubens + (Merit) also provided valuable feedback. + +Chair's Address + + The working group can be contacted via the current chair: + + Karl F. Fox + Ascend Communications, Inc. + 655 Metro Place South, Suite 370 + Dublin, Ohio 43017 + + EMail: karl@ascend.com + Phone: +1 614 760 4041 + Fax: +1 614 760 4050 + +Authors' Addresses + + Larry J. Blunk + Merit Network, Inc. + 4251 Plymouth Rd., Suite C + Ann Arbor, MI 48105 + + EMail: ljb@merit.edu + Phone: 734-763-6056 + FAX: 734-647-3185 + + + John R. Vollbrecht + Merit Network, Inc. + 4251 Plymouth Rd., Suite C + Ann Arbor, MI 48105 + + EMail: jrv@merit.edu + Phone: +1-313-763-1206 + FAX: +1-734-647-3185 + + + + + + + + + + + +Blunk & Vollbrecht Standards Track [Page 14] + +RFC 2284 EAP March 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Blunk & Vollbrecht Standards Track [Page 15] + diff --git a/rfc/rfc2433.txt b/rfc/rfc2433.txt new file mode 100644 index 00000000..3536e72a --- /dev/null +++ b/rfc/rfc2433.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group G. Zorn +Request for Comments: 2433 S. Cobb +Category: Informational Microsoft Corporation + October 1998 + + + Microsoft PPP CHAP Extensions + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +IESG Note + + The protocol described here has significant vulnerabilities. People + planning on implementing or using this protocol should read section + 12, "Security Considerations". + +1. Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method for + transporting multi-protocol datagrams over point-to-point links. PPP + defines an extensible Link Control Protocol and a family of Network + Control Protocols (NCPs) for establishing and configuring different + network-layer protocols. + + This document describes Microsoft's PPP CHAP dialect (MS-CHAP), which + extends the user authentication functionality provided on Windows + networks to remote workstations. MS-CHAP is closely derived from the + PPP Challenge Handshake Authentication Protocol described in RFC 1994 + [2], which the reader should have at hand. + + The algorithms used in the generation of various MS-CHAP protocol + fields are described in an appendix. + +2. Introduction + + Microsoft created MS-CHAP to authenticate remote Windows + workstations, providing the functionality to which LAN-based users + are accustomed while integrating the encryption and hashing + algorithms used on Windows networks. + + + + +Zorn & Cobb Informational [Page 1] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + Where possible, MS-CHAP is consistent with standard CHAP. Briefly, + the differences between MS-CHAP and standard CHAP are: + + * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP + option 3, Authentication Protocol. + + * The MS-CHAP Response packet is in a format designed for + compatibility with Microsoft's Windows NT 3.5, 3.51 and 4.0, and + Windows95 networking products. The MS-CHAP format does not + require the authenticator to store a clear-text or reversibly + encrypted password. + + * MS-CHAP provides authenticator-controlled authentication retry + and password changing mechanisms. + + * MS-CHAP defines a set of reason-for-failure codes returned in + the Failure packet Message field. + +3. Specification of Requirements + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as + described in [2]. + +4. LCP Configuration + + The LCP configuration for MS-CHAP is identical to that for standard + CHAP, except that the Algorithm field has value 0x80, rather than the + MD5 value 0x05. PPP implementations which do not support MS-CHAP, + but correctly implement LCP Config-Rej, should have no problem + dealing with this non-standard option. + +5. Challenge Packet + + The MS-CHAP Challenge packet is identical in format to the standard + CHAP Challenge packet. + + MS-CHAP authenticators send an 8-octet challenge Value field. Peers + need not duplicate Microsoft's algorithm for selecting the 8-octet + value, but the standard guidelines on randomness [1,2,7] SHOULD be + observed. + + Microsoft authenticators do not currently provide information in the + Name field. This may change in the future. + + + + + + + +Zorn & Cobb Informational [Page 2] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +6. Response Packet + + The MS-CHAP Response packet is identical in format to the standard + CHAP Response packet. However, the Value field is sub-formatted + differently as follows: + + 24 octets: LAN Manager compatible challenge response + 24 octets: Windows NT compatible challenge response + 1 octet : "Use Windows NT compatible challenge response" flag + + The LAN Manager compatible challenge response is an encoded function + of the password and the received challenge as output by the routine + LmChallengeResponse() (see section A.1, below). LAN Manager + passwords are limited to 14 case-insensitive OEM characters. Note + that use of the LAN Manager compatible challenge response has been + deprecated; peers SHOULD NOT generate it, and the sub-field SHOULD be + zero-filled. The algorithm used in the generation of the LAN Manager + compatible challenge response is described here for informational + purposes only. + + The Windows NT compatible challenge response is an encoded function + of the password and the received challenge as output by the routine + NTChallengeResponse() (see section A.5, below). The Windows NT + password is a string of 0 to (theoretically) 256 case-sensitive + Unicode [8] characters. Current versions of Windows NT limit + passwords to 14 characters, mainly for compatibility reasons; this + may change in the future. + + The "use Windows NT compatible challenge response" flag, if 1, + indicates that the Windows NT response is provided and should be used + in preference to the LAN Manager response. The LAN Manager response + will still be used if the account does not have a Windows NT password + hash, e.g. if the password has not been changed since the account + was uploaded from a LAN Manager 2.x account database. If the flag is + 0, the Windows NT response is ignored and the LAN Manager response is + used. Since the use of LAN Manager authentication has been + deprecated, this flag SHOULD always be set (1) and the LAN Manager + compatible challenge response field SHOULD be zero-filled. + + The Name field identifies the peer's user account name. The Windows + NT domain name may prefix the user's account name (e.g. + "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the + user account "john-doe"). If a domain is not provided, the backslash + should also be omitted, (e.g. "johndoe"). + + + + + + + +Zorn & Cobb Informational [Page 3] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +7. Success Packet + + The Success packet is identical in format to the standard CHAP + Success packet. + +8. Failure Packet + + The Failure packet is identical in format to the standard CHAP + Failure packet. There is, however, formatted text stored in the + Message field which, contrary to the standard CHAP rules, affects the + protocol. The Message field format is: + + "E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv" + + where + + The "eeeeeeeeee" is the decimal error code (need not be 10 + digits) corresponding to one of those listed below, though + implementations should deal with codes not on this list + gracefully. + + 646 ERROR_RESTRICTED_LOGON_HOURS + 647 ERROR_ACCT_DISABLED + 648 ERROR_PASSWD_EXPIRED + 649 ERROR_NO_DIALIN_PERMISSION + 691 ERROR_AUTHENTICATION_FAILURE + 709 ERROR_CHANGING_PASSWORD + + The "r" is a flag set to "1" if a retry is allowed, and "0" if + not. When the authenticator sets this flag to "1" it disables + short timeouts, expecting the peer to prompt the user for new + credentials and resubmit the response. + + The "cccccccccccccccc" is 16 hexadecimal digits representing an + ASCII representation of a new challenge value. This field is + optional. If it is not sent, the authenticator expects the + resubmitted response to be calculated based on the previous + challenge value plus decimal 23 in the first octet, i.e. the + one immediately following the Value Size field. Windows 95 + authenticators may send this field. Windows NT authenticators + do not, but may in the future. Both systems implement peer + support of this field. + + The "vvvvvvvvvv" is the decimal version code (need not be 10 + digits) indicating the MS-CHAP protocol version supported on + the server. Currently, this is interesting only in selecting a + Change Password packet type. If the field is not present the + version should be assumed to be 1; since use of the version 1 + + + +Zorn & Cobb Informational [Page 4] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + Change Password packet has been deprecated, this field SHOULD + always contain a value greater than or equal to 2. + + Implementations should accept but ignore additional text they do not + recognize. + +9. Change Password Packet (version 1) + + The version 1 Change Password packet does not appear in standard + CHAP. It allows the peer to change the password on the account + specified in the previous Response packet. The version 1 Change + Password packet should be sent only if the authenticator reports + ERROR_PASSWD_EXPIRED (E=648) and V is either missing or equal to one + in the Message field of the Failure packet. + + The use of the Change Password Packet (version 1) has been + deprecated; the format of the packet is described here for + informational purposes, but peers SHOULD NOT transmit it. + + The format of this packet is as follows: + + 1 octet : Code (=5) + 1 octet : Identifier + 2 octets: Length (=72) + 16 octets: Encrypted LAN Manager Old password Hash + 16 octets: Encrypted LAN Manager New Password Hash + 16 octets: Encrypted Windows NT Old Password Hash + 16 octets: Encrypted Windows NT New Password Hash + 2 octets: Password Length + 2 octets: Flags + + Code + 5 + + Identifier + The Identifier field is one octet and aids in matching requests + and replies. The value is the Identifier of the received + Failure packet to which this packet responds plus 1. + + Length + 72 + + Encrypted LAN Manager New Password Hash + Encrypted LAN Manager Old Password Hash + These fields contain the LAN Manager password hash of the new + and old passwords encrypted with the last received challenge + value, as output by the routine LmEncryptedPasswordHash() (see + section A.8, below). + + + +Zorn & Cobb Informational [Page 5] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + Encrypted Windows NT New Password Hash + Encrypted Windows NT Old Password Hash + These fields contain the Windows NT password hash of the new + and old passwords encrypted with the last received challenge + value, as output by the pseudo-code routine + NtEncryptedPasswordHash() (see section A.10, below). + + Password Length + The length in octets of the LAN Manager compatible form of the + new password. If this value is greater than or equal to zero + and less than or equal to 14 it is assumed that the encrypted + LAN Manager password hash fields are valid. Otherwise, it is + assumed these fields are not valid, in which case the Windows + NT compatible passwords MUST be provided. + + Flags + This field is two octets in length. It is a bit field of + option flags where 0 is the least significant bit of the 16-bit + quantity: + + Bit 0 + If this bit is set (1), it indicates that the encrypted + Windows NT hashed passwords are valid and should be used. + If this bit is cleared (0), the Windows NT fields are not + used and the LAN Manager fields must be provided. + + Bits 1-15 + Reserved, always clear (0). + +10. Change Password Packet (version 2) + + The version 2 Change Password packet does not appear in standard + CHAP. It allows the peer to change the password on the account + specified in the preceding Response packet. The version 2 Change + Password packet should be sent only if the authenticator reports + ERROR_PASSWD_EXPIRED (E=648) and a version of 2 or greater in the + Message field of the Failure packet. + + This packet type is supported by Windows NT 3.51, 4.0 and recent + versions of Windows 95. It is not supported by Windows NT 3.5 or + early versions of Windows 95. + + The format of this packet is as follows: + + 1 octet : Code + 1 octet : Identifier + 2 octets : Length + 516 octets : Password Encrypted with Old NT Hash + + + +Zorn & Cobb Informational [Page 6] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + 16 octets : Old NT Hash Encrypted with New NT Hash + 516 octets : Password Encrypted with Old LM Hash + 16 octets : Old LM Hash Encrypted With New NT Hash + 24 octets : LAN Manager compatible challenge response + 24 octets : Windows NT compatible challenge response + 2-octet : Flags + + Code + 6 + + Identifier + The Identifier field is one octet and aids in matching requests + and replies. The value is the Identifier of the received + Failure packet to which this packet responds plus 1. + + Length + 1118 + + Password Encrypted with Old NT Hash + This field contains the PWBLOCK form of the new Windows NT + password encrypted with the old Windows NT password hash, as + output by the NewPasswordEncryptedWithOldNtPasswordHash() + routine (see section A.11, below). + + Old NT Hash Encrypted with New NT Hash + This field contains the old Windows NT password hash encrypted + with the new Windows NT password hash, as output by the + OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (see + section A.14, below). + + Password Encrypted with Old LM Hash + This field contains the PWBLOCK form of the new Windows NT + password encrypted with the old LAN Manager password hash, as + output by the NewPasswordEncryptedWithOldLmPasswordHash() + routine described in section A.15, below. Note, however, that + the use of this field has been deprecated: peers SHOULD NOT + generate it, and this field SHOULD be zero-filled. + + Old LM Hash Encrypted With New NT Hash + This field contains the old LAN Manager password hash encrypted + with the new Windows NT password hash, as output by the + OldLmPasswordHashEncryptedWithNewNtPasswordHash() routine (see + section A.16, below). Note, however, that the use of this + field has been deprecated: peers SHOULD NOT generate it, and + this field SHOULD be zero-filled. + + + + + + +Zorn & Cobb Informational [Page 7] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + LAN Manager compatible challenge response + Windows NT compatible challenge response + The challenge response field (as described in the Response + packet description), but calculated on the new password and the + same challenge used in the last response. Note that use of the + LAN Manager compatible challenge response has been deprecated; + peers SHOULD NOT generate it, and the field SHOULD be zero- + filled. + + Flags + This field is two octets in length. It is a bit field of + option flags where 0 is the least significant bit of the 16-bit + quantity. The format of this field is illustrated in the + following diagram: + + 1 + 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Bit 0 + The "use Windows NT compatible challenge response" flag + as described in the Response packet. + + Bit 1 + Set (1) indicates that the "Password Encrypted with Old + LM Hash" and "Old LM Hash Encrypted With New NT Hash" + fields are valid and should be used. Clear (0) indicates + these fields are not valid. This bit SHOULD always be + clear (0). + + Bits 2-15 + Reserved, always clear (0). + +11. Security Considerations + + As an implementation detail, the authenticator SHOULD limit the + number of password retries allowed to make brute-force password + guessing attacks more difficult. + + Because the challenge value is encrypted using the password hash to + form the response and the challenge is transmitted in clear-text + form, both passive known-plaintext and active chosen-plaintext + attacks against the password hash are possible. Suitable precautions + (i.e., frequent password changes) SHOULD be taken in environments + where eavesdropping is likely. + + + + +Zorn & Cobb Informational [Page 8] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + The Change Password (version 1) packet is vulnerable to a passive + eavesdropping attack which can easily reveal the new password hash. + For this reason, it MUST NOT be sent if eavesdropping is possible. + +12. References + + [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC + 1661, July 1994. + + [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol + (CHAP)", RFC 1994, August 1996. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] "Data Encryption Standard (DES)", Federal Information Processing + Standard Publication 46-2, National Institute of Standards and + Technology, December 1993. + + [5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April 1992. + + [6] RC4 is a proprietary encryption algorithm available under license + from RSA Data Security Inc. For licensing information, contact: + RSA Data Security, Inc. + 100 Marine Parkway + Redwood City, CA 94065-1031 + + [7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness + Recomnendations for Security", RFC 1750, December 1994. + + [8] "The Unicode Standard, Version 2.0", The Unicode Consortium, + Addison-Wesley, 1996. ISBN 0-201-48345-9. + + [9] "DES Modes of Operation", Federal Information Processing + Standards Publication 81, National Institute of Standards and + Technology, December 1980 + +13. Acknowledgements + + Thanks (in no particular order) to Jeff Haag (Jeff_Haag@3com.com), + Bill Palter (palter@network-alchemy.com), Bruce Johnson + (bjohnson@microsoft.com), Tony Bell (tonybe@microsoft.com), Benoit + Martin (ehlija@vircom.com), and Joe Davies (josephd@microsoft.com) + for useful suggestions and feedback. + + + + + + + +Zorn & Cobb Informational [Page 9] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +14. Chair's Address + + The PPP Extensions Working Group can be contacted via the current + chair: + + Karl Fox + Ascend Communications + 3518 Riverside Drive + Suite 101 + Columbus, OH 43221 + + Phone: +1 614 326 6841 + EMail: karl@ascend.com + +15. Authors' Addresses + + Questions about this memo can also be directed to: + + Glen Zorn + Microsoft Corporation + One Microsoft Way + Redmond, Washington 98052 + + Phone: +1 425 703 1559 + Fax: +1 425 936 7329 + EMail: glennz@microsoft.com + + + Steve Cobb + Microsoft Corporation + One Microsoft Way + Redmond, Washington 98052 + + EMail: stevec@microsoft.com + + + + + + + + + + + + + + + + + +Zorn & Cobb Informational [Page 10] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +Appendix A - Pseudocode + + The routines mentioned in the text are described in pseudocode below. + +A.1 LmChallengeResponse() + + LmChallengeResponse( + IN 8-octet Challenge, + IN 0-to-14-oem-char Password, + OUT 24-octet Response ) + { + LmPasswordHash( Password, giving PasswordHash ) + ChallengeResponse( Challenge, PasswordHash, giving Response ) + } + + +A.2 LmPasswordHash() + + LmPasswordHash( + IN 0-to-14-oem-char Password, + OUT 16-octet PasswordHash ) + { + Set UcasePassword to the uppercased Password + Zero pad UcasePassword to 14 characters + + DesHash( 1st 7-octets of UcasePassword, + giving 1st 8-octets of PasswordHash ) + + DesHash( 2nd 7-octets of UcasePassword, + giving 2nd 8-octets of PasswordHash ) + } + + +A.3 DesHash() + + DesHash( + IN 7-octet Clear, + OUT 8-octet Cypher ) + { + /* + * Make Cypher an irreversibly encrypted form of Clear by + * encrypting known text using Clear as the secret key. + * The known text consists of the string + * + * KGS!@#$% + */ + + Set StdText to "KGS!@#$%" + + + +Zorn & Cobb Informational [Page 11] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + DesEncrypt( StdText, Clear, giving Cypher ) + } + + +A.4 DesEncrypt() + + DesEncrypt( + IN 8-octet Clear, + IN 7-octet Key, + OUT 8-octet Cypher ) + { + /* + * Use the DES encryption algorithm [4] in ECB mode [9] + * to encrypt Clear into Cypher such that Cypher can + * only be decrypted back to Clear by providing Key. + * Note that the DES algorithm takes as input a 64-bit + * stream where the 8th, 16th, 24th, etc. bits are + * parity bits ignored by the encrypting algorithm. + * Unless you write your own DES to accept 56-bit input + * without parity, you will need to insert the parity bits + * yourself. + */ + } + + +A.5 NtChallengeResponse() + + NtChallengeResponse( + IN 8-octet Challenge, + IN 0-to-256-unicode-char Password, + OUT 24-octet Response ) + { + NtPasswordHash( Password, giving PasswordHash ) + ChallengeResponse( Challenge, PasswordHash, giving Response ) + } + + +A.6 NtPasswordHash() + + NtPasswordHash( + IN 0-to-256-unicode-char Password, + OUT 16-octet PasswordHash ) + { + /* + * Use the MD4 algorithm [5] to irreversibly hash Password + * into PasswordHash. Only the password is hashed without + * including any terminating 0. + */ + + + +Zorn & Cobb Informational [Page 12] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + } + + +A.7 ChallengeResponse() + + ChallengeResponse( + IN 8-octet Challenge, + IN 16-octet PasswordHash, + OUT 24-octet Response ) + { + Set ZPasswordHash to PasswordHash zero-padded to 21 octets + + DesEncrypt( Challenge, + 1st 7-octets of ZPasswordHash, + giving 1st 8-octets of Response ) + + DesEncrypt( Challenge, + 2nd 7-octets of ZPasswordHash, + giving 2nd 8-octets of Response ) + + DesEncrypt( Challenge, + 3rd 7-octets of ZPasswordHash, + giving 3rd 8-octets of Response ) + } + + +A.8 LmEncryptedPasswordHash() + + LmEncryptedPasswordHash( + IN 0-to-14-oem-char Password, + IN 8-octet KeyValue, + OUT 16-octet Cypher ) + { + LmPasswordHash( Password, giving PasswordHash ) + + PasswordHashEncryptedWithBlock( PasswordHash, + KeyValue, + giving Cypher ) + } + + +A.9 PasswordHashEncryptedWithBlock() + + PasswordHashEncryptedWithBlock( + IN 16-octet PasswordHash, + IN 8-octet Block, + OUT 16-octet Cypher ) + { + + + +Zorn & Cobb Informational [Page 13] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + DesEncrypt( 1st 8-octets PasswordHash, + 1st 7-octets Block, + giving 1st 8-octets Cypher ) + + DesEncrypt( 2nd 8-octets PasswordHash, + 1st 7-octets Block, + giving 2nd 8-octets Cypher ) + } + + +A.10 NtEncryptedPasswordHash() + + NtEncryptedPasswordHash( IN 0-to-14-oem-char Password IN 8-octet + Challenge OUT 16-octet Cypher ) { + NtPasswordHash( Password, giving PasswordHash ) + + PasswordHashEncryptedWithBlock( PasswordHash, + Challenge, + giving Cypher ) + } + + +A.11 NewPasswordEncryptedWithOldNtPasswordHash() + + datatype-PWBLOCK + { + 256-unicode-char Password + 4-octets PasswordLength + } + + NewPasswordEncryptedWithOldNtPasswordHash( + IN 0-to-256-unicode-char NewPassword, + IN 0-to-256-unicode-char OldPassword, + OUT datatype-PWBLOCK EncryptedPwBlock ) + { + NtPasswordHash( OldPassword, giving PasswordHash ) + + EncryptPwBlockWithPasswordHash( NewPassword, + PasswordHash, + giving EncryptedPwBlock ) + } + + +A.12 EncryptPwBlockWithPasswordHash() + + EncryptPwBlockWithPasswordHash( + IN 0-to-256-unicode-char Password, + IN 16-octet PasswordHash, + + + +Zorn & Cobb Informational [Page 14] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + OUT datatype-PWBLOCK PwBlock ) + { + + Fill ClearPwBlock with random octet values + PwSize = lstrlenW( Password ) * sizeof( unicode-char ) + PwOffset = sizeof( ClearPwBlock.Password ) - PwSize + Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from Password + ClearPwBlock.PasswordLength = PwSize + Rc4Encrypt( ClearPwBlock, + sizeof( ClearPwBlock ), + PasswordHash, + sizeof( PasswordHash ), + giving PwBlock ) + } + + +A.13 Rc4Encrypt() + + Rc4Encrypt( + IN x-octet Clear, + IN integer ClearLength, + IN y-octet Key, + IN integer KeyLength, + OUT x-octet Cypher ) + { + /* + * Use the RC4 encryption algorithm [6] to encrypt Clear of + * length ClearLength octets into a Cypher of the same length + * such that the Cypher can only be decrypted back to Clear + * by providing a Key of length KeyLength octets. + */ + } + + +A.14 OldNtPasswordHashEncryptedWithNewNtPasswordHash() + + OldNtPasswordHashEncryptedWithNewNtPasswordHash( + IN 0-to-256-unicode-char NewPassword, + IN 0-to-256-unicode-char OldPassword, + OUT 16-octet EncryptedPasswordHash ) + { + NtPasswordHash( OldPassword, giving OldPasswordHash ) + NtPasswordHash( NewPassword, giving NewPasswordHash ) + NtPasswordHashEncryptedWithBlock( OldPasswordHash, + NewPasswordHash, + giving EncryptedPasswordHash ) + } + + + + +Zorn & Cobb Informational [Page 15] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +A.15 NewPasswordEncryptedWithOldLmPasswordHash() + + NewPasswordEncryptedWithOldLmPasswordHash( + IN 0-to-256-unicode-char NewPassword, + IN 0-to-256-unicode-char OldPassword, + OUT datatype-PWBLOCK EncryptedPwBlock ) + { + LmPasswordHash( OldPassword, giving PasswordHash ) + + EncryptPwBlockWithPasswordHash( NewPassword, PasswordHash, + giving EncryptedPwBlock ) + } + + +A.16 OldLmPasswordHashEncryptedWithNewNtPasswordHash() + + OldLmPasswordHashEncryptedWithNewNtPasswordHash( + IN 0-to-256-unicode-char NewPassword, + IN 0-to-256-unicode-char OldPassword, + OUT 16-octet EncryptedPasswordHash ) + { + LmPasswordHash( OldPassword, giving OldPasswordHash ) + + NtPasswordHash( NewPassword, giving NewPasswordHash ) + + NtPasswordHashEncryptedWithBlock( OldPasswordHash, NewPasswordHash, + giving EncrytptedPasswordHash ) + } + + +A.17 NtPasswordHashEncryptedWithBlock() + + NtPasswordHashEncryptedWithBlock( + IN 16-octet PasswordHash, + IN 16-octet Block, + OUT 16-octet Cypher ) + { + DesEncrypt( 1st 8-octets PasswordHash, + 1st 7-octets Block, + giving 1st 8-octets Cypher ) + + DesEncrypt( 2nd 8-octets PasswordHash, + 2nd 7-octets Block, + giving 2nd 8-octets Cypher ) + } + + + + + + +Zorn & Cobb Informational [Page 16] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +Appendix B - Examples + +B.1 Negotiation Examples + + Here are some examples of typical negotiations. The peer is on the + left and the authenticator is on the right. + + The packet sequence ID is incremented on each authentication retry + Response and on the change password response. All cases where the + packet sequence ID is updated are noted below. + + Response retry is never allowed after Change Password. Change + Password may occur after Response retry. The implied challenge form + is shown in the examples, though all cases of "first challenge+23" + should be replaced by the "C=cccccccccccccccc" challenge if + authenticator supplies it in the Failure packet. + +B.1.1 Successful authentication + + <- Challenge + Response -> + <- Success + + +B.1.2 Failed authentication with no retry allowed + + <- Challenge + Response -> + <- Failure (E=691 R=0) + + +B.1.3 Successful authentication after retry + + <- Challenge + Response -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to first challenge+23 -> + <- Success + + +B.1.4 Failed hack attack with 3 attempts allowed + + <- Challenge + Response -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to first challenge+23 -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to first challenge+23+23 -> + + + +Zorn & Cobb Informational [Page 17] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + <- Failure (E=691 R=0) + + +B.1.5 Successful authentication with password change + + <- Challenge + Response -> + <- Failure (E=648 R=0 V=2), disable short timeout + ChangePassword (++ID) to first challenge -> + <- Success + + +B.1.6 Successful authentication with retry and password change + + <- Challenge + Response -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to first challenge+23 -> + <- Failure (E=648 R=0 V=2), disable short timeout + ChangePassword (++ID) to first challenge+23 -> + <- Success + +B.2 Hash Example + +Intermediate values for password "MyPw". + + 8-octet Challenge: + 10 2D B5 DF 08 5D 30 41 + + 0-to-256-unicode-char NtPassword: + 4D 00 79 00 50 00 77 00 + + 16-octet NtPasswordHash: + FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC + + 24-octet NtChallengeResponse: + 4E 9D 3C 8F 9C FD 38 5D 5B F4 D3 24 67 91 95 6C + A4 C3 51 AB 40 9A 3D 61 + +B.3 Example of DES Key Generation + +DES uses 56-bit keys, expanded to 64 bits by the insertion of parity +bits. After the parity of the key has been fixed, every eighth bit is a +parity bit and the number of bits that are set (1) in each octet is odd; +i.e., odd parity. Note that many DES engines do not check parity, +however, simply stripping the parity bits. The following example +illustrates the values resulting from the use of the 16-octet +NTPasswordHash shown in Appendix B.2 to generate a pair of DES keys + + + +Zorn & Cobb Informational [Page 18] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +(e.g., for use in the NtPasswordHashEncryptedWithBlock() described in +Appendix A.17). + + 16-octet NtPasswordHash: + FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC + + First "raw" DES key (initial 7 octets of password hash): + FC 15 6A F7 ED CD 6C + + First parity-corrected DES key (eight octets): + FD 0B 5B 5E 7F 6E 34 D9 + + Second "raw" DES key (second 7 octets of password hash) + 0E DD E3 33 7D 42 7F + + Second parity-corrected DES key (eight octets): + 0E 6E 79 67 37 EA 08 FE + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zorn & Cobb Informational [Page 19] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Zorn & Cobb Informational [Page 20] + diff --git a/rfc/rfc2548.txt b/rfc/rfc2548.txt new file mode 100644 index 00000000..35c83c3e --- /dev/null +++ b/rfc/rfc2548.txt @@ -0,0 +1,2299 @@ + + + + + + +Network Working Group G. Zorn +Request for Comments: 2548 Microsoft Corporation +Category: Informational March 1999 + + + Microsoft Vendor-specific RADIUS Attributes + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + This document describes the set of Microsoft vendor-specific RADIUS + attributes. These attributes are designed to support Microsoft + proprietary dial-up protocols and/or provide support for features + which is not provided by the standard RADIUS attribute set [3]. It + is expected that this memo will be updated whenever Microsoft defines + a new vendor-specific attribute, since its primary purpose is to + provide an open, easily accessible reference for third-parties + wishing to interoperate with Microsoft products. + +1. Specification of Requirements + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as + described in [2]. + +2. Attributes + + The following sections describe sub-attributes which may be + transmitted in one or more RADIUS attributes of type Vendor-Specific + [3]. More than one sub-attribute MAY be transmitted in a single + Vendor-Specific Attribute; if this is done, the sub-attributes SHOULD + be packed as a sequence of Vendor-Type/Vendor-Length/Value triples + following the inital Type, Length and Vendor-ID fields. The Length + field of the Vendor-Specific Attribute MUST be set equal to the sum + of the Vendor-Length fields of the sub-attributes contained in the + Vendor-Specific Attribute, plus six. The Vendor-ID field of the + Vendor-Specific Attribute(s) MUST be set to decimal 311 (Microsoft). + + + + + +Zorn Informational [Page 1] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.1. Attributes for Support of MS-CHAP Version 1 + +2.1.1. Introduction + + Microsoft created Microsoft Challenge-Handshake Authentication + Protocol (MS-CHAP) [4] to authenticate remote Windows workstations, + providing the functionality to which LAN-based users are accustomed. + Where possible, MS-CHAP is consistent with standard CHAP [5], and the + differences are easily modularized. Briefly, the differences between + MS-CHAP and standard CHAP are: + + * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP + option 3, Authentication Protocol. + + * The MS-CHAP Response packet is in a format designed for + compatibility with Microsoft Windows NT 3.5, 3.51 and 4.0, + Microsoft Windows95, and Microsoft LAN Manager 2.x networking + products. The MS-CHAP format does not require the authenticator + to store a clear-text or reversibly encrypted password. + + * MS-CHAP provides an authenticator-controlled authentication + retry mechanism. + + * MS-CHAP provides an authenticator-controlled password changing + mechanism. + + * MS-CHAP defines an extended set of reason-for-failure codes, + returned in the Failure packet Message field. + + The attributes defined in this section reflect these differences. + +2.1.2. MS-CHAP-Challenge + + Description + + This Attribute contains the challenge sent by a NAS to a Microsoft + Challenge-Handshake Authentication Protocol (MS-CHAP) user. It + MAY be used in both Access-Request and Access-Challenge packets. + + A summary of the MS-CHAP-Challenge Attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + + + +Zorn Informational [Page 2] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 11 for MS-CHAP-Challenge. + + Vendor-Length + > 2 + + String + The String field contains the MS-CHAP challenge. + +2.1.3. MS-CHAP-Response + + Description + + This Attribute contains the response value provided by a PPP + Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) + user in response to the challenge. It is only used in Access- + Request packets. + + A summary of the MS-CHAP-Response Attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 3] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Ident | Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LM-Response + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response(cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NT-Response + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 1 for MS-CHAP-Response. + + Vendor-Length + 52 + + Ident + Identical to the PPP CHAP Identifier. + + Flags + The Flags field is one octet in length. If the Flags field is one + (0x01), the NT-Response field is to be used in preference to the + LM-Response field for authentication. The LM-Response field MAY + still be used (if non-empty), but the NT-Response SHOULD be tried + first. If it is zero, the NT-Response field MUST be ignored and + the LM-Response field used. + + + + + +Zorn Informational [Page 4] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + LM-Response + The LM-Response field is 24 octets in length and holds an encoded + function of the password and the received challenge. If this + field is empty, it SHOULD be zero-filled. + + NT-Response + + The NT-Response field is 24 octets in length and holds an encoded + function of the password and the received challenge. If this + field is empty, it SHOULD be zero-filled. + +2.1.4. MS-CHAP-Domain + + Description + + The MS-CHAP-Domain Attribute indicates the Windows NT domain in + which the user was authenticated. It MAY be included in both + Access-Accept and Accounting-Request packets. + + A summary of the MS-CHAP-Domain Attribute format is given below. The + fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Ident | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 10 for MS-CHAP-Domain. + + Vendor-Length + > 3 + + Ident + The Ident field is one octet and aids in matching requests and + replies. + + String + This field contains the name in ASCII of the Windows NT domain in + which the user was authenticated. + + + + + + + + + + +Zorn Informational [Page 5] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.1.5. MS-CHAP-Error + + Description + + The MS-CHAP-Error Attribute contains error data related to the + preceding MS-CHAP exchange. This Attribute may be used in both + MS-CHAP-V1 and MS-CHAP-V2 (see below) exchanges. It is only used + in Access-Reject packets. + + A summary of the MS-CHAP-Error Attribute format is given below. The + fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Ident | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 2 for MS-CHAP-Error. + + Vendor-Length + > 3 + + Ident + The Ident field is one octet and aids in matching requests and + replies. + + String + This field contains specially formatted ASCII text, which is + interpreted by the authenticating peer. + +2.1.6. MS-CHAP-CPW-1 + + Description + + This Attribute allows the user to change their password if it has + expired. This Attribute is only used in Access-Request packets, and + should only be included if an MS-CHAP-Error attribute was included in + the immediately preceding Access-Reject packet, the String field of + the MS-CHAP-Error attribute indicated that the user password had + expired, and the MS-CHAP version is less than 2. + + A summary of the MS-CHAP-CPW-1 Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + +Zorn Informational [Page 6] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Code | Ident | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LM-Old-Password + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Old-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Old-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Old-Password (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LM-New-Password + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-New-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-New-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-New-Password (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NT-Old-Password + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Old-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Old-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Old-Password (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NT-New-Password + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-New-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-New-Password (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-New-Password (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | New-LM-Password-Length | Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 3 for MS-CHAP-PW-1 + + Vendor-Length + 72 + + Code + The Code field is one octet in length. Its value is always 5. + + + +Zorn Informational [Page 7] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Ident + The Ident field is one octet and aids in matching requests and + replies. + + LM-Old-Password + The LM-Old-Password field is 16 octets in length. It contains the + encrypted Lan Manager hash of the old password. + + LM-New-Password + The LM-New-Password field is 16 octets in length. It contains the + encrypted Lan Manager hash of the new password. + + NT-Old-Password + The NT-Old-Password field is 16 octets in length. It contains the + encrypted Lan Manager hash of the old password. + + NT-New-Password + The NT-New-Password field is 16 octets in length. It contains the + encrypted Lan Manager hash of the new password. + + New-LM-Password-Length + The New-LM-Password-Length field is two octets in length and + contains the length in octets of the new LAN Manager-compatible + password. + + Flags + The Flags field is two octets in length. If the least significant + bit of the Flags field is one, this indicates that the NT-New- + Password and NT-Old-Password fields are valid and SHOULD be used. + Otherwise, the LM-New-Password and LM-Old-Password fields MUST be + used. + +2.1.7. MS-CHAP-CPW-2 + + Description + + This Attribute allows the user to change their password if it has + expired. This Attribute is only used in Access-Request packets, + and should only be included if an MS-CHAP-Error attribute was + included in the immediately preceding Access-Reject packet, the + String field of the MS-CHAP-Error attribute indicated that the + user password had expired, and the MS-CHAP version is equal to 2. + + A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + +Zorn Informational [Page 8] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Code | Ident | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Old-NT-Hash + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Old-NT-Hash (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Old-NT-Hash (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Old-NT-Hash (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Old-LM-Hash + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Old-LM-Hash(cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Old-LM-Hash(cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Old-LM-Hash(cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LM-Response + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Response (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NT-Response + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Zorn Informational [Page 9] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Vendor-Type + 4 for MS-CHAP-PW-2 + + Vendor-Length + 86 + + Code + 6 + + Ident + The Ident field is one octet and aids in matching requests and + replies. The value of this field MUST be identical to that in the + Ident field in all instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT- + Enc-PW and MS-CHAP-PW-2 attributes contained in a single Access- + Request packet. + + Old-NT-Hash + The Old-NT-Hash field is 16 octets in length. It contains the old + Windows NT password hash encrypted with the new Windows NT + password hash. + + Old-LM-Hash + The Old-LM-Hash field is 16 octets in length. It contains the old + Lan Manager password hash encrypted with the new Windows NT + password hash. + + LM-Response + The LM-Response field is 24 octets in length and holds an encoded + function of the password and the received challenge. If this + field is empty, it SHOULD be zero-filled. + + NT-Response + The NT-Response field is 24 octets in length and holds an encoded + function of the password and the received challenge. If this + field is empty, it SHOULD be zero-filled. + + Flags + The Flags field is two octets in length. If the least significant + bit (bit 0) of this field is one, the NT-Response field is to be + used in preference to the LM-Response field for authentication. + The LM-Response field MAY still be used (if present), but the NT- + Response SHOULD be tried first. If least significant bit of the + field is zero, the NT-Response field MUST be ignored and the LM- + Response field used instead. If bit 1 of the Flags field is one, + the Old-LM-Hash field is valid and SHOULD be used. If this bit is + set, at least one instance of the MS-CHAP-LM-Enc-PW attribute MUST + be included in the packet. + + + + +Zorn Informational [Page 10] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.1.8. MS-CHAP-LM-Enc-PW + + Description + + This Attribute contains the new Windows NT password encrypted with + the old LAN Manager password hash. The encrypted Windows NT + password is 516 octets in length; since this is longer than the + maximum lengtth of a RADIUS attribute, the password must be split + into several attibutes for transmission. A 2 octet sequence + number is included in the attribute to help preserve ordering of + the password fragments. + + This Attribute is only used in Access-Request packets, in + conjunction with the MS-CHAP-CPW-2 attribute. It should only be + included if an MS-CHAP-Error attribute was included in the + immediately preceding Access-Reject packet, the String field of + the MS-CHAP-Error attribute indicated that the user password had + expired, and the MS-CHAP version is 2 or greater. + + A summary of the MS-CHAP-LM-Enc-PW Attribute format is shown below. + The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Code | Ident | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence-Number | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 5 for MS-CHAP-LM-Enc-PW + + Vendor-Length + > 6 + + Code 6. Code is the same as for the MS-CHAP-PW-2 attribute. + + Ident + The Ident field is one octet and aids in matching requests and + replies. The value of this field MUST be identical in all + instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS- + CHAP-PW-2 attributes which are present in the same Access-Request + packet. + + + + + + + +Zorn Informational [Page 11] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Sequence-Number + The Sequence-Number field is two octets in length and indicates + which "chunk" of the encrypted password is contained in the + following String field. + + String The String field contains a portion of the encrypted password. + +2.2. MS-CHAP-NT-Enc-PW + + Description + + This Attribute contains the new Windows NT password encrypted with + the old Windows NT password hash. The encrypted Windows NT + password is 516 octets in length; since this is longer than the + maximum lengtth of a RADIUS attribute, the password must be split + into several attibutes for transmission. A 2 octet sequence + number is included in the attribute to help preserve ordering of + the password fragments. + + This Attribute is only used in Access-Request packets, in conjunc- + tion with the MS-CHAP-CPW-2 and MS-CHAP2-CPW attributes. It + should only be included if an MS-CHAP-Error attribute was included + in the immediately preceding Access-Reject packet, the String + field of the MS-CHAP-Error attribute indicated that the user + password had expired, and the MS-CHAP version is 2 or greater. + + A summary of the MS-CHAP-NT-Enc-PW Attribute format is shown below. + The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Code | Ident | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence-Number | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 6 for MS-CHAP-NT-Enc-PW + + Vendor-Length + > 6 + + Code + 6. Code is the same as for the MS-CHAP-PW-2 attribute. + + + + + + +Zorn Informational [Page 12] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Ident + The Ident field is one octet and aids in matching requests and + replies. The value of this field MUST be identical in all + instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS- + CHAP-PW-2 attributes which are present in the same Access-Request + packet. + + Sequence-Number + The Sequence-Number field is two octets in length and indicates + which "chunk" of the encrypted password is contained in the + following String field. + + String + The String field contains a portion of the encrypted password. + +2.3. Attributes for Support of MS-CHAP Version 2 + +2.3.1. Introduction + + This section describes RADIUS attributes supporting version two of + Microsoft's PPP CHAP dialect (MS-CHAP-V2) [14]. MS-CHAP-V2 is + similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1) + [4]. Certain protocol fields have been deleted or reused but with + different semantics. Where possible, MS-CHAP-V2 is consistent with + both MS-CHAP-V1 and standard CHAP [1]. Briefly, the differences + between MS-CHAP-V2 and MS-CHAP-V1 are: + + * MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP + option 3, Authentication Protocol. + + * MS-CHAP-V2 provides mutual authentication between peers by + piggybacking a peer challenge on the Response packet and an + authenticator response on the Success packet. + + * The calculation of the "Windows NT compatible challenge + response" sub-field in the Response packet has been changed to + include the peer challenge and the user name. + + * In MS-CHAP-V1, the "LAN Manager compatible challenge response" + sub-field was always sent in the Response packet. This field + has been replaced in MS-CHAP-V2 by the Peer-Challenge field. + + * The format of the Message field in the Failure packet has been + changed. + + * The Change Password (version 1) and Change Password (version 2) + packets are no longer supported. They have been replaced with a + single Change-Password packet. + + + +Zorn Informational [Page 13] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + The attributes defined in this section reflect these differences. + +2.3.2. MS-CHAP2-Response + + Description + + This Attribute contains the response value provided by an MS- + CHAP-V2 peer in response to the challenge. It is only used in + Access-Request packets. + + A summary of the MS-CHAP2-Response Attribute format is shown below. + The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Ident | Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer-Challenge + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Reserved (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Response + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Response (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 25 for MS-CHAP2-Response. + + Vendor-Length + 52 + + + +Zorn Informational [Page 14] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Ident + Identical to the PPP MS-CHAP v2 Identifier. + + Flags + The Flags field is one octet in length. It is reserved for future + use and MUST be zero. + + Peer-Challenge + The Peer-Challenge field is a 16-octet random number. + + Reserved + This field is reserved for future use and MUST be zero. + + Response + The Response field is 24 octets in length and holds an encoded + function of the password, the Peer-Challenge field and the + received challenge. + +2.3.3. MS-CHAP2-Success + + Description + + This Attribute contains a 42-octet authenticator response string. + This string MUST be included in the Message field of the MS-CHAP- + V2 Success packet sent from the NAS to the peer. This Attribute + is only used in Access-Accept packets. + + A summary of the MS-CHAP2-Success Attribute format is shown below. + The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Ident | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 26 for MS-CHAP2-Success. + + Vendor-Length + 45 + + Ident + Identical to the PPP MS-CHAP v2 Identifier. + + String + The 42-octet authenticator string (see above). + + + + +Zorn Informational [Page 15] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.3.4. MS-CHAP2-CPW + + Description + + This Attribute allows the user to change their password if it has + expired. This Attribute is only used in conjunction with the MS- + CHAP-NT-Enc-PW attribute in Access-Request packets, and should + only be included if an MS-CHAP-Error attribute was included in the + immediately preceding Access-Reject packet, the String field of + the MS-CHAP-Error attribute indicated that the user password had + expired, and the MS-CHAP version is equal to 3. + + A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 16] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Code | Ident | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Encrypted-Hash + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Encrypted-Hash (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Encrypted-Hash (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Encrypted-Hash (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer-Challenge + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Peer-Challenge (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NT-Response + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Response (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 27 for MS-CHAP2-PW + + Vendor-Length + 70 + + Code + 7 + + + +Zorn Informational [Page 17] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Ident + The Ident field is one octet and aids in matching requests and + replies. The value of this field MUST be identical to that in the + Ident field in all instances of the MS-CHAP-NT-Enc-PW contained in + the Access-Request packet. + + Encrypted-Hash + The Encrypted-Hash field is 16 octets in length. It contains the + old Windows NT password hash encrypted with the new Windows NT + password hash. + + NT-Response + The NT-Response field is 24 octets in length and holds an encoded + function of the new password, the Peer-Challenge field and the + received challenge. + + Flags + The Flags field is two octets in length. This field is reserved + for future use and MUST be zero. + +2.4. Attributes for MPPE Support + + This section describes a set of Attributes designed to support the + use of Microsoft Point-to-Point Encryption (MPPE) [6] in dial-up + networks. MPPE is a means of representing Point to Point Protocol + (PPP) [7] packets in a encrypted form. MPPE uses the RSA RC4 [8] + algorithm for encryption. The length of the session key to be used + for initializing encryption tables can be negotiated; MPPE currently + supports 40 bit and 128 bit session keys. MPPE is negotiated within + option 18 in the PPP Compression Control Protocol (CCP)[9], [10]. + +2.4.1. MS-CHAP-MPPE-Keys + + Description + + The MS-CHAP-MPPE-Keys Attribute contains two session keys for use + by the Microsoft Point-to-Point Encryption Protocol (MPPE). This + Attribute is only included in Access-Accept packets. + + A summary of the MS-CHAP-MPPE-Keys Attribute format is given below. + The fields are transmitted left to right. + + + + + + + + + + +Zorn Informational [Page 18] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Keys + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Keys (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 12 for MS-CHAP-MPPE-Keys. + + Vendor-Length + 34 + + Keys + The Keys field consists of two logical sub-fields: the LM-Key and + the NT-Key. The LM-Key is eight octets in length and contains the + first eight bytes of the output of the function LmPasswordHash(P, + This hash is constructed as follows: let the plain-text password + be represented by P. + + The NT-Key sub-field is sixteen octets in length and contains the + first sixteen octets of the hashed Windows NT password. The + format of the plaintext Keys field is illustrated in the following + diagram: + + + + + + + + + + + + +Zorn Informational [Page 19] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LM-Key + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + LM-Key (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NT-Key + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Key (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Key (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + NT-Key (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Padding + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Padding (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Keys field MUST be encrypted by the RADIUS server using the + same method defined for the User-Password Attribute [3]. Padding + is required because the method referenced above requires the field + to be encrypted to be a multiple of sixteen octets in length. + + Implementation Note + This attribute should only be returned in response to an + Access-Request packet containing MS-CHAP attributes. + +2.4.2. MS-MPPE-Send-Key + + Description + + The MS-MPPE-Send-Key Attribute contains a session key for use by + the Microsoft Point-to-Point Encryption Protocol (MPPE). As the + name implies, this key is intended for encrypting packets sent + from the NAS to the remote host. This Attribute is only included + in Access-Accept packets. + + A summary of the MS-MPPE-Send-Key Attribute format is given below. + The fields are transmitted left to right. + + + + + + + + + + +Zorn Informational [Page 20] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Salt + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 16 for MS-MPPE-Send-Key. + + Vendor-Length + > 4 + + Salt + The Salt field is two octets in length and is used to ensure the + uniqueness of the keys used to encrypt each of the encrypted + attributes occurring in a given Access-Accept packet. The most + significant bit (leftmost) of the Salt field MUST be set (1). The + contents of each Salt field in a given Access-Accept packet MUST + be unique. + + String + The plaintext String field consists of three logical sub-fields: + the Key-Length and Key sub-fields (both of which are required), + and the optional Padding sub-field. The Key-Length sub-field is + one octet in length and contains the length of the unencrypted Key + sub-field. The Key sub-field contains the actual encryption key. + If the combined length (in octets) of the unencrypted Key-Length + and Key sub-fields is not an even multiple of 16, then the Padding + sub-field MUST be present. If it is present, the length of the + Padding sub-field is variable, between 1 and 15 octets. The + String field MUST be encrypted as follows, prior to transmission: + + Construct a plaintext version of the String field by concate- + nating the Key-Length and Key sub-fields. If necessary, pad + the resulting string until its length (in octets) is an even + multiple of 16. It is recommended that zero octets (0x00) be + used for padding. Call this plaintext P. + + Call the shared secret S, the pseudo-random 128-bit Request + Authenticator (from the corresponding Access-Request packet) R, + and the contents of the Salt field A. Break P into 16 octet + chunks p(1), p(2)...p(i), where i = len(P)/16. Call the + ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. + Intermediate values b(1), b(2)...c(i) are required. Encryption + is performed in the following manner ('+' indicates + concatenation): + + + +Zorn Informational [Page 21] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) + b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) + . . + . . + . . + b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) + + The resulting encrypted String field will contain + c(1)+c(2)+...+c(i). + + On receipt, the process is reversed to yield the plaintext String. + + Implementation Notes + It is possible that the length of the key returned may be larger + than needed for the encryption scheme in use. In this case, the + RADIUS client is responsible for performing any necessary + truncation. + + This attribute MAY be used to pass a key from an external (e.g., + EAP [15]) server to the RADIUS server. In this case, it may be + impossible for the external server to correctly encrypt the key, + since the RADIUS shared secret might be unavailable. The external + server SHOULD, however, return the attribute as defined above; the + Salt field SHOULD be zero-filled and padding of the String field + SHOULD be done. When the RADIUS server receives the attribute + from the external server, it MUST correctly set the Salt field and + encrypt the String field before transmitting it to the RADIUS + client. If the channel used to communicate the MS-MPPE-Send-Key + attribute is not secure from eavesdropping, the attribute MUST be + cryptographically protected. + +2.4.3. MS-MPPE-Recv-Key + + Description + + The MS-MPPE-Recv-Key Attribute contains a session key for use by + the Microsoft Point-to-Point Encryption Protocol (MPPE). As the + name implies, this key is intended for encrypting packets received + by the NAS from the remote host. This Attribute is only included + in Access-Accept packets. + + A summary of the MS-MPPE-Recv-Key Attribute format is given below. + The fields are transmitted left to right. + + + + + + + + +Zorn Informational [Page 22] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Salt + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 17 for MS-MPPE-Recv-Key. + + Vendor-Length + > 4 + + Salt + The Salt field is two octets in length and is used to ensure the + uniqueness of the keys used to encrypt each of the encrypted + attributes occurring in a given Access-Accept packet. The most + significant bit (leftmost) of the Salt field MUST be set (1). The + contents of each Salt field in a given Access-Accept packet MUST + be unique. + + String + The plaintext String field consists of three logical sub-fields: + the Key-Length and Key sub-fields (both of which are required), + and the optional Padding sub-field. The Key-Length sub-field is + one octet in length and contains the length of the unencrypted Key + sub-field. The Key sub-field contains the actual encryption key. + If the combined length (in octets) of the unencrypted Key-Length + and Key sub-fields is not an even multiple of 16, then the Padding + sub-field MUST be present. If it is present, the length of the + Padding sub-field is variable, between 1 and 15 octets. The + String field MUST be encrypted as follows, prior to transmission: + + Construct a plaintext version of the String field by + concatenating the Key-Length and Key sub-fields. If necessary, + pad the resulting string until its length (in octets) is an + even multiple of 16. It is recommended that zero octets (0x00) + be used for padding. Call this plaintext P. + + Call the shared secret S, the pseudo-random 128-bit Request + Authenticator (from the corresponding Access-Request packet) R, + and the contents of the Salt field A. Break P into 16 octet + chunks p(1), p(2)...p(i), where i = len(P)/16. Call the + ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. + Intermediate values b(1), b(2)...c(i) are required. Encryption + is performed in the following manner ('+' indicates + concatenation): + + + +Zorn Informational [Page 23] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) + b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) + . . + . . + . . + b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) + + The resulting encrypted String field will contain + c(1)+c(2)+...+c(i). + + On receipt, the process is reversed to yield the plaintext String. + + Implementation Notes + It is possible that the length of the key returned may be larger + than needed for the encryption scheme in use. In this case, the + RADIUS client is responsible for performing any necessary + truncation. + + This attribute MAY be used to pass a key from an external (e.g., + EAP [15]) server to the RADIUS server. In this case, it may be + impossible for the external server to correctly encrypt the key, + since the RADIUS shared secret might be unavailable. The external + server SHOULD, however, return the attribute as defined above; the + Salt field SHOULD be zero-filled and padding of the String field + SHOULD be done. When the RADIUS server receives the attribute + from the external server, it MUST correctly set the Salt field and + encrypt the String field before transmitting it to the RADIUS + client. If the channel used to communicate the MS-MPPE-Recv-Key + attribute is not secure from eavesdropping, the attribute MUST be + cryptographically protected. + +2.4.4. MS-MPPE-Encryption-Policy + + Description + + The MS-MPPE-Encryption-Policy Attribute may be used to signify + whether the use of encryption is allowed or required. If the + Policy field is equal to 1 (Encryption-Allowed), any or none of + the encryption types specified in the MS-MPPE-Encryption-Types + Attribute MAY be used. If the Policy field is equal to 2 + (Encryption-Required), any of the encryption types specified in + the MS-MPPE-Encryption-Types Attribute MAY be used, but at least + one MUST be used. + + A summary of the MS-MPPE-Encryption-Policy Attribute format is given + below. The fields are transmitted left to right. + + + + + +Zorn Informational [Page 24] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Policy + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Policy (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 7 for MS-MPPE-Encryption-Policy. + + Vendor-Length + 6 + + Policy + The Policy field is 4 octets in length. Defined values are: + + 1 Encryption-Allowed 2 Encryption-Required + +2.4.5. MS-MPPE-Encryption-Types + + Description + + The MS-MPPE-Encryption-Types Attribute is used to signify the + types of encryption available for use with MPPE. It is a four + octet integer that is interpreted as a string of bits. + + A summary of the MS-MPPE-Encryption-Policy Attribute format is given + below. The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Types + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Types (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 8 for MS-MPPE-Encryption-Types. + + Vendor-Length + 6 + + Policy + The Types field is 4 octets in length. The following diagram + illustrates the Types field. + + + + +Zorn Informational [Page 25] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 3 2 1 + 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |S|L| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + If the L bit is set, RC4[5] encryption using a 40-bit key is + allowed. If the S bit is set, RC4 encryption using a 128-bit key + is allowed. If both the L and S bits are set, then either 40- or + 128-bit keys may be used with the RC4 algorithm. + +2.5. Attributes for BAP Support + + This section describes a set of vendor-specific RADIUS attributes + designed to support the dynamic control of bandwidth allocation in + multilink PPP [11]. Attributes are defined that specify whether use + of the PPP Bandwidth Allocation Protocol (BAP) [12] is allowed or + required on incoming calls, the level of line capacity (expressed as + a percentage) below which utilization must fall before a link is + eligible to be dropped, and the length of time (in seconds) that a + link must be under-utilized before it is dropped. + +2.5.1. MS-BAP-Usage + + Description + + This Attribute describes whether the use of BAP is allowed, + disallowed or required on new multilink calls. It MAY be used in + Access-Accept packets. + + A summary of the MS-BAP-Usage Attribute format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 13 for MS-BAP-Usage. + + Vendor-Length + 6 + + + + + +Zorn Informational [Page 26] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Value + The Value field is four octets. + + 0 BAP usage not allowed + 1 BAP usage allowed + 2 BAP usage required + +2.5.2. MS-Link-Utilization-Threshold + + Description + + This Attribute represents the percentage of available bandwidth + utilization below which the link must fall before the link is + eligible for termination. Permissible values for the MS-Link- + Utilization-Threshold Attribute are in the range 1-100, inclusive. + It is only used in Access-Accept packets. + + A summary of the MS-Link-Utilization-Threshold Attribute format is + shown below. The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 14 for MS-Link-Utilization-Threshold + + Vendor-Length 6 + + Value The Value field is four octets in length and represents the + percentage of available bandwidth utilization below which the link + must fall before the link is eligible for termination. + Permissible values are in the range 1-100, inclusive. + +2.5.3. MS-Link-Drop-Time-Limit + + Description + + The MS-Link-Drop-Time-Limit Attribute indicates the length of time + (in seconds) that a link must be underutilized before it is + dropped. It MAY only be included in Access-Accept packets. + + A summary of the MS-Link-Drop-Time-Limit Attribute format is given + below. The fields are transmitted left to right. + + + +Zorn Informational [Page 27] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 15 for MS-Link-Drop-Time-Limit + + Vendor-Length + 6 + + Value + The Value field represents the number of seconds that a link must + be underutilized (i.e., display bandwidth utilization below the + threshold specified in the MS-Link-Utilization-Threshold + Attribute) before the link is dropped. + +2.6. Attributes for ARAP Support + + This section describes a set of Attributes designed to support the + Apple Remote Access Protocol (ARAP). + +2.6.1. MS-Old-ARAP-Password + + Description + + The MS-Old-ARAP-Password Attribute is used to transmit the old + ARAP password during an ARAP password change operation. It MAY be + included in Access-Request packets. + + A summary of the MS-Old-ARAP-Password Attribute Attribute format is + given below. The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 19 for MS-Old-ARAP-Password Attribute + + Vendor-Length + > 3 + + + + +Zorn Informational [Page 28] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + String + The String field is one or more octets. It contains the old ARAP + password DES-encrypted using itself as the key. + +2.6.2. MS-New-ARAP-Password + + Description + + The MS-New-ARAP-Password Attribute is used to transmit the new + ARAP password during an ARAP password change operation. It MAY be + included in Access-Request packets. + + A summary of the MS-New-ARAP-Password Attribute Attribute format is + given below. The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 20 for MS-New-ARAP-Password Attribute + + Vendor-Length + > 3 + + String + The String field is one or more octets. It contains the new ARAP + password DES-encrypted using the old ARAP password as the key. + +2.6.3. MS-ARAP-Password-Change-Reason + + Description + + The MS-ARAP-Password-Change-Reason Attribute is used to indicate + reason for a server-initiated password change. It MAY be included + in Access-Challenge packets. + + A summary of the MS-ARAP-Password-Change-Reason Attribute format is + given below. The fields are transmitted left to right. + + + + + + + + + + +Zorn Informational [Page 29] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Why + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Why (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 21 for MS-ARAP-Password-Change-Reason + + Vendor-Length + 6 + + Why + The Why field is 4 octets in length. The following values are + defined: + Just-Change-Password 1 + Expired-Password 2 + Admin-Requires-Password-Change 3 + Password-Too-Short 4 + +2.6.4. MS-ARAP-Challenge + + Description + + This attribute is only present in an Access-Request packet + containing a Framed-Protocol Attribute with the value 3 (ARAP). + + A summary of the MS-ARAP-Challenge Attribute format is given below. + The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Challenge + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Challenge (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Challenge (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 33 for MS-ARAP-Challenge + + Vendor-Length + 10 + + + + +Zorn Informational [Page 30] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Value + The Challenge Field is 8 octets in length. It contains the + challenge (as two 4-octet quantities) sent by the NAS to the peer. + +2.7. Miscellaneous Attributes + + This section describes attributes which do not fall into any + particular category, but are used in the identification and operation + of Microsoft remote access products. + +2.7.1. MS-RAS-Vendor + + Description + + The MS-RAS-Vendor Attribute is used to indicate the manufacturer + of the RADIUS client machine. It MAY be included in both Access- + Request and Accounting-Request packets. + + A summary of the MS-RAS-Vendor Attribute format is given below. The + fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Vendor-ID + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Vendor-ID (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 9 for MS-RAS-Vendor + + Vendor-Length + 6 + + Vendor-ID + The Vendor-ID field is 4 octets in length. The high-order octet + is 0 and the low-order 3 octets are the SMI Network Management + Private Enterprise Code of the Vendor in network byte order, as + defined in the Assigned Numbers RFC [13]. + +2.7.2. MS-RAS-Version + + Description + + The MS-RAS-Version Attribute is used to indicate the version of + the RADIUS client software. This attribute SHOULD be included in + packets containing an MS-RAS-Vendor Attribute; it SHOULD NOT be + + + +Zorn Informational [Page 31] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + sent in packets which do not contain an MS-RAS-Vendor Attribute. + It MAY be included in both Access-Request and Accounting-Request + packets. + + A summary of the MS-RAS-Version Attribute format is given below. The + fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 18 for MS-RAS-Version + + Vendor-Length + > 3 + + String + The String field is one or more octets. The actual format of the + information is vendor specific, and a robust implementation SHOULD + support the field as undistinguished octets. + +2.7.3. MS-Filter + + Description + + The MS-Filter Attribute is used to transmit traffic filters. It + MAY be included in both Access-Accept and Accounting-Request + packets. + + If multiple MS-Filter Attributes are contained within a packet, + they MUST be in order and they MUST be consecutive attributes in + the packet. + + A summary of the MS-Filter Attribute format is given below. The + fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Filter... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 22 for MS-Filter Attribute + + + + +Zorn Informational [Page 32] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + Vendor-Length + > 3 + + Filter + The Filter field is one or more octets. It contains a sequence of + undifferentiated octets. + + If multiple MS-Filter Attributes occur in a single Access-Accept + packet, the Filter field from each MUST be concatenated in the + order received to form the actual filter. + +2.7.4. MS-Acct-Auth-Type + + Description + + The MS-Acct-Auth-Type Attribute is used to represent the method + used to authenticate the dial-up user. It MAY be included in + Accounting-Request packets. + + A summary of the MS-Acct-Auth-Type Attribute format is given below. + The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | Auth-Type + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Auth-Type (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 23 for MS-Acct-Auth-Type + + Vendor-Length + 6 + + Auth-Type + The Auth-Type field is 4 octets in length. The following values + are defined for this field: + + PAP 1 + CHAP 2 + MS-CHAP-1 3 + MS-CHAP-2 4 + EAP 5 + + + + + + +Zorn Informational [Page 33] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.7.5. MS-Acct-EAP-Type + + Description + + The MS-Acct-EAP-Type Attribute is used to represent the Extensible + Authentication Protocol (EAP) [15] type used to authenticate the + dial-up user. It MAY be included in Accounting-Request packets. + + A summary of the MS-Acct-EAP-Type Attribute format is given below. + The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | EAP-Type + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + EAP-Type (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 24 for MS-Acct-EAP-Type + + Vendor-Length + 6 + + Auth-Type + The EAP-Type field is 4 octets in length. The following values + are currently defined for this field: + + MD5 4 + OTP 5 + Generic Token Card 6 + TLS 13 + +2.7.6. MS-Primary-DNS-Server + + Description + + The MS-Primary-DNS-Server Attribute is used to indicate the + address of the primary Domain Name Server (DNS) [16, 17] server to + be used by the PPP peer. It MAY be included in both Access-Accept + and Accounting-Request packets. + + A summary of the MS-Primary-DNS-Server Attribute format is given + below. The fields are transmitted left to right. + + + + + + +Zorn Informational [Page 34] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | IP-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + IP-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 28 for MS-Primary-DNS-Server + + Vendor-Length + 6 + + IP-Address + The IP-Address field is 4 octets in length. It contains the IP + address of the primary DNS server. + +2.7.7. MS-Secondary-DNS-Server + + Description + + The MS-Secondary-DNS-Server Attribute is used to indicate the + address of the secondary DNS server to be used by the PPP peer. + It MAY be included in both Access-Accept and Accounting-Request + packets. + + A summary of the MS-Secondary-DNS-Server Attribute format is given + below. The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | IP-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + IP-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 29 for MS-Secondary-DNS-Server + + Vendor-Length + 6 + + IP-Address + The IP-Address field is 4 octets in length. It contains the IP + address of the secondary DNS server. + + + + +Zorn Informational [Page 35] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +2.7.8. MS-Primary-NBNS-Server + + Description + + The MS-Primary-NBNS-Server Attribute is used to indicate the + address of the primary NetBIOS Name Server (NBNS) [18] server to + be used by the PPP peer. It MAY be included in both Access-Accept + and Accounting-Request packets. + + A summary of the MS-Primary-MBNS-Server Attribute format is given + below. The fields are transmitted 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | IP-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + IP-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 30 for MS-Primary-NBNS-Server + + Vendor-Length + 6 + + IP-Address + The IP-Address field is 4 octets in length. It contains the IP + address of the primary NBNS server. + +2.7.9. MS-Secondary-NBNS-Server + + Description + + The MS-Secondary-NBNS-Server Attribute is used to indicate the + address of the secondary DNS server to be used by the PPP peer. + It MAY be included in both Access-Accept and Accounting-Request + packets. + + A summary of the MS-Secondary-NBNS-Server Attribute format is given + below. The fields are transmitted left to right. + + + + + + + + + + +Zorn Informational [Page 36] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Vendor-Type | Vendor-Length | IP-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + IP-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vendor-Type + 31 for MS-Secondary-NBNS-Server + + Vendor-Length + 6 + + IP-Address + The IP-Address field is 4 octets in length. It contains the IP + address of the secondary NBNS server. + +3. Table of Attributes + + The following table provides a guide to which of the above attributes + may be found in which kinds of packets, and in what quantity. + + Request Accept Reject Challenge Acct-Request # Attribute + 0-1 0 0 0 0 1 MS-CHAP-Response + 0 0 0-1 0 0 2 MS-CHAP-Error + 0-1 0 0 0 0 3 MS-CHAP-CPW-1 + 0-1 0 0 0 0 4 MS-CHAP-CPW-2 + 0+ 0 0 0 0 5 MS-CHAP-LM-Enc-PW + 0+ 0 0 0 0 6 MS-CHAP-NT-Enc-PW + 0 0-1 0 0 0 7 MS-MPPE-Encryption- + Policy + 0 0-1 0 0 0 8 MS-MPPE-Encryption-Type + 0-1 0 0 0 0-1 9 MS-RAS-Vendor + 0 0-1 0 0 0-1 10 MS-CHAP-Domain + 0-1 0 0 0-1 0 11 MS-CHAP-Challenge + 0 0-1 0 0 0 12 MS-CHAP-MPPE-Keys + 0 0-1 0 0 0 13 MS-BAP-Usage + 0 0-1 0 0 0 14 MS-Link-Utilization- + Threshold + 0 0-1 0 0 0 15 MS-Link-Drop-Time-Limit + 0 0-1 0 0 0 16 MS-MPPE-Send-Key + 0 0-1 0 0 0 17 MS-MPPE-Recv-Key + 0-1 0 0 0 0-1 18 MS-RAS-Version + 0-1 0 0 0 0 19 MS-Old-ARAP-Password + 0-1 0 0 0 0 20 MS-New-ARAP-Password + 0 0 0 0-1 0 21 MS-ARAP-PW-Change- + Reason + + + +Zorn Informational [Page 37] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + 0 0+ 0 0 0+ 22 MS-Filter + 0 0 0 0 0-1 23 MS-Acct-Auth-Type + 0 0 0 0 0-1 24 MS-Acct-EAP-Type + 0-1 0 0 0 0 25 MS-CHAP2-Response + 0 0-1 0 0 0 26 MS-CHAP2-Success + 0-1 0 0 0 0 27 MS-CHAP2-CPW + 0 0-1 0 0 0-1 28 MS-Primary-DNS-Server + 0 0-1 0 0 0-1 29 MS-Secondary-DNS-Server + 0 0-1 0 0 0-1 30 MS-Primary-NBNS-Server + 0 0-1 0 0 0-1 31 MS-Secondary-NBNS- + Server + 0-1 0 0 0 0 33 MS-ARAP-Challenge + +The following table defines the meaning of the above table entries. + +0 This attribute MUST NOT be present in packet. +0+ Zero or more instances of this attribute MAY be present in packet. +0-1 Zero or one instance of this attribute MAY be present in packet. + +4. Security Considerations + + MS-CHAP, like PPP CHAP, is susceptible to dictionary attacks. User + passwords should be chosen with care, and be of sufficient length to + deter easy guessing. + + Although the scheme used to protect the Keys field of the MS-CHAP- + MPPE-Keys, MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes is + believed to be relatively secure on the wire, RADIUS proxies will + decrypt and re-encrypt the field for forwarding. Therefore, these + attributes SHOULD NOT be used on networks where untrusted RADIUS + proxies reside. + +5. Acknowledgements + + Thanks to Carl Rigney (cdr@livingston.com), Ashwin Palekar (ash- + winp@microsoft.com), Aydin Edguer (edguer@MorningStar.com), Narendra + Gidwani (nareng@microsoft.com), Steve Cobb (stevec@microsoft.com), + Pat Calhoun (pcalhoun@eng.sun.com), Dave Mitton + (dmitton@baynetworks.com), Paul Funk (paul@funk.com), Gurdeep Singh + Pall (gurdeep@microsoft.com), Stephen Bensley (sbens@microsoft.com), + and Don Rule (don-aldr@microsoft.com) for useful suggestions and + editorial feedback. + + + + + + + + + +Zorn Informational [Page 38] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +6. Editor's Address + + Questions about this memo can be directed to: + + Glen Zorn + Microsoft Corporation + One Microsoft Way + Redmond, Washington 98052 + + Phone: +1 425 703 1559 + Fax: +1 425 936 7329 + EMail: glennz@microsoft.com + +7. References + + [1] Simpson, W., "PPP Challenge Handshake Authentication + Protocol (CHAP)", RFC 1994, August 1996. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote + Access Dial In User Service", RFC 2138, April 1997. + + [4] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, + October 1998. + + [5] Simpson, W., "PPP Challenge Handshake Authentication Protocol + (CHAP)", RFC 1994, August 1996. + + [6] Zorn, G. and G. Pall, "Microsoft Point-to-Point Encryption + (MPPE) Protocol", Work in Progress. + + [7] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC + 1661, July 1994. + + [8] RC4 is a proprietary encryption algorithm available under + license from RSA Data Security Inc. For licensing information, + contact: + RSA Data Security, Inc. + 100 Marine Parkway + Redwood City, CA 94065-1031 + + [9] Pall, G., "Microsoft Point-to-Point Compression (MPPC) + Protocol", RFC 2118, March 1997. + + [10] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC + 1962, June 1996. + + + +Zorn Informational [Page 39] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + + [11] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, + "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. + + [12] Richards, C. and K. Smith, "The PPP Bandwidth Allocation + Protocol (BAP) The PPP Bandwidth Allocation Control Protocol + (BACP)", RFC 2125, March 1997. + + [13] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, + October 1994. + + [14] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", Work in + Progress. + + [15] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication + Protocol (EAP)", RFC 2284, March 1998. + + [16] Mockapetris, P., "Domain Names - Concepts and Facilities", STD + 13, RFC 1034, USC/ISI, November 1987. + + [17] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [18] Auerbach, K., and A. Aggarwal, "Protocol Standard for a NetBIOS + Service on a TCP/UDP Transport", STD 19, RFCs 1001 and 1002, + March 1987. + + + + + + + + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 40] + +RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999 + + +10. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 41] + diff --git a/rfc/rfc2637.txt b/rfc/rfc2637.txt new file mode 100644 index 00000000..56e9e0f5 --- /dev/null +++ b/rfc/rfc2637.txt @@ -0,0 +1,3195 @@ + + + + + + +Network Working Group K. Hamzeh +Request for Comments: 2637 Ascend Communications +Category: Informational G. Pall + Microsoft Corporation + W. Verthein + 3Com + J. Taarud + Copper Mountain Networks + W. Little + ECI Telematics + G. Zorn + Microsoft Corporation + July 1999 + + + Point-to-Point Tunneling Protocol (PPTP) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +IESG Note + + The PPTP protocol was developed by a vendor consortium. The + documentation of PPTP is provided as information to the Internet + community. The PPP WG is currently defining a Standards Track + protocol (L2TP) for tunneling PPP across packet-switched networks. + +Abstract + + This document specifies a protocol which allows the Point to Point + Protocol (PPP) to be tunneled through an IP network. PPTP does not + specify any changes to the PPP protocol but rather describes a new + vehicle for carrying PPP. A client-server architecture is defined in + order to decouple functions which exist in current Network Access + Servers (NAS) and support Virtual Private Networks (VPNs). The PPTP + Network Server (PNS) is envisioned to run on a general purpose + operating system while the client, referred to as a PPTP Access + Concentrator (PAC) operates on a dial access platform. PPTP + specifies a call-control and management protocol which allows the + server to control access for dial-in circuit switched calls + originating from a PSTN or ISDN or to initiate outbound circuit- + + + +Hamzeh, et al. Informational [Page 1] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + switched connections. PPTP uses an enhanced GRE (Generic Routing + Encapsulation) mechanism to provide a flow- and congestion-controlled + encapsulated datagram service for carrying PPP packets. + +Specification of Requirements + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as + described in [12]. + + The words "silently discard", when used in reference to the behavior + of an implementation upon receipt of an incoming packet, are to be + interpreted as follows: the implementation discards the datagram + without further processing, and without indicating an error to the + sender. The implementation SHOULD provide the capability of logging + the error, including the contents of the discarded datagram, and + SHOULD record the event in a statistics counter. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Protocol Goals and Assumptions . . . . . . . . . . . . . . 4 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 + 1.3.1. Control Connection Overview . . . . . . . . . . . . . . 7 + 1.3.2. Tunnel Protocol Overview . . . . . . . . . . . . . . . . 7 + 1.4. Message Format and Protocol Extensibility . . . . . . . . 8 + 2. Control Connection Protocol Specification . . . . . . . . . 10 + 2.1. Start-Control-Connection-Request . . . . . . . . . . . . . 10 + 2.2. Start-Control-Connection-Reply . . . . . . . . . . . . . . 12 + 2.3. Stop-Control-Connection-Request . . . . . . . . . . . . . 15 + 2.4. Stop-Control-Connection-Reply . . . . . . . . . . . . . . 16 + 2.5. Echo-Request . . . . . . . . . . . . . . . . . . . . . . . 17 + 2.6. Echo-Reply . . . . . . . . . . . . . . . . . . . . . . . . 18 + 2.7. Outgoing-Call-Request . . . . . . . . . . . . . . . . . . 19 + 2.8. Outgoing-Call-Reply . . . . . . . . . . . . . . . . . . . 22 + 2.9. Incoming-Call-Request . . . . . . . . . . . . . . . . . . 25 + 2.10. Incoming-Call-Reply . . . . . . . . . . . . . . . . . . . 28 + 2.11. Incoming-Call-Connected . . . . . . . . . . . . . . . . . 29 + 2.12. Call-Clear-Request . . . . . . . . . . . . . . . . . . . 31 + 2.13. Call-Disconnect-Notify . . . . . . . . . . . . . . . . . 32 + 2.14. WAN-Error-Notify . . . . . . . . . . . . . . . . . . . . 33 + 2.15. Set-Link-Info . . . . . . . . . . . . . . . . . . . . . . 35 + 2.16. General Error Codes . . . . . . . . . . . . . . . . . . . 36 + 3. Control Connection Protocol Operation . . . . . . . . . . . 36 + 3.1. Control Connection States . . . . . . . . . . . . . . . . 37 + 3.1.1. Control Connection Originator (may be PAC or PNS) . . . 37 + 3.1.2. Control connection Receiver (may be PAC or PNS) . . . . 39 + + + +Hamzeh, et al. Informational [Page 2] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 3.1.3. Start Control Connection Initiation Request Collision . 40 + 3.1.4. Keep Alives and Timers . . . . . . . . . . . . . . . . . 40 + 3.2. Call States . . . . . . . . . . . . . . . . . . . . . . . 41 + 3.2.1. Timing considerations . . . . . . . . . . . . . . . . . 41 + 3.2.2. Call ID Values . . . . . . . . . . . . . . . . . . . . . 41 + 3.2.3. Incoming Calls . . . . . . . . . . . . . . . . . . . . . 41 + 3.2.3.1. PAC Incoming Call States . . . . . . . . . . . . . . . 42 + 3.2.3.2. PNS Incoming Call States . . . . . . . . . . . . . . . 43 + 3.2.4. Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 44 + 3.2.4.1. PAC Outgoing Call States . . . . . . . . . . . . . . . 45 + 3.2.4.2. PNS Outgoing Call States . . . . . . . . . . . . . . . 46 + 4. Tunnel Protocol Operation . . . . . . . . . . . . . . . . . 47 + 4.1. Enhanced GRE header . . . . . . . . . . . . . . . . . . . 47 + 4.2. Sliding Window Protocol . . . . . . . . . . . . . . . . . 49 + 4.2.1. Initial Window Size . . . . . . . . . . . . . . . . . . 49 + 4.2.2. Closing the Window . . . . . . . . . . . . . . . . . . . 49 + 4.2.3. Opening the Window . . . . . . . . . . . . . . . . . . . 50 + 4.2.4. Window Overflow . . . . . . . . . . . . . . . . . . . . 50 + 4.2.5. Multi-packet Acknowledgment . . . . . . . . . . . . . . 50 + 4.3. Out-of-sequence Packets . . . . . . . . . . . . . . . . . 50 + 4.4. Acknowledgment Time-Outs . . . . . . . . . . . . . . . . . 51 + 4.4.1. Calculating Adaptive Acknowledgment Time-Out . . . . . . 53 + 4.4.2. Congestion Control: Adjusting for Time-Out . . . . . . . 54 + 5. Security Considerations . . . . . . . . . . . . . . . . . . 54 + 6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 + 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . 57 + +1. Introduction + + PPTP allows existing Network Access Server (NAS) functions to be + separated using a client-server architecture. Traditionally, the + following functions are implemented by a NAS: + + 1) Physical native interfacing to PSTN or ISDN and control of + external modems or terminal adapters. + + A NAS may interface directly to a telco analog or digital + circuit or attach via an external modem or terminal adapter. + Control of a circuit-switched connection is accomplished with + either modem control or DSS1 ISDN call control protocols. + + The NAS, in conjunction with the modem or terminal adapters, + may perform rate adaption, analog to digital conversion, sync + to async conversion or a number of other alterations of data + streams. + + + + + +Hamzeh, et al. Informational [Page 3] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 2) Logical termination of a Point-to-Point-Protocol (PPP) Link + Control Protocol (LCP) session. + + 3) Participation in PPP authentication protocols [3,9,10]. + + 4) Channel aggregation and bundle management for PPP Multilink + Protocol. + + 5) Logical termination of various PPP network control protocols + (NCP). + + 6) Multiprotocol routing and bridging between NAS interfaces. + + PPTP divides these functions between the PAC and PNS. The PAC is + responsible for functions 1, 2, and possibly 3. The PNS may be + responsible for function 3 and is responsible for functions 4, 5, and + 6. The protocol used to carry PPP protocol data units (PDUs) between + the PAC and PNS, as well as call control and management is addressed + by PPTP. + + The decoupling of NAS functions offers these benefits: + + Flexible IP address management. Dial-in users may maintain a + single IP address as they dial into different PACs as long as they + are served from a common PNS. If an enterprise network uses + unregistered addresses, a PNS associated with the enterprise + assigns addresses meaningful to the private network. + + Support of non-IP protocols for dial networks behind IP networks. + This allows Appletalk and IPX, for example to be tunneled through + an IP-only provider. The PAC need not be capable of processing + these protocols. + + A solution to the "multilink hunt-group splitting" problem. + Multilink PPP, typically used to aggregate ISDN B channels, + requires that all of the channels composing a multilink bundle be + grouped at a single NAS. Since a multilink PPP bundle can be + handled by a single PNS, the channels comprising the bundle may be + spread across multiple PACs. + +1.1. Protocol Goals and Assumptions + + The PPTP protocol is implemented only by the PAC and PNS. No other + systems need to be aware of PPTP. Dial networks may be connected to a + PAC without being aware of PPTP. Standard PPP client software should + continue to operate on tunneled PPP links. + + + + + +Hamzeh, et al. Informational [Page 4] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + PPTP can also be used to tunnel a PPP session over an IP network. In + this configuration the PPTP tunnel and the PPP session runs between + the same two machines with the caller acting as a PNS. + + It is envisioned that there will be a many-to-many relationship + between PACs and PNSs. A PAC may provide service to many PNSs. For + example, an Internet service provider may choose to support PPTP for + a number of private network clients and create VPNs for them. Each + private network may operate one or more PNSs. A single PNS may + associate with many PACs to concentrate traffic from a large number + of geographically diverse sites. + + PPTP uses an extended version of GRE to carry user PPP packets. These + enhancements allow for low-level congestion and flow control to be + provided on the tunnels used to carry user data between PAC and PNS. + This mechanism allows for efficient use of the bandwidth available + for the tunnels and avoids unnecessary retransmisions and buffer + overruns. PPTP does not dictate the particular algorithms to be used + for this low level control but it does define the parameters that + must be communicated in order to allow such algorithms to work. + Suggested algorithms are included in section 4. + +1.2. Terminology + + Analog Channel + + A circuit-switched communication path which is intended to carry + 3.1 Khz audio in each direction. + + Digital Channel + + A circuit-switched communication path which is intended to carry + digital information in each direction. + + Call + + A connection or attempted connection between two terminal + endpoints on a PSTN or ISDN -- for example, a telephone call + between two modems. + + Control Connection + + A control connection is created for each PAC, PNS pair and + operates over TCP [4]. The control connection governs aspects of + the tunnel and of sessions assigned to the tunnel. + + + + + + +Hamzeh, et al. Informational [Page 5] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Dial User + + An end-system or router attached to an on-demand PSTN or ISDN + which is either the initiator or recipient of a call. + + Network Access Server (NAS) + + A device providing temporary, on-demand network access to users. + This access is point-to-point using PSTN or ISDN lines. + + PPTP Access Concentrator (PAC) + + A device attached to one or more PSTN or ISDN lines capable of PPP + operation and of handling the PPTP protocol. The PAC need only + implement TCP/IP to pass traffic to one or more PNSs. It may also + tunnel non-IP protocols. + + PPTP Network Server (PNS) + + A PNS is envisioned to operate on general-purpose computing/server + platforms. The PNS handles the server side of the PPTP protocol. + Since PPTP relies completely on TCP/IP and is independent of the + interface hardware, the PNS may use any combination of IP + interface hardware including LAN and WAN devices. + + Session + + PPTP is connection-oriented. The PNS and PAC maintain state for + each user that is attached to a PAC. A session is created when + end-to-end PPP connection is attempted between a dial user and the + PNS. The datagrams related to a session are sent over the tunnel + between the PAC and PNS. + + Tunnel + + A tunnel is defined by a PNS-PAC pair. The tunnel protocol is + defined by a modified version of GRE [1,2]. The tunnel carries + PPP datagrams between the PAC and the PNS. Many sessions are + multiplexed on a single tunnel. A control connection operating + over TCP controls the establishment, release, and maintenance of + sessions and of the tunnel itself. + +1.3. Protocol Overview + + There are two parallel components of PPTP: 1) a Control Connection + between each PAC-PNS pair operating over TCP and 2) an IP tunnel + operating between the same PAC-PNS pair which is used to transport + GRE encapsulated PPP packets for user sessions between the pair. + + + +Hamzeh, et al. Informational [Page 6] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +1.3.1. Control Connection Overview + + Before PPP tunneling can occur between a PAC and PNS, a control + connection must be established between them. The control connection + is a standard TCP session over which PPTP call control and management + information is passed. The control session is logically associated + with, but separate from, the sessions being tunneled through a PPTP + tunnel. For each PAC-PNS pair both a tunnel and a control connection + exist. The control connection is responsible for establishment, + management, and release of sessions carried through the tunnel. It is + the means by which a PNS is notified of an incoming call at an + associated PAC, as well as the means by which a PAC is instructed to + place an outgoing dial call. + + A control connection can be established by either the PNS or the PAC. + Following the establishment of the required TCP connection, the PNS + and PAC establish the control connection using the Start-Control- + Connection-Request and -Reply messages. These messages are also used + to exchange information about basic operating capabilities of the PAC + and PNS. Once the control connection is established, the PAC or PNS + may initiate sessions by requesting outbound calls or responding to + inbound requests. The control connection may communicate changes in + operating characteristics of an individual user session with a Set- + Link-Info message. Individual sessions may be released by either the + PAC or PNS, also through Control Connection messages. + + The control connection itself is maintained by keep-alive echo + messages. This ensures that a connectivity failure between the PNS + and the PAC can be detected in a timely manner. Other failures can be + reported via the + + Wan-Error-Notify message, also on the control connection. + + It is intended that the control connection will also carry management + related messages in the future, such as a message allowing the PNS to + request the status of a given PAC; these message types have not yet + been defined. + +1.3.2. Tunnel Protocol Overview + + PPTP requires the establishment of a tunnel for each communicating + PNS-PAC pair. This tunnel is used to carry all user session PPP + packets for sessions involving a given PNS-PAC pair. A key which is + present in the GRE header indicates which session a particular PPP + packet belongs to. + + + + + + +Hamzeh, et al. Informational [Page 7] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + In this manner, PPP packets are multiplexed and demultiplexed over a + single tunnel between a given PNS-PAC pair. The value to use in the + key field is established by the call establishment procedure which + takes place on the control connection. + + The GRE header also contains acknowledgment and sequencing + information that is used to perform some level of congestion-control + and error detection over the tunnel. Again the control connection is + used to determine rate and buffering parameters that are used to + regulate the flow of PPP packets for a particular session over the + tunnel. PPTP does not specify the particular algorithms to use for + congestion-control and flow-control. Suggested algorithms for the + determination of adaptive time-outs to recover from dropped data or + acknowledgments on the tunnel are included in section 4.4 of this + document. + +1.4. Message Format and Protocol Extensibility + + PPTP defines a set of messages sent as TCP data on the control + connection between a PNS and a given PAC. The TCP session for the + control connection is established by initiating a TCP connection to + port 1723 [6]. The source port is assigned to any unused port number. + + Each PPTP Control Connection message begins with an 8 octet fixed + header portion. This fixed header contains the following: the total + length of the message, the PPTP Message Type indicator, and a "Magic + Cookie". + + Two Control Connection message types are indicated by the PPTP + Message Type field: + + 1 - Control Message + 2 - Management Message + + Management messages are currently not defined. + + The Magic Cookie is always sent as the constant 0x1A2B3C4D. Its + basic purpose is to allow the receiver to ensure that it is properly + synchronized with the TCP data stream. It should not be used as a + means for resynchronizing the TCP data stream in the event that a + transmitter issues an improperly formatted message. Loss of + synchronization must result in immediate closing of the control + connection's TCP session. + + For clarity, all Control Connection message templates in the next + section include the entire PPTP Control Connection message header. + Numbers preceded by 0x are hexadecimal values. + + + + +Hamzeh, et al. Informational [Page 8] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +The currently defined Control Messages, grouped by function, are: + + Control Message Message Code + + (Control Connection Management) + + Start-Control-Connection-Request 1 + Start-Control-Connection-Reply 2 + Stop-Control-Connection-Request 3 + Stop-Control-Connection-Reply 4 + Echo-Request 5 + Echo-Reply 6 + + (Call Management) + + Outgoing-Call-Request 7 + Outgoing-Call-Reply 8 + Incoming-Call-Request 9 + Incoming-Call-Reply 10 + Incoming-Call-Connected 11 + Call-Clear-Request 12 + Call-Disconnect-Notify 13 + + (Error Reporting) + + WAN-Error-Notify 14 + + (PPP Session Control) + + Set-Link-Info 15 + + The Start-Control-Connection-Request and -Reply messages determine + which version of the Control Connection protocol will be used. The + version number field carried in these messages consists of a version + number in the high octet and a revision number in the low octet. + Version handling is described in section 2. The current value of the + version number field is 0x0100 for version 1, revision 0. + + The use of the GRE-like header for the encapsulation of PPP user + packets is specified in section 4.1. + + The MTU for the user data packets encapsulated in GRE is 1532 octets, + not including the IP and GRE headers. + + + + + + + + +Hamzeh, et al. Informational [Page 9] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +2. Control Connection Protocol Specification + + Control Connection messages are used to establish and clear user + sessions. The first set of Control Connection messages are used to + maintain the control connection itself. The control connection is + initiated by either the PNS or PAC after they establish the + underlying TCP connection. The procedure and configuration + information required to determine which TCP connections are + established is not covered by this protocol. + + The following Control Connection messages are all sent as user data + on the established TCP connection between a given PNS-PAC pair. Note + that care has been taken to ensure that all word (2 octet) and + longword (4 octet) values begin on appropriate boundaries. All data + is sent in network order (high order octets first). Any "reserved" + fields MUST be sent as 0 values to allow for protocol extensibility. + +2.1. Start-Control-Connection-Request + + The Start-Control-Connection-Request is a PPTP control message used + to establish the control connection between a PNS and a PAC. Each + PNS-PAC pair requires a dedicated control connection to be + established. A control connection must be established before any + other PPTP messages can be issued. The establishment of the control + connection can be initiated by either the PNS or PAC. A procedure + which handles the occurrence of a collision between PNS and PAC + Start-Control-Connection-Requests is described in section 3.1.3. + + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 10] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Protocol Version | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Capabilities | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Bearer Capabilities | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum Channels | Firmware Revision | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Host Name (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Vendor String (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. This constant value is used + as a sanity check on received messages + (see section 1.4). + + Control Message Type 1 for Start-Control-Connection-Request. + + Reserved0 This field MUST be 0. + + Protocol Version The version of the PPTP protocol that the + sender wishes to use. + + Reserved1 This field MUST be 0. + + + + + + + +Hamzeh, et al. Informational [Page 11] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Framing Capabilities A set of bits indicating the type of framing + that the sender of this message can provide. + The currently defined bit settings are: + + 1 - Asynchronous Framing supported + + 2 - Synchronous Framing supported + + Bearer Capabilities A set of bits indicating the bearer + capabilities that the sender of this message + can provide. The currently defined bit + settings are: + + 1 - Analog access supported + + 2 - Digital access supported + + Maximum Channels The total number of individual PPP sessions + this PAC can support. In Start-Control- + Connection-Requests issued by the PNS, this + value SHOULD be set to 0. It MUST be + ignored by the PAC. + + Firmware Revision This field contains the firmware revision + number of the issuing PAC, when issued by + the PAC, or the version of the PNS PPTP + driver if issued by the PNS. + + Host Name A 64 octet field containing the DNS name of + the issuing PAC or PNS. If less than 64 + octets in length, the remainder of this + field SHOULD be filled with octets of value + 0. + + Vendor Name A 64 octet field containing a vendor + specific string describing the type of PAC + being used, or the type of PNS software + being used if this request is issued by the + PNS. If less than 64 octets in length, the + remainder of this field SHOULD be filled + with octets of value 0. + +2.2. Start-Control-Connection-Reply + + The Start-Control-Connection-Reply is a PPTP control message sent in + reply to a received Start-Control-Connection-Request message. This + message contains a result code indicating the result of the control + connection establishment attempt. + + + +Hamzeh, et al. Informational [Page 12] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Protocol Version | Result Code | Error Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Capability | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Bearer Capability | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum Channels | Firmware Revision | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Host Name (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Vendor String (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 2 for Start-Control-Connection-Reply. + + Reserved0 This field MUST be 0. + + Protocol Version The version of the PPTP protocol that the + sender wishes to use. + + Result Code Indicates the result of the command channel + establishment attempt. Current valid Result + Code values are: + + 1 - Successful channel establishment + + 2 - General error -- Error Code + indicates the problem + + + +Hamzeh, et al. Informational [Page 13] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 3 - Command channel already exists; + + 4 - Requester is not authorized to + establish a command channel + + 5 - The protocol version of the + requester is not supported + + Error Code This field is set to 0 unless a "General + Error" exists, in which case Result Code is + set to 2 and this field is set to the value + corresponding to the general error condition + as specified in section 2.2. + + Framing Capabilities A set of bits indicating the type of framing + that the sender of this message can provide. + The currently defined bit settings are: + + 1 - Asynchronous Framing supported + + 2 - Synchronous Framing supported. + + Bearer Capabilities A set of bits indicating the bearer + capabilities that the sender of this message + can provide. The currently defined bit + settings are: + + 1 - Analog access supported + + 2 - Digital access supported + + Maximum Channels The total number of individual PPP sessions + this PAC can support. In a Start-Control- + Connection-Reply issued by the PNS, this + value SHOULD be set to 0 and it must be + ignored by the PAC. The PNS MUST NOT use + this value to try to track the remaining + number of PPP sessions that the PAC will + allow. + + Firmware Revision This field contains the firmware revision + number of the issuing PAC, or the version of + the PNS PPTP driver if issued by the PNS. + + + + + + + + +Hamzeh, et al. Informational [Page 14] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Host Name A 64 octet field containing the DNS name of + the issuing PAC or PNS. If less than 64 + octets in length, the remainder of this + field SHOULD be filled with octets of value + 0. + + Vendor Name A 64 octet field containing a vendor + specific string describing the type of PAC + being used, or the type of PNS software + being used if this request is issued by the + PNS. If less than 64 octets in length, the + remainder of this field SHOULD be filled + with octets of value 0. + +2.3. Stop-Control-Connection-Request + + The Stop-Control-Connection-Request is a PPTP control message sent by + one peer of a PAC-PNS control connection to inform the other peer + that the control connection should be closed. In addition to closing + the control connection, all active user calls are implicitly cleared. + The reason for issuing this request is indicated in the Reason field. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reason | Reserved1 | Reserved2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 3 for Stop-Control-Connection-Request. + + Reserved0 This field MUST be 0. + + Reason Indicates the reason for the control + connection being closed. Current valid + Reason values are: + + + +Hamzeh, et al. Informational [Page 15] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 1 (None) - General request to clear + control connection + + 2 (Stop-Protocol) - Can't support + peer's version of the protocol + + 3 (Stop-Local-Shutdown) - Requester is + being shut down + + Reserved1, Reserved2 These fields MUST be 0. + +2.4. Stop-Control-Connection-Reply + + The Stop-Control-Connection-Reply is a PPTP control message sent by + one peer of a PAC-PNS control connection upon receipt of a Stop- + Control-Connection-Request from the other peer. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | Error Code | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 4 for Stop-Control-Connection-Reply. + + Reserved0 This field MUST be 0. + + Result Code Indicates the result of the attempt to close + the control connection. Current valid Result + Code values are: + + + + + + + + +Hamzeh, et al. Informational [Page 16] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 1 (OK) - Control connection closed + + 2 (General Error) - Control connection + not closed for reason indicated in + Error Code + + Error Code This field is set to 0 unless a "General + Error" exists, in which case Result Code is + set to 2 and this field is set to the value + corresponding to the general error condition + as specified in section 2.2. + + Reserved1 This field MUST be 0. + +2.5. Echo-Request + + The Echo-Request is a PPTP control message sent by either peer of a + PAC-PNS control connection. This control message is used as a "keep- + alive" for the control connection. The receiving peer issues an + Echo-Reply to each Echo-Request received. As specified in section + 3.1.4, if the sender does not receive an Echo-Reply in response to an + Echo-Request, it will eventually clear the control connection. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 5 for Echo-Request. + + Reserved0 This field MUST be 0. + + + + + + +Hamzeh, et al. Informational [Page 17] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Identifier A value set by the sender of the Echo- + Request that is used to match the reply with + the corresponding request. + +2.6. Echo-Reply + + The Echo-Reply is a PPTP control message sent by either peer of a + PAC-PNS control connection in response to the receipt of an Echo- + Request. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | Error Code | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 6 for Echo-Reply. + + Reserved0 This field MUST be 0. + + Identifier The contents of the identify field from the + received Echo-Request is copied to this + field. + + Result Code Indicates the result of the receipt of the + Echo-Request. Current valid Result Code + values are: + + 1 (OK) - The Echo-Reply is valid + + 2 (General Error) - Echo-Request not + accepted for the reason indicated in + Error Code + + + +Hamzeh, et al. Informational [Page 18] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Error Code This field is set to 0 unless a "General + Error" condition exists, in which case + Result Code is set to 2 and this field is + set to the value corresponding to the + general error condition as specified in + section 2.2. + + Reserved1 This field MUST be 0. + +2.7. Outgoing-Call-Request + + The Outgoing-Call-Request is a PPTP control message sent by the PNS + to the PAC to indicate that an outbound call from the PAC is to be + established. This request provides the PAC with information required + to make the call. It also provides information to the PAC that is + used to regulate the transmission of data to the PNS for this session + once it is established. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 19] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Call Serial Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Minimum BPS | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum BPS | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Bearer Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Recv. Window Size | Packet Processing Delay | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Phone Number Length | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Phone Number (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Subaddress (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 7 for Outgoing-Call-Request. + + Reserved0 This field MUST be 0. + + + + + + + + + +Hamzeh, et al. Informational [Page 20] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Call ID A unique identifier, unique to a particular + PAC-PNS pair assigned by the PNS to this + session. It is used to multiplex and + demultiplex data sent over the tunnel + between the PNS and PAC involved in this + session. + + Call Serial Number An identifier assigned by the PNS to this + session for the purpose of identifying this + particular session in logged session + information. Unlike the Call ID, both the + PNS and PAC associate the same Call Serial + Number with a given session. The combination + of IP address and call serial number SHOULD + be unique. + + Minimum BPS The lowest acceptable line speed (in + bits/second) for this session. + + Maximum BPS The highest acceptable line speed (in + bits/second) for this session. + + Bearer Type A value indicating the bearer capability + required for this outgoing call. The + currently defined values are: + + 1 - Call to be placed on an analog + channel + + 2 - Call to be placed on a digital + channel + + 3 - Call can be placed on any type of + channel + + Framing Type A value indicating the type of PPP framing + to be used for this outgoing call. + + 1 - Call to use Asynchronous framing + + 2 - Call to use Synchronous framing + + 3 - Call can use either type of + framing + + Packet Recv. Window Size The number of received data packets the PNS + will buffer for this session. + + + + +Hamzeh, et al. Informational [Page 21] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Packet Processing Delay A measure of the packet processing delay + that might be imposed on data sent to the + PNS from the PAC. This value is specified + in units of 1/10 seconds. For the PNS this + number should be very small. See section + 4.4 for a description of how this value is + determined and used. + + Phone Number Length The actual number of valid digits in the + Phone Number field. + + Reserved1 This field MUST be 0. + + Phone Number The number to be dialed to establish the + outgoing session. For ISDN and analog calls + this field is an ASCII string. If the Phone + Number is less than 64 octets in length, the + remainder of this field is filled with + octets of value 0. + + Subaddress A 64 octet field used to specify additional + dialing information. If the subaddress is + less than 64 octets long, the remainder of + this field is filled with octets of value 0. + +2.8. Outgoing-Call-Reply + + The Outgoing-Call-Reply is a PPTP control message sent by the PAC to + the PNS in response to a received Outgoing-Call-Request message. The + reply indicates the result of the outgoing call attempt. It also + provides information to the PNS about particular parameters used for + the call. It provides information to allow the PNS to regulate the + transmission of data to the PAC for this session. + + + + + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 22] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Peer's Call ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | Error Code | Cause Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Connect Speed | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Recv. Window Size | Packet Processing Delay | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Physical Channel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 8 for Outgoing-Call-Reply. + + Reserved0 This field MUST be 0. + + Call ID A unique identifier for the tunnel, assigned + by the PAC to this session. It is used to + multiplex and demultiplex data sent over the + tunnel between the PNS and PAC involved in + this session. + + Peer's Call ID This field is set to the value received in + the Call ID field of the corresponding + Outgoing-Call-Request message. It is used + by the PNS to match the Outgoing-Call-Reply + with the Outgoing-Call-Request it issued. It + also is used as the value sent in the GRE + header for mux/demuxing. + + + + + + + +Hamzeh, et al. Informational [Page 23] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Result Code This value indicates the result of the + Outgoing-Call-Request attempt. Currently + valid values are: + + 1 (Connected) - Call established with + no errors + + 2 (General Error) - Outgoing Call not + established for the reason indicated + in Error Code + + 3 (No Carrier) - Outgoing Call failed + due to no carrier detected + + 4 (Busy) - Outgoing Call failed due to + detection of a busy signal + + 5 (No Dial Tone) - Outgoing Call + failed due to lack of a dial tone + + 6 (Time-out) - Outgoing Call was not + established within time allotted by + PAC + + 7 (Do Not Accept) - Outgoing Call + administratively prohibited + + Error Code This field is set to 0 unless a "General + Error" condition exists, in which case + Result Code is set to 2 and this field is + set to the value corresponding to the + general error condition as specified in + section 2.2. + + Cause Code This field gives additional failure + information. Its value can vary depending + upon the type of call attempted. For ISDN + call attempts it is the Q.931 cause code. + + Connect Speed The actual connection speed used, in + bits/second. + + Packet Recv. Window Size The number of received data packets the PAC + will buffer for this session. + + + + + + + +Hamzeh, et al. Informational [Page 24] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Packet Processing Delay A measure of the packet processing delay + that might be imposed on data sent to the + PAC from the PNS. This value is specified + in units of 1/10 seconds. For the PAC, this + number is related to the size of the buffer + used to hold packets to be sent to the + client and to the speed of the link to the + client. This value should be set to the + maximum delay that can normally occur + between the time a packet arrives at the PAC + and is delivered to the client. See section + 4.4 for an example of how this value is + determined and used. + + Physical Channel ID This field is set by the PAC in a vendor- + specific manner to the physical channel + number used to place this call. It is used + for logging purposes only. + +2.9. Incoming-Call-Request + + The Incoming-Call-Request is a PPTP control message sent by the PAC + to the PNS to indicate that an inbound call is to be established from + the PAC. This request provides the PNS with parameter information + for the incoming call. + + This message is the first in the "three-way handshake" used by PPTP + for establishing incoming calls. The PAC may defer answering the + call until it has received an Incoming-Call-Reply from the PNS + indicating that the call should be established. This mechanism allows + the PNS to obtain sufficient information about the call before it is + answered to determine whether the call should be answered or not. + + + + + + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 25] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Call Serial Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call Bearer Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Physical Channel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Dialed Number Length | Dialing Number Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Dialed Number (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Dialing Number (64 octets) + + | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Subaddress (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 9 for Incoming-Call-Request. + + Reserved0 This field MUST be 0. + + Call ID A unique identifier for this tunnel, + assigned by the PAC to this session. It is + used to multiplex and demultiplex data sent + over the tunnel between the PNS and PAC + involved in this session. + + + + + +Hamzeh, et al. Informational [Page 26] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Call Serial Number An identifier assigned by the PAC to this + session for the purpose of identifying this + particular session in logged session + information. Unlike the Call ID, both the + PNS and PAC associate the same Call Serial + Number to a given session. The combination + of IP address and call serial number should + be unique. + + Bearer Type A value indicating the bearer capability + used for this incoming call. Currently + defined values are: + + 1 - Call is on an analog channel + + 2 - Call is on a digital channel + + Physical Channel ID This field is set by the PAC in a vendor- + specific manner to the number of the + physical channel this call arrived on. + + Dialed Number Length The actual number of valid digits in the + Dialed Number field. + + Dialing Number Length The actual number of valid digits in the + Dialing Number field. + + Dialed Number The number that was dialed by the caller. + For ISDN and analog calls this field is an + ASCII string. If the Dialed Number is less + than 64 octets in length, the remainder of + this field is filled with octets of value 0. + + Dialing Number The number from which the call was placed. + For ISDN and analog calls this field is an + ASCII string. If the Dialing Number is less + than 64 octets in length, the remainder of + this field is filled with octets of value 0. + + Subaddress A 64 octet field used to specify additional + dialing information. If the subaddress is + less than 64 octets long, the remainder of + this field is filled with octets of value 0. + + + + + + + + +Hamzeh, et al. Informational [Page 27] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +2.10. Incoming-Call-Reply + + The Incoming-Call-Reply is a PPTP control message sent by the PNS to + the PAC in response to a received Incoming-Call-Request message. The + reply indicates the result of the incoming call attempt. It also + provides information to allow the PAC to regulate the transmission of + data to the PNS for this session. + + This message is the second in the three-way handshake used by PPTP + for establishing incoming calls. It indicates to the PAC whether the + call should be answered or not. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Peer's Call ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | Error Code | Packet Recv. Window Size | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Transmit Delay | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 10 for Incoming-Call-Reply. + + Reserved0 This field MUST be 0. + + Call ID A unique identifier for this tunnel assigned + by the PNS to this session. It is used to + multiplex and demultiplex data sent over the + tunnel between the PNS and PAC involved in + this session. + + Peer's Call ID This field is set to the value received in + the Call ID field of the corresponding + Incoming-Call-Request message. It is used by + + + +Hamzeh, et al. Informational [Page 28] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + the PAC to match the Incoming-Call-Reply + with the Incoming-Call-Request it issued. + This value is included in the GRE header of + transmitted data packets for this session. + + Result Code This value indicates the result of the + Incoming-Call-Request attempt. Current + valid Result Code values are: + + 1 (Connect) - The PAC should answer + the incoming call + + 2 (General Error) - The Incoming Call + should not be established due to the + reason indicated in Error Code + + 3 (Do Not Accept) - The PAC should not + accept the incoming call. It should + hang up or issue a busy indication + + Error Code This field is set to 0 unless a "General + Error" condition exists, in which case + Result Code is set to 2 and this field is + set to the value corresponding to the + general error condition as specified in + section 2.2. + + Packet Recv. Window Size The number of received data packets the PAC + will buffer for this session. + + Packet Transmit Delay A measure of the packet processing delay + that might be imposed on data sent to the + PAC from the PNS. This value is specified + in units of 1/10 seconds. + + Reserved1 This field MUST be 0. + +2.11. Incoming-Call-Connected + + The Incoming-Call-Connected message is a PPTP control message sent by + the PAC to the PNS in response to a received Incoming-Call-Reply. It + provides information to the PNS about particular parameters used for + the call. It also provides information to allow the PNS to regulate + the transmission of data to the PAC for this session. + + This message is the third in the three-way handshake used by PPTP for + establishing incoming calls. It provides a mechanism for providing + the PNS with additional information about the call that cannot, in + + + +Hamzeh, et al. Informational [Page 29] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + general, be obtained at the time the Incoming-Call-Request is issued + by the PAC. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer's Call ID | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Connect Speed | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Recv. Window Size | Packet Transmit Delay | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 11 for Incoming-Call-Connected. + + Reserved0 This field MUST be 0. + + Peer's Call ID This field is set to the value received in + the Call ID field of the corresponding + Incoming-Call-Reply message. It is used by + the PNS to match the Incoming-Call-Connected + with the Incoming-Call-Reply it issued. + + Connect Speed The actual connection speed used, in + bits/second. + + Packet Recv. Window Size The number of received data packets the PAC + will buffer for this session. + + Packet Transmit Delay A measure of the packet processing delay + that might be imposed on data sent to the + PAC from the PNS. This value is specified + in units of 1/10 seconds. + + + +Hamzeh, et al. Informational [Page 30] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Framing Type A value indicating the type of PPP framing + being used by this incoming call. + + 1 - Call uses asynchronous framing + + 2 - Call uses synchronous framing + +2.12. Call-Clear-Request + + The Call-Clear-Request is a PPTP control message sent by the PNS to + the PAC indicating that a particular call is to be disconnected. The + call being cleared can be either an incoming or outgoing call, in any + state. The PAC responds to this message with a Call-Disconnect- + Notify message. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 12 for Call-Clear-Request. + + Reserved0 This field MUST be 0. + + Call ID The Call ID assigned by the PNS to this + call. This value is used instead of the + Peer's Call ID because the latter may not be + known to the PNS if the call must be aborted + during call establishment. + + Reserved1 This field MUST be 0. + + + + + + +Hamzeh, et al. Informational [Page 31] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +2.13. Call-Disconnect-Notify + + The Call-Disconnect-Notify message is a PPTP control message sent by + the PAC to the PNS. It is issued whenever a call is disconnected, + due to the receipt by the PAC of a Call-Clear-Request or for any + other reason. Its purpose is to inform the PNS of both the + disconnection and the reason for it. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Result Code | Error Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cause Code | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Call Statistics (128 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 13 for Call-Disconnect-Notify. + + Reserved0 This field MUST be 0. + + Call ID The value of the Call ID assigned by the PAC + to this call. This value is used instead of + the Peer's Call ID because the latter may + not be known to the PNS if the call must be + aborted during call establishment. + + + + + + + + + +Hamzeh, et al. Informational [Page 32] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Result Code This value indicates the reason for the + disconnect. Current valid Result Code values + are: + + 1 (Lost Carrier) - Call disconnected + due to loss of carrier + + 2 (General Error) - Call disconnected + for the reason indicated in Error + Code + + 3 (Admin Shutdown) - Call disconnected + for administrative reasons + + 4 (Request) - Call disconnected due to + received Call-Clear-Request + + Error Code This field is set to 0 unless a "General + Error" condition exists, in which case the + Result Code is set to 2 and this field is + set to the value corresponding to the + general error condition as specified in + section 2.2. + + Cause Code This field gives additional disconnect + information. Its value varies depending on + the type of call being disconnected. For + ISDN calls it is the Q.931 cause code. + + Call Statistics This field is an ASCII string containing + vendor-specific call statistics that can be + logged for diagnostic purposes. If the + length of the string is less than 128, the + remainder of the field is filled with octets + of value 0. + +2.14. WAN-Error-Notify + + The WAN-Error-Notify message is a PPTP control message sent by the + PAC to the PNS to indicate WAN error conditions (conditions that + occur on the interface supporting PPP). The counters in this message + are cumulative. This message should only be sent when an error + occurs, and not more than once every 60 seconds. The counters are + reset when a new call is established. + + + + + + + +Hamzeh, et al. Informational [Page 33] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer's Call ID | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CRC Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hardware Overruns | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Buffer Overruns | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Time-out Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Alignment Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 14 for WAN-Error-Notify. + + Reserved0 This field MUST be 0. + + Peer's Call ID Th Call ID assigned by the PNS to this call. + + CRC Errors Number of PPP frames received with CRC + errors since session was established. + + Framing Errors Number of improperly framed PPP packets + received. + + Hardware Overruns Number of receive buffer over-runs since + session was established. + + Buffer Overruns Number of buffer over-runs detected since + session was established. + + + +Hamzeh, et al. Informational [Page 34] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Time-out Errors Number of time-outs since call was + established. + + Alignment Errors Number of alignment errors since call was + established. + +2.15. Set-Link-Info + + The Set-Link-Info message is a PPTP control message sent by the PNS + to the PAC to set PPP-negotiated options. Because these options can + change at any time during the life of the call, the PAC must be able + to update its internal call information dynamically and perform PPP + negotiation on an active PPP session. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer's Call ID | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Send ACCM | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Receive ACCM | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 15 for Set-Link-Info. + + Reserved0 This field MUST be 0. + + Peer's Call ID The value of the Call ID assigned by the PAC + to this call. + + Reserved1 This field MUST be 0. + + + + + + +Hamzeh, et al. Informational [Page 35] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Send ACCM The send ACCM value the client should use to + process outgoing PPP packets. The default + value used by the client until this message + is received is 0XFFFFFFFF. See [7]. + + Receive ACCM The receive ACCM value the client should use + to process incoming PPP packets. The default + value used by the client until this message + is received is 0XFFFFFFFF. See [7]. + +2.16. General Error Codes + + General error codes pertain to types of errors which are not specific + to any particular PPTP request, but rather to protocol or message + format errors. If a PPTP reply indicates in its Result Code that a + general error occurred, the General Error value should be examined to + determined what the error was. The currently defined General Error + codes and their meanings are: + + 0 (None) - No general error + + 1 (Not-Connected) - No control connection exists yet for this + PAC-PNS pair + + 2 (Bad-Format) - Length is wrong or Magic Cookie value is + incorrect + + 3 (Bad-Value) - One of the field values was out of range or + reserved field was non-zero + + 4 (No-Resource) - Insufficient resources to handle this command + now + + 5 (Bad-Call ID) - The Call ID is invalid in this context + + 6 (PAC-Error) - A generic vendor-specific error occurred in + the PAC + +3. Control Connection Protocol Operation + + This section describes the operation of various PPTP control + connection functions and the Control Connection messages which are + used to support them. The protocol operation of the control + connection is simplified because TCP is used to provide a reliable + transport mechanism. Ordering and retransmission of messages is not + a concern at this level. The TCP connection itself, however, can + close at any time and an appropriate error recovery mechanism must be + provided to handle this case. + + + +Hamzeh, et al. Informational [Page 36] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Some error recovery procedures are common to all states of the + control connection. If an expected reply does not arrive within 60 + seconds, the control connection is closed, unless otherwise + specified. Appropriate logging should be implemented for easy + determination of the problems and the reasons for closing the control + connection. + + Receipt of an invalid or malformed Control Connection message should + be logged appropriately, and the control connection should be closed + and restarted to ensure recovery into a known state. + +3.1. Control Connection States + + The control connection relies on a standard TCP connection for its + service. The PPTP control connection protocol is not distinguishable + between the PNS and PAC, but is distinguishable between the + originator and receiver. The originating peer is the one which first + attempts the TCP open. Since either PAC or PNS may originate a + connection, it is possible for a TCP collision to occur. See section + 3.1.3 for a description of this situation. + +3.1.1. Control Connection Originator (may be PAC or PNS) + + TCP Open Indication + /Send Start Control + Connection Request +-----------------+ + +------------------------------------>| wait_ctl_reply | + | +-----------------+ + | Collision/See (4.1.3) Close TCP V V V Receive Start Ctl + | +-------------------------------+ | | Connection Reply + | | | | Version OK + ^ V | V ++-----------------+ Receive Start Ctl | +-----------------+ +| idle | Connection Reply | | established | ++-----------------+ Version Not OK | +-----------------+ + ^ | V Local Terminate + | Receive Stop Control | | /Send Stop + | Connection Request | | Control Request + | /Send Stop Control Reply V V + | Close TCP +-----------------+ + +-------------------------------------| wait_stop_reply | + +-----------------+ + + + + + + + + + +Hamzeh, et al. Informational [Page 37] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + idle + The control connection originator attempts to open a TCP + connection to the peer during idle state. When the TCP connection + is open, the originator transmits a send Start-Control- + Connection-Request and then enters the wait_ctl_reply state. + + wait_ctl_reply + The originator checks to see if another TCP connection has been + requested from the same peer, and if so, handles the collision + situation described in section 3.1.3. + + When a Start-Control-Connection-Reply is received, it is examined + for a compatible version. If the version of the reply is lower + than the version sent in the request, the older (lower) version + should be used provided it is supported. If the version in the + reply is earlier and supported, the originator moves to the + established state. If the version is earlier and not supported, a + Stop-Control-Connection-Request SHOULD be sent to the peer and the + originator moves into the wait_stop_reply state. + + established + An established connection may be terminated by either a local + condition or the receipt of a Stop-Control-Connection-Request. In + the event of a local termination, the originator MUST send a + Stop-Control-Connection-Request and enter the wait_stop_reply + state. + + If the originator receives a Stop-Control-Connection-Request it + SHOULD send a Stop-Control-Connection-Reply and close the TCP + connection making sure that the final TCP information has been + "pushed" properly. + + wait_stop_reply + If a Stop-Control-Connection-Reply is received, the TCP connection + SHOULD be closed and the control connection becomes idle. + + + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 38] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +3.1.2. Control connection Receiver (may be PAC or PNS) + +Receive Start Control Connection Request +Version Not OK/Send Start Control Connection +Reply with Error + +--------+ + | | Receive Control Connection Request Version OK + | | /Send Start Control Connection Reply + | | +----------------------------------------+ + ^ V ^ V ++-----------------+ Receive Start Ctl +-----------------+ +| Idle | Connection Request | Established | ++-----------------+ /Send Stop Reply +-----------------+ + ^ ^ Close TCP V V Local Terminate + | +-------------------------------------+ | /Send Stop + | | Control Conn. + | V Request + | +-----------------+ + +-------------------------------------| Wait-Stop-Reply | + Receive Stop Control +-----------------+ + Connection Reply + /Close TCP + + idle + The control connection receiver waits for a TCP open attempt on + port 1723. When notified of an open TCP connection, it should + prepare to receive PPTP messages. When a Start-Control- + Connection-Request is received its version field should be + examined. If the version is earlier than the receiver's version + and the earlier version can be supported by the receiver, the + receiver SHOULD send a Start-Control-Connection-Reply. If the + version is earlier than the receiver's version and the version + cannot be supported, the receiver SHOULD send a Start-Connection- + Reply message, close the TCP connection and remain in the idle + state. If the receiver's version is the same as earlier than the + peer's, the receiver SHOULD send a Start-Control-Connection-Reply + with the receiver's version and enter the established state. + + established + An established connection may be terminated by either a local + condition or the reception of a Stop-Control-Connection-Request. + In the event of a local termination, the originator MUST send a + Stop-Control-Connection-Request and enter the wait_stop_reply + state. + + + + + + + +Hamzeh, et al. Informational [Page 39] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + If the originator receives a Stop-Control-Connection-Request it + SHOULD send a Stop-Control-Connection-Reply and close the TCP + connection, making sure that the final TCP information has been + "pushed" properly. + + wait_stop_reply + If a Stop-Control-Connection-Reply is received, the TCP connection + SHOULD be closed and the control connection becomes idle. + +3.1.3. Start Control Connection Initiation Request Collision + + A PAC and PNS must have only one control connection between them. It + is possible, however, for a PNS and a PAC to simultaneously attempt + to establish a control connection to each other. When a Start- + Control-Connection-Request is received on one TCP connection and + another Start-Control-Connection-Request has already been sent on + another TCP connection to the same peer, a collision has occurred. + + The "winner" of the initiation race is the peer with the higher IP + address (compared as 32 bit unsigned values, network number more + significant). For example, if the peers 192.33.45.17 and 192.33.45.89 + collide, the latter will be declared the winner. The loser will + immediately close the TCP connection it initiated, without sending + any further PPTP control messages on it and will respond to the + winner's request with a Start-Control-Connection-Reply message. The + winner will wait for the Start-Control-Connection-Reply on the + connection it initiated and also wait for a TCP termination + indication on the connection the loser opened. The winner MUST NOT + send any messages on the connection the loser initiated. + +3.1.4. Keep Alives and Timers + + A control connection SHOULD be closed by closing the underlying TCP + connection under the following circumstances: + + 1. If a control connection is not in the established state (i.e., + Start-Control-Connection-Request and Start-Control-Connection- + Reply have not been exchanged), a control connection SHOULD be + closed after 60 seconds by a peer waiting for a Start-Control- + Connection-Request or Start-Control-Connection-Reply message. + + 2. If a peer's control connection is in the established state and has + not received a control message for 60 seconds, it SHOULD send a + Echo-Request message. If an Echo-Reply is not received 60 seconds + after the Echo-Request message transmission, the control + connection SHOULD be closed. + + + + + +Hamzeh, et al. Informational [Page 40] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +3.2. Call States + +3.2.1. Timing considerations + + Because of the real-time nature of telephone signaling, both the PNS + and PAC should be implemented with multi-threaded architectures such + that messages related to multiple calls are not serialized and + blocked. The transit delay between the PAC and PNS should not exceed + one second. The call and connection state figures do not specify + exceptions caused by timers. The implicit assumption is that since + the TCP-based control connection is being verified with keep-alives, + there is less need to maintain strict timers for call control + messages. + + Establishing outbound international calls, including the modem + training and negotiation sequences, may take in excess of 1 minute so + the use of short timers is discouraged. + + If a state transition does not occur within 1 minute (except for + connections in the idle or established states), the integrity of the + protocol processing between the peers is suspect and the ENTIRE + CONTROL CONNECTION should be closed and restarted. All Call IDs are + logically released whenever a control connection is started. This + presumably also helps in preventing toll calls from being "lost" and + never cleared. + +3.2.2. Call ID Values + + Each peer assigns a Call ID value to each user session it requests or + accepts. This Call ID value MUST be unique for the tunnel between the + PNS and PAC to which it belongs. Tunnels to other peers can use the + same Call ID number so the receiver of a packet on a tunnel needs to + associate a user session with a particular tunnel and Call ID. It is + suggested that the number of potential Call ID values for each tunnel + be at least twice as large as the maximum number of calls expected on + a given tunnel. + + A session is defined by the triple (PAC, PNS, Call ID). + +3.2.3. Incoming Calls + + An Incoming-Call-Request message is generated by the PAC when an + associated telephone line rings. The PAC selects a Call ID and serial + number and indicates the call bearer type. Modems should always + indicate analog call type. ISDN calls should indicate digital when + unrestricted digital service or rate adaption is used and analog if + + + + + +Hamzeh, et al. Informational [Page 41] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + digital modems are involved. Dialing number, dialed number, and + subaddress may be included in the message if they are available from + the telephone network. + + Once the PAC sends the Incoming-Call-Request, it waits for a response + from the PNS but does not answer the call from the telephone network. + The PNS may choose not to accept the call if: + + - No resources are available to handle more sessions + + - The dialed, dialing, or subaddress fields are not indicative of + an authorized user + + - The bearer service is not authorized or supported + + If the PNS chooses to accept the call, it responds with an Incoming- + Call-Reply which also indicates window sizes (see section 4.2). When + the PAC receives the Outgoing-Call-Reply, it attempts to connect the + call, assuming the calling party has not hung up. A final call + connected message from the PAC to the PNS indicates that the call + states for both the PAC and the PNS should enter the established + state. + + When the dialed-in client hangs up, the call is cleared normally and + the PAC sends a Call-Disconnect-Notify message. If the PNS wishes to + clear a call, it sends a Call-Clear-Request message and then waits + for a Call-Disconnect-Notify. + +3.2.3.1. PAC Incoming Call States + + Ring/Send Incoming Call Request +-----------------+ + +----------------------------------------->| wait_reply | + | +-----------------+ + | Receive Incoming Call Reply V V V + | Not Accepting | | | Receive Incoming + | +--------------------------------+ | | Call Reply Accept- + | | +------------------------------+ | ing/Answer call; + | | | Abort/Send Call | Send Call + ^ V V Disconnect Notify V Connected ++-----------------+ +-----------------+ +| idle |<-----------------------------| established | ++-----------------+ Receive Clear Call Request +-----------------+ + or telco call dropped + or local disconnect + /Send Call Disconnect Notify + + + + + + +Hamzeh, et al. Informational [Page 42] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +The states associated with the PAC for incoming calls are: + + idle + The PAC detects an incoming call on one of its telco interfaces. + Typically this means an analog line is ringing or an ISDN TE has + detected an incoming Q.931 SETUP message. The PAC sends an + Incoming-Call-Request message and moves to the wait_reply state. + + wait_reply + The PAC receives an Incoming-Call-Reply message indicating non- + willingness to accept the call (general error or don't accept) and + moves back into the idle state. If the reply message indicates + that the call is accepted, the PAC sends an Incoming-Call- + Connected message and enters the established state. + + established + Data is exchanged over the tunnel. The call may be cleared + following: + + An event on the telco connection. The PAC sends a + Call-Disconnect-Notify message + + Receipt of a Call-Clear-Request. The PAC sends a + Call-Disconnect-Notify message + + A local reason. The PAC sends a Call-Disconnect-Notify message. + +3.2.3.2. PNS Incoming Call States + + Receive Incoming Call Request + /Send Incoming Call Reply +-----------------+ + Not Accepting if Error | Wait-Connect | + +-----+ +-----------------+ + | | Receive Incoming Call Req. ^ V V + | | /Send Incoming Call Reply OK | | | Receive Incoming + | | +--------------------------------+ | | Call Connect + ^ V ^ V------------------------------+ V ++-----------------+ Receive Call Disconnect +-----------------+ +| Idle | Notify +- | Established | ++-----------------+ | +-----------------+ + ^ ^ | V Local Terminate + | +----------------------------+ | /Send Call Clear + | Receive Call Disconnect | Request + | Notify V + | +-----------------+ + +--------------------------------------| Wait-Disconnect | + Receive Call Disconnect +-----------------+ + Notify + + + +Hamzeh, et al. Informational [Page 43] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +The states associated with the PNS for incoming calls are: + + idle + An Incoming-Call-Request message is received. If the request is + not acceptable, an Incoming-Call-Reply is sent back to the PAC and + the PNS remains in the idle state. If the Incoming-Call-Request + message is acceptable, an Incoming-Call-Reply is sent indicating + accept in the result code. The session moves to the wait_connect + state. + + wait_connect + If the session is connected on the PAC, the PAC sends an incoming + call connect message to the PNS which then moves into established + state. The PAC may send a Call-Disconnect-Notify to indicate that + the incoming caller could not be connected. This could happen, + for example, if a telephone user accidently places a standard + voice call to a PAC resulting in a handshake failure on the called + modem. + + established + The session is terminated either by receipt of a Call-Disconnect- + Notify message from the PAC or by sending a Call-Clear-Request. + Once a Call-Clear-Request has been sent, the session enters the + wait_disconnect state. + + wait_disconnect + Once a Call-Disconnect-Notify is received the session moves back + to the idle state. + +3.2.4. Outgoing Calls + + Outgoing messages are initiated by a PNS and instruct a PAC to place + a call on a telco interface. There are only two messages for outgoing + calls: Outgoing-Call-Request and Outgoing-Call-Reply. The PNS sends + an Outgoing-Call-Request specifying the dialed party phone number and + subaddress as well as speed and window parameters. The PAC MUST + respond to the Outgoing-Call-Request message with an Outgoing-Call- + Reply message once the PAC determines that: + + The call has been successfully connected + + A call failure has occurred for reasons such as: no interfaces are + available for dial-out, the called party is busy or does not + answer, or no dial tone is detected on the interface chosen for + dialing + + + + + + +Hamzeh, et al. Informational [Page 44] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +3.2.4.1. PAC Outgoing Call States + +Receive Outgoing Call Request in Error +/Send Outgoing Call Reply with Error + |--------+ + | | Receive Outgoing Call Request No Error + | | /Off Hook; Dial + | | +----------------------------------------- + ^ V ^ V ++-----------------+ Incomplete Call +-----------------+ +| idle | /Send Outgoing Call | wait_cs_ans | ++-----------------+ Reply with Error +-----------------+ + ^ ^ or Recv. Call Clear Req. V V Telco Answer + | | /Send Disconnect Notify| | /Send Outgoing + | +-------------------------------------+ | Call Reply. + | V + | +-----------------+ + +-------------------------------------| established | + Receive Call Clear Request +-----------------+ + or local terminate + or telco disconnect + /Hangup call and send + Call Disconnect Notify + + The states associated with the PAC for outgoing calls are: + + idle + Received Outgoing-Call-Request. If this is received in error, + respond with an Outgoing-Call-Reply with error condition set. + Otherwise, allocate physical channel to dial on. Place the + outbound call, wait for a connection, and move to the wait_cs_ans + state. + + wait_cs_ans + If the call is incomplete, send an Outgoing-Call-Reply with a + non-zero Error Code. If a timer expires on an outbound call, send + back an Outgoing-Call-Reply with a non-zero Error Code. If a + circuit switched connection is established, send an Outgoing- + Call-Reply indicating success. + + established + If a Call-Clear-Request is received, the telco call SHOULD be + released via appropriate mechanisms and a Call-Disconnect-Notify + message SHOULD BE sent to the PNS. If the call is disconnected by + the client or by the telco interface, a Call-Disconnect-Notify + message SHOULD be sent to the PNS. + + + + + +Hamzeh, et al. Informational [Page 45] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +3.2.4.2. PNS Outgoing Call States + + Open Indication Abort/Send + /Send Outgoing Call Call Clear + Request +-----------------+Request + +-------------------------------->| Wait-Reply |----------+ + | +-----------------+ | + | Receive Outgoing Call Reply V V Receive Outgoing | + | with Error | | Call Reply | + | +-------------------------------+ | No Error | + ^ V V | ++-----------------+ +-----------------+ | +| Idle |<-----------------------------| Established | | ++-----------------+ Receive Call Disconnect +-----------------+ | + ^ Notify V Local Terminate | + | | /Send Call Clear | + | | Request | + | Receive Call Disconnect V | + | Notify +-----------------+ | + +---------------------------------| Wait-Disconnect |<---------+ + +-----------------+ + +The states associated with the PNS for outgoing calls are: + + idle + An Outgoing-Call-Request message is sent to the PAC and the + session moves into the wait_reply state. + + wait_reply + An Outgoing-Call-Reply is received which indicates an error. The + session returns to idle state. No telco call is active. If the + Outgoing-Call-Reply does not indicate an error, the telco call is + connected and the session moves to the established state. + + established + If a Call-Disconnect-Notify is received, the telco call has been + terminated for the reason indicated in the Result and Cause Codes. + The session moves back to the idle state. If the PNS chooses to + terminate the session, it sends a Call-Clear-Request to the PAC + and then enters the wait_disconnect state. + + wait_disconnect + A session disconnection is waiting to be confirmed by the PAC. + Once the PNS receives the Call-Disconnect-Notify message, the + session enters idle state. + + + + + + +Hamzeh, et al. Informational [Page 46] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +4. Tunnel Protocol Operation + + The user data carried by the PPTP protocol are PPP data packets. PPP + packets are carried between the PAC and PNS, encapsulated in GRE + packets which in turn are carried over IP. The encapsulated PPP + packets are essentially PPP data packets less any media specific + framing elements. No HDLC flags, bit insertion, control characters, + or control character escapes are included. No CRCs are sent through + the tunnel. The IP packets transmitted over the tunnels between a PAC + and PNS has the following general structure: + + +--------------------------------+ + | Media Header | + +--------------------------------+ + | IP Header | + +--------------------------------+ + | GRE Header | + +--------------------------------+ + | PPP Packet | + +--------------------------------+ + +4.1. Enhanced GRE header + + The GRE header used in PPTP is enhanced slightly from that specified + in the current GRE protocol specification [1,2]. The main difference + involves the definition of a new Acknowledgment Number field, used to + determine if a particular GRE packet or set of packets has arrived at + the remote end of the tunnel. This Acknowledgment capability is not + used in conjunction with any retransmission of user data packets. It + is used instead to determine the rate at which user data packets are + to be transmitted over the tunnel for a given user session. The + format of the enhanced GRE header is as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key (HW) Payload Length | Key (LW) Call ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number (Optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Acknowledgment Number (Optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Hamzeh, et al. Informational [Page 47] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + C + (Bit 0) Checksum Present. Set to zero (0). + + R + (Bit 1) Routing Present. Set to zero (0). + + K + (Bit 2) Key Present. Set to one (1). + S + (Bit 3) Sequence Number Present. Set to one (1) if a payload + (data) packet is present. Set to zero (0) if payload is not + present (GRE packet is an Acknowledgment only). + + s + (Bit 4) Strict source route present. Set to zero (0). + + Recur + (Bits 5-7) Recursion control. Set to zero (0). + + A + (Bit 8) Acknowledgment sequence number present. Set to one (1) if + packet contains Acknowledgment Number to be used for acknowledging + previously transmitted data. + + Flags + (Bits 9-12) Must be set to zero (0). + + Ver + (Bits 13-15) Must contain 1 (enhanced GRE). + + Protocol Type + Set to hex 880B [8]. + + Key + Use of the Key field is up to the implementation. PPTP uses it as + follows: + Payload Length + (High 2 octets of Key) Size of the payload, not including + the GRE header + + Call ID + (Low 2 octets) Contains the Peer's Call ID for the session + to which this packet belongs. + + Sequence Number + Contains the sequence number of the payload. Present if S + bit (Bit 3) is one (1). + + + + +Hamzeh, et al. Informational [Page 48] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Acknowledgment Number + Contains the sequence number of the highest numbered GRE + packet received by the sending peer for this user session. + Present if A bit (Bit 8) is one (1). + + The payload section contains a PPP data packet without any + media specific framing elements. + + The sequence numbers involved are per packet sequence numbers. + The sequence number for each user session is set to zero at + session startup. Each packet sent for a given user session + which contains a payload (and has the S bit (Bit 3) set to one) + is assigned the next consecutive sequence number for that + session. + + This protocol allows acknowledgments to be carried with the + data and makes the overall protocol more efficient, which in + turn requires less buffering of packets. + +4.2. Sliding Window Protocol + + The sliding window protocol used on the PPTP data path is used for + flow control by each side of the data exchange. The enhanced GRE + protocol allows packet acknowledgments to be piggybacked on data + packets. Acknowledgments can also be sent separately from data + packets. Again, the main purpose of the sliding window protocol is + for flow control--retransmissions are not performed by the tunnel + peers. + +4.2.1. Initial Window Size + + Although each side has indicated the maximum size of its receive + window, it is recommended that a conservative approach be taken when + beginning to transmit data. The initial window size on the + transmitter is set to half the maximum size the receiver requested, + with a minimum size of one packet. The transmitter stops sending + packets when the number of packets awaiting acknowledgment is equal + to the current window size. As the receiver successfully digests + each window, the window size on the transmitter is bumped up by one + packet until the maximum is reached. This method prevents a system + from flooding an already congested network because no history has + been established. + +4.2.2. Closing the Window + + When a time-out does occur on a packet, the sender adjusts the size + of the transmit window down to one half its value when it failed. + Fractions are rounded up, and the minimum window size is one. + + + +Hamzeh, et al. Informational [Page 49] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +4.2.3. Opening the Window + + With every successful transmission of a window's worth of packets + without a time-out, the transmit window size is increased by one + packet until it reaches the maximum window size that was sent by the + other side when the call was connected. As stated earlier, no + retransmission is done on a time-out. After a time-out, the + transmission resumes with the window starting at one half the size of + the transmit window when the time-out occurred and adjusting upward + by one each time the transmit window is filled with packets that are + all acknowledged without time-outs. + +4.2.4. Window Overflow + + When a receiver's window overflows with too many incoming packets, + excess packets are thrown away. This situation should not arise if + the sliding window procedures are being properly followed by the + transmitter and receiver. It is assumed that, on the transmit side, + packets are buffered for transmission and are no longer accepted from + the packet source when the transmit buffer fills. + +4.2.5. Multi-packet Acknowledgment + + One feature of the PPTP sliding window protocol is that it allows the + acknowledgment of multiple packets with a single acknowledgment. All + outstanding packets with a sequence number lower or equal to the + acknowledgment number are considered acknowledged. Time-out + calculations are performed using the time the packet corresponding to + the highest sequence number being acknowledged was transmitted. + + Adaptive time-out calculations are only performed when an + Acknowledgment is received. When multi-packet acknowledgments are + used, the overhead of the adaptive time-out algorithm is reduced. The + PAC is not required to transmit multi-packet acknowledgments; it can + instead acknowledge each packet individually as it is delivered to + the PPP client. + +4.3. Out-of-sequence Packets + + Occasionally packets lose their sequencing across a complicated + internetwork. Say, for example that a PNS sends packets 0 to 5 to a + PAC. Because of rerouting in the internetwork, packet 4 arrives at + the PAC before packet 3. The PAC acknowledges packet 4, and may + assume packet 3 is lost. This acknowledgment grants window credit + beyond packet 4. + + + + + + +Hamzeh, et al. Informational [Page 50] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + When the PAC does receive packet 3, it MUST not attempt to transmit + it to the corresponding PPP client. To do so could cause problems, + as proper PPP protocol operation is premised upon receiving packets + in sequence. PPP does properly deal with the loss of packets, but + not with reordering so out of sequence packets between the PNS and + PAC MUST be silently discarded, or they may be reordered by the + receiver. When packet 5 comes in, it is acknowledged by the PAC + since it has a higher sequence number than 4, which was the last + highest packet acknowledged by the PAC. Packets with duplicate + sequence numbers should never occur since the PAC and PNS never + retransmit GRE packets. A robust implementation will silently + discard duplicate GRE packets, should it receive any. + +4.4. Acknowledgment Time-Outs + + PPTP uses sliding windows and time-outs to provide both user session + flow-control across the internetwork and to perform efficient data + buffering to keep the PAC-PNS data channels full without causing + receive buffer overflow. PPTP requires that a time-out be used to + recover from dropped data or acknowledgment packets. The exact + implementation of the time-out is vendor-specific. It is suggested + that an adaptive time-out be implemented with backoff for congestion + control. The time-out mechanism proposed here has the following + properties: + + Independent time-outs for each session. A device (PAC or PNS) will + have to maintain and calculate time-outs for every active session. + + An administrator-adjustable maximum time-out, MaxTimeOut, unique + to each device. + + An adaptive time-out mechanism that compensates for changing + throughput. To reduce packet processing overhead, vendors may + choose not to recompute the adaptive time-out for every received + acknowledgment. The result of this overhead reduction is that the + time-out will not respond as quickly to rapid network changes. + + Timer backoff on time-out to reduce congestion. The backed-off + timer value is limited by the configurable maximum time-out value. + Timer backoff is done every time an acknowledgment time-out + occurs. + + In general, this mechanism has the desirable behavior of quickly + backing off upon a time-out and of slowly decreasing the time-out + value as packets are delivered without time-outs. + + + + + + +Hamzeh, et al. Informational [Page 51] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Some definitions: + + Packet Processing Delay (PPD) is the amount of time required for + each side to process the maximum amount of data buffered in their + receive packet sliding window. The PPD is the value exchanged + between the PAC and PNS when a call is established. For the PNS, + this number should be small. For a PAC making modem connections, + this number could be significant. + + Sample is the actual amount of time incurred receiving an + acknowledgment for a packet. The Sample is measured, not + calculated. + + Round-Trip Time (RTT) is the estimated round-trip time for an + Acknowledgment to be received for a given transmitted packet. When + the network link is a local network, this delay will be minimal + (if not zero). When the network link is the Internet, this delay + could be substantial and vary widely. RTT is adaptive: it will + adjust to include the PPD and whatever shifting network delays + contribute to the time between a packet being transmitted and + receiving its acknowledgment. + + Adaptive Time-Out (ATO) is the time that must elapse before an + acknowledgment is considered lost. After a time-out, the sliding + window is partially closed and the ATO is backed off. + + The Packet Processing Delay (PPD) parameter is a 16-bit word + exchanged during the Call Control phase that represents tenths of a + second (64 means 6.4 seconds). The protocol only specifies that the + parameter is exchanged, it does not specify how it is calculated. The + way values for PPD are calculated is implementation-dependent and + need not be variable (static time-outs are allowed). The PPD must be + exchanged in the call connect sequences, even if it remains constant + in an implementation. One possible way to calculate the PPD is: + + PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate + PPD = PPD' + PACFudge + + Header is the total size of the IP and GRE headers, which is 36. The + MTU is the overall MTU for the internetwork link between the PAC and + PNS. WindowSize represents the number of packets in the sliding + window, and is implementation-dependent. The latency of the + internetwork could be used to pick a window size sufficient to keep + the current session's pipe full. The constant 8 converts octets to + bits (assuming ConnectRate is in bits per second). If ConnectRate is + in bytes per second, omit the 8. PACFudge is not required but can be + used to take overall processing overhead of the PAC into account. + + + + +Hamzeh, et al. Informational [Page 52] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + The value of PPD is used to seed the adaptive algorithm with the + initial RTT[n-1] value. + +4.4.1. Calculating Adaptive Acknowledgment Time-Out + + We still must decide how much time to allow for acknowledgments to + return. If the time-out is set too high, we may wait an unnecessarily + long time for dropped packets. If the time-out is too short, we may + time out just before the acknowledgment arrives. The acknowledgment + time-out should also be reasonable and responsive to changing network + conditions. + + The suggested adaptive algorithm detailed below is based on the TCP + 1989 implementation and is explained in [11]. 'n' means this + iteration of the calculation, and 'n-1' refers to values from the + last calculation. + + DIFF[n] = SAMPLE[n] - RTT[n-1] + DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) + RTT[n] = RTT[n-1] + (alpha * DIFF[n]) + ATO[n] = MAX (MinTimeOut, MIN (RTT[n] + + (chi * DEV[n]), MaxTimeOut)) + + DIFF represents the error between the last estimated round-trip + time and the measured time. DIFF is calculated on each iteration. + + DEV is the estimated mean deviation. This approximates the + standard deviation. DEV is calculated on each iteration and + stored for use in the next iteration. Initially, it is set to 0. + + RTT is the estimated round-trip time of an average packet. RTT is + ycalculated on each iteration and stored for use in the next + iteration. Initially, it is set to PPD. + + ATO is the adaptive time-out for the next transmitted packet. ATO + is calculated on each iteration. Its value is limited, by the MIN + function, to be a maximum of the configured MaxTimeOut value. + + Alpha is the gain for the average and is typically 1/8 (0.125). + + Beta is the gain for the deviation and is typically 1/4 (0.250). + + Chi is the gain for the time-out and is typically set to 4. + + + + + + + + +Hamzeh, et al. Informational [Page 53] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + To eliminate division operations for fractional gain elements, the + entire set of equations can be scaled. With the suggested gain + constants, they should be scaled by 8 to eliminate all division. To + simplify calculations, all gain values are kept to powers of two so + that shift operations can be used in place of multiplication or + division. + +4.4.2. Congestion Control: Adjusting for Time-Out + + This section describes how the calculation of ATO is modified in the + case where a time-out does occur. When a time-out occurs, the time- + out value should be adjusted rapidly upward. Although the GRE + packets are not retransmitted when a time-out occurs, the time-out + should be adjusted up toward a maximum limit. To compensate for + shifting internetwork time delays, a strategy must be employed to + increase the time-out when it expires (notice that in addition to + increasing the time-out, we are also shrinking the size of the window + as described in the next section). For an interval in which a time- + out occurs, the new + ATO is calculated as: + + RTT[n] = delta * RTT[n-1] + DEV[n] = DEV[n-1] + ATO[n] = MAX (MinTimeOut, MIN (RTT[n] + + (chi * DEV[n]), MaxTimeOut)) + + In this calculation of ATO, only the two values that both contribute + to ATO and are stored for the next iteration are calculated. RTT is + scaled by delta, and DEV is unmodified. DIFF is not carried forward + and is not used in this scenario. A value of 2 for Delta, the time- + out gain factor for RTT, is suggested. + +5. Security Considerations + + The security of user data passed over the tunneled PPP connection is + addressed by PPP, as is authentication of the PPP peers. + + Because the PPTP control channel messages are neither authenticated + nor integrity protected, it might be possible for an attacker to + hijack the underlying TCP connection. It is also possible to + manufacture false control channel messages and alter genuine messages + in transit without detection. + + The GRE packets forming the tunnel itself are not cryptographically + protected. Because the PPP negotiations are carried out over the + tunnel, it may be possible for an attacker to eavesdrop on and modify + those negotiations. + + + + +Hamzeh, et al. Informational [Page 54] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Unless the PPP payload data is cryptographically protected, it can be + captured and read or modified. + +6. Authors' Addresses + + Kory Hamzeh + Ascend Communications + 1275 Harbor Bay Parkway + Alameda, CA 94502 + + EMail: kory@ascend.com + + + Gurdeep Singh Pall + Microsoft Corporation + Redmond, WA + + EMail: gurdeep@microsoft.com + + + William Verthein + U.S. Robotics/3Com + + + Jeff Taarud + Copper Mountain Networks + + + W. Andrew Little + ECI Telematics + + + Glen Zorn + Microsoft Corporation + Redmond, WA + + EMail: glennz@microsoft.com + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 55] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +7. References + + [1] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing + Encapsulation (GRE)", RFC 1701, October 1994. + + [2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing + Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994. + + [3] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC + 1334, October 1992. + + [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, + September 1981. + + [5] Postel, J., "User Data Protocol", STD 6, RFC 768, August 1980. + + [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, + October 1994. See also: http://www.iana.org/numbers.html + + [7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + [8] Ethertype for PPP, Reserved with Xerox Corporation. + + [9] Simpson, W., "PPP Challenge Handshake Authentication Protocol + (CHAP)", RFC 1994, August 1996. + + [10] Blunk, L. and J Vollbrecht, "PPP Extensible Authentication + Protocol (EAP)", RFC 2284, March 1998. + + [11] Stevens, R., "TCP/IP Illustrated, Volume 1", p. 300, Addison- + Wesley, 1994. + + [12] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 56] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +8. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 57] + diff --git a/rfc/rfc2716.txt b/rfc/rfc2716.txt new file mode 100644 index 00000000..71b4a84b --- /dev/null +++ b/rfc/rfc2716.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group B. Aboba +Requests for Commments: 2716 D. Simon +Category: Experimental Microsoft + October 1999 + + + PPP EAP TLS Authentication Protocol + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +1. Abstract + + The Point-to-Point Protocol (PPP) provides a standard method for + transporting multi-protocol datagrams over point-to-point links. PPP + also defines an extensible Link Control Protocol (LCP), which can be + used to negotiate authentication methods, as well as an Encryption + Control Protocol (ECP), used to negotiate data encryption over PPP + links, and a Compression Control Protocol (CCP), used to negotiate + compression methods. The Extensible Authentication Protocol (EAP) is + a PPP extension that provides support for additional authentication + methods within PPP. + + Transport Level Security (TLS) provides for mutual authentication, + integrity-protected ciphersuite negotiation and key exchange between + two endpoints. This document describes how EAP-TLS, which includes + support for fragmentation and reassembly, provides for these TLS + mechanisms within EAP. + +2. Introduction + + The Extensible Authentication Protocol (EAP), described in [5], + provides a standard mechanism for support of additional + authentication methods within PPP. Through the use of EAP, support + for a number of authentication schemes may be added, including smart + cards, Kerberos, Public Key, One Time Passwords, and others. To date + however, EAP methods such as [6] have focussed on authenticating a + client to a server. + + + + + +Aboba & Simon Experimental [Page 1] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + However, it may be desirable to support mutual authentication, and + since PPP encryption protocols such as [9] and [10] assume existence + of a session key, it is useful to have a mechanism for session key + establishment. Since design of secure key management protocols is + non-trivial, it is desirable to avoid creating new mechanisms for + this. The EAP protocol described in this document allows a PPP peer + to take advantage of the protected ciphersuite negotiation, mutual + authentication and key management capabilities of the TLS protocol, + described in [12]. + +2.1. Requirements language + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as + described in [11]. + +3. Protocol overview + +3.1. Overview of the EAP-TLS conversation + + As described in [5], the EAP-TLS conversation will typically begin + with the authenticator and the peer negotiating EAP. The + authenticator will then typically send an EAP-Request/Identity packet + to the peer, and the peer will respond with an EAP-Response/Identity + packet to the authenticator, containing the peer's userId. + + From this point forward, while nominally the EAP conversation occurs + between the PPP authenticator and the peer, the authenticator MAY act + as a passthrough device, with the EAP packets received from the peer + being encapsulated for transmission to a RADIUS server or backend + security server. In the discussion that follows, we will use the term + "EAP server" to denote the ultimate endpoint conversing with the + peer. + + Once having received the peer's Identity, the EAP server MUST respond + with an EAP-TLS/Start packet, which is an EAP-Request packet with + EAP-Type=EAP-TLS, the Start (S) bit set, and no data. The EAP-TLS + conversation will then begin, with the peer sending an EAP-Response + packet with EAP-Type=EAP-TLS. The data field of that packet will + encapsulate one or more TLS records in TLS record layer format, + containing a TLS client_hello handshake message. The current cipher + spec for the TLS records will be TLS_NULL_WITH_NULL_NULL and null + compression. This current cipher spec remains the same until the + change_cipher_spec message signals that subsequent records will have + the negotiated attributes for the remainder of the handshake. + + + + + + +Aboba & Simon Experimental [Page 2] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + The client_hello message contains the client's TLS version number, a + sessionId, a random number, and a set of ciphersuites supported by + the client. The version offered by the client MUST correspond to TLS + v1.0 or later. + + The EAP server will then respond with an EAP-Request packet with + EAP-Type=EAP-TLS. The data field of this packet will encapsulate one + or more TLS records. These will contain a TLS server_hello handshake + message, possibly followed by TLS certificate, server_key_exchange, + certificate_request, server_hello_done and/or finished handshake + messages, and/or a TLS change_cipher_spec message. The server_hello + handshake message contains a TLS version number, another random + number, a sessionId, and a ciphersuite. The version offered by the + server MUST correspond to TLS v1.0 or later. + + If the client's sessionId is null or unrecognized by the server, the + server MUST choose the sessionId to establish a new session; + otherwise, the sessionId will match that offered by the client, + indicating a resumption of the previously established session with + that sessionID. The server will also choose a ciphersuite from those + offered by the client; if the session matches the client's, then the + ciphersuite MUST match the one negotiated during the handshake + protocol execution that established the session. + + The purpose of the sessionId within the TLS protocol is to allow for + improved efficiency in the case where a client repeatedly attempts to + authenticate to an EAP server within a short period of time. While + this model was developed for use with HTTP authentication, it may + also have application to PPP authentication (e.g. multilink). + + As a result, it is left up to the peer whether to attempt to continue + a previous session, thus shortening the TLS conversation. Typically + the peer's decision will be made based on the time elapsed since the + previous authentication attempt to that EAP server. Based on the + sessionId chosen by the peer, and the time elapsed since the previous + authentication, the EAP server will decide whether to allow the + continuation, or whether to choose a new session. + + In the case where the EAP server and authenticator reside on the same + device, then client will only be able to continue sessions when + connecting to the same NAS or tunnel server. Should these devices be + set up in a rotary or round-robin then it may not be possible for the + peer to know in advance the authenticator it will be connecting to, + and therefore which sessionId to attempt to reuse. As a result, it is + likely that the continuation attempt will fail. In the case where the + EAP authentication is remoted then continuation is much more likely + to be successful, since multiple NAS devices and tunnel servers will + remote their EAP authentications to the same RADIUS server. + + + +Aboba & Simon Experimental [Page 3] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + If the EAP server is resuming a previously established session, then + it MUST include only a TLS change_cipher_spec message and a TLS + finished handshake message after the server_hello message. The + finished message contains the EAP server's authentication response to + the peer. If the EAP server is not resuming a previously established + session, then it MUST include a TLS server_certificate handshake + message, and a server_hello_done handshake message MUST be the last + handshake message encapsulated in this EAP-Request packet. + + The certificate message contains a public key certificate chain for + either a key exchange public key (such as an RSA or Diffie-Hellman + key exchange public key) or a signature public key (such as an RSA or + DSS signature public key). In the latter case, a TLS + server_key_exchange handshake message MUST also be included to allow + the key exchange to take place. + + The certificate_request message is included when the server desires + the client to authenticate itself via public key. While the EAP + server SHOULD require client authentication, this is not a + requirement, since it may be possible that the server will require + that the peer authenticate via some other means. + + The peer MUST respond to the EAP-Request with an EAP-Response packet + of EAP-Type=EAP-TLS. The data field of this packet will encapsulate + one or more TLS records containing a TLS change_cipher_spec message + and finished handshake message, and possibly certificate, + certificate_verify and/or client_key_exchange handshake messages. If + the preceding server_hello message sent by the EAP server in the + preceding EAP-Request packet indicated the resumption of a previous + session, then the peer MUST send only the change_cipher_spec and + finished handshake messages. The finished message contains the + peer's authentication response to the EAP server. + + If the preceding server_hello message sent by the EAP server in the + preceeding EAP-Request packet did not indicate the resumption of a + previous session, then the peer MUST send, in addition to the + change_cipher_spec and finished messages, a client_key_exchange + message, which completes the exchange of a shared master secret + between the peer and the EAP server. If the EAP server sent a + certificate_request message in the preceding EAP-Request packet, then + the peer MUST send, in addition, certificate and certificate_verify + handshake messages. The former contains a certificate for the peer's + signature public key, while the latter contains the peer's signed + authentication response to the EAP server. After receiving this + packet, the EAP server will verify the peer's certificate and digital + signature, if requested. + + + + + +Aboba & Simon Experimental [Page 4] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + If the peer's authentication is unsuccessful, the EAP server SHOULD + send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS + record containing the appropriate TLS alert message. The EAP server + SHOULD send a TLS alert message rather immediately terminating the + conversation so as to allow the peer to inform the user of the cause + of the failure and possibly allow for a restart of the conversation. + + To ensure that the peer receives the TLS alert message, the EAP + server MUST wait for the peer to reply with an EAP-Response packet. + The EAP-Response packet sent by the peer MAY encapsulate a TLS + client_hello handshake message, in which case the EAP server MAY + allow the EAP-TLS conversation to be restarted, or it MAY contain an + EAP-Response packet with EAP-Type=EAP-TLS and no data, in which case + the EAP-Server MUST send an EAP-Failure packet, and terminate the + conversation. It is up to the EAP server whether to allow restarts, + and if so, how many times the conversation can be restarted. An EAP + Server implementing restart capability SHOULD impose a limit on the + number of restarts, so as to protect against denial of service + attacks. + + If the peers authenticates successfully, the EAP server MUST respond + with an EAP-Request packet with EAP-Type=EAP-TLS, which includes, in + the case of a new TLS session, one or more TLS records containing TLS + change_cipher_spec and finished handshke messages. The latter + contains the EAP server's authentication response to the peer. The + peer will then verify the hash in order to authenticate the EAP + server. + + If the EAP server authenticates unsuccessfully, the peer MAY send an + EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert + message identifying the reason for the failed authentication. The + peer MAY send a TLS alert message rather than immediately terminating + the conversation so as to allow the EAP server to log the cause of + the error for examination by the system administrator. + + To ensure that the EAP Server receives the TLS alert message, the + peer MUST wait for the EAP-Server to reply before terminating the + conversation. The EAP Server MUST reply with an EAP-Failure packet + since server authentication failure is a terminal condition. + + If the EAP server authenticates successfully, the peer MUST send an + EAP-Response packet of EAP-Type=EAP-TLS, and no data. The EAP-Server + then MUST respond with an EAP-Success message. + + + + + + + + +Aboba & Simon Experimental [Page 5] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + +3.2. Retry behavior + + As with other EAP protocols, the EAP server is responsible for retry + behavior. This means that if the EAP server does not receive a reply + from the peer, it MUST resend the EAP-Request for which it has not + yet received an EAP-Response. However, the peer MUST NOT resend EAP- + Response packets without first being prompted by the EAP server. + + For example, if the initial EAP-TLS start packet sent by the EAP + server were to be lost, then the peer would not receive this packet, + and would not respond to it. As a result, the EAP-TLS start packet + would be resent by the EAP server. Once the peer received the EAP-TLS + start packet, it would send an EAP-Response encapsulating the + client_hello message. If the EAP-Response were to be lost, then the + EAP server would resend the initial EAP-TLS start, and the peer would + resend the EAP-Response. + + As a result, it is possible that a peer will receive duplicate EAP- + Request messages, and may send duplicate EAP-Responses. Both the + peer and the EAP-Server should be engineered to handle this + possibility. + +3.3. Fragmentation + + A single TLS record may be up to 16384 octets in length, but a TLS + message may span multiple TLS records, and a TLS certificate message + may in principle be as long as 16MB. The group of EAP-TLS messages + sent in a single round may thus be larger than the PPP MTU size, the + maximum RADIUS packet size of 4096 octets, or even the Multilink + Maximum Received Reconstructed Unit (MRRU). As described in [2], the + multilink MRRU is negotiated via the Multilink MRRU LCP option, which + includes an MRRU length field of two octets, and thus can support + MRRUs as large as 64 KB. + + However, note that in order to protect against reassembly lockup and + denial of service attacks, it may be desirable for an implementation + to set a maximum size for one such group of TLS messages. Since a + typical certificate chain is rarely longer than a few thousand + octets, and no other field is likely to be anwhere near as long, a + reasonable choice of maximum acceptable message length might be 64 + KB. + + If this value is chosen, then fragmentation can be handled via the + multilink PPP fragmentation mechanisms described in [2]. While this + is desirable, there may be cases in which multilink or the MRRU LCP + option cannot be negotiated. As a result, an EAP-TLS implementation + MUST provide its own support for fragmentation and reassembly. + + + + +Aboba & Simon Experimental [Page 6] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + Since EAP is a simple ACK-NAK protocol, fragmentation support can be + added in a simple manner. In EAP, fragments that are lost or damaged + in transit will be retransmitted, and since sequencing information is + provided by the Identifier field in EAP, there is no need for a + fragment offset field as is provided in IPv4. + + EAP-TLS fragmentation support is provided through addition of a flags + octet within the EAP-Response and EAP-Request packets, as well as a + TLS Message Length field of four octets. Flags include the Length + included (L), More fragments (M), and EAP-TLS Start (S) bits. The L + flag is set to indicate the presence of the four octet TLS Message + Length field, and MUST be set for the first fragment of a fragmented + TLS message or set of messages. The M flag is set on all but the last + fragment. The S flag is set only within the EAP-TLS start message + sent from the EAP server to the peer. The TLS Message Length field is + four octets, and provides the total length of the TLS message or set + of messages that is being fragmented; this simplifies buffer + allocation. + + When an EAP-TLS peer receives an EAP-Request packet with the M bit + set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and + no data. This serves as a fragment ACK. The EAP server MUST wait + until it receives the EAP-Response before sending another fragment. + In order to prevent errors in processing of fragments, the EAP server + MUST increment the Identifier field for each fragment contained + within an EAP-Request, and the peer MUST include this Identifier + value in the fragment ACK contained within the EAP-Reponse. + Retransmitted fragments will contain the same Identifier value. + + Similarly, when the EAP server receives an EAP-Response with the M + bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-TLS + and no data. This serves as a fragment ACK. The EAP peer MUST wait + until it receives the EAP-Request before sending another fragment. + In order to prevent errors in the processing of fragments, the EAP + server MUST use increment the Identifier value for each fragment ACK + contained within an EAP-Request, and the peer MUST include this + Identifier value in the subsequent fragment contained within an EAP- + Reponse. + +3.4. Identity verification + + As part of the TLS negotiation, the server presents a certificate to + the peer, and if mutual authentication is requested, the peer + presents a certificate to the server. + + Note that since the peer has made a claim of identity in the EAP- + Response/Identity (MyID) packet, the EAP server SHOULD verify that + the claimed identity corresponds to the certificate presented by the + + + +Aboba & Simon Experimental [Page 7] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + peer. Typically this will be accomplished either by placing the + userId within the peer certificate, or by providing a mapping between + the peer certificate and the userId using a directory service. + + Similarly, the peer MUST verify the validity of the EAP server + certificate, and SHOULD also examine the EAP server name presented in + the certificate, in order to determine whether the EAP server can be + trusted. Please note that in the case where the EAP authentication is + remoted that the EAP server will not reside on the same machine as + the authenticator, and therefore the name in the EAP server's + certificate cannot be expected to match that of the intended + destination. In this case, a more appropriate test might be whether + the EAP server's certificate is signed by a CA controlling the + intended destination and whether the EAP server exists within a + target sub-domain. + +3.5. Key derivation + + Since the normal TLS keys are used in the handshake, and therefore + should not be used in a different context, new encryption keys must + be derived from the TLS master secret for use with PPP encryption. + For both peer and EAP server, the derivation proceeds as follows: + given the master secret negotiated by the TLS handshake, the + pseudorandom function (PRF) defined in the specification for the + version of TLS in use, and the value random defined as the + concatenation of the handshake message fields client_hello.random and + server_hello.random (in that order), the value PRF(master secret, + "client EAP encryption", random) is computed up to 128 bytes, and the + value PRF("", "client EAP encryption", random) is computed up to 64 + bytes (where "" is an empty string). The peer encryption key (the + one used for encrypting data from peer to EAP server) is obtained by + truncating to the correct length the first 32 bytes of the first PRF + of these two output strings. TheEAP server encryption key (the one + used for encrypting data from EAP server to peer), if different from + the client encryption key, is obtained by truncating to the correct + length the second 32 bytes of this same PRF output string. The + client authentication key (the one used for computing MACs for + messages from peer to EAP server), if used, is obtained by truncating + to the correct length the third 32 bytes of this same PRF output + string. The EAP server authentication key (the one used for + computing MACs for messages from EAP server to peer), if used, and if + different from the peer authentication key, is obtained by truncating + to the correct length the fourth 32 bytes of this same PRF output + string. The peer initialization vector (IV), used for messages from + peer to EAP server if a block cipher has been specified, is obtained + by truncating to the cipher's block size the first 32 bytes of the + second PRF output string mentioned above. Finally, the server + initialization vector (IV), used for messages from peer to EAP server + + + +Aboba & Simon Experimental [Page 8] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + if a block cipher has been specified, is obtained by truncating to + the cipher's block size the second 32 bytes of this second PRF + output. + + The use of these encryption and authentication keys is specific to + the PPP encryption mechanism used, such as those defined in [9] and + [10]. Additional keys or other non-secret values (such as IVs) can + be obtained as needed for future PPP encryption methods by extending + the outputs of the PRF beyond 128 bytes and 64 bytes, respectively. + +3.6. ECP negotiation + + Since TLS supports ciphersuite negotiation, peers completing the TLS + negotiation will also have selected a ciphersuite, which includes key + strength, encryption and hashing methods. As a result, a subsequent + Encryption Control Protocol (ECP) conversation, if it occurs, has a + predetermined result. + + In order to ensure agreement between the EAP-TLS ciphersuite + negotiation and the subsequent ECP negotiation (described in [6]), + during ECP negotiation the PPP peer MUST offer only the ciphersuite + negotiated inEAP-TLS. This ensures that the PPP authenticator MUST + accept the EAP-TLS negotiated ciphersuite in order for the + onversation to proceed. Should the authenticator not accept the + EAP-TLS negotiated ciphersuite, then the peer MUST send an LCP + terminate and disconnect. + + Please note that it cannot be assumed that the PPP authenticator and + EAP server are located on the same machine or that the authenticator + understands the EAP-TLS conversation that has passed through it. Thus + if the peer offers a ciphersuite other than the one negotiated in + EAP-TLS there is no way for the authenticator to know how to respond + correctly. + +3.7. CCP negotiation + + TLS as described in [12] supports compression as well as ciphersuite + negotiation. However, TLS only provides support for a limited number + of compression types which do not overlap with the compression types + used in PPP. As a result, during the EAP-TLS conversation the EAP + endpoints MUST NOT request or negotiate compression. Instead, the PPP + Compression Control Protocol (CCP), described in [13] should be used + to negotiate the desired compression scheme. + + + + + + + + +Aboba & Simon Experimental [Page 9] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + +3.8. Examples + + In the case where the EAP-TLS mutual authentication is successful, + the conversation will appear as follows: + + Authenticating Peer Authenticator + ------------------- ------------- + <- PPP LCP Request-EAP + auth + PPP LCP ACK-EAP + auth -> + <- PPP EAP-Request/ + Identity + PPP EAP-Response/ + Identity (MyID) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS Start) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS client_hello)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS server_hello, + TLS certificate, + [TLS server_key_exchange,] + [TLS certificate_request,] + TLS server_hello_done) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS certificate, + TLS client_key_exchange, + [TLS certificate_verify,] + TLS change_cipher_spec, + TLS finished) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) + PPP EAP-Response/ + EAP-Type=EAP-TLS -> + <- PPP EAP-Success + PPP Authentication + Phase complete, + NCP Phase starts + + ECP negotiation + CCP negotiation + + + +Aboba & Simon Experimental [Page 10] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + In the case where the EAP-TLS mutual authentication is successful, + and fragmentation is required, the conversation will appear as + follows: + + Authenticating Peer Authenticator + ------------------- ------------- + <- PPP LCP Request-EAP + auth + PPP LCP ACK-EAP + auth -> + <- PPP EAP-Request/ + Identity + PPP EAP-Response/ + Identity (MyID) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS Start, S bit set) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS client_hello)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS server_hello, + TLS certificate, + [TLS server_key_exchange,] + [TLS certificate_request,] + TLS server_hello_done) + (Fragment 1: L, M bits set) + PPP EAP-Response/ + EAP-Type=EAP-TLS -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (Fragment 2: M bit set) + PPP EAP-Response/ + EAP-Type=EAP-TLS -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (Fragment 3) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS certificate, + TLS client_key_exchange, + [TLS certificate_verify,] + TLS change_cipher_spec, + TLS inished)(Fragment 1: + L, M bits set)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + + + +Aboba & Simon Experimental [Page 11] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + PPP EAP-Response/ + EAP-Type=EAP-TLS + (Fragment 2)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) + PPP EAP-Response/ + EAP-Type=EAP-TLS -> + <- PPP EAP-Success + PPP Authentication + Phase complete, + NCP Phase starts + + ECP negotiation + CCP negotiation + + In the case where the server authenticates to the client + successfully, but the client fails to authenticate to the server, the + conversation will appear as follows: + + Authenticating Peer Authenticator + ------------------- ------------- + <- PPP LCP Request-EAP + auth + PPP LCP ACK-EAP + auth -> + <- PPP EAP-Request/ + Identity + PPP EAP-Response/ + Identity (MyID) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS Start) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS client_hello)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS server_hello, + TLS certificate, + [TLS server_key_exchange,] + TLS certificate_request, + TLS server_hello_done) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS certificate, + TLS client_key_exchange, + + + +Aboba & Simon Experimental [Page 12] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + TLS certificate_verify, + TLS change_cipher_spec, + TLS finished) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) + PPP EAP-Response/ + EAP-Type=EAP-TLS -> + <- PPP EAP-Request + EAP-Type=EAP-TLS + (TLS Alert message) + PPP EAP-Response/ + EAP-Type=EAP-TLS -> + <- PPP EAP-Failure + (User Disconnected) + + In the case where server authentication is unsuccessful, the + conversation will appear as follows: + + Authenticating Peer Authenticator + ------------------- ------------- + <- PPP LCP Request-EAP + auth + PPP LCP ACK-EAP + auth -> + <- PPP EAP-Request/ + Identity + PPP EAP-Response/ + Identity (MyID) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS Start) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS client_hello)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS server_hello, + TLS certificate, + [TLS server_key_exchange,] + [TLS certificate_request,] + TLS server_hello_done) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS certificate, + TLS client_key_exchange, + [TLS certificate_verify,] + + + +Aboba & Simon Experimental [Page 13] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + TLS change_cipher_spec, + TLS finished) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS Alert message) -> + <- PPP EAP-Failure + (User Disconnected) + + In the case where a previously established session is being resumed, + and both sides authenticate successfully, the conversation will + appear as follows: + + Authenticating Peer Authenticator + ------------------- ------------- + <- PPP LCP Request-EAP + auth + PPP LCP ACK-EAP + auth -> + <- PPP EAP-Request/ + Identity + PPP EAP-Response/ + Identity (MyID) -> + <- PPP EAP-Request/ + EAP-Request/ + EAP-Type=EAP-TLS + (TLS Start) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS client_hello)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS server_hello, + TLS change_cipher_spec + TLS finished) + + + + + + + +Aboba & Simon Experimental [Page 14] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) -> + <- PPP EAP-Success + PPP Authentication + Phase complete, + NCP Phase starts + + ECP negotiation + + CCP negotiation + + In the case where a previously established session is being resumed, + and the server authenticates to the client successfully but the + client fails to authenticate to the server, the conversation will + appear as follows: + + Authenticating Peer Authenticator + ------------------- ------------- + <- PPP LCP Request-EAP + auth + PPP LCP ACK-EAP + auth -> + <- PPP EAP-Request/ + Identity + PPP EAP-Response/ + Identity (MyID) -> + <- PPP EAP-Request/ + EAP-Request/ + EAP-Type=EAP-TLS + (TLS Start) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS client_hello) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS server_hello, + TLS change_cipher_spec, + TLS finished) + PPP EA-Response/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) -> + <- PPP EAP-Request + EAP-Type=EAP-TLS + (TLS Alert message) + + + + +Aboba & Simon Experimental [Page 15] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + PPP EAP-Response + EAP-Type=EAP-TLS -> + <- PPP EAP-Failure + (User Disconnected) + + In the case where a previously established session is being resumed, + and the server authentication is unsuccessful, the conversation will + appear as follows: + + Authenticating Peer Authenticator + ------------------- ------------- + <- PPP LCP Request-EAP + auth + PPP LCP ACK-EAP + auth -> + <- PPP EAP-Request/ + Identity + PPP EAP-Response/ + Identity (MyID) -> + <- PPP EAP-Request/ + EAP-Request/ + EAP-Type=EAP-TLS + (TLS Start) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS client_hello)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS server_hello, + TLS change_cipher_spec, + TLS finished) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS Alert message) -> + <- PPP EAP-Failure + (User Disconnected) + + + + + + + + + +Aboba & Simon Experimental [Page 16] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + +4. Detailed description of the EAP-TLS protocol + +4.1. PPP EAP TLS Packet Format + + A summary of the PPP EAP TLS Request/Response packet format is shown + below. The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Data... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 1 - Request + 2 - Response + + Identifier + + The identifier field is one octet and aids in matching responses + with requests. + + Length + + The Length field is two octets and indicates the length of the EAP + packet including the Code, Identifier, Length, Type, and Data + fields. Octets outside the range of the Length field should be + treated as Data Link Layer padding and should be ignored on + reception. + + Type + + 13 - EAP TLS + + Data + + The format of the Data field is determined by the Code field. + + + + + + + + + + + +Aboba & Simon Experimental [Page 17] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + +4.2. PPP EAP TLS Request Packet + + A summary of the PPP EAP TLS Request packet format is shown below. + The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Flags | TLS Message Length + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TLS Message Length | TLS Data... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 1 + + Identifier + + The Identifier field is one octet and aids in matching responses + with requests. The Identifier field MUST be changed on each + Request packet. + + Length + + The Length field is two octets and indicates the length of the EAP + packet including the Code, Identifier, Length, Type, and TLS + Response fields. + + Type + + 13 - EAP TLS + + Flags + + 0 1 2 3 4 5 6 7 8 + +-+-+-+-+-+-+-+-+ + |L M S R R R R R| + +-+-+-+-+-+-+-+-+ + + L = Length included + M = More fragments + S = EAP-TLS start + R = Reserved + + + + + +Aboba & Simon Experimental [Page 18] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + The L bit (length included) is set to indicate the presence of the + four octet TLS Message Length field, and MUST be set for the first + fragment of a fragmented TLS message or set of messages. The M bit + (more fragments) is set on all but the last fragment. The S bit + (EAP-TLS start) is set in an EAP-TLS Start message. This + differentiates the EAP-TLS Start message from a fragment + acknowledgement. + + TLS Message Length + + The TLS Message Length field is four octets, and is present only + if the L bit is set. This field provides the total length of the + TLS message or set of messages that is being fragmented. + + TLS data + + The TLS data consists of the encapsulated TLS packet in TLS record + format. + +4.3. PPP EAP TLS Response Packet + + A summary of the PPP EAP TLS Response packet format is shown below. + The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Flags | TLS Message Length + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TLS Message Length | TLS Data... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 2 + + Identifier + + The Identifier field is one octet and MUST match the Identifier + field from the corresponding request. + + Length + + The Length field is two octets and indicates the length of the EAP + packet including the Code, Identifir, Length, Type, and TLS data + fields. + + + +Aboba & Simon Experimental [Page 19] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + Type + + 13 - EAP TLS + + Flags + + 0 1 2 3 4 5 6 7 8 + +-+-+-+-+-+-+-+-+ + |L M S R R R R R| + +-+-+-+-+-+-+-+-+ + + L = Length included + M = More fragments + S = EAP-TLS start + R = Reserved + + The L bit (length included) is set to indicate the presence of the + four octet TLS Message Length field, and MUST be set for the first + fragment of a fragmented TLS message or set of messages. The M bit + (more fragments) is set on all but the last fragment. The S bit + (EAP-TLS start) is set in an EAP-TLS Start message. This + differentiates the EAP-TLS Start message from a fragment + acknowledgement. + + TLS Message Length + + The TLS Message Length field is four octets, and is present only + if the L bit is set. This field provides the total length of the + TLS message or set of messages that is being fragmented. + + TLS data + + The TLS data consists of the encapsulated TLS packet in TLS record + format. + + + + + + + + + + + + + + + + + +Aboba & Simon Experimental [Page 20] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + +5. References + + [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + [2] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, + "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. + + [3] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January + 1994. + + [4] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC + 1321, April 1992. + + [5] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication + Protocol (EAP)", RFC 2284, March 1998. + + [6] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June + 1996. + + [7] National Bureau of Standards, "Data Encryption Standard", FIPS + PUB 46 (January 1977). + + [8] National Bureau of Standards, "DES Modes of Operation", FIPS PUB + 81 (December 1980). + + [9] Sklower, K. amd G. Meyer, "The PPP DES Encryption Protocol, + Version 2 (DESE-bis)", RFC 2419, September 1998. + + [10] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", + RFC 2420, September 1998. + + [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC + 2246, November 1998. + + [13] Rand, D., "The PPP Compression Control Protocol", RFC 1962, June + 1996. + + + + + + + + + + + +Aboba & Simon Experimental [Page 21] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + +6. Security Considerations + +6.1. Certificate revocation + + Since the EAP server is on the Internet during the EAP conversation, + the server is capable of following a certificate chain or verifying + whether the peer's certificate has been revoked. In contrast, the + peer may or may not have Internet connectivity, and thus while it can + validate the EAP server's certificate based on a pre-configured set + of CAs, it may not be able to follow a certificate chain or verify + whether the EAP server's certificate has been revoked. + + In the case where the peer is initiating a voluntary Layer 2 tunnel + using PPTP or L2TP, the peer will typically already have a PPP + interface and Internet connectivity established at the time of tunnel + initiation. As a result, during the EAP conversation it is capable + of checking for certificate revocation. + + However, in the case where the peer is initiating an intial PPP + conversation, it will not have Internet connectivity and is therefore + not capable of checking for certificate revocation until after NCP + negotiation completes and the peer has access to the Internet. In + this case, the peer SHOULD check for certificate revocation after + connecting to the Internet. + +6.2. Separation of the EAP server and PPP authenticator + + As a result of the EAP-TLS conversation, the EAP endpoints will + mutually authenticate, negotiate a ciphersuite, and derive a session + key for subsequent use in PPP encryption. Since the peer and EAP + client reside on the same machine, it is necessary for the EAP client + module to pass the session key to the PPP encryption module. + + The situation may be more complex on the PPP authenticator, which may + or may not reside on the same machine as the EAP server. In the case + where the EAP server and PPP authenticator reside on different + machines, there are several implications for security. Firstly, the + mutual authentication defined in EAP-TLS will occur between the peer + and the EAP server, not between the peer and the authenticator. This + means that as a result of the EAP-TLS conversation, it is not + possible for the peer to validate the identity of the NAS or tunnel + server that it is speaking to. + + The second issue is that the session key negotiated between the peer + and EAP server will need to be transmitted to the authenticator. + Therefore a mechanism needs to be provided to transmit the session + key from the EAP server to the authenticator or tunnel server that + needs to use the key. The specification of this transit mechanism is + + + +Aboba & Simon Experimental [Page 22] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + outside the scope of this document. + +6.3. Relationship of PPP encryption to other security mechanisms + + It is envisaged that EAP-TLS will be used primarily with dialup PPP + connections. However, there are also circumstances in which PPP + encryption may be used along with Layer 2 tunneling protocols such as + PPTP and L2TP. + + In compulsory layer 2 tunneling, a PPP peer makes a connection to a + NAS or router which tunnels the PPP packets to a tunnel server. + Since with compulsory tunneling a PPP peer cannot tell whether its + packets are being tunneled, let alone whether the network device is + securing the tunnel, if security is required then the client must + make its own arrangements. In the case where all endpoints cannot be + relied upon to implement IPSEC, TLS, or another suitable security + protocol, PPP encryption provides a convenient means to ensure the + privacy of packets transiting between the client and the tunnel + server. + +7. Acknowledgments + + Thanks to Terence Spies, Glen Zorn and Narendra Gidwani of Microsoft + for useful discussions of this problem space. + +8. Authors' Addresses + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: 425-936-6605 + EMail: bernarda@microsoft.com + + + Dan Simon + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: 425-936-6711 + EMail: dansimon@microsoft.com + + + + + + + + +Aboba & Simon Experimental [Page 23] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Aboba & Simon Experimental [Page 24] + diff --git a/rfc/rfc2759.txt b/rfc/rfc2759.txt new file mode 100644 index 00000000..60371c42 --- /dev/null +++ b/rfc/rfc2759.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group G. Zorn +Request for Comments: 2759 Microsoft Corporation +Category: Informational January 2000 + + + Microsoft PPP CHAP Extensions, Version 2 + + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method for + transporting multi-protocol datagrams over point-to-point links. PPP + defines an extensible Link Control Protocol and a family of Network + Control Protocols (NCPs) for establishing and configuring different + network-layer protocols. + + This document describes version two of Microsoft's PPP CHAP dialect + (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS- + CHAP version one (MS-CHAP-V1, described in [9]). In particular, + certain protocol fields have been deleted or reused but with + different semantics. In addition, MS-CHAP-V2 features mutual + authentication. + + The algorithms used in the generation of various MS-CHAP-V2 protocol + fields are described in section 8. Negotiation and hash generation + examples are provided in section 9. + +Specification of Requirements + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as + described in [3]. + + + + + + + + + +Zorn Informational [Page 1] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. LCP Configuration . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Challenge Packet . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Response Packet . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. Success Packet . . . . . . . . . . . . . . . . . . . . . . . . 4 + 6. Failure Packet . . . . . . . . . . . . . . . . . . . . . . . . 5 + 7. Change-Password Packet . . . . . . . . . . . . . . . . . . . . 6 + 8. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 8.1. GenerateNTResponse() . . . . . . . . . . . . . . . . . . . . 7 + 8.2. ChallengeHash() . . . . . . . . . . . . . . . . . . . . . . . 8 + 8.3. NtPasswordHash() . . . . . . . . . . . . . . . . . . . . . . 9 + 8.4. HashNtPasswordHash() . . . . . . . . . . . . . . . . . . . . 9 + 8.5. ChallengeResponse() . . . . . . . . . . . . . . . . . . . . . 9 + 8.6. DesEncrypt() . . . . . . . . . . . . . . . . . . . . . . . . 10 + 8.7. GenerateAuthenticatorResponse() . . . . . . . . . . . . . . . 10 + 8.8. CheckAuthenticatorResponse() . . . . . . . . . . . . . . . . 12 + 8.9. NewPasswordEncryptedWithOldNtPasswordHash() . . . . . . . . . 12 + 8.10. EncryptPwBlockWithPasswordHash() . . . . . . . . . . . . . . 13 + 8.11. Rc4Encrypt() . . . . . . . . . . . . . . . . . . . . . . . . 13 + 8.12. OldNtPasswordHashEncryptedWithNewNtPasswordHash() . . . . . 14 + 8.13. NtPasswordHashEncryptedWithBlock() . . . . . . . . . . . . . 14 + 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 9.1. Negotiation Examples . . . . . . . . . . . . . . . . . . . . 14 + 9.1.1. Successful authentication . . . . . . . . . . . . . . . . . 15 + 9.1.2. Authenticator authentication failure . . . . . . . . . . . 15 + 9.1.3. Failed authentication with no retry allowed . . . . . . . . 15 + 9.1.4. Successful authentication after retry . . . . . . . . . . . 15 + 9.1.5. Failed hack attack with 3 attempts allowed . . . . . . . . 15 + 9.1.6. Successful authentication with password change . . . . . . 16 + 9.1.7. Successful authentication with retry and password change. . 16 + 9.2. Hash Example . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9.3. Example of DES Key Generation . . . . . . . . . . . . . . . . 17 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 + 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 + 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20 + + + + + + + + + + + + +Zorn Informational [Page 2] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +1. Introduction + + Where possible, MS-CHAP-V2 is consistent with both MS-CHAP-V1 and + standard CHAP. Briefly, the differences between MS-CHAP-V2 and MS- + CHAP-V1 are: + + * MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP + option 3, Authentication Protocol. + + * MS-CHAP-V2 provides mutual authentication between peers by + piggybacking a peer challenge on the Response packet and an + authenticator response on the Success packet. + + * The calculation of the "Windows NT compatible challenge response" + sub-field in the Response packet has been changed to include the + peer challenge and the user name. + + * In MS-CHAP-V1, the "LAN Manager compatible challenge response" + sub-field was always sent in the Response packet. This field has + been replaced in MS-CHAP-V2 by the Peer-Challenge field. + + * The format of the Message field in the Failure packet has been + changed. + + * The Change Password (version 1) and Change Password (version 2) + packets are no longer supported. They have been replaced with a + single Change-Password packet. + +2. LCP Configuration + + The LCP configuration for MS-CHAP-V2 is identical to that for + standard CHAP, except that the Algorithm field has value 0x81, rather + than the MD5 value 0x05. PPP implementations which do not support + MS-CHAP-V2, but correctly implement LCP Config-Rej, should have no + problem dealing with this non-standard option. + +3. Challenge Packet + + The MS-CHAP-V2 Challenge packet is identical in format to the + standard CHAP Challenge packet. + + MS-CHAP-V2 authenticators send an 16-octet challenge Value field. + Peers need not duplicate Microsoft's algorithm for selecting the 16- + octet value, but the standard guidelines on randomness [1,2,7] SHOULD + be observed. + + Microsoft authenticators do not currently provide information in the + Name field. This may change in the future. + + + +Zorn Informational [Page 3] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +4. Response Packet + + The MS-CHAP-V2 Response packet is identical in format to the standard + CHAP Response packet. However, the Value field is sub-formatted + differently as follows: + + 16 octets: Peer-Challenge + 8 octets: Reserved, must be zero + 24 octets: NT-Response + 1 octet : Flags + + The Peer-Challenge field is a 16-octet random number. As the name + implies, it is generated by the peer and is used in the calculation + of the NT-Response field, below. Peers need not duplicate + Microsoft's algorithm for selecting the 16-octet value, but the + standard guidelines on randomness [1,2,7] SHOULD be observed. + + The NT-Response field is an encoded function of the password, the + user name, the contents of the Peer-Challenge field and the received + challenge as output by the routine GenerateNTResponse() (see section + 8.1, below). The Windows NT password is a string of 0 to + (theoretically) 256 case-sensitive Unicode [8] characters. Current + versions of Windows NT limit passwords to 14 characters, mainly for + compatibility reasons; this may change in the future. When computing + the NT-Response field contents, only the user name is used, without + any associated Windows NT domain name. This is true regardless of + whether a Windows NT domain name is present in the Name field (see + below). + + The Flag field is reserved for future use and MUST be zero. + + The Name field is a string of 0 to (theoretically) 256 case-sensitive + ASCII characters which identifies the peer's user account name. The + Windows NT domain name may prefix the user's account name (e.g. + "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the + user account "johndoe"). If a domain is not provided, the backslash + should also be omitted, (e.g. "johndoe"). + +5. Success Packet + + The Success packet is identical in format to the standard CHAP + Success packet. However, the Message field contains a 42-octet + authenticator response string and a printable message. The format of + the message field is illustrated below. + + "S=<auth_string> M=<message>" + + + + + +Zorn Informational [Page 4] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + + The <auth_string> quantity is a 20 octet number encoded in ASCII as + 40 hexadecimal digits. The hexadecimal digits A-F (if present) MUST + be uppercase. This number is derived from the challenge from the + Challenge packet, the Peer-Challenge and NT-Response fields from the + Response packet, and the peer password as output by the routine + GenerateAuthenticatorResponse() (see section 8.7, below). The + authenticating peer MUST verify the authenticator response when a + Success packet is received. The method for verifying the + authenticator is described in section 8.8, below. If the + authenticator response is either missing or incorrect, the peer MUST + end the session. + + The <message> quantity is human-readable text in the appropriate + charset and language [12]. + +6. Failure Packet + + The Failure packet is identical in format to the standard CHAP + Failure packet. There is, however, formatted text stored in the + Message field which, contrary to the standard CHAP rules, does affect + the operation of the protocol. The Message field format is: + + "E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv +M=<msg>" + + where + + The "eeeeeeeeee" is the ASCII representation of a decimal error + code (need not be 10 digits) corresponding to one of those listed + below, though implementations should deal with codes not on this + list gracefully. + + 646 ERROR_RESTRICTED_LOGON_HOURS + 647 ERROR_ACCT_DISABLED + 648 ERROR_PASSWD_EXPIRED + 649 ERROR_NO_DIALIN_PERMISSION + 691 ERROR_AUTHENTICATION_FAILURE + 709 ERROR_CHANGING_PASSWORD + + The "r" is an ASCII flag set to '1' if a retry is allowed, and '0' + if not. When the authenticator sets this flag to '1' it disables + short timeouts, expecting the peer to prompt the user for new + credentials and resubmit the response. + + The "cccccccccccccccccccccccccccccccc" is the ASCII representation + of a hexadecimal challenge value. This field MUST be exactly 32 + octets long and MUST be present. + + + + +Zorn Informational [Page 5] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + + The "vvvvvvvvvv" is the ASCII representation of a decimal version + code (need not be 10 digits) indicating the password changing + protocol version supported on the server. For MS-CHAP-V2, this + value SHOULD always be 3. + + <msg> is human-readable text in the appropriate charset and + language [12]. + +7. Change-Password Packet + + The Change-Password packet does not appear in either standard CHAP or + MS-CHAP-V1. It allows the peer to change the password on the account + specified in the preceding Response packet. The Change-Password + packet should be sent only if the authenticator reports + ERROR_PASSWD_EXPIRED (E=648) in the Message field of the Failure + packet. + + This packet type is supported by recent versions of Windows NT 4.0, + Windows 95 and Windows 98. It is not supported by Windows NT 3.5, + Windows NT 3.51, or early versions of Windows NT 4.0, Windows 95 and + Windows 98. + + The format of this packet is as follows: + + 1 octet : Code + 1 octet : Identifier + 2 octets : Length + 516 octets : Encrypted-Password + 16 octets : Encrypted-Hash + 16 octets : Peer-Challenge + 8 octets : Reserved + 24 octets : NT-Response + 2-octet : Flags + + Code + 7 + + Identifier + The Identifier field is one octet and aids in matching requests + and replies. The value is the Identifier of the received Failure + packet to which this packet responds plus 1. + + Length + 586 + + + + + + + +Zorn Informational [Page 6] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + + Encrypted-Password + This field contains the PWBLOCK form of the new Windows NT + password encrypted with the old Windows NT password hash, as + output by the NewPasswordEncryptedWithOldNtPasswordHash() routine + (see section 8.9, below). + + Encrypted-Hash + This field contains the old Windows NT password hash encrypted + with the new Windows NT password hash, as output by the + OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (see + section 8.12, below). + + Peer-Challenge + A 16-octet random quantity, as described in the Response packet + description. + + Reserved + 8 octets, must be zero. + + NT-Response + The NT-Response field (as described in the Response packet + description), but calculated on the new password and the challenge + received in the Failure packet. + + Flags + This field is two octets in length. It is a bit field of option + flags where 0 is the least significant bit of the 16-bit quantity. + The format of this field is illustrated in the following diagram: + + 1 + 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Bits 0-15 + Reserved, always clear (0). + +8. Pseudocode + + The routines mentioned in the text above are described in pseudocode + in the following sections. + +8.1. GenerateNTResponse() + + GenerateNTResponse( + IN 16-octet AuthenticatorChallenge, + IN 16-octet PeerChallenge, + + + +Zorn Informational [Page 7] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + + IN 0-to-256-char UserName, + + IN 0-to-256-unicode-char Password, + OUT 24-octet Response ) + { + 8-octet Challenge + 16-octet PasswordHash + + ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, + giving Challenge) + + NtPasswordHash( Password, giving PasswordHash ) + ChallengeResponse( Challenge, PasswordHash, giving Response ) + } + +8.2. ChallengeHash() + + ChallengeHash( + IN 16-octet PeerChallenge, + IN 16-octet AuthenticatorChallenge, + IN 0-to-256-char UserName, + OUT 8-octet Challenge + { + + /* + * SHAInit(), SHAUpdate() and SHAFinal() functions are an + * implementation of Secure Hash Algorithm (SHA-1) [11]. These are + * available in public domain or can be licensed from + * RSA Data Security, Inc. + */ + + SHAInit(Context) + SHAUpdate(Context, PeerChallenge, 16) + SHAUpdate(Context, AuthenticatorChallenge, 16) + + /* + * Only the user name (as presented by the peer and + * excluding any prepended domain name) + * is used as input to SHAUpdate(). + */ + + SHAUpdate(Context, UserName, strlen(Username)) + SHAFinal(Context, Digest) + memcpy(Challenge, Digest, 8) + } + + + + + + +Zorn Informational [Page 8] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +8.3. NtPasswordHash() + + NtPasswordHash( + IN 0-to-256-unicode-char Password, + OUT 16-octet PasswordHash ) + { + /* + * Use the MD4 algorithm [5] to irreversibly hash Password + * into PasswordHash. Only the password is hashed without + * including any terminating 0. + */ + } + +8.4. HashNtPasswordHash() + + HashNtPasswordHash( + IN 16-octet PasswordHash, + OUT 16-octet PasswordHashHash ) + { + /* + * Use the MD4 algorithm [5] to irreversibly hash + * PasswordHash into PasswordHashHash. + */ + } + +8.5. ChallengeResponse() + + ChallengeResponse( + IN 8-octet Challenge, + IN 16-octet PasswordHash, + OUT 24-octet Response ) + { + Set ZPasswordHash to PasswordHash zero-padded to 21 octets + + DesEncrypt( Challenge, + 1st 7-octets of ZPasswordHash, + giving 1st 8-octets of Response ) + + DesEncrypt( Challenge, + 2nd 7-octets of ZPasswordHash, + giving 2nd 8-octets of Response ) + + DesEncrypt( Challenge, + 3rd 7-octets of ZPasswordHash, + giving 3rd 8-octets of Response ) + } + + + + + +Zorn Informational [Page 9] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +8.6. DesEncrypt() + + DesEncrypt( + IN 8-octet Clear, + IN 7-octet Key, + OUT 8-octet Cypher ) + { + /* + * Use the DES encryption algorithm [4] in ECB mode [10] + * to encrypt Clear into Cypher such that Cypher can + * only be decrypted back to Clear by providing Key. + * Note that the DES algorithm takes as input a 64-bit + * stream where the 8th, 16th, 24th, etc. bits are + * parity bits ignored by the encrypting algorithm. + * Unless you write your own DES to accept 56-bit input + * without parity, you will need to insert the parity bits + * yourself. + */ + } + +8.7. GenerateAuthenticatorResponse() + + GenerateAuthenticatorResponse( + IN 0-to-256-unicode-char Password, + IN 24-octet NT-Response, + IN 16-octet PeerChallenge, + IN 16-octet AuthenticatorChallenge, + IN 0-to-256-char UserName, + OUT 42-octet AuthenticatorResponse ) + { + 16-octet PasswordHash + 16-octet PasswordHashHash + 8-octet Challenge + + /* + * "Magic" constants used in response generation + */ + + Magic1[39] = + {0x4D, 0x61, 0x67, 0x69, 0x63, 0x20, 0x73, 0x65, 0x72, 0x76, + 0x65, 0x72, 0x20, 0x74, 0x6F, 0x20, 0x63, 0x6C, 0x69, 0x65, + 0x6E, 0x74, 0x20, 0x73, 0x69, 0x67, 0x6E, 0x69, 0x6E, 0x67, + 0x20, 0x63, 0x6F, 0x6E, 0x73, 0x74, 0x61, 0x6E, 0x74}; + + + + + + + + +Zorn Informational [Page 10] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + + Magic2[41] = + {0x50, 0x61, 0x64, 0x20, 0x74, 0x6F, 0x20, 0x6D, 0x61, 0x6B, + 0x65, 0x20, 0x69, 0x74, 0x20, 0x64, 0x6F, 0x20, 0x6D, 0x6F, + 0x72, 0x65, 0x20, 0x74, 0x68, 0x61, 0x6E, 0x20, 0x6F, 0x6E, + 0x65, 0x20, 0x69, 0x74, 0x65, 0x72, 0x61, 0x74, 0x69, 0x6F, + 0x6E}; + + /* + * Hash the password with MD4 + */ + + NtPasswordHash( Password, giving PasswordHash ) + + /* + * Now hash the hash + */ + + HashNtPasswordHash( PasswordHash, giving PasswordHashHash) + + SHAInit(Context) + SHAUpdate(Context, PasswordHashHash, 16) + SHAUpdate(Context, NTResponse, 24) + SHAUpdate(Context, Magic1, 39) + SHAFinal(Context, Digest) + + ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, + giving Challenge) + + SHAInit(Context) + SHAUpdate(Context, Digest, 20) + SHAUpdate(Context, Challenge, 8) + SHAUpdate(Context, Magic2, 41) + SHAFinal(Context, Digest) + + /* + * Encode the value of 'Digest' as "S=" followed by + * 40 ASCII hexadecimal digits and return it in + * AuthenticatorResponse. + * For example, + * "S=0123456789ABCDEF0123456789ABCDEF01234567" + */ + + } + + + + + + + + +Zorn Informational [Page 11] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +8.8. CheckAuthenticatorResponse() + + CheckAuthenticatorResponse( + IN 0-to-256-unicode-char Password, + IN 24-octet NtResponse, + IN 16-octet PeerChallenge, + IN 16-octet AuthenticatorChallenge, + IN 0-to-256-char UserName, + IN 42-octet ReceivedResponse, + OUT Boolean ResponseOK ) + { + + 20-octet MyResponse + + set ResponseOK = FALSE + GenerateAuthenticatorResponse( Password, NtResponse, PeerChallenge, + AuthenticatorChallenge, UserName, + giving MyResponse) + + if (MyResponse = ReceivedResponse) then set ResponseOK = TRUE + return ResponseOK + } + +8.9. NewPasswordEncryptedWithOldNtPasswordHash() + + datatype-PWBLOCK + { + 256-unicode-char Password + 4-octets PasswordLength + } + + NewPasswordEncryptedWithOldNtPasswordHash( + IN 0-to-256-unicode-char NewPassword, + IN 0-to-256-unicode-char OldPassword, + OUT datatype-PWBLOCK EncryptedPwBlock ) + { + NtPasswordHash( OldPassword, giving PasswordHash ) + + EncryptPwBlockWithPasswordHash( NewPassword, + PasswordHash, + giving EncryptedPwBlock ) + } + + + + + + + + + +Zorn Informational [Page 12] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +8.10. EncryptPwBlockWithPasswordHash() + + EncryptPwBlockWithPasswordHash( + IN 0-to-256-unicode-char Password, + IN 16-octet PasswordHash, + OUT datatype-PWBLOCK PwBlock ) + { + + Fill ClearPwBlock with random octet values + + PwSize = lstrlenW( Password ) * sizeof( unicode-char ) + PwOffset = sizeof( ClearPwBlock.Password ) - PwSize + Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from + Password + ClearPwBlock.PasswordLength = PwSize + Rc4Encrypt( ClearPwBlock, + sizeof( ClearPwBlock ), + PasswordHash, + sizeof( PasswordHash ), + giving PwBlock ) + } + +8.11. Rc4Encrypt() + + Rc4Encrypt( + IN x-octet Clear, + IN integer ClearLength, + IN y-octet Key, + IN integer KeyLength, + OUT x-octet Cypher ) + { + /* + * Use the RC4 encryption algorithm [6] to encrypt Clear of + * length ClearLength octets into a Cypher of the same length + * such that the Cypher can only be decrypted back to Clear + * by providing a Key of length KeyLength octets. + */ + } + + + + + + + + + + + + + +Zorn Informational [Page 13] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +8.12. OldNtPasswordHashEncryptedWithNewNtPasswordHash() + + OldNtPasswordHashEncryptedWithNewNtPasswordHash( + IN 0-to-256-unicode-char NewPassword, + IN 0-to-256-unicode-char OldPassword, + OUT 16-octet EncryptedPasswordHash ) + { + NtPasswordHash( OldPassword, giving OldPasswordHash ) + NtPasswordHash( NewPassword, giving NewPasswordHash ) + NtPasswordHashEncryptedWithBlock( OldPasswordHash, + NewPasswordHash, + giving EncryptedPasswordHash ) + } + +8.13. NtPasswordHashEncryptedWithBlock() + + NtPasswordHashEncryptedWithBlock( + IN 16-octet PasswordHash, + IN 16-octet Block, + OUT 16-octet Cypher ) + { + DesEncrypt( 1st 8-octets PasswordHash, + 1st 7-octets Block, + giving 1st 8-octets Cypher ) + + DesEncrypt( 2nd 8-octets PasswordHash, + 2nd 7-octets Block, + giving 2nd 8-octets Cypher ) + } + +9. Examples + + The following sections include protocol negotiation and hash + generation examples. + +9.1. Negotiation Examples + + Here are some examples of typical negotiations. The peer is on the + left and the authenticator is on the right. + + The packet sequence ID is incremented on each authentication retry + response and on the change password response. All cases where the + packet sequence ID is updated are noted below. + + Response retry is never allowed after Change Password. Change + Password may occur after response retry. + + + + + +Zorn Informational [Page 14] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +9.1.1. Successful authentication + + <- Authenticator Challenge + Peer Response/Challenge -> + <- Success/Authenticator Response + + (Authenticator Response verification succeeds, call continues) + +9.1.2. Authenticator authentication failure + + <- Authenticator Challenge + Peer Response/Challenge -> + <- Success/Authenticator Response + + (Authenticator Response verification fails, peer disconnects) + +9.1.3. Failed authentication with no retry allowed + + <- Authenticator Challenge + Peer Response/Challenge -> + <- Failure (E=691 R=0) + + (Authenticator disconnects) + +9.1.4. Successful authentication after retry + + <- Authenticator Challenge + Peer Response/Challenge -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to challenge in failure message -> + <- Success/Authenticator Response + + (Authenticator Response verification succeeds, call continues) + +9.1.5. Failed hack attack with 3 attempts allowed + + <- Authenticator Challenge + Peer Response/Challenge -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to challenge in Failure message -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to challenge in Failure message -> + <- Failure (E=691 R=0) + + + + + + + + +Zorn Informational [Page 15] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +9.1.6. Successful authentication with password change + + <- Authenticator Challenge + Peer Response/Challenge -> + <- Failure (E=648 R=0 V=3), disable short + timeout + ChangePassword (++ID) to challenge in Failure message -> + <- Success/Authenticator Response + + (Authenticator Response verification succeeds, call continues) + +9.1.7. Successful authentication with retry and password change + + <- Authenticator Challenge + Peer Response/Challenge -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to first challenge+23 -> + <- Failure (E=648 R=0 V=2), disable short + timeout + ChangePassword (++ID) to first challenge+23 -> + <- Success/Authenticator Response + + (Authenticator Response verification succeeds, call continues) + +9.2. Hash Example + + Intermediate values for user name "User" and password "clientPass". + All numeric values are hexadecimal. + +0-to-256-char UserName: +55 73 65 72 + +0-to-256-unicode-char Password: +63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00 + +16-octet AuthenticatorChallenge: +5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28 + +16-octet PeerChallenge: +21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E + +8-octet Challenge: +D0 2E 43 86 BC E9 12 26 + +16-octet PasswordHash: +44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE + + + + + +Zorn Informational [Page 16] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +24 octet NT-Response: +82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF + +16-octet PasswordHashHash: +41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F + +42-octet AuthenticatorResponse: +"S=407A5589115FD0D6209F510FE9C04566932CDA56" + +9.3. Example of DES Key Generation + + DES uses 56-bit keys, expanded to 64 bits by the insertion of parity + bits. After the parity of the key has been fixed, every eighth bit + is a parity bit and the number of bits that are set (1) in each octet + is odd; i.e., odd parity. Note that many DES engines do not check + parity, however, simply stripping the parity bits. The following + example illustrates the values resulting from the use of the password + "MyPw" to generate a pair of DES keys (e.g., for use in the + NtPasswordHashEncryptedWithBlock() described in section 8.13). + + 0-to-256-unicode-char Password: + 4D 79 50 77 + + 16-octet PasswordHash: + FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC + + First "raw" DES key (initial 7 octets of password hash): + FC 15 6A F7 ED CD 6C + + First parity-corrected DES key (eight octets): + FD 0B 5B 5E 7F 6E 34 D9 + + Second "raw" DES key (second 7 octets of password hash) + 0E DD E3 33 7D 42 7F + + Second parity-corrected DES key (eight octets): + 0E 6E 79 67 37 EA 08 FE + +10. Security Considerations + + As an implementation detail, the authenticator SHOULD limit the + number of password retries allowed to make brute-force password + guessing attacks more difficult. + + + + + + + + +Zorn Informational [Page 17] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +11. References + + [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC + 1661, July 1994. + + [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol + (CHAP)", RFC 1994, August 1996. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] "Data Encryption Standard (DES)", Federal Information Processing + Standard Publication 46-2, National Institute of Standards and + Technology, December 1993. + + [5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April + 1992. + + [6] RC4 is a proprietary encryption algorithm available under + license from RSA Data Security Inc. For licensing information, + contact: + + RSA Data Security, Inc. + 100 Marine Parkway + Redwood City, CA 94065-1031 + + [7] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + + [8] "The Unicode Standard, Version 2.0", The Unicode Consortium, + Addison-Wesley, 1996. ISBN 0-201-48345-9. + + [9] Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC + 2433, October 1998. + + [10] "DES Modes of Operation", Federal Information Processing + Standards Publication 81, National Institute of Standards and + Technology, December 1980. + + [11] "Secure Hash Standard", Federal Information Processing Standards + Publication 180-1, National Institute of Standards and + Technology, April 1995. + + [12] Zorn, G., "PPP LCP Internationalization Configuration Option", + RFC 2484, January 1999. + + + + + + +Zorn Informational [Page 18] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +12. Acknowledgements + + Thanks (in no particular order) to Bruce Johnson, Tony Bell, Paul + Leach, Terence Spies, Dan Simon, Narendra Gidwani, Gurdeep Singh + Pall, Jody Terrill, Brad Robel-Forrest, and Joe Davies for useful + suggestions and feedback. + +13. Author's Address + + Questions about this memo can also be directed to: + + Glen Zorn + Microsoft Corporation + One Microsoft Way + Redmond, Washington 98052 + + Phone: +1 425 703 1559 + Fax: +1 425 936 7329 + EMail: gwz@acm.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 19] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +14. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 20] + diff --git a/rfc/rfc2865.txt b/rfc/rfc2865.txt new file mode 100644 index 00000000..10ec2310 --- /dev/null +++ b/rfc/rfc2865.txt @@ -0,0 +1,4259 @@ + + + + + + +Network Working Group C. Rigney +Request for Comments: 2865 S. Willens +Obsoletes: 2138 Livingston +Category: Standards Track A. Rubens + Merit + W. Simpson + Daydreamer + June 2000 + + + Remote Authentication Dial In User Service (RADIUS) + +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. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +IESG Note: + + This protocol is widely implemented and used. Experience has shown + that it can suffer degraded performance and lost data when used in + large scale systems, in part because it does not include provisions + for congestion control. Readers of this document may find it + beneficial to track the progress of the IETF's AAA working group, + which may develop a successor protocol that better addresses the + scaling and congestion control issues. + +Abstract + + This document describes a protocol for carrying authentication, + authorization, and configuration information between a Network Access + Server which desires to authenticate its links and a shared + Authentication Server. + +Implementation Note + + This memo documents the RADIUS protocol. The early deployment of + RADIUS was done using UDP port number 1645, which conflicts with the + "datametrics" service. The officially assigned port number for + RADIUS is 1812. + + + + +Rigney, et al. Standards Track [Page 1] + +RFC 2865 RADIUS June 2000 + + +Table of Contents + + 1. Introduction .......................................... 3 + 1.1 Specification of Requirements ................... 4 + 1.2 Terminology ..................................... 5 + 2. Operation ............................................. 5 + 2.1 Challenge/Response .............................. 7 + 2.2 Interoperation with PAP and CHAP ................ 8 + 2.3 Proxy ........................................... 8 + 2.4 Why UDP? ........................................ 11 + 2.5 Retransmission Hints ............................ 12 + 2.6 Keep-Alives Considered Harmful .................. 13 + 3. Packet Format ......................................... 13 + 4. Packet Types .......................................... 17 + 4.1 Access-Request .................................. 17 + 4.2 Access-Accept ................................... 18 + 4.3 Access-Reject ................................... 20 + 4.4 Access-Challenge ................................ 21 + 5. Attributes ............................................ 22 + 5.1 User-Name ....................................... 26 + 5.2 User-Password ................................... 27 + 5.3 CHAP-Password ................................... 28 + 5.4 NAS-IP-Address .................................. 29 + 5.5 NAS-Port ........................................ 30 + 5.6 Service-Type .................................... 31 + 5.7 Framed-Protocol ................................. 33 + 5.8 Framed-IP-Address ............................... 34 + 5.9 Framed-IP-Netmask ............................... 34 + 5.10 Framed-Routing .................................. 35 + 5.11 Filter-Id ....................................... 36 + 5.12 Framed-MTU ...................................... 37 + 5.13 Framed-Compression .............................. 37 + 5.14 Login-IP-Host ................................... 38 + 5.15 Login-Service ................................... 39 + 5.16 Login-TCP-Port .................................. 40 + 5.17 (unassigned) .................................... 41 + 5.18 Reply-Message ................................... 41 + 5.19 Callback-Number ................................. 42 + 5.20 Callback-Id ..................................... 42 + 5.21 (unassigned) .................................... 43 + 5.22 Framed-Route .................................... 43 + 5.23 Framed-IPX-Network .............................. 44 + 5.24 State ........................................... 45 + 5.25 Class ........................................... 46 + 5.26 Vendor-Specific ................................. 47 + 5.27 Session-Timeout ................................. 48 + 5.28 Idle-Timeout .................................... 49 + 5.29 Termination-Action .............................. 49 + + + +Rigney, et al. Standards Track [Page 2] + +RFC 2865 RADIUS June 2000 + + + 5.30 Called-Station-Id ............................... 50 + 5.31 Calling-Station-Id .............................. 51 + 5.32 NAS-Identifier .................................. 52 + 5.33 Proxy-State ..................................... 53 + 5.34 Login-LAT-Service ............................... 54 + 5.35 Login-LAT-Node .................................. 55 + 5.36 Login-LAT-Group ................................. 56 + 5.37 Framed-AppleTalk-Link ........................... 57 + 5.38 Framed-AppleTalk-Network ........................ 58 + 5.39 Framed-AppleTalk-Zone ........................... 58 + 5.40 CHAP-Challenge .................................. 59 + 5.41 NAS-Port-Type ................................... 60 + 5.42 Port-Limit ...................................... 61 + 5.43 Login-LAT-Port .................................. 62 + 5.44 Table of Attributes ............................. 63 + 6. IANA Considerations ................................... 64 + 6.1 Definition of Terms ............................. 64 + 6.2 Recommended Registration Policies ............... 65 + 7. Examples .............................................. 66 + 7.1 User Telnet to Specified Host ................... 66 + 7.2 Framed User Authenticating with CHAP ............ 67 + 7.3 User with Challenge-Response card ............... 68 + 8. Security Considerations ............................... 71 + 9. Change Log ............................................ 71 + 10. References ............................................ 73 + 11. Acknowledgements ...................................... 74 + 12. Chair's Address ....................................... 74 + 13. Authors' Addresses .................................... 75 + 14. Full Copyright Statement .............................. 76 + +1. Introduction + + This document obsoletes RFC 2138 [1]. A summary of the changes + between this document and RFC 2138 is available in the "Change Log" + appendix. + + Managing dispersed serial line and modem pools for large numbers of + users can create the need for significant administrative support. + Since modem pools are by definition a link to the outside world, they + require careful attention to security, authorization and accounting. + This can be best achieved by managing a single "database" of users, + which allows for authentication (verifying user name and password) as + well as configuration information detailing the type of service to + deliver to the user (for example, SLIP, PPP, telnet, rlogin). + + + + + + + +Rigney, et al. Standards Track [Page 3] + +RFC 2865 RADIUS June 2000 + + + Key features of RADIUS are: + + Client/Server Model + + A Network Access Server (NAS) operates as a client of RADIUS. The + client is responsible for passing user information to designated + RADIUS servers, and then acting on the response which is returned. + + RADIUS servers are responsible for receiving user connection + requests, authenticating the user, and then returning all + configuration information necessary for the client to deliver + service to the user. + + A RADIUS server can act as a proxy client to other RADIUS servers + or other kinds of authentication servers. + + Network Security + + Transactions between the client and RADIUS server are + authenticated through the use of a shared secret, which is never + sent over the network. In addition, any user passwords are sent + encrypted between the client and RADIUS server, to eliminate the + possibility that someone snooping on an unsecure network could + determine a user's password. + + Flexible Authentication Mechanisms + + The RADIUS server can support a variety of methods to authenticate + a user. When it is provided with the user name and original + password given by the user, it can support PPP PAP or CHAP, UNIX + login, and other authentication mechanisms. + + Extensible Protocol + + All transactions are comprised of variable length Attribute- + Length-Value 3-tuples. New attribute values can be added without + disturbing existing implementations of the protocol. + +1.1. Specification of Requirements + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14 [2]. These key + words mean the same thing whether capitalized or not. + + An implementation is not compliant if it fails to satisfy one or more + of the must or must not requirements for the protocols it implements. + An implementation that satisfies all the must, must not, should and + + + +Rigney, et al. Standards Track [Page 4] + +RFC 2865 RADIUS June 2000 + + + should not requirements for its protocols is said to be + "unconditionally compliant"; one that satisfies all the must and must + not requirements but not all the should or should not requirements + for its protocols is said to be "conditionally compliant". + + A NAS that does not implement a given service MUST NOT implement the + RADIUS attributes for that service. For example, a NAS that is + unable to offer ARAP service MUST NOT implement the RADIUS attributes + for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an + unavailable service as an access-reject instead. + +1.2. Terminology + + This document frequently uses the following terms: + + service The NAS provides a service to the dial-in user, such as PPP + or Telnet. + + session Each service provided by the NAS to a dial-in user + constitutes a session, with the beginning of the session + defined as the point where service is first provided and + the end of the session defined as the point where service + is ended. A user may have multiple sessions in parallel or + series if the NAS supports that. + + silently discard + This means the implementation discards the packet without + further processing. The implementation SHOULD provide the + capability of logging the error, including the contents of + the silently discarded packet, and SHOULD record the event + in a statistics counter. + +2. Operation + + When a client is configured to use RADIUS, any user of the client + presents authentication information to the client. This might be + with a customizable login prompt, where the user is expected to enter + their username and password. Alternatively, the user might use a + link framing protocol such as the Point-to-Point Protocol (PPP), + which has authentication packets which carry this information. + + Once the client has obtained such information, it may choose to + authenticate using RADIUS. To do so, the client creates an "Access- + Request" containing such Attributes as the user's name, the user's + password, the ID of the client and the Port ID which the user is + accessing. When a password is present, it is hidden using a method + based on the RSA Message Digest Algorithm MD5 [3]. + + + + +Rigney, et al. Standards Track [Page 5] + +RFC 2865 RADIUS June 2000 + + + The Access-Request is submitted to the RADIUS server via the network. + If no response is returned within a length of time, the request is + re-sent a number of times. The client can also forward requests to + an alternate server or servers in the event that the primary server + is down or unreachable. An alternate server can be used either after + a number of tries to the primary server fail, or in a round-robin + fashion. Retry and fallback algorithms are the topic of current + research and are not specified in detail in this document. + + Once the RADIUS server receives the request, it validates the sending + client. A request from a client for which the RADIUS server does not + have a shared secret MUST be silently discarded. If the client is + valid, the RADIUS server consults a database of users to find the + user whose name matches the request. The user entry in the database + contains a list of requirements which must be met to allow access for + the user. This always includes verification of the password, but can + also specify the client(s) or port(s) to which the user is allowed + access. + + The RADIUS server MAY make requests of other servers in order to + satisfy the request, in which case it acts as a client. + + If any Proxy-State attributes were present in the Access-Request, + they MUST be copied unmodified and in order into the response packet. + Other Attributes can be placed before, after, or even between the + Proxy-State attributes. + + If any condition is not met, the RADIUS server sends an "Access- + Reject" response indicating that this user request is invalid. If + desired, the server MAY include a text message in the Access-Reject + which MAY be displayed by the client to the user. No other + Attributes (except Proxy-State) are permitted in an Access-Reject. + + If all conditions are met and the RADIUS server wishes to issue a + challenge to which the user must respond, the RADIUS server sends an + "Access-Challenge" response. It MAY include a text message to be + displayed by the client to the user prompting for a response to the + challenge, and MAY include a State attribute. + + If the client receives an Access-Challenge and supports + challenge/response it MAY display the text message, if any, to the + user, and then prompt the user for a response. The client then re- + submits its original Access-Request with a new request ID, with the + User-Password Attribute replaced by the response (encrypted), and + including the State Attribute from the Access-Challenge, if any. + Only 0 or 1 instances of the State Attribute SHOULD be + + + + + +Rigney, et al. Standards Track [Page 6] + +RFC 2865 RADIUS June 2000 + + + present in a request. The server can respond to this new Access- + Request with either an Access-Accept, an Access-Reject, or another + Access-Challenge. + + If all conditions are met, the list of configuration values for the + user are placed into an "Access-Accept" response. These values + include the type of service (for example: SLIP, PPP, Login User) and + all necessary values to deliver the desired service. For SLIP and + PPP, this may include values such as IP address, subnet mask, MTU, + desired compression, and desired packet filter identifiers. For + character mode users, this may include values such as desired + protocol and host. + +2.1. Challenge/Response + + In challenge/response authentication, the user is given an + unpredictable number and challenged to encrypt it and give back the + result. Authorized users are equipped with special devices such as + smart cards or software that facilitate calculation of the correct + response with ease. Unauthorized users, lacking the appropriate + device or software and lacking knowledge of the secret key necessary + to emulate such a device or software, can only guess at the response. + + The Access-Challenge packet typically contains a Reply-Message + including a challenge to be displayed to the user, such as a numeric + value unlikely ever to be repeated. Typically this is obtained from + an external server that knows what type of authenticator is in the + possession of the authorized user and can therefore choose a random + or non-repeating pseudorandom number of an appropriate radix and + length. + + The user then enters the challenge into his device (or software) and + it calculates a response, which the user enters into the client which + forwards it to the RADIUS server via a second Access-Request. If the + response matches the expected response the RADIUS server replies with + an Access-Accept, otherwise an Access-Reject. + + Example: The NAS sends an Access-Request packet to the RADIUS Server + with NAS-Identifier, NAS-Port, User-Name, User-Password (which may + just be a fixed string like "challenge" or ignored). The server + sends back an Access-Challenge packet with State and a Reply-Message + along the lines of "Challenge 12345678, enter your response at the + prompt" which the NAS displays. The NAS prompts for the response and + sends a NEW Access-Request to the server (with a new ID) with NAS- + Identifier, NAS-Port, User-Name, User-Password (the response just + entered by the user, encrypted), and the same State Attribute that + + + + + +Rigney, et al. Standards Track [Page 7] + +RFC 2865 RADIUS June 2000 + + + came with the Access-Challenge. The server then sends back either an + Access-Accept or Access-Reject based on whether the response matches + the required value, or it can even send another Access-Challenge. + +2.2. Interoperation with PAP and CHAP + + For PAP, the NAS takes the PAP ID and password and sends them in an + Access-Request packet as the User-Name and User-Password. The NAS MAY + include the Attributes Service-Type = Framed-User and Framed-Protocol + = PPP as a hint to the RADIUS server that PPP service is expected. + + For CHAP, the NAS generates a random challenge (preferably 16 octets) + and sends it to the user, who returns a CHAP response along with a + CHAP ID and CHAP username. The NAS then sends an Access-Request + packet to the RADIUS server with the CHAP username as the User-Name + and with the CHAP ID and CHAP response as the CHAP-Password + (Attribute 3). The random challenge can either be included in the + CHAP-Challenge attribute or, if it is 16 octets long, it can be + placed in the Request Authenticator field of the Access-Request + packet. The NAS MAY include the Attributes Service-Type = Framed- + User and Framed-Protocol = PPP as a hint to the RADIUS server that + PPP service is expected. + + The RADIUS server looks up a password based on the User-Name, + encrypts the challenge using MD5 on the CHAP ID octet, that password, + and the CHAP challenge (from the CHAP-Challenge attribute if present, + otherwise from the Request Authenticator), and compares that result + to the CHAP-Password. If they match, the server sends back an + Access-Accept, otherwise it sends back an Access-Reject. + + If the RADIUS server is unable to perform the requested + authentication it MUST return an Access-Reject. For example, CHAP + requires that the user's password be available in cleartext to the + server so that it can encrypt the CHAP challenge and compare that to + the CHAP response. If the password is not available in cleartext to + the RADIUS server then the server MUST send an Access-Reject to the + client. + +2.3. Proxy + + With proxy RADIUS, one RADIUS server receives an authentication (or + accounting) request from a RADIUS client (such as a NAS), forwards + the request to a remote RADIUS server, receives the reply from the + remote server, and sends that reply to the client, possibly with + changes to reflect local administrative policy. A common use for + proxy RADIUS is roaming. Roaming permits two or more administrative + entities to allow each other's users to dial in to either entity's + network for service. + + + +Rigney, et al. Standards Track [Page 8] + +RFC 2865 RADIUS June 2000 + + + The NAS sends its RADIUS access-request to the "forwarding server" + which forwards it to the "remote server". The remote server sends a + response (Access-Accept, Access-Reject, or Access-Challenge) back to + the forwarding server, which sends it back to the NAS. The User-Name + attribute MAY contain a Network Access Identifier [8] for RADIUS + Proxy operations. The choice of which server receives the forwarded + request SHOULD be based on the authentication "realm". The + authentication realm MAY be the realm part of a Network Access + Identifier (a "named realm"). Alternatively, the choice of which + server receives the forwarded request MAY be based on whatever other + criteria the forwarding server is configured to use, such as Called- + Station-Id (a "numbered realm"). + + A RADIUS server can function as both a forwarding server and a remote + server, serving as a forwarding server for some realms and a remote + server for other realms. One forwarding server can act as a + forwarder for any number of remote servers. A remote server can have + any number of servers forwarding to it and can provide authentication + for any number of realms. One forwarding server can forward to + another forwarding server to create a chain of proxies, although care + must be taken to avoid introducing loops. + + The following scenario illustrates a proxy RADIUS communication + between a NAS and the forwarding and remote RADIUS servers: + + 1. A NAS sends its access-request to the forwarding server. + + 2. The forwarding server forwards the access-request to the remote + server. + + 3. The remote server sends an access-accept, access-reject or + access-challenge back to the forwarding server. For this example, + an access-accept is sent. + + 4. The forwarding server sends the access-accept to the NAS. + + The forwarding server MUST treat any Proxy-State attributes already + in the packet as opaque data. Its operation MUST NOT depend on the + content of Proxy-State attributes added by previous servers. + + If there are any Proxy-State attributes in the request received from + the client, the forwarding server MUST include those Proxy-State + attributes in its reply to the client. The forwarding server MAY + include the Proxy-State attributes in the access-request when it + forwards the request, or MAY omit them in the forwarded request. If + the forwarding server omits the Proxy-State attributes in the + forwarded access-request, it MUST attach them to the response before + sending it to the client. + + + +Rigney, et al. Standards Track [Page 9] + +RFC 2865 RADIUS June 2000 + + + We now examine each step in more detail. + + 1. A NAS sends its access-request to the forwarding server. The + forwarding server decrypts the User-Password, if present, using + the shared secret it knows for the NAS. If a CHAP-Password + attribute is present in the packet and no CHAP-Challenge attribute + is present, the forwarding server MUST leave the Request- + Authenticator untouched or copy it to a CHAP-Challenge attribute. + + '' The forwarding server MAY add one Proxy-State attribute to the + packet. (It MUST NOT add more than one.) If it adds a Proxy- + State, the Proxy-State MUST appear after any other Proxy-States in + the packet. The forwarding server MUST NOT modify any other + Proxy-States that were in the packet (it may choose not to forward + them, but it MUST NOT change their contents). The forwarding + server MUST NOT change the order of any attributes of the same + type, including Proxy-State. + + 2. The forwarding server encrypts the User-Password, if present, + using the secret it shares with the remote server, sets the + Identifier as needed, and forwards the access-request to the + remote server. + + 3. The remote server (if the final destination) verifies the user + using User-Password, CHAP-Password, or such method as future + extensions may dictate, and returns an access-accept, access- + reject or access-challenge back to the forwarding server. For + this example, an access-accept is sent. The remote server MUST + copy all Proxy-State attributes (and only the Proxy-State + attributes) in order from the access-request to the response + packet, without modifying them. + + 4. The forwarding server verifies the Response Authenticator using + the secret it shares with the remote server, and silently discards + the packet if it fails verification. If the packet passes + verification, the forwarding server removes the last Proxy-State + (if it attached one), signs the Response Authenticator using the + secret it shares with the NAS, restores the Identifier to match + the one in the original request by the NAS, and sends the access- + accept to the NAS. + + A forwarding server MAY need to modify attributes to enforce local + policy. Such policy is outside the scope of this document, with the + following restrictions. A forwarding server MUST not modify existing + Proxy-State, State, or Class attributes present in the packet. + + + + + + +Rigney, et al. Standards Track [Page 10] + +RFC 2865 RADIUS June 2000 + + + Implementers of forwarding servers should consider carefully which + values it is willing to accept for Service-Type. Careful + consideration must be given to the effects of passing along Service- + Types of NAS-Prompt or Administrative in a proxied Access-Accept, and + implementers may wish to provide mechanisms to block those or other + service types, or other attributes. Such mechanisms are outside the + scope of this document. + +2.4. Why UDP? + + A frequently asked question is why RADIUS uses UDP instead of TCP as + a transport protocol. UDP was chosen for strictly technical reasons. + + There are a number of issues which must be understood. RADIUS is a + transaction based protocol which has several interesting + characteristics: + + 1. If the request to a primary Authentication server fails, a + secondary server must be queried. + + To meet this requirement, a copy of the request must be kept above + the transport layer to allow for alternate transmission. This + means that retransmission timers are still required. + + 2. The timing requirements of this particular protocol are + significantly different than TCP provides. + + At one extreme, RADIUS does not require a "responsive" detection + of lost data. The user is willing to wait several seconds for the + authentication to complete. The generally aggressive TCP + retransmission (based on average round trip time) is not required, + nor is the acknowledgement overhead of TCP. + + At the other extreme, the user is not willing to wait several + minutes for authentication. Therefore the reliable delivery of + TCP data two minutes later is not useful. The faster use of an + alternate server allows the user to gain access before giving up. + + 3. The stateless nature of this protocol simplifies the use of UDP. + + Clients and servers come and go. Systems are rebooted, or are + power cycled independently. Generally this does not cause a + problem and with creative timeouts and detection of lost TCP + connections, code can be written to handle anomalous events. UDP + however completely eliminates any of this special handling. Each + client and server can open their UDP transport just once and leave + it open through all types of failure events on the network. + + + + +Rigney, et al. Standards Track [Page 11] + +RFC 2865 RADIUS June 2000 + + + 4. UDP simplifies the server implementation. + + In the earliest implementations of RADIUS, the server was single + threaded. This means that a single request was received, + processed, and returned. This was found to be unmanageable in + environments where the back-end security mechanism took real time + (1 or more seconds). The server request queue would fill and in + environments where hundreds of people were being authenticated + every minute, the request turn-around time increased to longer + than users were willing to wait (this was especially severe when a + specific lookup in a database or over DNS took 30 or more + seconds). The obvious solution was to make the server multi- + threaded. Achieving this was simple with UDP. Separate processes + were spawned to serve each request and these processes could + respond directly to the client NAS with a simple UDP packet to the + original transport of the client. + + It's not all a panacea. As noted, using UDP requires one thing which + is built into TCP: with UDP we must artificially manage + retransmission timers to the same server, although they don't require + the same attention to timing provided by TCP. This one penalty is a + small price to pay for the advantages of UDP in this protocol. + + Without TCP we would still probably be using tin cans connected by + string. But for this particular protocol, UDP is a better choice. + +2.5. Retransmission Hints + + If the RADIUS server and alternate RADIUS server share the same + shared secret, it is OK to retransmit the packet to the alternate + RADIUS server with the same ID and Request Authenticator, because the + content of the attributes haven't changed. If you want to use a new + Request Authenticator when sending to the alternate server, you may. + + If you change the contents of the User-Password attribute (or any + other attribute), you need a new Request Authenticator and therefore + a new ID. + + If the NAS is retransmitting a RADIUS request to the same server as + before, and the attributes haven't changed, you MUST use the same + Request Authenticator, ID, and source port. If any attributes have + changed, you MUST use a new Request Authenticator and ID. + + A NAS MAY use the same ID across all servers, or MAY keep track of + IDs separately for each server, it is up to the implementer. If a + NAS needs more than 256 IDs for outstanding requests, it MAY use + + + + + +Rigney, et al. Standards Track [Page 12] + +RFC 2865 RADIUS June 2000 + + + additional source ports to send requests from, and keep track of IDs + for each source port. This allows up to 16 million or so outstanding + requests at one time to a single server. + +2.6. Keep-Alives Considered Harmful + + Some implementers have adopted the practice of sending test RADIUS + requests to see if a server is alive. This practice is strongly + discouraged, since it adds to load and harms scalability without + providing any additional useful information. Since a RADIUS request + is contained in a single datagram, in the time it would take you to + send a ping you could just send the RADIUS request, and getting a + reply tells you that the RADIUS server is up. If you do not have a + RADIUS request to send, it does not matter if the server is up or + not, because you are not using it. + + If you want to monitor your RADIUS server, use SNMP. That's what + SNMP is for. + +3. Packet Format + + Exactly one RADIUS packet is encapsulated in the UDP Data field [4], + where the UDP Destination Port field indicates 1812 (decimal). + + When a reply is generated, the source and destination ports are + reversed. + + This memo documents the RADIUS protocol. The early deployment of + RADIUS was done using UDP port number 1645, which conflicts with the + "datametrics" service. The officially assigned port number for + RADIUS is 1812. + + + + + + + + + + + + + + + + + + + + +Rigney, et al. Standards Track [Page 13] + +RFC 2865 RADIUS June 2000 + + + A summary of the RADIUS data format is shown below. The fields are + transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + The Code field is one octet, and identifies the type of RADIUS + packet. When a packet is received with an invalid Code field, it + is silently discarded. + + RADIUS Codes (decimal) are assigned as follows: + + 1 Access-Request + 2 Access-Accept + 3 Access-Reject + 4 Accounting-Request + 5 Accounting-Response + 11 Access-Challenge + 12 Status-Server (experimental) + 13 Status-Client (experimental) + 255 Reserved + + Codes 4 and 5 are covered in the RADIUS Accounting document [5]. + Codes 12 and 13 are reserved for possible use, but are not further + mentioned here. + + Identifier + + The Identifier field is one octet, and aids in matching requests + and replies. The RADIUS server can detect a duplicate request if + it has the same client source IP address and source UDP port and + Identifier within a short span of time. + + + + + + + +Rigney, et al. Standards Track [Page 14] + +RFC 2865 RADIUS June 2000 + + + Length + + The Length field is two octets. It indicates the length of the + packet including the Code, Identifier, Length, Authenticator and + Attribute fields. Octets outside the range of the Length field + MUST be treated as padding and ignored on reception. If the + packet is shorter than the Length field indicates, it MUST be + silently discarded. The minimum length is 20 and maximum length + is 4096. + + Authenticator + + The Authenticator field is sixteen (16) octets. The most + significant octet is transmitted first. This value is used to + authenticate the reply from the RADIUS server, and is used in the + password hiding algorithm. + + Request Authenticator + + In Access-Request Packets, the Authenticator value is a 16 + octet random number, called the Request Authenticator. The + value SHOULD be unpredictable and unique over the lifetime of a + secret (the password shared between the client and the RADIUS + server), since repetition of a request value in conjunction + with the same secret would permit an attacker to reply with a + previously intercepted response. Since it is expected that the + same secret MAY be used to authenticate with servers in + disparate geographic regions, the Request Authenticator field + SHOULD exhibit global and temporal uniqueness. + + The Request Authenticator value in an Access-Request packet + SHOULD also be unpredictable, lest an attacker trick a server + into responding to a predicted future request, and then use the + response to masquerade as that server to a future Access- + Request. + + Although protocols such as RADIUS are incapable of protecting + against theft of an authenticated session via realtime active + wiretapping attacks, generation of unique unpredictable + requests can protect against a wide range of active attacks + against authentication. + + The NAS and RADIUS server share a secret. That shared secret + followed by the Request Authenticator is put through a one-way + MD5 hash to create a 16 octet digest value which is xored with + the password entered by the user, and the xored result placed + + + + + +Rigney, et al. Standards Track [Page 15] + +RFC 2865 RADIUS June 2000 + + + in the User-Password attribute in the Access-Request packet. + See the entry for User-Password in the section on Attributes + for a more detailed description. + + Response Authenticator + + The value of the Authenticator field in Access-Accept, Access- + Reject, and Access-Challenge packets is called the Response + Authenticator, and contains a one-way MD5 hash calculated over + a stream of octets consisting of: the RADIUS packet, beginning + with the Code field, including the Identifier, the Length, the + Request Authenticator field from the Access-Request packet, and + the response Attributes, followed by the shared secret. That + is, ResponseAuth = + MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where + + denotes concatenation. + + Administrative Note + + The secret (password shared between the client and the RADIUS + server) SHOULD be at least as large and unguessable as a well- + chosen password. It is preferred that the secret be at least 16 + octets. This is to ensure a sufficiently large range for the + secret to provide protection against exhaustive search attacks. + The secret MUST NOT be empty (length 0) since this would allow + packets to be trivially forged. + + A RADIUS server MUST use the source IP address of the RADIUS UDP + packet to decide which shared secret to use, so that RADIUS + requests can be proxied. + + When using a forwarding proxy, the proxy must be able to alter the + packet as it passes through in each direction - when the proxy + forwards the request, the proxy MAY add a Proxy-State Attribute, + and when the proxy forwards a response, it MUST remove its Proxy- + State Attribute if it added one. Proxy-State is always added or + removed after any other Proxy-States, but no other assumptions + regarding its location within the list of attributes can be made. + Since Access-Accept and Access-Reject replies are authenticated on + the entire packet contents, the stripping of the Proxy-State + attribute invalidates the signature in the packet - so the proxy + has to re-sign it. + + Further details of RADIUS proxy implementation are outside the + scope of this document. + + + + + + +Rigney, et al. Standards Track [Page 16] + +RFC 2865 RADIUS June 2000 + + +4. Packet Types + + The RADIUS Packet type is determined by the Code field in the first + octet of the Packet. + +4.1. Access-Request + + Description + + Access-Request packets are sent to a RADIUS server, and convey + information used to determine whether a user is allowed access to + a specific NAS, and any special services requested for that user. + An implementation wishing to authenticate a user MUST transmit a + RADIUS packet with the Code field set to 1 (Access-Request). + + Upon receipt of an Access-Request from a valid client, an + appropriate reply MUST be transmitted. + + An Access-Request SHOULD contain a User-Name attribute. It MUST + contain either a NAS-IP-Address attribute or a NAS-Identifier + attribute (or both). + + An Access-Request MUST contain either a User-Password or a CHAP- + Password or a State. An Access-Request MUST NOT contain both a + User-Password and a CHAP-Password. If future extensions allow + other kinds of authentication information to be conveyed, the + attribute for that can be used in an Access-Request instead of + User-Password or CHAP-Password. + + An Access-Request SHOULD contain a NAS-Port or NAS-Port-Type + attribute or both unless the type of access being requested does + not involve a port or the NAS does not distinguish among its + ports. + + An Access-Request MAY contain additional attributes as a hint to + the server, but the server is not required to honor the hint. + + When a User-Password is present, it is hidden using a method based + on the RSA Message Digest Algorithm MD5 [3]. + + + + + + + + + + + + +Rigney, et al. Standards Track [Page 17] + +RFC 2865 RADIUS June 2000 + + + A summary of the Access-Request packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Request Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 1 for Access-Request. + + Identifier + + The Identifier field MUST be changed whenever the content of the + Attributes field changes, and whenever a valid reply has been + received for a previous request. For retransmissions, the + Identifier MUST remain unchanged. + + Request Authenticator + + The Request Authenticator value MUST be changed each time a new + Identifier is used. + + Attributes + + The Attribute field is variable in length, and contains the list + of Attributes that are required for the type of service, as well + as any desired optional Attributes. + +4.2. Access-Accept + + Description + + Access-Accept packets are sent by the RADIUS server, and provide + specific configuration information necessary to begin delivery of + service to the user. If all Attribute values received in an + Access-Request are acceptable then the RADIUS implementation MUST + transmit a packet with the Code field set to 2 (Access-Accept). + + + + +Rigney, et al. Standards Track [Page 18] + +RFC 2865 RADIUS June 2000 + + + On reception of an Access-Accept, the Identifier field is matched + with a pending Access-Request. The Response Authenticator field + MUST contain the correct response for the pending Access-Request. + Invalid packets are silently discarded. + + A summary of the Access-Accept packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 2 for Access-Accept. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Access-Request which caused this Access-Accept. + + Response Authenticator + + The Response Authenticator value is calculated from the Access- + Request value, as described earlier. + + Attributes + + The Attribute field is variable in length, and contains a list of + zero or more Attributes. + + + + + + + + + + + + +Rigney, et al. Standards Track [Page 19] + +RFC 2865 RADIUS June 2000 + + +4.3. Access-Reject + + Description + + If any value of the received Attributes is not acceptable, then + the RADIUS server MUST transmit a packet with the Code field set + to 3 (Access-Reject). It MAY include one or more Reply-Message + Attributes with a text message which the NAS MAY display to the + user. + + A summary of the Access-Reject packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 3 for Access-Reject. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Access-Request which caused this Access-Reject. + + Response Authenticator + + The Response Authenticator value is calculated from the Access- + Request value, as described earlier. + + Attributes + + The Attribute field is variable in length, and contains a list of + zero or more Attributes. + + + + + + + +Rigney, et al. Standards Track [Page 20] + +RFC 2865 RADIUS June 2000 + + +4.4. Access-Challenge + + Description + + If the RADIUS server desires to send the user a challenge + requiring a response, then the RADIUS server MUST respond to the + Access-Request by transmitting a packet with the Code field set to + 11 (Access-Challenge). + + The Attributes field MAY have one or more Reply-Message + Attributes, and MAY have a single State Attribute, or none. + Vendor-Specific, Idle-Timeout, Session-Timeout and Proxy-State + attributes MAY also be included. No other Attributes defined in + this document are permitted in an Access-Challenge. + + On receipt of an Access-Challenge, the Identifier field is matched + with a pending Access-Request. Additionally, the Response + Authenticator field MUST contain the correct response for the + pending Access-Request. Invalid packets are silently discarded. + + If the NAS does not support challenge/response, it MUST treat an + Access-Challenge as though it had received an Access-Reject + instead. + + If the NAS supports challenge/response, receipt of a valid + Access-Challenge indicates that a new Access-Request SHOULD be + sent. The NAS MAY display the text message, if any, to the user, + and then prompt the user for a response. It then sends its + original Access-Request with a new request ID and Request + Authenticator, with the User-Password Attribute replaced by the + user's response (encrypted), and including the State Attribute + from the Access-Challenge, if any. Only 0 or 1 instances of the + State Attribute can be present in an Access-Request. + + A NAS which supports PAP MAY forward the Reply-Message to the + dialing client and accept a PAP response which it can use as + though the user had entered the response. If the NAS cannot do + so, it MUST treat the Access-Challenge as though it had received + an Access-Reject instead. + + + + + + + + + + + + +Rigney, et al. Standards Track [Page 21] + +RFC 2865 RADIUS June 2000 + + + A summary of the Access-Challenge packet format is shown below. The + fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 11 for Access-Challenge. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Access-Request which caused this Access-Challenge. + + Response Authenticator + + The Response Authenticator value is calculated from the Access- + Request value, as described earlier. + + Attributes + + The Attributes field is variable in length, and contains a list of + zero or more Attributes. + +5. Attributes + + RADIUS Attributes carry the specific authentication, authorization, + information and configuration details for the request and reply. + + The end of the list of Attributes is indicated by the Length of the + RADIUS packet. + + Some Attributes MAY be included more than once. The effect of this + is Attribute specific, and is specified in each Attribute + description. A summary table is provided at the end of the + "Attributes" section. + + + + +Rigney, et al. Standards Track [Page 22] + +RFC 2865 RADIUS June 2000 + + + If multiple Attributes with the same Type are present, the order of + Attributes with the same Type MUST be preserved by any proxies. The + order of Attributes of different Types is not required to be + preserved. A RADIUS server or client MUST NOT have any dependencies + on the order of attributes of different types. A RADIUS server or + client MUST NOT require attributes of the same type to be contiguous. + + Where an Attribute's description limits which kinds of packet it can + be contained in, this applies only to the packet types defined in + this document, namely Access-Request, Access-Accept, Access-Reject + and Access-Challenge (Codes 1, 2, 3, and 11). Other documents + defining other packet types may also use Attributes described here. + To determine which Attributes are allowed in Accounting-Request and + Accounting-Response packets (Codes 4 and 5) refer to the RADIUS + Accounting document [5]. + + Likewise where packet types defined here state that only certain + Attributes are permissible in them, future memos defining new + Attributes should indicate which packet types the new Attributes may + be present in. + + A summary of the Attribute format is shown below. The fields are + transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + The Type field is one octet. Up-to-date values of the RADIUS Type + field are specified in the most recent "Assigned Numbers" RFC [6]. + Values 192-223 are reserved for experimental use, values 224-240 + are reserved for implementation-specific use, and values 241-255 + are reserved and should not be used. + + A RADIUS server MAY ignore Attributes with an unknown Type. + + A RADIUS client MAY ignore Attributes with an unknown Type. + + + + + + + + + + +Rigney, et al. Standards Track [Page 23] + +RFC 2865 RADIUS June 2000 + + + This specification concerns the following values: + + 1 User-Name + 2 User-Password + 3 CHAP-Password + 4 NAS-IP-Address + 5 NAS-Port + 6 Service-Type + 7 Framed-Protocol + 8 Framed-IP-Address + 9 Framed-IP-Netmask + 10 Framed-Routing + 11 Filter-Id + 12 Framed-MTU + 13 Framed-Compression + 14 Login-IP-Host + 15 Login-Service + 16 Login-TCP-Port + 17 (unassigned) + 18 Reply-Message + 19 Callback-Number + 20 Callback-Id + 21 (unassigned) + 22 Framed-Route + 23 Framed-IPX-Network + 24 State + 25 Class + 26 Vendor-Specific + 27 Session-Timeout + 28 Idle-Timeout + 29 Termination-Action + 30 Called-Station-Id + 31 Calling-Station-Id + 32 NAS-Identifier + 33 Proxy-State + 34 Login-LAT-Service + 35 Login-LAT-Node + 36 Login-LAT-Group + 37 Framed-AppleTalk-Link + 38 Framed-AppleTalk-Network + 39 Framed-AppleTalk-Zone + 40-59 (reserved for accounting) + 60 CHAP-Challenge + 61 NAS-Port-Type + 62 Port-Limit + 63 Login-LAT-Port + + + + + +Rigney, et al. Standards Track [Page 24] + +RFC 2865 RADIUS June 2000 + + + Length + + The Length field is one octet, and indicates the length of this + Attribute including the Type, Length and Value fields. If an + Attribute is received in an Access-Request but with an invalid + Length, an Access-Reject SHOULD be transmitted. If an Attribute + is received in an Access-Accept, Access-Reject or Access-Challenge + packet with an invalid length, the packet MUST either be treated + as an Access-Reject or else silently discarded. + + Value + + The Value field is zero or more octets and contains information + specific to the Attribute. The format and length of the Value + field is determined by the Type and Length fields. + + Note that none of the types in RADIUS terminate with a NUL (hex + 00). In particular, types "text" and "string" in RADIUS do not + terminate with a NUL (hex 00). The Attribute has a length field + and does not use a terminator. Text contains UTF-8 encoded 10646 + [7] characters and String contains 8-bit binary data. Servers and + servers and clients MUST be able to deal with embedded nulls. + RADIUS implementers using C are cautioned not to use strcpy() when + handling strings. + + The format of the value field is one of five data types. Note + that type "text" is a subset of type "string". + + text 1-253 octets containing UTF-8 encoded 10646 [7] + characters. Text of length zero (0) MUST NOT be sent; + omit the entire attribute instead. + + string 1-253 octets containing binary data (values 0 through + 255 decimal, inclusive). Strings of length zero (0) + MUST NOT be sent; omit the entire attribute instead. + + address 32 bit value, most significant octet first. + + integer 32 bit unsigned value, most significant octet first. + + time 32 bit unsigned value, most significant octet first -- + seconds since 00:00:00 UTC, January 1, 1970. The + standard Attributes do not use this data type but it is + presented here for possible use in future attributes. + + + + + + + +Rigney, et al. Standards Track [Page 25] + +RFC 2865 RADIUS June 2000 + + +5.1. User-Name + + Description + + This Attribute indicates the name of the user to be authenticated. + It MUST be sent in Access-Request packets if available. + + It MAY be sent in an Access-Accept packet, in which case the + client SHOULD use the name returned in the Access-Accept packet in + all Accounting-Request packets for this session. If the Access- + Accept includes Service-Type = Rlogin and the User-Name attribute, + a NAS MAY use the returned User-Name when performing the Rlogin + function. + + A summary of the User-Name Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 1 for User-Name. + + Length + + >= 3 + + String + + The String field is one or more octets. The NAS may limit the + maximum length of the User-Name but the ability to handle at least + 63 octets is recommended. + + The format of the username MAY be one of several forms: + + text Consisting only of UTF-8 encoded 10646 [7] characters. + + network access identifier + A Network Access Identifier as described in RFC 2486 + [8]. + + distinguished name + A name in ASN.1 form used in Public Key authentication + systems. + + + +Rigney, et al. Standards Track [Page 26] + +RFC 2865 RADIUS June 2000 + + +5.2. User-Password + + Description + + This Attribute indicates the password of the user to be + authenticated, or the user's input following an Access-Challenge. + It is only used in Access-Request packets. + + On transmission, the password is hidden. The password is first + padded at the end with nulls to a multiple of 16 octets. A one- + way MD5 hash is calculated over a stream of octets consisting of + the shared secret followed by the Request Authenticator. This + value is XORed with the first 16 octet segment of the password and + placed in the first 16 octets of the String field of the User- + Password Attribute. + + If the password is longer than 16 characters, a second one-way MD5 + hash is calculated over a stream of octets consisting of the + shared secret followed by the result of the first xor. That hash + is XORed with the second 16 octet segment of the password and + placed in the second 16 octets of the String field of the User- + Password Attribute. + + If necessary, this operation is repeated, with each xor result + being used along with the shared secret to generate the next hash + to xor the next segment of the password, to no more than 128 + characters. + + The method is taken from the book "Network Security" by Kaufman, + Perlman and Speciner [9] pages 109-110. A more precise + explanation of the method follows: + + Call the shared secret S and the pseudo-random 128-bit Request + Authenticator RA. Break the password into 16-octet chunks p1, p2, + etc. with the last one padded at the end with nulls to a 16-octet + boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need + intermediate values b1, b2, etc. + + b1 = MD5(S + RA) c(1) = p1 xor b1 + b2 = MD5(S + c(1)) c(2) = p2 xor b2 + . . + . . + . . + bi = MD5(S + c(i-1)) c(i) = pi xor bi + + The String will contain c(1)+c(2)+...+c(i) where + denotes + concatenation. + + + + +Rigney, et al. Standards Track [Page 27] + +RFC 2865 RADIUS June 2000 + + + On receipt, the process is reversed to yield the original + password. + + A summary of the User-Password Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 2 for User-Password. + + Length + + At least 18 and no larger than 130. + + String + + The String field is between 16 and 128 octets long, inclusive. + +5.3. CHAP-Password + + Description + + This Attribute indicates the response value provided by a PPP + Challenge-Handshake Authentication Protocol (CHAP) user in + response to the challenge. It is only used in Access-Request + packets. + + The CHAP challenge value is found in the CHAP-Challenge Attribute + (60) if present in the packet, otherwise in the Request + Authenticator field. + + A summary of the CHAP-Password Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | CHAP Ident | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + + + + +Rigney, et al. Standards Track [Page 28] + +RFC 2865 RADIUS June 2000 + + + Type + + 3 for CHAP-Password. + + Length + + 19 + + CHAP Ident + + This field is one octet, and contains the CHAP Identifier from the + user's CHAP Response. + + String + + The String field is 16 octets, and contains the CHAP Response from + the user. + +5.4. NAS-IP-Address + + Description + + This Attribute indicates the identifying IP Address of the NAS + which is requesting authentication of the user, and SHOULD be + unique to the NAS within the scope of the RADIUS server. NAS-IP- + Address is only used in Access-Request packets. Either NAS-IP- + Address or NAS-Identifier MUST be present in an Access-Request + packet. + + Note that NAS-IP-Address MUST NOT be used to select the shared + secret used to authenticate the request. The source IP address of + the Access-Request packet MUST be used to select the shared + secret. + + A summary of the NAS-IP-Address Attribute format is shown below. The + fields are transmitted from 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 4 for NAS-IP-Address. + + + +Rigney, et al. Standards Track [Page 29] + +RFC 2865 RADIUS June 2000 + + + Length + + 6 + + Address + + The Address field is four octets. + +5.5. NAS-Port + + Description + + This Attribute indicates the physical port number of the NAS which + is authenticating the user. It is only used in Access-Request + packets. Note that this is using "port" in its sense of a + physical connection on the NAS, not in the sense of a TCP or UDP + port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD + be present in an Access-Request packet, if the NAS differentiates + among its ports. + + A summary of the NAS-Port Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 5 for NAS-Port. + + Length + + 6 + + Value + + The Value field is four octets. + + + + + + + + + +Rigney, et al. Standards Track [Page 30] + +RFC 2865 RADIUS June 2000 + + +5.6. Service-Type + + Description + + This Attribute indicates the type of service the user has + requested, or the type of service to be provided. It MAY be used + in both Access-Request and Access-Accept packets. A NAS is not + required to implement all of these service types, and MUST treat + unknown or unsupported Service-Types as though an Access-Reject + had been received instead. + + A summary of the Service-Type Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 6 for Service-Type. + + Length + + 6 + + Value + + The Value field is four octets. + + 1 Login + 2 Framed + 3 Callback Login + 4 Callback Framed + 5 Outbound + 6 Administrative + 7 NAS Prompt + 8 Authenticate Only + 9 Callback NAS Prompt + 10 Call Check + 11 Callback Administrative + + + + + + +Rigney, et al. Standards Track [Page 31] + +RFC 2865 RADIUS June 2000 + + + The service types are defined as follows when used in an Access- + Accept. When used in an Access-Request, they MAY be considered to + be a hint to the RADIUS server that the NAS has reason to believe + the user would prefer the kind of service indicated, but the + server is not required to honor the hint. + + Login The user should be connected to a host. + + Framed A Framed Protocol should be started for the + User, such as PPP or SLIP. + + Callback Login The user should be disconnected and called + back, then connected to a host. + + Callback Framed The user should be disconnected and called + back, then a Framed Protocol should be started + for the User, such as PPP or SLIP. + + Outbound The user should be granted access to outgoing + devices. + + Administrative The user should be granted access to the + administrative interface to the NAS from which + privileged commands can be executed. + + NAS Prompt The user should be provided a command prompt + on the NAS from which non-privileged commands + can be executed. + + Authenticate Only Only Authentication is requested, and no + authorization information needs to be returned + in the Access-Accept (typically used by proxy + servers rather than the NAS itself). + + Callback NAS Prompt The user should be disconnected and called + back, then provided a command prompt on the + NAS from which non-privileged commands can be + executed. + + Call Check Used by the NAS in an Access-Request packet to + indicate that a call is being received and + that the RADIUS server should send back an + Access-Accept to answer the call, or an + Access-Reject to not accept the call, + typically based on the Called-Station-Id or + Calling-Station-Id attributes. It is + + + + + +Rigney, et al. Standards Track [Page 32] + +RFC 2865 RADIUS June 2000 + + + recommended that such Access-Requests use the + value of Calling-Station-Id as the value of + the User-Name. + + Callback Administrative + The user should be disconnected and called + back, then granted access to the + administrative interface to the NAS from which + privileged commands can be executed. + +5.7. Framed-Protocol + + Description + + This Attribute indicates the framing to be used for framed access. + It MAY be used in both Access-Request and Access-Accept packets. + + A summary of the Framed-Protocol Attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 7 for Framed-Protocol. + + Length + + 6 + + Value + + The Value field is four octets. + + 1 PPP + 2 SLIP + 3 AppleTalk Remote Access Protocol (ARAP) + 4 Gandalf proprietary SingleLink/MultiLink protocol + 5 Xylogics proprietary IPX/SLIP + 6 X.75 Synchronous + + + + + +Rigney, et al. Standards Track [Page 33] + +RFC 2865 RADIUS June 2000 + + +5.8. Framed-IP-Address + + Description + + This Attribute indicates the address to be configured for the + user. It MAY be used in Access-Accept packets. It MAY be used in + an Access-Request packet as a hint by the NAS to the server that + it would prefer that address, but the server is not required to + honor the hint. + + A summary of the Framed-IP-Address Attribute format is shown below. + The fields are transmitted from 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 8 for Framed-IP-Address. + + Length + + 6 + + Address + + The Address field is four octets. The value 0xFFFFFFFF indicates + that the NAS Should allow the user to select an address (e.g. + Negotiated). The value 0xFFFFFFFE indicates that the NAS should + select an address for the user (e.g. Assigned from a pool of + addresses kept by the NAS). Other valid values indicate that the + NAS should use that value as the user's IP address. + +5.9. Framed-IP-Netmask + + Description + + This Attribute indicates the IP netmask to be configured for the + user when the user is a router to a network. It MAY be used in + Access-Accept packets. It MAY be used in an Access-Request packet + as a hint by the NAS to the server that it would prefer that + netmask, but the server is not required to honor the hint. + + + + +Rigney, et al. Standards Track [Page 34] + +RFC 2865 RADIUS June 2000 + + + A summary of the Framed-IP-Netmask Attribute format is shown below. + The fields are transmitted from 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 9 for Framed-IP-Netmask. + + Length + + 6 + + Address + + The Address field is four octets specifying the IP netmask of the + user. + +5.10. Framed-Routing + + Description + + This Attribute indicates the routing method for the user, when the + user is a router to a network. It is only used in Access-Accept + packets. + + A summary of the Framed-Routing Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 10 for Framed-Routing. + + + + + +Rigney, et al. Standards Track [Page 35] + +RFC 2865 RADIUS June 2000 + + + Length + + 6 + + Value + + The Value field is four octets. + + 0 None + 1 Send routing packets + 2 Listen for routing packets + 3 Send and Listen + +5.11. Filter-Id + + Description + + This Attribute indicates the name of the filter list for this + user. Zero or more Filter-Id attributes MAY be sent in an + Access-Accept packet. + + Identifying a filter list by name allows the filter to be used on + different NASes without regard to filter-list implementation + details. + + A summary of the Filter-Id Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | Text ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 11 for Filter-Id. + + Length + + >= 3 + + Text + + The Text field is one or more octets, and its contents are + implementation dependent. It is intended to be human readable and + MUST NOT affect operation of the protocol. It is recommended that + the message contain UTF-8 encoded 10646 [7] characters. + + + +Rigney, et al. Standards Track [Page 36] + +RFC 2865 RADIUS June 2000 + + +5.12. Framed-MTU + + Description + + This Attribute indicates the Maximum Transmission Unit to be + configured for the user, when it is not negotiated by some other + means (such as PPP). It MAY be used in Access-Accept packets. It + MAY be used in an Access-Request packet as a hint by the NAS to + the server that it would prefer that value, but the server is not + required to honor the hint. + + A summary of the Framed-MTU Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 12 for Framed-MTU. + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 64 to 65535. + +5.13. Framed-Compression + + Description + + This Attribute indicates a compression protocol to be used for the + link. It MAY be used in Access-Accept packets. It MAY be used in + an Access-Request packet as a hint to the server that the NAS + would prefer to use that compression, but the server is not + required to honor the hint. + + More than one compression protocol Attribute MAY be sent. It is + the responsibility of the NAS to apply the proper compression + protocol to appropriate link traffic. + + + +Rigney, et al. Standards Track [Page 37] + +RFC 2865 RADIUS June 2000 + + + A summary of the Framed-Compression Attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 13 for Framed-Compression. + + Length + + 6 + + Value + + The Value field is four octets. + + 0 None + 1 VJ TCP/IP header compression [10] + 2 IPX header compression + 3 Stac-LZS compression + +5.14. Login-IP-Host + + Description + + This Attribute indicates the system with which to connect the user, + when the Login-Service Attribute is included. It MAY be used in + Access-Accept packets. It MAY be used in an Access-Request packet as + a hint to the server that the NAS would prefer to use that host, but + the server is not required to honor the hint. + + A summary of the Login-IP-Host Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + + + + + + +Rigney, et al. Standards Track [Page 38] + +RFC 2865 RADIUS June 2000 + + + 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 14 for Login-IP-Host. + + Length + + 6 + + Address + + The Address field is four octets. The value 0xFFFFFFFF indicates + that the NAS SHOULD allow the user to select an address. The + value 0 indicates that the NAS SHOULD select a host to connect the + user to. Other values indicate the address the NAS SHOULD connect + the user to. + +5.15. Login-Service + + Description + + This Attribute indicates the service to use to connect the user to + the login host. It is only used in Access-Accept packets. + + A summary of the Login-Service Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 15 for Login-Service. + + + + + + +Rigney, et al. Standards Track [Page 39] + +RFC 2865 RADIUS June 2000 + + + Length + + 6 + + Value + + The Value field is four octets. + + 0 Telnet + 1 Rlogin + 2 TCP Clear + 3 PortMaster (proprietary) + 4 LAT + 5 X25-PAD + 6 X25-T3POS + 8 TCP Clear Quiet (suppresses any NAS-generated connect string) + +5.16. Login-TCP-Port + + Description + + This Attribute indicates the TCP port with which the user is to be + connected, when the Login-Service Attribute is also present. It + is only used in Access-Accept packets. + + A summary of the Login-TCP-Port Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 16 for Login-TCP-Port. + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 0 to 65535. + + + +Rigney, et al. Standards Track [Page 40] + +RFC 2865 RADIUS June 2000 + + +5.17. (unassigned) + + Description + + ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED. + +5.18. Reply-Message + + Description + + This Attribute indicates text which MAY be displayed to the user. + + When used in an Access-Accept, it is the success message. + + When used in an Access-Reject, it is the failure message. It MAY + indicate a dialog message to prompt the user before another + Access-Request attempt. + + When used in an Access-Challenge, it MAY indicate a dialog message + to prompt the user for a response. + + Multiple Reply-Message's MAY be included and if any are displayed, + they MUST be displayed in the same order as they appear in the + packet. + + A summary of the Reply-Message Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | Text ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 18 for Reply-Message. + + Length + + >= 3 + + Text + + The Text field is one or more octets, and its contents are + implementation dependent. It is intended to be human readable, + and MUST NOT affect operation of the protocol. It is recommended + that the message contain UTF-8 encoded 10646 [7] characters. + + + +Rigney, et al. Standards Track [Page 41] + +RFC 2865 RADIUS June 2000 + + +5.19. Callback-Number + + Description + + This Attribute indicates a dialing string to be used for callback. + It MAY be used in Access-Accept packets. It MAY be used in an + Access-Request packet as a hint to the server that a Callback + service is desired, but the server is not required to honor the + hint. + + A summary of the Callback-Number Attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 19 for Callback-Number. + + Length + + >= 3 + + String + + The String field is one or more octets. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.20. Callback-Id + + Description + + This Attribute indicates the name of a place to be called, to be + interpreted by the NAS. It MAY be used in Access-Accept packets. + + + + + + + + + +Rigney, et al. Standards Track [Page 42] + +RFC 2865 RADIUS June 2000 + + + A summary of the Callback-Id Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 20 for Callback-Id. + + Length + + >= 3 + + String + + The String field is one or more octets. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.21. (unassigned) + + Description + + ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED. + +5.22. Framed-Route + + Description + + This Attribute provides routing information to be configured for + the user on the NAS. It is used in the Access-Accept packet and + can appear multiple times. + + A summary of the Framed-Route Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | Text ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + +Rigney, et al. Standards Track [Page 43] + +RFC 2865 RADIUS June 2000 + + + Type + + 22 for Framed-Route. + + Length + + >= 3 + + Text + + The Text field is one or more octets, and its contents are + implementation dependent. It is intended to be human readable and + MUST NOT affect operation of the protocol. It is recommended that + the message contain UTF-8 encoded 10646 [7] characters. + + For IP routes, it SHOULD contain a destination prefix in dotted + quad form optionally followed by a slash and a decimal length + specifier stating how many high order bits of the prefix to use. + That is followed by a space, a gateway address in dotted quad + form, a space, and one or more metrics separated by spaces. For + example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length + specifier may be omitted, in which case it defaults to 8 bits for + class A prefixes, 16 bits for class B prefixes, and 24 bits for + class C prefixes. For example, "192.168.1.0 192.168.1.1 1". + + Whenever the gateway address is specified as "0.0.0.0" the IP + address of the user SHOULD be used as the gateway address. + +5.23. Framed-IPX-Network + + Description + + This Attribute indicates the IPX Network number to be configured + for the user. It is used in Access-Accept packets. + + A summary of the Framed-IPX-Network Attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Rigney, et al. Standards Track [Page 44] + +RFC 2865 RADIUS June 2000 + + + Type + + 23 for Framed-IPX-Network. + + Length + + 6 + + Value + + The Value field is four octets. The value 0xFFFFFFFE indicates + that the NAS should select an IPX network for the user (e.g. + assigned from a pool of one or more IPX networks kept by the NAS). + Other values should be used as the IPX network for the link to the + user. + +5.24. State + + Description + + This Attribute is available to be sent by the server to the client + in an Access-Challenge and MUST be sent unmodified from the client + to the server in the new Access-Request reply to that challenge, + if any. + + This Attribute is available to be sent by the server to the client + in an Access-Accept that also includes a Termination-Action + Attribute with the value of RADIUS-Request. If the NAS performs + the Termination-Action by sending a new Access-Request upon + termination of the current session, it MUST include the State + attribute unchanged in that Access-Request. + + In either usage, the client MUST NOT interpret the attribute + locally. A packet must have only zero or one State Attribute. + Usage of the State Attribute is implementation dependent. + + A summary of the State Attribute format is shown below. The fields + are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 24 for State. + + + +Rigney, et al. Standards Track [Page 45] + +RFC 2865 RADIUS June 2000 + + + Length + + >= 3 + + String + + The String field is one or more octets. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.25. Class + + Description + + This Attribute is available to be sent by the server to the client + in an Access-Accept and SHOULD be sent unmodified by the client to + the accounting server as part of the Accounting-Request packet if + accounting is supported. The client MUST NOT interpret the + attribute locally. + + A summary of the Class Attribute format is shown below. The fields + are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 25 for Class. + + Length + + >= 3 + + String + + The String field is one or more octets. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + + + +Rigney, et al. Standards Track [Page 46] + +RFC 2865 RADIUS June 2000 + + +5.26. Vendor-Specific + + Description + + This Attribute is available to allow vendors to support their own + extended Attributes not suitable for general usage. It MUST not + affect the operation of the RADIUS protocol. + + Servers not equipped to interpret the vendor-specific information + sent by a client MUST ignore it (although it may be reported). + Clients which do not receive desired vendor-specific information + SHOULD make an attempt to operate without it, although they may do + so (and report they are doing so) in a degraded mode. + + A summary of the Vendor-Specific Attribute format is shown below. + The fields are transmitted from 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 | Vendor-Id + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Vendor-Id (cont) | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 26 for Vendor-Specific. + + Length + + >= 7 + + Vendor-Id + + The high-order octet is 0 and the low-order 3 octets are the SMI + Network Management Private Enterprise Code of the Vendor in + network byte order, as defined in the "Assigned Numbers" RFC [6]. + + String + + The String field is one or more octets. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + + + + +Rigney, et al. Standards Track [Page 47] + +RFC 2865 RADIUS June 2000 + + + It SHOULD be encoded as a sequence of vendor type / vendor length + / value fields, as follows. The Attribute-Specific field is + dependent on the vendor's definition of that attribute. An + example encoding of the Vendor-Specific attribute using this + method follows: + + 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 | Vendor-Id + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Vendor-Id (cont) | Vendor type | Vendor length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attribute-Specific... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Multiple subattributes MAY be encoded within a single Vendor- + Specific attribute, although they do not have to be. + +5.27. Session-Timeout + + Description + + This Attribute sets the maximum number of seconds of service to be + provided to the user before termination of the session or prompt. + This Attribute is available to be sent by the server to the client + in an Access-Accept or Access-Challenge. + + A summary of the Session-Timeout Attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 27 for Session-Timeout. + + Length + + 6 + + + + + +Rigney, et al. Standards Track [Page 48] + +RFC 2865 RADIUS June 2000 + + + Value + + The field is 4 octets, containing a 32-bit unsigned integer with + the maximum number of seconds this user should be allowed to + remain connected by the NAS. + +5.28. Idle-Timeout + + Description + + This Attribute sets the maximum number of consecutive seconds of + idle connection allowed to the user before termination of the + session or prompt. This Attribute is available to be sent by the + server to the client in an Access-Accept or Access-Challenge. + + A summary of the Idle-Timeout Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 28 for Idle-Timeout. + + Length + + 6 + + Value + + The field is 4 octets, containing a 32-bit unsigned integer with + the maximum number of consecutive seconds of idle time this user + should be permitted before being disconnected by the NAS. + +5.29. Termination-Action + + Description + + This Attribute indicates what action the NAS should take when the + specified service is completed. It is only used in Access-Accept + packets. + + + + +Rigney, et al. Standards Track [Page 49] + +RFC 2865 RADIUS June 2000 + + + A summary of the Termination-Action Attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 29 for Termination-Action. + + Length + + 6 + + Value + + The Value field is four octets. + + 0 Default + 1 RADIUS-Request + + If the Value is set to RADIUS-Request, upon termination of the + specified service the NAS MAY send a new Access-Request to the + RADIUS server, including the State attribute if any. + +5.30. Called-Station-Id + + Description + + This Attribute allows the NAS to send in the Access-Request packet + the phone number that the user called, using Dialed Number + Identification (DNIS) or similar technology. Note that this may + be different from the phone number the call comes in on. It is + only used in Access-Request packets. + + A summary of the Called-Station-Id Attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + +Rigney, et al. Standards Track [Page 50] + +RFC 2865 RADIUS June 2000 + + + Type + + 30 for Called-Station-Id. + + Length + + >= 3 + + String + + The String field is one or more octets, containing the phone + number that the user's call came in on. + + The actual format of the information is site or application + specific. UTF-8 encoded 10646 [7] characters are recommended, but + a robust implementation SHOULD support the field as + undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.31. Calling-Station-Id + + Description + + This Attribute allows the NAS to send in the Access-Request packet + the phone number that the call came from, using Automatic Number + Identification (ANI) or similar technology. It is only used in + Access-Request packets. + + A summary of the Calling-Station-Id Attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 31 for Calling-Station-Id. + + Length + + >= 3 + + + + + +Rigney, et al. Standards Track [Page 51] + +RFC 2865 RADIUS June 2000 + + + String + + The String field is one or more octets, containing the phone + number that the user placed the call from. + + The actual format of the information is site or application + specific. UTF-8 encoded 10646 [7] characters are recommended, but + a robust implementation SHOULD support the field as + undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.32. NAS-Identifier + + Description + + This Attribute contains a string identifying the NAS originating + the Access-Request. It is only used in Access-Request packets. + Either NAS-IP-Address or NAS-Identifier MUST be present in an + Access-Request packet. + + Note that NAS-Identifier MUST NOT be used to select the shared + secret used to authenticate the request. The source IP address of + the Access-Request packet MUST be used to select the shared + secret. + + A summary of the NAS-Identifier Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 32 for NAS-Identifier. + + Length + + >= 3 + + + + + + + + +Rigney, et al. Standards Track [Page 52] + +RFC 2865 RADIUS June 2000 + + + String + + The String field is one or more octets, and should be unique to + the NAS within the scope of the RADIUS server. For example, a + fully qualified domain name would be suitable as a NAS-Identifier. + + The actual format of the information is site or application + specific, and a robust implementation SHOULD support the field as + undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.33. Proxy-State + + Description + + This Attribute is available to be sent by a proxy server to + another server when forwarding an Access-Request and MUST be + returned unmodified in the Access-Accept, Access-Reject or + Access-Challenge. When the proxy server receives the response to + its request, it MUST remove its own Proxy-State (the last Proxy- + State in the packet) before forwarding the response to the NAS. + + If a Proxy-State Attribute is added to a packet when forwarding + the packet, the Proxy-State Attribute MUST be added after any + existing Proxy-State attributes. + + The content of any Proxy-State other than the one added by the + current server should be treated as opaque octets and MUST NOT + affect operation of the protocol. + + Usage of the Proxy-State Attribute is implementation dependent. A + description of its function is outside the scope of this + specification. + + A summary of the Proxy-State Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 33 for Proxy-State. + + + +Rigney, et al. Standards Track [Page 53] + +RFC 2865 RADIUS June 2000 + + + Length + + >= 3 + + String + + The String field is one or more octets. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.34. Login-LAT-Service + + Description + + This Attribute indicates the system with which the user is to be + connected by LAT. It MAY be used in Access-Accept packets, but + only when LAT is specified as the Login-Service. It MAY be used + in an Access-Request packet as a hint to the server, but the + server is not required to honor the hint. + + Administrators use the service attribute when dealing with + clustered systems, such as a VAX or Alpha cluster. In such an + environment several different time sharing hosts share the same + resources (disks, printers, etc.), and administrators often + configure each to offer access (service) to each of the shared + resources. In this case, each host in the cluster advertises its + services through LAT broadcasts. + + Sophisticated users often know which service providers (machines) + are faster and tend to use a node name when initiating a LAT + connection. Alternately, some administrators want particular + users to use certain machines as a primitive form of load + balancing (although LAT knows how to do load balancing itself). + + A summary of the Login-LAT-Service Attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + + + + +Rigney, et al. Standards Track [Page 54] + +RFC 2865 RADIUS June 2000 + + + Type + + 34 for Login-LAT-Service. + + Length + + >= 3 + + String + + The String field is one or more octets, and contains the identity + of the LAT service to use. The LAT Architecture allows this + string to contain $ (dollar), - (hyphen), . (period), _ + (underscore), numerics, upper and lower case alphabetics, and the + ISO Latin-1 character set extension [11]. All LAT string + comparisons are case insensitive. + +5.35. Login-LAT-Node + + Description + + This Attribute indicates the Node with which the user is to be + automatically connected by LAT. It MAY be used in Access-Accept + packets, but only when LAT is specified as the Login-Service. It + MAY be used in an Access-Request packet as a hint to the server, + but the server is not required to honor the hint. + + A summary of the Login-LAT-Node Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 35 for Login-LAT-Node. + + Length + + >= 3 + + + + + + + + +Rigney, et al. Standards Track [Page 55] + +RFC 2865 RADIUS June 2000 + + + String + + The String field is one or more octets, and contains the identity + of the LAT Node to connect the user to. The LAT Architecture + allows this string to contain $ (dollar), - (hyphen), . (period), + _ (underscore), numerics, upper and lower case alphabetics, and + the ISO Latin-1 character set extension. All LAT string + comparisons are case insensitive. + +5.36. Login-LAT-Group + + Description + + This Attribute contains a string identifying the LAT group codes + which this user is authorized to use. It MAY be used in Access- + Accept packets, but only when LAT is specified as the Login- + Service. It MAY be used in an Access-Request packet as a hint to + the server, but the server is not required to honor the hint. + + LAT supports 256 different group codes, which LAT uses as a form + of access rights. LAT encodes the group codes as a 256 bit + bitmap. + + Administrators can assign one or more of the group code bits at + the LAT service provider; it will only accept LAT connections that + have these group codes set in the bit map. The administrators + assign a bitmap of authorized group codes to each user; LAT gets + these from the operating system, and uses these in its requests to + the service providers. + + A summary of the Login-LAT-Group Attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 36 for Login-LAT-Group. + + Length + + 34 + + + + + +Rigney, et al. Standards Track [Page 56] + +RFC 2865 RADIUS June 2000 + + + String + + The String field is a 32 octet bit map, most significant octet + first. A robust implementation SHOULD support the field as + undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.37. Framed-AppleTalk-Link + + Description + + This Attribute indicates the AppleTalk network number which should + be used for the serial link to the user, which is another + AppleTalk router. It is only used in Access-Accept packets. It + is never used when the user is not another router. + + A summary of the Framed-AppleTalk-Link Attribute format is shown + below. The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 37 for Framed-AppleTalk-Link. + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 0 to 65535. The special value of 0 indicates + that this is an unnumbered serial link. A value of 1-65535 means + that the serial line between the NAS and the user should be + assigned that value as an AppleTalk network number. + + + + + + + +Rigney, et al. Standards Track [Page 57] + +RFC 2865 RADIUS June 2000 + + +5.38. Framed-AppleTalk-Network + + Description + + This Attribute indicates the AppleTalk Network number which the + NAS should probe to allocate an AppleTalk node for the user. It + is only used in Access-Accept packets. It is never used when the + user is another router. Multiple instances of this Attribute + indicate that the NAS may probe using any of the network numbers + specified. + + A summary of the Framed-AppleTalk-Network Attribute format is shown + below. The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 38 for Framed-AppleTalk-Network. + + Length + + 6 + + Value + + The Value field is four octets. Despite the size of the field, + values range from 0 to 65535. The special value 0 indicates that + the NAS should assign a network for the user, using its default + cable range. A value between 1 and 65535 (inclusive) indicates + the AppleTalk Network the NAS should probe to find an address for + the user. + +5.39. Framed-AppleTalk-Zone + + Description + + This Attribute indicates the AppleTalk Default Zone to be used for + this user. It is only used in Access-Accept packets. Multiple + instances of this attribute in the same packet are not allowed. + + + + + +Rigney, et al. Standards Track [Page 58] + +RFC 2865 RADIUS June 2000 + + + A summary of the Framed-AppleTalk-Zone Attribute format is shown + below. The fields are transmitted from left to right. + + 0 1 2 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 39 for Framed-AppleTalk-Zone. + + Length + + >= 3 + + String + + The name of the Default AppleTalk Zone to be used for this user. + A robust implementation SHOULD support the field as + undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + +5.40. CHAP-Challenge + + Description + + This Attribute contains the CHAP Challenge sent by the NAS to a + PPP Challenge-Handshake Authentication Protocol (CHAP) user. It + is only used in Access-Request packets. + + If the CHAP challenge value is 16 octets long it MAY be placed in + the Request Authenticator field instead of using this attribute. + + A summary of the CHAP-Challenge Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + + + + +Rigney, et al. Standards Track [Page 59] + +RFC 2865 RADIUS June 2000 + + + Type + + 60 for CHAP-Challenge. + + Length + + >= 7 + + String + + The String field contains the CHAP Challenge. + +5.41. NAS-Port-Type + + Description + + This Attribute indicates the type of the physical port of the NAS + which is authenticating the user. It can be used instead of or in + addition to the NAS-Port (5) attribute. It is only used in + Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or + both SHOULD be present in an Access-Request packet, if the NAS + differentiates among its ports. + + A summary of the NAS-Port-Type Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 61 for NAS-Port-Type. + + Length + + 6 + + Value + + The Value field is four octets. "Virtual" refers to a connection + to the NAS via some transport protocol, instead of through a + physical port. For example, if a user telnetted into a NAS to + + + + +Rigney, et al. Standards Track [Page 60] + +RFC 2865 RADIUS June 2000 + + + authenticate himself as an Outbound-User, the Access-Request might + include NAS-Port-Type = Virtual as a hint to the RADIUS server + that the user was not on a physical port. + + 0 Async + 1 Sync + 2 ISDN Sync + 3 ISDN Async V.120 + 4 ISDN Async V.110 + 5 Virtual + 6 PIAFS + 7 HDLC Clear Channel + 8 X.25 + 9 X.75 + 10 G.3 Fax + 11 SDSL - Symmetric DSL + 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase + Modulation + 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone + 14 IDSL - ISDN Digital Subscriber Line + 15 Ethernet + 16 xDSL - Digital Subscriber Line of unknown type + 17 Cable + 18 Wireless - Other + 19 Wireless - IEEE 802.11 + + PIAFS is a form of wireless ISDN commonly used in Japan, and + stands for PHS (Personal Handyphone System) Internet Access Forum + Standard (PIAFS). + +5.42. Port-Limit + + Description + + This Attribute sets the maximum number of ports to be provided to + the user by the NAS. This Attribute MAY be sent by the server to + the client in an Access-Accept packet. It is intended for use in + conjunction with Multilink PPP [12] or similar uses. It MAY also + be sent by the NAS to the server as a hint that that many ports + are desired for use, but the server is not required to honor the + hint. + + A summary of the Port-Limit Attribute format is shown below. The + fields are transmitted from left to right. + + + + + + + +Rigney, et al. Standards Track [Page 61] + +RFC 2865 RADIUS June 2000 + + + 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 62 for Port-Limit. + + Length + + 6 + + Value + + The field is 4 octets, containing a 32-bit unsigned integer with + the maximum number of ports this user should be allowed to connect + to on the NAS. + +5.43. Login-LAT-Port + + Description + + This Attribute indicates the Port with which the user is to be + connected by LAT. It MAY be used in Access-Accept packets, but + only when LAT is specified as the Login-Service. It MAY be used + in an Access-Request packet as a hint to the server, but the + server is not required to honor the hint. + + A summary of the Login-LAT-Port Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 63 for Login-LAT-Port. + + Length + + >= 3 + + + +Rigney, et al. Standards Track [Page 62] + +RFC 2865 RADIUS June 2000 + + + String + + The String field is one or more octets, and contains the identity + of the LAT port to use. The LAT Architecture allows this string + to contain $ (dollar), - (hyphen), . (period), _ (underscore), + numerics, upper and lower case alphabetics, and the ISO Latin-1 + character set extension. All LAT string comparisons are case + insensitive. + +5.44. Table of Attributes + + The following table provides a guide to which attributes may be found + in which kinds of packets, and in what quantity. + + Request Accept Reject Challenge # Attribute + 0-1 0-1 0 0 1 User-Name + 0-1 0 0 0 2 User-Password [Note 1] + 0-1 0 0 0 3 CHAP-Password [Note 1] + 0-1 0 0 0 4 NAS-IP-Address [Note 2] + 0-1 0 0 0 5 NAS-Port + 0-1 0-1 0 0 6 Service-Type + 0-1 0-1 0 0 7 Framed-Protocol + 0-1 0-1 0 0 8 Framed-IP-Address + 0-1 0-1 0 0 9 Framed-IP-Netmask + 0 0-1 0 0 10 Framed-Routing + 0 0+ 0 0 11 Filter-Id + 0-1 0-1 0 0 12 Framed-MTU + 0+ 0+ 0 0 13 Framed-Compression + 0+ 0+ 0 0 14 Login-IP-Host + 0 0-1 0 0 15 Login-Service + 0 0-1 0 0 16 Login-TCP-Port + 0 0+ 0+ 0+ 18 Reply-Message + 0-1 0-1 0 0 19 Callback-Number + 0 0-1 0 0 20 Callback-Id + 0 0+ 0 0 22 Framed-Route + 0 0-1 0 0 23 Framed-IPX-Network + 0-1 0-1 0 0-1 24 State [Note 1] + 0 0+ 0 0 25 Class + 0+ 0+ 0 0+ 26 Vendor-Specific + 0 0-1 0 0-1 27 Session-Timeout + 0 0-1 0 0-1 28 Idle-Timeout + 0 0-1 0 0 29 Termination-Action + 0-1 0 0 0 30 Called-Station-Id + 0-1 0 0 0 31 Calling-Station-Id + 0-1 0 0 0 32 NAS-Identifier [Note 2] + 0+ 0+ 0+ 0+ 33 Proxy-State + 0-1 0-1 0 0 34 Login-LAT-Service + 0-1 0-1 0 0 35 Login-LAT-Node + + + +Rigney, et al. Standards Track [Page 63] + +RFC 2865 RADIUS June 2000 + + + 0-1 0-1 0 0 36 Login-LAT-Group + 0 0-1 0 0 37 Framed-AppleTalk-Link + 0 0+ 0 0 38 Framed-AppleTalk-Network + 0 0-1 0 0 39 Framed-AppleTalk-Zone + 0-1 0 0 0 60 CHAP-Challenge + 0-1 0 0 0 61 NAS-Port-Type + 0-1 0-1 0 0 62 Port-Limit + 0-1 0-1 0 0 63 Login-LAT-Port + Request Accept Reject Challenge # Attribute + + [Note 1] An Access-Request MUST contain either a User-Password or a + CHAP-Password or State. An Access-Request MUST NOT contain both a + User-Password and a CHAP-Password. If future extensions allow other + kinds of authentication information to be conveyed, the attribute for + that can be used in an Access-Request instead of User-Password or + CHAP-Password. + + [Note 2] An Access-Request MUST contain either a NAS-IP-Address or a + NAS-Identifier (or both). + + The following table defines the meaning of the above table entries. + +0 This attribute MUST NOT be present in packet. +0+ Zero or more instances of this attribute MAY be present in packet. +0-1 Zero or one instance of this attribute MAY be present in packet. +1 Exactly one instance of this attribute MUST be present in packet. + +6. IANA Considerations + + This section provides guidance to the Internet Assigned Numbers + Authority (IANA) regarding registration of values related to the + RADIUS protocol, in accordance with BCP 26 [13]. + + There are three name spaces in RADIUS that require registration: + Packet Type Codes, Attribute Types, and Attribute Values (for certain + Attributes). + + RADIUS is not intended as a general-purpose Network Access Server + (NAS) management protocol, and allocations should not be made for + purposes unrelated to Authentication, Authorization or Accounting. + +6.1. Definition of Terms + + The following terms are used here with the meanings defined in + BCP 26: "name space", "assigned value", "registration". + + + + + + +Rigney, et al. Standards Track [Page 64] + +RFC 2865 RADIUS June 2000 + + + The following policies are used here with the meanings defined in + BCP 26: "Private Use", "First Come First Served", "Expert Review", + "Specification Required", "IETF Consensus", "Standards Action". + +6.2. Recommended Registration Policies + + For registration requests where a Designated Expert should be + consulted, the IESG Area Director for Operations should appoint the + Designated Expert. + + For registration requests requiring Expert Review, the ietf-radius + mailing list should be consulted. + + Packet Type Codes have a range from 1 to 254, of which 1-5,11-13 have + been allocated. Because a new Packet Type has considerable impact on + interoperability, a new Packet Type Code requires Standards Action, + and should be allocated starting at 14. + + Attribute Types have a range from 1 to 255, and are the scarcest + resource in RADIUS, thus must be allocated with care. Attributes + 1-53,55,60-88,90-91 have been allocated, with 17 and 21 available for + re-use. Attributes 17, 21, 54, 56-59, 89, 92-191 may be allocated + following Expert Review, with Specification Required. Release of + blocks of Attribute Types (more than 3 at a time for a given purpose) + should require IETF Consensus. It is recommended that attributes 17 + and 21 be used only after all others are exhausted. + + Note that RADIUS defines a mechanism for Vendor-Specific extensions + (Attribute 26) and the use of that should be encouraged instead of + allocation of global attribute types, for functions specific only to + one vendor's implementation of RADIUS, where no interoperability is + deemed useful. + + As stated in the "Attributes" section above: + + "[Attribute Type] Values 192-223 are reserved for experimental + use, values 224-240 are reserved for implementation-specific use, + and values 241-255 are reserved and should not be used." + + Therefore Attribute values 192-240 are considered Private Use, and + values 241-255 require Standards Action. + + Certain attributes (for example, NAS-Port-Type) in RADIUS define a + list of values to correspond with various meanings. There can be 4 + billion (2^32) values for each attribute. Adding additional values to + the list can be done on a First Come, First Served basis by the IANA. + + + + + +Rigney, et al. Standards Track [Page 65] + +RFC 2865 RADIUS June 2000 + + +7. Examples + + A few examples are presented to illustrate the flow of packets and + use of typical attributes. These examples are not intended to be + exhaustive, many others are possible. Hexadecimal dumps of the + example packets are given in network byte order, using the shared + secret "xyzzy5461". + +7.1. User Telnet to Specified Host + + The NAS at 192.168.1.16 sends an Access-Request UDP packet to the + RADIUS Server for a user named nemo logging in on port 3 with + password "arctangent". + + The Request Authenticator is a 16 octet random number generated by + the NAS. + + The User-Password is 16 octets of password padded at end with nulls, + XORed with MD5(shared secret|Request Authenticator). + + 01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb + 98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d + 93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8 + 01 10 05 06 00 00 00 03 + + 1 Code = Access-Request (1) + 1 ID = 0 + 2 Length = 56 + 16 Request Authenticator + + Attributes: + 6 User-Name = "nemo" + 18 User-Password + 6 NAS-IP-Address = 192.168.1.16 + 6 NAS-Port = 3 + + The RADIUS server authenticates nemo, and sends an Access-Accept UDP + packet to the NAS telling it to telnet nemo to host 192.168.1.3. + + The Response Authenticator is a 16-octet MD5 checksum of the code + (2), id (0), Length (38), the Request Authenticator from above, the + attributes in this reply, and the shared secret. + + + + + + + + + +Rigney, et al. Standards Track [Page 66] + +RFC 2865 RADIUS June 2000 + + + 02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf + 9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00 + 0e 06 c0 a8 01 03 + + 1 Code = Access-Accept (2) + 1 ID = 0 (same as in Access-Request) + 2 Length = 38 + 16 Response Authenticator + + Attributes: + 6 Service-Type (6) = Login (1) + 6 Login-Service (15) = Telnet (0) + 6 Login-IP-Host (14) = 192.168.1.3 + +7.2. Framed User Authenticating with CHAP + + The NAS at 192.168.1.16 sends an Access-Request UDP packet to the + RADIUS Server for a user named flopsy logging in on port 20 with PPP, + authenticating using CHAP. The NAS sends along the Service-Type and + Framed-Protocol attributes as a hint to the RADIUS server that this + user is looking for PPP, although the NAS is not required to do so. + + The Request Authenticator is a 16 octet random number generated by + the NAS, and is also used as the CHAP Challenge. + + The CHAP-Password consists of a 1 octet CHAP ID, in this case 22, + followed by the 16 octet CHAP response. + + 01 01 00 47 2a ee 86 f0 8d 0d 55 96 9c a5 97 8e + 0d 33 67 a2 01 08 66 6c 6f 70 73 79 03 13 16 e9 + 75 57 c3 16 18 58 95 f2 93 ff 63 44 07 72 75 04 + 06 c0 a8 01 10 05 06 00 00 00 14 06 06 00 00 00 + 02 07 06 00 00 00 01 + + 1 Code = 1 (Access-Request) + 1 ID = 1 + 2 Length = 71 + 16 Request Authenticator + + Attributes: + 8 User-Name (1) = "flopsy" + 19 CHAP-Password (3) + 6 NAS-IP-Address (4) = 192.168.1.16 + 6 NAS-Port (5) = 20 + 6 Service-Type (6) = Framed (2) + 6 Framed-Protocol (7) = PPP (1) + + + + + +Rigney, et al. Standards Track [Page 67] + +RFC 2865 RADIUS June 2000 + + + The RADIUS server authenticates flopsy, and sends an Access-Accept + UDP packet to the NAS telling it to start PPP service and assign an + address for the user out of its dynamic address pool. + + The Response Authenticator is a 16-octet MD5 checksum of the code + (2), id (1), Length (56), the Request Authenticator from above, the + attributes in this reply, and the shared secret. + + 02 01 00 38 15 ef bc 7d ab 26 cf a3 dc 34 d9 c0 + 3c 86 01 a4 06 06 00 00 00 02 07 06 00 00 00 01 + 08 06 ff ff ff fe 0a 06 00 00 00 02 0d 06 00 00 + 00 01 0c 06 00 00 05 dc + + 1 Code = Access-Accept (2) + 1 ID = 1 (same as in Access-Request) + 2 Length = 56 + 16 Response Authenticator + + Attributes: + 6 Service-Type (6) = Framed (2) + 6 Framed-Protocol (7) = PPP (1) + 6 Framed-IP-Address (8) = 255.255.255.254 + 6 Framed-Routing (10) = None (0) + 6 Framed-Compression (13) = VJ TCP/IP Header Compression (1) + 6 Framed-MTU (12) = 1500 + +7.3. User with Challenge-Response card + + The NAS at 192.168.1.16 sends an Access-Request UDP packet to the + RADIUS Server for a user named mopsy logging in on port 7. The user + enters the dummy password "challenge" in this example. The challenge + and response generated by the smart card for this example are + "32769430" and "99101462". + + The Request Authenticator is a 16 octet random number generated by + the NAS. + + The User-Password is 16 octets of password, in this case "challenge", + padded at the end with nulls, XORed with MD5(shared secret|Request + Authenticator). + + 01 02 00 39 f3 a4 7a 1f 6a 6d 76 71 0b 94 7a b9 + 30 41 a0 39 01 07 6d 6f 70 73 79 02 12 33 65 75 + 73 77 82 89 b5 70 88 5e 15 08 48 25 c5 04 06 c0 + a8 01 10 05 06 00 00 00 07 + + + + + + +Rigney, et al. Standards Track [Page 68] + +RFC 2865 RADIUS June 2000 + + + 1 Code = Access-Request (1) + 1 ID = 2 + 2 Length = 57 + 16 Request Authenticator + + Attributes: + 7 User-Name (1) = "mopsy" + 18 User-Password (2) + 6 NAS-IP-Address (4) = 192.168.1.16 + 6 NAS-Port (5) = 7 + + The RADIUS server decides to challenge mopsy, sending back a + challenge string and looking for a response. The RADIUS server + therefore and sends an Access-Challenge UDP packet to the NAS. + + The Response Authenticator is a 16-octet MD5 checksum of the code + (11), id (2), length (78), the Request Authenticator from above, the + attributes in this reply, and the shared secret. + + The Reply-Message is "Challenge 32769430. Enter response at prompt." + + The State is a magic cookie to be returned along with user's + response; in this example 8 octets of data (33 32 37 36 39 34 33 30 + in hex). + + 0b 02 00 4e 36 f3 c8 76 4a e8 c7 11 57 40 3c 0c + 71 ff 9c 45 12 30 43 68 61 6c 6c 65 6e 67 65 20 + 33 32 37 36 39 34 33 30 2e 20 20 45 6e 74 65 72 + 20 72 65 73 70 6f 6e 73 65 20 61 74 20 70 72 6f + 6d 70 74 2e 18 0a 33 32 37 36 39 34 33 30 + + 1 Code = Access-Challenge (11) + 1 ID = 2 (same as in Access-Request) + 2 Length = 78 + 16 Response Authenticator + + Attributes: + 48 Reply-Message (18) + 10 State (24) + + The user enters his response, and the NAS send a new Access-Request + with that response, and includes the State Attribute. + + The Request Authenticator is a new 16 octet random number. + + The User-Password is 16 octets of the user's response, in this case + "99101462", padded at the end with nulls, XORed with MD5(shared + secret|Request Authenticator). + + + +Rigney, et al. Standards Track [Page 69] + +RFC 2865 RADIUS June 2000 + + + The state is the magic cookie from the Access-Challenge packet, + unchanged. + + 01 03 00 43 b1 22 55 6d 42 8a 13 d0 d6 25 38 07 + c4 57 ec f0 01 07 6d 6f 70 73 79 02 12 69 2c 1f + 20 5f c0 81 b9 19 b9 51 95 f5 61 a5 81 04 06 c0 + a8 01 10 05 06 00 00 00 07 18 10 33 32 37 36 39 + 34 33 30 + + 1 Code = Access-Request (1) + 1 ID = 3 (Note that this changes.) + 2 Length = 67 + 16 Request Authenticator + + Attributes: + 7 User-Name = "mopsy" + 18 User-Password + 6 NAS-IP-Address (4) = 192.168.1.16 + 6 NAS-Port (5) = 7 + 10 State (24) + + The Response was incorrect (for the sake of example), so the RADIUS + server tells the NAS to reject the login attempt. + + The Response Authenticator is a 16 octet MD5 checksum of the code + (3), id (3), length(20), the Request Authenticator from above, the + attributes in this reply (in this case, none), and the shared secret. + + 03 03 00 14 a4 2f 4f ca 45 91 6c 4e 09 c8 34 0f + 9e 74 6a a0 + + 1 Code = Access-Reject (3) + 1 ID = 3 (same as in Access-Request) + 2 Length = 20 + 16 Response Authenticator + + Attributes: + (none, although a Reply-Message could be sent) + + + + + + + + + + + + + +Rigney, et al. Standards Track [Page 70] + +RFC 2865 RADIUS June 2000 + + +8. Security Considerations + + Security issues are the primary topic of this document. + + In practice, within or associated with each RADIUS server, there is a + database which associates "user" names with authentication + information ("secrets"). It is not anticipated that a particular + named user would be authenticated by multiple methods. This would + make the user vulnerable to attacks which negotiate the least secure + method from among a set. Instead, for each named user there should + be an indication of exactly one method used to authenticate that user + name. If a user needs to make use of different authentication + methods under different circumstances, then distinct user names + SHOULD be employed, each of which identifies exactly one + authentication method. + + Passwords and other secrets should be stored at the respective ends + such that access to them is as limited as possible. Ideally, the + secrets should only be accessible to the process requiring access in + order to perform the authentication. + + The secrets should be distributed with a mechanism that limits the + number of entities that handle (and thus gain knowledge of) the + secret. Ideally, no unauthorized person should ever gain knowledge + of the secrets. It is possible to achieve this with SNMP Security + Protocols [14], but such a mechanism is outside the scope of this + specification. + + Other distribution methods are currently undergoing research and + experimentation. The SNMP Security document [14] also has an + excellent overview of threats to network protocols. + + The User-Password hiding mechanism described in Section 5.2 has not + been subjected to significant amounts of cryptanalysis in the + published literature. Some in the IETF community are concerned that + this method might not provide sufficient confidentiality protection + [15] to passwords transmitted using RADIUS. Users should evaluate + their threat environment and consider whether additional security + mechanisms should be employed. + +9. Change Log + + The following changes have been made from RFC 2138: + + Strings should use UTF-8 instead of US-ASCII and should be handled as + 8-bit data. + + Integers and dates are now defined as 32 bit unsigned values. + + + +Rigney, et al. Standards Track [Page 71] + +RFC 2865 RADIUS June 2000 + + + Updated list of attributes that can be included in Access-Challenge + to be consistent with the table of attributes. + + User-Name mentions Network Access Identifiers. + + User-Name may now be sent in Access-Accept for use with accounting + and Rlogin. + + Values added for Service-Type, Login-Service, Framed-Protocol, + Framed-Compression, and NAS-Port-Type. + + NAS-Port can now use all 32 bits. + + Examples now include hexadecimal displays of the packets. + + Source UDP port must be used in conjunction with the Request + Identifier when identifying duplicates. + + Multiple subattributes may be allowed in a Vendor-Specific attribute. + + An Access-Request is now required to contain either a NAS-IP-Address + or NAS-Identifier (or may contain both). + + Added notes under "Operations" with more information on proxy, + retransmissions, and keep-alives. + + If multiple Attributes with the same Type are present, the order of + Attributes with the same Type MUST be preserved by any proxies. + + Clarified Proxy-State. + + Clarified that Attributes must not depend on position within the + packet, as long as Attributes of the same type are kept in order. + + Added IANA Considerations section. + + Updated section on "Proxy" under "Operations". + + Framed-MTU can now be sent in Access-Request as a hint. + + Updated Security Considerations. + + Text strings identified as a subset of string, to clarify use of + UTF-8. + + + + + + + +Rigney, et al. Standards Track [Page 72] + +RFC 2865 RADIUS June 2000 + + +10. References + + [1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote + Authentication Dial In User Service (RADIUS)", RFC 2138, April + 1997. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March, 1997. + + [3] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", + RFC 1321, April 1992. + + [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August + 1980. + + [5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + + [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC + 1700, October 1994. + + [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC + 2279, January 1998. + + [8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC + 2486, January 1999. + + [9] Kaufman, C., Perlman, R., and Speciner, M., "Network Security: + Private Communications in a Public World", Prentice Hall, March + 1995, ISBN 0-13-061466-1. + + [10] Jacobson, V., "Compressing TCP/IP headers for low-speed serial + links", RFC 1144, February 1990. + + [11] ISO 8859. International Standard -- Information Processing -- + 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin + Alphabet No. 1, ISO 8859-1:1987. + + [12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. + Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August + 1996. + + [13] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October + 1998. + + [14] Galvin, J., McCloghrie, K. and J. Davin, "SNMP Security + Protocols", RFC 1352, July 1992. + + + + +Rigney, et al. Standards Track [Page 73] + +RFC 2865 RADIUS June 2000 + + + [15] Dobbertin, H., "The Status of MD5 After a Recent Attack", + CryptoBytes Vol.2 No.2, Summer 1996. + +11. Acknowledgements + + RADIUS was originally developed by Steve Willens of Livingston + Enterprises for their PortMaster series of Network Access Servers. + +12. Chair's Address + + The working group can be contacted via the current chair: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + Phone: +1 925 737 2100 + EMail: cdr@telemancy.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rigney, et al. Standards Track [Page 74] + +RFC 2865 RADIUS June 2000 + + +13. Authors' Addresses + + Questions about this memo can also be directed to: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + Phone: +1 925 737 2100 + EMail: cdr@telemancy.com + + + Allan C. Rubens + Merit Network, Inc. + 4251 Plymouth Road + Ann Arbor, Michigan 48105-2785 + + EMail: acr@merit.edu + + + William Allen Simpson + Daydreamer + Computer Systems Consulting Services + 1384 Fontaine + Madison Heights, Michigan 48071 + + EMail: wsimpson@greendragon.com + + + Steve Willens + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + EMail: steve@livingston.com + + + + + + + + + + + + + + + +Rigney, et al. Standards Track [Page 75] + +RFC 2865 RADIUS June 2000 + + +14. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Rigney, et al. Standards Track [Page 76] + diff --git a/rfc/rfc2866.txt b/rfc/rfc2866.txt new file mode 100644 index 00000000..82da1dcc --- /dev/null +++ b/rfc/rfc2866.txt @@ -0,0 +1,1571 @@ + + + + + + +Network Working Group C. Rigney +Request for Comments: 2866 Livingston +Category: Informational June 2000 +Obsoletes: 2139 + + + RADIUS Accounting + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This document describes a protocol for carrying accounting + information between a Network Access Server and a shared Accounting + Server. + +Implementation Note + + This memo documents the RADIUS Accounting protocol. The early + deployment of RADIUS Accounting was done using UDP port number 1646, + which conflicts with the "sa-msg-port" service. The officially + assigned port number for RADIUS Accounting is 1813. + +Table of Contents + + 1. Introduction .................................... 2 + 1.1 Specification of Requirements ................. 3 + 1.2 Terminology ................................... 3 + 2. Operation ....................................... 4 + 2.1 Proxy ......................................... 4 + 3. Packet Format ................................... 5 + 4. Packet Types ................................... 7 + 4.1 Accounting-Request ............................ 8 + 4.2 Accounting-Response ........................... 9 + 5. Attributes ...................................... 10 + 5.1 Acct-Status-Type .............................. 12 + 5.2 Acct-Delay-Time ............................... 13 + 5.3 Acct-Input-Octets ............................. 14 + 5.4 Acct-Output-Octets ............................ 15 + 5.5 Acct-Session-Id ............................... 15 + + + +Rigney Informational [Page 1] + +RFC 2866 RADIUS Accounting June 2000 + + + 5.6 Acct-Authentic ................................ 16 + 5.7 Acct-Session-Time ............................. 17 + 5.8 Acct-Input-Packets ............................ 18 + 5.9 Acct-Output-Packets ........................... 18 + 5.10 Acct-Terminate-Cause .......................... 19 + 5.11 Acct-Multi-Session-Id ......................... 21 + 5.12 Acct-Link-Count ............................... 22 + 5.13 Table of Attributes ........................... 23 + 6. IANA Considerations ............................. 25 + 7. Security Considerations ......................... 25 + 8. Change Log ...................................... 25 + 9. References ...................................... 26 + 10. Acknowledgements ................................ 26 + 11. Chair's Address ................................. 26 + 12. Author's Address ................................ 27 + 13. Full Copyright Statement ........................ 28 + +1. Introduction + + Managing dispersed serial line and modem pools for large numbers of + users can create the need for significant administrative support. + Since modem pools are by definition a link to the outside world, they + require careful attention to security, authorization and accounting. + This can be best achieved by managing a single "database" of users, + which allows for authentication (verifying user name and password) as + well as configuration information detailing the type of service to + deliver to the user (for example, SLIP, PPP, telnet, rlogin). + + The RADIUS (Remote Authentication Dial In User Service) document [2] + specifies the RADIUS protocol used for Authentication and + Authorization. This memo extends the use of the RADIUS protocol to + cover delivery of accounting information from the Network Access + Server (NAS) to a RADIUS accounting server. + + This document obsoletes RFC 2139 [1]. A summary of the changes + between this document and RFC 2139 is available in the "Change Log" + appendix. + + Key features of RADIUS Accounting are: + + Client/Server Model + + A Network Access Server (NAS) operates as a client of the + RADIUS accounting server. The client is responsible for + passing user accounting information to a designated RADIUS + accounting server. + + + + + +Rigney Informational [Page 2] + +RFC 2866 RADIUS Accounting June 2000 + + + The RADIUS accounting server is responsible for receiving the + accounting request and returning a response to the client + indicating that it has successfully received the request. + + The RADIUS accounting server can act as a proxy client to + other kinds of accounting servers. + + Network Security + + Transactions between the client and RADIUS accounting server + are authenticated through the use of a shared secret, which is + never sent over the network. + + Extensible Protocol + + All transactions are comprised of variable length Attribute- + Length-Value 3-tuples. New attribute values can be added + without disturbing existing implementations of the protocol. + +1.1. Specification of Requirements + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [3]. These + key words mean the same thing whether capitalized or not. + +1.2. Terminology + + This document uses the following terms: + + service The NAS provides a service to the dial-in user, such as PPP + or Telnet. + + session Each service provided by the NAS to a dial-in user + constitutes a session, with the beginning of the session + defined as the point where service is first provided and + the end of the session defined as the point where service + is ended. A user may have multiple sessions in parallel or + series if the NAS supports that, with each session + generating a separate start and stop accounting record with + its own Acct-Session-Id. + + silently discard + This means the implementation discards the packet without + further processing. The implementation SHOULD provide the + capability of logging the error, including the contents of + the silently discarded packet, and SHOULD record the event + in a statistics counter. + + + +Rigney Informational [Page 3] + +RFC 2866 RADIUS Accounting June 2000 + + +2. Operation + + When a client is configured to use RADIUS Accounting, at the start of + service delivery it will generate an Accounting Start packet + describing the type of service being delivered and the user it is + being delivered to, and will send that to the RADIUS Accounting + server, which will send back an acknowledgement that the packet has + been received. At the end of service delivery the client will + generate an Accounting Stop packet describing the type of service + that was delivered and optionally statistics such as elapsed time, + input and output octets, or input and output packets. It will send + that to the RADIUS Accounting server, which will send back an + acknowledgement that the packet has been received. + + The Accounting-Request (whether for Start or Stop) is submitted to + the RADIUS accounting server via the network. It is recommended that + the client continue attempting to send the Accounting-Request packet + until it receives an acknowledgement, using some form of backoff. If + no response is returned within a length of time, the request is re- + sent a number of times. The client can also forward requests to an + alternate server or servers in the event that the primary server is + down or unreachable. An alternate server can be used either after a + number of tries to the primary server fail, or in a round-robin + fashion. Retry and fallback algorithms are the topic of current + research and are not specified in detail in this document. + + The RADIUS accounting server MAY make requests of other servers in + order to satisfy the request, in which case it acts as a client. + + If the RADIUS accounting server is unable to successfully record the + accounting packet it MUST NOT send an Accounting-Response + acknowledgment to the client. + +2.1. Proxy + + See the "RADIUS" RFC [2] for information on Proxy RADIUS. Proxy + Accounting RADIUS works the same way, as illustrated by the following + example. + + 1. The NAS sends an accounting-request to the forwarding server. + + 2. The forwarding server logs the accounting-request (if desired), + adds its Proxy-State (if desired) after any other Proxy-State + attributes, updates the Request Authenticator, and forwards the + request to the remote server. + + + + + + +Rigney Informational [Page 4] + +RFC 2866 RADIUS Accounting June 2000 + + + 3. The remote server logs the accounting-request (if desired), + copies all Proxy-State attributes in order and unmodified from + the request to the response packet, and sends the accounting- + response to the forwarding server. + + 4. The forwarding server strips the last Proxy-State (if it added + one in step 2), updates the Response Authenticator and sends + the accounting-response to the NAS. + + A forwarding server MUST not modify existing Proxy-State or Class + attributes present in the packet. + + A forwarding server may either perform its forwarding function in a + pass through manner, where it sends retransmissions on as soon as it + gets them, or it may take responsibility for retransmissions, for + example in cases where the network link between forwarding and remote + server has very different characteristics than the link between NAS + and forwarding server. + + Extreme care should be used when implementing a proxy server that + takes responsibility for retransmissions so that its retransmission + policy is robust and scalable. + +3. Packet Format + + Exactly one RADIUS Accounting packet is encapsulated in the UDP Data + field [4], where the UDP Destination Port field indicates 1813 + (decimal). + + When a reply is generated, the source and destination ports are + reversed. + + This memo documents the RADIUS Accounting protocol. The early + deployment of RADIUS Accounting was done using UDP port number 1646, + which conflicts with the "sa-msg-port" service. The officially + assigned port number for RADIUS Accounting is 1813. + + A summary of the RADIUS data format is shown below. The fields are + transmitted from left to right. + + + + + + + + + + + + +Rigney Informational [Page 5] + +RFC 2866 RADIUS Accounting June 2000 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + + Code + + The Code field is one octet, and identifies the type of RADIUS + packet. When a packet is received with an invalid Code field, it + is silently discarded. + + RADIUS Accounting Codes (decimal) are assigned as follows: + + 4 Accounting-Request + 5 Accounting-Response + + Identifier + + The Identifier field is one octet, and aids in matching requests + and replies. The RADIUS server can detect a duplicate request if + it has the same client source IP address and source UDP port and + Identifier within a short span of time. + + Length + + The Length field is two octets. It indicates the length of the + packet including the Code, Identifier, Length, Authenticator and + Attribute fields. Octets outside the range of the Length field + MUST be treated as padding and ignored on reception. If the + packet is shorter than the Length field indicates, it MUST be + silently discarded. The minimum length is 20 and maximum length + is 4095. + + Authenticator + + The Authenticator field is sixteen (16) octets. The most + significant octet is transmitted first. This value is used to + authenticate the messages between the client and RADIUS accounting + server. + + + +Rigney Informational [Page 6] + +RFC 2866 RADIUS Accounting June 2000 + + + Request Authenticator + + In Accounting-Request Packets, the Authenticator value is a 16 + octet MD5 [5] checksum, called the Request Authenticator. + + The NAS and RADIUS accounting server share a secret. The Request + Authenticator field in Accounting-Request packets contains a one- + way MD5 hash calculated over a stream of octets consisting of the + Code + Identifier + Length + 16 zero octets + request attributes + + shared secret (where + indicates concatenation). The 16 octet MD5 + hash value is stored in the Authenticator field of the + Accounting-Request packet. + + Note that the Request Authenticator of an Accounting-Request can + not be done the same way as the Request Authenticator of a RADIUS + Access-Request, because there is no User-Password attribute in an + Accounting-Request. + + Response Authenticator + + The Authenticator field in an Accounting-Response packet is called + the Response Authenticator, and contains a one-way MD5 hash + calculated over a stream of octets consisting of the Accounting- + Response Code, Identifier, Length, the Request Authenticator field + from the Accounting-Request packet being replied to, and the + response attributes if any, followed by the shared secret. The + resulting 16 octet MD5 hash value is stored in the Authenticator + field of the Accounting-Response packet. + + Attributes + + Attributes may have multiple instances, in such a case the order + of attributes of the same type SHOULD be preserved. The order of + attributes of different types is not required to be preserved. + +4. Packet Types + + The RADIUS packet type is determined by the Code field in the first + octet of the packet. + + + + + + + + + + + + +Rigney Informational [Page 7] + +RFC 2866 RADIUS Accounting June 2000 + + +4.1. Accounting-Request + + Description + + Accounting-Request packets are sent from a client (typically a + Network Access Server or its proxy) to a RADIUS accounting server, + and convey information used to provide accounting for a service + provided to a user. The client transmits a RADIUS packet with the + Code field set to 4 (Accounting-Request). + + Upon receipt of an Accounting-Request, the server MUST transmit an + Accounting-Response reply if it successfully records the + accounting packet, and MUST NOT transmit any reply if it fails to + record the accounting packet. + + Any attribute valid in a RADIUS Access-Request or Access-Accept + packet is valid in a RADIUS Accounting-Request packet, except that + the following attributes MUST NOT be present in an Accounting- + Request: User-Password, CHAP-Password, Reply-Message, State. + Either NAS-IP-Address or NAS-Identifier MUST be present in a + RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS- + Port-Type attribute or both unless the service does not involve a + port or the NAS does not distinguish among its ports. + + If the Accounting-Request packet includes a Framed-IP-Address, + that attribute MUST contain the IP address of the user. If the + Access-Accept used the special values for Framed-IP-Address + telling the NAS to assign or negotiate an IP address for the user, + the Framed-IP-Address (if any) in the Accounting-Request MUST + contain the actual IP address assigned or negotiated. + + A summary of the Accounting-Request packet format is shown below. + + The fields are transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Request Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + + + +Rigney Informational [Page 8] + +RFC 2866 RADIUS Accounting June 2000 + + + Code + + 4 for Accounting-Request. + + Identifier + + The Identifier field MUST be changed whenever the content of the + Attributes field changes, and whenever a valid reply has been + received for a previous request. For retransmissions where the + contents are identical, the Identifier MUST remain unchanged. + + Note that if Acct-Delay-Time is included in the attributes of an + Accounting-Request then the Acct-Delay-Time value will be updated + when the packet is retransmitted, changing the content of the + Attributes field and requiring a new Identifier and Request + Authenticator. + + Request Authenticator + + The Request Authenticator of an Accounting-Request contains a 16-octet + MD5 hash value calculated according to the method described in + "Request Authenticator" above. + + Attributes + + The Attributes field is variable in length, and contains a list of + Attributes. + +4.2. Accounting-Response + + Description + + Accounting-Response packets are sent by the RADIUS accounting + server to the client to acknowledge that the Accounting-Request + has been received and recorded successfully. If the Accounting- + Request was recorded successfully then the RADIUS accounting + server MUST transmit a packet with the Code field set to 5 + (Accounting-Response). On reception of an Accounting-Response by + the client, the Identifier field is matched with a pending + Accounting-Request. The Response Authenticator field MUST contain + the correct response for the pending Accounting-Request. Invalid + packets are silently discarded. + + A RADIUS Accounting-Response is not required to have any + attributes in it. + + A summary of the Accounting-Response packet format is shown below. + The fields are transmitted from left to right. + + + +Rigney Informational [Page 9] + +RFC 2866 RADIUS Accounting June 2000 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Response Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 5 for Accounting-Response. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Accounting-Request which caused this Accounting-Response. + + Response Authenticator + + The Response Authenticator of an Accounting-Response contains a + 16-octet MD5 hash value calculated according to the method + described in "Response Authenticator" above. + + Attributes + + The Attributes field is variable in length, and contains a list of + zero or more Attributes. + +5. Attributes + + RADIUS Attributes carry the specific authentication, authorization + and accounting details for the request and response. + + Some attributes MAY be included more than once. The effect of this + is attribute specific, and is specified in each attribute + description. + + The end of the list of attributes is indicated by the Length of the + RADIUS packet. + + A summary of the attribute format is shown below. The fields are + transmitted from left to right. + + + + +Rigney Informational [Page 10] + +RFC 2866 RADIUS Accounting June 2000 + + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + The Type field is one octet. Up-to-date values of the RADIUS Type + field are specified in the most recent "Assigned Numbers" RFC [6]. + Values 192-223 are reserved for experimental use, values 224-240 + are reserved for implementation-specific use, and values 241-255 + are reserved and should not be used. This specification concerns + the following values: + + 1-39 (refer to RADIUS document [2]) + 40 Acct-Status-Type + 41 Acct-Delay-Time + 42 Acct-Input-Octets + 43 Acct-Output-Octets + 44 Acct-Session-Id + 45 Acct-Authentic + 46 Acct-Session-Time + 47 Acct-Input-Packets + 48 Acct-Output-Packets + 49 Acct-Terminate-Cause + 50 Acct-Multi-Session-Id + 51 Acct-Link-Count + 60+ (refer to RADIUS document [2]) + + Length + + The Length field is one octet, and indicates the length of this + attribute including the Type, Length and Value fields. If an + attribute is received in an Accounting-Request with an invalid + Length, the entire request MUST be silently discarded. + + Value + + The Value field is zero or more octets and contains information + specific to the attribute. The format and length of the Value + field is determined by the Type and Length fields. + + Note that none of the types in RADIUS terminate with a NUL (hex + 00). In particular, types "text" and "string" in RADIUS do not + terminate with a NUL (hex 00). The Attribute has a length field + and does not use a terminator. Text contains UTF-8 encoded 10646 + + + +Rigney Informational [Page 11] + +RFC 2866 RADIUS Accounting June 2000 + + + [7] characters and String contains 8-bit binary data. Servers and + servers and clients MUST be able to deal with embedded nulls. + RADIUS implementers using C are cautioned not to use strcpy() when + handling strings. + + The format of the value field is one of five data types. Note + that type "text" is a subset of type "string." + + text 1-253 octets containing UTF-8 encoded 10646 [7] + characters. Text of length zero (0) MUST NOT be sent; + omit the entire attribute instead. + + string 1-253 octets containing binary data (values 0 through 255 + decimal, inclusive). Strings of length zero (0) MUST NOT + be sent; omit the entire attribute instead. + + address 32 bit value, most significant octet first. + + integer 32 bit unsigned value, most significant octet first. + + time 32 bit unsigned value, most significant octet first -- + seconds since 00:00:00 UTC, January 1, 1970. The + standard Attributes do not use this data type but it is + presented here for possible use in future attributes. + +5.1. Acct-Status-Type + + Description + + This attribute indicates whether this Accounting-Request marks the + beginning of the user service (Start) or the end (Stop). + + It MAY be used by the client to mark the start of accounting (for + example, upon booting) by specifying Accounting-On and to mark the + end of accounting (for example, just before a scheduled reboot) by + specifying Accounting-Off. + + A summary of the Acct-Status-Type attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Rigney Informational [Page 12] + +RFC 2866 RADIUS Accounting June 2000 + + + Type + + 40 for Acct-Status-Type. + + Length + + 6 + + Value + + The Value field is four octets. + + 1 Start + 2 Stop + 3 Interim-Update + 7 Accounting-On + 8 Accounting-Off + 9-14 Reserved for Tunnel Accounting + 15 Reserved for Failed + +5.2. Acct-Delay-Time + + Description + + This attribute indicates how many seconds the client has been + trying to send this record for, and can be subtracted from the + time of arrival on the server to find the approximate time of the + event generating this Accounting-Request. (Network transit time + is ignored.) + + Note that changing the Acct-Delay-Time causes the Identifier to + change; see the discussion under Identifier above. + + A summary of the Acct-Delay-Time attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + +Rigney Informational [Page 13] + +RFC 2866 RADIUS Accounting June 2000 + + + Type + + 41 for Acct-Delay-Time. + + Length + + 6 + + Value + + The Value field is four octets. + +5.3. Acct-Input-Octets + + Description + + This attribute indicates how many octets have been received from + the port over the course of this service being provided, and can + only be present in Accounting-Request records where the Acct- + Status-Type is set to Stop. + + A summary of the Acct-Input-Octets attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 42 for Acct-Input-Octets. + + Length + + 6 + + Value + + The Value field is four octets. + + + + + + + + +Rigney Informational [Page 14] + +RFC 2866 RADIUS Accounting June 2000 + + +5.4. Acct-Output-Octets + + Description + + This attribute indicates how many octets have been sent to the + port in the course of delivering this service, and can only be + present in Accounting-Request records where the Acct-Status-Type + is set to Stop. + + A summary of the Acct-Output-Octets attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 43 for Acct-Output-Octets. + + Length + + 6 + + Value + + The Value field is four octets. + +5.5. Acct-Session-Id + + Description + + This attribute is a unique Accounting ID to make it easy to match + start and stop records in a log file. The start and stop records + for a given session MUST have the same Acct-Session-Id. An + Accounting-Request packet MUST have an Acct-Session-Id. An + Access-Request packet MAY have an Acct-Session-Id; if it does, + then the NAS MUST use the same Acct-Session-Id in the Accounting- + Request packets for that session. + + The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7] + characters. + + + + + +Rigney Informational [Page 15] + +RFC 2866 RADIUS Accounting June 2000 + + + For example, one implementation uses a string with an 8-digit + upper case hexadecimal number, the first two digits increment on + each reboot (wrapping every 256 reboots) and the next 6 digits + counting from 0 for the first person logging in after a reboot up + to 2^24-1, about 16 million. Other encodings are possible. + + A summary of the Acct-Session-Id attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Text ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 44 for Acct-Session-Id. + + Length + + >= 3 + + String + + The String field SHOULD be a string of UTF-8 encoded 10646 [7] + characters. + +5.6. Acct-Authentic + + Description + + This attribute MAY be included in an Accounting-Request to + indicate how the user was authenticated, whether by RADIUS, the + NAS itself, or another remote authentication protocol. Users who + are delivered service without being authenticated SHOULD NOT + generate Accounting records. + + A summary of the Acct-Authentic attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Rigney Informational [Page 16] + +RFC 2866 RADIUS Accounting June 2000 + + + Type + + 45 for Acct-Authentic. + + Length + + 6 + + Value + + The Value field is four octets. + + 1 RADIUS + 2 Local + 3 Remote + +5.7. Acct-Session-Time + + Description + + This attribute indicates how many seconds the user has received + service for, and can only be present in Accounting-Request records + where the Acct-Status-Type is set to Stop. + + A summary of the Acct-Session-Time attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 46 for Acct-Session-Time. + + Length + + 6 + + Value + + The Value field is four octets. + + + + + +Rigney Informational [Page 17] + +RFC 2866 RADIUS Accounting June 2000 + + +5.8. Acct-Input-Packets + + Description + + This attribute indicates how many packets have been received from + the port over the course of this service being provided to a + Framed User, and can only be present in Accounting-Request records + where the Acct-Status-Type is set to Stop. + + A summary of the Acct-Input-packets attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 47 for Acct-Input-Packets. + + Length + + 6 + + Value + + The Value field is four octets. + +5.9. Acct-Output-Packets + + Description + + This attribute indicates how many packets have been sent to the + port in the course of delivering this service to a Framed User, + and can only be present in Accounting-Request records where the + Acct-Status-Type is set to Stop. + + A summary of the Acct-Output-Packets attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + +Rigney Informational [Page 18] + +RFC 2866 RADIUS Accounting June 2000 + + + 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 48 for Acct-Output-Packets. + + Length + + 6 + + Value + + The Value field is four octets. + +5.10. Acct-Terminate-Cause + + Description + + This attribute indicates how the session was terminated, and can + only be present in Accounting-Request records where the Acct- + Status-Type is set to Stop. + + A summary of the Acct-Terminate-Cause attribute format is shown + below. The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + +Rigney Informational [Page 19] + +RFC 2866 RADIUS Accounting June 2000 + + + Type + + 49 for Acct-Terminate-Cause + + Length + + 6 + + Value + + The Value field is four octets, containing an integer specifying + the cause of session termination, as follows: + + 1 User Request + 2 Lost Carrier + 3 Lost Service + 4 Idle Timeout + 5 Session Timeout + 6 Admin Reset + 7 Admin Reboot + 8 Port Error + 9 NAS Error + 10 NAS Request + 11 NAS Reboot + 12 Port Unneeded + 13 Port Preempted + 14 Port Suspended + 15 Service Unavailable + 16 Callback + 17 User Error + 18 Host Request + + The termination causes are as follows: + + User Request User requested termination of service, for + example with LCP Terminate or by logging out. + + Lost Carrier DCD was dropped on the port. + + Lost Service Service can no longer be provided; for + example, user's connection to a host was + interrupted. + + Idle Timeout Idle timer expired. + + Session Timeout Maximum session length timer expired. + + Admin Reset Administrator reset the port or session. + + + +Rigney Informational [Page 20] + +RFC 2866 RADIUS Accounting June 2000 + + + Admin Reboot Administrator is ending service on the NAS, + for example prior to rebooting the NAS. + + Port Error NAS detected an error on the port which + required ending the session. + + NAS Error NAS detected some error (other than on the + port) which required ending the session. + + NAS Request NAS ended session for a non-error reason not + otherwise listed here. + + NAS Reboot The NAS ended the session in order to reboot + non-administratively ("crash"). + + Port Unneeded NAS ended session because resource usage fell + below low-water mark (for example, if a + bandwidth-on-demand algorithm decided that + the port was no longer needed). + + Port Preempted NAS ended session in order to allocate the + port to a higher priority use. + + Port Suspended NAS ended session to suspend a virtual + session. + + Service Unavailable NAS was unable to provide requested service. + + Callback NAS is terminating current session in order + to perform callback for a new session. + + User Error Input from user is in error, causing + termination of session. + + Host Request Login Host terminated session normally. + +5.11. Acct-Multi-Session-Id + + Description + + This attribute is a unique Accounting ID to make it easy to link + together multiple related sessions in a log file. Each session + linked together would have a unique Acct-Session-Id but the same + Acct-Multi-Session-Id. It is strongly recommended that the Acct- + Multi-Session-Id contain UTF-8 encoded 10646 [7] characters. + + A summary of the Acct-Session-Id attribute format is shown below. + The fields are transmitted from left to right. + + + +Rigney Informational [Page 21] + +RFC 2866 RADIUS Accounting June 2000 + + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 50 for Acct-Multi-Session-Id. + + Length + + >= 3 + + String + + The String field SHOULD contain UTF-8 encoded 10646 [7] characters. + +5.12. Acct-Link-Count + + Description + + This attribute gives the count of links which are known to have been + in a given multilink session at the time the accounting record is + generated. The NAS MAY include the Acct-Link-Count attribute in any + Accounting-Request which might have multiple links. + + A summary of the Acct-Link-Count attribute format is show below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + + + + +Rigney Informational [Page 22] + +RFC 2866 RADIUS Accounting June 2000 + + + Type + + 51 for Acct-Link-Count. + + Length + + 6 + + Value + + The Value field is four octets, and contains the number of links + seen so far in this Multilink Session. + + It may be used to make it easier for an accounting server to know + when it has all the records for a given Multilink session. When + the number of Accounting-Requests received with Acct-Status-Type = + Stop and the same Acct-Multi-Session-Id and unique Acct-Session- + Id's equals the largest value of Acct-Link-Count seen in those + Accounting-Requests, all Stop Accounting-Requests for that + Multilink Session have been received. + + An example showing 8 Accounting-Requests should make things + clearer. For clarity only the relevant attributes are shown, but + additional attributes containing accounting information will also + be present in the Accounting-Request. + + Multi-Session-Id Session-Id Status-Type Link-Count + "10" "10" Start 1 + "10" "11" Start 2 + "10" "11" Stop 2 + "10" "12" Start 3 + "10" "13" Start 4 + "10" "12" Stop 4 + "10" "13" Stop 4 + "10" "10" Stop 4 + +5.13. Table of Attributes + + The following table provides a guide to which attributes may be found + in Accounting-Request packets. No attributes should be found in + Accounting-Response packets except Proxy-State and possibly Vendor- + Specific. + + + # Attribute + 0-1 User-Name + 0 User-Password + 0 CHAP-Password + + + +Rigney Informational [Page 23] + +RFC 2866 RADIUS Accounting June 2000 + + + 0-1 NAS-IP-Address [Note 1] + 0-1 NAS-Port + 0-1 Service-Type + 0-1 Framed-Protocol + 0-1 Framed-IP-Address + 0-1 Framed-IP-Netmask + 0-1 Framed-Routing + 0+ Filter-Id + 0-1 Framed-MTU + 0+ Framed-Compression + 0+ Login-IP-Host + 0-1 Login-Service + 0-1 Login-TCP-Port + 0 Reply-Message + 0-1 Callback-Number + 0-1 Callback-Id + 0+ Framed-Route + 0-1 Framed-IPX-Network + 0 State + 0+ Class + 0+ Vendor-Specific + 0-1 Session-Timeout + 0-1 Idle-Timeout + 0-1 Termination-Action + 0-1 Called-Station-Id + 0-1 Calling-Station-Id + 0-1 NAS-Identifier [Note 1] + 0+ Proxy-State + 0-1 Login-LAT-Service + 0-1 Login-LAT-Node + 0-1 Login-LAT-Group + 0-1 Framed-AppleTalk-Link + 0-1 Framed-AppleTalk-Network + 0-1 Framed-AppleTalk-Zone + 1 Acct-Status-Type + 0-1 Acct-Delay-Time + 0-1 Acct-Input-Octets + 0-1 Acct-Output-Octets + 1 Acct-Session-Id + 0-1 Acct-Authentic + 0-1 Acct-Session-Time + 0-1 Acct-Input-Packets + 0-1 Acct-Output-Packets + 0-1 Acct-Terminate-Cause + 0+ Acct-Multi-Session-Id + 0+ Acct-Link-Count + 0 CHAP-Challenge + + + + +Rigney Informational [Page 24] + +RFC 2866 RADIUS Accounting June 2000 + + + 0-1 NAS-Port-Type + 0-1 Port-Limit + 0-1 Login-LAT-Port + + [Note 1] An Accounting-Request MUST contain either a NAS-IP-Address + or a NAS-Identifier (or both). + + The following table defines the above table entries. + + 0 This attribute MUST NOT be present + 0+ Zero or more instances of this attribute MAY be present. + 0-1 Zero or one instance of this attribute MAY be present. + 1 Exactly one instance of this attribute MUST be present. + +6. IANA Considerations + + The Packet Type Codes, Attribute Types, and Attribute Values defined + in this document are registered by the Internet Assigned Numbers + Authority (IANA) from the RADIUS name spaces as described in the + "IANA Considerations" section of RFC 2865 [2], in accordance with BCP + 26 [8]. + +7. Security Considerations + + Security issues are discussed in sections concerning the + authenticator included in accounting requests and responses, using a + shared secret which is never sent over the network. + +8. Change Log + + US-ASCII replaced by UTF-8. + + Added notes on Proxy. + + Framed-IP-Address should contain the actual IP address of the user. + + If Acct-Session-ID was sent in an access-request, it must be used in + the accounting-request for that session. + + New values added to Acct-Status-Type. + + Added an IANA Considerations section. + + Updated references. + + Text strings identified as a subset of string, to clarify use of + UTF-8. + + + + +Rigney Informational [Page 25] + +RFC 2866 RADIUS Accounting June 2000 + + +9. References + + [1] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. + + [2] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote + Authentication Dial In User Service (RADIUS)", RFC 2865, June + 2000. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March, 1997. + + [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August + 1980. + + [5] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC + 1321, April 1992. + + [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, + October 1994. + + [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC + 2279, January 1998. + + [8] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + +10. Acknowledgements + + RADIUS and RADIUS Accounting were originally developed by Steve + Willens of Livingston Enterprises for their PortMaster series of + Network Access Servers. + +11. Chair's Address + + The RADIUS working group can be contacted via the current chair: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + Phone: +1 925 737 2100 + EMail: cdr@telemancy.com + + + + + + + + +Rigney Informational [Page 26] + +RFC 2866 RADIUS Accounting June 2000 + + +12. Author's Address + + Questions about this memo can also be directed to: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + EMail: cdr@telemancy.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rigney Informational [Page 27] + +RFC 2866 RADIUS Accounting June 2000 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Rigney Informational [Page 28] + diff --git a/rfc/rfc2869.txt b/rfc/rfc2869.txt new file mode 100644 index 00000000..74ed7f6a --- /dev/null +++ b/rfc/rfc2869.txt @@ -0,0 +1,2635 @@ + + + + + + +Network Working Group C. Rigney +Request for Comments: 2869 Livingston +Category: Informational W. Willats + Cyno Technologies + P. Calhoun + Sun Microsystems + June 2000 + + + RADIUS Extensions + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This document describes additional attributes for carrying + authentication, authorization and accounting information between a + Network Access Server (NAS) and a shared Accounting Server using the + Remote Authentication Dial In User Service (RADIUS) protocol + described in RFC 2865 [1] and RFC 2866 [2]. + +Table of Contents + + 1. Introduction .......................................... 2 + 1.1 Specification of Requirements ................... 3 + 1.2 Terminology ..................................... 3 + 2. Operation ............................................. 4 + 2.1 RADIUS support for Interim Accounting Updates.... 4 + 2.2 RADIUS support for Apple Remote Access + Protocol ........................................ 5 + 2.3 RADIUS Support for Extensible Authentication + Protocol (EAP) .................................. 11 + 2.3.1 Protocol Overview ............................... 11 + 2.3.2 Retransmission .................................. 13 + 2.3.3 Fragmentation ................................... 14 + 2.3.4 Examples ........................................ 14 + 2.3.5 Alternative uses ................................ 19 + 3. Packet Format ......................................... 19 + 4. Packet Types .......................................... 19 + 5. Attributes ............................................ 20 + + + +Rigney, et al. Informational [Page 1] + +RFC 2869 RADIUS Extensions June 2000 + + + 5.1 Acct-Input-Gigawords ............................ 22 + 5.2 Acct-Output-Gigawords ........................... 23 + 5.3 Event-Timestamp ................................. 23 + 5.4 ARAP-Password ................................... 24 + 5.5 ARAP-Features ................................... 25 + 5.6 ARAP-Zone-Access ................................ 26 + 5.7 ARAP-Security ................................... 27 + 5.8 ARAP-Security-Data .............................. 28 + 5.9 Password-Retry .................................. 28 + 5.10 Prompt .......................................... 29 + 5.11 Connect-Info .................................... 30 + 5.12 Configuration-Token ............................. 31 + 5.13 EAP-Message ..................................... 32 + 5.14 Message-Authenticator ........................... 33 + 5.15 ARAP-Challenge-Response ......................... 35 + 5.16 Acct-Interim-Interval ........................... 36 + 5.17 NAS-Port-Id ..................................... 37 + 5.18 Framed-Pool ..................................... 37 + 5.19 Table of Attributes ............................. 38 + 6. IANA Considerations ................................... 39 + 7. Security Considerations ............................... 39 + 7.1 Message-Authenticator Security .................. 39 + 7.2 EAP Security .................................... 39 + 7.2.1 Separation of EAP server and PPP authenticator .. 40 + 7.2.2 Connection hijacking ............................ 41 + 7.2.3 Man in the middle attacks ....................... 41 + 7.2.4 Multiple databases .............................. 41 + 7.2.5 Negotiation attacks ............................. 42 + 8. References ............................................ 43 + 9. Acknowledgements ...................................... 44 + 10. Chair's Address ....................................... 44 + 11. Authors' Addresses .................................... 45 + 12. Full Copyright Statement .............................. 47 + +1. Introduction + + RFC 2865 [1] describes the RADIUS Protocol as it is implemented and + deployed today, and RFC 2866 [2] describes how Accounting can be + performed with RADIUS. + + + + + + + + + + + + +Rigney, et al. Informational [Page 2] + +RFC 2869 RADIUS Extensions June 2000 + + + This memo suggests several additional Attributes that can be added to + RADIUS to perform various useful functions. These Attributes do not + have extensive field experience yet and should therefore be + considered experimental. + + The Extensible Authentication Protocol (EAP) [3] is a PPP extension + that provides support for additional authentication methods within + PPP. This memo describes how the EAP-Message and Message- + Authenticator attributes may be used for providing EAP support within + RADIUS. + + All attributes are comprised of variable length Type-Length-Value 3- + tuples. New attribute values can be added without disturbing + existing implementations of the protocol. + +1.1. Specification of Requirements + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [4]. + + An implementation is not compliant if it fails to satisfy one or more + of the must or must not requirements for the protocols it implements. + An implementation that satisfies all the must, must not, should and + should not requirements for its protocols is said to be + "unconditionally compliant"; one that satisfies all the must and must + not requirements but not all the should or should not requirements + for its protocols is said to be "conditionally compliant." + + A NAS that does not implement a given service MUST NOT implement the + RADIUS attributes for that service. For example, a NAS that is + unable to offer ARAP service MUST NOT implement the RADIUS attributes + for ARAP. A NAS MUST treat a RADIUS access-request requesting an + unavailable service as an access-reject instead. + +1.2. Terminology + + This document uses the following terms: + + service The NAS provides a service to the dial-in user, such as PPP + or Telnet. + + session Each service provided by the NAS to a dial-in user + constitutes a session, with the beginning of the session + defined as the point where service is first provided and + the end of the session defined as the point where service + + + + + +Rigney, et al. Informational [Page 3] + +RFC 2869 RADIUS Extensions June 2000 + + + is ended. A user may have multiple sessions in parallel or + series if the NAS supports that, with each session + generating a separate start and stop accounting record. + + silently discard + This means the implementation discards the packet without + further processing. The implementation SHOULD provide the + capability of logging the error, including the contents of + the silently discarded packet, and SHOULD record the event + in a statistics counter. + +2. Operation + + Operation is identical to that defined in RFC 2865 [1] and RFC 2866 + [2]. + +2.1. RADIUS support for Interim Accounting Updates + + When a user is authenticated, a RADIUS server issues an Access-Accept + in response to a successful Access-Request. If the server wishes to + receive interim accounting messages for the given user it must + include the Acct-Interim-Interval RADIUS attribute in the message, + which indicates the interval in seconds between interim messages. + + It is also possible to statically configure an interim value on the + NAS itself. Note that a locally configured value on the NAS MUST + override the value found in an Access-Accept. + + This scheme does not break backward interoperability since a RADIUS + server not supporting this extension will simply not add the new + Attribute. NASes not supporting this extension will ignore the + Attribute. + + Note that all information in an interim message is cumulative (i.e. + number of packets sent is the total since the beginning of the + session, not since the last interim message). + + It is envisioned that an Interim Accounting record (with Acct- + Status-Type = Interim-Update (3)) would contain all of the attributes + normally found in an Accounting Stop message with the exception of + the Acct-Term-Cause attribute. + + Since all the information is cumulative, a NAS MUST ensure that only + a single generation of an interim Accounting message for a given + session is present in the retransmission queue at any given time. + + + + + + +Rigney, et al. Informational [Page 4] + +RFC 2869 RADIUS Extensions June 2000 + + + A NAS MAY use a fudge factor to add a random delay between Interim + Accounting messages for separate sessions. This will ensure that a + cycle where all messages are sent at once is prevented, such as might + otherwise occur if a primary link was recently restored and many + dial-up users were directed to the same NAS at once. + + The Network and NAS CPU load of using Interim Updates should be + carefully considered, and appropriate values of Acct-Interim-Interval + chosen. + +2.2. RADIUS support for Apple Remote Access Protocol + + The RADIUS (Remote Authentication Dial-In User Service) protocol + provides a method that allows multiple dial-in Network Access Server + (NAS) devices to share a common authentication database. + + The Apple Remote Access Protocol (ARAP) provides a method for sending + AppleTalk network traffic over point-to-point links, typically, but + not exclusively, asynchronous and ISDN switched-circuit connections. + Though Apple is moving toward ATCP on PPP for future remote access + services, ARAP is still a common way for the installed base of + Macintosh users to make remote network connections, and is likely to + remain so for some time. + + ARAP is supported by several NAS vendors who also support PPP, IPX + and other protocols in the same NAS. ARAP connections in these + multi-protocol devices are often not authenticated with RADIUS, or if + they are, each vendor creates an individual solution to the problem. + + This section describes the use of additional RADIUS attributes to + support ARAP. RADIUS client and server implementations that implement + this specification should be able to authenticate ARAP connections in + an interoperable manner. + + This section assumes prior knowledge of RADIUS, and will go into some + detail on the operation of ARAP before entering a detailed discussion + of the proposed ARAP RADIUS attributes. + + There are two features of ARAP this document does not address: + + 1. User initiated password changing. This is not part of RADIUS, + but can be implemented through a software process other than + RADIUS. + + 2. Out-of-Band messages. At any time, the NAS can send messages to + an ARA client which appear in a dialog box on the dial-in + user's screen. These are not part of authentication and do not + belong here. However, we note that a Reply-Message attribute in + + + +Rigney, et al. Informational [Page 5] + +RFC 2869 RADIUS Extensions June 2000 + + + an Access-Accept may be sent down to the user as a sign-on + message of the day string using the out-of-band channel. + + We have tried to respect the spirit of the existing RADIUS protocol + as much as possible, making design decisions compatible with prior + art. Further, we have tried to strike a balance between flooding the + RADIUS world with new attributes, and hiding all of ARAP operation + within a single multiplexed ARAP attribute string or within Extended + Authentication Protocol (EAP) [3] machinery. + + However, we feel ARAP is enough of a departure from PPP to warrant a + small set of similarly named attributes of its own. + + We have assumed that an ARAP-aware RADIUS server will be able to do + DES encryption and generate security module challenges. This is in + keeping with the general RADIUS goal of smart server / simple NAS. + + ARAP authenticates a connection in two phases. The first is a "Two- + Way DES" random number exchange, using the user's password as a key. + We say "Two-Way" because the ARAP NAS challenges the dial-in client + to authenticate itself, and the dial-in client challenges the ARAP + NAS to authenticate itself. + + Specifically, ARAP does the following: + + 1. The NAS sends two 32-bit random numbers to the dial-in client + in an ARAP msg_auth_challenge packet. + + 2. The dial-in client uses the user's password to DES encrypt the + two random numbers sent to it by the NAS. The dial-in client + then sends this result, the user's name and two 32-bit random + numbers of its own back to the NAS in an ARAP msg_auth_request + packet. + + 3. The NAS verifies the encrypted random numbers sent by the + dial-in client are what it expected. If so, it encrypts the + dial-in client's challenge using the password and sends it back + to the dial-in client in an ARAP msg_auth_response packet. + + Note that if the dial-in client's response was wrong, meaning the + user has the wrong password, the server can initiate a retry sequence + up to the maximum amount of retries allowed by the NAS. In this case, + when the dial-in client receives the ARAP msg_auth_response packet it + will acknowledge it with an ARAP msg_auth_again packet. + + After this first "DES Phase" the ARAP NAS MAY initiate a secondary + authentication phase using what Apple calls "Add-In Security + Modules." Security Modules are small pieces of code which run on + + + +Rigney, et al. Informational [Page 6] + +RFC 2869 RADIUS Extensions June 2000 + + + both the client and server and are allowed to read and write + arbitrary data across the communications link to perform additional + authentication functions. Various security token vendors use this + mechanism to authenticate ARA callers. + + Although ARAP allows security modules to read and write anything they + like, all existing security modules use simple challenge and response + cycles, with perhaps some overall control information. This document + assumes all existing security modules can be supported with one or + more challenge/response cycles. + + To complicate RADIUS and ARAP integration, ARAP sends down some + profile information after the DES Phase and before the Security + Module phase. This means that besides the responses to challenges, + this profile information must also be present, at somewhat unusual + times. Fortunately the information is only a few pieces of numeric + data related to passwords, which this document packs into a single + new attribute. + + Presenting an Access-Request to RADIUS on behalf of an ARAP + connection is straightforward. The ARAP NAS generates the random + number challenge, and then receives the dial-in client's response, + the dial-in client's challenge, and the user's name. Assuming the + user is not a guest, the following information is forwarded in an + Access-Request packet: User-Name (up to 31 characters long), + Framed-Protocol (set to 3, ARAP), ARAP-Password, and any additional + attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id, + NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc. + + The Request Authenticator is a NAS-generated 16 octet random number. + The low-order 8 octets of this number are sent to the dial-in user as + the two 4 octet random numbers required in the ARAP + msg_auth_challenge packet. Octets 0-3 are the first random number and + Octets 4-7 are the second random number. + + The ARAP-Password in the Access-Request contains a 16 octet random + number field, and is used to carry the dial-in user's response to the + NAS challenge and the client's own challenge to the NAS. The high- + order octets contain the dial-in user's challenge to the NAS (2 32- + bit numbers, 8 octets) and the low-order octets contain the dial-in + user's response to the NAS challenge (2 32-bit numbers, 8 octets). + + Only one of User-Password, CHAP-Password, or ARAP-Password needs to + be present in an Access-Request, or one or more EAP-Messages. + + If the RADIUS server does not support ARAP it SHOULD return an + Access-Reject to the NAS. + + + + +Rigney, et al. Informational [Page 7] + +RFC 2869 RADIUS Extensions June 2000 + + + If the RADIUS server does support ARAP, it should verify the user's + response using the Challenge (from the lower order 8 octets of the + Request Authenticator) and the user's response (from the low order 8 + octets of the ARAP-Password). + + If that authentication fails, the RADIUS server should return an + Access-Reject packet to the NAS, with optional Password-Retry and + Reply-Messages attributes. The presence of Password-Retry indicates + the ARAP NAS MAY choose to initiate another challenge-response cycle, + up to a total number of times equal to the integer value of the + Password-Retry attribute. + + If the user is authenticated, the RADIUS server should return an + Access-Accept packet (Code 2) to the NAS, with ID and Response + Authenticator as usual, and attributes as follows: + + Service-Type of Framed-Protocol. + + Framed-Protocol of ARAP (3). + + Session-Timeout with the maximum connect time for the user in + seconds. If the user is to be given unlimited time, + Session-Timeout should not be included in the Access-Accept + packet, and ARAP will treat that as an unlimited timeout (-1). + + ARAP-Challenge-Response, containing 8 octets with the response to + the dial-in client's challenge. The RADIUS server calculates this + value by taking the dial-in client's challenge from the high order + 8 octets of the ARAP-Password attribute and performing DES + encryption on this value with the authenticating user's password + as the key. If the user's password is less than 8 octets in + length, the password is padded at the end with NULL octets to a + length of 8 before using it as a key. If the user's password is + greater than 8 octets in length, an Access-Reject MUST be sent + instead. + + ARAP-Features, containing information that the NAS should send to + the user in an ARAP "feature flags" packet. + + Octet 0: If zero, user cannot change their password. If non- + zero user can. (RADIUS does not handle the password changing, + just the attribute which indicates whether ARAP indicates they + can.) + + Octet 1: Minimum acceptable password length (0-8). + + + + + + +Rigney, et al. Informational [Page 8] + +RFC 2869 RADIUS Extensions June 2000 + + + Octet 2-5: Password creation date in Macintosh format, defined + as 32 bits unsigned representing seconds since Midnight GMT + January 1, 1904. + + Octet 6-9 Password Expiration Delta from create date in + seconds. + + Octet 10-13: Current RADIUS time in Macintosh format + + Optionally, a single Reply-Message with a text string up to 253 + characters long which MAY be sent down to the user to be displayed + in a sign-on/message of the day dialog. + + Framed-AppleTalk-Network may be included. + + Framed-AppleTalk-Zone, up to 32 characters in length, may be + included. + + ARAP defines the notion of a list of zones for a user. Along with + a list of zone names, a Zone Access Flag is defined (and used by + the NAS) which says how to use the list of zone names. That is, + the dial-in user may only be allowed to see the Default Zone, or + only the zones in the zone list (inclusive) or any zone except + those in the zone list (exclusive). + + The ARAP NAS handles this by having a named filter which contains + (at least) zone names. This solves the problem where a single + RADIUS server is managing disparate NAS clients who may not be + able to "see" all of the zone names in a user zone list. Zone + names only have meaning "at the NAS." The disadvantage of this + approach is that zone filters must be set up on the NAS somehow, + then referenced by the RADIUS Filter-Id. + + ARAP-Zone-Access contains an integer which specifies how the "zone + list" for this user should be used. If this attribute is present + and the value is 2 or 4 then a Filter-Id must also be present to + name a zone list filter to apply the access flag to. + + The inclusion of a Callback-Number or Callback-Id attribute in the + Access-Accept MAY cause the ARAP NAS to disconnect after sending + the Feature Flags to begin callback processing in an ARAP specific + way. + + + + + + + + + +Rigney, et al. Informational [Page 9] + +RFC 2869 RADIUS Extensions June 2000 + + + Other attributes may be present in the Access-Accept packet as well. + + An ARAP NAS will need other information to finish bringing up the + connection to the dial in client, but this information can be + provided by the ARAP NAS without any help from RADIUS, either through + configuration by SNMP, a NAS administration program, or deduced by + the AppleTalk stack in the NAS. Specifically: + + 1. AppearAsNet and AppearAsNode values, sent to the client to tell + it what network and node numbers it should use in its datagram + packets. AppearAsNet can be taken from the Framed-AppleTalk- + Network attribute or from the configuration or AppleTalk stack + onthe NAS. + + 2. The "default" zone - that is the name of the AppleTalk zone in + which the dial-in client will appear. (Or can be specified + with the Framed-AppleTalk-Zone attribute.) + + 3. Other very NAS specific stuff such as the name of the NAS, and + smartbuffering information. (Smartbuffering is an ARAP + mechanism for replacing common AppleTalk datagrams with small + tokens, to improve slow link performance in a few common + traffic situations.) + + 4. "Zone List" information for this user. The ARAP specification + defines a "zone count" field which is actually unused. + + RADIUS supports ARAP Security Modules in the following manner. + + After DES authentication has been completed, the RADIUS server may + instruct the ARAP NAS to run one or more security modules for the + dial-in user. Although the underlying protocol supports executing + multiple security modules in series, in practice all current + implementations only allow executing one. Through the use of + multiple Access-Challenge requests, multiple modules can be + supported, but this facility will probably never be used. + + We also assume that, even though ARAP allows a free-form dialog + between security modules on each end of the point-to-point link, in + actual practice all security modules can be reduced to a simple + challenge/response cycle. + + If the RADIUS server wishes to instruct the ARAP NAS to run a + security module, it should send an Access-Challenge packet to the NAS + with (optionally) the State attribute, plus the ARAP-Challenge- + Response, ARAP-Features, and two more attributes: + + + + + +Rigney, et al. Informational [Page 10] + +RFC 2869 RADIUS Extensions June 2000 + + + ARAP-Security: a four octet security module signature, containing a + Macintosh OSType. + + ARAP-Security-Data, a string to carry the actual security module + challenge and response. + + When the security module finishes executing, the security module + response is passed in an ARAP-Security-Data attribute from the NAS + to the RADIUS server in a second Access-Request, also including the + State from the Access-Challenge. The authenticator field contains no + special information in this case, and this can be discerned by the + presence of the State attribute. + +2.3. RADIUS Support for Extensible Authentication Protocol (EAP) + + The Extensible Authentication Protocol (EAP), described in [3], + provides a standard mechanism for support of additional + authentication methods within PPP. Through the use of EAP, support + for a number of authentication schemes may be added, including smart + cards, Kerberos, Public Key, One Time Passwords, and others. In + order to provide for support of EAP within RADIUS, two new + attributes, EAP-Message and Message-Authenticator, are introduced in + this document. This section describes how these new attributes may be + used for providing EAP support within RADIUS. + + In the proposed scheme, the RADIUS server is used to shuttle RADIUS- + encapsulated EAP Packets between the NAS and a backend security + server. While the conversation between the RADIUS server and the + backend security server will typically occur using a proprietary + protocol developed by the backend security server vendor, it is also + possible to use RADIUS-encapsulated EAP via the EAP-Message + attribute. This has the advantage of allowing the RADIUS server to + support EAP without the need for authentication-specific code, which + can instead reside on the backend security server. + +2.3.1. Protocol Overview + + The EAP conversation between the authenticating peer (dial-in user) + and the NAS begins with the negotiation of EAP within LCP. Once EAP + has been negotiated, the NAS MUST send an EAP-Request/Identity + message to the authenticating peer, unless identity is determined via + some other means such as Called-Station-Id or Calling-Station-Id. + The peer will then respond with an EAP-Response/Identity which the + the NAS will then forward to the RADIUS server in the EAP-Message + attribute of a RADIUS Access-Request packet. The RADIUS Server will + typically use the EAP-Response/Identity to determine which EAP type + is to be applied to the user. + + + + +Rigney, et al. Informational [Page 11] + +RFC 2869 RADIUS Extensions June 2000 + + + In order to permit non-EAP aware RADIUS proxies to forward the + Access-Request packet, if the NAS sends the EAP-Request/Identity, the + NAS MUST copy the contents of the EAP-Response/Identity into the + User-Name attribute and MUST include the EAP-Response/Identity in the + User-Name attribute in every subsequent Access-Request. NAS-Port or + NAS-Port-Id SHOULD be included in the attributes issued by the NAS in + the Access-Request packet, and either NAS-Identifier or NAS-IP- + Address MUST be included. In order to permit forwarding of the + Access-Reply by EAP-unaware proxies, if a User-Name attribute was + included in an Access-Request, the RADIUS Server MUST include the + User-Name attribute in subsequent Access-Accept packets. Without the + User-Name attribute, accounting and billing becomes very difficult to + manage. + + If identity is determined via another means such as Called-Station-Id + or Calling-Station-Id, the NAS MUST include these identifying + attributes in every Access-Request. + + While this approach will save a round-trip, it cannot be universally + employed. There are circumstances in which the user's identity may + not be needed (such as when authentication and accounting is handled + based on Called-Station-Id or Calling-Station-Id), and therefore an + EAP-Request/Identity packet may not necessarily be issued by the NAS + to the authenticating peer. In cases where an EAP-Request/Identity + packet will not be sent, the NAS will send to the RADIUS server a + RADIUS Access-Request packet containing an EAP-Message attribute + signifying EAP-Start. EAP-Start is indicated by sending an EAP- + Message attribute with a length of 2 (no data). However, it should be + noted that since no User-Name attribute is included in the Access- + Request, this approach is not compatible with RADIUS as specified in + [1], nor can it easily be applied in situations where proxies are + deployed, such as roaming or shared use networks. + + If the RADIUS server supports EAP, it MUST respond with an Access- + Challenge packet containing an EAP-Message attribute. If the RADIUS + server does not support EAP, it MUST respond with an Access-Reject. + The EAP-Message attribute includes an encapsulated EAP packet which + is then passed on to the authenticating peer. In the case where the + NAS does not initially send an EAP-Request/Identity message to the + peer, the Access-Challenge typically will contain an EAP-Message + attribute encapsulating an EAP-Request/Identity message, requesting + the dial-in user to identify themself. The NAS will then respond with + a RADIUS Access-Request packet containing an EAP-Message attribute + encapsulating an EAP-Response. The conversation continues until + either a RADIUS Access-Reject or Access-Accept packet is received. + + + + + + +Rigney, et al. Informational [Page 12] + +RFC 2869 RADIUS Extensions June 2000 + + + Reception of a RADIUS Access-Reject packet, with or without an EAP- + Message attribute encapsulating EAP-Failure, MUST result in the NAS + issuing an LCP Terminate Request to the authenticating peer. A + RADIUS Access-Accept packet with an EAP-Message attribute + encapsulating EAP-Success successfully ends the authentication phase. + The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain + all of the expected attributes which are currently returned in an + Access-Accept packet. + + The above scenario creates a situation in which the NAS never needs + to manipulate an EAP packet. An alternative may be used in + situations where an EAP-Request/Identity message will always be sent + by the NAS to the authenticating peer. + + For proxied RADIUS requests there are two methods of processing. If + the domain is determined based on the Called-Station-Id, the RADIUS + Server may proxy the initial RADIUS Access-Request/EAP-Start. If the + domain is determined based on the user's identity, the local RADIUS + Server MUST respond with a RADIUS Access-Challenge/EAP-Identity + packet. The response from the authenticating peer MUST be proxied to + the final authentication server. + + For proxied RADIUS requests, the NAS may receive an Access-Reject + packet in response to its Access-Request/EAP-Identity packet. This + would occur if the message was proxied to a RADIUS Server which does + not support the EAP-Message extension. On receiving an Access-Reject, + the NAS MUST send an LCP Terminate Request to the authenticating + peer, and disconnect. + +2.3.2. Retransmission + + As noted in [3], the EAP authenticator (NAS) is responsible for + retransmission of packets between the authenticating peer and the + NAS. Thus if an EAP packet is lost in transit between the + authenticating peer and the NAS (or vice versa), the NAS will + retransmit. As in RADIUS [1], the RADIUS client is responsible for + retransmission of packets between the RADIUS client and the RADIUS + server. + + Note that it may be necessary to adjust retransmission strategies and + authentication timeouts in certain cases. For example, when a token + card is used additional time may be required to allow the user to + find the card and enter the token. Since the NAS will typically not + have knowledge of the required parameters, these need to be provided + by the RADIUS server. This can be accomplished by inclusion of + Session-Timeout and Password-Retry attributes within the Access- + Challenge packet. + + + + +Rigney, et al. Informational [Page 13] + +RFC 2869 RADIUS Extensions June 2000 + + + If Session-Timeout is present in an Access-Challenge packet that also + contains an EAP-Message, the value of the Session-Timeout provides + the NAS with the maximum number of seconds the NAS should wait for an + EAP-Response before retransmitting the EAP-Message to the dial-in + user. + +2.3.3. Fragmentation + + Using the EAP-Message attribute, it is possible for the RADIUS server + to encapsulate an EAP packet that is larger than the MTU on the link + between the NAS and the peer. Since it is not possible for the RADIUS + server to use MTU discovery to ascertain the link MTU, the Framed-MTU + attribute may be included in an Access-Request packet containing an + EAP-Message attribute so as to provide the RADIUS server with this + information. + +2.3.4. Examples + + The example below shows the conversation between the authenticating + peer, NAS, and RADIUS server, for the case of a One Time Password + (OTP) authentication. OTP is used only for illustrative purposes; + other authentication protocols could also have been used, although + they might show somewhat different behavior. + +Authenticating Peer NAS RADIUS Server +------------------- --- ------------- + + <- PPP LCP Request-EAP + auth +PPP LCP ACK-EAP +auth -> + <- PPP EAP-Request/ + Identity +PPP EAP-Response/ +Identity (MyID) -> + RADIUS + Access-Request/ + EAP-Message/ + EAP-Response/ + (MyID) -> + <- RADIUS + Access-Challenge/ + EAP-Message/EAP-Request + OTP/OTP Challenge + <- PPP EAP-Request/ + OTP/OTP Challenge +PPP EAP-Response/ +OTP, OTPpw -> + + + +Rigney, et al. Informational [Page 14] + +RFC 2869 RADIUS Extensions June 2000 + + + RADIUS + Access-Request/ + EAP-Message/ + EAP-Response/ + OTP, OTPpw -> + <- RADIUS + Access-Accept/ + EAP-Message/EAP-Success + (other attributes) + <- PPP EAP-Success +PPP Authentication +Phase complete, +NCP Phase starts + +In the case where the NAS first sends an EAP-Start packet to the +RADIUS server, the conversation would appear as follows: + +Authenticating Peer NAS RADIUS Server +------------------- --- ------------- + + <- PPP LCP Request-EAP + auth +PPP LCP ACK-EAP +auth -> + RADIUS + Access-Request/ + EAP-Message/Start -> + <- RADIUS + Access-Challenge/ + EAP-Message/Identity + <- PPP EA-Request/ + Identity +PPP EAP-Response/ +Identity (MyID) -> + RADIUS + Access-Request/ + EAP-Message/ + EAP-Response/ + (MyID) -> + <- RADIUS + Access-Challenge/ + EAP-Message/EAP-Request + OTP/OTP Challenge + <- PPP EAP-Request/ + OTP/OTP Challenge +PPP EAP-Response/ +OTP, OTPpw -> + + + + +Rigney, et al. Informational [Page 15] + +RFC 2869 RADIUS Extensions June 2000 + + + RADIUS + Access-Request/ + EAP-Message/ + EAP-Response/ + OTP, OTPpw -> + <- RADIUS + Access-Accept/ + EAP-Message/EAP-Success + (other attributes) + <- PPP EAP-Success +PPP Authentication +Phase complete, +NCP Phase starts + +In the case where the client fails EAP authentication, the +conversation would appear as follows: + +Authenticating Peer NAS RADIUS Server +------------------- --- ------------- + + <- PPP LCP Request-EAP + auth +PPP LCP ACK-EAP +auth -> + Access-Request/ + EAP-Message/Start -> + <- RADIUS + Access-Challenge/ + EAP-Message/Identity + <- PPP EAP-Request/ + Identity +PPP EAP-Response/ +Identity (MyID) -> + RADIUS + Access-Request/ + EAP-Message/ + EAP-Response/ + (MyID) -> + <- RADIUS + Access-Challenge/ + EAP-Message/EAP-Request + OTP/OTP Challenge + <- PPP EAP-Request/ + OTP/OTP Challenge +PPP EAP-Response/ +OTP, OTPpw -> + RADIUS + Access-Request/ + + + +Rigney, et al. Informational [Page 16] + +RFC 2869 RADIUS Extensions June 2000 + + + EAP-Message/ + EAP-Response/ + OTP, OTPpw -> + <- RADIUS + Access-Reject/ + EAP-Message/EAP-Failure + + <- PPP EAP-Failure + (client disconnected) + +In the case that the RADIUS server or proxy does not support +EAP-Message, the conversation would appear as follows: + +Authenticating Peer NAS RADIUS Server +------------------- --- ------------- + + <- PPP LCP Request-EAP + auth +PPP LCP ACK-EAP +auth -> + RADIUS + Access-Request/ + EAP-Message/Start -> + <- RADIUS + Access-Reject + <- PPP LCP Terminate + (User Disconnected) + +In the case where the local RADIUS Server does support EAP-Message, +but the remote RADIUS Server does not, the conversation would appear +as follows: + +Authenticating Peer NAS RADIUS Server +------------------- --- ------------- + + <- PPP LCP Request-EAP + auth +PPP LCP ACK-EAP +auth -> + RADIUS + Access-Request/ + EAP-Message/Start -> + <- RADIUS + Access-Challenge/ + EAP-Message/Identity + <- PPP EAP-Request/ + Identity + + + + +Rigney, et al. Informational [Page 17] + +RFC 2869 RADIUS Extensions June 2000 + + +PPP EAP-Response/ +Identity +(MyID) -> + RADIUS + Access-Request/ + EAP-Message/EAP-Response/ + (MyID) -> + <- RADIUS + Access-Reject + (proxied from remote + RADIUS Server) + <- PPP LCP Terminate + (User Disconnected) + +In the case where the authenticating peer does not support EAP, but +where EAP is required for that user, the conversation would appear as +follows: + +Authenticating Peer NAS RADIUS Server +------------------- --- ------------- + + <- PPP LCP Request-EAP + auth +PPP LCP NAK-EAP +auth -> + <- PPP LCP Request-CHAP + auth +PPP LCP ACK-CHAP +auth -> + <- PPP CHAP Challenge +PPP CHAP Response -> + RADIUS + Access-Request/ + User-Name, + CHAP-Password -> + <- RADIUS + Access-Reject + <- PPP LCP Terminate + (User Disconnected) + +In the case where the NAS does not support EAP, but where EAP is +required for that user, the conversation would appear as follows: + +Authenticating Peer NAS RADIUS Server +------------------- --- ------------- + + <- PPP LCP Request-CHAP + auth + + + +Rigney, et al. Informational [Page 18] + +RFC 2869 RADIUS Extensions June 2000 + + +PP LCP ACK-CHAP +auth -> + <- PPP CHAP Challenge +PPP CHAP Response -> + RADIUS + Access-Request/ + User-Name, + CHAP-Password -> + + <- RADIUS + Access-Reject + <- PPP LCP Terminate + (User Disconnected) + +2.3.5. Alternative uses + + Currently the conversation between the backend security server and + the RADIUS server is proprietary because of lack of standardization. + In order to increase standardization and provide interoperability + between Radius vendors and backend security vendors, it is + recommended that RADIUS-encapsulated EAP be used for this + conversation. + + This has the advantage of allowing the RADIUS server to support EAP + without the need for authentication-specific code within the RADIUS + server. Authentication-specific code can then reside on a backend + security server instead. + + In the case where RADIUS-encapsulated EAP is used in a conversation + between a RADIUS server and a backend security server, the security + server will typically return an Access-Accept/EAP-Success message + without inclusion of the expected attributes currently returned in an + Access-Accept. This means that the RADIUS server MUST add these + attributes prior to sending an Access-Accept/EAP-Success message to + the NAS. + +3. Packet Format + + Packet Format is identical to that defined in RFC 2865 [1] and 2866 + [2]. + +4. Packet Types + + Packet types are identical to those defined in RFC 2865 [1] and 2866 + [2]. + + See "Table of Attributes" below to determine which types of packets + can contain which attributes defined here. + + + +Rigney, et al. Informational [Page 19] + +RFC 2869 RADIUS Extensions June 2000 + + +5. Attributes + + RADIUS Attributes carry the specific authentication, authorization + and accounting details for the request and response. + + Some attributes MAY be included more than once. The effect of this + is attribute specific, and is specified in each attribute + description. The order of attributes of the same type SHOULD be + preserved. The order of attributes of different types is not + required to be preserved. + + The end of the list of attributes is indicated by the Length of the + RADIUS packet. + + A summary of the attribute format is the same as in RFC 2865 [1] but + is included here for ease of reference. The fields are transmitted + from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + The Type field is one octet. Up-to-date values of the RADIUS Type + field are specified in the most recent "Assigned Numbers" RFC [5]. + Values 192-223 are reserved for experimental use, values 224-240 + are reserved for implementation-specific use, and values 241-255 + are reserved and should not be used. This specification concerns + the following values: + + 1-39 (refer to RFC 2865 [1], "RADIUS") + 40-51 (refer to RFC 2866 [2], "RADIUS Accounting") + 52 Acct-Input-Gigawords + 53 Acct-Output-Gigawords + 54 Unused + 55 Event-Timestamp + 56-59 Unused + 60-63 (refer to RFC 2865 [1], "RADIUS") + 64-67 (refer to [6]) + 68 (refer to [7]) + 69 (refer to [6]) + 70 ARAP-Password + 71 ARAP-Features + 72 ARAP-Zone-Access + + + +Rigney, et al. Informational [Page 20] + +RFC 2869 RADIUS Extensions June 2000 + + + 73 ARAP-Security + 74 ARAP-Security-Data + 75 Password-Retry + 76 Prompt + 77 Connect-Info + 78 Configuration-Token + 79 EAP-Message + 80 Message-Authenticator + 81-83 (refer to [6]) + 84 ARAP-Challenge-Response + 85 Acct-Interim-Interval + 86 (refer to [7]) + 87 NAS-Port-Id + 88 Framed-Pool + 89 Unused + 90-91 (refer to [6]) + 92-191 Unused + + Length + + The Length field is one octet, and indicates the length of this + attribute including the Type, Length and Value fields. If an + attribute is received in a packet with an invalid Length, the + entire request should be silently discarded. + + Value + + The Value field is zero or more octets and contains information + specific to the attribute. The format and length of the Value + field is determined by the Type and Length fields. + + Note that none of the types in RADIUS terminate with a NUL (hex + 00). In particular, types "text" and "string" in RADIUS do not + terminate with a NUL (hex 00). The Attribute has a length field + and does not use a terminator. Text contains UTF-8 encoded 10646 + [8] characters and String contains 8-bit binary data. Servers and + servers and clients MUST be able to deal with embedded nulls. + RADIUS implementers using C are cautioned not to use strcpy() when + handling strings. + + The format of the value field is one of five data types. Note + that type "text" is a subset of type "string." + + text 1-253 octets containing UTF-8 encoded 10646 [8] + characters. Text of length zero (0) MUST NOT be sent; + omit the entire attribute instead. + + + + + +Rigney, et al. Informational [Page 21] + +RFC 2869 RADIUS Extensions June 2000 + + + string 1-253 octets containing binary data (values 0 through + 255 decimal, inclusive). Strings of length zero (0) MUST + NOT be sent; omit the entire attribute instead. + + address 32 bit unsigned value, most significant octet first. + + integer 32 bit unsigned value, most significant octet first. + + time 32 bit unsigned value, most significant octet first -- + seconds since 00:00:00 UTC, January 1, 1970. + +5.1. Acct-Input-Gigawords + + Description + + This attribute indicates how many times the Acct-Input-Octets + counter has wrapped around 2^32 over the course of this service + being provided, and can only be present in Accounting-Request + records where the Acct-Status-Type is set to Stop or Interim- + Update. + + A summary of the Acct-Input-Gigawords attribute format is shown + below. The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 52 for Acct-Input-Gigawords. + + Length + + 6 + + Value + + The Value field is four octets. + + + + + + + + +Rigney, et al. Informational [Page 22] + +RFC 2869 RADIUS Extensions June 2000 + + +5.2. Acct-Output-Gigawords + + Description + + This attribute indicates how many times the Acct-Output-Octets + counter has wrapped around 2^32 in the course of delivering this + service, and can only be present in Accounting-Request records + where the Acct-Status-Type is set to Stop or Interim-Update. + + A summary of the Acct-Output-Gigawords attribute format is shown + below. The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 53 for Acct-Output-Gigawords. + + Length + + 6 + + Value + + The Value field is four octets. + +5.3. Event-Timestamp + + Description + + This attribute is included in an Accounting-Request packet to + record the time that this event occurred on the NAS, in seconds + since January 1, 1970 00:00 UTC. + + A summary of the Event-Timestamp attribute format is shown below. + The fields are transmitted from left to right. + + + + + + + + + +Rigney, et al. Informational [Page 23] + +RFC 2869 RADIUS Extensions June 2000 + + + 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 55 for Event-Timestamp + + Length + + 6 + + Value + + The Value field is four octets encoding an unsigned integer with + the number of seconds since January 1, 1970 00:00 UTC. + +5.4. ARAP-Password + + Description + + This attribute is only present in an Access-Request packet + containing a Framed-Protocol of ARAP. + + Only one of User-Password, CHAP-Password, or ARAP-Password needs + to be present in an Access-Request, or one or more EAP-Messages. + + A summary of the ARAP-Password attribute format is shown below. The + fields are transmitted from 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 | Value1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value2 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value4 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Rigney, et al. Informational [Page 24] + +RFC 2869 RADIUS Extensions June 2000 + + + Type + + 70 for ARAP-Password. + + Length + + 18 + + Value + + This attribute contains a 16 octet string, used to carry the + dial-in user's response to the NAS challenge and the client's own + challenge to the NAS. The high-order octets (Value1 and Value2) + contain the dial-in user's challenge to the NAS (2 32-bit numbers, + 8 octets) and the low-order octets (Value3 and Value4) contain the + dial-in user's response to the NAS challenge (2 32-bit numbers, 8 + octets). + +5.5. ARAP-Features + + Description + + This attribute is sent in an Access-Accept packet with Framed- + Protocol of ARAP, and includes password information that the NAS + should sent to the user in an ARAP "feature flags" packet. + + A summary of the ARAP-Features attribute format is shown below. The + fields are transmitted from 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 | Value1 | Value2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value3 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value5 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 71 for ARAP-Features. + + Length + + 16 + + + +Rigney, et al. Informational [Page 25] + +RFC 2869 RADIUS Extensions June 2000 + + + Value + + The Value field is a compound string containing information the + NAS should send to the user in the ARAP "feature flags" packet. + + Value1: If zero, user cannot change their password. If non-zero + user can. (RADIUS does not handle the password changing, just + the attribute which indicates whether ARAP indicates they can.) + + Value2: Minimum acceptable password length, from 0 to 8. + + Value3: Password creation date in Macintosh format, defined as + 32 unsigned bits representing seconds since Midnight GMT + January 1, 1904. + + Value4: Password Expiration Delta from create date in seconds. + + Value5: Current RADIUS time in Macintosh format. + +5.6. ARAP-Zone-Access + + Description + + This attribute is included in an Access-Accept packet with + Framed-Protocol of ARAP to indicate how the ARAP zone list for the + user should be used. + + A summary of the ARAP-Zone-Access attribute format is shown below. + The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 72 for ARAP-Zone-Access. + + Length + + 6 + + + + + +Rigney, et al. Informational [Page 26] + +RFC 2869 RADIUS Extensions June 2000 + + + Value + + The Value field is four octets encoding an integer with one of the + following values: + + 1 Only allow access to default zone + 2 Use zone filter inclusively + 4 Use zone filter exclusively + + + The value 3 is skipped, not because these are bit flags, but + because 3 in some ARAP implementations means "all zones" which is + the same as not specifying a list at all under RADIUS. + + If this attribute is present and the value is 2 or 4 then a + Filter-Id must also be present to name a zone list filter to apply + the access flag to. + +5.7. ARAP-Security + + Description + + This attribute identifies the ARAP Security Module to be used in + an Access-Challenge packet. + + A summary of the ARAP-Security attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 73 for ARAP-Security. + + Length + + 6 + + + + + + + + +Rigney, et al. Informational [Page 27] + +RFC 2869 RADIUS Extensions June 2000 + + + Value + + The Value field is four octets, containing an integer specifying + the security module signature, which is a Macintosh OSType. + (Macintosh OSTypes are 4 ascii characters cast as a 32-bit + integer) + +5.8. ARAP-Security-Data + + Description + + This attribute contains the actual security module challenge or + response, and can be found in Access-Challenge and Access-Request + packets. + + A summary of the ARAP-Security-Data attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 74 for ARAP-Security-Data. + + Length + + >=3 + + String + + The String field contains the security module challenge or + response associated with the ARAP Security Module specified in + ARAP-Security. + +5.9. Password-Retry + + Description + + This attribute MAY be included in an Access-Reject to indicate how + many authentication attempts a user may be allowed to attempt + before being disconnected. + + It is primarily intended for use with ARAP authentication. + + + + +Rigney, et al. Informational [Page 28] + +RFC 2869 RADIUS Extensions June 2000 + + + A summary of the Password-Retry attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 75 for Password-Retry. + + Length + + 6 + + Value + + The Value field is four octets, containing an integer specifying + the number of password retry attempts to permit the user. + +5.10. Prompt + + Description + + This attribute is used only in Access-Challenge packets, and + indicates to the NAS whether it should echo the user's response as + it is entered, or not echo it. + + + A summary of the Prompt attribute format is shown below. The fields + are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 76 for Prompt. + + + + +Rigney, et al. Informational [Page 29] + +RFC 2869 RADIUS Extensions June 2000 + + + Length + + 6 + + Value + + The Value field is four octets. + + 0 No Echo + 1 Echo + +5.11. Connect-Info + + Description + + This attribute is sent from the NAS to indicate the nature of the + user's connection. + + The NAS MAY send this attribute in an Access-Request or + Accounting-Request to indicate the nature of the user's + connection. + + A summary of the Connect-Info attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Text... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 77 for Connect-Info. + + Length + + >= 3 + + Text + + The Text field consists of UTF-8 encoded 10646 [8] characters. + The connection speed SHOULD be included at the beginning of the + first Connect-Info attribute in the packet. If the transmit and + receive connection speeds differ, they may both be included in the + first attribute with the transmit speed first (the speed the NAS + modem transmits at), a slash (/), the receive speed, then + optionally other information. + + + +Rigney, et al. Informational [Page 30] + +RFC 2869 RADIUS Extensions June 2000 + + + For example, "28800 V42BIS/LAPM" or "52000/31200 V90" + + More than one Connect-Info attribute may be present in an + Accounting-Request packet to accommodate expected efforts by ITU + to have modems report more connection information in a standard + format that might exceed 252 octets. + +5.12. Configuration-Token + + Description + + This attribute is for use in large distributed authentication + networks based on proxy. It is sent from a RADIUS Proxy Server to + a RADIUS Proxy Client in an Access-Accept to indicate a type of + user profile to be used. It should not be sent to a NAS. + + A summary of the Configuration-Token attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 78 for Configuration-Token. + + Length + + >= 3 + + String + + The String field is one or more octets. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + + The codification of the range of allowed usage of this field is + outside the scope of this specification. + + + + + + + + + + +Rigney, et al. Informational [Page 31] + +RFC 2869 RADIUS Extensions June 2000 + + +5.13. EAP-Message + + Description + + This attribute encapsulates Extended Access Protocol [3] packets + so as to allow the NAS to authenticate dial-in users via EAP + without having to understand the EAP protocol. + + The NAS places any EAP messages received from the user into one or + more EAP attributes and forwards them to the RADIUS Server as part + of the Access-Request, which can return EAP messages in Access- + Challenge, Access-Accept and Access-Reject packets. + + A RADIUS Server receiving EAP messages that it does not understand + SHOULD return an Access-Reject. + + The NAS places EAP messages received from the authenticating peer + into one or more EAP-Message attributes and forwards them to the + RADIUS Server within an Access-Request message. If multiple EAP- + Messages are contained within an Access-Request or Access- + Challenge packet, they MUST be in order and they MUST be + consecutive attributes in the Access-Request or Access-Challenge + packet. Access-Accept and Access-Reject packets SHOULD only have + ONE EAP-Message attribute in them, containing EAP-Success or EAP- + Failure. + + It is expected that EAP will be used to implement a variety of + authentication methods, including methods involving strong + cryptography. In order to prevent attackers from subverting EAP by + attacking RADIUS/EAP, (for example, by modifying the EAP-Success + or EAP-Failure packets) it is necessary that RADIUS/EAP provide + integrity protection at least as strong as those used in the EAP + methods themselves. + + Therefore the Message-Authenticator attribute MUST be used to + protect all Access-Request, Access-Challenge, Access-Accept, and + Access-Reject packets containing an EAP-Message attribute. + + Access-Request packets including an EAP-Message attribute without + a Message-Authenticator attribute SHOULD be silently discarded by + the RADIUS server. A RADIUS Server supporting EAP-Message MUST + calculate the correct value of the Message-Authenticator and + silently discard the packet if it does not match the value sent. + A RADIUS Server not supporting EAP-Message MUST return an Access- + Reject if it receives an Access-Request containing an EAP-Message + attribute. A RADIUS Server receiving an EAP-Message attribute that + it does not understand MUST return an Access-Reject. + + + + +Rigney, et al. Informational [Page 32] + +RFC 2869 RADIUS Extensions June 2000 + + + Access-Challenge, Access-Accept, or Access-Reject packets + including an EAP-Message attribute without a Message-Authenticator + attribute SHOULD be silently discarded by the NAS. A NAS + supporting EAP-Message MUST calculate the correct value of the + Message-Authenticator and silently discard the packet if it does + not match the value sent. + + A summary of the EAP-Message attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 79 for EAP-Message. + + Length + + >= 3 + + String + + The String field contains EAP packets, as defined in [3]. If + multiple EAP-Message attributes are present in a packet their + values should be concatenated; this allows EAP packets longer than + 253 octets to be passed by RADIUS. + +5.14. Message-Authenticator + + Description + + This attribute MAY be used to sign Access-Requests to prevent + spoofing Access-Requests using CHAP, ARAP or EAP authentication + methods. It MAY be used in any Access-Request. It MUST be used + in any Access-Request, Access-Accept, Access-Reject or Access- + Challenge that includes an EAP-Message attribute. + + A RADIUS Server receiving an Access-Request with a Message- + Authenticator Attribute present MUST calculate the correct value + of the Message-Authenticator and silently discard the packet if it + does not match the value sent. + + + + + + +Rigney, et al. Informational [Page 33] + +RFC 2869 RADIUS Extensions June 2000 + + + A RADIUS Client receiving an Access-Accept, Access-Reject or + Access-Challenge with a Message-Authenticator Attribute present + MUST calculate the correct value of the Message-Authenticator and + silently discard the packet if it does not match the value sent. + + Earlier drafts of this memo used "Signature" as the name of this + attribute, but Message-Authenticator is more precise. Its + operation has not changed, just the name. + + A summary of the Message-Authenticator attribute format is shown + below. The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 80 for Message-Authenticator + + Length + + 18 + + String + + When present in an Access-Request packet, Message-Authenticator is + an HMAC-MD5 [9] checksum of the entire Access-Request packet, + including Type, ID, Length and authenticator, using the shared + secret as the key, as follows. + + Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, + Request Authenticator, Attributes) + + When the checksum is calculated the signature string should be + considered to be sixteen octets of zero. + + For Access-Challenge, Access-Accept, and Access-Reject packets, + the Message-Authenticator is calculated as follows, using the + Request-Authenticator from the Access-Request this packet is in + reply to: + + Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, + Request Authenticator, Attributes) + + + + + +Rigney, et al. Informational [Page 34] + +RFC 2869 RADIUS Extensions June 2000 + + + When the checksum is calculated the signature string should be + considered to be sixteen octets of zero. The shared secret is + used as the key for the HMAC-MD5 hash. The is calculated and + inserted in the packet before the Response Authenticator is + calculated. + + This attribute is not needed if the User-Password attribute is + present, but is useful for preventing attacks on other types of + authentication. This attribute is intended to thwart attempts by + an attacker to setup a "rogue" NAS, and perform online dictionary + attacks against the RADIUS server. It does not afford protection + against "offline" attacks where the attacker intercepts packets + containing (for example) CHAP challenge and response, and performs + a dictionary attack against those packets offline. + + IP Security will eventually make this attribute unnecessary, so it + should be considered an interim measure. + +5.15. ARAP-Challenge-Response + + Description + + This attribute is sent in an Access-Accept packet with Framed- + Protocol of ARAP, and contains the response to the dial-in + client's challenge. + + A summary of the ARAP-Challenge-Response attribute format is shown + below. The fields are transmitted from 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 | Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 84 for ARAP-Challenge-Response. + + Length + + 10 + + + + + +Rigney, et al. Informational [Page 35] + +RFC 2869 RADIUS Extensions June 2000 + + + Value + + The Value field contains an 8 octet response to the dial-in + client's challenge. The RADIUS server calculates this value by + taking the dial-in client's challenge from the high order 8 octets + of the ARAP-Password attribute and performing DES encryption on + this value with the authenticating user's password as the key. If + the user's password is less than 8 octets in length, the password + is padded at the end with NULL octets to a length of 8 before + using it as a key. + +5.16. Acct-Interim-Interval + + Description + + This attribute indicates the number of seconds between each + interim update in seconds for this specific session. This value + can only appear in the Access-Accept message. + + A summary of the Acct-Interim-Interval attribute format is shown + below. The fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 85 for Acct-Interim-Interval. + + Length + + 6 + + Value + + The Value field contains the number of seconds between each + interim update to be sent from the NAS for this session. The value + MUST NOT be smaller than 60. The value SHOULD NOT be smaller than + 600, and careful consideration should be given to its impact on + network traffic. + + + + + + +Rigney, et al. Informational [Page 36] + +RFC 2869 RADIUS Extensions June 2000 + + +5.17. NAS-Port-Id + + Description + + This Attribute contains a text string which identifies the port of + the NAS which is authenticating the user. It is only used in + Access-Request and Accounting-Request packets. Note that this is + using "port" in its sense of a physical connection on the NAS, not + in the sense of a TCP or UDP port number. + + Either NAS-Port or NAS-Port-Id SHOULD be present in an Access- + Request packet, if the NAS differentiates among its ports. NAS- + Port-Id is intended for use by NASes which cannot conveniently + number their ports. + + A summary of the NAS-Port-Id Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Text... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 87 for NAS-Port-Id. + + Length + + >= 3 + + Text + + The Text field contains the name of the port using UTF-8 encoded + 10646 [8] characters. + +5.18. Framed-Pool + + Description + + This Attribute contains the name of an assigned address pool that + SHOULD be used to assign an address for the user. If a NAS does + not support multiple address pools, the NAS should ignore this + Attribute. Address pools are usually used for IP addresses, but + can be used for other protocols if the NAS supports pools for + those protocols. + + + +Rigney, et al. Informational [Page 37] + +RFC 2869 RADIUS Extensions June 2000 + + + A summary of the Framed-Pool Attribute format is shown below. The + fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 88 for Framed-Pool + + Length + + >= 3 + + String + + The string field contains the name of an assigned address pool + configured on the NAS. + +5.19. Table of Attributes + + The following table provides a guide to which attributes may be found + in which kind of packets. Acct-Input-Gigawords, Acct-Output- + Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in + an Accounting-Request packet. Connect-Info may have 0+ instances in + an Accounting-Request packet. The other attributes added in this + document must not be present in an Accounting-Request. + +Request Accept Reject Challenge # Attribute +0-1 0 0 0 70 ARAP-Password [Note 1] +0 0-1 0 0-1 71 ARAP-Features +0 0-1 0 0 72 ARAP-Zone-Access +0-1 0 0 0-1 73 ARAP-Security +0+ 0 0 0+ 74 ARAP-Security-Data +0 0 0-1 0 75 Password-Retry +0 0 0 0-1 76 Prompt +0-1 0 0 0 77 Connect-Info +0 0+ 0 0 78 Configuration-Token +0+ 0+ 0+ 0+ 79 EAP-Message [Note 1] +0-1 0-1 0-1 0-1 80 Message-Authenticator [Note 1] +0 0-1 0 0-1 84 ARAP-Challenge-Response +0 0-1 0 0 85 Acct-Interim-Interval +0-1 0 0 0 87 NAS-Port-Id +0 0-1 0 0 88 Framed-Pool +Request Accept Reject Challenge # Attribute + + + +Rigney, et al. Informational [Page 38] + +RFC 2869 RADIUS Extensions June 2000 + + + [Note 1] An Access-Request that contains either a User-Password or + CHAP-Password or ARAP-Password or one or more EAP-Message attributes + MUST NOT contain more than one type of those four attributes. If it + does not contain any of those four attributes, it SHOULD contain a + Message-Authenticator. If any packet type contains an EAP-Message + attribute it MUST also contain a Message-Authenticator. + + The following table defines the above table entries. + + 0 This attribute MUST NOT be present + 0+ Zero or more instances of this attribute MAY be present. + 0-1 Zero or one instance of this attribute MAY be present. + 1 Exactly one instance of this attribute MUST be present. + +6. IANA Considerations + + The Packet Type Codes, Attribute Types, and Attribute Values defined + in this document are registered by the Internet Assigned Numbers + Authority (IANA) from the RADIUS name spaces as described in the + "IANA Considerations" section of [1], in accordance with BCP 26 [10]. + +7. Security Considerations + + The attributes other than Message-Authenticator and EAP-Message in + this document have no additional security considerations beyond those + already identified in [1]. + +7.1. Message-Authenticator Security + + Access-Request packets with a User-Password establish the identity of + both the user and the NAS sending the Access-Request, because of the + way the shared secret between NAS and RADIUS server is used. + Access-Request packets with CHAP-Password or EAP-Message do not have + a User-Password attribute, so the Message-Authenticator attribute + should be used in access-request packets that do not have a User- + Password, in order to establish the identity of the NAS sending the + request. + +7.2. EAP Security + + Since the purpose of EAP is to provide enhanced security for PPP + authentication, it is critical that RADIUS support for EAP be secure. + In particular, the following issues must be addressed: + + Separation of EAP server and PPP authenticator + Connection hijacking + Man in the middle attacks + Multiple databases + + + +Rigney, et al. Informational [Page 39] + +RFC 2869 RADIUS Extensions June 2000 + + + Negotiation attacks + +7.2.1. Separation of EAP server and PPP authenticator + + It is possible for the EAP endpoints to mutually authenticate, + negotiate a ciphersuite, and derive a session key for subsequent use + in PPP encryption. + + This does not present an issue on the peer, since the peer and EAP + client reside on the same machine; all that is required is for the + EAP client module to pass the session key to the PPP encryption + module. + + The situation is more complex when EAP is used with RADIUS, since the + PPP authenticator will typically not reside on the same machine as + the EAP server. For example, the EAP server may be a backend security + server, or a module residing on the RADIUS server. + + In the case where the EAP server and PPP authenticator reside on + different machines, there are several implications for security. + Firstly, mutual authentication will occur between the peer and the + EAP server, not between the peer and the authenticator. This means + that it is not possible for the peer to validate the identity of the + NAS or tunnel server that it is speaking to. + + As described earlier, when EAP/RADIUS is used to encapsulate EAP + packets, the Message-Authenticator attribute is required in + EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the + RADIUS server. Since the Message-Authenticator attribute involves a + HMAC-MD5 hash, it is possible for the RADIUS server to verify the + integrity of the Access-Request as well as the NAS or tunnel server's + identity. Similarly, Access-Challenge packets sent from the RADIUS + server to the NAS are also authenticated and integrity protected + using an HMAC-MD5 hash, enabling the NAS or tunnel server to + determine the integrity of the packet and verify the identity of the + RADIUS server. Moreover, EAP packets sent via methods that contain + their own integrity protection cannot be successfully modified by a + rogue NAS or tunnel server. + + The second issue that arises in the case of an EAP server and PPP + authenticator residing on different machines is that the session key + negotiated between the peer and EAP server will need to be + transmitted to the authenticator. Therefore a mechanism needs to be + provided to transmit the session key from the EAP server to the + authenticator or tunnel server that needs to use the key. The + specification of this transit mechanism is outside the scope of this + document. + + + + +Rigney, et al. Informational [Page 40] + +RFC 2869 RADIUS Extensions June 2000 + + +7.2.2. Connection hijacking + + In this form of attack, the attacker attempts to inject packets into + the conversation between the NAS and the RADIUS server, or between + the RADIUS server and the backend security server. RADIUS does not + support encryption, and as described in [1], only Access-Reply and + Access-Challenge packets are integrity protected. Moreover, the + integrity protection mechanism described in [1] is weaker than that + likely to be used by some EAP methods, making it possible to subvert + those methods by attacking EAP/RADIUS. + + In order to provide for authentication of all packets in the EAP + exchange, all EAP/RADIUS packets MUST be authenticated using the + Message-Authenticator attribute, as described previously. + +7.2.3. Man in the middle attacks + + Since RADIUS security is based on shared secrets, end-to-end security + is not provided in the case where authentication or accounting + packets are forwarded along a proxy chain. As a result, attackers + gaining control of a RADIUS proxy will be able to modify EAP packets + in transit. + +7.2.4. Multiple databases + + In many cases a backend security server will be deployed along with a + RADIUS server in order to provide EAP services. Unless the backend + security server also functions as a RADIUS server, two separate user + databases will exist, each containing information about the security + requirements for the user. This represents a weakness, since security + may be compromised by a successful attack on either of the servers, + or their backend databases. With multiple user databases, adding a + new user may require multiple operations, increasing the chances for + error. The problems are further magnified in the case where user + information is also being kept in an LDAP server. In this case, three + stores of user information may exist. + + In order to address these threats, consolidation of databases is + recommended. This can be achieved by having both the RADIUS server + and backend security server store information in the same backend + database; by having the backend security server provide a full RADIUS + implementation; or by consolidating both the backend security server + and the RADIUS server onto the same machine. + + + + + + + + +Rigney, et al. Informational [Page 41] + +RFC 2869 RADIUS Extensions June 2000 + + +7.2.5. Negotiation attacks + + In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or + RADIUS server causes the authenticating peer to choose a less secure + authentication method so as to make it easier to obtain the user's + password. For example, a session that would normally be authenticated + with EAP would instead authenticated via CHAP or PAP; alternatively, + a connection that would normally be authenticated via one EAP type + occurs via a less secure EAP type, such as MD5. The threat posed by + rogue devices, once thought to be remote, has gained currency given + compromises of telephone company switching systems, such as those + described in [11]. + + Protection against negotiation attacks requires the elimination of + downward negotiations. This can be achieved via implementation of + per-connection policy on the part of the authenticating peer, and + per-user policy on the part of the RADIUS server. + + For the authenticating peer, authentication policy should be set on a + per-connection basis. Per-connection policy allows an authenticating + peer to negotiate EAP when calling one service, while negotiating + CHAP for another service, even if both services are accessible via + the same phone number. + + With per-connection policy, an authenticating peer will only attempt + to negotiate EAP for a session in which EAP support is expected. As a + result, there is a presumption that an authenticating peer selecting + EAP requires that level of security. If it cannot be provided, it is + likely that there is some kind of misconfiguration, or even that the + authenticating peer is contacting the wrong server. Should the NAS + not be able to negotiate EAP, or should the EAP-Request sent by the + NAS be of a different EAP type than what is expected, the + authenticating peer MUST disconnect. An authenticating peer expecting + EAP to be negotiated for a session MUST NOT negotiate CHAP or PAP. + + For a NAS, it may not be possible to determine whether a user is + required to authenticate with EAP until the user's identity is known. + For example, for shared-uses NASes it is possible for one reseller to + implement EAP while another does not. In such cases, if any users of + the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for + every call. This avoids forcing an EAP-capable client to do more than + one authentication, which weakens security. + + If CHAP is negotiated, the NAS will pass the User-Name and CHAP- + Password attributes to the RADIUS Server in an Access-Request packet. + If the user is not required to use EAP, then the RADIUS Server will + respond with an Access-Accept or Access-Reject packet as appropriate. + However, if CHAP has been negotiated but EAP is required, the RADIUS + + + +Rigney, et al. Informational [Page 42] + +RFC 2869 RADIUS Extensions June 2000 + + + server MUST respond with an Access-Reject, rather than an Access- + Challenge/EAP-Message/EAP-Request packet. The authenticating peer + MUST refuse to renegotiate authentication, even if the renegotiation + is from CHAP to EAP. + + If EAP is negotiated but is not supported by the RADIUS proxy or + server, then the server or proxy MUST respond with an Access-Reject. + In these cases, the NAS MUST send an LCP-Terminate and disconnect the + user. This is the correct behavior since the authenticating peer is + expecting EAP to be negotiated, and that expectation cannot be + fulfilled. An EAP-capable authenticating peer MUST refuse to + renegotiate the authentication protocol if EAP had initially been + negotiated. Note that problems with a non-EAP capable RADIUS proxy + could prove difficult to diagnose, since a user dialing in from one + location (with an EAP-capable proxy) might be able to successfully + authenticate via EAP, while the same user dialing into another + location (and encountering an EAP-incapable proxy) might be + consistently disconnected. + +8. References + + [1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote + Authentication Dial In User Service (RADIUS)", RFC 2865, June + 2000. + + [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + + [3] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication + Protocol (EAP)", RFC 2284, March 1998. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March, 1997. + + [5] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, + October 1994. + + [6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and + I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC + 2868, June 2000. + + [7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting + Modifications for Tunnel Protocol Support", RFC 2867, June 2000. + + [8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC + 2279, January 1998. + + + + + + +Rigney, et al. Informational [Page 43] + +RFC 2869 RADIUS Extensions June 2000 + + + [9] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing + for Message Authentication", RFC 2104, February 1997. + + [10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [11] Slatalla, M., and Quittner, J., "Masters of Deception." + HarperCollins, New York, 1995. + +9. Acknowledgements + + RADIUS and RADIUS Accounting were originally developed by Livingston + Enterprises (now part of Lucent Technologies) for their PortMaster + series of Network Access Servers. + + The section on ARAP is adopted with permission from "Using RADIUS to + Authenticate Apple Remote Access Connections" by Ward Willats of Cyno + Technologies (ward@cyno.com). + + The section on Acct-Interim-Interval is adopted with permission from + an earlier work in progress by Pat Calhoun of Sun Microsystems, Mark + Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies. + + The section on EAP is adopted with permission from an earlier work in + progress by Pat Calhoun of Sun Microsystems, Allan Rubens of Merit + Network, and Bernard Aboba of Microsoft. Thanks also to Dave Dawson + and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of + Microsoft for useful discussions of this problem space. + +10. Chair's Address + + The RADIUS working group can be contacted via the current chair: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + Phone: +1 925 737 2100 + EMail: cdr@telemancy.com + + + + + + + + + + + +Rigney, et al. Informational [Page 44] + +RFC 2869 RADIUS Extensions June 2000 + + +11. Authors' Addresses + + Questions about this memo can also be directed to: + + Carl Rigney + Livingston Enterprises + 4464 Willow Road + Pleasanton, California 94588 + + EMail: cdr@telemancy.com + + Questions on ARAP and RADIUS may be directed to: + + Ward Willats + Cyno Technologies + 1082 Glen Echo Ave + San Jose, CA 95125 + + Phone: +1 408 297 7766 + EMail: ward@cyno.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rigney, et al. Informational [Page 45] + +RFC 2869 RADIUS Extensions June 2000 + + + Questions on EAP and RADIUS may be directed to any of the following: + + Pat R. Calhoun + Network and Security Research Center + Sun Microsystems, Inc. + 15 Network Circle + Menlo Park, CA 94025 + + Phone: +1 650 786 7733 + EMail: pcalhoun@eng.sun.com + + + Allan C. Rubens + Tut Systems, Inc. + 220 E. Huron, Suite 260 + Ann Arbor, MI 48104 + + Phone: +1 734 995 1697 + EMail: arubens@tutsys.com + + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 936 6605 + EMail: bernarda@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + +Rigney, et al. Informational [Page 46] + +RFC 2869 RADIUS Extensions June 2000 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Rigney, et al. Informational [Page 47] + diff --git a/rfc/rfc3078.txt b/rfc/rfc3078.txt new file mode 100644 index 00000000..5bbcc130 --- /dev/null +++ b/rfc/rfc3078.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group G. Pall +Request for Comments: 3078 Microsoft Corporation +Category: Informational G. Zorn +Updates: 2118 cisco Systems + March 2001 + + + Microsoft Point-To-Point Encryption (MPPE) Protocol + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + The Point-to-Point Protocol (PPP) provides a standard method for + transporting multi-protocol datagrams over point-to-point links. + + The PPP Compression Control Protocol provides a method to negotiate + and utilize compression protocols over PPP encapsulated links. + + This document describes the use of the Microsoft Point to Point + Encryption (MPPE) to enhance the confidentiality of PPP-encapsulated + packets. + +Specification of Requirements + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as + described in [5]. + +1. Introduction + + The Microsoft Point to Point Encryption scheme is a means of + representing Point to Point Protocol (PPP) packets in an encrypted + form. + + MPPE uses the RSA RC4 [3] algorithm to provide data confidentiality. + The length of the session key to be used for initializing encryption + tables can be negotiated. MPPE currently supports 40-bit and 128-bit + session keys. + + + + +Pall & Zorn Informational [Page 1] + +RFC 3078 MPPE Protocol March 2001 + + + MPPE session keys are changed frequently; the exact frequency depends + upon the options negotiated, but may be every packet. + + MPPE is negotiated within option 18 [4] in the Compression Control + Protocol. + +2. Configuration Option Format + + + Description + + The CCP Configuration Option negotiates the use of MPPE on the + link. By default (i.e., if the negotiation of MPPE is not + attempted), no encryption is used. If, however, MPPE negotiation + is attempted and fails, the link SHOULD be terminated. + + A summary of the CCP Configuration Option format is shown below. The + fields are transmitted from 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 | Supported Bits | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Supported Bits | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 18 + + Length + + 6 + + Supported Bits + + This field is 4 octets, most significant octet first. + + 3 2 1 + 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |H| |M|S|L|D| |C| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Pall & Zorn Informational [Page 2] + +RFC 3078 MPPE Protocol March 2001 + + + The 'C' bit is used by MPPC [4] and is not discussed further in this + memo. The 'D' bit is obsolete; although some older peers may attempt + to negotiate this option, it SHOULD NOT be accepted. If the 'L' bit + is set (corresponding to a value of 0x20 in the least significant + octet), this indicates the desire of the sender to negotiate the use + of 40-bit session keys. If the 'S' bit is set (corresponding to a + value of 0x40 in the least significant octet), this indicates the + desire of the sender to negotiate the use of 128-bit session keys. + If the 'M' bit is set (corresponding to a value of 0x80 in the least + significant octet), this indicates the desire of the sender to + negotiate the use of 56-bit session keys. If the 'H' bit is set + (corresponding to a value of 0x01 in the most significant octet), + this indicates that the sender wishes to negotiate the use of + stateless mode, in which the session key is changed after the + transmission of each packet (see section 10, below). In the + following discussion, the 'S', 'M' and 'L' bits are sometimes + referred to collectively as "encryption options". + + All other bits are reserved and MUST be set to 0. + +2.1. Option Negotiation + + MPPE options are negotiated as described in [2]. In particular, the + negotiation initiator SHOULD request all of the options it supports. + The responder SHOULD NAK with a single encryption option (note that + stateless mode may always be negotiated, independent of and in + addition to an encryption option). If the responder supports more + than one encryption option in the set requested by the initiator, the + option selected SHOULD be the "strongest" option offered. + Informally, the strength of the MPPE encryption options may be + characterized as follows: + + STRONGEST + 128-bit encryption ('S' bit set) + 56-bit encryption ('M' bit set) + 40-bit encryption ('L' bit set) + WEAKEST + + This characterization takes into account the generally accepted + strength of the cipher. + + The initiator SHOULD then either send another request containing the + same option(s) as the responder's NAK or cancel the negotiation, + dropping the connection. + + + + + + + +Pall & Zorn Informational [Page 3] + +RFC 3078 MPPE Protocol March 2001 + + +3. MPPE Packets + + Before any MPPE packets are transmitted, PPP MUST reach the Network- + Layer Protocol phase and the CCP Control Protocol MUST reach the + Opened state. + + Exactly one MPPE datagram is encapsulated in the PPP Information + field. The PPP Protocol field indicates type 0x00FD for all + encrypted datagrams. + + The maximum length of the MPPE datagram transmitted over a PPP link + is the same as the maximum length of the Information field of a PPP + encapsulated packet. + + Only packets with PPP Protocol numbers in the range 0x0021 to 0x00FA + are encrypted. Other packets are not passed thru the MPPE processor + and are sent with their original PPP Protocol numbers. + + Padding + + It is recommended that padding not be used with MPPE. If the + sender uses padding it MUST negotiate the Self-Describing- + Padding Configuration option [10] during LCP phase and use + self-describing pads. + + Reliability and Sequencing + + The MPPE scheme does not require a reliable link. Instead, it + relies on a 12-bit coherency count in each packet to keep the + encryption tables synchronized. If stateless mode has not been + negotiated and the coherency count in the received packet does + not match the expected count, the receiver MUST send a CCP + Reset-Request packet to cause the resynchronization of the RC4 + tables. + + MPPE expects packets to be delivered in sequence. + + MPPE MAY be used over a reliable link, as described in "PPP + Reliable Transmission" [6], but this typically just adds + unnecessary overhead since only the coherency count is + required. + + Data Expansion + + The MPPE scheme does not expand or compress data. The number + of octets input to and output from the MPPE processor are the + same. + + + + +Pall & Zorn Informational [Page 4] + +RFC 3078 MPPE Protocol March 2001 + + +3.1. Packet Format + + A summary of the MPPE packet format is shown below. The fields are + transmitted from 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PPP Protocol |A|B|C|D| Coherency Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Encrypted Data... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + PPP Protocol + + The PPP Protocol field is described in the Point-to-Point + Protocol Encapsulation [1]. + + When MPPE is successfully negotiated by the PPP Compression + Control Protocol, the value of this field is 0x00FD. This + value MAY be compressed when Protocol-Field-Compression is + negotiated. + + Bit A + + This bit indicates that the encryption tables were initialized + before this packet was generated. The receiver MUST re- + initialize its tables with the current session key before + decrypting this packet. This bit is referred to as the FLUSHED + bit in this document. If the stateless option has been + negotiated, this bit MUST be set on every encrypted packet. + Note that MPPC and MPPE both recognize the FLUSHED bit; + therefore, if the stateless option is negotiated, it applies to + both MPPC and MPPE. + + Bit B + + This bit does not have any significance in MPPE. + + Bit C + + This bit does not have any significance in MPPE. + + Bit D + + This bit set to 1 indicates that the packet is encrypted. This + bit set to 0 means that this packet is not encrypted. + + + + +Pall & Zorn Informational [Page 5] + +RFC 3078 MPPE Protocol March 2001 + + + Coherency Count + + The coherency count is used to assure that the packets are sent + in proper order and that no packet has been dropped. It is a + monotonically increasing counter which incremented by 1 for + each packet sent. When the counter reaches 4095 (0x0FFF), it + is reset to 0. + + Encrypted Data + + The encrypted data begins with the protocol field. For + example, in case of an IP packet (0x0021 followed by an IP + header), the MPPE processor will first encrypt the protocol + field and then encrypt the IP header. + + If the packet contains header compression, the MPPE processor + is applied AFTER header compression is performed and MUST be + applied to the compressed header as well. For example, if a + packet contained the protocol type 0x002D (for a compressed + TCP/IP header), the MPPE processor would first encrypt 0x002D + and then it would encrypt the compressed Van-Jacobsen TCP/IP + header. + + Implementation Note + + If both MPPE and MPPC are negotiated on the same link, the MPPE + processor MUST be invoked after the MPPC processor by the + sender and the MPPE processor MUST be invoked before the MPPC + processor by the receiver. + +4. Initial Session Keys + + In the current implementation, initial session keys are derived from + peer credentials; however, other derivation methods are possible. + For example, some authentication methods (such as Kerberos [8] and + TLS [9]) produce session keys as side effects of authentication; + these keys may be used by MPPE in the future. For this reason, the + techniques used to derive initial MPPE session keys are described in + separate documents. + +5. Initializing RC4 Using a Session Key + + Once an initial session key has been derived, the RC4 context is + initialized as follows: + + rc4_key(RC4Key, Length_Of_Key, Initial_Session_Key) + + + + + +Pall & Zorn Informational [Page 6] + +RFC 3078 MPPE Protocol March 2001 + + +6. Encrypting Data + + Once initialized, data is encrypted using the following function and + transmitted with the CCP and MPPE headers. + + EncryptedData = rc4(RC4Key, Length_Of_Data, Data) + +7. Changing Keys + +7.1. Stateless Mode Key Changes + + If stateless encryption has been negotiated, the session key changes + every time the coherency count changes; i.e., on every packet. In + stateless mode, the sender MUST change its key before encrypting and + transmitting each packet and the receiver MUST change its key after + receiving, but before decrypting, each packet (see "Synchronization", + below). + +7.2. Stateful Mode Key Changes + + If stateful encryption has been negotiated, the sender MUST change + its key before encrypting and transmitting any packet in which the + low order octet of the coherency count equals 0xFF (the "flag" + packet), and the receiver MUST change its key after receiving, but + before decrypting, a "flag" packet (see "Synchronization", below). + +7.3. The MPPE Key Change Algorithm + + The following method is used to change keys: + + /* + * SessionKeyLength is 8 for 40-bit keys, 16 for 128-bit keys. + * + * SessionKey is the same as StartKey in the first call for + * a given session. + */ + + void + GetNewKeyFromSHA( + IN unsigned char *StartKey, + IN unsigned char *SessionKey, + IN unsigned long SessionKeyLength + OUT unsigned char *InterimKey ) + { + unsigned char Digest[20]; + + ZeroMemory(Digest, 20); + + + + +Pall & Zorn Informational [Page 7] + +RFC 3078 MPPE Protocol March 2001 + + + /* + * SHAInit(), SHAUpdate() and SHAFinal() + * are an implementation of the Secure + * Hash Algorithm [7] + */ + + SHAInit(Context); + SHAUpdate(Context, StartKey, SessionKeyLength); + SHAUpdate(Context, SHApad1, 40); + SHAUpdate(Context, SessionKey, SessionKeyLength); + SHAUpdate(Context, SHApad2, 40); + SHAFinal(Context, Digest); + + MoveMemory(InterimKey, Digest, SessionKeyLength); + } + + The RC4 tables are re-initialized using the newly created interim key: + + rc4_key(RC4Key, Length_Of_Key, InterimKey) + + Finally, the interim key is encrypted using the new tables to produce + a new session key: + + SessionKey = rc4(RC4Key, Length_Of_Key, InterimKey) + + For 40-bit session keys the most significant three octets of the new + session key are now set to 0xD1, 0x26 and 0x9E respectively; for 56- + bit keys, the most significant octet is set to 0xD1. + + Finally, the RC4 tables are re-initialized using the new session key: + + rc4_key(RC4Key, Length_Of_Key, SessionKey) + +8. Synchronization + + Packets may be lost during transfer. The following sections describe + synchronization for both the stateless and stateful cases. + +8.1. Stateless Synchronization + + If stateless encryption has been negotiated and the coherency count + in the received packet (C1) is greater than the coherency count in + the last packet previously received (C2), the receiver MUST perform N + = C1 - C2 key changes before decrypting the packet, in order to + ensure that its session key is synchronized with the session key of + the sender. Normally, the value of N will be 1; however, if + intervening packets have been lost, N may be greater than 1. For + example, if C1 = 5 and C2 = 02 then N = 3 key changes are required. + + + +Pall & Zorn Informational [Page 8] + +RFC 3078 MPPE Protocol March 2001 + + + Since the FLUSHED bit is set on every packet if stateless encryption + was negotiated, the transmission of CCP Reset-Request packets is not + required for synchronization. + +8.2. Stateful Synchronization + + If stateful encryption has been negotiated, the sender MUST change + its key before encrypting and transmitting any packet in which the + low order octet of the coherency count equals 0xFF (the "flag" + packet), and the receiver MUST change its key after receiving, but + before decrypting, a "flag" packet. However, the "flag" packet may + be lost. If this happens, the low order octet of the coherency count + in the received packet will be less than that in the last packet + previously received. In this case, the receiver MUST perform a key + change before decrypting the newly received packet, (since the sender + will have changed its key before transmitting the packet), then send + a CCP Reset-Request packet (see below). It is possible that 256 or + more consecutive packets could be lost; the receiver SHOULD detect + this condition and perform the number of key changes necessary to + resynchronize with the sender. + + If packet loss is detected while using stateful encryption, the + receiver MUST drop the packet and send a CCP Reset-Request packet + without data. After transmitting the CCP Reset-Request packet, the + receiver SHOULD silently discard all packets until a packet is + received with the FLUSHED bit set. On receiving a packet with the + FLUSHED bit set, the receiver MUST set its coherency count to the one + received in that packet and re-initialize its RC4 tables using the + current session key: + + rc4_key(RC4Key, Length_Of_Key, SessionKey) + + When the sender receives a CCP Reset-Request packet, it MUST re- + initialize its own RC4 tables using the same method and set the + FLUSHED bit in the next packet sent. Thus synchronization is + achieved without a CCP Reset-Ack packet. + +9. Security Considerations + + Because of the way that the RC4 tables are reinitialized during + stateful synchronization, it is possible that two packets may be + encrypted using the same key. For this reason, the stateful mode + SHOULD NOT be used in lossy network environments (e.g., layer two + tunnels on the Internet). + + + + + + + +Pall & Zorn Informational [Page 9] + +RFC 3078 MPPE Protocol March 2001 + + + Since the MPPE negotiation is not integrity protected, an active + attacker could alter the strength of the keys used by modifying the + Supported Bits field of the CCP Configuration Option packet. The + effects of this attack can be minimized through appropriate peer + configuration, however. + + Peers MUST NOT transmit user data until the MPPE negotiation is + complete. + + It is possible that an active attacker could modify the coherency + count of a packet, causing the peers to lose synchronization. + + An active denial-of-service attack could be mounted by methodically + inverting the value of the 'D' bit in the MPPE packet header. + +10. References + + [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + [2] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC + 1962, June 1996. + + [3] RC4 is a proprietary encryption algorithm available under + license from RSA Data Security Inc. For licensing information, + contact: + + RSA Data Security, Inc. + 100 Marine Parkway + Redwood City, CA 94065-1031 + + [4] Pall, G., "Microsoft Point-to-Point Compression (MPPC) + Protocol", RFC 2118, March 1997. + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [6] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994. + + [7] "Secure Hash Standard", Federal Information Processing Standards + Publication 180-1, National Institute of Standards and + Technology, April 1995. + + [8] Kohl, J. and C. Neuman "The Kerberos Network Authentication + System (V5)", RFC 1510, September 1993. + + [9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC + 2246, January 1999. + + + +Pall & Zorn Informational [Page 10] + +RFC 3078 MPPE Protocol March 2001 + + + [10] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January + 1994. + +11. Acknowledgements + + Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all + of Microsoft Corporation, significantly contributed to the design and + development of MPPE. + + Additional thanks to Robert Friend, Joe Davies, Jody Terrill, Archie + Cobbs, Mark Deuser, and Jeff Haag, for useful feedback. + +12. Authors' Addresses + + Questions about this memo can be directed to: + + Gurdeep Singh Pall + Microsoft Corporation + One Microsoft Way + Redmond, Washington 98052 + USA + + Phone: +1 425 882 8080 + Fax: +1 425 936 7329 + EMail: gurdeep@microsoft.com + + + Glen Zorn + cisco Systems + 500 108th Avenue N.E. + Suite 500 + Bellevue, Washington 98004 + USA + + Phone: +1 425 438 8218 + Fax: +1 425 438 1848 + EMail: gwz@cisco.com + + + + + + + + + + + + + + +Pall & Zorn Informational [Page 11] + +RFC 3078 MPPE Protocol March 2001 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Pall & Zorn Informational [Page 12] + diff --git a/rfc/rfc3079.txt b/rfc/rfc3079.txt new file mode 100644 index 00000000..4d7ba0de --- /dev/null +++ b/rfc/rfc3079.txt @@ -0,0 +1,1179 @@ + + + + + + +Network Working Group G. Zorn +Request for Comments: 3079 cisco Systems +Category: Informational March 2001 + + + Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + The Point-to-Point Protocol (PPP) provides a standard method for + transporting multi-protocol datagrams over point-to-point links. + + The PPP Compression Control Protocol provides a method to negotiate + and utilize compression protocols over PPP encapsulated links. + + Microsoft Point to Point Encryption (MPPE) is a means of representing + PPP packets in an encrypted form. MPPE uses the RSA RC4 algorithm to + provide data confidentiality. The length of the session key to be + used for initializing encryption tables can be negotiated. MPPE + currently supports 40-bit, 56-bit and 128-bit session keys. MPPE + session keys are changed frequently; the exact frequency depends upon + the options negotiated, but may be every packet. MPPE is negotiated + within option 18 in the Compression Control Protocol. + + This document describes the method used to derive initial MPPE + session keys from a variety of credential types. It is expected that + this memo will be updated whenever Microsoft defines a new key + derivation method for MPPE, since its primary purpose is to provide + an open, easily accessible reference for third-parties wishing to + interoperate with Microsoft products. + + MPPE itself (including the protocol used to negotiate its use, the + details of the encryption method used and the algorithm used to + change session keys during a session) is described in RFC 3078. + + + + + + + +Zorn Informational [Page 1] + +RFC 3079 MPPE Key Derivation March 2001 + + +Table of Contents + + 1. Specification of Requirements ............................... 2 + 2. Deriving Session Keys from MS-CHAP Credentials .............. 2 + 2.1. Generating 40-bit Session Keys ............................ 3 + 2.2. Generating 56-bit Session Keys ............................ 3 + 2.3. Generating 128-bit Session Keys ........................... 4 + 2.4. Key Derivation Functions .................................. 5 + 2.5. Sample Key Derivations .................................... 6 + 2.5.1. Sample 40-bit Key Derivation ............................ 6 + 2.5.2. Sample 56-bit Key Derivation ............................ 6 + 2.5.3. Sample 128-bit Key Derivation ........................... 7 + 3. Deriving Session Keys from MS-CHAP-2 Credentials ............ 7 + 3.1. Generating 40-bit Session Keys ............................ 8 + 3.2. Generating 56-bit Session Keys ............................ 9 + 3.3. Generating 128-bit Session Keys ...........................10 + 3.4. Key Derivation Functions ..................................11 + 3.5. Sample Key Derivations ....................................13 + 3.5.1. Sample 40-bit Key Derivation ............................13 + 3.5.2. Sample 56-bit Key Derivation ............................14 + 3.5.3. Sample 128-bit Key Derivation ...........................15 + 4. Deriving MPPE Session Keys from TLS Session Keys ............16 + 4.1. Generating 40-bit Session Keys ............................16 + 4.2. Generating 56-bit Session Keys ............................17 + 4.3. Generating 128-bit Session Keys ...........................17 + 5. Security Considerations .....................................18 + 5.1. MS-CHAP Credentials .......................................18 + 5.2. EAP-TLS Credentials .......................................19 + 6. References ..................................................19 + 7. Acknowledgements ............................................20 + 8. Author's Address ............................................20 + 9. Full Copyright Statement ....................................21 + +1. Specification of Requirements + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as + described in [6]. + +2. Deriving Session Keys from MS-CHAP Credentials + + The Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP-1) + [2] is a Microsoft-proprietary PPP [1] authentication protocol, + providing the functionality to which LAN-based users are accustomed + while integrating the encryption and hashing algorithms used on + Windows networks. + + + + + +Zorn Informational [Page 2] + +RFC 3079 MPPE Key Derivation March 2001 + + + The following sections detail the methods used to derive initial + session keys (40-, 56- and 128-bit) from MS-CHAP-1 credentials. + + Implementation Note + + The initial session key in both directions is derived from the + credentials of the peer that initiated the call and the challenge + used (if any) is the challenge from the first authentication. + This is true for both unilateral and bilateral authentication, as + well as for each link in a multilink bundle. In the multi-chassis + multilink case, implementations are responsible for ensuring that + the correct keys are generated on all participating machines. + +2.1. Generating 40-bit Session Keys + + MPPE uses a derivative of the peer's LAN Manager password as the 40- + bit session key used for initializing the RC4 encryption tables. + + The first step is to obfuscate the peer's password using the + LmPasswordHash() function (described in [2]). The first 8 octets of + the result are used as the basis for the session key generated in the + following way: + +/* +* PasswordHash is the basis for the session key +* SessionKey is a copy of PasswordHash and is the generative session key +* 8 is the length (in octets) of the key to be generated. +* +*/ +Get_Key(PasswordHash, SessionKey, 8) + +/* +* The effective length of the key is reduced to 40 bits by +* replacing the first three bytes as follows: +*/ +SessionKey[0] = 0xd1 ; +SessionKey[1] = 0x26 ; +SessionKey[2] = 0x9e ; + +2.2. Generating 56-bit Session Keys + + MPPE uses a derivative of the peer's LAN Manager password as the 56- + bit session key used for initializing the RC4 encryption tables. + + The first step is to obfuscate the peer's password using the + LmPasswordHash() function (described in [2]). The first 8 octets of + the result are used as the basis for the session key generated in the + following way: + + + +Zorn Informational [Page 3] + +RFC 3079 MPPE Key Derivation March 2001 + + +/* +* PasswordHash is the basis for the session key +* SessionKey is a copy of PasswordHash and is the generative session key +* 8 is the length (in octets) of the key to be generated. +* +*/ +Get_Key(PasswordHash, SessionKey, 8) + +/* +* The effective length of the key is reduced to 56 bits by +* replacing the first byte as follows: +*/ +SessionKey[0] = 0xd1 ; + +2.3. Generating 128-bit Session Keys + + MPPE uses a derivative of the peer's Windows NT password as the 128- + bit session key used for initializing encryption tables. + + The first step is to obfuscate the peer's password using + NtPasswordHash() function as described in [2]. The first 16 octets + of the result are then hashed again using the MD4 algorithm. The + first 16 octets of the second hash are used as the basis for the + session key generated in the following way: + +/* +* Challenge (as described in [9]) is sent by the PPP authenticator +* during authentication and is 8 octets long. +* NtPasswordHashHash is the basis for the session key. +* On return, InitialSessionKey contains the initial session +* key to be used. +*/ +Get_Start_Key(Challenge, NtPasswordHashHash, InitialSessionKey) + +/* +* CurrentSessionKey is a copy of InitialSessionKey +* and is the generative session key. +* Length (in octets) of the key to generate is 16. +* +*/ +Get_Key(InitialSessionKey, CurrentSessionKey, 16) + + + + + + + + + + +Zorn Informational [Page 4] + +RFC 3079 MPPE Key Derivation March 2001 + + +2.4. Key Derivation Functions + + The following procedures are used to derive the session key. + +/* + * Pads used in key derivation + */ + +SHApad1[40] = + {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; + +SHApad2[40] = + {0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, + 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, + 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, + 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2}; + +/* + * SHAInit(), SHAUpdate() and SHAFinal() functions are an + * implementation of Secure Hash Algorithm (SHA-1) [7]. These are + * available in public domain or can be licensed from + * RSA Data Security, Inc. + * + * 1) InitialSessionKey is 8 octets long for 56- and 40-bit + * session keys, 16 octets long for 128 bit session keys. + * 2) CurrentSessionKey is same as InitialSessionKey when this + * routine is called for the first time for the session. + */ + +Get_Key( +IN InitialSessionKey, +IN/OUT CurrentSessionKey +IN LengthOfDesiredKey ) +{ + SHAInit(Context) + SHAUpdate(Context, InitialSessionKey, LengthOfDesiredKey) + SHAUpdate(Context, SHAPad1, 40) + SHAUpdate(Context, CurrentSessionKey, LengthOfDesiredKey) + SHAUpdate(Context, SHAPad2, 40) + SHAFinal(Context, Digest) + memcpy(CurrentSessionKey, Digest, LengthOfDesiredKey) +} + +Get_Start_Key( +IN Challenge, + + + +Zorn Informational [Page 5] + +RFC 3079 MPPE Key Derivation March 2001 + + +IN NtPasswordHashHash, +OUT InitialSessionKey) +{ + SHAInit(Context) + SHAUpdate(Context, NtPasswordHashHash, 16) + SHAUpdate(Context, NtPasswordHashHash, 16) + SHAUpdate(Context, Challenge, 8) + SHAFinal(Context, Digest) + memcpy(InitialSessionKey, Digest, 16) +} + +2.5. Sample Key Derivations + + The following sections illustrate 40-, 56- and 128-bit key + derivations. All intermediate values are in hexadecimal. + +2.5.1. Sample 40-bit Key Derivation + + + Initial Values + Password = "clientPass" + + Step 1: LmPasswordHash(Password, PasswordHash) + PasswordHash = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2 + + Step 2: Copy PasswordHash to SessionKey + SessionKey = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2 + + Step 3: GetKey(PasswordHash, SessionKey, 8) + SessionKey = d8 08 01 53 8c ec 4a 08 + + Step 4: Reduce the effective key length to 40 bits + SessionKey = d1 26 9e 53 8c ec 4a 08 + +2.5.2. Sample 56-bit Key Derivation + + Initial Values + Password = "clientPass" + + Step 1: LmPasswordHash(Password, PasswordHash) + PasswordHash = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2 + + Step 2: Copy PasswordHash to SessionKey + SessionKey = 76 a1 52 93 60 96 d7 83 0e 23 90 22 74 04 af d2 + + Step 3: GetKey(PasswordHash, SessionKey, 8) + SessionKey = d8 08 01 53 8c ec 4a 08 + + + + +Zorn Informational [Page 6] + +RFC 3079 MPPE Key Derivation March 2001 + + + Step 4: Reduce the effective key length to 56 bits + SessionKey = d1 08 01 53 8c ec 4a 08 + +2.5.3. Sample 128-bit Key Derivation + +Initial Values + Password = "clientPass" + Challenge = 10 2d b5 df 08 5d 30 41 + +Step 1: NtPasswordHash(Password, PasswordHash) + PasswordHash = 44 eb ba 8d 53 12 b8 d6 11 47 44 11 f5 69 89 ae + +Step 2: PasswordHashHash = MD4(PasswordHash) + PasswordHashHash = 41 c0 0c 58 4b d2 d9 1c 40 17 a2 a1 2f a5 9f 3f + +Step 3: GetStartKey(Challenge, PasswordHashHash, InitialSessionKey) + InitialSessionKey = a8 94 78 50 cf c0 ac ca d1 78 9f b6 2d dc dd b0 + +Step 4: Copy InitialSessionKey to CurrentSessionKey + CurrentSessionKey = a8 94 78 50 cf c0 ac c1 d1 78 9f b6 2d dc dd b0 + +Step 5: GetKey(InitialSessionKey, CurrentSessionKey, 16) + CurrentSessionKey = 59 d1 59 bc 09 f7 6f 1d a2 a8 6a 28 ff ec 0b 1e + +3. Deriving Session Keys from MS-CHAP-2 Credentials + + Version 2 of the Microsoft Challenge-Handshake Authentication + Protocol (MS-CHAP-2) [8] is a Microsoft-proprietary PPP + authentication protocol, providing the functionality to which LAN- + based users are accustomed while integrating the encryption and + hashing algorithms used on Windows networks. + + The following sections detail the methods used to derive initial + session keys from MS-CHAP-2 credentials. 40-, 56- and 128-bit keys + are all derived using the same algorithm from the authenticating + peer's Windows NT password. The only difference is in the length of + the keys and their effective strength: 40- and 56-bit keys are 8 + octets in length, while 128-bit keys are 16 octets long. Separate + keys are derived for the send and receive directions of the session. + + Implementation Note + + The initial session keys in both directions are derived from the + credentials of the peer that initiated the call and the challenges + used are those from the first authentication. This is true as + well for each link in a multilink bundle. In the multi-chassis + multilink case, implementations are responsible for ensuring that + the correct keys are generated on all participating machines. + + + +Zorn Informational [Page 7] + +RFC 3079 MPPE Key Derivation March 2001 + + +3.1. Generating 40-bit Session Keys + + When used in conjunction with MS-CHAP-2 authentication, the initial + MPPE session keys are derived from the peer's Windows NT password. + + The first step is to obfuscate the peer's password using + NtPasswordHash() function as described in [8]. + + NtPasswordHash(Password, PasswordHash) + + The first 16 octets of the result are then hashed again using the MD4 + algorithm. + + PasswordHashHash = md4(PasswordHash) + + The first 16 octets of this second hash are used together with the + NT- Response field from the MS-CHAP-2 Response packet [8] as the + basis for the master session key: + + GetMasterKey(PasswordHashHash, NtResponse, MasterKey) + + Once the master key has been generated, it is used to derive two 40- + bit session keys, one for sending and one for receiving: + + GetAsymmetricStartKey(MasterKey, MasterSendKey, 8, TRUE, TRUE) + GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 8, FALSE, TRUE) + + The master session keys are never used to encrypt or decrypt data; + they are only used in the derivation of transient session keys. The + initial transient session keys are obtained by calling the function + GetNewKeyFromSHA() (described in [3]): + +GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey) +GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8, + ReceiveSessionKey) + + Next, the effective strength of both keys is reduced by setting the + first three octets to known constants: + + SendSessionKey[0] = ReceiveSessionKey[0] = 0xd1 + SendSessionKey[1] = ReceiveSessionKey[1] = 0x26 + SendSessionKey[2] = ReceiveSessionKey[2] = 0x9e + + Finally, the RC4 tables are initialized using the new session keys: + + rc4_key(SendRC4key, 8, SendSessionKey) + rc4_key(ReceiveRC4key, 8, ReceiveSessionKey) + + + + +Zorn Informational [Page 8] + +RFC 3079 MPPE Key Derivation March 2001 + + +3.2. Generating 56-bit Session Keys + + When used in conjunction with MS-CHAP-2 authentication, the initial + MPPE session keys are derived from the peer's Windows NT password. + + The first step is to obfuscate the peer's password using + NtPasswordHash() function as described in [8]. + + NtPasswordHash(Password, PasswordHash) + + The first 16 octets of the result are then hashed again using the MD4 + algorithm. + + PasswordHashHash = md4(PasswordHash) + + The first 16 octets of this second hash are used together with the + NT-Response field from the MS-CHAP-2 Response packet [8] as the basis + for the master session key: + + GetMasterKey(PasswordHashHash, NtResponse, MasterKey) + + Once the master key has been generated, it is used to derive two + 56-bit session keys, one for sending and one for receiving: + + GetAsymmetricStartKey(MasterKey, MasterSendKey, 8, TRUE, TRUE) + GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 8, FALSE, TRUE) + + The master session keys are never used to encrypt or decrypt data; + they are only used in the derivation of transient session keys. The + initial transient session keys are obtained by calling the function + GetNewKeyFromSHA() (described in [3]): + +GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey) +GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8, + ReceiveSessionKey) + + Next, the effective strength of both keys is reduced by setting the + first octet to a known constant: + + SendSessionKey[0] = ReceiveSessionKey[0] = 0xd1 + + Finally, the RC4 tables are initialized using the new session keys: + + rc4_key(SendRC4key, 8, SendSessionKey) + rc4_key(ReceiveRC4key, 8, ReceiveSessionKey) + + + + + + +Zorn Informational [Page 9] + +RFC 3079 MPPE Key Derivation March 2001 + + +3.3. Generating 128-bit Session Keys + + When used in conjunction with MS-CHAP-2 authentication, the initial + MPPE session keys are derived from the peer's Windows NT password. + + The first step is to obfuscate the peer's password using + NtPasswordHash() function as described in [8]. + + NtPasswordHash(Password, PasswordHash) + + The first 16 octets of the result are then hashed again using the MD4 + algorithm. + + PasswordHashHash = md4(PasswordHash) + + The first 16 octets of this second hash are used together with the + NT-Response field from the MS-CHAP-2 Response packet [8] as the basis + for the master session key: + + GetMasterKey(PasswordHashHash, NtResponse, MasterKey) + + Once the master key has been generated, it is used to derive two + 128-bit master session keys, one for sending and one for receiving: + +GetAsymmetricStartKey(MasterKey, MasterSendKey, 16, TRUE, TRUE) +GetAsymmetricStartKey(MasterKey, MasterReceiveKey, 16, FALSE, TRUE) + + The master session keys are never used to encrypt or decrypt data; + they are only used in the derivation of transient session keys. The + initial transient session keys are obtained by calling the function + GetNewKeyFromSHA() (described in [3]): + +GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey) +GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16, + ReceiveSessionKey) + + Finally, the RC4 tables are initialized using the new session keys: + + rc4_key(SendRC4key, 16, SendSessionKey) + rc4_key(ReceiveRC4key, 16, ReceiveSessionKey) + + + + + + + + + + + +Zorn Informational [Page 10] + +RFC 3079 MPPE Key Derivation March 2001 + + +3.4. Key Derivation Functions + + The following procedures are used to derive the session key. + +/* + * Pads used in key derivation + */ + +SHSpad1[40] = + {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; + +SHSpad2[40] = + {0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, + 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, + 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, + 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2, 0xf2}; + +/* + * "Magic" constants used in key derivations + */ + +Magic1[27] = + {0x54, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, + 0x68, 0x65, 0x20, 0x4d, 0x50, 0x50, 0x45, 0x20, 0x4d, + 0x61, 0x73, 0x74, 0x65, 0x72, 0x20, 0x4b, 0x65, 0x79}; + +Magic2[84] = + {0x4f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6c, 0x69, + 0x65, 0x6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2c, 0x20, + 0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, + 0x65, 0x20, 0x73, 0x65, 0x6e, 0x64, 0x20, 0x6b, 0x65, 0x79, + 0x3b, 0x20, 0x6f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x73, + 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73, 0x69, 0x64, 0x65, + 0x2c, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, + 0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20, + 0x6b, 0x65, 0x79, 0x2e}; + +Magic3[84] = + {0x4f, 0x6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, 0x6c, 0x69, + 0x65, 0x6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, 0x2c, 0x20, + 0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, + 0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20, + 0x6b, 0x65, 0x79, 0x3b, 0x20, 0x6f, 0x6e, 0x20, 0x74, 0x68, + 0x65, 0x20, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73, + 0x69, 0x64, 0x65, 0x2c, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, + + + +Zorn Informational [Page 11] + +RFC 3079 MPPE Key Derivation March 2001 + + + 0x20, 0x74, 0x68, 0x65, 0x20, 0x73, 0x65, 0x6e, 0x64, 0x20, + 0x6b, 0x65, 0x79, 0x2e}; + + + GetMasterKey( + IN 16-octet PasswordHashHash, + IN 24-octet NTResponse, + OUT 16-octet MasterKey ) + { + 20-octet Digest + + ZeroMemory(Digest, sizeof(Digest)); + + /* + * SHSInit(), SHSUpdate() and SHSFinal() + * are an implementation of the Secure Hash Standard [7]. + */ + + SHSInit(Context); + SHSUpdate(Context, PasswordHashHash, 16); + SHSUpdate(Context, NTResponse, 24); + SHSUpdate(Context, Magic1, 27); + SHSFinal(Context, Digest); + + MoveMemory(MasterKey, Digest, 16); + } + + VOID + GetAsymetricStartKey( + IN 16-octet MasterKey, + OUT 8-to-16 octet SessionKey, + IN INTEGER SessionKeyLength, + IN BOOLEAN IsSend, + IN BOOLEAN IsServer ) + { + + 20-octet Digest; + + ZeroMemory(Digest, 20); + + if (IsSend) { + if (IsServer) { + s = Magic3 + } else { + s = Magic2 + } + } else { + if (IsServer) { + + + +Zorn Informational [Page 12] + +RFC 3079 MPPE Key Derivation March 2001 + + + s = Magic2 + } else { + s = Magic3 + } + } + + /* + * SHSInit(), SHSUpdate() and SHSFinal() + * are an implementation of the Secure Hash Standard [7]. + */ + + SHSInit(Context); + SHSUpdate(Context, MasterKey, 16); + SHSUpdate(Context, SHSpad1, 40); + SHSUpdate(Context, s, 84); + SHSUpdate(Context, SHSpad2, 40); + SHSFinal(Context, Digest); + + MoveMemory(SessionKey, Digest, SessionKeyLength); + } + +3.5. Sample Key Derivations + + The following sections illustrate 40-, 56- and 128-bit key + derivations. All intermediate values are in hexadecimal. + +3.5.1. Sample 40-bit Key Derivation + +Initial Values + UserName = "User" + = 55 73 65 72 + + Password = "clientPass" + = 63 00 6C 00 69 00 65 00 6E 00 + 74 00 50 00 61 00 73 00 73 00 + + AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C + 60 21 32 26 26 28 + PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E + + Challenge = D0 2E 43 86 BC E9 12 26 + + NT-Response = + 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 + 11 4A 3D 85 D6 DF + +Step 1: NtPasswordHash(Password, PasswordHash) + PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE + + + +Zorn Informational [Page 13] + +RFC 3079 MPPE Key Derivation March 2001 + + +Step 2: PasswordHashHash = MD4(PasswordHash) + PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F + +Step 3: Derive the master key (GetMasterKey()) + MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31 + +Step 4: Derive the master send session key (GetAsymmetricStartKey()) + SendStartKey40 = 8B 7C DC 14 9B 99 3A 1B + +Step 5: Derive the initial send session key (GetNewKeyFromSHA()) + SendSessionKey40 = D1 26 9E C4 9F A6 2E 3E + +Sample Encrypted Message + rc4(SendSessionKey40, "test message") = 92 91 37 91 7E 58 03 D6 + 68 D7 58 98 + +3.5.2. Sample 56-bit Key Derivation + +Initial Values + UserName = "User" + = 55 73 65 72 + + Password = "clientPass" + = 63 00 6C 00 69 00 65 00 6E 00 74 00 50 + 00 61 00 73 00 73 00 + + AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C + 60 21 32 26 26 28 + PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E + + Challenge = D0 2E 43 86 BC E9 12 26 + + NT-Response = + 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 + 11 4A 3D 85 D6 DF + +Step 1: NtPasswordHash(Password, PasswordHash) + PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE + +Step 2: PasswordHashHash = MD4(PasswordHash) + PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F + +Step 3: Derive the master key (GetMasterKey()) + MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31 + +Step 4: Derive the master send session key (GetAsymmetricStartKey()) + SendStartKey56 = 8B 7C DC 14 9B 99 3A 1B + + + + +Zorn Informational [Page 14] + +RFC 3079 MPPE Key Derivation March 2001 + + +Step 5: Derive the initial send session key (GetNewKeyFromSHA()) + SendSessionKey56 = D1 5C 00 C4 9F A6 2E 3E + +Sample Encrypted Message + rc4(SendSessionKey40, "test message") = 3F 10 68 33 FA 44 8D + A8 42 BC 57 58 + +3.5.3. Sample 128-bit Key Derivation + +Initial Values + UserName = "User" + = 55 73 65 72 + + Password = "clientPass" + = 63 00 6C 00 69 00 65 00 6E 00 + 74 00 50 00 61 00 73 00 73 00 + + AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C + 60 21 32 26 26 28 + + PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E + + Challenge = D0 2E 43 86 BC E9 12 26 + + NT-Response = + 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 + 11 4A 3D 85 D6 DF + +Step 1: NtPasswordHash(Password, PasswordHash) + PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE + +Step 2: PasswordHashHash = MD4(PasswordHash) + PasswordHashHash = 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F + +Step 2: Derive the master key (GetMasterKey()) + MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31 + +Step 3: Derive the send master session key (GetAsymmetricStartKey()) + + SendStartKey128 = 8B 7C DC 14 9B 99 3A 1B A1 18 CB 15 3F 56 DC CB + +Step 4: Derive the initial send session key (GetNewKeyFromSHA()) + SendSessionKey128 = 40 5C B2 24 7A 79 56 E6 E2 11 00 7A E2 7B 22 D4 + +Sample Encrypted Message + rc4(SendSessionKey128, "test message") = 81 84 83 17 DF 68 + 84 62 72 FB 5A BE + + + + +Zorn Informational [Page 15] + +RFC 3079 MPPE Key Derivation March 2001 + + +4. Deriving MPPE Session Keys from TLS Session Keys + + The Extensible Authentication Protocol (EAP) [10] is a PPP extension + that provides support for additional authentication methods within + PPP. Transport Level Security (TLS) [11] provides for mutual + authentication, integrity-protected ciphersuite negotiation and key + exchange between two endpoints. EAP-TLS [12] is an EAP + authentication type which allows the use of TLS within the PPP + authentication framework. The following sections describe the + methods used to derive initial session keys from TLS session keys. + 56-, 40- and 128-bit keys are derived using the same algorithm. The + only difference is in the length of the keys and their effective + strength: 56- and 40-bit keys are 8 octets in length, while 128-bit + keys are 16 octets long. Separate keys are derived for the send and + receive directions of the session. + +4.1. Generating 40-bit Session Keys + + When MPPE is used in conjunction with EAP-TLS authentication, the TLS + master secret is used as the master session key. + + The algorithm used to derive asymmetrical master session keys from + the TLS master secret is described in [12]. The master session keys + are never used to encrypt or decrypt data; they are only used in the + derivation of transient session keys. + + Implementation Note + + If the asymmetrical master keys are less than 8 octets in length, + they MUST be padded on the left with zeroes before being used to + derive the initial transient session keys. Conversely, if the + asymmetrical master keys are more than 8 octets in length, they + must be truncated to 8 octets before being used to derive the + initial transient session keys. + + The initial transient session keys are obtained by calling the + function GetNewKeyFromSHA() (described in [3]): + +GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey) +GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8, +ReceiveSessionKey) + + Next, the effective strength of both keys is reduced by setting the + first three octets to known constants: + + SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1 + SendSessionKey[1] = ReceiveSessionKey[1] = 0x26 + SendSessionKey[2] = ReceiveSessionKey[2] = 0x9E + + + +Zorn Informational [Page 16] + +RFC 3079 MPPE Key Derivation March 2001 + + + Finally, the RC4 tables are initialized using the new session keys: + + rc4_key(SendRC4key, 8, SendSessionKey) + rc4_key(ReceiveRC4key, 8, ReceiveSessionKey) + +4.2. Generating 56-bit Session Keys + + When MPPE is used in conjunction with EAP-TLS authentication, the TLS + master secret is used as the master session key. + + The algorithm used to derive asymmetrical master session keys from + the TLS master secret is described in [12]. The master session keys + are never used to encrypt or decrypt data; they are only used in the + derivation of transient session keys. + + Implementation Note + + If the asymmetrical master keys are less than 8 octets in length, + they MUST be padded on the left with zeroes before being used to + derive the initial transient session keys. Conversely, if the + asymmetrical master keys are more than 8 octets in length, they + must be truncated to 8 octets before being used to derive the + initial transient session keys. + + The initial transient session keys are obtained by calling the + function GetNewKeyFromSHA() (described in [3]): + +GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 8, SendSessionKey) +GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 8, +ReceiveSessionKey) + + Next, the effective strength of both keys is reduced by setting the + initial octet to a known constant: + + SendSessionKey[0] = ReceiveSessionKey[0] = 0xD1 + + Finally, the RC4 tables are initialized using the new session keys: + + rc4_key(SendRC4key, 8, SendSessionKey) + rc4_key(ReceiveRC4key, 8, ReceiveSessionKey) + +4.3. Generating 128-bit Session Keys + + When MPPE is used in conjunction with EAP-TLS authentication, the TLS + master secret is used as the master session key. + + + + + + +Zorn Informational [Page 17] + +RFC 3079 MPPE Key Derivation March 2001 + + + The algorithm used to derive asymmetrical master session keys from + the TLS master secret is described in [12]. Note that the send key + on one side is the receive key on the other. + + The master session keys are never used to encrypt or decrypt data; + they are only used in the derivation of transient session keys. + + Implementation Note + + If the asymmetrical master keys are less than 16 octets in length, + they MUST be padded on the left with zeroes before being used to + derive the initial transient session keys. Conversely, if the + asymmetrical master keys are more than 16 octets in length, they + must be truncated to 16 octets before being used to derive the + initial transient session keys. + + The initial transient session keys are obtained by calling the + function GetNewKeyFromSHA() (described in [3]): + +GetNewKeyFromSHA(MasterSendKey, MasterSendKey, 16, SendSessionKey) +GetNewKeyFromSHA(MasterReceiveKey, MasterReceiveKey, 16, +ReceiveSessionKey) + + Finally, the RC4 tables are initialized using the new session keys: + + rc4_key(SendRC4key, 16, SendSessionKey) + rc4_key(ReceiveRC4key, 16, ReceiveSessionKey) + +5. Security Considerations + +5.1. MS-CHAP Credentials + + Because of the way in which 40-bit keys are derived from MS-CHAP-1 + credentials, the initial 40-bit session key will be identical in all + sessions established under the same peer credentials. For this + reason, and because RC4 with a 40-bit key length is believed to be a + relatively weak cipher, peers SHOULD NOT use 40-bit keys derived from + the LAN Manager password hash (as described above) if it can be + avoided. + + Since the MPPE session keys are derived from user passwords (in the + MS- CHAP-1 and MS-CHAP-2 cases), care should be taken to ensure the + selection of strong passwords and passwords should be changed + frequently. + + + + + + + +Zorn Informational [Page 18] + +RFC 3079 MPPE Key Derivation March 2001 + + +5.2. EAP-TLS Credentials + + The strength of the session keys is dependent upon the security of + the TLS protocol. + + The EAP server may be on a separate machine from the PPP + authenticator; if this is the case, adequate care must be taken in + the transmission of the EAP-TLS master keys to the authenticator. + +6. References + + [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC + 1661, July 1994. + + [2] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, + October 1998. + + [3] Pall, G. and G. Zorn, "Microsoft Point-to-Point Encryption + (MPPE) RFC 3078, March 2001. + + [4] RC4 is a proprietary encryption algorithm available under + license from RSA Data Security Inc. For licensing information, + contact: + RSA Data Security, Inc. + 100 Marine Parkway + Redwood City, CA 94065-1031 + + [5] Pall, G., "Microsoft Point-to-Point Compression (MPPC) + Protocol", RFC 2118, March 1997. + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [7] "Secure Hash Standard", Federal Information Processing Standards + Publication 180-1, National Institute of Standards and + Technology, April 1995. + + [8] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, + January 2000. + + [9] Simpson, W., "PPP Challenge Handshake Authentication Protocol + (CHAP)", RFC 1994, August 1996. + + [10] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication + Protocol (EAP)", RFC 2284, March 1998. + + + + + + +Zorn Informational [Page 19] + +RFC 3079 MPPE Key Derivation March 2001 + + + [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC + 2246, January 1999. + + [12] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", + RFC 2716, October 1999. + +7. Acknowledgements + + Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all + of Microsoft Corporation, significantly contributed to the design and + development of MPPE. + + Additional thanks to Robert Friend, Joe Davies, Jody Terrill, Archie + Cobbs, Mark Deuser, Vijay Baliga, Brad Robel-Forrest and Jeff Haag + for useful feedback. + + The technical portions of this memo were completed while the author + was employed by Microsoft Corporation. + +8. Author's Address + + Questions about this memo can also be directed to: + + Glen Zorn + cisco Systems + 500 108th Avenue N.E. + Suite 500 + Bellevue, Washington 98004 + USA + + Phone: +1 425 438 8218 + FAX: +1 425 438 1848 + EMail: gwz@cisco.com + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 20] + +RFC 3079 MPPE Key Derivation March 2001 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 21] + diff --git a/rfc/rfc3544.txt b/rfc/rfc3544.txt new file mode 100644 index 00000000..b4d2ac5e --- /dev/null +++ b/rfc/rfc3544.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group T. Koren +Request for Comments: 3544 Cisco Systems +Obsoletes: 2509 S. Casner +Category: Standards Track Packet Design + C. Bormann + Universitaet Bremen TZI + July 2003 + + + IP Header Compression over PPP + +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. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document describes an option for negotiating the use of header + compression on IP datagrams transmitted over the Point-to-Point + Protocol (RFC 1661). It defines extensions to the PPP Control + Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression + may be applied to IPv4 and IPv6 datagrams in combination with TCP, + UDP and RTP transport protocols as specified in RFC 2507, RFC 2508 + and RFC 3545. + +1. Introduction + + The IP Header Compression (IPHC) defined in [RFC2507] may be used for + compression of both IPv4 and IPv6 datagrams or packets encapsulated + with multiple IP headers. IPHC is also capable of compressing both + TCP and UDP transport protocol headers. The IP/UDP/RTP header + compression defined in [RFC2508] and [RFC3545] fits within the + framework defined by IPHC so that it may also be applied to both IPv4 + and IPv6 packets. + + + + + + + + + +Koren, et al. Standards Track [Page 1] + +RFC 3544 IP Header Compression over PPP July 2003 + + + In order to establish compression of IP datagrams sent over a PPP + link each end of the link must agree on a set of configuration + parameters for the compression. The process of negotiating link + parameters for network layer protocols is handled in PPP by a family + of network control protocols (NCPs). Since there are separate NCPs + for IPv4 and IPv6, this document defines configuration options to be + used in both NCPs to negotiate parameters for the compression scheme. + + This document obsoletes RFC 2509, adding two new suboptions to the IP + header compression configuration option. One suboption negotiates + usage of Enhanced RTP-Compression (specified in [RFC3545]), and the + other suboption negotiates header compression for only TCP or only + non-TCP packets. + + IPHC relies on the link layer's ability to indicate the types of + datagrams carried in the link layer frames. In this document nine + new types for the PPP Data Link Layer Protocol Field are defined + along with their meaning. + + In general, header compression schemes that use delta encoding of + compressed packets require that the lower layer does not reorder + packets between compressor and decompressor. IPHC uses delta + encoding of compressed packets for TCP and RTP. The IPHC + specification [RFC2507] includes methods that allow link layers that + may reorder packets to be used with IPHC. Since PPP does not reorder + packets these mechanisms are disabled by default. When using + reordering mechanisms such as multiclass multilink PPP [RFC2686], + care must be taken so that packets that share the same compression + context are not reordered. + +2. Configuration Option + + This document specifies a new compression protocol value for the IPCP + IP-Compression-Protocol option as specified in [RFC1332]. The new + value and the associated option format are described in section 2.1. + + The option format is structured to allow future extensions to the + IPHC scheme. + + NOTE: The specification of link and network layer parameter + negotiation for PPP [RFC1661], [RFC1331], [RFC1332] does not + prohibit multiple instances of one configuration option but states + that the specification of a configuration option must explicitly + allow multiple instances. [RFC3241] updates RFC 1332 by + explicitly allowing the sending of multiple instances of the IP- + Compression-Protocol configuration option, each with a different + value for IP-Compression-Protocol. Each type of compression + protocol may independently establish its own parameters. + + + +Koren, et al. Standards Track [Page 2] + +RFC 3544 IP Header Compression over PPP July 2003 + + + NOTE: [RFC1332] is not explicit about whether the option + negotiates the capabilities of the receiver or of the sender. In + keeping with current practice, we assume that the option describes + the capabilities of the decompressor (receiving side) of the peer + that sends the Config-Req. + +2.1. Configuration Option Format + + Both the network control protocol for IPv4, IPCP [RFC1332] and the + IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP Header + Compression parameters for their respective protocols. The format of + the configuration option is the same for both IPCP and IPV6CP. + + Description + + This NCP configuration option is used to negotiate parameters for + IP Header Compression. Successful negotiation of parameters + enables the use of Protocol Identifiers FULL_HEADER, + COMPRESSED_TCP, COMPRESSED_TCP_NODELTA, COMPRESSED_NON_TCP and + CONTEXT_STATE as specified in [RFC2507]. The option format is + summarized below. The fields are transmitted from 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 | IP-Compression-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TCP_SPACE | NON_TCP_SPACE | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | F_MAX_PERIOD | F_MAX_TIME | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAX_HEADER | suboptions... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + 2 + + Length + >= 14 + + The length may be increased if the presence of additional + parameters is indicated by additional suboptions. + + IP-Compression-Protocol + 0061 (hex) + + + + + + +Koren, et al. Standards Track [Page 3] + +RFC 3544 IP Header Compression over PPP July 2003 + + + TCP_SPACE + The TCP_SPACE field is two octets and indicates the maximum value + of a context identifier in the space of context identifiers + allocated for TCP. + + Suggested value: 15 + + TCP_SPACE must be at least 0 and at most 255 (the value 0 implies + having one context). + + NON_TCP_SPACE + The NON_TCP_SPACE field is two octets and indicates the maximum + value of a context identifier in the space of context identifiers + allocated for non-TCP. These context identifiers are carried in + COMPRESSED_NON_TCP, COMPRESSED_UDP and COMPRESSED_RTP packet + headers. + + Suggested value: 15 + + NON_TCP_SPACE must be at least 0 and at most 65535 (the value 0 + implies having one context). + + F_MAX_PERIOD + Maximum interval between full headers. No more than F_MAX_PERIOD + COMPRESSED_NON_TCP headers may be sent between FULL_HEADER + headers. + + Suggested value: 256 + + A value of zero implies infinity, i.e. there is no limit to the + number of consecutive COMPRESSED_NON_TCP headers. + + F_MAX_TIME + Maximum time interval between full headers. COMPRESSED_NON_TCP + headers may not be sent more than F_MAX_TIME seconds after sending + the last FULL_HEADER header. + + Suggested value: 5 seconds + + A value of zero implies infinity. + + MAX_HEADER + The largest header size in octets that may be compressed. + + Suggested value: 168 octets + + + + + + +Koren, et al. Standards Track [Page 4] + +RFC 3544 IP Header Compression over PPP July 2003 + + + The value of MAX_HEADER should be large enough so that at least + the outer network layer header can be compressed. To increase + compression efficiency MAX_HEADER should be set to a value large + enough to cover common combinations of network and transport layer + headers. + + suboptions + The suboptions field consists of zero or more suboptions. Each + suboption consists of a type field, a length field and zero or + more parameter octets, as defined by the suboption type. The + value of the length field indicates the length of the suboption in + its entirety, including the lengths of the type and length fields. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Parameters... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.2. RTP-Compression Suboption + + The RTP-Compression suboption is included in the NCP IP-Compression- + Protocol option for IPHC if IP/UDP/RTP compression is to be enabled. + + Inclusion of the RTP-Compression suboption enables use of additional + Protocol Identifiers COMPRESSED_RTP and COMPRESSED_UDP along with + additional forms of CONTEXT_STATE as specified in [RFC2508]. + + Description + + Enable use of Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP + and CONTEXT_STATE as specified in [RFC2508]. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + 1 + + Length + 2 + + + + + + + +Koren, et al. Standards Track [Page 5] + +RFC 3544 IP Header Compression over PPP July 2003 + + +2.3. Enhanced RTP-Compression Suboption + + To use the enhanced RTP header compression defined in [RFC3545], a + new sub-option 2 is added. Sub-option 2 is negotiated instead of, + not in addition to, sub-option 1. + + Description + + Enable use of Protocol Identifiers COMPRESSED_RTP and + CONTEXT_STATE as specified in [RFC2508]. In addition, enable use + of [RFC3545] compliant compression including the use of Protocol + Identifier COMPRESSED_UDP with additional flags and use of the C + flag with the FULL_HEADER Protocol Identifier to indicate use of + HDRCKSUM with COMPRESSED_RTP and COMPRESSED_UDP packets. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + 2 + + Length + 2 + +2.4. Negotiating header compression for only TCP or only non-TCP + packets + + In RFC 2509 it was not possible to negotiate only TCP header + compression or only non-TCP header compression because a value of 0 + in the TCP_SPACE or the NON_TCP_SPACE fields actually means that 1 + context is negotiated. + + A new suboption 3 is added to allow specifying that the number of + contexts for TCP_SPACE or NON_TCP_SPACE is zero, disabling use of the + corresponding compression. + + + + + + + + + + + + + +Koren, et al. Standards Track [Page 6] + +RFC 3544 IP Header Compression over PPP July 2003 + + + Description + + Enable header compression for only TCP or only non-TCP packets. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Parameter | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + 3 + + Length + 3 + + Parameter + + The parameter is 1 byte with one of the following values: + + 1 = the number of contexts for TCP_SPACE is 0 + 2 = the number of contexts for NON_TCP_SPACE is 0 + + This suboption overrides the values that were previously assigned to + TCP_SPACE and NON_TCP_SPACE in the IP Header Compression option. + + If suboption 3 is included multiple times with parameter 1 and 2, + compression is disabled for all packets. + +3. Multiple Network Control Protocols + + The IPHC protocol is able to compress both IPv6 and IPv4 datagrams. + Both IPCP and IPV6CP are able to negotiate option parameter values + for IPHC. These values apply to the compression of packets where the + outer header is an IPv4 header and an IPv6 header, respectively. + +3.1. Sharing Context Identifier Space + + For the compression and decompression of IPv4 and IPv6 datagram + headers the context identifier space is shared. While the parameter + values are independently negotiated, sharing the context identifier + spaces becomes more complex when the parameter values differ. Since + the compressed packets share context identifier space, the + compression engine must allocate context identifiers out of a common + pool; for compressed packets, the decompressor has to examine the + context state to determine what parameters to use for decompression. + + + + + +Koren, et al. Standards Track [Page 7] + +RFC 3544 IP Header Compression over PPP July 2003 + + + Context identifier spaces are not shared between TCP and non- + TCP/UDP/RTP. Doing so would require additional mechanisms to ensure + that no error can occur when switching from using a context + identifier for TCP to non-TCP. + +4. Demultiplexing of Datagrams + + The IPHC specification [RFC2507] defines four header formats for + different types of compressed headers. They are compressed TCP, + compressed TCP with no delta encoding, compressed non-TCP with 8 bit + CID and compressed non-TCP with 16 bit CID. The two non-TCP formats + may be distinguished by their contents so both may use the same + link-level identifier. A fifth header format, the full header is + distinct from a regular header in that it carries additional + information to establish shared context between the compressor and + decompressor. + + The specification of IP/UDP/RTP Header Compression [RFC2508] defines + four additional formats of compressed headers. They are for + compressed UDP and compressed RTP (on top of UDP), both with either + 8- or 16-bit CIDs. In addition, there is an explicit error message + from the decompressor to the compressor. + + The link layer must be able to indicate these header formats with + distinct values. Nine PPP Data Link Layer Protocol Field values are + specified below. + + FULL_HEADER + The frame contains a full header as specified in [RFC2508] Section + 3.3.1. This is the same as the FULL_HEADER specified in [RFC2507] + Section 5.3. + Value: 0061 (hex) + + COMPRESSED_TCP + The frame contains a datagram with a compressed header with the + format as specified in [RFC2507] Section 6a. + Value: 0063 (hex) + + COMPRESSED_TCP_NODELTA + The frame contains a datagram with a compressed header with the + format as specified in [RFC2507] Section 6b. + Value: 2063 (hex) + + COMPRESSED_NON_TCP + The frame contains a datagram with a compressed header with the + format as specified in either Section 6c or Section 6d of + [RFC2507]. + Value: 0065 (hex) + + + +Koren, et al. Standards Track [Page 8] + +RFC 3544 IP Header Compression over PPP July 2003 + + + COMPRESSED_RTP_8 + The frame contains a datagram with a compressed header with the + format as specified in [RFC2508] Section 3.3.2, using 8-bit CIDs. + Value: 0069 (hex) + + COMPRESSED_RTP_16 + The frame contains a datagram with a compressed header with the + format as specified in [RFC2508] Section 3.3.2, using 16-bit CIDs. + Value: 2069 (hex) + + COMPRESSED_UDP_8 + The frame contains a datagram with a compressed header with the + format as specified in [RFC2508] Section 3.3.3 or as specified in + [RFC3545] Section 2.1, using 8-bit CIDs. + Value: 0067 (hex) + + COMPRESSED_UDP_16 + The frame contains a datagram with a compressed header with the + format as specified in [RFC2508] Section 3.3.3 or as specified in + [RFC3545] Section 2.1, using 16-bit CIDs. + Value: 2067 (hex) + + CONTEXT_STATE + The frame is a link-level message sent from the decompressor to + the compressor as specified in [RFC2508] Section 3.3.5. + Value: 2065 (hex) + +5. Changes from RFC 2509 + + Two new suboptions are specified. See Sections 2.3 and 2.4. + +6. References + +6.1. Normative References + + [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for low-speed + serial links", RFC 1144, February 1990. + + [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol + (IPCP)", RFC 1332, May 1992. + + [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC + 2472, December 1998. + + [RFC2507] Degermark, M., Nordgren, B. and S. Pink, "Header + Compression for IP", RFC 2507, February 1999. + + + + + +Koren, et al. Standards Track [Page 9] + +RFC 3544 IP Header Compression over PPP July 2003 + + + [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP + Headers for Low-Speed Serial Links", RFC 2508, February + 1999. + + [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", + RFC 3241, April 2002. + + [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B. and + P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with + High Delay, Packet Loss and Reordering", RFC 3545, July + 2003. + +6.2. Informative References + + [RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link + PPP", RFC 2686, September 1999. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", RFC 3550, July 2003. + +7. IANA Considerations + + This document does not require any additional allocations from + existing namespaces in the IANA Point-to-Point Protocol Field + Assignments registry. However, there are three namespaces that were + defined by RFC 1332, RFC 2472, and RFC 2509 but not created in the + registry. Those three namespaces, described below, have been added + to the PPP registry. This document specifies two additional + allocations in the third one. + + Section 3.2 of RFC 1332 specifies an IP-Compression-Protocol + Configuration Option for the PPP IP Control Protocol and defines one + value for the IP-Compression-Protocol type field in that option. An + IANA registry has been created to allocate additional values for that + type field. As stated in RFC 1332, the values for the IP- + Compression-Protocol type field are always the same as the (primary) + PPP DLL Protocol Number assigned to packets of the particular + compression protocol. Assignment of additional IP-Compression- + Protocol type values is through the IETF consensus procedure as + specified in [RFC2434]. + + + +Koren, et al. Standards Track [Page 10] + +RFC 3544 IP Header Compression over PPP July 2003 + + + Section 4.2 of RFC 2472 specifies an IPv6-Compression-Protocol + Configuration Option for the PPP IPv6 Control Protocol and defines + one value for the IPv6-Compression-Protocol type field in that + option. An IANA registry has been created to allocate additional + values for that type field. The IPv6-Compression-Protocol + Configuration Option has the same structure as the IP-Compression- + Protocol Configuration Option defined in RFC 1332, but the set of + values defined for the type field may be different. As stated in RFC + 2472, the values for the IPv6-Compression-Protocol type field are + always the same as the (primary) PPP DLL Protocol Number assigned to + packets of the particular compression protocol. Assignment of + additional IPv6-Compression-Protocol type values is through the IETF + consensus procedure as specified in [RFC2434]. + + Section 2.1 of RFC 2509 specifies an additional type value to be + registered for both the IP-Compression-Protocol Configuration Option + and the IPv6-Compression-Protocol Configuration Option to indicate + use of the "IP Header Compression" protocol. The specification of + that type value is repeated in Section 2.1 of this document which + obsoletes RFC 2509. In conjunction with the additional type value, + the format for the variable-length option is specified. The format + includes a suboption field that may contain one or more suboptions. + Each suboption begins with a suboption type value. An IANA registry + has been created for the suboption type values; and is titled, "IP + Header Compression Configuration Option Suboption Types". + + Section 2.2 of RFC 2509 (and this document) defines one suboption + type. Sections 2.3 and 2.4 of this document define two additional + suboption types. It is expected that the number of additional + suboptions that will need to be defined is small. Therefore, anyone + wishing to define new suboptions is required to produce a revision of + this document to be vetted through the normal Internet Standards + process, as specified in [RFC2434]. + + RFC 2509 also defines nine PPP Data Link Layer Protocol Field values + which are already listed in the IANA registry of Point-to-Point + Protocol Field Assignments. Section 4 of this document repeats the + specification of those values without change. + +8. Security Considerations + + Negotiation of the option defined here imposes no additional security + considerations beyond those that otherwise apply to PPP [RFC1661]. + + The use of header compression can, in rare cases, cause the + misdelivery of packets. If necessary, confidentiality of packet + contents should be assured by encryption. + + + + +Koren, et al. Standards Track [Page 11] + +RFC 3544 IP Header Compression over PPP July 2003 + + + Encryption applied at the IP layer (e.g., using IPSEC mechanisms) + precludes header compression of the encrypted headers, though + compression of the outer IP header and authentication/security + headers is still possible as described in [RFC2507]. For RTP + packets, full header compression is possible if the RTP payload is + encrypted by itself without encrypting the UDP or RTP headers, as + described in [RFC3550]. This method is appropriate when the UDP and + RTP header information need not be kept confidential. + +9. Intellectual Property Rights Notice + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + + + + + + + + + +Koren, et al. Standards Track [Page 12] + +RFC 3544 IP Header Compression over PPP July 2003 + + +10. Acknowledgements + + Mathias Engan was the primary author of RFC 2509, of which this + document is a revision. + +11. Authors' Addresses + + Tmima Koren + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134-1706 + United States + + EMail: tmima@cisco.com + + + Stephen L. Casner + Packet Design + 3400 Hillview Avenue, Building 3 + Palo Alto, CA 94304 + United States + + EMail: casner@packetdesign.com + + + Carsten Bormann + Universitaet Bremen FB3 TZI + Postfach 330440 + D-28334 Bremen, GERMANY + + Phone: +49.421.218-7024 + Fax: +49.421.218-7000 + EMail: cabo@tzi.org + + + + + + + + + + + + + + + + + + +Koren, et al. Standards Track [Page 13] + +RFC 3544 IP Header Compression over PPP July 2003 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Koren, et al. Standards Track [Page 14] + diff --git a/rfc/rfc3576.txt b/rfc/rfc3576.txt new file mode 100644 index 00000000..89fd9eb9 --- /dev/null +++ b/rfc/rfc3576.txt @@ -0,0 +1,1683 @@ + + + + + + +Network Working Group M. Chiba +Request for Comments: 3576 G. Dommety +Category: Informational M. Eklund + Cisco Systems, Inc. + D. Mitton + Circular Logic, UnLtd. + B. Aboba + Microsoft Corporation + July 2003 + + + Dynamic Authorization Extensions to Remote + Authentication Dial In User Service (RADIUS) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document describes a currently deployed extension to the Remote + Authentication Dial In User Service (RADIUS) protocol, allowing + dynamic changes to a user session, as implemented by network access + server products. This includes support for disconnecting users and + changing authorizations applicable to a user session. + + + + + + + + + + + + + + + + + + + + +Chiba, et al. Informational [Page 1] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Requirements Language . . . . . . . . . . . . . . . . . 5 + 1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Disconnect Messages (DM) . . . . . . . . . . . . . . . . 5 + 2.2. Change-of-Authorization Messages (CoA) . . . . . . . . . 6 + 2.3. Packet Format. . . . . . . . . . . . . . . . . . . . . . 7 + 3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.1. Error-Cause. . . . . . . . . . . . . . . . . . . . . . . 13 + 3.2. Table of Attributes. . . . . . . . . . . . . . . . . . . 16 + 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20 + 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 21 + 5.1. Authorization Issues . . . . . . . . . . . . . . . . . . 21 + 5.2. Impersonation. . . . . . . . . . . . . . . . . . . . . . 22 + 5.3. IPsec Usage Guidelines . . . . . . . . . . . . . . . . . 22 + 5.4. Replay Protection. . . . . . . . . . . . . . . . . . . . 25 + 6. Example Traces . . . . . . . . . . . . . . . . . . . . . . . . 26 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 7.2. Informative References . . . . . . . . . . . . . . . . . 27 + 8. Intellectual Property Statement. . . . . . . . . . . . . . . . 28 + 9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 28 + 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 + 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30 + + + + + + + + + + + + + + + + + + + + + + + + +Chiba, et al. Informational [Page 2] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +1. Introduction + + The RADIUS protocol, defined in [RFC2865], does not support + unsolicited messages sent from the RADIUS server to the Network + Access Server (NAS). + + However, there are many instances in which it is desirable for + changes to be made to session characteristics, without requiring the + NAS to initiate the exchange. For example, it may be desirable for + administrators to be able to terminate a user session in progress. + Alternatively, if the user changes authorization level, this may + require that authorization attributes be added/deleted from a user + session. + + To overcome these limitations, several vendors have implemented + additional RADIUS commands in order to be able to support unsolicited + messages sent from the RADIUS server to the NAS. These extended + commands provide support for Disconnect and Change-of-Authorization + (CoA) messages. Disconnect messages cause a user session to be + terminated immediately, whereas CoA messages modify session + authorization attributes such as data filters. + +1.1. Applicability + + This protocol is being recommended for publication as an + Informational RFC rather than as a standards-track RFC because of + problems that cannot be fixed without creating incompatibilities with + deployed implementations. This includes security vulnerabilities, as + well as semantic ambiguities resulting from the design of the + Change-of-Authorization (CoA) commands. While fixes are recommended, + they cannot be made mandatory since this would be incompatible with + existing implementations. + + Existing implementations of this protocol do not support + authorization checks, so that an ISP sharing a NAS with another ISP + could disconnect or change authorizations for another ISP's users. + In order to remedy this problem, a "Reverse Path Forwarding" check is + recommended. See Section 5.1. for details. + + Existing implementations utilize per-packet authentication and + integrity protection algorithms with known weaknesses [MD5Attack]. + To provide stronger per-packet authentication and integrity + protection, the use of IPsec is recommended. See Section 5.3. for + details. + + + + + + + +Chiba, et al. Informational [Page 3] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Existing implementations lack replay protection. In order to support + replay detection, it is recommended that the Event-Timestamp + Attribute be added to all messages in situations where IPsec replay + protection is not employed. Implementations should be configurable + to silently discard messages lacking the Event-Timestamp Attribute. + See Section 5.4. for details. + + The approach taken with CoA commands in existing implementations + results in a semantic ambiguity. Existing implementations of the + CoA-Request identify the affected session, as well as supply the + authorization changes. Since RADIUS Attributes included within + existing implementations of the CoA-Request can be used for session + identification or authorization change, it may not be clear which + function a given attribute is serving. + + The problem does not exist within [Diameter], in which authorization + change is requested by a command using Attribute Value Pairs (AVPs) + solely for identification, resulting in initiation of a standard + Request/Response sequence where authorization changes are supplied. + As a result, in no command can Diameter AVPs have multiple potential + meanings. + + Due to differences in handling change-of-authorization requests in + RADIUS and Diameter, it may be difficult or impossible for a + Diameter/RADIUS gateway to successfully translate existing + implementations of this specification to equivalent messages in + Diameter. For example, a Diameter command changing any attribute + used for identification within existing CoA-Request implementations + cannot be translated, since such an authorization change is + impossible to carry out in existing implementations. Similarly, + translation between existing implementations of Disconnect-Request or + CoA-Request messages and Diameter is tricky because a Disconnect- + Request or CoA-Request message will need to be translated to multiple + Diameter commands. + + To simplify translation between RADIUS and Diameter, a Service-Type + Attribute with value "Authorize Only" can (optionally) be included + within a Disconnect-Request or CoA-Request. Such a Request contains + only identification attributes. A NAS supporting the "Authorize + Only" Service-Type within a Disconnect-Request or CoA-Request + responds with a NAK containing a Service-Type Attribute with value + "Authorize Only" and an Error-Cause Attribute with value "Request + Initiated". The NAS will then send an Access-Request containing a + Service-Type Attribute with a value of "Authorize Only". This usage + sequence is akin to what occurs in Diameter and so is more easily + translated by a Diameter/RADIUS gateway. + + + + + +Chiba, et al. Informational [Page 4] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +1.2. Requirements Language + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. The key + words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document + are to be interpreted as described in [RFC2119]. + +1.3. Terminology + + This document frequently uses the following terms: + + Network Access Server (NAS): The device providing access to the + network. + + service: The NAS provides a service to the user, + such as IEEE 802 or PPP. + + session: Each service provided by the NAS to a + user constitutes a session, with the + beginning of the session defined as the + point where service is first provided + and the end of the session defined as + the point where service is ended. A + user may have multiple sessions in + parallel or series if the NAS supports + that. + + silently discard: This means the implementation discards + the packet without further processing. + The implementation SHOULD provide the + capability of logging the error, + including the contents of the silently + discarded packet, and SHOULD record the + event in a statistics counter. + +2. Overview + + This section describes the most commonly implemented features of + Disconnect and Change-of-Authorization messages. + +2.1. Disconnect Messages (DM) + + A Disconnect-Request packet is sent by the RADIUS server in order to + terminate a user session on a NAS and discard all associated session + context. The Disconnect-Request packet is sent to UDP port 3799, and + identifies the NAS as well as the user session to be terminated by + inclusion of the identification attributes described in Section 3. + + + +Chiba, et al. Informational [Page 5] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + +----------+ Disconnect-Request +----------+ + | | <-------------------- | | + | NAS | | RADIUS | + | | Disconnect-Response | Server | + | | ---------------------> | | + +----------+ +----------+ + + The NAS responds to a Disconnect-Request packet sent by a RADIUS + server with a Disconnect-ACK if all associated session context is + discarded and the user session is no longer connected, or a + Disconnect-NAK, if the NAS was unable to disconnect the session and + discard all associated session context. A NAS MUST respond to a + Disconnect-Request including a Service-Type Attribute with value + "Authorize Only" with a Disconnect-NAK; a Disconnect-ACK MUST NOT be + sent. A NAS MUST respond to a Disconnect-Request including a + Service-Type Attribute with an unsupported value with a Disconnect- + NAK; an Error-Cause Attribute with value "Unsupported Service" MAY be + included. A Disconnect-ACK MAY contain the Attribute + Acct-Terminate-Cause (49) [RFC2866] with the value set to 6 for + Admin-Reset. + +2.2. Change-of-Authorization Messages (CoA) + + CoA-Request packets contain information for dynamically changing + session authorizations. This is typically used to change data + filters. The data filters can be of either the ingress or egress + kind, and are sent in addition to the identification attributes as + described in section 3. The port used, and packet format (described + in Section 2.3.), are the same as that for Disconnect-Request + Messages. + + The following attribute MAY be sent in a CoA-Request: + + Filter-ID (11) - Indicates the name of a data filter list to be + applied for the session that the identification + attributes map to. + + +----------+ CoA-Request +----------+ + | | <-------------------- | | + | NAS | | RADIUS | + | | CoA-Response | Server | + | | ---------------------> | | + +----------+ +----------+ + + The NAS responds to a CoA-Request sent by a RADIUS server with a + CoA-ACK if the NAS is able to successfully change the authorizations + for the user session, or a CoA-NAK if the Request is unsuccessful. A + NAS MUST respond to a CoA-Request including a Service-Type Attribute + + + +Chiba, et al. Informational [Page 6] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST NOT be + sent. A NAS MUST respond to a CoA-Request including a Service-Type + Attribute with an unsupported value with a CoA-NAK; an Error-Cause + Attribute with value "Unsupported Service" MAY be included. + +2.3. Packet Format + + For either Disconnect-Request or CoA-Request messages UDP port 3799 + is used as the destination port. For responses, the source and + destination ports are reversed. Exactly one RADIUS packet is + encapsulated in the UDP Data field. + + A summary of the data format is shown below. The fields are + transmitted from left to right. + + The packet format consists of the fields: Code, Identifier, Length, + Authenticator, and Attributes in Type:Length:Value (TLV) format. All + fields hold the same meaning as those described in RADIUS [RFC2865]. + The Authenticator field MUST be calculated in the same way as is + specified for an Accounting-Request in [RFC2866]. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Authenticator | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Attributes ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + The Code field is one octet, and identifies the type of RADIUS + packet. Packets received with an invalid Code field MUST be + silently discarded. RADIUS codes (decimal) for this extension are + assigned as follows: + + 40 - Disconnect-Request [RFC2882] + 41 - Disconnect-ACK [RFC2882] + 42 - Disconnect-NAK [RFC2882] + 43 - CoA-Request [RFC2882] + 44 - CoA-ACK [RFC2882] + 45 - CoA-NAK [RFC2882] + + + + +Chiba, et al. Informational [Page 7] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Identifier + + The Identifier field is one octet, and aids in matching requests + and replies. The RADIUS client can detect a duplicate request if + it has the same server source IP address and source UDP port and + Identifier within a short span of time. + + Unlike RADIUS as defined in [RFC2865], the responsibility for + retransmission of Disconnect-Request and CoA-Request messages lies + with the RADIUS server. If after sending these messages, the + RADIUS server does not receive a response, it will retransmit. + + The Identifier field MUST be changed whenever the content of the + Attributes field changes, or whenever a valid reply has been + received for a previous request. For retransmissions where the + contents are identical, the Identifier MUST remain unchanged. + + If the RADIUS server is retransmitting a Disconnect-Request or + CoA-Request to the same client as before, and the Attributes have + not changed, the same Request Authenticator, Identifier and source + port MUST be used. If any Attributes have changed, a new + Authenticator and Identifier MUST be used. + + Note that if the Event-Timestamp Attribute is included, it will be + updated when the packet is retransmitted, changing the content of + the Attributes field and requiring a new Identifier and Request + Authenticator. + + If the Request to a primary proxy fails, a secondary proxy must be + queried, if available. Issues relating to failover algorithms are + described in [AAATransport]. Since this represents a new request, + a new Request Authenticator and Identifier MUST be used. However, + where the RADIUS server is sending directly to the client, + failover typically does not make sense, since Disconnect or CoA + messages need to be delivered to the NAS where the session + resides. + + Length + + The Length field is two octets. It indicates the length of the + packet including the Code, Identifier, Length, Authenticator and + Attribute fields. Octets outside the range of the Length field + MUST be treated as padding and ignored on reception. If the + packet is shorter than the Length field indicates, it MUST be + silently discarded. The minimum length is 20 and the maximum + length is 4096. + + + + + +Chiba, et al. Informational [Page 8] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Authenticator + + The Authenticator field is sixteen (16) octets. The most + significant octet is transmitted first. This value is used to + authenticate the messages between the RADIUS server and client. + + Request Authenticator + + In Request packets, the Authenticator value is a 16 octet MD5 + [RFC1321] checksum, called the Request Authenticator. The Request + Authenticator is calculated the same way as for an Accounting- + Request, specified in [RFC2866]. + + Note that the Request Authenticator of a Disconnect or CoA-Request + cannot be done the same way as the Request Authenticator of a + RADIUS Access-Request, because there is no User-Password Attribute + in a Disconnect-Request or CoA-Request. + + Response Authenticator + + The Authenticator field in a Response packet (e.g. Disconnect-ACK, + Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the Response + Authenticator, and contains a one-way MD5 hash calculated over a + stream of octets consisting of the Code, Identifier, Length, the + Request Authenticator field from the packet being replied to, and + the response Attributes if any, followed by the shared secret. + The resulting 16 octet MD5 hash value is stored in the + Authenticator field of the Response packet. + + Administrative note: As noted in [RFC2865] Section 3, the secret + (password shared between the client and the RADIUS server) SHOULD be + at least as large and unguessable as a well-chosen password. RADIUS + clients MUST use the source IP address of the RADIUS UDP packet to + decide which shared secret to use, so that requests can be proxied. + + Attributes + + In Disconnect and CoA-Request messages, all Attributes are treated + as mandatory. A NAS MUST respond to a CoA-Request containing one + or more unsupported Attributes or Attribute values with a CoA-NAK; + a Disconnect-Request containing one or more unsupported Attributes + or Attribute values MUST be answered with a Disconnect-NAK. State + changes resulting from a CoA-Request MUST be atomic: if the + Request is successful, a CoA-ACK is sent, and all requested + authorization changes MUST be made. If the CoA-Request is + unsuccessful, a CoA-NAK MUST be sent, and the requested + + + + + +Chiba, et al. Informational [Page 9] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + authorization changes MUST NOT be made. Similarly, a state change + MUST NOT occur as a result of an unsuccessful Disconnect-Request; + here a Disconnect-NAK MUST be sent. + + Since within this specification attributes may be used for + identification, authorization or other purposes, even if a NAS + implements an attribute for use with RADIUS authentication and + accounting, it may not support inclusion of that attribute within + Disconnect-Request or CoA-Request messages, given the difference + in attribute semantics. This is true even for attributes + specified within [RFC2865], [RFC2868], [RFC2869] or [RFC3162] as + allowable within Access-Accept messages. + + As a result, attributes beyond those specified in Section 3.2. + SHOULD NOT be included within Disconnect or CoA messages since + this could produce unpredictable results. + + When using a forwarding proxy, the proxy must be able to alter the + packet as it passes through in each direction. When the proxy + forwards a Disconnect or CoA-Request, it MAY add a Proxy-State + Attribute, and when the proxy forwards a response, it MUST remove + its Proxy-State Attribute if it added one. Proxy-State is always + added or removed after any other Proxy-States, but no other + assumptions regarding its location within the list of Attributes + can be made. Since Disconnect and CoA responses are authenticated + on the entire packet contents, the stripping of the Proxy-State + Attribute invalidates the integrity check - so the proxy needs to + recompute it. A forwarding proxy MUST NOT modify existing Proxy- + State, State, or Class Attributes present in the packet. + + If there are any Proxy-State Attributes in a Disconnect-Request or + CoA-Request received from the server, the forwarding proxy MUST + include those Proxy-State Attributes in its response to the + server. The forwarding proxy MAY include the Proxy-State + Attributes in the Disconnect-Request or CoA-Request when it + forwards the request, or it MAY omit them in the forwarded + request. If the forwarding proxy omits the Proxy-State Attributes + in the request, it MUST attach them to the response before sending + it to the server. + + + + + + + + + + + + +Chiba, et al. Informational [Page 10] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +3. Attributes + + In Disconnect-Request and CoA-Request packets, certain attributes are + used to uniquely identify the NAS as well as a user session on the + NAS. All NAS identification attributes included in a Request message + MUST match in order for a Disconnect-Request or CoA-Request to be + successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent. + For session identification attributes, the User-Name and Acct- + Session-Id Attributes, if included, MUST match in order for a + Disconnect-Request or CoA-Request to be successful; other session + identification attributes SHOULD match. Where a mismatch of session + identification attributes is detected, a Disconnect-NAK or CoA-NAK + SHOULD be sent. The ability to use NAS or session identification + attributes to map to unique/multiple sessions is beyond the scope of + this document. Identification attributes include NAS and session + identification attributes, as described below. + + NAS identification attributes + + Attribute # Reference Description + --------- --- --------- ----------- + NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS. + NAS-Identifier 32 [RFC2865] String identifying the NAS. + NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Chiba, et al. Informational [Page 11] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Session identification attributes + + Attribute # Reference Description + --------- --- --------- ----------- + User-Name 1 [RFC2865] The name of the user + associated with the session. + NAS-Port 5 [RFC2865] The port on which the + session is terminated. + Framed-IP-Address 8 [RFC2865] The IPv4 address associated + with the session. + Called-Station-Id 30 [RFC2865] The link address to which + the session is connected. + Calling-Station-Id 31 [RFC2865] The link address from which + the session is connected. + Acct-Session-Id 44 [RFC2866] The identifier uniquely + identifying the session + on the NAS. + Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely + identifying related sessions. + NAS-Port-Type 61 [RFC2865] The type of port used. + NAS-Port-Id 87 [RFC2869] String identifying the port + where the session is. + Originating-Line-Info 94 [NASREQ] Provides information on the + characteristics of the line + from which a session + originated. + Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier + associated with the session; + always sent with + Framed-IPv6-Prefix. + Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated + with the session, always sent + with Framed-Interface-Id. + + To address security concerns described in Section 5.1., the User-Name + Attribute SHOULD be present in Disconnect-Request or CoA-Request + packets; one or more additional session identification attributes MAY + also be present. To address security concerns described in Section + 5.2., one or more of the NAS-IP-Address or NAS-IPv6-Address + Attributes SHOULD be present in Disconnect-Request or CoA-Request + packets; the NAS-Identifier Attribute MAY be present in addition. + + If one or more authorization changes specified in a CoA-Request + cannot be carried out, or if one or more attributes or attribute- + values is unsupported, a CoA-NAK MUST be sent. Similarly, if there + are one or more unsupported attributes or attribute values in a + Disconnect-Request, a Disconnect-NAK MUST be sent. + + + + +Chiba, et al. Informational [Page 12] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Where a Service-Type Attribute with value "Authorize Only" is + included within a CoA-Request or Disconnect-Request, attributes + representing an authorization change MUST NOT be included; only + identification attributes are permitted. If attributes other than + NAS or session identification attributes are included in such a CoA- + Request, implementations MUST send a CoA-NAK; an Error-Cause + Attribute with value "Unsupported Attribute" MAY be included. + Similarly, if attributes other than NAS or session identification + attributes are included in such a Disconnect-Request, implementations + MUST send a Disconnect-NAK; an Error-Cause Attribute with value + "Unsupported Attribute" MAY be included. + +3.1. Error-Cause + + Description + + It is possible that the NAS cannot honor Disconnect-Request or + CoA-Request messages for some reason. The Error-Cause Attribute + provides more detail on the cause of the problem. It MAY be + included within Disconnect-ACK, Disconnect-NAK and CoA-NAK + messages. + + A summary of the Error-Cause Attribute format is shown below. The + fields are transmitted from 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 | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 101 for Error-Cause + + Length + + 6 + + Value + + The Value field is four octets, containing an integer specifying + the cause of the error. Values 0-199 and 300-399 are reserved. + Values 200-299 represent successful completion, so that these + values may only be sent within Disconnect-ACK or CoA-ACK message + and MUST NOT be sent within a Disconnect-NAK or CoA-NAK. Values + + + +Chiba, et al. Informational [Page 13] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + 400-499 represent fatal errors committed by the RADIUS server, so + that they MAY be sent within CoA-NAK or Disconnect-NAK messages, + and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages. + Values 500-599 represent fatal errors occurring on a NAS or RADIUS + proxy, so that they MAY be sent within CoA-NAK and Disconnect-NAK + messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK + messages. Error-Cause values SHOULD be logged by the RADIUS + server. Error-Code values (expressed in decimal) include: + + # Value + --- ----- + 201 Residual Session Context Removed + 202 Invalid EAP Packet (Ignored) + 401 Unsupported Attribute + 402 Missing Attribute + 403 NAS Identification Mismatch + 404 Invalid Request + 405 Unsupported Service + 406 Unsupported Extension + 501 Administratively Prohibited + 502 Request Not Routable (Proxy) + 503 Session Context Not Found + 504 Session Context Not Removable + 505 Other Proxy Processing Error + 506 Resources Unavailable + 507 Request Initiated + + "Residual Session Context Removed" is sent in response to a + Disconnect-Request if the user session is no longer active, but + residual session context was found and successfully removed. This + value is only sent within a Disconnect-ACK and MUST NOT be sent + within a CoA-ACK, Disconnect-NAK or CoA-NAK. + + "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be + sent by implementations of this specification. + + "Unsupported Attribute" is a fatal error sent if a Request contains + an attribute (such as a Vendor-Specific or EAP-Message Attribute) + that is not supported. + + "Missing Attribute" is a fatal error sent if critical attributes + (such as NAS or session identification attributes) are missing from a + Request. + + "NAS Identification Mismatch" is a fatal error sent if one or more + NAS identification attributes (see Section 3.) do not match the + identity of the NAS receiving the Request. + + + + +Chiba, et al. Informational [Page 14] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + "Invalid Request" is a fatal error sent if some other aspect of the + Request is invalid, such as if one or more attributes (such as EAP- + Message Attribute(s)) are not formatted properly. + + "Unsupported Service" is a fatal error sent if a Service-Type + Attribute included with the Request is sent with an invalid or + unsupported value. + + "Unsupported Extension" is a fatal error sent due to lack of support + for an extension such as Disconnect and/or CoA messages. This will + typically be sent by a proxy receiving an ICMP port unreachable + message after attempting to forward a Request to the NAS. + + "Administratively Prohibited" is a fatal error sent if the NAS is + configured to prohibit honoring of Request messages for the specified + session. + + "Request Not Routable" is a fatal error which MAY be sent by a RADIUS + proxy and MUST NOT be sent by a NAS. It indicates that the RADIUS + proxy was unable to determine how to route the Request to the NAS. + For example, this can occur if the required entries are not present + in the proxy's realm routing table. + + "Session Context Not Found" is a fatal error sent if the session + context identified in the Request does not exist on the NAS. + + "Session Context Not Removable" is a fatal error sent in response to + a Disconnect-Request if the NAS was able to locate the session + context, but could not remove it for some reason. It MUST NOT be + sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a + Disconnect-NAK. + + "Other Proxy Processing Error" is a fatal error sent in response to a + Request that could not be processed by a proxy, for reasons other + than routing. + + "Resources Unavailable" is a fatal error sent when a Request could + not be honored due to lack of available NAS resources (memory, non- + volatile storage, etc.). + + "Request Initiated" is a fatal error sent in response to a Request + including a Service-Type Attribute with a value of "Authorize Only". + It indicates that the Disconnect-Request or CoA-Request has not been + honored, but that a RADIUS Access-Request including a Service-Type + Attribute with value "Authorize Only" is being sent to the RADIUS + server. + + + + + +Chiba, et al. Informational [Page 15] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +3.2. Table of Attributes + + The following table provides a guide to which attributes may be found + in which packets, and in what quantity. + + Change-of-Authorization Messages + + Request ACK NAK # Attribute + 0-1 0 0 1 User-Name [Note 1] + 0-1 0 0 4 NAS-IP-Address [Note 1] + 0-1 0 0 5 NAS-Port [Note 1] + 0-1 0 0-1 6 Service-Type [Note 6] + 0-1 0 0 7 Framed-Protocol [Note 3] + 0-1 0 0 8 Framed-IP-Address [Note 1] + 0-1 0 0 9 Framed-IP-Netmask [Note 3] + 0-1 0 0 10 Framed-Routing [Note 3] + 0+ 0 0 11 Filter-ID [Note 3] + 0-1 0 0 12 Framed-MTU [Note 3] + 0+ 0 0 13 Framed-Compression [Note 3] + 0+ 0 0 14 Login-IP-Host [Note 3] + 0-1 0 0 15 Login-Service [Note 3] + 0-1 0 0 16 Login-TCP-Port [Note 3] + 0+ 0 0 18 Reply-Message [Note 2] + 0-1 0 0 19 Callback-Number [Note 3] + 0-1 0 0 20 Callback-Id [Note 3] + 0+ 0 0 22 Framed-Route [Note 3] + 0-1 0 0 23 Framed-IPX-Network [Note 3] + 0-1 0-1 0-1 24 State [Note 7] + 0+ 0 0 25 Class [Note 3] + 0+ 0 0 26 Vendor-Specific [Note 3] + 0-1 0 0 27 Session-Timeout [Note 3] + 0-1 0 0 28 Idle-Timeout [Note 3] + 0-1 0 0 29 Termination-Action [Note 3] + 0-1 0 0 30 Called-Station-Id [Note 1] + 0-1 0 0 31 Calling-Station-Id [Note 1] + 0-1 0 0 32 NAS-Identifier [Note 1] + 0+ 0+ 0+ 33 Proxy-State + 0-1 0 0 34 Login-LAT-Service [Note 3] + 0-1 0 0 35 Login-LAT-Node [Note 3] + 0-1 0 0 36 Login-LAT-Group [Note 3] + 0-1 0 0 37 Framed-AppleTalk-Link [Note 3] + 0+ 0 0 38 Framed-AppleTalk-Network [Note 3] + 0-1 0 0 39 Framed-AppleTalk-Zone [Note 3] + 0-1 0 0 44 Acct-Session-Id [Note 1] + 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] + 0-1 0-1 0-1 55 Event-Timestamp + 0-1 0 0 61 NAS-Port-Type [Note 1] + Request ACK NAK # Attribute + + + +Chiba, et al. Informational [Page 16] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Request ACK NAK # Attribute + 0-1 0 0 62 Port-Limit [Note 3] + 0-1 0 0 63 Login-LAT-Port [Note 3] + 0+ 0 0 64 Tunnel-Type [Note 5] + 0+ 0 0 65 Tunnel-Medium-Type [Note 5] + 0+ 0 0 66 Tunnel-Client-Endpoint [Note 5] + 0+ 0 0 67 Tunnel-Server-Endpoint [Note 5] + 0+ 0 0 69 Tunnel-Password [Note 5] + 0-1 0 0 71 ARAP-Features [Note 3] + 0-1 0 0 72 ARAP-Zone-Access [Note 3] + 0+ 0 0 78 Configuration-Token [Note 3] + 0+ 0-1 0 79 EAP-Message [Note 2] + 0-1 0-1 0-1 80 Message-Authenticator + 0+ 0 0 81 Tunnel-Private-Group-ID [Note 5] + 0+ 0 0 82 Tunnel-Assignment-ID [Note 5] + 0+ 0 0 83 Tunnel-Preference [Note 5] + 0-1 0 0 85 Acct-Interim-Interval [Note 3] + 0-1 0 0 87 NAS-Port-Id [Note 1] + 0-1 0 0 88 Framed-Pool [Note 3] + 0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5] + 0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5] + 0-1 0 0 94 Originating-Line-Info [Note 1] + 0-1 0 0 95 NAS-IPv6-Address [Note 1] + 0-1 0 0 96 Framed-Interface-Id [Note 1] + 0+ 0 0 97 Framed-IPv6-Prefix [Note 1] + 0+ 0 0 98 Login-IPv6-Host [Note 3] + 0+ 0 0 99 Framed-IPv6-Route [Note 3] + 0-1 0 0 100 Framed-IPv6-Pool [Note 3] + 0 0 0+ 101 Error-Cause + Request ACK NAK # Attribute + + Disconnect Messages + + Request ACK NAK # Attribute + 0-1 0 0 1 User-Name [Note 1] + 0-1 0 0 4 NAS-IP-Address [Note 1] + 0-1 0 0 5 NAS-Port [Note 1] + 0-1 0 0-1 6 Service-Type [Note 6] + 0-1 0 0 8 Framed-IP-Address [Note 1] + 0+ 0 0 18 Reply-Message [Note 2] + 0-1 0-1 0-1 24 State [Note 7] + 0+ 0 0 25 Class [Note 4] + 0+ 0 0 26 Vendor-Specific + 0-1 0 0 30 Called-Station-Id [Note 1] + 0-1 0 0 31 Calling-Station-Id [Note 1] + 0-1 0 0 32 NAS-Identifier [Note 1] + 0+ 0+ 0+ 33 Proxy-State + Request ACK NAK # Attribute + + + +Chiba, et al. Informational [Page 17] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Request ACK NAK # Attribute + 0-1 0 0 44 Acct-Session-Id [Note 1] + 0-1 0-1 0 49 Acct-Terminate-Cause + 0-1 0 0 50 Acct-Multi-Session-Id [Note 1] + 0-1 0-1 0-1 55 Event-Timestamp + 0-1 0 0 61 NAS-Port-Type [Note 1] + 0+ 0-1 0 79 EAP-Message [Note 2] + 0-1 0-1 0-1 80 Message-Authenticator + 0-1 0 0 87 NAS-Port-Id [Note 1] + 0-1 0 0 94 Originating-Line-Info [Note 1] + 0-1 0 0 95 NAS-IPv6-Address [Note 1] + 0-1 0 0 96 Framed-Interface-Id [Note 1] + 0+ 0 0 97 Framed-IPv6-Prefix [Note 1] + 0 0+ 0+ 101 Error-Cause + Request ACK NAK # Attribute + + [Note 1] Where NAS or session identification attributes are included + in Disconnect-Request or CoA-Request messages, they are used for + identification purposes only. These attributes MUST NOT be used for + purposes other than identification (e.g. within CoA-Request messages + to request authorization changes). + + [Note 2] The Reply-Message Attribute is used to present a displayable + message to the user. The message is only displayed as a result of a + successful Disconnect-Request or CoA-Request (where a Disconnect-ACK + or CoA-ACK is subsequently sent). Where EAP is used for + authentication, an EAP-Message/Notification-Request Attribute is sent + instead, and Disconnect-ACK or CoA-ACK messages contain an EAP- + Message/Notification-Response Attribute. + + [Note 3] When included within a CoA-Request, these attributes + represent an authorization change request. When one of these + attributes is omitted from a CoA-Request, the NAS assumes that the + attribute value is to remain unchanged. Attributes included in a + CoA-Request replace all existing value(s) of the same attribute(s). + + [Note 4] When included within a successful Disconnect-Request (where + a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be + sent unmodified by the client to the accounting server in the + Accounting Stop packet. If the Disconnect-Request is unsuccessful, + then the Class Attribute is not processed. + + [Note 5] When included within a CoA-Request, these attributes + represent an authorization change request. Where tunnel attribute(s) + are sent within a successful CoA-Request, all existing tunnel + attributes are removed and replaced by the new attribute(s). + + + + + +Chiba, et al. Informational [Page 18] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + [Note 6] When included within a Disconnect-Request or CoA-Request, a + Service-Type Attribute with value "Authorize Only" indicates that the + Request only contains NAS and session identification attributes, and + that the NAS should attempt reauthorization by sending an Access- + Request with a Service-Type Attribute with value "Authorize Only". + This enables a usage model akin to that supported in Diameter, thus + easing translation between the two protocols. Support for the + Service-Type Attribute is optional within CoA-Request and + Disconnect-Request messages; where it is not included, the Request + message may contain both identification and authorization attributes. + A NAS that does not support the Service-Type Attribute with the value + "Authorize Only" within a Disconnect-Request MUST respond with a + Disconnect-NAK including no Service-Type Attribute; an Error-Cause + Attribute with value "Unsupported Service" MAY be included. A NAS + that does not support the Service-Type Attribute with the value + "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK + including no Service-Type Attribute; an Error-Cause Attribute with + value "Unsupported Service" MAY be included. + + A NAS supporting the "Authorize Only" Service-Type value within + Disconnect-Request or CoA-Request messages MUST respond with a + Disconnect-NAK or CoA-NAK respectively, containing a Service-Type + Attribute with value "Authorize Only", and an Error-Cause Attribute + with value "Request Initiated". The NAS then sends an Access-Request + to the RADIUS server with a Service-Type Attribute with value + "Authorize Only". This Access-Request SHOULD contain the NAS + attributes from the Disconnect or CoA-Request, as well as the session + attributes from the Request legal for inclusion in an Access-Request + as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As + noted in [RFC2869] Section 5.19, a Message-Authenticator attribute + SHOULD be included in an Access-Request that does not contain a + User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. + The RADIUS server should send back an Access-Accept to (re-)authorize + the session or an Access-Reject to refuse to (re-)authorize it. + + [Note 7] The State Attribute is available to be sent by the RADIUS + server to the NAS in a Disconnect-Request or CoA-Request message and + MUST be sent unmodified from the NAS to the RADIUS server in a + subsequent ACK or NAK message. If a Service-Type Attribute with + value "Authorize Only" is included in a Disconnect-Request or CoA- + Request along with a State Attribute, then the State Attribute MUST + be sent unmodified from the NAS to the RADIUS server in the resulting + Access-Request sent to the RADIUS server, if any. The State + Attribute is also available to be sent by the RADIUS server to the + NAS in a CoA-Request that also includes a Termination-Action + Attribute with the value of RADIUS-Request. If the client performs + the Termination-Action by sending a new Access-Request upon + termination of the current session, it MUST include the State + + + +Chiba, et al. Informational [Page 19] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Attribute unchanged in that Access-Request. In either usage, the + client MUST NOT interpret the Attribute locally. A Disconnect- + Request or CoA-Request packet must have only zero or one State + Attribute. Usage of the State Attribute is implementation dependent. + If the RADIUS server does not recognize the State Attribute in the + Access-Request, then it MUST send an Access-Reject. + + The following table defines the meaning of the above table entries. + + 0 This attribute MUST NOT be present in packet. + 0+ Zero or more instances of this attribute MAY be present in + packet. + 0-1 Zero or one instance of this attribute MAY be present in packet. + 1 Exactly one instance of this attribute MUST be present in packet. + +4. IANA Considerations + + This document uses the RADIUS [RFC2865] namespace, see + <http://www.iana.org/assignments/radius-types>. There are six + updates for the section: RADIUS Packet Type Codes. These Packet + Types are allocated in [RADIANA]: + + 40 - Disconnect-Request + 41 - Disconnect-ACK + 42 - Disconnect-NAK + 43 - CoA-Request + 44 - CoA-ACK + 45 - CoA-NAK + + Allocation of a new Service-Type value for "Authorize Only" is + requested. This document also uses the UDP [RFC768] namespace, see + <http://www.iana.org/assignments/port-numbers>. The authors request + a port assignment from the Registered ports range. Finally, this + specification allocates the Error-Cause Attribute (101) with the + following decimal values: + + # Value + --- ----- + 201 Residual Session Context Removed + 202 Invalid EAP Packet (Ignored) + 401 Unsupported Attribute + 402 Missing Attribute + 403 NAS Identification Mismatch + 404 Invalid Request + 405 Unsupported Service + 406 Unsupported Extension + 501 Administratively Prohibited + 502 Request Not Routable (Proxy) + + + +Chiba, et al. Informational [Page 20] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + 503 Session Context Not Found + 504 Session Context Not Removable + 505 Other Proxy Processing Error + 506 Resources Unavailable + 507 Request Initiated + +5. Security Considerations + +5.1. Authorization Issues + + Where a NAS is shared by multiple providers, it is undesirable for + one provider to be able to send Disconnect-Request or CoA-Requests + affecting the sessions of another provider. + + A NAS or RADIUS proxy MUST silently discard Disconnect-Request or + CoA-Request messages from untrusted sources. By default, a RADIUS + proxy SHOULD perform a "reverse path forwarding" (RPF) check to + verify that a Disconnect-Request or CoA-Request originates from an + authorized RADIUS server. In addition, it SHOULD be possible to + explicitly authorize additional sources of Disconnect-Request or + CoA-Request packets relating to certain classes of sessions. For + example, a particular source can be explicitly authorized to send + CoA-Request messages relating to users within a set of realms. + + To perform the RPF check, the proxy uses the session identification + attributes included in Disconnect-Request or CoA-Request messages, in + order to determine the RADIUS server(s) to which an equivalent + Access-Request could be routed. If the source address of the + Disconnect-Request or CoA-Request is within this set, then the + Request is forwarded; otherwise it MUST be silently discarded. + + Typically the proxy will extract the realm from the Network Access + Identifier [RFC2486] included within the User-Name Attribute, and + determine the corresponding RADIUS servers in the proxy routing + tables. The RADIUS servers for that realm are then compared against + the source address of the packet. Where no RADIUS proxy is present, + the RPF check will need to be performed by the NAS itself. + + Since authorization to send a Disconnect-Request or CoA-Request is + determined based on the source address and the corresponding shared + secret, the NASes or proxies SHOULD configure a different shared + secret for each RADIUS server. + + + + + + + + + +Chiba, et al. Informational [Page 21] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +5.2. Impersonation + + [RFC2865] Section 3 states: + + A RADIUS server MUST use the source IP address of the RADIUS UDP + packet to decide which shared secret to use, so that RADIUS + requests can be proxied. + + When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or + NAS-IPv6-Address Attributes will typically not match the source + address observed by the RADIUS server. Since the NAS-Identifier + Attribute need not contain an FQDN, this attribute may not be + resolvable to the source address observed by the RADIUS server, even + when no proxy is present. + + As a result, the authenticity check performed by a RADIUS server or + proxy does not verify the correctness of NAS identification + attributes. This makes it possible for a rogue NAS to forge NAS-IP- + Address, NAS-IPv6-Address or NAS-Identifier Attributes within a + RADIUS Access-Request in order to impersonate another NAS. It is + also possible for a rogue NAS to forge session identification + attributes such as the Called-Station-Id, Calling-Station-Id, or + Originating-Line-Info [NASREQ]. This could fool the RADIUS server + into sending Disconnect-Request or CoA-Request messages containing + forged session identification attributes to a NAS targeted by an + attacker. + + To address these vulnerabilities RADIUS proxies SHOULD check whether + NAS identification attributes (see Section 3.) match the source + address of packets originating from the NAS. Where one or more + attributes do not match, Disconnect-Request or CoA-Request messages + SHOULD be silently discarded. + + Such a check may not always be possible. Since the NAS-Identifier + Attribute need not correspond to an FQDN, it may not be resolvable to + an IP address to be matched against the source address. Also, where + a NAT exists between the RADIUS client and proxy, checking the NAS- + IP-Address or NAS-IPv6-Address Attributes may not be feasible. + +5.3. IPsec Usage Guidelines + + In addition to security vulnerabilities unique to Disconnect or CoA + messages, the protocol exchanges described in this document are + susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is + RECOMMENDED that IPsec be employed to afford better security. + + + + + + +Chiba, et al. Informational [Page 22] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + Implementations of this specification SHOULD support IPsec [RFC2401] + along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] + with a non-null transform SHOULD be supported, and IPsec ESP with a + non-null encryption transform and authentication support SHOULD be + used to provide per-packet confidentiality, authentication, integrity + and replay protection. IKE SHOULD be used for key management. + + Within RADIUS [RFC2865], a shared secret is used for hiding + Attributes such as User-Password, as well as used in computation of + the Response Authenticator. In RADIUS accounting [RFC2866], the + shared secret is used in computation of both the Request + Authenticator and the Response Authenticator. + + Since in RADIUS a shared secret is used to provide confidentiality as + well as integrity protection and authentication, only use of IPsec + ESP with a non-null transform can provide security services + sufficient to substitute for RADIUS application-layer security. + Therefore, where IPsec AH or ESP null is used, it will typically + still be necessary to configure a RADIUS shared secret. + + Where RADIUS is run over IPsec ESP with a non-null transform, the + secret shared between the NAS and the RADIUS server MAY NOT be + configured. In this case, a shared secret of zero length MUST be + assumed. However, a RADIUS server that cannot know whether incoming + traffic is IPsec-protected MUST be configured with a non-null RADIUS + shared secret. + + When IPsec ESP is used with RADIUS, per-packet authentication, + integrity and replay protection MUST be used. 3DES-CBC MUST be + supported as an encryption transform and AES-CBC SHOULD be supported. + AES-CBC SHOULD be offered as a preferred encryption transform if + supported. HMAC-SHA1-96 MUST be supported as an authentication + transform. DES-CBC SHOULD NOT be used as the encryption transform. + + A typical IPsec policy for an IPsec-capable RADIUS client is + "Initiate IPsec, from me to any destination port UDP 1812". This + IPsec policy causes an IPsec SA to be set up by the RADIUS client + prior to sending RADIUS traffic. If some RADIUS servers contacted by + the client do not support IPsec, then a more granular policy will be + required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, + destination port UDP 1812." + + For a client implementing this specification, the policy would be + "Accept IPsec, from any to me, destination port UDP 3799". This + causes the RADIUS client to accept (but not require) use of IPsec. + It may not be appropriate to require IPsec for all RADIUS servers + connecting to an IPsec-enabled RADIUS client, since some RADIUS + servers may not support IPsec. + + + +Chiba, et al. Informational [Page 23] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept + IPsec, from any to me, destination port 1812". This causes the + RADIUS server to accept (but not require) use of IPsec. It may not + be appropriate to require IPsec for all RADIUS clients connecting to + an IPsec-enabled RADIUS server, since some RADIUS clients may not + support IPsec. + + For servers implementing this specification, the policy would be + "Initiate IPsec, from me to any, destination port UDP 3799". This + causes the RADIUS server to initiate IPsec when sending RADIUS + extension traffic to any RADIUS client. If some RADIUS clients + contacted by the server do not support IPsec, then a more granular + policy will be required, such as "Initiate IPsec, from me to IPsec- + capable-RADIUS-client, destination port UDP 3799". + + Where IPsec is used for security, and no RADIUS shared secret is + configured, it is important that the RADIUS client and server perform + an authorization check. Before enabling a host to act as a RADIUS + client, the RADIUS server SHOULD check whether the host is authorized + to provide network access. Similarly, before enabling a host to act + as a RADIUS server, the RADIUS client SHOULD check whether the host + is authorized for that role. + + RADIUS servers can be configured with the IP addresses (for IKE + Aggressive Mode with pre-shared keys) or FQDNs (for certificate + authentication) of RADIUS clients. Alternatively, if a separate + Certification Authority (CA) exists for RADIUS clients, then the + RADIUS server can configure this CA as a trust anchor [RFC3280] for + use with IPsec. + + Similarly, RADIUS clients can be configured with the IP addresses + (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for + certificate authentication) of RADIUS servers. Alternatively, if a + separate CA exists for RADIUS servers, then the RADIUS client can + configure this CA as a trust anchor for use with IPsec. + + Since unlike SSL/TLS, IKE does not permit certificate policies to be + set on a per-port basis, certificate policies need to apply to all + uses of IPsec on RADIUS clients and servers. In IPsec deployment + supporting only certificate authentication, a management station + initiating an IPsec-protected telnet session to the RADIUS server + would need to obtain a certificate chaining to the RADIUS client CA. + Issuing such a certificate might not be appropriate if the management + station was not authorized as a RADIUS client. + + Where RADIUS clients may obtain their IP address dynamically (such as + an Access Point supporting DHCP), Main Mode with pre-shared keys + [RFC2409] SHOULD NOT be used, since this requires use of a group + + + +Chiba, et al. Informational [Page 24] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + pre-shared key; instead, Aggressive Mode SHOULD be used. Where + RADIUS client addresses are statically assigned, either Aggressive + Mode or Main Mode MAY be used. With certificate authentication, Main + Mode SHOULD be used. + + Care needs to be taken with IKE Phase 1 Identity Payload selection in + order to enable mapping of identities to pre-shared keys, even with + Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity + Payloads are used and addresses are dynamically assigned, mapping of + identities to keys is not possible, so that group pre-shared keys are + still a practical necessity. As a result, the ID_FQDN identity + payload SHOULD be employed in situations where Aggressive mode is + utilized along with pre-shared keys and IP addresses are dynamically + assigned. This approach also has other advantages, since it allows + the RADIUS server and client to configure themselves based on the + fully qualified domain name of their peers. + + Note that with IPsec, security services are negotiated at the + granularity of an IPsec SA, so that RADIUS exchanges requiring a set + of security services different from those negotiated with existing + IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs + are also advisable where quality of service considerations dictate + different handling RADIUS conversations. Attempting to apply + different quality of service to connections handled by the same IPsec + SA can result in reordering, and falling outside the replay window. + For a discussion of the issues, see [RFC2983]. + +5.4. Replay Protection + + Where IPsec replay protection is not used, the Event-Timestamp (55) + Attribute [RFC2869] SHOULD be included within all messages. When + this attribute is present, both the NAS and the RADIUS server MUST + check that the Event-Timestamp Attribute is current within an + acceptable time window. If the Event-Timestamp Attribute is not + current, then the message MUST be silently discarded. This implies + the need for time synchronization within the network, which can be + achieved by a variety of means, including secure NTP, as described in + [NTPAUTH]. + + Both the NAS and the RADIUS server SHOULD be configurable to silently + discard messages lacking an Event-Timestamp Attribute. A default + time window of 300 seconds is recommended. + + + + + + + + + +Chiba, et al. Informational [Page 25] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +6. Example Traces + + Disconnect Request with User-Name: + + 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....# + 16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^.. + 32: 6d63 6869 6261 + + Disconnect Request with Acct-Session-ID: + + 0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(..... + 16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,. + 32: 3930 3233 3435 3637 90234567 + + Disconnect Request with Framed-IP-Address: + + 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(..... + 16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ... + 32: 0a00 0203 + +7. References + +7.1. Normative References + + [RFC1305] Mills, D., "Network Time Protocol (version 3) + Specification, Implementation and Analysis", RFC 1305, + March 1992. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC + 1321, April 1992. + + [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for + the Internet Protocol", RFC 2401, November 1998. + + [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security + Payload (ESP)", RFC 2406, November 1998. + + [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + + + + + +Chiba, et al. Informational [Page 26] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, RFC + 2434, October 1998. + + [RFC2486] Aboba, B. and M. Beadles, "The Network Access + Identifier", RFC 2486, January 1999. + + [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + + [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS + Extensions", RFC 2869, June 2000. + + [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", + RFC 3162, August 2001. + + [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [RADIANA] Aboba, B., "IANA Considerations for RADIUS (Remote + Authentication Dial In User Service)", RFC 3575, July + 2003. + +7.2. Informative References + + [RFC2882] Mitton, D., "Network Access Server Requirements: + Extended RADIUS Practices", RFC 2882, July 2000. + + [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC + 2983, October 2000. + + [AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization + and Accounting (AAA) Transport Profile", RFC 3539, + June 2003. + + [Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in + Progress. + + [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent + Attack", CryptoBytes Vol.2 No.2, Summer 1996. + + [NASREQ] Calhoun, P., et al., "Diameter Network Access Server + Application", Work in Progress. + + + +Chiba, et al. Informational [Page 27] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + + [NTPAUTH] Mills, D., "Public Key Cryptography for the Network + Time Protocol", Work in Progress. + +8. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards- related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementers or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +9. Acknowledgments + + This protocol was first developed and distributed by Ascend + Communications. Example code was distributed in their free server + kit. + + The authors would like to acknowledge the valuable suggestions and + feedback from the following people: + + Avi Lior <avi@bridgewatersystems.com>, + Randy Bush <randy@psg.net>, + Steve Bellovin <smb@research.att.com> + Glen Zorn <gwz@cisco.com>, + Mark Jones <mjones@bridgewatersystems.com>, + Claudio Lapidus <clapidus@hotmail.com>, + Anurag Batta <Anurag_Batta@3com.com>, + Kuntal Chowdhury <chowdury@nortelnetworks.com>, and + Tim Moore <timmoore@microsoft.com>. + Russ Housley <housley@vigilsec.com> + + + + + + + +Chiba, et al. Informational [Page 28] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +10. Authors' Addresses + + Murtaza Chiba + Cisco Systems, Inc. + 170 West Tasman Dr. + San Jose CA, 95134 + + EMail: mchiba@cisco.com + Phone: +1 408 525 7198 + + Gopal Dommety + Cisco Systems, Inc. + 170 West Tasman Dr. + San Jose, CA 95134 + + EMail: gdommety@cisco.com + Phone: +1 408 525 1404 + + Mark Eklund + Cisco Systems, Inc. + 170 West Tasman Dr. + San Jose, CA 95134 + + EMail: meklund@cisco.com + Phone: +1 865 671 6255 + + David Mitton + Circular Logic UnLtd. + 733 Turnpike Street #154 + North Andover, MA 01845 + + EMail: david@mitton.com + Phone: +1 978 683 1814 + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + EMail: bernarda@microsoft.com + Phone: +1 425 706 6605 + Fax: +1 425 936 7329 + + + + + + + + + +Chiba, et al. Informational [Page 29] + +RFC 3576 Dynamic Authorization Extensions to RADIUS July 2003 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Chiba, et al. Informational [Page 30] + diff --git a/rfc/rfc3580.txt b/rfc/rfc3580.txt new file mode 100644 index 00000000..b87235cf --- /dev/null +++ b/rfc/rfc3580.txt @@ -0,0 +1,1683 @@ + + + + + + +Network Working Group P. Congdon +Request for Comments: 3580 Hewlett Packard Company +Category: Informational B. Aboba + Microsoft + A. Smith + Trapeze Networks + G. Zorn + Cisco Systems + J. Roese + Enterasys + September 2003 + + + IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) + Usage Guidelines + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document provides suggestions on Remote Authentication Dial In + User Service (RADIUS) usage by IEEE 802.1X Authenticators. The + material in this document is also included within a non-normative + Appendix within the IEEE 802.1X specification, and is being presented + as an IETF RFC for informational purposes. + + + + + + + + + + + + + + + + + + +Congdon, et al. Informational [Page 1] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Requirements Language. . . . . . . . . . . . . . . . . . 4 + 2. RADIUS Accounting Attributes . . . . . . . . . . . . . . . . . 5 + 2.1. Acct-Terminate-Cause . . . . . . . . . . . . . . . . . . 5 + 2.2. Acct-Multi-Session-Id. . . . . . . . . . . . . . . . . . 6 + 2.3. Acct-Link-Count. . . . . . . . . . . . . . . . . . . . . 7 + 3. RADIUS Authentication. . . . . . . . . . . . . . . . . . . . . 7 + 3.1. User-Name. . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.2. User-Password, CHAP-Password, CHAP-Challenge . . . . . . 8 + 3.3. NAS-IP-Address, NAS-IPv6-Address . . . . . . . . . . . . 8 + 3.4. NAS-Port . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.5. Service-Type . . . . . . . . . . . . . . . . . . . . . . 8 + 3.6. Framed-Protocol. . . . . . . . . . . . . . . . . . . . . 9 + 3.7. Framed-IP-Address, Framed-IP-Netmask . . . . . . . . . . 9 + 3.8. Framed-Routing . . . . . . . . . . . . . . . . . . . . . 9 + 3.9. Filter-ID. . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.10. Framed-MTU . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.11. Framed-Compression . . . . . . . . . . . . . . . . . . . 10 + 3.12. Displayable Messages . . . . . . . . . . . . . . . . . . 10 + 3.13. Callback-Number, Callback-ID . . . . . . . . . . . . . . 10 + 3.14. Framed-Route, Framed-IPv6-Route. . . . . . . . . . . . . 11 + 3.15. State, Class, Proxy-State. . . . . . . . . . . . . . . . 11 + 3.16. Vendor-Specific. . . . . . . . . . . . . . . . . . . . . 11 + 3.17. Session-Timeout. . . . . . . . . . . . . . . . . . . . . 11 + 3.18. Idle-Timeout . . . . . . . . . . . . . . . . . . . . . . 12 + 3.19. Termination-Action . . . . . . . . . . . . . . . . . . . 12 + 3.20. Called-Station-Id. . . . . . . . . . . . . . . . . . . . 12 + 3.21. Calling-Station-Id . . . . . . . . . . . . . . . . . . . 12 + 3.22. NAS-Identifier . . . . . . . . . . . . . . . . . . . . . 12 + 3.23. NAS-Port-Type. . . . . . . . . . . . . . . . . . . . . . 12 + 3.24. Port-Limit . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.25. Password-Retry . . . . . . . . . . . . . . . . . . . . . 13 + 3.26. Connect-Info . . . . . . . . . . . . . . . . . . . . . . 13 + 3.27. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 13 + 3.28. Message-Authenticator. . . . . . . . . . . . . . . . . . 13 + 3.29. NAS-Port-Id. . . . . . . . . . . . . . . . . . . . . . . 13 + 3.30. Framed-Pool, Framed-IPv6-Pool. . . . . . . . . . . . . . 14 + 3.31. Tunnel Attributes. . . . . . . . . . . . . . . . . . . . 14 + 4. RC4 EAPOL-Key Descriptor . . . . . . . . . . . . . . . . . . . 15 + 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 18 + 5.1. Packet Modification or Forgery . . . . . . . . . . . . . 18 + 5.2. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 19 + 5.3. Known Plaintext Attacks. . . . . . . . . . . . . . . . . 19 + 5.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 5.5. Outcome Mismatches . . . . . . . . . . . . . . . . . . . 20 + + + +Congdon, et al. Informational [Page 2] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + 5.6. 802.11 Integration . . . . . . . . . . . . . . . . . . . 20 + 5.7. Key Management Issues. . . . . . . . . . . . . . . . . . 21 + 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 + 7.2. Informative References . . . . . . . . . . . . . . . . . 23 + 8. Table of Attributes. . . . . . . . . . . . . . . . . . . . . . 25 + 9. Intellectual Property Statement . . . . . . . . . . . . . . . 28 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 + 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 + 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30 + +1. Introduction + + IEEE 802.1X enables authenticated access to IEEE 802 media, including + Ethernet, Token Ring, and 802.11 wireless LANs. Although Remote + Authentication Dial In User Service (RADIUS) support is optional + within IEEE 802.1X, it is expected that many IEEE 802.1X + Authenticators will function as RADIUS clients. + + IEEE 802.1X [IEEE8021X] provides "network port authentication" for + IEEE 802 [IEEE802] media, including Ethernet [IEEE8023], Token Ring + and 802.11 [IEEE80211] wireless LANS. + + IEEE 802.1X does not require use of a backend Authentication Server, + and thus can be deployed with stand-alone bridges or Access Points, + as well as in centrally managed scenarios. + + In situations where it is desirable to centrally manage + authentication, authorization and accounting (AAA) for IEEE 802 + networks, deployment of a backend authentication and accounting + server is desirable. In such situations, it is expected that IEEE + 802.1X Authenticators will function as AAA clients. + + This document provides suggestions on RADIUS usage by IEEE 802.1X + Authenticators. Support for any AAA protocol is optional for IEEE + 802.1X Authenticators, and therefore this specification has been + incorporated into a non-normative Appendix within the IEEE 802.1X + specification. + +1.1. Terminology + + This document uses the following terms: + + Access Point (AP) + A Station that provides access to the distribution services via + the wireless medium for associated Stations. + + + + +Congdon, et al. Informational [Page 3] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + Association + The service used to establish Access Point/Station mapping and + enable Station invocation of the distribution system services. + + Authenticator + An Authenticator is an entity that requires authentication from + the Supplicant. The Authenticator may be connected to the + Supplicant at the other end of a point-to-point LAN segment or + 802.11 wireless link. + + Authentication Server + An Authentication Server is an entity that provides an + Authentication Service to an Authenticator. This service + verifies, from the credentials provided by the Supplicant, the + claim of identity made by the Supplicant. + + Port Access Entity (PAE) + The protocol entity associated with a physical or virtual + (802.11) Port. A given PAE may support the protocol + functionality associated with the Authenticator, Supplicant or + both. + + Station (STA) + Any device that contains an IEEE 802.11 conformant medium + access control (MAC) and physical layer (PHY) interface to the + wireless medium (WM). + + Supplicant + A Supplicant is an entity that is being authenticated by an + Authenticator. The Supplicant may be connected to the + Authenticator at one end of a point-to-point LAN segment or + 802.11 wireless link. + +1.2. Requirements Language + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. The key + words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document + are to be interpreted as described in [RFC2119]. + + + + + + + + + + + +Congdon, et al. Informational [Page 4] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +2. RADIUS Accounting Attributes + + With a few exceptions, the RADIUS accounting attributes defined in + [RFC2866], [RFC2867], and [RFC2869] have the same meaning within IEEE + 802.1X sessions as they do in dialup sessions and therefore no + additional commentary is needed. + + Attributes requiring more discussion include: + + Acct-Terminate-Cause + Acct-Multi-Session-Id + Acct-Link-Count + +2.1. Acct-Terminate-Cause + + This attribute indicates how the session was terminated, as described + in [RFC2866]. [IEEE8021X] defines the following termination cause + values, which are shown with their RADIUS equivalents in the table on + the next page. + + IEEE 802.1X RADIUS + dot1xAuthSessionTerminateCause Acct-Terminate-Cause + Value Value + ------------- -------------------- + SupplicantLogoff(1) User Request (1) + portFailure(2) Lost Carrier (2) + SupplicantRestart(3) Supplicant Restart (19) + reauthFailed(4) Reauthentication Failure (20) + authControlForceUnauth(5) Admin Reset (6) + portReInit(6) Port Reinitialized (21) + portAdminDisabled(7) Port Administratively Disabled (22) + notTerminatedYet(999) N/A + + When using this attribute, the User Request (1) termination cause + corresponds to the situation in which the session terminated due to + an EAPOL-Logoff received from the Supplicant. When a session is + moved due to roaming, the EAPOL state machines will treat this as a + Supplicant Logoff. + + A Lost Carrier (2) termination cause indicates session termination + due to loss of physical connectivity for reasons other than roaming + between Access Points. For example, if the Supplicant disconnects a + point-to-point LAN connection, or moves out of range of an Access + Point, this termination cause is used. Lost Carrier (2) therefore + equates to a Port Disabled condition in the EAPOL state machines. + + A Supplicant Restart (19) termination cause indicates + re-initialization of the Supplicant state machines. + + + +Congdon, et al. Informational [Page 5] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + A Reauthentication Failure (20) termination cause indicates that a + previously authenticated Supplicant has failed to re-authenticate + successfully following expiry of the re-authentication timer or + explicit re-authentication request by management action. + + Within [IEEE80211], periodic re-authentication may be useful in + preventing reuse of an initialization vector with a given key. Since + successful re-authentication does not result in termination of the + session, accounting packets are not sent as a result of + re-authentication unless the status of the session changes. For + example: + + a. The session is terminated due to re-authentication failure. In + this case the Reauthentication Failure (20) termination cause is + used. + + b. The authorizations are changed as a result of a successful + re-authentication. In this case, the Service Unavailable (15) + termination cause is used. For accounting purposes, the portion + of the session after the authorization change is treated as a + separate session. + + Where IEEE 802.1X authentication occurs prior to association, + accounting packets are not sent until an association occurs. + + An Admin Reset (6) termination cause indicates that the Port has been + administratively forced into the unauthorized state. + + A Port Reinitialized (21) termination cause indicates that the Port's + MAC has been reinitialized. + + A Port Administratively Disabled (22) termination cause indicates + that the Port has been administratively disabled. + +2.2. Acct-Multi-Session-Id + + The purpose of this attribute is to make it possible to link together + multiple related sessions. While [IEEE8021X] does not act on + aggregated ports, it is possible for a Supplicant roaming between + Access Points to cause multiple RADIUS accounting packets to be sent + by different Access Points. + + Where supported by the Access Points, the Acct-Multi-Session-Id + attribute can be used to link together the multiple related sessions + of a roaming Supplicant. In such a situation, if the session context + is transferred between Access Points, accounting packets MAY be sent + without a corresponding authentication and authorization exchange, + + + + +Congdon, et al. Informational [Page 6] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + provided that Association has occurred. However, in such a situation + it is assumed that the Acct-Multi-Session-Id is transferred between + the Access Points as part of the Inter-Access Point Protocol (IAPP). + + If the Acct-Multi-Session-Id were not unique between Access Points, + then it is possible that the chosen Acct-Multi-Session-Id will + overlap with an existing value allocated on that Access Point, and + the Accounting Server would therefore be unable to distinguish a + roaming session from a multi-link session. + + As a result, the Acct-Multi-Session-Id attribute is unique among all + the bridges or Access Points, Supplicants and sessions. In order to + provide this uniqueness, it is suggested that the Acct-Multi- + Session-Id be of the form: + + Original AP MAC Address | Supplicant MAC Address | NTP Timestamp + + Here "|" represents concatenation, the original AP MAC Address is the + MAC address of the bridge or Access Point at which the session + started, and the 64-bit NTP timestamp indicates the beginning of the + original session. In order to provide for consistency of the Acct- + Multi-Session-Id between roaming sessions, the Acct-Multi-Session-Id + may be moved between Access Points as part of IAPP or another handoff + scheme. + + The use of an Acct-Multi-Session-Id of this form guarantees + uniqueness among all Access Points, Supplicants and sessions. Since + the NTP timestamp does not wrap on reboot, there is no possibility + that a rebooted Access Point could choose an Acct-Multi-Session-Id + that could be confused with that of a previous session. + + Since the Acct-Multi-Session-Id is of type String as defined in + [RFC2866], for use with IEEE 802.1X, it is encoded as an ASCII string + of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2- + 14-23-DE-AF-23-83-C0-76-B8-44-E8" + +2.3. Acct-Link-Count + + The Acct-Link-Count attribute may be used to account for the number + of ports that have been aggregated. + +3. RADIUS Authentication + + This section describes how attributes defined in [RFC2865], + [RFC2867], [RFC2868], [RFC2869], [RFC3162] and [RFC3579] are used in + IEEE 802.1X authentication. + + + + + +Congdon, et al. Informational [Page 7] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +3.1. User-Name + + In IEEE 802.1X, the Supplicant typically provides its identity via an + EAP-Response/Identity message. Where available, the Supplicant + identity is included in the User-Name attribute, and included in the + RADIUS Access-Request and Access-Reply messages as specified in + [RFC2865] and [RFC3579]. + + Alternatively, as discussed in [RFC3579] Section 2.1., the User-Name + attribute may contain the Calling-Station-ID value, which is set to + the Supplicant MAC address. + +3.2. User-Password, CHAP-Password, CHAP-Challenge + + Since IEEE 802.1X does not support PAP or CHAP authentication, the + User-Password, CHAP-Password or CHAP-Challenge attributes are not + used by IEEE 802.1X Authenticators acting as RADIUS clients. + +3.3. NAS-IP-Address, NAS-IPv6-Address + + For use with IEEE 802.1X, the NAS-IP-Address contains the IPv4 + address of the bridge or Access Point acting as an Authenticator, and + the NAS-IPv6-Address contains the IPv6 address. If the IEEE 802.1X + Authenticator has more than one interface, it may be desirable to use + a loopback address for this purpose so that the Authenticator will + still be reachable even if one of the interfaces were to fail. + +3.4. NAS-Port + + For use with IEEE 802.1X the NAS-Port will contain the port number of + the bridge, if this is available. While an Access Point does not + have physical ports, a unique "association ID" is assigned to every + mobile Station upon a successful association exchange. As a result, + for an Access Point, if the association exchange has been completed + prior to authentication, the NAS-Port attribute will contain the + association ID, which is a 16-bit unsigned integer. Where IEEE + 802.1X authentication occurs prior to association, a unique NAS-Port + value may not be available. + +3.5. Service-Type + + For use with IEEE 802.1X, the Framed (2), Authenticate Only (8), and + Call Check (10) values are most commonly used. + + A Service-Type of Framed indicates that appropriate 802 framing + should be used for the connection. A Service-Type of Authenticate + Only (8) indicates that no authorization information needs to be + returned in the Access-Accept. As described in [RFC2865], a + + + +Congdon, et al. Informational [Page 8] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + Service-Type of Call Check is included in an Access-Request packet to + request that the RADIUS server accept or reject the connection + attempt, typically based on the Called-Station-ID (set to the bridge + or Access Point MAC address) or Calling-Station-ID attributes (set to + the Supplicant MAC address). As noted in [RFC2865], it is + recommended that in this case, the User-Name attribute be given the + value of Calling-Station-Id. + +3.6. Framed-Protocol + + Since there is no value for IEEE 802 media, the Framed-Protocol + attribute is not used by IEEE 802.1X Authenticators. + +3.7. Framed-IP-Address, Framed-IP-Netmask + + IEEE 802.1X does not provide a mechanism for IP address assignment. + Therefore the Framed-IP-Address and Framed-IP-Netmask attributes can + only be used by IEEE 802.1X Authenticators that support IP address + assignment mechanisms. Typically this capability is supported by + layer 3 devices. + +3.8. Framed-Routing + + The Framed-Routing attribute indicates the routing method for the + Supplicant. It is therefore only relevant for IEEE 802.1X + Authenticators that act as layer 3 devices, and cannot be used by a + bridge or Access Point. + +3.9. Filter-ID + + This attribute indicates the name of the filter list to be applied to + the Supplicant's session. For use with an IEEE 802.1X Authenticator, + it may be used to indicate either layer 2 or layer 3 filters. Layer + 3 filters are typically only supported on IEEE 802.1X Authenticators + that act as layer 3 devices. + +3.10. Framed-MTU + + This attribute indicates the maximum size of an IP packet that may be + transmitted over the wire between the Supplicant and the + Authenticator. IEEE 802.1X Authenticators set this to the value + corresponding to the relevant 802 medium, and include it in the + RADIUS Access-Request. The RADIUS server may send an EAP packet as + large as Framed-MTU minus four (4) octets, taking into account the + additional overhead for the IEEE 802.1X Version (1), Type (1) and + Body Length (2) fields. For EAP over IEEE 802 media, the Framed-MTU + values (which do not include LLC/SNAP overhead) and maximum frame + length values (not including the preamble) are as follows: + + + +Congdon, et al. Informational [Page 9] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + Maximum Frame + Media Framed-MTU Length + ========= =============== ============== + Ethernet 1500 1522 + 802.3 1500 1522 + 802.4 8174 8193 + 802.5 (4 Mbps) 4528 4550 + 802.5 (16 Mbps) 18173 18200 + 802.5 (100 Mb/s) 18173 18200 + 802.6 9191 9240 + 802.9a 1500 1518 + 802.11 2304 2346 + 802.12 (Ethernet) 1500 1518 + 802.12 (Token Ring) 4502 4528 + FDDI 4479 4500 + + NOTE - the Framed-MTU size for IEEE 802.11 media may change as a + result of ongoing work being undertaken in the IEEE 802.11 Working + Group. Since some 802.11 stations cannot handle an MTU larger than + 1500 octets, it is recommended that RADIUS servers encountering a + NAS-Port-Type value of 802.11 send EAP packets no larger than 1496 + octets. + +3.11. Framed-Compression + + [IEEE8021X] does not include compression support. Therefore this + attribute is not understood by [IEEE8021X] Authenticators. + +3.12. Displayable Messages + + The Reply-Message attribute, defined in section 5.18 of [RFC2865], + indicates text which may be displayed to the user. This is similar + in concept to the EAP Notification Type, defined in [RFC2284]. As + noted in [RFC3579], Section 2.6.5, when sending a displayable message + to an [IEEE8021X] Authenticator, displayable messages are best sent + within EAP-Message/EAP-Request/Notification attribute(s), and not + within Reply-Message attribute(s). + +3.13. Callback-Number, Callback-ID + + These attributes are not understood by IEEE 802.1X Authenticators. + + + + + + + + + + +Congdon, et al. Informational [Page 10] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +3.14. Framed-Route, Framed-IPv6-Route + + The Framed-Route and Framed-IPv6-Route attributes provide routes that + are to be configured for the Supplicant. These attributes are + therefore only relevant for IEEE 802.1X Authenticators that act as + layer 3 devices, and cannot be understood by a bridge or Access + Point. + +3.15. State, Class, Proxy-State + + These attributes are used for the same purposes as described in + [RFC2865]. + +3.16. Vendor-Specific + + Vendor-specific attributes are used for the same purposes as + described in [RFC2865]. The MS-MPPE-Send-Key and MS-MPPE-Recv-Key + attributes, described in section 2.4 of [RFC2548], MAY be used to + encrypt and authenticate the RC4 EAPOL-Key descriptor [IEEE8021X, + Section 7.6]. Examples of the derivation of the MS-MPPE-Send-Key and + MS-MPPE-Recv-Key attributes from the master key negotiated by an EAP + method are given in [RFC2716]. Details of the EAPOL-Key descriptor + are provided in Section 4. + +3.17. Session-Timeout + + When sent along in an Access-Accept without a Termination-Action + attribute or with a Termination-Action attribute set to Default, the + Session-Timeout attribute specifies the maximum number of seconds of + service provided prior to session termination. + + When sent in an Access-Accept along with a Termination-Action value + of RADIUS-Request, the Session-Timeout attribute specifies the + maximum number of seconds of service provided prior to re- + authentication. In this case, the Session-Timeout attribute is used + to load the reAuthPeriod constant within the Reauthentication Timer + state machine of 802.1X. When sent with a Termination-Action value + of RADIUS-Request, a Session-Timeout value of zero indicates the + desire to perform another authentication (possibly of a different + type) immediately after the first authentication has successfully + completed. + + When sent in an Access-Challenge, this attribute represents the + maximum number of seconds that an IEEE 802.1X Authenticator should + wait for an EAP-Response before retransmitting. In this case, the + Session-Timeout attribute is used to load the suppTimeout constant + within the backend state machine of IEEE 802.1X. + + + + +Congdon, et al. Informational [Page 11] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +3.18. Idle-Timeout + + The Idle-Timeout attribute is described in [RFC2865]. For IEEE 802 + media other than 802.11 the media are always on. As a result the + Idle-Timeout attribute is typically only used with wireless media + such as IEEE 802.11. It is possible for a wireless device to wander + out of range of all Access Points. In this case, the Idle-Timeout + attribute indicates the maximum time that a wireless device may + remain idle. + +3.19. Termination-Action + + This attribute indicates what action should be taken when the service + is completed. The value RADIUS-Request (1) indicates that re- + authentication should occur on expiration of the Session-Time. The + value Default (0) indicates that the session should terminate. + +3.20. Called-Station-Id + + For IEEE 802.1X Authenticators, this attribute is used to store the + bridge or Access Point MAC address in ASCII format (upper case only), + with octet values separated by a "-". Example: "00-10-A4-23-19-C0". + In IEEE 802.11, where the SSID is known, it SHOULD be appended to the + Access Point MAC address, separated from the MAC address with a ":". + Example "00-10-A4-23-19-C0:AP1". + +3.21. Calling-Station-Id + + For IEEE 802.1X Authenticators, this attribute is used to store the + Supplicant MAC address in ASCII format (upper case only), with octet + values separated by a "-". Example: "00-10-A4-23-19-C0". + +3.22. NAS-Identifier + + This attribute contains a string identifying the IEEE 802.1X + Authenticator originating the Access-Request. + +3.23. NAS-Port-Type + + For use with IEEE 802.1X, NAS-Port-Type values of Ethernet (15) + Wireless - IEEE 802.11 (19), Token Ring (20) and FDDI (21) may be + used. + + + + + + + + + +Congdon, et al. Informational [Page 12] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +3.24. Port-Limit + + This attribute has no meaning when sent to an [IEEE8021X] + Authenticator. + +3.25. Password-Retry + + In IEEE 802.1X, the Authenticator always transitions to the HELD + state after an authentication failure. Thus this attribute does not + make sense for IEEE 802.1X. + +3.26. Connect-Info + + This attribute is sent by a bridge or Access Point to indicate the + nature of the Supplicant's connection. When sent in the Access- + Request it is recommended that this attribute contain information on + the speed of the Supplicant's connection. For 802.11, the following + format is recommended: "CONNECT 11Mbps 802.11b". If sent in the + Accounting STOP, this attribute may be used to summarize statistics + relating to session quality. For example, in IEEE 802.11, the + Connect-Info attribute may contain information on the number of link + layer retransmissions. The exact format of this attribute is + implementation specific. + +3.27. EAP-Message + + Since IEEE 802.1X provides for encapsulation of EAP as described in + [RFC2284] and [IEEE8021X], the EAP-Message attribute defined in + [RFC3579] is used to encapsulate EAP packets for transmission from + the IEEE 802.1X Authenticator to the Authentication Server. [RFC3579] + Section 2.2. describes how the Authentication Server handles invalid + EAP packets passed to it by the Authenticator. + +3.28. Message-Authenticator + + As noted in [RFC3579] Section 3.1., the Message-Authenticator + attribute MUST be used to protect packets within a RADIUS/EAP + conversation. + +3.29. NAS-Port-Id + + This attribute is used to identify the IEEE 802.1X Authenticator port + which authenticates the Supplicant. The NAS-Port-Id differs from the + NAS-Port in that it is a string of variable length whereas the NAS- + Port is a 4 octet value. + + + + + + +Congdon, et al. Informational [Page 13] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +3.30. Framed-Pool, Framed-IPv6-Pool + + IEEE 802.1X does not provide a mechanism for IP address assignment. + Therefore the Framed-Pool and Framed-IPv6-Pool attributes can only be + used by IEEE 802.1X Authenticators that support IP address assignment + mechanisms. Typically this capability is supported by layer 3 + devices. + +3.31. Tunnel Attributes + + Reference [RFC2868] defines RADIUS tunnel attributes used for + authentication and authorization, and [RFC2867] defines tunnel + attributes used for accounting. Where the IEEE 802.1X Authenticator + supports tunneling, a compulsory tunnel may be set up for the + Supplicant as a result of the authentication. + + In particular, it may be desirable to allow a port to be placed into + a particular Virtual LAN (VLAN), defined in [IEEE8021Q], based on the + result of the authentication. This can be used, for example, to + allow a wireless host to remain on the same VLAN as it moves within a + campus network. + + The RADIUS server typically indicates the desired VLAN by including + tunnel attributes within the Access-Accept. However, the IEEE 802.1X + Authenticator may also provide a hint as to the VLAN to be assigned + to the Supplicant by including Tunnel attributes within the Access- + Request. + + For use in VLAN assignment, the following tunnel attributes are used: + + Tunnel-Type=VLAN (13) + Tunnel-Medium-Type=802 + Tunnel-Private-Group-ID=VLANID + + Note that the VLANID is 12-bits, taking a value between 1 and 4094, + inclusive. Since the Tunnel-Private-Group-ID is of type String as + defined in [RFC2868], for use with IEEE 802.1X, the VLANID integer + value is encoded as a string. + + When Tunnel attributes are sent, it is necessary to fill in the Tag + field. As noted in [RFC2868], section 3.1: + + The Tag field is one octet in length and is intended to provide a + means of grouping attributes in the same packet which refer to the + same tunnel. Valid values for this field are 0x01 through 0x1F, + inclusive. If the Tag field is unused, it MUST be zero (0x00). + + + + + +Congdon, et al. Informational [Page 14] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, Tunnel- + Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-ID or + Tunnel-Server-Auth-ID attributes (but not Tunnel-Type, Tunnel- + Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag field of + greater than 0x1F is interpreted as the first octet of the following + field. + + Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X + Authenticators that may support tunneling but not VLANs), it is only + necessary for tunnel attributes to specify a single tunnel. As a + result, where it is only desired to specify the VLANID, the tag field + SHOULD be set to zero (0x00) in all tunnel attributes. Where + alternative tunnel types are to be provided, tag values between 0x01 + and 0x1F SHOULD be chosen. + +4. RC4 EAPOL-Key Frame + + The RC4 EAPOL-Key frame is created and transmitted by the + Authenticator in order to provide media specific key information. + For example, within 802.11 the RC4 EAPOL-Key frame can be used to + distribute multicast/broadcast ("default") keys, or unicast ("key + mapping") keys. The "default" key is the same for all Stations + within a broadcast domain. + + The RC4 EAPOL-Key frame is not acknowledged and therefore the + Authenticator does not know whether the Supplicant has received it. + If it is lost, then the Supplicant and Authenticator will not have + the same keying material, and communication will fail. If this + occurs, the problem is typically addressed by re-running the + authentication. + + The RC4 EAPOL-Key frame is sent from the Authenticator to the + Supplicant in order to provision the "default" key, and subsequently + in order to refresh the "default" key. It may also be used to + refresh the key-mapping key. Rekey is typically only required with + weak ciphersuites such as WEP, defined in [IEEE80211]. + + Where keys are required, an EAP method that derives keys is typically + selected. Therefore the initial "key mapping" keys can be derived + from EAP keying material, without requiring the Authenticator to send + an RC4 EAPOL-Key frame to the Supplicant. An example of how EAP + keying material can be derived and used is presented in [RFC2716]. + + + + + + + + + +Congdon, et al. Informational [Page 15] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + While the RC4 EAPOL-Key frame is defined in [IEEE8021X], a more + complete description is provided on the next page. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version | Packet Type | Packet Body Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Key Length |Replay Counter... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Replay Counter... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Replay Counter | Key IV... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key IV... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key IV... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key IV... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key IV... |F| Key Index | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Signature... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Signature... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Signature... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Signature... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Version + The Version field is one octet. For IEEE 802.1X, it contains the + value 0x01. + + Packet Type + The Packet Type field is one octet, and determines the type of + packet being transmitted. For an EAPOL-Key Descriptor, the Packet + Type field contains 0x03. + + Packet Body Length + The Packet Body Length is two octets, and contains the length of + the EAPOL-Key descriptor in octets, not including the Version, + Packet Type and Packet Body Length fields. + + + + + +Congdon, et al. Informational [Page 16] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + Type + The Type field is a single octet. The Key descriptor is defined + differently for each Type; this specification documents only the + RC4 Key Descriptor (Type = 0x01). + + Key Length + The Key Length field is two octets. If Packet Body Length = 44 + + Key Length, then the Key Field contains the key in encrypted form, + of length Key Length. This is 5 octets (40 bits) for WEP, and 13 + octets (104 bits) for WEP-128. If Packet Body Length = 44, then + the Key field is absent, and Key Length represents the number of + least significant octets from the MS-MPPE-Send-Key attribute + [RFC2548] to be used as the keying material. Note that the MS- + MPPE-Send-Key and MS-MPPE-Recv-Key attributes are defined from the + point of view of the Authenticator. From the Supplicant point of + reference, the terms are reversed. Thus the MS-MPPE-Recv-Key on + the Supplicant corresponds to the MS-MPPE-Send-Key on the + Authenticator, and the MS-MPPE-Send-Key on the Supplicant + corresponds to the MS-MPPE-Recv-Key on the Authenticator. + + Replay Counter + The Replay Counter field is 8 octets. It does not repeat within + the life of the keying material used to encrypt the Key field and + compute the Key Signature field. A 64-bit NTP timestamp MAY be + used as the Replay Counter. + + Key IV + The Key IV field is 16 octets and includes a 128-bit + cryptographically random number. + + F + The Key flag (F) is a single bit, describing the type of key that + is included in the Key field. Values are: + + 0 = for broadcast (default key) + 1 = for unicast (key mapping key) + + Key Index + The Key Index is 7 bits. + + Key Signature + The Key Signature field is 16 octets. It contains an HMAC-MD5 + message integrity check computed over the EAPOL-Key descriptor, + starting from the Version field, with the Key field filled in if + present, but with the Key Signature field set to zero. For the + computation, the 32 octet (256 bit) MS-MPPE-Send-Key [RFC2548] is + used as the HMAC-MD5 key. + + + + +Congdon, et al. Informational [Page 17] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + Key + If Packet Body Length = 44 + Key Length, then the Key Field + contains the key in encrypted form, of length Key Length. If + Packet Body Length = 44, then the Key field is absent, and the + least significant Key Length octets from the MS-MPPE-Send-Key + attribute is used as the keying material. Where the Key field is + encrypted using RC4, the RC4 encryption key used to encrypt this + field is formed by concatenating the 16 octet (128 bit) Key-IV + field with the 32 octet MS-MPPE-Recv-Key attribute. This yields a + 48 octet RC4 key (384 bits). + +5. Security Considerations + + Since this document describes the use of RADIUS for purposes of + authentication, authorization, and accounting in IEEE 802.1X-enabled + networks, it is vulnerable to all of the threats that are present in + other RADIUS applications. For a discussion of these threats, see + [RFC2607], [RFC2865], [RFC3162], [RFC3579], and [RFC3576]. + + Vulnerabilities include: + + Packet modification or forgery + Dictionary attacks + Known plaintext attacks + Replay + Outcome mismatches + 802.11 integration + Key management issues + +5.1. Packet Modification or Forgery + + RADIUS, defined in [RFC2865], does not require all Access-Requests to + be authenticated or integrity protected. However, IEEE 802.1X is + based on EAP. As described in [3579], Section 3.1.: + + The Message-Authenticator attribute MUST be used to protect all + Access-Request, Access-Challenge, Access-Accept, and Access-Reject + packets containing an EAP-Message attribute. + + As a result, when used with IEEE 802.1X, all RADIUS packets MUST be + authenticated and integrity protected. In addition, as described in + [3579], Section 4.2.: + + To address the security vulnerabilities of RADIUS/EAP, + implementations of this specification SHOULD support IPsec + [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP + [RFC2406] with non-null transform SHOULD be supported, and IPsec + ESP with a non-null encryption transform and authentication + + + +Congdon, et al. Informational [Page 18] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + support SHOULD be used to provide per-packet confidentiality, + authentication, integrity and replay protection. IKE SHOULD be + used for key management. + +5.2. Dictionary Attacks + + As discussed in [RFC3579] Section 4.3.3., the RADIUS shared secret is + vulnerable to offline dictionary attack, based on capture of the + Response Authenticator or Message-Authenticator attribute. In order + to decrease the level of vulnerability, [RFC2865], Section 3 + recommends: + + The secret (password shared between the client and the RADIUS + server) SHOULD be at least as large and unguessable as a well- + chosen password. It is preferred that the secret be at least 16 + octets. + + In addition, the risk of an offline dictionary attack can be further + mitigated by employing IPsec ESP with a non-null transform in order + to encrypt the RADIUS conversation, as described in [RFC3579], + Section 4.2. + +5.3. Known Plaintext Attacks + + Since IEEE 802.1X is based on EAP, which does not support PAP, the + RADIUS User-Password attribute is not used to carry hidden user + passwords. The hiding mechanism utilizes MD5, defined in [RFC1321], + in order to generate a key stream based on the RADIUS shared secret + and the Request Authenticator. Where PAP is in use, it is possible + to collect key streams corresponding to a given Request Authenticator + value, by capturing RADIUS conversations corresponding to a PAP + authentication attempt using a known password. Since the User- + Password is known, the key stream corresponding to a given Request + Authenticator can be determined and stored. + + The vulnerability is described in detail in [RFC3579], Section 4.3.4. + Even though IEEE 802.1X Authenticators do not support PAP + authentication, a security vulnerability can still exist where the + same RADIUS shared secret is used for hiding User-Password as well as + other attributes. This can occur, for example, if the same RADIUS + proxy handles authentication requests for both IEEE 802.1X (which may + hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-Recv-Key + attributes) and GPRS (which may hide the User-Password attribute). + + The threat can be mitigated by protecting RADIUS with IPsec ESP with + a non-null transform, as described in [RFC3579], Section 4.2. In + addition, the same RADIUS shared secret MUST NOT be used for both + IEEE 802.1X authentication and PAP authentication. + + + +Congdon, et al. Informational [Page 19] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +5.4. Replay + + As noted in [RFC3579] Section 4.3.5., the RADIUS protocol provides + only limited support for replay protection. Replay protection for + RADIUS authentication and accounting can be provided by enabling + IPsec replay protection with RADIUS, as described in [RFC3579], + Section 4.2. + + As with the Request Authenticator, for use with IEEE 802.1X + Authenticators, the Acct-Session-Id SHOULD be globally and temporally + unique. + +5.5. Outcome Mismatches + + [RFC3579] Section 2.6.3. discusses the issues that arise when the EAP + packet encapsulated in an EAP-Message attribute does not agree with + the RADIUS Packet Type. For example, an EAP Success packet might be + encapsulated within an Access-Reject; an EAP Failure might be sent + within an Access-Accept; or an EAP Success or Failure might be sent + within an Access-Challenge. + + As described in [RFC3579] Section 2.6.3., these conflicting messages + are likely to cause confusion. To ensure that access decisions made + by IEEE 802.1X Authenticators conform to the wishes of the RADIUS + server, it is necessary for the Authenticator to make the decision + solely based on the authentication result (Access-Accept/Reject) and + not based on the contents of EAP-Message attributes, if present. + +5.6. 802.11 Integration + + [IEEE8021X] was developed for use on wired IEEE 802 networks such as + Ethernet, and therefore does not describe how to securely adapt IEEE + 802.1X for use with 802.11. This is left to an enhanced security + specification under development within IEEE 802.11. + + For example, [IEEE8021X] does not specify whether authentication + occurs prior to, or after association, nor how the derived keys are + used within various ciphersuites. It also does not specify + ciphersuites addressing the vulnerabilities discovered in WEP, + described in [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl]. + [IEEE8021X] only defines an authentication framework, leaving the + definition of the authentication methods to other documents, such as + [RFC2716]. + + Since [IEEE8021X] does not address 802.11 integration issues, + implementors are strongly advised to consult additional IEEE 802.11 + security specifications for guidance on how to adapt IEEE 802.1X for + use with 802.11. For example, it is likely that the IEEE 802.11 + + + +Congdon, et al. Informational [Page 20] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + enhanced security specification will define its own IEEE 802.11 key + hierarchy as well as new EAPOL-Key descriptors. + +5.7. Key Management Issues + + The EAPOL-Key descriptor described in Section 4. is likely to be + deprecated in the future, when the IEEE 802.11 enhanced security + group completes its work. Known security issues include: + + [1] Default key-only support. IEEE 802.1X enables the derivation of + per-Station unicast keys, known in [IEEE80211] as "key mapping + keys." Keys used to encrypt multicast/broadcast traffic are + known as "default keys". However, in some 802.11 + implementations, the unicast keys, derived as part of the EAP + authentication process, are used solely in order to encrypt, + authenticate and integrity protect the EAPOL-Key descriptor, as + described in Section 4. These implementations only support use + of default keys (ordinarily only used with multicast/broadcast + traffic) to secure all traffic, unicast or multicast/broadcast, + resulting in inherent security weaknesses. + + Where per-Station key-mapping keys (e.g. unicast keys) are + unsupported, any Station possessing the default key can decrypt + traffic from other Stations or impersonate them. When used + along with a weak cipher (e.g. WEP), implementations supporting + only default keys provide more material for attacks such as + those described in [Fluhrer] and [Stubbl]. If in addition, the + default key is not refreshed periodically, IEEE 802.1X dynamic + key derivation provides little or no security benefit. For an + understanding of the issues with WEP, see [Berkeley], [Arbaugh], + [Fluhrer], and [Stubbl]. + + [2] Reuse of keying material. The EAPOL-Key descriptor specified in + section 4 uses the same keying material (MS-MPPE-Recv-Key) both + to encrypt the Key field within the EAPOL-Key descriptor, and to + encrypt data passed between the Station and Access Point. + Multi-purpose keying material is frowned upon, since multiple + uses can leak information helpful to an attacker. + + [3] Weak algorithms. The algorithm used to encrypt the Key field + within the EAPOL-Key descriptor is similar to the algorithm used + in WEP, and as a result, shares some of the same weaknesses. As + with WEP, the RC4 stream cipher is used to encrypt the key. As + input to the RC4 engine, the IV and key are concatenated rather + than being combined within a mixing function. As with WEP, the + IV is not a counter, and therefore there is little protection + against reuse. + + + + +Congdon, et al. Informational [Page 21] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + As a result of these vulnerabilities, implementors intending to use + the EAPOL-Key descriptor described in this document are urged to + consult the 802.11 enhanced security specification for a more secure + alternative. It is also advisable to consult the evolving literature + on WEP vulnerabilities, in order to better understand the risks, as + well as to obtain guidance on setting an appropriate re-keying + interval. + +6. IANA Considerations + + This specification does not create any RADIUS attributes nor any new + number spaces for IANA administration. However, it does require + assignment of new values to existing RADIUS attributes. These + include: + + Attribute Values Required + ========= =============== + NAS-Port-Type Token-Ring (20), FDDI (21) + Tunnel-Type VLAN (13) + Acct-Terminate-Cause Supplicant Restart (19) + Reauthentication Failure (20) + Port Reinitialized (21) + Port Administratively Disabled (22) + +7. References + +7.1. Normative References + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC + 1321, April 1992. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible + Authentication Protocol (EAP)", RFC 2284, March 1998. + + [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + + [RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting + Modifications for Tunnel Protocol Support", RFC 2867, + June 2000. + + + + + +Congdon, et al. Informational [Page 22] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., + Holdrege, M. and I. Goyret, "RADIUS Attributes for + Tunnel Protocol Support", RFC 2868, June 2000. + + [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS + Extensions", RFC 2869, June 2000. + + [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", + RFC 3162, August 2001. + + [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. + Aboba, "Dynamic Authorization Extensions to Remote + Authentication Dial In User Service (RADIUS)", RFC + 3576, July 2003. + + [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote + Authentication Dial In User Service) Support For + Extensible Authentication Protocol (EAP)", RFC 3579, + September 2003. + + [IEEE8021X] IEEE Standards for Local and Metropolitan Area + Networks: Port based Network Access Control, IEEE Std + 802.1X-2001, June 2001. + +7.2. Informative References + + [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, RFC + 2434, October 1998. + + [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS + Attributes", RFC 2548, March 1999. + + [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and + Policy Implementation in Roaming", RFC 2607, June + 1999. + + [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication + Protocol", RFC 2716, October 1999. + + + +Congdon, et al. Informational [Page 23] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent + Attack." CryptoBytes Vol.2 No.2, Summer 1996. + + [IEEE802] IEEE Standards for Local and Metropolitan Area + Networks: Overview and Architecture, ANSI/IEEE Std + 802, 1990. + + [IEEE8021Q] IEEE Standards for Local and Metropolitan Area + Networks: Draft Standard for Virtual Bridged Local + Area Networks, P802.1Q, January 1998. + + [IEEE8023] ISO/IEC 8802-3 Information technology - + Telecommunications and information exchange between + systems - Local and metropolitan area networks - + Common specifications - Part 3: Carrier Sense + Multiple Access with Collision Detection (CSMA/CD) + Access Method and Physical Layer Specifications, (also + ANSI/IEEE Std 802.3- 1996), 1996. + + [IEEE80211] Information technology - Telecommunications and + information exchange between systems - Local and + metropolitan area networks - Specific Requirements + Part 11: Wireless LAN Medium Access Control (MAC) and + Physical Layer (PHY) Specifications, IEEE Std. + 802.11-1999, 1999. + + [Berkeley] Borisov, N., Goldberg, I. and D. Wagner, "Intercepting + Mobile Communications: The Insecurity of 802.11", ACM + SIGMOBILE, Seventh Annual International Conference on + Mobile Computing and Networking, July 2001, Rome, + Italy. + + [Arbaugh] Arbaugh, W., Shankar, N. and J.Y.C. Wan, "Your 802.11 + Wireless Network has No Clothes", Department of + Computer Science, University of Maryland, College + Park, March 2001. + + [Fluhrer] Fluhrer, S., Mantin, I. and A. Shamir, "Weaknesses in + the Key Scheduling Algorithm of RC4", Eighth Annual + Workshop on Selected Areas in Cryptography, Toronto, + Canada, August 2001. + + [Stubbl] Stubblefield, A., Ioannidis, J. and A. Rubin, "Using + the Fluhrer, Mantin and Shamir Attack to Break WEP", + 2002 NDSS Conference. + + + + + + +Congdon, et al. Informational [Page 24] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +8. Table of Attributes + + The following table provides a guide to which attributes MAY be sent + and received as part of IEEE 802.1X authentication. L3 denotes + attributes that require layer 3 capabilities, and thus may not be + supported by all Authenticators. For each attribute, the reference + provides the definitive information on usage. + + 802.1X # Attribute + X 1 User-Name [RFC2865] + 2 User-Password [RFC2865] + 3 CHAP-Password [RFC2865] + X 4 NAS-IP-Address [RFC2865] + X 5 NAS-Port [RFC2865] + X 6 Service-Type [RFC2865] + 7 Framed-Protocol [RFC2865] + L3 8 Framed-IP-Address [RFC2865] + L3 9 Framed-IP-Netmask [RFC2865] + L3 10 Framed-Routing [RFC2865] + X 11 Filter-Id [RFC2865] + X 12 Framed-MTU [RFC2865] + 13 Framed-Compression [RFC2865] + L3 14 Login-IP-Host [RFC2865] + L3 15 Login-Service [RFC2865] + L3 16 Login-TCP-Port [RFC2865] + 18 Reply-Message [RFC2865] + 19 Callback-Number [RFC2865] + 20 Callback-Id [RFC2865] + L3 22 Framed-Route [RFC2865] + L3 23 Framed-IPX-Network [RFC2865] + X 24 State [RFC2865] + X 25 Class [RFC2865] + X 26 Vendor-Specific [RFC2865] + X 27 Session-Timeout [RFC2865] + X 28 Idle-Timeout [RFC2865] + X 29 Termination-Action [RFC2865] + X 30 Called-Station-Id [RFC2865] + X 31 Calling-Station-Id [RFC2865] + X 32 NAS-Identifier [RFC2865] + X 33 Proxy-State [RFC2865] + 34 Login-LAT-Service [RFC2865] + 35 Login-LAT-Node [RFC2865] + 36 Login-LAT-Group [RFC2865] + 802.1X # Attribute + + + + + + + +Congdon, et al. Informational [Page 25] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + 802.1X # Attribute + L3 37 Framed-AppleTalk-Link [RFC2865] + L3 38 Framed-AppleTalk-Network [RFC2865] + L3 39 Framed-AppleTalk-Zone [RFC2865] + X 40 Acct-Status-Type [RFC2866] + X 41 Acct-Delay-Time [RFC2866] + X 42 Acct-Input-Octets [RFC2866] + X 43 Acct-Output-Octets [RFC2866] + X 44 Acct-Session-Id [RFC2866] + X 45 Acct-Authentic [RFC2866] + X 46 Acct-Session-Time [RFC2866] + X 47 Acct-Input-Packets [RFC2866] + X 48 Acct-Output-Packets [RFC2866] + X 49 Acct-Terminate-Cause [RFC2866] + X 50 Acct-Multi-Session-Id [RFC2866] + X 51 Acct-Link-Count [RFC2866] + X 52 Acct-Input-Gigawords [RFC2869] + X 53 Acct-Output-Gigawords [RFC2869] + X 55 Event-Timestamp [RFC2869] + 60 CHAP-Challenge [RFC2865] + X 61 NAS-Port-Type [RFC2865] + 62 Port-Limit [RFC2865] + 63 Login-LAT-Port [RFC2865] + X 64 Tunnel-Type [RFC2868] + X 65 Tunnel-Medium-Type [RFC2868] + L3 66 Tunnel-Client-Endpoint [RFC2868] + L3 67 Tunnel-Server-Endpoint [RFC2868] + L3 68 Acct-Tunnel-Connection [RFC2867] + L3 69 Tunnel-Password [RFC2868] + 70 ARAP-Password [RFC2869] + 71 ARAP-Features [RFC2869] + 72 ARAP-Zone-Access [RFC2869] + 73 ARAP-Security [RFC2869] + 74 ARAP-Security-Data [RFC2869] + 75 Password-Retry [RFC2869] + 76 Prompt [RFC2869] + X 77 Connect-Info [RFC2869] + X 78 Configuration-Token [RFC2869] + X 79 EAP-Message [RFC3579] + X 80 Message-Authenticator [RFC3579] + X 81 Tunnel-Private-Group-ID [RFC2868] + L3 82 Tunnel-Assignment-ID [RFC2868] + X 83 Tunnel-Preference [RFC2868] + 84 ARAP-Challenge-Response [RFC2869] + 802.1X # Attribute + + + + + + +Congdon, et al. Informational [Page 26] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + 802.1X # Attribute + X 85 Acct-Interim-Interval [RFC2869] + X 86 Acct-Tunnel-Packets-Lost [RFC2867] + X 87 NAS-Port-Id [RFC2869] + L3 88 Framed-Pool [RFC2869] + L3 90 Tunnel-Client-Auth-ID [RFC2868] + L3 91 Tunnel-Server-Auth-ID [RFC2868] + X 95 NAS-IPv6-Address [RFC3162] + 96 Framed-Interface-Id [RFC3162] + L3 97 Framed-IPv6-Prefix [RFC3162] + L3 98 Login-IPv6-Host [RFC3162] + L3 99 Framed-IPv6-Route [RFC3162] + L3 100 Framed-IPv6-Pool [RFC3162] + X 101 Error-Cause [RFC3576] + 802.1X # Attribute + + Key + === + X = May be used with IEEE 802.1X authentication + L3 = Implemented only by Authenticators with Layer 3 + capabilities + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Congdon, et al. Informational [Page 27] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +9. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards- related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +10. Acknowledgments + + The authors would like to acknowledge Bob O'Hara of Airespace, David + Halasz of Cisco, Tim Moore, Sachin Seth and Ashwin Palekar of + Microsoft, Andrea Li, Albert Young and Dave Bagby of 3Com for + contributions to this document. + + + + + + + + + + + + + + + + + + + + + + + +Congdon, et al. Informational [Page 28] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +11. Authors' Addresses + + Paul Congdon + Hewlett Packard Company + HP ProCurve Networking + 8000 Foothills Blvd, M/S 5662 + Roseville, CA 95747 + + Phone: +1 916 785 5753 + Fax: +1 916 785 8478 + EMail: paul_congdon@hp.com + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 706 6605 + Fax: +1 425 936 7329 + EMail: bernarda@microsoft.com + + Andrew Smith + Trapeze Networks + 5753 W. Las Positas Blvd. + Pleasanton, CA 94588-4084 + + Fax: +1 415 345 1827 + EMail: ah_smith@acm.org + + John Roese + Enterasys + + Phone: +1 603 337 1506 + EMail: jjr@enterasys.com + + Glen Zorn + Cisco Systems, Inc. + 500 108th Avenue N.E., Suite 500 + Bellevue, WA 98004 + + Phone: +1 425 438 8218 + Fax: +1 425 438 1848 + EMail: gwz@cisco.com + + + + + + + + +Congdon, et al. Informational [Page 29] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Congdon, et al. Informational [Page 30] + diff --git a/rfc/rfc791.txt b/rfc/rfc791.txt new file mode 100644 index 00000000..5952d0b4 --- /dev/null +++ b/rfc/rfc791.txt @@ -0,0 +1,2887 @@ + + +RFC: 791 + + + + + + + + INTERNET PROTOCOL + + + DARPA INTERNET PROGRAM + + PROTOCOL SPECIFICATION + + + + September 1981 + + + + + + + + + + + + + + prepared for + + Defense Advanced Research Projects Agency + Information Processing Techniques Office + 1400 Wilson Boulevard + Arlington, Virginia 22209 + + + + + + + + by + + Information Sciences Institute + University of Southern California + 4676 Admiralty Way + Marina del Rey, California 90291 + + + +September 1981 + Internet Protocol + + + + TABLE OF CONTENTS + + PREFACE ........................................................ iii + +1. INTRODUCTION ..................................................... 1 + + 1.1 Motivation .................................................... 1 + 1.2 Scope ......................................................... 1 + 1.3 Interfaces .................................................... 1 + 1.4 Operation ..................................................... 2 + +2. OVERVIEW ......................................................... 5 + + 2.1 Relation to Other Protocols ................................... 9 + 2.2 Model of Operation ............................................ 5 + 2.3 Function Description .......................................... 7 + 2.4 Gateways ...................................................... 9 + +3. SPECIFICATION ................................................... 11 + + 3.1 Internet Header Format ....................................... 11 + 3.2 Discussion ................................................... 23 + 3.3 Interfaces ................................................... 31 + +APPENDIX A: Examples & Scenarios ................................... 34 +APPENDIX B: Data Transmission Order ................................ 39 + +GLOSSARY ............................................................ 41 + +REFERENCES .......................................................... 45 + + + + + + + + + + + + + + + + + + + + + + [Page i] + + + September 1981 +Internet Protocol + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page ii] + + +September 1981 + Internet Protocol + + + + PREFACE + + + +This document specifies the DoD Standard Internet Protocol. This +document is based on six earlier editions of the ARPA Internet Protocol +Specification, and the present text draws heavily from them. There have +been many contributors to this work both in terms of concepts and in +terms of text. This edition revises aspects of addressing, error +handling, option codes, and the security, precedence, compartments, and +handling restriction features of the internet protocol. + + Jon Postel + + Editor + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [Page iii] + + + + September 1981 + + +RFC: 791 +Replaces: RFC 760 +IENs 128, 123, 111, +80, 54, 44, 41, 28, 26 + + INTERNET PROTOCOL + + DARPA INTERNET PROGRAM + PROTOCOL SPECIFICATION + + + + 1. INTRODUCTION + +1.1. Motivation + + The Internet Protocol is designed for use in interconnected systems of + packet-switched computer communication networks. Such a system has + been called a "catenet" [1]. The internet protocol provides for + transmitting blocks of data called datagrams from sources to + destinations, where sources and destinations are hosts identified by + fixed length addresses. The internet protocol also provides for + fragmentation and reassembly of long datagrams, if necessary, for + transmission through "small packet" networks. + +1.2. Scope + + The internet protocol is specifically limited in scope to provide the + functions necessary to deliver a package of bits (an internet + datagram) from a source to a destination over an interconnected system + of networks. There are no mechanisms to augment end-to-end data + reliability, flow control, sequencing, or other services commonly + found in host-to-host protocols. The internet protocol can capitalize + on the services of its supporting networks to provide various types + and qualities of service. + +1.3. Interfaces + + This protocol is called on by host-to-host protocols in an internet + environment. This protocol calls on local network protocols to carry + the internet datagram to the next gateway or destination host. + + For example, a TCP module would call on the internet module to take a + TCP segment (including the TCP header and user data) as the data + portion of an internet datagram. The TCP module would provide the + addresses and other parameters in the internet header to the internet + module as arguments of the call. The internet module would then + create an internet datagram and call on the local network interface to + transmit the internet datagram. + + In the ARPANET case, for example, the internet module would call on a + + + [Page 1] + + + September 1981 +Internet Protocol +Introduction + + + + local net module which would add the 1822 leader [2] to the internet + datagram creating an ARPANET message to transmit to the IMP. The + ARPANET address would be derived from the internet address by the + local network interface and would be the address of some host in the + ARPANET, that host might be a gateway to other networks. + +1.4. Operation + + The internet protocol implements two basic functions: addressing and + fragmentation. + + The internet modules use the addresses carried in the internet header + to transmit internet datagrams toward their destinations. The + selection of a path for transmission is called routing. + + The internet modules use fields in the internet header to fragment and + reassemble internet datagrams when necessary for transmission through + "small packet" networks. + + The model of operation is that an internet module resides in each host + engaged in internet communication and in each gateway that + interconnects networks. These modules share common rules for + interpreting address fields and for fragmenting and assembling + internet datagrams. In addition, these modules (especially in + gateways) have procedures for making routing decisions and other + functions. + + The internet protocol treats each internet datagram as an independent + entity unrelated to any other internet datagram. There are no + connections or logical circuits (virtual or otherwise). + + The internet protocol uses four key mechanisms in providing its + service: Type of Service, Time to Live, Options, and Header Checksum. + + The Type of Service is used to indicate the quality of the service + desired. The type of service is an abstract or generalized set of + parameters which characterize the service choices provided in the + networks that make up the internet. This type of service indication + is to be used by gateways to select the actual transmission parameters + for a particular network, the network to be used for the next hop, or + the next gateway when routing an internet datagram. + + The Time to Live is an indication of an upper bound on the lifetime of + an internet datagram. It is set by the sender of the datagram and + reduced at the points along the route where it is processed. If the + time to live reaches zero before the internet datagram reaches its + destination, the internet datagram is destroyed. The time to live can + be thought of as a self destruct time limit. + + +[Page 2] + + +September 1981 + Internet Protocol + Introduction + + + + The Options provide for control functions needed or useful in some + situations but unnecessary for the most common communications. The + options include provisions for timestamps, security, and special + routing. + + The Header Checksum provides a verification that the information used + in processing internet datagram has been transmitted correctly. The + data may contain errors. If the header checksum fails, the internet + datagram is discarded at once by the entity which detects the error. + + The internet protocol does not provide a reliable communication + facility. There are no acknowledgments either end-to-end or + hop-by-hop. There is no error control for data, only a header + checksum. There are no retransmissions. There is no flow control. + + Errors detected may be reported via the Internet Control Message + Protocol (ICMP) [3] which is implemented in the internet protocol + module. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [Page 3] + + + September 1981 +Internet Protocol + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 4] + + +September 1981 + Internet Protocol + + + + 2. OVERVIEW + +2.1. Relation to Other Protocols + + The following diagram illustrates the place of the internet protocol + in the protocol hierarchy: + + + +------+ +-----+ +-----+ +-----+ + |Telnet| | FTP | | TFTP| ... | ... | + +------+ +-----+ +-----+ +-----+ + | | | | + +-----+ +-----+ +-----+ + | TCP | | UDP | ... | ... | + +-----+ +-----+ +-----+ + | | | + +--------------------------+----+ + | Internet Protocol & ICMP | + +--------------------------+----+ + | + +---------------------------+ + | Local Network Protocol | + +---------------------------+ + + Protocol Relationships + + Figure 1. + + Internet protocol interfaces on one side to the higher level + host-to-host protocols and on the other side to the local network + protocol. In this context a "local network" may be a small network in + a building or a large network such as the ARPANET. + +2.2. Model of Operation + + The model of operation for transmitting a datagram from one + application program to another is illustrated by the following + scenario: + + We suppose that this transmission will involve one intermediate + gateway. + + The sending application program prepares its data and calls on its + local internet module to send that data as a datagram and passes the + destination address and other parameters as arguments of the call. + + The internet module prepares a datagram header and attaches the data + to it. The internet module determines a local network address for + this internet address, in this case it is the address of a gateway. + + + [Page 5] + + + September 1981 +Internet Protocol +Overview + + + + It sends this datagram and the local network address to the local + network interface. + + The local network interface creates a local network header, and + attaches the datagram to it, then sends the result via the local + network. + + The datagram arrives at a gateway host wrapped in the local network + header, the local network interface strips off this header, and + turns the datagram over to the internet module. The internet module + determines from the internet address that the datagram is to be + forwarded to another host in a second network. The internet module + determines a local net address for the destination host. It calls + on the local network interface for that network to send the + datagram. + + This local network interface creates a local network header and + attaches the datagram sending the result to the destination host. + + At this destination host the datagram is stripped of the local net + header by the local network interface and handed to the internet + module. + + The internet module determines that the datagram is for an + application program in this host. It passes the data to the + application program in response to a system call, passing the source + address and other parameters as results of the call. + + + Application Application + Program Program + \ / + Internet Module Internet Module Internet Module + \ / \ / + LNI-1 LNI-1 LNI-2 LNI-2 + \ / \ / + Local Network 1 Local Network 2 + + + + Transmission Path + + Figure 2 + + + + + + + +[Page 6] + + +September 1981 + Internet Protocol + Overview + + + +2.3. Function Description + + The function or purpose of Internet Protocol is to move datagrams + through an interconnected set of networks. This is done by passing + the datagrams from one internet module to another until the + destination is reached. The internet modules reside in hosts and + gateways in the internet system. The datagrams are routed from one + internet module to another through individual networks based on the + interpretation of an internet address. Thus, one important mechanism + of the internet protocol is the internet address. + + In the routing of messages from one internet module to another, + datagrams may need to traverse a network whose maximum packet size is + smaller than the size of the datagram. To overcome this difficulty, a + fragmentation mechanism is provided in the internet protocol. + + Addressing + + A distinction is made between names, addresses, and routes [4]. A + name indicates what we seek. An address indicates where it is. A + route indicates how to get there. The internet protocol deals + primarily with addresses. It is the task of higher level (i.e., + host-to-host or application) protocols to make the mapping from + names to addresses. The internet module maps internet addresses to + local net addresses. It is the task of lower level (i.e., local net + or gateways) procedures to make the mapping from local net addresses + to routes. + + Addresses are fixed length of four octets (32 bits). An address + begins with a network number, followed by local address (called the + "rest" field). There are three formats or classes of internet + addresses: in class a, the high order bit is zero, the next 7 bits + are the network, and the last 24 bits are the local address; in + class b, the high order two bits are one-zero, the next 14 bits are + the network and the last 16 bits are the local address; in class c, + the high order three bits are one-one-zero, the next 21 bits are the + network and the last 8 bits are the local address. + + Care must be taken in mapping internet addresses to local net + addresses; a single physical host must be able to act as if it were + several distinct hosts to the extent of using several distinct + internet addresses. Some hosts will also have several physical + interfaces (multi-homing). + + That is, provision must be made for a host to have several physical + interfaces to the network with each having several logical internet + addresses. + + + + [Page 7] + + + September 1981 +Internet Protocol +Overview + + + + Examples of address mappings may be found in "Address Mappings" [5]. + + Fragmentation + + Fragmentation of an internet datagram is necessary when it + originates in a local net that allows a large packet size and must + traverse a local net that limits packets to a smaller size to reach + its destination. + + An internet datagram can be marked "don't fragment." Any internet + datagram so marked is not to be internet fragmented under any + circumstances. If internet datagram marked don't fragment cannot be + delivered to its destination without fragmenting it, it is to be + discarded instead. + + Fragmentation, transmission and reassembly across a local network + which is invisible to the internet protocol module is called + intranet fragmentation and may be used [6]. + + The internet fragmentation and reassembly procedure needs to be able + to break a datagram into an almost arbitrary number of pieces that + can be later reassembled. The receiver of the fragments uses the + identification field to ensure that fragments of different datagrams + are not mixed. The fragment offset field tells the receiver the + position of a fragment in the original datagram. The fragment + offset and length determine the portion of the original datagram + covered by this fragment. The more-fragments flag indicates (by + being reset) the last fragment. These fields provide sufficient + information to reassemble datagrams. + + The identification field is used to distinguish the fragments of one + datagram from those of another. The originating protocol module of + an internet datagram sets the identification field to a value that + must be unique for that source-destination pair and protocol for the + time the datagram will be active in the internet system. The + originating protocol module of a complete datagram sets the + more-fragments flag to zero and the fragment offset to zero. + + To fragment a long internet datagram, an internet protocol module + (for example, in a gateway), creates two new internet datagrams and + copies the contents of the internet header fields from the long + datagram into both new internet headers. The data of the long + datagram is divided into two portions on a 8 octet (64 bit) boundary + (the second portion might not be an integral multiple of 8 octets, + but the first must be). Call the number of 8 octet blocks in the + first portion NFB (for Number of Fragment Blocks). The first + portion of the data is placed in the first new internet datagram, + and the total length field is set to the length of the first + + +[Page 8] + + +September 1981 + Internet Protocol + Overview + + + + datagram. The more-fragments flag is set to one. The second + portion of the data is placed in the second new internet datagram, + and the total length field is set to the length of the second + datagram. The more-fragments flag carries the same value as the + long datagram. The fragment offset field of the second new internet + datagram is set to the value of that field in the long datagram plus + NFB. + + This procedure can be generalized for an n-way split, rather than + the two-way split described. + + To assemble the fragments of an internet datagram, an internet + protocol module (for example at a destination host) combines + internet datagrams that all have the same value for the four fields: + identification, source, destination, and protocol. The combination + is done by placing the data portion of each fragment in the relative + position indicated by the fragment offset in that fragment's + internet header. The first fragment will have the fragment offset + zero, and the last fragment will have the more-fragments flag reset + to zero. + +2.4. Gateways + + Gateways implement internet protocol to forward datagrams between + networks. Gateways also implement the Gateway to Gateway Protocol + (GGP) [7] to coordinate routing and other internet control + information. + + In a gateway the higher level protocols need not be implemented and + the GGP functions are added to the IP module. + + + +-------------------------------+ + | Internet Protocol & ICMP & GGP| + +-------------------------------+ + | | + +---------------+ +---------------+ + | Local Net | | Local Net | + +---------------+ +---------------+ + + Gateway Protocols + + Figure 3. + + + + + + + + [Page 9] + + + September 1981 +Internet Protocol + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 10] + + +September 1981 + Internet Protocol + + + + 3. SPECIFICATION + +3.1. Internet Header Format + + A summary of the contents of the internet header follows: + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Version| IHL |Type of Service| Total Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identification |Flags| Fragment Offset | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Time to Live | Protocol | Header Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options | Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Example Internet Datagram Header + + Figure 4. + + Note that each tick mark represents one bit position. + + Version: 4 bits + + The Version field indicates the format of the internet header. This + document describes version 4. + + IHL: 4 bits + + Internet Header Length is the length of the internet header in 32 + bit words, and thus points to the beginning of the data. Note that + the minimum value for a correct header is 5. + + + + + + + + + + + + + [Page 11] + + + September 1981 +Internet Protocol +Specification + + + + Type of Service: 8 bits + + The Type of Service provides an indication of the abstract + parameters of the quality of service desired. These parameters are + to be used to guide the selection of the actual service parameters + when transmitting a datagram through a particular network. Several + networks offer service precedence, which somehow treats high + precedence traffic as more important than other traffic (generally + by accepting only traffic above a certain precedence at time of high + load). The major choice is a three way tradeoff between low-delay, + high-reliability, and high-throughput. + + Bits 0-2: Precedence. + Bit 3: 0 = Normal Delay, 1 = Low Delay. + Bits 4: 0 = Normal Throughput, 1 = High Throughput. + Bits 5: 0 = Normal Relibility, 1 = High Relibility. + Bit 6-7: Reserved for Future Use. + + 0 1 2 3 4 5 6 7 + +-----+-----+-----+-----+-----+-----+-----+-----+ + | | | | | | | + | PRECEDENCE | D | T | R | 0 | 0 | + | | | | | | | + +-----+-----+-----+-----+-----+-----+-----+-----+ + + Precedence + + 111 - Network Control + 110 - Internetwork Control + 101 - CRITIC/ECP + 100 - Flash Override + 011 - Flash + 010 - Immediate + 001 - Priority + 000 - Routine + + The use of the Delay, Throughput, and Reliability indications may + increase the cost (in some sense) of the service. In many networks + better performance for one of these parameters is coupled with worse + performance on another. Except for very unusual cases at most two + of these three indications should be set. + + The type of service is used to specify the treatment of the datagram + during its transmission through the internet system. Example + mappings of the internet type of service to the actual service + provided on networks such as AUTODIN II, ARPANET, SATNET, and PRNET + is given in "Service Mappings" [8]. + + + +[Page 12] + + +September 1981 + Internet Protocol + Specification + + + + The Network Control precedence designation is intended to be used + within a network only. The actual use and control of that + designation is up to each network. The Internetwork Control + designation is intended for use by gateway control originators only. + If the actual use of these precedence designations is of concern to + a particular network, it is the responsibility of that network to + control the access to, and use of, those precedence designations. + + Total Length: 16 bits + + Total Length is the length of the datagram, measured in octets, + including internet header and data. This field allows the length of + a datagram to be up to 65,535 octets. Such long datagrams are + impractical for most hosts and networks. All hosts must be prepared + to accept datagrams of up to 576 octets (whether they arrive whole + or in fragments). It is recommended that hosts only send datagrams + larger than 576 octets if they have assurance that the destination + is prepared to accept the larger datagrams. + + The number 576 is selected to allow a reasonable sized data block to + be transmitted in addition to the required header information. For + example, this size allows a data block of 512 octets plus 64 header + octets to fit in a datagram. The maximal internet header is 60 + octets, and a typical internet header is 20 octets, allowing a + margin for headers of higher level protocols. + + Identification: 16 bits + + An identifying value assigned by the sender to aid in assembling the + fragments of a datagram. + + Flags: 3 bits + + Various Control Flags. + + Bit 0: reserved, must be zero + Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. + Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. + + 0 1 2 + +---+---+---+ + | | D | M | + | 0 | F | F | + +---+---+---+ + + Fragment Offset: 13 bits + + This field indicates where in the datagram this fragment belongs. + + + [Page 13] + + + September 1981 +Internet Protocol +Specification + + + + The fragment offset is measured in units of 8 octets (64 bits). The + first fragment has offset zero. + + Time to Live: 8 bits + + This field indicates the maximum time the datagram is allowed to + remain in the internet system. If this field contains the value + zero, then the datagram must be destroyed. This field is modified + in internet header processing. The time is measured in units of + seconds, but since every module that processes a datagram must + decrease the TTL by at least one even if it process the datagram in + less than a second, the TTL must be thought of only as an upper + bound on the time a datagram may exist. The intention is to cause + undeliverable datagrams to be discarded, and to bound the maximum + datagram lifetime. + + Protocol: 8 bits + + This field indicates the next level protocol used in the data + portion of the internet datagram. The values for various protocols + are specified in "Assigned Numbers" [9]. + + Header Checksum: 16 bits + + A checksum on the header only. Since some header fields change + (e.g., time to live), this is recomputed and verified at each point + that the internet header is processed. + + The checksum algorithm is: + + The checksum field is the 16 bit one's complement of the one's + complement sum of all 16 bit words in the header. For purposes of + computing the checksum, the value of the checksum field is zero. + + This is a simple to compute checksum and experimental evidence + indicates it is adequate, but it is provisional and may be replaced + by a CRC procedure, depending on further experience. + + Source Address: 32 bits + + The source address. See section 3.2. + + Destination Address: 32 bits + + The destination address. See section 3.2. + + + + + +[Page 14] + + +September 1981 + Internet Protocol + Specification + + + + Options: variable + + The options may appear or not in datagrams. They must be + implemented by all IP modules (host and gateways). What is optional + is their transmission in any particular datagram, not their + implementation. + + In some environments the security option may be required in all + datagrams. + + The option field is variable in length. There may be zero or more + options. There are two cases for the format of an option: + + Case 1: A single octet of option-type. + + Case 2: An option-type octet, an option-length octet, and the + actual option-data octets. + + The option-length octet counts the option-type octet and the + option-length octet as well as the option-data octets. + + The option-type octet is viewed as having 3 fields: + + 1 bit copied flag, + 2 bits option class, + 5 bits option number. + + The copied flag indicates that this option is copied into all + fragments on fragmentation. + + 0 = not copied + 1 = copied + + The option classes are: + + 0 = control + 1 = reserved for future use + 2 = debugging and measurement + 3 = reserved for future use + + + + + + + + + + + + [Page 15] + + + September 1981 +Internet Protocol +Specification + + + + The following internet options are defined: + + CLASS NUMBER LENGTH DESCRIPTION + ----- ------ ------ ----------- + 0 0 - End of Option list. This option occupies only + 1 octet; it has no length octet. + 0 1 - No Operation. This option occupies only 1 + octet; it has no length octet. + 0 2 11 Security. Used to carry Security, + Compartmentation, User Group (TCC), and + Handling Restriction Codes compatible with DOD + requirements. + 0 3 var. Loose Source Routing. Used to route the + internet datagram based on information + supplied by the source. + 0 9 var. Strict Source Routing. Used to route the + internet datagram based on information + supplied by the source. + 0 7 var. Record Route. Used to trace the route an + internet datagram takes. + 0 8 4 Stream ID. Used to carry the stream + identifier. + 2 4 var. Internet Timestamp. + + + + Specific Option Definitions + + End of Option List + + +--------+ + |00000000| + +--------+ + Type=0 + + This option indicates the end of the option list. This might + not coincide with the end of the internet header according to + the internet header length. This is used at the end of all + options, not the end of each option, and need only be used if + the end of the options would not otherwise coincide with the end + of the internet header. + + May be copied, introduced, or deleted on fragmentation, or for + any other reason. + + + + + + +[Page 16] + + +September 1981 + Internet Protocol + Specification + + + + No Operation + + +--------+ + |00000001| + +--------+ + Type=1 + + This option may be used between options, for example, to align + the beginning of a subsequent option on a 32 bit boundary. + + May be copied, introduced, or deleted on fragmentation, or for + any other reason. + + Security + + This option provides a way for hosts to send security, + compartmentation, handling restrictions, and TCC (closed user + group) parameters. The format for this option is as follows: + + +--------+--------+---//---+---//---+---//---+---//---+ + |10000010|00001011|SSS SSS|CCC CCC|HHH HHH| TCC | + +--------+--------+---//---+---//---+---//---+---//---+ + Type=130 Length=11 + + Security (S field): 16 bits + + Specifies one of 16 levels of security (eight of which are + reserved for future use). + + 00000000 00000000 - Unclassified + 11110001 00110101 - Confidential + 01111000 10011010 - EFTO + 10111100 01001101 - MMMM + 01011110 00100110 - PROG + 10101111 00010011 - Restricted + 11010111 10001000 - Secret + 01101011 11000101 - Top Secret + 00110101 11100010 - (Reserved for future use) + 10011010 11110001 - (Reserved for future use) + 01001101 01111000 - (Reserved for future use) + 00100100 10111101 - (Reserved for future use) + 00010011 01011110 - (Reserved for future use) + 10001001 10101111 - (Reserved for future use) + 11000100 11010110 - (Reserved for future use) + 11100010 01101011 - (Reserved for future use) + + + + + + [Page 17] + + + September 1981 +Internet Protocol +Specification + + + + Compartments (C field): 16 bits + + An all zero value is used when the information transmitted is + not compartmented. Other values for the compartments field + may be obtained from the Defense Intelligence Agency. + + Handling Restrictions (H field): 16 bits + + The values for the control and release markings are + alphanumeric digraphs and are defined in the Defense + Intelligence Agency Manual DIAM 65-19, "Standard Security + Markings". + + Transmission Control Code (TCC field): 24 bits + + Provides a means to segregate traffic and define controlled + communities of interest among subscribers. The TCC values are + trigraphs, and are available from HQ DCA Code 530. + + Must be copied on fragmentation. This option appears at most + once in a datagram. + + Loose Source and Record Route + + +--------+--------+--------+---------//--------+ + |10000011| length | pointer| route data | + +--------+--------+--------+---------//--------+ + Type=131 + + The loose source and record route (LSRR) option provides a means + for the source of an internet datagram to supply routing + information to be used by the gateways in forwarding the + datagram to the destination, and to record the route + information. + + The option begins with the option type code. The second octet + is the option length which includes the option type code and the + length octet, the pointer octet, and length-3 octets of route + data. The third octet is the pointer into the route data + indicating the octet which begins the next source address to be + processed. The pointer is relative to this option, and the + smallest legal value for the pointer is 4. + + A route data is composed of a series of internet addresses. + Each internet address is 32 bits or 4 octets. If the pointer is + greater than the length, the source route is empty (and the + recorded route full) and the routing is to be based on the + destination address field. + + +[Page 18] + + +September 1981 + Internet Protocol + Specification + + + + If the address in destination address field has been reached and + the pointer is not greater than the length, the next address in + the source route replaces the address in the destination address + field, and the recorded route address replaces the source + address just used, and pointer is increased by four. + + The recorded route address is the internet module's own internet + address as known in the environment into which this datagram is + being forwarded. + + This procedure of replacing the source route with the recorded + route (though it is in the reverse of the order it must be in to + be used as a source route) means the option (and the IP header + as a whole) remains a constant length as the datagram progresses + through the internet. + + This option is a loose source route because the gateway or host + IP is allowed to use any route of any number of other + intermediate gateways to reach the next address in the route. + + Must be copied on fragmentation. Appears at most once in a + datagram. + + Strict Source and Record Route + + +--------+--------+--------+---------//--------+ + |10001001| length | pointer| route data | + +--------+--------+--------+---------//--------+ + Type=137 + + The strict source and record route (SSRR) option provides a + means for the source of an internet datagram to supply routing + information to be used by the gateways in forwarding the + datagram to the destination, and to record the route + information. + + The option begins with the option type code. The second octet + is the option length which includes the option type code and the + length octet, the pointer octet, and length-3 octets of route + data. The third octet is the pointer into the route data + indicating the octet which begins the next source address to be + processed. The pointer is relative to this option, and the + smallest legal value for the pointer is 4. + + A route data is composed of a series of internet addresses. + Each internet address is 32 bits or 4 octets. If the pointer is + greater than the length, the source route is empty (and the + + + + [Page 19] + + + September 1981 +Internet Protocol +Specification + + + + recorded route full) and the routing is to be based on the + destination address field. + + If the address in destination address field has been reached and + the pointer is not greater than the length, the next address in + the source route replaces the address in the destination address + field, and the recorded route address replaces the source + address just used, and pointer is increased by four. + + The recorded route address is the internet module's own internet + address as known in the environment into which this datagram is + being forwarded. + + This procedure of replacing the source route with the recorded + route (though it is in the reverse of the order it must be in to + be used as a source route) means the option (and the IP header + as a whole) remains a constant length as the datagram progresses + through the internet. + + This option is a strict source route because the gateway or host + IP must send the datagram directly to the next address in the + source route through only the directly connected network + indicated in the next address to reach the next gateway or host + specified in the route. + + Must be copied on fragmentation. Appears at most once in a + datagram. + + Record Route + + +--------+--------+--------+---------//--------+ + |00000111| length | pointer| route data | + +--------+--------+--------+---------//--------+ + Type=7 + + The record route option provides a means to record the route of + an internet datagram. + + The option begins with the option type code. The second octet + is the option length which includes the option type code and the + length octet, the pointer octet, and length-3 octets of route + data. The third octet is the pointer into the route data + indicating the octet which begins the next area to store a route + address. The pointer is relative to this option, and the + smallest legal value for the pointer is 4. + + A recorded route is composed of a series of internet addresses. + Each internet address is 32 bits or 4 octets. If the pointer is + + +[Page 20] + + +September 1981 + Internet Protocol + Specification + + + + greater than the length, the recorded route data area is full. + The originating host must compose this option with a large + enough route data area to hold all the address expected. The + size of the option does not change due to adding addresses. The + intitial contents of the route data area must be zero. + + When an internet module routes a datagram it checks to see if + the record route option is present. If it is, it inserts its + own internet address as known in the environment into which this + datagram is being forwarded into the recorded route begining at + the octet indicated by the pointer, and increments the pointer + by four. + + If the route data area is already full (the pointer exceeds the + length) the datagram is forwarded without inserting the address + into the recorded route. If there is some room but not enough + room for a full address to be inserted, the original datagram is + considered to be in error and is discarded. In either case an + ICMP parameter problem message may be sent to the source + host [3]. + + Not copied on fragmentation, goes in first fragment only. + Appears at most once in a datagram. + + Stream Identifier + + +--------+--------+--------+--------+ + |10001000|00000010| Stream ID | + +--------+--------+--------+--------+ + Type=136 Length=4 + + This option provides a way for the 16-bit SATNET stream + identifier to be carried through networks that do not support + the stream concept. + + Must be copied on fragmentation. Appears at most once in a + datagram. + + + + + + + + + + + + + + [Page 21] + + + September 1981 +Internet Protocol +Specification + + + + Internet Timestamp + + +--------+--------+--------+--------+ + |01000100| length | pointer|oflw|flg| + +--------+--------+--------+--------+ + | internet address | + +--------+--------+--------+--------+ + | timestamp | + +--------+--------+--------+--------+ + | . | + . + . + Type = 68 + + The Option Length is the number of octets in the option counting + the type, length, pointer, and overflow/flag octets (maximum + length 40). + + The Pointer is the number of octets from the beginning of this + option to the end of timestamps plus one (i.e., it points to the + octet beginning the space for next timestamp). The smallest + legal value is 5. The timestamp area is full when the pointer + is greater than the length. + + The Overflow (oflw) [4 bits] is the number of IP modules that + cannot register timestamps due to lack of space. + + The Flag (flg) [4 bits] values are + + 0 -- time stamps only, stored in consecutive 32-bit words, + + 1 -- each timestamp is preceded with internet address of the + registering entity, + + 3 -- the internet address fields are prespecified. An IP + module only registers its timestamp if it matches its own + address with the next specified internet address. + + The Timestamp is a right-justified, 32-bit timestamp in + milliseconds since midnight UT. If the time is not available in + milliseconds or cannot be provided with respect to midnight UT + then any time may be inserted as a timestamp provided the high + order bit of the timestamp field is set to one to indicate the + use of a non-standard value. + + The originating host must compose this option with a large + enough timestamp data area to hold all the timestamp information + expected. The size of the option does not change due to adding + + +[Page 22] + + +September 1981 + Internet Protocol + Specification + + + + timestamps. The intitial contents of the timestamp data area + must be zero or internet address/zero pairs. + + If the timestamp data area is already full (the pointer exceeds + the length) the datagram is forwarded without inserting the + timestamp, but the overflow count is incremented by one. + + If there is some room but not enough room for a full timestamp + to be inserted, or the overflow count itself overflows, the + original datagram is considered to be in error and is discarded. + In either case an ICMP parameter problem message may be sent to + the source host [3]. + + The timestamp option is not copied upon fragmentation. It is + carried in the first fragment. Appears at most once in a + datagram. + + Padding: variable + + The internet header padding is used to ensure that the internet + header ends on a 32 bit boundary. The padding is zero. + +3.2. Discussion + + The implementation of a protocol must be robust. Each implementation + must expect to interoperate with others created by different + individuals. While the goal of this specification is to be explicit + about the protocol there is the possibility of differing + interpretations. In general, an implementation must be conservative + in its sending behavior, and liberal in its receiving behavior. That + is, it must be careful to send well-formed datagrams, but must accept + any datagram that it can interpret (e.g., not object to technical + errors where the meaning is still clear). + + The basic internet service is datagram oriented and provides for the + fragmentation of datagrams at gateways, with reassembly taking place + at the destination internet protocol module in the destination host. + Of course, fragmentation and reassembly of datagrams within a network + or by private agreement between the gateways of a network is also + allowed since this is transparent to the internet protocols and the + higher-level protocols. This transparent type of fragmentation and + reassembly is termed "network-dependent" (or intranet) fragmentation + and is not discussed further here. + + Internet addresses distinguish sources and destinations to the host + level and provide a protocol field as well. It is assumed that each + protocol will provide for whatever multiplexing is necessary within a + host. + + + [Page 23] + + + September 1981 +Internet Protocol +Specification + + + + Addressing + + To provide for flexibility in assigning address to networks and + allow for the large number of small to intermediate sized networks + the interpretation of the address field is coded to specify a small + number of networks with a large number of host, a moderate number of + networks with a moderate number of hosts, and a large number of + networks with a small number of hosts. In addition there is an + escape code for extended addressing mode. + + Address Formats: + + High Order Bits Format Class + --------------- ------------------------------- ----- + 0 7 bits of net, 24 bits of host a + 10 14 bits of net, 16 bits of host b + 110 21 bits of net, 8 bits of host c + 111 escape to extended addressing mode + + A value of zero in the network field means this network. This is + only used in certain ICMP messages. The extended addressing mode + is undefined. Both of these features are reserved for future use. + + The actual values assigned for network addresses is given in + "Assigned Numbers" [9]. + + The local address, assigned by the local network, must allow for a + single physical host to act as several distinct internet hosts. + That is, there must be a mapping between internet host addresses and + network/host interfaces that allows several internet addresses to + correspond to one interface. It must also be allowed for a host to + have several physical interfaces and to treat the datagrams from + several of them as if they were all addressed to a single host. + + Address mappings between internet addresses and addresses for + ARPANET, SATNET, PRNET, and other networks are described in "Address + Mappings" [5]. + + Fragmentation and Reassembly. + + The internet identification field (ID) is used together with the + source and destination address, and the protocol fields, to identify + datagram fragments for reassembly. + + The More Fragments flag bit (MF) is set if the datagram is not the + last fragment. The Fragment Offset field identifies the fragment + location, relative to the beginning of the original unfragmented + datagram. Fragments are counted in units of 8 octets. The + + +[Page 24] + + +September 1981 + Internet Protocol + Specification + + + + fragmentation strategy is designed so than an unfragmented datagram + has all zero fragmentation information (MF = 0, fragment offset = + 0). If an internet datagram is fragmented, its data portion must be + broken on 8 octet boundaries. + + This format allows 2**13 = 8192 fragments of 8 octets each for a + total of 65,536 octets. Note that this is consistent with the the + datagram total length field (of course, the header is counted in the + total length and not in the fragments). + + When fragmentation occurs, some options are copied, but others + remain with the first fragment only. + + Every internet module must be able to forward a datagram of 68 + octets without further fragmentation. This is because an internet + header may be up to 60 octets, and the minimum fragment is 8 octets. + + Every internet destination must be able to receive a datagram of 576 + octets either in one piece or in fragments to be reassembled. + + The fields which may be affected by fragmentation include: + + (1) options field + (2) more fragments flag + (3) fragment offset + (4) internet header length field + (5) total length field + (6) header checksum + + If the Don't Fragment flag (DF) bit is set, then internet + fragmentation of this datagram is NOT permitted, although it may be + discarded. This can be used to prohibit fragmentation in cases + where the receiving host does not have sufficient resources to + reassemble internet fragments. + + One example of use of the Don't Fragment feature is to down line + load a small host. A small host could have a boot strap program + that accepts a datagram stores it in memory and then executes it. + + The fragmentation and reassembly procedures are most easily + described by examples. The following procedures are example + implementations. + + General notation in the following pseudo programs: "=<" means "less + than or equal", "#" means "not equal", "=" means "equal", "<-" means + "is set to". Also, "x to y" includes x and excludes y; for example, + "4 to 7" would include 4, 5, and 6 (but not 7). + + + + [Page 25] + + + September 1981 +Internet Protocol +Specification + + + + An Example Fragmentation Procedure + + The maximum sized datagram that can be transmitted through the + next network is called the maximum transmission unit (MTU). + + If the total length is less than or equal the maximum transmission + unit then submit this datagram to the next step in datagram + processing; otherwise cut the datagram into two fragments, the + first fragment being the maximum size, and the second fragment + being the rest of the datagram. The first fragment is submitted + to the next step in datagram processing, while the second fragment + is submitted to this procedure in case it is still too large. + + Notation: + + FO - Fragment Offset + IHL - Internet Header Length + DF - Don't Fragment flag + MF - More Fragments flag + TL - Total Length + OFO - Old Fragment Offset + OIHL - Old Internet Header Length + OMF - Old More Fragments flag + OTL - Old Total Length + NFB - Number of Fragment Blocks + MTU - Maximum Transmission Unit + + Procedure: + + IF TL =< MTU THEN Submit this datagram to the next step + in datagram processing ELSE IF DF = 1 THEN discard the + datagram ELSE + To produce the first fragment: + (1) Copy the original internet header; + (2) OIHL <- IHL; OTL <- TL; OFO <- FO; OMF <- MF; + (3) NFB <- (MTU-IHL*4)/8; + (4) Attach the first NFB*8 data octets; + (5) Correct the header: + MF <- 1; TL <- (IHL*4)+(NFB*8); + Recompute Checksum; + (6) Submit this fragment to the next step in + datagram processing; + To produce the second fragment: + (7) Selectively copy the internet header (some options + are not copied, see option definitions); + (8) Append the remaining data; + (9) Correct the header: + IHL <- (((OIHL*4)-(length of options not copied))+3)/4; + + +[Page 26] + + +September 1981 + Internet Protocol + Specification + + + + TL <- OTL - NFB*8 - (OIHL-IHL)*4); + FO <- OFO + NFB; MF <- OMF; Recompute Checksum; + (10) Submit this fragment to the fragmentation test; DONE. + + In the above procedure each fragment (except the last) was made + the maximum allowable size. An alternative might produce less + than the maximum size datagrams. For example, one could implement + a fragmentation procedure that repeatly divided large datagrams in + half until the resulting fragments were less than the maximum + transmission unit size. + + An Example Reassembly Procedure + + For each datagram the buffer identifier is computed as the + concatenation of the source, destination, protocol, and + identification fields. If this is a whole datagram (that is both + the fragment offset and the more fragments fields are zero), then + any reassembly resources associated with this buffer identifier + are released and the datagram is forwarded to the next step in + datagram processing. + + If no other fragment with this buffer identifier is on hand then + reassembly resources are allocated. The reassembly resources + consist of a data buffer, a header buffer, a fragment block bit + table, a total data length field, and a timer. The data from the + fragment is placed in the data buffer according to its fragment + offset and length, and bits are set in the fragment block bit + table corresponding to the fragment blocks received. + + If this is the first fragment (that is the fragment offset is + zero) this header is placed in the header buffer. If this is the + last fragment ( that is the more fragments field is zero) the + total data length is computed. If this fragment completes the + datagram (tested by checking the bits set in the fragment block + table), then the datagram is sent to the next step in datagram + processing; otherwise the timer is set to the maximum of the + current timer value and the value of the time to live field from + this fragment; and the reassembly routine gives up control. + + If the timer runs out, the all reassembly resources for this + buffer identifier are released. The initial setting of the timer + is a lower bound on the reassembly waiting time. This is because + the waiting time will be increased if the Time to Live in the + arriving fragment is greater than the current timer value but will + not be decreased if it is less. The maximum this timer value + could reach is the maximum time to live (approximately 4.25 + minutes). The current recommendation for the initial timer + setting is 15 seconds. This may be changed as experience with + + + [Page 27] + + + September 1981 +Internet Protocol +Specification + + + + this protocol accumulates. Note that the choice of this parameter + value is related to the buffer capacity available and the data + rate of the transmission medium; that is, data rate times timer + value equals buffer size (e.g., 10Kb/s X 15s = 150Kb). + + Notation: + + FO - Fragment Offset + IHL - Internet Header Length + MF - More Fragments flag + TTL - Time To Live + NFB - Number of Fragment Blocks + TL - Total Length + TDL - Total Data Length + BUFID - Buffer Identifier + RCVBT - Fragment Received Bit Table + TLB - Timer Lower Bound + + Procedure: + + (1) BUFID <- source|destination|protocol|identification; + (2) IF FO = 0 AND MF = 0 + (3) THEN IF buffer with BUFID is allocated + (4) THEN flush all reassembly for this BUFID; + (5) Submit datagram to next step; DONE. + (6) ELSE IF no buffer with BUFID is allocated + (7) THEN allocate reassembly resources + with BUFID; + TIMER <- TLB; TDL <- 0; + (8) put data from fragment into data buffer with + BUFID from octet FO*8 to + octet (TL-(IHL*4))+FO*8; + (9) set RCVBT bits from FO + to FO+((TL-(IHL*4)+7)/8); + (10) IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8) + (11) IF FO = 0 THEN put header in header buffer + (12) IF TDL # 0 + (13) AND all RCVBT bits from 0 + to (TDL+7)/8 are set + (14) THEN TL <- TDL+(IHL*4) + (15) Submit datagram to next step; + (16) free all reassembly resources + for this BUFID; DONE. + (17) TIMER <- MAX(TIMER,TTL); + (18) give up until next fragment or timer expires; + (19) timer expires: flush all reassembly with this BUFID; DONE. + + In the case that two or more fragments contain the same data + + +[Page 28] + + +September 1981 + Internet Protocol + Specification + + + + either identically or through a partial overlap, this procedure + will use the more recently arrived copy in the data buffer and + datagram delivered. + + Identification + + The choice of the Identifier for a datagram is based on the need to + provide a way to uniquely identify the fragments of a particular + datagram. The protocol module assembling fragments judges fragments + to belong to the same datagram if they have the same source, + destination, protocol, and Identifier. Thus, the sender must choose + the Identifier to be unique for this source, destination pair and + protocol for the time the datagram (or any fragment of it) could be + alive in the internet. + + It seems then that a sending protocol module needs to keep a table + of Identifiers, one entry for each destination it has communicated + with in the last maximum packet lifetime for the internet. + + However, since the Identifier field allows 65,536 different values, + some host may be able to simply use unique identifiers independent + of destination. + + It is appropriate for some higher level protocols to choose the + identifier. For example, TCP protocol modules may retransmit an + identical TCP segment, and the probability for correct reception + would be enhanced if the retransmission carried the same identifier + as the original transmission since fragments of either datagram + could be used to construct a correct TCP segment. + + Type of Service + + The type of service (TOS) is for internet service quality selection. + The type of service is specified along the abstract parameters + precedence, delay, throughput, and reliability. These abstract + parameters are to be mapped into the actual service parameters of + the particular networks the datagram traverses. + + Precedence. An independent measure of the importance of this + datagram. + + Delay. Prompt delivery is important for datagrams with this + indication. + + Throughput. High data rate is important for datagrams with this + indication. + + + + + [Page 29] + + + September 1981 +Internet Protocol +Specification + + + + Reliability. A higher level of effort to ensure delivery is + important for datagrams with this indication. + + For example, the ARPANET has a priority bit, and a choice between + "standard" messages (type 0) and "uncontrolled" messages (type 3), + (the choice between single packet and multipacket messages can also + be considered a service parameter). The uncontrolled messages tend + to be less reliably delivered and suffer less delay. Suppose an + internet datagram is to be sent through the ARPANET. Let the + internet type of service be given as: + + Precedence: 5 + Delay: 0 + Throughput: 1 + Reliability: 1 + + In this example, the mapping of these parameters to those available + for the ARPANET would be to set the ARPANET priority bit on since + the Internet precedence is in the upper half of its range, to select + standard messages since the throughput and reliability requirements + are indicated and delay is not. More details are given on service + mappings in "Service Mappings" [8]. + + Time to Live + + The time to live is set by the sender to the maximum time the + datagram is allowed to be in the internet system. If the datagram + is in the internet system longer than the time to live, then the + datagram must be destroyed. + + This field must be decreased at each point that the internet header + is processed to reflect the time spent processing the datagram. + Even if no local information is available on the time actually + spent, the field must be decremented by 1. The time is measured in + units of seconds (i.e. the value 1 means one second). Thus, the + maximum time to live is 255 seconds or 4.25 minutes. Since every + module that processes a datagram must decrease the TTL by at least + one even if it process the datagram in less than a second, the TTL + must be thought of only as an upper bound on the time a datagram may + exist. The intention is to cause undeliverable datagrams to be + discarded, and to bound the maximum datagram lifetime. + + Some higher level reliable connection protocols are based on + assumptions that old duplicate datagrams will not arrive after a + certain time elapses. The TTL is a way for such protocols to have + an assurance that their assumption is met. + + + + +[Page 30] + + +September 1981 + Internet Protocol + Specification + + + + Options + + The options are optional in each datagram, but required in + implementations. That is, the presence or absence of an option is + the choice of the sender, but each internet module must be able to + parse every option. There can be several options present in the + option field. + + The options might not end on a 32-bit boundary. The internet header + must be filled out with octets of zeros. The first of these would + be interpreted as the end-of-options option, and the remainder as + internet header padding. + + Every internet module must be able to act on every option. The + Security Option is required if classified, restricted, or + compartmented traffic is to be passed. + + Checksum + + The internet header checksum is recomputed if the internet header is + changed. For example, a reduction of the time to live, additions or + changes to internet options, or due to fragmentation. This checksum + at the internet level is intended to protect the internet header + fields from transmission errors. + + There are some applications where a few data bit errors are + acceptable while retransmission delays are not. If the internet + protocol enforced data correctness such applications could not be + supported. + + Errors + + Internet protocol errors may be reported via the ICMP messages [3]. + +3.3. Interfaces + + The functional description of user interfaces to the IP is, at best, + fictional, since every operating system will have different + facilities. Consequently, we must warn readers that different IP + implementations may have different user interfaces. However, all IPs + must provide a certain minimum set of services to guarantee that all + IP implementations can support the same protocol hierarchy. This + section specifies the functional interfaces required of all IP + implementations. + + Internet protocol interfaces on one side to the local network and on + the other side to either a higher level protocol or an application + program. In the following, the higher level protocol or application + + + [Page 31] + + + September 1981 +Internet Protocol +Specification + + + + program (or even a gateway program) will be called the "user" since it + is using the internet module. Since internet protocol is a datagram + protocol, there is minimal memory or state maintained between datagram + transmissions, and each call on the internet protocol module by the + user supplies all information necessary for the IP to perform the + service requested. + + An Example Upper Level Interface + + The following two example calls satisfy the requirements for the user + to internet protocol module communication ("=>" means returns): + + SEND (src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result) + + where: + + src = source address + dst = destination address + prot = protocol + TOS = type of service + TTL = time to live + BufPTR = buffer pointer + len = length of buffer + Id = Identifier + DF = Don't Fragment + opt = option data + result = response + OK = datagram sent ok + Error = error in arguments or local network error + + Note that the precedence is included in the TOS and the + security/compartment is passed as an option. + + RECV (BufPTR, prot, => result, src, dst, TOS, len, opt) + + where: + + BufPTR = buffer pointer + prot = protocol + result = response + OK = datagram received ok + Error = error in arguments + len = length of buffer + src = source address + dst = destination address + TOS = type of service + opt = option data + + + +[Page 32] + + +September 1981 + Internet Protocol + Specification + + + + When the user sends a datagram, it executes the SEND call supplying + all the arguments. The internet protocol module, on receiving this + call, checks the arguments and prepares and sends the message. If the + arguments are good and the datagram is accepted by the local network, + the call returns successfully. If either the arguments are bad, or + the datagram is not accepted by the local network, the call returns + unsuccessfully. On unsuccessful returns, a reasonable report must be + made as to the cause of the problem, but the details of such reports + are up to individual implementations. + + When a datagram arrives at the internet protocol module from the local + network, either there is a pending RECV call from the user addressed + or there is not. In the first case, the pending call is satisfied by + passing the information from the datagram to the user. In the second + case, the user addressed is notified of a pending datagram. If the + user addressed does not exist, an ICMP error message is returned to + the sender, and the data is discarded. + + The notification of a user may be via a pseudo interrupt or similar + mechanism, as appropriate in the particular operating system + environment of the implementation. + + A user's RECV call may then either be immediately satisfied by a + pending datagram, or the call may be pending until a datagram arrives. + + The source address is included in the send call in case the sending + host has several addresses (multiple physical connections or logical + addresses). The internet module must check to see that the source + address is one of the legal address for this host. + + An implementation may also allow or require a call to the internet + module to indicate interest in or reserve exclusive use of a class of + datagrams (e.g., all those with a certain value in the protocol + field). + + This section functionally characterizes a USER/IP interface. The + notation used is similar to most procedure of function calls in high + level languages, but this usage is not meant to rule out trap type + service calls (e.g., SVCs, UUOs, EMTs), or any other form of + interprocess communication. + + + + + + + + + + + [Page 33] + + + September 1981 +Internet Protocol + + + +APPENDIX A: Examples & Scenarios + +Example 1: + + This is an example of the minimal data carrying internet datagram: + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Ver= 4 |IHL= 5 |Type of Service| Total Length = 21 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identification = 111 |Flg=0| Fragment Offset = 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Time = 123 | Protocol = 1 | header checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | source address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | destination address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | + +-+-+-+-+-+-+-+-+ + + Example Internet Datagram + + Figure 5. + + Note that each tick mark represents one bit position. + + This is a internet datagram in version 4 of internet protocol; the + internet header consists of five 32 bit words, and the total length of + the datagram is 21 octets. This datagram is a complete datagram (not + a fragment). + + + + + + + + + + + + + + + + + + +[Page 34] + + +September 1981 + Internet Protocol + + + +Example 2: + + In this example, we show first a moderate size internet datagram (452 + data octets), then two internet fragments that might result from the + fragmentation of this datagram if the maximum sized transmission + allowed were 280 octets. + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Ver= 4 |IHL= 5 |Type of Service| Total Length = 472 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identification = 111 |Flg=0| Fragment Offset = 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Time = 123 | Protocol = 6 | header checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | source address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | destination address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | + \ \ + \ \ + | data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Example Internet Datagram + + Figure 6. + + + + + + + + + + + + + + + + + + [Page 35] + + + September 1981 +Internet Protocol + + + + Now the first fragment that results from splitting the datagram after + 256 data octets. + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Ver= 4 |IHL= 5 |Type of Service| Total Length = 276 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identification = 111 |Flg=1| Fragment Offset = 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Time = 119 | Protocol = 6 | Header Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | source address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | destination address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | + \ \ + \ \ + | data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Example Internet Fragment + + Figure 7. + + + + + + + + + + + + + + + + + + + + + +[Page 36] + + +September 1981 + Internet Protocol + + + + And the second fragment. + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Ver= 4 |IHL= 5 |Type of Service| Total Length = 216 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identification = 111 |Flg=0| Fragment Offset = 32 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Time = 119 | Protocol = 6 | Header Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | source address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | destination address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | + \ \ + \ \ + | data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Example Internet Fragment + + Figure 8. + + + + + + + + + + + + + + + + + + + + + + + [Page 37] + + + September 1981 +Internet Protocol + + + +Example 3: + + Here, we show an example of a datagram containing options: + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Ver= 4 |IHL= 8 |Type of Service| Total Length = 576 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identification = 111 |Flg=0| Fragment Offset = 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Time = 123 | Protocol = 6 | Header Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | source address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | destination address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Opt. Code = x | Opt. Len.= 3 | option value | Opt. Code = x | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Opt. Len. = 4 | option value | Opt. Code = 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Opt. Code = y | Opt. Len. = 3 | option value | Opt. Code = 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | + \ \ + \ \ + | data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Example Internet Datagram + + Figure 9. + + + + + + + + + + + + + + + + +[Page 38] + + +September 1981 + Internet Protocol + + + +APPENDIX B: Data Transmission Order + +The order of transmission of the header and data described in this +document is resolved to the octet level. Whenever a diagram shows a +group of octets, the order of transmission of those octets is the normal +order in which they are read in English. For example, in the following +diagram the octets are transmitted in the order they are numbered. + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 1 | 2 | 3 | 4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 5 | 6 | 7 | 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 9 | 10 | 11 | 12 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Transmission Order of Bytes + + Figure 10. + +Whenever an octet represents a numeric quantity the left most bit in the +diagram is the high order or most significant bit. That is, the bit +labeled 0 is the most significant bit. For example, the following +diagram represents the value 170 (decimal). + + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |1 0 1 0 1 0 1 0| + +-+-+-+-+-+-+-+-+ + + Significance of Bits + + Figure 11. + +Similarly, whenever a multi-octet field represents a numeric quantity +the left most bit of the whole field is the most significant bit. When +a multi-octet quantity is transmitted the most significant octet is +transmitted first. + + + + + + + + + + [Page 39] + + + September 1981 +Internet Protocol + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 40] + + +September 1981 + Internet Protocol + + + + GLOSSARY + + + +1822 + BBN Report 1822, "The Specification of the Interconnection of + a Host and an IMP". The specification of interface between a + host and the ARPANET. + +ARPANET leader + The control information on an ARPANET message at the host-IMP + interface. + +ARPANET message + The unit of transmission between a host and an IMP in the + ARPANET. The maximum size is about 1012 octets (8096 bits). + +ARPANET packet + A unit of transmission used internally in the ARPANET between + IMPs. The maximum size is about 126 octets (1008 bits). + +Destination + The destination address, an internet header field. + +DF + The Don't Fragment bit carried in the flags field. + +Flags + An internet header field carrying various control flags. + +Fragment Offset + This internet header field indicates where in the internet + datagram a fragment belongs. + +GGP + Gateway to Gateway Protocol, the protocol used primarily + between gateways to control routing and other gateway + functions. + +header + Control information at the beginning of a message, segment, + datagram, packet or block of data. + +ICMP + Internet Control Message Protocol, implemented in the internet + module, the ICMP is used from gateways to hosts and between + hosts to report errors and make routing suggestions. + + + + + [Page 41] + + + September 1981 +Internet Protocol +Glossary + + + +Identification + An internet header field carrying the identifying value + assigned by the sender to aid in assembling the fragments of a + datagram. + +IHL + The internet header field Internet Header Length is the length + of the internet header measured in 32 bit words. + +IMP + The Interface Message Processor, the packet switch of the + ARPANET. + +Internet Address + A four octet (32 bit) source or destination address consisting + of a Network field and a Local Address field. + +internet datagram + The unit of data exchanged between a pair of internet modules + (includes the internet header). + +internet fragment + A portion of the data of an internet datagram with an internet + header. + +Local Address + The address of a host within a network. The actual mapping of + an internet local address on to the host addresses in a + network is quite general, allowing for many to one mappings. + +MF + The More-Fragments Flag carried in the internet header flags + field. + +module + An implementation, usually in software, of a protocol or other + procedure. + +more-fragments flag + A flag indicating whether or not this internet datagram + contains the end of an internet datagram, carried in the + internet header Flags field. + +NFB + The Number of Fragment Blocks in a the data portion of an + internet fragment. That is, the length of a portion of data + measured in 8 octet units. + + + +[Page 42] + + +September 1981 + Internet Protocol + Glossary + + + +octet + An eight bit byte. + +Options + The internet header Options field may contain several options, + and each option may be several octets in length. + +Padding + The internet header Padding field is used to ensure that the + data begins on 32 bit word boundary. The padding is zero. + +Protocol + In this document, the next higher level protocol identifier, + an internet header field. + +Rest + The local address portion of an Internet Address. + +Source + The source address, an internet header field. + +TCP + Transmission Control Protocol: A host-to-host protocol for + reliable communication in internet environments. + +TCP Segment + The unit of data exchanged between TCP modules (including the + TCP header). + +TFTP + Trivial File Transfer Protocol: A simple file transfer + protocol built on UDP. + +Time to Live + An internet header field which indicates the upper bound on + how long this internet datagram may exist. + +TOS + Type of Service + +Total Length + The internet header field Total Length is the length of the + datagram in octets including internet header and data. + +TTL + Time to Live + + + + + [Page 43] + + + September 1981 +Internet Protocol +Glossary + + + +Type of Service + An internet header field which indicates the type (or quality) + of service for this internet datagram. + +UDP + User Datagram Protocol: A user level protocol for transaction + oriented applications. + +User + The user of the internet protocol. This may be a higher level + protocol module, an application program, or a gateway program. + +Version + The Version field indicates the format of the internet header. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 44] + + +September 1981 + Internet Protocol + + + + REFERENCES + + + +[1] Cerf, V., "The Catenet Model for Internetworking," Information + Processing Techniques Office, Defense Advanced Research Projects + Agency, IEN 48, July 1978. + +[2] Bolt Beranek and Newman, "Specification for the Interconnection of + a Host and an IMP," BBN Technical Report 1822, Revised May 1978. + +[3] Postel, J., "Internet Control Message Protocol - DARPA Internet + Program Protocol Specification," RFC 792, USC/Information Sciences + Institute, September 1981. + +[4] Shoch, J., "Inter-Network Naming, Addressing, and Routing," + COMPCON, IEEE Computer Society, Fall 1978. + +[5] Postel, J., "Address Mappings," RFC 796, USC/Information Sciences + Institute, September 1981. + +[6] Shoch, J., "Packet Fragmentation in Inter-Network Protocols," + Computer Networks, v. 3, n. 1, February 1979. + +[7] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and + Newman, August 1979. + +[8] Postel, J., "Service Mappings," RFC 795, USC/Information Sciences + Institute, September 1981. + +[9] Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences + Institute, September 1981. + + + + + + + + + + + + + + + + + + + + [Page 45] + diff --git a/rfc/rfc793.txt b/rfc/rfc793.txt new file mode 100644 index 00000000..603a78c8 --- /dev/null +++ b/rfc/rfc793.txt @@ -0,0 +1,5247 @@ + + +RFC: 793 + + + + + + + + TRANSMISSION CONTROL PROTOCOL + + + DARPA INTERNET PROGRAM + + PROTOCOL SPECIFICATION + + + + September 1981 + + + + + + + + + + + + + + prepared for + + Defense Advanced Research Projects Agency + Information Processing Techniques Office + 1400 Wilson Boulevard + Arlington, Virginia 22209 + + + + + + + + by + + Information Sciences Institute + University of Southern California + 4676 Admiralty Way + Marina del Rey, California 90291 + + + +September 1981 + Transmission Control Protocol + + + + TABLE OF CONTENTS + + PREFACE ........................................................ iii + +1. INTRODUCTION ..................................................... 1 + + 1.1 Motivation .................................................... 1 + 1.2 Scope ......................................................... 2 + 1.3 About This Document ........................................... 2 + 1.4 Interfaces .................................................... 3 + 1.5 Operation ..................................................... 3 + +2. PHILOSOPHY ....................................................... 7 + + 2.1 Elements of the Internetwork System ........................... 7 + 2.2 Model of Operation ............................................ 7 + 2.3 The Host Environment .......................................... 8 + 2.4 Interfaces .................................................... 9 + 2.5 Relation to Other Protocols ................................... 9 + 2.6 Reliable Communication ........................................ 9 + 2.7 Connection Establishment and Clearing ........................ 10 + 2.8 Data Communication ........................................... 12 + 2.9 Precedence and Security ...................................... 13 + 2.10 Robustness Principle ......................................... 13 + +3. FUNCTIONAL SPECIFICATION ........................................ 15 + + 3.1 Header Format ................................................ 15 + 3.2 Terminology .................................................. 19 + 3.3 Sequence Numbers ............................................. 24 + 3.4 Establishing a connection .................................... 30 + 3.5 Closing a Connection ......................................... 37 + 3.6 Precedence and Security ...................................... 40 + 3.7 Data Communication ........................................... 40 + 3.8 Interfaces ................................................... 44 + 3.9 Event Processing ............................................. 52 + +GLOSSARY ............................................................ 79 + +REFERENCES .......................................................... 85 + + + + + + + + + + + + [Page i] + + + September 1981 +Transmission Control Protocol + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page ii] + + +September 1981 + Transmission Control Protocol + + + + PREFACE + + + +This document describes the DoD Standard Transmission Control Protocol +(TCP). There have been nine earlier editions of the ARPA TCP +specification on which this standard is based, and the present text +draws heavily from them. There have been many contributors to this work +both in terms of concepts and in terms of text. This edition clarifies +several details and removes the end-of-letter buffer-size adjustments, +and redescribes the letter mechanism as a push function. + + Jon Postel + + Editor + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [Page iii] + + + + +RFC: 793 +Replaces: RFC 761 +IENs: 129, 124, 112, 81, +55, 44, 40, 27, 21, 5 + + TRANSMISSION CONTROL PROTOCOL + + DARPA INTERNET PROGRAM + PROTOCOL SPECIFICATION + + + + 1. INTRODUCTION + +The Transmission Control Protocol (TCP) is intended for use as a highly +reliable host-to-host protocol between hosts in packet-switched computer +communication networks, and in interconnected systems of such networks. + +This document describes the functions to be performed by the +Transmission Control Protocol, the program that implements it, and its +interface to programs or users that require its services. + +1.1. Motivation + + Computer communication systems are playing an increasingly important + role in military, government, and civilian environments. This + document focuses its attention primarily on military computer + communication requirements, especially robustness in the presence of + communication unreliability and availability in the presence of + congestion, but many of these problems are found in the civilian and + government sector as well. + + As strategic and tactical computer communication networks are + developed and deployed, it is essential to provide means of + interconnecting them and to provide standard interprocess + communication protocols which can support a broad range of + applications. In anticipation of the need for such standards, the + Deputy Undersecretary of Defense for Research and Engineering has + declared the Transmission Control Protocol (TCP) described herein to + be a basis for DoD-wide inter-process communication protocol + standardization. + + TCP is a connection-oriented, end-to-end reliable protocol designed to + fit into a layered hierarchy of protocols which support multi-network + applications. The TCP provides for reliable inter-process + communication between pairs of processes in host computers attached to + distinct but interconnected computer communication networks. Very few + assumptions are made as to the reliability of the communication + protocols below the TCP layer. TCP assumes it can obtain a simple, + potentially unreliable datagram service from the lower level + protocols. In principle, the TCP should be able to operate above a + wide spectrum of communication systems ranging from hard-wired + connections to packet-switched or circuit-switched networks. + + + [Page 1] + + + September 1981 +Transmission Control Protocol +Introduction + + + + TCP is based on concepts first described by Cerf and Kahn in [1]. The + TCP fits into a layered protocol architecture just above a basic + Internet Protocol [2] which provides a way for the TCP to send and + receive variable-length segments of information enclosed in internet + datagram "envelopes". The internet datagram provides a means for + addressing source and destination TCPs in different networks. The + internet protocol also deals with any fragmentation or reassembly of + the TCP segments required to achieve transport and delivery through + multiple networks and interconnecting gateways. The internet protocol + also carries information on the precedence, security classification + and compartmentation of the TCP segments, so this information can be + communicated end-to-end across multiple networks. + + Protocol Layering + + +---------------------+ + | higher-level | + +---------------------+ + | TCP | + +---------------------+ + | internet protocol | + +---------------------+ + |communication network| + +---------------------+ + + Figure 1 + + Much of this document is written in the context of TCP implementations + which are co-resident with higher level protocols in the host + computer. Some computer systems will be connected to networks via + front-end computers which house the TCP and internet protocol layers, + as well as network specific software. The TCP specification describes + an interface to the higher level protocols which appears to be + implementable even for the front-end case, as long as a suitable + host-to-front end protocol is implemented. + +1.2. Scope + + The TCP is intended to provide a reliable process-to-process + communication service in a multinetwork environment. The TCP is + intended to be a host-to-host protocol in common use in multiple + networks. + +1.3. About this Document + + This document represents a specification of the behavior required of + any TCP implementation, both in its interactions with higher level + protocols and in its interactions with other TCPs. The rest of this + + +[Page 2] + + +September 1981 + Transmission Control Protocol + Introduction + + + + section offers a very brief view of the protocol interfaces and + operation. Section 2 summarizes the philosophical basis for the TCP + design. Section 3 offers both a detailed description of the actions + required of TCP when various events occur (arrival of new segments, + user calls, errors, etc.) and the details of the formats of TCP + segments. + +1.4. Interfaces + + The TCP interfaces on one side to user or application processes and on + the other side to a lower level protocol such as Internet Protocol. + + The interface between an application process and the TCP is + illustrated in reasonable detail. This interface consists of a set of + calls much like the calls an operating system provides to an + application process for manipulating files. For example, there are + calls to open and close connections and to send and receive data on + established connections. It is also expected that the TCP can + asynchronously communicate with application programs. Although + considerable freedom is permitted to TCP implementors to design + interfaces which are appropriate to a particular operating system + environment, a minimum functionality is required at the TCP/user + interface for any valid implementation. + + The interface between TCP and lower level protocol is essentially + unspecified except that it is assumed there is a mechanism whereby the + two levels can asynchronously pass information to each other. + Typically, one expects the lower level protocol to specify this + interface. TCP is designed to work in a very general environment of + interconnected networks. The lower level protocol which is assumed + throughout this document is the Internet Protocol [2]. + +1.5. Operation + + As noted above, the primary purpose of the TCP is to provide reliable, + securable logical circuit or connection service between pairs of + processes. To provide this service on top of a less reliable internet + communication system requires facilities in the following areas: + + Basic Data Transfer + Reliability + Flow Control + Multiplexing + Connections + Precedence and Security + + The basic operation of the TCP in each of these areas is described in + the following paragraphs. + + + [Page 3] + + + September 1981 +Transmission Control Protocol +Introduction + + + + Basic Data Transfer: + + The TCP is able to transfer a continuous stream of octets in each + direction between its users by packaging some number of octets into + segments for transmission through the internet system. In general, + the TCPs decide when to block and forward data at their own + convenience. + + Sometimes users need to be sure that all the data they have + submitted to the TCP has been transmitted. For this purpose a push + function is defined. To assure that data submitted to a TCP is + actually transmitted the sending user indicates that it should be + pushed through to the receiving user. A push causes the TCPs to + promptly forward and deliver data up to that point to the receiver. + The exact push point might not be visible to the receiving user and + the push function does not supply a record boundary marker. + + Reliability: + + The TCP must recover from data that is damaged, lost, duplicated, or + delivered out of order by the internet communication system. This + is achieved by assigning a sequence number to each octet + transmitted, and requiring a positive acknowledgment (ACK) from the + receiving TCP. If the ACK is not received within a timeout + interval, the data is retransmitted. At the receiver, the sequence + numbers are used to correctly order segments that may be received + out of order and to eliminate duplicates. Damage is handled by + adding a checksum to each segment transmitted, checking it at the + receiver, and discarding damaged segments. + + As long as the TCPs continue to function properly and the internet + system does not become completely partitioned, no transmission + errors will affect the correct delivery of data. TCP recovers from + internet communication system errors. + + Flow Control: + + TCP provides a means for the receiver to govern the amount of data + sent by the sender. This is achieved by returning a "window" with + every ACK indicating a range of acceptable sequence numbers beyond + the last segment successfully received. The window indicates an + allowed number of octets that the sender may transmit before + receiving further permission. + + + + + + + +[Page 4] + + +September 1981 + Transmission Control Protocol + Introduction + + + + Multiplexing: + + To allow for many processes within a single Host to use TCP + communication facilities simultaneously, the TCP provides a set of + addresses or ports within each host. Concatenated with the network + and host addresses from the internet communication layer, this forms + a socket. A pair of sockets uniquely identifies each connection. + That is, a socket may be simultaneously used in multiple + connections. + + The binding of ports to processes is handled independently by each + Host. However, it proves useful to attach frequently used processes + (e.g., a "logger" or timesharing service) to fixed sockets which are + made known to the public. These services can then be accessed + through the known addresses. Establishing and learning the port + addresses of other processes may involve more dynamic mechanisms. + + Connections: + + The reliability and flow control mechanisms described above require + that TCPs initialize and maintain certain status information for + each data stream. The combination of this information, including + sockets, sequence numbers, and window sizes, is called a connection. + Each connection is uniquely specified by a pair of sockets + identifying its two sides. + + When two processes wish to communicate, their TCP's must first + establish a connection (initialize the status information on each + side). When their communication is complete, the connection is + terminated or closed to free the resources for other uses. + + Since connections must be established between unreliable hosts and + over the unreliable internet communication system, a handshake + mechanism with clock-based sequence numbers is used to avoid + erroneous initialization of connections. + + Precedence and Security: + + The users of TCP may indicate the security and precedence of their + communication. Provision is made for default values to be used when + these features are not needed. + + + + + + + + + + [Page 5] + + + September 1981 +Transmission Control Protocol + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 6] + + +September 1981 + Transmission Control Protocol + + + + 2. PHILOSOPHY + +2.1. Elements of the Internetwork System + + The internetwork environment consists of hosts connected to networks + which are in turn interconnected via gateways. It is assumed here + that the networks may be either local networks (e.g., the ETHERNET) or + large networks (e.g., the ARPANET), but in any case are based on + packet switching technology. The active agents that produce and + consume messages are processes. Various levels of protocols in the + networks, the gateways, and the hosts support an interprocess + communication system that provides two-way data flow on logical + connections between process ports. + + The term packet is used generically here to mean the data of one + transaction between a host and its network. The format of data blocks + exchanged within the a network will generally not be of concern to us. + + Hosts are computers attached to a network, and from the communication + network's point of view, are the sources and destinations of packets. + Processes are viewed as the active elements in host computers (in + accordance with the fairly common definition of a process as a program + in execution). Even terminals and files or other I/O devices are + viewed as communicating with each other through the use of processes. + Thus, all communication is viewed as inter-process communication. + + Since a process may need to distinguish among several communication + streams between itself and another process (or processes), we imagine + that each process may have a number of ports through which it + communicates with the ports of other processes. + +2.2. Model of Operation + + Processes transmit data by calling on the TCP and passing buffers of + data as arguments. The TCP packages the data from these buffers into + segments and calls on the internet module to transmit each segment to + the destination TCP. The receiving TCP places the data from a segment + into the receiving user's buffer and notifies the receiving user. The + TCPs include control information in the segments which they use to + ensure reliable ordered data transmission. + + The model of internet communication is that there is an internet + protocol module associated with each TCP which provides an interface + to the local network. This internet module packages TCP segments + inside internet datagrams and routes these datagrams to a destination + internet module or intermediate gateway. To transmit the datagram + through the local network, it is embedded in a local network packet. + + The packet switches may perform further packaging, fragmentation, or + + + [Page 7] + + + September 1981 +Transmission Control Protocol +Philosophy + + + + other operations to achieve the delivery of the local packet to the + destination internet module. + + At a gateway between networks, the internet datagram is "unwrapped" + from its local packet and examined to determine through which network + the internet datagram should travel next. The internet datagram is + then "wrapped" in a local packet suitable to the next network and + routed to the next gateway, or to the final destination. + + A gateway is permitted to break up an internet datagram into smaller + internet datagram fragments if this is necessary for transmission + through the next network. To do this, the gateway produces a set of + internet datagrams; each carrying a fragment. Fragments may be + further broken into smaller fragments at subsequent gateways. The + internet datagram fragment format is designed so that the destination + internet module can reassemble fragments into internet datagrams. + + A destination internet module unwraps the segment from the datagram + (after reassembling the datagram, if necessary) and passes it to the + destination TCP. + + This simple model of the operation glosses over many details. One + important feature is the type of service. This provides information + to the gateway (or internet module) to guide it in selecting the + service parameters to be used in traversing the next network. + Included in the type of service information is the precedence of the + datagram. Datagrams may also carry security information to permit + host and gateways that operate in multilevel secure environments to + properly segregate datagrams for security considerations. + +2.3. The Host Environment + + The TCP is assumed to be a module in an operating system. The users + access the TCP much like they would access the file system. The TCP + may call on other operating system functions, for example, to manage + data structures. The actual interface to the network is assumed to be + controlled by a device driver module. The TCP does not call on the + network device driver directly, but rather calls on the internet + datagram protocol module which may in turn call on the device driver. + + The mechanisms of TCP do not preclude implementation of the TCP in a + front-end processor. However, in such an implementation, a + host-to-front-end protocol must provide the functionality to support + the type of TCP-user interface described in this document. + + + + + + +[Page 8] + + +September 1981 + Transmission Control Protocol + Philosophy + + + +2.4. Interfaces + + The TCP/user interface provides for calls made by the user on the TCP + to OPEN or CLOSE a connection, to SEND or RECEIVE data, or to obtain + STATUS about a connection. These calls are like other calls from user + programs on the operating system, for example, the calls to open, read + from, and close a file. + + The TCP/internet interface provides calls to send and receive + datagrams addressed to TCP modules in hosts anywhere in the internet + system. These calls have parameters for passing the address, type of + service, precedence, security, and other control information. + +2.5. Relation to Other Protocols + + The following diagram illustrates the place of the TCP in the protocol + hierarchy: + + + +------+ +-----+ +-----+ +-----+ + |Telnet| | FTP | |Voice| ... | | Application Level + +------+ +-----+ +-----+ +-----+ + | | | | + +-----+ +-----+ +-----+ + | TCP | | RTP | ... | | Host Level + +-----+ +-----+ +-----+ + | | | + +-------------------------------+ + | Internet Protocol & ICMP | Gateway Level + +-------------------------------+ + | + +---------------------------+ + | Local Network Protocol | Network Level + +---------------------------+ + + Protocol Relationships + + Figure 2. + + It is expected that the TCP will be able to support higher level + protocols efficiently. It should be easy to interface higher level + protocols like the ARPANET Telnet or AUTODIN II THP to the TCP. + +2.6. Reliable Communication + + A stream of data sent on a TCP connection is delivered reliably and in + order at the destination. + + + + [Page 9] + + + September 1981 +Transmission Control Protocol +Philosophy + + + + Transmission is made reliable via the use of sequence numbers and + acknowledgments. Conceptually, each octet of data is assigned a + sequence number. The sequence number of the first octet of data in a + segment is transmitted with that segment and is called the segment + sequence number. Segments also carry an acknowledgment number which + is the sequence number of the next expected data octet of + transmissions in the reverse direction. When the TCP transmits a + segment containing data, it puts a copy on a retransmission queue and + starts a timer; when the acknowledgment for that data is received, the + segment is deleted from the queue. If the acknowledgment is not + received before the timer runs out, the segment is retransmitted. + + An acknowledgment by TCP does not guarantee that the data has been + delivered to the end user, but only that the receiving TCP has taken + the responsibility to do so. + + To govern the flow of data between TCPs, a flow control mechanism is + employed. The receiving TCP reports a "window" to the sending TCP. + This window specifies the number of octets, starting with the + acknowledgment number, that the receiving TCP is currently prepared to + receive. + +2.7. Connection Establishment and Clearing + + To identify the separate data streams that a TCP may handle, the TCP + provides a port identifier. Since port identifiers are selected + independently by each TCP they might not be unique. To provide for + unique addresses within each TCP, we concatenate an internet address + identifying the TCP with a port identifier to create a socket which + will be unique throughout all networks connected together. + + A connection is fully specified by the pair of sockets at the ends. A + local socket may participate in many connections to different foreign + sockets. A connection can be used to carry data in both directions, + that is, it is "full duplex". + + TCPs are free to associate ports with processes however they choose. + However, several basic concepts are necessary in any implementation. + There must be well-known sockets which the TCP associates only with + the "appropriate" processes by some means. We envision that processes + may "own" ports, and that processes can initiate connections only on + the ports they own. (Means for implementing ownership is a local + issue, but we envision a Request Port user command, or a method of + uniquely allocating a group of ports to a given process, e.g., by + associating the high order bits of a port name with a given process.) + + A connection is specified in the OPEN call by the local port and + foreign socket arguments. In return, the TCP supplies a (short) local + + +[Page 10] + + +September 1981 + Transmission Control Protocol + Philosophy + + + + connection name by which the user refers to the connection in + subsequent calls. There are several things that must be remembered + about a connection. To store this information we imagine that there + is a data structure called a Transmission Control Block (TCB). One + implementation strategy would have the local connection name be a + pointer to the TCB for this connection. The OPEN call also specifies + whether the connection establishment is to be actively pursued, or to + be passively waited for. + + A passive OPEN request means that the process wants to accept incoming + connection requests rather than attempting to initiate a connection. + Often the process requesting a passive OPEN will accept a connection + request from any caller. In this case a foreign socket of all zeros + is used to denote an unspecified socket. Unspecified foreign sockets + are allowed only on passive OPENs. + + A service process that wished to provide services for unknown other + processes would issue a passive OPEN request with an unspecified + foreign socket. Then a connection could be made with any process that + requested a connection to this local socket. It would help if this + local socket were known to be associated with this service. + + Well-known sockets are a convenient mechanism for a priori associating + a socket address with a standard service. For instance, the + "Telnet-Server" process is permanently assigned to a particular + socket, and other sockets are reserved for File Transfer, Remote Job + Entry, Text Generator, Echoer, and Sink processes (the last three + being for test purposes). A socket address might be reserved for + access to a "Look-Up" service which would return the specific socket + at which a newly created service would be provided. The concept of a + well-known socket is part of the TCP specification, but the assignment + of sockets to services is outside this specification. (See [4].) + + Processes can issue passive OPENs and wait for matching active OPENs + from other processes and be informed by the TCP when connections have + been established. Two processes which issue active OPENs to each + other at the same time will be correctly connected. This flexibility + is critical for the support of distributed computing in which + components act asynchronously with respect to each other. + + There are two principal cases for matching the sockets in the local + passive OPENs and an foreign active OPENs. In the first case, the + local passive OPENs has fully specified the foreign socket. In this + case, the match must be exact. In the second case, the local passive + OPENs has left the foreign socket unspecified. In this case, any + foreign socket is acceptable as long as the local sockets match. + Other possibilities include partially restricted matches. + + + + [Page 11] + + + September 1981 +Transmission Control Protocol +Philosophy + + + + If there are several pending passive OPENs (recorded in TCBs) with the + same local socket, an foreign active OPEN will be matched to a TCB + with the specific foreign socket in the foreign active OPEN, if such a + TCB exists, before selecting a TCB with an unspecified foreign socket. + + The procedures to establish connections utilize the synchronize (SYN) + control flag and involves an exchange of three messages. This + exchange has been termed a three-way hand shake [3]. + + A connection is initiated by the rendezvous of an arriving segment + containing a SYN and a waiting TCB entry each created by a user OPEN + command. The matching of local and foreign sockets determines when a + connection has been initiated. The connection becomes "established" + when sequence numbers have been synchronized in both directions. + + The clearing of a connection also involves the exchange of segments, + in this case carrying the FIN control flag. + +2.8. Data Communication + + The data that flows on a connection may be thought of as a stream of + octets. The sending user indicates in each SEND call whether the data + in that call (and any preceeding calls) should be immediately pushed + through to the receiving user by the setting of the PUSH flag. + + A sending TCP is allowed to collect data from the sending user and to + send that data in segments at its own convenience, until the push + function is signaled, then it must send all unsent data. When a + receiving TCP sees the PUSH flag, it must not wait for more data from + the sending TCP before passing the data to the receiving process. + + There is no necessary relationship between push functions and segment + boundaries. The data in any particular segment may be the result of a + single SEND call, in whole or part, or of multiple SEND calls. + + The purpose of push function and the PUSH flag is to push data through + from the sending user to the receiving user. It does not provide a + record service. + + There is a coupling between the push function and the use of buffers + of data that cross the TCP/user interface. Each time a PUSH flag is + associated with data placed into the receiving user's buffer, the + buffer is returned to the user for processing even if the buffer is + not filled. If data arrives that fills the user's buffer before a + PUSH is seen, the data is passed to the user in buffer size units. + + TCP also provides a means to communicate to the receiver of data that + at some point further along in the data stream than the receiver is + + +[Page 12] + + +September 1981 + Transmission Control Protocol + Philosophy + + + + currently reading there is urgent data. TCP does not attempt to + define what the user specifically does upon being notified of pending + urgent data, but the general notion is that the receiving process will + take action to process the urgent data quickly. + +2.9. Precedence and Security + + The TCP makes use of the internet protocol type of service field and + security option to provide precedence and security on a per connection + basis to TCP users. Not all TCP modules will necessarily function in + a multilevel secure environment; some may be limited to unclassified + use only, and others may operate at only one security level and + compartment. Consequently, some TCP implementations and services to + users may be limited to a subset of the multilevel secure case. + + TCP modules which operate in a multilevel secure environment must + properly mark outgoing segments with the security, compartment, and + precedence. Such TCP modules must also provide to their users or + higher level protocols such as Telnet or THP an interface to allow + them to specify the desired security level, compartment, and + precedence of connections. + +2.10. Robustness Principle + + TCP implementations will follow a general principle of robustness: be + conservative in what you do, be liberal in what you accept from + others. + + + + + + + + + + + + + + + + + + + + + + + + [Page 13] + + + September 1981 +Transmission Control Protocol + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 14] + + +September 1981 + Transmission Control Protocol + + + + 3. FUNCTIONAL SPECIFICATION + +3.1. Header Format + + TCP segments are sent as internet datagrams. The Internet Protocol + header carries several information fields, including the source and + destination host addresses [2]. A TCP header follows the internet + header, supplying information specific to the TCP protocol. This + division allows for the existence of host level protocols other than + TCP. + + TCP Header Format + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source Port | Destination Port | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Acknowledgment Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data | |U|A|P|R|S|F| | + | Offset| Reserved |R|C|S|S|Y|I| Window | + | | |G|K|H|T|N|N| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Checksum | Urgent Pointer | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options | Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + TCP Header Format + + Note that one tick mark represents one bit position. + + Figure 3. + + Source Port: 16 bits + + The source port number. + + Destination Port: 16 bits + + The destination port number. + + + + + [Page 15] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + Sequence Number: 32 bits + + The sequence number of the first data octet in this segment (except + when SYN is present). If SYN is present the sequence number is the + initial sequence number (ISN) and the first data octet is ISN+1. + + Acknowledgment Number: 32 bits + + If the ACK control bit is set this field contains the value of the + next sequence number the sender of the segment is expecting to + receive. Once a connection is established this is always sent. + + Data Offset: 4 bits + + The number of 32 bit words in the TCP Header. This indicates where + the data begins. The TCP header (even one including options) is an + integral number of 32 bits long. + + Reserved: 6 bits + + Reserved for future use. Must be zero. + + Control Bits: 6 bits (from left to right): + + URG: Urgent Pointer field significant + ACK: Acknowledgment field significant + PSH: Push Function + RST: Reset the connection + SYN: Synchronize sequence numbers + FIN: No more data from sender + + Window: 16 bits + + The number of data octets beginning with the one indicated in the + acknowledgment field which the sender of this segment is willing to + accept. + + Checksum: 16 bits + + The checksum field is the 16 bit one's complement of the one's + complement sum of all 16 bit words in the header and text. If a + segment contains an odd number of header and text octets to be + checksummed, the last octet is padded on the right with zeros to + form a 16 bit word for checksum purposes. The pad is not + transmitted as part of the segment. While computing the checksum, + the checksum field itself is replaced with zeros. + + The checksum also covers a 96 bit pseudo header conceptually + + +[Page 16] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + prefixed to the TCP header. This pseudo header contains the Source + Address, the Destination Address, the Protocol, and TCP length. + This gives the TCP protection against misrouted segments. This + information is carried in the Internet Protocol and is transferred + across the TCP/Network interface in the arguments or results of + calls by the TCP on the IP. + + +--------+--------+--------+--------+ + | Source Address | + +--------+--------+--------+--------+ + | Destination Address | + +--------+--------+--------+--------+ + | zero | PTCL | TCP Length | + +--------+--------+--------+--------+ + + The TCP Length is the TCP header length plus the data length in + octets (this is not an explicitly transmitted quantity, but is + computed), and it does not count the 12 octets of the pseudo + header. + + Urgent Pointer: 16 bits + + This field communicates the current value of the urgent pointer as a + positive offset from the sequence number in this segment. The + urgent pointer points to the sequence number of the octet following + the urgent data. This field is only be interpreted in segments with + the URG control bit set. + + Options: variable + + Options may occupy space at the end of the TCP header and are a + multiple of 8 bits in length. All options are included in the + checksum. An option may begin on any octet boundary. There are two + cases for the format of an option: + + Case 1: A single octet of option-kind. + + Case 2: An octet of option-kind, an octet of option-length, and + the actual option-data octets. + + The option-length counts the two octets of option-kind and + option-length as well as the option-data octets. + + Note that the list of options may be shorter than the data offset + field might imply. The content of the header beyond the + End-of-Option option must be header padding (i.e., zero). + + A TCP must implement all options. + + + [Page 17] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + Currently defined options include (kind indicated in octal): + + Kind Length Meaning + ---- ------ ------- + 0 - End of option list. + 1 - No-Operation. + 2 4 Maximum Segment Size. + + + Specific Option Definitions + + End of Option List + + +--------+ + |00000000| + +--------+ + Kind=0 + + This option code indicates the end of the option list. This + might not coincide with the end of the TCP header according to + the Data Offset field. This is used at the end of all options, + not the end of each option, and need only be used if the end of + the options would not otherwise coincide with the end of the TCP + header. + + No-Operation + + +--------+ + |00000001| + +--------+ + Kind=1 + + This option code may be used between options, for example, to + align the beginning of a subsequent option on a word boundary. + There is no guarantee that senders will use this option, so + receivers must be prepared to process options even if they do + not begin on a word boundary. + + Maximum Segment Size + + +--------+--------+---------+--------+ + |00000010|00000100| max seg size | + +--------+--------+---------+--------+ + Kind=2 Length=4 + + + + + + +[Page 18] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + Maximum Segment Size Option Data: 16 bits + + If this option is present, then it communicates the maximum + receive segment size at the TCP which sends this segment. + This field must only be sent in the initial connection request + (i.e., in segments with the SYN control bit set). If this + option is not used, any segment size is allowed. + + Padding: variable + + The TCP header padding is used to ensure that the TCP header ends + and data begins on a 32 bit boundary. The padding is composed of + zeros. + +3.2. Terminology + + Before we can discuss very much about the operation of the TCP we need + to introduce some detailed terminology. The maintenance of a TCP + connection requires the remembering of several variables. We conceive + of these variables being stored in a connection record called a + Transmission Control Block or TCB. Among the variables stored in the + TCB are the local and remote socket numbers, the security and + precedence of the connection, pointers to the user's send and receive + buffers, pointers to the retransmit queue and to the current segment. + In addition several variables relating to the send and receive + sequence numbers are stored in the TCB. + + Send Sequence Variables + + SND.UNA - send unacknowledged + SND.NXT - send next + SND.WND - send window + SND.UP - send urgent pointer + SND.WL1 - segment sequence number used for last window update + SND.WL2 - segment acknowledgment number used for last window + update + ISS - initial send sequence number + + Receive Sequence Variables + + RCV.NXT - receive next + RCV.WND - receive window + RCV.UP - receive urgent pointer + IRS - initial receive sequence number + + + + + + + [Page 19] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + The following diagrams may help to relate some of these variables to + the sequence space. + + Send Sequence Space + + 1 2 3 4 + ----------|----------|----------|---------- + SND.UNA SND.NXT SND.UNA + +SND.WND + + 1 - old sequence numbers which have been acknowledged + 2 - sequence numbers of unacknowledged data + 3 - sequence numbers allowed for new data transmission + 4 - future sequence numbers which are not yet allowed + + Send Sequence Space + + Figure 4. + + + + The send window is the portion of the sequence space labeled 3 in + figure 4. + + Receive Sequence Space + + 1 2 3 + ----------|----------|---------- + RCV.NXT RCV.NXT + +RCV.WND + + 1 - old sequence numbers which have been acknowledged + 2 - sequence numbers allowed for new reception + 3 - future sequence numbers which are not yet allowed + + Receive Sequence Space + + Figure 5. + + + + The receive window is the portion of the sequence space labeled 2 in + figure 5. + + There are also some variables used frequently in the discussion that + take their values from the fields of the current segment. + + + + +[Page 20] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + Current Segment Variables + + SEG.SEQ - segment sequence number + SEG.ACK - segment acknowledgment number + SEG.LEN - segment length + SEG.WND - segment window + SEG.UP - segment urgent pointer + SEG.PRC - segment precedence value + + A connection progresses through a series of states during its + lifetime. The states are: LISTEN, SYN-SENT, SYN-RECEIVED, + ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, + TIME-WAIT, and the fictional state CLOSED. CLOSED is fictional + because it represents the state when there is no TCB, and therefore, + no connection. Briefly the meanings of the states are: + + LISTEN - represents waiting for a connection request from any remote + TCP and port. + + SYN-SENT - represents waiting for a matching connection request + after having sent a connection request. + + SYN-RECEIVED - represents waiting for a confirming connection + request acknowledgment after having both received and sent a + connection request. + + ESTABLISHED - represents an open connection, data received can be + delivered to the user. The normal state for the data transfer phase + of the connection. + + FIN-WAIT-1 - represents waiting for a connection termination request + from the remote TCP, or an acknowledgment of the connection + termination request previously sent. + + FIN-WAIT-2 - represents waiting for a connection termination request + from the remote TCP. + + CLOSE-WAIT - represents waiting for a connection termination request + from the local user. + + CLOSING - represents waiting for a connection termination request + acknowledgment from the remote TCP. + + LAST-ACK - represents waiting for an acknowledgment of the + connection termination request previously sent to the remote TCP + (which includes an acknowledgment of its connection termination + request). + + + + [Page 21] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + TIME-WAIT - represents waiting for enough time to pass to be sure + the remote TCP received the acknowledgment of its connection + termination request. + + CLOSED - represents no connection state at all. + + A TCP connection progresses from one state to another in response to + events. The events are the user calls, OPEN, SEND, RECEIVE, CLOSE, + ABORT, and STATUS; the incoming segments, particularly those + containing the SYN, ACK, RST and FIN flags; and timeouts. + + The state diagram in figure 6 illustrates only state changes, together + with the causing events and resulting actions, but addresses neither + error conditions nor actions which are not connected with state + changes. In a later section, more detail is offered with respect to + the reaction of the TCP to events. + + NOTE BENE: this diagram is only a summary and must not be taken as + the total specification. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 22] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + + +---------+ ---------\ active OPEN + | CLOSED | \ ----------- + +---------+<---------\ \ create TCB + | ^ \ \ snd SYN + passive OPEN | | CLOSE \ \ + ------------ | | ---------- \ \ + create TCB | | delete TCB \ \ + V | \ \ + +---------+ CLOSE | \ + | LISTEN | ---------- | | + +---------+ delete TCB | | + rcv SYN | | SEND | | + ----------- | | ------- | V + +---------+ snd SYN,ACK / \ snd SYN +---------+ + | |<----------------- ------------------>| | + | SYN | rcv SYN | SYN | + | RCVD |<-----------------------------------------------| SENT | + | | snd ACK | | + | |------------------ -------------------| | + +---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+ + | -------------- | | ----------- + | x | | snd ACK + | V V + | CLOSE +---------+ + | ------- | ESTAB | + | snd FIN +---------+ + | CLOSE | | rcv FIN + V ------- | | ------- + +---------+ snd FIN / \ snd ACK +---------+ + | FIN |<----------------- ------------------>| CLOSE | + | WAIT-1 |------------------ | WAIT | + +---------+ rcv FIN \ +---------+ + | rcv ACK of FIN ------- | CLOSE | + | -------------- snd ACK | ------- | + V x V snd FIN V + +---------+ +---------+ +---------+ + |FINWAIT-2| | CLOSING | | LAST-ACK| + +---------+ +---------+ +---------+ + | rcv ACK of FIN | rcv ACK of FIN | + | rcv FIN -------------- | Timeout=2MSL -------------- | + | ------- x V ------------ x V + \ snd ACK +---------+delete TCB +---------+ + ------------------------>|TIME WAIT|------------------>| CLOSED | + +---------+ +---------+ + + TCP Connection State Diagram + Figure 6. + + + [Page 23] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + +3.3. Sequence Numbers + + A fundamental notion in the design is that every octet of data sent + over a TCP connection has a sequence number. Since every octet is + sequenced, each of them can be acknowledged. The acknowledgment + mechanism employed is cumulative so that an acknowledgment of sequence + number X indicates that all octets up to but not including X have been + received. This mechanism allows for straight-forward duplicate + detection in the presence of retransmission. Numbering of octets + within a segment is that the first data octet immediately following + the header is the lowest numbered, and the following octets are + numbered consecutively. + + It is essential to remember that the actual sequence number space is + finite, though very large. This space ranges from 0 to 2**32 - 1. + Since the space is finite, all arithmetic dealing with sequence + numbers must be performed modulo 2**32. This unsigned arithmetic + preserves the relationship of sequence numbers as they cycle from + 2**32 - 1 to 0 again. There are some subtleties to computer modulo + arithmetic, so great care should be taken in programming the + comparison of such values. The symbol "=<" means "less than or equal" + (modulo 2**32). + + The typical kinds of sequence number comparisons which the TCP must + perform include: + + (a) Determining that an acknowledgment refers to some sequence + number sent but not yet acknowledged. + + (b) Determining that all sequence numbers occupied by a segment + have been acknowledged (e.g., to remove the segment from a + retransmission queue). + + (c) Determining that an incoming segment contains sequence numbers + which are expected (i.e., that the segment "overlaps" the + receive window). + + + + + + + + + + + + + + +[Page 24] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + In response to sending data the TCP will receive acknowledgments. The + following comparisons are needed to process the acknowledgments. + + SND.UNA = oldest unacknowledged sequence number + + SND.NXT = next sequence number to be sent + + SEG.ACK = acknowledgment from the receiving TCP (next sequence + number expected by the receiving TCP) + + SEG.SEQ = first sequence number of a segment + + SEG.LEN = the number of octets occupied by the data in the segment + (counting SYN and FIN) + + SEG.SEQ+SEG.LEN-1 = last sequence number of a segment + + A new acknowledgment (called an "acceptable ack"), is one for which + the inequality below holds: + + SND.UNA < SEG.ACK =< SND.NXT + + A segment on the retransmission queue is fully acknowledged if the sum + of its sequence number and length is less or equal than the + acknowledgment value in the incoming segment. + + When data is received the following comparisons are needed: + + RCV.NXT = next sequence number expected on an incoming segments, and + is the left or lower edge of the receive window + + RCV.NXT+RCV.WND-1 = last sequence number expected on an incoming + segment, and is the right or upper edge of the receive window + + SEG.SEQ = first sequence number occupied by the incoming segment + + SEG.SEQ+SEG.LEN-1 = last sequence number occupied by the incoming + segment + + A segment is judged to occupy a portion of valid receive sequence + space if + + RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND + + or + + RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND + + + + [Page 25] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + The first part of this test checks to see if the beginning of the + segment falls in the window, the second part of the test checks to see + if the end of the segment falls in the window; if the segment passes + either part of the test it contains data in the window. + + Actually, it is a little more complicated than this. Due to zero + windows and zero length segments, we have four cases for the + acceptability of an incoming segment: + + Segment Receive Test + Length Window + ------- ------- ------------------------------------------- + + 0 0 SEG.SEQ = RCV.NXT + + 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND + + >0 0 not acceptable + + >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND + or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND + + Note that when the receive window is zero no segments should be + acceptable except ACK segments. Thus, it is be possible for a TCP to + maintain a zero receive window while transmitting data and receiving + ACKs. However, even when the receive window is zero, a TCP must + process the RST and URG fields of all incoming segments. + + We have taken advantage of the numbering scheme to protect certain + control information as well. This is achieved by implicitly including + some control flags in the sequence space so they can be retransmitted + and acknowledged without confusion (i.e., one and only one copy of the + control will be acted upon). Control information is not physically + carried in the segment data space. Consequently, we must adopt rules + for implicitly assigning sequence numbers to control. The SYN and FIN + are the only controls requiring this protection, and these controls + are used only at connection opening and closing. For sequence number + purposes, the SYN is considered to occur before the first actual data + octet of the segment in which it occurs, while the FIN is considered + to occur after the last actual data octet in a segment in which it + occurs. The segment length (SEG.LEN) includes both data and sequence + space occupying controls. When a SYN is present then SEG.SEQ is the + sequence number of the SYN. + + + + + + + +[Page 26] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + Initial Sequence Number Selection + + The protocol places no restriction on a particular connection being + used over and over again. A connection is defined by a pair of + sockets. New instances of a connection will be referred to as + incarnations of the connection. The problem that arises from this is + -- "how does the TCP identify duplicate segments from previous + incarnations of the connection?" This problem becomes apparent if the + connection is being opened and closed in quick succession, or if the + connection breaks with loss of memory and is then reestablished. + + To avoid confusion we must prevent segments from one incarnation of a + connection from being used while the same sequence numbers may still + be present in the network from an earlier incarnation. We want to + assure this, even if a TCP crashes and loses all knowledge of the + sequence numbers it has been using. When new connections are created, + an initial sequence number (ISN) generator is employed which selects a + new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 + bit clock whose low order bit is incremented roughly every 4 + microseconds. Thus, the ISN cycles approximately every 4.55 hours. + Since we assume that segments will stay in the network no more than + the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55 + hours we can reasonably assume that ISN's will be unique. + + For each connection there is a send sequence number and a receive + sequence number. The initial send sequence number (ISS) is chosen by + the data sending TCP, and the initial receive sequence number (IRS) is + learned during the connection establishing procedure. + + For a connection to be established or initialized, the two TCPs must + synchronize on each other's initial sequence numbers. This is done in + an exchange of connection establishing segments carrying a control bit + called "SYN" (for synchronize) and the initial sequence numbers. As a + shorthand, segments carrying the SYN bit are also called "SYNs". + Hence, the solution requires a suitable mechanism for picking an + initial sequence number and a slightly involved handshake to exchange + the ISN's. + + The synchronization requires each side to send it's own initial + sequence number and to receive a confirmation of it in acknowledgment + from the other side. Each side must also receive the other side's + initial sequence number and send a confirming acknowledgment. + + 1) A --> B SYN my sequence number is X + 2) A <-- B ACK your sequence number is X + 3) A <-- B SYN my sequence number is Y + 4) A --> B ACK your sequence number is Y + + + + [Page 27] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + Because steps 2 and 3 can be combined in a single message this is + called the three way (or three message) handshake. + + A three way handshake is necessary because sequence numbers are not + tied to a global clock in the network, and TCPs may have different + mechanisms for picking the ISN's. The receiver of the first SYN has + no way of knowing whether the segment was an old delayed one or not, + unless it remembers the last sequence number used on the connection + (which is not always possible), and so it must ask the sender to + verify this SYN. The three way handshake and the advantages of a + clock-driven scheme are discussed in [3]. + + Knowing When to Keep Quiet + + To be sure that a TCP does not create a segment that carries a + sequence number which may be duplicated by an old segment remaining in + the network, the TCP must keep quiet for a maximum segment lifetime + (MSL) before assigning any sequence numbers upon starting up or + recovering from a crash in which memory of sequence numbers in use was + lost. For this specification the MSL is taken to be 2 minutes. This + is an engineering choice, and may be changed if experience indicates + it is desirable to do so. Note that if a TCP is reinitialized in some + sense, yet retains its memory of sequence numbers in use, then it need + not wait at all; it must only be sure to use sequence numbers larger + than those recently used. + + The TCP Quiet Time Concept + + This specification provides that hosts which "crash" without + retaining any knowledge of the last sequence numbers transmitted on + each active (i.e., not closed) connection shall delay emitting any + TCP segments for at least the agreed Maximum Segment Lifetime (MSL) + in the internet system of which the host is a part. In the + paragraphs below, an explanation for this specification is given. + TCP implementors may violate the "quiet time" restriction, but only + at the risk of causing some old data to be accepted as new or new + data rejected as old duplicated by some receivers in the internet + system. + + TCPs consume sequence number space each time a segment is formed and + entered into the network output queue at a source host. The + duplicate detection and sequencing algorithm in the TCP protocol + relies on the unique binding of segment data to sequence space to + the extent that sequence numbers will not cycle through all 2**32 + values before the segment data bound to those sequence numbers has + been delivered and acknowledged by the receiver and all duplicate + copies of the segments have "drained" from the internet. Without + such an assumption, two distinct TCP segments could conceivably be + + +[Page 28] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + assigned the same or overlapping sequence numbers, causing confusion + at the receiver as to which data is new and which is old. Remember + that each segment is bound to as many consecutive sequence numbers + as there are octets of data in the segment. + + Under normal conditions, TCPs keep track of the next sequence number + to emit and the oldest awaiting acknowledgment so as to avoid + mistakenly using a sequence number over before its first use has + been acknowledged. This alone does not guarantee that old duplicate + data is drained from the net, so the sequence space has been made + very large to reduce the probability that a wandering duplicate will + cause trouble upon arrival. At 2 megabits/sec. it takes 4.5 hours + to use up 2**32 octets of sequence space. Since the maximum segment + lifetime in the net is not likely to exceed a few tens of seconds, + this is deemed ample protection for foreseeable nets, even if data + rates escalate to l0's of megabits/sec. At 100 megabits/sec, the + cycle time is 5.4 minutes which may be a little short, but still + within reason. + + The basic duplicate detection and sequencing algorithm in TCP can be + defeated, however, if a source TCP does not have any memory of the + sequence numbers it last used on a given connection. For example, if + the TCP were to start all connections with sequence number 0, then + upon crashing and restarting, a TCP might re-form an earlier + connection (possibly after half-open connection resolution) and emit + packets with sequence numbers identical to or overlapping with + packets still in the network which were emitted on an earlier + incarnation of the same connection. In the absence of knowledge + about the sequence numbers used on a particular connection, the TCP + specification recommends that the source delay for MSL seconds + before emitting segments on the connection, to allow time for + segments from the earlier connection incarnation to drain from the + system. + + Even hosts which can remember the time of day and used it to select + initial sequence number values are not immune from this problem + (i.e., even if time of day is used to select an initial sequence + number for each new connection incarnation). + + Suppose, for example, that a connection is opened starting with + sequence number S. Suppose that this connection is not used much + and that eventually the initial sequence number function (ISN(t)) + takes on a value equal to the sequence number, say S1, of the last + segment sent by this TCP on a particular connection. Now suppose, + at this instant, the host crashes, recovers, and establishes a new + incarnation of the connection. The initial sequence number chosen is + S1 = ISN(t) -- last used sequence number on old incarnation of + connection! If the recovery occurs quickly enough, any old + + + [Page 29] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + duplicates in the net bearing sequence numbers in the neighborhood + of S1 may arrive and be treated as new packets by the receiver of + the new incarnation of the connection. + + The problem is that the recovering host may not know for how long it + crashed nor does it know whether there are still old duplicates in + the system from earlier connection incarnations. + + One way to deal with this problem is to deliberately delay emitting + segments for one MSL after recovery from a crash- this is the "quite + time" specification. Hosts which prefer to avoid waiting are + willing to risk possible confusion of old and new packets at a given + destination may choose not to wait for the "quite time". + Implementors may provide TCP users with the ability to select on a + connection by connection basis whether to wait after a crash, or may + informally implement the "quite time" for all connections. + Obviously, even where a user selects to "wait," this is not + necessary after the host has been "up" for at least MSL seconds. + + To summarize: every segment emitted occupies one or more sequence + numbers in the sequence space, the numbers occupied by a segment are + "busy" or "in use" until MSL seconds have passed, upon crashing a + block of space-time is occupied by the octets of the last emitted + segment, if a new connection is started too soon and uses any of the + sequence numbers in the space-time footprint of the last segment of + the previous connection incarnation, there is a potential sequence + number overlap area which could cause confusion at the receiver. + +3.4. Establishing a connection + + The "three-way handshake" is the procedure used to establish a + connection. This procedure normally is initiated by one TCP and + responded to by another TCP. The procedure also works if two TCP + simultaneously initiate the procedure. When simultaneous attempt + occurs, each TCP receives a "SYN" segment which carries no + acknowledgment after it has sent a "SYN". Of course, the arrival of + an old duplicate "SYN" segment can potentially make it appear, to the + recipient, that a simultaneous connection initiation is in progress. + Proper use of "reset" segments can disambiguate these cases. + + Several examples of connection initiation follow. Although these + examples do not show connection synchronization using data-carrying + segments, this is perfectly legitimate, so long as the receiving TCP + doesn't deliver the data to the user until it is clear the data is + valid (i.e., the data must be buffered at the receiver until the + connection reaches the ESTABLISHED state). The three-way handshake + reduces the possibility of false connections. It is the + + + +[Page 30] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + implementation of a trade-off between memory and messages to provide + information for this checking. + + The simplest three-way handshake is shown in figure 7 below. The + figures should be interpreted in the following way. Each line is + numbered for reference purposes. Right arrows (-->) indicate + departure of a TCP segment from TCP A to TCP B, or arrival of a + segment at B from A. Left arrows (<--), indicate the reverse. + Ellipsis (...) indicates a segment which is still in the network + (delayed). An "XXX" indicates a segment which is lost or rejected. + Comments appear in parentheses. TCP states represent the state AFTER + the departure or arrival of the segment (whose contents are shown in + the center of each line). Segment contents are shown in abbreviated + form, with sequence number, control flags, and ACK field. Other + fields such as window, addresses, lengths, and text have been left out + in the interest of clarity. + + + + TCP A TCP B + + 1. CLOSED LISTEN + + 2. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED + + 3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED + + 4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED + + 5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED + + Basic 3-Way Handshake for Connection Synchronization + + Figure 7. + + In line 2 of figure 7, TCP A begins by sending a SYN segment + indicating that it will use sequence numbers starting with sequence + number 100. In line 3, TCP B sends a SYN and acknowledges the SYN it + received from TCP A. Note that the acknowledgment field indicates TCP + B is now expecting to hear sequence 101, acknowledging the SYN which + occupied sequence 100. + + At line 4, TCP A responds with an empty segment containing an ACK for + TCP B's SYN; and in line 5, TCP A sends some data. Note that the + sequence number of the segment in line 5 is the same as in line 4 + because the ACK does not occupy sequence number space (if it did, we + would wind up ACKing ACK's!). + + + + [Page 31] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + Simultaneous initiation is only slightly more complex, as is shown in + figure 8. Each TCP cycles from CLOSED to SYN-SENT to SYN-RECEIVED to + ESTABLISHED. + + + + TCP A TCP B + + 1. CLOSED CLOSED + + 2. SYN-SENT --> <SEQ=100><CTL=SYN> ... + + 3. SYN-RECEIVED <-- <SEQ=300><CTL=SYN> <-- SYN-SENT + + 4. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED + + 5. SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ... + + 6. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED + + 7. ... <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED + + Simultaneous Connection Synchronization + + Figure 8. + + The principle reason for the three-way handshake is to prevent old + duplicate connection initiations from causing confusion. To deal with + this, a special control message, reset, has been devised. If the + receiving TCP is in a non-synchronized state (i.e., SYN-SENT, + SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset. + If the TCP is in one of the synchronized states (ESTABLISHED, + FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it + aborts the connection and informs its user. We discuss this latter + case under "half-open" connections below. + + + + + + + + + + + + + + + +[Page 32] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + + + TCP A TCP B + + 1. CLOSED LISTEN + + 2. SYN-SENT --> <SEQ=100><CTL=SYN> ... + + 3. (duplicate) ... <SEQ=90><CTL=SYN> --> SYN-RECEIVED + + 4. SYN-SENT <-- <SEQ=300><ACK=91><CTL=SYN,ACK> <-- SYN-RECEIVED + + 5. SYN-SENT --> <SEQ=91><CTL=RST> --> LISTEN + + + 6. ... <SEQ=100><CTL=SYN> --> SYN-RECEIVED + + 7. SYN-SENT <-- <SEQ=400><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED + + 8. ESTABLISHED --> <SEQ=101><ACK=401><CTL=ACK> --> ESTABLISHED + + Recovery from Old Duplicate SYN + + Figure 9. + + As a simple example of recovery from old duplicates, consider + figure 9. At line 3, an old duplicate SYN arrives at TCP B. TCP B + cannot tell that this is an old duplicate, so it responds normally + (line 4). TCP A detects that the ACK field is incorrect and returns a + RST (reset) with its SEQ field selected to make the segment + believable. TCP B, on receiving the RST, returns to the LISTEN state. + When the original SYN (pun intended) finally arrives at line 6, the + synchronization proceeds normally. If the SYN at line 6 had arrived + before the RST, a more complex exchange might have occurred with RST's + sent in both directions. + + Half-Open Connections and Other Anomalies + + An established connection is said to be "half-open" if one of the + TCPs has closed or aborted the connection at its end without the + knowledge of the other, or if the two ends of the connection have + become desynchronized owing to a crash that resulted in loss of + memory. Such connections will automatically become reset if an + attempt is made to send data in either direction. However, half-open + connections are expected to be unusual, and the recovery procedure is + mildly involved. + + If at site A the connection no longer exists, then an attempt by the + + + [Page 33] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + user at site B to send any data on it will result in the site B TCP + receiving a reset control message. Such a message indicates to the + site B TCP that something is wrong, and it is expected to abort the + connection. + + Assume that two user processes A and B are communicating with one + another when a crash occurs causing loss of memory to A's TCP. + Depending on the operating system supporting A's TCP, it is likely + that some error recovery mechanism exists. When the TCP is up again, + A is likely to start again from the beginning or from a recovery + point. As a result, A will probably try to OPEN the connection again + or try to SEND on the connection it believes open. In the latter + case, it receives the error message "connection not open" from the + local (A's) TCP. In an attempt to establish the connection, A's TCP + will send a segment containing SYN. This scenario leads to the + example shown in figure 10. After TCP A crashes, the user attempts to + re-open the connection. TCP B, in the meantime, thinks the connection + is open. + + + + TCP A TCP B + + 1. (CRASH) (send 300,receive 100) + + 2. CLOSED ESTABLISHED + + 3. SYN-SENT --> <SEQ=400><CTL=SYN> --> (??) + + 4. (!!) <-- <SEQ=300><ACK=100><CTL=ACK> <-- ESTABLISHED + + 5. SYN-SENT --> <SEQ=100><CTL=RST> --> (Abort!!) + + 6. SYN-SENT CLOSED + + 7. SYN-SENT --> <SEQ=400><CTL=SYN> --> + + Half-Open Connection Discovery + + Figure 10. + + When the SYN arrives at line 3, TCP B, being in a synchronized state, + and the incoming segment outside the window, responds with an + acknowledgment indicating what sequence it next expects to hear (ACK + 100). TCP A sees that this segment does not acknowledge anything it + sent and, being unsynchronized, sends a reset (RST) because it has + detected a half-open connection. TCP B aborts at line 5. TCP A will + + + +[Page 34] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + continue to try to establish the connection; the problem is now + reduced to the basic 3-way handshake of figure 7. + + An interesting alternative case occurs when TCP A crashes and TCP B + tries to send data on what it thinks is a synchronized connection. + This is illustrated in figure 11. In this case, the data arriving at + TCP A from TCP B (line 2) is unacceptable because no such connection + exists, so TCP A sends a RST. The RST is acceptable so TCP B + processes it and aborts the connection. + + + + TCP A TCP B + + 1. (CRASH) (send 300,receive 100) + + 2. (??) <-- <SEQ=300><ACK=100><DATA=10><CTL=ACK> <-- ESTABLISHED + + 3. --> <SEQ=100><CTL=RST> --> (ABORT!!) + + Active Side Causes Half-Open Connection Discovery + + Figure 11. + + In figure 12, we find the two TCPs A and B with passive connections + waiting for SYN. An old duplicate arriving at TCP B (line 2) stirs B + into action. A SYN-ACK is returned (line 3) and causes TCP A to + generate a RST (the ACK in line 3 is not acceptable). TCP B accepts + the reset and returns to its passive LISTEN state. + + + + TCP A TCP B + + 1. LISTEN LISTEN + + 2. ... <SEQ=Z><CTL=SYN> --> SYN-RECEIVED + + 3. (??) <-- <SEQ=X><ACK=Z+1><CTL=SYN,ACK> <-- SYN-RECEIVED + + 4. --> <SEQ=Z+1><CTL=RST> --> (return to LISTEN!) + + 5. LISTEN LISTEN + + Old Duplicate SYN Initiates a Reset on two Passive Sockets + + Figure 12. + + + + [Page 35] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + A variety of other cases are possible, all of which are accounted for + by the following rules for RST generation and processing. + + Reset Generation + + As a general rule, reset (RST) must be sent whenever a segment arrives + which apparently is not intended for the current connection. A reset + must not be sent if it is not clear that this is the case. + + There are three groups of states: + + 1. If the connection does not exist (CLOSED) then a reset is sent + in response to any incoming segment except another reset. In + particular, SYNs addressed to a non-existent connection are rejected + by this means. + + If the incoming segment has an ACK field, the reset takes its + sequence number from the ACK field of the segment, otherwise the + reset has sequence number zero and the ACK field is set to the sum + of the sequence number and segment length of the incoming segment. + The connection remains in the CLOSED state. + + 2. If the connection is in any non-synchronized state (LISTEN, + SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges + something not yet sent (the segment carries an unacceptable ACK), or + if an incoming segment has a security level or compartment which + does not exactly match the level and compartment requested for the + connection, a reset is sent. + + If our SYN has not been acknowledged and the precedence level of the + incoming segment is higher than the precedence level requested then + either raise the local precedence level (if allowed by the user and + the system) or send a reset; or if the precedence level of the + incoming segment is lower than the precedence level requested then + continue as if the precedence matched exactly (if the remote TCP + cannot raise the precedence level to match ours this will be + detected in the next segment it sends, and the connection will be + terminated then). If our SYN has been acknowledged (perhaps in this + incoming segment) the precedence level of the incoming segment must + match the local precedence level exactly, if it does not a reset + must be sent. + + If the incoming segment has an ACK field, the reset takes its + sequence number from the ACK field of the segment, otherwise the + reset has sequence number zero and the ACK field is set to the sum + of the sequence number and segment length of the incoming segment. + The connection remains in the same state. + + + +[Page 36] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + 3. If the connection is in a synchronized state (ESTABLISHED, + FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), + any unacceptable segment (out of window sequence number or + unacceptible acknowledgment number) must elicit only an empty + acknowledgment segment containing the current send-sequence number + and an acknowledgment indicating the next sequence number expected + to be received, and the connection remains in the same state. + + If an incoming segment has a security level, or compartment, or + precedence which does not exactly match the level, and compartment, + and precedence requested for the connection,a reset is sent and + connection goes to the CLOSED state. The reset takes its sequence + number from the ACK field of the incoming segment. + + Reset Processing + + In all states except SYN-SENT, all reset (RST) segments are validated + by checking their SEQ-fields. A reset is valid if its sequence number + is in the window. In the SYN-SENT state (a RST received in response + to an initial SYN), the RST is acceptable if the ACK field + acknowledges the SYN. + + The receiver of a RST first validates it, then changes state. If the + receiver was in the LISTEN state, it ignores it. If the receiver was + in SYN-RECEIVED state and had previously been in the LISTEN state, + then the receiver returns to the LISTEN state, otherwise the receiver + aborts the connection and goes to the CLOSED state. If the receiver + was in any other state, it aborts the connection and advises the user + and goes to the CLOSED state. + +3.5. Closing a Connection + + CLOSE is an operation meaning "I have no more data to send." The + notion of closing a full-duplex connection is subject to ambiguous + interpretation, of course, since it may not be obvious how to treat + the receiving side of the connection. We have chosen to treat CLOSE + in a simplex fashion. The user who CLOSEs may continue to RECEIVE + until he is told that the other side has CLOSED also. Thus, a program + could initiate several SENDs followed by a CLOSE, and then continue to + RECEIVE until signaled that a RECEIVE failed because the other side + has CLOSED. We assume that the TCP will signal a user, even if no + RECEIVEs are outstanding, that the other side has closed, so the user + can terminate his side gracefully. A TCP will reliably deliver all + buffers SENT before the connection was CLOSED so a user who expects no + data in return need only wait to hear the connection was CLOSED + successfully to know that all his data was received at the destination + TCP. Users must keep reading connections they close for sending until + the TCP says no more data. + + + [Page 37] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + There are essentially three cases: + + 1) The user initiates by telling the TCP to CLOSE the connection + + 2) The remote TCP initiates by sending a FIN control signal + + 3) Both users CLOSE simultaneously + + Case 1: Local user initiates the close + + In this case, a FIN segment can be constructed and placed on the + outgoing segment queue. No further SENDs from the user will be + accepted by the TCP, and it enters the FIN-WAIT-1 state. RECEIVEs + are allowed in this state. All segments preceding and including FIN + will be retransmitted until acknowledged. When the other TCP has + both acknowledged the FIN and sent a FIN of its own, the first TCP + can ACK this FIN. Note that a TCP receiving a FIN will ACK but not + send its own FIN until its user has CLOSED the connection also. + + Case 2: TCP receives a FIN from the network + + If an unsolicited FIN arrives from the network, the receiving TCP + can ACK it and tell the user that the connection is closing. The + user will respond with a CLOSE, upon which the TCP can send a FIN to + the other TCP after sending any remaining data. The TCP then waits + until its own FIN is acknowledged whereupon it deletes the + connection. If an ACK is not forthcoming, after the user timeout + the connection is aborted and the user is told. + + Case 3: both users close simultaneously + + A simultaneous CLOSE by users at both ends of a connection causes + FIN segments to be exchanged. When all segments preceding the FINs + have been processed and acknowledged, each TCP can ACK the FIN it + has received. Both will, upon receiving these ACKs, delete the + connection. + + + + + + + + + + + + + + +[Page 38] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + + + TCP A TCP B + + 1. ESTABLISHED ESTABLISHED + + 2. (Close) + FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> --> CLOSE-WAIT + + 3. FIN-WAIT-2 <-- <SEQ=300><ACK=101><CTL=ACK> <-- CLOSE-WAIT + + 4. (Close) + TIME-WAIT <-- <SEQ=300><ACK=101><CTL=FIN,ACK> <-- LAST-ACK + + 5. TIME-WAIT --> <SEQ=101><ACK=301><CTL=ACK> --> CLOSED + + 6. (2 MSL) + CLOSED + + Normal Close Sequence + + Figure 13. + + + + TCP A TCP B + + 1. ESTABLISHED ESTABLISHED + + 2. (Close) (Close) + FIN-WAIT-1 --> <SEQ=100><ACK=300><CTL=FIN,ACK> ... FIN-WAIT-1 + <-- <SEQ=300><ACK=100><CTL=FIN,ACK> <-- + ... <SEQ=100><ACK=300><CTL=FIN,ACK> --> + + 3. CLOSING --> <SEQ=101><ACK=301><CTL=ACK> ... CLOSING + <-- <SEQ=301><ACK=101><CTL=ACK> <-- + ... <SEQ=101><ACK=301><CTL=ACK> --> + + 4. TIME-WAIT TIME-WAIT + (2 MSL) (2 MSL) + CLOSED CLOSED + + Simultaneous Close Sequence + + Figure 14. + + + + + + [Page 39] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + +3.6. Precedence and Security + + The intent is that connection be allowed only between ports operating + with exactly the same security and compartment values and at the + higher of the precedence level requested by the two ports. + + The precedence and security parameters used in TCP are exactly those + defined in the Internet Protocol (IP) [2]. Throughout this TCP + specification the term "security/compartment" is intended to indicate + the security parameters used in IP including security, compartment, + user group, and handling restriction. + + A connection attempt with mismatched security/compartment values or a + lower precedence value must be rejected by sending a reset. Rejecting + a connection due to too low a precedence only occurs after an + acknowledgment of the SYN has been received. + + Note that TCP modules which operate only at the default value of + precedence will still have to check the precedence of incoming + segments and possibly raise the precedence level they use on the + connection. + + The security paramaters may be used even in a non-secure environment + (the values would indicate unclassified data), thus hosts in + non-secure environments must be prepared to receive the security + parameters, though they need not send them. + +3.7. Data Communication + + Once the connection is established data is communicated by the + exchange of segments. Because segments may be lost due to errors + (checksum test failure), or network congestion, TCP uses + retransmission (after a timeout) to ensure delivery of every segment. + Duplicate segments may arrive due to network or TCP retransmission. + As discussed in the section on sequence numbers the TCP performs + certain tests on the sequence and acknowledgment numbers in the + segments to verify their acceptability. + + The sender of data keeps track of the next sequence number to use in + the variable SND.NXT. The receiver of data keeps track of the next + sequence number to expect in the variable RCV.NXT. The sender of data + keeps track of the oldest unacknowledged sequence number in the + variable SND.UNA. If the data flow is momentarily idle and all data + sent has been acknowledged then the three variables will be equal. + + When the sender creates a segment and transmits it the sender advances + SND.NXT. When the receiver accepts a segment it advances RCV.NXT and + sends an acknowledgment. When the data sender receives an + + +[Page 40] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + acknowledgment it advances SND.UNA. The extent to which the values of + these variables differ is a measure of the delay in the communication. + The amount by which the variables are advanced is the length of the + data in the segment. Note that once in the ESTABLISHED state all + segments must carry current acknowledgment information. + + The CLOSE user call implies a push function, as does the FIN control + flag in an incoming segment. + + Retransmission Timeout + + Because of the variability of the networks that compose an + internetwork system and the wide range of uses of TCP connections the + retransmission timeout must be dynamically determined. One procedure + for determining a retransmission time out is given here as an + illustration. + + An Example Retransmission Timeout Procedure + + Measure the elapsed time between sending a data octet with a + particular sequence number and receiving an acknowledgment that + covers that sequence number (segments sent do not have to match + segments received). This measured elapsed time is the Round Trip + Time (RTT). Next compute a Smoothed Round Trip Time (SRTT) as: + + SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT) + + and based on this, compute the retransmission timeout (RTO) as: + + RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]] + + where UBOUND is an upper bound on the timeout (e.g., 1 minute), + LBOUND is a lower bound on the timeout (e.g., 1 second), ALPHA is + a smoothing factor (e.g., .8 to .9), and BETA is a delay variance + factor (e.g., 1.3 to 2.0). + + The Communication of Urgent Information + + The objective of the TCP urgent mechanism is to allow the sending user + to stimulate the receiving user to accept some urgent data and to + permit the receiving TCP to indicate to the receiving user when all + the currently known urgent data has been received by the user. + + This mechanism permits a point in the data stream to be designated as + the end of urgent information. Whenever this point is in advance of + the receive sequence number (RCV.NXT) at the receiving TCP, that TCP + must tell the user to go into "urgent mode"; when the receive sequence + number catches up to the urgent pointer, the TCP must tell user to go + + + [Page 41] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + into "normal mode". If the urgent pointer is updated while the user + is in "urgent mode", the update will be invisible to the user. + + The method employs a urgent field which is carried in all segments + transmitted. The URG control flag indicates that the urgent field is + meaningful and must be added to the segment sequence number to yield + the urgent pointer. The absence of this flag indicates that there is + no urgent data outstanding. + + To send an urgent indication the user must also send at least one data + octet. If the sending user also indicates a push, timely delivery of + the urgent information to the destination process is enhanced. + + Managing the Window + + The window sent in each segment indicates the range of sequence + numbers the sender of the window (the data receiver) is currently + prepared to accept. There is an assumption that this is related to + the currently available data buffer space available for this + connection. + + Indicating a large window encourages transmissions. If more data + arrives than can be accepted, it will be discarded. This will result + in excessive retransmissions, adding unnecessarily to the load on the + network and the TCPs. Indicating a small window may restrict the + transmission of data to the point of introducing a round trip delay + between each new segment transmitted. + + The mechanisms provided allow a TCP to advertise a large window and to + subsequently advertise a much smaller window without having accepted + that much data. This, so called "shrinking the window," is strongly + discouraged. The robustness principle dictates that TCPs will not + shrink the window themselves, but will be prepared for such behavior + on the part of other TCPs. + + The sending TCP must be prepared to accept from the user and send at + least one octet of new data even if the send window is zero. The + sending TCP must regularly retransmit to the receiving TCP even when + the window is zero. Two minutes is recommended for the retransmission + interval when the window is zero. This retransmission is essential to + guarantee that when either TCP has a zero window the re-opening of the + window will be reliably reported to the other. + + When the receiving TCP has a zero window and a segment arrives it must + still send an acknowledgment showing its next expected sequence number + and current window (zero). + + The sending TCP packages the data to be transmitted into segments + + +[Page 42] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + which fit the current window, and may repackage segments on the + retransmission queue. Such repackaging is not required, but may be + helpful. + + In a connection with a one-way data flow, the window information will + be carried in acknowledgment segments that all have the same sequence + number so there will be no way to reorder them if they arrive out of + order. This is not a serious problem, but it will allow the window + information to be on occasion temporarily based on old reports from + the data receiver. A refinement to avoid this problem is to act on + the window information from segments that carry the highest + acknowledgment number (that is segments with acknowledgment number + equal or greater than the highest previously received). + + The window management procedure has significant influence on the + communication performance. The following comments are suggestions to + implementers. + + Window Management Suggestions + + Allocating a very small window causes data to be transmitted in + many small segments when better performance is achieved using + fewer large segments. + + One suggestion for avoiding small windows is for the receiver to + defer updating a window until the additional allocation is at + least X percent of the maximum allocation possible for the + connection (where X might be 20 to 40). + + Another suggestion is for the sender to avoid sending small + segments by waiting until the window is large enough before + sending data. If the the user signals a push function then the + data must be sent even if it is a small segment. + + Note that the acknowledgments should not be delayed or unnecessary + retransmissions will result. One strategy would be to send an + acknowledgment when a small segment arrives (with out updating the + window information), and then to send another acknowledgment with + new window information when the window is larger. + + The segment sent to probe a zero window may also begin a break up + of transmitted data into smaller and smaller segments. If a + segment containing a single data octet sent to probe a zero window + is accepted, it consumes one octet of the window now available. + If the sending TCP simply sends as much as it can whenever the + window is non zero, the transmitted data will be broken into + alternating big and small segments. As time goes on, occasional + pauses in the receiver making window allocation available will + + + [Page 43] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + result in breaking the big segments into a small and not quite so + big pair. And after a while the data transmission will be in + mostly small segments. + + The suggestion here is that the TCP implementations need to + actively attempt to combine small window allocations into larger + windows, since the mechanisms for managing the window tend to lead + to many small windows in the simplest minded implementations. + +3.8. Interfaces + + There are of course two interfaces of concern: the user/TCP interface + and the TCP/lower-level interface. We have a fairly elaborate model + of the user/TCP interface, but the interface to the lower level + protocol module is left unspecified here, since it will be specified + in detail by the specification of the lowel level protocol. For the + case that the lower level is IP we note some of the parameter values + that TCPs might use. + + User/TCP Interface + + The following functional description of user commands to the TCP is, + at best, fictional, since every operating system will have different + facilities. Consequently, we must warn readers that different TCP + implementations may have different user interfaces. However, all + TCPs must provide a certain minimum set of services to guarantee + that all TCP implementations can support the same protocol + hierarchy. This section specifies the functional interfaces + required of all TCP implementations. + + TCP User Commands + + The following sections functionally characterize a USER/TCP + interface. The notation used is similar to most procedure or + function calls in high level languages, but this usage is not + meant to rule out trap type service calls (e.g., SVCs, UUOs, + EMTs). + + The user commands described below specify the basic functions the + TCP must perform to support interprocess communication. + Individual implementations must define their own exact format, and + may provide combinations or subsets of the basic functions in + single calls. In particular, some implementations may wish to + automatically OPEN a connection on the first SEND or RECEIVE + issued by the user for a given connection. + + + + + +[Page 44] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + In providing interprocess communication facilities, the TCP must + not only accept commands, but must also return information to the + processes it serves. The latter consists of: + + (a) general information about a connection (e.g., interrupts, + remote close, binding of unspecified foreign socket). + + (b) replies to specific user commands indicating success or + various types of failure. + + Open + + Format: OPEN (local port, foreign socket, active/passive + [, timeout] [, precedence] [, security/compartment] [, options]) + -> local connection name + + We assume that the local TCP is aware of the identity of the + processes it serves and will check the authority of the process + to use the connection specified. Depending upon the + implementation of the TCP, the local network and TCP identifiers + for the source address will either be supplied by the TCP or the + lower level protocol (e.g., IP). These considerations are the + result of concern about security, to the extent that no TCP be + able to masquerade as another one, and so on. Similarly, no + process can masquerade as another without the collusion of the + TCP. + + If the active/passive flag is set to passive, then this is a + call to LISTEN for an incoming connection. A passive open may + have either a fully specified foreign socket to wait for a + particular connection or an unspecified foreign socket to wait + for any call. A fully specified passive call can be made active + by the subsequent execution of a SEND. + + A transmission control block (TCB) is created and partially + filled in with data from the OPEN command parameters. + + On an active OPEN command, the TCP will begin the procedure to + synchronize (i.e., establish) the connection at once. + + The timeout, if present, permits the caller to set up a timeout + for all data submitted to TCP. If data is not successfully + delivered to the destination within the timeout period, the TCP + will abort the connection. The present global default is five + minutes. + + The TCP or some component of the operating system will verify + the users authority to open a connection with the specified + + + [Page 45] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + precedence or security/compartment. The absence of precedence + or security/compartment specification in the OPEN call indicates + the default values must be used. + + TCP will accept incoming requests as matching only if the + security/compartment information is exactly the same and only if + the precedence is equal to or higher than the precedence + requested in the OPEN call. + + The precedence for the connection is the higher of the values + requested in the OPEN call and received from the incoming + request, and fixed at that value for the life of the + connection.Implementers may want to give the user control of + this precedence negotiation. For example, the user might be + allowed to specify that the precedence must be exactly matched, + or that any attempt to raise the precedence be confirmed by the + user. + + A local connection name will be returned to the user by the TCP. + The local connection name can then be used as a short hand term + for the connection defined by the <local socket, foreign socket> + pair. + + Send + + Format: SEND (local connection name, buffer address, byte + count, PUSH flag, URGENT flag [,timeout]) + + This call causes the data contained in the indicated user buffer + to be sent on the indicated connection. If the connection has + not been opened, the SEND is considered an error. Some + implementations may allow users to SEND first; in which case, an + automatic OPEN would be done. If the calling process is not + authorized to use this connection, an error is returned. + + If the PUSH flag is set, the data must be transmitted promptly + to the receiver, and the PUSH bit will be set in the last TCP + segment created from the buffer. If the PUSH flag is not set, + the data may be combined with data from subsequent SENDs for + transmission efficiency. + + If the URGENT flag is set, segments sent to the destination TCP + will have the urgent pointer set. The receiving TCP will signal + the urgent condition to the receiving process if the urgent + pointer indicates that data preceding the urgent pointer has not + been consumed by the receiving process. The purpose of urgent + is to stimulate the receiver to process the urgent data and to + indicate to the receiver when all the currently known urgent + + +[Page 46] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + data has been received. The number of times the sending user's + TCP signals urgent will not necessarily be equal to the number + of times the receiving user will be notified of the presence of + urgent data. + + If no foreign socket was specified in the OPEN, but the + connection is established (e.g., because a LISTENing connection + has become specific due to a foreign segment arriving for the + local socket), then the designated buffer is sent to the implied + foreign socket. Users who make use of OPEN with an unspecified + foreign socket can make use of SEND without ever explicitly + knowing the foreign socket address. + + However, if a SEND is attempted before the foreign socket + becomes specified, an error will be returned. Users can use the + STATUS call to determine the status of the connection. In some + implementations the TCP may notify the user when an unspecified + socket is bound. + + If a timeout is specified, the current user timeout for this + connection is changed to the new one. + + In the simplest implementation, SEND would not return control to + the sending process until either the transmission was complete + or the timeout had been exceeded. However, this simple method + is both subject to deadlocks (for example, both sides of the + connection might try to do SENDs before doing any RECEIVEs) and + offers poor performance, so it is not recommended. A more + sophisticated implementation would return immediately to allow + the process to run concurrently with network I/O, and, + furthermore, to allow multiple SENDs to be in progress. + Multiple SENDs are served in first come, first served order, so + the TCP will queue those it cannot service immediately. + + We have implicitly assumed an asynchronous user interface in + which a SEND later elicits some kind of SIGNAL or + pseudo-interrupt from the serving TCP. An alternative is to + return a response immediately. For instance, SENDs might return + immediate local acknowledgment, even if the segment sent had not + been acknowledged by the distant TCP. We could optimistically + assume eventual success. If we are wrong, the connection will + close anyway due to the timeout. In implementations of this + kind (synchronous), there will still be some asynchronous + signals, but these will deal with the connection itself, and not + with specific segments or buffers. + + In order for the process to distinguish among error or success + indications for different SENDs, it might be appropriate for the + + + [Page 47] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + buffer address to be returned along with the coded response to + the SEND request. TCP-to-user signals are discussed below, + indicating the information which should be returned to the + calling process. + + Receive + + Format: RECEIVE (local connection name, buffer address, byte + count) -> byte count, urgent flag, push flag + + This command allocates a receiving buffer associated with the + specified connection. If no OPEN precedes this command or the + calling process is not authorized to use this connection, an + error is returned. + + In the simplest implementation, control would not return to the + calling program until either the buffer was filled, or some + error occurred, but this scheme is highly subject to deadlocks. + A more sophisticated implementation would permit several + RECEIVEs to be outstanding at once. These would be filled as + segments arrive. This strategy permits increased throughput at + the cost of a more elaborate scheme (possibly asynchronous) to + notify the calling program that a PUSH has been seen or a buffer + filled. + + If enough data arrive to fill the buffer before a PUSH is seen, + the PUSH flag will not be set in the response to the RECEIVE. + The buffer will be filled with as much data as it can hold. If + a PUSH is seen before the buffer is filled the buffer will be + returned partially filled and PUSH indicated. + + If there is urgent data the user will have been informed as soon + as it arrived via a TCP-to-user signal. The receiving user + should thus be in "urgent mode". If the URGENT flag is on, + additional urgent data remains. If the URGENT flag is off, this + call to RECEIVE has returned all the urgent data, and the user + may now leave "urgent mode". Note that data following the + urgent pointer (non-urgent data) cannot be delivered to the user + in the same buffer with preceeding urgent data unless the + boundary is clearly marked for the user. + + To distinguish among several outstanding RECEIVEs and to take + care of the case that a buffer is not completely filled, the + return code is accompanied by both a buffer pointer and a byte + count indicating the actual length of the data received. + + Alternative implementations of RECEIVE might have the TCP + + + +[Page 48] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + allocate buffer storage, or the TCP might share a ring buffer + with the user. + + Close + + Format: CLOSE (local connection name) + + This command causes the connection specified to be closed. If + the connection is not open or the calling process is not + authorized to use this connection, an error is returned. + Closing connections is intended to be a graceful operation in + the sense that outstanding SENDs will be transmitted (and + retransmitted), as flow control permits, until all have been + serviced. Thus, it should be acceptable to make several SEND + calls, followed by a CLOSE, and expect all the data to be sent + to the destination. It should also be clear that users should + continue to RECEIVE on CLOSING connections, since the other side + may be trying to transmit the last of its data. Thus, CLOSE + means "I have no more to send" but does not mean "I will not + receive any more." It may happen (if the user level protocol is + not well thought out) that the closing side is unable to get rid + of all its data before timing out. In this event, CLOSE turns + into ABORT, and the closing TCP gives up. + + The user may CLOSE the connection at any time on his own + initiative, or in response to various prompts from the TCP + (e.g., remote close executed, transmission timeout exceeded, + destination inaccessible). + + Because closing a connection requires communication with the + foreign TCP, connections may remain in the closing state for a + short time. Attempts to reopen the connection before the TCP + replies to the CLOSE command will result in error responses. + + Close also implies push function. + + Status + + Format: STATUS (local connection name) -> status data + + This is an implementation dependent user command and could be + excluded without adverse effect. Information returned would + typically come from the TCB associated with the connection. + + This command returns a data block containing the following + information: + + local socket, + + + [Page 49] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + + foreign socket, + local connection name, + receive window, + send window, + connection state, + number of buffers awaiting acknowledgment, + number of buffers pending receipt, + urgent state, + precedence, + security/compartment, + and transmission timeout. + + Depending on the state of the connection, or on the + implementation itself, some of this information may not be + available or meaningful. If the calling process is not + authorized to use this connection, an error is returned. This + prevents unauthorized processes from gaining information about a + connection. + + Abort + + Format: ABORT (local connection name) + + This command causes all pending SENDs and RECEIVES to be + aborted, the TCB to be removed, and a special RESET message to + be sent to the TCP on the other side of the connection. + Depending on the implementation, users may receive abort + indications for each outstanding SEND or RECEIVE, or may simply + receive an ABORT-acknowledgment. + + TCP-to-User Messages + + It is assumed that the operating system environment provides a + means for the TCP to asynchronously signal the user program. When + the TCP does signal a user program, certain information is passed + to the user. Often in the specification the information will be + an error message. In other cases there will be information + relating to the completion of processing a SEND or RECEIVE or + other user call. + + The following information is provided: + + Local Connection Name Always + Response String Always + Buffer Address Send & Receive + Byte count (counts bytes received) Receive + Push flag Receive + Urgent flag Receive + + +[Page 50] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + TCP/Lower-Level Interface + + The TCP calls on a lower level protocol module to actually send and + receive information over a network. One case is that of the ARPA + internetwork system where the lower level module is the Internet + Protocol (IP) [2]. + + If the lower level protocol is IP it provides arguments for a type + of service and for a time to live. TCP uses the following settings + for these parameters: + + Type of Service = Precedence: routine, Delay: normal, Throughput: + normal, Reliability: normal; or 00000000. + + Time to Live = one minute, or 00111100. + + Note that the assumed maximum segment lifetime is two minutes. + Here we explicitly ask that a segment be destroyed if it cannot + be delivered by the internet system within one minute. + + If the lower level is IP (or other protocol that provides this + feature) and source routing is used, the interface must allow the + route information to be communicated. This is especially important + so that the source and destination addresses used in the TCP + checksum be the originating source and ultimate destination. It is + also important to preserve the return route to answer connection + requests. + + Any lower level protocol will have to provide the source address, + destination address, and protocol fields, and some way to determine + the "TCP length", both to provide the functional equivlent service + of IP and to be used in the TCP checksum. + + + + + + + + + + + + + + + + + + + [Page 51] + + + September 1981 +Transmission Control Protocol +Functional Specification + + + +3.9. Event Processing + + The processing depicted in this section is an example of one possible + implementation. Other implementations may have slightly different + processing sequences, but they should differ from those in this + section only in detail, not in substance. + + The activity of the TCP can be characterized as responding to events. + The events that occur can be cast into three categories: user calls, + arriving segments, and timeouts. This section describes the + processing the TCP does in response to each of the events. In many + cases the processing required depends on the state of the connection. + + Events that occur: + + User Calls + + OPEN + SEND + RECEIVE + CLOSE + ABORT + STATUS + + Arriving Segments + + SEGMENT ARRIVES + + Timeouts + + USER TIMEOUT + RETRANSMISSION TIMEOUT + TIME-WAIT TIMEOUT + + The model of the TCP/user interface is that user commands receive an + immediate return and possibly a delayed response via an event or + pseudo interrupt. In the following descriptions, the term "signal" + means cause a delayed response. + + Error responses are given as character strings. For example, user + commands referencing connections that do not exist receive "error: + connection not open". + + Please note in the following that all arithmetic on sequence numbers, + acknowledgment numbers, windows, et cetera, is modulo 2**32 the size + of the sequence number space. Also note that "=<" means less than or + equal to (modulo 2**32). + + + +[Page 52] + + +September 1981 + Transmission Control Protocol + Functional Specification + + + + A natural way to think about processing incoming segments is to + imagine that they are first tested for proper sequence number (i.e., + that their contents lie in the range of the expected "receive window" + in the sequence number space) and then that they are generally queued + and processed in sequence number order. + + When a segment overlaps other already received segments we reconstruct + the segment to contain just the new data, and adjust the header fields + to be consistent. + + Note that if no state change is mentioned the TCP stays in the same + state. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [Page 53] + + + September 1981 +Transmission Control Protocol +Functional Specification + OPEN Call + + + + OPEN Call + + CLOSED STATE (i.e., TCB does not exist) + + Create a new transmission control block (TCB) to hold connection + state information. Fill in local socket identifier, foreign + socket, precedence, security/compartment, and user timeout + information. Note that some parts of the foreign socket may be + unspecified in a passive OPEN and are to be filled in by the + parameters of the incoming SYN segment. Verify the security and + precedence requested are allowed for this user, if not return + "error: precedence not allowed" or "error: security/compartment + not allowed." If passive enter the LISTEN state and return. If + active and the foreign socket is unspecified, return "error: + foreign socket unspecified"; if active and the foreign socket is + specified, issue a SYN segment. An initial send sequence number + (ISS) is selected. A SYN segment of the form <SEQ=ISS><CTL=SYN> + is sent. Set SND.UNA to ISS, SND.NXT to ISS+1, enter SYN-SENT + state, and return. + + If the caller does not have access to the local socket specified, + return "error: connection illegal for this process". If there is + no room to create a new connection, return "error: insufficient + resources". + + LISTEN STATE + + If active and the foreign socket is specified, then change the + connection from passive to active, select an ISS. Send a SYN + segment, set SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT + state. Data associated with SEND may be sent with SYN segment or + queued for transmission after entering ESTABLISHED state. The + urgent bit if requested in the command must be sent with the data + segments sent as a result of this command. If there is no room to + queue the request, respond with "error: insufficient resources". + If Foreign socket was not specified, then return "error: foreign + socket unspecified". + + + + + + + + + + + + +[Page 54] + + +September 1981 + Transmission Control Protocol + Functional Specification +OPEN Call + + + + SYN-SENT STATE + SYN-RECEIVED STATE + ESTABLISHED STATE + FIN-WAIT-1 STATE + FIN-WAIT-2 STATE + CLOSE-WAIT STATE + CLOSING STATE + LAST-ACK STATE + TIME-WAIT STATE + + Return "error: connection already exists". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [Page 55] + + + September 1981 +Transmission Control Protocol +Functional Specification + SEND Call + + + + SEND Call + + CLOSED STATE (i.e., TCB does not exist) + + If the user does not have access to such a connection, then return + "error: connection illegal for this process". + + Otherwise, return "error: connection does not exist". + + LISTEN STATE + + If the foreign socket is specified, then change the connection + from passive to active, select an ISS. Send a SYN segment, set + SND.UNA to ISS, SND.NXT to ISS+1. Enter SYN-SENT state. Data + associated with SEND may be sent with SYN segment or queued for + transmission after entering ESTABLISHED state. The urgent bit if + requested in the command must be sent with the data segments sent + as a result of this command. If there is no room to queue the + request, respond with "error: insufficient resources". If + Foreign socket was not specified, then return "error: foreign + socket unspecified". + + SYN-SENT STATE + SYN-RECEIVED STATE + + Queue the data for transmission after entering ESTABLISHED state. + If no space to queue, respond with "error: insufficient + resources". + + ESTABLISHED STATE + CLOSE-WAIT STATE + + Segmentize the buffer and send it with a piggybacked + acknowledgment (acknowledgment value = RCV.NXT). If there is + insufficient space to remember this buffer, simply return "error: + insufficient resources". + + If the urgent flag is set, then SND.UP <- SND.NXT-1 and set the + urgent pointer in the outgoing segments. + + + + + + + + + + +[Page 56] + + +September 1981 + Transmission Control Protocol + Functional Specification +SEND Call + + + + FIN-WAIT-1 STATE + FIN-WAIT-2 STATE + CLOSING STATE + LAST-ACK STATE + TIME-WAIT STATE + + Return "error: connection closing" and do not service request. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [Page 57] + + + September 1981 +Transmission Control Protocol +Functional Specification + RECEIVE Call + + + + RECEIVE Call + + CLOSED STATE (i.e., TCB does not exist) + + If the user does not have access to such a connection, return + "error: connection illegal for this process". + + Otherwise return "error: connection does not exist". + + LISTEN STATE + SYN-SENT STATE + SYN-RECEIVED STATE + + Queue for processing after entering ESTABLISHED state. If there + is no room to queue this request, respond with "error: + insufficient resources". + + ESTABLISHED STATE + FIN-WAIT-1 STATE + FIN-WAIT-2 STATE + + If insufficient incoming segments are queued to satisfy the + request, queue the request. If there is no queue space to + remember the RECEIVE, respond with "error: insufficient + resources". + + Reassemble queued incoming segments into receive buffer and return + to user. Mark "push seen" (PUSH) if this is the case. + + If RCV.UP is in advance of the data currently being passed to the + user notify the user of the presence of urgent data. + + When the TCP takes responsibility for delivering data to the user + that fact must be communicated to the sender via an + acknowledgment. The formation of such an acknowledgment is + described below in the discussion of processing an incoming + segment. + + + + + + + + + + + + +[Page 58] + + +September 1981 + Transmission Control Protocol + Functional Specification +RECEIVE Call + + + + CLOSE-WAIT STATE + + Since the remote side has already sent FIN, RECEIVEs must be + satisfied by text already on hand, but not yet delivered to the + user. If no text is awaiting delivery, the RECEIVE will get a + "error: connection closing" response. Otherwise, any remaining + text can be used to satisfy the RECEIVE. + + CLOSING STATE + LAST-ACK STATE + TIME-WAIT STATE + + Return "error: connection closing". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [Page 59] + + + September 1981 +Transmission Control Protocol +Functional Specification + CLOSE Call + + + + CLOSE Call + + CLOSED STATE (i.e., TCB does not exist) + + If the user does not have access to such a connection, return + "error: connection illegal for this process". + + Otherwise, return "error: connection does not exist". + + LISTEN STATE + + Any outstanding RECEIVEs are returned with "error: closing" + responses. Delete TCB, enter CLOSED state, and return. + + SYN-SENT STATE + + Delete the TCB and return "error: closing" responses to any + queued SENDs, or RECEIVEs. + + SYN-RECEIVED STATE + + If no SENDs have been issued and there is no pending data to send, + then form a FIN segment and send it, and enter FIN-WAIT-1 state; + otherwise queue for processing after entering ESTABLISHED state. + + ESTABLISHED STATE + + Queue this until all preceding SENDs have been segmentized, then + form a FIN segment and send it. In any case, enter FIN-WAIT-1 + state. + + FIN-WAIT-1 STATE + FIN-WAIT-2 STATE + + Strictly speaking, this is an error and should receive a "error: + connection closing" response. An "ok" response would be + acceptable, too, as long as a second FIN is not emitted (the first + FIN may be retransmitted though). + + + + + + + + + + + +[Page 60] + + +September 1981 + Transmission Control Protocol + Functional Specification +CLOSE Call + + + + CLOSE-WAIT STATE + + Queue this request until all preceding SENDs have been + segmentized; then send a FIN segment, enter CLOSING state. + + CLOSING STATE + LAST-ACK STATE + TIME-WAIT STATE + + Respond with "error: connection closing". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [Page 61] + + + September 1981 +Transmission Control Protocol +Functional Specification + ABORT Call + + + + ABORT Call + + CLOSED STATE (i.e., TCB does not exist) + + If the user should not have access to such a connection, return + "error: connection illegal for this process". + + Otherwise return "error: connection does not exist". + + LISTEN STATE + + Any outstanding RECEIVEs should be returned with "error: + connection reset" responses. Delete TCB, enter CLOSED state, and + return. + + SYN-SENT STATE + + All queued SENDs and RECEIVEs should be given "connection reset" + notification, delete the TCB, enter CLOSED state, and return. + + SYN-RECEIVED STATE + ESTABLISHED STATE + FIN-WAIT-1 STATE + FIN-WAIT-2 STATE + CLOSE-WAIT STATE + + Send a reset segment: + + <SEQ=SND.NXT><CTL=RST> + + All queued SENDs and RECEIVEs should be given "connection reset" + notification; all segments queued for transmission (except for the + RST formed above) or retransmission should be flushed, delete the + TCB, enter CLOSED state, and return. + + CLOSING STATE + LAST-ACK STATE + TIME-WAIT STATE + + Respond with "ok" and delete the TCB, enter CLOSED state, and + return. + + + + + + + + +[Page 62] + + +September 1981 + Transmission Control Protocol + Functional Specification +STATUS Call + + + + STATUS Call + + CLOSED STATE (i.e., TCB does not exist) + + If the user should not have access to such a connection, return + "error: connection illegal for this process". + + Otherwise return "error: connection does not exist". + + LISTEN STATE + + Return "state = LISTEN", and the TCB pointer. + + SYN-SENT STATE + + Return "state = SYN-SENT", and the TCB pointer. + + SYN-RECEIVED STATE + + Return "state = SYN-RECEIVED", and the TCB pointer. + + ESTABLISHED STATE + + Return "state = ESTABLISHED", and the TCB pointer. + + FIN-WAIT-1 STATE + + Return "state = FIN-WAIT-1", and the TCB pointer. + + FIN-WAIT-2 STATE + + Return "state = FIN-WAIT-2", and the TCB pointer. + + CLOSE-WAIT STATE + + Return "state = CLOSE-WAIT", and the TCB pointer. + + CLOSING STATE + + Return "state = CLOSING", and the TCB pointer. + + LAST-ACK STATE + + Return "state = LAST-ACK", and the TCB pointer. + + + + + + [Page 63] + + + September 1981 +Transmission Control Protocol +Functional Specification + STATUS Call + + + + TIME-WAIT STATE + + Return "state = TIME-WAIT", and the TCB pointer. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 64] + + +September 1981 + Transmission Control Protocol + Functional Specification +SEGMENT ARRIVES + + + + SEGMENT ARRIVES + + If the state is CLOSED (i.e., TCB does not exist) then + + all data in the incoming segment is discarded. An incoming + segment containing a RST is discarded. An incoming segment not + containing a RST causes a RST to be sent in response. The + acknowledgment and sequence field values are selected to make the + reset sequence acceptable to the TCP that sent the offending + segment. + + If the ACK bit is off, sequence number zero is used, + + <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK> + + If the ACK bit is on, + + <SEQ=SEG.ACK><CTL=RST> + + Return. + + If the state is LISTEN then + + first check for an RST + + An incoming RST should be ignored. Return. + + second check for an ACK + + Any acknowledgment is bad if it arrives on a connection still in + the LISTEN state. An acceptable reset segment should be formed + for any arriving ACK-bearing segment. The RST should be + formatted as follows: + + <SEQ=SEG.ACK><CTL=RST> + + Return. + + third check for a SYN + + If the SYN bit is set, check the security. If the + security/compartment on the incoming segment does not exactly + match the security/compartment in the TCB then send a reset and + return. + + <SEQ=SEG.ACK><CTL=RST> + + + + [Page 65] + + + September 1981 +Transmission Control Protocol +Functional Specification + SEGMENT ARRIVES + + + + If the SEG.PRC is greater than the TCB.PRC then if allowed by + the user and the system set TCB.PRC<-SEG.PRC, if not allowed + send a reset and return. + + <SEQ=SEG.ACK><CTL=RST> + + If the SEG.PRC is less than the TCB.PRC then continue. + + Set RCV.NXT to SEG.SEQ+1, IRS is set to SEG.SEQ and any other + control or text should be queued for processing later. ISS + should be selected and a SYN segment sent of the form: + + <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK> + + SND.NXT is set to ISS+1 and SND.UNA to ISS. The connection + state should be changed to SYN-RECEIVED. Note that any other + incoming control or data (combined with SYN) will be processed + in the SYN-RECEIVED state, but processing of SYN and ACK should + not be repeated. If the listen was not fully specified (i.e., + the foreign socket was not fully specified), then the + unspecified fields should be filled in now. + + fourth other text or control + + Any other control or text-bearing segment (not containing SYN) + must have an ACK and thus would be discarded by the ACK + processing. An incoming RST segment could not be valid, since + it could not have been sent in response to anything sent by this + incarnation of the connection. So you are unlikely to get here, + but if you do, drop the segment, and return. + + If the state is SYN-SENT then + + first check the ACK bit + + If the ACK bit is set + + If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send a reset (unless + the RST bit is set, if so drop the segment and return) + + <SEQ=SEG.ACK><CTL=RST> + + and discard the segment. Return. + + If SND.UNA =< SEG.ACK =< SND.NXT then the ACK is acceptable. + + second check the RST bit + + +[Page 66] + + +September 1981 + Transmission Control Protocol + Functional Specification +SEGMENT ARRIVES + + + + If the RST bit is set + + If the ACK was acceptable then signal the user "error: + connection reset", drop the segment, enter CLOSED state, + delete TCB, and return. Otherwise (no ACK) drop the segment + and return. + + third check the security and precedence + + If the security/compartment in the segment does not exactly + match the security/compartment in the TCB, send a reset + + If there is an ACK + + <SEQ=SEG.ACK><CTL=RST> + + Otherwise + + <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK> + + If there is an ACK + + The precedence in the segment must match the precedence in the + TCB, if not, send a reset + + <SEQ=SEG.ACK><CTL=RST> + + If there is no ACK + + If the precedence in the segment is higher than the precedence + in the TCB then if allowed by the user and the system raise + the precedence in the TCB to that in the segment, if not + allowed to raise the prec then send a reset. + + <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK> + + If the precedence in the segment is lower than the precedence + in the TCB continue. + + If a reset was sent, discard the segment and return. + + fourth check the SYN bit + + This step should be reached only if the ACK is ok, or there is + no ACK, and it the segment did not contain a RST. + + If the SYN bit is on and the security/compartment and precedence + + + [Page 67] + + + September 1981 +Transmission Control Protocol +Functional Specification + SEGMENT ARRIVES + + + + are acceptable then, RCV.NXT is set to SEG.SEQ+1, IRS is set to + SEG.SEQ. SND.UNA should be advanced to equal SEG.ACK (if there + is an ACK), and any segments on the retransmission queue which + are thereby acknowledged should be removed. + + If SND.UNA > ISS (our SYN has been ACKed), change the connection + state to ESTABLISHED, form an ACK segment + + <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> + + and send it. Data or controls which were queued for + transmission may be included. If there are other controls or + text in the segment then continue processing at the sixth step + below where the URG bit is checked, otherwise return. + + Otherwise enter SYN-RECEIVED, form a SYN,ACK segment + + <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK> + + and send it. If there are other controls or text in the + segment, queue them for processing after the ESTABLISHED state + has been reached, return. + + fifth, if neither of the SYN or RST bits is set then drop the + segment and return. + + + + + + + + + + + + + + + + + + + + + + + + +[Page 68] + + +September 1981 + Transmission Control Protocol + Functional Specification +SEGMENT ARRIVES + + + + Otherwise, + + first check sequence number + + SYN-RECEIVED STATE + ESTABLISHED STATE + FIN-WAIT-1 STATE + FIN-WAIT-2 STATE + CLOSE-WAIT STATE + CLOSING STATE + LAST-ACK STATE + TIME-WAIT STATE + + Segments are processed in sequence. Initial tests on arrival + are used to discard old duplicates, but further processing is + done in SEG.SEQ order. If a segment's contents straddle the + boundary between old and new, only the new parts should be + processed. + + There are four cases for the acceptability test for an incoming + segment: + + Segment Receive Test + Length Window + ------- ------- ------------------------------------------- + + 0 0 SEG.SEQ = RCV.NXT + + 0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND + + >0 0 not acceptable + + >0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND + or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND + + If the RCV.WND is zero, no segments will be acceptable, but + special allowance should be made to accept valid ACKs, URGs and + RSTs. + + If an incoming segment is not acceptable, an acknowledgment + should be sent in reply (unless the RST bit is set, if so drop + the segment and return): + + <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> + + After sending the acknowledgment, drop the unacceptable segment + and return. + + + [Page 69] + + + September 1981 +Transmission Control Protocol +Functional Specification + SEGMENT ARRIVES + + + + In the following it is assumed that the segment is the idealized + segment that begins at RCV.NXT and does not exceed the window. + One could tailor actual segments to fit this assumption by + trimming off any portions that lie outside the window (including + SYN and FIN), and only processing further if the segment then + begins at RCV.NXT. Segments with higher begining sequence + numbers may be held for later processing. + + second check the RST bit, + + SYN-RECEIVED STATE + + If the RST bit is set + + If this connection was initiated with a passive OPEN (i.e., + came from the LISTEN state), then return this connection to + LISTEN state and return. The user need not be informed. If + this connection was initiated with an active OPEN (i.e., came + from SYN-SENT state) then the connection was refused, signal + the user "connection refused". In either case, all segments + on the retransmission queue should be removed. And in the + active OPEN case, enter the CLOSED state and delete the TCB, + and return. + + ESTABLISHED + FIN-WAIT-1 + FIN-WAIT-2 + CLOSE-WAIT + + If the RST bit is set then, any outstanding RECEIVEs and SEND + should receive "reset" responses. All segment queues should be + flushed. Users should also receive an unsolicited general + "connection reset" signal. Enter the CLOSED state, delete the + TCB, and return. + + CLOSING STATE + LAST-ACK STATE + TIME-WAIT + + If the RST bit is set then, enter the CLOSED state, delete the + TCB, and return. + + + + + + + + +[Page 70] + + +September 1981 + Transmission Control Protocol + Functional Specification +SEGMENT ARRIVES + + + + third check security and precedence + + SYN-RECEIVED + + If the security/compartment and precedence in the segment do not + exactly match the security/compartment and precedence in the TCB + then send a reset, and return. + + ESTABLISHED STATE + + If the security/compartment and precedence in the segment do not + exactly match the security/compartment and precedence in the TCB + then send a reset, any outstanding RECEIVEs and SEND should + receive "reset" responses. All segment queues should be + flushed. Users should also receive an unsolicited general + "connection reset" signal. Enter the CLOSED state, delete the + TCB, and return. + + Note this check is placed following the sequence check to prevent + a segment from an old connection between these ports with a + different security or precedence from causing an abort of the + current connection. + + fourth, check the SYN bit, + + SYN-RECEIVED + ESTABLISHED STATE + FIN-WAIT STATE-1 + FIN-WAIT STATE-2 + CLOSE-WAIT STATE + CLOSING STATE + LAST-ACK STATE + TIME-WAIT STATE + + If the SYN is in the window it is an error, send a reset, any + outstanding RECEIVEs and SEND should receive "reset" responses, + all segment queues should be flushed, the user should also + receive an unsolicited general "connection reset" signal, enter + the CLOSED state, delete the TCB, and return. + + If the SYN is not in the window this step would not be reached + and an ack would have been sent in the first step (sequence + number check). + + + + + + + [Page 71] + + + September 1981 +Transmission Control Protocol +Functional Specification + SEGMENT ARRIVES + + + + fifth check the ACK field, + + if the ACK bit is off drop the segment and return + + if the ACK bit is on + + SYN-RECEIVED STATE + + If SND.UNA =< SEG.ACK =< SND.NXT then enter ESTABLISHED state + and continue processing. + + If the segment acknowledgment is not acceptable, form a + reset segment, + + <SEQ=SEG.ACK><CTL=RST> + + and send it. + + ESTABLISHED STATE + + If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <- SEG.ACK. + Any segments on the retransmission queue which are thereby + entirely acknowledged are removed. Users should receive + positive acknowledgments for buffers which have been SENT and + fully acknowledged (i.e., SEND buffer should be returned with + "ok" response). If the ACK is a duplicate + (SEG.ACK < SND.UNA), it can be ignored. If the ACK acks + something not yet sent (SEG.ACK > SND.NXT) then send an ACK, + drop the segment, and return. + + If SND.UNA < SEG.ACK =< SND.NXT, the send window should be + updated. If (SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and + SND.WL2 =< SEG.ACK)), set SND.WND <- SEG.WND, set + SND.WL1 <- SEG.SEQ, and set SND.WL2 <- SEG.ACK. + + Note that SND.WND is an offset from SND.UNA, that SND.WL1 + records the sequence number of the last segment used to update + SND.WND, and that SND.WL2 records the acknowledgment number of + the last segment used to update SND.WND. The check here + prevents using old segments to update the window. + + + + + + + + + +[Page 72] + + +September 1981 + Transmission Control Protocol + Functional Specification +SEGMENT ARRIVES + + + + FIN-WAIT-1 STATE + + In addition to the processing for the ESTABLISHED state, if + our FIN is now acknowledged then enter FIN-WAIT-2 and continue + processing in that state. + + FIN-WAIT-2 STATE + + In addition to the processing for the ESTABLISHED state, if + the retransmission queue is empty, the user's CLOSE can be + acknowledged ("ok") but do not delete the TCB. + + CLOSE-WAIT STATE + + Do the same processing as for the ESTABLISHED state. + + CLOSING STATE + + In addition to the processing for the ESTABLISHED state, if + the ACK acknowledges our FIN then enter the TIME-WAIT state, + otherwise ignore the segment. + + LAST-ACK STATE + + The only thing that can arrive in this state is an + acknowledgment of our FIN. If our FIN is now acknowledged, + delete the TCB, enter the CLOSED state, and return. + + TIME-WAIT STATE + + The only thing that can arrive in this state is a + retransmission of the remote FIN. Acknowledge it, and restart + the 2 MSL timeout. + + sixth, check the URG bit, + + ESTABLISHED STATE + FIN-WAIT-1 STATE + FIN-WAIT-2 STATE + + If the URG bit is set, RCV.UP <- max(RCV.UP,SEG.UP), and signal + the user that the remote side has urgent data if the urgent + pointer (RCV.UP) is in advance of the data consumed. If the + user has already been signaled (or is still in the "urgent + mode") for this continuous sequence of urgent data, do not + signal the user again. + + + + [Page 73] + + + September 1981 +Transmission Control Protocol +Functional Specification + SEGMENT ARRIVES + + + + CLOSE-WAIT STATE + CLOSING STATE + LAST-ACK STATE + TIME-WAIT + + This should not occur, since a FIN has been received from the + remote side. Ignore the URG. + + seventh, process the segment text, + + ESTABLISHED STATE + FIN-WAIT-1 STATE + FIN-WAIT-2 STATE + + Once in the ESTABLISHED state, it is possible to deliver segment + text to user RECEIVE buffers. Text from segments can be moved + into buffers until either the buffer is full or the segment is + empty. If the segment empties and carries an PUSH flag, then + the user is informed, when the buffer is returned, that a PUSH + has been received. + + When the TCP takes responsibility for delivering the data to the + user it must also acknowledge the receipt of the data. + + Once the TCP takes responsibility for the data it advances + RCV.NXT over the data accepted, and adjusts RCV.WND as + apporopriate to the current buffer availability. The total of + RCV.NXT and RCV.WND should not be reduced. + + Please note the window management suggestions in section 3.7. + + Send an acknowledgment of the form: + + <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK> + + This acknowledgment should be piggybacked on a segment being + transmitted if possible without incurring undue delay. + + + + + + + + + + + + +[Page 74] + + +September 1981 + Transmission Control Protocol + Functional Specification +SEGMENT ARRIVES + + + + CLOSE-WAIT STATE + CLOSING STATE + LAST-ACK STATE + TIME-WAIT STATE + + This should not occur, since a FIN has been received from the + remote side. Ignore the segment text. + + eighth, check the FIN bit, + + Do not process the FIN if the state is CLOSED, LISTEN or SYN-SENT + since the SEG.SEQ cannot be validated; drop the segment and + return. + + If the FIN bit is set, signal the user "connection closing" and + return any pending RECEIVEs with same message, advance RCV.NXT + over the FIN, and send an acknowledgment for the FIN. Note that + FIN implies PUSH for any segment text not yet delivered to the + user. + + SYN-RECEIVED STATE + ESTABLISHED STATE + + Enter the CLOSE-WAIT state. + + FIN-WAIT-1 STATE + + If our FIN has been ACKed (perhaps in this segment), then + enter TIME-WAIT, start the time-wait timer, turn off the other + timers; otherwise enter the CLOSING state. + + FIN-WAIT-2 STATE + + Enter the TIME-WAIT state. Start the time-wait timer, turn + off the other timers. + + CLOSE-WAIT STATE + + Remain in the CLOSE-WAIT state. + + CLOSING STATE + + Remain in the CLOSING state. + + LAST-ACK STATE + + Remain in the LAST-ACK state. + + + [Page 75] + + + September 1981 +Transmission Control Protocol +Functional Specification + SEGMENT ARRIVES + + + + TIME-WAIT STATE + + Remain in the TIME-WAIT state. Restart the 2 MSL time-wait + timeout. + + and return. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 76] + + +September 1981 + Transmission Control Protocol + Functional Specification +USER TIMEOUT + + + + USER TIMEOUT + + For any state if the user timeout expires, flush all queues, signal + the user "error: connection aborted due to user timeout" in general + and for any outstanding calls, delete the TCB, enter the CLOSED + state and return. + + RETRANSMISSION TIMEOUT + + For any state if the retransmission timeout expires on a segment in + the retransmission queue, send the segment at the front of the + retransmission queue again, reinitialize the retransmission timer, + and return. + + TIME-WAIT TIMEOUT + + If the time-wait timeout expires on a connection delete the TCB, + enter the CLOSED state and return. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [Page 77] + + + September 1981 +Transmission Control Protocol + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 78] + + +September 1981 + Transmission Control Protocol + + + + GLOSSARY + + + +1822 + BBN Report 1822, "The Specification of the Interconnection of + a Host and an IMP". The specification of interface between a + host and the ARPANET. + +ACK + A control bit (acknowledge) occupying no sequence space, which + indicates that the acknowledgment field of this segment + specifies the next sequence number the sender of this segment + is expecting to receive, hence acknowledging receipt of all + previous sequence numbers. + +ARPANET message + The unit of transmission between a host and an IMP in the + ARPANET. The maximum size is about 1012 octets (8096 bits). + +ARPANET packet + A unit of transmission used internally in the ARPANET between + IMPs. The maximum size is about 126 octets (1008 bits). + +connection + A logical communication path identified by a pair of sockets. + +datagram + A message sent in a packet switched computer communications + network. + +Destination Address + The destination address, usually the network and host + identifiers. + +FIN + A control bit (finis) occupying one sequence number, which + indicates that the sender will send no more data or control + occupying sequence space. + +fragment + A portion of a logical unit of data, in particular an internet + fragment is a portion of an internet datagram. + +FTP + A file transfer protocol. + + + + + + [Page 79] + + + September 1981 +Transmission Control Protocol +Glossary + + + +header + Control information at the beginning of a message, segment, + fragment, packet or block of data. + +host + A computer. In particular a source or destination of messages + from the point of view of the communication network. + +Identification + An Internet Protocol field. This identifying value assigned + by the sender aids in assembling the fragments of a datagram. + +IMP + The Interface Message Processor, the packet switch of the + ARPANET. + +internet address + A source or destination address specific to the host level. + +internet datagram + The unit of data exchanged between an internet module and the + higher level protocol together with the internet header. + +internet fragment + A portion of the data of an internet datagram with an internet + header. + +IP + Internet Protocol. + +IRS + The Initial Receive Sequence number. The first sequence + number used by the sender on a connection. + +ISN + The Initial Sequence Number. The first sequence number used + on a connection, (either ISS or IRS). Selected on a clock + based procedure. + +ISS + The Initial Send Sequence number. The first sequence number + used by the sender on a connection. + +leader + Control information at the beginning of a message or block of + data. In particular, in the ARPANET, the control information + on an ARPANET message at the host-IMP interface. + + + +[Page 80] + + +September 1981 + Transmission Control Protocol + Glossary + + + +left sequence + This is the next sequence number to be acknowledged by the + data receiving TCP (or the lowest currently unacknowledged + sequence number) and is sometimes referred to as the left edge + of the send window. + +local packet + The unit of transmission within a local network. + +module + An implementation, usually in software, of a protocol or other + procedure. + +MSL + Maximum Segment Lifetime, the time a TCP segment can exist in + the internetwork system. Arbitrarily defined to be 2 minutes. + +octet + An eight bit byte. + +Options + An Option field may contain several options, and each option + may be several octets in length. The options are used + primarily in testing situations; for example, to carry + timestamps. Both the Internet Protocol and TCP provide for + options fields. + +packet + A package of data with a header which may or may not be + logically complete. More often a physical packaging than a + logical packaging of data. + +port + The portion of a socket that specifies which logical input or + output channel of a process is associated with the data. + +process + A program in execution. A source or destination of data from + the point of view of the TCP or other host-to-host protocol. + +PUSH + A control bit occupying no sequence space, indicating that + this segment contains data that must be pushed through to the + receiving user. + +RCV.NXT + receive next sequence number + + + + [Page 81] + + + September 1981 +Transmission Control Protocol +Glossary + + + +RCV.UP + receive urgent pointer + +RCV.WND + receive window + +receive next sequence number + This is the next sequence number the local TCP is expecting to + receive. + +receive window + This represents the sequence numbers the local (receiving) TCP + is willing to receive. Thus, the local TCP considers that + segments overlapping the range RCV.NXT to + RCV.NXT + RCV.WND - 1 carry acceptable data or control. + Segments containing sequence numbers entirely outside of this + range are considered duplicates and discarded. + +RST + A control bit (reset), occupying no sequence space, indicating + that the receiver should delete the connection without further + interaction. The receiver can determine, based on the + sequence number and acknowledgment fields of the incoming + segment, whether it should honor the reset command or ignore + it. In no case does receipt of a segment containing RST give + rise to a RST in response. + +RTP + Real Time Protocol: A host-to-host protocol for communication + of time critical information. + +SEG.ACK + segment acknowledgment + +SEG.LEN + segment length + +SEG.PRC + segment precedence value + +SEG.SEQ + segment sequence + +SEG.UP + segment urgent pointer field + + + + + +[Page 82] + + +September 1981 + Transmission Control Protocol + Glossary + + + +SEG.WND + segment window field + +segment + A logical unit of data, in particular a TCP segment is the + unit of data transfered between a pair of TCP modules. + +segment acknowledgment + The sequence number in the acknowledgment field of the + arriving segment. + +segment length + The amount of sequence number space occupied by a segment, + including any controls which occupy sequence space. + +segment sequence + The number in the sequence field of the arriving segment. + +send sequence + This is the next sequence number the local (sending) TCP will + use on the connection. It is initially selected from an + initial sequence number curve (ISN) and is incremented for + each octet of data or sequenced control transmitted. + +send window + This represents the sequence numbers which the remote + (receiving) TCP is willing to receive. It is the value of the + window field specified in segments from the remote (data + receiving) TCP. The range of new sequence numbers which may + be emitted by a TCP lies between SND.NXT and + SND.UNA + SND.WND - 1. (Retransmissions of sequence numbers + between SND.UNA and SND.NXT are expected, of course.) + +SND.NXT + send sequence + +SND.UNA + left sequence + +SND.UP + send urgent pointer + +SND.WL1 + segment sequence number at last window update + +SND.WL2 + segment acknowledgment number at last window update + + + + [Page 83] + + + September 1981 +Transmission Control Protocol +Glossary + + + +SND.WND + send window + +socket + An address which specifically includes a port identifier, that + is, the concatenation of an Internet Address with a TCP port. + +Source Address + The source address, usually the network and host identifiers. + +SYN + A control bit in the incoming segment, occupying one sequence + number, used at the initiation of a connection, to indicate + where the sequence numbering will start. + +TCB + Transmission control block, the data structure that records + the state of a connection. + +TCB.PRC + The precedence of the connection. + +TCP + Transmission Control Protocol: A host-to-host protocol for + reliable communication in internetwork environments. + +TOS + Type of Service, an Internet Protocol field. + +Type of Service + An Internet Protocol field which indicates the type of service + for this internet fragment. + +URG + A control bit (urgent), occupying no sequence space, used to + indicate that the receiving user should be notified to do + urgent processing as long as there is data to be consumed with + sequence numbers less than the value indicated in the urgent + pointer. + +urgent pointer + A control field meaningful only when the URG bit is on. This + field communicates the value of the urgent pointer which + indicates the data octet associated with the sending user's + urgent call. + + + + + +[Page 84] + + +September 1981 + Transmission Control Protocol + + + + REFERENCES + + + +[1] Cerf, V., and R. Kahn, "A Protocol for Packet Network + Intercommunication", IEEE Transactions on Communications, + Vol. COM-22, No. 5, pp 637-648, May 1974. + +[2] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program + Protocol Specification", RFC 791, USC/Information Sciences + Institute, September 1981. + +[3] Dalal, Y. and C. Sunshine, "Connection Management in Transport + Protocols", Computer Networks, Vol. 2, No. 6, pp. 454-473, + December 1978. + +[4] Postel, J., "Assigned Numbers", RFC 790, USC/Information Sciences + Institute, September 1981. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [Page 85] + |