Internet DRAFT - draft-liang-idr-flowspec-orf
draft-liang-idr-flowspec-orf
Idr Working Group Q. Liang
Internet-Draft W. Hao
Intended status: Standards Track J. You
Expires: December 1, 2015 Huawei
June 1, 2015
BGP FlowSpec Outbound Route Filter
draft-liang-idr-flowspec-orf-01.txt
Abstract
This document defines a new ORF-type, called the "FlowSpec-ORF".
FlowSpec-ORF is applicable in the networks supporting flow
specifications (FlowSpec) [RFC5575]. It can be used to filter the
FlowSpec rules on demand.
Requirements Language
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 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Liang, et al. Expires December 1, 2015 [Page 1]
Internet-Draft BGP FlowSpec ORF 2015
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases for FlowSpec-ORF . . . . . . . . . . . . . . . . . 3
3.1. Network Security . . . . . . . . . . . . . . . . . . . . 3
3.2. FlowSpec Capability Negotiation . . . . . . . . . . . . . 4
4. FlowSpec-ORF Encoding . . . . . . . . . . . . . . . . . . . . 5
4.1. Filters . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. FlowSpec-ORF Capability . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
The Outbound Route Filtering Capability defined in [RFC5291] provides
a mechanism for a BGP speaker to send to its BGP peer a set of
Outbound Route Filters (ORFs) that can be used by its peer to filter
its outbound routing updates to the speaker.
[RFC5292] defines Address Prefix ORF type which can be used to
perform address-prefix-based route filtering. This ORF-type supports
prefix-length- or range-based matching, wild-card-based address
prefix matching, as well as the exact address prefix matching for
address families.
[I-D.ietf-bess-orf-covering-prefixes] defines Covering Prefixes ORF
(CP-ORF) which is applicable in Virtual Hub-and-Spoke VPNs and BGP/
MPLS Ethernet VPN (EVPN) networks.
In order to filter the FlowSpec rules [RFC5575], this document
defines a new ORF-type, called the "FlowSpec-ORF". FlowSpec-ORF is
applicable in the networks supporting flow specifications (FlowSpec)
[RFC5575]. It can be used to filter the FlowSpec rules on demand.
Liang, et al. Expires December 1, 2015 [Page 2]
Internet-Draft BGP FlowSpec ORF 2015
2. Terminology
This section contains definitions for terms used frequently
throughout this document. However, many additional definitions can
be found in [RFC5291] and [RFC5575].
Flow Specification (FlowSpec): A flow specification is an n-tuple
consisting of several matching criteria that can be applied to IP
traffic, including filters and actions. Each FlowSpec consists of
a set of filters and a set of actions.
3. Use Cases for FlowSpec-ORF
3.1. Network Security
Normally each AS corresponds to a management domain. ASs have
different security policies. FlowSpec rule dissemination also needs
the security consideration. We take FlowSpec Anti-DOS application in
L3VPN scenario as an example.
In provider-based L3VPN networks, the VPN customer network needs
traffic filtering capabilities towards their external network
connections (e.g., firewall facing public network connection). As
shown in Figure 1, traffic analyzer is deployed in the customer
network VPN1 AS1; while attacker is in the VPN1 AS3. When ASBR1 (AS
Boundary Router) receives flow specification policies from the
traffic analyzer, it will generate and distribute the flow
specification rules to ASBR4 through provider network via MP-EBGP.
Once ASBR4 receives the flow specification rules, it can block the
attack traffic closer to the source of the attacker.
+----------------+
+-------+ | FlowSpec Policy|
|Target | | Server | +---------+
+----\--+ +---/------------+ |Attacker |
\ / +---/-----+
\ / /
\ / /
\ / /
/------\ \ / /------\ / /------\
// \\+\--/-+ +-----+/ \\+-----+ +--/--+/ \\
| VPN1 Site |ASBR | |ASBR | |ASBR | |ASBR | VPN1 Site |
\\ AS1 //| 1 +----+ 2 |\ AS2 //| 3 +----+ 4 |\ AS3 //
\------/ +-----+ +-----+ \------/ +-----+ +-----+ \------/
Customer Network Provider Network Customer Network
Figure 1: Scenario 1 - Anti-DOS based on FlowSpec
Liang, et al. Expires December 1, 2015 [Page 3]
Internet-Draft BGP FlowSpec ORF 2015
In this use case, the provider network needs to deploy security
policies to filter the FlowSpec rules from the customer network, i.e.
only accepts the authorized or secure FlowSpec rules which can be
supported. Therefore, ASBR2 can send to ASBR1 a set of FlowSpec-ORF
that can be used by ASBR1 to filter its outbound FlowSpec rules to
ASBR2.
If the traffic analyzer is deployed in the provider network AS2,
while attacker is in the VPN1 AS3, as shown in Figure 2; RR will
generate and then distribute FlowSpec rules to ASBR2 and ASBR3 when
it receives the FlowSpec policies from the traffic analyzer.
Furthermore, ASBR2 and ASBR3 will distribute the FlowSpec rules to
ASBR1 and ASBR4 respectively. Once ASBR4 receives the flow
specification rules, it can block the attack traffic closer to the
source of the attacker.
+----------------+
+-------+ | FlowSpec Policy|
|Target | | Server | +---------+
+----\--+ +---------+------+ |Attacker |
\ | +---/-----+
\ | /
\ +-+--+ /
\ |RR | /
/------\ \ /+----+\ / /------\
// \\+\----+ +-----+/ \\+-----+ +--/--+/ \\
| VPN1 Site |ASBR | |ASBR | |ASBR | |ASBR | VPN1 Site |
\\ AS1 //| 1 +----+ 2 |\ AS2 //| 3 +----+ 4 |\ AS3 //
\------/ +-----+ +-----+ \------/ +-----+ +-----+ \------/
Customer Network Provider Network Customer Network
Figure 2: Scenario 2 - Anti-DOS based on FlowSpec
In this use case, the customer network also needs to deploy security
policies to filter the FlowSpec rules from the provider network, i.e.
only accepts the authorized or secure FlowSpec rules which can be
supported. Therefore, ASBR4 can send to ASBR3 a set of FlowSpec-ORF
that can be used by ASBR4 to filter its outbound FlowSpec rules to
ASBR4.
3.2. FlowSpec Capability Negotiation
FlowSpec[RFC5575]is an n-tuple consisting of several matching
criteria that can be applied to IP traffic. The matching criteria
can include elements such as source and destination address prefixes,
IP protocol, and transport protocol port numbers. Traditional
routers or L3 switches use special FIB hardware, such as TCAM,
Liang, et al. Expires December 1, 2015 [Page 4]
Internet-Draft BGP FlowSpec ORF 2015
AISC.The forwarding plane usually doesn't support Type, Code fields
matching for ICMP packet. However, some modern forwarding devices
such as vRouter can support FlowSpec matching with more elements. So
even though different BGP speakers have the FlowSpec capability,
their filters and action types of FlowSpec may be different.
Therefore, BGP speaker should send its FlowSpec capability to BGP
peers with the format of FlowSpec-ORF, then it can only receive the
FlowSpec rules on demand; those that cannot be supported or are not
required will be denied.
4. FlowSpec-ORF Encoding
FlowSpec-ORF (ORF-type: TBD，First Come First Served) entries
can be carried in the BGP ROUTE-REFRESH [RFC5291] message. The types
of FlowSpec-ORF are identified by (Address Family Identifier,
Subsequent Address Family Identifier (AFI, SAFI)) pairs [RFC4760].
They are aligned with the values for (AFI, SAFI) used in BGP UPDATE
message, as shown in the following table:
+----------------+------------------------+---------------------------+
| AFI/SAFI Value | Description | RFC/Draft |
+----------------+------------------------+---------------------------+
| AFI=1,SAFI=133 | IPv4 FlowSpec rule/orf | RFC5575 |
+----------------+------------------------+---------------------------+
| AFI=1,SAFI=134 | VPNv4 FlowSpec rule/orf| RFC5575 |
+----------------+------------------------+---------------------------+
| AFI=2,SAFI=133 | IPv6 FlowSpec rule/orf |draft-ietf-idr-flow-spec-v6|
+----------------+------------------------+---------------------------+
| AFI=2,SAFI=134 | VPNv6 FlowSpec rule/orf|draft-ietf-idr-flow-spec-v6|
+----------------+------------------------+---------------------------+
| AFI=25,SAFI=134| L2 VPN FlowSpec rule/or|draft-hao-idr-flowspec-evpn|
+----------------+------------------------+---------------------------+
The format of FlowSpec-ORF entry is aligned with ORF entry encoding
defined in [RFC5291]. Therein, the "Type specific part" is extended
as shown in Figure 3:
Liang, et al. Expires December 1, 2015 [Page 5]
Internet-Draft BGP FlowSpec ORF 2015
+---------------------------+
|Sequence (32 bits) |
+---------------------------+
|Filter Number (8 bits) |
+---------------------------+
|RD Number (8 bits) |
+---------------------------+
|RD Equal Flag (1 bits) |
+---------------------------+
|Reserved (15 bits) |
+---------------------------+
|Action Matching (32 bits) |
+---------------------------+
|RD 1 (64 bits) |
+---------------------------+
|...... |
+---------------------------+
|RD n (64 bits) |
+---------------------------+
|Filters (variable, RFC5575)|
+---------------------------+
Figure 3: FlowSpec-ORF "Type specific part" Encoding
Sequence: the relative ordering of the entry among all the
FlowSpec-ORF entries.
Filter Number: the number of the filters of a FlowSpec-ORF entry.
RD Number: the number of the RD items. When SAFI=133, RD
Number=0; When SAFI=134, RD number must be no less than 1.
RD Equal Flag: matching mode for RD. If set, the operation is
equality between data and value. If unset, the operation is
inequality between data and value.
Reserved: it is set to 0 on transmit and ignored on receipt.
RD: An 8-byte Route Distinguisher (RD), present when SAFI=134.
Action Matching: each bit corresponds to a particular FlowSpec
action [RFC5575]. If set, match the action; If unset, not match
the action.
If Filter Number=0, Action Matching=0, RD Number!=0, then this
FlowSpec-ORF is used to match the "RD" field. When SAFI=134, the BGP
speaker (e.g. PE or ASBR) will distribute this FlowSpec-ORF, i.e.
deny those VPN instances which are not configured locally.
Liang, et al. Expires December 1, 2015 [Page 6]
Internet-Draft BGP FlowSpec ORF 2015
When BGP Speaker distributes FlowSpec rules to the BGP peers, it will
first check the FlowSpec-ORF. When more than one FlowSpec-ORF entry
matches the NLRI of the FlowSpec rule, the "first-match" rule
applies. That is, the ORF entry with the smallest sequence number
(among all the matching ORF entries) is considered as the sole match,
and it would determine whether the FlowSpec rule should be
advertised.
4.1. Filters
The filters in FlowSpec-ORF are aligned with the filters defined in
[RFC5575] except the following four types:
+---------------------------------------+--------------------------------+
| Filter Type | RFC/Draft |
+---------------------------------------+--------------------------------+
|Type 1: Destination Prefix IPv4 or IPv6|RFC5575, |
| |draft-ietf-idr-flow-spce-v6 |
+---------------------------------------+--------------------------------+
|Type 2: Source Prefix IPv4 or IPv6 |RFC5575, |
| |draft-ietf-idr-flow-spce-v6 |
+---------------------------------------+--------------------------------+
|Type 14: Destination MAC Prefix |draft-hao-idr-flowspec-evpn |
+---------------------------------------+--------------------------------+
|Type 15: Source MAC Prefix |draft-hao-idr-flowspec-evpn |
+---------------------------------------+--------------------------------+
These four types are encoded as follows:
+--------------------------------+
| Type(8 bits) |
+--------------------------------+
| MaxLen (8 bits) |
+--------------------------------+
| MinLen (8 bits) |
+--------------------------------+
| Length (8 bits) |
+--------------------------------+
| Prefix (32/48/128 bits) |
+--------------------------------+
Therein, MaxLen, MinLen, Length, Prefix are the same as defined in
[RFC5292].
Liang, et al. Expires December 1, 2015 [Page 7]
Internet-Draft BGP FlowSpec ORF 2015
4.2. Actions
The "Action Matching" field indicates a particular FlowSpec action
[RFC5575] that needs to match or not. When some bit of Action
Matching is set, the corresponding FlowSpec action of the FlowSpec
rule should be matched. Otherwise, this FlowSpec rule is not
matched.
+-----------------------+----------------------+------------+
| FlowSpec Action Type | Action Matching bit | RFC/Draft |
+-----------------------+----------------------+------------+
| traffic-rate | 0 | RFC5575 |
| traffic-action | 1 | RFC5575 |
| redirect | 2 | RFC5575 |
| traffic-marking | 3 | RFC5575 |
+-----------------------+----------------------+------------+
4.3. FlowSpec-ORF Capability
Section 5 of RFC 5291 describes how BGP speakers use the Outbound
Route Filtering Capability to advertise their intention to send
FlowSpec-ORFs and their willingness to accept FlowSpec-ORFs.
5. IANA Considerations
This document defines a new ORF, i.e. FlowSpec-ORF (Type Code: TBD1),
which is used to to filter the FlowSpec rules on demand.
6. Security considerations
Each FlowSpec-ORF consumes memory and compute resources on the device
that supports it. Therefore, a device supporting FlowSpec-ORF takes
the following steps to protect itself from oversubscription:
(1) When negotiating the ORF capability, advertise willingness to
receive the FlowSpec-ORF only to known, trusted BGP peers.
(2) Enforce a per-peer limit on the number of FlowSpec-ORFs that can
be installed at any given time. Ignore all requests to add FlowSpec-
ORFs beyond that limit and/or reply a BGP notification message to
indicate "ROUTE-REFRESH Message Error" (Error Code: 7)/"FlowSpec-ORF
overfilling Error" (Subcode: TBD2).
(3) When BGP speaker receives unknown FlowSpec-ORF, it will send to
the BGP peer the Notification message carrying Error Code/Subcode,
e.g. "ROUTE-REFRESH Message Error" (Error Code: 7) / "FlowSpec-ORF
Attribute Error" (Subcode: TBD3).
Liang, et al. Expires December 1, 2015 [Page 8]
Internet-Draft BGP FlowSpec ORF 2015
Security considerations for BGP are presented in [RFC4271] while
further security analysis of BGP is found in [RFC6952].
7. Acknowledgement
TBD.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering
Capability for BGP-4", RFC 5291, August 2008.
[RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound
Route Filter for BGP-4", RFC 5292, August 2008.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, August 2009.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013.
8.2. Informative References
[I-D.hao-idr-flowspec-evpn]
Weiguo, H., Zhuang, S., and S. Litkowski, "Dissemination
of Flow Specification Rules for L2 VPN", draft-hao-idr-
flowspec-evpn-02 (work in progress), January 2015.
[I-D.ietf-bess-orf-covering-prefixes]
Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong,
"Covering Prefixes Outbound Route Filter for BGP-4",
draft-ietf-bess-orf-covering-prefixes-06 (work in
progress), March 2015.
Liang, et al. Expires December 1, 2015 [Page 9]
Internet-Draft BGP FlowSpec ORF 2015
[I-D.ietf-idr-flow-spec-v6]
Raszuk, R., Pithawala, B., McPherson, D., and A. Andy,
"Dissemination of Flow Specification Rules for IPv6",
draft-ietf-idr-flow-spec-v6-06 (work in progress),
November 2014.
Authors' Addresses
Qiandeng Liang
Huawei
101 Software Avenue, Yuhuatai District
Nanjing, 210012
China
Email: liangqiandeng@huawei.com
Weiguo Hao
Huawei
101 Software Avenue, Yuhuatai District
Nanjing, 210012
China
Email: haoweiguo@huawei.com
Jianjie You
Huawei
101 Software Avenue, Yuhuatai District
Nanjing, 210012
China
Email: youjianjie@huawei.com
Liang, et al. Expires December 1, 2015 [Page 10]
