diff options
Diffstat (limited to 'doc')
36 files changed, 0 insertions, 58827 deletions
diff --git a/doc/README b/doc/README deleted file mode 100644 index a76719b..0000000 --- a/doc/README +++ /dev/null @@ -1,15 +0,0 @@ -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/doc/README.Reference b/doc/README.Reference deleted file mode 100644 index a76719b..0000000 --- a/doc/README.Reference +++ /dev/null @@ -1,15 +0,0 @@ -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/doc/ms-chap.txt b/doc/ms-chap.txt deleted file mode 100644 index f009400..0000000 --- a/doc/ms-chap.txt +++ /dev/null @@ -1,1139 +0,0 @@ -
-
-
-
-
-
-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/doc/pptp-draft.txt b/doc/pptp-draft.txt deleted file mode 100644 index f58701b..0000000 --- a/doc/pptp-draft.txt +++ /dev/null @@ -1,3472 +0,0 @@ - -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/doc/rfc1172.txt b/doc/rfc1172.txt deleted file mode 100644 index 5307640..0000000 --- a/doc/rfc1172.txt +++ /dev/null @@ -1,2312 +0,0 @@ - - - - - - -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/doc/rfc1332.txt b/doc/rfc1332.txt deleted file mode 100644 index 3e12042..0000000 --- a/doc/rfc1332.txt +++ /dev/null @@ -1,787 +0,0 @@ - - - - - - -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/doc/rfc1334.txt b/doc/rfc1334.txt deleted file mode 100644 index 6051f48..0000000 --- a/doc/rfc1334.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -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/doc/rfc1548.txt b/doc/rfc1548.txt deleted file mode 100644 index 7b8a33a..0000000 --- a/doc/rfc1548.txt +++ /dev/null @@ -1,2971 +0,0 @@ - - - - - - -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/doc/rfc1570.txt b/doc/rfc1570.txt deleted file mode 100644 index edda5d9..0000000 --- a/doc/rfc1570.txt +++ /dev/null @@ -1,1057 +0,0 @@ - - - - - - -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/doc/rfc1661.txt b/doc/rfc1661.txt deleted file mode 100644 index 02112bd..0000000 --- a/doc/rfc1661.txt +++ /dev/null @@ -1,2976 +0,0 @@ - - - - - - -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/doc/rfc1662.txt b/doc/rfc1662.txt deleted file mode 100644 index 5a5b214..0000000 --- a/doc/rfc1662.txt +++ /dev/null @@ -1,1436 +0,0 @@ - - - - - - - -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/doc/rfc1701.txt b/doc/rfc1701.txt deleted file mode 100644 index 60a0e9b..0000000 --- a/doc/rfc1701.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -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/doc/rfc1702.txt b/doc/rfc1702.txt deleted file mode 100644 index 50b57ae..0000000 --- a/doc/rfc1702.txt +++ /dev/null @@ -1,227 +0,0 @@ - - - - - - -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/doc/rfc1877.txt b/doc/rfc1877.txt deleted file mode 100644 index 843c15c..0000000 --- a/doc/rfc1877.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -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/doc/rfc1962.txt b/doc/rfc1962.txt deleted file mode 100644 index fc9b47d..0000000 --- a/doc/rfc1962.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -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/doc/rfc1979.txt b/doc/rfc1979.txt deleted file mode 100644 index 7a95cd3..0000000 --- a/doc/rfc1979.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -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/doc/rfc1990.txt b/doc/rfc1990.txt deleted file mode 100644 index a4f7ffe..0000000 --- a/doc/rfc1990.txt +++ /dev/null @@ -1,1347 +0,0 @@ - - - - - - -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/doc/rfc1994.txt b/doc/rfc1994.txt deleted file mode 100644 index e4a553e..0000000 --- a/doc/rfc1994.txt +++ /dev/null @@ -1,732 +0,0 @@ - - - - - - -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/doc/rfc2138.txt b/doc/rfc2138.txt deleted file mode 100644 index 9f4a86d..0000000 --- a/doc/rfc2138.txt +++ /dev/null @@ -1,3643 +0,0 @@ - - - - - - -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/doc/rfc2139.txt b/doc/rfc2139.txt deleted file mode 100644 index 88c5af8..0000000 --- a/doc/rfc2139.txt +++ /dev/null @@ -1,1403 +0,0 @@ - - - - - - -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/doc/rfc2284.txt b/doc/rfc2284.txt deleted file mode 100644 index 9940562..0000000 --- a/doc/rfc2284.txt +++ /dev/null @@ -1,843 +0,0 @@ - - - - - - -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/doc/rfc2433.txt b/doc/rfc2433.txt deleted file mode 100644 index 3536e72..0000000 --- a/doc/rfc2433.txt +++ /dev/null @@ -1,1123 +0,0 @@ - - - - - - -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/doc/rfc2548.txt b/doc/rfc2548.txt deleted file mode 100644 index 35c83c3..0000000 --- a/doc/rfc2548.txt +++ /dev/null @@ -1,2299 +0,0 @@ - - - - - - -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/doc/rfc2637.txt b/doc/rfc2637.txt deleted file mode 100644 index 56e9e0f..0000000 --- a/doc/rfc2637.txt +++ /dev/null @@ -1,3195 +0,0 @@ - - - - - - -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/doc/rfc2716.txt b/doc/rfc2716.txt deleted file mode 100644 index 71b4a84..0000000 --- a/doc/rfc2716.txt +++ /dev/null @@ -1,1347 +0,0 @@ - - - - - - -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/doc/rfc2759.txt b/doc/rfc2759.txt deleted file mode 100644 index 60371c4..0000000 --- a/doc/rfc2759.txt +++ /dev/null @@ -1,1123 +0,0 @@ - - - - - - -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/doc/rfc2865.txt b/doc/rfc2865.txt deleted file mode 100644 index 10ec231..0000000 --- a/doc/rfc2865.txt +++ /dev/null @@ -1,4259 +0,0 @@ - - - - - - -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/doc/rfc2866.txt b/doc/rfc2866.txt deleted file mode 100644 index 82da1dc..0000000 --- a/doc/rfc2866.txt +++ /dev/null @@ -1,1571 +0,0 @@ - - - - - - -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/doc/rfc2869.txt b/doc/rfc2869.txt deleted file mode 100644 index 74ed7f6..0000000 --- a/doc/rfc2869.txt +++ /dev/null @@ -1,2635 +0,0 @@ - - - - - - -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/doc/rfc3078.txt b/doc/rfc3078.txt deleted file mode 100644 index 5bbcc13..0000000 --- a/doc/rfc3078.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -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/doc/rfc3079.txt b/doc/rfc3079.txt deleted file mode 100644 index 4d7ba0d..0000000 --- a/doc/rfc3079.txt +++ /dev/null @@ -1,1179 +0,0 @@ - - - - - - -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/doc/rfc3544.txt b/doc/rfc3544.txt deleted file mode 100644 index b4d2ac5..0000000 --- a/doc/rfc3544.txt +++ /dev/null @@ -1,787 +0,0 @@ - - - - - - -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/doc/rfc3576.txt b/doc/rfc3576.txt deleted file mode 100644 index 89fd9eb..0000000 --- a/doc/rfc3576.txt +++ /dev/null @@ -1,1683 +0,0 @@ - - - - - - -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/doc/rfc3580.txt b/doc/rfc3580.txt deleted file mode 100644 index b87235c..0000000 --- a/doc/rfc3580.txt +++ /dev/null @@ -1,1683 +0,0 @@ - - - - - - -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/doc/rfc791.txt b/doc/rfc791.txt deleted file mode 100644 index 5952d0b..0000000 --- a/doc/rfc791.txt +++ /dev/null @@ -1,2887 +0,0 @@ - - -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/doc/rfc793.txt b/doc/rfc793.txt deleted file mode 100644 index 603a78c..0000000 --- a/doc/rfc793.txt +++ /dev/null @@ -1,5247 +0,0 @@ - - -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] - |