idnits 2.17.1 draft-zartbot-sr-udp-00.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 abstract seems to contain references ([RFC8754]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 25 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (29 June 2020) is 1391 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 559 -- Looks like a reference, but probably isn't: '1' on line 386 == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-00 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-29 ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING K. Fang 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Experimental Y. Li 5 Expires: 31 December 2020 Google, Inc. 6 F. Cai 7 Cisco Systems, Inc. 8 29 June 2020 10 Segment Routing over UDP(SRoU) 11 draft-zartbot-sr-udp-00 13 Abstract 15 This document defines the Segment Routing Header[RFC8754] extension 16 in UDP transport protocol with Network Address Translation Traversal. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 31 December 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 53 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. SR over UDP(SRoU) Packet encapsulation . . . . . . . . . . . 3 55 2.1. SR over UDP(SRoU) Header . . . . . . . . . . . . . . . . 4 56 3. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1. Type:0x1, IPv4 Locator Mode . . . . . . . . . . . . . . . 7 58 3.2. Type:0x2, SRv6 format . . . . . . . . . . . . . . . . . . 10 59 3.3. Type:0x3, Compressed Segment List . . . . . . . . . . . . 10 60 3.3.1. Service Registration & Mapping . . . . . . . . . . . 10 61 3.4. Optional TLV . . . . . . . . . . . . . . . . . . . . . . 10 62 3.4.1. SR Integrity TLV . . . . . . . . . . . . . . . . . . 10 63 3.4.2. Micro-segmentation(uSeg) . . . . . . . . . . . . . . 10 64 3.4.3. End.PacketInfo . . . . . . . . . . . . . . . . . . . 11 65 4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.1. Traffic engineering over Internet . . . . . . . . . . . . 11 67 4.2. Multipath forwarding . . . . . . . . . . . . . . . . . . 12 68 4.3. Micro Segmentation . . . . . . . . . . . . . . . . . . . 12 69 4.4. Container Network . . . . . . . . . . . . . . . . . . . . 12 70 4.5. MPLS-SR with SDWAN . . . . . . . . . . . . . . . . . . . 12 71 4.6. Cloud Native Network platform . . . . . . . . . . . . . . 13 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 6.1. SRoU with QUIC . . . . . . . . . . . . . . . . . . . . . 14 75 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 76 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 Normative References . . . . . . . . . . . . . . . . . . . . . 14 78 Informative References . . . . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 Many UDP based transport protocol(eg, IPSec/DTLS/QUIC) could provide 84 a secure transportation layer to handle overlay traffic. 86 This document defines a new Segment Routing Header in UDP payload to 87 enable segment routing over UDP(SRoU). 89 Segment Routing over UDP(SRoU) interworking with QUIC could provide a 90 generic programmable and secure transport layer for next generation 91 applications. 93 Discussion of this work is encouraged to happen on GitHub repository 94 which contains the draft: https://github.com/zartbot/draft-quic-sr 95 (https://github.com/zartbot/draft-quic-sr) 97 1.1. Specification of Requirements 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 1.2. Motivation 107 Segment Routing provides source-based path enforcement and 108 transportation level programmability but lacks of IPv4 support for 109 transport over internet. 111 MPLS-over-UDP[RFC7510] and MPLS Segment Routing over IP[RFC8663] 112 defined SR-MPLS over IPv4 network, but it lacks of NAT traversal 113 capabilities. 115 Many SDWAN vendors defined their private protocols for routing 116 control over multiple public cloud and internet, it's hard for 117 interop with multi-vendors. 119 Many applications may require intelligence traffic steering(CDN/LB 120 case), SRoU with QUIC could be used in these cases. 122 2. SR over UDP(SRoU) Packet encapsulation 124 The SRoU defined a generic segment routing enabled transport 125 layer,the SR Header insert in UDP payload. 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | IP Header | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | UDP Header | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | SRoU Header | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | | 135 | Payload | 136 | | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 Figure 1: SRoU encapsulation 141 2.1. SR over UDP(SRoU) Header 143 SR over UDP must be present at the head of UDP payload. 145 0 1 2 3 146 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Magic Number | SRoU Length | Flow ID Length| Protocol-ID | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | | 151 | Flow ID( Variable length) | 152 | | 153 | | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Source Address | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Source Port | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Segment Type | SR Hdr Len | Last Entry | Segments Left | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | | 164 | Segment List[0] (length based on segment type) | 165 | | 166 | | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | | 169 | | 170 ... 171 | | 172 | | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | | 175 | Segment List[0] (length based on segment type) | 176 | | 177 | | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 // // 180 // Optional Type Length Value objects (variable) // 181 // // 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 2: SRoU Header 186 Magic Number: 1 Byte field with ALL ZERO. 188 SRoU Length: 1 Byte, The byte length of a SRoU header. 190 FlowID Length: 1 Byte, The byte length of FlowID field. 192 Protocol-ID: 194 +------+------+------------------------------------+ 195 | Type | Name | Section | 196 +======+======+====================================+ 197 | 0x0 | OAM | for Link state probe and other OAM | 198 +------+------+------------------------------------+ 199 | 0x1 | IPv4 | Indicate inner payload is IPv4 pkt | 200 +------+------+------------------------------------+ 201 | 0x2 | IPv6 | Indicate inner payload is IPv6 pkt | 202 +------+------+------------------------------------+ 204 Table 1: Protocol ID field 206 Source Address: Protocol-ID = 1, this field is 4-Bytes IPv4 address 207 Protocol-ID = 2, this field is 16-Bytes IPv6 address 209 Source Port: Source UDP Port Number 211 Segment Type: 213 +------+-------------------------+------+-------------+ 214 | Type | Name | Len | Section | 215 +======+=========================+======+=============+ 216 | 0x0 | Reserved | | | 217 +------+-------------------------+------+-------------+ 218 | 0x1 | IPv4 Address+ Port | 48b | Section 3.1 | 219 +------+-------------------------+------+-------------+ 220 | 0x2 | SRv6 | 128b | Section 3.2 | 221 +------+-------------------------+------+-------------+ 222 | 0x3 | Compressed Segment List | 128b | Section 3.3 | 223 +------+-------------------------+------+-------------+ 225 Table 2: Segment Types 227 SR Hdr Len: SR Header length, include the SR Header flags Segment- 228 List and Optional TLV. 230 Last Entry: contains the index(zero based), in the Segment List, of 231 the last element of the Segment List. 233 Segments Left: 8-bit unsigned integer. Number of route segemnts 234 remaining, i.e., number of explicitly listed intermediate nodes 235 still to be visited before reaching the final destination. 237 Segment List[0..n]: 128-bit/48-bit/144-bit addresses to represent 238 the SR Policy. Detailed forwarding behavior will be defined in 239 Section 3 241 TLV: Opptional TLV used for future extension.currently only defined 242 the following TLV. 244 +------+----------------------+----------+---------------+ 245 | Type | Value | Len | Section | 246 +======+======================+==========+===============+ 247 | 0x0 | SR Integrity | 32b | Section 3.4.1 | 248 +------+----------------------+----------+---------------+ 249 | 0x1 | Micro Segment Policy | variable | Section 3.4.2 | 250 +------+----------------------+----------+---------------+ 251 | 0x2 | End.PacketInfo | variable | Section 3.4.3 | 252 +------+----------------------+----------+---------------+ 254 Table 3: Optional TLV 256 3. Packet Processing 258 This section describe the packet proccessing procedure. The 259 following topology will be used in this section. 261 H1---R1----------I1------R3----------+---R4---H2 262 | | 263 |-----------R2------------------| 264 | 265 | 266 I2 268 I1,I2: Interim Node that support SRoU 269 R1~R4: Traditional Router 270 H1,H2: Host 272 Figure 3: Topology for packet proccesing 274 +------+----------------------+-----------+----------------+ 275 | Host | Address | SRoU Port | Post NAT | 276 +======+======================+===========+================+ 277 | H1 | 192.168.1.2 | 5111 | 10.1.1.1:23456 | 278 +------+----------------------+-----------+----------------+ 279 | R1 | 192.168.1.1/10.1.1.1 | | | 280 +------+----------------------+-----------+----------------+ 281 | R2 | 10.1.2.2 | | | 282 +------+----------------------+-----------+----------------+ 283 | R3 | 10.1.3.3 | | | 284 +------+----------------------+-----------+----------------+ 285 | R4 | 10.1.4.4 | | | 286 +------+----------------------+-----------+----------------+ 287 | H2 | 10.99.2.2 | 443 | 10.1.4.4:443 | 288 +------+----------------------+-----------+----------------+ 289 | I1 | 10.99.1.1 | 8811 | | 290 +------+----------------------+-----------+----------------+ 291 | I2 | 192.168.99.2 | 8822 | 10.1.2.2:12345 | 292 +------+----------------------+-----------+----------------+ 294 Table 4: IP address table 296 3.1. Type:0x1, IPv4 Locator Mode 298 In this mode, the endpoint could directly insert the interim node 299 IPv4 addresses and port into the segment-list. 301 For example, H1 intend to send packet to H2 via R1->I2--->H2, In this 302 case SRoU packet will be NATed twice to show the NAT traversal 303 workflow. I2's public address could use STUN[RFC5389] protocol 304 detected and sync to all SRoU enabled devices. 306 H1 send packet with SRoU Header as below, H1 could use STUN detect 307 it's source public address, but consider the simplicity, the 1st hop 308 SRoU forwarder cloud update the source ip/port field in SRoU header. 310 IP/UDP Header { 311 Source IP: 192.168.1.2, 312 Destination IP: 10.1.2.2(SegmentList[1],I2 Pre-NAT public address), 313 Source Port: 5111, 314 Destination Port: 12345(SegmentList[1],I2 Pre-NAT public port), 315 } 316 SRoU Header { 317 Magic Num = 0x0 318 SRoU Length = 29 319 FlowID Length = 0x3 320 Protocol-ID = 0x1(IPv4), 321 FlowID = 0x123, 322 Source Address = 192.168.1.2, 323 Source Port = 5111, 324 Segment Left = 0x1, 325 Last Entry = 0x1, 326 SegmenetList[0] = 10.1.4.4:443(H2), 327 SegmenetList[1] = 10.1.2.2:12345(I2), 328 } 330 Figure 4: Type:0x1 H1-->I2 Packet Header 332 R1 is a NAT Device it will change the Source IP/Port to 333 10.1.1.1:23456. But this router may not have ALG function to modify 334 SRoU Header.Then packet will send to 10.1.2.2:12345. It will be NAT 335 again to I2. 337 After twice NAT, I2 Recieved packet as below: 339 IP/UDP Header { 340 Source IP: 10.1.1.1(H1 post NAT addr), 341 Destination IP: 192.168.99.2(I2 private addr), 342 Source Port: 23456(H1 post NAT port), 343 Destination Port: 8822(I2 private port), 344 } 345 SRoU Header { 346 Magic Num = 0x0 347 SRoU Length = 29 348 FlowID Length = 0x3 349 Protocol-ID = 0x1(IPv4), 350 FlowID = 0x123, 351 Source Address = 192.168.1.2, 352 Source Port = 5111, 353 Segment Left = 0x1, 354 Last Entry = 0x1, 355 SegmenetList[0] = 10.1.4.4:443(H2), 356 SegmenetList[1] = 10.1.2.2:12345(I2), 357 } 358 Figure 5: Type:0x1 H1-->I2, I2 Recieved Packet Header 360 if the (LastEntry == Segment Left) indicate I2 is the 1st hop SRoU 361 forwarder, It MUST apply ALG to update the Source Address/Port field 362 by the IP/UDP header. Then it will execute Segment Left - 1, and 363 copy SegmentList[0] to DA/Dport. Consider some interim router like 364 R2 has URPF checking, the SA/Sport will also updated to I2 SRoU 365 socket address. 367 I2-->H2 packet: 369 IP/UDP Header { 370 Source IP: 192.168.00.2(I2 Private), 371 Destination IP: 10.1.4.4(SegmentList[0]), 372 Source Port: 8822(I2 Private), 373 Destination Port: 443(SegmentList[0]), 374 } 375 SRoU Header { 376 Magic Num = 0x0 377 SRoU Length = 29 378 FlowID Length = 0x3 379 Protocol-ID = 0x1(IPv4), 380 FlowID = 0x123, 381 Source Address = 10.1.1.1(update by I2 ALG), 382 Source Port = 23456(update by I2 ALG), 383 Segment Left = 0x0(SL--), 384 Last Entry = 0x1, 385 SegmenetList[0] = 10.1.4.4:443(H2), 386 SegmenetList[1] = 10.1.2.2:12345(I2), 387 } 389 Figure 6: Type:0x1 I2-->H2 Packet Header 391 H2 will recieve the packet, and if the segment left == 0, it MUST 392 copy the Source Address and Port into IP/UDP Header and strip out the 393 SRoU Header and send to udp socket. It may cache the reversed 394 segmentlist for symmetric routing. 396 H2 send to UDP socket 398 IP/UDP Header { 399 Source IP: 10.1.1.1(Copied from SRoU Src field), 400 Destination IP: 10.99.2.2(Static NAT by R4), 401 Source Port: 23456(Copied from SRoU Src field), 402 Destination Port: 443(SegmentList[0]), 403 } 404 UDP Payload { 405 } 406 Figure 7: Type:0x1 H2 Send to UDP socket 408 3.2. Type:0x2, SRv6 format 410 IPv6 does not need to consider the NAT traversal case, In this mode 411 almost forwarding action is same as SRv6. This is only used for 412 application driven traffic steering(like CDN/LB usecase.). It has 413 some benefit interworking with QUIC, the pure userspace 414 implementation could provide additional flexibility. 416 For example some IOT sensor with legacy kernel stack does not support 417 SRv6 could use SRoU insert SRH in UDP payload, the 1st hop SRoU 418 forwarder could convert it to standard SRv6 packet. 420 3.3. Type:0x3, Compressed Segment List 422 3.3.1. Service Registration & Mapping 424 I1,I2 use SRoU port as source port to inital STUN[RFC5389] session to 425 SR mapping server, the mapping server could detect the Post NAT 426 address and assign SID for each host, and distribute IP/port-SID 427 mapping database to all the SRoU enabled host. 429 +------+----------------+------+ 430 | Host | Socket | SID | 431 +======+================+======+ 432 | I1 | 10.99.1.1:8811 | 1111 | 433 +------+----------------+------+ 434 | I2 | 10.1.2.2:12345 | 2222 | 435 +------+----------------+------+ 437 Table 5: sid mapping 439 In this mode the socket information could combined with IPv4 and 440 IPv6. 442 3.4. Optional TLV 444 3.4.1. SR Integrity TLV 446 SR Integrity Tag to validate the SRH. All fields in the SRH except 447 Segments Left fields need to be checked. 449 3.4.2. Micro-segmentation(uSeg) 451 Option-TLV could defined Sub-TLV to support Micro-segmentation 452 Security policy 453 OptionTLV { 454 0x1, uSeg{ 455 0x0, SRC_GROUP_ID, 456 0x1, DST_GROUP_ID, 457 0x2, APP_GROUP_ID, 458 0x3, SRC_DEVICE_ID, 459 0x4, DST_DEVICE_ID, 460 0x5, APP_ID, 461 } 462 } 464 Customer also could encode this microsegment policy header in flowID 465 field. 467 3.4.3. End.PacketInfo 469 This optional TLV defines extened packet info and Segment-end packet 470 edit function. Sub-TLV defines as below: 472 3.4.3.1. Type:0x0, VPN-ID 474 The SDWAN Router could use [I-D.ietf-quic-datagram] as VPN tunnel, 475 This Sub-TLV defined the VPN-ID inside the tunnel. 477 If SRoU header has this sub-TLV, the device MUST decrypt inner 478 payload and use the VPN-ID for inner packet destination lookup. 480 3.4.3.2. Type:0x1, Orginal Destination Address/Port 482 In SR Type 0x3, The original destination address/port cloud not 483 encode in 128bit field, it could be store in option TLV. 485 4. Usage 487 4.1. Traffic engineering over Internet 489 Client-------R1------------Internet--------------R2-----------Server 490 | | 491 | | 492 R3----V1----PubliCloud--------V2-----| 494 Figure 8: Traffic Engineering over internet 496 Many video/conferencing application requires traffic engineering over 497 IPv4 Internet, Webex/Zoom/Teams may setup V1,V2 in public cloud, The 498 client and server could encode the V1/V2 information in SRoU header 499 for traffic engineering 501 4.2. Multipath forwarding 503 Same as previously topoloy Figure 8, customer cloud ask server 504 transmit packet over different path, two path have same Flow-ID, QUIC 505 could be used in this case to provide multistream/multihoming 506 support. 508 4.3. Micro Segmentation 510 Same as previously topoloy Figure 8, the interim Router: R1/R2/R3, 511 V1,V2 could insert uSeg Sub-TLV based on client and server uSeg 512 identity, and other interim network equipment could based on this 513 sub-TLV implement security policy or QoS policy. 515 4.4. Container Network 517 C1----SideCar1-----L1-----S1------L2----SideCar2-------C2 518 | | 519 |------S2-------| 520 C1,C2: Container 521 L1,L2: Leaf switch 522 S1,S2: Spine switch 524 Figure 9: Service-Mesh & Container Network 526 SRoU with QUIC also could be used for container network interface, 527 especially for service-mesh sidecar. The sidecar could aware the 528 Datacenter underlay topology by BGP-LinkState, and use SRH select 529 best path to avoid congestion. At the same time, all traffic are 530 encrypted by [I-D.ietf-quic-tls]. 532 4.5. MPLS-SR with SDWAN 534 S1---INET(ipv4)----PE1------MPLS------PE2----S2 536 S1,S2: SDWAN Router 537 PE1,PE2: SR enabled MPLS PE 539 Figure 10: MPLS-SR with SDWAN 541 S1 will setup IPSec SA with S2 for end-to-end encryption, And it will 542 use BSID between PE1-PE2 for traffic engineering. 544 MPLS based BSID and IPv4 based locator could be encoded in uSID.A 545 distributed mapping table could be used to translate uSID to packet 546 action. 548 IP/UDP Header { 549 Source IP: H1, 550 Destination IP: PE1, 551 Source Port: srcport, 552 Destination Port: IPSec, 553 } 554 SRoU Header { 555 SegmentType = 0x1, 556 SR_HDR_Len = 2, 557 Last Entry = 0x0, 558 Segment Left = 0, 559 SegmenetList[0] = uSID: FC0:2222:3333:4444:: 560 } 562 Figure 11: Type:0x1 S1-->PE1 Packet Header 564 4.6. Cloud Native Network platform 566 Each of the SRoU forwarder only rely on a UDP socket, it could be 567 implement by a container. Customer could deploy such SRoU enable 568 container in multiple cloud to provide a cloud-angonostic solution. 569 All containers could be managed by K8S. 571 A distributed K-V store could be used for SRoU forwarder service 572 registration, routing(announce prefix), all the SRoU forwarder could 573 measue peer's reachability/jitter/loss and update link-state to the 574 K-V store. forwarding policy also could be sync by the K-V store. 575 Detailed information will be provided in another I.D(ETCD based 576 disaggregated SDN control plane). 578 SRoU forwarder also could be implement by BPF for container 579 communication. It will provide host level traffic engineering for 580 massive scale datacenter to reduce the West-East traffic congestion. 582 The best practice for SRoU is working with QUIC. SRoU with QUIC 583 transport protocol provides the following benefit for SDWAN : 585 * Stream multiplexing 587 * Stream and connection-level flow control 589 * Low-latency connection establishment 591 * Connection migration and resilience to NAT rebinding 593 * Authenticated and encrypted header and payload 594 SRoU add traffic-engineering and VPN capabilites for SDWAN. Many 595 existing SDWAN features could gain the benefits like: 597 * TCP optimization 599 * Packet duplication 601 5. Security Considerations 603 The SRoU forwarder must validate the packet, FlowID could be used for 604 source validation. It could be a token based solution, this token 605 could be assigned by controller with a dedicated expire time. 606 Source/Dest device ID and group cloud encode in flowid and signed by 607 controller, just like JWT. 609 A blacklist on controller k-v store could be implemented to block 610 device when the token does not expire. 612 6. IANA Considerations 614 6.1. SRoU with QUIC 616 The magic number in SRoU must be ZERO to distiguish with QUIC Long/ 617 Short packet format. 619 Acknowledgements 621 The following people provided substantial contributions to this 622 document: 624 * Bin Shi, Cisco Systems, Inc. 626 * Yijen Wang, Cisco Systems, Inc. 628 * Pix Xu, Cisco Systems, Inc. 630 * Xing James Jiang, Cisco Systems, Inc. 632 References 634 Normative References 636 [I-D.ietf-quic-datagram] 637 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 638 Datagram Extension to QUIC", Work in Progress, Internet- 639 Draft, draft-ietf-quic-datagram-00, 26 February 2020, 640 . 643 [I-D.ietf-quic-tls] 644 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 645 Work in Progress, Internet-Draft, draft-ietf-quic-tls-29, 646 9 June 2020, . 649 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 650 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 651 DOI 10.17487/RFC5389, October 2008, 652 . 654 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 655 "Encapsulating MPLS in UDP", RFC 7510, 656 DOI 10.17487/RFC7510, April 2015, 657 . 659 [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 660 W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, 661 DOI 10.17487/RFC8663, December 2019, 662 . 664 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 665 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 666 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 667 . 669 Informative References 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", BCP 14, RFC 2119, 673 DOI 10.17487/RFC2119, March 1997, 674 . 676 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 677 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 678 May 2017, . 680 Authors' Addresses 682 Kevin Fang 683 Cisco Systems, Inc. 685 Email: zartbot.ietf@gmail.com 687 Yinghao Li 688 Google, Inc. 690 Email: liyinghao@gmail.com 692 Feng Cai 693 Cisco Systems, Inc. 695 Email: fecai@cisco.com