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.

I have marked this document as "Not ready" due to, what I perceive as, lack of clarity related to security properties. For example:

Section 5.1: "Are similar" - are they the same or not? If not, please describe the differences.

Section 5.2.1: "Repurposing IPv6 Unicast family to carry Transport routes also may impact the operational complexity and security aspects in the network." Impact the security aspects how? When or under what circumstances? How to protect against regressions?

Section 8:

- "This document does not change the underlying security issues inherent in the existing BGP protocol"
  a) Stating that there are "inherent security issues" in BGP reads strange to me.
  b) A document cannot really change security issues, but the protocol or the constructs defined in the document may.

  Therefore, suggest changing to something like: "The constructs defined herein do not change the security properties of the BGP protocol."

- "This document follows the security considerations" - not sure what "follow" security considerations mean. Does it mean that all of the Security Considerations of BGP - CT apply.? In particular, is the Walled Garden approach *recommended* to prevent the risk of unintended route escapes, does it have to be adopted, or what? "Followed" is again unclear.

- "This SAFI routes ..." - I cannot parse this, but suspect it was meant to say that the SAFI routes described open up a new avenue of attack?

- "In order to mitigate the risk of the diversion of traffic from its intended destination, BGPsec solutions ([RFC8205] and Origin Validation [RFC8210]) may be extended in [sic] future" - this text seems to say that there currently is no mitigation against the aforementioned diversion attacks. Is this correct? If so, text should state so. If correct, I would also not consider such a gap acceptable for a standards-track document, but since this is Experimental I guess it may be acceptable.

- That said, the last paragraph of Section 8 indicates there are mechanisms to completely mitigate diversion attacks, which leaves me confused. Perhaps the difference is between SAFIs other than 1 and SAFI 1? If so, I would suggest switching the order of the last two paragraphs, and change the non-Internet SAFI to: "For non-Internet SAFIs (SAFIs other than 1), BGPsec solutions ([RFC8205] and Origin Validation [RFC8210]) may be extended to mitigate the risk of the diversion of traffic from its intended destination" - though the "may" still feels unsatisfactory.

/M