idnits 2.17.1 draft-schoenw-opsawg-nm-srv-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4420 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5539 (Obsoleted by RFC 7589) == Outdated reference: A later version (-05) exists of draft-ietf-opsawg-automated-network-configuration-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Schoenwaelder 3 Internet-Draft Jacobs University Bremen 4 Intended status: Informational T. Tsou 5 Expires: September 13, 2012 C. Zhou 6 Huawei Technologies 7 March 12, 2012 9 DNS SRV Resource Records for Network Management Protocols 10 draft-schoenw-opsawg-nm-srv-03 12 Abstract 14 This document specifies how to use Domain Name Service (DNS) SRV 15 Resource Records (RRs) to locate network management services. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 13, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Service Names . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. SYSLOG . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.3. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5.1. Normative References . . . . . . . . . . . . . . . . . . . 8 60 5.2. Informative References . . . . . . . . . . . . . . . . . . 9 61 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 10 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 64 1. Introduction 66 This document specifies how to use Domain Name Service (DNS) SRV 67 Resource Records (RRs) [RFC2782] to locate network management 68 services. The use of SRV RRs can be useful in network bootstrapping 69 scenarios or in zero-configuration network scenarios (e.g., home 70 networks). 72 The network management DNS SRV RRs defined in this memo may be used 73 for different purposes: 75 o Manageable devices announce their management interfaces using a 76 multicast DNS service [I-D.cheshire-dnsext-multicastdns]. A 77 management system discovers the devices and initiates management 78 interactions with them. 80 o Devices discover destinations for event notifications or logging 81 services by looking up (statically) configured SRV RRs in the DNS. 83 The DNS SRV RRs defined in this memo address some gaps identified for 84 the automated configuration of large IP networks 85 [I-D.ietf-opsawg-automated-network-configuration]. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 2. Service Names 93 IANA maintains the registry for service names and port numbers 94 [RFC6335]. The service names maintained in this registry can be used 95 with DNS SRV records. In addition, these service names can be used 96 for dynamic service discovery as defined in 97 [I-D.cheshire-dnsext-dns-sd]. 99 2.1. SYSLOG 101 The Reliable Delivery of syslog specification [RFC3195] already 102 mentions the usage of DNS SRV RRs to locate SYSLOG collectors. The 103 more recent SYSLOG protocol specification [RFC5424] and the 104 associated transport mappings ([RFC5425], [RFC5426], [RFC6012]) do 105 not discuss the usage of SRV RRs to locate SYSLOG collectors. This 106 specification takes the service label definition from [RFC3195] and 107 makes it applicable to structured SYSLOG as defined in [RFC5424]: 109 _syslog Identifies a SYSLOG collector. This SRV RR is primarily 110 for discovery of SYSLOG collectors by SYSLOG originators 111 or relays. 113 Example: service records 115 _syslog._tcp SRV 0 1 6514 syslog.example.com. 116 _syslog._udp SRV 0 1 514 syslog.example.com. 118 A SYSLOG originator may need additional information to send SYSLOG 119 messages to a SYSLOG collector. How this information is derived is 120 not specified and implementation dependent. 122 Note that the IANA service names and port number registry defines the 123 following service names and default port numbers: 125 +-------------+------+-------+-------------------------+-----------+ 126 | Name | Port | Proto | Description | Reference | 127 +-------------+------+-------+-------------------------+-----------+ 128 | syslog | 514 | udp | Syslog over UDP | [RFC5426] | 129 | syslog-conn | 601 | tcp | Reliable Syslog Service | [RFC3195] | 130 | syslog-conn | 601 | udp | Reliable Syslog Service | [RFC3195] | 131 | syslog-tls | 6514 | tcp | Syslog over TLS | [RFC5425] | 132 | syslog-tls | 6514 | udp | Syslog over DTLS | [RFC5425] | 133 | syslog-tls | 6514 | dccp | Syslog over DTLS | [RFC5425] | 134 +-------------+------+-------+-------------------------+-----------+ 136 Table 1: SYSLOG Service Names and Port Numbers 138 [[SYSLOG-Q1: Shall we suggest that implementations MUST or SHOULD use 139 only the syslog service name for discovery? This way, it is not 140 necessary to start a discovery for multiple service names. Of 141 course, we also loose some context information (e.g., that TLS is to 142 be used, which might matter if non-default port numbers are used). 143 --JS]] 145 [[SYSLOG-Q2: What is the future of Reliable Syslog? Can we expect 146 this to be retired so that we can choose to ignore it? --JS]] 148 [[SYSLOG-Q3: What to do with SYSLOG over DTLS/DCCP? Section 7 of the 149 multicast service discovery document suggests that applications using 150 transport protocols different from UDP and TCP should all use the 151 _udp protocol label. Its unclear whether this is generally accepted 152 common practice for SRV records or only a specific recommendation for 153 service discovery. --JS]] 155 [[SYSLOG-Q4: SYSLOG over plain TCP is forthcoming. At the time of 156 this writing, the specification is with the IESG. --JS]] 158 2.2. SNMP 160 The Simple Network Management Protocol (SNMP) [RFC3410] distinguishes 161 between SNMP entities containing command responder and notification 162 originator applications (traditionally called agents) and SNMP 163 entities containing command generator and/or notification receiver 164 applications (traditionally called managers) [RFC3411]. This 165 specification defines two new SRV service labels for SNMP: 167 _snmp Identifies an SNMP entity containing a command responder 168 application. This record is primarily for discovery of 169 SNMP agents that announce their presence using multicast 170 DNS protocols. 172 _snmp-trap Identifies an SNMP entity containing a notification 173 receiver application. This SRV RR is primarily for 174 discovery of SNMP notification sinks by SNMP notification 175 generator applications. 177 Example: service records 179 _snmp._udp SRV 0 1 161 device.example.com. 180 _snmp-trap._udp SRV 0 1 162 nms.example.com. 182 An SNMP engine containing a command generator application needs 183 additional information to send SNMP messages to a SNMP engine 184 containing a command responder application. How this information is 185 derived is not specified and implementation dependent. Similarily, 186 an SNMP engine containing a notification originator application needs 187 additional information to send SNMP messages to a SNMP engine 188 containing a notification receiver application. How this information 189 is derived is not specified and implementation dependent. 191 Note that the IANA service names and port number registry defines the 192 following service names and default port numbers: 194 +--------------+-------+-------+----------------------+-----------+ 195 | Name | Port | Proto | Description | Reference | 196 +--------------+-------+-------+----------------------+-----------+ 197 | snmp | 161 | udp | SNMP over UDP | [RFC3430] | 198 | snmp | 161 | tcp | SNMP over TCP | [RFC3417] | 199 | snmp-trap | 162 | udp | SNMP traps over UDP | [RFC3430] | 200 | snmp-trap | 162 | tcp | SNMP traps over TCP | [RFC3417] | 201 | snmpssh | 5161 | tcp | SNMP over SSH | [RFC5592] | 202 | snmpssh-trap | 5162 | tcp | SNMP traps over SSH | [RFC5592] | 203 | snmptls | 10161 | tcp | SNMP over TLS | [RFC6353] | 204 | snmpdtls | 10161 | udp | SNMP over DTLS | [RFC6353] | 205 | snmptls-trap | 10162 | tcp | SNMP traps over TLS | [RFC6353] | 206 | snmptls-trap | 10162 | udp | SNMP traps over DTLS | [RFC6353] | 207 +--------------+-------+-------+----------------------+-----------+ 209 Table 2: SNMP Service Names and Port Numbers 211 [[SNMP-Q1: Shall we suggest that implementations MUST or SHOULD use 212 only the snmp and snmp-trap service names for discovery? This way, 213 it is not necessary to start a discovery for multiple service names. 214 Of course, we also loose some context information (e.g., that TLS is 215 to be used, which might matter if non-default port numbers are used). 216 --JS]] 218 2.3. NETCONF 220 The NECONF protocol [RFC6241] provides mechanisms to install, 221 manipulate, and delete the configuration of network devices. The 222 mandatory to implement transport uses the Secure Shell (SSH) protocol 223 [RFC6242]. SSH sessions are initiated by the NETCONF client. This 224 specification adds a new SRV service label for NETCONF: 226 _netconf Identifies a NETCONF server. This record is primarily 227 for discovery of NETCONF servers that announce their 228 presence using multicast DNS protocols. 230 Example: service records 232 _netconf._tcp SRV 0 1 830 device.example.com. 234 A NETCONF client needs additional information in order to establish a 235 session with a NETCONF server. How this information is derived is 236 not specified and implementation dependent. 238 Note that the IANA service names and port number registry defines the 239 following service names and default port numbers: 241 +-----------------+------+-------+----------------------+-----------+ 242 | Name | Port | Proto | Description | Reference | 243 +-----------------+------+-------+----------------------+-----------+ 244 | netconf-ssh | 830 | tcp | NETCONF over SSH | [RFC6242] | 245 | netconf-beep | 831 | tcp | NETCONF over BEEP | [RFC4744] | 246 | netconfsoaphttp | 832 | tcp | NETCONF over | [RFC4743] | 247 | | | | SOAP/HTTP | | 248 | netconfsoapbeep | 833 | tcp | NETCONF over | [RFC4743] | 249 | | | | SOAP/BEEP | | 250 | netconf-tls | 6513 | tcp | NETCONF over TLS | [RFC5539] | 251 +-----------------+------+-------+----------------------+-----------+ 253 Table 3: NETCONF Service Names and Port Numbers 255 [[NETCONF-Q1: Shall we suggest that implementations MUST or SHOULD 256 use only the netconf service name for discovery? This way, it is not 257 necessary to start a discovery for multiple service names. Of 258 course, we also loose some context information (e.g., that TLS or SSH 259 is to be used, which might matter if non-default port numbers are 260 used). --JS]] 262 [[NETCONF-Q2: There is discussion to retire NETCONF over SOAP and 263 NETCONF over BEEP which may simplify this a bit. --JS]] 265 3. Security Considerations 267 The security considerations spelled out in the DNS SRV specification 268 [RFC2782] apply. In general, the usage of DNSSEC [RFC4033] is 269 recommended in environments where DNS cannot be trusted. 271 The usage of multicast DNS protocols to discover network management 272 services potentially introduces new security risks since such 273 protocols usually assume cooperating participants. In an environment 274 where antagonistic participants exists, it is necessary to deploy 275 additional security mechanism such as DNSSEC to securely discover 276 network management services. 278 4. IANA Considerations 280 TBD 282 5. References 283 5.1. Normative References 285 [I-D.cheshire-dnsext-dns-sd] 286 Cheshire, S. and M. Krochmal, "DNS-Based Service 287 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in 288 progress), December 2011. 290 [I-D.cheshire-dnsext-multicastdns] 291 Cheshire, S. and M. Krochmal, "Multicast DNS", 292 draft-cheshire-dnsext-multicastdns-15 (work in progress), 293 December 2011. 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, March 1997. 298 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 299 specifying the location of services (DNS SRV)", RFC 2782, 300 February 2000. 302 [RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", 303 RFC 3195, November 2001. 305 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 306 Management Protocol (SNMP)", STD 62, RFC 3417, 307 December 2002. 309 [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol 310 Over Transmission Control Protocol Transport Mapping", 311 RFC 3430, December 2002. 313 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 314 Rose, "DNS Security Introduction and Requirements", 315 RFC 4033, March 2005. 317 [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access 318 Protocol (SOAP)", RFC 4743, December 2006. 320 [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over 321 the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, 322 December 2006. 324 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 326 [RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer 327 Security (TLS) Transport Mapping for Syslog", RFC 5425, 328 March 2009. 330 [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", 331 RFC 5426, March 2009. 333 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 334 RFC 5539, May 2009. 336 [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure 337 Shell Transport Model for the Simple Network Management 338 Protocol (SNMP)", RFC 5592, June 2009. 340 [RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, 341 "Datagram Transport Layer Security (DTLS) Transport 342 Mapping for Syslog", RFC 6012, October 2010. 344 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 345 Bierman, "Network Configuration Protocol (NETCONF)", 346 RFC 6241, June 2011. 348 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 349 Shell (SSH)", RFC 6242, June 2011. 351 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 352 Cheshire, "Internet Assigned Numbers Authority (IANA) 353 Procedures for the Management of the Service Name and 354 Transport Protocol Port Number Registry", BCP 165, 355 RFC 6335, August 2011. 357 [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport 358 Model for the Simple Network Management Protocol (SNMP)", 359 RFC 6353, July 2011. 361 5.2. Informative References 363 [I-D.ietf-opsawg-automated-network-configuration] 364 Tsou, T., Schoenwaelder, J., Shi, Y., Taylor, T., and G. 365 Yang, "Problem Statement for the Automated Configuration 366 of Large IP Networks", 367 draft-ietf-opsawg-automated-network-configuration-03 (work 368 in progress), March 2012. 370 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 371 "Introduction and Applicability Statements for Internet- 372 Standard Management Framework", RFC 3410, December 2002. 374 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 375 Architecture for Describing Simple Network Management 376 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 377 December 2002. 379 Appendix A. Open Issues 381 1. draft-hallambaker-esrv-01 proposes a RRs to store additional 382 information in so called General Service Description (GSRV) and 383 Extended Service Description (ESRV) records (e.g., which security 384 protocol to use). This is traditionally done using TXT records. 386 2. draft-kwatsen-reverse-ssh-00 proposes a mechanism which allows an 387 SSH server to establish the TCP connection to an SSH client; if 388 this moves forward NETCONF servers may want to discover NETCONF 389 clients. 391 Authors' Addresses 393 Juergen Schoenwaelder 394 Jacobs University Bremen 395 Campus Ring 1 396 Bremen 28759 397 Germany 399 Email: j.schoenwaelder@jacobs-university.de 401 Tina Tsou 402 Huawei Technologies 403 Bantian, Longgang District 404 Shenzhen 518129 405 P.R. China 407 Email: tena@huawei.com 409 Cathy Zhou 410 Huawei Technologies 411 Bantian, Longgang District 412 Shenzhen 518129 413 P.R. China 415 Email: cathyzhou@huawei.com