idnits 2.17.1 draft-marques-sdnp-flow-spec-00.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 'Intended status' indicated for this document; assuming Proposed Standard 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 111: '...VPN. The egress MAY also choose to ap...' RFC 2119 keyword, line 302: '...ments in an item SHOULD follow the "fl...' RFC 2119 keyword, line 308: '... port>" SHOULD be mutually exclusive...' RFC 2119 keyword, line 331: '...gnaling gateways SHOULD enforce the fo...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 11, 2011) is 4580 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-01 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 5 errors (**), 0 flaws (~~), 3 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 4 Expires: April 13, 2012 L. Fang 5 Cisco Systems 6 P. Pan 7 Infinera Corp 8 A. Shukla 9 Juniper Networks 10 October 11, 2011 12 Traffic classification, filtering and redirection for end-system IP 13 VPNs. 14 draft-marques-sdnp-flow-spec-00 16 Abstract 18 When IP VPNs are used to interconnect end-systems 19 [I-D.marques-l3vpn-end-system] it may be desirable to introduce 20 traffic control rules at a finer level of granularity than an IP 21 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 April 13, 2012. 48 Copyright Notice 49 Copyright (c) 2011 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 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. End-system functionality . . . . . . . . . . . . . . . . . . . 6 66 3. XML schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4. Signaling gateway functionality . . . . . . . . . . . . . . . 10 68 5. Top-of-rack switch . . . . . . . . . . . . . . . . . . . . . . 11 69 6. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Introduction 76 When end-system IP VPNs [I-D.marques-l3vpn-end-system] are used to 77 interconnect Virtual Machines or other multi-tenant applications it 78 may be desirable to control the flow of traffic between sender(s) and 79 receiver at a finer level of granularity than an IP destination host 80 prefix. 82 In the IP protocol model, ingress points map traffic into forwarding 83 equivalence classes (FECs) which are then given consistent treatment 84 through a transport network. This document defines a signaling 85 protocol that conveys traffic classification rules. These rules can 86 be applied by ingress points into an end-system IP VPN in order to 87 define FECs that depend on both the destination IP address of the 88 traffic as well as additional fiels such as the the transport 89 protocol and ports. 91 One example where this may be desirable is in scenarios where 92 different VPNs may exchange traffic directly. For instance, a VPN 93 that provides a common service to multiple tenants. In this case, 94 the owner of the destination address may wish to inject a traffic 95 rule that limits traffic to TCP packets to and from a specific port. 96 Another example is an application that request specific diffserv 97 [RFC2474] markings for certain types of traffic. In other 98 situations, network administrators may wish to inject specific rules 99 that temporarily redirect traffic. 101 This document uses a point-to-multipoint model for traffic filtering 102 rules where the traffic egress requests all the ingresses to perform 103 a given traffic classification action. The entity that advertises 104 the destination address of the traffic, or a proxy in its behalf, 105 injects a flow-based route advertisement into the signaling 106 infrastructure. This flow-based route is propagated according to VPN 107 policies to all the ingress points of the VPN, the end-systems which 108 contain VMs allowed to access the destination. 110 The traffic filtering rules are then applied at all the ingress 111 points of the VPN. The egress MAY also choose to apply the same 112 rules in cases where they are equivalent at both locations. 114 +-----+ +--------+ 115 | VM1 | --- | host 1 | - 116 +-----+ +--------+ \ 117 \+~~~~~~~~~+ +--------+ +------+ 118 | network | ---- | host 3 | -- | VM 3 | 119 +~~~~~~~~~+ +--------+ +------+ 120 / 121 +-----+ +--------+ / 122 | VM2 | --- | host 2 | - / 123 +-----+ +--------+ 124 126 Figure 1 128 The figure above contains an example topology in which a given VM (VM 129 3) provides a common infrastructure service. VM1 and VM2 belong to 130 different tenants and are in VPNs which are allowed to access the 131 service in VM3. 133 This specification allows VM3 to advertise a traffic filtering rule, 134 as a flow-spec route, requesting the Host OSes in host 1 and host 2 135 to limit any traffic flow to VM3's destination IP address such that, 136 for instance, only packets for a specific TCP destination port are 137 allowed. 139 It is important to note that traffic filtering does not avoid the 140 need for application level authorization and authentication. 142 When a flow-spec route is advertised, the number of possible ingress 143 points it not known in advance. There is no mechanism to generate a 144 positive or negative acknowledgement from the ingress points. This 145 is in contrast to the more traditional network management operation 146 in which the management station is aware of all the agents that must 147 be controlled. 149 As with the base end-system IP VPN specification, the forwarding and 150 signaling networks are distinct. Flow-spec routes are advertised by 151 the egress end-system or by a proxy in its behalf. The routes are 152 injected into one or more XMPP signaling gateways and propagated 153 using the BGP flow-spec address family [RFC5575]. 155 Using the same vrf-import and export policies that define the IP VPN, 156 the flow-spec routes are then imported from BGP into a vpn-specific 157 database and advertised to all the ingress end-system, which apply 158 them. 160 This document limits itself to "stateless" traffic classification 161 rules that classify a given IP packet independently of any previous 162 data traffic. 164 2. End-system functionality 166 It is common for end-systems to support traffic classification . One 167 such example is the Linux "ipchains" functionality. This document 168 assumes that such functionality can be associated with a particular 169 Virtual Routing and Forwarding (VRF) table on the end-system and that 170 each virtual interface is associated with a VRF. The traffic 171 classification rules described in this document are applied at the 172 VRF level. 174 The BGP Flow Specification [RFC5575] document lists a set of IPv4 175 protocol header fields and match operations that are though to be a 176 minimum common set of supported functionality among hardware 177 implementations. 179 These fields are: 181 o IPv4 destination address. 183 o IPv4 source address. 185 o IP protocol identifier. 187 o Transport Ports: Source, Destination or Either. 189 o ICMP Type and Code. 191 o TCP flags. 193 o Packet length. 195 o Diffserv Code Point. 197 o IPv4 fragmentation flags. 199 When numeric values are specified (i.e. fields other than IP 200 addresses), the match operator can specify a list of values with 201 inequality operators. Note that this may result in one logical rule, 202 as defined by this specification to be implemented as multiple 203 classification rules on the underlying OS implementation. For 204 instance the match operations in the Linux "ipchains" implementation 205 are more restrictive. 207 The match operator is defined via the following BNF grammar: 209 ::= 211 ::= 213 | "||" 215 | "&&" 217 ::= value 219 ::= "<" | "<=" | "=" | "!=" | ">=" | ">" 221 As an example, a value range is expressed as: ">= begin && <= end". 223 The result of a flow-spec rule is one of the following actions: 225 o allow 227 o deny 229 o rate-limit 231 o redirect 233 o copy 235 o log 237 o set-dscp 239 The redirect and copy actions have as a target an FEC which should 240 contain an unique UUID [RFC4122] identifier as well as information 241 regarding the SNPA address and label used for forwarding. 243 The copy action instructs the system to generate a copy of the 244 original packet and forward to the specified FEC. Both copy and log 245 actions have an additional parameter which controls whether all 246 matching packets or a sample is subject to the specified treatment. 248 The 'set-dscp' action specifies the DSCP value to be assigned to the 249 outer IP header of the packet, when a packet is encapsulated. 251 3. XML schema 253 In the end-system IP VPN [I-D.marques-l3vpn-end-system] 254 specification, IP reachability information is encoded as XMPP "item" 255 information belonging to collection nodes where each collection is 256 the IP reachability information for a given VPN. End-systems can 257 publish and receive notifications for these nodes. 259 This document uses the same approach. It uses a collection with the 260 name of "/ip4-flow-spec" to publish and receive 261 updates corresponding to IPv4 flow-spec routes. When an end-system 262 published a node into such a collection it must generate a node name 263 that is unique among the nodes that it publishes. It then associates 264 that node with the collection. 266 XML encoding used by flow-spec items: 268 269 270 10.0.1/24 271 20.0.128/20 272 =6 || =17 273 =80 274 =80 275 =80 276 =1 277 =1 278 =(syn|rst|ack|fin) 279 >40 280 =0 281 =(df|first|more|last) 282 283 284 285 286 287 288 'infrastructure-ip-address' 289 290 291 292 293 ... 294 295 296 297 128 298 299 300 302 The sequence of XML elements in an item SHOULD follow the "flow 303 specification" NLRI type order as the example above. IP source and 304 destination prefixes are encoded in their standard textual 305 representation of "/". Protocol and 306 Port elements are expressed using the match operator syntax 307 documented above. "" and "" or "" SHOULD be mutually exclusive. The icmp type and code fields 309 as well as ip-length and dscp are again encoded using the value match 310 operator. The ">tcp-flags>" element uses either an equality or match 311 operation of the TCP header flags. A binary match is expressed as 312 "m/(syn|rst|ack|fin)/". The "" element may also use a 313 binary match operation. 315 4. Signaling gateway functionality 317 As with IP reachabilty information, signaling gateways create a 318 routing database for each 'vpn-customer-name'. An XMPP client (an 319 end-system) can publish and subscribe to multiple of these databases. 320 Each "virtual interface" on the end-system is associated with a 321 virtual routing table on the gateway. 323 From a signaling perspective, the gateway functions as a IP VPN PE as 324 described in section 8 of [RFC5575]. As with IP reachability, this 325 document uses the XMPP interface to delegate the forwarding 326 functionality to the end-system, separating it from the signaling 327 node. 329 In [RFC5575] no route validation procedure is defined for the IP VPN 330 application. For the purposes of the end-system IP VPN application, 331 signaling gateways SHOULD enforce the following rules. 333 A flow-spec route is valid if its Route Target list is an exact 334 match to the export route target list for the virtual routing 335 table. 337 A flow-spec route is valid if it contains an IP destination 338 prefixes and there is an exact match between its Route Target list 339 and the Route Target list contained in the IP unicast route that 340 covers that specific destination prefix. 342 A flow-spec route should be considered unfeasible otherwise and 343 not imported into the specific virtual routing database. 345 5. Top-of-rack switch 347 It may be desirable to implement some of the traffic classification 348 functionality on a traditional network element, rather than in the 349 end-system. For instance the end-system may not fully support all 350 the desired functionality. 352 In this case, a network element can have access to the signaling 353 information using two different methods: 355 By receiving BGP signaling information directly. A Top-of-rack 356 switch, for example, could infer whether a given end-system is 357 downstream from it by examining the IP infrastructure addresses of 358 the end-systems and extracting information into its forwarding 359 plane whenever an end-point of a VPN is downstream. 361 By using a "men-in-the-middle" technique in which the XMPP client 362 sessions from end-systems terminate in the TOP-of-rack switches. 363 The switch can then establish an XMPP session to the signaling 364 gateway and proxy the information between the two sessions. 366 The second approach presents the switch itself with a simplified 367 interface in which it does not need to understand the policies 368 associated with a specific VPN. 370 6. Applications 372 This specification provides a mechanism to distribute traffic 373 classification rules to many enforcement points. This may of 374 interest in applications where it is desirable to avoid the standard 375 approach of a centralized enforcement point. Typically in situations 376 where the volume of traffic or the nature of the problem make it more 377 cost effective to do so. 379 One such application is the enforcement of stateless traffic 380 forwarding rules for infrastructure services. An application level 381 services, such as a storage server may need to support multiple data- 382 center tenants. In this scenario the storage VPN advertises a given 383 address prefix, which contains both the anycast IP address of the 384 load-balancers as the addresses of individual servers. Using VPN 385 import policies, the data-center management solution allows the 386 tenant specific VPNs to see these routes. The tenant VPN addresses 387 must also be reachable on the storage VPN, in this example. 389 This specification allows the storage service to block out traffic 390 that does not match the specific transport protocols used to provide 391 this service. It also allows confirming traffic to be marked with 392 the appropriate diffserv classification. The network administrator 393 case also use this mechanism for diagnostic purposes. 395 7. Security Considerations 397 There are two independent areas that are worth examining when it 398 comes to security. The integrity of the control plane information 399 and the forwarding actions. 401 This document assumes that all signaling interactions use mutual 402 authentication, where all communication channels are authenticated. 404 For traffic filtering and redirection this mechanism assumes a "best- 405 effort" model. The ingress points will strive to perform the actions 406 specified by the egress. However there are no strict guarantees that 407 the actions can be applied successfully on an ingress points or that 408 the order of operations is such that no non-conforming traffic is 409 ever presented to the egress. 411 For traffic filtering rules, the egress point can choose to apply the 412 rules also in order to provide stronger guarantees. 414 Applications should themselves authenticate its communication peers 415 my methods that do not depend on the IP addresses used at the network 416 layer. 418 8. References 420 [I-D.marques-l3vpn-end-system] 421 Marques, P., Fang, L., and P. Pan, "End-system support for 422 BGP-signaled IP/VPNs.", draft-marques-l3vpn-end-system-01 423 (work in progress), October 2011. 425 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 426 "Definition of the Differentiated Services Field (DS 427 Field) in the IPv4 and IPv6 Headers", RFC 2474, 428 December 1998. 430 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 431 Unique IDentifier (UUID) URN Namespace", RFC 4122, 432 July 2005. 434 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 435 and D. McPherson, "Dissemination of Flow Specification 436 Rules", RFC 5575, August 2009. 438 Authors' Addresses 440 Pedro Marques 442 Email: pedro.r.marques@gmail.com 444 Luyuan Fang 445 Cisco Systems 446 111 Wood Avenue South 447 Iselin, NJ 08830 449 Email: lufang@cisco.com 451 Ping Pan 452 Infinera Corp 453 140 Caspian Ct. 454 Sunnyvale, CA 94089 456 Email: ppan@infinera.com 458 Amit Shukla 459 Juniper Networks 460 1194 N. Mathilda Av. 461 Sunnyvale, CA 94089 463 Email: amit@juniper.net