doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc5425.txt b/doc/rfc/rfc5425.txt
new file mode 100644
index 0000000..e799e36
--- /dev/null
+++ b/doc/rfc/rfc5425.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                       F. Miao, Ed.
+Request for Comments: 5425                                    Y. Ma, Ed.
+Category: Standards Track                            Huawei Technologies
+                                                         J. Salowey, Ed.
+                                                     Cisco Systems, Inc.
+                                                              March 2009
+
+
+      Transport Layer Security (TLS) Transport Mapping for Syslog
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Abstract
+
+   This document describes the use of Transport Layer Security (TLS) to
+   provide a secure connection for the transport of syslog messages.
+   This document describes the security threats to syslog and how TLS
+   can be used to counter such threats.
+
+
+
+
+Miao, et al.                Standards Track                     [Page 1]
+
+RFC 5425            TLS Transport Mapping for Syslog          March 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................3
+   2. Security Requirements for Syslog ................................3
+   3. Using TLS to Secure Syslog ......................................4
+   4. Protocol Elements ...............................................5
+      4.1. Port Assignment ............................................5
+      4.2. Initiation .................................................5
+           4.2.1. Certificate-Based Authentication ....................5
+           4.2.2. Certificate Fingerprints ............................6
+           4.2.3. Cryptographic Level .................................7
+      4.3. Sending Data ...............................................7
+           4.3.1. Message Length ......................................7
+      4.4. Closure ....................................................8
+   5. Security Policies ...............................................8
+      5.1. End-Entity Certificate Based Authorization .................8
+      5.2. Subject Name Authorization .................................9
+      5.3. Unauthenticated Transport Sender ...........................9
+      5.4. Unauthenticated Transport Receiver ........................10
+      5.5. Unauthenticated Transport Receiver and Sender .............10
+   6. Security Considerations ........................................10
+      6.1. Authentication and Authorization Policies .................10
+      6.2. Name Validation ...........................................11
+      6.3. Reliability ...............................................11
+   7. IANA Considerations ............................................11
+      7.1. Port Number ...............................................11
+   8. Acknowledgments ................................................11
+   9. References .....................................................12
+      9.1. Normative References ......................................12
+      9.2. Informative References ....................................12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Miao, et al.                Standards Track                     [Page 2]
+
+RFC 5425            TLS Transport Mapping for Syslog          March 2009
+
+
+1.  Introduction
+
+   This document describes the use of Transport Layer Security (TLS
+   [RFC5246]) to provide a secure connection for the transport of syslog
+   [RFC5424] messages.  This document describes the security threats to
+   syslog and how TLS can be used to counter such threats.
+
+1.1.  Terminology
+
+   The following definitions are used in this document:
+
+   o  An "originator" generates syslog content to be carried in a
+      message.
+
+   o  A "collector" gathers syslog content for further analysis.
+
+   o  A "relay" forwards messages, accepting messages from originators
+      or other relays, and sending them to collectors or other relays.
+
+   o  A "transport sender" passes syslog messages to a specific
+      transport protocol.
+
+   o  A "transport receiver" takes syslog messages from a specific
+      transport protocol.
+
+   o  A "TLS client" is an application that can initiate a TLS
+      connection by sending a Client Hello to a server.
+
+   o  A "TLS server" is an application that can receive a Client Hello
+      from a client and reply with a Server Hello.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2.  Security Requirements for Syslog
+
+   Syslog messages may transit several hops to arrive at the intended
+   collector.  Some intermediary networks may not be trusted by the
+   originator, relay, or receiver because the network is in a different
+   security domain or at a different security level from the originator,
+   relay, or collector.  Another security concern is that the
+   originator, relay, or receiver itself is in an insecure network.
+
+   There are several threats to be addressed for syslog security.  The
+   primary threats are:
+
+
+
+
+
+Miao, et al.                Standards Track                     [Page 3]
+
+RFC 5425            TLS Transport Mapping for Syslog          March 2009
+
+
+   o  Masquerade.  An unauthorized transport sender may send messages to
+      a legitimate transport receiver, or an unauthorized transport
+      receiver may try to deceive a legitimate transport sender into
+      sending syslog messages to it.
+
+   o  Modification.  An attacker between the transport sender and the
+      transport receiver may modify an in-transit syslog message and
+      then forward the message to the transport receiver.  Such
+      modification may make the transport receiver misunderstand the
+      message or cause it to behave in undesirable ways.
+
+   o  Disclosure.  An unauthorized entity may examine the contents of
+      the syslog messages, gaining unauthorized access to the
+      information.  Some data in syslog messages is sensitive and may be
+      useful to an attacker, such as the password of an authorized
+      administrator or user.
+
+   The secondary threat is:
+
+   o  Message stream modification.  An attacker may delete one or more
+      syslog messages from a series of messages, replay a message, or
+      alter the delivery sequence.  The syslog protocol itself is not
+      based on message order.  However, an event in a syslog message may
+      relate semantically to events in other messages, so message
+      ordering may be important to understanding a sequence of events.
+
+   The following threats are deemed to be of lesser importance for
+   syslog, and are not addressed in this document:
+
+   o  Denial of Service
+
+   o  Traffic Analysis
+
+3.  Using TLS to Secure Syslog
+
+   TLS can be used as a secure transport to counter all the primary
+   threats to syslog described above:
+
+   o  Confidentiality to counter disclosure of the message contents.
+
+   o  Integrity-checking to counter modifications to a message on a hop-
+      by-hop basis.
+
+   o  Server or mutual authentication to counter masquerade.
+
+   Note: This secure transport (i.e., TLS) only secures syslog transport
+   in a hop-by-hop manner, and is not concerned with the contents of
+   syslog messages.  In particular, the authenticated identity of the
+
+
+
+Miao, et al.                Standards Track                     [Page 4]
+
+RFC 5425            TLS Transport Mapping for Syslog          March 2009
+
+
+   transport sender (e.g., subject name in the certificate) is not
+   necessarily related to the HOSTNAME field of the syslog message.
+   When authentication of syslog message origin is required, [SYS-SIGN]
+   can be used.
+
+4.  Protocol Elements
+
+4.1.  Port Assignment
+
+   A syslog transport sender is always a TLS client and a transport
+   receiver is always a TLS server.
+
+   The TCP port 6514 has been allocated as the default port for syslog
+   over TLS, as defined in this document.
+
+4.2.  Initiation
+
+   The transport sender should initiate a connection to the transport
+   receiver and then send the TLS Client Hello to begin the TLS
+   handshake.  When the TLS handshake has finished, the transport sender
+   MAY then send the first syslog message.
+
+   TLS typically uses certificates [RFC5280] to authenticate peers.
+   Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to
+   support the mandatory to implement cipher suite, which is
+   TLS_RSA_WITH_AES_128_CBC_SHA.  This document is assumed to apply to
+   future versions of TLS, in which case the mandatory to implement
+   cipher suite for the implemented version MUST be supported.
+
+4.2.1.  Certificate-Based Authentication
+
+   Both syslog transport sender (TLS client) and syslog transport
+   receiver (TLS server) MUST implement certificate-based
+   authentication.  This consists of validating the certificate and
+   verifying that the peer has the corresponding private key.  The
+   latter part is performed by TLS.  To ensure interoperability between
+   clients and servers, the following methods for certificate validation
+   SHALL be implemented:
+
+   o  Certification path validation: The TLS peer is configured with one
+      or more trust anchors (typically root CA (certification authority)
+      certificates), which allow it to verify a binding between the
+      subject name and the public key.  Additional policy controls
+      needed for authorizing the syslog transport sender and receiver
+      (i.e., verifying that the subject name represents an authorized
+      party) are described in Section 5.  Certification path validation
+      is performed as defined in [RFC5280].  This method is useful where
+      there is a Public Key Infrastructure (PKI) deployment.
+
+
+
+Miao, et al.                Standards Track                     [Page 5]
+
+RFC 5425            TLS Transport Mapping for Syslog          March 2009
+
+
+   o  End-entity certificate matching: The transport sender or receiver
+      is configured with information necessary to identify the valid
+      end-entity certificates of its authorized peers.  The end-entity
+      certificates can be self-signed, and no certification path
+      validation is needed.  Implementations MUST support certificate
+      fingerprints in Section 4.2.2 and MAY allow other formats for
+      end-entity certificates such as a DER-encoded certificate.  This
+      method provides an alternative to a PKI that is simple to deploy
+      and still maintains a reasonable level of security.
+
+   Both transport receiver and transport sender implementations MUST
+   provide means to generate a key pair and self-signed certificate in
+   the case that a key pair and certificate are not available through
+   another mechanism.
+
+   The transport receiver and transport sender SHOULD provide mechanisms
+   to record the end-entity certificate for the purpose of correlating
+   it with the sent or received data.
+
+4.2.2.  Certificate Fingerprints
+
+   Both client and server implementations MUST make the certificate
+   fingerprints for their certificate available through a management
+   interface.  The labels for the algorithms are taken from the textual
+   names of the hash functions as defined in the IANA registry "Hash
+   Function Textual Names" allocated in [RFC4572].
+
+   The mechanism to generate a fingerprint is to take the hash of the
+   DER-encoded certificate using a cryptographically strong algorithm,
+   and convert the result into colon-separated, hexadecimal bytes, each
+   represented by 2 uppercase ASCII characters.  When a fingerprint
+   value is displayed or configured, the fingerprint is prepended with
+   an ASCII label identifying the hash function followed by a colon.
+   Implementations MUST support SHA-1 as the hash algorithm and use the
+   ASCII label "sha-1" to identify the SHA-1 algorithm.  The length of a
+   SHA-1 hash is 20 bytes and the length of the corresponding
+   fingerprint string is 65 characters.  An example certificate
+   fingerprint is:
+
+      sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D
+
+   During validation the hash is extracted from the fingerprint and
+   compared against the hash calculated over the received certificate.
+
+
+
+
+
+
+
+
+Miao, et al.                Standards Track                     [Page 6]
+
+RFC 5425            TLS Transport Mapping for Syslog          March 2009
+
+
+4.2.3.  Cryptographic Level
+
+   Syslog applications SHOULD be implemented in a manner that permits
+   administrators, as a matter of local policy, to select the
+   cryptographic level and authentication options they desire.
+
+   TLS permits the resumption of an earlier TLS session or the use of
+   another active session when a new session is requested, in order to
+   save the expense of another full TLS handshake.  The security
+   parameters of the resumed session are reused for the requested
+   session.  The security parameters SHOULD be checked against the
+   security requirements of the requested session to make sure that the
+   resumed session provides proper security.
+
+4.3.  Sending Data
+
+   All syslog messages MUST be sent as TLS "application data".  It is
+   possible for multiple syslog messages to be contained in one TLS
+   record or for a single syslog message to be transferred in multiple
+   TLS records.  The application data is defined with the following ABNF
+   [RFC5234] expression:
+
+   APPLICATION-DATA = 1*SYSLOG-FRAME
+
+   SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG
+
+   MSG-LEN = NONZERO-DIGIT *DIGIT
+
+   SP = %d32
+
+   NONZERO-DIGIT = %d49-57
+
+   DIGIT = %d48 / NONZERO-DIGIT
+
+   SYSLOG-MSG is defined in the syslog protocol [RFC5424].
+
+4.3.1.  Message Length
+
+   The message length is the octet count of the SYSLOG-MSG in the
+   SYSLOG-FRAME.  A transport receiver MUST use the message length to
+   delimit a syslog message.  There is no upper limit for a message
+   length per se.  However, in order to establish a baseline for
+   interoperability, this specification requires that a transport
+   receiver MUST be able to process messages with a length up to and
+   including 2048 octets.  Transport receivers SHOULD be able to process
+   messages with lengths up to and including 8192 octets.
+
+
+
+
+
+Miao, et al.                Standards Track                     [Page 7]
+
+RFC 5425            TLS Transport Mapping for Syslog          March 2009
+
+
+4.4.  Closure
+
+   A transport sender MUST close the associated TLS connection if the
+   connection is not expected to deliver any syslog messages later.  It
+   MUST send a TLS close_notify alert before closing the connection.  A
+   transport sender (TLS client) MAY choose to not wait for the
+   transport receiver's close_notify alert and simply close the
+   connection, thus generating an incomplete close on the transport
+   receiver (TLS server) side.  Once the transport receiver gets a
+   close_notify from the transport sender, it MUST reply with a
+   close_notify unless it becomes aware that the connection has already
+   been closed by the transport sender (e.g., the closure was indicated
+   by TCP).
+
+   When no data is received from a connection for a long time (where the
+   application decides what "long" means), a transport receiver MAY
+   close the connection.  The transport receiver (TLS server) MUST
+   attempt to initiate an exchange of close_notify alerts with the
+   transport sender before closing the connection.  Transport receivers
+   that are unprepared to receive any more data MAY close the connection
+   after sending the close_notify alert, thus generating an incomplete
+   close on the transport sender side.
+
+5.  Security Policies
+
+   Different environments have different security requirements and
+   therefore would deploy different security policies.  This section
+   discusses some of the security policies that may be implemented by
+   syslog transport receivers and syslog transport senders.  The
+   security policies describe the requirements for authentication and
+   authorization.  The list of policies in this section is not
+   exhaustive and other policies MAY be implemented.
+
+   If the peer does not meet the requirements of the security policy,
+   the TLS handshake MUST be aborted with an appropriate TLS alert.
+
+5.1.  End-Entity Certificate Based Authorization
+
+   In the simplest case, the transport sender and receiver are
+   configured with information necessary to identity the valid
+   end-entity certificates of its authorized peers.
+
+   Implementations MUST support specifying the authorized peers using
+   certificate fingerprints, as described in Section 4.2.1 and
+   Section 4.2.2.
+
+
+
+
+
+
+Miao, et al.                Standards Track                     [Page 8]
+
+RFC 5425            TLS Transport Mapping for Syslog          March 2009
+
+
+5.2.  Subject Name Authorization
+
+   Implementations MUST support certification path validation [RFC5280].
+   In addition, they MUST support specifying the authorized peers using
+   locally configured host names and matching the name against the
+   certificate as follows.
+
+   o  Implementations MUST support matching the locally configured host
+      name against a dNSName in the subjectAltName extension field and
+      SHOULD support checking the name against the common name portion
+      of the subject distinguished name.
+
+   o  The '*' (ASCII 42) wildcard character is allowed in the dNSName of
+      the subjectAltName extension (and in common name, if used to store
+      the host name), but only as the left-most (least significant) DNS
+      label in that value.  This wildcard matches any left-most DNS
+      label in the server name.  That is, the subject *.example.com
+      matches the server names a.example.com and b.example.com, but does
+      not match example.com or a.b.example.com.  Implementations MUST
+      support wildcards in certificates as specified above, but MAY
+      provide a configuration option to disable them.
+
+   o  Locally configured names MAY contain the wildcard character to
+      match a range of values.  The types of wildcards supported MAY be
+      more flexible than those allowed in subject names, making it
+      possible to support various policies for different environments.
+      For example, a policy could allow for a trust-root-based
+      authorization where all credentials issued by a particular CA
+      trust root are authorized.
+
+   o  If the locally configured name is an internationalized domain
+      name, conforming implementations MUST convert it to the ASCII
+      Compatible Encoding (ACE) format for performing comparisons, as
+      specified in Section 7 of [RFC5280].
+
+   o  Implementations MAY support matching a locally configured IP
+      address against an iPAddress stored in the subjectAltName
+      extension.  In this case, the locally configured IP address is
+      converted to an octet string as specified in [RFC5280], Section
+      4.2.1.6.  A match occurs if this octet string is equal to the
+      value of iPAddress in the subjectAltName extension.
+
+5.3.  Unauthenticated Transport Sender
+
+   In some environments the authenticity of syslog data is not important
+   or is verifiable by other means, so transport receivers may accept
+   data from any transport sender.  To achieve this, the transport
+   receiver can skip transport sender authentication (by not requesting
+
+
+
+Miao, et al.                Standards Track                     [Page 9]
+
+RFC 5425            TLS Transport Mapping for Syslog          March 2009
+
+
+   client authentication in TLS or by accepting any certificate).  In
+   this case, the transport receiver is authenticated and authorized,
+   however this policy does not protect against the threat of transport
+   sender masquerade described in Section 2.  The use of this policy is
+   generally NOT RECOMMENDED for this reason.
+
+5.4.  Unauthenticated Transport Receiver
+
+   In some environments the confidentiality of syslog data is not
+   important, so messages are sent to any transport receiver.  To
+   achieve this, the transport sender can skip transport receiver
+   authentication (by accepting any certificate).  While this policy
+   does authenticate and authorize the transport sender, it does not
+   protect against the threat of transport receiver masquerade described
+   in Section 2, leaving the data sent vulnerable to disclosure and
+   modification.  The use of this policy is generally NOT RECOMMENDED
+   for this reason.
+
+5.5.  Unauthenticated Transport Receiver and Sender
+
+   In environments where security is not a concern at all, both the
+   transport receiver and transport sender can skip authentication (as
+   described in Sections 5.3 and 5.4).  This policy does not protect
+   against any of the threats described in Section 2 and is therefore
+   NOT RECOMMENDED.
+
+6.  Security Considerations
+
+   This section describes security considerations in addition to those
+   in [RFC5246].
+
+6.1.  Authentication and Authorization Policies
+
+   Section 5 discusses various security policies that may be deployed.
+   The threats in Section 2 are mitigated only if both the transport
+   sender and transport receiver are properly authenticated and
+   authorized, as described in Sections 5.1 and 5.2.  These are the
+   RECOMMENDED configurations for a default policy.
+
+   If the transport receiver does not authenticate the transport sender,
+   it may accept data from an attacker.  Unless it has another way of
+   authenticating the source of the data, the data should not be
+   trusted.  This is especially important if the syslog data is going to
+   be used to detect and react to security incidents.  The transport
+   receiver may also increase its vulnerability to denial of service,
+   resource consumption, and other attacks if it does not authenticate
+   the transport sender.  Because of the increased vulnerability to
+   attack, this type of configuration is NOT RECOMMENDED.
+
+
+
+Miao, et al.                Standards Track                    [Page 10]
+
+RFC 5425            TLS Transport Mapping for Syslog          March 2009
+
+
+   If the transport sender does not authenticate the syslog transport
+   receiver, then it may send data to an attacker.  This may disclose
+   sensitive data within the log information that is useful to an
+   attacker, resulting in further compromises within the system.  If a
+   transport sender is operated in this mode, the data sent SHOULD be
+   limited to data that is not valuable to an attacker.  In practice
+   this is very difficult to achieve, so this type of configuration is
+   NOT RECOMMENDED.
+
+   Forgoing authentication and authorization on both sides allows for
+   man-in-the-middle, masquerade, and other types of attacks that can
+   completely compromise integrity and confidentiality of the data.
+   This type of configuration is NOT RECOMMENDED.
+
+6.2.  Name Validation
+
+   The subject name authorization policy authorizes the subject in the
+   certificate against a locally configured name.  It is generally not
+   appropriate to obtain this name through other means, such as DNS
+   lookup, since this introduces additional security vulnerabilities.
+
+6.3.  Reliability
+
+   It should be noted that the syslog transport specified in this
+   document does not use application-layer acknowledgments.  TCP uses
+   retransmissions to provide protection against some forms of data
+   loss.  However, if the TCP connection (or TLS session) is broken for
+   some reason (or closed by the transport receiver), the syslog
+   transport sender cannot always know what messages were successfully
+   delivered to the syslog application at the other end.
+
+7.  IANA Considerations
+
+7.1.  Port Number
+
+   IANA assigned TCP port number 6514 in the "Registered Port Numbers"
+   range with the keyword "syslog-tls".  This port will be the default
+   port for syslog over TLS, as defined in this document.
+
+8.  Acknowledgments
+
+   Authors appreciate Eric Rescorla, Rainer Gerhards, Tom Petch, Anton
+   Okmianski, Balazs Scheidler, Bert Wijnen, Martin Schuette, Chris
+   Lonvick, and members of the syslog working group for their effort on
+   issues resolving discussion.  Authors would also like to thank Balazs
+   Scheidler, Tom Petch, and other persons for their input on security
+   threats of syslog.  The authors would like to acknowledge David
+
+
+
+
+Miao, et al.                Standards Track                    [Page 11]
+
+RFC 5425            TLS Transport Mapping for Syslog          March 2009
+
+
+   Harrington for his detailed reviews of the content and grammar of the
+   document and Pasi Eronen for his contributions to certificate
+   authentication and authorization sections.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5234]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
+               Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [RFC5246]   Dierks, T. and E. Rescorla, "The Transport Layer Security
+               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC5280]   Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+               Housley, R., and W. Polk, "Internet X.509 Public Key
+               Infrastructure Certificate and Certificate Revocation
+               List (CRL) Profile", RFC 5280, May 2008.
+
+   [RFC5424]   Gerhards, R., "The Syslog Protocol", RFC 5424, March
+               2009.
+
+9.2.  Informative References
+
+   [RFC4572]   Lennox, J., "Connection-Oriented Media Transport over the
+               Transport Layer Security (TLS) Protocol in the Session
+               Description Protocol (SDP)", RFC 4572, July 2006.
+
+   [SYS-SIGN]  Kelsey, J., "Signed syslog Messages", Work in Progress,
+               October 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Miao, et al.                Standards Track                    [Page 12]
+
+RFC 5425            TLS Transport Mapping for Syslog          March 2009
+
+
+Authors' Addresses
+
+   Fuyou Miao (editor)
+   Huawei Technologies
+   No. 3, Xinxi Rd
+   Shangdi Information Industry Base
+   Haidian District, Beijing  100085
+   P. R. China
+
+   Phone: +86 10 8288 2008
+   EMail: miaofy@huawei.com
+   URI:   www.huawei.com
+
+   Yuzhi Ma (editor)
+   Huawei Technologies
+   No. 3, Xinxi Rd
+   Shangdi Information Industry Base
+   Haidian District, Beijing  100085
+   P. R. China
+
+   Phone: +86 10 8288 2008
+   EMail: myz@huawei.com
+   URI:   www.huawei.com
+
+
+   Joseph Salowey (editor)
+   Cisco Systems, Inc.
+   2901 3rd. Ave
+   Seattle, WA  98121
+   USA
+
+   EMail: jsalowey@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Miao, et al.                Standards Track                    [Page 13]
+