idnits 2.17.1 draft-zorn-rfc2868bis-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2138, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8197 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '12' is defined on line 833, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 836, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2637 (ref. '1') ** Downref: Normative reference to an Historic RFC: RFC 2341 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2107 (ref. '4') ** Obsolete normative reference: RFC 2401 (ref. '5') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 1827 (ref. '8') (Obsoleted by RFC 2406) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '9') ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. '10') ** Downref: Normative reference to an Informational RFC: RFC 2867 (ref. '11') ** Obsolete normative reference: RFC 1700 (ref. '14') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 2869 (ref. '15') ** Obsolete normative reference: RFC 2434 (ref. '16') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2373 (ref. '17') (Obsoleted by RFC 3513) == Outdated reference: A later version (-08) exists of draft-ietf-l2tpext-security-02 ** Downref: Normative reference to an Informational RFC: RFC 2809 (ref. '19') -- Possible downref: Non-RFC (?) normative reference: ref. '21' Summary: 20 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn 3 Internet-Draft Cisco Systems 4 Obsoletes: RFC 2138 D. Leifer 5 Category: Standards Track A. Rubens 6 Tut Systems Inc. 7 J. Shriver 8 Intel Corporation 9 M. Holdrege 10 ipVerse 11 I. Goyret 12 Lucent Technologies 13 November 2001 15 RADIUS Attributes for Tunnel Protocol Support 17 1. Status of this Memo 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other groups 24 may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference material 29 or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 The distribution of this memo is unlimited. It is filed as , and expires May 17, 2002. Please send comments 39 to the authors (leifer@del.com, acr@del.com, holdrege@lucent.com, 40 igoyret@lucent.com, John.Shriver@intel.com and gwz@acm.org). 42 2. Abstract 44 This document defines a set of RADIUS attributes designed to support the 45 provision of compulsory tunneling in dial-up networks. 47 3. Motivation 49 Many applications of tunneling protocols such as L2TP involve dial-up 50 network access. Some, such as the provision of access to corporate 51 intranets via the Internet, are characterized by voluntary tunneling: 52 the tunnel is created at the request of the user for a specific purpose. 53 Other applications involve compulsory tunneling: the tunnel is created 54 without any action from the user and without allowing the user any 55 choice in the matter. In order to provide this functionality, new 56 RADIUS attributes are needed to carry the tunneling information from the 57 RADIUS server to the tunnel end points; this document defines those 58 attributes. Specific recommendations for, and examples of, the 59 application of these attributes for L2TP can be found in RFC 2809 [19]. 61 4. Specification of Requirements 63 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 64 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 65 described in [14]. 67 5. Attributes 69 Multiple instances of each of the attributes defined below may be 70 included in a single RADIUS packet. In this case, the attributes to be 71 applied to any given tunnel SHOULD all contain the same value in their 72 respective Tag fields; otherwise, the Tag field SHOULD NOT be used. 74 If the RADIUS server returns attributes describing multiple tunnels then 75 the tunnels SHOULD be interpreted by the tunnel initiator as 76 alternatives and the server SHOULD include an instance of the Tunnel- 77 Preference Attribute in the set of Attributes pertaining to each 78 alternative tunnel. Similarly, if the RADIUS client includes multiple 79 sets of tunnel Attributes in an Access-Request packet, all the 80 Attributes pertaining to a given tunnel SHOULD contain the same value in 81 their respective Tag fields and each set SHOULD include an appropriately 82 valued instance of the Tunnel-Preference Attribute. 84 5.1. Tunnel-Type 86 Description 88 This Attribute indicates the tunneling protocol(s) to be used (in 89 the case of a tunnel initiator) or the tunneling protocol in use 90 (in the case of a tunnel terminator). It MAY be included in 91 Access-Request, Access-Accept and Accounting-Request packets. If 92 the Tunnel-Type Attribute is present in an Access-Request packet 93 sent from a tunnel initiator, it SHOULD be taken as a hint to the 94 RADIUS server as to the tunneling protocols supported by the 95 tunnel end-point; the RADIUS server MAY ignore the hint, however. 96 A tunnel initiator is not required to implement any of these 97 tunnel types; if a tunnel initiator receives an Access-Accept 98 packet which contains only unknown or unsupported Tunnel-Types, 99 the tunnel initiator MUST behave as though an Access-Reject had 100 been received instead. 102 If the Tunnel-Type Attribute is present in an Access-Request 103 packet sent from a tunnel terminator, it SHOULD be taken to 104 signify the tunneling protocol in use. In this case, if the 105 RADIUS server determines that the use of the communicated protocol 106 is not authorized, it MAY return an Access-Reject packet. If a 107 tunnel terminator receives an Access-Accept packet which contains 108 one or more Tunnel-Type Attributes, none of which represent the 109 tunneling protocol in use, the tunnel terminator SHOULD behave as 110 though an Access-Reject had been received instead. 112 A summary of the Tunnel-Type Attribute format is shown below. The 113 fields are transmitted from left to right. 115 0 1 2 3 116 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Type | Length | Tag | Value 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 Value (cont) | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 Type 124 64 for Tunnel-Type 126 Length 127 Always 6. 129 Tag 130 The Tag field is one octet in length and is intended to provide a 131 means of grouping attributes in the same packet which refer to the 132 same tunnel. Valid values for this field are 0x01 through 0x1F, 133 inclusive. If the Tag field is unused, it MUST be zero (0x00). 135 Value 136 The Value field is three octets and contains one of the following 137 values, indicating the type of tunnel to be started. 139 1 Point-to-Point Tunneling Protocol (PPTP) [1] 140 2 Layer Two Forwarding (L2F) [2] 141 3 Layer Two Tunneling Protocol (L2TP) [3] 142 4 Ascend Tunnel Management Protocol (ATMP) [4] 143 5 Virtual Tunneling Protocol (VTP) 144 6 IP Authentication Header in the Tunnel-mode (AH) [5] 145 7 IP-in-IP Encapsulation (IP-IP) [6] 146 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [7] 147 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [8] 148 10 Generic Route Encapsulation (GRE) [9] 149 11 Bay Dial Virtual Services (DVS) 150 12 IP-in-IP Tunneling [10] 151 ?? Secure L2TP [18] 153 5.2. Tunnel-Medium-Type 155 Description 157 The Tunnel-Medium-Type Attribute indicates which transport medium 158 to use when creating a tunnel for those protocols (such as L2TP) 159 that can operate over multiple transports. It MAY be included in 160 both Access-Request and Access-Accept packets; if it is present in 161 an Access-Request packet, it SHOULD be taken as a hint to the 162 RADIUS server as to the tunnel media supported by the tunnel end- 163 point. The RADIUS server MAY ignore the hint, however. 165 A summary of the Tunnel-Medium-Type Attribute format is given below. 166 The fields are transmitted left to right. 168 0 1 2 3 169 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Type | Length | Tag | Value | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Value (cont) | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Type 177 65 for Tunnel-Medium-Type 179 Length 180 6 182 Tag 183 The Tag field is one octet in length and is intended to provide a 184 means of grouping attributes in the same packet which refer to the 185 same tunnel. Valid values for this field are 0x01 through 0x1F, 186 inclusive. If the Tag field is unused, it MUST be zero (0x00). 188 Value 189 The Value field is three octets and contains one of the values 190 listed under "Address Family Numbers" in [14]. For the sake of 191 convenience, a relevant excerpt of this list is reproduced below. 193 1 IPv4 (IP version 4) 194 2 IPv6 (IP version 6) 195 3 NSAP 196 4 HDLC (8-bit multidrop) 197 5 BBN 1822 198 6 802 (includes all 802 media plus Ethernet "canonical format") 199 7 E.163 (POTS) 200 8 E.164 (SMDS, Frame Relay, ATM) 201 9 F.69 (Telex) 202 10 X.121 (X.25, Frame Relay) 203 11 IPX 204 12 Appletalk 205 13 Decnet IV 206 14 Banyan Vines 207 15 E.164 with NSAP format subaddress 209 5.3. Tunnel-Client-Endpoint 211 Description 213 This Attribute contains the address of the initiator end of the 214 tunnel. It MAY be included in both Access-Request and Access- 215 Accept packets to indicate the address from which a new tunnel is 216 to be initiated. If the Tunnel-Client-Endpoint Attribute is 217 included in an Access-Request packet, the RADIUS server should 218 take the value as a hint; the server is not obligated to honor the 219 hint, however. This Attribute SHOULD be included in Accounting- 220 Request packets which contain Acct-Status-Type attributes with 221 values of either Start or Stop, in which case it indicates the 222 address from which the tunnel was initiated. This Attribute, 223 along with the Tunnel-Server-Endpoint and Acct-Tunnel-Connection- 224 ID attributes, may be used to provide a globally unique means to 225 identify a tunnel for accounting and auditing purposes. 227 A summary of the Tunnel-Client-Endpoint Attribute format is shown 228 below. The fields are transmitted from left to right. 230 0 1 2 3 231 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type | Length | Tag | String ... 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Type 237 66 for Tunnel-Client-Endpoint. 239 Length 240 >= 3 242 Tag 243 The Tag field is one octet in length and is intended to provide a 244 means of grouping attributes in the same packet which refer to the 245 same tunnel. If the value of the Tag field is greater than 0x00 246 and less than or equal to 0x1F, it SHOULD be interpreted as 247 indicating which tunnel (of several alternatives) this attribute 248 pertains. If the Tag field is greater than 0x1F, it SHOULD be 249 interpreted as the first byte of the following String field. 251 String 252 The format of the address represented by the String field depends 253 upon the value of the Tunnel-Medium-Type attribute. 255 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 256 fully qualified domain name (FQDN) of the tunnel client machine, 257 or it is a "dotted-decimal" IP address. Conformant 258 implementations MUST support the dotted-decimal format and SHOULD 259 support the FQDN format for IP addresses. 261 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 262 FQDN of the tunnel client machine, or it is a text representation 263 of the address in either the preferred or alternate form [17]. 264 Conformant implementations MUST support the preferred form and 265 SHOULD support both the alternate text form and the FQDN format 266 for IPv6 addresses. 268 If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a 269 tag referring to configuration data local to the RADIUS client 270 that describes the interface and medium-specific address to use. 272 5.4. Tunnel-Server-Endpoint 274 Description 276 This Attribute indicates the address of the server end of the 277 tunnel. The Tunnel-Server-Endpoint Attribute MAY be included (as 278 a hint to the RADIUS server) in the Access-Request packet and MUST 279 be included in the Access-Accept packet if the initiation of a 280 tunnel is desired. It SHOULD be included in Accounting-Request 281 packets that contain Acct-Status-Type attributes with values of 282 either Start or Stop and which pertain to a tunneled session. 283 This Attribute, along with the Tunnel-Client-Endpoint and Acct- 284 Tunnel-Connection-ID Attributes [11], may be used to provide a 285 globally unique means to identify a tunnel for accounting and 286 auditing purposes. 288 A summary of the Tunnel-Server-Endpoint Attribute format is shown 289 below. The fields are transmitted from left to right. 291 0 1 2 3 292 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Type | Length | Tag | String ... 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Type 298 67 for Tunnel-Server-Endpoint. 300 Length 301 >= 3 303 Tag 304 The Tag field is one octet in length and is intended to provide a 305 means of grouping attributes in the same packet which refer to the 306 same tunnel. If the value of the Tag field is greater than 0x00 307 and less than or equal to 0x1F, it SHOULD be interpreted as 308 indicating which tunnel (of several alternatives) this attribute 309 pertains. If the Tag field is greater than 0x1F, it SHOULD be 310 interpreted as the first byte of the following String field. 312 String 313 The format of the address represented by the String field depends 314 upon the value of the Tunnel-Medium-Type attribute. 316 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 317 fully qualified domain name (FQDN) of the tunnel client machine, 318 or it is a "dotted-decimal" IP address. Conformant 319 implementations MUST support the dotted-decimal format and SHOULD 320 support the FQDN format for IP addresses. 322 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 323 FQDN of the tunnel client machine, or it is a text representation 324 of the address in either the preferred or alternate form [17]. 325 Conformant implementations MUST support the preferred form and 326 SHOULD support both the alternate text form and the FQDN format 327 for IPv6 addresses. 329 If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag 330 referring to configuration data local to the RADIUS client that 331 describes the interface and medium-specific address to use. 333 5.5. Tunnel-Password 335 Description 337 This Attribute may contain a password to be used to authenticate 338 to a remote server. It may only be included in an Access-Accept 339 packet. 341 A summary of the Tunnel-Password Attribute format is shown below. 342 The fields are transmitted from left to right. 344 0 1 2 3 345 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type | Length | Tag | Salt 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Salt (cont) | String ... 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Type 353 69 for Tunnel-Password 355 Length 356 >= 3 358 Tag 359 The Tag field is one octet in length and is intended to provide a 360 means of grouping attributes in the same packet which refer to the 361 same tunnel. Valid values for this field are 0x01 through 0x1F, 362 inclusive. If the value of the Tag field is greater than 0x00 and 363 less than or equal to 0x1F, it SHOULD be interpreted as indicating 364 which tunnel (of several alternatives) this attribute pertains; 365 otherwise, the Tag field SHOULD be ignored. 367 Salt 368 The Salt field is two octets in length and is used to ensure the 369 uniqueness of the encryption key used to encrypt each instance of 370 the Tunnel-Password attribute occurring in a given Access-Accept 371 packet. The most significant bit (leftmost) of the Salt field 372 MUST be set (1). The contents of each Salt field in a given 373 Access-Accept packet MUST be unique. 375 String 376 The plaintext String field consists of three logical sub-fields: 377 the Data-Length and Password sub-fields (both of which are 378 required), and the optional Padding sub-field. The Data-Length 379 sub-field is one octet in length and contains the length of the 380 unencrypted Password sub-field. The Password sub-field contains 381 the actual tunnel password. If the combined length (in octets) of 382 the unencrypted Data-Length and Password sub-fields is not an even 383 multiple of 16, then the Padding sub-field MUST be present. If it 384 is present, the length of the Padding sub-field is variable, 385 between 1 and 15 octets. The String field MUST be encrypted as 386 follows, prior to transmission: 388 Construct a plaintext version of the String field by 389 concatenating the Data-Length and Password sub-fields. If 390 necessary, pad the resulting string until its length (in 391 octets) is an even multiple of 16. It is recommended that zero 392 octets (0x00) be used for padding. Call this plaintext P. 394 Call the shared secret S, the pseudo-random 128-bit Request 395 Authenticator (from the corresponding Access-Request packet) R, 396 and the contents of the Salt field A. Break P into 16 octet 397 chunks p(1), p(2)...p(i), where i = len(P)/16. Call the 398 ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. 399 Intermediate values b(1), b(2)...c(i) are required. Encryption 400 is performed in the following manner ('+' indicates 401 concatenation): 403 b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) 404 b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) 405 . . 406 . . 407 . . 408 b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) 410 The resulting encrypted String field will contain 411 c(1)+c(2)+...+c(i). 413 On receipt, the process is reversed to yield the plaintext String. 415 5.6. Tunnel-Private-Group-ID 417 Description 419 This Attribute indicates the group ID for a particular tunneled 420 session. The Tunnel-Private-Group-ID Attribute MAY be included in 421 the Access-Request packet if the tunnel initiator can pre- 422 determine the group resulting from a particular connection and 423 SHOULD be included in the Access-Reply packet if this tunnel 424 session is to be treated as belonging to a particular private 425 group. Private groups may be used to associate a tunneled session 426 with a particular group of users. For example, it may be used to 427 facilitate routing of unregistered IP addresses through a 428 particular interface. It SHOULD be included in Accounting-Request 429 packets that contain Acct-Status-Type attributes with values of 430 either Start or Stop and which pertain to a tunneled session. 432 A summary of the Tunnel-Private-Group-ID Attribute format is shown 433 below. The fields are transmitted from left to right. 435 0 1 2 3 436 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Type | Length | Tag | String ... 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Type 442 81 for Tunnel-Private-Group-ID. 444 Length 445 >= 3 447 Tag 448 The Tag field is one octet in length and is intended to provide a 449 means of grouping attributes in the same packet which refer to the 450 same tunnel. If the value of the Tag field is greater than 0x00 451 and less than or equal to 0x1F, it SHOULD be interpreted as 452 indicating which tunnel (of several alternatives) this attribute 453 pertains. If the Tag field is greater than 0x1F, it SHOULD be 454 interpreted as the first byte of the following String field. 456 String 457 This field must be present. The group ID is represented by the 458 String field. There is no restriction on the format of group IDs. 460 5.7. Tunnel-Assignment-ID 462 Description 464 This Attribute is used to indicate to the tunnel initiator the 465 particular tunnel to which a session is to be assigned. Some 466 tunneling protocols, such as PPTP and L2TP, allow for sessions 467 between the same two tunnel endpoints to be multiplexed over the 468 same tunnel and also for a given session to utilize its own 469 dedicated tunnel. This attribute provides a mechanism for RADIUS 470 to be used to inform the tunnel initiator (e.g. PAC, LAC) whether 471 to assign the session to a multiplexed tunnel or to a separate 472 tunnel. Furthermore, it allows for sessions sharing multiplexed 473 tunnels to be assigned to different multiplexed tunnels. 475 A particular tunneling implementation may assign differing 476 characteristics to particular tunnels. For example, different 477 tunnels may be assigned different QOS parameters. Such tunnels 478 may be used to carry either individual or multiple sessions. The 479 Tunnel-Assignment-ID attribute thus allows the RADIUS server to 480 indicate that a particular session is to be assigned to a tunnel 481 that provides an appropriate level of service. It is expected 482 that any QOS-related RADIUS tunneling attributes defined in the 483 future that accompany this attribute will be associated by the 484 tunnel initiator with the ID given by this attribute. In the 485 meantime, any semantic given to a particular ID string is a matter 486 left to local configuration in the tunnel initiator. 488 The Tunnel-Assignment-ID attribute is of significance only to 489 RADIUS and the tunnel initiator. The ID it specifies is intended 490 to be of only local use to RADIUS and the tunnel initiator. The 491 ID assigned by the tunnel initiator is not conveyed to the tunnel 492 peer. 494 This attribute MAY be included in the Access-Accept. The tunnel 495 initiator receiving this attribute MAY choose to ignore it and 496 assign the session to an arbitrary multiplexed or non-multiplexed 497 tunnel between the desired endpoints. This attribute SHOULD also 498 be included in Accounting-Request packets which contain Acct- 499 Status-Type attributes with values of either Start or Stop and 500 which pertain to a tunneled session. 502 If a tunnel initiator supports the Tunnel-Assignment-ID Attribute, 503 then it should assign a session to a tunnel in the following 504 manner: 506 If this attribute is present and a tunnel exists between the 507 specified endpoints with the specified ID, then the session 508 should be assigned to that tunnel. 510 If this attribute is present and no tunnel exists between the 511 specified endpoints with the specified ID, then a new tunnel 512 should be established for the session and the specified ID 513 should be associated with the new tunnel. 515 If this attribute is not present, then the session is assigned 516 to an unnamed tunnel. If an unnamed tunnel does not yet exist 517 between the specified endpoints then it is established and used 518 for this and subsequent sessions established without the 519 Tunnel-Assignment-ID attribute. A tunnel initiator MUST NOT 520 assign a session for which a Tunnel-Assignment-ID Attribute was 521 not specified to a named tunnel (i.e. one that was initiated by 522 a session specifying this attribute). 524 Note that the same ID may be used to name different tunnels if 525 such tunnels are between different endpoints. 527 A summary of the Tunnel-Assignment-ID Attribute format is shown 528 below. The fields are transmitted from left to right. 530 0 1 2 3 531 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Type | Length | Tag | String ... 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Type 537 82 for Tunnel-Assignment-ID. 539 Length 540 > 3 542 Tag 543 The Tag field is one octet in length and is intended to provide a 544 means of grouping attributes in the same packet which refer to the 545 same tunnel. If the value of the Tag field is greater than 0x00 546 and less than or equal to 0x1F, it SHOULD be interpreted as 547 indicating which tunnel (of several alternatives) this attribute 548 pertains. If the Tag field is greater than 0x1F, it SHOULD be 549 interpreted as the first byte of the following String field. 551 String 552 This field must be present. The tunnel ID is represented by the 553 String field. There is no restriction on the format of the ID. 555 5.8. Tunnel-Preference 557 Description 559 If more than one set of tunneling attributes is returned by the 560 RADIUS server to the tunnel initiator, this Attribute SHOULD be 561 included in each set to indicate the relative preference assigned 562 to each tunnel. For example, suppose that Attributes describing 563 two tunnels are returned by the server, one with a Tunnel-Type of 564 PPTP and the other with a Tunnel-Type of L2TP. If the tunnel 565 initiator supports only one of the Tunnel-Types returned, it will 566 initiate a tunnel of that type. If, however, it supports both 567 tunnel protocols, it SHOULD use the value of the Tunnel-Preference 568 Attribute to decide which tunnel should be started. The tunnel 569 having the numerically lowest value in the Value field of this 570 Attribute SHOULD be given the highest preference. The values 571 assigned to two or more instances of the Tunnel-Preference 572 Attribute within a given Access-Accept packet MAY be identical. 573 In this case, the tunnel initiator SHOULD use locally configured 574 metrics to decide which set of attributes to use. This Attribute 575 MAY be included (as a hint to the server) in Access-Request 576 packets, but the RADIUS server is not required to honor this hint. 578 A summary of the Tunnel-Preference Attribute format is shown below. 579 The fields are transmitted from left to right. 581 0 1 2 3 582 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Type | Length | Tag | Value 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Value (cont) | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 Type 590 83 for Tunnel-Preference 592 Length 593 Always 6. 595 Tag 596 The Tag field is one octet in length and is intended to provide a 597 means of grouping attributes in the same packet which refer to the 598 same tunnel. Valid values for this field are 0x01 through 0x1F, 599 inclusive. If the Tag field is unused, it MUST be zero (0x00). 601 Value 602 The Value field is three octets in length and indicates the 603 preference to be given to the tunnel to which it refers; higher 604 preference is given to lower values, with 0x000000 being most 605 preferred and 0xFFFFFF least preferred. 607 5.9. Tunnel-Client-Auth-ID 609 Description 611 This Attribute specifies the name used by the tunnel initiator 612 during the authentication phase of tunnel establishment. The 613 Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the 614 RADIUS server) in the Access-Request packet, and MUST be included 615 in the Access-Request packet if an authentication name other than 616 the default is desired. This Attribute SHOULD be included in 617 Accounting-Request packets which contain Acct-Status-Type 618 attributes with values of either Start or Stop and which pertain 619 to a tunneled session. 621 A summary of the Tunnel-Client-Auth-ID Attribute format is shown 622 below. The fields are transmitted from left to right. 624 0 1 2 3 625 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Type | Length | Tag | String ... 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Type 631 90 for Tunnel-Client-Auth-ID. 633 Length 634 > 3 636 Tag 637 The Tag field is one octet in length and is intended to provide a 638 means of grouping attributes in the same packet which refer to the 639 same tunnel. If the value of the Tag field is greater than 0x00 640 and less than or equal to 0x1F, it SHOULD be interpreted as 641 indicating which tunnel (of several alternatives) this attribute 642 pertains. If the Tag field is greater than 0x1F, it SHOULD be 643 interpreted as the first byte of the following String field. 645 String 646 This field must be present. The String field contains the 647 authentication name of the tunnel initiator. The authentication 648 name SHOULD be represented in the UTF-8 charset. 650 5.10. Tunnel-Server-Auth-ID 652 Description 654 This Attribute specifies the name used by the tunnel terminator 655 during the authentication phase of tunnel establishment. The 656 Tunnel-Server-Auth-ID Attribute MAY be included (as a hint to the 657 RADIUS server) in the Access-Request packet, and MUST be included 658 in the Access-Request packet if an authentication name other than 659 the default is desired. This Attribute SHOULD be included in 660 Accounting-Request packets which contain Acct-Status-Type 661 attributes with values of either Start or Stop and which pertain 662 to a tunneled session. 664 A summary of the Tunnel-Server-Auth-ID Attribute format is shown 665 below. The fields are transmitted from left to right. 667 0 1 2 3 668 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | Type | Length | Tag | String ... 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 Type 674 91 for Tunnel-Server-Auth-ID. 676 Length 677 > 3 679 Tag 680 The Tag field is one octet in length and is intended to provide a 681 means of grouping attributes in the same packet which refer to the 682 same tunnel. If the value of the Tag field is greater than 0x00 683 and less than or equal to 0x1F, it SHOULD be interpreted as 684 indicating which tunnel (of several alternatives) this attribute 685 pertains. If the Tag field is greater than 0x1F, it SHOULD be 686 interpreted as the first byte of the following String field. 688 String 689 This field must be present. The String field contains the 690 authentication name of the tunnel terminator. The authentication 691 name SHOULD be represented in the UTF-8 charset. 693 5.11. Tunnel-DSCP-Value 695 Description 696 This Attribute specifies the differentiated services [20] 697 codepoint to be applied to the tunnel. The Tunnel-DSCP-Value 698 Attribute MAY be included (as a hint to the RADIUS server) in the 699 Access-Request packet, and it SHOULD be included in the Access- 700 Accept packet if other than best-effort service is desired for the 701 tunnel in question. This Attribute SHOULD be included in 702 Accounting-Request packets which contain Acct-Status-Type 703 attributes with values of either Start or Stop and which pertain 704 to a tunneled session. 706 A summary of the Tunnel-DSCP-Value Attribute format is shown below. 707 The fields are transmitted from left to right. 709 0 1 2 3 710 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Type | Length | Tag | Value 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 Value (cont) | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 Type 718 ?? for Tunnel-DSCP-Value. 720 Length 721 Always 6 723 Tag 724 The Tag field is one octet in length and is intended to provide a 725 means of grouping attributes in the same packet which refer to the 726 same tunnel. Valid values for this field are 0x01 through 0x1F, 727 inclusive. If the Tag field is unused, it MUST be zero (0x00). 729 Value 730 The Value field is three octets in length. The low-order (right- 731 most) six bits of the field contain the codepoint [21] to be 732 applied to the tunnel. 734 6. Table of Attributes 736 The following table provides a guide to which of the above attributes 737 may be found in which kinds of packets, and in what quantity. 739 Request Accept Reject Challenge Acct-Request # Attribute 740 0+ 0+ 0 0 0-1 64 Tunnel-Type 741 0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type 742 0+ 0+ 0 0 0-1 66 Tunnel-Client-Endpoint 743 0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint 744 0 0+ 0 0 0 69 Tunnel-Password 745 0+ 0+ 0 0 0-1 81 Tunnel-Private-Group-ID 746 0 0+ 0 0 0-1 82 Tunnel-Assignment-ID 747 0+ 0+ 0 0 0 83 Tunnel-Preference 748 0+ 0+ 0 0 0-1 90 Tunnel-Client-Auth-ID 749 0+ 0+ 0 0 0-1 91 Tunnel-Server-Auth-ID 750 0+ 0+ 0 0 0-1 ?? Tunnel-DSCP-Value 752 The following table defines the meaning of the above table entries. 754 0 This attribute MUST NOT be present in packet. 755 0+ Zero or more instances of this attribute MAY be present in packet. 756 0-1 Zero or one instance of this attribute MAY be present in packet. 758 7. Security Considerations 760 The Tunnel-Password Attribute may contain information which should only 761 be known to a tunnel endpoint. However, the method used to hide the 762 value of the attribute is such that intervening RADIUS proxies will have 763 knowledge of the contents. For this reason, the Tunnel-Password 764 Attribute SHOULD NOT be included in Access-Accept packets which may pass 765 through (relatively) untrusted RADIUS proxies. In addition, the Tunnel- 766 Password Attribute SHOULD NOT be returned to an unauthenticated client; 767 if the corresponding Access-Request packet did not contain a verified 768 instance of the Signature Attribute [15], the Access-Accept packet 769 SHOULD NOT contain an instance of the Tunnel-Password Attribute. 771 Tunnel protocols offer various levels of security, from none (e.g., 772 PPTP) to strong (e.g., IPSec). Note, however, that in the compulsory 773 tunneling case any security measures in place only apply to traffic 774 between the tunnel endpoints. In particular, end-users SHOULD NOT rely 775 upon the security of the tunnel to protect their data; encryption and/or 776 integrity protection of tunneled traffic MUST NOT be considered as a 777 replacement for end-to-end security. 779 8. IANA Considerations 781 This document defines a number of "magic" numbers to be maintained by 782 the IANA. This section explains the criteria to be used by the IANA to 783 assign additional numbers in each of these lists. The following 784 subsections describe the assignment policy for the namespaces defined 785 elsewhere in this document. 787 8.1. Tunnel-Type Attribute Values 789 Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1; the 790 remaining values are available for assignment by the IANA with IETF 791 Consensus [16]. 793 8.2. Tunnel-Medium-Type Attribute Values 795 Values 1-15 of the Tunnel-Medium-Type Attribute are defined in Section 796 5.2; the remaining values are available for assignment by the IANA with 797 IETF Consensus [16]. 799 9. References 801 [1] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., Zorn, 802 G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999 804 [2] Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two 805 Forwarding (Protocol) 'L2F'", RFC 2341, May 1998 807 [3] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., Zorn, G., 808 Palter, B., "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 809 1999 811 [4] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, 812 November 1997 814 [5] Kent, S., Atkinson, R., "Security Architecture for the Internet 815 Protocol", RFC 2401, November 1998 817 [6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996 819 [7] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 820 1996 822 [8] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, 823 August 1995 825 [9] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 826 Encapsulation (GRE)", RFC 1701, October 1994 828 [10] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 830 [11] Zorn, G., Mitton, D., "RADIUS Accounting Modifications for Tunnel 831 Protocol Support", RFC 2867, June 2000 833 [12] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 834 Authentication Dialin User Service (RADIUS)", RFC 2865, June 2000 836 [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement 837 Levels", BCP 14, RFC 2119, March 1997 839 [14] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 840 October 1994 842 [15] Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions", RFC 843 2869, June 2000 845 [16] Narten, T., Alvestrand, H., "Guidelines for writing an IANA 846 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 848 [17] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", 849 RFC 2373, July 1998 851 [18] Patel, B., Aboba, B., Dixon, W., Zorn, G., Booth, S., "Securing 852 L2TP using IPSEC", draft-ietf-l2tpext-security-02.txt (work in 853 progress), November 2001 855 [19] Aboba, B., Zorn, G., "Implementation of L2TP Compulsory Tunneling 856 via RADIUS", RFC 2809, April 2000 858 [20] Nichols, K., Blake, S., Baker, F., Black, D., "Definition of the 859 Differentiated Services Field (DS Field) in the IPv4 and IPv6 860 Headers", RFC 2474, December 1998 862 [21] IANA DSCP Registry, http://www.isi.edu/in- 863 notes/iana/assignments/dscp-registry 865 10. Acknowledgements 867 Thanks to Dave Mitton for pointing out a nasty circular dependency in 868 the original Tunnel-Password attribute definition, Mike Mun for catching 869 a cut-and-paste error in Section 3.10 Of RFC 2868 and (in no particular 870 order) to Kory Hamzeh, Bertrand Buclin, Andy Valencia, Bill Westfield, 871 Kris Michielsen, Gurdeep Singh Pall, Ran Atkinson, Aydin Edguer, and 872 Bernard Aboba for useful input and review. 874 11. Authors' Addresses 876 Questions about this memo can be directed to: 878 Glen Zorn 879 Cisco Systems 880 500 108th Avenue N.E. 881 Suite 500 882 Bellevue, Washington 98004 883 USA 885 Phone: +1 425 438 8210 886 FAX: +1 425 438 1848 887 E-Mail: gwz@cisco.com 889 Dory Leifer 890 Tut Systems, Inc. 891 220 East Huron, Suite 220 892 Ann Arbor, MI 48104 893 USA 895 Phone: +1 734 995 1697 896 E-Mail: leifer@del.com 898 John Shriver 899 Intel Corporation 900 28 Crosby Drive 901 Bedford, MA 01730 903 Phone: +1 781 687 1329 904 E-Mail: John.Shriver@intel.com 906 Allan Rubens 907 Tut Systems, Inc. 908 220 East Huron, Suite 220 909 Ann Arbor, MI 48104 910 USA 912 Phone: +1 734 995 1697 913 E-Mail: arubens@tutsys.com 915 Matt Holdrege 916 ipVerse 917 223 Ximeno Avenue 918 Long Beach, California 90803 919 USA 921 E-Mail: matt@ipverse.com 922 Ignacio Goyret 923 Lucent Technologies 924 One Ascend Plaza 925 1701 Harbor Bay Parkway 926 Alameda, California 94502 927 USA 929 Phone: +1 510 769 6001 930 E-Mail: igoyret@lucent.com 932 12. Expiration Date 934 This memo is filed as and expires May 935 17, 2002.