idnits 2.17.1 draft-ietf-dhc-relay-id-suboption-13.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 19, 2013) is 4046 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBA' is mentioned on line 298, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC B. Joshi 3 Internet-Draft D. Ramakrishna Rao 4 Intended status: Standards Track Infosys Ltd. 5 Expires: August 23, 2013 M. Stapp 6 Cisco Systems, Inc. 7 February 19, 2013 9 The DHCPv4 Relay Agent Identifier Suboption 10 draft-ietf-dhc-relay-id-suboption-13.txt 12 Abstract 14 This document defines a new Relay Agent Identifier suboption for the 15 Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information 16 option. The suboption carries a value that uniquely identifies the 17 relay agent device within the administrative domain. The value is 18 normally administratively-configured in the relay agent. The 19 suboption allows a DHCP relay agent to include the identifier in the 20 DHCP messages it sends. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 23, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Example Use-Cases . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Bulk Leasequery . . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Industrial Ethernet . . . . . . . . . . . . . . . . . . . . 3 61 4. Suboption Format . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Identifier Stability . . . . . . . . . . . . . . . . . . . . . 4 63 5.1. Identifier Uniqueness . . . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 65 6.1. Forged Relay ID attacks . . . . . . . . . . . . . . . . . . 6 66 6.2. Factory Floor Scenario . . . . . . . . . . . . . . . . . . 7 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) [RFC2131] 77 provides IP addresses and configuration information for IPv4 clients. 78 It includes a relay agent capability, in which network elements 79 receive broadcast messages from clients and forward them to DHCP 80 servers as unicast messages. In many network environments, relay 81 agents add information to the DHCP messages before forwarding them, 82 using the Relay Agent Information option [RFC3046]. Servers that 83 recognize the relay agent information option echo it back in their 84 replies. 86 This specification introduces a Relay Agent Identifier (Relay-Id) 87 suboption for the Relay Agent Information option. The Relay-Id 88 suboption carries a sequence of octets that is intended to uniquely 89 identify the relay agent within the administrative domain. In this 90 document, an administrative domain consist of all DHCP servers and 91 relay agents that communicate with each other. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 DHCPv4 terminology is defined in [RFC2131], and the DHCPv4 Relay 100 Agent Information Option in [RFC3046]. 102 3. Example Use-Cases 104 3.1. Bulk Leasequery 106 There has been quite a bit of recent interest in extending the DHCP 107 Leasequery protocol [RFC4388] to accommodate some additional 108 situations. There is a recent document 109 [I-D.ietf-dhc-dhcpv4-bulk-leasequery] proposing a variety of 110 enhancements to the existing Leasequery protocol. The document 111 describes a use-case where a relay agent queries DHCP servers using 112 the Relay Identifier to retrieve all the leases allocated through the 113 relay agent. 115 3.2. Industrial Ethernet 117 DHCP typically identifies clients based on information in their DHCP 118 messages - such as the Client-Identifier option, or the value of the 119 chaddr field. In some networks, however, the location of a client - 120 its point of attachment to the network - is a more useful identifier. 121 In factory-floor networks (commonly called 'Industrial' networks), 122 for example, the role a device plays is often fixed and based on its 123 location. Using manual address configuration is possible (and is 124 common) but it would be beneficial if DHCP configuration could be 125 applied to these networks. 127 One way to provide connection-based identifiers for industrial 128 networks is to have the network elements acting as DHCP relay agents 129 supply information that a DHCP server could use as a client 130 identifier. A straightforward way to form identifier information is 131 to combine something that is unique within the scope of the network 132 element, such as a port/slot value, with something that uniquely 133 identifies that network element, such as a Relay Agent Identifier. 135 4. Suboption Format 137 Format of the Relay Agent Identifier suboption: 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 |SUBOPT_RELAY_ID| length | | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 144 . . 145 . identifier (variable) . 146 . . 147 +---------------------------------------------------------------+ 149 Where: 151 SUBOPT_RELAY_ID [TBA] 153 length the number of octets in the suboption 154 (excluding the suboption ID and length fields); 155 the minimum length is one. 157 identifier the identifying data. 159 5. Identifier Stability 161 If the relay identifier is to be meaningful it has to be stable. A 162 relay agent SHOULD use a single identifier value consistently. The 163 identifier used by a relay device SHOULD be committed to stable 164 storage, unless the relay device can regenerate the value upon 165 reboot. 167 If the relay-id configured in a relay agent is not unique within its 168 administrative domain, resource allocation problems may occur as the 169 DHCP server attempts to allocate the same resource to devices behind 170 two different relay agents. Therefore, relay-id configured in a 171 relay agent MUST be unique within its administrative domain. To aid 172 in ensuring uniqueness of relay-ids, relay agents SHOULD make their 173 relay identifiers visible to their administrators via their user 174 interface, through a log entry, through a MIB field, or through some 175 other mechanism. 177 Implementors of relay agents should note that the identifier needs to 178 be present in all DHCP message types where its value is being used by 179 the DHCP server. The relay agent may not be able to add the Relay 180 Agent Information option to all messages - such as RENEW messages 181 sent as IP unicasts. In some deployments that might mean that the 182 server has to be willing to continue to associate the relay 183 identifier it has last seen with a lease that is being RENEWed. 184 Other deployments may prefer to use the Server Identifier Override 185 suboption [RFC5107] to permit the relay device to insert the Relay 186 Agent Information option into all relayed messages. 188 Handling situations where a relay agent device is replaced is another 189 aspect of stability. One of the use-cases for the relay identifier 190 is to permit a server to associate clients' lease bindings with the 191 relay device connected to the clients. If the relay device is 192 replaced, because it has failed or been upgraded, it may be desirable 193 for the new device to continue to provide the same relay identifier 194 as the old device. Therefore if a relay agent supports relay-id, the 195 relay-id should be administratively configurable. 197 5.1. Identifier Uniqueness 199 Administrators should take special care to ensure that relay-ids 200 configured in their relay agents are not duplicated. There are a 201 number of strategies that may be used to achieve this. 203 Administrators may use a strategy to configure unique relay-ids. One 204 such strategy is that a relay-id on a relay agent may re-use an 205 existing identifier or set of identifiers that are already guaranteed 206 to be unique (e.g., UUID [RFC4122]). 208 For administrators who are already using a provisioning system to 209 manage their networking infrastructure, it may work to enumerate 210 relay agents on the basis of roles, and then as a second step, assign 211 those roles to specific relay agents or groups of relay agents. In 212 such a scenario, when a replacement relay agent is first seen by the 213 DHCP server, this could trigger a configuration event on the 214 provisioning system, and the new relay agent could be assigned to the 215 role of the relay agent it is replacing. 217 In some cases it may be that the DHCP server has configurable event 218 notification, and that a duplicate relay-id would cause some event 219 that could trigger a notification, and that would never happen in any 220 other case. In this scenario, administrators should take advantage 221 of this feature. This is not a perfect solution, because it will not 222 work until such an event occurs. 224 A network management/provisioning system may also be able to collect 225 a full list of all relay agents on the network. It may then notice 226 that more than one device reports the same relay-id. In such a case, 227 the provisioning system could notify the administrator of the fault, 228 which could then be corrected. 230 This is not an exhaustive list of strategies. We suggest an 231 additional strategy in the security considerations section; 232 administrators are also encouraged to consider the specifics of their 233 own network configuration to see if there is some way to detect 234 duplicate relay-ids other than the ones listed here, if none of these 235 will work. 237 6. Security Considerations 239 6.1. Forged Relay ID attacks 241 Security issues with the Relay Agent Information option and its use 242 by servers in address assignment are discussed in [RFC3046] and 243 [RFC4030]. The DHCP Relay Agent Information option depends on a 244 trusted relationship between the DHCP relay agent and the DHCP 245 server, as described in Section 5 of RFC 3046. While the 246 introduction of fraudulent DHCP relay agent information options can 247 be prevented by a perimeter defense that blocks these options unless 248 the DHCP relay agent is trusted, a deeper defense using the 249 authentication suboption for DHCP relay agent information option 250 [RFC4030] SHOULD be deployed as well. It also helps in avoiding 251 duplication of relay identifiers by malicious entities. However, 252 implementation of authentication suboption for DHCP relay agent 253 information option [RFC4030] is not a must to support relay-id 254 suboption. 256 6.2. Factory Floor Scenario 258 One possible use case for the relay-id suboption is the automated 259 configuration of machines on a factory floor. In this situation, 260 various sections of the factory floor might be on their own network 261 links, with a relay agent interposed between those links and the DHCP 262 server. The relay-id of each relay agent might cause special 263 configurations to be downloaded to those devices to control their 264 behavior. 266 If a relay agent was deployed on the factory floor in such a 267 situation, with an incorrect relay-id, there is the potential that 268 devices could be misconfigured in a way that could produce incorrect 269 results, cause physical damage, or even create hazardous conditions 270 for workers. 272 In deployment scenarios like this one, administrators must use some 273 dependable technique to ensure that such misconfigurations do not 274 occur. It is beyond the scope of this document to provide a complete 275 list of such techniques. 277 However, as an example, a relay agent device intended for use in such 278 a scenario could require the use of a hardware token that contains 279 the relay-id, that is physically attached to the installation 280 location of the relay agent device, and that can be connected to and 281 disconnected from the relay agent device without the use of special 282 tools. Such a relay agent device should not be operable when this 283 hardware token is not connected to it: either it should fail because 284 it presents an unknown identifier to the DHCP server, or it should 285 simply refuse to relay DHCP packets until the token is connected to 286 it. 288 A relay agent device that does not provide a clear mitigation 289 strategy for a scenario where misconfiguration could have damaging or 290 hazardous consequences should not be deployed in such a scenario. 292 7. IANA Considerations 294 We request that IANA assign a new suboption code from the registry of 295 DHCP Agent Sub-Option Codes maintained in 296 http://www.iana.org/assignments/bootp-dhcp-parameters. 298 Relay Agent Identifier Suboption [TBA] 300 8. Acknowledgments 302 Thanks to Bernie Volz, David W. Hankins, Pavan Kurapati and Ted Lemon 303 for providing valuable suggestions. 305 9. References 307 9.1. Normative References 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 312 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 313 RFC 2131, March 1997. 315 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 316 RFC 3046, January 2001. 318 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 319 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 320 Option", RFC 4030, March 2005. 322 9.2. Informative References 324 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 325 Unique IDentifier (UUID) URN Namespace", RFC 4122, 326 July 2005. 328 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 329 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 331 [RFC5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 332 "DHCP Server Identifier Override Suboption", RFC 5107, 333 February 2008. 335 [I-D.ietf-dhc-dhcpv4-bulk-leasequery] 336 Kinnear, K., Stapp, M., Joshi, B., and N. Russell, "Bulk 337 DHCPv4 Lease Query", 338 draft-ietf-dhc-dhcpv4-bulk-leasequery-07 (work in 339 progress), October 2012. 341 Authors' Addresses 343 Bharat Joshi 344 Infosys Ltd. 345 44 Electronics City, Hosur Road 346 Bangalore 560 100 347 India 349 Email: bharat_joshi@infosys.com 350 URI: http://www.infosys.com/ 352 D.T.V Ramakrishna Rao 353 Infosys Ltd. 354 44 Electronics City, Hosur Road 355 Bangalore 560 100 356 India 358 Email: ramakrishnadtv@infosys.com 359 URI: http://www.infosys.com/ 361 Mark Stapp 362 Cisco Systems, Inc. 363 1414 Massachusetts Ave. 364 Boxborough, MA 01719 365 USA 367 Phone: +1 978 936 0000 368 Email: mjs@cisco.com