One document matched: draft-marques-sdnp-flow-spec-00.xml

<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc toc="yes"?>
<rfc ipr='trust200902' docName='draft-marques-sdnp-flow-spec-00'>

<front>
<title abbrev='Traffic classification on end-system VPNs'>
Traffic classification, filtering and redirection for end-system IP VPNs.
</title>

<author initials='P.' surname='Marques' fullname='Pedro Marques'>
    <address>
    <email>pedro.r.marques@gmail.com</email>
    </address>
</author>

<author initials='L.' surname='Fang' fullname='Luyuan Fang'>
  <organization>Cisco Systems</organization>
  <address>
    <postal>
      <street>111 Wood Avenue South</street>
      <city>Iselin</city>
      <region>NJ</region>
      <code>08830</code>
    </postal>
    <email>lufang@cisco.com</email>
  </address>
</author>

<author initials='P.' surname='Pan' fullname='Ping Pan'>
  <organization>Infinera Corp</organization>
  <address>
    <postal>
      <street>140 Caspian Ct.</street>
      <city>Sunnyvale</city>
      <region>CA</region>
      <code>94089</code>
    </postal>
    <email>ppan@infinera.com</email>
  </address>
</author>

<author initials='A.' surname='Shukla' fullname='Amit Shukla'>
  <organization>Juniper Networks</organization>
  <address>
    <postal>
      <street>1194 N. Mathilda Av.</street>
      <city>Sunnyvale</city>
      <region>CA</region>
      <code>94089</code>
    </postal>
    <email>amit@juniper.net</email>
  </address>
</author>

<date month="October" year="2011"/>
<area>Routing</area>
<abstract>
<t>When IP VPNs are used to interconnect
<xref target='I-D.marques-l3vpn-end-system'>end-systems</xref> it may be
desirable to introduce traffic control rules at a finer level of granularity
than an IP destination address.</t>

<t>This document extends the end-system IP VPN specification with support
for fine grain traffic classification, filtering and redirection rules.
It applies the
existing BGP IP VPN <xref target='RFC5575'>flow specification dissemination
mechanism</xref> to end-system IP VPNs in order to provide the
ability to control IP packets that match a specific pattern, which may include
fields other than the IP destination address.</t>
</abstract>
</front>

<middle>
<section title='Introduction'>
<t>When <xref target='I-D.marques-l3vpn-end-system'>end-system IP VPNs</xref>
are used to interconnect Virtual Machines or other multi-tenant applications it may be desirable to control the flow of traffic between sender(s) and receiver
at a finer level of granularity than an IP destination host prefix.</t>

<t>In the IP protocol model, ingress points map traffic into forwarding equivalence classes (FECs) which are then given consistent treatment through a transport network. This document defines a signaling protocol that conveys traffic
classification rules. These rules can be applied by ingress points into an
end-system IP VPN in order to define FECs that
depend on both the destination IP address of the traffic as well as additional
fiels such as the the transport protocol and ports.</t>

<t>One example where this may be desirable is in scenarios where different VPNs may exchange traffic directly. For instance, a VPN that provides a common service to multiple tenants. In this case, the owner of the destination address may
wish to inject a traffic rule that limits traffic to TCP packets to and from a specific port.

Another example is an application that request specific <xref target='RFC2474'>
diffserv</xref> markings for
certain types of traffic.

In other situations, network administrators may
wish to inject specific rules that temporarily redirect traffic.</t>

<t>This document uses a point-to-multipoint model for traffic filtering
rules where the traffic egress requests all the ingresses to perform a given
traffic classification action.
The entity that advertises the destination address of the traffic, or a
proxy in its behalf, injects a flow-based route advertisement into the signaling
infrastructure. This flow-based route is propagated according to VPN policies
to all the ingress points of the VPN, the end-systems which contain VMs
allowed to access the destination.</t>

<t>The traffic filtering rules are then applied at all the ingress points
of the VPN. The egress MAY also choose to apply the same rules in cases
where they are equivalent at both locations.</t>

<figure anchor='model'>
<artwork><![CDATA[
+-----+	    +--------+
| VM1 | --- | host 1 | -
+-----+	    +--------+   \
             <filter>      \+~~~~~~~~~+	     +--------+	   +------+
                            | network | ---- | host 3 | -- | VM 3 |
                            +~~~~~~~~~+	     +--------+	   +------+
			   /
+-----+	    +--------+	  /
| VM2 | --- | host 2 | - /
+-----+	    +--------+
             <filter>
]]></artwork>
</figure>

<t>The figure above contains an example topology in which a given VM (VM 3)
provides a common infrastructure service. VM1 and VM2 belong to different
tenants and are in VPNs which are allowed to access the service in VM3.</t>

<t>This specification allows VM3 to advertise a traffic filtering rule, as
a flow-spec route,
requesting the Host OSes in host 1 and host 2 to limit any traffic flow to
VM3's destination IP address such that, for instance, only packets for a
specific TCP destination port are allowed.</t>

<t>It is important to note that traffic filtering does not avoid the need for
application level authorization and authentication.</t>

<t>When a flow-spec route is advertised, the number of possible ingress points
it not known in advance. There is no mechanism to generate a positive or
negative acknowledgement from the ingress points. This is in contrast
to the more traditional network management operation in which the management
station is aware of all the agents that must be controlled.</t>

<t>As with the base end-system IP VPN specification, the forwarding
and signaling networks are distinct. Flow-spec routes are advertised
by the egress end-system or by a proxy in its behalf. The routes are
injected into one or more XMPP signaling gateways and propagated using the
BGP <xref target="RFC5575">flow-spec address family</xref>.</t>

<t>Using the same vrf-import and export policies that define the IP VPN, the
flow-spec routes are then imported from BGP into a vpn-specific database and advertised to all the ingress end-system, which apply them.</t>

<t>This document limits itself to "stateless" traffic classification rules that
classify a given IP packet independently of any previous data traffic.
</t>

</section>

<section title='End-system functionality'>
<t>It is common for end-systems to support traffic classification
. One such example is the Linux "ipchains" functionality. This document
assumes that such functionality can be associated with a particular Virtual
Routing and Forwarding (VRF) table on the end-system and that each
virtual interface is associated with a VRF. The traffic classification rules
described in this document are applied at the VRF level.</t>

<t>The BGP <xref target='RFC5575'>Flow Specification</xref> document
lists a set of IPv4 protocol header fields and match operations that are
though to be a minimum
common set of supported functionality among hardware implementations.</t>

<t>These fields are:
<list style='symbols'>
<t>IPv4 destination address.</t>
<t>IPv4 source address.</t>
<t>IP protocol identifier.</t>
<t>Transport Ports: Source, Destination or Either.</t>
<t>ICMP Type and Code.</t>
<t>TCP flags.</t>
<t>Packet length.</t>
<t>Diffserv Code Point.</t>
<t>IPv4 fragmentation flags.</t>
</list>
</t>
<t>When numeric values are specified (i.e. fields other than IP addresses), the match operator can specify a list of values with inequality operators. Note
that this may result in one logical rule, as defined by this specification
to be implemented as multiple classification rules on the underlying OS implementation. For instance the match operations in the Linux "ipchains" implementation
are more restrictive.</t>
<t>The match operator is defined via the following BNF grammar:
<list style='hanging'>
  <t hangText="<match> ::="><terms></t>
  <t hangText="<terms> ::="><term> </t>
<t>| <term> "||" <terms> </t>
<t>| <term> "&&" <terms></t>
  <t hangText="<term> ::="> <operator> value</t>
  <t hangText="<operator> ::="> "<" | "<=" | "=" | "!=" | ">=" | ">"</t>
</list>
</t>
<t>As an example, a value range is expressed as:
">= begin && <= end".</t>

<t>The result of a flow-spec rule is one of the following actions:
<list style='symbols'>
  <t>allow</t>
  <t>deny</t>
  <t>rate-limit</t>
  <t>redirect</t>
  <t>copy</t>
  <t>log</t>
  <t>set-dscp</t>
</list>
</t>

<t>The redirect and copy actions have as a target an FEC which should contain
an unique <xref target='RFC4122'>UUID</xref> identifier as well as information regarding the 
SNPA address and label used for forwarding.</t>
<t>The copy action instructs the system to generate a copy of the original
packet and forward to the specified FEC. Both copy and log actions have an
additional parameter which controls whether all matching packets or a sample
is subject to the specified treatment.</t>
<t>The 'set-dscp' action specifies the DSCP value to be assigned to the outer
IP header of the packet, when a packet is encapsulated.</t>
</section>

<section title='XML schema'>
<t>
In the <xref target='I-D.marques-l3vpn-end-system'>end-system IP VPN</xref>
specification, IP reachability information is encoded as XMPP "item" information
belonging to collection nodes where each collection is the IP reachability
information for a given VPN.
End-systems can publish and receive notifications for these nodes.</t>

<t>This document uses the same approach. It uses a collection with the
name of "<vpn-customer-name>/ip4-flow-spec"
 to publish and receive
updates corresponding to IPv4 flow-spec routes.
When an end-system published a node into such a collection it must generate
a node name that is unique among the nodes that it publishes. It then
associates that node with the collection.</t>

<figure>
<preamble>XML encoding used by flow-spec items:</preamble>
<artwork align='left'><![CDATA[
<item>
  <entry xmlns='http://ietf.org/protocol/bgpvpn/ip4-flow-spec'>
    <ip4-destination>10.0.1/24</ip4-destination>
    <ip4-source>20.0.128/20</ip4-source>
    <ip4-protocol>=6 || =17</ip4-protocol>
    <port>=80</port>
    <destination-port>=80</destination-port>
    <source-port>=80</source-port>
    <icmp-type>=1</icmp-type>
    <icmp-code>=1</icmp-code>
    <tcp-flags>=(syn|rst|ack|fin)</tcp-flags>
    <ip-length>>40</ip-length>
    <dscp>=0</dscp>
    <ip4-fragment>=(df|first|more|last)</ip4-fragment>
    <action>
      <accept/>
      <deny/>
      <rate-limit rate='10pps'/>
      <redirect>
        <fec uuid='550e8400-e29b-41d4-a716-446655440000'>
	  <snpa af='1'>'infrastructure-ip-address'</snpa>
	  <label>1</label>
	</fec>
      </redirect>
      <copy>
        <fec>...</fec>
	<sample/>
      </copy>
      <log/>
      <set-dscp>128</set-dscp>
    </action>
  </entry>
</item>
]]></artwork>
</figure>
<t>
The sequence of XML elements in an item SHOULD follow the "flow specification" NLRI type order as the example above. IP source and destination prefixes are encoded in their standard textual representation of
<dotted notation>"/"<prefix-length>. Protocol and Port elements
are expressed using the match operator syntax documented above. "<port>"
and "<destination-port>" or "<source-port>" SHOULD be mutually
exclusive. The icmp type and code fields as well as ip-length and dscp are
again encoded using the value match operator. The ">tcp-flags>" element
uses either an equality or match operation of the TCP header flags. A binary match is expressed as "m/(syn|rst|ack|fin)/". The "<ip4-fragment>" element
may also use a binary match operation.
</t>

</section>

<section title='Signaling gateway functionality'>
<t>As with IP reachabilty information, signaling gateways
create a routing database for each
'vpn-customer-name'. An XMPP client (an end-system) can publish and
subscribe to multiple of these databases. Each "virtual interface"
on the end-system is associated with a virtual routing table on the gateway.</t>

<t>From a signaling perspective, the gateway functions as a IP VPN PE as
described in section 8 of <xref target='RFC5575'/>. As with IP reachability,
this document uses the XMPP interface to delegate the forwarding functionality
to the end-system, separating it from the signaling node.</t>

<t>In <xref target='RFC5575'/> no route validation procedure is defined
for the IP VPN application. For the purposes of the end-system IP VPN
application, signaling gateways SHOULD enforce the following rules.
<list>
  <t>A flow-spec route is valid if its Route Target list is an exact match
to the export route target list for the virtual routing table.</t>
  <t>A flow-spec route is valid if it contains an IP destination prefixes and
there is an exact match between its Route Target list and the Route Target list
contained in the IP unicast route that covers that specific destination prefix.</t>
  <t>A flow-spec route should be considered unfeasible otherwise and not imported into the specific virtual routing database.</t>
</list>
</t>

</section>

<section title='Top-of-rack switch'>
<t>It may be desirable to implement some of the traffic classification
functionality on a traditional network element, rather than in the end-system.
 For instance the end-system may not fully support all the desired
functionality.</t>
<t>In this case, a network element can have access to the signaling information
using two different methods:
<list>
  <t>By receiving BGP signaling information directly. A Top-of-rack switch,
for example, could infer whether a given end-system is downstream from
it by examining the IP infrastructure addresses of the end-systems and
extracting information into its forwarding plane whenever an end-point of
a VPN is downstream.</t>
  <t>By using a "men-in-the-middle" technique in which the XMPP client
sessions from end-systems terminate in the TOP-of-rack switches. The
switch can then establish an XMPP session to the signaling gateway and
proxy the information between the two sessions.</t>
</list>
</t>

<t>The second approach presents the switch itself with a simplified
interface in which it does not need to understand the policies associated
with a specific VPN.</t>

</section>

<section title='Applications'>
<t>This specification provides a mechanism to distribute traffic classification rules to many enforcement points. This may of interest in applications where
it is desirable to avoid the standard approach of a centralized enforcement
point. Typically in situations where the volume of traffic or the nature of
the problem make it more cost effective to do so.</t>
<t>One such application is the enforcement of stateless traffic forwarding rules for infrastructure services. An application level services, such as a storage
server may need to support multiple data-center tenants. In this scenario
the storage VPN advertises a given address prefix, which contains both
the anycast IP address of the load-balancers as the addresses of individual
servers. Using VPN import policies, the data-center management solution
allows the tenant specific VPNs to see these routes. The tenant VPN addresses
must also be reachable on the storage VPN, in this example.</t>
<t>This specification allows the storage service to block out traffic that does not match the specific transport protocols used to provide this service. It also allows confirming traffic to be marked with the appropriate diffserv classification. The network administrator case also use this mechanism for diagnostic
purposes.</t>
</section>

<section title='Security Considerations'>
<t>There are two independent areas that are worth examining when it comes to
security. The integrity of the control plane information and the forwarding
actions.</t>
<t>This document assumes that all signaling interactions use mutual authentication, where all communication channels are authenticated.</t>
<t>For traffic filtering and redirection this mechanism assumes a "best-effort"
model. The ingress points will strive to perform the actions specified by
the egress. However there are no strict guarantees that the actions can be
applied successfully on an ingress points or that the order of operations is
such that no non-conforming traffic is ever presented to the egress.</t>
<t>For traffic filtering rules, the egress point can choose to apply the
rules also in order to provide stronger guarantees.</t>
<t>Applications should themselves authenticate its communication peers my methods
that do not depend on the IP addresses used at the network layer.</t>
</section>

</middle>

<back>
  <references>
    <?rfc include="reference.I-D.marques-l3vpn-end-system.xml"?>
    <?rfc include="reference.RFC.2474.xml"?>
    <?rfc include="reference.RFC.4122.xml"?>
    <?rfc include="reference.RFC.5575.xml"?>
  </references>
</back>
</rfc>