idnits 2.17.1 draft-ietf-dhc-dhcpv6-unknown-msg-08.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 (Using the creation date from RFC3315, updated by this document, for RFC5378 checks: 1995-02-03) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 27, 2014) is 3682 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Y. Cui 3 Internet-Draft Q. Sun 4 Updates: 3315 (if approved) Tsinghua University 5 Intended status: Standards Track T. Lemon 6 Expires: September 28, 2014 Nominum, Inc. 7 March 27, 2014 9 Handling Unknown DHCPv6 Messages 10 draft-ietf-dhc-dhcpv6-unknown-msg-08 12 Abstract 14 DHCPv6 is not specific about handling messages with unknown types. 15 This memo describes the problems and defines how a DHCPv6 server, 16 client or relay agent should behave when receiving unknown DHCPv6 17 messages. This document also provides advice for authors of future 18 documents defining new messages sent from DHCP servers to DHCP relay 19 agents, and should be read by potential authors of such documents. 20 This document updates RFC3315. 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 September 28, 2014. 39 Copyright Notice 41 Copyright (c) 2014 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 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 70 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 71 4. Relay Agent Behavior Update . . . . . . . . . . . . . . . . . 3 72 4.1. A Valid Message for Constructing a New Relay-forward 73 Message . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 4.2. Relaying a Message toward Server . . . . . . . . . . . . 4 75 4.3. Relaying a Message toward Client . . . . . . . . . . . . 4 76 5. Client and Server Behavior Update . . . . . . . . . . . . . . 5 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 79 8. Contributors List . . . . . . . . . . . . . . . . . . . . . . 6 80 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 83 1. Introduction 85 DHCPv6 [RFC3315] provides a framework for conveying IPv6 86 configuration information to hosts on a TCP/IP network. But 87 [RFC3315] is not specific about how to deal with messages with 88 unrecognized types. This document describes the problems and defines 89 the behavior of a DHCPv6 server, client or relay agent when handling 90 unknown DHCPv6 messages. 92 2. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Problem Statement 100 When a relay agent receives a message, it decides to send the message 101 either toward the server or toward the client. It decides on the 102 direction to forward based on the message type. Since RFC3315 was 103 published new message types have been defined. More such messages 104 may be defined in the future. RFC3315 does not specify the what to 105 do when a DHCP agent does not recognize the type of message it has 106 received. This may lead to relay agents inappropriately dropping 107 such messages, and to other DHCP agents inappropriately processing 108 such messages. 110 In addition, there is no specific requirement for dealing with 111 unknown messages by the client or server in RFC3315. 113 Note it is expected that most future DHCPv6 messages will not be used 114 to communicate directly with relay agents (though they may need to be 115 relayed by relay agents). 117 4. Relay Agent Behavior Update 119 Relay agents relay messages toward servers and clients according to 120 the message type. The Relay-reply message is sent toward the client. 121 The Relay-forward message and other types of messages are sent toward 122 the server. 124 We say "toward the client" and "toward the server" because relay 125 agents may be chained together, so a relay message may be sent 126 through multiple relay agents along the path to its destination. 127 Relay-reply messages specify a destination address; the relay agent 128 extracts the encapsulated message and sends it to the specified 129 destination address. Any message other than a Relay-reply does not 130 have such a specified destination, so it follows the default 131 forwarding path configured on the relay agent, which is always toward 132 the server. 134 The sole purpose of requiring relay agents to relay unknown messages 135 is to ensure that when legitimate new messages are defined in the 136 protocol, relay agents, even if they were manufactured prior to the 137 definition of these new messages, will, by default, succeed in 138 relaying such messages. 140 4.1. A Valid Message for Constructing a New Relay-forward Message 142 Section 20.1 of [RFC3315] states that: 144 "When a relay agent receives a valid message to be relayed, it 145 constructs a new Relay-forward message." 147 It does not define which types of messages are valid for constructing 148 Relay-Forward messages. In this document, we specify the definition 149 as follows. 151 The message is valid for constructing a new Relay-forward message: 153 (a) if the message is a Relay-forward message, or 155 (b) if the relay agent recognizes the message type and is not the 156 intended target, or 158 (c) if the relay agent does not recognize the message type. 160 New DHCP message types may be defined in future that are sent, 161 unsolicited, to relay agents. Relay agents that do not implement 162 these messages will not recognize such messages as being intended for 163 them. A relay agent that implements this specification will 164 therefore forward such messages to the DHCP servers to which it is 165 configured to relay client messages. 167 At this time, no such message types have been specified. If such a 168 message is specified in the future, it is possible that this would 169 result in needless load on DHCP servers. If such a message type is 170 defined in a future specification, authors may need to consider some 171 strategy for identifying non-conforming relays and not sending such 172 messages to them. 174 However, since DHCP servers do not respond to unknown messages, this 175 is unlikely to create significant load, and therefore is likely to be 176 unnecessary. 178 4.2. Relaying a Message toward Server 180 If the relay agent receives a Relay-forward message, Section 20.1.2 181 of [RFC3315] defines the required behavior. If the relay agent 182 receives messages other than Relay-forward and Relay-reply and the 183 relay agent does not recognize its message type, it MUST forward them 184 as is described in Section 20.1.1 of [RFC3315]. 186 4.3. Relaying a Message toward Client 188 If the relay agent receives a Relay-reply message, it MUST process 189 the message as is defined in Section 20.2 of [RFC3315], regardless of 190 the type of the message encapsulated in the Relay Message Option. 192 5. Client and Server Behavior Update 194 A client or server MUST silently discard any received DHCPv6 message 195 with an unknown message type. 197 6. Security Considerations 199 This document creates no new security issues that are not already 200 present in RFC3315. By explicitly documenting the correct handling 201 of unknown messages, this document, if implemented, reduces any 202 security exposure that might result from incorrect handling of 203 unknown messages. The following issues are issues that could already 204 be present with section 23 of [RFC3315], but we discuss them in 205 detail here as guidance for implementors. 207 As the relay agent will forward all unknown types of DHCPv6 messages, 208 a malicious attacker can interfere with the relaying function by 209 constructing fake DHCPv6 messages with arbitrary type code. The same 210 problem may happen in current DHCPv4 and DHCPv6 practice where the 211 attacker constructs the fake DHCP message with a known type code. 213 Clients and servers that implement this specification will discard 214 unknown DHCPv6 messages. Since RFC3315 did not specify either relay 215 agent, client or server behavior in the presence of unknown messages, 216 it is possible that some servers or clients that have not been 217 updated to conform to this specification might be made vulnerable to 218 client attacks through the relay agent. 220 For this reason, we recommend that relay agents, clients and servers 221 be updated to follow this new specification. However, in most 222 deployment scenarios, it will be much easier to attack clients 223 directly than through a relay agent; furthermore, attacks using 224 unknown message types are already possible on the local wire. 226 So in most cases, if clients are not upgraded there should be minimal 227 additional risk; at sites where only servers and relay agents can be 228 upgraded, the incremental benefit of doing so most likely exceeds any 229 risk due to vulnerable clients. 231 Nothing in this update should be construed to mean that relay agents 232 may not be administratively configurable to drop messages on the 233 basis of the message type, for security reasons (e.g., in a 234 firewall). 236 7. IANA Considerations 238 This document does not include an IANA request. 240 8. Contributors List 242 Many thanks to Bernie Volz, Tomek Mrugalski, Sheng Jiang, Cong Liu 243 and Yuchi Chen for their contributions to the document. 245 9. Normative References 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, March 1997. 250 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 251 and M. Carney, "Dynamic Host Configuration Protocol for 252 IPv6 (DHCPv6)", RFC 3315, July 2003. 254 Authors' Addresses 256 Yong Cui 257 Tsinghua University 258 Beijing 100084 259 P.R.China 261 Phone: +86-10-6260-3059 262 Email: yong@csnet1.cs.tsinghua.edu.cn 264 Qi Sun 265 Tsinghua University 266 Beijing 100084 267 P.R.China 269 Phone: +86-10-6278-5822 270 Email: sunqi@csnet1.cs.tsinghua.edu.cn 272 Ted Lemon 273 Nominum, Inc. 274 2000 Seaport Blvd 275 Redwood City, CA 94063 276 USA 278 Phone: +1-650-381-6000 279 Email: Ted.Lemon@nominum.com