idnits 2.17.00 (12 Aug 2021) /tmp/idnits19963/draft-du-panrg-gateway-based-trust-relationship-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 31, 2021) is 134 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Du 3 Internet-Draft P. Liu 4 Intended status: Informational China Mobile 5 Expires: July 4, 2022 December 31, 2021 7 Gateway Based Trust Relationship Between the Endpoint and the 8 Intermediate Node 9 draft-du-panrg-gateway-based-trust-relationship-01 11 Abstract 13 This document describes a mechanism about establishing trust 14 relationship between the endpoint and the intermediate node along the 15 path based on the gateway of the endpoint. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 4, 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Proposed Mechanism for the Trust Problem . . . . . . . . . . 3 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 6.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 In future, many new services would emerge in the network, such as the 70 5G URLLC (Ultra Reliable Low Latency Communication) service, and the 71 holographic type communications. Many of the new services need a 72 higher QoS (Quality of Service) level than the current Internet 73 services, and some of them have a critical SLA (Service-Level 74 Agreement) requirement. The SLA differences between the new services 75 and traditional services would become larger and lager. However, 76 current networks can only provide the Best Effort bearing, in which 77 all the traffic are treated as the same kind. In summary, current 78 networks are short of negotiation abilities between the network and 79 the applications. PANRG in the IRTF has proposed a research 80 direction to enable the path aware networking. A lot of analyses 81 have been done in the [RFC9049], which explains reasons why various 82 Path Aware techniques have seen limited or no deployment. 84 One of the reasons is that it is hard to establish a trust 85 relationship between the Endpoint and Intermediate Node. In the 86 current network structure, the Endpoints only needs to be aware of 87 the each other, and assume that the network can provide a good 88 connection service for them. On the other hand, traditionally, 89 Intermediate Nodes only need to support IP forwarding and do not need 90 to be aware of up-layer information. In addition, the network nodes 91 work in a per-packet model, not a per-flow model. Also in the 92 [RFC9049], it is said that "per-connection state in intermediate 93 nodes has been an impediment to adoption and deployment". 95 However, we can find that the gateway of the Endpoint is able to 96 maintain a per-connection state and a trust-relationship for each 97 user. For example, the users in the fixed network need to be 98 authorized by the BNG (Broadband Network Gateway), and the BNG also 99 needs to do the accounting for each user. It is hard and unnecessary 100 to make every intermediate node along the path has the same ability 101 as the BNG; however, if they can have some communication with the 102 BNG, perhaps they can make a better path choice for the user. 103 Following this direction, this document proposes a mechanism about 104 how to enable the communication between the BNG and the Head-End node 105 in the network, because the Head-End node is the main node to select 106 the path for a flow in the network. If any future work on the trust 107 relationship between the Endpoint and the Intermediate Node is 108 considered, the mechanism in this document can be a reference. 110 2. Proposed Mechanism for the Trust Problem 112 As shown in the Figure 1, in the fixed network, the BNG works as the 113 gateway for the Client, and provides the Internet connection service 114 for the Applications. The Client and Server are the EndPoints, and 115 the BNG, Head-End, Mid-Node, End-Node are the nodes along the path 116 from the Client to the Server. There are three paths, i.e., A, B, C, 117 with different properties such as high bandwidth or low latency, 118 between the Head-End and the End-Node in the network. 120 By default, all the traffic from the APPs are forwarded from the 121 Head-End to the End-Node with the same treatment in the network. In 122 the Head-end, perhaps a load balance mechanism can be enabled, but 123 normally without any per-flow mechanism, because the Head-End does 124 not know the requirements of each flow. If the Applications need 125 different treatments in the network, and the Head-End can schedule 126 the traffic to a proper path, the user can have a better experience 127 and the network resource can be used more efficiently. 129 Client Server 130 +-----+ +-----+ 131 |App x|-\ /->|App x| 132 +-----+ | +-----+ +---------+ +--------+ +---------+ | +-----+ 133 \->| | | |-A-| |-A-| |-/ 134 User side | BNG |-|Head-End |-B-|Mid-Node|-B-|End-Node | 135 /->| | | |-C-| |-C-| |-\ 136 +-----+ | +-----+ +---------+ +--------+ +---------+ | +-----+ 137 |App y|-/ \->|App y| 138 +-----+ --------- Uplink ----------> +-----+ 140 Figure 1: Path-aware Mechanism in the Fixed Network 142 The following paragraphs are about the trust problems and the 143 potential solutions for them. 145 The first problem is the path information collection for the 146 Endpoints. The Endpoints should be able to trust the path 147 information that the Intermediate Nodes signal. As a first step, we 148 only consider the situation that information is limited and does not 149 need to be updated frequently. In this case, if the Head-End needs 150 to inform the Endpoints something, it can send the information with 151 its signature generated by using a private key. The Endpoints can 152 check the information using the corresponding public key. For 153 example, the public key can be obtained by the Endpoint in the 154 authentication procedure. 156 The second problem is the Head-End should trust the Endpoints if it 157 receives some path selection suggestions from the Endpoints. In this 158 case, we think that the BNG has authenticated the Endpoints, so that 159 the BNG can send some information to the Head-End indicating that the 160 Endpoint is not a fake one. For example, the BNG and the Head-End 161 can using an IPSec to transfer the traffic that needs specific 162 treatment. Another option is that the BNG can forward the traffic 163 that needs specific treatment with its signature generated by using a 164 private key. The Head-End can check the information using the 165 corresponding public key of the BNG. 167 The reason that we do not suggest that the Endpoints make the 168 signature is because their number is much larger than the number of 169 BNGs. We do not think the Head-End can handle a large number of 170 keys. Meanwhile, in this mechanism, the Intermediate Node does not 171 need to maintain per-connection state. 173 3. IANA Considerations 175 TBD. 177 4. Security Considerations 179 TBD. 181 5. Acknowledgements 183 TBD. 185 6. References 187 6.1. Normative References 189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 190 Requirement Levels", BCP 14, RFC 2119, 191 DOI 10.17487/RFC2119, March 1997, 192 . 194 6.2. Informative References 196 [RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to 197 Deployment (A Bestiary of Roads Not Taken)", RFC 9049, 198 DOI 10.17487/RFC9049, June 2021, 199 . 201 Authors' Addresses 203 Zongpeng Du 204 China Mobile 205 No.32 XuanWuMen West Street 206 Beijing 100053 207 China 209 Email: duzongpeng@foxmail.com 211 Peng Liu 212 China Mobile 213 No.32 XuanWuMen West Street 214 Beijing 100053 215 China 217 Email: liupengyjy@chinamobile.com