idnits 2.17.1 draft-ietf-dhc-auth-suboption-00.txt: 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 23, 2002) is 7976 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) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '6') ** Obsolete normative reference: RFC 2845 (ref. '7') (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group M. Stapp 3 Internet-Draft Cisco Systems, Inc. 4 Expires: December 22, 2002 T. Lemon 5 Nominum, Inc. 6 June 23, 2002 8 The Authentication Suboption for the DHCP Relay Agent Option 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 22, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 The DHCP Relay Agent Information Option RFC3046[1] conveys 41 information between a DHCP Relay Agent and a DHCP server. This 42 specification defines a new authentication suboption for that option 43 which supports source entity authentication and data integrity for 44 that option. The authentication suboption contains a payload derived 45 from the option used in DHCP Authentication RFC3118[2]. 47 Table of Contents 49 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1 Requirements Terminology . . . . . . . . . . . . . . . . . . 3 51 1.2 DHCP Terminology . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Suboption Format . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Replay Detection . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Computing Authentication Information . . . . . . . . . . . . 5 56 5.1 The HMAC-MD5 Algorithm . . . . . . . . . . . . . . . . . . . 6 57 6. Procedures for Sending Messages . . . . . . . . . . . . . . 7 58 6.1 Replay Detection . . . . . . . . . . . . . . . . . . . . . . 7 59 6.2 Packet Preparation . . . . . . . . . . . . . . . . . . . . . 7 60 6.3 Signature Computation . . . . . . . . . . . . . . . . . . . 7 61 6.4 Sending the Message . . . . . . . . . . . . . . . . . . . . 8 62 7. Procedures for Processing Incoming Messages . . . . . . . . 8 63 7.1 Initial Examination . . . . . . . . . . . . . . . . . . . . 8 64 7.2 Replay Detection Check . . . . . . . . . . . . . . . . . . . 8 65 7.3 Signature Check . . . . . . . . . . . . . . . . . . . . . . 9 66 8. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 9 67 8.1 Sending Messages to Servers . . . . . . . . . . . . . . . . 9 68 8.2 Receiving Messages from Servers . . . . . . . . . . . . . . 9 69 9. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 9 70 9.1 Receiving Messages from Relay Agents . . . . . . . . . . . . 10 71 9.2 Sending Reply Messages to Relay Agents . . . . . . . . . . . 10 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 73 11. Security Considerations . . . . . . . . . . . . . . . . . . 10 74 11.1 Protocol Vulnerabilities . . . . . . . . . . . . . . . . . . 11 75 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 76 References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 78 Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 80 1. Terminology 82 1.1 Requirements Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119[3]. 88 1.2 DHCP Terminology 90 DISCUSSION: 91 Is there anything that should go here, or do we think that 92 readers will be sufficiently familiar with DHCP? 94 2. Introduction 96 DHCP (RFC2131[4]) provides IP addresses and configuration 97 information for IPv4 clients. It includes a relay-agent capability, 98 in which processes within the network infrastructure receive 99 broadcast messages from clients and forward them to servers as 100 unicast messages. In network environments like DOCSIS 101 data-over-cable and DSL, it has proven useful for the relay agent to 102 add information to the DHCP message before forwarding it, using the 103 relay-agent information option, RFC3046[1]. The kind of information 104 that relays add is often used in the server's decision making about 105 the addresses and configuration parameters that the client should 106 receive. The way that the relay-agent data is used in server 107 decision-making tends to make that data very important, and 108 highlights the importance of the trust relationship between the 109 relay agent and the server. 111 The existing DHCP Authentication[2] specification only covers 112 communication between the DHCP client and server. Because 113 relay-agent information is added after the client has signed its 114 message, the DHCP Authentication specification explictly excludes 115 relay-agent data from that authentication. 117 The goals of this specification are: 118 1. to define a method that a relay-agent can use to protect the 119 integrity of the data that the relay adds 120 2. to provide replay protection for that data 121 3. to leverage the mechanisms that DHCP Authentication specifies 122 in order to leverage the security review and implementation 123 code-base of that specification. 125 In order to meet these goals, we specify a new relay-agent 126 suboption, the Authentication suboption. The format of this 127 suboption is very similar to the DHCP Authentication option's 128 format, and the specification of the cryptographic methods and 129 signature computation for the suboption are inherited from that 130 option. 132 The Authentication suboption is included by relay agents who wish to 133 ensure the integrity of the data they include in the Relay Agent 134 option. These relay agents are configured with the parameters 135 necessary to generate cryptographically strong signatures of the 136 data in the DHCP messages which they forward to DHCP servers. A DHCP 137 server configured to process the Authentication suboption uses the 138 information in the suboption to validate the signature in the 139 suboption, and continues processing the packet only if the signature 140 is valid. If the DHCP server sends a response, it includes an 141 Authentication suboption in its response message, signing the data 142 in its message. Relay agents check the signatures in DHCP server 143 responses and decide whether to forward the responses based on the 144 signatures' validity. 146 3. Suboption Format 148 The format of the Authentication suboption is inherited from the 149 DHCP Authentication option. 151 0 1 2 3 152 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Code | Length | Algorithm | MBZ | RDM | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Replay Detection (64 bits) | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Replay Detection cont. | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | | 161 | | 162 | Authentication Information | 163 | | 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 The code for the suboption is TBD. The length field includes the 168 lengths of the algorithm, RDM, and all subsequent suboption fields 169 in octets. 171 The Algorithm field defines the algorithm used to generate the 172 authentication information. 174 The Replay Detection Method (RDM) field defines the method used to 175 generate the Replay Detection Data. 177 The Reply Detection field contains a value used to detect replays, 178 interpreted according to the RDM. 180 The Authentication Information field contains the data required to 181 communicate algorithm-specific parameters, as well as the signature. 182 The signature is usually a digest of the data in the DHCP packet 183 computed using the method specified by the Algorithm field. 185 4. Replay Detection 187 The replay-detection mechanism is based on the notion that a 188 receiver can determine whether or not a message has a valid replay 189 token value. The default RDM, with value 1, specifies that the 190 Replay Detection field contains an increasing counter value. The 191 receiver associates a replay counter with each sender, and rejects 192 any message containing an authentication suboption with a Replay 193 Detection counter value less than the last valid value. DHCP servers 194 MAY identify relays by giaddr value or by other data in the message 195 (e.g. data in other relay-agent suboptions). Relays identify DHCP 196 servers by source IP address. If the message's replay detection 197 value is valid, and the signature is also valid, the receiver 198 updates the its notion of the last valid replay counter value 199 associated with the sender. 201 All implementations MUST support the default RDM. Additional methods 202 may be defined in the future, following the process described in 203 Section 10. 205 Receivers SHOULD perform the replay-detection check before 206 validating the signature. The authentication hash calculation is 207 likely to be much more expensive than the replay-detection value 208 check. 210 DISCUSSION: 211 This places a burden on the receiver to maintain some run-time 212 state (the most-recent valid counter value) for each sender, but 213 the number of members in a DHCP agent-server system is unlikely 214 to be unmanageably large. 216 5. Computing Authentication Information 218 The Authentication Information field contains a computed signature, 219 generated by the sender. All algorithms are defined to process the 220 data in the DHCP messages in the same way. The sender and receiver 221 compute the signature across a buffer containing all of the bytes in 222 the DHCP message, including the fixed DHCP message header, the DHCP 223 options, and the relay-agent suboption, with the following 224 exceptions. The value of the 'hops' field MUST be set to zero, 225 because its value may be changed in transmission. The value of the 226 'giaddr' field MUST also be set to all-zeroes because it may be 227 modified in networks where one relay agent adds the relay-agent 228 option but another relay sets 'giaddr' (see RFC3046[1], section 229 2.1). In addition, because the relay-agent option itself is included 230 in the computation, the 'signature' part of the 'authentication 231 information' field in the Authentication suboption is set to all 232 zeroes. The relay-agent option length, the Authentication suboption 233 length and other Authentication suboption fields are all included in 234 the computation. 236 All implementations MUST support Algorithm 1, the HMAC-MD5 237 algorithm. Additional algorithms may be defined in the future, 238 following the process described in Section 10. 240 5.1 The HMAC-MD5 Algorithm 242 Algorithm 1 is assigned to the HMAC[5] protocol, using the MD5[6] 243 hash function. This algorithm requires that a shared secret key be 244 configured at the relay agent and the DHCP server. A 32-bit Key 245 Identifier is associated with each shared key, and this identifier 246 is carried in the first 4 bytes of the Authentication Information 247 field of the Authentication suboption. The HMAC-MD5 computation 248 generates a 16-byte signature, which is placed in the Authentication 249 Information field after the Key ID. 251 The format of the Authentication suboption when Algorithm 1 is used 252 is: 254 0 1 2 3 255 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Code | 34 |0 0 0 0 0 0 0 1| MBZ | RDM | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Replay Detection (64 bits) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Replay Detection cont. | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Key ID (32 bits) | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 | HMAC-MD5 (128 bits) | 267 | | 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 The suboption length is 34, the RDM and Replay Detection fields are 272 as specified in Section 4, the Key ID is set by the sender to the ID 273 of the key used in computing the signature, as an integer value in 274 network byte-order. The HMAC signature follows the Key ID. 276 The Key ID exists only to allow the sender and receiver to specify a 277 shared secret in cases where more than one secret is in use among a 278 network's relays and DHCP servers. The Key ID values are entirely a 279 matter of local configuration; they only need to be locally unique. 280 This specification does not define any semantics or impose any 281 requirements on this algorithm's Key ID values. 283 DISCUSSION: 284 We specify a four-byte Key ID, following the example of the DHCP 285 Authentication RFC. Other authentication protocols, like DNS 286 TSIG[7], use a key name. A key name is more flexible and 287 potentially more human-readable than a key id. DHCP servers may 288 well be configured to use key names for DNS updates using TSIG, 289 so it might simplify DHCP server configuration if some of the 290 key-management for both protocols could be shared. Should we 291 specify a variable-length Key Name instead of a fixed-length Key 292 ID? 294 6. Procedures for Sending Messages 296 6.1 Replay Detection 298 The sender obtains a replay-detection counter value to use, based on 299 the RDM it is using. If the sender is using RDM 1, the default RDM, 300 the value MUST be greater than any previously-sent value. 302 6.2 Packet Preparation 304 The sender sets the 'giaddr' field and the 'hops' field to all 305 zeroes. The sender appends the relay-agent information option to the 306 client's packet, including the Authentication suboption. The sender 307 sets the suboption length, places the Replay Detection value into 308 the Replay Detection field of the suboption, and sets the algorithm 309 to the algorithm number that it is using. If the sender is using 310 HMAC-MD5, it sets the Key ID field to the appropriate value. The 311 sender sets the field which will contain the signature to all 312 zeroes. Other algorithms may specify additional preparation steps. 314 6.3 Signature Computation 316 The sender computes the signature across the entire DHCP message, 317 using the algorithm it has selected. The sender places the result of 318 the computation into the signature field of the Authentication 319 suboption. 321 6.4 Sending the Message 323 The sender restores the 'hops' field's value, and sends the message. 325 7. Procedures for Processing Incoming Messages 327 7.1 Initial Examination 329 The receiver examines the message, the value of the giaddr field, 330 and determines whether the packet includes the relay-agent 331 information option. The receiver uses its configuration to determine 332 whether it should expect an Authentication suboption. The receiver 333 MAY be configured to drop incoming messages which do not contain a 334 valid relay agent information option and Authentication suboption. 336 If the receiver determines that the Authentication suboption is 337 present and that it should process the suboption, it uses the data 338 in the message to determine which algorithm, key, and RDM to use in 339 validating the message. If the receiver cannot determine which 340 algorithm, key, and RDM to use, or if it does not support the value 341 indicated in the message, it SHOULD be configured to drop the 342 message. Because this situation could indicate a misconfiguration 343 which could deny service to clients, receivers MAY attempt to notify 344 their administrators or log an error message. 346 7.2 Replay Detection Check 348 The receiver examines the RDM field. Receivers MUST discard 349 messages containing RDM values which they do not support. Because 350 this may indicate a misconfiguration at the sender, an attempt 351 SHOULD be made to indicate this condition to the administrator, by 352 incrementing an error counter or writing a log message. If the 353 receiver supports the RDM, it examines the value in the Replay 354 Detection field using the procedures in the RDM and in Section 4. If 355 the Replay value is not valid, the receiver MUST drop the message. 357 DISCUSSION: 358 Note that the receiver must not update its notion of the last 359 valid Replay Detection value for the sender at this point. Until 360 the signature has been checked, the Replay Detection field cannot 361 be trusted. If the receiver trusts the Replay Detection value 362 without checking the signature, a malicious host could send a 363 replayed message with a Replay Detection value that was very 364 high, tricking the receiver into rejected legitimate values from 365 the sender. 367 7.3 Signature Check 369 The receiver prepares the packet in order to check the signature. 370 The receiver sets the 'giaddr' and 'hops' fields to zero, and sets 371 the signature field of the Authentication suboption to all zeroes. 372 Using the algorithm and key associated with the sender, the receiver 373 computes a hash of the message. The receiver compares the result of 374 its computation with the value sent by the sender. If the signatures 375 do not match, the receiver MUST drop the message. Otherwise, the 376 receiver updates its notion of the last valid Replay Detection value 377 associated with the sender, and processes the message. 379 8. Relay Agent Behavior 381 DHCP Relay agents are typically configured with the addresses of one 382 or more DHCP servers. A relay agent which implements this suboption 383 requires an algorithm number for each server, as well as appropriate 384 credentials (i.e. keys) to use. Relay implementations SHOULD support 385 configuration which indicates that all relayed messages should 386 include the authentication suboption. This SHOULD be disabled by 387 default. Relays MAY support configuration that indicates that 388 certain destination servers support the authentication suboption, 389 while other servers do not. Relays MAY support configuration of a 390 single algorithm number and key to be used with all DHCP servers, or 391 they MAY support configuration of different algorithms and keys for 392 each server. 394 8.1 Sending Messages to Servers 396 When the relay agent receives a broadcast packet from a client, it 397 determines which DHCP servers (or other relays) should receive 398 copies of the message. If the relay is configured to include the 399 Authentication suboption, it determines which Algorithm and RDM to 400 use, and then it performs the steps in Section 6. 402 8.2 Receiving Messages from Servers 404 When the relay agent receives a message, it determines from its 405 configuration whether it expects the message to contain a 406 relay-agent information option and an Authentication suboption. The 407 relay MAY be configured to drop response messages that do not 408 contain the Authentication suboption. The relay then follows the 409 procedures in Section 7. 411 9. DHCP Server Behavior 413 DHCP servers may interact with multiple relay agents. Server 414 implementations MAY support configuration that associates the same 415 algorithm and key with all relay agents. Servers MAY support 416 configuration which specifies the algorithm and key to use with each 417 relay agent individually. 419 9.1 Receiving Messages from Relay Agents 421 When a DHCP server which implements the Authentication suboption 422 receives a message, it performs the steps in Section 7. 424 9.2 Sending Reply Messages to Relay Agents 426 When the server has prepared a reply message, it uses the incoming 427 request message and its configuration to determine whether it should 428 include a relay-agent information option and an Authentication 429 suboption. If the server is configured to include the Authentication 430 suboption, it determines which Algorithm and RDM to use, and then 431 performs the steps in Section 6. 433 DISCUSSION: 434 This server behavior represents a slight variance from 435 RFC3046[1], Section 2.2. The Authentication suboption is not 436 echoed back from the server to the relay: the server generates 437 its own suboption. 439 10. IANA Considerations 441 Section 3 defines a new suboption for the DHCP relay-agent option, 442 called the Authentication Suboption. IANA is requested to allocate a 443 new suboption code from the relay-agent option suboption number 444 space. 446 This specification introduces two new number-spaces for the 447 Authentication suboption's 'Algorithm' and 'Replay Detection Method' 448 fields. These number spaces are to be created and maintained by IANA. 450 The Algorithm identifier is a one-byte value. Algorithm value 0 is 451 reserved. Algorithm value 1 is assigned to the HMAC-MD5 signature as 452 defined in Section 5.1. Additional algorithm values will be 453 allocated and assigned through IETF consensus, as defined in RFC 454 2434[8]. 456 The RDM identifier is a four-bit value. RDM value 0 is reserved. RDM 457 value 1 is assigned to the use of a monotonically increasing counter 458 value as defined in Section 4. Additional RDM values will be 459 allocated and assigned through IETF consensus, as defined in RFC 460 2434[8]. 462 11. Security Considerations 464 This specification describes a protocol to add source authentication 465 and message integrity protection to the messages between DHCP relay 466 agents and DHCP servers. 468 The use of this protocol imposes a new computational burden on relay 469 agents and servers, because they must perform cryptographic hash 470 calculations when they send and receive messages. This burden may 471 add latency to DHCP messages exchanges. Because relay agents are 472 involved when clients reboot, periods of very high reboot activity 473 will result in the largest number of messages which have to be 474 signed and verified. During a cable MSO head-end reboot event, for 475 example, the time required for all clients to be served may increase. 477 11.1 Protocol Vulnerabilities 479 Because DHCP is a UDP protocol, messages between relays and servers 480 may be delivered in a different order than the order in which they 481 were generated. The replay-detection mechanism will cause receivers 482 to drop packets which are delivered 'late', leading to client 483 retries. The retry mechanisms which most clients implement should 484 not cause this to be an enormous issue, but it will cause senders to 485 do computational work which will be wasted if their messages are 486 re-ordered. 488 12. Acknowledgements 490 The need for this specification was made clear by comments made by 491 Thomas Narten and John Schnizlein, and the use of the DHCP 492 Authentication option format was suggested by Josh Littlefield, at 493 IETF 53. 495 References 497 [1] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 498 January 2001. 500 [2] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 501 RFC 3118, June 2001. 503 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 504 Levels", RFC 2119, March 1997. 506 [4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 507 March 1997. 509 [5] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 510 for Message Authentication", RFC 2104, February 1997. 512 [6] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April 513 1992. 515 [7] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 516 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 517 2845, May 2000. 519 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 520 Considerations Section in RFCs", RFC 2434, October 1998. 522 Authors' Addresses 524 Mark Stapp 525 Cisco Systems, Inc. 526 250 Apollo Dr. 527 Chelmsford, MA 01824 528 USA 530 Phone: 978.244.8498 531 EMail: mjs@cisco.com 533 Ted Lemon 534 Nominum, Inc. 535 950 Charter St. 536 Redwood City, CA 94063 537 USA 539 EMail: mellon@nominum.com 541 Full Copyright Statement 543 Copyright (C) The Internet Society (2002). All Rights Reserved. 545 This document and translations of it may be copied and furnished to 546 others, and derivative works that comment on or otherwise explain it 547 or assist in its implementation may be prepared, copied, published 548 and distributed, in whole or in part, without restriction of any 549 kind, provided that the above copyright notice and this paragraph 550 are included on all such copies and derivative works. However, this 551 document itself may not be modified in any way, such as by removing 552 the copyright notice or references to the Internet Society or other 553 Internet organizations, except as needed for the purpose of 554 developing Internet standards in which case the procedures for 555 copyrights defined in the Internet Standards process must be 556 followed, or as required to translate it into languages other than 557 English. 559 The limited permissions granted above are perpetual and will not be 560 revoked by the Internet Society or its successors or assigns. 562 This document and the information contained herein is provided on an 563 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 564 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 565 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 566 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 567 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 569 Acknowledgement 571 Funding for the RFC editor function is currently provided by the 572 Internet Society.