idnits 2.17.1 draft-fu-diffserv-security-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 41 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 688, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '1') ** Obsolete normative reference: RFC 2598 (ref. '3') (Obsoleted by RFC 3246) ** Downref: Normative reference to an Informational RFC: RFC 2638 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DiffServ Working Group Zhi Fu, S. Felix Wu 2 Internet Draft T.S. Wu, He Huang 3 Expiration Date: April 2000 NC State University USA 5 Fengmin Gong 6 MCNC USA 8 Oct. 1999 10 Security Issues for Differentiated Service Framework 11 13 Status of this Memo 15 This document is an Internet Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its Areas, and its Working Groups. Note that 20 other groups may also distribute working documents as Internet 21 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 26 Internet Drafts as reference material or to cite them other than 27 as a "working 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 Discussion and suggestion for improvement are requested. All 36 discussion may be sent to DiffServ mailing list or to individual 37 authors. Distribution of this draft is unlimited. 39 Copyright Notice 41 Copyright (C) The Internet Society (1999). All Rights Reserved. 43 draft-fu-diffserv-security-00.txt Oct. 1999 45 1. Abstract 47 This document provides a security analysis for the differentiated 48 service framework. We studied what kinds of attacks can be performed 49 and how badly attacks can affect network services under the DiffServ 50 framework. Without a careful investigation of potential attacks and 51 impacts, the protection systems can not be effectively developed and 52 evaluated. The DiffServ working group, as a whole, needs to decide 53 what the important security issues are (or what specific attacks we 54 need to defend against). Then, it will be meaningful to discuss the 55 possible solutions to those realistic threats to DiffServ networks. 56 The conclusion reached is that intrusion detection & response systems 57 need to be developed to protect QoS provisioned by DiffServ. The 58 threat model specified in this report then can be used to evaluate 59 the effectiveness of defense systems for the DiffServ framework. 61 2. Overview of DiffServ Architecture 63 Current "best-effort" service of Internet is not adequate for 64 applications with stronger Quality of Service (QoS) requirement in terms 65 of delay, loss rate, jitter, error rate etc. Differentiated Service 66 (DiffServ)[1,2,3,4] provides several classes of service to meet 67 heterogeneous application requirement. DiffServ currently defines 68 Expedited Forwarding (EF) Per-hop Behavior(PHB) and Assured Forwarding 69 (AF) PHB [3,4], in which PHB is the forwarding treatment of a certain 70 class of traffic. EF service is to provide a low loss, low delay 71 "Virtual Leased Line" service to all the behaved traffic (conform to a 72 contracted peak rate and burst) while AF is to provide the forwarding 73 assurance over the Internet (no matter lightly loaded or in times of 74 congestion), i.e. packets are unlikely to be dropped as long as it stays 75 within the subscribed profile. All other traffic is treated as best 76 effort service. 78 Within DiffServ framework, a user needs to pay for the specific quality 79 of service he desires. A contract between a customer and a provider is 80 usually described in the form of a service level agreement (SLA). The 81 customer could be either a single user, a corporation network or another 82 ISP. The SLAs contain profiles (rate, burst, time of transmission etc. 83 of the traffic from the customer to the provider network) for different 84 service classes, expected service performance and the dispositions for 85 the in- or out-of-profile traffic etc. 87 D1 D2 D3 D4 88 +----------+ +-----------+ +-----------+ +----------+ 89 | | | | | | | | 90 | | |500 | |500 | |500 | 91 | S ==FR==ER====IR=========ER=====IR=========ER=====IR====== D | 92 | | | | | | | | 93 +----------+ +-----------+ +-----------+ +----------+ 95 draft-fu-diffserv-security-00.txt Oct. 1999 97 FR: First router is the router closest to the source on the path 98 ER: Egress router is the router from which a flow exits one domain 99 IR: Ingress router is the router from which a flow enters one domain 101 Fig. 1 A Simplified DiffServ Architecture 103 Figure 1 illustrates the basic process for DiffServ networks to 104 provision differentiated services. Packets will be first classified 105 into micro flows based on subscribed service profile and marked (six 106 bits in TOS byte of IP packet are used as DiffServ Code Points (DSCP) 107 to mark the different service classes) correctly at ingress edge router 108 (typically first router on the path). All the routers in the core of 109 networks only perform simple forwarding function: put packets into 110 different queues according to DS code points conveyed then forward them 111 as scheduled (various scheduling mechanisms can be used, e.g. priority 112 queue, WRR, CBQ etc.). Some queue management mechanisms, like RED or 113 RIO, could be used to preferentially drop low precedence packets to 114 provide low drop rate for high precedence packets during congestion. No 115 per-flow classification and admission control is necessary for interior 116 routers. Packets will be measured and conditioned (policing or shaping) 117 in aggregate (per service class) according to DS code point at the 118 border routers to enforce the agreement. Egress routers might perform 119 shaping to ensure the conformance and ingress routers must do policing 120 to protect their domains against excessive traffic from other domains. 121 Unconformed EF packets will be dropped and unconformed AF traffic may be 122 re-marked to lower precedence class. 124 The DiffServ architecture is simple and scalable in the sense that only 125 aggregate traffic is checked at boundary of networks and no per-flow 126 information state and processing is needed in network core. However, 127 fairness is hard to maintain within aggregation thus potentially 128 attackers could inject some illegitimately self-labeled (mark as EF or 129 AF) packets into network to either steal resource or seriously bring 130 down the quality of network service of other traffic. Also, attackers 131 can perform modifying, dropping and delaying attacks to degrade or 132 damage QoS provisioned by DiffServ networks. We will discuss security 133 issues in detail next. 135 3. Vulnerability analysis of DiffServ 137 3.1 Attacker's objectives, capabilities and operations 139 The attackers to QoS provisioning of DiffServ networks aim at stealing 140 unprovisioned resources or damaging the QoS (denial of QoS) of other 141 traffic (either a particular victim microflow or a group of flows). The 142 higher price associated with the enhanced services creates incentive to 143 steal. With degradation of delay, loss rate, jitter or error rate, 145 draft-fu-diffserv-security-00.txt Oct. 1999 147 caused by attacks, legitimate flows may be unable to achieve the desired 148 QoS, even could lead certain applications to crash. Service provider may 149 lose customers or business contracts when a bunch of flows are badly 150 affected within the provider's domain by attacks. 152 For the attacker's access point, attacks can be launched from end-hosts, 153 routers or communication links. If we consider attacker's capability, 154 attackers could perform attack operations on the data packet flow such 155 as injecting, delaying, dropping, modifying, and eavesdropping. Attack 156 access points determine what specific attacks are possible. For instance 157 , the attackers who have access on a node not on the transit path of a 158 certain traffic flow can only perform injecting attack, while attackers 159 who are on communication link or node on the transit path of packets can 160 perform all the five attacks on the packets passing by. 162 >From the modeling point of view, given the access point information, 163 we can decide a set of operations that a particular attacker can perform 164 at that point. And, an attack against DiffServ can be defined as a 165 sequence of operations (each with a timestamp) to achieve a particular 166 objective. Formally, an attacker A who has access to a network entity 167 X can perform any of AttackOP = {OP_1, OP_2,... OP_N}. And, an "attack 168 instance" is defined as [A, X, AttackOP, Seq_Att], where Seq_Att = 169 {[OP_r1, t_1], [OP_r2, t_2], ... [OP_rM,t_M]} and 1 <= ri <= N. 171 Following our definition, a randomized attacker can be modeled as the 172 following: 174 Let OP_1 = dropping, OP_2 = delaying X seconds, OP_3 = tampering the 175 message, OP_4 = duplicating Y copies of the message, and OP_5 = behaving 176 normally. When the attack receive a packet/message. The attacker will 177 flip a coin, and with probability P_i, it will perform OP_i. And, if the 178 attacker performs M operations on M incoming packets, the damage to the 179 QoS (delay, throughput, jitter, bandwidth utilization, and availability) 180 is the quantitative difference between the expect QoS when no operations 181 are applied and the observed QoS with those M attack operations. 183 Please note that, in this draft, we have only modeled a single attack 184 point. In the future, we will extend our model to describe coordinated 185 attack access points. 187 3.2 Attacks' mechanisms and impacts 189 In a DiffServ network, a certain amount of bandwidth is 190 configured/allocated at each node for each class. A certain end-to-end 191 QoS requirement is inherently achieved through the concatenation of 192 resource and correct provisioning mechanism (scheduling, classifying 193 etc.) at each node. Besides the bandwidth allocated at each node, the 194 first router and border routers need to be configured with profile 195 based on which they can perform conditioning functions. 197 draft-fu-diffserv-security-00.txt Oct. 1999 199 Attackers could launch QoS attack through two approaches: one is 200 attacking the configuration process and the other one is attacking the 201 data forwarding process. Certain resources have to be pre-allocated, 202 either through automatic protocol (signaling protocols such as RSVP or 203 management protocols such as SNMP MIB or LDAP Policy Schema) or manually 204 configured. Attackers can maliciously tamper with the configuration 205 process to make resource incorrectly allocated and conditioning policy 206 incorrectly executed. Also, the attacker can target directly at data 207 transmission to cause damage to QoS provisioning. 209 3.2.1 Attacking the configuration process 211 3.2.1.1 Attack operations 213 If a manual configuration is deployed, attackers could manage to 214 compromise it via social engineering or physical access. When an 215 automatic protocol is used for configuration, under our model, attackers 216 could only perform the following attack operations: 218 o Injecting Packets 220 The attackers, posing as an configuration authority, can originate 221 packets with bogus configuration information to make the allocation 222 either to be unnecessarily large (waste resource or steal resource for 223 attacker) or insufficiently small (deny service to some legitimate 224 flows). It can achieve the same end through modifying configuration 225 packets. 227 o Modifying Packet Content 229 The attackers in the middle of configuration transit path can 230 maliciously modify (increase or decrease) the allocated resource to be 231 either too large or too small. 233 o Delaying Packets 235 Attackers can delay or replay old configuration packets when the 236 configuration is no longer applicable. Delaying forever becomes dropping 237 attack. 239 o Dropping Packets 241 Attackers can quietly drop the configuration packets. For example, at 242 certain point, a new configuration needs to be issued. If the 243 information is dropped in transit, then the receiving nodes will 244 continue to enforce the old configuration which is incorrect 245 configuration. 247 No matter through physical access or protocol packets access, the 248 consequences of attacks to signaling process of DiffServ is to make 249 configuration incorrectly installed, either too large or too small. For 251 draft-fu-diffserv-security-00.txt Oct. 1999 253 example, if the policing profile of an ingress router is maliciously 254 made larger, then, on one hand, resource may be stolen by passing theft 255 traffic into its domain; on the other hand, the additionally allowed 256 traffic may cause congestion, compete for resource thus degrade QoS of 257 other traffic within the domain. Furthermore, if the policing profile 258 is made smaller, the ingress router may drop much legitimate traffic 259 which should not be dropped. For another example, if some of the 260 flow classification profiles in a first router are tampered then those 261 particular flows may not be able to receive appropriate services. 263 3.2.1.2 Example protocols and their protection 265 The specific implementation of configuration mechanisms could be varied. 266 We use BB's approach [5] as an example to briefly discuss the protection 267 of configuration protocols. 269 o Trustable BBs 271 BBs are responsible for maintaining local policies, allocated resources 272 information and negotiating the resource allocation etc. In addition, a 273 BB is responsible for the resource allocation within its domain. 274 Therefore, BBs play an important role in DiffServ architecture and 275 require high degree of security and trustability to prevent attackers 276 from tampering critical information. 278 o Exchanging negotiation messages between BBs. 280 In DiffServ, each domain's BB establishes a secure association with its 281 peer in the adjacent domain. This mechanism ensured the negotiation 282 message's security. 284 o Configuring interior and border routers 286 Manual configuration or RSVP[7], SNMP etc. could be used in early 287 deployment and another protocol may be developed for future standards 288 work. Then the corresponding security mechanisms for RSVP, SNMP or 289 others could be applied. There must be some mechanisms for 290 authenticating the sender of the configuration information. 292 Since BB is the central authority in an administrative domain, it could 293 also be used as key distribution center (KDC). In such a scheme, every 294 internal router will have a shared secret with the BB and they could 295 exchange cryptographic message with BB using DES or HMD5 with the shared 296 key, thereby guaranteeing the security of configuration messages between 297 BB and other routers within the same domain. Please be aware that those 298 security mechanisms can prevent injecting, modifying, delaying attacks 299 but not dropping attacks. 301 3.2.2 Attacking packet delivery 303 3.2.2.1 Injecting packets with unauthorized code point 305 draft-fu-diffserv-security-00.txt Oct. 1999 307 Because in DiffServ the DS code points mark the differentiated 308 forwarding treatment, the theft- and denial-of-service attacks could 309 be launched against these bits. For example, unauthorized use of the 310 service bits (DSCP) bit may result in service degradation to all other 311 traffic flows in the same class. 313 In DiffServ, the border routers will perform traffic conditioning on 314 aggregated traffic from a certain domain without classifying individual 315 flow's behavior. This feature provides good scalability while introduces 316 security concern that one unbehaved or malicious flow might cause many 317 other behaved traffic packets dropped (or shaped to lower rate) at 318 borders. In addition, the thieves could send out some data packets 319 labeled to enhanced service code point directly without buying proper 320 profile in advance. As a result, some of the theft traffic might be 321 covertly sent to destination at the cost of service degradation of a 322 lot of honestly behaved traffic. Although the first router is 323 responsible to check against the illegitimate marking and issue correct 324 classification and marking onto flows, the attackers can still inject 325 traffic to fool or bypass the first router in the following ways: 327 o It is well known a security problem that source address is untrusted. 328 Attackers sit in an end-host within same subnet of a legitimate customer 329 can send fake traffic to impersonate a legitimate customer (by setting 330 flow identity , such as source address, destination address, port number 331 etc., to be identity of another flow) in order to pass the first 332 router's check. Impersonating traffic sent out from an end-host that is 333 not within the same subnet of the impersonated customer can be detected 334 by the first router from the conflict between the incoming interface and 335 the source address. However, the impersonating traffic from the same 336 subnet of impersonated customer is easier to be detected by 337 investigating the subnet. 339 o If the first router is compromised then the attacker traffic can 340 certainly be injected into DiffServ domains. The traffic also might be 341 injected from the compromised first router itself. 343 o If the source domain is non-DiffServ compliant such that the first 344 router does not perform its classification function, then attackers 345 can inject traffic with a fake source address. Although normally a 346 service provider needs to have MF classification function performed at 347 its ingress router adjacent to a non-DiffServ-compliant domain, it is 348 easier for attackers to inject impersonating traffic than in the case 349 that the source domain is DiffServ capable. 351 o The traffic also might be injected from a router such that no first 352 router is able to do MF classification for the flow. 354 Once the bad packets covertly enters into a DiffServ domain, they have 355 all access to queues and bandwidth prepared for enhanced service class 356 and all the boundary routers only check aggregate traffic's conformance 357 without any specific identifying information for individual flows. The 358 injected flow may cause the following impacts: 360 draft-fu-diffserv-security-00.txt Oct. 1999 362 1). Resources Stolen. 363 D4 364 +----------+ 365 | | 366 |200k | 367 D1 D2 D3 | | 368 +----------+ +----------+ +----------+ +----------+ 369 | E.... | | | | | 370 | \.........500k.............500k......... D5 371 | ====================================== . +----------+ 372 | B===/ | | | | | \ .........F | 373 +----------+ +----------+ +----------+ ==========D | 374 |300k | 375 +----------+ 377 Fig. 2 Example for theft-of-service 379 In figure 2, Bob already paid to reserve its EF traffic from B to 380 D at rate 200kps. The number drawn at each border is the rate 381 negotiated between two neighboring domains. If at this time, the 382 communication path from domain D1 to domain D4 is lightly loaded 383 then the theft flow from E to F at rate 100k might be successfully 384 transmitted. It will not be an uncommon case that provider 385 conservatively over-reserve resource to meet its customers needs, 386 which may be taken advantage of by the thief attackers. 388 2). QoS degraded for other traffic along its path. 390 An injected flow took away some resources supposed to be used by 391 legitimate flows. It may affect other flows encountering it with 392 the following results: 394 a. Longer delay 396 The small queuing delay for EF service is achieved by configuring 397 the service rate greater than the arrival rate. Injected traffic 398 may cause service rate no longer greater than arrival rate such 399 that queuing delay is built up. In the case the injected flow is 400 very bursty, the queuing and the resultant service become more 401 unpredictable. In addition, less bandwidth available to legitimate 402 flows also add in the cause of longer delay. 404 Similarly, some of AF traffic flow's resource could be consumed by 405 injected AF traffic such that longer queuing and transmission delay 406 is introduced. 408 If some provider has egress router to shape the aggregate flow, 409 then the injected flow may cause the aggregate flow to exceed the 410 aggregate profile such that the aggregate traffic has to be delayed 411 by the shaping process. 413 draft-fu-diffserv-security-00.txt Oct. 1999 415 b. Bigger jitter 417 As we described above, an injected bursty EF traffic may cause 418 variable queuing delay such that bigger jitter is brought into the 419 EF traffic service. 421 Bursty traffic is permitted for AF service class. Another injected 422 flow aggregated with other bursty flow may or may not cause worse 423 jitter. 425 c. Larger drop rate 427 In figure 2, if the flow E to F is at rate 200kps, then the aggregate 428 flow will become 400k and part of the aggregate will be dropped at 429 border of D5 such that some of traffic flow B-D is unfairly dropped. 431 Also, too much injected EF traffic may cause EF queue overflow to 432 drop some legitimate EF packets (EF queue buffer is not required to 433 be very large due to little queuing normally experienced by EF 434 traffic). AF service provisioning uses mechanisms such as RED, RIO 435 to selectively drop packets to avoid congestion. Injected traffic 436 may cause more congestion such that good traffic will have higher 437 probability to be dropped than before. In addition, excessive AF 438 aggregate caused by AF traffic injection may cause some good traffic 439 be re-marked to be lower class such as to have more probability to 440 be dropped during congestion. 442 By successfully injecting traffic, attackers can also target at a 443 service provider. For example, in order to bring down one particular 444 ISP's business, the attacker can choose a specific timing at which the 445 ISP's network is heavily loaded (nearly fills SLA) and suddenly send 446 out large amount of EF or AF traffic packets and run. The hit-and-run 447 attack is not easy to locate and this one "hit" could cause a lot of 448 packets being dropped at the ingress border routers and suffer the 449 ISP's customers. 451 The border router is good point to detect unconformance by metering 452 and policing aggregate flow (some provider may have MF classification 453 function to provide special service to certain flows but it will not 454 be a general case for all flows due to its overhead and scalability 455 limitation). However, it may not help too much in narrowing down the 456 attacker. Taking the example in item 2).c, the unconformance is 457 detected and some of the aggregate traffic is dropped at domain D5 458 while the attacker source resides in domain D1. When traffic is dropped 459 at D5, it is well equally possible that the attack traffic originates 460 from either D1, D2, D3 or D4. 462 Another example is depicted in the figure 3 as the following: 464 draft-fu-diffserv-security-00.txt Oct. 1999 466 D5 467 +----------+ 468 | | 469 | F ~ | 470 | 200 ~ | 471 +-------~--+ 472 ~ 473 D1 D2 D3 ~ D4 474 +----------+ +-----------+ +-------~---+ +----------+ 475 | | | | | ~ | | | 476 | | |500 | |500 ~ | |500 | 477 | B=====================================~==============D | 478 | C.500........ 500~ ~|~ ~ ~|~ ~ ~ ~ | | | 479 +----------+ +-.-----~---+ +-----------+ +----------+ 480 . ~ 481 . D6 ~ 482 +-.-----~--+ 483 | . ~ | 484 | . ~ | 485 | . 500 ~ | 486 +-.-----~--+ 487 . ~ 488 . ~ 489 . ~ 490 A E 492 Fig. 3 Example for injecting attack 494 In the example shown in fig.3, Alice sends EF traffic from A to C ( 495 drawn as ...stream) at 200kbps and Bob sends some EF packets from B to 496 D ( drawn as === stream) at 500kbps. An vicious attacker Eve who aims 497 at undermining Bob's traffic sends illegitimate packets from E to F ( 498 drawn as ~ stream) at 250kbps. Suppose there is no other traffic at this 499 time. Then D6 and D2's ingress router will OKey all Alice and Eve's 500 traffic while D3's ingress policer with profile 500kbps has to drop some 501 of aggregate traffic which belongs to either Bob or Eve. 503 Furthermore, we can see that, Eve's illegitimate traffic will cause 504 dropping at ingress points of both D3 and D5 (if there is a legitimate 505 flow traversing D5 at this time, some of it might also be dropped at 506 border of D5.) Therefore, one bad flow could bring about damages 507 involving multiple regions, although ingress policing can help to reduce 508 the bad effect of damage propagation across the domain boundaries. 510 So we know when the border routers detect unconformance, we can never 511 be sure which domain the attack comes from. It is not easy to narrow 512 down the attackers to a specific domain. The main problem is that the 513 border routers treat traffic in aggregation without identifying 514 individual flow. This characteristic could grant vicious attackers great 515 opportunities to launch various attacks. The difficulty of catching the 517 draft-fu-diffserv-security-00.txt Oct. 1999 519 attackers lies in that the attacking can originate from possibly 520 anywhere and destine to anywhere as long as it has a cross with the 521 target flow, which may lead to the good flow's packets get dropped at 522 the cross point. 524 3.2.2.2 Unauthorizedly modifying header info of packets 526 Attackers on the path can illegitimately modify service bit such that 527 the services differentiated based on the service bits are distorted. For 528 example, flow A is registered for EF service for "virtual leased line" 529 type delivery while flow B reserves AF service for low loss delivery. 530 Attackers could modify flow A's service bit to be AF and flow B's 531 service bit to be EF. As a result, flow A does not get real time 532 delivery service as desired while flow B either get EF service ( 533 attackers stole resource for flow B) or some of flow B are dropped for 534 unconformance at ingress policer (the EF aggregate is not in conformance 535 with aggregate profile). 537 Attackers can modify some traffic's code points to attack some other 538 flows. For example, one best effort flow which is maliciously upgraded 539 to EF service will possibly make other EF flows dropped at policers. 541 For AF service, generally one AF class traffic can be re-marked to other 542 class for excessive traffic detected at ingress policer. It is hard to 543 distinguish that the AF service bit is modified by ingress policer 544 legitimately or by attacker maliciously. 546 Besides modifying service bit, attacker could also spoof on other fields 547 . For example, since the leaf router classify packets according to 548 source address, destination address, port number, protocol etc. fields, 549 the attacker can modify the flow identity information such as to let 550 leaf router make wrong classification. After the leaf router, the 551 attacker can also modify the traffic's destination address to make it 552 delivered to somewhere else. Attackers may utilize one flow to damage 553 another flow without the need to insert traffic themselves. It can be 554 illustrated with the following example. Flow A with EF service bit is 555 destined to New York while flow B with EF bit heads for Los Angeles. An 556 attacker sit on the path of flow B may maliciously modify the flow B's 557 destination address to be also New York . This action will bring damage 558 to both of the flows as flow B is forwarded somewhere else other than 559 its destination while much of flow A's traffic (as well as other traffic 560 bundled in aggregation) might be dropped for aggregate unconformance at 561 policiers. 563 3.2.2.3 Malicious dropping packets 565 Attackers in the middle of path could silently drop packets such that 566 the loss rate of a traffic flow is increased. In addition, they can 567 selectively drop important packets such that statistically drop rate is 568 not obviously deviate but the application may fail. Dropping is hard to 569 detect especially selective dropping. 571 draft-fu-diffserv-security-00.txt Oct. 1999 573 In two cases routers may legitimately drop packets. Firstly, RED/RIO can 574 be used to selectively drop to prevent congestion. Secondly, ingress 575 policer can drop excessive EF packets to protect its domain. Therefore, 576 when drop happens, we need to distinguish whether packets are dropped 577 legitimately or maliciously. 579 Since border routers need to handle much more traffic than interior 580 routers, a compromised border router will bring in severe problems. 581 Therefore, the security of border routers should be emphasized and 582 should be firmly enhanced. 584 3.2.2.4 Deliberate delaying packets 586 A compromised router on the path may also viciously delay a packet 587 which can cause DiffServ network fail to provide the required delay 588 bound and also could cause packets out-of-order thus increase jitter 589 dramatically. 591 4. The possible countermeasures and the difficulty 593 As we analyzed above, once the malicious packets infiltrated into the 594 DiffServ domain, they can occupy the resources illegitimately or damage 595 other traffic. We will discuss the possible countermeasures and the 596 difficulties to deal with the attacks. 598 As we know, the ingress edge router should clear the unauthorized 599 service bit and mark correctly for the packets coming from the local 600 hosts. However, the ingress edge router might not succeed in doing that 601 in the case of 1) source address could be bogus to cheat the first 602 router 2) the first router is not DS-compliant or get compromised 3) the 603 first router is bypassed by injecting from a link or a router, or modify 604 the service bits after the first router checking. 606 One way to alleviate the security problem is to let traffic-originating 607 node in a provider domain to be ingress router or first router of the 608 traffic. However, this does not prevent the code point from being 609 modified after the ingress router's checking. In addition, the 610 performance overhead introduced by classification and policing function 611 as well as the configuration and administration in core routers might 612 not be desirable. 614 For the vulnerable links, we can use security tunnel to ensure packet 615 integrity passing a vulnerable link. But it is expensive to authenticate 616 and verify every data packet passing this link and the resource to do 617 authentication could be too much and might not justify the security 618 benefit. 620 The code point which introduce service differentiation is a major target 621 of attacks. Code points are not secured since it is mutable and 623 draft-fu-diffserv-security-00.txt Oct. 1999 625 should be readable for every router to provide forwarding treatment 626 accordingly. Without the prevention mechanism, the intrusion detection 627 and response system need to be employed to deal with the above analyzed 628 attacks. 630 We can use intrusion detection to detect the attack and remove the 631 attackers. From section 3.2.2, we know it is impossible to narrow down 632 the attack into one domain upon the unconformance detected by border 633 routers. The difficulty of catching the attackers lies in that the 634 attack can originate from possibly any where and destine to anywhere 635 without necessity of bad traffic to direct to the victim's destination. 637 The attacker locating could be complicated and time-consuming across 638 multiple domains by just examining log files in every machine. Even if 639 we know the attacks probably originate from a particular domain by 640 whatever clue, it still could be very hard to pinpoint the attacker 641 when there are thousands of hosts and hundreds of routers within a big 642 organizational domain. Very likely that when enough evidence has been 643 collected, the attacker has already achieved his goal which is to either 644 steal resource to transmit some traffic or undermine some other flows, 645 and run away! Therefore, some automatic intrusion detection scheme need 646 to be developed to be able to fight against the attackers in DiffServ. 648 5. Remarks 650 In this report, we propose a threat analysis and model to describe 651 denial of service attacks in the context of DiffServ. Our intention here 652 is only to address security issues such that we could later evaluate the 653 effectiveness of protection mechanisms for the DiffServ framework. 654 Although at this point we have not proposed any solution to these 655 problems, we conjecture that the solutions will NOT be entirely 656 "preventive" or "cryptographic-based". For instance, we do not see any 657 effective way to prevent "random dropping." Encryption solutions such as 658 IPSec ESP will help in making "selective dropping" much harder, but it 659 can not entirely eliminate the problem. Furthermore, any extra 660 cryptographic operations on either data or control flow will have a 661 significant impact on performance. In other words, we believe that 662 eventually many of the problems need to be resolved in the context of 663 intrusion engineering: vulnerability analysis, intrusion detection, 664 intrusion source analysis, and intrusion response/damage control. The 665 model specified in this report then can be used to evaluate the 666 effectiveness of intrusion engineering for the DiffServ framework. 668 6. References 670 [1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang , and W. Weiss, 671 "An Architecture for Differentiated Services", RFC 2475, December 1998 673 [2] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the 674 Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", 675 RFC 2474, December 1998 677 draft-fu-diffserv-security-00.txt Oct. 1999 679 [3] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding PHB", 680 RFC 2598, June 1999 682 [4] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding 683 PHB Group", RFC 2597, June 1999 685 [5] K. Nichols, V. Jacobson and L. Zhang, "A Two-bit Differentiated 686 Services Architecture for the Internet", RFC 2638, July 1999 688 [6] Y. Bernet, J. Binder, S. Blake, M. Carlson, E. Davies, B. Ohlman, 689 D. Verma, Z. Wang, W. Weiss, "A Framework for Differentiated Services", 690 Internet draft, , February, 1999 692 [7] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, "Resource 693 Reservation Protocol (RSVP) - Version 1 Functional Specification", 694 RFC 2205, September 1997 696 7. Authors Address 698 Zhi Fu, zfu@eos.ncsu.edu 699 S. Felix Wu, wu@csc.ncsu.edu 700 Tsung-li Wu, twu2@eos.ncsu.edu 701 He Huang, hhuang2@eos.ncsu.edu 702 NCSU USA 704 Fengmin Gong, gong@mcnc.org 705 MCNC USA 707 draft-fu-diffserv-security-00.txt Oct. 1999