idnits 2.17.1
draft-padma-ideas-problem-statement-03.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 (July 3, 2017) is 2489 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Obsolete informational reference (is this intentional?): RFC 6830
(Obsoleted by RFC 9300, RFC 9301)
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group P. Pillay-Esnault, Ed.
3 Internet-Draft Huawei
4 Intended status: Informational M. Boucadair
5 Expires: January 4, 2018 Orange
6 G. Fioccola
7 Telecom Italia
8 C. Jacquenet
9 Orange
10 A. Nennker
11 Deutsche Telekom
12 July 3, 2017
14 Problem Statement for Identity Enabled Networks
15 draft-padma-ideas-problem-statement-03
17 Abstract
19 This problem statement examines how existing protocols that separate
20 identifiers from their location may benefit from the concept of
21 identity. The proposal laid out herein advocates for a standardized
22 identity/identifier network infrastructure that provides a framework
23 to support identity services in addition to enhancing existing
24 identifier/location mapping and resolution services.
26 Status of This Memo
28 This Internet-Draft is submitted in full conformance with the
29 provisions of BCP 78 and BCP 79.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF). Note that other groups may also distribute
33 working documents as Internet-Drafts. The list of current Internet-
34 Drafts is at http://datatracker.ietf.org/drafts/current/.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than as "work in progress."
41 This Internet-Draft will expire on January 4, 2018.
43 Copyright Notice
45 Copyright (c) 2017 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
61 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
62 3. Key Problems . . . . . . . . . . . . . . . . . . . . . . . . 5
63 3.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 5
64 3.1.1. Tracking Prevention . . . . . . . . . . . . . . . . . 5
65 3.1.2. Privacy against Eavesdroppers . . . . . . . . . . . . 5
66 3.1.3. Identifier Right to be Forgotten . . . . . . . . . . 6
67 3.2. Common Infrastructure and Primitives . . . . . . . . . . 6
68 3.3. Allocation Schemes Guidance . . . . . . . . . . . . . . . 7
69 4. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
70 4.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . . 7
71 4.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 8
72 4.3. Future Studies . . . . . . . . . . . . . . . . . . . . . 8
73 5. Relationship between IDEAS and other IETF Working Groups . . 8
74 5.1. LISP WG . . . . . . . . . . . . . . . . . . . . . . . . . 9
75 5.2. HIP WG . . . . . . . . . . . . . . . . . . . . . . . . . 9
76 5.3. NVO3 WG . . . . . . . . . . . . . . . . . . . . . . . . . 9
77 6. Companion Documents . . . . . . . . . . . . . . . . . . . . . 9
78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
80 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
82 11. Informative References . . . . . . . . . . . . . . . . . . . 10
83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
85 1. Introduction
87 While the separation of identifier from the location is not a new
88 concept, existing solutions such as Host Identity Protocol (HIP)
89 [RFC7401] , Location/Separation Protocol (LISP) [RFC6830] and
90 Identifier-Locator Addressing (ILA) [ILA] for IPv6, may benefit from
91 a higher layer abstraction that separates the identity of an entity
92 from its associated identifier(s).
94 In identifier and Location split protocols, identifiers (IDf) are
95 used for decoupling the identifier and the location information at
96 the network layer. Typically, a IDf represents an end-point
97 communication tied to an entity. Usually, IDfs are long-lived and
98 may or may not be routable. However, locators (LOC) may be transient
99 and associated with the location of the entity. The LOCs are
100 routable network addresses (e.g. IPv4, IPv6 addresses). The IDfs
101 are mapped to LOCs for forwarding purposes. Modification of LOC
102 information is handled by an a mapping system that updates the IDf/
103 LOC mappings.
105 In order to communicate with a device, the initiator relies on a
106 mapping system that is designed to process lookup requests on a
107 network IDf and return the LOC(s). While the mapping system fulfills
108 its functionality, this mode of operation has some drawbacks.
110 The entities update the system with their (IDf,LOC) bindings. In
111 some cases, it may register the LOC of a forwarding element such as a
112 proxy or HIP Rendezvous Server. Regardless, it is assumed that once
113 the entities have registered their (IDF,LOC(s)) tuple to the system,
114 this information is available to all with access to the mapping
115 system. Any request for this information would then be readily
116 available without any discrimination. For example, a public entity
117 needs to have its IDf public to be discovered by clients. However,
118 it might not be always desirable that some devices (e.g. home
119 cameras) are visible to all without any control.
121 Privacy and security requirements of entities suggest the use of some
122 mechanism to authenticate entities that can dynamically discover them
123 and prevent unwanted communication. In existing architectures it is
124 possible to authenticate IDf, however they are not permanently
125 attached to the entity. This is crucial in a multi-provider and/or
126 multi-domain scenario, related for example to a complex end-to-end
127 service.
129 Therefore the concept of an identity(IDy) tied to an entity and to
130 its lifecycle should be considered. The IDy is intended to be used
131 for identifying and authenticating an entity. Likewise, the IDy
132 information should not be carried in clear in packet headers. The
133 Section 3 of this document will describe how this IDy may be used.
135 Furthermore, it would be beneficial to generalize this Identity
136 concept across protocols that may benefit from it. Therefore there
137 is a need for a system which shares some common control plane for
138 services commonly used such as look-ups or updates.
140 This document examines the possible changes and improvements needed
141 to address these challenges in Identity Enabled networkS (IDEAS). It
142 describes the problem statement and advocates for a standardized
143 extensible common control plane for IDf/LOC protocols that supports:
145 Identity services (including registration and authentication)
147 Management of access credentials based on IDy
149 Look-ups with restrictions
151 Mapping, and resolution services on IDfs
153 2. Definition of Terms
155 Entity: An entity is a communication endpoint. It can be a
156 device, a node, or a (software) process, that needs to be
157 identified and locatable/reachable. Such entity will have one or
158 more communication interfaces. An entity may have multiple IDfs
159 simultaneously that are NOT associated with any particular
160 interface(s). It is reached by the resolution of one or more of
161 its IDfs to one or more LOCs.
163 Identity (IDy): The essence of "being" of a specific entity. An
164 IDy is not to be confused with an IDf: while an IDf may be used to
165 refer to an entity, an IDf's lifecycle is not necessarily tied to
166 the lifecycle of the IDy it is referencing. On the other hand,
167 the IDy's lifecycle is inherently tied to the lifecycle of the
168 entity itself.
170 Identifier (IDf): An IDf denotes information to unambiguously
171 identify an entity or an entity group within a given scope. An
172 IDf is the equivalent of an End point identifier (EID) in LISP or
173 Host Identity Tag (HIT) in HIP. It may be visible in
174 communications.
176 Locator (LOC): A locator is a routable network address. It may be
177 associated with an IDf and used for communication on the network
178 layer according to LOC/IDf split principle. A LOC is the
179 equivalent of a Routing Locator (RLOC) in LISP or an IP address in
180 HIP.
182 Metadata (META): Data associated with an IDy and its IDfs in the
183 framework. The metadata is to be used for storing long-lived slow
184 changing information such as the nature of the entity (e.g. camera
185 or phone).
187 IDy/IDf mapping: One IDy may be associated to multiple IDfs. The
188 IDfs are mapped to one IDy.
190 Identifier-based: When an entity is only reachable through one or
191 more communication access then a protocol or a solution is said to
192 be identifier-based if it uses an ID-LOC decoupling and a mapping
193 system (MS) as base components of the architecture.
195 GeneRic Identity Services (GRIDS): GRIDS is a set of services to
196 manage the lifecycle of ID[y|f]s, to map and resolve IDfs and
197 LOCs, and to associate META with entities. It is a distributed
198 system that stores the IDy, IDf, the associated LOC(s), and META
199 in the form of tuples (ID, LOC, and META). Meta queries are
200 supported and queries are restricted to authenticated and
201 authorized IDys.
203 IDentity Enabled Networks (IDEAS): IDEAS are networks that support
204 the IDf/IDy decoupling as well as IDf /LOC decoupling using GRIDS.
205 Reaching an entity is achieved by the resolution of IDf(s) to
206 LOC(s).
208 Scope: Domain of applicability or usability of an IDfs and IDys.
209 The scope may be global or limited, e.g., considered local with
210 geographic proximity or private within an administrative domain.
212 3. Key Problems
214 3.1. Privacy
216 3.1.1. Tracking Prevention
218 Access to a mapping system may reveal the location and other
219 sensitive information about an entity to the requestor of a look-up
220 on an IDf. Repeated look-ups on the mapping system may be misused
221 for tracking IDfs of an entity or mount an attack.
223 To preserve its privacy, the entity or infrastructure may restrict
224 access for look-ups for certain IDfs or IDys or entity with specific
225 meta. (E.g. nature of an entity stored in meta as a camera).
227 Currently, even if look-ups on the mapping systems were modified not
228 to return a result if the requestor is barred, it would be easily
229 defeated if the requestor changes its IDf. However, if all IDfs of
230 an entity are associated with the IDy, then the requestor entity
231 cannot easily defeat the aforementioned filtering rule by just
232 changing its IDf.
234 3.1.2. Privacy against Eavesdroppers
236 Eavesdroppers may observe the traffic and deduce the flows between
237 two IDfs or entities. To protect its privacy, an entity may choose
238 additional temporary IDfs for communications.
240 However, this mechanism makes discovery difficult and the entity must
241 at least have a long-lived IDf for this purpose.
243 The use of obfuscation is another solution to protect the source and
244 destination IDf however this implies extra processing or DPI for
245 functionalities such as late binding.
247 The use of IDy as an indirection to the actual IDfs used on the wire
248 present the advantage of having the source and destination ephemeral
249 IDfs in clear but authorized use may still maps these to the IDy.
250 The IDy of an entity must not be revealed in packets. Therefore,
251 encrypting the control plane mechanisms (requests and replies) is
252 required to avoid eavesdroppers to deduce who are the peers of
253 communication flows.
255 3.1.3. Identifier Right to be Forgotten
257 The control of the IDy/IDf mappings can restrict access to selected
258 requesting IDys/IDfs and also limit that access over time to
259 implement an "identifier right to be forgotten".
261 The advantage of this method is that entities may use IDfs for
262 communication to better protect their IDy. Only authorized
263 communication partners can find out the corresponding IDys. The
264 concept of IDy proposed by IDEAS helps to provide privacy in
265 communication in a similar way as IPv6 privacy extension minimizes
266 the risk of being tracked by a stable MAC address. To that end,
267 access restriction is needed for mapping system requests that also
268 need to be encrypted to avoid eavesdropping.
270 3.2. Common Infrastructure and Primitives
272 Currently, each of the IDf-based protocols uses its own specific
273 mapping databases. While IDf-based data plane mechanisms may serve
274 fundamentally different objectives and may not need to interoperate,
275 there is a potential benefit in providing them with a common
276 interface for common services such as IDy/IDf registration,
277 discovery, update, resolution and access control policy.
278 Furthermore, the lack of a common infrastructure with standardized
279 invocation interfaces has the following downsides:
281 a. An impediment for the deployment of IDf-based. Indeed, it would
282 be inefficient to deploy several specialized mapping/ resolution
283 network databases within the same administrative domain.
284 Furthermore, there will be additional expense and overhead to
285 administer multiple proprietary mapping systems.
287 b. Difficulty to have an overall view of the network. If multiple
288 IDf-based solutions with distinct mapping systems are deployed,
289 troubleshooting may be difficult as the information may be
290 located in different places.
292 c. Complex Management due to disjoint information spread over
293 several mapping systems. Operations such as merging networks are
294 error prone and more challenging to detect and fix.
295 Additionally, there will be considerable management overhead
296 whenever devices migrate.
298 d. Barriers to the enforcement of common and consistent policies.
299 For example, in cross-platform IoT networking, brokering services
300 may be needed to enforce routing/security/QoS/TE policies on
301 behalf of partnering structures - service provider, energy
302 provider, content provider, etc.
304 The common infrastructure may be supported within limited or private
305 scopes. In addition support of private instances provides the
306 necessary separation for specific users or applications.
308 3.3. Allocation Schemes Guidance
310 Currently, there is no consistent guidance or allocation scheme for
311 non-IP address format public IDfs across all protocols. Each
312 protocol has historically assigned their IDfs independently, be it
313 structured or not. An agreed scheme or a collision detection
314 mechanism within a scope may facilitate cross-domain communication in
315 the future. This would simplify the implementation of some use cases
316 to facilitate cross-silo communications or to better address the
317 merging of networks.
319 The support of several allocation schemes by carving specific ranges
320 within a name space and recycling should be explored for the future
321 mapping systems. The operations and ease of deployment should also
322 be considered as they may influence policy enforcement schemes
323 related to the allocation of IDfs of the use of relevant META.
325 4. Scopes
327 4.1. In Scope
329 The scope of this work is on the network layer (layer 3). The
330 network identities that may be alphanumerical are assumed to map to
331 numerical IDfs as in LISP, HIP or ILA. The LOCs are assumed to be
332 IPv4 or IPv6 addresses.
334 The META is assumed to be tied to the IDy or IDf and slow changing.
336 While the issues described in the document may be generalized to a
337 broader scope, IDEAS is focused on delivering functionalities at the
338 network layer only.
340 4.2. Out of Scope
342 The following are out of scope for this effort:
344 o The resolution or mapping of domain names or any application level
345 naming or directories (like URIs ...).
347 o META information with rapid changes
349 4.3. Future Studies
351 Other network addressing schemes may be considered for future
352 studies.
354 5. Relationship between IDEAS and other IETF Working Groups
356 This document is meant to encourage the IETF community to investigate
357 the opportunity of a new specification effort to address some
358 specific problems from an IDy Enabled Networks standpoint in general.
359 The focus is to find a common solution and infrastructure that can be
360 shared by current protocols and facilitate the introduction of new
361 IDy-based services while avoiding rehashing the same problems again
362 each time a new service pops up.
364 We propose to address these problems with a GeneRic IDentity Services
365 (GRIDS) infrastructure which includes standardized access and
366 multiple services. The services include secured registration,
367 discovery, updates with data integrity, mapping and resolution
368 capabilities, define relationships between identities or group of
369 identities, access control policy and security.
371 Some other working groups are already working to address some
372 specific limitations or enhancement of identifier-based protocols but
373 do not take IDy requirements as highlighted in this document into
374 consideration. These working groups include LISP, HIP and NVO3.
376 Protocols and architectures defined by these WGs may assume a mapping
377 system or other resolution techniques, but they are not currently
378 covering the other services mentioned in this document.
380 5.1. LISP WG
382 The LISP WG has been working on multiple mapping systems (ALT, DDT)
383 for the LISP control plane and the primary function of this mapping
384 system is to map and resolve the IDf to IP addresses (EID/RLOC
385 mapping). LISP WG is also looking at Casssandra and blockchain.
386 Though some requirements are common,GRIDS has new specific
387 requirements described in [IDEAS-REQ].
389 5.2. HIP WG
391 The HIP WG has based its IDy to IDf resolution service on DNS.
392 Operational IDf to Loc for fast mobility with low latency is handled
393 by HIP-RVS [RFC8005] and specific HIP Mobility Notification messaging
394 [RFC8046].
396 5.3. NVO3 WG
398 The NV03 WG has been working on a mapping of VN names to VN IDs in
399 the network virtualization space and their requirements differ from
400 the wireless broadband requirements and cross-silo communications
401 that have been mentioned in this document.
403 6. Companion Documents
405 There are three companion documents:
407 o Use Cases for Identity Enabled Networks [IDEAS-USE]
409 o Requirements for Generic Identity Services in Identity Enabled
410 Networks [IDEAS-REQ]
412 o Identity Use Cases in IDEAS [IDEAS-IDY]
414 o Gap Analysis for Identity Enabled Networks [IDEAS-GAP]
416 7. Security Considerations
418 Due to the sensitivity of IDy tied to IDf and LOC, there is a need to
419 pay attention to security ramifications. In particular, the security
420 goals should include confidentiality, possible encryption for
421 integrity of sensitive data and privacy.
423 8. IANA Considerations
425 This document has no actions for IANA.
427 9. Contributors
429 The following individuals (by first name alphabetical order) have
430 contributed to this document:
432 o Albert Cabellos
434 o Alex Clemm
436 o Dino Farinacci
438 o Georgios Karagiannis
440 o Jim Guichard
442 o Michael Menth
444 o Robert Moskowitz
446 o Tom Herbert
448 o Uma Chunduri
450 This present document is based on an extract of the first version of
451 the draft. The authors and their affiliations on the original
452 document are: D. Farinacci (lispers.net), D. Meyer (Brocade), D.
453 Lake (Cisco Systems), T. Herbert (Facebook), M. Menth (University
454 of Tuebingen), Dipenkar Raychaudhuri (Rutgers University) and Julius
455 Mueller (ATT).
457 10. Acknowledgments
459 The authors would like to thank Stewart Bryant, David Lake, Bingyang
460 Liu, Dave Meyer, Dipenkar Raychaudhuri, Yingzhen Qu, and Onur Ozan
461 Koyluoglu for their review and input on this document. The authors
462 would like to thank Jean-Michel Esnault, Renwei Li, Lin Han, Kiran
463 Makhijani Erik Nordmark, Burjiz Pithawala, and Jeff Tansura who
464 participated in numerous discussions.
466 This document was produced using Marshall Rose's xml2rfc tool.
468 11. Informative References
470 [IDEAS-GAP]
471 Qu, Y., Cabellos, A., Moskowitz, R., Liu, B., and A.
472 Stockmayer, "Identity Use Cases in IDEAS", July 2017,
473 .
476 [IDEAS-IDY]
477 Chunduri, U., Clemm, A., and M. Menth, "Identity Use Cases
478 in IDEAS", June 2017, .
481 [IDEAS-REQ]
482 Pillay-Esnault, P., Clemm, A., Farinacci, D., and D.
483 Meyer, "Requirements for Generic Resilient Identity
484 Services in Identity Enabled Networks", March 2017,
485 .
488 [IDEAS-USE]
489 Pillay-Esnault, P., Farinacci, D., Herbert, T., Jacquenet,
490 C., Lake, D., Menth, M., Meyer, D., and D. Raychaudhuri,
491 "Use Cases for Identity Enabled Networks", March 2017,
492 .
495 [ILA] Herbert, T., "Identifier-locator addressing for network
496 virtualization", March 2016,
497 .
500 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
501 Locator/ID Separation Protocol (LISP)", RFC 6830,
502 DOI 10.17487/RFC6830, January 2013,
503 .
505 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
506 Henderson, "Host Identity Protocol Version 2 (HIPv2)",
507 RFC 7401, DOI 10.17487/RFC7401, April 2015,
508 .
510 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
511 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
512 October 2016, .
514 [RFC8046] Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility
515 with the Host Identity Protocol", RFC 8046,
516 DOI 10.17487/RFC8046, February 2017,
517 .
519 Authors' Addresses
520 Padma Pillay-Esnault (editor)
521 Huawei
522 2330 Central Expressway
523 Santa Clara, CA 95050
524 USA
526 Email: padma.ietf@gmail.com
528 Mohamed Boucadair
529 Orange
530 Rennes 35000
531 France
533 Email: mohamed.boucadair@orange.com
535 Giuseppe Fioccola
536 Telecom Italia
538 Email: giuseppe.fioccola@telecomitalia.it
540 Christian Jacquenet
541 Orange
542 Rennes 35000
543 France
545 Email: christian.jacquenet@orange.com
547 Axel Nennker
548 Deutsche Telekom
550 Email: Axel.Nennker@telekom.de