Internet DRAFT - draft-chen-secure-path-architecture

draft-chen-secure-path-architecture







Internet Engineering Task Force                                Chen, Ed.
Internet-Draft                                                     L. Su
Intended status: Informational                              China Mobile
Expires: 5 September 2024                                   4 March 2024


                  the architecture for secure routing
                 draft-chen-secure-path-architecture-01

Abstract

   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.

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 5 September 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights



Chen & Su               Expires 5 September 2024                [Page 1]

Internet-Draft                  archi-SR                      March 2024


   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Secure routing architecture . . . . . . . . . . . . . . . . .   3
     2.1.  Components  . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.1.  Attester  . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.2.  Controller  . . . . . . . . . . . . . . . . . . . . .   3
       2.1.3.  Authorizer  . . . . . . . . . . . . . . . . . . . . .   4
       2.1.4.  Secfunction . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Secure path Operations  . . . . . . . . . . . . . . . . .   4
       2.2.1.  Indirect Model  . . . . . . . . . . . . . . . . . . .   5
       2.2.2.  Direct Model  . . . . . . . . . . . . . . . . . . . .   6
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   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.

   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.

   1.Security of static nodes: the trustworthy of nodes in the routing
   path need to be evaluated;

   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;

   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.

   Therefore, this draft attempts to propose an architecture for secure
   routing.




Chen & Su               Expires 5 September 2024                [Page 2]

Internet-Draft                  archi-SR                      March 2024


2.  Secure routing architecture

   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.

                 +-----------+
       +---------+ Authorizer+---------+
       |         +-----------+         |
       |                               |
   +---+------+                  +-----+------+
   | Attester +------------------+ Controller |
   +---+------+                  +-----+------+
       |                               |
       |          +------------+       |
       +----------+SecFunction +-------+
                  +------------+

   Figure 1: Basic secure path architecture

2.1.  Components

2.1.1.  Attester

   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.

2.1.2.  Controller

   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.





Chen & Su               Expires 5 September 2024                [Page 3]

Internet-Draft                  archi-SR                      March 2024


                 |         |
                 |         |
            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

2.1.3.  Authorizer

   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.

2.1.4.  Secfunction

   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.

2.2.  Secure path Operations










Chen & Su               Expires 5 September 2024                [Page 4]

Internet-Draft                  archi-SR                      March 2024


2.2.1.  Indirect Model

   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.

+------------+     +----------+               +-----------+   +------------+
|SecFunction |     | Attester |               | Authorizer|   | Controller |
+-----+------+     +-----+----+               +-----+-----+   +------+-----+
      |                  |                          |                |
      |               secure                        |                |
      |                boot                         |                |
      |                  |                          |                |
      +------------------>                          |                |
      | aware security   |                          |                |
      | capabilities     |                          |                |
      |                  +-------------------------->                |
      |                  |   security capabilities  |                |
      |                  | & trustworthiness claim  +---------------->
      |                  |                          |Attestation     |
      |                  |                          | Result         |
      |                  |                          |                |
      |                  |                                           |
      |                  <-------------------------------------------+
      |                  |  Secure path routing policy issurance     |


                     Figure 2: Indirect Model

   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.










Chen & Su               Expires 5 September 2024                [Page 5]

Internet-Draft                  archi-SR                      March 2024


+------------+     +----------+           +-----------+       +------------+
|SecFunction |     | Attester |           | Authorizer|       | Controller |
+-----+------+     +-----+----+           +-----+-----+       +------+-----+
      |                  |                      |                    |
      <------------------+                      |                    |
      |enable SecFunction|                      |                    |
      |----------------->|                      |                    |
      |  ok       traffic forwarding            |                    |
      |                  |                      |                    |
      |                  +---------------------->                    |
      |                  |Secure path validation+--------------------+
      |                  |                      |  Validation Result |

        Figure 3: Path and security service validation Process

2.2.2.  Direct Model

   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.

   +-----------+                  +----------+  +----------+
   |SecFunction|                  |Authorizer|  |Controller|
   +-----+-----+                  +----+-----+  +----+-----+
         |                             |             |
         |                             |             |
         +---------------------------->|             |
         |security capability report   |             |
         |         +--------+          +------------>|
         |         |Attester|          | attestation |
         |         +---+----+          |   result    |
         |             |                             |
         |<------------+<----------------------------+
         |             |  secure path routing        |
         |             |    policy issurance         |
         |             |                             |

                Figure 4: Direct Model










Chen & Su               Expires 5 September 2024                [Page 6]

Internet-Draft                  archi-SR                      March 2024


   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.

   +-----------+  +--------+      +----------+  +----------+
   |SecFunction|  |Attester|      |Authorizer|  |Controller|
   +-----+-----+  +----+---+      +----+-----+  +----+-----+
         |             |               |             |
         |             |               |             |
         |             +-------------->|             |
         |             |path validation|             |
         |             |               |             |
         |                             |             |
         +---------------------------->|             |
         |security service validation  +------------->
         |                             |validation   |
         |                             |result       |

     Figure 5: Path and security service validation Process

3.  IANA Considerations

   This memo includes no request to IANA.

4.  Security Considerations

   TBD

Authors' Addresses

   Meiling Chen (editor)
   China Mobile
   BeiJing
   China
   Email: chenmeiling@chinamobile.com


   Li Su
   China Mobile
   BeiJing
   China
   Email: suli@chinamobile.com




Chen & Su               Expires 5 September 2024                [Page 7]