idnits 2.17.1 draft-herbert-idgroups-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 339: '...entifier to member identifiers MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 3, 2018) is 2272 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? 'RFC3513' on line 132 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Experimental Quantonium 4 Expires: August 2018 6 February 3, 2018 8 Identifier groups 9 draft-herbert-idgroups-00 11 Abstract 13 This draft describes a means to create logical identifier groups to 14 manage identifiers in a mapping system for identifier-locator 15 protocols. An identifier group consists of identifiers that have 16 similar properties in the context of the mapping system. Identifier 17 groups facilitate bulk operations on the mapping system that would 18 affect multiple identifiers. A primary use case for this is to 19 facilitate mobility of devices that are associated with possibly 20 thousands or even millions of identifiers. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2 Characteristics of identifiers . . . . . . . . . . . . . . . . 3 62 2.1 Identifier addresses . . . . . . . . . . . . . . . . . . . . 3 63 2.2 Desired properties . . . . . . . . . . . . . . . . . . . . . 4 64 2.2 Policy mechanisms for identifiers . . . . . . . . . . . . . 4 65 3 Structure of identifier groups . . . . . . . . . . . . . . . . 5 66 4 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1 Management interface . . . . . . . . . . . . . . . . . . . . 7 68 4.2 Query interface . . . . . . . . . . . . . . . . . . . . . . 7 69 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 8 70 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 71 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 7.1 Normative References . . . . . . . . . . . . . . . . . . . 10 73 7.2 Informative References . . . . . . . . . . . . . . . . . . 10 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1 Introduction 78 This document describes identifier groups for identifier-locator 79 mapping systems. 81 Identifier-locator protocols include the concept of identifiers as a 82 type of node addressing. Identifiers are logical endpoints of 83 communications and only differ from canonical addresses in that they 84 are not topological. A node may be assigned multiple ephemeral 85 identifiers so that they be can used to create different source 86 addresses for different communications to benefit privacy and 87 anonymity. It is expected that individual end devices may have 88 thousands of active ephemeral identifiers; a device that connects 89 backend subnets could have millions of associated identifiers. 91 An identifier-group is an group of identifiers within a mapping 92 system that share some common properties. A grouping is arbitrary, 93 the given application or mapping system may create identifier groups 94 as needed. An identifier may belong to multiple groups, however when 95 an operation is performed it must be clear as to which group 96 applicable properties are be derived from. Groups may also be 97 hierarchical such that groups may be members of other groups and thus 98 inherit properties from their parent groups. 100 A primary application of identifier groups is mobility where a device 101 has a number of identifiers associated with it. When such a device 102 moves in the network and is assigned a new locator, all of the 103 identifiers associated with the device assume the new locator also. 104 Identifier groups provide a level of indirection so that the locator 105 can be set for all of the associated identifiers for the device in a 106 single operation on the mapping system. 108 2 Characteristics of identifiers 110 This section list some salient properties of identifiers that are 111 relevant to a mapping system and privacy. 113 2.1 Identifier addresses 115 Identifier addresses are full IP addresses that are either an 116 identifier or contain an identifier as part of the address. 117 Identifier addresses are used by endpoints to achieve communications. 118 In order to reach the end host where the node indicated by an 119 identifier resides, somewhere in the path an identifier-locator 120 operation is performed and the packet is typically modified (either 121 by encapsulation or address translation) to reach the correct node. 122 At the destination node, a reverse operation is done to restore the 123 originally sent packet before presenting the packet to the end node 124 or application. 126 Identifier addresses should have the following properties: 128 2.2 Desired properties 130 o They are composed of a global routing prefix and a suffix that 131 is internal to an orgnization. This is the same property for IP 132 addresses [RFC3513]. 134 o The registry and organization of an address can be determined by 135 the network prefix. This is true for any global address. 137 o The organizational bits in the address should have minimal 138 hierarchy to prevent inferences. It might be reasonable to have 139 an internal prefix that divides identifiers based on broad 140 geographic regions, but detailed information such as location, 141 department in an enterprise, or device type should not be 142 encoded in a globally visible address. 144 o Given two identifier addresses and no other information, the 145 desired properties of correlating them are: 147 o It can be inferred if they belong the same organization and 148 registry. This is true for any two global IP addresses. 150 o It may be inferred that they belong to the same broad 151 grouping, such as a geographic region, if the information is 152 encoded in the organizational bits of the address. 154 o No other correlation can be established. For example, it 155 cannot be inferred that the IP addresses address the same 156 device, the IP addresses reside in the same subnet or 157 department, or that the nodes for the two addresses have any 158 geographic proximity to one another. 160 2.2 Policy mechanisms for identifiers 162 Other than a globally routable network prefix, identifier addresses 163 require no hierarchy since they are not topological. Therefore all or 164 most of the organizational bits in a publicly visible address form a 165 flat, non-hierarchical space. To create identifier addresses with the 166 properties listed above, the bits in this space are pseudo-randomly 167 assigned to form addresses. 169 While the routing requirements are satisfied by the identifier- 170 locator protocols and mapping system, the lack of internal hierarchy 171 in addresses is a potential disruption for network deployments that 172 rely on address hierarchy to implement policy. For instance, an 173 enterprise might implement a firewall rule base on destination 174 network prefix that prevents the engineering department from talking 175 to human resources. 177 In order to apply such policies and still maintain the properties to 178 prevent inference, a firewall could create rules based on identifier 179 groups. So when a packet arrives at the firewall, the mapping system 180 may be consulted and information for a group is returned. A policy 181 decision, i.e. forward or drop, may be made per this information. 183 In the example above, identifier groups might be created for 184 engineering and human resources. The policy is expressed that members 185 of the engineering group are not allowed to send to members human 186 resources group. Since the groups are not encoded in the addresses 187 there is no means for an external party to infer which packets belong 188 to engineering and which belong to human resources. This is a privacy 189 benefit compared to common method of encoding the department in the 190 address hierarchy. An additional benefit is that such groupings are 191 arbitrarily flexible and are not constrained by the need to format 192 information into addresses (address prefixes for instance). Since the 193 addresses don't contain group information, group membership can be 194 changed for an address without requiring the node to change its 195 address. 197 3 Structure of identifier groups 199 Identifier groups can form a hierarchical structure within a mapping 200 system domain. The diagram below illustrates a hierarchy containing 201 two levels of groups and six identifier mapping entries at the 202 leaves. 203 +-------+ 204 | | 205 | Group | 206 | | 207 +---+---+ 208 | 209 +------------+ +-----+-----+ +------------+ 210 | Identifier |---+ | | +---| Identifier | 211 +------------+ | +---+---+ +---+---+ | +------------+ 212 +------------+ | | | | | | +------------+ 213 | Identifier |---+--| Group | | Group |--+---| Identifier | 214 +------------+ | | | | | | +------------+ 215 +------------+ | +-------+ +-------+ | +------------+ 216 | Identifier |---+ +---| Identifier | 217 +------------+ +------------+ 219 The diagram below provides an explicit example of using an identifier 220 group hierarchy for mobility. 222 In this scenario, we consider a bus has an onboard WIFI network. 223 There are two UEs attached to the WIFI, where both have been assigned 224 three identifiers. 225 +----------+ 226 | WIFI | 227 | Bus | 228 | Locator | 229 +-----+----+ 230 | 231 +------------+ +-----+-----+ +------------+ 232 | Identifier |--+ | | +---| Identifier | 233 +------------ | +-----+---+ +---+-----+ | +------------+ 234 +------------+ | | UE | | UE | | +------------+ 235 | Identifier |--+--| Locator | | Locator |--+---| Identifier | 236 +------------+ | | | | | | +------------+ 237 +------------+ | +---------+ +---------+ | +------------+ 238 | Identifier |--+ +---| Identifier | 239 +------------+ +------------+ 241 In this hierarchy, each UE has an associated group that contains all 242 the identifiers for the UE. The WIFI device has an associated group 243 that contains the groups for the attached UE devices. With this 244 structure, each identifier has two locator mappings. The first one 245 maps the identifier to the WIFI device in the bus. The second maps 246 the identifier to the UE attached to the WIFI network. 248 When a packet from an external network is sent to one of the 249 identifiers, the mapping system is consulted to retrieve the top 250 level locator to forward the packet. This locator will direct the 251 packet to the WIFI router on the bus. At the bus WIFI router, the 252 second level locator mapping for the identifier is consulted to 253 determine the locator of the UE that has the identifier. The 254 resultant locator is used to forward the packet to the appropriate UE 255 device. At the UE, the identifier is used to deliver the packet to 256 the appropriate application. 258 As the bus moves through a mobile network, the locator for the WIFI 259 changes so effectively the top level locator for all the identifiers 260 for all the UEs within the bus also must be changed. Identifier 261 groups allow this to be done in one operation on the mapping system. 262 When passengers disembark and leave the range of the WIFI, the group 263 membership of the UE is disassociated from the WIFI bus group. The UE 264 may attach to another network so that the locator or group membership 265 for the UE would be set appropriately. 267 Note that in the above example, an identifier group hierarchy is used 268 to create a locator hierarchy. That is, multiple identifier locator 269 operations are performed to get packets to destination. This is 270 expected to be common in identifier-locator deployments. It is 271 analogous to a packet going through a routing hierarchy where at each 272 level the information applied became progressively more specific to 273 the final destination (i.e. at each layer the prefix match is 274 longer). 276 4 Interfaces 278 The mapping system interface is logically divided into the management 279 interface and the query interface. 281 4.1 Management interface 283 The management interface is used to create and manipulate mapping 284 entries and identifier groups. 286 The allowed operations on the management interface are: 288 o Create groups 290 o Set properties of a group, such as a locator or membership in 291 another group in a group hierarchy 293 o Change properties of a group 295 o Create identifier mapping entries 297 o Set identifier mapping properties such as locator or group 298 membership 300 o Change identifier mapping properties 302 o Delete an identifier mapping entry 304 o Remove all members from a group 306 o Delete all identifier mappings in a group 308 o Delete a group (that has no members) 310 Note that there is no public interface defined that will return all 311 the members of a group. This is intended to limit visibility to this 312 sensitive information. 314 4.2 Query interface 315 The query interface is used by devices that require identifier to 316 locator mappings. This interface is read-only. 318 The basic operations in the query interface are: 320 o Lookup locator for an identifier. In the case that a group 321 hierarchy is present, the lookup request includes an indication 322 as to which level in the hierarchy is applicable. 324 o Lookup group information by group identifier. This is needed if 325 the entry returned in a mapping entry indicates a group in a 326 level of indirection. The internal structure for mapping entries 327 which are members of the same group may reference a single group 328 structure. 330 o Request notifications of mapping entry changes if the mapping 331 system supports pub/sub model. This includes notifications that 332 a group membership has changed. 334 o Request notifications of group changes. For example, if the 335 locator for an identifier group changes. 337 5 Security Considerations 339 Access to mappings of group identifier to member identifiers MUST be 340 strictly controlled. If this information is compromised, then privacy 341 and anonymity of users could be undermined. In the case that the 342 group identifiers refer to a single device, such as a UE in a mobile 343 network, breach of the mapping from group identifier to identifiers 344 may be sufficient to compromise individual user identities. Note that 345 these concerns are not specific to identifier-locator mapping 346 systems, but in any scenario where address assignment is done for 347 devices. 349 The management interface should provide very strong authorization and 350 employ encryption when communicating with the mapping system. The 351 mapping system should enable security mechanisms associated with 352 databases that contains sensitive information. 354 The query interface is always read-only, however this should also 355 have strong access authorization methods for security and privacy. 357 A distributed identifier-locator mapping system should be deployed 358 within a single administratively controlled domain. Low level 359 information that potentially contains PII (Personally Identifiable 360 Information) or specific location information should never be shared 361 between administrative domains. It is conceivable that two networks 362 could share a high level identifier-locator mapping system distinct 363 from their internal systems to support cross domain identifier- 364 locator mappings. In this case, a locator hierarchy would be employed 365 so as not to reveal any detailed information or PII. Specifically, 366 identifier group information that refers specific devices and end 367 locators for specific devices should not be visible. 369 6 IANA Considerations 371 7 References 373 7.1 Normative References 375 7.2 Informative References 377 Author's Address 379 Tom Herbert 380 Quantonium 381 Santa Clara, CA 382 USA 384 Email: tom@quantonium.net