Re: [Idr] ttRE: FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt

[[e-mail]]

Alexander,

Please see inline [Bruno]

TL;DR: If an AS using tunneling between ASBRs there is no risk of forwarding loops due to inconsistent IBGP routes. If not, there are. AFAIK this spec address the Internet and needs to also address ASes using hop by hop IP forwarding.




Orange Restricted
From: Alexander Azimov <[e-mail]>
Sent: Thursday, February 17, 2022 10:45 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]>
Cc: Sriram, Kotikalapudi (Fed) <[e-mail]>; [e-mail]; Alvaro Retana (aretana) <[e-mail]>; [e-mail]; Susan Hares <[e-mail]>; Jeffrey Haas <[e-mail]>
Subject: Re: ttRE: [Idr] FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt

Bruno,

CLUSTER_LIST is an optional non-transitive attribute. It makes quite reasonable to have different processing for iBGP and eBGP.
OTC, is an optional transitive attribute with an effect on the routing selection process. So, I don't feel that CLUSTER_LIST is a good reference.
[Bruno] The question was whether RFC7606 allowed for different behavior based on iBGP or eBGP. Note also that RFC 4271 decision process makes a difference between iBGP and eBGP: the reason is that in order to avoid forwarding loops inside the AS we need routing consistency within the AS, while on EBGP boundary we are free to filter routes without risk of loops.
https://datatracker.ietf.org/doc/html/rfc4271#section-9.1.1


The common way to use communities (RFC1997 or RFC8092) is an action upon receipt from eBGP neighbor, optional additional marking, and action at the export policy with another eBGP neighbor. In that form, there is much in common with OTC and possible issues that we are discussing.

Let's go back to the side effects of accepting such malformed attributes from iBGP neighbors while filtering them when received from eBGP neighbors.
Let's say we have a network with two routers R1 and R2 and a route reflector (RR). Between R1 and R2 there are only P devices - common today MPLS core.

R1 adds OTC at the receipt and due to bugs in the implementation, it has incorrect length.
The RR detects it but passes by, while R2 is not upgraded and processes OTC as an unknown transitive path attribute, just passing it to its eBGP neighbor.
As a result, such routes may be filtered several hops away. And IMO it will be quite hard to debug.
[Bruno] As OTC is a transitive attribute, what you describe in the specific case of error, happens much more generally (e.g. RR does not support OTC). So you are essentially saying that OTC "is quite hard to debug" at least while not universally supported. (5-10 years is the typical duration IMHO, assuming success)

Another issue will happen if R2 does a proper check, but due to other BGP path attributes or igp cost chooses the route with malformed attribute among possible alternatives.
With the 'treat-as-withdraw' approach it has a chance to pick an alternative route, with your current suggestion it will be limiting the number of prefixes that are sent to its customers.
[Bruno] In your AS using tunneling, hence not subject to forwarding loops inside the AS, you are free to add a policy to depref/filter such a route. But in the general case, this is not safe.

I see your point of getting rid of loops in the case of a network with multiple IP lookups in the global table while the packet travels through its core. But I'm not sure if this reason is enough to change error handling cause it may bring undesirable side effects for modern design network that uses tunneling.
[Bruno]
- First I don't agree that "modern" networks use tunneling and hence we can design a solution specifically for the networks using tunneling and don't address the IP networks doing hop by hop routing (especially as we are talking about the Internet using IP.)
- Now if you do want to restrict the solution to network using tunnels, do say so in the spec, and handle the consequences.


And as the same technique may apply to other optional transitive attributes such as communities or large communities I still believe that discussion should be done in terms of updating RFC7606.
[Bruno] OTC is a special case as the attribute is not considered within the AS (by design and enforced in the standard track document). Community are different and more general tools.

--Brunp


ср, 16 февр. 2022 г. в 19:44, <[e-mail]<mailto:[e-mail]>>:
Alexander,

Please see inline [Bruno]



Orange Restricted
From: Alexander Azimov <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, February 16, 2022 5:24 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc: Sriram, Kotikalapudi (Fed) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Alvaro Retana (aretana) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[e-mail]>>; Jeffrey Haas <[e-mail]<mailto:[e-mail]>>
Subject: Re: ttRE: [Idr] FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt

Bruno,

Please see the quote from 7.8 of RFC7606 which I see as good example:


   The error handling of [RFC1997<https://datatracker.ietf.org/doc/html/rfc1997>] is revised as follows:



   o  The Community attribute SHALL be considered malformed if its

      length is not a non-zero multiple of 4.



   o  An UPDATE message with a malformed Community attribute SHALL be

      handled using the approach of "treat-as-withdraw".



As you can see, there is no difference between processing communities with malformed length whether they are received thorugh eBGP or iBGP.



[Bruno] Please see https://datatracker.ietf.org/doc/html/rfc7606#section-7.10 where there is a difference between eBGP and iBGP, both in term of error condition and action taken:


The error handling of [RFC4456<https://datatracker.ietf.org/doc/html/rfc4456>] is revised as follows:


   o  if the CLUSTER_LIST attribute is received from an external
      neighbor, it SHALL be discarded using the approach of "attribute
      discard"; or

   o  if received from an internal neighbor, it SHALL be considered
      malformed if its length is not a non-zero multiple of 4.  If
      malformed, the UPDATE message SHALL be handled using the approach
      of "treat-as-withdraw".





And in the context of OTC inside AS one can say that OTC use case and community use case that are marking routes to prevent leaking is very much the same, do you agree?
[Bruno] Not sure what your point is. I don't agree in the general case:
- community allows for very flexible usage, including having an effect on route selection or installation
- OTC is defined to not be used inside iBGP hence is guaranteed to have no effect on route selection or installation within the AS


And btw, getting back to your original example, how your proposal will help to prevent loops if for some reason the internal sessions are configured as eBGP with private ASNs?
[Bruno] Not sure what you mean by "internal session configured as eBGP". A priori, if you configure eBGP you have an AS boundary and you may filter/change preference of routes on this boundary. (without creating loops)

Your last suggestion that restricts route advertisement in all directions including Customers may improve the situation but in the partial deploy scenario still may lead to hard to debug issues when routes with malformed attribute will travel beyond single administrative domain.
[Bruno] I'm not sure to see your case:
- if the ASBR supports OTC, the proposal would be to filter the route on all eBGP sessions hence the malformed attribute will not travel beyond single administrative domain
- if the ASBR does not support OTC, by definition of optional transitive, it will propagate the route and the malformed attributes regardless of the error handling specified for OTC.

--Bruno

ср, 16 февр. 2022 г. в 17:18, <[e-mail]<mailto:[e-mail]>>:
Hi Sriram,

Please see inline [Bruno2]



Orange Restricted
From: Sriram, Kotikalapudi (Fed) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 15, 2022 11:52 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>; Alexander Azimov <[e-mail]<mailto:[e-mail]>>; Jeffrey Haas <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Alvaro Retana (aretana) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Idr] FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt

Hi Bruno,

Comments inline marked with [Sriram].

>[Bruno] - RFC7606 provides a guidance https://datatracker.ietf.org/doc/html/rfc7606#section-8<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7606%23section-8&data=04%7C01%7Ckotikalapudi.sriram%40nist.gov%7Cb7a059d3cee145ca531c08d9f0a3c35f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637805408436586543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Fsbz%2B8gTR8c0r94m4SoaamR4O%2BmHiMYH5tY9uRCXTHk%3D&reserved=0> . It's only half a page so anyone interested could read. I don't think it can be summarized as per you above sentence.

[Sriram] Section 8 of RFC 7606 that you cite, says:

   A document that specifies a new BGP attribute MUST provide specifics
   regarding what constitutes an error for that attribute and how that
   error is to be handled.  Allowable error-handling approaches are
   detailed in Section 2.

[Sriram] From the list of error-handling approaches detailed in Section 2, only treat-as-withdraw and attribute discard are relevant for us. Since the RFC says, "Allowable error-handling approaches are detailed in Section 2",  it does not allow for applying none of the approaches as an option.

[Bruno2] First step that RFC7606 does is to define (i.e. choose) what constitute an error. We could define that length is not checked for IBGP because we don't care about the content (or even the attribute). Alternatively, I'm also fine with attribute discard if we consider that the attribute is in error and hence could not be trusted.

>[Bruno] In particular there is not such "SHALL be handled using the approach of "treat-as-withdraw".

[Sriram] Regarding attribute discard, RFC 7606 says: "This approach MUST NOT be used except in the case of an attribute that has no effect on route selection or installation." This implies: This approach MUST NOT be used in the case of an attribute that has an effect on route selection or installation. Do you agree? The route does propagate from iBGP (ingress) to eBGP (in the ASBR), where the attribute plays a role in route selection for propagation.

[Bruno2] 1) For IBGP, OTC attribute has no effect on route selection and installation. 2) Since you seem to be calling for "treat-as-withdraw", I would argue that "treat-as-withdraw" has also an effect on route selection or installation, and a bigger one. So it's not really safer in term of side effect.

>[Bruno] It also specifically calls for attention to optional transitive attributes (such as OTC) for which "the damage inflicted may be multiplied  manyfold >

[Sriram] The "damage inflicted may be multiplied manyfold" is about session reset. That is why the RFC urges the use of treas-as-withdraw or attribute discard instead.
[Bruno2] It's discussed in the context as session reset, but the cause is the optional transitive attribute. Cf following text which only refers to the type of attribute and not the action taken
   although the problematic attributes may have
   originated with a single update transmitted by a single BGP speaker,
   by the time they encounter a router that checks them they may have
   been replicated many times and thus may cause the reset of many
   peering sessions.  Thus, the damage inflicted may be multiplied
   manyfold.



>[Bruno] Without double checking, I don't recall that OTC is acted upon within IBGP. So in this case it does not affect routing selection. Let's just specify to not even look at it (it's optional) and problem is solved.

[Sriram] iBGP and eBGP within an ASBR are not isolated operations. Please see my comment above.
Not to look at OTC is not an option.
[Bruno2] If this were true, we could not define the OTC as an optional transitive attribute, because essentially some routers will not look at OTC. Pick your option.


A compliant router checks syntax errors in iBGP (just as in eBGP) based on its expectations of the OTC Attribute. If the length value does not match, the Attribute is malformed.

[Sriram] If the OTC attribute is malformed for any reason, we cannot be sure that even the Attribute type value is correct (or as intended).
[Bruno2] 1) That's not the path chosen by RFC 7606 in case of a length error. 2) I would find debatable to assume an error on a field (type) when you don't see an error on this field. TLV construct provides hierarchy: I agree that what is inside the TLV (i.e. after/below the error) can't be trusted; but for what is before the error, there is little to no reason to assume an error (and if we do, we could imagine anything and in particular an attribute for which the error handling is "session reset".)

[Sriram] Then must it be propagated from iBGP to eBGP (in the ASBR) and then to eBGP neighbors?
[Bruno2] Current text proposes to _not_ propagate to eBGP neighbors except for Customer. If length is wrong, I would be fine to also not propagate to Customerif you find this better.

Thanks for the discussion
--Bruno

Thanks.

Sriram



_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.


--
Best regards,
Alexander Azimov

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.


--
Best regards,
Alexander Azimov

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.