[RTG-DIR]Rtgdir early review of draft-menon-svr-06

[Carlos Pignataro via Datatracker <[e-mail]>]

Reviewer: Carlos Pignataro
Review result: Has Issues

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.