Generalized UDP Source Port for DHCP Relay
draft-ietf-dhc-relay-port-09
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8357.
|
|
---|---|---|---|
Authors | Naiming Shen , Enke Chen | ||
Last updated | 2017-11-30 (Latest revision 2017-11-29) | ||
Replaces | draft-shen-dhc-client-port | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
INTDIR Early review
(of
-05)
by Ralf Weber
Ready w/nits
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Tomek Mrugalski | ||
Shepherd write-up | Show Last changed 2017-06-23 | ||
IESG | IESG state | Became RFC 8357 (Proposed Standard) | |
Consensus boilerplate | Yes | ||
Telechat date | (None) | ||
Responsible AD | Suresh Krishnan | ||
Send notices to | "Tomek Mrugalski" <tomasz.mrugalski@gmail.com> | ||
IANA | IANA review state | IANA OK - Actions Needed |
draft-ietf-dhc-relay-port-09
Internet Engineering Task Force (IETF) A. Bierman Request for Comments: 7317 YumaWorks Category: Standards Track M. Bjorklund ISSN: 2070-1721 Tail-f Systems August 2014 A YANG Data Model for System Management Abstract This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server. This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7317. Copyright Notice Copyright (c) 2014 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. Bierman & Bjorklund Standards Track [Page 1] RFC 7317 YANG System Management August 2014 Table of Contents 1. Introduction ....................................................2 1.1. Terminology ................................................3 1.2. Tree Diagrams ..............................................3 2. Objectives ......................................................4 2.1. System Identification ......................................4 2.2. System Time Management .....................................4 2.3. User Authentication ........................................4 2.4. DNS Resolver ...............................................5 2.5. System Control .............................................5 3. System Data Model ...............................................5 3.1. System Identification ......................................5 3.2. System Time Management .....................................6 3.3. DNS Resolver Model .........................................7 3.4. RADIUS Client Model ........................................7 3.5. User Authentication Model ..................................8 3.5.1. SSH Public Key Authentication .......................8 3.5.2. Local User Password Authentication ..................9 3.5.3. RADIUS Password Authentication ......................9 3.6. System Control .............................................9 4. Relationship to the SNMPv2-MIB .................................10 5. IANA Crypt Hash YANG Module ....................................10 6. System YANG Module .............................................13 7. IANA Considerations ............................................31 8. Security Considerations ........................................31 9. References .....................................................33 9.1. Normative References ......................................33 9.2. Informative References ....................................35 1. Introduction This document defines a YANG [RFC6020] data model for the configuration and identification of some common properties within a device containing a Network Configuration Protocol (NETCONF) server. Devices that are managed by NETCONF and perhaps other mechanisms have common properties that need to be configured and monitored in a standard way. The "ietf-system" YANG module defined in this document provides the following features: o configuration and monitoring of system identification o configuration and monitoring of system time-of-day o configuration of user authentication Bierman & Bjorklund Standards Track [Page 2] RFC 7317 YANG System Management August 2014 o configuration of local users o configuration of the DNS resolver o system control operations (shutdown, restart, setting time) 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. The following terms are defined in [RFC6241] and are not redefined here: o client o configuration data o server o state data The following terms are defined in [RFC6020] and are not redefined here: o augment o data model 1.2. Tree Diagrams A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows: o Brackets "[" and "]" enclose list keys. o Abbreviations before data node names: "rw" means configuration (read-write), and "roShen & Chen Expires June 2, 2018 [Page 2] Internet-Draft DHCP Relay Source Port November 2017 network management complexities, especially given the scarceness of the IPv4 addresses. This document proposes an extension to relax the fixed UDP source port requirement for the DHCP relay agents. This extension requires a DHCP server to remember the inbound packet's UDP port number along with the IPv4/IPv6 address. The DHCP server when sending back replies MUST use the UDP port number that the incoming relay agent uses instead of the fixed DHCP port number. In the case of IPv6 cascaded relay agents [RFC3315], the upstream relay agent needs to use the "Relay Source Port Option" to record the downstream source port and it MUST use this recorded port number instead of the fixed DHCP port number when replaying the reply messages. 1.1. Requirements Language 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. Terminology Downstream Device: In the DHCP relay context, it refers to the next relay agent for forwarding Relay-reply Messages. Upstream Device: In the DHCP relay context, it refers to the next relay agent or DHCP server for forwarding Relay-forward Messages. Relay Source Port: This is the UDP port that a relay agent uses to receive Relay-forward Messages from an upstream device. Downstream Source Port: This is the UDP port that the downstream device uses when forwarding Relay-forward Messages to this relay agent device. This UDP port is to be used by this relay agent device when forwarding the Relay-reply Messages to that downstream device. Non-DHCP UDP Port: Any valid and non-zero UDP port other than port 67 for DHCPv4 and port 547 for DHCPv6. 3. Changes to DHCP Specifications 3.1. Additions to DHCPv4 in RFC 2131 Section 4.1 of RFC 2131 [RFC2131] specifies that: Shen & Chen Expires June 2, 2018 [Page 3] Internet-Draft DHCP Relay Source Port November 2017 DHCP uses UDP as its transport protocol. DHCP messages from a client to a server are sent to the 'DHCP server' port (67), and DHCP messages from a server to a client are sent to the 'DHCP client' port (68). Relay agents implementing this specification may be configured instead to use a source port number other than 67, and to receive responses on that same port. This will only work when the DHCP server or relay agent to which such a relay agent is forwarding messages is upgraded to support this extension. 3.2. Additions to DHCPv6 in RFC 3315 Section 5.2 of RFC 3315 [RFC3315] specifies that: Clients listen for DHCP messages on UDP port 546. Servers and relay agents listen for DHCP messages on UDP port 547. Relay agents implementing this specification may be configured instead to use a source port number other than 547, and to receive responses on that same port. This will only work when the DHCP server or relay agent to which such a relay agent is forwarding messages is upgraded to support this extension. 4. Relay Source Port Sub-option and Option Relay agents do not maintain state. To return a message to its source, the relay agent must include all the required information in the Relay-Forward message. When a relay in a sequence of cascaded relays does not use the standard source port, that source port must be included along with the source address. This option allows the relay agent to do so. 4.1. Source Port Sub-option for DHCPv4 The Relay Agent "Source Port Sub-option" is a new option, and it is part of the relay-agent-information option for DHCPv4 [RFC3046]. The format of the "Source Port Sub-option" is shown below: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SubOpt Code | Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: Shen & Chen Expires June 2, 2018 [Page 4] Internet-Draft DHCP Relay Source Port November 2017 SubOpt Code: SUBOPT_RELAY_PORT. 8 bit value, to be assigned by IANA. Len: 8 bit value to be set to 0. 4.2. Relay Source Port Option for DHCPv6 The "Relay Source Port Option" is a new DHCPv6 option. It MUST be used either by a DHCPv6 relay agent that uses a non-DHCP UDP port (not 547) communicating with the IPv6 server and the upstream relay agent, or by a IPv6 relay agent that detects the use of a non-DHCP UDP port (not 547) by a downstream relay agent. The format of the "Relay Source Port Option" is shown below: 0 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_RELAY_RELAY_PORT | Option-Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream Source Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: Option-Code: OPTION_RELAY_RELAY_PORT. 16 bit value, to be assigned by IANA. Option-Len: 16 bit value to be set to 2. Downstream Source Port: 16 bit value. To be set by the IPv6 relay either to the downstream relay agent's UDP source port used for the UDP packet, or to zero if only the local relay agent uses the non-DHCP UDP port (not 547). 5. Relay Agent and Server Behavior 5.1. DHCPv4 When a relay agent uses a non-DHCP UDP port (not 67) communicating with the DHCP server, it MUST include the &" means state data (read-only). o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list. Bierman & Bjorklund Standards Track [Page 3] RFC 7317 YANG System Management August 2014 o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. 2. Objectives 2.1. System Identification There are many common properties used to identify devices, operating systems, software versions, etc. that need to be supported in the system data module. These objects are defined as operational state data, and the information returned by the server is intended to be specific to the device vendor. Some user-configurable administrative strings are also provided, such as the system location and description. 2.2. System Time Management Management of the date and time used by the system needs to be supported. The use of one or more NTP servers to automatically set the system date and time needs to be possible. Utilization of the Time Zone Database [RFC6557] also needs to be supported. It should be possible to configure the system to use NTP. 2.3. User Authentication The authentication mechanism needs to support password authentication over RADIUS in order to support deployment scenarios with centralized authentication servers. Additionally, for scenarios when no centralized authentication server exists or for situations where the centralized authentication server cannot be reached from the device, local users need to be supported. Since the mandatory transport protocol for NETCONF is Secure Shell (SSH) [RFC6242], the authentication model needs to support SSH's "publickey" and "password" authentication methods [RFC4252]. The model for authentication configuration should be flexible enough to support authentication methods defined by other standards documents or by vendors. It should be possible to configure the system authentication properties. Bierman & Bjorklund Standards Track [Page 4] RFC 7317 YANG System Management August 2014 2.4. DNS Resolver The configuration of the DNS resolver within the system containing the NETCONF server is required in order to control how domain names are resolved. 2.5. System Control A few operations are needed to support common tasks such as restarting the device or setting the system date and time. 3. System Data Model 3.1. System Identification The data model for system identification has the following structure: +--rw system | +--rw contact? string | +--rw hostname? inet:domain-name | +--rw location? string +--ro system-state +--ro platform +--ro os-name? string +--ro os-release? string +--ro os-version? string +--ro machine? string Bierman & Bjorklund Standards Track [Page 5] RFC 7317 YANG System Management August 2014 3.2. System Time Management The data model for system time management has the following structure: +--rw system | +--rw clock | | +--rw (timezone)? | | +--:(timezone-name) | | | +--rw timezone-name? timezone-name | | +--:(timezone-utc-offset) | | +--rw timezone-utc-offset? int16 | +--rw ntp! | +--rw enabled? boolean | +--rw server* [name] | +--rw name string | +--rw (transport) | | +--:(udp) | | +--rw udp | | +--rw address inet:host | | +--rw port? inet:port-number | +--rw association-type? enumeration | +--rw iburst? boolean | +--rw prefer? boolean +--ro system-state +--ro clock +--ro current-datetime? yang:date-and-time +--ro boot-datetime? yang:date-and-time New "case" statements can be added in future revisions of this data model, or through augmentation by some other data model. Bierman & Bjorklund Standards Track [Page 6] RFC 7317 YANG System Management August 2014 3.3. DNS Resolver Model The data model for configuration of the DNS resolver has the following structure: +--rw system +--rw dns-resolver +--rw search* inet:domain-name +--rw server* [name] | +--rw name string | +--rw (transport) | +--:(udp-and-tcp) | +--udp-and-tcp | +--rw address inet:ip-address | +--rw port? inet:port-number +--rw options +--rw timeout? uint8 +--rw attempts? uint8 New "case" statements can be added in future revisions of this data model, or through augmentation by some other data model. 3.4. RADIUS Client Model The data model for configuration of the RADIUS client has the following structure: +--rw system +--rw radius +--rw server* [name] | +--rw name string | +--rw (transport) | | +--:(udp) | | +--rw udp | | +--rw address inet:host | | +--rw authentication-port? inet:port-number | | +--rw shared-secret string | +--rw authentication-type? identityref +--rw options +--rw timeout? uint8 +--rw attempts? uint8 New "case" statements can be added in future revisions of this data model, or through augmentation by some other data model. Bierman & Bjorklund Standards Track [Page 7] RFC 7317 YANG System Management August 2014 3.5. User Authentication Model This document defines three authentication methods for use with NETCONF: o publickey for local users over SSH o password for local users over any secure transport o password for RADIUS users over any secure transport Additional methods can be defined by other standards documents or by vendors. This document defines two optional YANG features: "local-users" and "radius-authentication", which the server advertises to indicate support for configuring local users on the device and support for using RADIUS for authentication, respectively. The authentication parameters defined in this document are primarily used to configure authentication of NETCONF users but MAY also be used by other interfaces, e.g., a command line interface or a web- based user interface. The data model for user authentication has the following structure: +--rw system +--rw authentication +--rw user-authentication-order* identityref +--rw user* [name] +--rw name string +--rw password? ianach:crypt-hash +--rw authorized-key* [name] +--rw name string +--rw algorithm string +--rw key-data binary 3.5.1. SSH Public Key Authentication If the NETCONF server advertises the "local-users" feature, configuration of local users and their SSH public keys is supported in the /system/authentication/user list. Public key authentication is requested by the SSH client. If the quot;Source Port Sub-option" in Relay-forward messages to indicate that. When an IPv4 server receives a message from a relay agent with the "Source Port Sub-option", it MUST remember the UDP source port of the Shen & Chen Expires June 2, 2018 [Page 5] Internet-Draft DHCP Relay Source Port November 2017 message and use that port number as the UDP destination port when sending the reply message to the same relay agent. 5.2. DHCPv6 The IPv6 relay agent MUST include the "Relay Source Port Option" when it uses a non-DHCP UDP port (not 547) to communicate to a DHCPv6 server or an upstream IPv6 relay agent. Also when an IPv6 relay agent detects that a downstream relay agent uses a non-DHCP UDP port in the packet, it MUST record the port number in the "Downstream Source Port" field of this option. If this option is included to indicate only the local non-DHCP UDP port usage and there is no downstream relay agent's non-DHCP UDP port usage, the field Downstream Source Port field MUST be set to zero. The IPv6 relay agent MUST include this option in the following three cases: 1) The local relay agent uses a non-DHCP UDP port (not 547). 2) the downstream relay agent uses a non-DHCP UDP port (not 547). 3) the local relay agent and the downstream relay agent both use non-DHCP UDP ports (not 547). In the first case, the value of the "Downstream Source Port" field is set to zero. In the other two cases, the value of the field is set to the UDP port number that the downstream relay agent uses. When an IPv6 server receives a Relay-forward message with the "Relay Source Port Option", it MUST copy the option when constructing the Relay-reply chain in response to the Relay-forward message. This option MUST NOT appear in any message other than a Relay-forward or Relay-reply message. Additionally, the IPv6 server MUST check and use the UDP source port from the UDP packet of the Relay-forward message in replying to the relay agent. When a relay agent receives a Relay-reply message with the "Relay Source Port Option" from a server or from an upstream relay agent, if the "Downstream Source Port" field in the option is non-zero, it MUST use this UDP port number to forward the Relay-reply message to the downstream relay agent. 5.3. Compatibility Sites that need for relay agents to specify a source port will need to install new DHCP server and DHCP relay agent software with this feature. If a site installs only DHCP relay agent software with this Shen & Chen Expires June 2, 2018 [Page 6] Internet-Draft DHCP Relay Source Port November 2017 feature, there is no possibility that the DHCP server will be able to communicate to the relay agent. 5.4. Deployment Considerations During deployment, it is advisable the operator and/or user of the new DHCP relay port implementation upgrade the DHCP server first when possible, before the relay implementations are deployed. This would ensure that the erroneous case noted in Section 5.3 is not encountered. If the upstream relay agent or server does not support this extension, this DHCP relay port feature needs to be disabled. When the DHCP relay port implementation is deployed, the default relay agent behavior should use the DHCP UDP port, it is recommended that the configuration is setup to allow for the mode of operation where a non-DHCP port can be used for the DHCP relay agents. Although if the network uses firewall to block or allow DHCP packets with both static UDP source and destination port numbers, this may no longer match the packets from new DHCP relay agent and server software with this extension. The firewall rules need to be modified only to match the DHCP server side of the UDP port number, and if necessary, IP addresses and other attributes. 6. An IPv6 Cascaded Relay Example An example of IPv6 cascaded relay agents with the "Relay Source Port Option" is shown below. (forward) (forward) (forward) Relay1 ----------> Relay2 ----------> Relay3 ----------> Server (1000) (547) (547) (reply) (reply) (reply) <---------- <---------- <---------- In the above diagram, all the IPv6 devices support this generalized UDP source port extension except for Relay3. Relay1 is the only relay agent device uses a non-DHCP UDP port (not 547). Relay2 is the upstream device of Relay1. Both Relay1 and Relay2 include the "Relay Source Port Option" in Relay-forward message. Relay1 sets the "Downstream Source Port" field in the option to zero. Relay2 notices the "Relay Source Port Option" is included in the message from Relay1, and it determines Shen & Chen Expires June 2, 2018 [Page 7] Internet-Draft DHCP Relay Source Port November 2017 that the UDP source port used by Relay1 is 1000. Relay2 will include the "Relay Source Port Option" and it sets the "Downstream Source Port" field in the option to 1000. The IPv6 server copies the "Relay Source Port Option" when replying with the Relay-reply message. When Relay2 receives the Relay-reply message with the "Relay Source Port Option", it finds the "Downstream Source Port" field has the value of 1000. Relay2 then uses this port number in the UDP packet when sending the Relay-reply message to Relay1. When Relay1 receives the Relay-reply message with the "Relay Source Port Option", it finds that the "Downstream Source Port" field has the value of zero. Relay1 then uses the normal IPv6 port 547 in the packet sending the Relay-reply message to its downstream relay agent or uses UDP port 546 to an IPv6 client. This DHCP extension works with any combination of IPv6 cascaded relay agents, as long as the relay agent which uses a non-DHCP UDP port (not 547) and its upstream relay device support this generalized UDP source port extension. Similar to the above example, now assume that Relay2 uses the UDP source port of 2000 instead of 547 as in the diagram. The Relay3 device needs to support this DHCP extension and it will set 2000 in its "Downstream Source Port" field of the option in the Relay-forward message. When DHCP server sends the DHCP Relay-reply to Relay3, Relay3 finds its own relay option has this "Downstream Source Port" with the value of 2000. Relay3 will use this UDP port when sending the Relay-reply message to Relay2. Relay2 finds its own relay option also has this "Downstream Source Port" with the value of 1000. Relay2 will use this UDP port when sending the Relay-reply message to Relay1. 7. IANA Considerations A new sub-option, DHCPv4 Relay Source Port, is defined in this document within the IPv4 Relay Agent Information Option. It needs to be assigned by IANA in the "DHCP Relay Agent Sub-Option Codes" registry, http://www.iana.org/assignments/bootp-dhcp-parameters as specified in [RFC3046]. A new option, DHCPv6 Relay Source Port, is defined in this document for DHCPv6 and it needs to be assigned by IANA for the DHCPv6 option code, in the "Option Codes" registry for DHCPv6, http://www.iana.org/assignments/dhcpv6-parameters as specified in [RFC3315]. Shen & Chen Expires June 2, 2018 [Page 8] Internet-Draft DHCP Relay Source Port November 2017 8. Security Considerations [RFC3118] and [RFC3315] described many of the threats in using DHCP. This extension does not raise addition security issues. 9. Acknowledgments The authors would like to thank Peter Arberg, Luyuan Fang, Bhanu Gopalasetty, Scott Kelly, Andre Kostur, Victor Kuarsingh, Ted Lemon, Adam Roach, Kishore Seshadri and Jackelyn Shen for their review and comments of this document. The authors would like to thank Bernie Volz for discussions that led to the definition of The Relay Source Port sub-option and DHCPv6 Relay Source Port Option. The RFC text was produced using Marshall Rose's xml2rfc tool. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc- editor.org/info/rfc2119>. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, DOI 10.17487/RFC3046, January 2001, <https://www.rfc-editor.org/info/rfc3046>. [RFC3118] Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001, <https://www.rfc-editor.org/info/rfc3118>. [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <https://www.rfc-editor.org/info/rfc3315>. Authors' Addresses Shen & Chen Expires June 2, 2018 [Page 9] Internet-Draft DHCP Relay Source Port November 2017 Naiming Shen Cisco Systems 560 McCarthy Blvd. Milpitas, CA 95035 US Email: naiming@cisco.com Enke Chen Cisco Systems 560 McCarthy Blvd. Milpitas, CA 95035 US Email: enkechen@cisco.com Shen & Chen Expires June 2, 2018 [Page 10]