idnits 2.17.1 draft-jiang-6man-cga-sec-option-01.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 -- The document date (January 14, 2015) is 3383 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 informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Jiang 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Standards Track D. Zhang 5 Expires: July 18, 2015 Alibaba Co., Ltd 6 S. Krishnan 7 Ericsson 8 January 14, 2015 10 CGA SEC Option for Secure Neighbor Discovery Protocol 11 draft-jiang-6man-cga-sec-option-01 13 Abstract 15 A Cryptographically Generated Address is an IPv6 addresses binding 16 with a public/private key pair. It is a vital component of Secure 17 Neighbor Discovery (SeND) protocol. The current SeND specifications 18 are lack of procedures to specify the Sec bits. A new SEC option is 19 defined accordingly to address this issue. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 18, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 57 3. CGA SEC Option . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 3 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 8.2. Informative References . . . . . . . . . . . . . . . . . 4 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 67 1. Introduction 69 Cryptographically Generated Addresses (CGA, [RFC3972]) are used to 70 make sure that the sender of a Neighbor Discovery message is the 71 "owner" of the claimed address. Although it is not mandatory, it is 72 a vital component of Secure Neighbor Discovery (SeND, [RFC3971]) 73 protocol. After CGA has been defined, as an independent security 74 property, many other CGA usages have been proposed and defined, such 75 as Enhanced Route Optimization for Mobile IPv6 [RFC4866], Site 76 Multihoming by IPv6 Intermediation (SHIM6) [RFC5533], etc. 78 SEC bits are an important parameter in the generation of CGAs. 79 Particularly, SEC values are used to artificially introduce 80 additional difficulty in the CGA generation process in order to 81 provide additional protection against brute force attacks. 82 Therefore, in different environments, host may be required to use 83 different SEC bits in the generation of their CGAs. However, the 84 base SeND protocol fails to distribute the SEC values to the hosts. 85 As a result, the network administration cannot propagate any 86 requirements regarding to SEC value of host-generated CGA addresses. 87 In order to fill this gap, a new CGA SEC Option, is defined in this 88 document. 90 2. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. CGA SEC Option 98 CGA SEC Option is used to indicate on link hosts the lowest CGA SEC 99 value they SHOULD use. It SHOULD be contained in and only in the 100 Router Advertisement Message [RFC4861]. 102 0 1 2 3 103 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | OPTION_CGA_SEC_OPTION | option-len | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | SEC bits | 108 +-+-+-+-+-+-+-+-+ 110 option-code OPTION_CGA_SEC_OPTION (TBA1) 112 option-len 1. 114 SEC bits The value of SEC bits is specified in [RFC3972]. 116 4. Host Behavior 118 On receiving the CGA SEC Option with a recommended SEC value, a host 119 SHOULD use a CGA with the recommended or higher SEC value. If 120 choosing a CGA with a SEC value lower than the recommended, the host 121 MAY take the risk that it is not able to use full network 122 capabilities. The network may consider the hosts that use CGAs with 123 lower SEC values as unsecure users and decline some or all network 124 services. 126 5. Security Considerations 128 This document extends SeND with a CGA SEC Option to transprot SEC 129 bits used in the generation of GCAs, which enables administrators to 130 specify and adjust the security level of the CGAs used in the 131 network. Apart from that, this approach does not introduce any 132 significant changes to the underlying security issues considered in 133 Section 9 of [RFC3971]. 135 6. IANA Considerations 137 This document defines a new Neighbor Discovery Protocol options, 138 which must be assigned an Option Type value within the IPv6 Neighbor 139 Discovery Option Formats table of Internet Control Message Protocol 140 version 6 (ICMPv6) Parameters (http://www.iana.org/assignments/ 141 icmpv6-parameters): 143 Type | Description | Reference 144 ---------+------------------+--------------- 145 TBA1 | CGA SEC option | This document 147 7. Acknowledgements 149 The authors would like to thanks the valuable comments made by 150 members of 6man WG. 152 This document was produced using the xml2rfc tool [RFC2629]. 154 8. References 156 8.1. Normative References 158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 159 Requirement Levels", BCP 14, RFC 2119, March 1997. 161 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 162 Neighbor Discovery (SEND)", RFC 3971, March 2005. 164 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 165 RFC 3972, March 2005. 167 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 168 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 169 September 2007. 171 8.2. Informative References 173 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 174 June 1999. 176 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 177 Optimization for Mobile IPv6", RFC 4866, May 2007. 179 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 180 Shim Protocol for IPv6", RFC 5533, June 2009. 182 Authors' Addresses 184 Sheng Jiang 185 Huawei Technologies Co., Ltd 186 Q14, Huawei Campus, No.156 Beiqing Road 187 Hai-Dian District, Beijing, 100095 188 P.R. China 190 Email: jiangsheng@huawei.com 191 Dacheng Zhang 192 Alibaba Co., Ltd 193 9th Floor, A Area, Wentelai World Finance Centre, 1 West Dawang Road 194 Chaoyang District, Beijing, 100095 100025 195 P.R. China 197 Email: dacheng.zdc@alibaba-inc.com 199 Suresh Krishnan 200 Ericsson 201 8400 Decarie Blvd. 202 Town of Mount Royal, QC 203 Canada 205 Phone: +1 514 345 7900 x42871 206 Email: suresh.krishnan@ericsson.com