Internet DRAFT - draft-fu-diffserv-security
draft-fu-diffserv-security
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
<draft-fu-diffserv-security-00.txt>
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, <draft-ietf-diffserv-framework-02.txt>, 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
