Re: [GROW] AD Review of draft-ietf-idr-bgp-open-policy-15

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi Alvaro,

Sorry for the delay in responding. Thank you for the new set of comments. Our responses are inline below marked with [AA/KS-2]. We have uploaded version-17 with changes based on your suggestions (either in the round-2 set of comments or the email discussions that followed). 

Please let us know if we have missed anything or if you have new comments.

Regards,
Sriram / Alexander 
 
---------------------------------------------------

Re: [Idr] AD Review of draft-ietf-idr-bgp-open-policy-15
Alvaro Retana <[e-mail]> Wed, 18 August 2021
On August 10, 2021 at 12:23:09 PM, Alexander Azimov wrote:

Alexander/Sriram:

The document has improved significantly!  Thank you for the hard work!!

[AA/KS-2] Great to hear that. Thank you.

I have just a couple of responses inline, and have appended a quick
review of -16.  In general, most of the remaining items should be easy
to address.  The only significant issue I want to discuss some more is
related to confederations (see below).  All these comments can be
considered last call comments.

> Instead of returning the document to the WG, and because it is short,
> I am including a long list of suggestions below. Given all the
> proposed changes, we will eventually need to run a new WGLC explicitly
> including the grow WG -- I have cc'd them in this message as well.

Sue: Please issue a WGLC (cc'ing grow) for this document.  A week
should be enough.

Once the WGLC is done and we have an updated document I will start the IETF LC.

Thanks!

Alvaro.

...
> 124 2. Peering Relationships
...
> [major] "MUST NOT send...prefixes learned from..." Again, given that
> the roles are session-based, how do you expect this requirement to be
> satisfied? IOW, how would an eBGP session in routerA know that a
> specific prefix was learned from a Peer (or not) at routerB on the
> other side of the network?
>
[AA/KS] There are some details that need to be understood. If a route was
[AA/KS] advertised by a Peer, Provider, or RS and it is not marked with OTC,
[AA/KS] then the ingress router adds an OTC Attribute with the AS number of
[AA/KS] the sender (remote AS). See revised Section 4. The mere presence of
[AA/KS] an OTC indicates to the egress router that the route was learned from
[AA/KS] a Peer, Provider, or RS and it can be advertised only to customers.
[AA/KS] The absence of an OTC Attribute indicates to the egress router that
[AA/KS] the route was either advertised by a Customer or originated by the
[AA/KS] local AS. If a route received from a Customer at an ingress router has
[AA/KS] an OTC Attribute, then the route is rejected by ingress policy. So, a
[AA/KS] customer route or a locally originated route never has OTC attached
[AA/KS] when received at the egress router. Now, this is explained well in the
[AA/KS] revised Section 4 in the updated draft.

Please add something like that (shorter) to §2.  Suggestion>

   As specified in §4, the Only to Customer (OTC) Attribute is used to
   identify all the routes in the AS that have been received from a Peer,
   Provider or RS.

[AA/KS-2] Done.

...
> What about confederations? I understand the intent here is to prevent
> leaks in the Internet, so a private ASN shouldn't show up there. §5
> hints at the BGP Role Capability being applicable only to eBGP, but it
> doesn't normatively constrain it to "normal" eBGP sessions. Should
> it? I think it should. If you do too, what should a receiver do if
> the Capability is received over iBGP or an eBGP session that is not
> "normal" -- ignore sounds like a good thing.
>
[AA/KS] Yes, “ignore” -- meaning do not act on it and let the OTC Attribute
[AA/KS] propagate -- seems correct. IMO, the OTC processing at the ingress/
[AA/KS] egress of the confederation will happen correctly as per this draft
[AA/KS] (RFC). So, nothing specific to confederations needs to be said.
[AA/KS] Please advise.

The question is this:  §4 says (talking about egress policy) that "an
OTC Attribute MUST be added with a value equal to the AS number of the
local AS".  Should a router that sends an UPDATE to a member of the
confederation in a different ASN include the OTC?

Note that rfc5065 says this:

   A member of a BGP confederation MUST use its Member-AS Number in all
   transactions with peers that are members of the same confederation as
   the local BGP speaker.

...and rfc4271 defines eBGP simply as:

   A peer in a different AS is referred to as an external peer, while a
   peer in the same AS is referred to as an internal peer.  Internal BGP
   and external BGP are commonly abbreviated as IBGP and EBGP.

So, if a confederation peer is in a different ASN, then it is an eBGP
peer.  The egress policy should then result in an OTC with the a
Member-ASN.  Which results in the route not being propagated to a
Provider (assuming the confederation is a Customer).

If the OTC is ignored (as suggested above) and the route is advertised
to the Provider, who will not use the route anyway because it has an
OTC.

This assumes that the intra-confederation eBGP sessions are configured
to use BGP Roles.  Yes, I think this won't be too common...but it
could happen.

Thinking out loud -- I see a couple of possibilities:

1- Say that the rules in §4 don't apply if there is a private ASN in
it.  But this constrains other applications, specially ones where the
Customer doesn't have its own ASN.

2- Require that any OTCs added inside a confederation be removed
before a route is advertised externally.  This path is against this
text:

   Once the OTC Attribute has been set, it MUST be preserved unchanged.

Suggestion>
   A BGP speaker that advertises a route to a BGP speaker located in a
   neighboring autonomous system that is not a member of the local
   confederation [rfc5065] MUST remove any OTC Attributes whose value
   matches an ASN in the removed AS_CONFED_SEQUENCE or AS_CONFED_SET in
   the AS_PATH.  Otherwise, the OTC Attribute MUST be preserved unchanged.

[AA/KS-2] As agreed in the recent email thread about confederations, the following paragraph has been added in Section 4:

   The procedures specified in this document are NOT RECOMMENDED to be
   used between autonomous systems in an AS Confederation [RFC5065].  If
   an OTC Attribute is added on egress from the AS Confederation, its
   value MUST equal the AS Confederation Identifier.  Also, on egress
   from the AS Confederation, an UPDATE MUST NOT contain an OTC
   Attribute with a value corresponding to any Member-AS Number other
   than the AS Confederation Identifier.

[AA/KS-2] We have also added this additional paragraph involving private ASNs (data center etc.) as agreed in the more recent emails:

   The procedures specified in this document in scenarios that use
   private AS numbers behind an Internet-facing ASN (e.g., a data center
   network [RFC7938] or stub customer) may be used, but any details are
   outside the scope of this document.  On egress from the Internet-
   facing AS, the OTC Attribute MUST NOT contain a value other than the
   Internet-facing ASN.

[AA/KS-2] Please let us know if the positioning of the above two paragraphs in Section 4 seems fine or if you feel they (both or one) belong in the Additional Considerations section. 

[AA/KS-2] I addition, the following paragraph is a slightly modified version of a previously existing paragraph in Section 4:

   Once the OTC Attribute has been set, it MUST be preserved unchanged
   (this also applies to an AS Confederation).


rfc5065 would need to be a Normative reference.

[AA/KS-2] Done.

[End Comments -15]


[Start of Review -16]

[Line numbers from idnits.]

...
124	1.1.  Terminology

126	   In the rest of this document, the term "Peer" is used to refer to a
127	   "lateral peer" for simplicity.  Also, the terms Provider and Customer
128	   are used to refer to a transit provider and a transit customer,
129	   respectively.  Further, the terms RS and RS-Client are used to refer
130	   to a Route Server and its client, respectively.

[major] "lateral peer" is used in several places but not explicitly
defined.  What is a lateral peer?  How is it different from a
"regular" peer?  I looked at rfc7909 but couldn't find an explicit
definition there either -- did I miss it?  If so, then there's no need
to add anything else. :-)

[AA/KS-2] RFC 7908 says: The term "lateral" here is synonymous with "non-transit" or "peer-to-peer". The RFC also repeats several times the phrase “a lateral (i.e., non-transit) peer”. We do reference RFC7908 when we first use the term “lateral” in Sec. 1.

[AA/KS-2]  We also made this substitution in Sec. 1.1:
s/In the rest of this document, the term "Peer" is used to refer to a "lateral peer" for simplicity./
In the rest of this document, the term "Peer" is used to refer to a "lateral (i.e., non-transit) peer" for simplicity./

...
173	3.  BGP Role

175	   The BGP Role characterizes the relationship between the eBGP speakers
176	   forming a session.  BGP Role is configured on a per-session basis.
177	   An eBGP speaker SHOULD configure the BGP Role locally based on the
178	   local AS's knowledge of its Role.  The only exception is when the
179	   eBGP connection is complex (see Section 5).  BGP Roles are mutually
180	   confirmed using the BGP Role Capability (described in Section 3.1) on
181	   each eBGP session between autonomous systems (ASes).  One of the
182	   Roles described below SHOULD be configured at the local AS for each
183	   eBGP session with a neighbor (remote AS) (see definitions in
184	   Section 1.1).

[minor] There's some redundant text...

Suggestion>
   The BGP Role characterizes the relationship between the eBGP
   speakers forming a session.  One of the Roles described below
   SHOULD be configured at the local AS for each eBGP session (see
   definitions in Section 1.1) based on the local AS's knowledge
   of its Role.  The only exception is when the eBGP connection is
   'complex' (see Section 5).  BGP Roles are mutually confirmed
   using the BGP Role Capability (described in Section 3.1) on
   each eBGP session.

[AA/KS-2]  Done.

...
227	3.2.  Role Correctness
...
251	   If the BGP Role Capability is sent, but one is not received, then the
252	   connection MAY be rejected using the Role Mismatch Notification (code
253	   2, subcode 8); this mode of operation is called the "strict mode".
254	   For backward compatibility, if the BGP speaker does not receive the
255	   capability from its peer, it SHOULD ignore the absence of BGP Role
256	   Capability and proceed with session establishment; this SHOULD be the
257	   default non-strict mode of operation.  In this case, the locally
258	   configured BGP Role is used for the procedures described in
259	   Section 4.

[major] "strict mode"

The text is not strict about "strict mode": rejecting the session is
optional.  You also added this text to the Security Considerations:

   Setting the strict mode of operation for BGP Role negotiation as the
   default may result in a situation where the eBGP session will not
   come up after a software update.  Such an implementation of this
   document is strongly discouraged.

Even if strict mode is not the default, configuring it may still
result in the same problem.   If discouraged then why even talk about
it?

Suggestion>

   For backward compatibility, if the BGP Role Capability is sent but
   one is not received, the BGP Speaker SHOULD ignore the absence of
   the BGP Role Capability and proceed with session establishment.
   The locally configured BGP Role is used for the procedures described
   in Section 4.

   ... later on in the security section ...

   Strictly requiring the presence of the BGP Role Capability may result
   in a situation where the eBGP session will not come up after a software
   update or configuration change.  Such an implementation of this document
   is strongly discouraged.

Note that this suggestion simplifies the text (no more "MAY...strict"
"contradiction") while not changing the functionality.

If the strict requirement is not good, is there a reason to not always
require the backwards compatible behavior?  If implementations already
reset sessions then I guess we can keep the "SHOULD".

[AA/KS-2]  Done. The suggested rewording is very helpful (eliminates the “contradiction” and adds clarity). We prefer to keep SHOULD rather than change it to MUST.

[AA/KS-2]  Since it says SHOULD, it would be appropriate to mention when it may not be the case. Also, we do want to still mention the possibility of a strict mode. So, the following paragraph without any normative language is added:

   An operator may choose to apply a "strict mode" in which the receipt
   of a BGP Role Capability from the remote AS is required.  When
   operating in the "strict mode", if the BGP Role Capability is sent,
   but one is not received, then the connection is rejected using the
   Role Mismatch Notification (code 2, subcode 8).  See comments in
   Section 7.

[AA/KS-2] This paragraph is consistent with what was said in the intro: "An eBGP speaker may require the use of this capability and confirmation of BGP Role with a neighbor for the BGP OPEN to succeed.” 

[AA/KS-2] In Section 7 (Security Section), we have added (slight rewording of your suggestion above):

   Setting the strict mode of operation for BGP Role negotiation as the
   default may result in a situation where the eBGP session will not
   come up after a software update.  Implementations with such default
   behavior are strongly discouraged.

261	   If an eBGP speaker receives multiple but identical BGP Role
262	   Capabilities with the same value in each, then the speaker MUST
263	   consider it to be a single BGP Role Capability and proceed [RFC5492].
264	   If multiple BGP Role Capabilities are received and not all of them
265	   have the same value, then the BGP speaker MUST reject the connection
266	   using the Role Mismatch Notification (code 2, subcode 8).

[major] s/the speaker MUST...[RFC5492]/the speaker must...[RFC5492]

This behavior is already specified in rfc5492, no need to specify it here again.

[AA/KS-2]  Yes. Done.

...
271	4.  BGP Only to Customer (OTC) Attribute
...
316	   The OTC Attribute may be set by the egress policy of remote AS or by
317	   the ingress policy of local AS.  In both scenarios, the OTC value
318	   will be the same.  This makes the scheme more robust and benefits
319	   early adopters.

[nit] s/egress policy of remote AS or by the ingress policy of local
AS/egress policy of the remote AS or by the ingress policy of the
local AS

[AA/KS-2]  Done.

...
334	   The described ingress and egress policies are applicable only for
335	   unicast IPv4 and IPv6 address families and MUST not affect other
336	   address families by default.  The operator MUST NOT have the ability
337	   to modify the policies defined in this section.

[major] s/MUST not/MUST NOT

[AA/KS-2]  Done.

[major] "MUST not affect other address families by default"   Maybe
"MUST NOT be applied to other address families by default" ??

[AA/KS-2]  Yes. That seems to be the better way to say it. Done.

339	5.  Additional Considerations
...
349	   No Roles SHOULD be configured on a 'complex' eBGP session (assuming
350	   it is not segregated) and in that case, the OTC Attribute processing
351	   MUST be done relying on configuration on a per-prefix basis.  Also,
352	   in this case, the per-prefix peering configuration MUST follow the
353	   same definitions of peering relations as described in Section 2.
354	   However, in this case, there are no built-in measures to check
355	   correctness of the per-prefix peering configuration.

[major] This paragraph requires the use of OTC in cases where a Role
is not configured.  I don't feel comfortable with that because it is
equivalent to mandating behavior for eBGP sessions that don't support
this document.  I would prefer it if this was worded as a
recommendation (non-normative).

Suggestion>
   No Roles SHOULD be configured on a 'complex' eBGP session (assuming
   it is not segregated).  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 correctness of
   the per-prefix peering configuration.

[AA/KS-2]  Yes, agree. The suggested non-normative wording is better. Done.


357	   The incorrect setting of BGP Roles and/or OTC Attributes may affect
358	   prefix propagation.  Further, this document does not specify any
359	   special handling of incorrect AS numbers in the OTC Attribute.  Such
360	   errors should not happen with proper configuration.

[] Let's take out the last sentence.  The rest of the paragraph
implies that the value of the ASN doesn't matter/shouldn't be checked
(because it could be set elsewhere)...but calling it an error gives it
the importance that it doesn't have.

[AA/KS-2]  Removed the last sentence. Done.

362	6.  IANA Considerations

364	   IANA has registered a new BGP Capability described in Section 3.1 in
365	   the "Capability Codes" registry's "IETF Review" range [RFC5492].  The
366	   description for the new capability is "BGP Role".  IANA has assigned
367	   the value 9 [to be removed upon publication:
368	   https://www.iana.org/assignments/capability-codes/capability-
369	   codes.xhtml].  This document is the reference for the new capability.

[nit] s/BGP Capability described in Section 3.1/BGP Capability (Section 3.1)

[AA/KS-2]  Done.

...
406	7.  Security Considerations
...
428	   Removing the OTC Attribute or changing its value can limit the
429	   opportunity of route leak detection.  Such activity can be done on
430	   purpose as part of a Man in the Middle (MITM) attack.  For example,
431	   an AS can remove the OTC Attribute on a received route and then leak
432	   the route to its transit provider.  Such malicious activity cannot be
433	   prevented without cryptographically signing the BGP UPDATE [RFC8205]
434	   or out of band detection [I-D.ietf-sidrops-aspa-verification], but
435	   such schemes are beyond the scope of this document.

[] As you may know, the IETF has been discussing the use of more
inclusive terminology.  Please consider changing this phrase: "on
purpose as part of a Man in the Middle (MITM) attack."

Suggestions:
"on purpose by a rogue router."
"on purpose as part of an on-path attack."

https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/

[AA/KS-2]  Inclusive terminology is very important. Thanks for catching it. Done.


[major] "Such malicious activity cannot be prevented without
cryptographically signing the BGP UPDATE [RFC8205] or out of band
detection [I-D.ietf-sidrops-aspa-verification], but such schemes are
beyond the scope of this document."

BGPSec doesn't protect against the removal of the OTC -- or protect
any other attribute (except for the AS_PATH).

As far as I can tell, I-D.ietf-sidrops-aspa-verification doesn't
protect against the removal of the OTC either, and could only detect
anomalies related to the Customer/Peer(s) relationship.

The point here is that the potential mitigation would either not work
in this case or only provide a partial solution.  I think we would be
better off simply recognizing that this threat is not new in BGP and
that it may affect any attribute.

[AA/KS-2]  The revised paragraph reads as follows:

   Removing the OTC Attribute or changing its value can limit the
   opportunity of route leak detection.  Such activity can be done on
   purpose as part of an on-path attack.  For example, an AS can remove
   the OTC Attribute on a received route and then leak the route to its
   transit provider.  This kind of threat is not new in BGP and it may
   affect any Attribute (BGPsec [RFC8205] offers protection only for the
   AS_PATH Attribute).

...
448	8.1.  Normative References
...
460	   [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis",
461	              RFC 4272, DOI 10.17487/RFC4272, January 2006,
462	              <https://www.rfc-editor.org/info/rfc4272>.

[major] This reference can be informative.

[AA/KS-2]  Done.

[EoR -16]