idnits 2.17.1 draft-csl-dhc-dhcpv6-unknown-msg-3315update-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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 102: '...orward or Relay-reply, it MUST forward...' RFC 2119 keyword, line 107: '...elay-reply message, it MUST unpack the...' RFC 2119 keyword, line 113: '...n this case, the client or server MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2013) is 4049 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Cui 3 Internet-Draft Q. Sun 4 Intended status: Standards Track Tsinghua University 5 Expires: September 27, 2013 T. Lemon 6 Nominum, Inc. 7 March 26, 2013 9 Handling Unknown DHCPv6 Messages 10 draft-csl-dhc-dhcpv6-unknown-msg-3315update-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. 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 September 27, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Relay Agent Behavior Update . . . . . . . . . . . . . . . . . 2 56 3.1. Relaying a Message towards Server . . . . . . . . . . . . 3 57 3.2. Relaying a Message towards Client . . . . . . . . . . . . 3 58 4. Client and Server Behavior Update . . . . . . . . . . . . . . 3 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 61 7. Contributors List . . . . . . . . . . . . . . . . . . . . . . 4 62 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 65 1. Introduction 67 Dynamic Host Configuration Protocol version 6 (DHCPv6) [RFC3315] 68 provides a framework for conveying IPv6 configuration information to 69 hosts on a TCP/IP network. But RFC 3315 is not specific about how to 70 deal with message with unrecognized types. This document describe 71 the problems and defines the behavior of a DHCPv6 function node in 72 this case. 74 2. Problem Statement 76 The relay agent is bound to send a message to either the server or 77 the client. But RFC 3315 doesn't specify how the relay agent can 78 find out that it should send a message towards the server or towards 79 the client. 81 Another issue is that, there is no statement in RFC 3315 about the 82 case that what a relay agent should do if it receives message types 83 it doesn't recognize. RFC 3315 doesn't require it to relay the 84 messages, nor advise it to drop them. 86 In addition, there is no specific requirement of the client or server 87 on dealing with an unknown message in RFC 3315. 89 3. Relay Agent Behavior Update 91 A relay agent is responsible for relaying messages between the client 92 and server. The Relay-reply message is meant for the client 93 (downlink), while the Relay-forward message and other types of 94 message is meant for the server (uplink). A relay agent should 95 leverage the information to determine whether it should relay the 96 message towards the server or the client. 98 3.1. Relaying a Message towards Server 100 If the relay agent received a Relay-forward, Section 20.1.2 of 101 [RFC3315] defines the related behavior. If the relay agent received 102 messages other than Relay-forward or Relay-reply, it MUST forward 103 them as is described in Section 20.1.1 of [RFC3315]. 105 3.2. Relaying a Message towards Client 107 If the relay agent received a Relay-reply message, it MUST unpack the 108 message and forward it as is defined in Section 20.2 of [RFC3315]. 110 4. Client and Server Behavior Update 112 There are chances that the client or server would receive DHCPv6 113 messages with unknown types. In this case, the client or server MUST 114 discard the unrecognized messages. 116 5. Security Considerations 118 As the relay agent will forward all unknown types of DHCPv6 messages, 119 a malicious attacker can interference with the relaying function by 120 inject fake DHCPv6 messages with arbitrary type code. But this is 121 the same problem happens in current DHCPv4 and DHCPv6 practice where 122 the attacker has to construct the fake DHCP message with an known 123 type code. 125 Clients and servers that implement this specification will discard 126 unknown DHCPv6 messages. Since RFC3315 did not specify either relay, 127 client or server behavior in the presence of unknown messages, it is 128 possible that some server or client that has not been updated to 129 conform to this specification might be made vulnerable to client 130 attacks through the relay agent. 132 For this reason, we recommend that relay agents, clients and servers 133 be updated to follow this new specification. However, in most 134 deployment scenarios, it will be much easier to attack clients 135 directly than through a relay; furthermore, attacks using unknown 136 message types are already possible on the local wire, yet no known 137 vulnerabilities exist. 139 So in most cases, if clients are not upgraded there should be minimal 140 additional risk; at sites where only servers and relays can be 141 upgraded, the incremental benefit of doing so most likely exceeds any 142 risk due to vulnerable clients. 144 6. IANA Considerations 145 This document does not include an IANA request. 147 7. Contributors List 149 Many thanks for Cong Liu and Yuchi Chen's contribution to the draft. 151 8. Normative References 153 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 154 and M. Carney, "Dynamic Host Configuration Protocol for 155 IPv6 (DHCPv6)", RFC 3315, July 2003. 157 Authors' Addresses 159 Yong Cui 160 Tsinghua University 161 Department of Computer Science, Tsinghua University 162 Beijing 100084 163 P.R.China 165 Phone: +86-10-6260-3059 166 Email: yong@csnet1.cs.tsinghua.edu.cn 168 Qi Sun 169 Tsinghua University 170 Department of Computer Science, Tsinghua University 171 Beijing 100084 172 P.R.China 174 Phone: +86-10-6278-5822 175 Email: sunqi@csnet1.cs.tsinghua.edu.cn 177 Ted Lemon 178 Nominum, Inc. 179 2000 Seaport Blvd 180 Redwood City, CA 94063 181 USA 183 Phone: +1-650-381-6000 184 Email: mellon@nominum.com