Early Review of draft-ietf-idr-vpn-prefix-orf-20
review-ietf-idr-vpn-prefix-orf-20-secdir-early-kelly-2025-09-03-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.

This is an early review of an experimental draft.

This document defines an experimental Outbound Route Filter (ORF) called the
VPN Prefix ORF.

A number of acronyms are used without definition, including RBI, PE, and ASBR.
VRF is used in the abstract, and then later defined in the "Terminology"
section, but the others were not defined there. I'd suggest expanding all
acronyms on first use.

Section 4 page 5 says "In order to more finely control VPN routing, when not
all VRFs on a PE that are interested in VPN routes with a specific RD exceed
the limit, the PE MUST NOT send a VPN Prefix ORF entry." This sentence doesn't
make sense to me.

Section 6 page 15 says "Optional TLVs: carry the potential additional
information to give the extensibility of the VPN Prefix ORF mechanism.  Its
format is shown in Figure 6.  If one or more TLV(s) are not well formed, they
should be ignored" -- a little further down, it says "According to [RFC5291],
if any of the fields of a VPN Prefix ORF entry in the message contains an
unrecognized value, the whole specified ORF previously received is removed."

Should there be a difference between handling of "not well formed" vs.
"unrecognized"? What does "not well formed" mean? I found this a little
confusing.

The Security Considerations section says

"This draft does build upon [RFC5291].  A BGP speaker will maintain the VPN
Prefix ORF entries in an ORF-Policy table, this behavior consumes its memory
and compute resources.  To avoid the excessive consumption of resources,
[RFC5291] specifies that a BGP speaker can only accept ORF entries transmitted
by its interested peers."

The security considerations in RFC5291 simply state that it adds no security
considerations beyond those of RFC4271 (BGP), and I was unable to find anything
about resource consumption or interested peers in 5291 -- so I'm not sure what
to make of this reference.

It might be good to explicitly state that this draft adds no new security
considerations beyond those of 5291.