Subject: [Idr] Benjamin Kaduk's No Objection on draft-ietf-idr-bgp-open-policy-19: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 17 Jan 2022 11:46:05 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-idr-bgp-open-policy-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Alexey Melnikov for the secdir review and re-review; I echo
his comments about the usefulness of the mechanism and the quality of
the security considerations section.  Thank you for this document!

I'm rather sympathetic to John's remarks about "policy" vs (e.g.)
"procedures".

This document establishes the generic-sounding "BGP Role" capability and
a registry for the corresponding values, but the focus of the technical
mechanisms presented here is to avoid route leakage.  Might there be
other future consumers of BGP Role (perhaps including use of Role for
iBGP to get in-band confirmation of the relationship between peers) that
are unrelated to avoiding route leakage?  Is there anything in this
document we might change to facilitate such future extensions?

Section 6

Subsections for the individual actions/registries being acted upon/in
might aid readability.

Section 8.1

RFC 7908 is referenced only once, in a location that doesn't obviously
induce a normative requirement.  It does seem like a good thing to read
before implementing this document, though, so maybe the takeaway is to
add more references to it rather than demote it to informative.

NITS

Section 1

   Existing approaches to leak prevention rely on marking routes by
   operator configuration, with no check that the configuration
   corresponds to that of the eBGP neighbor, or enforcement that the two
   eBGP speakers agree on the relationship.  This document enhances the

I suggest adding an adjective to "relationship" (maybe "topology"?).

   BGP OPEN message to establish an agreement of the relationship on
   each eBGP session between autonomous systems in order to enforce

Similarly here, though maybe "nature of the relationship" in this
instance.

Section 2

   A BGP speaker may apply policy to reduce what is announced, and a
   recipient may apply policy to reduce the set of routes they accept.
   Violation of the above rules may result in route leaks.  Automatic
   enforcement of these rules should significantly reduce route leaks
   that may otherwise occur due to manual configuration mistakes.

If I understand correctly, "violation of the above rules" refers to the
enumerated rules a few paragraphs prior, and specifically not to the two
applications of policy mentioned in the preceding sentence.  Assuming
that's correct, then it seems useful to clarify the transition between
sentences, perhaps "use of such policies that violate the rules listed
above may result in route leaks" or "when these policies violate the
rules listed above, route leaks may occur".

Section 5

   An operator may want to achieve an equivalent outcome by configuring
   policies on a per-prefix basis to follow the definitions of peering
   relations as described in Section 2.  However, in this case, there
   are no built-in measures to check the correctness of the per-prefix
   peering configuration.

"built-in" is perhaps needlessly vague; we might say "in-band" or "no
measures in the protocol" instead.

Section 7

   Removing the OTC Attribute or changing its value can limit the
   opportunity of route leak detection.  Such activity can be done on

I think s/of/for/

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Fri, 21 Jan 2022 00:38:12 +0000

Hi Benjamin,

Thank you for the comments. We'll include changes based on your suggestions in v-21. Please let us know if the responses (proposed changes) provided inline seem good to you.

>I'm rather sympathetic to John's remarks about "policy" vs (e.g.) "procedures".

Done already in version-20.

>This document establishes the generic-sounding "BGP Role" capability and a registry for the corresponding values, but the focus of the technical mechanisms presented here is to avoid route leakage.  Might there be other future consumers of BGP Role (perhaps including use of Role for iBGP to get in-band confirmation of the relationship between peers) that are unrelated to avoiding route leakage?  Is there anything in this document we might change to facilitate such future extensions?

We feel that BGP Role can be used by future consumers per their needs (as applicable) and nothing in this document needs to change at present.

>Subsections for the individual actions/registries being acted upon/in might aid readability.

If OK with you, we'll leave Section 6 as is. We can do this later if IANA folks also see an advantage. (We looked at other RFCs, e.g., RF 8205, where multiple IANA actions were required but subsections were not used.)

>RFC 7908 is referenced only once, in a location that doesn't obviously induce a normative requirement.  It does seem like a good thing to read before implementing this document, though, so maybe the takeaway is to add more references to it rather than demote it to informative.

Yes, two more references to RFC 7908 later in the document have been added in suitable places. We keep it as a normative reference. One of those references is the addition of a sentence in Section 2.1:

Old text:

   The terms defined and used in this document (see below) do not

   necessarily represent business relationships based on payment

   agreements.  These terms are used to represent restrictions on BGP

   route propagation, sometimes known as the Gao-Rexford model [Gao].

New text:

   The terms defined and used in this document (see below) do not

   necessarily represent business relationships based on payment

   agreements.  These terms are used to represent restrictions on BGP

   route propagation, sometimes known as the Gao-Rexford model [Gao].

   The terms Provider, Customer, and Peer used here are synonymous to

   the terms "transit provider", "customer", and "lateral (i.e., non-

   transit) peer", respectively, used in [RFC7908].

>I suggest adding an adjective to "relationship" (maybe "topology"?).

We made this substitution:

s/ relationship/ peering relationship/

>Similarly here, though maybe "nature of the relationship" in this instance.

Here also, we made the same substitution:

s/ relationship/ peering relationship/

>If I understand correctly, "violation of the above rules" refers to the enumerated rules a few paragraphs prior, and specifically not to the two applications of policy mentioned in the preceding sentence.  Assuming that's correct, then it seems useful to clarify the transition between sentences, perhaps "use of such policies that violate the rules listed above may result in route leaks" or "when these policies violate the rules listed above, route leaks may occur".

The second sentence was not referring to the first. The phrase "Violation of the above rules" was merely referring to the route propagation rules described earlier as you correctly understand. We now use two paragraphs to be clear. Following your suggestion, we have made the following change:

Old text:

New text:

   Violation of the route propagation rules listed above may result in

   route leaks [RFC7908].  Automatic enforcement of these rules should

   significantly reduce route leaks that may otherwise occur due to

   manual configuration mistakes.

   peering configuration.

>"built-in" is perhaps needlessly vague; we might say "in-band" or "no measures in the protocol" instead.

We made this substitution per your suggestion:

s/built-in/in-band/

Another choice is to use "automated" or "more automated".

>I think s/of/for/

Done.

Sriram / Alexander

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Fri, 21 Jan 2022 04:19:02 +0000

Hi Benjamin,

Please ignore the previous email. I am resending because there was a line spacing problem earlier.  :(

Old text:

New text:

Old text:

New text:

Done.

Sriram / Alexander