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

Versions: 00 01 02 03

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]


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