idnits 2.17.00 (12 Aug 2021) /tmp/idnits10972/draft-xyz-pidloc-reqs-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 27, 2019) is 1083 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) == Unused Reference: 'I-D.ietf-lisp-rfc6830bis' is defined on line 178, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lisp-rfc6833bis' is defined on line 184, but no explicit reference was found in the text == Unused Reference: 'I-D.herbert-intarea-ila' is defined on line 197, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-intarea-tunnels' is defined on line 202, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lisp-sec' is defined on line 207, but no explicit reference was found in the text == Unused Reference: 'I-D.nordmark-id-loc-privacy' is defined on line 212, but no explicit reference was found in the text == Unused Reference: 'RFC6740' is defined on line 227, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 232, but no explicit reference was found in the text == Unused Reference: 'RFC6833' is defined on line 237, but no explicit reference was found in the text == Unused Reference: 'RFC7217' is defined on line 248, but no explicit reference was found in the text == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-26 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-24 == Outdated reference: A later version (-10) exists of draft-ietf-intarea-tunnels-09 == Outdated reference: A later version (-25) exists of draft-ietf-lisp-sec-17 == Outdated reference: A later version (-02) exists of draft-xyz-pidloc-ps-00 Summary: 0 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Iannone 3 Internet-Draft Telecom ParisTech 4 Intended status: Standards Track D. von Hugo 5 Expires: November 28, 2019 Deutsche Telekom 6 B. Sarikaya 7 Denpel Informatique 8 May 27, 2019 10 Requirements to Secure End to End Privacy in IdLoc Systems 11 draft-xyz-pidloc-reqs-00.txt 13 Abstract 15 Use of Identifier Locator separation systems is proposed for various 16 use cases to allow for efficient and service aware flexible end-to- 17 end routing. A statement on the issue of privacy preservation of 18 both users and devices identity and location describes major 19 challenges identified for this problem. This document attempts to 20 derive requirements towards a potential solution space of approaches 21 to preserve privacy in Identifier-Locator split (PidLoc) protocols. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 28, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 59 3. Identifier Locator Separation Protocols . . . . . . . . . . . 3 60 4. PId-Loc Requirements . . . . . . . . . . . . . . . . . . . . 3 61 4.1. Limited Effort . . . . . . . . . . . . . . . . . . . . . 3 62 4.2. Flexibility . . . . . . . . . . . . . . . . . . . . . . . 3 63 4.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 3 64 4.4. Resiliency . . . . . . . . . . . . . . . . . . . . . . . 3 65 4.5. ID to Locator Association Protection . . . . . . . . . . 4 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 71 8.2. Informative References . . . . . . . . . . . . . . . . . 5 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 [I-D.xyz-pidloc-ps] has identified and described typical use cases 77 for application of privacy preserving Identifier-Locator split 78 (PidLoc) approaches and derived thereof a problem statement 79 describing corresponding issues and challenges. Privacy in this 80 respect includes prevention of acquisition of personal information, 81 behavioral details, and location information by unauthorised parties. 82 This document tries to assess that set of issues and challenges to 83 come up with a set of requirements for approaches towards service 84 specific and optimized packet routing based on Id-Loc principle 85 providing privacy and security. 87 2. Conventions and Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119] and 92 [I-D.xyz-pidloc-ps]. 94 3. Identifier Locator Separation Protocols 96 This section summarizes the specifics and commonalities of existing 97 Identifier Locator (Id-Loc) Separation Protocols and highlights the 98 corresponding challenges and issues identified in 99 [I-D.xyz-pidloc-ps]. 101 4. PId-Loc Requirements 103 This section lists requirements which emerge from the use case 104 analysis and will apply (beside the general requirements to fit with 105 privacy considerations for Internet Protocols as laid down in RFC 106 6973 [RFC6973] and partly also on design criteria for confidentiality 107 in the data plane of LISP described in RFC 8061 [RFC8061]) for the 108 solution space providing privacy and security in generic Identifier 109 Locator Split Approaches. 111 4.1. Limited Effort 113 The measures to ensure privacy to Id-Loc systems shall not require 114 additional infrastructure and external third party provided resources 115 to be used nor increase the overall effort such that network and 116 service performance is strongly degraded. Successful privacy 117 measures shall not impact availability. 119 4.2. Flexibility 121 Because Id-Loc approaches can be used in mobile environments, 122 flexibility in time and space should be provided. The same Id, 123 associated to a specific device, can move around and at different 124 times can have different privacy requirements, may be depending on 125 the specific connection or provider used. Still because of mobility, 126 a certain device can have different privacy requirements depending of 127 where it is. 129 4.3. Scalability 131 Because some of the ID-Loc proposals aim at being deployed in 132 datacenters, the methods to ensure privacy has to be able to function 133 at very large scale. 135 4.4. Resiliency 137 The measure shall not rely on a potential single point of failure nor 138 a single mechanism and allow for automatic rebooting or relying on 139 alternative solutions in case of compromise and attacks. 141 4.5. ID to Locator Association Protection 143 The Id-Loc system may need to use measures for binding one or more 144 identifiers to one or more locators. This is usually achieved by a 145 mapping or lookup system (e.g. DNS) which has to be protected 146 against unauthorised access and may allow for different policy-based 147 chosen levels of security. Like any other software-based service, 148 the mapping system has to be protected against DDoS attacks and the 149 like. However, there are specific points to be tackled: 151 o Mapping System Access Control: Who can access the mapping system? 153 o Mapping Access Control: Someone authorized to access the mapping 154 system does not mean that is authorized to access the mapping of a 155 specific Identifier. 157 o Byzantines Attacks: What if someone is able to inject tempered 158 information to attack either the mapping system itself of a 159 specific identifier? 161 The above may be defined on various criteria, like for instance 162 administrative criteria "devices part of the same company", or 163 geographical criteria "only close by devices", or service-aware 164 "devices operating the same service". 166 5. IANA Considerations 168 TBD. 170 6. Security Considerations 172 7. Acknowledgements 174 8. References 176 8.1. Normative References 178 [I-D.ietf-lisp-rfc6830bis] 179 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 180 Cabellos-Aparicio, "The Locator/ID Separation Protocol 181 (LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress), 182 November 2018. 184 [I-D.ietf-lisp-rfc6833bis] 185 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 186 "Locator/ID Separation Protocol (LISP) Control-Plane", 187 draft-ietf-lisp-rfc6833bis-24 (work in progress), February 188 2019. 190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 191 Requirement Levels", BCP 14, RFC 2119, 192 DOI 10.17487/RFC2119, March 1997, 193 . 195 8.2. Informative References 197 [I-D.herbert-intarea-ila] 198 Herbert, T. and P. Lapukhov, "Identifier-locator 199 addressing for IPv6", draft-herbert-intarea-ila-01 (work 200 in progress), March 2018. 202 [I-D.ietf-intarea-tunnels] 203 Touch, J. and M. Townsley, "IP Tunnels in the Internet 204 Architecture", draft-ietf-intarea-tunnels-09 (work in 205 progress), July 2018. 207 [I-D.ietf-lisp-sec] 208 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 209 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-17 210 (work in progress), November 2018. 212 [I-D.nordmark-id-loc-privacy] 213 Nordmark, E., "Privacy issues in ID/locator separation 214 systems", draft-nordmark-id-loc-privacy-00 (work in 215 progress), July 2018. 217 [I-D.xyz-pidloc-ps] 218 Hugo, D., Sarikaya, B., Iannone, L., Petrescu, A., Kj, S., 219 and U. Fattore, "Problem Statement for Secure End to End 220 Privacy in IdLoc Systems", draft-xyz-pidloc-ps-00 (work in 221 progress), May 2019. 223 [NYC_cab] Douriez, et al., M., "Anonymizing NYC Taxi Data: Does It 224 Matter?", Proc. of IEEE Intl. Conf. on Data Science and 225 Advanced Analytics (DSAA'16) , pp. 140-148, 2016. 227 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 228 Protocol (ILNP) Architectural Description", RFC 6740, 229 DOI 10.17487/RFC6740, November 2012, 230 . 232 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 233 Locator/ID Separation Protocol (LISP)", RFC 6830, 234 DOI 10.17487/RFC6830, January 2013, 235 . 237 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 238 Protocol (LISP) Map-Server Interface", RFC 6833, 239 DOI 10.17487/RFC6833, January 2013, 240 . 242 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 243 Morris, J., Hansen, M., and R. Smith, "Privacy 244 Considerations for Internet Protocols", RFC 6973, 245 DOI 10.17487/RFC6973, July 2013, 246 . 248 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 249 Interface Identifiers with IPv6 Stateless Address 250 Autoconfiguration (SLAAC)", RFC 7217, 251 DOI 10.17487/RFC7217, April 2014, 252 . 254 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 255 (LISP) Data-Plane Confidentiality", RFC 8061, 256 DOI 10.17487/RFC8061, February 2017, 257 . 259 Authors' Addresses 261 Luigi Iannone 262 Telecom ParisTech 264 Email: ggx@gigix.net 266 Dirk von Hugo 267 Deutsche Telekom 268 Deutsche-Telekom-Allee 7 269 D-64295 Darmstadt 270 Germany 272 Email: Dirk.von-Hugo@telekom.de 274 Behcet Sarikaya 275 Denpel Informatique 277 Email: sarikaya@ieee.org