idnits 2.17.1 draft-marques-sdnp-flow-spec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([I-D.marques-l3vpn-end-system], [RFC5575]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 109: '... VPN. The egress MAY also choose to ap...' RFC 2119 keyword, line 163: '... VPN Forwarder MUST support stateles...' RFC 2119 keyword, line 296: '...ments in an item SHOULD follow the "fl...' RFC 2119 keyword, line 302: '... port>" SHOULD be mutually exclusive...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 2012) is 4393 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-marques-l3vpn-end-system-05 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Marques 3 Internet-Draft Contrail Systems 4 Intended status: Standards Track L. Fang 5 Expires: October 01, 2012 Cisco Systems 6 P. Pan 7 Infinera Corp 8 A. Shukla 9 Juniper Networks 10 M. Napierala 11 AT&T Labs 12 April 2012 14 Traffic classification in end-system IP VPNs. 15 draft-marques-sdnp-flow-spec-01 17 Abstract 19 When IP VPNs are used to interconnect end-systems [I-D.marques-l3vpn- 20 end-system] it may be desirable to introduce traffic control rules at 21 a finer level of granularity than an IP destination address. 23 This document extends the end-system IP VPN specification with 24 support for fine grain traffic classification, filtering and 25 redirection rules. It applies the existing BGP IP VPN flow 26 specification dissemination mechanism [RFC5575] to end-system IP VPNs 27 in order to provide the ability to control IP packets that match a 28 specific pattern, which may include fields other than the IP 29 destination address. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 01, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. VPN Forwarder functionality . . . . . . . . . . . . . . . . . 4 65 3. XML schema . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Signaling gateway functionality . . . . . . . . . . . . . . . 7 67 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 When end-system IP VPNs [I-D.marques-l3vpn-end-system] are used to 75 interconnect Virtual Machines or other multi-tenant applications it 76 may be desirable to control the flow of traffic between sender(s) and 77 receiver at a finer level of granularity than an IP destination host 78 prefix. 80 In the IP protocol model, ingress points map traffic into forwarding 81 equivalence classes (FECs) which are then given consistent treatment 82 through a transport network. This document defines a signaling 83 protocol that conveys traffic classification rules. These rules can 84 be applied by ingress points into an end-system IP VPN in order to 85 define FECs that depend on both the destination IP address of the 86 traffic as well as additional fiels such as the the transport 87 protocol and ports. 89 One example where this may be desirable is in scenarios where 90 different VPNs may exchange traffic directly. For instance, a VPN 91 that provides a common service to multiple tenants. In this case, 92 the owner of the destination address may wish to inject a traffic 93 rule that limits traffic to TCP packets to and from a specific port. 94 Another example is an application that request specific diffserv 95 [RFC2474] markings for certain types of traffic. In other 96 situations, network administrators may wish to inject specific rules 97 that temporarily redirect traffic. 99 This document uses a point-to-multipoint model for traffic filtering 100 rules where the traffic egress requests all the ingresses to perform 101 a given traffic classification action. The entity that advertises 102 the destination address of the traffic, or a proxy in its behalf, 103 injects a flow-based route advertisement into the signaling 104 infrastructure. This flow-based route is propagated according to VPN 105 policies to all the ingress points of the VPN, the end-systems which 106 contain VMs allowed to access the destination. 108 The traffic filtering rules are then applied at all the ingress 109 points of the VPN. The egress MAY also choose to apply the same rules 110 in cases where they are equivalent at both locations. 112 +-----+ +--------+ 113 | VM1 | --- | host 1 | - 114 +-----+ +--------+ \ 115 \+~~~~~~~~~+ +--------+ +------+ 116 | network | ---- | host 3 | -- | VM 3 | 117 +~~~~~~~~~+ +--------+ +------+ 118 / 119 +-----+ +--------+ / 120 | VM2 | --- | host 2 | - / 121 +-----+ +--------+ 122 124 The figure above contains an example topology in which a given VM (VM 125 3) provides a common infrastructure service. VM1 and VM2 belong to 126 different tenants and are in VPNs which are allowed to access the 127 service in VM3. 129 This specification allows VM3 to advertise a traffic filtering rule, 130 as a flow-spec route, requesting the VPN Forwarders for hosts 1 and 2 131 to limit any traffic flow to VM3's destination IP address such that, 132 for instance, only packets for a specific TCP destination port are 133 allowed. 135 It is important to note that traffic filtering does not avoid the 136 need for application level authorization and authentication. 138 When a flow-spec route is advertised, the number of possible ingress 139 points it not known in advance. There is no mechanism to generate a 140 positive or negative acknowledgement from the ingress points. This 141 is in contrast to the more traditional network management operation 142 in which the management station is aware of all the agents that must 143 be controlled. 145 As with the base end-system IP VPN specification, the forwarding and 146 signaling networks are distinct. Flow-spec routes are advertised by 147 the egress end-system or by a proxy in its behalf. The routes are 148 injected into one or more XMPP signaling gateways and propagated 149 using the BGP flow-spec address family [RFC5575]. 151 Using the same vrf-import and export policies that define the IP VPN, 152 the flow-spec routes are then imported from BGP into a vpn-specific 153 database and advertised to all the ingress end-system, which apply 154 them. 156 This document limits itself to "stateless" traffic classification 157 rules that classify a given IP packet independently of any previous 158 data traffic. 160 2. VPN Forwarder functionality 162 In order to implement the functionality described in this document a 163 VPN Forwarder MUST support stateless traffic classification rules 164 that are capable of matching the TCP/IP protocol fields defined in 165 [RFC5575]. 167 This document assumes that this traffic filtering functionality can 168 be associated with a particular Virtual Routing and Forwarding (VRF) 169 table, either directly or through the virtual interfaces associated 170 with the VRF. Conceptually, the traffic classification rules 171 described in this document are applied at the VRF level. 173 The BGP Flow Specification [RFC5575] document lists a set of TCP/IP 174 packet header fields and match operations that are though to be a 175 minimum common set of supported functionality among implementations. 177 The defined packet header fields are: 179 o IPv4 destination address. 181 o IPv4 source address. 183 o IP protocol identifier. 185 o Transport Ports: Source, Destination or Either. 187 o ICMP Type and Code. 189 o TCP flags. 191 o Packet length. 193 o Diffserv Code Point. 195 o IPv4 fragmentation flags. 197 When numeric values are specified (i.e. fields other than IP 198 addresses), the match operator can specify a list of values with 199 inequality operators. Note that this may result in one logical rule, 200 as defined by this specification to be implemented as multiple 201 classification rules on the underlying implementation. 203 The match operator is defined via the following BNF grammar: 205 ::= 207 ::= 209 | "||" 211 | "&&" 213 ::= value 215 ::= "<" | "<=" | "=" | "!=" | ">=" | ">" 217 As an example, a value range is expressed as: ">= begin && <= end". 219 The result of a flow-spec rule is one of the following actions: 221 o allow 223 o deny 225 o rate-limit 227 o redirect 229 o copy 231 o log 233 o set-dscp 235 The redirect and copy actions have as a target an FEC which should 236 contain an unique UUID [RFC4122] identifier as well as information 237 regarding the IP next-hop address and label used for forwarding. 239 The copy action instructs the system to generate a copy of the 240 original packet and forward to the specified FEC. Both copy and log 241 actions have an additional parameter which controls whether all 242 matching packets or a sample is subject to the specified treatment. 244 The 'set-dscp' action specifies the DSCP value to be assigned to the 245 outer IP header of the packet, when a packet is encapsulated. 247 3. XML schema 248 In the end-system IP VPN [I-D.marques-l3vpn-end-system] 249 specification, IP reachability information is encoded as XMPP "item" 250 information belonging to collection nodes where each collection is 251 the IP reachability information for a given VPN. End-systems can 252 publish and receive notifications for these nodes. 254 This document uses the same approach. It uses a collection with the 255 name of "/ip4-flow-spec" to publish and receive 256 updates corresponding to IPv4 flow-spec routes. When an end-system 257 published a node into such a collection it must generate a node name 258 that is unique among the nodes that it publishes. It then associates 259 that node with the collection. 261 XML encoding used by flow-spec items: 263 264 265 10.0.1/24 266 20.0.128/20 267 =6 || =17 268 =80 269 =80 270 =80 271 =1 272 =1 273 =(syn|rst|ack|fin) 274 >40 275 =0 276 =(df|first|more|last) 277 278 279 280 281 282 283 'infrastructure-ip-address' 284 285 286 287 288 ... 289 290 291 292 128 293 294 295 296 The sequence of XML elements in an item SHOULD follow the "flow 297 specification" NLRI type order as the example above. IP source and 298 destination prefixes are encoded in their standard textual 299 representation of "/". Protocol and 300 Port elements are expressed using the match operator syntax 301 documented above. "" and "" or "" SHOULD be mutually exclusive. The icmp type and code fields 303 as well as ip-length and dscp are again encoded using the value match 304 operator. The "" element uses either an equality or match 305 operation of the TCP header flags. A binary match is expressed as "m 306 /(syn|rst|ack|fin)/". The "" element may also use a 307 binary match operation. 309 4. Signaling gateway functionality 311 As with IP reachabilty information, signaling gateways create a 312 routing database for each 'vpn-customer-name'. An XMPP client (a VPN 313 Forwarder) can publish and subscribe to multiple of these databases. 314 Each "virtual interface" on the end-system is associated with a 315 virtual routing table on the gateway. 317 From a signaling perspective, the gateway functions as a IP VPN PE as 318 described in section 8 of [RFC5575]. As with IP reachability, this 319 document uses the XMPP interface to delegate the forwarding 320 functionality to the VPN Forwarder, separating it from the signaling 321 node. 323 5. Applications 325 This specification provides a mechanism to distribute traffic 326 classification rules to many enforcement points. This may of 327 interest in applications where it is desirable to avoid the standard 328 approach of a centralized enforcement point. Typically in situations 329 where the volume of traffic or the nature of the problem make it more 330 cost effective to do so. 332 One such application is the enforcement of stateless traffic 333 forwarding rules for infrastructure services. An application level 334 services, such as a storage server may need to support multiple data- 335 center tenants. In this scenario the storage VPN advertises a given 336 address prefix, which contains both the anycast IP address of the 337 load-balancers as the addresses of individual servers. Using VPN 338 import policies, the data-center management solution allows the 339 tenant specific VPNs to see these routes. The tenant VPN addresses 340 must also be reachable on the storage VPN, in this example. 342 This specification allows the storage service to block out traffic 343 that does not match the specific transport protocols used to provide 344 this service. It also allows confirming traffic to be marked with 345 the appropriate diffserv classification. The network administrator 346 case also use this mechanism for diagnostic purposes. 348 6. Security Considerations 349 There are two independent areas that are worth examining when it 350 comes to security. The integrity of the control plane information 351 and the forwarding actions. 353 This document assumes that all signaling interactions use mutual 354 authentication, where all communication channels are authenticated. 356 For traffic filtering and redirection this mechanism assumes a "best- 357 effort" model. The ingress points will strive to perform the actions 358 specified by the egress. However there are no strict guarantees that 359 the actions can be applied successfully on an ingress points or that 360 the order of operations is such that no non-conforming traffic is 361 ever presented to the egress. 363 For traffic filtering rules, the egress point can choose to apply the 364 rules also in order to provide stronger guarantees. 366 Applications should themselves authenticate its communication peers 367 my methods that do not depend on the IP addresses used at the network 368 layer. 370 7. References 372 [I-D.marques-l3vpn-end-system] 373 Marques, P., Fang, L., Pan, P., Shukla, A., Napierala, M. 374 and N. Bitar, "BGP-signaled end-system IP/VPNs.", 375 Internet-Draft draft-marques-l3vpn-end-system-05, March 376 2012. 378 [RFC2474] Nichols, K., Blake, S., Baker, F. and D.L. Black, 379 "Definition of the Differentiated Services Field (DS 380 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 381 1998. 383 [RFC4122] Leach, P., Mealling, M. and R. Salz, "A Universally Unique 384 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 386 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J. 387 and D. McPherson, "Dissemination of Flow Specification 388 Rules", RFC 5575, August 2009. 390 Authors' Addresses 392 Pedro Marques 393 Contrail Systems 394 440 N Wolfe Rd 395 Sunnyvale, CA 94085 397 Email: roque@contrailsystems.com 398 Luyuan Fang 399 Cisco Systems 400 111 Wood Avenue South 401 Iselin, NJ 08830 403 Email: lufang@cisco.com 405 Ping Pan 406 Infinera Corp 407 140 Caspian Ct. 408 Sunnyvale, CA 94089 410 Email: ppan@infinera.com 412 Amit Shukla 413 Juniper Networks 414 1194 N. Mathilda Av. 415 Sunnyvale, CA 94089 417 Email: amit@juniper.net 419 Maria Napierala 420 AT&T Labs 421 200 Laurel Avenue 422 Middletown, NJ 07748 424 Email: mnapierala@att.com