idnits 2.17.1 draft-herbert-ila-mobile-01.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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2018) is 2241 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MN' is mentioned on line 213, but not defined == Outdated reference: A later version (-01) exists of draft-herbert-intarea-ila-00 -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 4641 (ref. 'RFC4941') (Obsoleted by RFC 6781) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Informational Quantonium 4 Expires: September 2018 K. Bogineni 5 Verizon 7 March 6, 2018 9 Identifier Locator Addressing for Mobile User-Plane 10 draft-herbert-ila-mobile-01 12 Abstract 14 This document discusses the applicability of Identifier Locator 15 Addressing (ILA) to the user-plane of mobile networks. ILA allows a 16 means to implement network overlays without the overhead, 17 complexities, or anchor points associated with encapsulation. This 18 solution facilitates highly efficient packet forwarding and provides 19 low latency and scalability in mobile networks. ILA can be used in 20 conjunction with techniques such as network slices and Network 21 Function Virtualization to achieve optimal service based forwarding. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2 Conventions and Terminology . . . . . . . . . . . . . . . . . . 5 62 3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4 Reference topology . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1 ILA routers (ILA-R) . . . . . . . . . . . . . . . . . . . . 6 65 4.1.1 Forwarding routers . . . . . . . . . . . . . . . . . . . 7 66 4.1.2 Mapping resolution . . . . . . . . . . . . . . . . . . . 7 67 4.2 ILA forwarding nodes (ILA-N) . . . . . . . . . . . . . . . . 7 68 4.2.1 ILA to SIR address transformation . . . . . . . . . . . 7 69 4.2.2 ILA forwarding . . . . . . . . . . . . . . . . . . . . . 8 70 4.3 ILA hosts (ILA-H) . . . . . . . . . . . . . . . . . . . . . 8 71 4.4 ILA management (ILA-M) . . . . . . . . . . . . . . . . . . . 9 72 5 Data plane operation . . . . . . . . . . . . . . . . . . . . . . 9 73 5.1 SIR to ILA transformation . . . . . . . . . . . . . . . . . 10 74 5.2 ILA to SIR transformation . . . . . . . . . . . . . . . . . 11 75 5.3 Data path efficiency . . . . . . . . . . . . . . . . . . . . 11 76 5.4 Alternative data path use cases . . . . . . . . . . . . . . 12 77 5.5 Locator chaning . . . . . . . . . . . . . . . . . . . . . . 12 78 5.6 ICMP handling . . . . . . . . . . . . . . . . . . . . . . . 12 79 6 Control plane . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 6.1 ILA router mapping database . . . . . . . . . . . . . . . . 13 81 6.1.1 ILA with BGP . . . . . . . . . . . . . . . . . . . . . . 13 82 6.1.2 Key/value store . . . . . . . . . . . . . . . . . . . . 13 83 6.2 ILA Mapping Protocol . . . . . . . . . . . . . . . . . . . . 13 84 6.3 Address assignment . . . . . . . . . . . . . . . . . . . . 14 85 6.3.1 Singleton address assignment . . . . . . . . . . . . . . 14 86 6.3.2 Network prefix assignment . . . . . . . . . . . . . . . 14 87 7 ILA in 5G networks . . . . . . . . . . . . . . . . . . . . . . 15 88 7.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15 89 7.2 Protocol layering . . . . . . . . . . . . . . . . . . . . . 16 90 7.3 Control plane between ILA and network . . . . . . . . . . . 16 91 7.4 ILA and network slices . . . . . . . . . . . . . . . . . . . 17 93 8 Security considerations . . . . . . . . . . . . . . . . . . . . 18 94 8.1 Data plane security . . . . . . . . . . . . . . . . . . . . 18 95 8.2 Control plane security . . . . . . . . . . . . . . . . . . . 19 96 8.3 Privacy in address assignment . . . . . . . . . . . . . . . 20 97 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 9.1 Normative References . . . . . . . . . . . . . . . . . . . 21 99 9.2 Informative References . . . . . . . . . . . . . . . . . . 22 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 102 1 Introduction 104 In mobile networks, mobility management systems provide connectivity 105 while mobile nodes move around. A control-plane system signals 106 movements of a mobile node, and a user-plane establishes tunnels 107 between mobile nodes and anchor nodes over IP based backhaul and core 108 networks. 110 This document discusses the applicability of Identifier Locator 111 Addressing (ILA) to those mobile networks. ILA is a form of 112 identifier/locator split where identity and location of a node are 113 disassociated in IP addresses. ILA nodes transform destination 114 addresses of packets by overwriting part of the address with a 115 locator. The locator provides the topological address for forwarding 116 a packet towards its destination. Before a packet is delivered to the 117 end destination, the destination address is reverted to its original 118 value. 120 An ILA mobile user-plane implementation needs both data plane and 121 control plane components. 123 The data plane includes the ILA transformation processing as well as 124 handling to maintain conformance with IP protocols. The ILA data 125 plane is described in [ILA]. 127 The control plane's primary function is to maintain a mapping 128 database that is shared amongst ILA nodes. The mapping database 129 contains entries for the mobile nodes in the network, and the number 130 of mapping entries is expected scale into the billions. In order to 131 scale, a two level hierarchy of ILA nodes is defined by ILA routers 132 and ILA forwarding nodes. 134 ILA routers maintain a full set of ILA mappings. Routers may be 135 replicated for redundancy and load balancing. The mapping system may 136 also be sharded, so that each router is responsible for a shard. 137 Routers use a protocol to synchronize the mappings for each shard. 139 ILA forwarding nodes perform a reverse ILA transformations to restore 140 the destination address in packets before delivery. A forwarding node 141 can also maintain a cache of ILA mappings to perform transformations 142 on intra domain traffic as an optimization to avoid having to forward 143 packets through ILA routers. Forwarding nodes are typically located 144 close to the mobile nodes. The ILA Mapping Protocol [ILAMP] is used 145 between forwarding nodes and ILA routers to manage the cache. 147 2 Conventions and Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 ILA related terms are defined in [ILA]. 155 3 Motivation 157 Emerging applications such as VR, AR, and autonomous vehicle 158 communication require very low latency, high bandwidth, and high 159 reliability. For mobile devices, these requirements must not only be 160 met when the device is stationary, but also across handover during 161 mobile events. Mobility needs to be a seamless operation where IP 162 addresses and connections are maintained. In a second dimension, the 163 number of connected mobile devices, including a large contingent of 164 IoT devices, is expected to grow by several orders of magnitude 165 within a few years as enabling technologies such as 5G are deployed. 167 The convergence of mobile networks and datacenter networks is also 168 pertinent. Simple physics (i.e. speed of light) dictates that very 169 low latency for applications (order of less than five milliseconds) 170 can only be achieved by placing application servers in close 171 proximity to clients and minimizing the number of network hops. An 172 emerging trend is for providers to house datacenters within the 173 network to run applications. For similar reasons, many providers are 174 integrating multi-tenant cloud services directly in their mobile 175 networks. The upshot is that mobile networks need to support the 176 convergence of mobile devices, datacenter virtualization, and cloud. 177 A single solution framework for all of this is desirable. 179 Current mobile architecture is hitting the limits of scalability and 180 performance. In particular, anchor points used in 3GPP have become 181 single points of failure, bottlenecks, and lead to sub-optimal 182 triangular routing. The anchor model is also inflexible in attempts 183 to leverage services of the transport network such as network slices 184 and Network Function Virtualization. The control plane to manage 185 millions of GTP tunnels is complex and difficult to scale. GTP-U is 186 narrowly defined for a particular use case, which makes it difficult 187 to leverage for other use cases. The use of any in-network tunneling, 188 including GTP, raises issues of overhead, MTU and fragmentation, 189 security, and other complexities. 191 ILA is a proposed alternative to GTP-U and encapsulation. It does not 192 require anchors and simplifies both the data plane and control plane. 193 ILA has zero wire overhead so there are no issues around MTU and 194 fragmentation. Its use is transparent to the network, and it is 195 compatible with existing hardware and commonly deployed protocol 196 optimizations. ILA is a general network overlay protocol to meet the 197 requirements of use cases in a converged network. User Plane 198 Functions (UPF) with ILA are lightweight and stateless such that they 199 can be brought up quickly as needed. 201 4 Reference topology 203 Figure 1 shows an example topology of ILA in a mobile network. 205 [MN] O---------------O 206 | | App Server | 207 ___v___ | | 208 / Radio \ o-------o | +--------+ | 209 / Access \==| ILA-N | | | ILA-H | | 210 \ NW / o-------o | +--------+ | o-------o 211 \________/ \ O---------------O | ILA-M | 212 \ || o-------o 213 [MN] \ ______||__ 214 | \ / \ 215 ___v___ \ / \ ________ 216 / Radio \ o-------o / \ o-------o / \ 217 / Access \==| ILA-N |==/ IPv6-Only \==| ILA-R |==/ DN \ 218 \ NW / o-------o \ Network / o-------o \(Internet)/ 219 \________/ \ / \________/ 220 \ / 221 \__________/ 223 Figure 1: Mobile User-plane with ILA 225 There are four types of functional nodes in the ILA architecture: 227 o ILA routers (ILA-R) 229 o ILA forwarding nodes (ILA-N) 231 o ILA hosts (ILA-H) 233 o ILA managment (ILA-M) 235 4.1 ILA routers (ILA-R) 237 ILA routers are deployed within the network infrastructure and 238 collectively contain a mapping database of all identifier to locator 239 mappings in an ILA domain. The database may be sharded across the 240 identifier space by some number of ILA routers for scalability. ILA 241 routers may also be replicated for scalability and availability. 243 ILA routers provide two main functions: ILA forwarding and mapping 244 resolution. An ILA router may perform one both of these functions at 245 the same time. If a router performs both functions it may send ILA 246 redirects. 248 4.1.1 Forwarding routers 250 Forwarding routers perform ILA transformations when packets enter an 251 ILA domain. A destination address of a packet that is a SIR address 252 is transformed to an ILA address. The process is that the router 253 performs a lookup on the destination address in a mapping table and a 254 locator is returned. The locator is written into the destination 255 address of the packet (typically the high order sixty-four bits are 256 overwritten with a locator). 258 In the case of a sharded database, the high order bits of the 259 identifier indicate the shard number. This is included in a routing 260 prefix so that the packet is routed to an ILA router that contains 261 the database for the indicated shard. 263 4.1.2 Mapping resolution 265 An ILA router that is performing mapping resolution will respond to 266 mapping requests from ILA forwarding nodes or ILA hosts (these are 267 described below). The mapping request protocol allows the caller to 268 request the locator for an identifier address. 270 4.2 ILA forwarding nodes (ILA-N) 272 ILA forwarding nodes are deployed in the network infrastructure 273 towards the edges to provide ILA transformations for end devices. ILA 274 forwarding nodes have two functions: ILA to SIR address 275 transformation and ILA forwarding. As indicated in the reference 276 topology, forwarding nodes may be deployed near the point of device 277 attachment (e.g. base station, eNodeB) of mobile nodes. 279 4.2.1 ILA to SIR address transformation 281 In the path towards the end devices, forwarding nodes perform ILA to 282 SIR address transformation. That is, they perform a reverse ILA 283 transformation in order to restore the original addresses in packet. 284 Forwarding the packet on to the destination is done based on the SIR 285 address. For instance, an eNodeB may map a SIR address to a layer 2 286 address of the attached device that has the SIR address. Note that 287 this functionality is required somewhere in the path between the ILA 288 node that writes a locator into an address and the ultimate 289 destination device (e.g. a UE). It is not recommended that this 290 functionality is implemented on end user devices. 292 When a node migrates its point of attachment from one ILA-N to 293 another, the local mapping on the old ILA-N is removed. If an ILA 294 addressed packet is received by an ILA-N for which there is no local 295 mapping, then the packet is forwarded back into the network with a 296 destination SIR address. The packet should be forwarded through an 297 ILA router that can perform the tansformation for the new ILA-N. A 298 "negative" mapping with timeout may also be set in an ILA-N to ensure 299 that ILA-N is able to infer the SIR address (e.g. would be needed 300 with non-local identifiers). 302 4.2.2 ILA forwarding 304 A forwarding node may perform ILA transformation and forward packets 305 directly to peer ILA nodes in the same domain. The mappings for this 306 are maintained in a working set cache in each ILA-N. As a cache there 307 must be methods to populate, evict, and timeout entries. A cache is 308 considered an optimization, so the system should be functional 309 without its use (e.g. if the cache has no entries). The possibility 310 of Denial of Service attack (DOS) on a cache being populated by 311 unmanaged outside events, in this case mobile devices sending packets 312 to arbitrary destinations, must be considered in the cache design. 314 If a packet is received by an ILA forwarding node from a downstream 315 node that is destined to another node in the same ILA domain for 316 which there is no existing cache entry, then: 318 o The packet is forwarded by address. The SIR address plus shard 319 identifier prefix will route the packet to a forwarding ILA 320 router which will perform ILA transformation of the packet to 321 reach its destination. 323 o An ILA router may return an ILA redirect to inform the 324 forwarding node of a direct ILA mapping. 326 o If the forwarding node gets a mapping from an ILA router, then 327 subsequent packets for the destination can be directly sent 328 using the mapping. Note that a forwarding node does not hold 329 packets that are pending mapping resolution. 331 4.3 ILA hosts (ILA-H) 333 ILA host are forwarding nodes that are embedded in end servers to 334 provide ILA transformation. Since an ILA host is integrated with the 335 host stack sourcing packets, there are opportunities for optimizing 336 processing. 338 ILA is not recommended to run on end user devices, however there may 339 be servers or other end devices that are in the provider network that 340 might benefit from participating in ILA (this is illustrated in the 341 reference topology above). A server that implements ILA forwarding 342 can directly send to ILA peers in the same domain to avoid triangular 343 routing. 345 4.4 ILA management (ILA-M) 347 The ILA management node provides the interface between the ILA 348 infrastructure and mobile management of a network. Similar to ILA-Rs 349 there may be multiple ILA-Ms in the network and they can be 350 replicated for redundancy and load distribution. Data managed by ILA- 351 Ms needs to be synchronized across ILA-Ms. It is conceivable that the 352 set of ILA-Ms could be split into shards serving different geographic 353 area in order to localize data. ILA-Ms may be co-located with ILA-Rs 354 so that there is a fast path between them. 356 The management nodes are responsible for: 358 o Receiving notifications from the session management in the 359 mobile network. Notifications of interest include: when mobile 360 nodes attach to the network, are removed from the network, or 361 change their point of attachment in the network (i.e. they 362 move). 364 o Managing identifier groups. Identifier groups are sets of 365 identifiers (nodes) that share common properties [ILAGRPS]. In a 366 mobile network, identifier groups are used to represent all the 367 identifiers assigned to a mobile node. Each mobile node will 368 have its own identifier group. 370 o Writing identifier locator mappings into the ILA mapping 371 database. The written content is based on the information 372 provide by session management. 374 o Changing the mapping table when a locator for an identifier, 375 group, or mobile node changes. A locator for a device changes 376 when its point of attachment changes. 378 o Creating identifiers for attached devices. Identifiers may be 379 persistent so that each time a device attaches it gets the same 380 identifier. 382 o Registering ILA-Rs, ILA-Ns and their locators. ILA-Ms coordinate 383 the operation of ILA nodes in the network. 385 5 Data plane operation 386 ILA performs transformations on IPv6 addresses of packets in flight. 387 A SIR to ILA address transformation overwrites the destination 388 address with a locator address for forwarding over a network. An ILA 389 to SIR address transformation restores an IP address to its original 390 contents. The transformations are always paired so that a SIR to ILA 391 address transformation is always undone before delivery. End hosts 392 and applications only see SIR addresses. Effectively, ILA is a 393 mechanism to implement transparent network overlays. Note the process 394 is specifically called a "transformation" as opposed to "translation" 395 which distinguishes ILA from NAT. NAT translations are not undone 396 before reception and NAT is not transparent to the end points. 398 5.1 SIR to ILA transformation 400 SIR to ILA address transformations may be performed by ILA routers, 401 ILA forwarding nodes, and ILA hosts. 403 SIR to ILA transformation is done by a lookup on the destination 404 address in a mapping table. On an ILA router this table contains all 405 the entries for the shard the router serves. On a forwarding node or 406 host, the table is a cache of entries. If a corresponding entry is 407 found, then a locator is returned. The locator is written into the 408 destination address. 410 If checksum neutral mapping is being used to preserve transport layer 411 checksums, then that is indicated in the mapping entry. Checksum 412 neutral mangles the low order sixteen bits of the identifier portion 413 of the address. The checksum difference between the SIR prefix and 414 the locator is added into to the low order sixteen bits of the 415 identifier. 417 If an ILA router does not find a match on the destination address in 418 its table then the packet is dropped as having no route to host. 420 If an ILA forwarding node or host does not find a match on the 421 destination address, then it forwards the packet unchanged. The 422 packet may encounter an ILA router that performs the transformation. 424 In response to forwarding a packet, a router might send an ILA 425 redirect to an ILA forwarding node. A redirect informs a node of an 426 ILA mapping that may be cached to avoid triangular routing when 427 forwarding subsequent packets. The destination of a redirect is the 428 upstream forwarding node of the source of packet. An ILA router can 429 determine this by performing an ILA lookup on the source address of 430 the packet being forwarded. This assumes that the source is a SIR 431 address for the ILA domain and that the use of ILA is symmetric so 432 that the lookup reveals the correct forwarding node; this needs to be 433 accounted for in network design. 435 5.2 ILA to SIR transformation 437 Transformed packets are forwarded to an ILA-N or ILA-H based on 438 normal routing of the packet with a locator in the its destination 439 address (upper sixty-four bits). When a node receives the packet it 440 first performs performs an ILA to SIR address transformation by 441 mapping the received locator (one local to the node) to a SIR 442 address. If checksum neutral mapping has been done, the lower sixteen 443 bits in the identifier must be fixed up. This is done by subtracting 444 the checksum difference of the SIR address and locator from the low 445 order bits of the identifier (the opposite operation of setting the 446 checksum neutral bits). 448 After transforming a destination back to SIR address, a lookup is 449 performed on the identifier to determine if it is local (that is it 450 refers to a node that is downstream of the ILA node). If the node is 451 local, it is forwarded downstream using normal mechanisms of the 452 network. If the node is not local, the SIR addressed packet is 453 forwarded back into the network. The packet should traverse an ILA 454 router that can transform its destination to the correct locator and 455 possibly send a redirect towards the source. 457 5.3 Data path efficiency 459 There basic operations of ILA address transformation, either SIR to 460 ILA or ILA to SIR, are: 462 1) Read destination address from a packet. 464 2) Lookup all or are part of the destination address in table. 465 This is a fixed length lookup. 467 3) Overwrite all or part of the destination address with a locator 468 value returned from the lookup. 470 4) Fix the checksum neutral mapping bits in the identifier. 472 5) Forward the resultant packet. 474 The computationally intensive operations in this path are the lookup 475 and checksum neutral processing. 477 The lookup operation is on a fixed length key so a simple hash table 478 can be used. It is also amenable for use with a hardware TCAM. On an 479 ILA host, an ILA mapping may be cached with a connection context so 480 that a lookup does not to be performed for every packet sent on the 481 connection. 483 Checksum neutral processing entails 1's complement arithmetic over 484 sixty-four or 128 bit values. In the case that the full 128 bit 485 identifier address is a one-to-one mapping with a locator address, 486 then the checksum computation is constant for a mapping and can be 487 precomputed and saved with the mapping. 489 5.4 Alternative data path use cases 491 ILA supports multicast encoding, virtual networking modes, and 492 IPv4/IPv6 translation. These require different processing, and in the 493 case of IPv4/IPv6 translation the size of the packet increases. 494 However, these alternative cases should not fundamentally increase 495 the cost of the lookups since instructions for alternative processing 496 can be returned by a lookup. 498 5.5 Locator chaning 500 ILA allows multiple locator transformations to effectively implement 501 hop-by-hop source routing. This can be used to deliberately have a 502 packet visit some set of nodes. This might also be used in the case 503 where two domains are exchange ILA mappings, but only share locators 504 that are ingress points in their network and not final locators of a 505 node. This would be done to protect user location from being exposed. 507 5.6 ICMP handling 509 A packet whose destination address is an ILA address may generate an 510 ICMP error. In this case the ICMP data will contain an IPv6 header 511 whose destination is an ILA address. If a sender receives an ICMP 512 error with an ILA address as the destination of the original packet, 513 it won't recognize the destination address as one that it sent to and 514 this may leak information about internal nodes of the network. To 515 prevent this from happening, upstream ILA-Ns of ILA-Hs of an end node 516 can filter ICMP packets. When an ICMP packet is received by these 517 nodes, an ILA destination address can be transformed back to a SIR 518 address by performing a reverse lookup. 520 6 Control plane 522 This section describes the ILA control plane for the mobile user- 523 plane. 525 The ILA control plane is separate from the control plane of the 526 mobile network. An interface between the session management of the 527 network and the control plane is needed to get device information and 528 point of attachment. The intent is that the interface is well 529 compartmentalized to minimize the amount of specialization needed to 530 adapt ILA for use in different access technologies. 532 6.1 ILA router mapping database 534 There are a number of options to use for implementing the ILA mapping 535 system and router protocol amongst ILA-Rs. The mapping database must 536 be able to scale and provide fast converge when mobile nodes move 537 within the network. 539 6.1.1 ILA with BGP 541 A traditional routing protocol could be used for route dissemination. 542 [BGPILA] defines multiprotocol extensions to BGP for distributing ILA 543 mappings. 545 6.1.2 Key/value store 547 A mapping database is logically a simple key/value store where the 548 lookup key is fixed length (sixty-four or 128 bytes). This 549 characteristic affords the possibility of using a key/value database 550 in lieu of traditional routing protocols. 552 The idea of the key/value database is that each shard is a 553 distributed database instance with some number of replicas. When a 554 write is done in the database, the change is propagated throughout 555 all of the replicas for the shard using the standard database 556 replication mechanisms. Mapping information is written to the 557 database using common database API and requires authenticated write 558 permissions. Each ILA router can read the database for the associated 559 shard to perform its function. 561 The database is assumed to be (mostly) persistent and recoverable if 562 database nodes are lost. The selection of an ILA router shard and 563 shard instance is idempotent and stateless per packet, so that shards 564 and shard replicas can be dynamically added or removed. 566 6.2 ILA Mapping Protocol 568 The ILA Mapping Protocol [ILAMP] is used between ILA forwarding nodes 569 and ILA mapping resolution routers. The purpose of the protocol is to 570 populate and maintain the ILA mapping cache in forwarding nodes. 572 ILA forwarding nodes can use a pull model (request/response), push 573 model (pub/sub), or redirects to populate the mapping table. ILAMP 574 runs over TCP which provides reliability, statefulness implied by 575 established connections, allows use of HTTP and RESTful APIs, and 576 standard security in the form of TLS. 578 The protocol is composed of message primitives: 580 o Map request: Sent by an ILA-N or ILA-H to an ILA-R to request 581 mapping information for an IPv6 address. 583 o Map information: Sent by an ILA-R to an ILA-N or ILA-H and 584 provides mappings. A map information message can be sent in 585 response to a map request, when mappings are pushed in pub/sub, 586 or a mapping is being advertised by ILA redirect. The reason the 587 mapping information was sent in included in a message. 589 o Subscribe/unsubscribe: Sent by an ILA-N or ILA-H to an ILA-R. 590 "Subscribe" requests mapping notifications for the listed 591 identifiers. Notifications are sent when a mapping entry for an 592 identifier changes. "Unsubscribe" requests that notifications 593 for the listed identifiers stop. 595 o Locator unreachable: sent by an ILA-R to an ILA-N or ILA-H to 596 indicate that another ILA-N is no longer reachable so all cache 597 entries using that ILA-N or ILA-H should be evicted. 599 6.3 Address assignment 601 Mobile nodes are assigned addresses that serve as identifiers. A node 602 may be assigned singleton addresses or a network prefix. Privacy is 603 an important consideration in address assignment. 605 6.3.1 Singleton address assignment 607 DHCPv6 or static address configuration can be used to assign 608 singleton addresses to a node. These addresses have no topological 609 component and are not meaningfully aggregable for routing, so an 610 entry in the ILA mapping table would be created for each address. 611 Nodes may be assigned thousand of addresses or even millions of IPv6 612 addresses. Given the large IPv6 address space there are few concerns 613 about address depletion, however to the mapping system each address 614 is represented in a identifier to locator mapping. Scaling this needs 615 to be carefully considered. Sharding, replication, and caching on 616 forwarding nodes are meant to provide scalability. 618 6.3.2 Network prefix assignment 620 A node may be assigned a /64 address via SLAAC as is common in many 621 provider networks. In this scenario, the low order sixty-four bits 622 contains IIDs arbitrarily assigned by a device for its own purposes; 623 these bits cannot be used as an identifier in identifier/locator 624 split. 626 To support /64 prefix assignment with ILA, the ILA identifier can be 627 encoded in the the upper sixty-four bits of an address and the lower 628 sixty-four bits are ignored by ILA. Since only a subset of bits are 629 available, a level of indirection can be used so that ILA transforms 630 the upper sixty four bits to contain both a locator and an index into 631 a locator (ILA-N) specific table. The entry in the table provides the 632 original sixty-four bit prefix so that ILA to SIR address 633 transformation can be done. 635 7 ILA in 5G networks 637 The section describes applying ILA for use in a 5G network. ILA is 638 instantiated as a function in the 5G services architecture described 639 in [3GPPTS]. 641 7.1 Architecture 643 Figures 2 and 3 depict two architectural options for the use of ILA 644 in a 5G architecture. ILA is logically a network function and ILA 645 interfaces to the 5G control plane via service based interfaces. In 646 this architecture, ILA replaces GTP use over the N9 interface. 647 Identifier address to locator address transformations in the downlink 648 from the data network are done by an ILA-R. Transformations for intra 649 domain traffic can be done by an ILA-N close to the gNB or by an ILA- 650 R in the case of a cache miss. Locator address to identifier address 651 transformation happen at ILA-Ns. ILA could be supported on a gNB. In 652 this case, an ILA-N would be co- resident at a gNB and ILA is used 653 over N3 interface in lieu GTP-U. 655 Service Based Interfaces 656 ----+-----+-----+----+----+----+----+--------+-----+-------- 657 | | | | | | | | | 658 +---+---+ | +--+--+ | +--+--+ | +--+--+ +--+--+ | 659 | NSSF+ | | | NRF | | | DSF | | | UDM | | NEF | | 660 +-------+ | +-----+ | +-----+ | +-----+ +-----+ | 661 | | | | 662 +---+----+ +--+--+ +---+--+ +-------------+--+ 663 | AMF | | PCF | | AUSF | | ILA-M | ^ 664 +---+--+-+ +-----+ +------+ +-+-----------+--+ | 665 +-------+ | | | | ILARP 666 | 5G UE |--+ | | <-ILAMP-> | | 667 +---+---+ | N2 +-----+----+ +---+---+ V +----+ 668 | | +------------| ILA-N |--| ILA-R |------| DN | 669 | | | N3 +-+---+--+-+ +-+-----+ +----+ 670 | | | | | | | 671 | +---+------+-+ +---+ +------+ 672 +-----| gNB | N9 N9 673 +------------+ 675 Figure 2: ILA in 5G architecture - Option 1 676 Service Based Interfaces 677 ----+-----+-----+----+----+----+------+----+----+----+--------+-- 678 | | | | | | | | | | | 679 +---+---+ | +--+--+ | +--+--+ | | | | +--+--+ +--+--+ 680 | NSSF | | | NRF | | | DSF | | | | | | UDM | | NEF | 681 +-------+ | +-----+ | +-----+ | | | | +-----+ +-----+ 682 | | | | | | 683 +---+----+ +--+--+ +---+--+ | +--+--+ | 684 | AMF | | PCF | | AUSF | | |ILA-M| | 685 +---+--+-+ +-----+ +------+ | +--+--+ | 686 +-------+ | | | | 687 | 5G UE |--+ | | | 688 +---+---+ | N2 +----+--+ +---+---+ +----+ 689 | | +---------| ILA-N |--| ILA-R |------| DN | 690 | | | N3 ++--+-+-+ +-+-----+ +----+ 691 | | | | | | | 692 | +---+------+-+ +--+ +------+ 693 +-----| gNB | N9 N9 694 +------------+ 696 Figure 3: ILA in 5G architecture - Option 2 698 7.2 Protocol layering 700 Figure 3 illustrates the protocol layers of packets packets sent over 701 various data plane interfaces in the downlink direction of data 702 network to a mobile node. Note that this assumes the topology shown 703 in Figure 2 where GTP-U is used over N3 and ILA is used on N9. 705 ---> ---> ---> 706 DN to ILA-R ILA-R to ILA-N ILA-N to gNB gNB to UE 707 +------------+ +------------+ +------------+ +------------+ 708 | Application| | Application| | Application| | Application| 709 +------------+ +------------+ +------------+ +------------+ 710 | L4 | | L4 | | L4 | | L4 | 711 +------------+ +------------+ +------------+ +------------+ 712 | IPv6 | | IPv6 (ILA) | | IPv6 | | PDU Layer | 713 +------------+ | +------------+ | +------------+ +------------+ 714 | L2 | | | L2 | | | GTP-U | | AN Protocol| 715 +------------+ | +------------+ | +------------+ | Layers | 716 | | | UDP/IP | | | 717 N6 <--N9 --> N3 +------------+ +------------+ 718 | L2 | 719 +------------+ 721 Figure 3: ILA and protocol layer in 5G 723 7.3 Control plane between ILA and network 724 ILA is a consumer of several 5G network services. The service 725 operations of interest to ILA are: 727 o Nudm (Unified Data Management): Provides subscriber information. 729 o Nsmf (Service Managment Function): Provides information about 730 PDU sessions. 732 o Namf (Core Access and Mobility Function): Provides notifications 733 of mobility events. 735 ILA-M subscribes to notifications from network services. These 736 notifications drive changes in the ILA mapping table. The service 737 interfaces reference a UE by UE ID (SUPI or IMSI-Group Identifier), 738 this is used as the key in the ILA identifier database to map UEs to 739 addresses and identifier groups. Point of attachment is given by gNB 740 ID, this is used as the key in the ILA locator database to map a gNB 741 to an ILA-N and its locator. 743 7.4 ILA and network slices 745 Figure 4 illustrates the use of network slices with ILA. 747 ----+-------------------------------------+-------------------- 748 | | 749 +-------------------------+ +----------------------------+ 750 | +--------+ Slice | | +-------------+ Slice | 751 | | SMF |-----+ #1 | | | ILA-M |----+ #2 | 752 | +---+----+ | | | +-----------+-+ | | 753 | N4 | | N4 | | | | | | 754 | +---+--+ +--+----+ | | +--------+ | +--+----+ | +----+ 755 | | UPF | | UPF | | | | ILA-N | | | ILA-R | |---| DN | 756 | +-------+ +-------+ | | +--------+ | +-------+ | +----+ 757 +-------------------------+ +--------------|-------------+ 758 | | 759 +--+-+ +------------|-------------+ 760 | DN | | | Slice | 761 +----+ | +------+----+ #3 | 762 | | | | 763 | +-------+ +-------+ | +----+ 764 +-----+ | | ILA-H | | ILA-R | |---| DN | 765 | MEC |----| +-------+ +-------+ | +----+ 766 +-----+ +--------------------------+ 768 Figure 4: ILA and network slices in 5G 770 In this figure, slice #1 illustrates legacy use of UPFs without ILA 771 in a slice. ILA can be deployed incrementally or in parts of the 772 network. As demonstrated, the use of network slices can provide 773 domain isolation for this. 775 Slice #2 supports ILA. Some number of ILA-Ns and ILA-Rs are deployed. 776 ILA transformations are performed over the N9 interface. ILA-Rs would 777 be deployed at the N6 interface to perform transformations on packets 778 received from a data network. ILA-Ns will be deployed deeper in the 779 network at one side of the N3 interface. ILA-Ns may be supplemented 780 by ILA-Rs that are deployed in the network. ILA-M manages the ILA 781 nodes and mapping database within the slice. 783 Slice #3 shows another slice that supports ILA. In this scenario, the 784 slice is for Mobile Edge Computing. The slice contains ILA-Rs and 785 ILA-Ns, and as illustrated, it may also contain ILA_Hs that run 786 directly on edge computing servers. Note in this example, one ILA-M, 787 and hence one ILA domain, is shared between slice #2 and slice #3. 788 Alternatively, the two slices could each have their own ILA-M and 789 define separate ILA domains. 791 8 Security considerations 793 A mobile public infrastructure has many considerations in security as 794 well as privacy. Fundamentally, a system must protect against 795 misdirection for the purposes of hijacking traffic, spoofing, 796 revealing user identities, exposing accurate geo-location, and Denial 797 of Service attacks on the infrastructure. Security must be considered 798 for both the data and control planes. 800 8.1 Data plane security 802 The ILA data plane must protect against spoofing, inadvertent leakage 803 of sensitive information, and Denial of Service attack. 805 Locator addresses must be contained within an ILA domain. ILA to SIR 806 transformations MUST be performed before allowing a packet to egress 807 an ILA domain. 809 Nodes outside of an ILA domain MUST NOT be permitted to send packets 810 into the domain that have an ILA address in either the source or 811 destination. A stateless firewall at the domain boundary can be used 812 to drop such packets. Note that in the ILA protocol, ILA addresses 813 are not used in source addresses. 815 Section 5.6 describes the handling of ICMP with ILA to avoid leaking 816 locators outside the ILA domain. 818 When a cache is employed that is populated by events from an outside 819 party there is the possibility of Denial of Service attack. A 820 conceptual attack on ILA-N would be for an attacker will flood its 821 link with packets destined to random SIR addresses. The intent is to 822 exhaust the cache memory so that legitimate traffic is blocked from 823 using the cache and hence needs to take sub-optimal routing. The 824 attack can also generate vast numbers of control messages to DOS the 825 infrastructure. 827 It is recommended that ILA redirects, as opposed to query model or 828 pub/sub, is used to mitigate attacks. The reasoning is: 830 o On a cache miss the packet is forwarded and might encounter a 831 router that sends a redirect. The packet itself implies a 832 request for a mapping so no additional control message are 833 needed. 835 o An ILA router will send a redirect only if there is a mapping to 836 the destination. It doesn't sent negative information. In 837 particular, if the identifier space is reasonably sparse a 838 random address attack will not be very effective. 840 o A cache entry is created only when a valid redirect is received. 841 This can be contrasted with a query mechanism that might create 842 state for pending resolutions. 844 o An inactivity timeout can used to evict cache entries. Given the 845 incoming packet rate and a preferred inactivity timeout, a cache 846 can be sized to absorb an attack. 848 o An ILA router may apply its knowledge to rate limit, prioritize, 849 and shape the use of redirects to manage caches. For instance, 850 an ILA router might identify "hot nodes" in the network that 851 receive a lot of traffic and provide the most benefit when 852 cached in forwarding nodes. 854 8.2 Control plane security 856 A mapping system contains sensitive privacy information that could be 857 used to make inferences about user's identity or their geo-location. 858 This information needs to be protected. 860 Mapping protocols must be secured to prevent an attacker from 861 injecting mapping entries to redirect traffic to their own devices. 862 To this end, mapping protocols for ILA are intended to use TCP. The 863 statefulness of TCP deters spoofing of messages and allows for 864 privacy and identity verification in the form of X.509 certificates. 865 The control protocol includes "secure" redirects that must be 866 authenticated to originate from a legitimate ILA router. 868 Mapping protocols must also be resilient to DOS attack, especially in 869 a scenario where a cache of mappings is being employed. Such a cache 870 might be populated in response to the activities of a third party 871 (for instance an application sending packets to different 872 destinations). An attack on the cache whereby an attacker attempts to 873 fill the cache with entries to random destinations must be mitigated. 874 The recommendation of ILA is to use "secure redirects" as a scalable 875 and secure means to populate a forwarding cache. 877 Write access to the ILA mapping database must be strictly controlled. 878 In the ILA architecture only ILA-Ms write to the mapping database. 879 Write access to the database should require strong credentials, 880 validation of each operation, and encryption and authentication of 881 operations being sent over the network. 883 Read access the ILA routing database should also be controlled. 884 Devices should only access data on a "need to know" basis. For 885 instance, ILA routers might need identifier to group mappings to 886 perform forwarding, but they should not need to retrieve all the 887 identifiers for a group. The latter information can be contained in 888 the ILA-Ms. 890 8.3 Privacy in address assignment 892 A node may use multiple addresses to prevent inferences by third 893 parties that break privacy. Properties of addresses to maintain 894 strong privacy are: 896 o They are composed of a global routing prefix and a suffix that 897 is internal to an organization or provider. This is the same 898 property for IP addresses [RFC3513]. 900 o The registry and organization of an address can be determined by 901 the network prefix. This is true for any global address. 903 o The organizational bits in the address should have minimal 904 hierarchy to prevent inference. It might be reasonable to have 905 an internal prefix that divides identifiers based on broad 906 geographic regions, but detailed information such as accurate 907 location, department in an enterprise, or device type should not 908 be encoded in a globally visible address. 910 o Given two addresses and no other information, the desired 911 properties of correlating them are: 913 o It can be inferred if they belong the same organization and 914 registry. This is true for any two global IP addresses. 916 o It may be inferred that they belong to the same broad 917 grouping, such as a geographic region, if the information is 918 encoded in the organizational bits of the address (e.g. are 919 in the same shard). 921 o No other correlation can be established. For example, it 922 cannot be inferred that the IP addresses address the same 923 node, the addressed nodes reside in the same subnet, rack, or 924 department, or that the nodes for the two addresses have any 925 geographic proximity to one another. 927 Ostensibly, assigning a /64 prefix to a node is good for security. 928 The end device can create its own random addresses in the low order 929 sixty-four bits which mitigates address scanning attacks. However, 930 the upper sixty for bits of the address become a static identifier 931 for the node that potentially allows DOS on the device, as well as 932 third party correlations on addresses that deduce that different 933 flows are sourced from the same user. 935 [RFC4941] recommends rotating addresses to protect privacy. In the 936 case of sixty-four bit address assignments this would entail that a 937 new prefix for the device is periodically requested. There is no 938 recommendation for the frequency of address change and there is no 939 quantitative description of the effects of periodic address change. 941 For maximum privacy, a different address could be used for each 942 connection. If this were done for every connection in the network, it 943 would create network state for each connection (note that is sort of 944 thing already exists with stateful NAT). Scaling the mapping system 945 to accommodate this is challenging. One alternative to be 946 investigated is use a reversible cryptographic hash to aggregate 947 identifiers and reduce the number of mappings needed. 949 9 References 951 9.1 Normative References 953 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 954 Requirement Levels", BCP 14, RFC 2119, DOI 955 10.17487/RFC2119, March 1997, . 958 [ILA] Herbert, T., and Lapukhov, P., "Identifier Locator 959 Addressing for IPv6" draft-herbert-intarea-ila-00 961 [ILAMP] Herbert, T., "Identifier Locator Addressing Mapping 962 Protocol" draft-herbert-ila-ilamp-00 964 9.2 Informative References 966 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 967 (IPv6) Addressing Architecture", RFC 3513, DOI 968 10.17487/RFC3513, April 2003, . 971 [RFC4941] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 972 RFC 4641, DOI 10.17487/RFC4641, September 2006, 973 . 975 [ILAGRPS] Herbert, T., "Identifier Groups in ILA", To be published 977 [BGPILA] Lapukhov, P., "Use of BGP for dissemination of ILA mapping 978 information" draft-lapukhov-bgp-ila-afi-02 980 [3GPPTS] 3rd Generation Partnership Project (3GPP), "3GPP TS 981 23.502", http://www.3gpp.org/DynaReport/23-series.htm 983 Authors' Addresses 985 Tom Herbert 986 Quantonium 987 Santa Clara, CA 988 USA 990 Email: tom@quantonium.net 992 Kalyani Bogineni 993 Verizon 994 One Verizon Way, Basking Ridge, NJ 07920 995 USA 997 Email: kalyani.bogineni@verizon.com