idnits 2.17.1 draft-ietf-dhc-dhcpv6-unknown-msg-02.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 (September 25, 2013) is 3838 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: March 29, 2014 Nominum, Inc. 7 September 25, 2013 9 Handling Unknown DHCPv6 Messages 10 draft-ietf-dhc-dhcpv6-unknown-msg-02 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 RFC3315. 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 March 29, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 55 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Relay Agent Behavior Update . . . . . . . . . . . . . . . . . . 3 57 4.1. Definition of a Valid Message . . . . . . . . . . . . . . . 4 58 4.2. Relaying a Message towards Server . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 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 message with unrecognized types. This document describe 73 the problems and defines the behavior of a DHCPv6 function node when 74 handling unknown DHCPv6 messages. This document updates [RFC3315]. 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 4.1. Definition of a Valid Message 116 Section 20.1 of [RFC3315] states that: 118 "When a relay agent receives a valid message to be relayed, it 119 constructs a new Relay-forward message." 121 It doesn't define what a valid message is. In this document, we 122 specify the definition as follows. 124 The message is valid for constructing a new Relay-forward message: 126 (a) if the message is a Relay-forward message, or 128 (b) if a relay agent receives the message but the relay agent does 129 not identify itself as the target of the message, and the message 130 is not a Relay-reply message. 132 In the case that a new type of relay message is sent to a relay agent 133 but the relay agent doesn't recognize it, the message is put into a 134 Relay-forward message and sent to the server. Then the server knows 135 the relay agent doesn't support the new message. 137 4.2. Relaying a Message towards Server 139 If the relay agent received a Relay-forward message, Section 20.1.2 140 of [RFC3315] defines the related behavior. If the relay agent 141 received messages other than Relay-forward and Relay-reply, it MUST 142 forward them as is described in Section 20.1.1 of [RFC3315]. 144 4.3. Relaying a Message towards Client 146 If the relay agent receives a Relay-reply message, it MUST process 147 the message as is defined in Section 20.2 of [RFC3315], regardless of 148 the type of the message encapsulated in the Relay Message Option. 150 5. Client and Server Behavior Update 152 There are chances that the client or server would receive DHCPv6 153 messages with unknown types. In this case, the client or server MUST 154 discard the unrecognized messages. 156 6. Security Considerations 157 As the relay agent will forward all unknown types of DHCPv6 messages, 158 a malicious attacker can interfere with the relaying function by 159 constructing fake DHCPv6 messages with arbitrary type code. The same 160 problem may happen in current DHCPv4 and DHCPv6 practice where the 161 attacker has to construct the fake DHCP message with an known type 162 code. 164 Clients and servers that implement this specification will discard 165 unknown DHCPv6 messages. Since RFC3315 did not specify either relay, 166 client or server behavior in the presence of unknown messages, it is 167 possible that some servers or clients that have not been updated to 168 conform to this specification might be made vulnerable to client 169 attacks through the relay agent. 171 For this reason, we recommend that relay agents, clients and servers 172 be updated to follow this new specification. However, in most 173 deployment scenarios, it will be much easier to attack clients 174 directly than through a relay; furthermore, attacks using unknown 175 message types are already possible on the local wire. 177 So in most cases, if clients are not upgraded there should be minimal 178 additional risk; at sites where only servers and relays can be 179 upgraded, the incremental benefit of doing so most likely exceeds any 180 risk due to vulnerable clients. 182 Nothing in this update should be construed to mean that relay agents 183 may not be administratively configurable to drop messages on the 184 basis of the message type, for security reasons (e.g., in a 185 firewall). The sole purpose of requiring relay agents to relay 186 unknown messages is to ensure that when legitimate new messages are 187 defined in the protocol, relay agents, even if they were manufactured 188 prior to the definition of these new messages, will, by default, 189 succeed in relaying such messages. 191 7. IANA Considerations 193 This document does not include an IANA request. 195 8. Contributors List 197 Many thanks for Bernie Volz, Cong Liu and Yuchi Chen's contributions 198 to the draft. 200 9. Normative References 202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", BCP 14, RFC 2119, March 1997. 205 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 206 and M. Carney, "Dynamic Host Configuration Protocol for 207 IPv6 (DHCPv6)", RFC 3315, July 2003. 209 Authors' Addresses 211 Yong Cui 212 Tsinghua University 213 Department of Computer Science, Tsinghua University 214 Beijing 100084 215 P.R.China 217 Phone: +86-10-6260-3059 218 Email: yong@csnet1.cs.tsinghua.edu.cn 220 Qi Sun 221 Tsinghua University 222 Department of Computer Science, 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: mellon@nominum.com