idnits 2.17.1 draft-guichard-spring-srv6-simplified-firewall-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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 25, 2019) is 1859 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 == Outdated reference: A later version (-02) exists of draft-xuclad-spring-sr-service-programming-01 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING J. Guichard, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational C. Filsfils 5 Expires: September 26, 2019 Cisco Systems, Inc. 6 D. Bernier 7 Bell Canada 8 Z. Li 9 Huawei Technologies 10 F. Clad, Ed. 11 P. Camarillo 12 A. AbdelSalam 13 Cisco Systems, Inc. 14 March 25, 2019 16 Simplifying Firewall Rules with Network Programming and SRH Metadata 17 draft-guichard-spring-srv6-simplified-firewall-00 19 Abstract 21 A clear application of the SRv6 Network Programming model consists in 22 steering, in a stateless manner, packets through a Service Function 23 Chain (SFC). Each Service Function (SF) is identified by a segment. 24 Each SF can enrich its operation thanks to metadata present in the 25 SRH. 27 This document describes a practical use-case where the SF is a 28 firewall and the metadata helps to drastically decrease the number of 29 rules that need to be maintained by the operation team. 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 https://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 September 26, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Use-case overview . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Demo availability . . . . . . . . . . . . . . . . . . . . . . 5 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 7.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 76 1. Introduction 78 The Segment Routing architecture is defined in [RFC8402]. 80 The IPv6 instantiation of Segment Routing, also known as SRv6, 81 leverages the Segment Routing Header (SRH) defined in 82 [I-D.ietf-6man-segment-routing-header] to encode a list of segments, 83 as well as some complementary information in an IPv6 header. 84 [I-D.filsfils-spring-srv6-network-programming] builds upon the base 85 SRv6 definition and introduces the concept of network programming. 86 In a sense, the list of segments in the SRH is the source code of a 87 network program, while the SRH TLVs represent the memory of that 88 program. 90 Furthermore, [I-D.xuclad-spring-sr-service-programming] describes how 91 segments can be associated with Service Functions and defines SRH 92 TLVs specifically designed for carrying service metadata. Together, 93 these documents define an integrated solution for underlay, overlay 94 and SFC that uses a single header and does not require any per-flow 95 state in the network fabric. 97 2. Use-case overview 99 In an SR domain, firewall policies are applied to control how the 100 various endpoints, users or applications are allowed to communicate 101 between each other. These entities are categorized into classes for 102 the purpose of applying policies to pools rather than individual 103 entities. For example, the endpoints in Class1 may be allowed to 104 communicate with those in either Class3 or Class4, but Class2 is can 105 only communicate with Class4, and Class5 cannot communicate with any 106 other class. 108 A reference diagram is depicted on Figure 1. An SRv6-enabled network 109 interconnects 4 classes (Class1..4) and a firewall appliance is in 110 charge of enforcing the network policies. 112 +--------------------------------+ 113 +-------+ | SRv6 domain | +-------+ 114 |Class1 |-+ | | +-|Class3 | 115 +-------+ | +----+----+ +----------+ +----+----+ | +-------+ 116 +-| Node A | | F1 | | Node B |-+ 117 +-|(ingress)|-----|(firewall)|-----|(egress) |-+ 118 +-------+ | +----+----+ +----------+ +----+----+ | +-------+ 119 |Class2 |-+ | ---------------------> | +-|Class4 | 120 +-------+ | | +-------+ 121 +--------------------------------+ 123 Figure 1: Base diagram 125 Node A is configured to steer the traffic coming from Class1 or 126 Class2 and headed to Class3 or Class4 into an SRv6 service policy to 127 Node B, via the firewall F1. As part of the steering process, Node A 128 identifies the source and destination classes, encapsulates the 129 traffic and attaches an SRH that contains the SR Policy SID-list, as 130 well as the class information in the SRH TLVs. The procedure to 131 identify the traffic classes is out of the scope of this document. 133 Node B is similarly configured to handle flows in the reverse 134 direction. 136 The firewall F1 reads the SRH TLVs and decides to forward or drop the 137 traffic based on the combination of the source and destination 138 classes. The availability of class metadata allows the firewall 139 rule-set size to scale with the number of valid (source class, 140 destination class) pairs. This drastically simplifies the firewall 141 configuration and operation compared to a traditional 5-tuple-based 142 model with tens of thousands of entries. 144 In Figure 2, a traffic flow from Class1 to Class3 is steered into the 145 SRv6 Policy "", where "B:F1:A::" represents a 146 service SID instantiated on the firewall F1 and "B:B:D3::" is an 147 End.DX4 SID on the egress node B that sends the inner packet to 148 Class3. The SRH "S-class" and "D-class" TLVs respectively represent 149 the source and destination class identifiers. This traffic flow is 150 allowed to traverse the firewall and reaches its final destination in 151 Class3. 153 +--------------------------------+ 154 | SRv6 domain | 155 | | 156 +-------+ +----+----+ +----------+ +----+----+ +-------+ 157 |Class1 |---| Node A | | F1 | | Node B |---|Class3 | 158 +-------+ |(ingress)|-----|(firewall)|-----|(egress) | +-------+ 159 +----+----+ +----------+ +----+----+ 160 --> | ---------------------> | --> 161 | | 162 +--------------------------------+ 164 +--------------+ +--------------+ +--------------+ +--------------+ 165 |IP4(10.0.1.12,| | IP6(A, F1) | | IP6(A, B) | |IP4(10.0.1.12,| 166 | 10.3.0.34)| +--------------+ +--------------+ | 10.3.0.34)| 167 +--------------+ |SRH(B:B:D3::, | |SRH(B:B:D3::, | +--------------+ 168 |B:F1:A::;SL=1;| |B:F1:A::;SL=0;| 169 | S-class=Cl1;| | S-class=Cl1;| 170 | D-class=Cl3)| | D-class=Cl3)| 171 +--------------+ +--------------+ 172 |IP4(10.0.1.12,| |IP4(10.0.1.12,| 173 | 10.3.0.34)| | 10.3.0.34)| 174 +--------------+ +--------------+ 176 Figure 2: Traffic flow from Class1 to Class3 178 In Figure 3, a traffic flow from Class2 to Class3 is steered into the 179 exact same SRv6 Policy "". The SRH "S-class" and 180 "D-class" TLVs are similarly populated with the source and 181 destination class identifiers. However, "S-class=Cl2" and 182 "D-class=Cl3" does not match an authorized class combination on the 183 firewall. The traffic is considered as invalid and dropped at F1. 185 +--------------------------------+ 186 | SRv6 domain | 187 | | 188 +-------+ +----+----+ +----------+ +----+----+ +-------+ 189 |Class2 |---| Node A | | F1 | | Node B |---|Class3 | 190 +-------+ |(ingress)|-----|(firewall)|-----|(egress) | +-------+ 191 +----+----+ +----------+ +----+----+ 192 --> | --------> X | 193 | | 194 +--------------------------------+ 196 +--------------+ +--------------+ 197 |IP4(10.0.1.12,| | IP6(A, F1) | 198 | 10.3.0.34)| +--------------+ 199 +--------------+ |SRH(B:B:D3::, | 200 |B:F1:A::;SL=1;| 201 | S-class=Cl2;| 202 | D-class=Cl3)| 203 +--------------+ 204 |IP4(10.0.1.12,| 205 | 10.3.0.34)| 206 +--------------+ 208 Figure 3: Traffic flow from Class2 to Class3 210 3. Demo availability 212 A working demo is available, using FD.io VPP [FDio] instances as 213 ingress and egress routers and the iptables-based SERA firewall 214 [SERA]. 216 4. IANA Considerations 218 To be updated. 220 5. Security Considerations 222 To be updated. 224 6. Acknowledgements 226 To be updated. 228 7. References 229 7.1. Normative References 231 [I-D.ietf-6man-segment-routing-header] 232 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 233 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 234 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 235 progress), February 2019. 237 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 238 Decraene, B., Litkowski, S., and R. Shakir, "Segment 239 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 240 July 2018, . 242 7.2. Informative References 244 [FDio] "The Fast Data Project", The Linux Foundation , 2018, 245 . 247 [I-D.filsfils-spring-srv6-network-programming] 248 Filsfils, C., Camarillo, P., Leddy, J., 249 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 250 Network Programming", draft-filsfils-spring-srv6-network- 251 programming-07 (work in progress), February 2019. 253 [I-D.xuclad-spring-sr-service-programming] 254 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 255 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 256 Henderickx, W., and S. Salsano, "Service Programming with 257 Segment Routing", draft-xuclad-spring-sr-service- 258 programming-01 (work in progress), October 2018. 260 [SERA] Abdelsalam, A., Salsano, S., Clad, F., Camarillo, P., and 261 C. Filsfils, "SERA: SEgment Routing Aware Firewall for 262 Service Function Chaining scenarios", IFIP Networking , 263 May 2018. 265 Authors' Addresses 267 James N Guichard (editor) 268 Huawei 270 Email: james.n.guichard@huawei.com 272 Clarence Filsfils 273 Cisco Systems, Inc. 275 Email: cf@cisco.com 276 Daniel Bernier 277 Bell Canada 279 Email: daniel.bernier@bell.ca 281 Zhenbin Li 282 Huawei Technologies 284 Email: lizhenbin@huawei.com 286 Francois Clad (editor) 287 Cisco Systems, Inc. 289 Email: fclad@cisco.com 291 Pablo Camarillo 292 Cisco Systems, Inc. 294 Email: pcamaril@cisco.com 296 Ahmed AbdelSalam 297 Cisco Systems, Inc. 299 Email: ahabdels@cisco.com