idnits 2.17.1 draft-ietf-dhc-dhcpv6-unknown-msg-00.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 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 (April 24, 2013) is 4020 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 Intended status: Standards Track Tsinghua University 5 Expires: October 26, 2013 T. Lemon 6 Nominum, Inc. 7 April 24, 2013 9 Handling Unknown DHCPv6 Messages 10 draft-ietf-dhc-dhcpv6-unknown-msg-00 12 Abstract 14 Dynamic Host Configuration Protocol version 6 (DHCPv6) isn't specific 15 about handling messages with unknown types. This document describes 16 the problems and defines how a DHCPv6 function node should behave in 17 this 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 October 26, 2013. 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 . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 message with unrecognized types. This document describe 73 the problems and defines the behavior of a DHCPv6 function node in 74 this case. 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 specify how the relay agent can find 86 out it should send a message towards the server or towards the 87 client. 89 Another issue is that, there is no statement in RFC3315 about what a 90 relay agent should do when receiving message types it doesn't 91 recognize. The relay agent isn't required to relay the messages, nor 92 advised to 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 is responsible for relaying messages between the client 100 and server. The Relay-reply message is meant to be sent to the 101 client side (downlink), while the Relay-forward message and other 102 types of message are meant to be sent to the server side (uplink). A 103 relay agent should determine whether the message should be relayed 104 towards the server or the client according to message types. 106 4.1. Definition of a Valid Message 108 Section 20.1 of [RFC3315] states that: 110 "When a relay agent receives a valid message to be relayed, it 111 constructs a new Relay-forward message." 112 However it doesn't specify what a valid message is. In this 113 document, we define that a message is valid for constructing a new 114 Relay-forward message if it is not a Relay-reply message. 116 4.2. Relaying a Message towards Server 118 If the relay agent received a Relay-forward message, Section 20.1.2 119 of [RFC3315] defines the related behavior. If the relay agent 120 received messages other than Relay-forward and Relay-reply, it MUST 121 forward them as is described in Section 20.1.1 of [RFC3315]. 123 4.3. Relaying a Message towards Client 125 If the relay agent received a Relay-reply message, it MUST unpack the 126 message and forward it as is defined in Section 20.2 of [RFC3315], 127 regardless of the message type in Relay Message Option. 129 5. Client and Server Behavior Update 131 There are chances that the client or server would receive DHCPv6 132 messages with unknown types. In this case, the client or server MUST 133 discard the unrecognized messages. 135 6. Security Considerations 137 As the relay agent will forward all unknown types of DHCPv6 messages, 138 a malicious attacker can interfere with the relaying function by 139 constructing fake DHCPv6 messages with arbitrary type code. The same 140 problem may happen in current DHCPv4 and DHCPv6 practice where the 141 attacker has to construct the fake DHCP message with an known type 142 code. 144 Clients and servers that implement this specification will discard 145 unknown DHCPv6 messages. Since RFC3315 did not specify either relay, 146 client or server behavior in the presence of unknown messages, it is 147 possible that some server or client that has not been updated to 148 conform to this specification might be made vulnerable to client 149 attacks through the relay agent. 151 For this reason, we recommend that relay agents, clients and servers 152 be updated to follow this new specification. However, in most 153 deployment scenarios, it will be much easier to attack clients 154 directly than through a relay; furthermore, attacks using unknown 155 message types are already possible on the local wire. 157 So in most cases, if clients are not upgraded there should be minimal 158 additional risk; at sites where only servers and relays can be 159 upgraded, the incremental benefit of doing so most likely exceeds any 160 risk due to vulnerable clients. 162 Nothing in this update should be construed to mean that relay agents 163 may not be administratively configurable to drop messages on the 164 basis of the message type, for security reasons (e.g., in a 165 firewall). The sole purpose of requiring relay agents to relay 166 unknown messages is to ensure that when legitimate new messages are 167 defined in the protocol, relay agents, even if they were manufactured 168 prior to the definition of these new messages, will, by default, 169 succeed in relaying such messages. 171 7. IANA Considerations 173 This document does not include an IANA request. 175 8. Contributors List 177 Many thanks for Bernie Volz, Cong Liu and Yuchi Chen's contributions 178 to the draft. 180 9. Normative References 182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 183 Requirement Levels", BCP 14, RFC 2119, March 1997. 185 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 186 and M. Carney, "Dynamic Host Configuration Protocol for 187 IPv6 (DHCPv6)", RFC 3315, July 2003. 189 Authors' Addresses 191 Yong Cui 192 Tsinghua University 193 Department of Computer Science, Tsinghua University 194 Beijing 100084 195 P.R.China 197 Phone: +86-10-6260-3059 198 Email: yong@csnet1.cs.tsinghua.edu.cn 200 Qi Sun 201 Tsinghua University 202 Department of Computer Science, Tsinghua University 203 Beijing 100084 204 P.R.China 206 Phone: +86-10-6278-5822 207 Email: sunqi@csnet1.cs.tsinghua.edu.cn 209 Ted Lemon 210 Nominum, Inc. 211 2000 Seaport Blvd 212 Redwood City, CA 94063 213 USA 215 Phone: +1-650-381-6000 216 Email: mellon@nominum.com