idnits 2.17.1 draft-ietf-syslog-transport-tls-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 622. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 18, 2008) is 5789 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) == Outdated reference: A later version (-29) exists of draft-ietf-syslog-sign-23 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Syslog Working Group F. Miao, Ed. 3 Internet-Draft Y. Ma, Ed. 4 Intended status: Standards Track Huawei Technologies 5 Expires: December 20, 2008 J. Salowey, Ed. 6 Cisco Systems, Inc. 7 June 18, 2008 9 TLS Transport Mapping for Syslog 10 draft-ietf-syslog-transport-tls-13.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 20, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document describes the use of Transport Layer Security (TLS) to 44 provide a secure connection for the transport of syslog messages. 45 This document describes the security threats to syslog and how TLS 46 can be used to counter such threats. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Security Requirements for Syslog . . . . . . . . . . . . . . . 3 53 3. Using TLS to Secure Syslog . . . . . . . . . . . . . . . . . . 4 54 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 5 55 4.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 5 56 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2.1. Certificate-Based Authentication . . . . . . . . . . . 5 58 4.2.2. Certificate Fingerprints . . . . . . . . . . . . . . . 6 59 4.2.3. Cryptographic Level . . . . . . . . . . . . . . . . . 7 60 4.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.3.1. Message Length . . . . . . . . . . . . . . . . . . . . 7 62 4.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5. Security Policies . . . . . . . . . . . . . . . . . . . . . . 8 64 5.1. End-Entity Certificate Based Authorization . . . . . . . . 8 65 5.2. Subject Name Authorization . . . . . . . . . . . . . . . . 9 66 5.3. Unauthenticated Transport Sender . . . . . . . . . . . . . 9 67 5.4. Unauthenticated Transport Receiver . . . . . . . . . . . . 9 68 5.5. Unauthenticated Transport Receiver and Sender . . . . . . 10 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 6.1. Authentication and Authorization Policies . . . . . . . . 10 71 6.2. Name Validation . . . . . . . . . . . . . . . . . . . . . 11 72 6.3. Reliability . . . . . . . . . . . . . . . . . . . . . . . 11 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 7.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 11 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 79 Appendix A. Changes from -12 . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 81 Intellectual Property and Copyright Statements . . . . . . . . . . 14 83 1. Introduction 85 This document describes the use of Transport Layer Security (TLS 86 [I-D.ietf-tls-rfc4346-bis]) to provide a secure connection for the 87 transport of syslog [I-D.ietf-syslog-protocol] messages. This 88 document describes the security threats to syslog and how TLS can be 89 used to counter such threats. 91 1.1. Terminology 93 The following definitions are used in this document: 95 o An "originator" generates syslog content to be carried in a 96 message. 98 o A "collector" gathers syslog content for further analysis. 100 o A "relay" forwards messages, accepting messages from originators 101 or other relays, and sending them to collectors or other relays. 103 o A "transport sender" passes syslog messages to a specific 104 transport protocol. 106 o A "transport receiver" takes syslog messages from a specific 107 transport protocol. 109 o A "TLS client" is an application that can initiate a TLS 110 connection by sending a Client Hello to a peer. 112 o A "TLS server" is an application that can receive a Client Hello 113 from a peer and reply with a Server Hello. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2. Security Requirements for Syslog 121 Syslog messages may transit several hops to arrive at the intended 122 collector. Some intermediary networks may not be trusted by the 123 originator, relay, or receiver because the network is in a different 124 security domain or at a different security level from the originator, 125 relay, or collector. Another security concern is that the 126 originator, relay, or receiver itself is in an insecure network. 128 There are several threats to be addressed for syslog security. The 129 primary threats are: 131 o Masquerade. An unauthorized transport sender may send messages to 132 a legitimate transport receiver, or an unauthorized transport 133 receiver tries to deceive a legitimate transport sender into 134 sending syslog messages to it. 136 o Modification. An attacker between the transport sender and the 137 transport receiver may modify an in-transit syslog message and 138 then forward the message to the transport receiver. Such 139 modification may make the transport receiver misunderstand the 140 message or cause it to behave in undesirable ways. 142 o Disclosure. An unauthorized entity may examine the contents of 143 the syslog messages, gaining unauthorized access to the 144 information. Some data in syslog messages is sensitive and may be 145 useful to an attacker, such as the password of an authorized 146 administrator or user. 148 The secondary threat is: 150 o Message stream modification. An attacker may delete one or more 151 syslog message from a series of messages, replay a message, or 152 alter the delivery sequence. The syslog protocol itself is not 153 based on message order, but an event in a syslog message may 154 relate semantically to events in other messages, so message 155 ordering may be important to understanding a sequence of events. 157 The following threats are deemed to be of lesser importance for 158 syslog, and are not addressed in this document: 160 o Denial of Service 162 o Traffic Analysis 164 3. Using TLS to Secure Syslog 166 TLS can be used as a secure transport to counter all the primary 167 threats to syslog described above: 169 o Confidentiality to counter disclosure of the message contents; 171 o Integrity checking to counter modifications to a message on a hop- 172 by-hop basis; 174 o Server or mutual authentication to counter masquerade. 176 Note: This secure transport (i.e., TLS) only secures syslog transport 177 in a hop-by-hop manner, and is not concerned with the contents of 178 syslog messages. In particular, the authenticated identity of the 179 transport sender (e.g., subject name in the certificate) is not 180 necessarily related to the HOSTNAME field of the syslog message. 181 When authentication of syslog message origin is required, 182 [I-D.ietf-syslog-sign] can be used. 184 4. Protocol Elements 186 4.1. Port Assignment 188 A syslog transport sender is always a TLS client and a transport 189 receiver is always a TLS server. 191 The TCP port NNN has been allocated as the default port for syslog 192 over TLS, as defined in this document. 194 Note to RFC Editor: please replace NNN with the IANA-assigned value, 195 and remove this note. 197 4.2. Initiation 199 The transport sender should initiate a connection to the transport 200 receiver and then send the TLS Client Hello to begin the TLS 201 handshake. When the TLS handshake has finished the transport sender 202 MAY then send the first syslog message. 204 TLS typically uses certificates [RFC5280] to authenticate peers. 205 Implementations MUST support TLS 1.2 [I-D.ietf-tls-rfc4346-bis] and 206 are REQUIRED to support the mandatory to implement cipher suite, 207 which is TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to 208 apply to future versions of TLS, in which case the mandatory to 209 implement cipher suite for the implemented version MUST be supported. 211 4.2.1. Certificate-Based Authentication 213 Both syslog transport sender (TLS Client) and syslog transport 214 receiver (TLS server) MUST implement certificate-based 215 authentication. This consists of validating the certificate and 216 verifying that the peer has the corresponding private key. The 217 latter part is performed by TLS. To ensure interoperability between 218 clients and servers, the following methods for certificate validation 219 SHALL be implemented: 221 o Certification path validation: The TLS peer is configured with one 222 or more trust anchors (typically root CA certificates), which 223 allow it to verify a binding between the subject name and the 224 public key. Additional policy controls needed for authorizing the 225 syslog transport sender and receiver (i.e., verifying that the 226 subject name represents an authorized party) are described in 227 Section 5. Certificate path validation is performed as defined in 228 [RFC5280]. This method is useful where there is a PKI deployment. 230 o End-entity certificate matching: The transport sender or receiver 231 is configured with information necessary to identify the valid 232 end-entity certificates of its authorized peers. The end-entity 233 certificates can be self-signed, and no certification path 234 validation is needed. Implementations MUST support certificate 235 fingerprints in Section 4.2.2 and MAY allow other formats for end- 236 entity certificates such as a DER encoded certificate. This 237 method provides an alternative to a PKI that is simple to deploy 238 and still maintains a reasonable level of security. 240 Both transport receiver and transport sender implementations MUST 241 provide a means to generate a key pair and self-signed certificate in 242 the case that a key pair and certificate are not available through 243 another mechanism. 245 The transport receiver and transport sender SHOULD provide mechanisms 246 to record the end-entity certificate for the purpose of correlating 247 it with the sent or received data. 249 4.2.2. Certificate Fingerprints 251 Both client and server implementations MUST make the certificate 252 fingerprints for their certificate available through a management 253 interface. 255 The mechanism to generate a fingerprint is to take the hash of the 256 DER-encoded certificate using a cryptographically strong algorithm 257 and convert the result into colon separated, hexadecimal bytes, each 258 represented by 2 uppercase ASCII characters. When a fingerprint 259 value is displayed or configured the fingerprint is prepended with an 260 ASCII label identifying the hash function followed by a colon. 261 Implementations MUST support SHA-1 as the hash algorithm and use the 262 ASCII label "SHA1" to identify the SHA-1 algorithm. The length of a 263 SHA-1 hash is 20 bytes and the length of the corresponding 264 fingerprint string is 64 characters. An example certificate 265 fingerprint is: 267 SHA1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D 269 During validation the hash is extracted from the fingerprint and 270 compared against the hash calculated over the received certificate. 272 4.2.3. Cryptographic Level 274 Syslog applications SHOULD be implemented in a manner that permits 275 administrators, as a matter of local policy, to select the 276 cryptographic level and authentication options they desire. 278 TLS permits the resumption of an earlier TLS session or the use of 279 another active session when a new session is requested, in order to 280 save the expense of another full TLS handshake. The security 281 parameters of the resumed session are reused for the requested 282 session. The security parameters SHOULD be checked against the 283 security requirement of the requested session to make sure that the 284 resumed session provides proper security. 286 4.3. Sending data 288 All syslog messages MUST be sent as TLS "application data". It is 289 possible that multiple syslog messages be contained in one TLS 290 record, or that a syslog message be transferred in multiple TLS 291 records. The application data is defined with the following ABNF 292 [RFC5234] expression: 294 APPLICATION-DATA = 1*SYSLOG-FRAME 296 SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG 298 MSG-LEN = NONZERO-DIGIT *DIGIT 300 SP = %d32 302 NONZERO-DIGIT = %d49-57 304 DIGIT = %d48 / NONZERO-DIGIT 306 SYSLOG-MSG is defined in syslog [I-D.ietf-syslog-protocol] protocol. 308 4.3.1. Message Length 310 The message length is the octet count of the SYSLOG-MSG in the 311 SYSLOG-FRAME. A transport receiver MUST use the message length to 312 delimit a syslog message. There is no upper limit for a message 313 length per se. However, in order to establish a baseline for 314 interoperability, this specification requires that a transport 315 receiver MUST be able to process messages with a length up to and 316 including 2048 octets. Transport receiver SHOULD be able to process 317 messages with lengths up to and including 8192 octets. 319 4.4. Closure 321 A TLS client MUST close the associated TLS connection if the 322 connection is not expected to deliver any syslog messages later. It 323 MUST send a TLS close_notify alert before closing the connection. A 324 client MAY choose to not wait for the server's close_notify alert and 325 simply close the connection, thus generating an incomplete close on 326 the server side. Once the server gets a close_notify from the 327 client, it MUST reply with a close_notify unless it becomes aware 328 that the connection has already been closed by the client (e.g., the 329 closure was indicated by TCP). 331 When no data is received from a connection for a long time (where the 332 application decides what "long" means), a server MAY close the 333 connection. The server MUST attempt to initiate an exchange of 334 close_notify alerts with the client before closing the connection. 335 Servers that are unprepared to receive any more data MAY close the 336 connection after sending the close_notify alert, thus generating an 337 incomplete close on the client side. When the client has received 338 the close_notify alert from the server and still has pending data to 339 send, it SHOULD send the pending data before sending the close_notify 340 alert. 342 5. Security Policies 344 Different environments have different security requirements and 345 therefore would deploy different security policies. This section 346 discusses some of the security policies that may be implemented by 347 syslog transport receivers and syslog transport senders. The 348 security policies describe the requirements for authentication and 349 authorization. The list of policies in this section is not 350 exhaustive and other policies MAY be implemented. 352 If the peer does not meet the requirements of the security policy, 353 the TLS handshake SHOULD be aborted with an appropriate TLS alert. 355 5.1. End-Entity Certificate Based Authorization 357 In the simplest case, the transport sender and receiver are 358 configured with information necessary to identity the valid end- 359 entity certificates of its authorized peers. 361 Implementations MUST support specifying the authorized peers using 362 certificate fingerprints, as described in Section 4.2.1 and 363 Section 4.2.2. 365 5.2. Subject Name Authorization 367 Implementations MUST support specifying the authorized peers using 368 locally configured host names, MUST support certification path 369 validation [RFC5280] and matching the name with the certificate as 370 follows: 372 Implementations MUST support matching the locally configured name 373 against a SubjectAltName field with a type of dNSName and SHOULD 374 support checking the name against the Common Name portion of the 375 Subject Distinguished Name. If more than one identity is present in 376 the certificate, a match in any one of the set is considered 377 acceptable. Matching of host names is case-insensitive. 378 Implementations also MAY support wildcards in locally configured 379 names to match a range of values. For example, a "*" wildcard 380 character MAY be used as the left-most name component. In this case, 381 *.example.com would match a.example.com, foo.example.com, etc., but 382 would not match example.com. Using a wildcard for the entire host 383 name makes it possible to deploy trust-root-based authorization where 384 all credentials issued by a particular CA trust root are authorized. 386 Implementations MAY also support matching a locally configured 387 identifier against other parts of the certificate, such as the 388 SerialNumber portion of the Subject Distinguished Name, or a 389 SubjectAltName of type ipAddress. Implementations MAY support other 390 checks such as restrictions on the depth of a certificate chain. 392 5.3. Unauthenticated Transport Sender 394 In some environments, the authenticity of syslog data is not 395 important or it is verifiable by other means, so transport receivers 396 may accept data from any transport sender. To achieve this, the 397 transport receiver can skip transport sender authentication (by not 398 requesting client authentication in TLS, or accepting any 399 certificate). In this case, the transport receiver is authenticated 400 and authorized, however this policy does not protect against the 401 threat of transport sender masquerade described in Section 2. The 402 use of this policy is generally NOT RECOMMENDED for this reason. 404 5.4. Unauthenticated Transport Receiver 406 In some environments the confidentiality of syslog data is not 407 important so messages are sent to any transport receiver. To achieve 408 this, the transport sender can skip transport receiver authentication 409 (by accepting any certificate). While this policy does authenticate 410 and authorize the transport sender, it does not protect against the 411 threat of transport receiver masquerade described in Section 2, 412 leaving the data sent vulnerable to disclosure and modification. The 413 use of this policy is generally NOT RECOMMENDED for this reason. 415 5.5. Unauthenticated Transport Receiver and Sender 417 In environments where security is not a concern at all, both the 418 transport receiver and transport sender can skip authentication (as 419 described in Sections 5.2 and 5.3). This policy does not protect 420 against any of the threats described in Section 2 and is therefore 421 NOT RECOMMENDED. 423 6. Security Considerations 425 This section describes security considerations in addition to those 426 in [I-D.ietf-tls-rfc4346-bis]. 428 6.1. Authentication and Authorization Policies 430 Section 5 discusses various security policies that may be deployed. 431 The threats in Section 2 are mitigated only if both the transport 432 sender and transport receiver are properly authenticated and 433 authorized, as described in Section 5.1 and Section 5.2. These are 434 the RECOMMENDED configurations for a default policy. 436 If the transport receiver does not authenticate the transport sender 437 it may accept data from an attacker. Unless it has another way of 438 authenticating the source of the data, the data should not be 439 trusted. This is especially important if the syslog data is going to 440 be used to detect and react to security incidents. The transport 441 receiver may also increase its vulnerability to denial of service, 442 resource consumption and other attacks if it does not authenticate 443 the transport sender. Because of the increased vulnerability to 444 attack, this type of configuration is NOT RECOMMENDED. 446 If the transport sender does not authenticate the syslog transport 447 receiver then it may send data to an attacker. This may disclose 448 sensitive data within the log information that is useful to an 449 attacker resulting in further compromises within the system. If a 450 transport sender is operated in this mode, the data sent SHOULD be 451 limited to data that is not valuable to an attacker. In practice 452 this is very difficult to achieve, so this type of configuration is 453 NOT RECOMMENDED. 455 Forgoing authentication and authorization on both sides allows for 456 man-in-the-middle, masquerade and other types of attacks that can 457 completely compromise integrity and confidentiality of the data. 458 This type of configuration is NOT RECOMMENDED. 460 6.2. Name Validation 462 The subject name authorization policy authorizes the subject in the 463 certificate against a locally configured name. It is generally not 464 appropriate to obtain this name through some other means such as DNS 465 lookup since this introduces additional security vulnerabilities. 467 6.3. Reliability 469 It should be noted that the syslog transport specified in this 470 document does not use application-layer acknowledgments. TCP uses 471 retransmissions to provide protection against some forms of data 472 loss. However, if the TCP connection (or TLS session) is broken for 473 some reason (or closed by the transport receiver), the syslog 474 transport sender cannot always know what messages were successfully 475 delivered to the syslog application at the other end. 477 7. IANA Considerations 479 7.1. Port Number 481 IANA is requested to assign a TCP port number in the range 1..1023 in 482 the http://www.iana.org/assignments/port-numbers registry which will 483 be the default port for syslog over TLS, as defined in this document. 485 8. Acknowledgments 487 Authors appreciate Eric Rescorla, Rainer Gerhards, Tom Petch, Anton 488 Okmianski, Balazs Scheidler, Bert Wijnen, Martin Scheutte, Chris 489 Lonvick and members of the syslog working group for their effort on 490 issues resolving discussion. Authors would also like to appreciate 491 Balazs Scheidler, Tom Petch and other persons for their input on 492 security threats of syslog. The authors would like to acknowledge 493 David Harrington for his detailed reviews of the content and grammar 494 of the document and Pasi Eronen for his contributions to certificate 495 authentication and authorization sections. 497 9. References 499 9.1. Normative References 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, March 1997. 504 [I-D.ietf-syslog-protocol] 505 Gerhards, R., "The syslog Protocol", 506 draft-ietf-syslog-protocol-23 (work in progress), 507 September 2007. 509 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 510 Housley, R., and W. Polk, "Internet X.509 Public Key 511 Infrastructure Certificate and Certificate Revocation List 512 (CRL) Profile", RFC 5280, May 2008. 514 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 515 Specifications: ABNF", STD 68, RFC 5234, January 2008. 517 [I-D.ietf-tls-rfc4346-bis] 518 Dierks, T. and E. Rescorla, "The Transport Layer Security 519 (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10 520 (work in progress), March 2008. 522 9.2. Informative References 524 [I-D.ietf-syslog-sign] 525 Kelsey, J., "Signed syslog Messages", 526 draft-ietf-syslog-sign-23 (work in progress), 527 October 2007. 529 Appendix A. Changes from -12 531 Please remove in published RFC. 533 Section 3: Expanded note to include reference to Syslog Sign. 535 Section 4.2: Included mandatory to implement ciphersuites that 536 track future versions of the TLS 538 Section 4.2.1: Revised to certificate based authentication 539 mechanisms. authorization policy is covered in section 5. 541 Section 4.2.2: added to describe fingerprint format 543 Section 5: new security policies section 545 Security Considerations: added reference to TLS security 546 considerations, removed cipher suite section which was redundant 547 with TLS 549 Added redundancy and name validation to security considerations 550 section 552 Authors' Addresses 554 Fuyou Miao (editor) 555 Huawei Technologies 556 No. 3, Xinxi Rd 557 Shangdi Information Industry Base 558 Haidian District, Beijing 100085 559 P. R. China 561 Phone: +86 10 8288 2008 562 Email: miaofy@huawei.com 563 URI: www.huawei.com 565 Yuzhi Ma (editor) 566 Huawei Technologies 567 No. 3, Xinxi Rd 568 Shangdi Information Industry Base 569 Haidian District, Beijing 100085 570 P. R. China 572 Phone: +86 10 8288 2008 573 Email: myz@huawei.com 574 URI: www.huawei.com 576 Joseph Salowey (editor) 577 Cisco Systems, Inc. 578 2901 3rd. Ave 579 Seattle, WA 98121 580 USA 582 Email: jsalowey@cisco.com 584 Full Copyright Statement 586 Copyright (C) The IETF Trust (2008). 588 This document is subject to the rights, licenses and restrictions 589 contained in BCP 78, and except as set forth therein, the authors 590 retain all their rights. 592 This document and the information contained herein are provided on an 593 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 594 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 595 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 596 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 597 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 598 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 600 Intellectual Property 602 The IETF takes no position regarding the validity or scope of any 603 Intellectual Property Rights or other rights that might be claimed to 604 pertain to the implementation or use of the technology described in 605 this document or the extent to which any license under such rights 606 might or might not be available; nor does it represent that it has 607 made any independent effort to identify any such rights. Information 608 on the procedures with respect to rights in RFC documents can be 609 found in BCP 78 and BCP 79. 611 Copies of IPR disclosures made to the IETF Secretariat and any 612 assurances of licenses to be made available, or the result of an 613 attempt made to obtain a general license or permission for the use of 614 such proprietary rights by implementers or users of this 615 specification can be obtained from the IETF on-line IPR repository at 616 http://www.ietf.org/ipr. 618 The IETF invites any interested party to bring to its attention any 619 copyrights, patents or patent applications, or other proprietary 620 rights that may cover technology that may be required to implement 621 this standard. Please address the information to the IETF at 622 ietf-ipr@ietf.org. 624 Acknowledgment 626 Funding for the RFC Editor function is provided by the IETF 627 Administrative Support Activity (IASA).