Hi, Please find below the Routing Area Directorate (rtgdir) review for draft-menon-svr-06. Review of draft-menon-svr-06 Type Early Review Team Routing Area Directorate (rtgdir) Reviewer Carlos Pignataro Summary: This is a complex document, comprehensive and detail-rich. It describes Juniper's Secure Vector Routing (SVR), which is an overlay inter-networking protocol that operates at the session layer. It seems to have use cases in SD-WAN and multi-cloud. As a meta-specification, or all-inclusive specification, a reader might end up wondering why agglutinate and not partition this into various documents. For example, there's a BFD specification embedded. That said, more details and more comprehensive is appropriate if not over-specified. The document has a logical organization of Theory, Examples, Protocol Spec, followed by a less clear set of main sections. The "Definitions" sub-section is also very useful. More Substantive: CMP: Has the BFD working group reviewed this? Particularly in the context of "BFD Metadata". If not, I recommend it is. See Section 5.1 CMP: Are BFD Control packets used unauthenticated as a kickstart? CMP: I would also request a TSV review of S7.3.1 CMP: "Use of BFD on Peer Pathways" --> Has the use of S-BFD [RFC 7880] been explored? It seems like an appropriate and simpler use-case. 9. IANA Considerations This document does not require any IANA involvement. CMP: There are many numbers and Types for TLVs and protocol headers defined. Why not IANA registration? If not IANA, how can the protocol be extended? CMP: This seems to be a serious oversight. Minor: Figure 8 CMP: Is there an "Ack" missing on the 3-way TCP handshake? CMP: Some IP addresses used are private and not documentation ones. All network interface-based tenant definitions are local to an SVR router. The tenant definitions on ingress to SVR MAY not match those on egress from SVR. This permits the use of different segmentation techniques in different networks. CMP: "MAY not"? Remember there is no "MAY NOT" CMP: Also, I recommend changing all "byte" to "octet" CMP: Is ICMP an attach here as well? S8 More Editorial: 3.1.4. Bring Peer Into Service . . . . . . . . . . . . . . . 23 CMP: "... Peer into Service..." 1.2. Overview An SVR implementation describes a network requirement semantically and shares this as SVR Metadata with a routing peer. The requirement to a peer is conveyed by means of a cookie, often referred to as first packet SVR Metadata, which is placed in the first packet of a session that is targeted towards the SVR Peer. SVR requires session state on every participating SVR router and sets up a bi-flow (matching forward and reverse flows) based on the requirement. Once CMP: What is a "bi-flow"? It's only used once, should this be a "bidirectional flow" instead? Router Certificate: A Certificate Signing Request (CSR) is created by every router that attaches to an SVR network that contains the routers UUID, Authority, and public key. The resulting certificate is used to authenticate SVR routes on Peer Pathways. The certificate (and public key) are fairly long lived, and seldom used. Keying procedures use derived key functions based on the certificate. CMP: "...The certificate and the public key are..." or "...The certificate is..." 2.4. SVR Metadata Handshake To ensure the SVR Metadata is received and understood between peers, a handshake is performed for each routed session. A sender of SVR metadata confirms it's receipt by receiving a subsequent backward SVR metadata from its peer. Senders must include CMP: "... confirms its receipt..." CMP: Now, confirm receipt by receiving? Sounds strange... 2.5. Pathway Obstructions and Changes Firewalls and middleboxes that sit along a peer pathway may not propagate TCP SYN messages with data in the payload (Despite being valid), or may verify sequence numbers in TCP streams (which are invalidated due to the inclusion of SVR Metadata). The two devices CMP: This sentence needs rewriting... "may not ... or may ..." is not clear. 2.8. Optional use of Tenants and Service names for Routing SVR Metadata contains contextual IP Addresses (sources, destinations, and Waypoints) along with textual service names (i.e., Zoom, Office365, etc.). The SVR routers can apply policies and route sessions based on the textual names if they have a route information base that contains service names. When performing name based routing, a destination NAT is often required when exiting the SVR CMP: "...name-based routing..." 3.2. CIDR based SVR Peer FIB Entries To route packets and sessions of packets onto SVR Peer Pathways, a route lookup must return an indication of either a SVR peer pathway, or a SVR peer. CMP: "or an SVR" CMP: This should be checked throughout the document, s/a SVR/an SVR/g; 3.4. SVR Security Definitions For basic SVR functionality to work between peers, there must be a Authority wide provisioned set of rules. These rules include: CMP: "an Authority" 3.7.1.11. Sending the First Packet The packet length and checksum is corrected, and the packet is transmitted. The sending side will include the same exact SVR CMP: "...are..." To implement false positive logic, SVR implementations MUST insert an empty SVR Metadata header (12 byte header with 0 TLVs). This creates CMP: "12-octet header" CMP: I recommend changing all "byte" to "octet" For efficiency reasons, when verifying an Time Based HMAC signature, CMP: "a Time-based HMAC" tenant and service. Absence of a applicable SVR policy prevents SVR sessions from being established. The deny by default approach is RECOMMENDED. CMP: "an applicable" Both routers have learned each other's IP Address and have determined there are no NAT's between them CMP: "no NATs" The key and its index is then shared with all known peers using an Encrypted BFD Metadata that contains SVR_key_data. The Current Peer CMP: "...index are then..." Thanks! Carlos.