idnits 2.17.1 draft-habault-gallet-homenet-multihoming-sdsa-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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2012) is 4445 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Habault 3 Internet-Draft L. Toutain 4 Intended status: Informational Telecom Bretagne 5 Expires: August 26, 2012 E. Gallet de Santerre 6 February 23, 2012 8 Proposal for selecting the default-route according to source address 9 draft-habault-gallet-homenet-multihoming-sdsa-00 11 Abstract 13 SDSA approach is to assure that packets, going out the multihomed 14 site, have the correct source address, regarding to the ISP and thus 15 to avoid the ingress filtering problem. In that purpose, SDSA takes 16 into account the source address in the site routing decision for 17 outgoing packets, when default-route is involved. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 26, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. SDSA routers . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. Packet processing . . . . . . . . . . . . . . . . . . . . 4 69 3. Network routing evolution . . . . . . . . . . . . . . . . . . 5 70 3.1. Routing table strucutre . . . . . . . . . . . . . . . . . 6 71 3.2. Default Source Routes Diffusion . . . . . . . . . . . . . 6 72 3.3. Deployment of SDSA . . . . . . . . . . . . . . . . . . . . 7 73 3.3.1. Partial SDSA Site . . . . . . . . . . . . . . . . . . 8 74 3.3.2. Total SDSA Site . . . . . . . . . . . . . . . . . . . 9 75 4. SDSA Analysis . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 Many companies are connected to the Internet through several Internet 87 Service Providers (ISPs). This practice, known as multihoming, 88 increases the communication capabilities of companies, enabling link- 89 failure-resistant connection, load sharing and redundancy. In 90 [I-D.chown-homenet-arch] Homenet working group is also taking 91 multihoming into consideration for future home network which puts the 92 ingress filtering issue of multihomed network back on the agenda. In 93 IPv6, multihomed sites generally have several global prefixes for 94 their networks, which means several global addresses for each end- 95 host of a site. When these multihomed end-hosts try to communicate 96 with another site, the communication can be filtered by the provider 97 edge router because of ingress filtering (the packet is dropped if 98 the ISP has not delegated the packet's source address prefix 99 [RFC2827], [RFC3704]). It results in an unjustified packet loss and 100 a subsequent delay in packet transmission. 102 An interesting approach to solve the described ingress filtering 103 issue is proposed in the Source Address Dependent (SAD) routing 104 mechanism [BGRA06]. SAD routing proposes to have several routing 105 tables on each router, each table being dependent on one of the 106 prefixes delegated by the ISPs. With this proposal, packets are 107 routed to their destination through the correct ISP. However, 108 several routing tables on each router highly increases the memory 109 space needed for routing information. The construction and 110 maintenance of such tables is time-consuming and all routes to site 111 destinations are duplicate on each table. Due to their independence 112 on the source address, this redundancy of local information is 113 unnecessary. In order to avoid these issues and still resolve the 114 ingress filtering issue in an IPv6 multihomed edge network, we 115 propose the Selection of the Default-route according to the Source 116 Address (SDSA) of a packet. SDSA enhances the routing protocol in an 117 edge network because it takes into account the source address of a 118 packet in the routing decision. As it does not require major 119 modifications in edge networks, SDSA is easy to deploy and brings 120 immediate benefits. Moreover, it could be possible to couple SDSA 121 with other solutions (e.g. solution providing session survival) to 122 cover all issues that multihoming rises. 124 2. Proposal 126 SDSA approach is to assure that packets, going out the multihomed 127 site, have the correct source address, regarding to the ISP and thus 128 to avoid the ingress filtering problem. In that purpose, SDSA takes 129 into account the source address in the site routing decision for 130 outgoing packets, when default-route is involved. 132 2.1. SDSA routers 134 Routers implied in the SDSA selection have two routing tables. The 135 first one, very similar to actual routing tables, lists known 136 destinations (site destinations and some specific external 137 destinations advertised by ISPs) and the next hop to those 138 destinations. This first table does not have any default route. We 139 call this table the destination table. The second table contains all 140 the prefixes delegated by the site's ISPs. Each prefix of this table 141 is associated with a next hop (an SDSA router too) and drives packets 142 along a path to the ISP, which has delegated the prefix. We call 143 this second table the prefix table. The prefix table represents a 144 list of different default-routes, which depend on prefixes. Such a 145 structure has the advantage of separating the routing knowledge to 146 the architecture knowledge. Site topology changes do not impact the 147 prefix table (except possibly for next hop) and changes in delegated 148 prefix do not imply a recomputation of the destination table. 150 2.2. Packet processing 152 The packet processing by an SDSA router is slightly different from 153 the processing of a classical router to take into account the source 154 address. For all the traffic to a known destination, routers perform 155 destination based routing. SDSA occurs only when an end-host in a 156 multihomed site sends a packet to a destination in another site. The 157 packet is forwarded until it reaches an SDSA router. The SDSA router 158 processes the packet following the algorithm in Figure 1. 160 Packet arrives 161 | 162 | 163 v 164 +---------------------+ +-------------+ 165 | Destination address | Best match | Packet sent | 166 | comparison with |------------->| to next hop | 167 | known routes | found | | 168 +---------------------+ +-------------+ 169 | 170 | No match found 171 | 172 v 173 +---------------------+ +-------------+ 174 | Source address | Best match | Packet sent | 175 |comparison with known|------------->| to next hop | 176 | delegated prefixes | found | | 177 +---------------------+ +-------------+ 178 | 179 | No match found 180 | +----------------+ 181 | | Packet dropped | 182 +--------------------->| by ingress | 183 | filtering | 184 +----------------+ 186 Figure 1: SDSA algorithm 188 It checks the destination address and compares to all known routes 189 (except the default route). If the destination address matches an 190 entry, the packet is sent to the next hop and the algorithm ends. If 191 not, the source address is checked and compared to the list of 192 delegated prefixes. If a match is found in this list, the packet is 193 sent to the associated next hop. If there is no match, the packet is 194 dropped, considered as a trial of address spoofing. With this 195 process, a packet whom destination is unknown, is routed to the ISP 196 edge router which has delegated the source address prefix. 198 3. Network routing evolution 200 To select the default route based on the source address, first, we 201 need to change the routing table structure of SDSA routers to accept 202 several default routes. Second, to populate this new routing table, 203 the diffusion of routes has to support some modifications. 205 3.1. Routing table strucutre 207 As mentionned previously, the classical routing table is separated in 208 two complementary tables. The first one, which we called the 209 destination table, contains all routes that we find currently in a 210 routing table, except the default route. The entries of the 211 destination table are mostly internal prefixes and some specific 212 external prefixes announced by ISPs. Next hops are specified as in 213 current routing tables. This table is used for the destination 214 address check. The second table, called the prefix table, is 215 populated with prefixes delegated by ISPs. Each prefix of this table 216 has an associated next hop which will be used to route packets along 217 a path to the ISP which has delegated the prefix. The prefix table 218 participates in the source address check when there is no match 219 during the destination address check. We called entries of that 220 table, Default Source Routes (DSRs). 222 3.2. Default Source Routes Diffusion 224 Each edge router announces the same information as legacy routing 225 systems and the DSR associated with the prefix delegated by its 226 directly connected ISP. SDSA site routers receive these announces 227 (from different edge routers) and construct their routing destination 228 and prefix tables. 230 +-------+ +-------+ 231 | ISP A | | ISP B | 232 +-------+ +-------+ 233 {a::} |* {b::} |x 234 |* |@ 235 +----+* +----+@ + ------------- + 236 | RA |* | RB |@ | R3 classical | 237 +----+* +----+@ | routing table | 238 / \* / \@ |---------------| 239 | \* / |@ | Dest | NH | 240 +----+ +----+ +----+ | ... | 241 | R1 | ------- | R2 | -*-*-* | R3 |~| ... | 242 +----+ +----+ +----+ | ::/0 | RB | 243 | */@ + ------------- + 244 \ */@ + ------------- + 245 +----+ */@ | R3 SDSA | 246 | R4 | ---------*+@ | routing table | 247 +----+ *|@ |---------------| 248 *|@ | Prefix | NH | 249 +-----------+ | a:: | R2 | 250 | IPv6 Host | | b:: | RB | 251 +-----------+ + ------------- + 252 @@@@ Classical routing - Dropped by ingress filtering 253 **** SDSA routing - Delivered to destination 255 Figure 2: SDSA routing compared to classical routing 257 Figure 2 shows a comparison between an SDSA routing scheme and a 258 classical one. In this example, we show routing tables of R3 only, 259 with and without SDSA, but all routers can use the SDSA mechanism. 260 We notice that R3 has several DSRs, each one corresponding to a 261 default route to a specific ISP. ISPA (respectively ISPB ) delegates 262 prefix a (respectively b) to RA (respectively RB). Routers RA and RB 263 advertise their routing information (knwon routes and DSRs) to the 264 site. SDSA routers use this routing information to populate their 265 destination table and their prefix table. A packet to a destination 266 address I>>::1 from a source address a::1 is dropped by ISPB in a 267 classical routing scheme (the @ path in Figure 2), whereas the packet 268 is forwarded to router RA and sent through ISPA until its 269 destination, in the SDSA scheme (the * path in Figure 2). 271 3.3. Deployment of SDSA 273 As described in Section 2.2, if the destination address does not 274 match any entry in the destination table, the source address is 275 compared to DSRs. The SDSA mechanism is only efficient if SDSA 276 routers are aware of all prefixes delegated by site ISPs. Indeed, if 277 an SDSA router does not know all prefixes, a source address check 278 could have no match in the prefix table even if the prefix of the 279 source address has been delegated by one of the site ISPs. So, each 280 SDSA router has to receive a DSR from each ISP of the site; 281 particularly, the edge routers. As all routers involved in SDSA 282 mechanism have to be aware of all prefixes delegated by ISPs, a 283 necessary condition to use the SDSA mechanism is that there is a 284 unique connected graph of SDSA routers including, at least, all edge 285 routers (as shown in Figure 3). 287 +-------+ +-------+ 288 | ISP A | | ISP B | 289 +-------+ +-------+ 290 | | | | \ 291 | | | | | 292 +----+ +----+ +----+ +----+ | SDSA 293 | R* |-----| R* |------| R* |-----| R* | | area 294 +----+ +----+ +----+ +----+ | 295 | \ / / / 296 | \ +----+ / 297 | \ / / \ 298 | +----+ +----+ | 299 | | R |---------------| R | | 300 | +----+ +----+ | 301 | / | Classical 302 | / | routing 303 +----+ +----+ | area 304 | R |----------------| R | | 305 +----+ +----+ | 306 / 307 R*: SDSA Router 308 R : Classical Router 310 Figure 3: Necessary condition to an SDSA deployment 312 3.3.1. Partial SDSA Site 314 As SDSA requires router modifications in a site, it must be 315 progressively deployable. In that purpose, SDSA does not need to be 316 run on all site routers immediately and brings benefits even if few 317 routers are using it. 319 In a partial deployment scheme, all routers are not using the SDSA 320 mechanism, but it is possible to go to one edge router to another 321 along a path of SDSA routers (see Figure 3). A packet sent by a 322 terminal host to an external destination is potentially processed by 323 a router that does not use SDSA. Following the default route of each 324 classical router, the packet is necessarily forwarded to an SDSA 325 router. Then, the packet is routed by this SDSA router to the 326 appropriate edge router (associated with the source address prefix). 327 An evident drawback of this deployment method is that the path 328 followed by the packet from source to edge router is not necessarly 329 the shortest. The worst case occurs when the packet is routed by 330 classical routers to an inappropriate edge router. Then, this edge 331 router uses the SDSA mechanism to forward the packet on a path to the 332 correct edge router. This increases the delay to deliver the packet 333 to the destination. On the other hand, considering that, without 334 SDSA, the packet would have been dropped by ingress filtering at ISP 335 edge router, the deployment of SDSA in the site remains a positive 336 evolution. 338 3.3.2. Total SDSA Site 340 In a total SDSA deployment scheme, all routers use SDSA, and are 341 aware of ISP prefixes. A packet sent by a site machine to an 342 external destination is directly pro- cessed by an SDSA router. 343 Therefore, the packet is forwarded along a route to the edge router 344 which has advertised the prefix of the packet source address. Thus, 345 the path followed by the packet from the source to correct ISP edge 346 router is the best possible as the SDSA process is made as close as 347 possible to the source. 349 The total SDSA deployment scheme not only solves the ingress 350 filtering issue, but also makes internal routing as efficient as with 351 current routing protocols. 353 4. SDSA Analysis 355 According to [WVTP97], the Buildup Time Complexity (BTC) of a table 356 containing n entries of length k is in O(nk). The Space/Memory 357 Complexity (SMC) of such a table is in O(n). Compared to a classical 358 router, an SDSA has two tables to construct and update. We call k 359 (resp. l) the length of a destination table item (resp. prefix table 360 item), m the number of ISPs and n the number of advertised routes. 361 We can make the assumption that k ~ l and that m <= n. For the SDSA 362 proposal, the complexity is the sum of each table complexity. 363 Consequently, the SDSA BTC and SMC are given by: 365 BTCSDSA =O(ml+nk)=O(nk) (1) 367 SMCSDSA = O(m + n) = O(n) (2) 369 The time complexity of the construction and the update of SDSA tables 370 is equivalent to current complexity. 372 5. IANA Considerations 374 TBD 376 6. Security Considerations 378 TBD 380 7. Acknowledgement 382 The work presented in this draft has been realized by Etienne Gallet 383 de Santere in the preparation of his thesis. The result of his 384 research and his thesis has never been published. However, regarding 385 the growing interest in multihoming, it seems important to present 386 his research all the more so implementation has already been 387 realized. 389 8. References 391 8.1. Normative References 393 [BGRA06] Bagnulo, M., Garcia-Martinez, A., Rodriguez, J., and A. 394 Azcorra, "End-site routing support for IPv6 multihoming", 395 2006. 397 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 398 Defeating Denial of Service Attacks which employ IP Source 399 Address Spoofing", BCP 38, RFC 2827, May 2000. 401 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 402 Networks", BCP 84, RFC 3704, March 2004. 404 [WVTP97] Waldvogel, M., Varghese, G., Turner, J., and B. Plattner, 405 "Scalable high speed ip routing lookups", 1997. 407 8.2. Informative References 409 [I-D.chown-homenet-arch] 410 Arkko, J., Chown, T., Weil, J., and O. Troan, "Home 411 Networking Architecture for IPv6", 412 draft-chown-homenet-arch-01 (work in progress), 413 October 2011. 415 Authors' Addresses 417 Guillaume Habault 418 Telecom Bretagne 419 Rennes, 35000 420 FRANCE 422 Phone: +33 2 99 12 7032 423 Email: guillaume.habault@telecom-bretagne.eu 425 Laurent Toutain 426 Telecom Bretagne 427 Rennes, 35000 428 FRANCE 430 Phone: +33 2 99 12 7026 431 Email: laurent.toutain@telecom-bretagne.eu 433 Etienne Gallet de Santerre 434 Rennes, 35000 435 FRANCE 437 Phone: 438 Email: etiegall@yahoo.fr