<?xml version="1.0" encoding="us-ascii"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.3 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC8402 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml">
<!ENTITY RFC8754 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml">
<!ENTITY I-D.ietf-spring-sr-service-programming SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-sr-service-programming.xml">
<!ENTITY I-D.ietf-spring-srv6-network-programming SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-srv6-network-programming.xml">
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-guichard-spring-srv6-simplified-firewall-02" category="info">

  <front>
    <title abbrev="SRv6 Simplified Firewall">Simplifying Firewall Rules with Network Programming and SRH Metadata</title>

    <author initials="J." surname="Guichard" fullname="James N Guichard" role="editor">
      <organization>Futurewei Technologies Ltd.</organization>
      <address>
        <email>james.n.guichard@futurewei.com</email>
      </address>
    </author>
    <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>cf@cisco.com</email>
      </address>
    </author>
    <author initials="D." surname="Bernier" fullname="Daniel Bernier">
      <organization>Bell Canada</organization>
      <address>
        <email>daniel.bernier@bell.ca</email>
      </address>
    </author>
    <author initials="Z." surname="Li" fullname="Zhenbin Li">
      <organization>Huawei Technologies</organization>
      <address>
        <email>lizhenbin@huawei.com</email>
      </address>
    </author>
    <author initials="F." surname="Clad" fullname="Francois Clad" role="editor">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>fclad@cisco.com</email>
      </address>
    </author>
    <author initials="P." surname="Camarillo" fullname="Pablo Camarillo">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>pcamaril@cisco.com</email>
      </address>
    </author>
    <author initials="A." surname="AbdelSalam" fullname="Ahmed AbdelSalam">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>ahabdels@cisco.com</email>
      </address>
    </author>

    <date year="2020" month="April" day="07"/>

    <area>General</area>
    <workgroup>SPRING</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>A clear application of the SRv6 Network Programming model consists in steering,
in a stateless manner, packets through a Service Function Chain (SFC). Each
Service Function (SF) is identified by a segment. Each SF can enrich its
operation thanks to metadata present in the SRH.</t>

<t>This document describes a practical use-case where the SF is a firewall and the
metadata helps to drastically decrease the number of rules that need to be
maintained by the operation team.</t>



    </abstract>


  </front>

  <middle>


<section anchor="sec-intro" title="Introduction">

<t>The Segment Routing architecture is defined in <xref target="RFC8402"/>.</t>

<t>The IPv6 instantiation of Segment Routing, also known as SRv6, leverages the
Segment Routing Header (SRH) defined in <xref target="RFC8754"/>
to encode a list of segments, as well as some complementary information in an
IPv6 header. <xref target="I-D.ietf-spring-srv6-network-programming"/> builds upon the
base SRv6 definition and introduces the concept of network programming. In a
sense, the list of segments in the SRH is the source code of a network program,
while the SRH TLVs represent the memory of that program.</t>

<t>Furthermore, <xref target="I-D.ietf-spring-sr-service-programming"/> describes how segments
can be associated with Service Functions and defines SRH TLVs specifically
designed for carrying service metadata. Together, these documents define an
integrated solution for underlay, overlay and SFC that uses a single header and
does not require any per-flow state in the network fabric.</t>

</section>
<section anchor="use-case-overview" title="Use-case overview">

<t>In an SR domain, firewall policies are applied to control how the various
endpoints, users or applications are allowed to communicate between each other.
These entities are categorized into classes for the purpose of applying policies
to pools rather than individual entities. For example, the endpoints in Class1
may be allowed to communicate with those in either Class3 or Class4, but Class2
is can only communicate with Class4, and Class5 cannot communicate with any
other class.</t>

<t>A reference diagram is depicted on <xref target="fig-base"/>. An SRv6-enabled network
interconnects 4 classes (Class1..4) and a firewall appliance is in charge of
enforcing the network policies.</t>

<figure title="Base diagram" anchor="fig-base"><artwork><![CDATA[
                 +--------------------------------+
+-------+        |          SRv6 domain           |        +-------+
|Class1 |-+      |                                |      +-|Class3 |
+-------+ | +----+----+     +----------+     +----+----+ | +-------+
          +-| Node A  |     |    F1    |     | Node B  |-+
          +-|(ingress)|-----|(firewall)|-----|(egress) |-+
+-------+ | +----+----+     +----------+     +----+----+ | +-------+
|Class2 |-+      |     --------------------->     |      +-|Class4 |
+-------+        |                                |        +-------+
                 +--------------------------------+
]]></artwork></figure>

<t>Node A is configured to steer the traffic coming from Class1 or Class2 and
headed to Class3 or Class4 into an SRv6 service policy to Node B, via the
firewall F1. As part of the steering process, Node A identifies the source and
destination classes, encapsulates the traffic and attaches an SRH that contains
the SR Policy SID-list, as well as the class information in the SRH TLVs. The
procedure to identify the traffic classes is out of the scope of this document.</t>

<t>Node B is similarly configured to handle flows in the reverse direction.</t>

<t>The firewall F1 reads the SRH TLVs and decides to forward or drop the traffic
based on the combination of the source and destination classes. The availability
of class metadata allows the firewall rule-set size to scale with the number of
valid (source class, destination class) pairs. This drastically simplifies the
firewall configuration and operation compared to a traditional 5-tuple-based
model with tens of thousands of entries.</t>

<t>In <xref target="fig-pkt-pass"/>, a traffic flow from Class1 to Class3 is steered into the
SRv6 Policy <spanx style="verb">&lt;B:F1:A::, B:B:D3::&gt;</spanx>, where <spanx style="verb">B:F1:A::</spanx> represents a service SID
instantiated on the firewall F1 and <spanx style="verb">B:B:D3::</spanx> is an End.DX4 SID on the egress
node B that sends the inner packet to Class3. The SRH <spanx style="verb">S-class</spanx> and <spanx style="verb">D-class</spanx>
TLVs respectively represent the source and destination class identifiers. This
traffic flow is allowed to traverse the firewall and reaches its final
destination in Class3.</t>

<figure title="Traffic flow from Class1 to Class3" anchor="fig-pkt-pass"><artwork><![CDATA[
                 +--------------------------------+
                 |          SRv6 domain           |
                 |                                |
+-------+   +----+----+     +----------+     +----+----+   +-------+
|Class1 |---| Node A  |     |    F1    |     | Node B  |---|Class3 |
+-------+   |(ingress)|-----|(firewall)|-----|(egress) |   +-------+
            +----+----+     +----------+     +----+----+
         -->     |     --------------------->     |     -->
                 |                                |
                 +--------------------------------+

+--------------+ +--------------+  +--------------+ +--------------+
|IP4(10.0.1.12,| |  IP6(A, F1)  |  |  IP6(A, B)   | |IP4(10.0.1.12,|
|    10.3.0.34)| +--------------+  +--------------+ |    10.3.0.34)|
+--------------+ |SRH(B:B:D3::, |  |SRH(B:B:D3::, | +--------------+
                 |B:F1:A::;SL=1;|  |B:F1:A::;SL=0;|
                 |  S-class=Cl1;|  |  S-class=Cl1;|
                 |  D-class=Cl3)|  |  D-class=Cl3)|
                 +--------------+  +--------------+
                 |IP4(10.0.1.12,|  |IP4(10.0.1.12,|
                 |    10.3.0.34)|  |    10.3.0.34)|
                 +--------------+  +--------------+
]]></artwork></figure>

<t>In <xref target="fig-pkt-drop"/>, a traffic flow from Class2 to Class3 is steered into the
exact same SRv6 Policy <spanx style="verb">&lt;B:F1:A::, B:B:D3::&gt;</spanx>. The SRH <spanx style="verb">S-class</spanx> and <spanx style="verb">D-class</spanx>
TLVs are similarly populated with the source and destination class identifiers.
However, <spanx style="verb">S-class=Cl2</spanx> and <spanx style="verb">D-class=Cl3</spanx> does not match an authorized class
combination on the firewall. The traffic is considered as invalid and dropped at
F1.</t>

<figure title="Traffic flow from Class2 to Class3" anchor="fig-pkt-drop"><artwork><![CDATA[
                 +--------------------------------+
                 |          SRv6 domain           |
                 |                                |
+-------+   +----+----+     +----------+     +----+----+   +-------+
|Class2 |---| Node A  |     |    F1    |     | Node B  |---|Class3 |
+-------+   |(ingress)|-----|(firewall)|-----|(egress) |   +-------+
            +----+----+     +----------+     +----+----+
         -->     |     --------> X                |
                 |                                |
                 +--------------------------------+

+--------------+ +--------------+
|IP4(10.0.1.12,| |  IP6(A, F1)  |
|    10.3.0.34)| +--------------+
+--------------+ |SRH(B:B:D3::, |
                 |B:F1:A::;SL=1;|
                 |  S-class=Cl2;|
                 |  D-class=Cl3)|
                 +--------------+
                 |IP4(10.0.1.12,|
                 |    10.3.0.34)|
                 +--------------+
]]></artwork></figure>

</section>
<section anchor="demo-availability" title="Demo availability">

<t>A working demo is available, using FD.io VPP <xref target="FDio"/> instances as ingress and
egress routers and the iptables-based SERA firewall <xref target="SERA"/>.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>To be updated.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>To be updated.</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>To be updated.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC8402;
&RFC8754;


    </references>

    <references title='Informative References'>

&I-D.ietf-spring-sr-service-programming;
&I-D.ietf-spring-srv6-network-programming;
<reference anchor="FDio" target="https://fd.io">
  <front>
    <title>The Fast Data Project</title>
    <author >
      <organization></organization>
    </author>
    <date year="2018"/>
  </front>
  <seriesInfo name="The Linux Foundation" value=""/>
</reference>
<reference anchor="SERA" >
  <front>
    <title>SERA: SEgment Routing Aware Firewall for Service Function Chaining scenarios</title>
    <author initials="A." surname="Abdelsalam">
      <organization></organization>
    </author>
    <author initials="S." surname="Salsano">
      <organization></organization>
    </author>
    <author initials="F." surname="Clad">
      <organization></organization>
    </author>
    <author initials="P." surname="Camarillo">
      <organization></organization>
    </author>
    <author initials="C." surname="Filsfils">
      <organization></organization>
    </author>
    <date year="2018" month="May"/>
  </front>
  <seriesInfo name="IFIP Networking" value=""/>
</reference>


    </references>



  </back>

<!-- ##markdown-source:
H4sIADU6jF4AA+1aa2/bOBb9zl9BtF8SxNIkadqddbdFnaRuM+gUQdwdDGax
QGiJtjmVRC0pOePG2d++55J62m6SFrNfFhugic3HvZf3ce6h1CAIWKGKRA75
RKV5omYrlc35WBl5I5KEX5WJtPxGFQv+URY32nzml0bPjUhTWieymE+u3vOf
ZSFiUQgmplMjlxB2tXxRS1QybgSyWEeZSKEuNmJWBPNSRQth4sDmBgIDa5Yv
AtvsC2bVvuDwmEGBHLIIv+farIZcZTPNmMrNkBemtMXx4eFfsUwYKYb8ncyk
EQkjk+dGlzlsury6+PiOfZYrDMZDfpEV0mSyCM7JFMYiHcOEIS9tIGykFMvV
kP+j0NGAW20KI2cWn1YpffgnY6IsFtoMGQ8Yhy12yH8K+bvqPBjyx/wJvy3/
2J3QZi4y9UUUSmdDPi6LEmeUin+S0SLTiZ4r7PhQxCHWGk2hkbEqtMFXmQqV
DPnvJDTMwtp7b2a1kDDSaceisxCeT+wM/xqLzhJ4KItkd6Zv0pmykeaTlS1k
iiNfZFHY6o5mbyKa39B0HvJTeFNJ0yg6h0iZdIb7Wk4l8utMZEicVnrs9oRT
v+fNFGvCSHT0/BbyD6pR8dtCZlOV+aG++Pel2HRqqyZRX/zONwu3bOMw45C8
1AZxbEQWaWXr0ce4a3fkZhEk7HTgJXSKVBiVJLpRfCmmie6Nf0Ok8sjv26lu
FPLRNJbJRCQibfSNFimKtTfxDQrFQtBO21HIMm1S7F2icjm/Gp/9eHJ4XH/8
y/OTIQoYZdxZcxGch0oWsxYRAivNUkUyyFvk2b0S2JF5lNpcOz5Xmv5yXqHd
pwUKQNgCWVoIwrTfZVS4BdCGXCGr/KoPKiv/4GNdZrFzgpcizFwWQ74oitwO
f/hhFodKuxmHUvz48OhHfJ28vRr11D5xIxifpzIr+JUuC8LR0Q1qskVdOIRP
/KGBD1lEavnZQqiMFttIZoirtk+c5AaHqp+gH2BbxbE3OQk54mtFpjdn2tTv
DW9kZ2+uDzJ9B16MLy7rzgHbOx76Way8l1gQBFxMbWEEIsBGPEqkMFzk6AGR
8zjXM14gEq6p7GpDqcZBeaQzq2xhYRVHfkpKigHSiwt8hU50MstTkaExDHgu
os8Sa4sFmsN8gTW7Hc73JuOz/ZC/FdGCbS3B5D4HLqgY0fSdbroifdLF12/j
kzGPRMZlZgDXXBWW6RzNyUkoFiL7DDM0T6seynMjLSWHyqpTvw8Z+7SAGjTP
0uVNLG1k1BR9gpbDb/BUgsYlg0hYyW8WEunkNo/JPMHrPuo6NiZYo20hk9zp
R0O2Tk6ygvwIXdR6GVmZAo8pCMaxAZhc8EzirNg1hSi4qcA/f3ja0TmeFGno
Q5yqOE4kY0+p8Rodl96Ft0+tjAJFQ3d0TNgs+8UhTLRQBcoTLY5OE8uZUwb/
3N5WkHJ3F/rNF5fIEaRlIRCQJns2RA44kl/zz5m+QXZYl1gDnsglzJ67E0q2
acV7KWJ4YQ/h2N82AVB2d8fgD3RWJCM8niAVSXWVCgBLKLqhnoe/VqcS+Qqa
I2lSmBVvYBAWU85mzB1l4dSGUPNYuLu749NSJbHlZe4STLIphdJVjzNcOSWU
CaqKhD8zVVAkc2d2JZh3BIcIHBcMuWnlwK3fPGMnZSlQ9NHq0kQkGU7BSrEp
eMBuFiqRzbZPH36x3Mi6Bmg4lSn4ngcBZF61EfEelwbzBrOwZ5eDdnUOuKet
noW+aYxnVKNThM5aHSF1EF7HezeL3jrP+Qywrc02lxEQwNUPgwY1pwQhJI+E
MY5VV9Y0lR7yTxpdZEF4hN+IUV3gdZJTGiBGEsaTPVYnpYsdiUU/kiYRqwHX
S/fBs/HxmXcTwIAKHzg8h3t9GtEKMHBMZLqAl/9VAhYwuOIo2GCWkDcIKes4
1rGaiSmgK6Ta/XuNMaR0qeQNY5QVGRwB6wkKBi3Y5BoQTmyWupsDdA8ayDPk
XeLcT3qW1M5Ky2QW51q5YoH5xoJ8dPtAJQct6KaWk6ZlRrMSkStupATKEuJq
cmpIgABLCZqL2orq+qC+uOolGQkCjklyKdmSlybX1icrVLvA1eegAs+1TpCh
gjQ49IaYWC1VXAKBa1XoiBAn/xBU4b5WmrORc89I6RGQc+UybveJXPaht1sX
D6mcRrfzGTnGfToZoNgL//mYoeYoiXUGCN+SVK+nLHGfn9NiSoStpcgI5lzo
vRNSV8atR/p7Q6wEFZOH4lxFlJkE5LczNQ8IagDGfJQ5wAlAVaYJFlSp5LLZ
IP4Z8Nzyk8b9e94lYXiy7yzstizKAEGalXMeXXnmFCDkC6IWUYS62VpHC2b/
++s/DYtpfg6CB34OWL3koN6zbrd7fHUl0BG63pR+wNb+qHxdi+kI2f2zrkWs
q/CvO5asveiD1q7OQToDB73lzpLu2df8I2H0qNbmfo+PWvXVglNOhve37iEE
AGy7v3aC13t17JoB6efd1j/FdO+J400n7ozb611OPOk5cTuc90aC73TixtQ9
eXRfXt4O+dO6kvy14dWTU/pc1d0T0KQqVFTvOsNiMCMHH472umIAm56hG1Ft
U33MjE4r1Gmw49i1A9cZ3OZNaPH4KHwhN83LVdeK1vt0GPClEo5lNAU7PkL9
W1BsU9TUvebj1L3BNgDw9RFq5tyjC65PSdDRzBOiCiUGRK9EbssEUGV753SY
URQAfwL6zPVl1wep16Akgd2OYfBLb//k4jwg+tKjZY4DkapNNtZlJyHdCpk7
R0yMFJ6oDrHqe75CNgQJFLJxRARy7L90CH1YhfSUVluVqkQYh+Hd4KLXgEBz
atMN0zLEWV1uGOnYSUWDO7HAGhHbPsHyDCaC3Y7646y4gMYU+tjovHsMxx0d
vnuCmE7rmNQHaiLGd0TMOYuLpcCJpipRBRrLrPJxcwVx/c9b2NhNVw3QtwLe
+OJ8bMGsmp7YuZSwpUhUzPdqokmiB9um7CMdlXH2kN87d53maaPtZ3HtfNGw
5fZaQ9RdVGER5KrYcWowgOdBUaLnu+qNmb+YeqNBm73PwHQgzX1B6I3vVBd1
A80/F0EOg+/uBl60SybHzbpF3NYrZQxVV01o3OWFKrbK9Ou/nQ7HR8PRcDjg
p8PT4fmz4fD19aC6JF7Xk9ct63a8sSp31Alrr1NtJnQTjHxzXYu+dhfOjL/N
4vD81xMSUO/xTYBlPtNddUJdlZuK7uXVtbw9nc8fytvrSeACee3VnVffWHVh
IPpNj5AQ0P7t4b78bNGnzgzWczidpOVmmPLF1js/CTbS4w6u9phAGvTAq+Z7
z/4LhOTrDeqrhOTePV/per1O+U09ezfxCb6NbgQ7iQ9mvoF4fLVnf8tx2o19
VrEzOv0Fr7/L71tDj8gJtrHmYHPTwZaY7SVsfXF5snd0GB6GR+HR8WBN1l5c
vtgbDRCmfWd8O3K6746zuYe5E2LgGYaeneyvH2PJ5p7t46yBB3s13gycJZsj
W8fZ9m0NfC8nH14dvVxvjBy+3F0oFQq9Okv8no2RnXvOmxXP9tfbIw8GeYeX
dujZjNd2NHbZ1g/PtvO/x7bHsNu6zdUM99ODjY54b69LElW5t0seP9AlcT+P
0IJEWj0cu7dhPrIT0TOGlsDlOndcNW6Jy6P7EXuPxrOkZ0PXbYod95VSAl3z
5okOCGtEt/fqnYB7yOHWsR5x63dwf7Dahf5KYWEIuUoQ0fQEyxkMj+c0XDBw
/P93s+oG+r/azV7zX7d99z3+3hr6U7rYwy3q4f7zcHN5uHM80CeOH9MVHsbZ
hxH/YXx/hJbHYre/J96L3cd97GZP+blMdf8yyEa8ejUINMQkMW4/T89NS+v+
M8p5qDT/5fIS2E/vce/uqhc89NrCIZSrCvfQwBcIN7hx0/Pj6m0XV3lBEq2/
lrnXsi2Dv72l7+4N0lN+Mfo44mcVAvqnzrhR03suXub05jJ2yyYyKg0O8Iil
o4jeMyUynkv/nmFrzX8AFi4E6YUjAAA=

-->

</rfc>

