Skip to main content

Early Review of draft-ietf-idr-sdwan-edge-discovery-18
review-ietf-idr-sdwan-edge-discovery-18-secdir-early-meadows-2024-12-10-00

Request Review of draft-ietf-idr-sdwan-edge-discovery-17
Requested revision 17 (document currently at 21)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2024-12-15
Requested 2024-10-15
Requested by Keyur Patel
Authors Linda Dunbar , Susan Hares , Kausik Majumdar , Robert Raszuk , Venkit Kasiviswanathan
I-D last updated 2024-12-10
Completed reviews Intdir Early review of -17 by Antoine Fressancourt (diff)
Rtgdir Early review of -18 by Ketan Talaulikar (diff)
Opsdir Early review of -17 by Daniele Ceccarelli (diff)
Secdir Early review of -18 by Catherine Meadows (diff)
Comments
Please review and provide comments.
Assignment Reviewer Catherine Meadows
State Completed
Request Early review on draft-ietf-idr-sdwan-edge-discovery by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/ft3Ww0R30NH98HArlisY8U4LWjw
Reviewed revision 18 (document currently at 21)
Result Has nits
Completed 2024-12-10
review-ietf-idr-sdwan-edge-discovery-18-secdir-early-meadows-2024-12-10-00
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Ready with NITS.

This ID describes the encoding of BGP UPDATE messages for the SD-WAN edge node
property discovery, for the case in which a BGP Route Reflector (RR) receives
the BGP UPDATE from SD-WAN edges and then propagates the information to the
intended peers.   This is generally considered the best architecture for
propagating updates,  because it requires the fewest communications.  After the
preliminaries the ID gives, in Section 3, a framework for SD-WAN edge
discovery, and in Section 4, an outline of constrained propagation of BFG
update.   Both of these are copiously illustrated with examples,  and help to
give an idea of the kinds of issues that might arise.  This part seems to be
more informational than descriptive; there are very few SHOULDs or MUSTs.

Sections 6 through 8ngive the meat of the ID: the messages, their format, and
the information that is encoded in them.  These are presented in detail. 
Section 9 deals with error handling.  This mainly repeats material that is in
RFC9012, and RFC7606, but it is useful to have for context.

Sections 10 and 11 deal with Manageability Considerations and Security
Considerations, respectively.

I like the approach taken by the this ID.  Instead of just giving the bare
specifications, (given in Section 6 through 8), the authors make the effort  to
provide the context behind them, so the reader can understand  how to use them.
 It also is I think the first ID I’ve seen with a manageability considerations
section, although the inclusion of such a section has been under discussion for
a long time.  In this case, the section recommends a simplified set of
information with which to set up IPsec Security Associations for the SD-WAN
hybrid tunnel, which makes it easier to avoid and identify mismatching SAs.

On the negative side, the presentation is a little rough around the edges.  
There are numerous typos and misspellings, many which should have been caught
by the spellchecker.  A careful proofreading is in order.

In addition, I noticed that  the list of acronyms in Section 2 has many missing
definitions:  I noticed

MPLS, SA, VRF, BGP, NRLI (different kinds of NRLI are defined, but not NRLI
itself), TLV and subTLV, GRE, VXLAN, and VNI

were missing before I gave up.  Please, if it’s an acronym, put it in!  Also,
RT-EC is out of alphabetical order.

Finally, I think that the Security Considerations Section should have a pointer
to the SA mismatch issue discussed in the Manageability Considerations Section,
since that is a security issue too.