idnits 2.17.1 draft-ietf-dhc-dhcpv6-unknown-msg-03.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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document updates RFC3315, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 12, 2013) is 3819 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 (~~), 2 warnings (==), 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: RFC3315 (if approved) Tsinghua University 5 Intended status: Standards Track T. Lemon 6 Expires: May 16, 2014 Nominum, Inc. 7 November 12, 2013 9 Handling Unknown DHCPv6 Messages 10 draft-ietf-dhc-dhcpv6-unknown-msg-03 12 Abstract 14 Dynamic Host Configuration Protocol version 6 (DHCPv6) isn't specific 15 about handling messages with unknown types. This memo describes the 16 problems and defines how a DHCPv6 function node should behave in this 17 case. This document updates RFC 3315. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 16, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 55 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 56 4. Relay Agent Behavior Update . . . . . . . . . . . . . . . . . 2 57 4.1. Definition of a Valid Message . . . . . . . . . . . . . . 3 58 4.2. Relaying a Message towards Server . . . . . . . . . . . . 3 59 4.3. Relaying a Message towards Client . . . . . . . . . . . . 4 60 5. Client and Server Behavior Update . . . . . . . . . . . . . . 4 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 8. Contributors List . . . . . . . . . . . . . . . . . . . . . . 5 64 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 Dynamic Host Configuration Protocol version 6 (DHCPv6) [RFC3315] 70 provides a framework for conveying IPv6 configuration information to 71 hosts on a TCP/IP network. But [RFC3315] is not specific about how 72 to deal with messages with unrecognized types. This document 73 describes the problems and defines the behavior of a DHCPv6 function 74 node when handling unknown DHCPv6 messages. 76 2. Requirements Language 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 3. Problem Statement 84 The relay agent is bound to send a message either to the server or to 85 the client. But RFC3315 doesn't explicitly describe how the relay 86 agent can find out it should send a message towards the server or 87 towards the client. 89 Another issue is that, it's not specific in RFC3315 about what a 90 relay agent should do if it doesn't recognize the received messages. 91 The relay agent isn't required to relay the messages, nor advised to 92 drop them. 94 In addition, there is no specific requirement of the client or server 95 on dealing with an unknown message in RFC3315. 97 4. Relay Agent Behavior Update 99 A relay agent relays the message towards the server or the client 100 according to the message type. Relay-reply messages are sent toward 101 the client. The Relay-forward message and other types of message are 102 sent toward the server. 104 We say "toward the client" and "toward the server" because relay 105 agents may be chained together, so a relay message may be sent 106 through multiple relays along the path to its destination. Relay- 107 reply messages specify a destination address; the relay agent 108 extracts the encapsulated message and sends it to the specified 109 destination address. Any message other than a Relay-reply does not 110 have such a specified destination, so it follows the default 111 forwarding path configured on the relay agent, which is always toward 112 the server. 114 The sole purpose of requiring relay agents to relay unknown messages 115 is to ensure that when legitimate new messages are defined in the 116 protocol, relay agents, even if they were manufactured prior to the 117 definition of these new messages, will, by default, succeed in 118 relaying such messages. 120 4.1. Definition of a Valid Message 122 Section 20.1 of [RFC3315] states that: 124 "When a relay agent receives a valid message to be relayed, it 125 constructs a new Relay-forward message." 127 It doesn't define what a valid message is. In this document, we 128 specify the definition as follows. 130 The message is valid for constructing a new Relay-forward message: 132 (a) if the message is a Relay-forward message, or 134 (b) if a relay agent receives the message but the relay agent does 135 not identify itself as the target of the message, and the message 136 is not a Relay-reply message. 138 In the case that a new type of relay message is sent to a relay agent 139 but the relay agent doesn't recognize it, the message is put into a 140 Relay-forward message and sent to the server. Then the server knows 141 the relay agent doesn't support the new message. 143 4.2. Relaying a Message towards Server 144 If the relay agent received a Relay-forward message, Section 20.1.2 145 of [RFC3315] defines the related behavior. If the relay agent 146 received messages other than Relay-forward and Relay-reply, it MUST 147 forward them as is described in Section 20.1.1 of [RFC3315]. 149 4.3. Relaying a Message towards Client 151 If the relay agent receives a Relay-reply message, it MUST process 152 the message as is defined in Section 20.2 of [RFC3315], regardless of 153 the type of the message encapsulated in the Relay Message Option. 155 5. Client and Server Behavior Update 157 There are chances that the client or server would receive DHCPv6 158 messages with unknown types. In this case, the client or server MUST 159 discard the unrecognized messages. 161 6. Security Considerations 163 As the relay agent will forward all unknown types of DHCPv6 messages, 164 a malicious attacker can interfere with the relaying function by 165 constructing fake DHCPv6 messages with arbitrary type code. The same 166 problem may happen in current DHCPv4 and DHCPv6 practice where the 167 attacker has to construct the fake DHCP message with an known type 168 code. 170 Clients and servers that implement this specification will discard 171 unknown DHCPv6 messages. Since RFC3315 did not specify either relay, 172 client or server behavior in the presence of unknown messages, it is 173 possible that some servers or clients that have not been updated to 174 conform to this specification might be made vulnerable to client 175 attacks through the relay agent. 177 For this reason, we recommend that relay agents, clients and servers 178 be updated to follow this new specification. However, in most 179 deployment scenarios, it will be much easier to attack clients 180 directly than through a relay; furthermore, attacks using unknown 181 message types are already possible on the local wire. 183 So in most cases, if clients are not upgraded there should be minimal 184 additional risk; at sites where only servers and relays can be 185 upgraded, the incremental benefit of doing so most likely exceeds any 186 risk due to vulnerable clients. 188 Nothing in this update should be construed to mean that relay agents 189 may not be administratively configurable to drop messages on the 190 basis of the message type, for security reasons (e.g., in a 191 firewall). 193 7. IANA Considerations 195 This document does not include an IANA request. 197 8. Contributors List 199 Many thanks to Bernie Volz, Cong Liu and Yuchi Chen for their 200 contributions to the document. 202 9. Normative References 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, March 1997. 207 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 208 and M. Carney, "Dynamic Host Configuration Protocol for 209 IPv6 (DHCPv6)", RFC 3315, July 2003. 211 Authors' Addresses 213 Yong Cui 214 Tsinghua University 215 Beijing 100084 216 P.R.China 218 Phone: +86-10-6260-3059 219 Email: yong@csnet1.cs.tsinghua.edu.cn 221 Qi Sun 222 Tsinghua University 223 Beijing 100084 224 P.R.China 226 Phone: +86-10-6278-5822 227 Email: sunqi@csnet1.cs.tsinghua.edu.cn 229 Ted Lemon 230 Nominum, Inc. 231 2000 Seaport Blvd 232 Redwood City, CA 94063 233 USA 235 Phone: +1-650-381-6000 236 Email: Ted.Lemon@nominum.com