--- 1/draft-ietf-dhc-userclass-07.txt 2006-02-04 23:06:31.000000000 +0100 +++ 2/draft-ietf-dhc-userclass-08.txt 2006-02-04 23:06:31.000000000 +0100 @@ -1,19 +1,19 @@ Internet Engineering Task Force Glenn Stump, IBM INTERNET DRAFT Ralph Droms, Bucknell University -Date: May 2000 Ye Gu, Ramesh Vyaghrapuri, -Expires: October 2000 Ann Demirtjis, Microsoft +Date: June 2000 Ye Gu, Ramesh Vyaghrapuri, +Expires: November 2000 Ann Demirtjis, Microsoft Burcak Beser, 3Com Jerome Privat, BT The User Class Option for DHCP - + Status of this Memo The document is an Internet-Draft and is in full conformance with all of the provisions of Section 10 of RFC 2026. 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. @@ -113,74 +113,98 @@ This option is a DHCP option [1, 2]. This option MAY carry multiple User Classes. Servers may interpret the meanings of multiple class specifications in an implementation dependent or configuration dependent manner, and so the use of multiple classes by a DHCP client should be based on the specific server implementation and configuration which will be used to process that User class option. -The code for this option is TBD. -Each User Class value is indicated in an opaque field and is -preceded by a one-byte field giving its length. -Let n be the number of User Classes carried in the -option. The length of the option as specified in Len must be -the sum of the lengths of each of the class names plus n: -Len= Len1 + Len2 + ...+ Lenn + n. +The format of this option is as follows: - Code Len Len1 Len2 - +-----+-----+-----+----------+-----+--------------+---- - | TBD | N | L1 | class 1 | L2 | class 2 |... - +-----+-----+-----+----------+-----+--------------+---- + Code Len Value + +-----+-----+--------------------- . . . --+ + | 77 | N | User Class Data ('Len' octets) | + +-----+-----+--------------------- . . . --+ + +where Value consists of zero or more instances of User Class Data. +Each instance of User Class Data is formatted as follows: + + UC_Len_i User_Class_Data_i + +--------+------------------------ . . . --+ + | L_i | Opaque-Data ('UC_Len_i' octets) | + +--------+------------------------ . . . --+ + +Each User Class value (User_Class_Data_i) is indicated as an opaque +field. +The value in UC_Len_i does not include the length field itself +and MUST be non-zero. +Let m be the number of User Classes carried in the option. The +length of the option as specified in Len must be the sum of the +lengths of each of the class names plus m: +Len= UC_Len_1 + UC_Len_2 + ... + UC_Len_m + m. +If any instances of User Class Data are present, the minimum +value of Len is two (Len = UC_Len_1 + 1 = 1 + 1 = 2). + +The Code for this option is 77. A server that is not equipped to interpret any given user class specified by a client MUST ignore it (although it may be reported). If a server recognizes one or more user classes specified by the client, but does not recognize one or more other user classes specified by the client, the server MAY use the user classes it recognizes. DHCP clients implementing this option SHOULD allow users to enter one or more user class values. -5. Security Considerations +5. IANA Considerations + +Option 77, which IANA has already assigned for this purpose, +should be used as the User Class Option for DHCP. + +6. Security Considerations DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed is section 7 of the protocol specification [1]. This lack of authentication mechanism means that a DHCP server cannot check if a client or user is authorised to use a given User Class. +This introduces an obvious vulnerability when using the User +Class option. For example, if the User Class is used to give +out special IP addresses that have better QoS associated with +them (as described in section 1), there is no way to authenticate +a client and it is therefore impossible to check if a client is +authorised to use such an IP address. -6. References +7. References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [2] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997. -7. Acknowledgments +8. Acknowledgments -This document combines ideas from draft-ietf-dhc-userclass-03.txt -(by Glenn Stump and Ralph Droms) and -draft-ietf-dhc-useraddr-00.txt (by Ye Gu, Ramesh Vyaghrapuri and -Burcak Beser). It has been published as a revision to -draft-ietf-dhc-userclass-05.txt. +This document is based on earlier drafts by Glenn Stump, +Ralph Droms, Ye Gu, Ramesh Vyaghrapuri and Burcak Beser. Thanks to Ted Lemon, Steve Gonczi, Kim Kinnear, Bernie Volz, -Richard Jones, Barr Hibbs for their comments and suggestions. +Richard Jones, Barr Hibbs and Thomas Narten for their comments +and suggestions. -8. Author Information +9. Author Information Glenn Stump IBM Networking Software P.O. Box 12195 RTP, NC 27709 Phone: (919) 301-4277 Email: stumpga@us.ibm.com Ralph Droms Computer Science Department @@ -218,23 +242,23 @@ Phone: 425-705-2254 Email: annd@microsoft.com Jerome Privat BT Advanced Communications Technology Centre Adastral Park, Martlesham Heath, IP5 3RE UK Phone: +44 1473 648910 Email: jerome.privat@bt.com -9. Expiration +10. Expiration -This document will expire on October 2000. +This document will expire on November 2000. 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