[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 4744

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


   Using the NETCONF Protocol over Blocks Extensible Exchange Protocol
                                  (BEEP)
                        draft-ietf-netconf-beep-04

Status of this Memo

    This document is an Internet-Draft and is subject to all provisions
    of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
    RFC 3668.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as
    Internet-Drafts.

    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
    http://www.ietf.org/ietf/1id-abstracts.txt.

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

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

Copyright Notice

    Copyright (C) The Internet Society (2005).

Abstract

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







Lear & Crozier         Expires September 17, 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 17, 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) [6] .

    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 [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 intermittantly 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 17, 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 [6].

    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 SHOULD NOT be used
    unencrypted channels to avoid risk of eavesdropping.

    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
    conversation.

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 17, 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="http://iana.org/beep/netconf" />
          M: </start>
          M: END
          A: RPY 0 1 . 38 87
          A: Content-Type: application/beep+xml
          A:
          A: <profile uri="http://iana.org/beep/netconf" />
          A: END

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

    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:
        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:/example.net/router/2.3/core#myfeature
        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 17, 2005               [Page 5]


Internet-Draft             NETCONF over BEEP                  March 2005


    well.

    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 [7].  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
    mapping.

2.5  BEEP Profile for NETCONF

    Profile Identification: http://iana.org/beep/netconf

    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 17, 2005               [Page 6]


Internet-Draft             NETCONF over BEEP                  March 2005


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

















































Lear & Crozier         Expires September 17, 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.

    BEEP makes use of both transport layer security and SASL.  We require
    that TLS be used in BEEP as described by the BEEP standard.
    Client-side certificates are strongly desirable, but an SASL
    authentication is the bare minimum.  SASL allows for the use of
    protocols such as RADIUS [10], so that authentication can occur off
    the box.

    In keeping with the BEEP standard, SASL authentication will occur on
    the first channel creation, and prior to issuance of any protocol
    operations.  No further authentication may occur during the same
    session.  This avoids a situation where rights are different between
    different channels.  If an implementation wishes to support multiple
    accesses by different individuals with different rights, then
    multiple sessions are required.

    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 17, 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 17, 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, and Eamon O'Tuathail for their very constructive
    participation.









































Lear & Crozier         Expires September 17, 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]  Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
         3080, March 2001.

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

6.2  Informative References

    [8]   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.

    [9]   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.

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












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


Internet-Draft             NETCONF over BEEP                  March 2005


Authors' Addresses

    Eliot Lear
    Cisco Systems
    Glatt-com
    Glattzentrum, Zurich  8301
    CH

    EMail: lear@cisco.com


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

    EMail: kcrozier@cisco.com

































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


Internet-Draft             NETCONF over BEEP                  March 2005


Appendix A.  Change Log

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

    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 17, 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
    http://www.ietf.org/ipr.

    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
    ietf-ipr@ietf.org.


Disclaimer of Validity

    This document and the information contained herein are provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


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.


Acknowledgment

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




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


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/