idnits 2.17.1 draft-baker-ipv6-isis-dst-flowlabel-routing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 17, 2013) is 4076 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F.J. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track February 17, 2013 5 Expires: August 21, 2013 7 Using IS-IS with Role-Based Access Control 8 draft-baker-ipv6-isis-dst-flowlabel-routing-00 10 Abstract 12 This note describes the changes necessary for IS-IS to route classes 13 of IPv6 traffic that are defined by an IPv6 Flow Label and a 14 destination prefix. This implies not routing "to a destination", but 15 "traffic matching a classification tuple". The obvious application 16 is data center inter-tenant routing using a form of role-based access 17 control. If the sender doesn't know the value to insert in the flow 18 label (the receiver's tenant ID), he in effect has no route to that 19 destination. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 21, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Theory of Routing . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Dealing with ambiguity . . . . . . . . . . . . . . . . . 3 59 3. Extensions necessary for IS-IS/IPv6 . . . . . . . . . . . . . 4 60 3.1. On Flow labels and Security . . . . . . . . . . . . . . . 4 61 3.2. Flow Label sub-TLV . . . . . . . . . . . . . . . . . . . 5 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 9.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Appendix A. Use case: Data Center Role-based Access Control . . 6 71 Appendix B. FIB Design . . . . . . . . . . . . . . . . . . . . . 6 72 B.1. Staged Lookup . . . . . . . . . . . . . . . . . . . . . . 7 73 B.2. PATRICIA . . . . . . . . . . . . . . . . . . . . . . . . 7 74 B.2.1. Virtual Bit String . . . . . . . . . . . . . . . . . 7 75 B.2.2. Tree Construction . . . . . . . . . . . . . . . . . . 8 76 B.2.3. Tree Lookup . . . . . . . . . . . . . . . . . . . . . 8 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 This specification builds on the extensible TLV defined in [RFC5308]. 82 It adds to the existing Reachability TLV the (obviously optional) 83 sub-TLV for an IPv6 Flow Label, to define routes defined by a 84 destination prefix plus a flow label. [RFC5308] also provides an 85 "address TLV", which enables a router to identify the prefixes in use 86 on its interfaces. The Address TLV is not extensible; it does not 87 permit sub-TLVs. Hence, classes of traffic defined by the 88 destination address plus a flow label MUST be advertised using the 89 Reachability TLV. 91 Advertised IS-IS TLVs that specify only a destination prefix may be 92 understood as identifying a destination prefix used with "any" flow 93 label, which is a very useful class of traffic to compactly 94 represent. 96 1.1. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. Theory of Routing 104 Both IS-IS and OSPF perform their calculations by building a lattice 105 of routers and routes from the router performing the calculation to 106 each router, and then use those routes to get to destinations that 107 those routes advertise connectivity to. Following the SPF algorithm, 108 calculation starts by selecting a starting point (typically the 109 router doing the calculation), and successively adding {link, router) 110 pairs until one has calculated a route to every router in the 111 network. As each router is added, including the original router, 112 destinations that it is directly connected to are turned into routes 113 in the route table: "to get to 2001:db8::/32, route traffic to 114 {interface, list of next hop routers}". For immediate neighbors to 115 the originating router, of course, there is no next hop router; 116 traffic is handled locally. 118 IS-IS [ISO.10589.1992] represents those destinations as a type- 119 length-value field that identifies an address. For CLNS, it was 120 designed for the ISO NSAP; by various extensions, it also handles 121 IPv4 and IPv6 prefixes and their counterparts for other protocols. 122 Adding a new class of traffic to route is as simple as adding a new 123 tuple type and the supporting method routines for that class of 124 traffic. 126 2.1. Dealing with ambiguity 128 In any routing protocol, there is the possibility of ambiguity. An 129 area border router might, for example, summarize the routes to other 130 areas into a small set of relatively short prefixes, which have more 131 specific routes within the area. Traditionally, we have dealt with 132 that using a "longest match first" rule. If the same datagram 133 matches more than one destination prefix advertised within the area, 134 we follow the route to the longest matching prefix. 136 When routing a class of traffic, we follow an analogous "most 137 specific match" rule; we follow the route for the most specific 138 matching tuple. In cases of simple overlap, such as routing to 139 2001:db8::/32 or 2001:db8:1::/48, that is exactly analogous; we 140 choose one of the two routes. 142 It is possible, however, to construct an ambiguous case in which 143 neither class subsumes the other. For example, presume that 144 o A is a prefix, 146 o B is a more-specific prefix within A, and 148 o C is a specific flow label value 150 The two classes "routes to A using flow label C" and "routes to B 151 using any flow label" are ambiguous: a datagram to B using the flow 152 label C matches both classes, and it is not clear in the data plane 153 what decision to make. Solving this requires the addition of a third 154 route in the FIB corresponding to the class for routes to B using 155 flow label C, which is more-specific than either of the first two, 156 and can be given routing guidance based on metrics or other policy in 157 the usual way. 159 3. Extensions necessary for IS-IS/IPv6 161 Section 2 of [RFC5308] defines the "IPv6 Reachability TLV", and 162 carries in it destination prefix advertisements. It has the 163 capability of extension, using sub-TLVs. The extension needed is to 164 add a sub-TLV for each additional item in the tuple. We interpret 165 the lack of a given sub-TLV as "any"; by definition, S=0 implies any 166 source address, any DSCP, and any flow label. If S=1, there will be 167 one or more additional sub-TLVs following the sub-TLV format 168 specified there. 170 3.1. On Flow labels and Security 172 According to section 6 of [RFC2460], a Flow Label is a 20 bit number 173 which 175 "may be used by a source to label sequences of packets for which 176 it requests special handling by the IPv6 routers". 178 The possible use case mentioned in an appendix is egress routing. 179 Other RFCs suggest other possible use cases. 181 In this model, the flow label is used to prove that the datagram's 182 sender has specific knowledge of its intended receiver. No proof is 183 requested; this is left for higher layer exchanges such as IPSec or 184 TLS. However, if the information is distributed privately, such as 185 through DHCP/DHCPv6, the network can presume that a system that marks 186 traffic with the right flow label has a good chance of being 187 authorized to communicate with its peer. 189 The key consideration, in this context, is that the flow label is a 190 20 bit number. As such, an advertised route requiring a given flow 191 label value is calling for an exact match of all 20 bits of the label 192 value. 194 3.2. Flow Label sub-TLV 196 0 1 2 3 197 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Type | Length | MBZ | 20 bit Flow Label 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | 202 +-+-+-+-+-+-+-+-+ 204 Flow Label Sub-TLV 206 Flow Label Type: assigned by IANA 208 TLV Length: Length of the sub-TLV in octets 210 Flow Label: 20 bits of Flow Label value 212 MBZ: unused, MUST be zero when generated, ignored on receipt. 214 4. IANA Considerations 216 This section will request an identifying value for the TLV defined. 217 This is deferred to the -01 version of the draft. 219 5. Security Considerations 221 To be considered. 223 6. Privacy Considerations 225 To be considered. 227 7. Acknowledgements 229 8. Change Log 231 Initial Version: February 2013 233 9. References 235 9.1. Normative References 237 [ISO.10589.1992] 238 International Organization for Standardization, 239 "Intermediate system to intermediate system intra-domain- 240 routing routine information exchange protocol for use in 241 conjunction with the protocol for providing the 242 connectionless-mode Network Service (ISO 8473)", ISO 243 Standard 10589, 1992. 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, March 1997. 248 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 249 6 (IPv6) Specification", RFC 2460, December 1998. 251 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 252 2008. 254 9.2. Informative References 256 [PATRICIA] 257 Morrison, D.R., "Practical Algorithm to Retrieve 258 Information Coded in Alphanumeric", Journal of the ACM 259 15(4) pp514-534, October 1968. 261 Appendix A. Use case: Data Center Role-based Access Control 263 Consider a data center in which IPv6 is deployed throughout using 264 internet routing technologies instead of tunnels, and the Flow Label 265 is used to identify tenants, as discussed in Section 3.1. Hosts are 266 required, by configuration if necessary, to know their own tenant 267 number and the numbers of any tenants they are authorized to 268 communicate with. When they originate a datagram, they send it to 269 their peer's destination address and label it with their peer's 270 tenant id. They, or their router on their behalf, advertise their 271 own addresses as traffic classes 273 {destination prefix, Tenant Flow Label } 275 The net effect is that traffic is routed among tenants that are 276 authorized to communicate, but not among tenants that are not 277 authorized to communicate - there is no route. This is done without 278 tunnels, access lists, or other data plane overhead; the overhead is 279 in the control plane, equipping authorized parties to communicate. 281 Appendix B. FIB Design 283 While the design of the Forwarding Information Base is not a matter 284 for standardization, as it only has to work correctly, not 285 interoperate with something else, the design of a FIB for this type 286 of lookup may differ from approaches used in destination routing. We 287 describe two possible approaches from the perspective of a proof of 288 concept. These are a staged lookup and a single FIB. 290 B.1. Staged Lookup 292 A FIB can be designed as a staged lookup. Given that it is unlikely 293 that any given destination would support very many tenants, a simple 294 list or small hash may be sufficient; one looks up the destination, 295 and having found it, validates the flow label used. In such a 296 design, it is necessary to have the option of "any" flow label in 297 addition to the set of specified flow labels, as it is legal and 298 correct to advertise routes that do not have flow labels. 300 B.2. PATRICIA 302 One approach is a [PATRICIA] Tree. This is a relative of a Trie, but 303 unlike a Trie, need not use every bit in classification, and does not 304 need the bits used to be contiguous. It depends on treating the bit 305 string as a set of slices of some size, potentially of different 306 sizes. Slice width is an implementation detail; since the algorithm 307 is most easily described using a slice of a single bit, that will be 308 presumed in this description. 310 B.2.1. Virtual Bit String 312 It is quite possible to view the fields in a datagram header 313 incorporated into the classification tuple as a virtual bit string 314 such as is shown in Figure 1. This bit string has various regions 315 within it. Some vary and are therefore useful in a radix tree 316 lookup. Some may be essentially constant - all global IPv6 addresses 317 at this writing are within 2000::/3, for example, so while it must be 318 tested to assure a match, incorporating it into the radix tree may 319 not be very helpful in classification. Others are ignored; if the 320 destination is a remote /64, we really don't care what the EID is. 321 In addition, due to variation in prefix length and other details, the 322 widths of those fields vary among themselves. The algorithm the FIB 323 implements, therefore, must efficiently deal with the fact of a 324 discontiguous lookup key. 326 +---------------------+----------------------+-----+-----------+ 327 |Destination Prefix |Source Prefix |DSCP | Flow Label| 328 +------+------+-------+------+-------+-------+-----+-----------+ 329 Common|Varying|Ignored|Common|Varying|Ignored|Varying or ignored 331 Figure 1: Treating a traffic class as a virtual bit string 333 B.2.2. Tree Construction 335 The tree is constructed by recursive slice-wise decomposition. At 336 each stage, the input is a set of classes to be classified. At each 337 stage, the result is the addition of a lookup node in the tree that 338 identifies the location of its slice in the virtual bit string (which 339 might be a bit number), the width of the slice to be inspected, and 340 an enumerated set of results. Each result is a similar set of 341 classes, and is analyzed in a similar manner. 343 The analysis is performed by enumerating which bits that have not 344 already been considered are best suited to classification. For a 345 slice of N bits, one wants to select a slide that most evenly divides 346 the set of classes into 2^N subsets. If one or more bits in the 347 slice is ignored in some of the classes, those classes must be 348 included in every subset, as the actual classification of them will 349 depend on other bits. 351 Input:{2001:db8::/32, ::/0, *, *} 352 {2001:db8:1::/48, ::/0, AF41, *} 353 {2001:db8:1::/48, ::/0, AF42, *} 354 {2001:db8:1::/48, ::/0, AF43, *} 355 Common parts: Destination prefix 2001:dba, source prefix, and label 356 Varying parts: DSCP and the third set of sixteen bits in the 357 destination prefix 358 One possible decomposition: 359 (1) slice = DSCP 360 enumerated cases: 361 (a) { {2001:db8::/32, ::/0, *, *}, {2001:db8:1::/48, ::/0, AF41, *} } 362 (b) { {2001:db8::/32, ::/0, *, *}, {2001:db8:1::/48, ::/0, AF42, *} } 363 (c) { {2001:db8::/32, ::/0, *, *}, {2001:db8:1::/48, ::/0, AF43, *} } 364 (2) slice = third sixteen bit field in destination 365 This divides each enumerated case into those containing 0001 and 366 "everything else", which would imply 2001:db8::/32 367 (1) DSCP 368 -------------------------- 369 (1a) (1b) (1c) 370 / \ / \ / \ 371 /32 /48 /32 /48 /32 /48 373 Figure 2: Example PATRICIA Tree 375 B.2.3. Tree Lookup 377 To look something up in a PATRICIA Tree, one starts at the root of 378 the tree and performs the indicated comparisons recursively walking 379 down the tree until one reaches a terminal node. When the enumerated 380 subset is empty or contains only a single class, classification 381 stops. Either classification has failed (there was no matching 382 class, or one has presumably found the indicated class. At that 383 point, every bit in the virtual bit string must be compared to the 384 classifier; classification is accepted on a perfect match. 386 In the example in Figure 2, if a packet {2001:db8:1:2:3:4:5:6, 387 2001:db8:2:3:4:5:6:7, AF41, 0} arrives, we start at the root. Since 388 it is an AF41 packet, we deduce that case (1a) applies, and since the 389 destination has 0001 in the third sixteen bit field of the 390 destination address, we are comparing to {2001:db8:1::/48, ::/0, 391 AF41, *}. Since the destination address is within 2001:db8:1::/48, 392 classification as that succeeds. 394 Author's Address 396 Fred Baker 397 Cisco Systems 398 Santa Barbara, California 93117 399 USA 401 Email: fred@cisco.com