idnits 2.17.1 draft-moskowitz-flexip-addressing-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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (January 30, 2019) is 1910 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Moskowitz 3 Internet-Draft HTT Consulting 4 Intended status: Informational GP. Li 5 Expires: August 3, 2019 S. Ren 6 Huawei 7 January 30, 2019 9 FlexIP Addressing 10 draft-moskowitz-flexip-addressing-00 12 Abstract 14 This memo proposes an unbounded Flexible Address Space (FAS), 15 consisting of a publicly routable Global Address Part (GP) and a 16 locally routable Local Address Part (LP). It expands GP and LP to 17 provide address privacy and special LP formats. Use cases are also 18 provided. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 3, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 58 2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Flexible Address System . . . . . . . . . . . . . . . . . . . 4 61 3.1. Infinite address space . . . . . . . . . . . . . . . . . 4 62 3.2. Textual representation . . . . . . . . . . . . . . . . . 5 63 3.3. Some Assignment Principles . . . . . . . . . . . . . . . 6 64 4. Expanding into the Flexible Address System . . . . . . . . . 6 65 4.1. Adding a MapID to the Local Part . . . . . . . . . . . . 6 66 4.2. FlexIP Addressing Privacy Concerns . . . . . . . . . . . 7 67 4.2.1. Address Privacy via a Cryptographic Mapping Function 7 68 4.3. Inbound FlexIP Address Considerations . . . . . . . . . . 8 69 4.4. Adding a MapID to the Global Part . . . . . . . . . . . . 8 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 8.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Appendix A. FlexIP Addressing Local Part Use Cases . . . . . . . 9 77 A.1. Case 1: FlexIP METrie as Local Forwarding Part . . . . . 9 78 A.2. Case 2: Layer 2 forwarding network . . . . . . . . . . . 10 79 A.3. Case 3: IPv4/IPv6 forwarding network . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 This memo defines a new IP address system, called the Flexible 85 Address System (FAS). Compared to the conventional fixed length IP 86 system, FAS is designed with 2 infinite address spaces, Global and 87 Local, that can support variable length IP addresses, called flexible 88 addresses. FAS has a global hierarchical structure of flexible 89 addresses from the perspective of management. This hierarchical 90 structure may also be used in a local part of FAS. 92 It proposes a number of different formats for the Local Part, 93 including IPv4/6 addresses and IEEE 802 48 and 64 bit MAC addresses 94 in addition to the unbounded FAS bit structure. 96 Further, it provides privacy of both the LP and customer bits of the 97 GP through the use of a MapID (MID). The MapID is explained for each 98 use case. It works differently when used for LP privacy than it does 99 for GP privacy. 101 1.1. Related Work 103 PIP [RFC1621] provided for variable length addresses so that the size 104 of the address could be adjusted to the demands of the particular 105 environment, and to ensure the ability to meet any future networking 106 requirements. PIP also made a distinction of identifier from 107 addresses. 109 FlexIP has parallels in PIP, but takes advantages in advancements in 110 Identities, routing, and provider networking. 112 2. Terms and Definitions 114 2.1. Requirements Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 2.2. Notations 122 || signifies concatenation of information - e.g., X || Y is the 123 concatenation of X and Y. 125 [x|y] Either x or y. 127 2.3. Definitions 129 DI (Device Identifier): The portion of the Local Part that 130 Identifies the device interface. 132 FAS (Flexible Address System): The unbounded address space of 133 FlexIP. 135 GP (Global Part): The globally routable portion of FAS. It is 136 textually represented to the left of a period in little endian 137 format. 139 GPF (Global Part Forwarding): The global routing of a FAS addressed 140 packet. 142 LP (Local Part): The locally routable portion of FAS. It is 143 textually represented to the right of a period in big endian 144 format. 146 LPF (Local Part Forwarding): The local routing of a FAS addressed 147 packet. 149 MID (MapID): Index into the address mapping function used to provide 150 address privacy. 152 OV (Obfuscated Value): The mapped value of the hidden address. 154 3. Flexible Address System 156 This section presents a new IP address system called Flexible Address 157 System (FAS), in which the IP addresses can be with variable length, 158 rather than the conventional fixed bits. 160 FlexIP FAS addresses can simply be viewed as composed of two parts: 161 Global (GP) and Local (LP). The Global part is represented in little 162 endian form (most significant adjacent to the period) and the Local 163 Part is big endian. 165 GP.LP 167 3.1. Infinite address space 169 From the perspective of address space management, flexible IP 170 addresses (Flex-IP) can simply be viewed as composed of two parts: 171 Global (GP) and Local (LP) Parts, as is shown below. 173 | 174 ...00 1 | 01 175 ...00 10 | 100 176 ...00 1010 | 0001 177 ...00 10010 | 100001 178 ...00 10010 | 1000010 179 ------------|------------- 180 Infinite Global Part | Infinite Local Part 182 Figure 1: Flexible address space and structure 184 Figure 1 shows the structure of flexible IP addresses, which are 185 represented in binary. A flexible IP address commonly consists of 186 two parts, the global part and the local part. The global prefix is 187 a network prefix used for management and assignment. Each specified 188 global prefix can be treated as a natural number. Thus, the number 189 of available global prefix equals to natural number domain. 191 While the local part is used to identify interfaces or hosts in a 192 certain subnet, along with any local routing prefix. The size of the 193 local part can be any bits, determined by the allocation strategies. 194 While for a specified subnet with delegated global part, its local 195 part should be with fixed bits and cannot be changed once assigned. 196 For different subnets, the size of their local parts can be same or 197 different. The local part consists of several units, which further 198 consists of one bit or several bits. The length of the local part 199 should be an integer multiple of the unit size. The size of unit can 200 be any length but should be defined uniformly. 202 Theoretically, both the global part and local address part are 203 infinite. The FAS address space can be expanded on demand and will 204 never be exhausted. Ideally, if unit size is set to 1 bit, FAS 205 address space can evolve completely smooth, bit-by-bit. Even with a 206 bigger unit, FAS address space is still infinite and there is no need 207 to prescribe a fixed or maximum length of the address space. 209 3.2. Textual representation 211 The global part can also be split into several units. If there is an 212 aliquant part when splitting, add auxiliary zeros on the left side. 213 Then, by representing each unit as a decimal number, a flexible IP 214 address can be represented textually with the conventional dotted- 215 decimal form. For example, as depicted in Figure 2, with 4bits as 216 unit size, a 10bits address 10 0100 0110 with the first two bits as 217 global part can be transformed to a 12bits address 00 10 0100 0110 by 218 adding two auxiliary bits of zeros on the left side. Then it can be 219 further expressed in a textual format as 2.4.6. Moreover, this 220 address can also be expressed as 0.2.4.6, or even 0.0.2.4.6, which 221 may provide more convenience in some cases like the routing lookup in 222 the following sections. 224 Binary Dotted decimal 226 Effective address 10 0100 01 10 --> 2.0.0 227 -------------------------------------------------------- 228 Expressional address 0010 0100 0110 --> 0.2.0.0 229 0000 0010 0100 0110 0.0.2.0.0 231 Figure 2: Textual representation for FAS 233 For easy understanding and description, the binary address 10 0100 234 0110 is called an effective address with 10 bits effective length. 235 While 00 10 0100 0110 and 0.2.4.6 are called expression addresses 236 with 12 bits expression length. For special cases, the corresponding 237 decimal dotted address 2.4.6 is called an effective address when 238 described with 10bits effective length and called expression address 239 when described with 12bits expression length. This document will 240 take 8 bits as the unit size to accommodate the custom of IPv4. 242 3.3. Some Assignment Principles 244 The FAS address should be centralized allocated by some organization 245 liken IANA. When allocating an address block to a company or an 246 organization, the value of the global part should be specified. 248 If the assigner is a Network Service Provider, they can further 249 extend their global part to support their customers. If they have 250 multiple entries into their network and need to advertise different 251 GP lengths, this will have an impact on the RIBs. 253 4. Expanding into the Flexible Address System 255 This simple view of a two-branched tree of addresses for FAS is a 256 gross simplification as it hides complexities in both parts. A 257 simple view of the Global Part is that of an unbounded hierarchy to 258 facilitate packet forwarding (GPF) between multiple public 259 connectivity providers. The Local Part minimally contains a local 260 packet forwarding (LPF) hierarchy and a device 'interface' identifier 261 (DI). This is the simplest case for the Local Part. The following 262 expands to a deeper view of both parts. 264 4.1. Adding a MapID to the Local Part 266 A MapID (MID) provides an access mechanism to support a different 267 presentation of the Local Part to the Global network. The intention 268 is to either provide privacy of the local part to the global network, 269 or to provide address transformation of FlexIP global addresses to 270 some local addressing structure. A later section will describe using 271 the MID in the Global Part. 273 MID applies to inbound processing at the local network border router. 274 It is the index to a table that defines the mapping function (e.g. 275 lookup or math transform function) and any associated information 276 (e.g. key value). Within the local network, MID has no meaning 277 (Appendix A.1 below). 279 The MID has local significance and of no semantic value to the global 280 FlexIP network nor to other local networks. Thus its size cannot 281 easily be fixed. Although there are use cases where its length could 282 be zero (only a single mapping ever used), it is strongly recommended 283 it always be present and its length be 8 bits. It is the privacy 284 mapping function that requires multiple values (see Section 4.2). 286 Appendix A.3, below, presents an argument for global significance for 287 MID for potentially one value (e.g. MID=0). 289 4.2. FlexIP Addressing Privacy Concerns 291 A desired goal with FlexIP is to mask information about devices on 292 the local network. This includes and is not limited to the Device 293 Identifier and Local Forwarding Part. Not only is it desirable to 294 stop a network observer from linking all traffic from a device by 295 observing the DI portion of the address but also from learning about 296 the local network design and what devices are, network-wise, close by 297 sharing the same local forwarding information. 299 There are two ways to obfuscate the LFP + DI address portion on the 300 global network. The most commonly used is a mapping approach where a 301 gateway device stores the mapping of local to global addressing to 302 produce an Obfuscated Value (OV). The oldest, NAT, typically employs 303 a many-to-one map (except for applications like PASV FTP). Others 304 include one-to-one mapping and encapsulation. A second approach is a 305 reversible function that transform the local to an obfuscated value. 306 Packets are transformed bidirectionally as they cross the local 307 gateway. 309 To facilitate mappings choices in Local Part content a MapID (MID) is 310 included as the first portion of the LP. 312 Thus at this point we view the FlexIP address as: 314 Locally - GP.LFP||DI 315 Globally - GP.MID||OV 317 4.2.1. Address Privacy via a Cryptographic Mapping Function 319 Consider function F where: 321 F(K, LFP||DI) = OV 322 and 323 F'(K, OV) = LFP||DI 325 To provide privacy, K should change over time or some function based 326 on packet content inspection. To accommodate multiple, concurrent 327 values of K, multiple MIDs are needed. The nature of F is unknown at 328 this point. Since Len(LFP||DI) is small and even variable within a 329 local network, many current cryptographic functions are not safe to 330 use. Research is needed to find a safe function for this purpose. 331 The actual function used will influence the nature of K lifetime and 332 thus how many may exist at a given time. If MID reuse is allowed, 8 333 bits should be sufficient. 335 4.3. Inbound FlexIP Address Considerations 337 Devices that do not have native FlexIP addressing support, will 338 require a network mapping that presents FlexIP addresses in a format 339 understood by the device. This is a highly local consideration. It 340 should present a one-to-one mapping of global to local. 342 4.4. Adding a MapID to the Global Part 344 A MID can also be used in the Global Part. For example a provider 345 may provide a privacy service to a customer by frequently changing 346 the OV. In this case the address may be: 348 GFP||MID||OV.LP 350 There are a number of limitations in using this approach. It may not 351 be viable if the customer needs outward-facing servers that are 352 discoverable via DNS. 354 5. IANA Considerations 356 FAS will need an IP version number assignment. The FAS header may 357 have TLVs to manage. 359 IANA may responsible for some level of FAS GP allocation. 361 6. Security Considerations 363 Address privacy is a major component of FAS, thus a careful 364 evaluation of all address mapping methods is required. Were a 365 gateway performs table mappings between internal and external 366 addresses, attention is needed ensure the privacy of the mapping 367 table. Where mapping is achieved via a crypto function, there are a 368 different set of privacy concerns. 370 Further, lifetime of use of an address needs to be a factor. 371 Mappings should change regularly to minimize the attack of tracking 372 flows with the same OV. 374 7. Acknowledgments 376 TBD 378 8. References 380 8.1. Normative References 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, 384 DOI 10.17487/RFC2119, March 1997, 385 . 387 8.2. Informative References 389 [RFC1621] Francis, P., "Pip Near-term Architecture", RFC 1621, 390 DOI 10.17487/RFC1621, May 1994, 391 . 393 Appendix A. FlexIP Addressing Local Part Use Cases 395 A.1. Case 1: FlexIP METrie as Local Forwarding Part 397 A local network may deploy the full capability of the FlexIP METrie 398 in its own internal tree. In this case there can be three levels in 399 the addresses and two MapIDs: 401 GP.MID1||LFP1||MID2||LFP2||DI 403 In this example, LFP2 may be as in case 3 below. 405 It is possible to consider this as an infinite process of "layers of 406 an onion", but it is best practice to only carry this to a global 407 METrie and a single local METrie. One valuable benefit of this case 408 is the two levels of mappings which provides a level of privacy 409 between portions of the local network. 411 A simpler instance of local METrie use may be: 413 GP.MID||LFP||DI 415 Where GP and LFP are separated instances of the unbounded addressing 416 and independent METrie trees. 418 A.2. Case 2: Layer 2 forwarding network 420 There are two common layer 2 technologies for packet forwarding: IEEE 421 802.1 and 802.15.10. 802.1 can be used on an 802.3/802.11 deployment 422 and 802.15.10 on an 802.15.4 deployment. In such a network, LFP may 423 be null. The DI would typically be the device MAC address and thus, 424 a privacy mapping can be critical (don't expose the MAC address of a 425 camera that has a known security flaw). The DI could also be an IPv6 426 Link Local address. The FE80::/10 prefix need not be included in the 427 mapping. 429 Packets outbound from the local network will have some destination 430 internal address that the border router maps to the global FlexIP 431 address. 433 Packets inbound to the local network need to source addresses mapped 434 at the border router to the internal addressing format. Without 435 other knowledge, nothing is known about inbound packet source 436 addresses. 438 A.3. Case 3: IPv4/IPv6 forwarding network 440 As IPv4 and IPv6 addressing naturally can be viewed as LFP||DI, they 441 can directly replace those portions of a FlexIP address. This allows 442 for legacy networks to participate in FlexIP and for FlexIP to be 443 used as the global infrastructure for an IPv4/v6 service provider. 444 The address appears as: 446 GP.MID||[IPv4|IPv6] 448 Border gateway address processing is similar to Case 2. Global 449 agreement on a MID value to represent this case (e.g. MID=0) could 450 facilitate FlexIP infrastructure to be the connectivity between 451 legacy IPv4/v6 networks. 453 Authors' Addresses 455 Robert Moskowitz 456 HTT Consulting 457 Oak Park, MI 48237 459 Email: rgm@labs.htt-consult.com 460 Guangpeng Li 461 Huawei 462 Beijing 100095 463 China 465 Email: liguangpeng@huawei.com 467 Shoushou Ren 468 Huawei 469 No. 156 of Beiqing Road, Haidian District 470 Beijing 100095 471 China 473 Email: renshoushou@huawei.com