[secdir] Re: [Idr] draft-ietf-idr-vpn-prefix-orf-20 early Secdir review

[Keyur Patel <[e-mail]>]

Hi Scott,

Thanks for the draft review. Can you please confirm if version 22 addresses all your concerns?

Best Regards,
Keyur

From: Wei Wang <[e-mail]>
Date: Wednesday, September 3, 2025 at 11:03 PM
To: Scott Kelly <[e-mail]>, secdir <[e-mail]>
Cc: draft-ietf-idr-vpn-prefix-orf.all <[e-mail]>, idr <[e-mail]>
Subject: Re: [Idr] draft-ietf-idr-vpn-prefix-orf-20 early Secdir review
Hi Scott,

Thanks for your comments! Please see my inline replies with [WW].

Best Regards,
Wei
Original
________________________________
From: Scott Kelly via Datatracker <[e-mail]>
Date: 2025年9月4日 03:59
To: secdir <[e-mail]>
Cc: draft-ietf-idr-vpn-prefix-orf.all <[e-mail]>, idr <[e-mail]>
Subject: [Idr] draft-ietf-idr-vpn-prefix-orf-20 early Secdir review

Document: draft-ietf-idr-vpn-prefix-orf
Title: VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4
Reviewer: Scott Kelly
Review result: Has Issues

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.[WW]: We will add all acronyms we used in this draft to the "Terminology", and  expand all acronyms on the first use in -v21.

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.[WW]: The core meaning of this sentence is: A PE must "reject routes on demand" --- it will only reject a specific type of routes (those carrying a particular RD) when all VRFs that require this type of routes can no longer accommodate them. As long as there is even one VRF that can still accommodate such routes, the PE must not reject them. Only in this way can it "achieve more refined control over VPN routes" and avoid unnecessary route loss.


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.
[WW]: We will modify the "not well formed" to "unrecognized" in -v21.
And to keep the context consistency, the content will be modified as follow:
"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 unrecognized, the whole VPN Prefix ORF entry SHOULD be removed."


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.
[WW]: We will make this modification in -v21.

_______________________________________________
Idr mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]

[EXTERNAL]