idnits 2.17.1 draft-bagnulo-shim6-privacy-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 341. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 20, 2006) is 6396 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-shim6-failure-detection-03 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft UC3M 4 Intended status: Informational October 20, 2006 5 Expires: April 23, 2007 7 Privacy Analysis for the SHIM6 protocol 8 draft-bagnulo-shim6-privacy-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 23, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This note presents a privacy analysis for the SHIM6 protocol for IPv6 42 site multihoming support and the failure detection extensions for the 43 SHIM6 protocol.This note does not attempt to provide a solution for 44 providing SHIM6 protocol privacy. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Privacy of the ULID-pair context establishment exchange . . . . 3 50 3. Payload packets . . . . . . . . . . . . . . . . . . . . . . . . 6 51 4. Other Signalling messages . . . . . . . . . . . . . . . . . . . 6 52 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 53 6. Security considerations . . . . . . . . . . . . . . . . . . . . 7 54 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 Intellectual Property and Copyright Statements . . . . . . . . . . 9 58 1. Introduction 60 This note presents a privacy analysis for the SHIM6 protocol as 61 defined in [1] and the failure detection extensions for the SHIM6 62 protocol defined in [2]. 64 The scenario considered is the following: two nodes are communicating 65 using the SHIM6 protocol to achieve enhanced fault tolerance 66 capabilities. The potential attackers are located along the path and 67 their goal is to obtain relevant information by observing the 68 exchanged packets. In particular, we consider that information 69 harvesters may be interested in determining whether a set of 70 addresses belongs to a single host or if a set of packets exchanged 71 using different address pairs belong to the same communication. In 72 the following sections we will analyze the information contained in 73 the SHIM6 protocol messages that can be used to obtain such 74 information. 76 It should be noted that this analysis is limited to malicious third 77 parties that are located along one or several of the available paths 78 between the communication parties and that it is out of the scope of 79 the analysis the case where the potential attacker is one of the 80 parties involved in the communication i.e. the goal is not to avoid 81 the disclosure of locator information from the peer. 83 The remaining of this note is structured as follows: in the next 84 section we will perform a privacy analysis of the SHIM6 4-way 85 exchange to establish ULID-pair contexts. Next, we will analyze the 86 privacy aspects of the payload packet exchange and finally we 87 consider the privacy implications of other protocol messages, 88 including the failure detection protocol for the SHIM6 protocol. 90 2. Privacy of the ULID-pair context establishment exchange 92 The ULID-pair context establishment exchange consists of 4 messages: 93 I1, R1, I2 and R2. We will next analyze the privacy implications of 94 each of them. 96 The I1 message is exchanged using a valid locator pair in the IPv6 97 address fields. In addition, the I1 message contains the Initiator 98 context tag and nonce. Besides it can carry additional options. In 99 particular, in case that the locator pair used differs from the ULID 100 pair for the context, an ULID-pair option must be carried in the I1 101 message. 103 Among the information carried in the I1 message we consider that the 104 following may have privacy implications if it can be observed by a 105 third party: 106 o The binding between a locator pair and ULID pair if the ULID-pair 107 option is carried in clear text 108 o The Context Tag information can be used by an attacker in order to 109 correlate different packets containing different locator pairs. 110 Through this mean, the attacker can learn that multiple locators 111 belong to the same endpoint and that the different packets 112 carrying different address pairs belong to the same communication. 114 In order to achieve privacy protection, it is required to conceal all 115 this information. 117 The next message to be exchanged is R1. This message contains a pair 118 of valid locators in the IPv6 address fields and in the message 119 itself, it contains the Initiator nonce and the Responder nonce. In 120 addition, the R1 message support the Validator option, which contain 121 cryptographic information. 123 The disclosure of any of these elements doesn't seems to raise any 124 privacy concerns, so there does not seem to be any requirement to 125 conceal the information carried in the R1 message. 127 After the R1 message the ULID-pair context establishment continues 128 with the I2 message. The I2 message is carried in a packet 129 containing again a valid locator pair in the IPv6 header address 130 fields and, in the I2 message itself the Initiator context tag, the 131 Initiator and Responder nonces are conveyed. The I2 message can 132 carry also the following options: ULID pair, Forked Instance 133 Identifier, Locator list, Locator Preferences, CGA Parameter Data 134 Structure and CGA Signature. 136 Of all the aforementioned information conveyed in the I2 message, we 137 identify the following items that may imply privacy concerns: 138 o The Initiator Context tag, for the same reasons than in the I1 139 message 140 o The ULID-pair option, for the same reasons than in the I1 message 141 o The locator list option, since it carries the list of locator 142 which disclosure would clearly result in allowing the attacker to 143 identify the multiple locator associated with a single endpoint 144 o The CGA parameter data structure option. In this case, it depends 145 of which information is carried in the data structure. If a 146 multiprefix extension is carried i.e. HBA are used, then the 147 information is critical from a privacy perspective, since the 148 information about multiple prefixes and hence about multiple 149 locators is included in the data structure. If the multiprefix 150 extension is not included, then the CGA parameter data structure 151 could be used by an attacker to obtain identifier information 152 (since there is enough information in the data structure to re- 153 create the associated CGA). So if the CGA is being used as 154 locator in the packet (and no multiprefix extension is being 155 used), then the CGA parameter data structure is not critical from 156 a privacy perspective. 158 The other information carried in the I2 message is not considered to 159 be critical for preserving the privacy. In particular, the Forked 160 Instance Identifier could be used to correlate different packets, but 161 without knowing the Context tag, the attack seems not very practical. 162 The Locator preference option may inform about the number of locators 163 available and the relative preference between them, but without 164 knowing the actual locators, this information does not seem to be 165 very relevant neither. Finally, the CGA signature information does 166 not seem to provide any useful information for an attacker. 168 The last packet of the initial exchange is the R2 packet that 169 contains the Responder context tag, and the following potential 170 options: Locator List, Locator Preferences, CGA Parameter Data 171 Structure, CGA Signature. Analogously to the I2 case, the following 172 information needs to be concealed: the Responder context tag, the 173 Locator list option, the CGA Parameter Data structure. 175 In addition to the four messages of the basic ULID-pair context 176 establishment exchange, there are also two additional messages 177 defined, that need to be analyzed also these are the R1bis packet and 178 the I2bis packet. 180 The R1bis message is carried in a packet that carries valid locators 181 in the IPv6 address fields and the message itself contains the Packet 182 context tag and the Responder nonce. In addition, it also can carry 183 the Validator option. 185 Similarly to the R1 packet, the R1bis packet does not carries any 186 critical information from a privacy point of view. 188 The I2bis message is also carried in a packet that contains valid 189 locators in the IPv6 address fields and it carries the following 190 information in the message: Initiator context tag, the Initiator and 191 Responder nonces and the Packet context tag. In addition it allows 192 the following options: Responder Validator, ULID pair, Forked 193 Instance Identifier, Locator list, Locator Preferences, CGA Parameter 194 Data Structure and the CGA Signature. 196 Similarly to the previous cases, the following information needs to 197 be concealed in order to preserve privacy: Initiator context Tag, 198 ULID pair option, Locator List option, CGA Parameter Data Structure. 200 3. Payload packets 202 Payload packets are data packets that carry the SHIM6 header 203 containing the Payload option. This option carries the Receiver 204 context tag. The main privacy issue related to the Payload packets 205 is that they may change the locator pair used while keeping the 206 Context tag unchanged. The problem with this approach is that an 207 attacker located along the different paths can correlate different 208 packets carrying different locator pairs through the constant context 209 tag included in the payload header. Through this mean, the attacker 210 can determine different locators of the locator set and determine 211 that different packets exchanged belong to a single communication. 212 In order to prevent this privacy breach, it is required that 213 different unrelated context tags are used when the locator pair is 214 changed. 216 4. Other Signalling messages 218 In addition to the messages previously analyzed, the SHIM6 protocol 219 also defines the Update Request and Ack messages and the Keepalive 220 and Probe messages. We will next perform the privacy analysis for 221 these messages. 223 The Update Request carries the Context tag and the request nonce and 224 it supports the following options: Locator List, Locator Preferences, 225 CGA Parameter Data Structure, CGA Signature. 227 As for the prior analysis, the critical information from a privacy 228 perspective is the following: the context tag (if a different locator 229 pair is being used), the Locator List option, and the CGA parameter 230 data structure (with the considerations described above). 232 The Update Ack message contains the context tag and the request 233 nonce. If different locator pair is used, the context tag and the 234 request nonce can be used to correlate different packets with 235 different locator pairs. In this case, the context tag and nonce 236 information need to be concealed to protect privacy. 238 With respect to Keepalive and Probe messages, the critical 239 information contained in those messages is the following: the context 240 tag and the identifier information carried in different options 241 available. 243 The considerations with respect to the context tag information are 244 similar to the ones already discussed for other messages. 246 With respect to the Identifier information, this information would 247 allow the correlation of different Keepalive and Probe packets, 248 allowing then to bind different locators used in different packets. 249 In order to preserve privacy, the Identifier information need to be 250 concealed. 252 5. Conclusion 254 It is clear that there is quite a few information included in the 255 SHIM6 protocol that need to be concealed in order to provide privacy 256 support for the SHIM6 protocol. However, it is likely that 257 encrypting the critical information using a shared secret generated 258 through a Diffie Hellman exchange would provide enough protection for 259 most of the cases. There are however two cases that would require 260 additional study: one is the case of the information exchanged in the 261 I1 packet, which is the first message to be exchanged implying that 262 no previous shared secret can possible be exchanged. In order to 263 address this case, or additional prior message exchange is included 264 in the protocol to provide privacy or the critical information is 265 removed from the I1 message. Another case that would require further 266 analysis is the case of the context tag. The context tag is used to 267 demultiplex incoming packet. In order for this to be useful, the 268 context tag needs to be known beforehand by both ends and in order to 269 provide privacy support, the context tag needs to be changed when the 270 locator pair is changed. Mechanisms for changing the context tag 271 depending on the locator pair used can be defined, keeping in mind 272 that the relation between the locator pair and the context tag must 273 remain untraceable for an external observer. 275 6. Security considerations 277 This note analyzes the privacy issues of the SHIM6 protocol. 278 Additional security considerations of the SHIM6 protocol are 279 addressed in the protocol specification itself 281 7. References 283 [1] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", 284 draft-ietf-shim6-l3shim-00 (work in progress), July 2005. 286 [2] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair 287 Exploration Protocol for IPv6 Multihoming", 288 draft-ietf-shim6-failure-detection-03 (work in progress), 289 December 2005. 291 Author's Address 293 Marcelo Bagnulo 294 Universidad Carlos III de Madrid 295 Av. Universidad 30 296 Leganes, Madrid 28911 297 SPAIN 299 Phone: 34 91 6249500 300 Email: marcelo@it.uc3m.es 301 URI: http://www.it.uc3m.es 303 Full Copyright Statement 305 Copyright (C) The Internet Society (2006). 307 This document is subject to the rights, licenses and restrictions 308 contained in BCP 78, and except as set forth therein, the authors 309 retain all their rights. 311 This document and the information contained herein are provided on an 312 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 313 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 314 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 315 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 316 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 317 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 319 Intellectual Property 321 The IETF takes no position regarding the validity or scope of any 322 Intellectual Property Rights or other rights that might be claimed to 323 pertain to the implementation or use of the technology described in 324 this document or the extent to which any license under such rights 325 might or might not be available; nor does it represent that it has 326 made any independent effort to identify any such rights. Information 327 on the procedures with respect to rights in RFC documents can be 328 found in BCP 78 and BCP 79. 330 Copies of IPR disclosures made to the IETF Secretariat and any 331 assurances of licenses to be made available, or the result of an 332 attempt made to obtain a general license or permission for the use of 333 such proprietary rights by implementers or users of this 334 specification can be obtained from the IETF on-line IPR repository at 335 http://www.ietf.org/ipr. 337 The IETF invites any interested party to bring to its attention any 338 copyrights, patents or patent applications, or other proprietary 339 rights that may cover technology that may be required to implement 340 this standard. Please address the information to the IETF at 341 ietf-ipr@ietf.org. 343 Acknowledgment 345 Funding for the RFC Editor function is provided by the IETF 346 Administrative Support Activity (IASA).