Status of this Memo

This Internet-Draft is submitted to IETF in full
conformance with the provisions of BCP 78 and 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.”

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

The Network Configuration Protocol (NETCONF) provides mechanisms to
install, manipulate, and delete the configuration of network
devices. This document describes how to use the Transport Layer
Security (TLS) protocol to secure NETCONF exchanges.

1.
Introduction

The NETCONF protocol [RFC4741] (Enns, R., “NETCONF Configuration Protocol,” December 2006.) defines a mechanism
through which a network device can be managed. NETCONF is
connection-oriented, requiring a persistent connection between
peers. This connection must provide reliable, sequenced data
delivery, integrity and confidentiality and peers authentication.

Throughout this document, the terms "client" and "server" are
used to refer to the two ends of the TLS connection. The client
actively opens the TLS connection, and the server passively
listens for the incoming TLS connection. The terms "manager" and
"agent" are used to refer to the two ends of the NETCONF protocol
session. The manager issues NETCONF remote procedure call (RPC)
commands, and the agent replies to those commands. When NETCONF
is run over TLS using the mapping defined in this document, the
client is always the manager, and the server is always the agent.

2.
NETCONF over TLS

2.1.
Connection Initiation

The peer acting as the NETCONF manager MUST also act as the TLS
client. It MUST connect to the server that passively listens for
the incoming TLS connection on the TCP port <IANA-to-be-assigned>.
(Note to RFC Editor: please replace <IANA-to-be-assigned> with the
IANA-assigned value, and remove this note).
It MUST therefore send the TLS ClientHello message to begin the TLS
handshake. Once the TLS handshake has finished, the client and
the server MAY begin to exchange NETCONF data. In particular,
the client will send complete XML documents to the server
containing <rpc> elements, and the server will respond with
complete XML documents containing <rpc-reply> elements. The
client MAY indicate interest in receiving event notifications
from a server by creating a subscription to receive event
notifications [RFC5277] (Chisholm, S. and H. Trevino, “NETCONF Event Notifications,” July 2008.), in which case the server
replies to indicate whether the subscription request was
successful and, if it was successful, begins sending the event
notifications to the client as the events occur within the
system.

All NETCONF messages MUST be sent as TLS "application data". It
is possible that multiple NETCONF messages be contained in one
TLS record, or that a NETCONF message be transferred in multiple
TLS records.

2.2.
Connection Closure

A TLS client (NETCONF manager) MUST close the associated TLS
connection if the connection is not expected to issue any NETCONF
RPC commands later. It MUST send a TLS close_notify alert before
closing the connection. The TLS client MAY choose to not wait
for the TLS server (NETCONF agent) close_notify alert and simply
close the connection, thus generating an incomplete close on the
TLS server side. Once the TLS server gets a close_notify from
the TLS client, it MUST reply with a close_notify unless it
becomes aware that the connection has already been closed by the
TLS client (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 NETCONF peer MAY
close the connection. The NETCONF peer MUST attempt to initiate
an exchange of close_notify alerts with the other NETCONF peer
before closing the connection. The close_notify's sender that is
unprepared to receive any more data MAY close the connection
after sending the close_notify alert, thus generating an
incomplete close on the close_notify's receiver side.

3.
Endpoint Authentication and Identification

3.1.
Server Identity

During the TLS negotiation, the client MUST carefully examine the
certificate presented by the server to determine if it meets
their expectations. Particularly, the client MUST check its
understanding of the server hostname against the server's
identity as presented in the server Certificate message, in order
to prevent man-in-the-middle attacks.

3.2.
Client Identity

The server may have no external knowledge on client's identity
and identity checks might not be possible (unless the client has
a certificate chain rooted in an appropriate CA). If a server has
knowledge on client's identity (typically from some source external to
NETCONF or TLS) it MUST check the identity as described above.

This document in its current version does not support third party
authentication due to the fact that TLS does not specify this way
of authentication and that NETCONF depends on the transport
protocol for the authentication service. If third party
authentication is needed, BEEP or SSH transport can be used.

An attacker might be able to inject arbitrary NETCONF messages
via some application that does not carefully check exchanged
messages or deliberately insert the delimiter sequence in a
NETCONF message to create a DoS attack. Hence, applications and
NETCONF APIs MUST ensure that the delimiter sequence defined in
Section 2.1 never appears in NETCONF messages; otherwise, those
messages can be dropped, garbled or mis-interpreted. If the
delimiter sequence is found in a NETCONF message by the
sender side, a robust implementation of this document should warn
the user that illegal characters have been discovered. If the
delimiter sequence is found in a NETCONF message by the receiver
side (including any XML attribute values, XML comments or
processing instructions) a robust implementation of this document
must silently discard the message without further processing and
then stop the NETCONF session.

The author would like to acknowledge David Harrington, Miao
Fuyou, Eric Rescorla, Juergen Schoenwaelder, Simon Josefsson,
Olivier Coupelon, Alfred Hoenes and the NETCONF mailing list
members for their comments on the document. The author
appreciates also Bert Wijnen, Mehmet Ersue and Dan Romascanu for
their efforts on issues resolving discussion, and Charlie
Kaufman, Pasi Eronen and Tim Polk for the thorough review of this
document.

Section 3.2: "Typically, the server has no external knowledge" is replaced with
"The server may have no external knowledge"

Section 4 : text added to the Security Considerations section to describe security
threads and to give recommendations on the sender and receiver behaviour in case
they detect the delimiter sequence in between a NETCONF message.