<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.6 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-chen-secure-path-architecture-01" category="info" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.20.0 -->
  <front>
    <title abbrev="archi-SR">the architecture for secure routing</title>
    <seriesInfo name="Internet-Draft" value="draft-chen-secure-path-architecture-01"/>
    <author initials="" surname="Chen" fullname="Meiling Chen" role="editor">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <city>BeiJing</city>
          <country>China</country>
        </postal>
        <email>chenmeiling@chinamobile.com</email>
      </address>
    </author>
    <author initials="L." surname="Su" fullname="Li Su">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <city>BeiJing</city>
          <country>China</country>
        </postal>
        <email>suli@chinamobile.com</email>
      </address>
    </author>
    <date year="2024" month="March" day="04"/>
    <area>Security</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>keyword2</keyword>
    <abstract>
      <?line 34?>

<t>Some users need to choose nodes that meet security requirements to form secure routing and ensure that traffic can defend against dynamic attacks during path forwarding.</t>
      <t>In this architecture, there are four roles defined: attester, authorizer, controller and secfunction, the interaction of these four roles can achieve the selection of secure routing and security services. The purpose of this architecture is to secure the routing, including node static security assessment, dynamic security defense, and routing path and security service consistency validation.</t>
    </abstract>
  </front>
  <middle>
    <?line 40?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>In the early stages of internet development, users' demand for the network was that access everywhere, but now users demand is to securely connect to everywhere. For security requirements are becoming increasingly evident, this includes both user privacy and security requirements as well as business security requirements.</t>
      <t>How to implement secure paths has become a new research direction. To meet users' needs for secure path, at least the following three parts need to be included.</t>
      <t>1.Security of static nodes: the trustworthy of nodes in the routing path need to be evaluated;</t>
      <t>2.Routing path defense security: this requires the ability to resist attacks at the routing level, in terms of implementation, it is required that ISPs can match security defense capabilities during routing scheduling;</t>
      <t>3.Secure path Validation: on the premise that a secure path has been formed, ensure that user traffic is indeed forwarded according to the pre-formed path.</t>
      <t>Therefore, this draft attempts to propose an architecture for secure routing.</t>
    </section>
    <section anchor="secure-routing-architecture">
      <name>Secure routing architecture</name>
      <t>There are four roles in the secure path architecture, Attester can report the security information to the contoller through the authorizer, the authorizer is responsible for verifing the authenticity of the information. The controller matches the user's requirements based on the obtained information to form a secure routing strategy, how to match user requirements is out of scope. Then forward data for users along secure paths and provide secure service capabilities. Finally, the authorizer verifies whether the forwarding path is consistent with the issued routing policy and whether the security capability is truly provided.</t>
      <artwork><![CDATA[
              +-----------+
    +---------+ Authorizer+---------+
    |         +-----------+         |
    |                               |
+---+------+                  +-----+------+
| Attester +------------------+ Controller |
+---+------+                  +-----+------+
    |                               |
    |          +------------+       |
    +----------+SecFunction +-------+
               +------------+
 
Figure 1: Basic secure path architecture
]]></artwork>
      <section anchor="components">
        <name>Components</name>
        <section anchor="attester">
          <name>Attester</name>
          <t>In Remote ATtestation procedureS (RATS), one peer (the "Attester") produces believable information about itself ("Evidence") to enable a remote peer (the "Relying Party") to decide whether or not to consider that Attester a trustworthy peer, but in secure path attester produces evidence of secure boot and information of usable security capabilities to enable the controller to select secure nodes to form routing paths.</t>
        </section>
        <section anchor="controller">
          <name>Controller</name>
          <t>The controller actually contains two functions, one is orchestration and the other is control. The controller can obtain information from all nodes in the network, implement network programming to form forwarding path policies, and distribute the policies to the forwarding nodes.</t>
          <artwork><![CDATA[
                |         |                                            
                |         |                                            
           User's        User's                                        
           Network       Security                                      
           Requirements  Requirments                                   
                |         |                                            
                v         v                                            
             +------------------+                  +------------------+
 Devices'    |                  | Path and Security|                  |
-----------> |  Orchestrater    +----------------> |  Controller      |
 Status      |                  |   Policy         |                  |
             +------------------+                  +--------+---------+
                ^         ^                                 |          
                |         |                            Policy          
            Networks'   Security                       Distribution    
            Conditon    Incidents                           |          
                |         |                                 |          
                |         |                                 v          

                Figure X: The function of Orchestration controller
]]></artwork>
        </section>
        <section anchor="authorizer">
          <name>Authorizer</name>
          <t>As an vital third party, before the formation of path strategy, the authorizer's responsibility is to verify the authenticity of the attester's claim; After path policy execution or during the execution of routing policies, authorizer verifies if the path is executed as scheduled and the security capability is truly provided.</t>
        </section>
        <section anchor="secfunction">
          <name>Secfunction</name>
          <t>There are two functions for forming a secure path: one is to ensure the static security of the routing node by secure boot, and the other is to provide security capabilities to defend against dynamic attacks during the routing forwarding process. The secfunction include the security capabilities that the routing node itself can provide externally, the ability to security resource pool supported by virtualization, and the ability to provide specialized hardware security devices, such as IPS/firewall.</t>
        </section>
      </section>
      <section anchor="secure-path-operations">
        <name>Secure path Operations</name>
        <section anchor="indirect-model">
          <name>Indirect Model</name>
          <t>Indirect Model: the controller Obtains security function information through the attester node, and then send the security informations to authorizer, after verifying the authenticity of the information, the controller can obtain attestation result. After forming routing policy according to users' requirements, secure path policies can be distributed to routing nodes, the whole process can be seen in Figure2.</t>
          <artwork><![CDATA[
+------------+     +----------+               +-----------+   +------------+
|SecFunction |     | Attester |               | Authorizer|   | Controller |
+-----+------+     +-----+----+               +-----+-----+   +------+-----+
      |                  |                          |                |
      |               secure                        |                |
      |                boot                         |                |
      |                  |                          |                |
      +------------------>                          |                |
      | aware security   |                          |                |
      | capabilities     |                          |                |
      |                  +-------------------------->                |
      |                  |   security capabilities  |                |
      |                  | & trustworthiness claim  +---------------->
      |                  |                          |Attestation     |
      |                  |                          | Result         |
      |                  |                          |                |
      |                  |                                           |
      |                  <-------------------------------------------+
      |                  |  Secure path routing policy issurance     |

                    
                     Figure 2: Indirect Model
]]></artwork>
          <t>When the network node receives the routing policy, it enable the security functions, then all traffic forwarding will receive security services. During the data forwarding process or after the data forwarding is completed, security validation can be performed on the entire process, including verification of secure paths and verification of whether security services are provided, the final validation results will be given to the controller or present to users.</t>
          <artwork><![CDATA[
+------------+     +----------+           +-----------+       +------------+
|SecFunction |     | Attester |           | Authorizer|       | Controller |
+-----+------+     +-----+----+           +-----+-----+       +------+-----+
      |                  |                      |                    |
      <------------------+                      |                    |
      |enable SecFunction|                      |                    |
      |----------------->|                      |                    |
      |  ok       traffic forwarding            |                    |
      |                  |                      |                    |
      |                  +---------------------->                    |
      |                  |Secure path validation+--------------------+
      |                  |                      |  Validation Result |

        Figure 3: Path and security service validation Process
]]></artwork>
        </section>
        <section anchor="direct-model">
          <name>Direct Model</name>
          <t>Direct Model: If the security function has a public address, the security function proactively reports its own information to the authorizer, after verifying the authenticity of the information, the controller can obtain attestation result. After forming routing policy according to users' requirements, secure path policies can be distributed to secfunction, the whole process can be seen in Figure4.</t>
          <artwork><![CDATA[
+-----------+                  +----------+  +----------+
|SecFunction|                  |Authorizer|  |Controller|
+-----+-----+                  +----+-----+  +----+-----+
      |                             |             |
      |                             |             |
      +---------------------------->|             |
      |security capability report   |             |
      |         +--------+          +------------>|
      |         |Attester|          | attestation |
      |         +---+----+          |   result    |
      |             |                             |
      |<------------+<----------------------------+
      |             |  secure path routing        |
      |             |    policy issurance         |
      |             |                             |

             Figure 4: Direct Model
]]></artwork>
          <t>In the direct model the network node and secfuntion both receive the routing policy, then all traffic forwarding will receive security services. During the data forwarding process or after the data forwarding is completed, security validation can be performed on the entire process, including verification of secure paths and verification of whether security services are provided, the final validation results will be given to the controller or present to users.</t>
          <artwork><![CDATA[
+-----------+  +--------+      +----------+  +----------+
|SecFunction|  |Attester|      |Authorizer|  |Controller|
+-----+-----+  +----+---+      +----+-----+  +----+-----+
      |             |               |             |
      |             |               |             |
      |             +-------------->|             |
      |             |path validation|             |
      |             |               |             |
      |                             |             |
      +---------------------------->|             |
      |security service validation  +------------->
      |                             |validation   |
      |                             |result       |

  Figure 5: Path and security service validation Process
]]></artwork>
        </section>
      </section>
    </section>
    <section anchor="IANA">
      <name>IANA Considerations</name>
      <t>This memo includes no request to IANA.</t>
    </section>
    <section anchor="Security">
      <name>Security Considerations</name>
      <t>TBD</t>
    </section>
  </middle>
  <back>
    <?line 221?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1bbY/buBH+vsD+ByILNDnY3iab9EOdIujebYJu0VyC3e3L
pxa0RNvESqKPpOz46rvf3pkhKVGUvC/OBiiKKh9uTVHD4XDmmWdGuslkcnxk
LK/yf/FCVWLKrK7F8ZFcafrT2LOXL3//8uz4KON2ymQ1V+yE/bAU2S08V89K
aYxUld2u4NHL9zcfjo+4FnzKrkVWa2m3x0ebBdyprNCVsOx9tZCVEFpWC3bD
zS37oHQG6x0f5SqreAlScs3ndpItRTUxKERMVtwuJ1xnS2lFZnHk5St8xEpb
oMZLweK7bK40c48yrWoLa4FWs5kW66mbOLm+Oj4qeAWaier46HYzPT5ibNKo
OblAHdzYrdhulM7BAics5xbWO3t59mbyevKGTSY0wqRhc1kUIgf7MF5bVXIr
M14UWzbbsi9lcabnGZNzVinLFnKNa8K0pdKw7gR0xF2IXFrQ+4RpUaq1CNPd
cTCQbKZo9wp/OEN9FLJAO4ZRpRc4RVacfVQzWdBzGZzBlH0v5J/JDDCg6srq
rZ+JI6LkspgytHjpRP4xw3slCTnNVIlaujX/Itl1/QSLmbqQ/VXcvwnYlc+M
1Tyz+PtalYLVRmjDwHVyZhXoqpQRYKBcGDh/blkpwLuMdzqw4U+1BEOKyhqc
Dx5RJi7BwOfh9A0OkQRYbz6XGct4xXIxF3CbLzjY3bJ8C3rCLW4tz24Ny2ty
YPRLFL3hOoffp6jsZQXSwCFihxyji2p0UvTNWtOJG1wEYiGfolhhwPPGzHmF
/Bn/ziCsYGIhNKkK2s/rKrMQbSQPPAIe4TTA1ByHTEc87oODEmItaL4RhWhm
D9iiMR5Yei0zYU7ZDTy2qvUKbU1LJBtDzwfremG4iBc4Bu2yokar0CExgBgI
iXYNbowwBs9n3Fi3uUnWN2A2VCuoSMYe0hMNZSTYr8q2bM0LCTEJuzwNrlTK
PC8IYk4wwLXKazJDc1qCCa4hVkHHBdgNNioDXOVgvEKtnJ7kgs9hrEQ1EGTw
WZgG+HDLNtx7Is/AdobBk3q7wXMfs1ltwQwb78ReQGw7WB12UYFVcax99BTx
cY9bozfNBMQNWgfMDbBr4E8QJdYyJ43pwNxJwMZmCiyIKrCVlmsO1uqYsyvc
sI0oCvzvrAaxuKPBmacM7fgn2BwoLstVQcPBJfDQDFuiFNQUQgDstQEBRqAf
sRzE0GGArykXw97KGOkmRnIUBR5hWQH7tGT6OUSH2uD27VILnKJtixEzEbae
OyVfnYakRBHgPJIgxOUQSndwlnZJExy4yCr2a+eF0QoCHK6GHJC/pSXOTq/i
id6RG8tN3Yl4+xmXuQD+UCWQB0Pgxw3KcNtZukBfHJNCQpfOT4O9uYMFaVkr
PnfueHn92WEBJCWweBpkcGvlVJCiAbawpIGckNeYEd7i7l47A7qzYH9rQm3K
lLPSCpxCGo+nPD457wOiIigW+bgDveSUAX/JZXM0sYdW+AtiShHGopn8ShMn
icRTsN9gxMCg8I5PRILAtVy5NLDSirAMkfFuwnDq8OI6gcnooWbFFNa9x8Sb
7yaDcw/3dCparMDj2ifwaJBl6ZJMG/aLycDlAnB1VS+WzneidNH97fzArBAa
Z4XbIaCKnLtocVPBcWTmw8FllGZdh/1RCiLv8S6Lx/XcdAFjxg2chfcDNbMc
U1u6E0rDPE0+mOmtWGzHbOlgxHkqOUVnDdgTPELBm6mVIB2r4CVIxTjt06Es
0tlFF4cQ7sAFEB3DjSaHRFEAoAu8BNhbz6jOgmAFAGdM6R6FAgFwhw1aNhnJ
so207qyAKNciSmeqkB6BY2GNDzQKbSlR6Bpw3euek3P+ChcSqvgaTdpr5G62
QyN23uxklE7bDctoRnfptOELpuHzo/TxRPqoWXvXRkO8cLP+D60HPlr2AxVO
po26CnSmRfdGAA0fPB9rxkfpgSTS4Pbx0Qe5QM97BUQZEna2FyjCEQMOQcWl
SohljAI3cNLYDX8Dr2FXUDZALXJ+g8Mu4sBfMsBvLa7Zi6vzm+vvxhCgsBLU
X+wFetuzIOTZdzgZiBHSBFEAZ+SIGnH48hnGnrRAI+fsxbP3xDEyAU8iY6lo
PqfixXaWuAJygw7/GZLz1s3ORYYhGPweQpYqHeXiJqdQgKzQeAbvpGaU7SgV
IG3HeGF+sxXhlYwY70zBUkS/or3B7drQDvrxh+He7tB2UZEIHNLqIN5XJB7q
YtZgTsPJtT7tc0iH6sPZU+WIY1h9MNg3C8zfuBNEINQIx4icdDhV7oCXDOoQ
CCX2YBxTjkPnjgHmWgEwA9/rkB5PbccRrwtsF0y80LwsfUqm3aZASBAH5nM8
PgdA1BKOzRkx3AwJLnqYdNiLcXGw3hfdnevbCPqry4WDvx4l6EdvWXc1TPXx
gq7ilOl/+R+PE0TXkxl7PfDX4wUNJoneNTQLBF0Iqmuf45SB3ewAo3yNGcw/
NIuqynC9Q0GfmliECBtanmZFqSwIYteA1LUJyw9oxNhnRxTiob5GX2OjHheI
r38O/LXvilQ72I+S3SaCfIzQCd4TIRcBbhDeeoLgLLDdRncuq4zK5bvi4ym2
9rSCoiAiBpBcnmT8Y0oJIKQPTHSfOokji3JRSzdOIqqII+fIndlaWl5gaaVz
KrWBH8+o3goA3mZTwv+W13dp9POoNGkZrnLseru3OgnpHR7PCi7Lt+x8Ttm+
yTVbJr6AVzgldChmqcHTjs+7FNzlpwGKL92qgdI7CViKmlAW4w+fdx9O29G4
120rr1tFdlI91TJoVao8Y6YzDSSAeIkJvbe0x+btFrZLfbjZNiZC4z5xcFVy
WyINcaGHdUfjtWNqgKTU+OZi1NQMzZo99pSh0dvbkqekyGyC5uIL9u+iEq7t
sURNLAM1e4ZMRBXM1Cusw+FIwUJrqZGEyZ99WyUYKRLT2GgFXBanwpNL2OGG
axH3WCjhjEE8FLTgOZefr387h+S8Ad28O7C4p/JpJVxgNjT/snI9MvYR9lq4
nmU8Mk0p6aeZo42NEpGBo2I87iIE3ozmbHaL3Dr17kgCOULcf+AUjC6GH9hk
GKe6R+zUKeWUhaOqC3vq4z2ERFpJxy0i30SMuwfjTq3Q0E9cciYidkqdvdjB
jFNzs1SFCN4bHjPY0QJtHdyeRaR1oIwc7c/HadGdlo27uNrc+RTR1EdptthF
8L2j3/0yOimko6Fh3UapbqMuZdjDXvZcvVu7fXL8oX21HFf4PYGcA/c1QMre
HSJnx3gXYw62cwdaByc/TE7vGtjq3i3fZ+fhRPDY8/pN1EBw7zKIQQwx9QPP
/TyCq4fsa58cqNcQ6x64rzvkpAOHyenPvUPOH/afe++6BzfinJjgPPZRNcem
jtenT37xGh4NvPhs2kusgf3+HVNf/GKPSAbMFHLt+99djei1S9Qe6iVel0Aq
6q+ElxwRIdpIGPfyh17CXrR0KrS4Ey6FZNel36FJ1A3CBo7F1y7NAu2b0pDM
gHv4Vyq+jY+pWzc5L36n61hy1vD9Xps9nRB6fb39Ee8NDNll2jl232P9XP43
zlKgKH1CEb8Z8alNYetPGOxTBQ5wUEYeaoEfnpHTbOzGDs3IaTaOdDs4Iw8O
N5E+ENYD7YT75ex8jESGO0ifXU+dd4fJYUyFdttAWD5GzoMWPkDOnkw6SBzu
1CfG0zawBsUf5j/ty+CQwTrI7GH39bRtsfU+44gC/rNDnG5L4iKpgy46VdDl
fBh86cUzZ6t6VmCJmueaoGx4LuAQflCzxu8x3ItZg+UlU5tq6KXs/2z50/vW
6AHFz5s9UHt3e3bU/dXF1SEP7GDprkXRBET3rTrqrHo/Yu51/rvC7f6H7qDI
PThrVxrqMvnvBx6gXtvwZf0xt27/oV1IaZH4Xcc796yUJi68qxtuu8d699iy
eaiTkkZ38s49h7tjnXgIwbTfes2vQRr6NXtKmKqHyjfTBPACFPpP1jx5LfFm
n662HwzSGdGXX4FiDjHY//PT/y5+OuqH6yNAMw3aR4BmA4vxqo8AzX4rKvH2
J3sogdC9oNkdThjQt1Mvvb5NIhjgTonIuxoasexYwoP3pONmhYcyj1+/O5jq
scvzH8+xPqJPQXyz+d8nOPqLe10CiFGKUrVftlaKuI4wFFg4033x2XzCh4v3
JIY7Tur3F+3X5zOO/3uD+/cfisMewCIxAAA=

-->

</rfc>
