idnits 2.17.00 (12 Aug 2021) /tmp/idnits55308/draft-haddad-sava-prefix-reachability-detection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 370. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1, 2007) is 5431 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) ** Downref: Normative reference to an Informational RFC: RFC 3792 (ref. 'CGA') == Outdated reference: draft-ietf-hip-base has been published as RFC 5201 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. 'HIP') ** Obsolete normative reference: RFC 4306 (ref. 'IKEv2') (Obsoleted by RFC 5996) == Outdated reference: draft-ietf-ipv6-2461bis has been published as RFC 4861 -- No information found for draft-haddad-optimizing-send - is the name correct? == Outdated reference: A later version (-01) exists of draft-sava-problem-statement-00 == Outdated reference: draft-ietf-sidr-arch has been published as RFC 6480 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Source Address Verification W. Haddad 3 Architecture (SAVA) M. Naslund 4 Internet-Draft Ericsson Research 5 Expires: January 2, 2008 C. Vogt 6 Ericsson Research Nomadic Lab 7 July 1, 2007 9 Enabling Source Address Verification via Prefix Reachability Detection 10 draft-haddad-sava-prefix-reachability-detection-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 2, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 In this memo, we introduce an approach called "Prefix Reachability 44 Detection", which aims to address certain man-in-the middle 45 misbehavior problems and enable a location-based authentication. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions used in this document . . . . . . . . . . . . . . 4 51 3. Motivation and Assumptions . . . . . . . . . . . . . . . . . . 5 52 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 53 5. New Options and Messages Formats . . . . . . . . . . . . . . . 9 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 55 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 56 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 57 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 58 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 60 Intellectual Property and Copyright Statements . . . . . . . . . . 14 62 1. Introduction 64 In this memo, we introduce an approach called "Prefix Reachability 65 Detection (PRD)", which aims to address certain man-in-the middle 66 (MiTM) misbehavior problems on the IP layer and enable a location- 67 based authentication. A direct consequence of applying the PRD 68 approach is a source address verification mechanism, which can also 69 be used in a mobile and multihomed environment. 71 The main components for applying the PRD protocol are a secure and 72 trustable "prefix routing lookup" mechanism and a secure on-demand 73 query/response between the communicating endpoints and their first 74 hop routers. 76 2. Conventions used in this document 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 [TERM]. 82 3. Motivation and Assumptions 84 The motivation behind this work stems from the need for an efficient 85 and scalable solution to thwart MiTM misbehavior. In fact, a MiTM 86 misbehavior can manifest itself in different aspects, which include 87 unwanted traffic, impersonation, identity theft, denial-of service 88 (DoS). All these aspects can target a network and/or a particular 89 node but they share the same disruptive and destructive goals. They 90 also have one common feature reflected by the alarming and steadily 91 increasing frequency of their occurrence. Consequently, there is an 92 urgent need to address this problem to avoid what could be (very) 93 unpleasant real-world side-effects. 95 Our goal is to provide a solution, which can protect against these 96 different aspects by enabling a source address verification mechanism 97 and at in parallel, offer a set of attributes which can significantly 98 improve the security and the overall efficiency of different types of 99 new and existing solutions. These attributes can be seen as 100 consequences, which fall beyond addressing the SAVA problem statement 101 described in [SAVA]. 103 In order to achieve our goal, we make the following assumptions: 105 - Existence of a secure and trustable mechanism, which enables at 106 least a particular set/class of routers to fetch security credentials 107 (i.e., using a third entity) of other routers belonging to the same 108 set. Such mechanism can be based for example, on the ongoing work on 109 [SIDR]. 111 - Existence of secure and trustable links between each endpoint and 112 the first hop router. Note that this does not really impose new 113 requirements and has already been addressed in [SeND]. 115 4. Protocol Overview 117 The suggested approach enables one endpoint to check the topological 118 location of the other endpoint, which maps correctly to the prefix 119 claimed in their IP address. Such procedure is also referred to by 120 "location authentication". 122 The PRD protocol is performed in parallel with running a key exchange 123 protocol, e.g., [IKEv2] or [HIP]. In the following, we consider the 124 classic scenario where a client (C) is establishing an IKEv2 session 125 with a server (S) and we delegate to (S) the task of triggering the 126 PRD protocol. 128 In its most generic form, the PRD protocol consists on executing (in 129 order) the following steps: 131 1. After completing the IKEv2 exchange, (S) requests from its first 132 hop router (we call it AR(S)) to perform a prefix reachability 133 detection, i.e., location authentication, on (C)'s IP address. 134 For this purpose, (S) sends a "Prefix_Reachability_Request (PRR)" 135 message to AR(S), which carries a secret (called Ksh) and (C)'s 136 IP address. Ksh is derived from the hash of IKEv2 session key 137 (Ks) and a hint (H). The PRR message MUST be signed with (C)'s 138 CGA private key (as described in [CGA]) and the option carrying 139 Ksh MUST be encrypted with AR(S) public key. 141 Note that an optimized version of the SeND protocol (described in 142 [OpSeND]) enables (S) and AR(S) to authenticate all messages 143 exchanged between them by using a shared secret, which in turn 144 eliminates the burden of using private/public key to sign (and 145 encrypt) the PRR message. 147 (C) and (S) MUST use the same method to derive Ksh. This method 148 SHOULD be: 150 Ksh = First[ 128, Hash[ Hash(Ks) | IID(C) | IID(S) ]] 152 Where: 154 - First(X,Y) indicates a truncation of "Y" data so that only the 155 first "X" bits remain to be used. 156 - Hash is a secure cryptographic function. 157 - Ks is IKEv2 session key. 158 - IID(C) = (C)'s IP address interface identifier 159 - IID(S) = (S)'s IP address interface identifier 160 - "|" (concatenation): indicates bytewise concatenation, as in A 161 | B. This concatenation requires that all of the octets of the 162 datum A appear first in the result, followed by all of the octets 163 of the datum B. 164 - IID(C) | IID(S) = Hint (H) 166 2. Upon receiving a valid PRR message, AR(S) starts its mission by 167 performing a "prefix lookup" using (C)'s 64-bit prefix, in order 168 to learn the corresponding IP address and public key of AR(C) 169 (denoted Kpc). It follows that the result of a prefix lookup 170 MUST return the public key and the IP address of the router, 171 which is advertising the queried prefix. Note that it may be 172 useful for AR(S) to store AR(C) parameters for a limited amount 173 of time. 175 3. After retrieving AR(C)'s IP address and public key, AR(S) sends 176 an "On_Link_Presence_Request" (OLPR) message to AR(C), which 177 carries (C)'s 64-bit interface identifier (IID), (S)'s 64-bit 178 prefix and a 64-bit nonce. The IP destination address used in 179 the OLPR message is the one sent to AR(S) in response to its 180 query related to (C)'s prefix. The OLPR message MUST be 181 authenticated with Ksh and signed with AR(S) private key. 183 4. Upon receiving an OLPR message, AR(C) starts the validation 184 procedure by performing an (S)'s prefix look up in order to fetch 185 the corresponding IP address(es) and public key(s) (we call it 186 Kps). After that, AR(C) checks the validity of the IP source 187 address used in the OLPR message. This is followed by checking 188 the requested IID presence on the link. For this purpose, AR(C) 189 SHOULD use the neighbor discovery protocol (described in [NDP]) 190 and SHOULD insert the hint (H) in the corresponding message 191 (i.e., in a new option). Finally, AR(C) MUST authenticate (or 192 sign) the ND message before sending it (note that the message may 193 be sent only to (C) and in this case, it can be authenticated 194 with the shared secret obtained from running OptiSeND between 195 AR(C) and (C)). 197 5. When (C) detects the hint in the ND message, it replies by 198 sending Ksh to AR(C). For this purpose, Ksh is inserted in an 199 encrypted option carried by an authenticated ND message sent to 200 AR(C). 202 6. After receiving a valid ND message from (C), AR(C) decrypts Ksh 203 and uses it to check the authenticity of the OLPR message. If 204 the message is valid, then AR(C) proceeds to check the signature 205 using AR(S)'s Kps, then sends back an 206 "On_Link_Presence_Confirmation (OLPC)" message to AR(S). The 207 OLPC message SHOULD carry (H) and the nonce sent in the OLPR 208 message. In addition, the OLPC message MUST be authenticated 209 with Ksh and signed with AR(C) private key. 211 However, if AR(C) does not get any valid reply (i.e., a message 212 from (C) carrying Ksh), then it MUST send an 213 "On_link_Prefix_Denial (OLPD)" message to AR(S). It follows that 214 the OLPD message cannot be authenticated and in this case, it 215 MUST carry the hint and the nonce sent in the OLPR message and 216 MUST be signed with AR(C) private key only. 218 7. After checking the validity of OLPC/OLPD, AR(S) notifies (S) 219 about the success/failure of its PRR message. This is done by 220 sending a "Prefix_Reachability_Acknowledgment (PRA)" message to 221 (S). The PRA message MUST be signed with AR(S) private key or 222 authenticated with a shared secret between AR(S) and (S). The 223 OLPD message is reflected in the PRA message by setting the 224 "Alert" (A) bit. 225 Following receipt of a valid PRA message, (S) can decide whether 226 to pursue or not the data exchange with (C). 228 The PRD procedure can be repeated periodically during the data 229 exchange between the two endpoints and/or upon receiving a mobility 230 signaling message indicating a switch made by (C) to another network 231 or when switching to another interface. For this purpose, refreshing 232 Ksh is required in each location authentication procedure. To this 233 end, one way would be to add a counter in the formula used to 234 generate Ksh. For instance, we could do: 236 Ksh = First[ 128, Hash[ Hash(Ks) | IID(C) | IID(S) | COUNT ] ] 238 Where COUNT is equal to zero on the first PRD, then its value is 239 increased by 1 (or more) for each new run. This also means that the 240 new value SHOULD be sent in the signaling. 242 5. New Options and Messages Formats 244 The PRD protocol introduces 4 new messages and one new option which 245 are TBD. 247 6. Security Considerations 249 This memo introduces a new protocol, which aims to detect and thwart 250 certain MiTM misbehavior. Hence, the main goal is to improve the 251 detection and defense capabilities on both sides of the two 252 communicating endpoints. If implemented correctly, in its current 253 form and to the best of our knowledge, the PRD protocol does not 254 introduce nor increase any new/existing security threats. It should 255 be noted however, that the presence of a nonce in the OLPD message is 256 highly recommended in order to avoid launching a DoS attack on AR(S). 258 7. Acknowledgments 260 Authors would like to thank Pekka Nikander, Rolf Blom, Andras Mehes 261 and Yuri Ismailov for their valuable input. 263 8. References 265 8.1. Normative References 267 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 268 RFC 3792, March 2005. 270 [HIP] Moskowitz, B., Nikander, P., Jokela, P., and T. Henderson, 271 "Host Identity Protocol", Internet 272 Draft, draft-ietf-hip-base-07.txt, February 2007. 274 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 275 RFC 4306, December 2005. 277 [NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 278 "Neighbor Discovery for IP Version 6 (IPv6)", Internet 279 Draft, draft-ietf-ipv6-2461bis-11.txt, March 2007. 281 [SeND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P. 282 Nikander, "Secure Neighbor Discovery (SEND)", RFC 3971, 283 March 2005. 285 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 286 Requirement Levels", RFC 2119, BCP , March 1997. 288 8.2. Informative References 290 [OpSeND] Haddad, W., Krishnan, S., Choi, J., and J. Laganier, 291 "Secure Neighbor Discovery (SeND) Optimizations: The 292 OptiSeND Protocol", Internet 293 Draft, draft-haddad-optimizing-send-00.txt, July 2007. 295 [SAVA] Wu, J., Bonica, R., Bi, J., Li, X., Ren, G., and M I. 296 Williams, "Source Address Verification Architecture Problem 297 Statement", Internet 298 Draft, draft-sava-problem-statement-00.txt, February 2007. 300 [SIDR] Barnes, R. and S. Kent, "An Infrastructure to Support 301 Secure Internet Routing", Internet 302 Draft, draft-ietf-sidr-arch-00.txt, January 2007. 304 Authors' Addresses 306 Wassim Haddad 307 Ericsson Research 308 Torshamnsgatan 23 309 SE-164 80 Stockholm 310 Sweden 312 Phone: +46 8 4044079 313 Email: Wassim.Haddad@ericsson.com 315 Mats Naslund 316 Ericsson Research 317 Torshamnsgatan 23 318 SE-164 80 Stockholm 319 Sweden 321 Phone: +46 8 58533739 322 Email: Mats.Naslund@ericsson.com 324 Christian Vogt 325 Ericsson Research Nomadic Lab 326 Jorvas FI-02420 327 Finland 329 Phone: +358 9 299 1 330 Email: Christian.Vogt@ericsson.com 332 Full Copyright Statement 334 Copyright (C) The IETF Trust (2007). 336 This document is subject to the rights, licenses and restrictions 337 contained in BCP 78, and except as set forth therein, the authors 338 retain all their rights. 340 This document and the information contained herein are provided on an 341 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 342 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 343 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 344 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 345 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 346 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 348 Intellectual Property 350 The IETF takes no position regarding the validity or scope of any 351 Intellectual Property Rights or other rights that might be claimed to 352 pertain to the implementation or use of the technology described in 353 this document or the extent to which any license under such rights 354 might or might not be available; nor does it represent that it has 355 made any independent effort to identify any such rights. Information 356 on the procedures with respect to rights in RFC documents can be 357 found in BCP 78 and BCP 79. 359 Copies of IPR disclosures made to the IETF Secretariat and any 360 assurances of licenses to be made available, or the result of an 361 attempt made to obtain a general license or permission for the use of 362 such proprietary rights by implementers or users of this 363 specification can be obtained from the IETF on-line IPR repository at 364 http://www.ietf.org/ipr. 366 The IETF invites any interested party to bring to its attention any 367 copyrights, patents or patent applications, or other proprietary 368 rights that may cover technology that may be required to implement 369 this standard. Please address the information to the IETF at 370 ietf-ipr@ietf.org. 372 Acknowledgment 374 Funding for the RFC Editor function is provided by the IETF 375 Administrative Support Activity (IASA).