Internet DRAFT - draft-schoenw-opsawg-nm-srv
draft-schoenw-opsawg-nm-srv
Internet Engineering Task Force J. Schoenwaelder
Internet-Draft Jacobs University Bremen
Intended status: Informational T. Tsou
Expires: September 13, 2012 C. Zhou
Huawei Technologies
March 12, 2012
DNS SRV Resource Records for Network Management Protocols
draft-schoenw-opsawg-nm-srv-03
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 in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 13, 2012.
Copyright Notice
Copyright (c) 2012 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
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 Simplified BSD License.
Schoenwaelder, et al. Expires September 13, 2012 [Page 1]
Internet-Draft Network Management SRV Records March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. SYSLOG . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Normative References . . . . . . . . . . . . . . . . . . . 8
5.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Schoenwaelder, et al. Expires September 13, 2012 [Page 2]
Internet-Draft Network Management SRV Records March 2012
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 [I-D.cheshire-dnsext-multicastdns]. 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 DNS SRV RRs defined in this memo address some gaps identified for
the automated configuration of large IP networks
[I-D.ietf-opsawg-automated-network-configuration].
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. Service Names
IANA maintains the registry for service names and port numbers
[RFC6335]. The service names maintained in this registry can be used
with DNS SRV records. In addition, these service names can be used
for dynamic service discovery as defined in
[I-D.cheshire-dnsext-dns-sd].
2.1. SYSLOG
The Reliable Delivery of syslog specification [RFC3195] already
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]:
Schoenwaelder, et al. Expires September 13, 2012 [Page 3]
Internet-Draft Network Management SRV Records March 2012
_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.
Note that the IANA service names and port number registry defines the
following service names and default port numbers:
+-------------+------+-------+-------------------------+-----------+
| Name | Port | Proto | Description | Reference |
+-------------+------+-------+-------------------------+-----------+
| syslog | 514 | udp | Syslog over UDP | [RFC5426] |
| syslog-conn | 601 | tcp | Reliable Syslog Service | [RFC3195] |
| syslog-conn | 601 | udp | Reliable Syslog Service | [RFC3195] |
| syslog-tls | 6514 | tcp | Syslog over TLS | [RFC5425] |
| syslog-tls | 6514 | udp | Syslog over DTLS | [RFC5425] |
| syslog-tls | 6514 | dccp | Syslog over DTLS | [RFC5425] |
+-------------+------+-------+-------------------------+-----------+
Table 1: SYSLOG Service Names and Port Numbers
[[SYSLOG-Q1: Shall we suggest that implementations MUST or SHOULD use
only the syslog service name for discovery? This way, it is not
necessary to start a discovery for multiple service names. Of
course, we also loose some context information (e.g., that TLS is to
be used, which might matter if non-default port numbers are used).
--JS]]
[[SYSLOG-Q2: What is the future of Reliable Syslog? Can we expect
this to be retired so that we can choose to ignore it? --JS]]
[[SYSLOG-Q3: What to do with SYSLOG over DTLS/DCCP? Section 7 of the
multicast service discovery document suggests that applications using
transport protocols different from UDP and TCP should all use the
_udp protocol label. Its unclear whether this is generally accepted
common practice for SRV records or only a specific recommendation for
service discovery. --JS]]
[[SYSLOG-Q4: SYSLOG over plain TCP is forthcoming. At the time of
this writing, the specification is with the IESG. --JS]]
Schoenwaelder, et al. Expires September 13, 2012 [Page 4]
Internet-Draft Network Management SRV Records March 2012
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 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.
Note that the IANA service names and port number registry defines the
following service names and default port numbers:
Schoenwaelder, et al. Expires September 13, 2012 [Page 5]
Internet-Draft Network Management SRV Records March 2012
+--------------+-------+-------+----------------------+-----------+
| Name | Port | Proto | Description | Reference |
+--------------+-------+-------+----------------------+-----------+
| snmp | 161 | udp | SNMP over UDP | [RFC3430] |
| snmp | 161 | tcp | SNMP over TCP | [RFC3417] |
| snmp-trap | 162 | udp | SNMP traps over UDP | [RFC3430] |
| snmp-trap | 162 | tcp | SNMP traps over TCP | [RFC3417] |
| snmpssh | 5161 | tcp | SNMP over SSH | [RFC5592] |
| snmpssh-trap | 5162 | tcp | SNMP traps over SSH | [RFC5592] |
| snmptls | 10161 | tcp | SNMP over TLS | [RFC6353] |
| snmpdtls | 10161 | udp | SNMP over DTLS | [RFC6353] |
| snmptls-trap | 10162 | tcp | SNMP traps over TLS | [RFC6353] |
| snmptls-trap | 10162 | udp | SNMP traps over DTLS | [RFC6353] |
+--------------+-------+-------+----------------------+-----------+
Table 2: SNMP Service Names and Port Numbers
[[SNMP-Q1: Shall we suggest that implementations MUST or SHOULD use
only the snmp and snmp-trap service names for discovery? This way,
it is not necessary to start a discovery for multiple service names.
Of course, we also loose some context information (e.g., that TLS is
to be used, which might matter if non-default port numbers are used).
--JS]]
2.3. NETCONF
The NECONF protocol [RFC6241] provides mechanisms to install,
manipulate, and delete the configuration of network devices. The
mandatory to implement transport uses the Secure Shell (SSH) protocol
[RFC6242]. SSH sessions are 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.
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.
Note that the IANA service names and port number registry defines the
following service names and default port numbers:
Schoenwaelder, et al. Expires September 13, 2012 [Page 6]
Internet-Draft Network Management SRV Records March 2012
+-----------------+------+-------+----------------------+-----------+
| Name | Port | Proto | Description | Reference |
+-----------------+------+-------+----------------------+-----------+
| netconf-ssh | 830 | tcp | NETCONF over SSH | [RFC6242] |
| netconf-beep | 831 | tcp | NETCONF over BEEP | [RFC4744] |
| netconfsoaphttp | 832 | tcp | NETCONF over | [RFC4743] |
| | | | SOAP/HTTP | |
| netconfsoapbeep | 833 | tcp | NETCONF over | [RFC4743] |
| | | | SOAP/BEEP | |
| netconf-tls | 6513 | tcp | NETCONF over TLS | [RFC5539] |
+-----------------+------+-------+----------------------+-----------+
Table 3: NETCONF Service Names and Port Numbers
[[NETCONF-Q1: Shall we suggest that implementations MUST or SHOULD
use only the netconf service name for discovery? This way, it is not
necessary to start a discovery for multiple service names. Of
course, we also loose some context information (e.g., that TLS or SSH
is to be used, which might matter if non-default port numbers are
used). --JS]]
[[NETCONF-Q2: There is discussion to retire NETCONF over SOAP and
NETCONF over BEEP which may simplify this a bit. --JS]]
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. References
Schoenwaelder, et al. Expires September 13, 2012 [Page 7]
Internet-Draft Network Management SRV Records March 2012
5.1. Normative References
[I-D.cheshire-dnsext-dns-sd]
Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", draft-cheshire-dnsext-dns-sd-11 (work in
progress), December 2011.
[I-D.cheshire-dnsext-multicastdns]
Cheshire, S. and M. Krochmal, "Multicast DNS",
draft-cheshire-dnsext-multicastdns-15 (work in progress),
December 2011.
[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.
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3417,
December 2002.
[RFC3430] Schoenwaelder, J., "Simple Network Management Protocol
Over Transmission Control Protocol Transport Mapping",
RFC 3430, December 2002.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access
Protocol (SOAP)", RFC 4743, December 2006.
[RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over
the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744,
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",
Schoenwaelder, et al. Expires September 13, 2012 [Page 8]
Internet-Draft Network Management SRV Records March 2012
RFC 5426, March 2009.
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)",
RFC 5539, May 2009.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
Shell Transport Model for the Simple Network Management
Protocol (SNMP)", RFC 5592, June 2009.
[RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng,
"Datagram Transport Layer Security (DTLS) Transport
Mapping for Syslog", RFC 6012, October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, August 2011.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport
Model for the Simple Network Management Protocol (SNMP)",
RFC 6353, July 2011.
5.2. Informative References
[I-D.ietf-opsawg-automated-network-configuration]
Tsou, T., Schoenwaelder, J., Shi, Y., Taylor, T., and G.
Yang, "Problem Statement for the Automated Configuration
of Large IP Networks",
draft-ietf-opsawg-automated-network-configuration-03 (work
in progress), March 2012.
[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.
Schoenwaelder, et al. Expires September 13, 2012 [Page 9]
Internet-Draft Network Management SRV Records March 2012
Appendix A. Open Issues
1. draft-hallambaker-esrv-01 proposes a RRs to store additional
information in so called General Service Description (GSRV) and
Extended Service Description (ESRV) records (e.g., which security
protocol to use). This is traditionally done using TXT records.
2. draft-kwatsen-reverse-ssh-00 proposes a mechanism which allows an
SSH server to establish the TCP connection to an SSH client; if
this moves forward NETCONF servers may want to discover NETCONF
clients.
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 September 13, 2012 [Page 10]
