Internet Engineering Task Force J. Schoenwaelder Internet-Draft Jacobs University Bremen Intended status: Standards Track T. Tsou Expires: December 7, 2011 C. Zhou Huawei Technologies June 5, 2011 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for Network Management Protocols draft-schoenw-opsawg-nm-dhc-02 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. 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 December 7, 2011. Copyright Notice Copyright (c) 2011 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 Schoenwaelder, et al. Expires December 7, 2011 [Page 1] Internet-Draft DHC Options for Network Management June 2011 (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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . 8 Appendix A. Relationship to the SNMP Configuration MIB Modules . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Schoenwaelder, et al. Expires December 7, 2011 [Page 2] Internet-Draft DHC Options for Network Management June 2011 1. Introduction This document defines new Dynamic Host Configuration Protocol (DHCPv4 [RFC2131] and DHCPv6 [RFC3315]) options providing lists of IP addresses that can be used to locate network management services. The Dynamic Host Configuration (DHC) options 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. 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 Schoenwaelder, et al. Expires December 7, 2011 [Page 3] Internet-Draft DHC Options for Network Management June 2011 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). 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). 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: 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 7, 2011 [Page 4] Internet-Draft DHC Options for Network Management June 2011 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 [RFC5953] 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 7, 2011 [Page 5] Internet-Draft DHC Options for Network Management June 2011 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 7, 2011 [Page 6] Internet-Draft DHC Options for Network Management June 2011 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] as an option code from the "DHCP Option Codes" registry. IANA is requested to assign [IANA: TBD2] as an option code from the "DHCPv6 Options Codes" registry for OPTION_SYSLOG_COLLECTOR. IANA is requested to assign [IANA: TBD3] as an option code from the "DHCP Option Codes" registry. IANA is requested to assign [IANA: TBD4] as an option code from the "DHCPv6 Options Codes" registry for OPTION_SNMP_NOT_RECEIVER. 6. Acknowledgements The authors like to thank Ralf Droms, Ted Lemon and Bernie Volz for their helpful comments. 7. References 7.1. Normative References [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. [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 Schoenwaelder, et al. Expires December 7, 2011 [Page 7] Internet-Draft DHC Options for Network Management June 2011 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. [RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5953, August 2010. [RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, "Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog", RFC 6012, October 2010. 7.2. Informational References [I-D.ietf-opsawg-automated-network-configuration] ZOU), 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-01 (work in progress), May 2011. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Schoenwaelder, et al. Expires December 7, 2011 [Page 8] Internet-Draft DHC Options for Network Management June 2011 Appendix A. Relationship to the SNMP Configuration MIB Modules The SNMP notification receiver DHCPv4 and DHCPv6 options 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 of preference, 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: snmpTargetParamsName = "dhcp-xyz-param" (INDEX) snmpTargetParamsMPModel = 3 (SNMPv3) snmpTargetParamsSecurityModel = 3 (USM) snmpTargetParamsSecurityName = "joe" snmpTargetParamsSecurityLevel = authNoPriv(2) snmpTargetParamsStorageType = volatile(2) snmpTargetParamsRowStatus = active(1) Creating of a suitable entry in the snmpTargetParamsTable requires local information. Depending on the security model, additional information will be necessary. A decision should be taken whether we assume that a suitable entry can dynamically be created following some local policy information or whether it is expected that snmpTargetParamsTable entries are pre- provisioned and the DHCPv4 and DHCPv6 options carry the name of the Schoenwaelder, et al. Expires December 7, 2011 [Page 9] Internet-Draft DHC Options for Network Management June 2011 snmpTargetParamsName entry to apply. 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 December 7, 2011 [Page 10]