Network Working Group Dai GuangMing
Internet Draft Z. Ye
Expires: March 2007 Huawei Technologies
September 13, 2006
Specific Route uRPF (SRU)
draft-dai-specific-route-urpf-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "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.
This Internet-Draft will expire on March 13, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
This document describes a mechanism to extend Unicast Reverse Path
Forwarding(uRPF). By associating an uRPF flag with a specific route,
uRPF can be controlled in a finer granularity than traditional one.
It may be used to reduce the cost to network devices caused by uRPF.
Dai Expires March 13, 2007 [Page 1]
Internet-Draft Control Plane Security Capabilities September 2006
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119]
Table of Contents
1. Introduction................................................2
1.1. Current Implements......................................3
1.2. Some Problems..........................................3
2. Specific route uRPF (SRU)....................................3
2.1. Mechanism..............................................4
2.2. Process................................................4
2.3. Deployment.............................................4
2.3.1. Deployment model 1.................................4
2.3.2. Deployment model 2.................................5
2.4. Benefit................................................7
2.5. Design Consideration....................................7
3. Security Considerations......................................7
4. Acknowledgements............................................8
5. References..................................................8
5.1. Normative References....................................8
5.2. Informative References..................................8
Author's Addresses.............................................8
Intellectual Property Statement.................................9
Disclaimer of Validity.........................................9
Copyright Statement...........................................10
Acknowledgment................................................10
1. Introduction
As a countermeasure against forged source address attacks, uRPF has
been deployed widely in operator's network. uRPF performs additional
lookup operation on the routing table based on the source address of
a packet to determine whether the packet is allowed to be received
from an interface, i.e. whether the source address of the packet is a
spoofed one.
Dai Expires March 13, 2007 [Page 2]
Internet-Draft Control Plane Security Capabilities September 2006
1.1. Current Implements
[RFC3704] documents several types of PRF (Reverse Path Forwarding)
implements: loose RPF, strict RPF and feasible RPF. The loose RPF
only checks for the existence of a route; the strict RPF will further
compare the consistency of the incoming interface with the outgoing
interface of the route; the feasible RPF additionally takes all
available outgoing interfaces into account.
Some routers integrate uRPF with ACL (Access Control list). When uRPF
check for a packet fails, the ACLs configured in advance for the
route will be consulted to decide whether the packet should be
dropped. It is conceptually identical to uRPF check for a specific
packet stream defined by ACLs.
1.2. Some Problems
Although uRPF benefits network security, it may also have a negative
effect to performance of network devices.
For an uRPF-enabled interface, performance of a network device is
unavoidably affected because it must look up route table both for
source and destination address. A device requires additional resource
to perform the second lookup operation at the same time, or it would
not reach the capacity of line-speed forwarding.
To some routers, mentioned ACL-based uRPF may worsen the situation
because it need to consult additional configured data, such as an ACL
table and an action table which containing deny, allow and some other
possible actions. All of above operations increase the processing
expense for packet forwarding.
In addition, no matter which type of uRFP is selected, each packet
received from an uRPF-enabled interface must be checked. uRPF in a
finer granularity is not available to reduce the expense.
2. Specific route uRPF (SRU)
This draft documents a new type uPRF, specific route uRPF (SRU),
which can be performed to check uRPF in a finer granularity. In some
situations, ACL-based uRPF can achieve similar effect, but SRU is
more efficient and more scalable.
Dai Expires March 13, 2007 [Page 3]
Internet-Draft Control Plane Security Capabilities September 2006
2.1. Mechanism
Forwarding Information Base (FIB, [RFC1812]) is a core component of
IP forwarding process. A FIB entry contains at least the output
interface and next hop for a specific prefix. In this proposal, an
additional uRPF flag is associated with each FIB entry. This flag
indicates whether a packet destining the prefix should be check
against uRPF.
2.2. Process
After applying this mechanism, the forwarding process will seem as
follows:
-Firstly, a router processor consults FIB using the destination
address of a received packet as usual.
-Then, if an entry is found, its uRPF flag will be checked. If the
flag is set, a subsequent uRPF check will be performed. Or else,
uRPF check will not happen to the packet.
-Finally, according to the result of the uRPF check, the route
processor decides whether to drop the packet or not.
2.3. Deployment
2.3.1. Deployment model 1
uRPF-Enabled Interface+------+ BGP UPDATE +------+
-------->| AS1 |<------------| AS2 |
+------+ +------+
^
|BGP UPDATE
|
+------+
Dai Expires March 13, 2007 [Page 4]
Internet-Draft Control Plane Security Capabilities September 2006
| AS3 |
+------+
Figure 1: A deployment scenario
Figure 1 illustrates a possible application scene. Suppose AS2 asks
AS1 to perform an uRPF check before forwarding packets to it. However,
AS3 has not such request. In order to meet the requirement, AS1 could
design a following routing policy.
-When receiving a BGP UPDATE, AS1 gets the former AS Number from
its AS_PATH attribute.
-If the former AS is AS2, before installing routes in the UPDATE
into RIB, AS1 associate an uRPF flag with them.
-Otherwise, the UPDATE will be treated as usual.
-When a route in RIB is selected as a best route and is installed
into FIB, its uRPF flag should be attached to corresponding FIB
entry.
-When a router processor selects a FIB entry, it will also check
its uRPF flag to decide whether to perform an uRPF check.
Through above measures, user requirement will be satisfied. It is
impossible or at least difficult for current uRPF technologies, such
as ACL-based uRPF, to meet the request. Moreover, only nodes in AS2
are requested to support SRU, no other network device and protocols
need to be modified.
2.3.2. Deployment model 2
Since a SRU check is a check against each individual route, the uRPF
operation may be treated as an extended attribute of a route. Thus,
besides being deployed by manual configurations, it also can be
propagated with routes by using dynamic routing protocols.
Dai Expires March 13, 2007 [Page 5]
Internet-Draft Control Plane Security Capabilities September 2006
+-------+
| ST |
+-------+
|
| iBGP UPDATE with a special
V COMMUNITY attribute
------------------------------
| |
| |
V V
+-----------------+ +----------------+
| RA (iBGP Router)| |RB (iBGP Router)|
+-----------------+ +----------------+
Figure 2: Another deployment scenario
Figure 2 illustrates a possible deployment scenario within a BGP
Autonomous System(AS). ST is a station which maintains uRPF policies
and is responsible to distribute them within an AS. The following
steps could be taken to distribute policies.
o Configuring BGP routers of an AS in advance
For a BGP router which supports SRU, policies used to map route
attributes to uRPF operations are pre-configured. For example, a
special COMMUNITY attribute value may be selected to mean to enable
uRPF to a prefix and another value means to disable.
o Distribute uRPF policies
When a ST decides to enable the uRPF operation of a specific route,
it only needs to propagate a BGP UPDATE within the AS and attach the
pre-defined COMMUNITY attribute on it. After receiving the UPDATE, a
BGP router will apply the attached policies. Deployment and
revocation of policies can be performed in the same way.
Dai Expires March 13, 2007 [Page 6]
Internet-Draft Control Plane Security Capabilities September 2006
The above deployment manner is similar to that of some black hole
filtering which counters DDOS attacks. Certainly, we could also
transmit uRPF policies in routing advertisements directly, such as
using a new route attribute. Thus the first step could be omitted.
2.4. Benefit
As a countermeasure towards DDOS, uRPF could only mitigate spoofed
address attacks. It does not make sense, when not any attack occurs.
Essentially, uRPF is similar to black hole filtering. The difference
between them is the latter lacks of measure to decide whether a
spoofed address attack has taken place. Thus, every received packet
has to be checked. If a dedicated device, such as an IDR system, is
available to detecting such attacks in time, SRU may be a better
choose.
Anyway, SRU provide a measure in a finer granularity and can be used
to perform uRPF on demand in the future and reduces its performance
impact on forwarding.
2.5. Design Consideration
FIB can be assumed as a 'forward policies database' for each received
packet, so an uRPF flag of a FIB entry will affect all the interfaces
in a device. In order to provide flexibility and apply different uRPF
policy to different interface, interface information should be
introduced in a fib entry. The information consists of interfaces
index in which received packets will be performed uRPF check. In this
way, although a single FIB is used, policies can be difference in
each individual interface.
An interface, which does not enable route-base uRPF, can simply
ignore the uRPF flag and interfaces information corresponding to the
found FIB entry. Thus, received packets from the interface can be
performed [RFC3704] uRPF check. In this way SRU may coexistence with
[RFC3704] uRPF.
3. Security Considerations
To be added.
Dai Expires March 13, 2007 [Page 7]
Internet-Draft Control Plane Security Capabilities September 2006
4. Acknowledgements
To be added.
5. References
5.1. Normative References
[RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms",
RFC 1208, March 1991.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
equirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1812] Baker, F, "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC2827] P. Ferguson, D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Address
Spoofing", BCP 38, RFC 2827, May 2000
[RFC4271] Y. Rekhter, T. Li, S. Hares, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006
5.2. Informative References
[RFC3704] F. Baker, P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
Author's Addresses
Dai Guangming
Huawei Technologies
No.3, Xinxi Road, Shangdi Information Industry Base
Haidian District, Beijing City 100085
Email: daigm@huawei.com
Dai Expires March 13, 2007 [Page 8]
Internet-Draft Control Plane Security Capabilities September 2006
Zhao Ye
Huawei Technologies
No.3, Xinxi Road, Shangdi Information Industry Base
Haidian District, Beijing City 100085
Email: ye.zhao_ietf@hotmail.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Dai Expires March 13, 2007 [Page 9]
Internet-Draft Control Plane Security Capabilities September 2006
Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Dai Expires March 13, 2007 [Page 10]