<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" docName="draft-lin-opsec-trustroute-problem-statement-01" category="info">
    <?rfc toc="yes"?>
    <?rfc sortrefs="yes"?>
    <front>
        <title abbrev="Trustworthiness Routing Problem Statement">
            Problem Statement and Use Cases of Trustworthiness-based Routing
        </title>

        <author initials="T." surname="Lin" fullname="Tao Lin">
            <organization>H3C</organization>
            <address>
                <email>lintao@h3c.com</email>
            </address>
        </author>

        <author initials="H." surname="Li" fullname="Hao Li">
            <organization>H3C</organization>
            <address>
                <email>lihao@h3c.com</email>
            </address>
        </author>

        <author initials="X." surname="Shi" fullname="Xingang Shi">
            <organization>Tsinghua University</organization>
            <address>
                <email>shixg@cernet.edu.cn</email>
            </address>
        </author>

        <author initials="X." surname="Yin" fullname="Xia Yin">
            <organization>Tsinghua University</organization>
            <address>
                <email>yxia@tsinghua.edu.cn</email>
            </address>
        </author>

        <author initials="W." surname="Chen" fullname="Wenlong Chen">
            <organization>Capital Normal University</organization>
            <address>
                <email>chenwenlong@cnu.edu.cn</email>
            </address>
        </author>

        <date month="December" day="14" year="2021" />

        <area>General</area>
        <workgroup>Network Working Group</workgroup>
        <keyword>Routing</keyword>
        <keyword>Trustworthiness</keyword>
        <abstract>
            <t>Currently, network operators are trying to provide fine-granularity Service Level Agreement (SLA) guarantee to achieve better Quality of Experience (QoE) for end users and engage customers, such as ultra-low latency and high reliability service. However, with increasing security threats, differentiated QoE services are insufficient, the demands for more differentiated security service are emerging.</t>
            <t>This document explores the requirements for differentiated security services and identifies the scenarios for network operators. To provide differentiated security services, possible trustworthiness-based routing solution is discussed.</t>
        </abstract>
    </front>

    <middle>
        <section title="Introduction" toc="include">
            <t>For the traditional best effort service provided by IP networks, routing is optimized for a single arbitrary metric, e.g. IGP cost in OSPF and IS-IS. To support differentiated services, additional routing metrics are used, such as bandwidth, jitter and delay. However, security metrics and methods of corresponding treatment are seldom taken into considerations.</t>
            <t>Customers may request the network to transfer their traffic flows with different security guarantees. Or the provider may classify traffic flows into different classes by security-related features. These traffic flows of different security service classes are expected to be transmitted by different sets of nodes, because the trustworthiness of different nodes is possibly not the same. The traffic flows which have higher security requests are expected to be transmitted by the nodes with higher trustworthiness. Trustworthiness is used as a security metric to evaluate the qualification of network elements for differentiated security services.</t>
            <t>This document describes the requirements and use cases of trustworthiness-based routing.</t>
        </section>

        <section title="Terminology" toc="include">
            <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and only when, they appear in all capitals, as shown here.</t>
            <t>Trustworthiness: The attribute of a network element used to evaluate its qualification for security services.</t>
        </section>

        <section title="Problem Statement" toc="default">
            <t>With more and more security incidents occur repeatedly, security continues to be an increasingly important common concern for network users and network operators. Good connectivity is insufficient, higher and higher requirements for network security are emerging. From different perspectives of operators and end users, there will be different needs. On the one hand, end users require network operators to ensure network security, on the other hand, network operators need to prevent the intrusion and attack from malicious users. Two following use cases are described:</t>

            <section title="Use Case 1: Customers Require Security Service" toc="default">
                <t>From the perspective of end users, different users may have different security level requirements. Some users are sensitive to security and would like the network path given by the operator to have higher security. The network path is composed by many network forwarding devices, and the trustworthiness of each device affects the trustworthiness of the whole path. These network forwarding devices come from different vendors, have different security capabilities, and may have different security status at a certain time. Therefore, operators need to evaluate the trustworthiness of network forwarding devices, and choose different security level paths for users with different security requirements.</t>
                <figure>
                    <artwork>
                +--------+    ##########    +--------+
Customer 1 --+--| node 1 |----# node 2 #----| node 3 |--- App Server
             |  +--------+    ##########    +--------+
Customer 2 --+       |             |             |
                     |             |             |
                +--------+    +--------+    +--------+
                | node 4 |----| node 5 |----| node 6 |
                +--------+    +--------+    +--------+
                    </artwork>
                </figure>
                <t>In the above network, node 1, node 3, node 4, node 5 and node 6 have advanced anti-hacker modules, but node 2 does not have such module. Two customers at node 1 both need to visit the application server at node 3. Customer 1 requests normal service. Customer 2 needs to transmit confidential information and requests the network to provide secure service.</t>
                <t>For the packets from Customer 1, the shortest path &lt;node 1, node 2, node 3&gt; is used. For the packets from Customer 2, the path only contains the nodes with advanced anti-hacker modules, which can reduce the risk of manipulation or disclosure. Therefore, node 2 is excluded and the best path is &lt;node 1, node 4, node 5, node 6, node 3&gt;. </t>
            </section>

            <section title="Use Case 2: Providers Require Secure defense" toc="default">
                <t>For network operators, different users have different levels of trustworthiness. Most users are normal and harmless, but there are also a small number of users suspected of threatening network security. Therefore, for users with threats, operators may consider choosing paths with different security levels.</t>
                <figure>
                    <artwork>
Traffic Flow 1
&lt;Src A, Dest B>-+   +--------+    ##########    +--------+  +- Addr B
                +-->| node 1 |----# node 2 #----| node 3 |--+
Traffic Flow 2 -+   +--------+    ##########    +--------+  +- Addr D
&lt;Src C, Dest D>          |             |             |
                         |             |             |
                    +--------+    +--------+    +--------+
                    | node 4 |----| node 5 |----| node 6 |
                    +--------+    +--------+    +--------+
                    </artwork>
                </figure>
                <t>In the above network, node 1, node 3, node 4, node 5 and node 6 have tracing modules which can record attacking packets, but node 2 does not have such module. Two traffic flows enter the network at node 1 and need to be transmitted to node 3. A and B are authenticated addresses, but C or D is not. The traffic flow which comes from an authenticated address and goes to another authenticated address is classified by the provider as a credible flow.  Therefore, Traffic Flow 1 is classified as credible, and Traffic Flow 2 is classified as incredible. For Traffic Flow 1, the shortest path &lt;node 1, node 2, node 3&gt; is used. For Traffic Flow 2, the packets are transmitted by the nodes with tracing modules. If there are attacking packets in Traffic Flow 2, these packets will be recorded and may be analyzed to trace the attacker. Therefore, node 2 is excluded and the best path is &lt;node 1, node 4, node 5, node 6, node 3&gt;.</t>
            </section>
        </section>

        <section title="Solution Discussions" toc="default">
            <t>To provide differentiated security services, specific traffic flows should be identified by the network. For example, the IPv4 TOS field, the IPv6 Traffic Class field, or the 5-tuple in the IP and transport protocol header of a packet can be used to determine its security service class. </t>
            <t>For the traditional best effort service, routing is optimized for a single arbitrary metric, e.g. IGP cost in OSPF and IS-IS. To support differentiated services, additional routing metrics are used, such as bandwidth, jitter and delay.</t>
            <t>Trustworthiness is an attribute of a network element which is used as a security metric to evaluate its qualification for differentiated security services. Trustworthiness attributes may be taken into consideration of device capability, administration authority, security protocol, etc. </t>
            <t>When computing paths for differentiated security services, trustworthiness attributes are added into the constraints. Then particular traffic flows are steered into these paths. There are several existing technologies that can steer traffic over a path that is computed using different constraints instead of the shortest IGP path. They may be extended to implement trustworthiness-based routing. For example, Segment Routing Policy, as defined in <xref target="I-D.ietf-idr-segment-routing-te-policy"></xref>, enables the instantiation of an ordered list of segments on a node for implementing a source routing policy with a specific intent for traffic steering from that node. For another example, Flexible Algorithm, as defined in <xref target="I-D.ietf-lsr-flex-algo"></xref>, provides a mechanism for IGP to compute constraint-based paths under a combination of calculation-type, metric-type, and constraints. Other technologies, such as multi-topology routing, may also be candidates. Because of the flexibility of these technologies, they can adapt to different perspectives and needs from end users and network operators.</t>
        </section>

        <section title="Security Considerations">
            <t>TBD.</t>
        </section>

        <section title="IANA Considerations">
            <t>No IANA action is required so far.</t>
        </section>

        <section title="Contributors" toc="default">
            <t>In addition to the authors listed on the front page, the following co-authors have also contributed to this document:</t>
             <figure>
                    <artwork>
Mengxiao Chen
H3C

Email: chen.mengxiao@h3c.com


Xiangqing Chang
H3C

Email: chang.xiangqing@h3c.com
                    </artwork>
            </figure>
        </section>
    </middle>

    <back>
        <references title="Normative References">
            <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
                <front>
                <title>
                Key words for use in RFCs to Indicate Requirement Levels
                </title>
                <author initials="S." surname="Bradner" fullname="S. Bradner">
                <organization/>
                </author>
                <date year="1997" month="March"/>
                <abstract>
                <t>
                In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
                </t>
                </abstract>
                </front>
                <seriesInfo name="BCP" value="14"/>
                <seriesInfo name="RFC" value="2119"/>
                <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            </reference>
            <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
                <front>
                <title>
                Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
                </title>
                <author initials="B." surname="Leiba" fullname="B. Leiba">
                <organization/>
                </author>
                <date year="2017" month="May"/>
                <abstract>
                <t>
                RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
                </t>
                </abstract>
                </front>
                <seriesInfo name="BCP" value="14"/>
                <seriesInfo name="RFC" value="8174"/>
                <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            </reference>
        </references>
            
        <references title="Informative References">
            <reference anchor="I-D.ietf-idr-segment-routing-te-policy">
                <front>
                    <title>Advertising Segment Routing Policies in BGP</title>
                    <author initials="S" surname="Previdi" fullname="Stefano Previdi">
                    <organization/>
                    </author>
                    <author initials="C" surname="Filsfils" fullname="Clarence Filsfils">
                    <organization/>
                    </author>
                    <author initials="K" surname="Talaulikar" fullname="Ketan Talaulikar">
                    <organization/>
                    </author>
                    <author initials="P" surname="Mattes" fullname="Paul Mattes">
                    <organization/>
                    </author>
                    <author initials="D" surname="Jain" fullname="Dhanendra Jain">
                    <organization/>
                    </author>
                    <author initials="S" surname="Lin" fullname="Steven Lin">
                    <organization/>
                    </author>
                    <date year="2021" month="November" day="10"/>
                    <abstract>
                    <t>This document defines a new BGP SAFI with a new NLRI in order to advertise a candidate path of a Segment Routing (SR) Policy. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. The headend of an SR Policy may learn multiple candidate paths for an SR Policy. Candidate paths may be learned via a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document specifies the way in which BGP may be used to distribute SR Policy candidate paths. New sub-TLVs for the Tunnel Encapsulation Attribute are defined for signaling information about these candidate paths.</t>
                    </abstract>
                </front>
                <seriesInfo name="Internet-Draft" value="draft-ietf-idr-segment-routing-te-policy-14"/>
                <format type="TXT" target="https://www.ietf.org/internet-drafts/draft-ietf-idr-segment-routing-te-policy-14.txt"/>
            </reference>
            <reference anchor="I-D.ietf-lsr-flex-algo">
                <front>
                <title>IGP Flexible Algorithm</title>
                <author initials="P" surname="Psenak" fullname="Peter Psenak">
                <organization/>
                </author>
                <author initials="S" surname="Hegde" fullname="Shraddha Hegde">
                <organization/>
                </author>
                <author initials="C" surname="Filsfils" fullname="Clarence Filsfils">
                <organization/>
                </author>
                <author initials="K" surname="Talaulikar" fullname="Ketan Talaulikar">
                <organization/>
                </author>
                <author initials="A" surname="Gulko" fullname="Arkadiy Gulko">
                <organization/>
                </author>
                <date month="October" day="25" year="2021"/>
                <abstract>
                <t>IGP protocols traditionally compute best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE based or Segment Routing based Traffic Engineering to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document proposes a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths.</t>
                </abstract>
                </front>
                <seriesInfo name="Internet-Draft" value="draft-ietf-lsr-flex-algo-18"/>
                <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-lsr-flex-algo-18.txt"/>
            </reference>
        </references>

    </back>
</rfc>