Incorrect setting of BGP Path Attribute Extended Length flag breaks MRT output

[Simon Marsh]

Hi,

i run bird as a route collector in DN42 and so get a variety of different
BGP daemons peering with and passing routes to the collector.
We recently ran in to an issue where MRT dumps from bird were not readable
by any of the common MRT parsers and, on investigation, found a bug in how
bird handles the BGP Path Attribute Extended Length flag.

The issue occurred because peers using the FRR daemon set the Extended
Length flag on the AS PATH attribute by default, regardless of the actual
data length. When bird re-encodes the AS Path (for example as part of the
MRT dump) it correctly re-calculates whether to use an 8 bit or 16 bit
length field for the attribute, but simply copies the flags and does not
reset the Extended Length flag in the 8 bit case. This results in an AS
PATH attribute being output that has the Extended Length flag set but
with the actual length field being only 8 bits. Of course, any
parsers trying read this get very confused.

A simple fix is to ensure the Extended Length flag is cleared when encoding
the 3 byte attribute header:

diff --git a/proto/bgp/attrs.c b/proto/bgp/attrs.c
index 6752cb7f..5c7b4fdd 100644
--- a/proto/bgp/attrs.c
+++ b/proto/bgp/attrs.c
@@ -118,7 +118,7 @@ bgp_set_attr(ea_list **attrs, struct linpool *pool,
uint code, uint flags, uintp
 static inline int
 bgp_put_attr_hdr3(byte *buf, uint code, uint flags, uint len)
 {
-  *buf++ = flags;
+  *buf++ = flags & ~BAF_EXT_LEN;
   *buf++ = code;
   *buf++ = len;
   return 3;

Cheers


Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20210327/d0200156/attachment.htm>