idnits 2.17.1 draft-zinin-rtg-dos-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 775. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2005) is 6921 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 2385 (ref. 'TCP-MD5') (Obsoleted by RFC 5925) Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alex Zinin 3 Internet Draft Alcatel 4 Expiration Date: October 2005 May 2005 5 File name: draft-zinin-rtg-dos-02.txt 7 Protecting Internet Routing Infrastructure from 8 Outsider DoS Attacks 10 draft-zinin-rtg-dos-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its Areas, and its Working Groups. Note that other 21 groups may also distribute working documents as Internet Drafts. 23 Internet Drafts are draft documents valid for a maximum of six 24 months. Internet Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet 26 Drafts as reference material or to cite them other than as a "working 27 draft" or "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The mechanism described in this document helps to secure an Internet 38 Service Provider's router infrastructure from outsider attacks, 39 including (but not limited to) Distributed denial of service (DDoS) 40 attacks based on CPU and/or queue exhaustion (e.g., TCP SYN flooding 41 and flooding of invalid MD5-signed routing protocol packets.) The 42 presented approach is based on explicitly marking control packets 43 from trusted sources by different link-layer encapsulation and does 44 not require any modifications to user data exchange protocols, ICMP, 45 routing protocols or changes to existing hardware in routers, which 46 allows it to be deployed quickly throughout the Internet. 48 1 Introduction 50 1.1 Problem Description 52 The packet authentication mechanisms currently used in Internet 53 routing protocols [OSPF, TCP-MD5] leave a generic threat open for an 54 outside attacker--overloading the control CPUs of the routers with 55 packets that look like they belong to a valid routing protocol 56 adjacency or a peering session, yet are fake and would be discarded 57 because of invalid digest value. Because all IP parameters of valid 58 and faked packets look absolutely identical, it is impossible to 59 reject faked packets earlier in the process. This leads to 60 overloading of internal queues allocated for control traffic (routing 61 and signaling protocols), and hence dropping of legitimate control 62 packets. This, combined with high CPU utilization, results in 63 destruction of routing protocol sessions and finally in denial of 64 service by the network. It is interesting to observe that as security 65 mechanisms in routing protocols become more sophisticated and 66 computationally expensive, it becomes easier for an attacker to mount 67 a CPU-exhaustion-based attack against a router. 69 Another example of an attack mountable against routers is the simple 70 SYN-flood attack, which could potentially exhaust the router's CPU. 72 The in-band nature of IP routing and signaling creates a perfect 73 environment for an attacker to put the network itself out of service. 74 The fundamental problems leading to the possibility of a DoS attack 75 on a router are (a) legitimate and forged packets share resources 76 inside the router (such as queues) before the authentication check is 77 performed, and (b) the negative authentication decision is 78 computationally expensive enough to discourage router vendors from 79 performing the check at the line rate. In the latter case, it is 80 important to note that the lack of line-rate processing significantly 81 increases the router's susceptibility to a distributed DoS attack. 83 1.2 Existing Approaches and Disadvantages 85 Potential approaches to the problem known to date include: 87 1. Adding specialized HW elements to the line-card architecture 88 that would allow the line cards to identify packets that need 89 to be authenticated (e.g., OSPF, BGP, RSVP) and perform the 90 MD5 check at the line rate (before the packets are put in any 91 queue), as well as identify TCP SYN packets and limit the rate 92 at which they are sent to the control card. 94 2. Perform aggressive packet filtering at the edges of the net- 95 work, on both customer-facing and service provider peering 96 interfaces to make sure that packets destined for the internal 97 routers are not received from outside the network. 99 3. Use a completely separate set of links for control protocols 100 and customer data, i.e. out-of-band network control. 102 Below are the disadvantages of these methods (correspondingly): 104 1. From the service provider's perspective, additional HW 105 increases the cost of the system and requires upgrades of the 106 line-cards of all routers in a service provider's network. 107 From the Internet security perspective, it will take years 108 before a considerable number of service providers upgrade 109 their routing infrastructure, and thus before the threat of 110 DoS attack on the Internet routing system is sufficiently mit- 111 igated. 113 2. Many of today's deployed Internet core routers do not have the 114 ability to perform line-rate access control list (ACL) pro- 115 cessing at high speeds, which means that the inter-service 116 provider links will remain insecure. Combined with the fact 117 that not all service providers filter potentially dangerous 118 packets on the customer interfaces, this approach has the same 119 disadvantages from the deployment and Internet security per- 120 spective as the first approach. 122 3. While the out-of-band control scheme is extremely interesting, 123 implementation could require substantial modification to the 124 routing protocols and complete re-architecting of the service 125 provider networks. From the architectural point of view, it 126 would also require a major shift from the assumption that con- 127 trol-plane connectivity implies connectivity of the data 128 plane. 130 The solution described in this document allows service providers to 131 improve their network without major hardware upgrades , changes to 132 routing protocols or network architecture, and with limited software 133 modifications. 135 2 Solution 137 2.1 Overview 139 The proposed mechanism uses the fact that there are only a limited 140 number of devices in a network that have a legitimate right to send a 141 packet to a router's control plane. This set of devices includes, of 142 course, other routers in the service provider's network, and network 143 operations center (NOC) machines. The rest of the devices in the 144 Internet, including user hosts, and routers in other service provider 145 networks should not need to send packets to the routers internal to 146 the first provider's network.. 148 They key aspect of the proposal is marking of packets from the set of 149 trusted devices in a way that it would either be impossible to spoof 150 by an untrusted device or that would ensure that even if an attacker 151 created such a packet, it would be dropped by the routers already 152 deployed in the Internet today. One option of such marking described 153 in this document is using a different protocol ID in the layer-2 154 frames when sending IPv4 control packets among the routers. We call 155 this "control IPv4 encapsulation". All Internet routers used today 156 will drop these packets as unrecognized by default. This step makes 157 sure that such a packet marking technique can be relied upon. 159 The next step is a small modification to the router's local IP pro- 160 cessing and encapsulation logic to allow only control-encapsulated 161 IPv4 packets to be sent to the control plane along the normal path. 162 Other packets are considered dangerous and are put on a heavily rate- 163 limited queue. This ensures that outsider attacks do not exhaust 164 resources used for communication with trusted devices. Note that the 165 encapsulation check has O(1) complexity, and can easily be performed 166 at line rate even in legacy routers without major HW or SW modifica- 167 tions. One of the many advantages of this approach is in the fact 168 that no additional packet filtering at the customer or peering inter- 169 faces is requires by the service provider, since user data packets 170 always enter the network as dangerous. 172 Note that the proposed mechanism does not require modification or 173 affect existing Internet user data or network troubleshooting proto- 174 cols--ICMP will still work they way it works today, so ping, tracer- 175 oute, TCP path MTU discovery, remain functional. The reason for this 176 is the fact that the proposal only helps routers quickly classify 177 packets as trusted and untrusted, but does not require untrusted 178 packets (e.g., ICMP) to be dropped. Of course, if a router already 179 has a capability to identify ICMP packets and put them on a separate 180 queue, the service provider may decide to configure the router to 181 drop all untrusted packets except for ICMP. 183 It should also be noted, that this proposal is not an attempt to pro- 184 tect from compromised trusted routers or insider attacks, neither it 185 is an attemp to substitute existing security mechanisms in routing 186 protocols. Instead it helps to protect the routers from outsider 187 (user-level) attacks, such as distributed DoS attacks based on infec- 188 tion of untrusted devices (Internet-connected hosts) with computer 189 viruses turning them into traffic generators targeted against 190 Internet routers, which is considered to be a bigger threat today. 191 In the situation where a trusted router is compromised, the mechanism 192 still offers additional security by limiting the potential affect of 193 the attack to the boundaries of the trust domain the compromised 194 router participates in through the notion of interface groups. 195 Routers implementing this mechanism and not participating in that 196 domain will not be susceptible to the attack. 198 Finally, the mechanism allows for gradual deployment across the 199 Internet without a flag day and incremental security gain as it is 200 deployed wider. 202 2.2 Separating Data and Control Encapsulation 204 As discussed before, the packet marking technique needs to have the 205 property of default invalidity in order to make sure that no data 206 flowing on the Internet today is considered trusted and is accepted 207 into a service provider's network with such marking if an attacker 208 tried to spoof a packet. Using techniques like DSCP-code marking or 209 IP options does not satisfy this requirement, as it would call for 210 filtering at every customer-facing router in the Internet to make 211 sure that no user data packet is injected with this reserved DSCP 212 value. This is the reason why the author has chosen to use a layer-2 213 encapsulation technique to achieve this--frames carrying unknown pro- 214 tocols are dropped by todays deployed routers. 216 This document describes two possible methods for a different layer-2 217 encapsulation--a separate protocol ID, and a link-local MPLS label. 218 Each has its own advantages and disadvantages discussed below . 220 Option 1: New Protocol ID 222 As a protocol ID value is defined for IPv4 and IPv6 for each used 223 media type today (such as Ether_type code), it would be possible to 224 define IPv4-control and IPv6-control protocol IDs. 226 The advantage of this method is an implicit 100% guarantee that if 227 the protocol ID is selected from an unused space, the packets will 228 be unrecognized. This approach also seems like the "clean" way of 229 doing this. 231 The disadvantage of this approach is that the control encapsulation 232 protocol ID will need to be defined for each media type used today, 233 which may take a while. Another disadvantage is that in case of an 234 MPLS network, a control packet maybe put on an LSP together with 235 data packets, so the receiving router wouldn't be able to tell the 236 difference. Getting around this problem may require maintaining two 237 sets of next-hops per route in the data path. See Option 3 below, 238 however. 240 Option 2: Link-local MPLS Label 242 This method is more of a hack and relies on the fact that MPLS 243 encapsulation is either defined for or mapped to most of today's 244 used media types. It should be possible to reserve a single label 245 value (or 2 if a separate one for IPv6 is deemed necessary) from 246 the "reserved" range (values 4-15 defined by [MPLS-STACK]), declare 247 it to be link-local, disallow this value from being used for tran- 248 sit MPLS LSPs, and use this as the control encapsulation. Note that 249 since the label would only have significance on the local link, it 250 can be reused on all links. Control messages used for signaling of 251 transit label switched paths (LSPs) can be safely put on top of 252 this label, as there are no order of origin dependencies. Routers 253 that do not support MPLS would not need to have any MPLS code added 254 and could just treat this as a special sequence of octects in the 255 link frame that identifies control encapsulation. 257 When a control packet for a multi-hop routing session (iBGP or OSPF 258 virtual link) is put on an LSP, an extra label with the reserved 259 value would be added on top of the label stack thus identifying the 260 control packet. 262 Because service providers generally do not support MPLS on their 263 customer interfaces, and because the label value would be taken 264 from the reserved space, it would be impossible for an Internet 265 user to spoof a control packet using existing Internet infrastruc- 266 ture. 268 The advantage of this approach is that only a single value for the 269 label would need to be reserved. 271 The disadvantages are that more modifications of the router 272 microcode are necessary. 274 Option 3: Combined 276 It is possible to use the new protocol ID whenever a control packet 277 is not MPLS-encapsulated, and use an extra reserved label whenever 278 it is put on an LSP. See section XXX for more information on sup- 279 port of MPLS networks. 281 Control-plane software is then modified to make sure that all 282 locally-originated packets that are relevant within the service 283 provider's network only (such as routing protocols, MPLS signaling, 284 telnet, ssh, SNMP, etc.) are control-encapsulated when the outbound 285 interface is configured as such. Control packets that need to be 286 received by the users (ICMP) are either encapsulated as before (data 287 encapsulation) or also as control. In the latter case, they will be 288 data-encapsulated as soon as they leave the trust domain of the ser- 289 vice provider. 291 2.3 Interface Groups 293 When deploying this mechanism, the service provider will need to 294 identify a group of interfaces where the control encapsulation should 295 or should not be used. There will most probably be a group of inter- 296 faces used for the backbone connection, and another group used for 297 customer connections and peering with other service providers. 299 The described mechanism uses the notion of an "interface group". 300 There is practically no complexity associated with an interface 301 group--each interface has an interface-group attribute associated 302 with it. Two interfaces are considered to be in one interface group 303 if their interface-group attributes are equal. The service provider 304 is expected to configure the interface group attributes of the inter- 305 faces to match the trust communities, as in the following example. 306 Backbone interfaces, interfaces to customer A, interfaces to customer 307 B, interfaces to service provider X, and interfaces to service 308 provider Y, would all be put in separate interface-groups: "back- 309 bone", "cust-A", "cust-B", "peer-X", "peer-Y", correspondingly. 311 As we will see further in the document, when a control-encapsulated 312 packet is forwarded across an interface-group boundary, it become 313 data-encapsulated (untrusted). This is to ensure that if, for exam- 314 ple, two service providers are using control encapsulation for their 315 eBGP session, or if an eBGP session between a service provider and a 316 customer is control-encapsulated, forged packets originated by a 317 potentially compromised BGP peer and destined inside of the service 318 provider's network are not considered trusted beyond the border 319 router. In other words, we trust control traffic from a customer or 320 another service provider only as far as it needs to go and no fur- 321 ther. Again, once a control-encapsulated packet crosses an interface- 322 group boundary, its encapsulation is changed to data and it will be 323 considered as untrusted by all other routers. 325 2.4 Modified Local Processing and Packet Encapsulation Procedures 327 The following new interface parameters used by the modified algo- 328 rithms are introduced. 330 InterfaceGroup: 331 the ID of the group the interface belongs to 333 IpCtlSendEncap: 334 defines which encapsulation should be used on the interface to 335 send control packets originated locally by the router or 336 received as control-encapsulated on another interface. Possi- 337 ble values: Data, and Control. Default: Data. 339 IpCtlRcvEncap: 340 defines the type of encapsulation that needs to be used in 341 order for the received packet to be allowed for local process- 342 ing by the RP as trusted. Values: Data, Control, Both . 343 Default: Data. 345 The router's behavior is modified as follows. 347 1. A packet addressed to the router itself is considered trusted 348 and is allowed to be locally processed (queued to the control 349 card) if IpCtlRcvEncap of the receiving interface is set to 350 Both, or matches the encapsulation that was used to send the 351 received packet. Otherwise, the packet is put on a "slow" 352 queue (or dropped if the router has the capability to recog- 353 nize ICMP packets and still allow them to be processed in a 354 rate-limited fashion). 356 2. The router uses Control encapsulation for an outgoing packet 357 if IpCtlSndEncap of the outbound interface is Control AND the 358 packet: 360 a) Has been locally originated by the router itself, OR 362 b) Has been received in Control encapsulation AND Interface- 363 Group parameters of the inbound and outbound interfaces 364 are the same (the packet is not leaving its trust 365 domain.) 367 Otherwise, (the packet is untrusted or is leaving its trust 368 domain by crossing the interface-group boundary), Data encap- 369 sulation is used. 371 2.5 NOC Support and "Trusted" Interfaces 373 Hosts on the NOC segments of the service provider's network are an 374 example of trusted devices that are not routers. However, unlike 375 routers, it is unrealistic to expect hosts within the NOC segment to 376 exchange packets using Control encapsulation, as this would require 377 modification to many operating systems. Another specific of a NOC 378 segment is the fact that it majority of cases, it will need to be 379 able to communicate with the rest of the service provider's network 380 using both Data and Control encapsulated packets. The following is an 381 explanation why. 383 It is already a common practice to allow incoming telnet, ssh, and 384 snmp packets to routers only if they were originated within a NOC 385 segment (this is usually done by configuring CLI and SNMP-specific 386 filters by access control lists), however, the network administrators 387 are rarely physically located on the NOC premises-many of them work 388 from home and are often mobile. This is why management access to the 389 routers usually requires establishing a secure shell (SSH) session to 390 a server in the NOC, and then from there another SSH session to a 391 router. Of course, the SSH server is usually behind a firewall (let's 392 call it FW1). In our case, this would be a firewall that communicates 393 Data packets with the rest of the service provider's network. 395 Since all telnet, ssh, snmp, etc. packets going from the NOC segment 396 to the routers in the network need to appear in Control encapsula- 397 tion, regular data packets exchanged on the NOC segment at some point 398 need to be sent out as Control encapsulated packets. This, of course, 399 introduces a potential security threat (if the hosts on the NOC seg- 400 ment were used to attack the routers, all forged packets would be 401 considered by routers as trusted.) However, it is much less expensive 402 for a service provider to protect its routers from its own NOC seg- 403 ments by installing a firewall (let's call it FW2) that will make 404 sure that only valid packets are sent out as control to the routers 405 in the network. 407 Note that FW1 and FW2 are only functionally separate, but may physi- 408 cally be the same device. 410 There are potentially two ways how NOC data packets can be injected 411 as Control into the network: a) FW2's network-facing interface sup- 412 ports Control encapsulation, and b) FW2 has no support of Control 413 encapsulation, but the first-hop router it is connected to performs 414 the "translation". The former case is the most secure, while the lat- 415 ter is the most probable, at least in the beginning. Below is how the 416 router performs the translation function. 418 The notion of a "trusted interface" is defined by introducing the 419 following parameter: 421 IpTrustedInterface: When True, identifies a trusted interface. It is 422 expected that only very few interfaces in the service provider's net- 423 work will be configured as Trusted (for example, interfaces connect- 424 ing a NOC segment to the rest of the network through a firewall.) 425 Possible values: True, and False. Default: False. 427 The router's behavior is further modified to accommodate the notion 428 of trusted interface as follows: 430 1. A packet received on a Trusted interface in any encapsulation 431 is treated as if it was received in Control encapsulation 432 (i.e., is allowed to be locally processed and is sent out 433 using Control encapsulation as long as it stays within the 434 same interface group). 436 2. All packets (trusted and untrusted) sent out of a Trusted 437 interface are Data-encapsulated. 439 DISCUSSION: we may want to allow only trusted packets to be sent on a 440 Trusted interface towards NOC. This will make the job of FW2 much 441 easier, but will cut off ICMP messages coming from outside the net- 442 work or from a different trust domain if the service provider has 443 many. 445 2.6 ICMP, Ping, and Traceroute 447 ICMP needs special attention, because its scope of validity is not so 448 well contained as for routing and signaling protocols. Let's consider 449 how this proposals handles ICMP by looking at the following generic 450 combinations for ICMP messages: 452 1. Originated by and addressed to devices within the same trust 453 domain, for example, an ICMP "Echo Request" message originated 454 by a NOC host and received by a router. Same for an ICMP "Echo 455 Reply". All ICMP messages will be considered trusted. No 456 issues here. 458 2. Originated by a trusted device (router), addressed to an 459 untrusted one (a ICMP "Destination Unreachable" to an Inter- 460 net-connected host, for example). The router will inject the 461 packet using Control encapsulation, however, as the packet 462 leaves the service provider's network, it will be sent out 463 using Data encapsulation (see step 2 in the modified router 464 algorithm), as expected by the receiver. 466 3. Originated by an untrusted host, addressed to a service 467 provider's router. The router will put the packet on the 468 'untrusted' queue, and it will be processed. 470 4. Originated by and addressed to an untrusted host. The message 471 will enter and leave the network as untrusted data without 472 touching any router's control plane. 474 Traceroute from the outside world does not present any problem, 475 because Control-encapsulated ICMP messages sent back to the probing 476 host will be automatically converted to Data as they leave the trust 477 domain. 479 Traceroute within the network (e.g., from NOC or a router) is not a 480 problem because the messages are exchanged in Control encapsulation. 481 If traceroute crosses multiple trust domains or goes outside the ser- 482 vice provider's network, ICMP messages will come back as Data and 483 will go through a FW to NOC or may be received through the slow queue 484 by the router (if traceroute is originated by the router.) 486 2.6 Routing Protocols 488 One of the advantages of the described mechanism is that no modifica- 489 tion of existing routing protocols is required. Routing protocols 490 still work over IPv4, the only difference is actual layer-2 encapsu- 491 lation of those packets, which is (in the simplest case) Control for 492 all packets originated by a router. 494 The routing paradigm remains the same--the messages are sent inbound 495 across the same physical links as data packets. Control and data are 496 only virtually separated, just enough to make a decision on whether a 497 packet should be considered from a trusted source or not. 499 Because the IS-IS routing protocol encapsulates its PDUs in L2 500 frames, as opposed to IP packets, it is not susceptible to the out- 501 sider attacks, and hence no modification to IS-IS encapsulation is 502 required. If IS-IS-in-IP is used, the routers need to make sure that 503 the IP packets is Control-encapsulated. Note that the fact the IS-IS 504 routing protocol is not susceptible to outsider attacks does not mean 505 that ISP running IS-IS should not be worried about those attacks. 506 There's a whole set of potential CPU-based attacks which an outsider 507 could mount, and this set is constantly growing. 509 2.7 Multicast 511 There are two aspects of IP mutlicast we're interested in from the 512 routing security point of view: routing protocols, and (S,G) state. 514 From the routing protocols perspective, service provider's routers 515 are protected by the presented mechanism as with unicast. 517 The link between data and control plane required to maintain the 518 (S,G) state is part of the multicast architecture and may be consid- 519 ered by some as an issue (it is definitely safer to decouple control 520 and data planes of the network as much as possible). Presented secu- 521 rity mechanism does not affect it in anyway. The service provider 522 will have to make an informed decision whether to deploy multicast in 523 its network or not keeping in mind the possibility of some router 524 implementations not being able to keep up with large amounts of (S,G) 525 state. 527 2.8 MPLS Networks 529 When the mechanism is deployed in an MPLS network, it is possible for 530 any IP packet (including a control one) that is sent over multiple 531 hops to be put on an LSP due to an LSR using either LDP-derived FECs 532 or IGP-shortcut FECs. Because layer-2 encapsulation is not preserved 533 when an IP packet is put on an LSP, it will be impossible for the 534 receiving router to tell the difference between data and control 535 packets if just a different link-layer protocol ID was used to mark 536 trusted packets. 538 To solve this problem, the LSR putting the control packet on an LSP, 539 adds an extra inner label with the reserved value described before to 540 the label stack. 542 If penultimate hop popping (PHP) is used in the network, the tail-end 543 LSR may not even notice the fact that the packet has traveled on a 544 LSP if the MPLS-label approach is used for encapsulation, because the 545 LSR will receive the packet with only one--reserved--label. 547 If the PHP mechanism is not used, the receiving LSR, after popping 548 the outer label, will need to recognize the reserved value of the 549 inner label and treat the packet as Control-encapsulated. 551 3 Deployment Considerations 553 The following subsections discuss how the described mechanism would 554 be deployed in a service provider's network. Note that we consider 555 the final setup, after all transitional steps. The transition scenar- 556 ios are described in a separate subsection 558 3.1 Backbone-only Routers 560 Routers where all interfaces are connected to internal links will 561 most often have all of them configured to be in the same interface 562 group. It is possible of course, to have multiple Control trust 563 domains within a single service provider's network if for example, 564 BGP AS confederations are used. In this case, each member-AS would be 565 a separate trust domain and some BGP speakers would have more than 566 one interface group. One consideration related to running a network 567 with multiple trust domains is the fact that control message that are 568 not naturally scoped to a single trust domain (such as ICMP) will be 569 encapsulated as Data once they leave the trust domain they have been 570 originated in. This means that Control encapsulation-aware firewalls 571 connecting the NOC segment need to also receive and process Data- 572 encapsulated ICMP. 574 Receiving and sending encapsulation of control packets would be set 575 to Control on all interfaces. 577 3.2 Customer-facing Routers 579 Customer facing routers will have more than one interface group. 581 One group will be configured for all backbone links. In this group 582 receive and send encapsulation will be configured as Control. 584 For each customer, all interfaces providing connections to it will be 585 configured as a separate interface group. The type of encapsulation 586 is expected to be Data for a long time, before customer routers start 587 supporting Control encapsulation. With Data encapsulation, the router 588 is allowed to send Data-encapsulated control packets to the control 589 plane CPU. Other packets, supposedly both valid data and potentially 590 forged packets, are forwarded onwards to the network using Data 591 encapsulation, so other routers in the network won't allow these 592 packets to the control plane in case of an attack. 594 When Control encapsulation is supported by the customer routers, the 595 service provider will configure send and receive control packet 596 encapsulation on those links to be Control. This will prevent DoS 597 attacks on the customer-facing router on those links. 599 3.3 Peer-facing Routers 601 Peer-facing routers will be configured similar to the customer-facing 602 routers. If the peering routers do not support Control encapsulation, 603 the routers are configured to allow Data-encapsulated packets to be 604 received by the control CPU. Potential attacks against the border 605 router could be prevented by the BGP TTL hack (though implementing 606 Control encapsulation seems easier.) service provider's internal 607 routers will not be susceptible to the attacks originated in other 608 service providers, because forged packets will be sent as Data and 609 won't be allowed to the routers' control plane CPUs. When Control 610 encapsulation is supported, the border router will be protected from 611 the DoS attack on the links to those service providers supporting 612 this technique. 614 An important point to keep in mind here is the fact that trust 615 domains of the service providers are not merged when they peer with 616 each other. Links used to peer with other service providers are put 617 in a separate interface group from the backbone interface group. This 618 means that even if routers of another service provider are compro- 619 mised and forged packets are sent as Control to us, they would first 620 be translated to Data encapsulation by that service provider's border 621 router, but even if they are not for some reason (or if the service 622 provider's border router is compromised), our border router will 623 "translate" any forged control packets into Data as they cross the 624 boundary between the peering and the backbone interface group. 626 3.4 Internet Exchgange Points and Help from LAN Switches 628 In the case where a LAN segment is used to connect devices under dif- 629 ferent administrative control (as in the case of an Internet Exchange 630 point, for example), it is possible that some connected devices may 631 not be trusted enough for others to agree to receive control-encapsu- 632 lated packets from them. In order to avoid line-rate source-based 633 filtering, LAN switches may be equipped with a small bit of addi- 634 tional functionality controlling whether inbound control-encapsulated 635 packets are allowed on a specific port. Because this check is done on 636 a per-port basis and the switch does not need to look further than 637 the layer-2 frame, this check can easily be performed at the line 638 rate without performance degradation. The LAN switch administrator 639 would then have to ensure that control frames are allowed only from 640 trusted devices. 642 From the security perspective this essentially means that the service 643 provider, normally only marginally trusting its IX peers, would need 644 to trust the IX administrator's decision on whether the remote device 645 is trusted or not, in other words, when a service provider agrees to 646 accept control frames on an IX-connected interface, it essentially 647 agrees to trust the security of that IX. However, though this means 648 that IX-connected routers are less secure from each other, even if a 649 trusted IX router is compromised, the effect of the attack is limited 650 to the border router by the notion of the interface groups. Besides, 651 IX-connected routers still have the same level of security against 652 user-level attacks, which is thought of as a bigger threat than an 653 attack from a compromised or untrusted IX-connected device. 655 3.5 NOC 657 As describe before, NOC segments can be connected to a service 658 provider's network either through a Control-encapsulation-aware FW, 659 or through a regular FW connected to a router implementing Trusted 660 interfaces. 662 3.5 Transition Scenarios 664 To be completed. 666 Note that no flag day is required and gradual deployment gives incre- 667 mental security increase. 669 4 Security Considerations 670 The described proposal does not claim to provide complete protection 671 of routers against all types of attacks. Instead, it raises the bar 672 by attempting to prevent attacks mounted by outsiders that have no 673 access to the SP's network except for basic IP connectivity. These 674 types of attacks are considered to be the immediate threat on the 675 Internet routing system and the proposal attempts to protect against 676 it without requiring expensive hardware upgrades. By virtually sepa- 677 rating control and data packets, the level of security in IP networks 678 is raised to the one normally found in ATM or Frame Relay networks, 679 where routing and signaling are virtually out-of-band. This level of 680 security is considered by many to be just enough to feel comfortable. 682 Insider attacks, based on the physical access to the SP's equipment 683 or on compromising a trusted device (such as a router or a NOC- 684 attached host) are not prevented by this mechanism. 686 The described proposal relies on the notion of a trust domain, which 687 implies that if a router is configured to accept Control-encapsulated 688 packets on an interface, the administrator administrator has full 689 control of the devices attached to the segment and capable of sending 690 Control-encapsulated packets (in reality, any connected device should 691 be assumed to be capable of doing so), and those devices are autho- 692 rized to send them. In other words, physical security needs to be 693 insured by the SP. This practically means that no devices that with 694 high probability can be compromised by an outside attacker (such as 695 servers, or hosts) should be allowed on the segments used for router 696 connections. Point-to-point links used between routers encourage this 697 requirement by their very nature, while LAN segments require more 698 attention to ensure no unauthorized devices have access to them. 699 Fortunately, this is already the best current practice that the ser- 700 vice providers follow. In the situations where a device connected to 701 an otherwise trusted segment is considered to be highly susceptible 702 to being compromised, some help from the LAN switch used to implement 703 the segment is required. See Section XXX for more information. 705 Finally, because the described mechanism does not prevent from 706 insider attacks, it should not be considered as a substitute for 707 existing or future authentication mechanisms in routing protocols or 708 other security measures used in the service provider networks (e.g., 709 SSH). Instead, they should be considered complimentary to each other 710 and used together. In fact, the more elaborate and computationally 711 expensive routing protocol-specific mechanisms become, the easier it 712 will be for an outside attacker to bring a router to its knees, and 713 the more important it will be to separate control and data encapsula- 714 tion in the Internet. 716 4. Intellectual Property Considerations 717 The IETF takes no position regarding the validity or scope of any 718 intellectual property or other rights that might be claimed to per- 719 tain to the implementation or use of the technology described in this 720 document or the extent to which any license under such rights might 721 or might not be available; neither does it represent that it has made 722 any effort to identify any such rights. Information on the IETF's 723 procedures with respect to rights in standards-track and standards- 724 related documentation can be found in BCP-11. Copies of claims of 725 rights made available for publication and any assurances of licenses 726 to be made available, or the result of an attempt made to obtain a 727 general license or permission for the use of such proprietary rights 728 by implementors or users of this specification can be obtained from 729 the IETF Secretariat. 731 The IETF invites any interested party to bring to its attention any 732 copyrights, patents or patent applications, or other proprietary 733 rights which may cover technology that may be required to practice 734 this standard. Please address the information to the IETF Executive 735 Director. 737 The IETF has been notified of intellectual property rights claimed in 738 regard to some or all of the specification contained in this docu- 739 ment. For more information consult the online list of claimed 740 rights. 742 5. Acknowledgements 744 Thanks to Ben Crosby, Steve Buchko, Randy Bush, John Heasley, Radia 745 Perlman, and Tony Li for an early review of this work. 747 6. References 749 [OSPF] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet 750 Engineering Task Force, 1998. 752 [TCP-MD5] A. Heffernan. Protection of BGP Sessions via the TCP MD5 753 Signature Option. RFC 2385. 1998. 755 [MPLS-STACK] RFC 3032. MPLS Label Stack Encoding. 757 7. Authors' Addresses 759 Alex Zinin 760 Alcatel 761 E-mail: zinin@psg.com 763 Full Copyright Statement 765 Copyright (C) The Internet Society (2005). This document is subject 766 to the rights, licenses and restrictions contained in BCP 78, and 767 except as set forth therein, the authors retain all their rights. 769 This document and the information contained herein are provided on an 770 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 771 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 772 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 773 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 774 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 775 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.