Internet Engineering Task Force                                M. Badra 
INTERNET DRAFT                                         LIMOS Laboratory 
 
November 9, 2006                                    Expires: April 2007 
    
                              NETCONF over TLS 
                      <draft-badra-tls-netconf-01.txt> 
    
    
Status 
    
   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 
   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 April 09, 2007. 
    
Copyright Notice 
    
   Copyright (C) The Internet Society (2006).  
    
Abstract 
    
   The NETCONF configuration protocol provides mechanisms to install, 
   manipulate, and delete the configuration of network devices. This 
   document describes how to use TLS to secure NETCONF exchanges. 
    
1 Introduction 
    
   The NETCONF protocol [NETCONF] defines a simple mechanism through 
   which a network device can be managed.  NETCONF is connection-
   oriented, requiring a persistent connection between peers.  This 

 
 
Badra               Informational - Expires April 2007         [Page 1] 
 
INTERNET-DRAFT             NETCONF over TLS               November 2006 
 
 
   connection must provide reliable, sequenced data delivery, integrity 
   and confidentiality and peers authentication. This document 
   describes how to use TLS [TLS] to secure NETCONF connections. 
    
1.2 Requirements language and Terminologies 
    
   The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document 
   are to be interpreted as described in RFC-2119. 
    
1.3 Terminology 
    
   This document uses the following terms: 
    
   manager 
   It refers to the end initiating the NETCONF connection. It issues 
   the NETCONF RPC commands. 
    
   agent 
   It refers to the end replying to the manager's commands during the 
   NETCONF connection. 
    
2. NETCONF over TLS 
    
   Since TLS is application protocol-independent, NETCONF can operate 
   on top of the TLS protocol transparently. Therefore, use NETCONF 
   over TLS precisely as we would use NETCONF over the transport layer. 
    
2.1. Connection Initiation 
    
   The agent acting as the NETCONF client SHOULD also act as the TLS 
   client. It SHOULD initiate a connection to the server on the 
   appropriate port and then send the TLS ClientHello to begin the TLS 
   handshake. Once the TLS handshake has been finished, the client or 
   the server MAY then send their NETCONF messages. All these messages 
   are encapsulated into TLS records of type "application data". These 
   records are protected using the TLS material keys. 
    
2.2. Connection Closure 
    
   The NETCONF agent MAY stop the NETCONF connection at any time and 
   therefore notify the receiver that no more data on this channel will 
   be sent and that any data received after a closure request will be 
   ignored. TLS has the ability for secure connection closure using the 
   Alert protocol. When the agent processes a closure request of the 
   NETCONF, the agent SHALL respond, terminate the TLS session, and 
   close the transport connection. The agent MUST NOT process any RPC 
   commands received on the current session after receiving the closure 
   request and the manager MUNT NOT send any RPC command after sending 


 
 
Badra               Informational - Expires April 2007         [Page 2] 
INTERNET-DRAFT             NETCONF over TLS               November 2006 
 
 
   the closure request. The agent MUST respond with a confirmation of 
   the closure and close down the channel immediately. 
    
3. Security Considerations 
    
   The security considerations described throughout [TLS] apply here as 
   well. 
    
4. IANA Considerations 
    
   This section provides guidance to the IANA to assign a TCP port 
   number which will be the default port for NETCONF over TLS. 
    
References 
    
   [TLS]      Dierks, T., et al., "The TLS Protocol Version 1.0", RFC 
              2246, January 1999. 
    
   [NETCONF]  Enns, R., "NETCONF Configuration Protocol", 
              draft-ietf-netconf-prot-09 (work in progress), October 
              2005. 
    
Author's Addresses 
    
   Mohamad Badra 
   LIMOS Laboratory - UMR (6158), CNRS 
   France                    Email: badra@isima.fr 
    
   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 IETF's procedures with respect to rights in IETF 
   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 

 
 
Badra               Informational - Expires April 2007         [Page 3] 
INTERNET-DRAFT             NETCONF over TLS               November 2006 
 
 
   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 (2006). 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. 



























 
 
Badra               Informational - Expires April 2007         [Page 4]