idnits 2.17.1 draft-chen-spring-srv6-srh-security-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 144: '...ERVED: 15 bits. MUST be 0 on transmis...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Dec 27, 2021) is 852 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 222 -- Looks like a reference, but probably isn't: '1' on line 224 -- Looks like a reference, but probably isn't: '2' on line 226 == Unused Reference: 'I-D.cl-spring-generalized-srv6-for-cmpr' is defined on line 360, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-cl-spring-generalized-srv6-for-cmpr-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Spring D. Lu 3 Internet-Draft M. Chen 4 Intended status: Standards Track Li. Su 5 Expires: June 30, 2022 China Mobile 6 Wei. Pan 7 Cheng. Li 8 Huawei Technologies 9 Dec 27, 2021 11 SRH and IP header protection 12 draft-chen-spring-srv6-srh-security-02 14 Abstract 16 This document proposes a method to protect SRH and IP header using 17 signature which stored in the TLV, this scheme can apply to SRv6 and 18 G-SRv6. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 30, 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. New TLV Type for Signature . . . . . . . . . . . . . . . . . 3 57 4. SRH protection used in SRv6 and G-SRv6 . . . . . . . . . . . 4 58 5. signing and verifying process . . . . . . . . . . . . . . . . 7 59 6. verifying optimization process . . . . . . . . . . . . . . . 8 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 63 10. Normative References . . . . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 SRv6 is a protocol for forwarding IPv6 packets over a network based 69 on the concept of source routing. By inserting a Segment Routing 70 Header (SRH) into the IPv6 packet, an explicit IPv6 address stack is 71 pressed into the SRH, and the destination address and offset address 72 stack are constantly updated by the intermediate node to complete 73 hop-by-hop forwarding, SRH is defined in RFC8754 [RFC8754] 75 G-SRv6 is generalized Segment Routing over IPv6 which can reduce the 76 overhead of SRv6 by encoding the Generalized SIDs in SID list, the 77 compression solution is designed in the draft [I-D.cl-spring- 78 generalized-srv6-for-cmpr]. 80 As an emerging source routing protocol, SRv6 is confronted with 81 various threat of source routing attacks. By defining SRH, attackers 82 can construct various source routing attacks, such as bypassing key 83 detection nodes of network and constructing malicious loops. 85 SRv6 networks generally define SRv6 trust domains for basic security 86 protection, which is also mentioned in the draft [I.D.li-spring-srv6- 87 security-consideration] and RFC 8754 [RFC8754]. Firstly, the address 88 space in the SRv6 trust domain is defined to avoid SRv6 trust domain 89 address leakage. Then ACL filtering is enabled at the boundary of 90 the trust domain, and packets whose destination address is SRv6 trust 91 domain are discarded to avoid source routing attack on SRV6 trust 92 domain by attacking packets. 94 SRv6 trust domains use Segment Bingding technology for basic 95 security. RFC8754 defines SRv6 HMAC TLV for IPv6 source address and 96 SRH integrity protection which based on SRv6 trust domain, identity 97 authentication based on the shared key, to prevent illegal access and 98 tamper header, so as to prevent various source routing attacks. 99 However, there is a problem with this scheme, HMAC verification is 100 based on symmetric key verification, that means all network nodes 101 that need to be verified have to share the same key, there may exist 102 a problems. 104 Secret key leak problem: when a single point's key was leaked, 105 then all the trust domain was compromised. 107 In this document we present an alternative method for Segment Routing 108 Header protection. 110 2. Terminology 112 This document uses the terminology defined in [RFC8754]. 114 3. New TLV Type for Signature 116 This section describes how to use the certificate to authenticate the 117 header. The source address field in IP header and several fields in 118 SRH are protected by signature, and the result of signature is stored 119 in TLV, the TLV format is consistent with the HMAC TLV defined in 120 RFC8754, we describe this in Figure 1. 122 By defining a new type of TLV which the Type is 6 and we call it Auth 123 TLV, indicates that the TLV is used for signature protection based on 124 asymmetric secret keys. Auth TLV is described in Figure 1. 126 +--------+---------------------------+ 127 | Type | Length |D| RESERVED | 128 +--------+---------------------------+ 129 | AUTH Key ID(4 octets) | 130 +------------------------------------+ 131 | | 132 | AUTH(variable) | 133 | | 134 +------------------------------------+ 135 Figure 1: Auth TLV format 137 Type: 6. 139 Length: The length of the variable-length data in bytes. 141 D: 1 bit. 1 indicates that the Destination Address verification is 142 disabled due to use of a reduced Segment List. 144 RESERVED: 15 bits. MUST be 0 on transmission. 146 AUTH Key ID: A 4-octet opaque number that uniquely identifies the 147 hash algorithm, signature algorithm, and certificate serial number 148 used for signature authentication. 150 AUTH: the content of the signature that protects the field, in 151 multiples of 8 octets, at most 32 octets. 153 The AUTH TLV is used to protect IPv6 source address, SRH header for 154 signature protection. Which fields are in the range of the signature 155 check? they are described in Figure 2 and Figure 3, Figure 2 is for 156 SRv6 and Figure 5 is for G-SRv6. 158 The AUTH Key ID field is opaque--i.e.,it has neither syntax nor 159 semantic except as an identifier of the right combination of hash 160 algorithm, signature algorithm and certificate serial number 162 Hash Algorithm indicates the hash algorithm used in the header, such 163 as SHA256, and we do not recommend using SHA1. 165 Signature Algorithm indicates the asymmetric signature algorithm 166 used, such as ECDSA and RAS2048. 168 Certificate Serial number used to identify certificate that issued by 169 CA, if a custom certificate is used, the Certificate Serial number 170 represents the identity of the custom certificate. 172 4. SRH protection used in SRv6 and G-SRv6 174 Segment routing header is defined in RFC8754, when user choose to use 175 the method proposed in this draft, the complete SRv6 header with Auth 176 TLV is show as figure 2, and figure 3 is for G-SRV6. 178 +--------------+----------------+----------------------------+ 179 | Version | Traffic class | Flow Label | 180 +--------------+--------------------------------+------------+ 181 | Payload Length | Next=43 | Hop Limit | 182 +-------------------------------+---------------+------------+ 183 | Source Address | 184 +------------------------------------------------------------+ 185 | Destination Address | 186 +--------------+---------------------------------------------+ 187 | Next Header | Hdr Ext Len |Routing Type=4 |Segment Left| 188 +------------------------------------------------------------+ 189 | Last Entry | Flags | Tag | 190 +--------------+----------------+----------------------------+ 191 | Segment List[0] | 192 +------------------------------------------------------------+ 193 | Segment List[1] | 194 +------------------------------------------------------------+ 195 | Segment List[2] | 196 +--------------+----------------+---+------------------------+ 197 | Type=6 | Length | D | Reserved | 198 +--------------+----------------+---+------------------------+ 199 | Auth Key ID | 200 +------------------------------------------------------------+ 201 | Auth(variable) | 202 +------------------------------------------------------------+ 203 | IPv6 Payload | 204 +------------------------------------------------------------- 206 Figure 2: Complete SRv6 header with Auth TLV 208 Figure 5 is the detailed structure for G-SRv6 209 +--------------+----------------+----------------------------+ 210 | Version | Traffic class | Flow Label | 211 +--------------+--------------------------------+------------+ 212 | Payload Length | Next=43 | Hop Limit | 213 +-------------------------------+---------------+------------+ 214 | Source Address | 215 +------------------------------------------------------------+ 216 | Destination Address | 217 +--------------+---------------------------------------------+ 218 | Next Header | Hdr Ext Len |Routing Type=4 |Segment Left| 219 +------------------------------------------------------------+ 220 | Last Entry | Flags | Tag | 221 +--------------+----------------+----------------------------+ 222 | G-SID Container[0] | 223 +------------------------------------------------------------+ 224 | G-SID Container[1] | 225 +------------------------------------------------------------+ 226 | G-SID Container[2] | 227 +--------------+----------------+---+------------------------+ 228 | Type=6 | Length | D | Reserved | 229 +--------------+----------------+---+------------------------+ 230 | Auth Key ID | 231 +------------------------------------------------------------+ 232 | Auth(variable) | 233 +------------------------------------------------------------+ 234 | IPv6 Payload | 235 +------------------------------------------------------------- 237 Figure 3: Complete SRv6 header with Auth TLV 239 Signature check those fields that need to be protected will be 240 signed, the range of signatures includes IPv6 Source address, SRH 241 Last Entry, SRH Flags, SRH Segment List, AUTH TLV D, AUTH TLV 242 Reserved, AUTH TLV Auth Key ID. 244 what's the difference between this scheme with the AH of the IPv6? 245 In this scheme, the message is protected in the routing extension 246 header with type = 43, and AH uses the extension header with type = 247 51, they are totally independent. According to the IPv6 protocol, 248 the processing order of AH extension header is lower than that of 249 routing extension header, that is, the AH extension header will not 250 be parsed until the source route forwarding is completed and the 251 routing extension header pops up. AH cannot be directly used to 252 protect the source route attack. 254 5. signing and verifying process 256 First, need the CA center to issue a root certificate to the 257 controller that will generate controller's public and private key, or 258 the controller use custom certificate, it depends on the detail 259 implementation. How to preset and update a CA certificate on a 260 device is out of scope in this document. The process described in 261 this document uses CA certificates by default. 263 SRv6 controller uses the private key of the certificate to hash the 264 SRH and IP header, and encapsulates the digital signature generated 265 by SRv6 header and controller in the SRV6 source node. The signature 266 process is divided into three steps. 268 Step1: Preset certificates, include private keys and controller 269 certificates on SRv6 controllers, and CA root certificates on key 270 network devices; 272 Step2: After the secure connection is established between the 273 controller and the network device on the control plane, perform 274 public key certificate distribution and signature algorithm 275 selection, and inform the key node the selection result. 277 Step3: SRv6 controller uses the private key, the hash algorithm and 278 the asymmetric algorithm selected in the step2 to sign the packet 279 header which generated according to the routing result, and store the 280 signature results in the TLV, finally sends the routing result which 281 include the signature to the source node, the source node wraps and 282 forwards an SRv6 packet with a signature, the SRv6 network structure 283 is described in Figure 4. 285 +------------+ Public key 286 | Controller | Private key 287 +-----^------+ 288 | 289 +------------+------+-----+-------------+ 290 | | | | 291 | | | | 292 | |certificate | | 293 | | | | 294 | | | | 295 +---+--+ +---v--+ +--+---+ +---+--+ 296 | RT A +-----+ RT B +------+ RT C +-----+ RT D | 297 +------+ +------+ +------+ +------+ 299 Figure 4: SRv6 network structure 301 Signature verification is required at key network nodes, it's also 302 divided into three steps. 304 Step1: Enable signature verification at the key nodes. 306 Step2: Request a public key certificate from the controller. 308 Step3: calculate the hash value according to the header, and use the 309 public key to decrypt the signature in the message, compare the 310 decryption result with the hash value, if verify successful, forward 311 the message, otherwise, the message is discarded. 313 6. verifying optimization process 315 When asymmetric key is used to verify the signature of the forward 316 message on the data plane, the processing efficiency of the forward 317 message is reduced. An efficient lookup table forwarding mechanism 318 for signature verification can be considered, which verifies the 319 signature of the first packet of the data, and records the hash 320 result and signature of the packet header into the hash table. The 321 subsequent packets can directly find the hash table and compare the 322 signature result, no more need to decrypt, also can divide into three 323 steps. 325 Step1: When the interface of signature verification is opened and the 326 SRV6 message is received, the hash value of the message header is 327 calculated and finds if the local hash table is hit, the local hash 328 table contains hash value and signature value, and they are bound. 330 Step2: If the local hash table is not hit, the controller's public 331 key is used to decrypt the signature and compare whether the 332 decrypted result is consistent with the calculated hash value. If 333 not, the message is discarded. If the hash value and decrypted 334 result are consistently then recorded to the local hash table, and 335 the processing packet is forwarded. 337 Step3: If the local hash table is hit, the signature value in message 338 is compared with hash table's signature value, if yes then forwarded 339 to process the message, if not then discarded. 341 7. Security Considerations 343 SRv6 is threatened by various source routing attacks. By defining 344 SRH, an attacker can construct various source routing attacks, such 345 as bypassing the key detection nodes of the network and constructing 346 malicious loops, in this draft we propose a method, it can prevent a 347 single device from being compromised and exposes the network's shared 348 key, then the entire network is under threat. 350 8. IANA Considerations 352 This document does not require any action from IANA. 354 9. Acknowledgement 356 TBD 358 10. Normative References 360 [I-D.cl-spring-generalized-srv6-for-cmpr] 361 (editor), W. C., Li, Z., (editor), C. L., Clad, F., Liu, 362 A., Xie, C., Liu, Y., and S. Zadok, "Generalized SRv6 363 Network Programming for SRv6 Compression", draft-cl- 364 spring-generalized-srv6-for-cmpr-04 (work in progress), 365 October 2021. 367 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 368 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 369 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 370 . 372 Authors' Addresses 374 Dongjie Lu 375 China Mobile 376 32, Xuanwumen West 377 BeiJing, BeiJing 100053 378 China 380 Email: ludongjie@chinamobile.com 382 Meiling Chen 383 China Mobile 384 32, Xuanwumen West 385 BeiJing, BeiJing 100053 386 China 388 Email: chenmeiling@chinamobile.com 389 Li Su 390 China Mobile 391 32, Xuanwumen West 392 BeiJing 100053 393 China 395 Email: suli@chinamobile.com 397 Wei Pan 398 Huawei Technologies 399 101 Software Avenue, Yuhuatai District 400 Nanjing 401 China 403 Email: william.panwei@huawei.com 405 Cheng Li 406 Huawei Technologies 407 Huawei Campus, No. 156 Beiqing Rd. 408 Beijing 100095 409 China 411 Email: c.l@huawei.com