| I2RS working group | S. Hares |
| Internet-Draft | Hickory Hill Consulting |
| Intended status: Standards Track | Q. Wu |
| Expires: August 17, 2014 | Huawei |
| February 13, 2014 |
An Information Model for I2RS Reading Information Policy
draft-hares-i2rs-im-read-info-policy-00
The Interface to the routing system (I2RS) specifies a new interface that a client (I2RS client) can utilize to interface to the routing system. Some applications that utilize the services of I2RS client may require a specific set of data in response to network events or conditions based on pre-established rules. In order to reduce the data flow through the network, the I2RS client needs to signal the I2RS agent to filter some of the collected data or events prior to transmission to the i2rs client. This functionality is necessary to meet the requirements I2RS enabled services which include service-layer routing improvements, and control of traffic flows and exit points.
This document introduces a read-only I2RS RIB policy Informational Model that provides filters for the reads and notifications from the I2RS RIB Info Model (IM). This model utilizes a generic information model (IM) for policy templates that is extensible and hierarchical. These templates support the features described by the I2RS architectural model.
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."
This Internet-Draft will expire on August 17, 2014.
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 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.
The Interface to the Routing System (I2RS) [[I-D.ietf-i2rs-architecture]] provides read and write access to the information and state within the routing process within routing elements. The I2RS client interacts with one or more I2RS agents to collect information from network routing systems. One set of protocol independent use cases that the I2RS interface be used in are described in [I-D.white-i2rs-use-case] Protocol Independent Use Case for the Interface. These scenarios suggest that require I2RS interfaces to be able to:
Processing of collected information at the I2RS agent may require the I2RS Agent to filter certain information or group pieces of information in order to reduce the data flow through the network to the I2RS client. Some applications utilizing the services of an I2RS client may also wish to require specific data in response to network events or conditions based on pre-established policy rules. For example if the traffic flow measured by network devices exceeds some limit, then the I2RS client may wish to query for all routes with some match pattern. This will allow service-layer routing improvements, and control of traffic flows and exit points.
This document introduces an information model (IM) for filtering policies enacted at I2RS agent before transmitting data to the I2RS client. The [I-D.ietf-i2rs-architecture] suggests that associated with the I2RS RIB model there will be "Policy-based Routing (ACLs)" and RIB "policy controls". This policy model utilizes the generic policy model found in [I-D.hares-i2rs-info-model-policy] and operates on the I2RS RIB information module [I-D.ietf-i2rs-rib-info-model]. The use of a generic policy model allows the creation of named templates for reading or writing to the I2RS RIB module that have three levels of structure (policy group, network policy, and Local elements of policy). The local elements of policy operate in the monitoring stage as read functionality and as filters for the I2RS agent transmission of data to the I2RS client.
Reading information via I2RS from the BGP protocol regarding BGP routes, BGP protocol events, and BGP protocol statistics may also be needed to filter the information an I2RS agent sends to an I2RS client. The [I-D.keyupate-i2rs-bgp-usecases] provides a use case for BGP monitoring in section 5 where it indicates it is important to monitor prefixes of "high visibility" end-users for the announcement or withdraw of prefixes, the suppression of prefix announcements (due to flap damping), and alternate best path selections. It is also important to trace dropped routes, and statistics per EBGP session. These BGP prefixes may need to be tracked both at the BGP and at the active RIB level. The read policy described here for use by the I2RS agent for the RIB Information can be extended to support the read filtering for BGP.
Policy about what I2RS can read from the RIB is contained in the following:
This section provides an overview of the Network Policy information model. The next section contains an example of the RIB Filtering model.
I2RS client requesting filtered data from the I2RS agent sets the policy into a Network Policy list for Read Filtering. This policy list is created as a set of policy sets that contain a policy group with its associated policy rules. These policy rules are saved in the I2RS Agent's local store.
If the I2RS Agent fails, then these policy rules must be instantiated by the I2RS Client. The templates for the I2RS Agent may be part of the generic templates stored within the routing system and uploaded by name by the I2RS client. This would provide easy of maintenance for systems with these policy templates. However, this is not a requirement for the proper function of this Read Filtering Policy model.
Below is a diagram of the Read Filtering policy model.
+-------------------------+
| Read Filtering |
| Policy for |
| I2RS Agent |
| Policy Set |
| |
+--+-------------------+--+
^ ^
/|\ /|\ (sequence of)
| "extends" | "extends"
+--------^-------+ +-------^-------+ +------------+
|
| Policy Group | | Policy Rule |<---|Local Policy|
|
+----------------+ +---------------+ +------------+
: :
......: :.....
: :
: :
+---------V---------+ +-V-------------+
| Policy Condition | | Policy Action |
+-------------------+ +---------------+
: : : : : :
.....: . :..... .....: . :.....
: : : : : :
+----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+
| Match | |Policy | |Policy| | Set || Policy ||Policy|
|Operator| |Variable| |Value | |Operator||Variable|| Value|
+--------+ +--------+ +------+ +--------++--------++------+
Figure 1: Overall model structure
Policy Groups can include other policy groups. This aids in building up the policy set as logical components. Operational groups can utilize this to map the policy groups to actual operational service policies. In a similar fashion, policy sets could contain other policy sets.
This section provides an example of the Read Filter Policy Information model. The example is taken from the protocol independent use cases use cases this I2RS architecture can be used in are described in [I-D.white-i2rs-use-case] Protocol Independent Use Case for the Interface which contains the following examples:
The specific read monitoring filtering policy is proposed for each use case.
scenario:
+----------+
|i2rs-client|-------------------
| |-----------+ |
-----------+ | |
| +------+ |
| | ir2s | |
| | agent| |
Valid Source--\ | /---|R2 |-------+\
+-------+/ +------+ | \
|R1 i2rs| | R3--Valid
| agent| | Destination
+-------+ i2rs agent
Attack Source--/ \--Monitoring Device-----/
Figure 2 - Distributed reaction to Network Attacks
Description:
In the scenario of the of the Distributed Reactions, an I2RS client is attached to the routing functions on a two network devices (R1 and R2), and a network monitoring device (see figure 2). The routing device R1 has external ports upon which both valid sources and (upon attack) invalid sources may send data. The I2RS client is learning attack prefixes from the monitoring devices which are processing samples of the traffic. A set of suspected prefixes are collected by the I2RS client from the monitoring devices. The I2RS Client uses these prefixes to control the attack mitigation reading and writing RIB policy.
Currently, the [I-D.ietf-i2rs-rib-info-model] only includes a "route change notification" or "next-hop resolution". Neither of these change notifications directly imply listening to a stream of the data below, but should. This draft is focused on the READ filters installed for the stream of notifications suggested by the [I-D.ietf-i2rs-architecture]
The I2RS Client sends command to the I2RS agent in R1 and R2 to request event notification of route changes for any destination routes matching (exact or longer) prefixes which begin with 129.10/16 or 192.169/16. The I2RS Client sends notification filter policies to the I2RS Agents at R1 and R2 to collect with the notification: the routing instance, the RIB, the Route(route-attributes, route-match, and next-hop list) for the watched prefixes. The I2RS Client also sends commands to the forwarding function of R1, R2, and the monitoring device to provide traffic statistics regarding the number of prefixes received with these routes beginning with the prefix 129.10/16 (match or longer), and 192.169/16 (match or longer).
The Read Filter policy is instantiated at R1 and R2 in order to filter just the routes necessary to track. Previous attack patterns have seen 192.169.10/24 or longer prefixes used to during the attack. A special detailed receive policy is also set-up to prepare for these attacks.
The policy filtering matches security attack vector named "red dog 1" so the operator decides to give this policy set an identity of "red dog 1" with a scope of read, a role of security monitoring, a precedence of 1, a priority of 1, and a security model of secure TCP. The network prefix 129.10/16 (exact or longer) is identified as red-net, and the prefix 192.169/16 (exact or longer) is weak-red-net. The 192.169.10/24 is identified as weak-red-watch.
The Read filters sent for the states are include filters for the traffic statistics per interface (Eg. exterior interface to network, attack source, and R1-R2 Interface).
The following diagram provides the filters for the first policy. The policy filtering matches attack vector "red dog 1" so the operator decides to give this policy set an identity of "red dog 1" with a scope of read, a role of security monitoring, a precedence of 1, a priority of 1, and a security model of secure TCP.
+-------------------------+
| Read Filtering |
| Policy for I2RS Agent |
| Policy Set for |
| Attack filters |
+--+-----------------+----+
^ [1..N] ^ [1..N]
/|\ /|\ ------------------------------------+
| "extends" |-----------------+ |
| | | |
+--------^-----+ +-------^-------+ +-----+---------+ +-------+------+
| Policy Group | | Policy Rule 1 | | Policy Rule 2 | |Policy Rule 3 | ....
| Red Dog 1 | | red-net | | weak-red-net | |weak-red-watch|
+--------------+ +---------------+ +---------------+ +--------------+
: :
......: :.....
: :
: :
+---------V---------+ +-V-------------+
| Policy Condition | | Policy Action |
+-------------------+ +---------------+
: : : : : :
.....: . :..... .....: . :.....
: : : : : :
+----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+
| Match | |Policy | |Policy| | Set || Policy ||Policy|
|Operator| |Variable| |Value | |Operator||Variable|| Value|
+--------+ +--------+ +------+ +--------++--------++------+
IP-ADDRESS- Destination Send
AS-RESOLVED Address 129.10/16 Set Route yes
-BY-DNS info
Figure 3: Example of read statistics filter
The following is the Read Filtering Policy Set 1
Read Policy List
The read policy list has the summary structure below. All Structures underneath the filter policies can utilize template from the three layer generic policy model found in [I-D.hares-i2rs-info-model-policy]. Note that policy groups can be included in policy groups.
read filter-policies
0...N |
policy set
|------------------------|
|---policy group [1-N] policy rules [1-N]-- status
|----| | | | |
| | | |
+-------+----+-------+ policy policy enabled/disable
| | | | condition Action mandatory/optional
Identity role priority precedence
|
+----------+
| |
resource scope
(read / write)
(event)
Figure 5 - read filter policies
scenario:
+---------------------+
| APP or Controller |
+---------------------+
|
|
+----------------+
/ Centralized \
+ Route server +
----------------------
| hub (F) |
| 192.50.128/24 *---------+
+--*----*---*------*-+ |
| | | | | |
+--*--+ | +-*--+ +*----+ |
source 1---| A |---| C |--| E |---- |
\ /+--+--+ | +----+ +-----+ |
\ / | | | |
\/ | | | |
/\ +-----+ | +-----+*-----------+
source 2 \ | B *-| | D |
\| |-----| |-----
+-----+ +-----+
*- are BGP RR connections
|- are hub/spoke connects
spokes: A,B,C,D,E nodes
hub: F node
The second use case mentioned in [I-D.white-i2rs-use-case] is an improvement of the hub and spoke overlay networks. Current hub and spoke networks balance between information held in the spoke table and optimized routing in the overlay, and mobility of nodes. Most solutions in this space use some form of centralized route server which keeps all routes (reachable destination and next hops), and has a protocol by which the route-server and spoke devices communicate, and caches at remote site. [I-D.white-i2rs-use-case] suggests that I2RS can provide an alternative control plane by allowing remote sites to register (or transmit through BGP) the reachable destinations at each site, along with the router within the forwarding path.
The [I-D.ji-i2rs-usecases-ccne-service] also provides a more detailed discussion of the centralized control element that supports using I2rs plus BGP Route-Reflectors (RR), I2RS plus MPLS-TE and PCE (RFC4655), (both stateless and stateful [I-D.ietf-pce-stateful-pce]).
For both use cases, the read filtering allows the centralized server to obtain notification of route changes (installed, active, who) and next-hop resolution per [I-D.ietf-i2rs-rib-info-model] for a particular range of addresses. In addition, interface failures will impact the possible route calculated at the hub. A notification stream watching interfaces and nexthop changes can be tailored to watch the interfaces for the main traffic path and backup paths.
Example Read Filters
Across the "*--*" links the hub passes the I2RS and BGP protocol packets. Also across these links passes the the traffic forwarded to the hub, and then forward to the correct destination.
The route server sets policy group CCNE-2 to look for address changes in forwarding pathway routes in address range 192.50.128/18(match or longer), nexthop changes on 192.150.150/24, interface failures in 192.150.160/24, and failures for Route installs. Policy is name CCNE-2.
The following additions to the RIB Info model are needed to support this use case
scenario: TBD
scenario: TBD
This section specifies the network policy information model in Routing Backus-Naur Form (RBNF, [RFC5511]). The policy definitions utilize the generic information model for policy. The RBNF form below is split into two parts: specific read filter policies, and a reference section for the generic information model ([I-D.hares-i2rs-info-model-policy])
<Read-Filter-Policies> ::= [<Policy-Set>] <Policy-Set> ::=[<Policy-Group>]
This section provides the RBNF definitions from utilized from the generic information model ([I-D.hares-i2rs-info-model-policy]). This section is informational and will be removed once referencing issues to the generic model have been resolved.
<PolicyGroup> ::= <Identity>
<Role>
<priority>
<precedence>
<Policy-Rule>
[<Supporting-Policy-Group>]
[<Policy-Group-Extension>]
<Scope> ::= <Read-Scope>
|<Write-Scope>
<Role> ::= <Resource>
| <Scope>
<Policy-Group-Extension> ::= <>
...
<network-policy-rule> ::= (<policy-rule>...)
<policy-rule> ::= <Identity>
<priority>
<precedence>
<Role>
(<Condition>
(<Action>...)
<Security-Model>
[<policy-rule-extension>]
<Scope> ::= (<Read> [<read-scope>]) |
(<Write> [<write-scope>])
(<Notification> [<notification-scope>])
<Role> ::= <Resource> | <Scope>
<Security-Model> ::= <First-Matching>|<All-Matching>
<policy-rule-extension> ::= <i2rs-policy-extension> |
...
<condition> ::= <variable>
(<value>...)
[<Match-Operator>]
[<condition-extension>]
<Match-Operator> ::= <IS-SET-MEMBER'>
|<IN-INTEGER-RANGE>
|<IP-ADDRESS-AS-RESOLVED-BY-DNS>
|<Match-Operator-extension>
<condition-extension> ::= <i2rs-condition-extension> |
...
<action> ::= <variable>
<value>
<Set-Operator>
<Notify-Operator>
[<action-extension> ]
<action-extension> ::= <i2rs-action-extension> |
...
<local-policy-rule> ::= (<local-policy-rule>...)
<local-policy-rule> ::= <Identity>
<priority>
<precedence>
<Role>
(<Condition>
(<Action>...)
<Security-Model>
<Scope> ::= (<Read> [<read-scope>]) |
(<Write> [<write-scope>])
<Role> ::= <Resource> | <Scope>
<Security-Model> ::= <First-Matching>|
<All-Matching>
...
<condition> ::= <variable>
(<value>...)
[<Match-Operator>]
[<condition-extension>]
<Match-Operator> ::= <IS-SET-MEMBER'>
|<IN-INTEGER-RANGE>
|<IP-ADDRESS-AS-RESOLVED-BY-DNS>
|<Match-Operator-extension>
<condition-extension> ::= <i2rs-condition-extension> |
...
<action> ::= <variable>
<value>
<Set-Operator>
[<action-extension>]
<action-extension> ::= <i2rs-action-extension> |
...
The elements of the Policy Group information model are as follows:
The elements of the Network-Policy Rule information model are as follows:
The local network-policy model extends the Network-Policy Rule information model. The elements of the local network-policy model are the local network-policy model as follows:
This draft includes no request to IANA.
TBD.