Internet Engineering Task Force J. Schoenwaelder Internet-Draft Jacobs University Bremen Intended status: Standards Track T. Tsou Expires: December 07, 2013 C. Zhou T. Taylor Huawei Technologies June 05, 2013 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Network Management Protocols draft-schoenw-opsawg-nm-dhc-04 Abstract This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options providing lists of IP addresses that can be used to locate network management services, specifically for the collection of logs and of Simple Network Management Protocol (SNMP) notifications. 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 December 07, 2013. Copyright Notice Copyright (c) 2013 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 Schoenwaelder, et al. Expires December 07, 2013 [Page 1] Internet-Draft DHC Options for Network Management June 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. DHC Options for SYSLOG . . . . . . . . . . . . . . . . . . . 3 2.1. SYSLOG Collector Address Option for DHCPv4 . . . . . . . 3 2.2. SYSLOG Collector Address Option for DHCPv6 . . . . . . . 4 3. DHC Options for SNMP . . . . . . . . . . . . . . . . . . . . 5 3.1. SNMP Notification Receiver Address Option for DHCPv4 . . 5 3.2. SNMP Notification Receiver Address Option for DHCPv6 . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informational References . . . . . . . . . . . . . . . . 9 Appendix A. Relationship to the SNMP Configuration MIB Modules . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction New networks such as 3GPP Long Term Evolution (LTE) are being deployed today with tens of thousands of network nodes. All of these nodes have to be configured and monitored for the network to operate correctly. Any steps to automate this process will be helpful to reduce the cost of deployment. The Dynamic Host Configuration Protocol (DHCPv4 [RFC2131] and DHCPv6 [RFC3315]) is a relevant tool for this purpose. It provides a number of existing options to allow a node to acquire its configuration file and to locate key servers in the network. However, the existing options have been defined more with end hosts than with network nodes in mind. Network nodes require active management, and therefore need to acquire the addresses of their management servers. This document is specifically focussed on the requirement for event reporting. To that end, it defines new DHCP options capable of listing: o one or more addresses of SYSLOG [RFC5424] collectors; o one or more addresses of SNMP [RFC3410] entities hosting Notification Receiver applications. Schoenwaelder, et al. Expires December 07, 2013 [Page 2] Internet-Draft DHC Options for Network Management June 2013 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. DHC Options for SYSLOG The SYSLOG protocol [RFC5424] supports several transport mappings. According to RFC 5424, implementations MUST support the TLS/TCP-based transport defined in [RFC5425] and they SHOULD also support the UDP- based transport defined in [RFC5426] for compatibility with traditional SYSLOG. An optional transport of SYSLOG messages over DTLS/DCCP and DTLS/UDP is defined in [RFC6012]. The DHC options described below provide a list of IPv4 or IPv6 addresses of SYSLOG collectors in order of preference. The client SHOULD use the addresses sequentially but may be configured to try secure and/or congestion aware transports before falling back to transports that are not congestion aware or insecure. As such, the client may prefer to select an address providing a secure congestion aware transport even if it is listed with lower preference. 2.1. SYSLOG Collector Address Option for DHCPv4 This section describes the SYSLOG IPv4 Address Option for DHCPv4. The SYSLOG IPv4 Address Option begins with an option code followed by a length octet. The value of the length octet does not include itself or the option code. The option layout is depicted below: Code Len IPv4 Address 1 IPv4 Address 2 +-----+-----+-----+-----+-----+-----+-----+-----+-- | TBD1| n | a1 | a2 | a3 | a4 | a1 | a2 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-- The code for the SYSLOG DHCPv4 option is [IANA: TBD1]. The minimum length of the option is 4 octets, and the length MUST always be a multiple of 4. The option MUST NOT be specified by the DHCPv4 client, as it is intended only to be returned from the DHCPv4 server. If the DHCPv4 client wants to receive this information from the server, it needs to include the number [IANA: TBD1] in the "DHCP Parameter Request List" option (55). Schoenwaelder, et al. Expires December 07, 2013 [Page 3] Internet-Draft DHC Options for Network Management June 2013 Server addresses SHOULD be listed in order of preference, and the client SHOULD use the addresses sequentially but may be configured to use addresses in a different order according to some local policy (e.g., the client prefers secure and/or congestion aware transports as described above). Historical note: DHCPv4 option 7 was originally defined (Section 3.9 of [RFC2132]) to provide the addresses of one or more log servers. However, the logging technology concerned was specified to be "MIT-LCS UDP log servers". It seems preferable to define a new option for SYSLOG collectors. 2.2. SYSLOG Collector Address Option for DHCPv6 This section describes the SYSLOG IPv6 Address Option for DHCPv6. The SYSLOG IPv6 Address Option begins with an option-code followed by the option-len. The value of the option-len does not include itself or the option-code. The option layout is depicted below: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | IPv6 address of SYSLOG collector | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The option-code of the SYSLOG DHCPv6 option OPTION_SYSLOG_COLLECTOR is [IANA: TBD2]. The minimum option-len is 16 octets, and the length MUST always be a multiple of 16. The option MUST NOT appear in other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request and Reply. The option number for these options MAY appear in the Option Request Option (6) in the following messages: Solicit, Request, Renew, Rebind, Information-Request and Reconfigure. The addresses SHOULD be listed in order of preference, and the client SHOULD use the addresses sequentially but may be configured to use addresses in a different order according to some local policy (e.g., the client prefers secure and/or congestion aware transports as described above). Schoenwaelder, et al. Expires December 07, 2013 [Page 4] Internet-Draft DHC Options for Network Management June 2013 3. DHC Options for SNMP The SNMP protocol [RFC3410] supports several transport mappings. The preferred IP-based transport is SNMP over UDP [RFC3417]. An experimental transport of SNMP over TCP is defined in [RFC3430]. An optional standards-track transport of SNMP over SSH is defined in [RFC5592] while optional standards-track transports over TLS and DTLS are defined in [RFC6353] The DHC options described below provide a list of IPv4 or IPv6 addresses of SNMP entities hosting Notification Receiver applications in order of preference. The client SHOULD use the addresses sequentially but may be configured to try secure and/or congestion aware transports before falling back to transports that are not congestion aware or insecure. As such, the client may prefer to select an address providing a secure congestion aware transport even if it is listed with lower preference. 3.1. SNMP Notification Receiver Address Option for DHCPv4 This section describes the SNMP IPv4 Address Option for DHCPv4. The SNMP IPv4 Address Option begins with an option code followed by a length octet. The value of the length octet does not include itself or the option code. The option layout is depicted below: Code Len IPv4 Address 1 IPv4 Address 2 +-----+-----+-----+-----+-----+-----+-----+-----+-- | TBD3| n | a1 | a2 | a3 | a4 | a1 | a2 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-- The code for the SNMP notification receiver DHCPv4 option is [IANA: TBD3]. The minimum length of the option is 4 octets, and the length MUST always be a multiple of 4. The option MUST NOT be specified by the DHCPv4 client, as it is intended only to be returned from the DHCPv4 server. If the DHCPv4 client wants to receive this information from the server, it needs to include the number [IANA: TBD3] in the "DHCP Parameter Request List" option (55). The addresses SHOULD be listed in order of preference, and the client SHOULD use the addresses sequentially but may be configured to use addresses in a different order according to some local policy (e.g., the client prefers secure and/or congestion aware transports as described above). Schoenwaelder, et al. Expires December 07, 2013 [Page 5] Internet-Draft DHC Options for Network Management June 2013 3.2. SNMP Notification Receiver Address Option for DHCPv6 This section describes the SNMP IPv6 Address Option for DHCPv6. The SNMP IPv6 Address Option begins with an option-code followed by the option-len. The value of the option-len does not include itself or the option-code. The option layout is depicted below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | IPv6 address of SNMP notification receiver | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The option-code of the SNMP notification receiver DHCPv6 option OPTION_SNMP_NOT_RECEIVER is [IANA: TBD4]. The minimum option-len is 16 octets, and the length MUST always be a multiple of 16. The option MUST NOT appear in other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request and Reply. The option number for these options MAY appear in the Option Request Option (6) in the following messages: Solicit, Request, Renew, Rebind, Information-Request and Reconfigure. Server addresses SHOULD be listed in order of preference, and the client SHOULD use the addresses sequentially but may be configured to use addresses in a different order according to some local policy (e.g., the client prefers secure and/or congestion aware transports as described above). 4. Security Considerations The security considerations in [RFC2131] and [RFC3315]) apply. If an adversary manages to modify the response from a DHCPv4 or DHCPv6 server or insert its own response, a node could be led to contact a rogue network management server. It is recommended to use the DHCPv4 authentication option described in [RFC3118] where available. This will also protect against denial- of-service attacks to DHCP servers. [RFC3118] provides mechanisms for both entity authentication and message authentication. Schoenwaelder, et al. Expires December 07, 2013 [Page 6] Internet-Draft DHC Options for Network Management June 2013 In IPv6 networks using DHCPv6, it is recommended that clients use authentication of DHCPv6 messages as described in Section 21 of [RFC3315]. In deployments where DHCPv4 or DHCPv6 authentication is not available, lower-layer security services may be sufficient to protect DHCPv4 and DHCPv6 messages. 5. IANA Considerations IANA is requested to assign [IANA: TBD1] and [IANA: TBD3] as option codes in the "DHCP Option Codes" registry. The desired entries are shown in Table 1. +------+------------------+----------+------------------+-----------+ | Tag | Name | Data | Meaning | Reference | | | | Length | | | +------+------------------+----------+------------------+-----------+ | TBD1 | SYSLOG Collector | N | N/4 SYSLOG | RFCxxxx | | | Address | | collector | | | | | | addresses | | | TBD3 | SNMP | N | N/4 SNMP | RFCxxxx | | | Notification | | Notification | | | | Receiver Address | | Receiver | | | | | | addresses | | +------+------------------+----------+------------------+-----------+ Table 1: DHCPv4 Option Codes For Network Management Servers IANA is requested to assign [IANA: TBD2] as an option code from the "DHCPv6 Options Codes" registry for OPTION_SYSLOG_COLLECTOR, with reference RFCxxxx. IANA is requested to assign [IANA: TBD4] as an option code from the "DHCPv6 Options Codes" registry for OPTION_SNMP_NOT_RECEIVER, with reference RFCxxxx. RFC Editor's Note: RFCxxxx denotes the present document. 6. Acknowledgements The authors like to thank Ralf Droms, Ted Lemon and Bernie Volz for their helpful comments. 7. References 7.1. Normative References Schoenwaelder, et al. Expires December 07, 2013 [Page 7] Internet-Draft DHC Options for Network Management June 2013 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [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. [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. [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. [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 6353, July 2011. Schoenwaelder, et al. Expires December 07, 2013 [Page 8] Internet-Draft DHC Options for Network Management June 2013 7.2. Informational References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Appendix A. Relationship to the SNMP Configuration MIB Modules The SNMP notification receiver address DHCPv4 and DHCPv6 options defined in Section 3.1 and Section 3.2 provide the basic information to setup a target in the SNMP-TARGET-MIB and the SNMP-NOTIFICATION- MIB [RFC3413]. After selecting the transport (e.g., by probing the availability of possible SNMP transport endpoints according to some local policy, a volatile entry in the snmpTargetTable can be created as follows (assuming xyz is some suitable unique handle for the received DHCP option): snmpTargetAddrName = "dhcp-xyz" (INDEX) snmpTargetAddrTDomain = snmpUDPDomain snmpTargetAddrTAddress = "a.b.c.d" snmpTargetAddrTimeout = 1500 (DEFVAL) snmpTargetAddrRetryCount = 3 (DEFVAL) snmpTargetAddrTagList = "dhcp-xyz-tag" snmpTargetAddrParams = "dhcp-xyz-param" snmpTargetAddrStorageType = volatile(2) snmpTargetAddrRowStatus = active(1) A matching volatile entry in the snmpNotifyTable can also be easily created: snmpNotifyName = "dhcp-xyz" (INDEX) snmpNotifyTag = "dhcp-xyz-tag" snmpNotifyType = trap(1) (DEFVAL) snmpNotifyStorageType = volatile(2) snmpNotifyRowStatus = active(1) In addition, an entry in the snmpTargetParamsTable is needed. Its structure for SNMPv3/USM user "joe" is as follows: Schoenwaelder, et al. Expires December 07, 2013 [Page 9] Internet-Draft DHC Options for Network Management June 2013 snmpTargetParamsName = "dhcp-xyz-param" (INDEX) snmpTargetParamsMPModel = 3 (SNMPv3) snmpTargetParamsSecurityModel = 3 (USM) snmpTargetParamsSecurityName = "joe" snmpTargetParamsSecurityLevel = authNoPriv(2) snmpTargetParamsStorageType = volatile(2) snmpTargetParamsRowStatus = active(1) Creation of a suitable entry in the snmpTargetParamsTable requires local information. Depending on the security model, additional information will be necessary. The creation of a suitable snmpTargetParamsTable entry may either be dynamic (i.e., the entry is created upon receipt of a DHC lease using some local policy information and deleted when the DHC lease expires) or suitable snmpTargetParamsTable entries may be pre-provisioned based on the expected naming of the target entries that are created dynamically. Implementations may also pre-provision snmpTargetAddrTable entries and only dynamically create suitable snmpNotifyTable entries. Authors' Addresses Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 Bremen 28759 Germany Email: j.schoenwaelder@jacobs-university.de Tina Tsou Huawei Technologies 2330 Central Expressway Santa Clara CA 95050 USA Email: Tina.Tsou.Zouting@huawei.com Schoenwaelder, et al. Expires December 07, 2013 [Page 10] Internet-Draft DHC Options for Network Management June 2013 Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: cathyzhou@huawei.com Tom Taylor Huawei Technologies Ottawa Canada Email: tom.taylor.stds@gmail.com Schoenwaelder, et al. Expires December 07, 2013 [Page 11]