idnits 2.17.1 draft-ietf-dhc-dhcpv6-unknown-msg-06.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 13, 2014) is 3695 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 14, 2014 Nominum, Inc. 7 March 13, 2014 9 Handling Unknown DHCPv6 Messages 10 draft-ietf-dhc-dhcpv6-unknown-msg-06 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 14, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 4.2. Relaying a Message toward Server . . . . . . . . . . . . 5 75 4.3. Relaying a Message toward Client . . . . . . . . . . . . 5 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. However, RFC 3315 102 does not explicitly describe how the relay agent can determine 103 whether it should send a message toward the server or the client, 104 although this is implied by the message definitions in RFC3315. 106 Another issue is that RFC3315 does not specify what a relay agent 107 should do if it does not recognize a received message; the relay 108 agent is not required to relay the message, nor advised to drop the 109 message. If relaying an unknown message, the relay agent is given no 110 guidance about whether to send it toward the server or the client. 112 In addition, there is no specific requirement for dealing with 113 unknown messages by the client or server in RFC3315. 115 Note it is expected that most future DHCPv6 messages will not be used 116 to communicate directly with relay agents (though they may need to be 117 relayed by relay agents). 119 4. Relay Agent Behavior Update 121 Relay agents relay messages toward servers and clients according to 122 the message type. The Relay-reply message is sent toward the client. 123 The Relay-forward message and other types of messages are sent toward 124 the server. 126 We say "toward the client" and "toward the server" because relay 127 agents may be chained together, so a relay message may be sent 128 through multiple relay agents along the path to its destination. 129 Relay-reply messages specify a destination address; the relay agent 130 extracts the encapsulated message and sends it to the specified 131 destination address. Any message other than a Relay-reply does not 132 have such a specified destination, so it follows the default 133 forwarding path configured on the relay agent, which is always toward 134 the server. 136 The sole purpose of requiring relay agents to relay unknown messages 137 is to ensure that when legitimate new messages are defined in the 138 protocol, relay agents, even if they were manufactured prior to the 139 definition of these new messages, will, by default, succeed in 140 relaying such messages. 142 4.1. A Valid Message for Constructing a New Relay-forward Message 144 Section 20.1 of [RFC3315] states that: 146 "When a relay agent receives a valid message to be relayed, it 147 constructs a new Relay-forward message." 149 It does not define which types of messages are valid for constructing 150 Relay-Forward messages. In this document, we specify the definition 151 as follows. 153 The message is valid for constructing a new Relay-forward message: 155 (a) if the message is a Relay-forward message, or 157 (b) if the relay agent receives the message for which it is not the 158 target according to the message type. 160 New DHCP message types may be defined in future that are intended to 161 convey information from DHCP servers to relay agents. Relay agents 162 that do not implement these messages will not recognize that such 163 messages are intended for them. A relay agent that implements this 164 specification will necessarily forward such messages to the DHCP 165 servers to which it is configured to relay client messages. 167 At this time, no messages of this variety have been specified. If 168 such a message is specified in the future, the specification could 169 include text something like the following: 171 DHCP servers that send this new message type MAY, when they receive 172 a relayed message of this type, mark the relay agent to which the 173 message was sent as not implementing messages of this type. In 174 this case, the DHCP server MAY implement a strategy of probing the 175 relay agent occasionally to see if it has been updated. 177 However, this is not strictly necessary, since DHCP does not provide 178 a signaling message for rejecting unexpected message types, and 179 therefore DHCP servers are not expected to respond to such messages. 181 Documents specifying new message types should use different types for 182 communicating *to* relay agents than are used for communicating 183 *from* relay agents, so that no confusion can occur where a message 184 sent to a relay agent is sent back to the DHCP server, which then 185 tries to process it as if it came from a relay agent. 187 4.2. Relaying a Message toward Server 189 If the relay agent receives a Relay-forward message, Section 20.1.2 190 of [RFC3315] defines the required behavior. If the relay agent 191 receives messages other than Relay-forward and Relay-reply and the 192 relay agent does not recognize its message type, it MUST forward them 193 as is described in Section 20.1.1 of [RFC3315]. 195 4.3. Relaying a Message toward Client 197 If the relay agent receives a Relay-reply message, it MUST process 198 the message as is defined in Section 20.2 of [RFC3315], regardless of 199 the type of the message encapsulated in the Relay Message Option. 201 5. Client and Server Behavior Update 203 A client or server MUST silently discard any received DHCPv6 message 204 with an unknown message type. 206 6. Security Considerations 208 This document creates no new security issues that are not already 209 present in RFC3315. By explicitly documenting the correct handling 210 of unknown messages, this document, if implemented, reduces any 211 security exposure that might result from incorrect handling of 212 unknown messages. The following issues are issues that could already 213 be present with section 23 of [RFC3315], but we discuss them in 214 detail here as guidance for implementors. 216 As the relay agent will forward all unknown types of DHCPv6 messages, 217 a malicious attacker can interfere with the relaying function by 218 constructing fake DHCPv6 messages with arbitrary type code. The same 219 problem may happen in current DHCPv4 and DHCPv6 practice where the 220 attacker constructs the fake DHCP message with a known type code. 222 Clients and servers that implement this specification will discard 223 unknown DHCPv6 messages. Since RFC3315 did not specify either relay 224 agent, client or server behavior in the presence of unknown messages, 225 it is possible that some servers or clients that have not been 226 updated to conform to this specification might be made vulnerable to 227 client attacks through the relay agent. 229 For this reason, we recommend that relay agents, clients and servers 230 be updated to follow this new specification. However, in most 231 deployment scenarios, it will be much easier to attack clients 232 directly than through a relay agent; furthermore, attacks using 233 unknown message types are already possible on the local wire. 235 So in most cases, if clients are not upgraded there should be minimal 236 additional risk; at sites where only servers and relay agents can be 237 upgraded, the incremental benefit of doing so most likely exceeds any 238 risk due to vulnerable clients. 240 Nothing in this update should be construed to mean that relay agents 241 may not be administratively configurable to drop messages on the 242 basis of the message type, for security reasons (e.g., in a 243 firewall). 245 7. IANA Considerations 247 This document does not include an IANA request. 249 8. Contributors List 251 Many thanks to Bernie Volz, Tomek Mrugalski, Sheng Jiang, Cong Liu 252 and Yuchi Chen for their contributions to the document. 254 9. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 260 and M. Carney, "Dynamic Host Configuration Protocol for 261 IPv6 (DHCPv6)", RFC 3315, July 2003. 263 Authors' Addresses 265 Yong Cui 266 Tsinghua University 267 Beijing 100084 268 P.R.China 270 Phone: +86-10-6260-3059 271 Email: yong@csnet1.cs.tsinghua.edu.cn 273 Qi Sun 274 Tsinghua University 275 Beijing 100084 276 P.R.China 278 Phone: +86-10-6278-5822 279 Email: sunqi@csnet1.cs.tsinghua.edu.cn 280 Ted Lemon 281 Nominum, Inc. 282 2000 Seaport Blvd 283 Redwood City, CA 94063 284 USA 286 Phone: +1-650-381-6000 287 Email: Ted.Lemon@nominum.com