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

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 10 Feb 2022 14:00:32 +0000

Earlier, in version-21, the inclusion of changes based on all IESG comments was completed.

Now version-22 completes incorporating changes based on Bruno's comments. Thank you, Bruno.

Sriram / Alexander

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: Thursday, February 10, 2022 8:40 AM
To: Alexander Azimov <[email-masked]>; Eugene Bogomazov <[email-masked]>; Keyur Patel <[email-masked]>; Sriram, Kotikalapudi (Fed) <[email-masked]>; Randy Bush <[email-masked]>
Subject: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt

A new version of I-D, draft-ietf-idr-bgp-open-policy-22.txt

has been successfully submitted by Kotikalapudi Sriram and posted to the IETF repository.

Name:                draft-ietf-idr-bgp-open-policy

Revision:           22

Title:                   Route Leak Prevention and Detection using Roles in UPDATE and OPEN Messages

Document date:            2022-02-10

Group:               idr

Pages:                15

URL:            https://www.ietf.org/archive/id/draft-ietf-idr-bgp-open-policy-22.txt

The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/

There is also an htmlized version available at:

https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy-22

A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-open-policy-22

Abstract:

   Route leaks are the propagation of BGP prefixes that violate

   assumptions of BGP topology relationships, e.g., announcing a route

   learned from one transit provider to another transit provider or a

   lateral (i.e., non-transit) peer or announcing a route learned from

   one lateral peer to another lateral peer or a transit provider.

   These are usually the result of misconfigured or absent BGP route

   filtering or lack of coordination between autonomous systems (ASes).

   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 peering relationship.  This document

   enhances the BGP OPEN message to establish an agreement of the

   peering relationship on each eBGP session between autonomous systems

   in order to enforce appropriate configuration on both sides.

   Propagated routes are then marked according to the agreed

   relationship, allowing both prevention and detection of route leaks.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 10 Feb 2022 09:13:46 -0500

Sriram,

> Now version-22 completes incorporating changes based on Bruno's comments. Thank you, Bruno.

I just finished catching up on this thread.  Good timing. :-)

I understand the motivation for the current text from the thread that just
happened.  In particular, it resulted in the following text:

:   If an UPDATE with an OTC Attribute is received in iBGP, then the
:   Attribute or UPDATE SHALL NOT be considered malformed based on the
:   specified length.  This avoids treat-as-withdraw error handling and
:   prevents the possibility of long-lived forwarding loops in iBGP
:   (Section 6 in [RFC7606]).  It also avoids Attribute-discard error
:   handling [RFC7606] and hence route leak detection capability is not
:   compromised in case the route is propagated to eBGP neighbors.

Could the authors comment on how this behavior is intended to interact with
the advertisement procedures?

:   1.  If a route is to be advertised to a Customer, Peer, or RS-Client
:       (when the sender is an RS), and the OTC Attribute is not present,
:       then when advertising the route, an OTC Attribute MUST be added
:       with a value equal to the AS number of the local AS.
:
:   2.  If a route already contains the OTC Attribute, it MUST NOT be
:       propagated to Providers, Peers, or RS(s).

Is it 1 and it wasn't present because it is malformed?  We thus re-generate it?

Is it 2 because it has one and, as a single bit of corrupted information we
still can avoid propagating it?  And if 2, and we are propagating it to
customers, are we comfortable with it having treat-as-withdraw done by the
receiver that hopefully can tell it is corrupted?

-- Jeff

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 10 Feb 2022 15:40:50 +0000

Hi Jeff,

>Is it 1 and it wasn't present because it is malformed?  We thus re-generate it?

I think you understand that the ingress and egress procedures (the two numbered lists in Section 4) are specified for eBGP only. In iBGP, the Update passes through except for syntax checking on the OTC (syntax checking is done on any BGP Attribute). Now to your question, the OTC may be absent for one of two reasons: (1) the preceding ASes did not need to add OTC (per protocol spec); (2) one or more of the ASes was not upgraded. In this spec, we only speak about OTC length error (not equal to 4). If there is more to the malformed OTC, then there would be synchronization error etc. for the Update and that is covered elsewhere (for BGP Attributes in general). So, if the OTC length was not 4, then that would have caused treat-as-withdraw action at the eBGP ingress to the AS with the correct implementation. OTOH, with incorrect implementation at the ingress to the AS, the Update could propagate in iBGP with malformed OTC (not equal to 4). But the length error is not acted on in iBGP, and hence the Update with malformed OTC may propagate to a Customer. The Customer would detect the error and apply treat-as-withdraw.

>Is it 2 because it has one and, as a single bit of corrupted information we still can avoid propagating it?  And if 2, and we are propagating it to customers, are we comfortable with it having treat-as-withdraw done by the receiver that hopefully can tell it is corrupted?

I think this question is already covered in the above response.

Thank you.

Sriram

-----Original Message-----

From: Jeffrey Haas [email-masked]<mailto:[email-masked]>

I understand the motivation for the current text from the thread that just happened.  In particular, it resulted in the following text:

Could the authors comment on how this behavior is intended to interact with the advertisement procedures?

:

Is it 2 because it has one and, as a single bit of corrupted information we still can avoid propagating it?  And if 2, and we are propagating it to customers, are we comfortable with it having treat-as-withdraw done by the receiver that hopefully can tell it is corrupted?

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 10 Feb 2022 11:09:35 -0500

Sriram,

On Thu, Feb 10, 2022 at 03:40:50PM +0000, Sriram, Kotikalapudi (Fed) wrote:
> I think you understand that the ingress and egress procedures (the two
> numbered lists in Section 4) are specified for eBGP only.

I do.

The malformed OTC is optional-transitive.  The updated procedure says that
if you discover it is malformed in iBGP reception you don't treat it as
malformed.  We're also not stripping it.  It's therefore still present.

> In iBGP, the
> Update passes through except for syntax checking on the OTC (syntax
> checking is done on any BGP Attribute). Now to your question, the OTC may
> be absent for one of two reasons: (1) the preceding ASes did not need to
> add OTC (per protocol spec); (2) one or more of the ASes was not upgraded.

It's more precise to say that one of the involved eBGP speakers wasn't
upgraded.  ASes may be partially upgraded.

> In this spec, we only speak about OTC length error (not equal to 4). If
> there is more to the malformed OTC, then there would be synchronization
> error etc. for the Update and that is covered elsewhere (for BGP
> Attributes in general).

My question is solely about the incorrect length of the value field.

> So, if the OTC length was not 4, then that would
> have caused treat-as-withdraw action at the eBGP ingress to the AS with
> the correct implementation. OTOH, with incorrect implementation at the
> ingress to the AS,

It is sufficient that a receiving ASBR not support this feature.  That has
been one of the core scenarios under discussion this entire time.

> the Update could propagate in iBGP with malformed OTC
> (not equal to 4). But the length error is not acted on in iBGP, and hence
> the Update with malformed OTC may propagate to a Customer. The Customer
> would detect the error and apply treat-as-withdraw.

You have avoided my original question related to sender procedures.

An ASBR that understands the feature has a route with a malformed value for
OTC - the length is not 4.

It has received this route via iBGP and hos NOT done treat as withdraw nor
has it stripped the attribute.

The advertisement procedures toward another AS wherein the open-policy
capability has been negotiated now apply.

If the route to be advertised contains a malformed OTC, is the attribute
considered to be present or not?

If it's not considered to be "present", we'd replace the malformed entry
with a new one accord to 1, above.

If it is considered present, we have enough information, even if it is
malformed, to NOT propagate it toward Providers, Peers, or RS(s).

This leaves the Customer case. As you note, if we simply propagate the
malformed attribute, it should drop the route via treat-as-withdraw.
However, the ASBR dropping it only knows that it has received a malformed
OTC attribute, and it is reasonable for it to presume that the malformed
attribute was generated by the peer ASBR rather than something on the other
side of one or more ASes.  This confuses the troubleshooting procedure,
although it still implements the correct intent.

What I am arguing is that the above procedures are intended to address the
clean scenario.  They are not precise enough for the dirty scenario in
question.

It is arguable that for the sending procedures, you want the following:

+   0.  Routes that contain a malformed OTC attribute SHOULD NOT be
+       advertised to eBGP peers.
+
:   1.  If a route is to be advertised to a Customer, Peer, or RS-Client
:       (when the sender is an RS), and the OTC Attribute is not present,
:       then when advertising the route, an OTC Attribute MUST be added
:       with a value equal to the AS number of the local AS.
:
:   2.  If a route already contains the OTC Attribute, it MUST NOT be
:       propagated to Providers, Peers, or RS(s).

The exact wording of 0 becomes messy because your new text tries to redefine
malformed.  What it should likely say is that it's malformed but you
won't be exercising RFC 7606 procedures on it.

-- Jeff

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Thu, 10 Feb 2022 20:42:16 +0000

Hi Jeff,

>An ASBR that understands the feature has a route with a malformed value for OTC - the length is not 4.

Not exactly. Bruno's scenarios are based on one or more routers or ASBRs in an AS having implementation errors.  In some cases, the OTC length value is 4 but the ASBR erroneously determines it is not, and in other cases, the OTC length value is not 4 but ASBR erroneously determines it is.

>If the route to be advertised contains a malformed OTC, is the attribute considered to be present or not?

The attribute is considered to be present even when the OTC length value is not 4.

> This leaves the Customer case. As you note, if we simply propagate the malformed attribute, it should drop the route via treat-as-withdraw.
However, the ASBR dropping it only knows that it has received a malformed OTC attribute, and it is reasonable for it to presume that the malformed attribute was generated by the peer ASBR rather than something on the other side of one or more ASes.  This confuses the troubleshooting procedure, although it still implements the correct intent.

It is possible, the Customer AS finds the OTC is not malformed (the OTC length value is 4); IOW the peer ASBR might have erroneously determined it was not 4. Regarding troubleshooting, the only knowledge that can be gleaned is the ASN value in the OTC. How to make use of that for where the route leak or a malformed OTC may have occurred is not within the scope of the document.

>+       advertised to eBGP peers.

In one of the scenarios considered, we are assuming that the ASBR may have an implementation error on the iBGP ingress side because of which it *erroneously* determines that the OTC length value is not equal to 4. So, we cannot safely assume that there isn't the same implementation error possibility on the eBGP egress side of the ASBR. That is the reason, it appears safe and better to forward the Update to the Customer and let them figure it out about the OTC at eBGP ingress and act on it as specified. No harm is done. Customer AS accepts Updates with OTC (length value = 4) or without OTC from the Provider. If it finds the OTC length value is not 4, it applies treat-as-withdraw.

>The exact wording of 0 becomes messy because your new text tries to redefine malformed.  What it should likely say is that it's malformed but you won't be exercising RFC 7606 procedures on it.

#0 step may not be needed as discussed above, but are you saying you might nevertheless prefer the following substitution?

OLD text:

   If an UPDATE with an OTC Attribute is received in iBGP, then the
   Attribute or UPDATE SHALL NOT be considered malformed based on the
   specified length.  This avoids treat-as-withdraw error handling and
   prevents the possibility of long-lived forwarding loops in iBGP
   (Section 6 in [RFC7606]).  It also avoids Attribute-discard error
   handling [RFC7606] and hence route leak detection capability is not
   compromised in case the route is propagated to eBGP neighbors.

NEW text:

   If an UPDATE with an OTC Attribute is received in iBGP and the OTC length
   value is not 4, then the latter by itself SHALL NOT result in treat-as-withdraw
   or Attribute-discard error handling.  Avoiding treat-as-withdraw error
   handling prevents the possibility of long-lived forwarding loops in iBGP
   (Section 6 in [RFC7606]).  Avoiding Attribute-discard error handling [RFC7606]
   prevents compromising the route leak detection capability
   in case the route is propagated to eBGP neighbors.

Sriram

-----Original Message-----
From: Jeffrey Haas <[email-masked]>
Sent: Thursday, February 10, 2022 11:10 AM
To: Sriram, Kotikalapudi (Fed) <[email-masked]>
Cc: [email-masked]; Alvaro Retana (aretana) <[email-masked]>; [email-masked]; Susan Hares <[email-masked]>; [email-masked]
Subject: Re: [Idr] FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt

Sriram,

I do.

The malformed OTC is optional-transitive.  The updated procedure says that if you discover it is malformed in iBGP reception you don't treat it as malformed.  We're also not stripping it.  It's therefore still present.

> checking is done on any BGP Attribute). Now to your question, the OTC
> may be absent for one of two reasons: (1) the preceding ASes did not
> need to add OTC (per protocol spec); (2) one or more of the ASes was not upgraded.

It's more precise to say that one of the involved eBGP speakers wasn't upgraded.  ASes may be partially upgraded.

> In this spec, we only speak about OTC length error (not equal to 4).
> If there is more to the malformed OTC, then there would be
> synchronization error etc. for the Update and that is covered
> elsewhere (for BGP Attributes in general).

> So, if the OTC length was not 4, then that would have caused
> treat-as-withdraw action at the eBGP ingress to the AS with the
> correct implementation. OTOH, with incorrect implementation at the
> ingress to the AS,

It is sufficient that a receiving ASBR not support this feature.  That has been one of the core scenarios under discussion this entire time.

> the Update could propagate in iBGP with malformed OTC (not equal to
> 4). But the length error is not acted on in iBGP, and hence the Update
> with malformed OTC may propagate to a Customer. The Customer would
> detect the error and apply treat-as-withdraw.

An ASBR that understands the feature has a route with a malformed value for OTC - the length is not 4.

It has received this route via iBGP and hos NOT done treat as withdraw nor has it stripped the attribute.

The advertisement procedures toward another AS wherein the open-policy capability has been negotiated now apply.

If the route to be advertised contains a malformed OTC, is the attribute considered to be present or not?

If it's not considered to be "present", we'd replace the malformed entry with a new one accord to 1, above.

If it is considered present, we have enough information, even if it is malformed, to NOT propagate it toward Providers, Peers, or RS(s).

This leaves the Customer case. As you note, if we simply propagate the malformed attribute, it should drop the route via treat-as-withdraw.
However, the ASBR dropping it only knows that it has received a malformed OTC attribute, and it is reasonable for it to presume that the malformed attribute was generated by the peer ASBR rather than something on the other side of one or more ASes.  This confuses the troubleshooting procedure, although it still implements the correct intent.

What I am arguing is that the above procedures are intended to address the clean scenario.  They are not precise enough for the dirty scenario in question.

The exact wording of 0 becomes messy because your new text tries to redefine malformed.  What it should likely say is that it's malformed but you won't be exercising RFC 7606 procedures on it.

-- Jeff

---

From: <[email-masked]>
Date: Fri, 11 Feb 2022 09:14:47 +0000

Hi Jeff, Sriram,

Sorry to jump in.
2c comment

> The attribute is considered to be present even when the OTC length value is not 4.

May be an editorial option would be to not consider the attribute as malformed if the length is not 4, and consider the length only when the AS/value is read (very rarely, possibly only once in §4, point 2).
That may remove some text and specific cases. e.g.

OLD:    If an eBGP speaker receives an UPDATE with an OTC Attribute with a

   length different from 4 octets, then the UPDATE SHALL be considered

   malformed.  If malformed, the UPDATE message SHALL be handled using

   the approach of treat-as-withdraw [RFC7606<https://datatracker.ietf.org/doc/html/rfc7606>].

   (Section 6 in [RFC7606]<https://datatracker.ietf.org/doc/html/rfc7606#section-6>).  It also avoids Attribute-discard error

   handling [RFC7606<https://datatracker.ietf.org/doc/html/rfc7606>] and hence route leak detection capability is not

NEW: <null>

OLD:

   2.  If a route with the OTC Attribute is received from a Peer (i.e.,

       remote AS with a Peer Role) and the Attribute has a value that is

       not equal to the remote (i.e., Peer's) AS number, then it is a

       route leak and MUST be considered ineligible.

NEW:

   2.  If a route with the OTC Attribute is received from a Peer (i.e.,

       remote AS with a Peer Role) and the Attribute has a value that is

       not equal to the remote (i.e., Peer's) AS number (including when the attribute value is not 4 octets), then it is a

       route leak and MUST be considered ineligible.

Really up to you
--Bruno

Orange Restricted
From: Sriram, Kotikalapudi (Fed) <[email-masked]>
Sent: Thursday, February 10, 2022 9:42 PM

Hi Jeff,

OLD text:

NEW text:

Sriram

-----Original Message-----
From: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 10, 2022 11:10 AM
To: Sriram, Kotikalapudi (Fed) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] FW: New Version Notification for draft-ietf-idr-bgp-open-policy-22.txt

Sriram,

I do.

-- Jeff

_________________________________________________________________________________________________________________________

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.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 11 Feb 2022 09:47:15 -0500

Sriram,

On Thu, Feb 10, 2022 at 08:42:16PM +0000, Sriram, Kotikalapudi (Fed) wrote:
> Not exactly. Bruno's scenarios are based on one or more routers or ASBRs
> in an AS having implementation errors.  In some cases, the OTC length
> value is 4 but the ASBR erroneously determines it is not, and in other
> cases, the OTC length value is not 4 but ASBR erroneously determines it
> is.

BGP is not designed to give us robustness vs. Byzantine failures.  While I
understand (in painful personal experience) Bruno's example of such a
failure, BGP has to deal with faults for routes it received, not necessarily
what it believes the unknown intent of the sending router is.

> It is possible, the Customer AS finds the OTC is not malformed (the OTC length value is 4); IOW the peer ASBR might have erroneously determined it was not 4. Regarding troubleshooting, the only kno…

No, it's not discussed in the document.  However, it's part of BGP behavior
to discuss what you do with PDUs you receive on the wire.

BGP behaviors are covered both in a sending context and a receive context.

A very strong motivation for RFC 7606's work was not transmitting things you
know are broken (i.e. treat-as-withdraw, attribute-strip) and what you do if
you receive broken things.

So, it is quite within scope to have this discussion.

A sending ASBR that has an OTC that is not of length 4 knows it is broken.
Why make the receiver do the work to decide it's broken?  Some strange
belief that 4!=4 in one of the implementations?

My experience is these classes of bugs are best supressed as close to the
fault as possible.  This is especially true when the bugs may impact one
vendor or code train.  If the fault is in the receiver, the fault may never
get caught in an ecosystem solely of receivers with that bug, but can be
halted by a sender.

> In one of the scenarios considered, we are assuming that the ASBR may have an implementation error on the iBGP ingress side because of which it *erroneously* determines that the OTC length value is…

If you can't trust the implementation, you can't trust the implementation.
BGP's goal isn't to trust the downstream implementation, its goal is to use
the state it has received and what it is going to send.

> #0 step may not be needed as discussed above, but are you saying you might nevertheless prefer the following substitution?

I'll follow up on this point in Bruno's response.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 11 Feb 2022 09:52:38 -0500

Bruno,

> That may remove some text and specific cases. e.g.

Other IETF work introduces the idea "well formed, but invalid".  In this
case, it's not even well formed since the specification declares it to be of
length 4.

>    compromised in case the route is propagated to eBGP neighbors.

A BGP speaker receiving an OTC Attribute with a length that is not 4 octets
shall be considered to have an invalid value.

(and then...)

2.  If a route with the OTC Attribute is received from a Peer (i.e.,
remote AS with a Peer Role) and the Attribute has a value that is
not equal to the remote (i.e., Peer's) AS number, or the valid is invalid,
then it is a route leak and MUST be considered ineligible.

Same idea, just formalizing valid/invalid vs. malformed since malformed
implies the need to trigger specific RFC 7606 behaviors.

-- Jeff

---

From: <[email-masked]>
Date: Fri, 11 Feb 2022 15:47:28 +0000

Jeff,

> Sent: Friday, February 11, 2022 3:53 PM
> 
> Bruno,
> 
> > May be an editorial option would be to not consider the attribute as malformed if
> the length is not 4, and consider the length only when the AS/value is read (very
> rarely, possibly only once in §4, point 2).
> >    the approach of treat-as-withdraw
> [RFC7606<https://datatracker.ietf.org/doc/html/rfc7606>].
> >
> >
> >
> >    (Section 6 in [RFC7606]<https://datatracker.ietf.org/doc/html/rfc7606#section-
> 6>).  It also avoids Attribute-discard error
> >

Would work for me.

(I would assume the following typo :s/ or the valid is invalid/ or the value is invalid)

--Bruno

Orange Restricted

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Mon, 14 Feb 2022 21:02:42 +0000

Jeff,
Bruno,

Thank you for the thoughts you've shared. Alexander and I are once again discussing OTC error handling carefully considering RFC 7606. One of us will summarize that shortly on this list.

Sriram

-----Original Message-----
From: Jeffrey Haas

Bruno,

What this suggests to me:

>    the approach of treat-as-withdraw [RFC7606<https://datatracker.ietf.org/doc/html/rfc7606><http://rfc7606%3Chttps//datatracker.ietf.org/doc/html/rfc7606%3E>]6>].
>
>
>
>    (Section 6 in [RFC7606]<https://datatracker.ietf.org/doc/html/rfc7606#section-6><http://rfc7606]%3Chttps//datatracker.ietf.org/doc/html/rfc7606>)6>).  It also avoids Attribute-discard error
>
>    handling [RFC7606<https://datatracker.ietf.org/doc/html/rfc7606><http://rfc7606%3Chttps//datatracker.ietf.org/doc/html/rfc7606%3E>] and hence route leak detection capability is not
>

(and then...)

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 15 Feb 2022 09:48:39 -0500

Sriram,

In a side conversation, Bruno points out RFC 7606 sense of malformed with
targeted actions is appropriate.  So, I withdraw my comment about not
calling these malformed.

Updated proposal follows:

NEW:

An OTC Attribute with a length that is not 4 octets SHALL be considered
malformed.  

An UPDATE message with a malformed OTC Attribute received from an eBGP peer
MUST be handled using the approach of "treat-as-withdraw".

When an UPDATE message with a malformed OTC Attribute is received from an
iBGP peer, the OTC message's value field SHOULD be ignored and considered
invalid.

Applying "treat-as-withdraw" behaviors to routes received via iBGP may lead
to forwarding loops. ([RFC 7606], Section 6.)  Retaining the malformed OTC
Attribute with an invalid value permits an adjacent AS to prevent route
leaks. 

> not equal to the remote (i.e., Peer's) AS number, or the value is invalid,

---

From: Alexander Azimov <[email-masked]>
Date: Tue, 15 Feb 2022 18:28:23 +0300

Jeff,

Since that is ongoing discussion I will give my 50 cent.

As far as I understand RFC7606 provides general guidance that any path
attribute with incorrect length that may affect routing selection process
SHALL be handled using the approach of "treat-as-withdraw". This policy
applies to all attributes, mandatory like ASPATH and optional like
communities of any flavour.

And I fail to understand why OTC should be handled in a different manner.
Yes, "treat-as-withdraw" may lead to forward loops in quite specific
setups, but making exceptions for iBGP opens another vulnerability when
route will be discarded by direct or indirect customer with no easy way to
debug the issue.

With this in mind I suggest to stick to the old wording:

   If an UPDATE is received with a malformed OTC Attribute (e.g., the OTC
length
  value is different from 4 octets), then the UPDATE SHALL be considered
   malformed.  If malformed, the UPDATE message SHALL be handled using
   the approach of treat-as-withdraw [RFC7606].

And if there is desire to update RFC7606 and corresponding documents I will
gladly follow such activity but IMO it should be done out of scope of open
policy document.

вт, 15 февр. 2022 г. в 17:48, Jeffrey Haas <[email-masked]>:

> > >    the approach of treat-as-withdraw [RFC7606<
> https://datatracker.ietf.org/doc/html/rfc7606><http://rfc7606%3Chttps//
> datatracker.ietf.org/doc/html/rfc7606%3E>]6>].
> > >
> > >
> > >
> > >    (Section 6 in [RFC7606]<
> https://datatracker.ietf.org/doc/html/rfc7606#section-6><http://rfc7606
> ]%3Chttps//datatracker.ietf.org/doc/html/rfc7606>)6>).  It also avoids
> Attribute-discard error
> > >
> > >    handling [RFC7606<https://datatracker.ietf.org/doc/html/rfc7606><
> http://rfc7606%3Chttps//datatracker.ietf.org/doc/html/rfc7606%3E>] and
> hence route leak detection capability is not
> > >
> > >        not equal to the remote (i.e., Peer's) AS number (including
> when the attribute value is not 4 octets), then it is a
> > >

-- 
Best regards,
Alexander Azimov

---

From: <[email-masked]>
Date: Tue, 15 Feb 2022 16:53:51 +0000

Alexander,

Please see inline [Bruno]

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

Jeff,

As far as I understand RFC7606 provides general guidance that any path attribute with incorrect length that may affect routing selection process SHALL be handled using the approach of "treat-as-withdraw". This policy applies to all attributes, mandatory like ASPATH and optional like communities of any flavour.

[Bruno]

- RFC7606 provides a guidance https://datatracker.ietf.org/doc/html/rfc7606#section-8 . It's only half a page so anyone interested could read. I don't think it can be summarized as per you above sentence. In particular there is not such "SHALL be handled using the approach of "treat-as-withdraw".  It also specifically calls for attention to optional transitive attributes (such as OTC) for which "the damage inflicted may be multiplied  manyfold >
- Also for an attribute, RFC7606 defined a different error handling behavior for EBGP and IBGP cases https://datatracker.ietf.org/doc/html/rfc7606#section-7.10 so there is precedent.

And I fail to understand why OTC should be handled in a different manner.
[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.

--Bruno

Yes, "treat-as-withdraw" may lead to forward loops in quite specific setups, but making exceptions for iBGP opens another vulnerability when route will be discarded by direct or indirect customer with no easy way to debug the issue.

   If an UPDATE is received with a malformed OTC Attribute (e.g., the OTC length
  value is different from 4 octets), then the UPDATE SHALL be considered
   malformed.  If malformed, the UPDATE message SHALL be handled using
   the approach of treat-as-withdraw [RFC7606].

And if there is desire to update RFC7606 and corresponding documents I will gladly follow such activity but IMO it should be done out of scope of open policy document.

вт, 15 февр. 2022 г. в 17:48, Jeffrey Haas <[email-masked]<mailto:[email-masked]>>:
Sriram,

On Mon, Feb 14, 2022 at 09:02:42PM +0000, Sriram, Kotikalapudi (Fed) wrote:
> >    the approach of treat-as-withdraw [RFC7606<https://datatracker.ietf.org/doc/html/rfc7606><http://rfc7606%3Chttps//datatracker.ietf.org/doc/html/rfc7606%3E<http://datatracker.ietf.org/doc/html/rfc7606%3E>>]6>].
> >
> >
> >
> >    (Section 6 in [RFC7606]<https://datatracker.ietf.org/doc/html/rfc7606#section-6><http://rfc7606]%3Chttps//datatracker.ietf.org/doc/html/rfc7606<http://datatracker.ietf.org/doc/html/rfc7606>>)6>).  It also avoids Attribute-discard error
> >
> >    handling [RFC7606<https://datatracker.ietf.org/doc/html/rfc7606><http://rfc7606%3Chttps//datatracker.ietf.org/doc/html/rfc7606%3E<http://datatracker.ietf.org/doc/html/rfc7606%3E>>] and hence route leak detection capability is not
> >

NEW:

--
Best regards,
Alexander Azimov

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 15 Feb 2022 22:52:17 +0000

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.

>[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.

>[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.

>[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) an…

[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. 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). Then must it be propagated from iBGP to eBGP (in the ASBR) and then to eBGP neighbors?

Thanks.

Sriram