Re: [f-nsp] Netiron AS4 capabilities

Bogdan-Stefan Rotariu <[email protected]> Fri, 30 Jun 2023 15:41:29 +0300
Newsgroups gmane.network.nsp.foundry
Message-ID <[email protected]>
--===============3802131548150100852==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A594B1A9-F815-4349-8153-BF70AC1DE7A2"


--Apple-Mail=_A594B1A9-F815-4349-8153-BF70AC1DE7A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Ok, so, this is te answer from Mikrotik regarding the extended-length.

"extended length" is not really related to this issue. That flag only =
signals how length value is encoded. "extended length" does not =
determine on how ASNs are encoded.

Regarding length itself, RFC does not define that extended length =
attribute MUST not be used when length is less than 255. "MAY" and =
"MUST" meaning is not the same.=20

--
Bogdan-Stefan Rotariu
[email protected]




> On 30 Jun 2023, at 11:59, J=C3=B6rg Kost <[email protected]> wrote:
>=20
> Yes, that also works without any problems, otherwise we would all have =
issues with our devices for years ;-) - please point out the =
extended-length. As a workaround, have you turned off as4 capability =
only for the neighbor Mikrotik router from CER configuration? Would be =
worth an idea. The problem doesn't seem to be related to AS4 Capability =
causally, but maybe this changes the flagging of the attribute on =
Mikrotik router.
>=20
> On 30 Jun 2023, at 10:52, Bogdan Rotariu wrote:
>=20
>> Just received a reponse from the Mikrotik ticket:
>>=20
>> "RFC 6793 updates RFC4271 where Section 4.1 states
>> "
>> A BGP speaker that advertises such a capability to a particular peer,
>> and receives from that peer the advertisement of such a capability,
>> MUST encode AS numbers as four-octet entities in both the AS_PATH
>> attribute and the AGGREGATOR attribute in the updates it sends to the
>> peer and MUST assume that these attributes in the updates received
>> from the peer encode AS numbers as four-octet entities.
>> "
>>=20
>> AS4_AGGREGATOR does not apply here in this case because both speakers =
are considered "NEW BGP Speakers"
>>=20
>> Section 3 states what is "NEW Speaker" and what is "OLD Speaker=E2=80=9D=

>>=20
>> "
>>=20
>>> On 30 Jun 2023, at 10:44, J=C3=B6rg Kost <[email protected]> wrote:
>>>=20
>>> I see, however, you won't be able to solve it any other way than
>>>=20
>>> 1.) Open a new bug report with extended-length at Mikrotik (or use =
older firmware?)
>>> or
>>> 2.) Use a route reflector, which takes the communication between the =
routers.
>>>=20
>>> There's no point in flagging if the length, for example, can be =
represented as fixed with 8 bits, or is even set to 0. So there is =
conflicting information in the BGP message and therefore an Attributes =
Length or Attributed Data error is thrown. Or do I miss something?
>>>=20
>>> IMHO, the Brocade/Extreme Device protects you from reading =
"out-of-bounds" and implements the RFC correctly. Otherwise these would =
be classic exploitable buffer overflow conditions.
>>>=20
>>> https://datatracker.ietf.org/doc/html/rfc1771 used to be much more =
striking: "Extended Length may be used only if the length of the =
attribute
>>>         value is greater than 255 octets."
>>>=20
>>> While https://www.rfc-editor.org/rfc/rfc4271.html says:
>>> If the Extended Length bit of the Attribute Flags octet is set
>>>         to 1, the third and fourth octets of the path attribute =
contain
>>>         the length of the attribute data in octets.
>>>=20
>>>=20
>>>=20
>>> On 30 Jun 2023, at 0:41, Bogdan Rotariu wrote:
>>>=20
>>>> Ok, I can totally replicate the issue using Mikrotik's CHR latest =
7.11beta2. Session between a CHR and a CER2024 closes with same error =
"Error: Invalid AGGREGATOR attribute length 8=E2=80=9D. If anyone would =
like to do a test I would appreciate that.
>>>>=20
>>>>> On 30 Jun 2023, at 00:50, Bogdan Rotariu <[email protected]> =
wrote:
>>>>>=20
>>>>> Ty, during my research I have found out that Mikrotik forces =
atomic-aggregate attribute to any announced prefixes, I guess the =
extended-length: set comes from that? This bug they acknowledge but said =
it has nothing to do with my issue and its just Brocade fault.
>>>>>=20
>>>>>> On 30 Jun 2023, at 00:27, J=C3=B6rg Kost <[email protected]> wrote:
>>>>>>=20
>>>>>> Bottom line: Vote with your wallet, buy some Extreme ;-)
>>>>>>=20
>>>>>> In your dump e.g. there is an empty AS-Path with length 0 and =
then Extended-Length is set anyway.
>>>>>> I think that the spontaneously flag setting, will cause problems =
for other vendors too.
>>>>>>=20
>>>>>> Path Attribute - AS_PATH: empty
>>>>>> Flags: 0x50, Transitive, Extended-Length, Well-known, Complete
>>>>>>     0... .... =3D Optional: Not set
>>>>>>     .1.. .... =3D Transitive: Set
>>>>>>     ..0. .... =3D Partial: Not set
>>>>>>     ...1 .... =3D Extended-Length: Set
>>>>>>     .... 0000 =3D Unused: 0x0
>>>>>> Type Code: AS_PATH (2)
>>>>>> Length: 0
>>>>>>=20
>>>>>>=20
>>>>>> On 29 Jun 2023, at 23:13, Bogdan Rotariu wrote:
>>>>>>=20
>>>>>>> Yes Netiron is a real stable software, we have plenty Brocades =
in use and except the ones that got many sessions and occasionally have =
memory issues, we never had any issues. Unfortunately I cannot convince =
Mikrotik that they have a bug and till now I cannot see anyone else on =
the forum or on their discord server that are affected by this
>>>>>>> issue and more unfortunately I got my hands on devices I cannot =
use :-)
>>>>>>>=20
>>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> foundry-nsp mailing list
>>>> [email protected]
>>>> http://puck.nether.net/mailman/listinfo/foundry-nsp


--Apple-Mail=_A594B1A9-F815-4349-8153-BF70AC1DE7A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;">Ok, so, this =
is te answer from Mikrotik regarding the =
extended-length.<div><br></div><div><p style=3D"caret-color: rgb(23, 43, =
77); color: rgb(23, 43, 77); font-family: -apple-system, =
BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, Oxygen, Ubuntu, =
&quot;Fira Sans&quot;, &quot;Droid Sans&quot;, &quot;Helvetica =
Neue&quot;, sans-serif; font-size: 14px;">"extended length" is not =
really related to this issue. That flag only signals how length value is =
encoded. "extended length" does not determine on how ASNs are =
encoded.</p><p style=3D"caret-color: rgb(23, 43, 77); color: rgb(23, 43, =
77); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe =
UI&quot;, Roboto, Oxygen, Ubuntu, &quot;Fira Sans&quot;, &quot;Droid =
Sans&quot;, &quot;Helvetica Neue&quot;, sans-serif; font-size: =
14px;">Regarding length itself, RFC does not define that extended length =
attribute MUST not be used when length is less than 255. "MAY" and =
"MUST" meaning is not the same.&nbsp;<br></p><div>
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space;"><div style=3D"color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;">--</div><div style=3D"color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;">Bogdan-Stefan Rotariu</div><div =
style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-stroke-width: =
0px;">[email protected]</div><div style=3D"color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;"><br></div><br =
class=3D"Apple-interchange-newline"></div><br =
class=3D"Apple-interchange-newline">
</div>
<div><br><blockquote type=3D"cite"><div>On 30 Jun 2023, at 11:59, J=C3=B6r=
g Kost &lt;[email protected]&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div>Yes, that also works =
without any problems, otherwise we would all have issues with our =
devices for years ;-) - please point out the extended-length. As a =
workaround, have you turned off as4 capability only for the neighbor =
Mikrotik router from CER configuration? Would be worth an idea. The =
problem doesn't seem to be related to AS4 Capability causally, but maybe =
this changes the flagging of the attribute on Mikrotik router.<br><br>On =
30 Jun 2023, at 10:52, Bogdan Rotariu wrote:<br><br><blockquote =
type=3D"cite">Just received a reponse from the Mikrotik =
ticket:<br><br>"RFC 6793 updates RFC4271 where Section 4.1 =
states<br>"<br>A BGP speaker that advertises such a capability to a =
particular peer,<br>and receives from that peer the advertisement of =
such a capability,<br>MUST encode AS numbers as four-octet entities in =
both the AS_PATH<br>attribute and the AGGREGATOR attribute in the =
updates it sends to the<br>peer and MUST assume that these attributes in =
the updates received<br>from the peer encode AS numbers as four-octet =
entities.<br>"<br><br>AS4_AGGREGATOR does not apply here in this case =
because both speakers are considered "NEW BGP Speakers"<br><br>Section 3 =
states what is "NEW Speaker" and what is "OLD =
Speaker=E2=80=9D<br><br>"<br><br><blockquote type=3D"cite">On 30 Jun =
2023, at 10:44, J=C3=B6rg Kost &lt;[email protected]&gt; wrote:<br><br>I =
see, however, you won't be able to solve it any other way =
than<br><br>1.) Open a new bug report with extended-length at Mikrotik =
(or use older firmware?)<br>or<br>2.) Use a route reflector, which takes =
the communication between the routers.<br><br>There's no point in =
flagging if the length, for example, can be represented as fixed with 8 =
bits, or is even set to 0. So there is conflicting information in the =
BGP message and therefore an Attributes Length or Attributed Data error =
is thrown. Or do I miss something?<br><br>IMHO, the Brocade/Extreme =
Device protects you from reading "out-of-bounds" and implements the RFC =
correctly. Otherwise these would be classic exploitable buffer overflow =
conditions.<br><br>https://datatracker.ietf.org/doc/html/rfc1771 used to =
be much more striking: "Extended Length may be used only if the length =
of the attribute<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;value is greater than =
255 octets."<br><br>While https://www.rfc-editor.org/rfc/rfc4271.html =
says:<br>If the Extended Length bit of the Attribute Flags octet is =
set<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to 1, the third =
and fourth octets of the path attribute contain<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the length of the =
attribute data in octets.<br><br><br><br>On 30 Jun 2023, at 0:41, Bogdan =
Rotariu wrote:<br><br><blockquote type=3D"cite">Ok, I can totally =
replicate the issue using Mikrotik's CHR latest 7.11beta2. Session =
between a CHR and a CER2024 closes with same error "Error: Invalid =
AGGREGATOR attribute length 8=E2=80=9D. If anyone would like to do a =
test I would appreciate that.<br><br><blockquote type=3D"cite">On 30 Jun =
2023, at 00:50, Bogdan Rotariu &lt;[email protected]&gt; =
wrote:<br><br>Ty, during my research I have found out that Mikrotik =
forces atomic-aggregate attribute to any announced prefixes, I guess the =
extended-length: set comes from that? This bug they acknowledge but said =
it has nothing to do with my issue and its just Brocade =
fault.<br><br><blockquote type=3D"cite">On 30 Jun 2023, at 00:27, J=C3=B6r=
g Kost &lt;[email protected]&gt; wrote:<br><br>Bottom line: Vote with your =
wallet, buy some Extreme ;-)<br><br>In your dump e.g. there is an empty =
AS-Path with length 0 and then Extended-Length is set anyway.<br>I think =
that the spontaneously flag setting, will cause problems for other =
vendors too.<br><br>Path Attribute - AS_PATH: empty<br> Flags: 0x50, =
Transitive, Extended-Length, Well-known, Complete<br> =
&nbsp;&nbsp;&nbsp;&nbsp;0... .... =3D Optional: Not set<br> =
&nbsp;&nbsp;&nbsp;&nbsp;.1.. .... =3D Transitive: Set<br> =
&nbsp;&nbsp;&nbsp;&nbsp;..0. .... =3D Partial: Not set<br> =
&nbsp;&nbsp;&nbsp;&nbsp;...1 .... =3D Extended-Length: Set<br> =
&nbsp;&nbsp;&nbsp;&nbsp;.... 0000 =3D Unused: 0x0<br> Type Code: AS_PATH =
(2)<br> Length: 0<br><br><br>On 29 Jun 2023, at 23:13, Bogdan Rotariu =
wrote:<br><br><blockquote type=3D"cite">Yes Netiron is a real stable =
software, we have plenty Brocades in use and except the ones that got =
many sessions and occasionally have memory issues, we never had any =
issues. Unfortunately I cannot convince Mikrotik that they have a bug =
and till now I cannot see anyone else on the forum or on their discord =
server that are affected by this<br>issue and more unfortunately I got =
my hands on devices I cannot use =
:-)<br><br></blockquote></blockquote><br></blockquote><br><br>____________=
___________________________________<br>foundry-nsp mailing =
list<br>[email protected]<br>http://puck.nether.net/mailman/list=
info/foundry-nsp<br></blockquote></blockquote></blockquote></div></div></b=
lockquote></div><br></div></body></html>=

--Apple-Mail=_A594B1A9-F815-4349-8153-BF70AC1DE7A2--


--===============3802131548150100852==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp

--===============3802131548150100852==--