DiffServ Working Group Zhi Fu, S. Felix Wu Internet Draft T.S. Wu, He Huang Expiration Date: April 2000 NC State University USA Fengmin Gong MCNC USA Oct. 1999 Security Issues for Differentiated Service Framework Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Discussion and suggestion for improvement are requested. All discussion may be sent to DiffServ mailing list or to individual authors. Distribution of this draft is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Fu, et al Expires: April 2000 page 1 draft-fu-diffserv-security-00.txt Oct. 1999 1. Abstract This document provides a security analysis for the differentiated service framework. We studied what kinds of attacks can be performed and how badly attacks can affect network services under the DiffServ framework. Without a careful investigation of potential attacks and impacts, the protection systems can not be effectively developed and evaluated. The DiffServ working group, as a whole, needs to decide what the important security issues are (or what specific attacks we need to defend against). Then, it will be meaningful to discuss the possible solutions to those realistic threats to DiffServ networks. The conclusion reached is that intrusion detection & response systems need to be developed to protect QoS provisioned by DiffServ. The threat model specified in this report then can be used to evaluate the effectiveness of defense systems for the DiffServ framework. 2. Overview of DiffServ Architecture Current "best-effort" service of Internet is not adequate for applications with stronger Quality of Service (QoS) requirement in terms of delay, loss rate, jitter, error rate etc. Differentiated Service (DiffServ)[1,2,3,4] provides several classes of service to meet heterogeneous application requirement. DiffServ currently defines Expedited Forwarding (EF) Per-hop Behavior(PHB) and Assured Forwarding (AF) PHB [3,4], in which PHB is the forwarding treatment of a certain class of traffic. EF service is to provide a low loss, low delay "Virtual Leased Line" service to all the behaved traffic (conform to a contracted peak rate and burst) while AF is to provide the forwarding assurance over the Internet (no matter lightly loaded or in times of congestion), i.e. packets are unlikely to be dropped as long as it stays within the subscribed profile. All other traffic is treated as best effort service. Within DiffServ framework, a user needs to pay for the specific quality of service he desires. A contract between a customer and a provider is usually described in the form of a service level agreement (SLA). The customer could be either a single user, a corporation network or another ISP. The SLAs contain profiles (rate, burst, time of transmission etc. of the traffic from the customer to the provider network) for different service classes, expected service performance and the dispositions for the in- or out-of-profile traffic etc. D1 D2 D3 D4 +----------+ +-----------+ +-----------+ +----------+ | | | | | | | | | | |500 | |500 | |500 | | S ==FR==ER====IR=========ER=====IR=========ER=====IR====== D | | | | | | | | | +----------+ +-----------+ +-----------+ +----------+ Fu, et al Expires: April 2000 page 2 draft-fu-diffserv-security-00.txt Oct. 1999 FR: First router is the router closest to the source on the path ER: Egress router is the router from which a flow exits one domain IR: Ingress router is the router from which a flow enters one domain Fig. 1 A Simplified DiffServ Architecture Figure 1 illustrates the basic process for DiffServ networks to provision differentiated services. Packets will be first classified into micro flows based on subscribed service profile and marked (six bits in TOS byte of IP packet are used as DiffServ Code Points (DSCP) to mark the different service classes) correctly at ingress edge router (typically first router on the path). All the routers in the core of networks only perform simple forwarding function: put packets into different queues according to DS code points conveyed then forward them as scheduled (various scheduling mechanisms can be used, e.g. priority queue, WRR, CBQ etc.). Some queue management mechanisms, like RED or RIO, could be used to preferentially drop low precedence packets to provide low drop rate for high precedence packets during congestion. No per-flow classification and admission control is necessary for interior routers. Packets will be measured and conditioned (policing or shaping) in aggregate (per service class) according to DS code point at the border routers to enforce the agreement. Egress routers might perform shaping to ensure the conformance and ingress routers must do policing to protect their domains against excessive traffic from other domains. Unconformed EF packets will be dropped and unconformed AF traffic may be re-marked to lower precedence class. The DiffServ architecture is simple and scalable in the sense that only aggregate traffic is checked at boundary of networks and no per-flow information state and processing is needed in network core. However, fairness is hard to maintain within aggregation thus potentially attackers could inject some illegitimately self-labeled (mark as EF or AF) packets into network to either steal resource or seriously bring down the quality of network service of other traffic. Also, attackers can perform modifying, dropping and delaying attacks to degrade or damage QoS provisioned by DiffServ networks. We will discuss security issues in detail next. 3. Vulnerability analysis of DiffServ 3.1 Attacker's objectives, capabilities and operations The attackers to QoS provisioning of DiffServ networks aim at stealing unprovisioned resources or damaging the QoS (denial of QoS) of other traffic (either a particular victim microflow or a group of flows). The higher price associated with the enhanced services creates incentive to steal. With degradation of delay, loss rate, jitter or error rate, Fu, et al Expires: April 2000 page 3 draft-fu-diffserv-security-00.txt Oct. 1999 caused by attacks, legitimate flows may be unable to achieve the desired QoS, even could lead certain applications to crash. Service provider may lose customers or business contracts when a bunch of flows are badly affected within the provider's domain by attacks. For the attacker's access point, attacks can be launched from end-hosts, routers or communication links. If we consider attacker's capability, attackers could perform attack operations on the data packet flow such as injecting, delaying, dropping, modifying, and eavesdropping. Attack access points determine what specific attacks are possible. For instance , the attackers who have access on a node not on the transit path of a certain traffic flow can only perform injecting attack, while attackers who are on communication link or node on the transit path of packets can perform all the five attacks on the packets passing by. >From the modeling point of view, given the access point information, we can decide a set of operations that a particular attacker can perform at that point. And, an attack against DiffServ can be defined as a sequence of operations (each with a timestamp) to achieve a particular objective. Formally, an attacker A who has access to a network entity X can perform any of AttackOP = {OP_1, OP_2,... OP_N}. And, an "attack instance" is defined as [A, X, AttackOP, Seq_Att], where Seq_Att = {[OP_r1, t_1], [OP_r2, t_2], ... [OP_rM,t_M]} and 1 <= ri <= N. Following our definition, a randomized attacker can be modeled as the following: Let OP_1 = dropping, OP_2 = delaying X seconds, OP_3 = tampering the message, OP_4 = duplicating Y copies of the message, and OP_5 = behaving normally. When the attack receive a packet/message. The attacker will flip a coin, and with probability P_i, it will perform OP_i. And, if the attacker performs M operations on M incoming packets, the damage to the QoS (delay, throughput, jitter, bandwidth utilization, and availability) is the quantitative difference between the expect QoS when no operations are applied and the observed QoS with those M attack operations. Please note that, in this draft, we have only modeled a single attack point. In the future, we will extend our model to describe coordinated attack access points. 3.2 Attacks' mechanisms and impacts In a DiffServ network, a certain amount of bandwidth is configured/allocated at each node for each class. A certain end-to-end QoS requirement is inherently achieved through the concatenation of resource and correct provisioning mechanism (scheduling, classifying etc.) at each node. Besides the bandwidth allocated at each node, the first router and border routers need to be configured with profile based on which they can perform conditioning functions. Fu, et al Expires: April 2000 page 4 draft-fu-diffserv-security-00.txt Oct. 1999 Attackers could launch QoS attack through two approaches: one is attacking the configuration process and the other one is attacking the data forwarding process. Certain resources have to be pre-allocated, either through automatic protocol (signaling protocols such as RSVP or management protocols such as SNMP MIB or LDAP Policy Schema) or manually configured. Attackers can maliciously tamper with the configuration process to make resource incorrectly allocated and conditioning policy incorrectly executed. Also, the attacker can target directly at data transmission to cause damage to QoS provisioning. 3.2.1 Attacking the configuration process 3.2.1.1 Attack operations If a manual configuration is deployed, attackers could manage to compromise it via social engineering or physical access. When an automatic protocol is used for configuration, under our model, attackers could only perform the following attack operations: o Injecting Packets The attackers, posing as an configuration authority, can originate packets with bogus configuration information to make the allocation either to be unnecessarily large (waste resource or steal resource for attacker) or insufficiently small (deny service to some legitimate flows). It can achieve the same end through modifying configuration packets. o Modifying Packet Content The attackers in the middle of configuration transit path can maliciously modify (increase or decrease) the allocated resource to be either too large or too small. o Delaying Packets Attackers can delay or replay old configuration packets when the configuration is no longer applicable. Delaying forever becomes dropping attack. o Dropping Packets Attackers can quietly drop the configuration packets. For example, at certain point, a new configuration needs to be issued. If the information is dropped in transit, then the receiving nodes will continue to enforce the old configuration which is incorrect configuration. No matter through physical access or protocol packets access, the consequences of attacks to signaling process of DiffServ is to make configuration incorrectly installed, either too large or too small. For Fu, et al Expires: April 2000 page 5 draft-fu-diffserv-security-00.txt Oct. 1999 example, if the policing profile of an ingress router is maliciously made larger, then, on one hand, resource may be stolen by passing theft traffic into its domain; on the other hand, the additionally allowed traffic may cause congestion, compete for resource thus degrade QoS of other traffic within the domain. Furthermore, if the policing profile is made smaller, the ingress router may drop much legitimate traffic which should not be dropped. For another example, if some of the flow classification profiles in a first router are tampered then those particular flows may not be able to receive appropriate services. 3.2.1.2 Example protocols and their protection The specific implementation of configuration mechanisms could be varied. We use BB's approach [5] as an example to briefly discuss the protection of configuration protocols. o Trustable BBs BBs are responsible for maintaining local policies, allocated resources information and negotiating the resource allocation etc. In addition, a BB is responsible for the resource allocation within its domain. Therefore, BBs play an important role in DiffServ architecture and require high degree of security and trustability to prevent attackers from tampering critical information. o Exchanging negotiation messages between BBs. In DiffServ, each domain's BB establishes a secure association with its peer in the adjacent domain. This mechanism ensured the negotiation message's security. o Configuring interior and border routers Manual configuration or RSVP[7], SNMP etc. could be used in early deployment and another protocol may be developed for future standards work. Then the corresponding security mechanisms for RSVP, SNMP or others could be applied. There must be some mechanisms for authenticating the sender of the configuration information. Since BB is the central authority in an administrative domain, it could also be used as key distribution center (KDC). In such a scheme, every internal router will have a shared secret with the BB and they could exchange cryptographic message with BB using DES or HMD5 with the shared key, thereby guaranteeing the security of configuration messages between BB and other routers within the same domain. Please be aware that those security mechanisms can prevent injecting, modifying, delaying attacks but not dropping attacks. 3.2.2 Attacking packet delivery 3.2.2.1 Injecting packets with unauthorized code point Fu, et al Expires: April 2000 page 6 draft-fu-diffserv-security-00.txt Oct. 1999 Because in DiffServ the DS code points mark the differentiated forwarding treatment, the theft- and denial-of-service attacks could be launched against these bits. For example, unauthorized use of the service bits (DSCP) bit may result in service degradation to all other traffic flows in the same class. In DiffServ, the border routers will perform traffic conditioning on aggregated traffic from a certain domain without classifying individual flow's behavior. This feature provides good scalability while introduces security concern that one unbehaved or malicious flow might cause many other behaved traffic packets dropped (or shaped to lower rate) at borders. In addition, the thieves could send out some data packets labeled to enhanced service code point directly without buying proper profile in advance. As a result, some of the theft traffic might be covertly sent to destination at the cost of service degradation of a lot of honestly behaved traffic. Although the first router is responsible to check against the illegitimate marking and issue correct classification and marking onto flows, the attackers can still inject traffic to fool or bypass the first router in the following ways: o It is well known a security problem that source address is untrusted. Attackers sit in an end-host within same subnet of a legitimate customer can send fake traffic to impersonate a legitimate customer (by setting flow identity , such as source address, destination address, port number etc., to be identity of another flow) in order to pass the first router's check. Impersonating traffic sent out from an end-host that is not within the same subnet of the impersonated customer can be detected by the first router from the conflict between the incoming interface and the source address. However, the impersonating traffic from the same subnet of impersonated customer is easier to be detected by investigating the subnet. o If the first router is compromised then the attacker traffic can certainly be injected into DiffServ domains. The traffic also might be injected from the compromised first router itself. o If the source domain is non-DiffServ compliant such that the first router does not perform its classification function, then attackers can inject traffic with a fake source address. Although normally a service provider needs to have MF classification function performed at its ingress router adjacent to a non-DiffServ-compliant domain, it is easier for attackers to inject impersonating traffic than in the case that the source domain is DiffServ capable. o The traffic also might be injected from a router such that no first router is able to do MF classification for the flow. Once the bad packets covertly enters into a DiffServ domain, they have all access to queues and bandwidth prepared for enhanced service class and all the boundary routers only check aggregate traffic's conformance without any specific identifying information for individual flows. The injected flow may cause the following impacts: Fu, et al Expires: April 2000 page 7 draft-fu-diffserv-security-00.txt Oct. 1999 1). Resources Stolen. D4 +----------+ | | |200k | D1 D2 D3 | | +----------+ +----------+ +----------+ +----------+ | E.... | | | | | | \.........500k.............500k......... D5 | ====================================== . +----------+ | B===/ | | | | | \ .........F | +----------+ +----------+ +----------+ ==========D | |300k | +----------+ Fig. 2 Example for theft-of-service In figure 2, Bob already paid to reserve its EF traffic from B to D at rate 200kps. The number drawn at each border is the rate negotiated between two neighboring domains. If at this time, the communication path from domain D1 to domain D4 is lightly loaded then the theft flow from E to F at rate 100k might be successfully transmitted. It will not be an uncommon case that provider conservatively over-reserve resource to meet its customers needs, which may be taken advantage of by the thief attackers. 2). QoS degraded for other traffic along its path. An injected flow took away some resources supposed to be used by legitimate flows. It may affect other flows encountering it with the following results: a. Longer delay The small queuing delay for EF service is achieved by configuring the service rate greater than the arrival rate. Injected traffic may cause service rate no longer greater than arrival rate such that queuing delay is built up. In the case the injected flow is very bursty, the queuing and the resultant service become more unpredictable. In addition, less bandwidth available to legitimate flows also add in the cause of longer delay. Similarly, some of AF traffic flow's resource could be consumed by injected AF traffic such that longer queuing and transmission delay is introduced. If some provider has egress router to shape the aggregate flow, then the injected flow may cause the aggregate flow to exceed the aggregate profile such that the aggregate traffic has to be delayed by the shaping process. Fu, et al Expires: April 2000 page 8 draft-fu-diffserv-security-00.txt Oct. 1999 b. Bigger jitter As we described above, an injected bursty EF traffic may cause variable queuing delay such that bigger jitter is brought into the EF traffic service. Bursty traffic is permitted for AF service class. Another injected flow aggregated with other bursty flow may or may not cause worse jitter. c. Larger drop rate In figure 2, if the flow E to F is at rate 200kps, then the aggregate flow will become 400k and part of the aggregate will be dropped at border of D5 such that some of traffic flow B-D is unfairly dropped. Also, too much injected EF traffic may cause EF queue overflow to drop some legitimate EF packets (EF queue buffer is not required to be very large due to little queuing normally experienced by EF traffic). AF service provisioning uses mechanisms such as RED, RIO to selectively drop packets to avoid congestion. Injected traffic may cause more congestion such that good traffic will have higher probability to be dropped than before. In addition, excessive AF aggregate caused by AF traffic injection may cause some good traffic be re-marked to be lower class such as to have more probability to be dropped during congestion. By successfully injecting traffic, attackers can also target at a service provider. For example, in order to bring down one particular ISP's business, the attacker can choose a specific timing at which the ISP's network is heavily loaded (nearly fills SLA) and suddenly send out large amount of EF or AF traffic packets and run. The hit-and-run attack is not easy to locate and this one "hit" could cause a lot of packets being dropped at the ingress border routers and suffer the ISP's customers. The border router is good point to detect unconformance by metering and policing aggregate flow (some provider may have MF classification function to provide special service to certain flows but it will not be a general case for all flows due to its overhead and scalability limitation). However, it may not help too much in narrowing down the attacker. Taking the example in item 2).c, the unconformance is detected and some of the aggregate traffic is dropped at domain D5 while the attacker source resides in domain D1. When traffic is dropped at D5, it is well equally possible that the attack traffic originates from either D1, D2, D3 or D4. Another example is depicted in the figure 3 as the following: Fu, et al Expires: April 2000 page 9 draft-fu-diffserv-security-00.txt Oct. 1999 D5 +----------+ | | | F ~ | | 200 ~ | +-------~--+ ~ D1 D2 D3 ~ D4 +----------+ +-----------+ +-------~---+ +----------+ | | | | | ~ | | | | | |500 | |500 ~ | |500 | | B=====================================~==============D | | C.500........ 500~ ~|~ ~ ~|~ ~ ~ ~ | | | +----------+ +-.-----~---+ +-----------+ +----------+ . ~ . D6 ~ +-.-----~--+ | . ~ | | . ~ | | . 500 ~ | +-.-----~--+ . ~ . ~ . ~ A E Fig. 3 Example for injecting attack In the example shown in fig.3, Alice sends EF traffic from A to C ( drawn as ...stream) at 200kbps and Bob sends some EF packets from B to D ( drawn as === stream) at 500kbps. An vicious attacker Eve who aims at undermining Bob's traffic sends illegitimate packets from E to F ( drawn as ~ stream) at 250kbps. Suppose there is no other traffic at this time. Then D6 and D2's ingress router will OKey all Alice and Eve's traffic while D3's ingress policer with profile 500kbps has to drop some of aggregate traffic which belongs to either Bob or Eve. Furthermore, we can see that, Eve's illegitimate traffic will cause dropping at ingress points of both D3 and D5 (if there is a legitimate flow traversing D5 at this time, some of it might also be dropped at border of D5.) Therefore, one bad flow could bring about damages involving multiple regions, although ingress policing can help to reduce the bad effect of damage propagation across the domain boundaries. So we know when the border routers detect unconformance, we can never be sure which domain the attack comes from. It is not easy to narrow down the attackers to a specific domain. The main problem is that the border routers treat traffic in aggregation without identifying individual flow. This characteristic could grant vicious attackers great opportunities to launch various attacks. The difficulty of catching the Fu, et al Expires: April 2000 page 10 draft-fu-diffserv-security-00.txt Oct. 1999 attackers lies in that the attacking can originate from possibly anywhere and destine to anywhere as long as it has a cross with the target flow, which may lead to the good flow's packets get dropped at the cross point. 3.2.2.2 Unauthorizedly modifying header info of packets Attackers on the path can illegitimately modify service bit such that the services differentiated based on the service bits are distorted. For example, flow A is registered for EF service for "virtual leased line" type delivery while flow B reserves AF service for low loss delivery. Attackers could modify flow A's service bit to be AF and flow B's service bit to be EF. As a result, flow A does not get real time delivery service as desired while flow B either get EF service ( attackers stole resource for flow B) or some of flow B are dropped for unconformance at ingress policer (the EF aggregate is not in conformance with aggregate profile). Attackers can modify some traffic's code points to attack some other flows. For example, one best effort flow which is maliciously upgraded to EF service will possibly make other EF flows dropped at policers. For AF service, generally one AF class traffic can be re-marked to other class for excessive traffic detected at ingress policer. It is hard to distinguish that the AF service bit is modified by ingress policer legitimately or by attacker maliciously. Besides modifying service bit, attacker could also spoof on other fields . For example, since the leaf router classify packets according to source address, destination address, port number, protocol etc. fields, the attacker can modify the flow identity information such as to let leaf router make wrong classification. After the leaf router, the attacker can also modify the traffic's destination address to make it delivered to somewhere else. Attackers may utilize one flow to damage another flow without the need to insert traffic themselves. It can be illustrated with the following example. Flow A with EF service bit is destined to New York while flow B with EF bit heads for Los Angeles. An attacker sit on the path of flow B may maliciously modify the flow B's destination address to be also New York . This action will bring damage to both of the flows as flow B is forwarded somewhere else other than its destination while much of flow A's traffic (as well as other traffic bundled in aggregation) might be dropped for aggregate unconformance at policiers. 3.2.2.3 Malicious dropping packets Attackers in the middle of path could silently drop packets such that the loss rate of a traffic flow is increased. In addition, they can selectively drop important packets such that statistically drop rate is not obviously deviate but the application may fail. Dropping is hard to detect especially selective dropping. Fu, et al Expires: April 2000 page 11 draft-fu-diffserv-security-00.txt Oct. 1999 In two cases routers may legitimately drop packets. Firstly, RED/RIO can be used to selectively drop to prevent congestion. Secondly, ingress policer can drop excessive EF packets to protect its domain. Therefore, when drop happens, we need to distinguish whether packets are dropped legitimately or maliciously. Since border routers need to handle much more traffic than interior routers, a compromised border router will bring in severe problems. Therefore, the security of border routers should be emphasized and should be firmly enhanced. 3.2.2.4 Deliberate delaying packets A compromised router on the path may also viciously delay a packet which can cause DiffServ network fail to provide the required delay bound and also could cause packets out-of-order thus increase jitter dramatically. 4. The possible countermeasures and the difficulty As we analyzed above, once the malicious packets infiltrated into the DiffServ domain, they can occupy the resources illegitimately or damage other traffic. We will discuss the possible countermeasures and the difficulties to deal with the attacks. As we know, the ingress edge router should clear the unauthorized service bit and mark correctly for the packets coming from the local hosts. However, the ingress edge router might not succeed in doing that in the case of 1) source address could be bogus to cheat the first router 2) the first router is not DS-compliant or get compromised 3) the first router is bypassed by injecting from a link or a router, or modify the service bits after the first router checking. One way to alleviate the security problem is to let traffic-originating node in a provider domain to be ingress router or first router of the traffic. However, this does not prevent the code point from being modified after the ingress router's checking. In addition, the performance overhead introduced by classification and policing function as well as the configuration and administration in core routers might not be desirable. For the vulnerable links, we can use security tunnel to ensure packet integrity passing a vulnerable link. But it is expensive to authenticate and verify every data packet passing this link and the resource to do authentication could be too much and might not justify the security benefit. The code point which introduce service differentiation is a major target of attacks. Code points are not secured since it is mutable and Fu, et al Expires: April 2000 page 12 draft-fu-diffserv-security-00.txt Oct. 1999 should be readable for every router to provide forwarding treatment accordingly. Without the prevention mechanism, the intrusion detection and response system need to be employed to deal with the above analyzed attacks. We can use intrusion detection to detect the attack and remove the attackers. From section 3.2.2, we know it is impossible to narrow down the attack into one domain upon the unconformance detected by border routers. The difficulty of catching the attackers lies in that the attack can originate from possibly any where and destine to anywhere without necessity of bad traffic to direct to the victim's destination. The attacker locating could be complicated and time-consuming across multiple domains by just examining log files in every machine. Even if we know the attacks probably originate from a particular domain by whatever clue, it still could be very hard to pinpoint the attacker when there are thousands of hosts and hundreds of routers within a big organizational domain. Very likely that when enough evidence has been collected, the attacker has already achieved his goal which is to either steal resource to transmit some traffic or undermine some other flows, and run away! Therefore, some automatic intrusion detection scheme need to be developed to be able to fight against the attackers in DiffServ. 5. Remarks In this report, we propose a threat analysis and model to describe denial of service attacks in the context of DiffServ. Our intention here is only to address security issues such that we could later evaluate the effectiveness of protection mechanisms for the DiffServ framework. Although at this point we have not proposed any solution to these problems, we conjecture that the solutions will NOT be entirely "preventive" or "cryptographic-based". For instance, we do not see any effective way to prevent "random dropping." Encryption solutions such as IPSec ESP will help in making "selective dropping" much harder, but it can not entirely eliminate the problem. Furthermore, any extra cryptographic operations on either data or control flow will have a significant impact on performance. In other words, we believe that eventually many of the problems need to be resolved in the context of intrusion engineering: vulnerability analysis, intrusion detection, intrusion source analysis, and intrusion response/damage control. The model specified in this report then can be used to evaluate the effectiveness of intrusion engineering for the DiffServ framework. 6. References [1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang , and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998 [2] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998 Fu, et al Expires: April 2000 page 13 draft-fu-diffserv-security-00.txt Oct. 1999 [3] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999 [4] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999 [5] K. Nichols, V. Jacobson and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", RFC 2638, July 1999 [6] Y. Bernet, J. Binder, S. Blake, M. Carlson, E. Davies, B. Ohlman, D. Verma, Z. Wang, W. Weiss, "A Framework for Differentiated Services", Internet draft, , February, 1999 [7] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997 7. Authors Address Zhi Fu, zfu@eos.ncsu.edu S. Felix Wu, wu@csc.ncsu.edu Tsung-li Wu, twu2@eos.ncsu.edu He Huang, hhuang2@eos.ncsu.edu NCSU USA Fengmin Gong, gong@mcnc.org MCNC USA Fu, et al Expires: April 2000 page 14 draft-fu-diffserv-security-00.txt Oct. 1999