Subject: [Idr] Notification Subcode Squatting (draft-ietf-idr-bgp-open-policy)

From: Alvaro Retana <[email-masked]>
Date: Wed, 15 Dec 2021 12:52:51 -0800

Dear idr WG:

draft-ietf-idr-bgp-open-policy is currently in IETF Last Call.

This document specifies a new Role Mismatch Notification (code 2,
subcode 8).  This value was initially allocated by IANA in 2018 [1].

Unfortunately, Alexander (cc'd) just pointed out that BIRD uses the
same code and subcode combination for a Notification in the case where
an AFI/SAFI is not supported. :-(  As far as I can tell, no such
Notification is specified anywhere.  However, a quick search points at
cisco potentially implementing the same functionality [2] [3] [4] --
some of these reports go as far back as 2010.

What now?

Given that there seem to be multiple deployed implementations that use
this code/subcode combination, we should avoid using it even if they
are squatting on it. :-(  Also, BIRD was one of the two reported
implementations for draft-ietf-idr-bgp-open-policy.  So I propose that
we request IANA to assign a different value for the new Notification
specified in this document.

Before moving forward, I want to confirm that the WG agrees with the
proposal.  Please take a look at the questions below.  I would like to
hear from implementers at BIRD and cisco (and any other that I didn't
find that might be in the same situation), and from FRR (the second
implementation of draft-ietf-idr-bgp-open-policy).

Q1: Should a new subcode be requested for the Role Mismatch Notification
    specified in draft-ietf-idr-bgp-open-policy?

[ ]: Yes.
[ ]: No, the squatters should update their implementations.
[ ]: Something else.

Q2: What should we do with subcode 8?

[ ]: It should be deprecated (i.e., no one can use it).
[ ]: Write a specification for an "unsupported AFI/SAFI" Notification.
[ ]: Something else.

I will keep this poll open until Jan/5, 2022.

Thanks!

Alvaro.

[1] https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-6

[2] https://community.cisco.com/t5/routing/bgp-3-notification-erro/td-p/1572684

[3] https://www.wireshark.org/lists/wireshark-bugs/201607/msg00164.html

[4] https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsu79206

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 15 Dec 2021 16:59:41 -0500

Alvaro,

> some of these reports go as far back as 2010.

It would be useful if someone at Cisco can do the appropriate code forensics
and confirm if this is the case.

And while they're in that code, figure out what other sins they may have if
that's the case.

> I will keep this poll open until Jan/5, 2022.

My opinion crosses a few of these items, perhaps into "Something else".

If Cisco, as a large vendor, confirms they have such squatting in place,
they should come clean and we should consider possibly setting the code
point aside for their application.  "Deprecating" it would simply be leaving
it in use without actually documenting it which would probably be better.

Bird as a smaller implementation with a shorter development cycle could
theoretically just renumber if they're the only impacted party.  That said,
if there's a motivation for them to have squatted on a code point, they're
due the same consideration that Cisco is: Document what's going on and lets
discuss.  At least the "come clean" can be a bit more public introspection
into their code base. :-)

My concerns for interoperability impacts are modest.  The Cease NOTIFICATION
code indicates "drop the session".  draft-ietf-idr-bgp-open-policy does not
suggest a DATA portion for their newly allocated sub-code.  If it's the case
that the squatted features append DATA, and use it for anything besides
informative purposes, there's more concern.  That said, implementations
making use of NOTIFICATION DATA without appropriate sanity checking are
already vulnerable to forms of attack.  It's why we try hard to keep data
out of NOTIFICATION that is more than informative.

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Thu, 16 Dec 2021 13:15:12 +0100

> >     specified in draft-ietf-idr-bgp-open-policy?

My recommendation would be "Yes". A little bit of IANA paperwork now
will probably go a long way when deployment in the field happens.

> My concerns for interoperability impacts are modest.  The Cease
> NOTIFICATION code indicates "drop the session".

While I agree that the session is going down anyway, I have some
concern stemming from an operational debugging perspective.

I suspect it'll be highly confusing if one side sees an error message
indicating something along the lines of "role mismatch", but the EBGP
peer sees "unsupported AFI".

As for the existing squatted value, I would mark it as 'deprecated'
until a standards track document specifies otherwise. If it is of any
help, I'm willing to put an internet-draft forward in spirit of RFC 8093.

Kind regards,

Job

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 19 Dec 2021 10:41:25 -0500

Alvaro: 

Documenting what is out there and pragmatism is the best policy.   

Q1. Something else 

If Cisco has been squatting on the subcode 8, cisco experts should let us know: 1) how widely it is deployed, and 2) how difficult to change.    
If Bird, the same questions apply.  

Pragmatism 

Q2. (b) Deprecating the code and (c) working with pragmatism to get actual implementations to registered code. 

Sue 

PS - +1 to what Jeff Haas says as well. 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Alvaro Retana
Sent: Wednesday, December 15, 2021 3:53 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Susan Hares
Subject: [Idr] Notification Subcode Squatting (draft-ietf-idr-bgp-open-policy)

Dear idr WG:

What now?

[ ]: Yes.

Thanks!

Alvaro.

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "Jeffrey Chiang (jefchian)" <[email-masked]>
Date: Tue, 21 Dec 2021 01:20:18 +0000

Cisco has implemented https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-multisession-07 many years ago. We are using the subcodes as stated in the draft, but offset by one, because at the time (and now still), subcode 7 was already used. They are
8 - Capability Value Mismatch (was called "No Supported AFI/SAFI" in version 00)
9 - Grouping Conflict
10 - Grouping Required
We would like to resurrect the draft and progress it to RFC.
Are there any other implementations?

Regards,
Jeffrey

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: Sunday, December 19, 2021 7:41 AM
To: 'Alvaro Retana' <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Notification Subcode Squatting (draft-ietf-idr-bgp-open-policy)

Alvaro: 

Q1. Something else 

Pragmatism 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Alvaro Retana
Sent: Wednesday, December 15, 2021 3:53 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Susan Hares
Subject: [Idr] Notification Subcode Squatting (draft-ietf-idr-bgp-open-policy)

Dear idr WG:

This document specifies a new Role Mismatch Notification (code 2, subcode 8).  This value was initially allocated by IANA in 2018 [1].

Unfortunately, Alexander (cc'd) just pointed out that BIRD uses the same code and subcode combination for a Notification in the case where an AFI/SAFI is not supported. :-(  As far as I can tell, no such Notification is specified anywhere.  However, a quick search points at cisco potentially implementing the same functionality [2] [3] [4] -- some of these reports go as far back as 2010.

What now?

Given that there seem to be multiple deployed implementations that use this code/subcode combination, we should avoid using it even if they are squatting on it. :-(  Also, BIRD was one of the two reported implementations for draft-ietf-idr-bgp-open-policy.  So I propose that we request IANA to assign a different value for the new Notification specified in this document.

Before moving forward, I want to confirm that the WG agrees with the proposal.  Please take a look at the questions below.  I would like to hear from implementers at BIRD and cisco (and any other that I didn't find that might be in the same situation), and from FRR (the second implementation of draft-ietf-idr-bgp-open-policy).

[ ]: Yes.

Thanks!

Alvaro.

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 21 Dec 2021 05:49:37 -0500

Alvaro / All

As Cisco plans to progress the multi session draft we should to look for a
new subcode.

[X]: Yes.

[X]: Something else.

Cisco has taken ownership of the sub code to progress.

Kind Regards

Gyan

On Mon, Dec 20, 2021 at 8:20 PM Jeffrey Chiang (jefchian) <jefchian=
[email-masked]> wrote:

> Cisco has implemented
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-multisession-07
> many years ago. We are using the subcodes as stated in the draft, but
> offset by one, because at the time (and now still), subcode 7 was already
> used. They are
> If Cisco has been squatting on the subcode 8, cisco experts should let us
> know: 1) how widely it is deployed, and 2) how difficult to change.
> This document specifies a new Role Mismatch Notification (code 2, subcode
> 8).  This value was initially allocated by IANA in 2018 [1].
>
> Unfortunately, Alexander (cc'd) just pointed out that BIRD uses the same
> code and subcode combination for a Notification in the case where an
> AFI/SAFI is not supported. :-(  As far as I can tell, no such Notification
> is specified anywhere.  However, a quick search points at cisco potentially
> implementing the same functionality [2] [3] [4] -- some of these reports go
> as far back as 2010.
>
>
> What now?
>
> this code/subcode combination, we should avoid using it even if they are
> squatting on it. :-(  Also, BIRD was one of the two reported
> implementations for draft-ietf-idr-bgp-open-policy.  So I propose that we
> request IANA to assign a different value for the new Notification specified
> in this document.
>
> proposal.  Please take a look at the questions below.  I would like to hear
> from implementers at BIRD and cisco (and any other that I didn't find that
> might be in the same situation), and from FRR (the second implementation of
> draft-ietf-idr-bgp-open-policy).
>
>
> [1]
> https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-6
>
> [2]
> https://community.cisco.com/t5/routing/bgp-3-notification-erro/td-p/1572684
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 21 Dec 2021 14:56:29 -0500

Jeffrey,

Could you confirm there are no other unregistered subcodes in use for any of your notifications while you're in there?  :-)

-- Jeff (who audited Juniper's suite a while back but will do so again after the new year)

> On Dec 20, 2021, at 8:20 PM, Jeffrey Chiang (jefchian) <jefchian=[email-masked]> wrote:
>