Internet Engineering Task Force J. Schoenwaelder
Internet-Draft Jacobs University Bremen
Intended status: Informational T. Tsou
Expires: June 3, 2011 C. Zhou
Huawei Technologies
November 30, 2010
DNS SRV Resource Records for Network Management Protocols
draft-schoenw-opsawg-nm-srv-01
Abstract
This document specifies how to use Domain Name Service (DNS) SRV
Resource Records (RRs) to locate network management services.
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."
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 June 3, 2011.
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Schoenwaelder, et al. Expires June 3, 2011 [Page 1]
Internet-Draft Network Management SRV Records November 2010
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SRV Service Labels . . . . . . . . . . . . . . . . . . . . . . 3
2.1. SYSLOG . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Informative References . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Schoenwaelder, et al. Expires June 3, 2011 [Page 2]
Internet-Draft Network Management SRV Records November 2010
1. Introduction
This document specifies how to use Domain Name Service (DNS) SRV
Resource Records (RRs) [RFC2782] to locate network management
services. The use of SRV RRs can be useful in network bootstrapping
scenarios or in zero-configuration network scenarios (e.g., home
networks).
The network management DNS SRV RRs defined in this memo may be used
for different purposes:
o Manageable devices announce their management interfaces using a
multicast DNS service. A management system discovers the devices
and initiates management interactions with them.
o Devices discover destinations for event notifications or logging
services by looking up (statically) configured SRV RRs in the DNS.
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. SRV Service Labels
2.1. SYSLOG
The Reliable Delivery of syslog specification [RFC3195] mentions the
usage of DNS SRV RRs to locate SYSLOG collectors. The more recent
SYSLOG protocol specification [RFC5424] and the associated transport
mappings ([RFC5425], [RFC5426], [RFC6012]) do not discuss the usage
of SRV RRs to locate SYSLOG collectors. This specification takes the
service label definition from [RFC3195] and makes it applicable to
structured SYSLOG as defined in [RFC5424]:
_syslog Identifies a SYSLOG collector. This SRV RR is primarily
for discovery of SYSLOG collectors by SYSLOG originators
or relays.
Example: service records
_syslog._tcp SRV 0 1 6514 syslog.example.com.
_syslog._udp SRV 0 1 514 syslog.example.com.
A SYSLOG originator may need additional information to send SYSLOG
messages to a SYSLOG collector. How this information is derived is
not specified and implementation dependent.
Schoenwaelder, et al. Expires June 3, 2011 [Page 3]
Internet-Draft Network Management SRV Records November 2010
2.2. SNMP
The Simple Network Management Protocol (SNMP) [RFC3410] distinguishes
between SNMP entities containing command responder and notification
originator applications (traditionally called agents) and SNMP
entities containing command generator and/or notification receiver
applications (traditionally called a managers) [RFC3411]. This
specification defines two new SRV service labels for SNMP:
_snmp Identifies an SNMP entity containing a command responder
application. This record is primarily for discovery of
SNMP agents that announce their presence using multicast
DNS protocols.
_snmp-trap Identifies an SNMP entity containing a notification
receiver application. This SRV RR is primarily for
discovery of SNMP notification sinks by SNMP notification
generator applications.
Example: service records
_snmp._udp SRV 0 1 161 device.example.com.
_snmp-trap._udp SRV 0 1 162 nms.example.com.
An SNMP engine containing a command generator application needs
additional information to send SNMP messages to a SNMP engine
containing a command responder application. How this information is
derived is not specified and implementation dependent. Similarily,
an SNMP engine containing a notification originator application needs
additional information to send SNMP messages to a SNMP engine
containing a notification receiver application. How this information
is derived is not specified and implementation dependent.
2.3. NETCONF
The NECONF protocol [RFC4741] provides mechanisms to install,
manipulate, and delete the configuration of network devices. The
mandatory to implement transport uses the Secure Shell (SSH) protocol
[RFC4742]. SSH sessions are always initiated by the NETCONF client.
This specification adds a new SRV service label for NETCONF:
_netconf Identifies a NETCONF server. This record is primarily
for discovery of NETCONF servers that announce their
presence using multicast DNS protocols.
Example: service records
_netconf._tcp SRV 0 1 830 device.example.com.
Schoenwaelder, et al. Expires June 3, 2011 [Page 4]
Internet-Draft Network Management SRV Records November 2010
A NETCONF client needs additional information in order to establish a
session with a NETCONF server. How this information is derived is
not specified and implementation dependent.
3. Security Considerations
The security considerations spelled out in the DNS SRV specification
[RFC2782] apply. In general, the usage of DNSSEC [RFC4033] is
recommended in environments where DNS cannot be trusted.
The usage of multicast DNS protocols to discover network management
services potentially introduces new security risks since such
protocols usually assume cooperating participants. In an environment
where antagonistic participants exists, it is necessary to deploy
additional security mechanism such as DNSSEC to securely discover
network management services.
4. IANA Considerations
TBD
5. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog",
RFC 3195, November 2001.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
Schoenwaelder, et al. Expires June 3, 2011 [Page 5]
Internet-Draft Network Management SRV Records November 2010
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF
Configuration Protocol over Secure SHell (SSH)", RFC 4742,
December 2006.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer
Security (TLS) Transport Mapping for Syslog", RFC 5425,
March 2009.
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP",
RFC 5426, March 2009.
[RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng,
"Datagram Transport Layer Security (DTLS) Transport
Mapping for Syslog", RFC 6012, October 2010.
Appendix A. Open Issues
1. draft-gudmundsson-dns-srv-iana-registry-04 proposes a template
for registering SRV names. We may have to use this format in
case draft-gudmundsson-dns-srv-iana-registry-04 moves forward.
2. draft-hallambaker-esrv-00 proposes a mechanism to store
additional information in so called ESRV records (e.g., which
security protocol to use). This is traditionally done using TXT
records.
3. draft-gudmundsson-dnsext-srv-clarify describes extended service
labels that may be used to identify security protocols that are
located between the management protocol and the transport
protocol. This may be adopted to identify TLS/DTLS/SSH usage to
secure management protocols.
Schoenwaelder, et al. Expires June 3, 2011 [Page 6]
Internet-Draft Network Management SRV Records November 2010
Authors' Addresses
Juergen Schoenwaelder
Jacobs University Bremen
Campus Ring 1
Bremen 28759
Germany
Email: j.schoenwaelder@jacobs-university.de
Tina Tsou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: tena@huawei.com
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: cathyzhou@huawei.com
Schoenwaelder, et al. Expires June 3, 2011 [Page 7]