Network Working Group                                            E. Lear
Internet-Draft                                                K. Crozier
Expires: September 2, 2005                                 Cisco Systems
                                                               March 2005

   Using the NETCONF Protocol over Blocks Extensible Exchange Protocol

Status of this Memo

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.

    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-

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at

    The list of Internet-Draft Shadow Directories can be accessed at

    This Internet-Draft will expire on September 2, 2005.

Copyright Notice

    Copyright (C) The Internet Society (2005).


    This document specifies an application protocol mapping for the
    NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP).

Lear & Crozier          Expires September 2, 2005               [Page 1]

Internet-Draft              NETCONF over BEEP                 March 2005

Table of Contents

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
      1.1   Why BEEP?  . . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  BEEP Transport Mapping . . . . . . . . . . . . . . . . . . . .  4
      2.1   NETCONF Session Establishment  . . . . . . . . . . . . . .  4
      2.2   Starting a Channel for NETCONF . . . . . . . . . . . . . .  4
      2.3   NETCONF Session Usage  . . . . . . . . . . . . . . . . . .  6
      2.4   NETCONF Session Teardown . . . . . . . . . . . . . . . . .  6
      2.5   BEEP Profile for NETCONF . . . . . . . . . . . . . . . . .  6
    3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
    4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
    5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
    6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
      6.1   Normative References . . . . . . . . . . . . . . . . . . . 11
      6.2   Informative References . . . . . . . . . . . . . . . . . . 11
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
    A.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13
        Intellectual Property and Copyright Statements . . . . . . . . 14

Lear & Crozier          Expires September 2, 2005               [Page 2]

Internet-Draft              NETCONF over BEEP                 March 2005

1.  Introduction

    The NETCONF protocol [1] defines a simple mechanism through which a
    network device can be managed.  NETCONF is designed to be usable over
    a variety of application protocols.  This document specifies an
    application protocol mapping for NETCONF over the Blocks Extensible
    Exchange Protocol (BEEP) [7] .

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    document are to be interpreted as described in RFC 2119 [2].

1.1  Why BEEP?

    Use of BEEP is natural as an application protocol for transport of
    XML.  As a peer to peer protocol, BEEP provides an easy way to
    implement NETCONF, no matter which side of the connection was the
    initiator.  This "bidirectionality" allows for either manager or
    agent to initiate a connection.  This is particularly important to
    support large number of intermittently connected devices, as well as
    those devices that must reverse the management connection in the face
    of firewalls and NATs.

    The SASL profile used by BEEP allows for a simple and direct mapping
    to the existing security model for CLI, while TLS provides a strong
    well tested encryption mechanism with either server or server and
    client-side authentication.

Lear & Crozier          Expires September 2, 2005               [Page 3]

Internet-Draft              NETCONF over BEEP                 March 2005

2.  BEEP Transport Mapping

    All NETCONF over BEEP implementations MUST implement the profile and
    functional mapping between NETCONF and BEEP as described below.

2.1  NETCONF Session Establishment

    Managers may be either BEEP listeners or initiators.  Similarly,
    agents may be either listeners or initiators.  Thus the initial
    exchange takes place without regard to whether a manager or the agent
    is the initiator.  After the transport connection is established, as
    greetings are exchanged, they SHOULD each announce their support for
    TLS [4] and optionally SASL [3].  Once greetings are exchanged, if
    TLS is to be used and available by both parties, the listener STARTs
    a channel with the TLS profile.

    Once TLS has been started, a new greeting is sent by both initiator
    and listener, as required by the BEEP RFC.

    At this point, if SASL is desired, the initiator starts a BEEP
    channel to perform a SASL exchange to authenticate itself.  Upon
    completion of authentication the channel is closed.  That is, the
    channel is exclusively used to authenticate.

    Examples of both TLS and SASL profiles can be found in [7].

    It is anticipated that the SASL PLAIN mechanism will be heavily used
    in conjunction with TLS.[5]  In such cases, in accordance with RFC
    2595 the PLAIN mechanism MUST NOT be advertised in the first BEEP
    <greeting>, but only in the one following a successful TLS
    negotiation.  This applies only if TLS and SASL PLAIN mechanisms are
    both to be used.  The SASL PLAIN mechanism MUST NOT be used
    unencrypted channels to avoid risk of eavesdropping.  More specifics
    about the use of SASL and TLS are mentioned in Security
    Considerations below.

    Once authentication has occurred, there is no need to distinguish
    between initiator and listener.  We now distinguish between manager
    and agent, and it is assumed that each knows its role in the

2.2  Starting a Channel for NETCONF

    The manager now establishes new channel and specifies the single
    NETCONF profile.  For example:

Lear & Crozier          Expires September 2, 2005               [Page 4]

Internet-Draft              NETCONF over BEEP                 March 2005

          (M = Manager ; A = Agent )

          M: MSG 0 1 . 10 48 101
          M: Content-type: application/beep+xml
          M: <start number="1">
          M:   <profile uri="" />
          M: </start>
          M: END
          A: RPY 0 1 . 38 87
          A: Content-Type: application/beep+xml
          A: <profile uri="" />
          A: END

    At this point we are ready to proceed on BEEP channel 1 with NETCONF

    Next the manager and the agent exchange NETCONF <hello> elements on
    the new channel so that each side learns the other's capabilities.
    This occurs through a MSG.  Each side will then respond with
    positively.  The following example is adapted from [1] Section 8.1:

        A: MSG 1 0 . 0 436
        A: Content-type: application/beep+xml
        A: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        A:   <capabilities>
        A:     <capability>
        A:       urn:ietf:params:xml:ns:netconf:base:1.0
        A:     </capability>
        A:     <capability>
        A:       urn:ietf:params:xml:ns:netconf:base:1.0#startup
        A:     </capability>
        A:     <capability>
        A:       http:/
        A:     </capability>
        A:   </capabilities>
        A:   <session-id>4</session-id>
        A: </hello>
        A: END

        M: RPY 1 0 . 0 0
        M: END

    Certain NETCONF capabilities may require additional BEEP channels.
    When such capabilities are defined, a BEEP mapping must be defined as

Lear & Crozier          Expires September 2, 2005               [Page 5]

Internet-Draft              NETCONF over BEEP                 March 2005


    At this point, the NETCONF session is established, and capabilities
    have been exchanged.

2.3  NETCONF Session Usage

    Nearly all NETCONF operations are executed through the <rpc> tag.  To
    issue an RPC, the manager transmits on the operational channel a BEEP
    MSG containing the RPC and its arguments.  In accordance with the
    BEEP standard, RPC requests may be split across multiple BEEP frames.

    Once received and processed, the agent responds with BEEP RPYs on the
    same channel with the response to the RPC.  In accordance with the
    BEEP standard, responses may be split across multiple BEEP frames.

2.4  NETCONF Session Teardown

    Upon receipt of <close-session> from the manager, once the agent has
    completed all RPCs, it will close BEEP channel 0.  When an agent
    needs to initiate a close it will do so by closing BEEP channel 0.
    Although not required to do so, the agent should allow for a
    reasonable period for a manager to release an existing lock prior to
    initiating a close.  Once the agent has closed channel 0, all locks
    are released, and each side follows tear down procedures as specified
    in [8].  Having received a BEEP close or having sent <close-session>,
    a manager MUST NOT send further requests.  If there are additional
    activities due to expanded capabilities, these MUST cease in an
    orderly manner, and should be properly described in the capability

2.5  BEEP Profile for NETCONF

    Profile Identification:

    messages exchanged during Channel Creation: not applicable

    Messages starting one-to-one exchanges: "hello", "rpc", "rpc-reply"

    Messages in positive replies: "rpc-reply"

    Messages in negative replies: "rpc-reply"

    Messages in one-to-many exchanges: none

    Message syntax: [1]

    message semantics: [1]

Lear & Crozier          Expires September 2, 2005               [Page 6]

Internet-Draft              NETCONF over BEEP                 March 2005

    Contact Information: c.f., the "Author's Address" section of this

Lear & Crozier          Expires September 2, 2005               [Page 7]

Internet-Draft              NETCONF over BEEP                 March 2005

3.  Security Considerations

    Configuration information is by its very nature sensitive.  Its
    transmission in the clear and without integrity checking leaves
    devices open to classic so-called "person in the middle" attacks.
    Configuration information often times contains passwords, user names,
    service descriptions, and topological information, all of which are
    sensitive.  A NETCONF application protocol, therefore, must minimally
    support options for both confidentiality and authentication.

    The BEEP mapping described in this documents addresses both
    confidentiality and authentication in a flexible manner through the
    use of TLS and SASL profiles.  Confidentiality is provided via the
    TLS profile, and is used as discussed above.  In addition, the server
    certificate shall serve as the server's authentication to the client.
    The client MUST be prepared to recognize a valid server certificate.
    While distribution of such certificates is beyond the scope of this
    document, the implementor is cautioned to be aware of any
    interdependencies that may be placed on the network infrastructure
    through the use of protocols that validate trust anchors.

    For client-side authentication there are several options.  The client
    MAY provide a certificate during the initiation phase of TLS, in
    which case the subject of that certificate shall be considered
    principle for authentication purposes.  Once again, server
    implementors should be aware of any interdependencies that could be
    created through protocols used to validate trust anchors.

    In the case where the client has not authenticated through TLS, the
    server SHOULD advertise one or more SASL profile, from which the
    client will choose.  In the singular case where TLS is established
    the minimum profile MAY be PLAIN.  Otherwise, implementations MUST
    support the DIGEST-MD5 profile as described in [6], and they MAY
    support other profiles such as OTP.[12]

    Different environments may well allow different rights prior to and
    then after authentication.  An authorization model is not specified
    in this document.  When an operation is not properly authorized then
    a simple rpc-error containing "permission denied" is sufficient.
    Note that authorization information may be exchanged in the form of
    configuration information, which is all the more reason to ensure the
    security of the connection.

Lear & Crozier          Expires September 2, 2005               [Page 8]

Internet-Draft              NETCONF over BEEP                 March 2005

4.  IANA Considerations

    The IANA will assign a TCP port for NETCONF, and register the BEEP
    profile contained here-in.

Lear & Crozier          Expires September 2, 2005               [Page 9]

Internet-Draft              NETCONF over BEEP                 March 2005

5.  Acknowledgments

    This work is the product of the NETCONF IETF working group, and many
    people have contributed to the NETCONF discussion.  Most notably, Rob
    Ens, Phil Schafer, Andy Bierman, Wes Hardiger, Ted Goddard, and
    Margaret Wasserman all contributed in some fashion to this work,
    which was originally to be found in the NETCONF base protocol
    specification.  Thanks also to Weijing Chen, Keith Allen, Juergen
    Schoenwaelder, Marshall Rose, and Eamon O'Tuathail for their very
    constructive participation.

Lear & Crozier          Expires September 2, 2005              [Page 10]

Internet-Draft              NETCONF over BEEP                 March 2005

6.  References

6.1  Normative References

    [1]  Enns, R., "NETCONF Configuration Protocol",
         draft-ietf-netconf-prot-04 (work in progress), October 2004.

    [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

    [3]  Myers, J., "Simple Authentication and Security Layer (SASL)",
         RFC 2222, October 1997.

    [4]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and
         P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
         January 1999.

    [5]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
         June 1999.

    [6]  Leach, P. and C. Newman, "Using Digest Authentication as a SASL
         Mechanism", RFC 2831, May 2000.

    [7]  Rose, M., "The Blocks Extensible Exchange Protocol Core",
         RFC 3080, March 2001.

    [8]  Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081,
         March 2001.

6.2  Informative References

    [9]   Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
          "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
          REC REC-xml-20001006, October 2000.

    [10]  Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the
          Use of Extensible Markup Language (XML) within IETF Protocols",
          BCP 70, RFC 3470, January 2003.

    [11]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
          Authentication Dial In User Service (RADIUS)", RFC 2865,
          June 2000.

    [12]  Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
          October 1998.

Lear & Crozier          Expires September 2, 2005              [Page 11]

Internet-Draft              NETCONF over BEEP                 March 2005

Authors' Addresses

    Eliot Lear
    Cisco Systems
    Glattzentrum, Zurich  8301


    Ken Crozier
    Cisco Systems
    170 W. Tasman Dr.
    San Jose, CA  95134-1706


Lear & Crozier          Expires September 2, 2005              [Page 12]

Internet-Draft              NETCONF over BEEP                 March 2005

Appendix A.  Change Log

    05: improved advice on use of tls and SASL profiles.

    04: complete revamp of the profile.  Added <hello> as well as

    03: minor gnits relating to <close-session>

    02: added comments about locking

    01: Removed management channel, rpc-status, rpc-abort, and associated
    profile changes.

Lear & Crozier          Expires September 2, 2005              [Page 13]

Internet-Draft              NETCONF over BEEP                 March 2005

Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.  Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository at

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at

Disclaimer of Validity

    This document and the information contained herein are provided on an

Copyright Statement

    Copyright (C) The Internet Society (2005).  This document is subject
    to the rights, licenses and restrictions contained in BCP 78, and
    except as set forth therein, the authors retain all their rights.


    Funding for the RFC Editor function is currently provided by the
    Internet Society.

Lear & Crozier          Expires September 2, 2005              [Page 14]