Re: control characters in BGP shutdown communication(RFC 9003) messages and NETCONF

[Job Snijders via NANOG <nanog () lists nanog org>]

On Sun, Sep 07, 2025 at 07:55:02PM +0300, Martin Tonusoo wrote:
> > Older versions of Junos incorrectly interpret the first byte of the
> > Shutdown Communication as a character in the message, instead as the
> > length field.
>
> Thanks, I can confirm this. 

Cheers.

> However, I also noticed that one can deliberately/accidentally inject
> control characters to Shutdown Communication field and Junos would
> return those control characters in its NETCONF response. For example,
> let's say that I send a following valid cease NOTIFICATION message to
> a Juniper router running Junos version 25.2R1.9:
>
> Border Gateway Protocol - NOTIFICATION Message
>     Marker: ffffffffffffffffffffffffffffffff
>     Length: 34
>     Type: NOTIFICATION Message (3)
>     Major error Code: Cease (6)
>     Minor error Code (Cease): Administratively Shutdown (2)
>     BGP Shutdown Communication Length: 12
>     Shutdown Communication: \vmaintenance
>
> ff ff ff ff ff ff ff ff ff ff ff ff ff ff   ..............
> ff ff 00 22 03 06 02 0c 0b 6d 61 69 6e 74 65 6e   ...".....mainten
> 61 6e 63 65                                       ance
>
> As seen above, the 0x0c is the length of the Shutdown Communication
> field in octets and the "0b 6d 61 69 6e 74 65 6e 61 6e 63 65" is the
> message. Calling the "get-bgp-neighbor-information" or
> "get-bgp-summary-information" RPC on that router would include the
> character 0x0b, which is invalid in XML 1.0.

The Shutdown Communication is _supposed_ to only contain valid UTF-8,
but of course neighbors can put any bytes they want on the wire (as you
noticed!).

If I worked at Juniper/HPE ... I'd use something like strnvis() to
sanitize the (untrusted) network input contained within a Shutdown
Communication. See the documentation here https://man.openbsd.org/vis.3
This is what OpenBGPD uses in order to avoid logging raw control
character sequences into the router's syslog facility.

Running the sequence you provided through a command line utility that
calls vis(), one can see that the non-printable character is replaced by
an encoding which uses a backslash ‘\’ character to introduce special
sequences. Vis encoding is a unique, invertible representation composed
entirely of graphic characters. Perfect for stuff like this!

        $ echo 0b6d61696e74656e616e6365 | xxd -r -ps | hexdump -C
        00000000  0b 6d 61 69 6e 74 65 6e  61 6e 63 65              |.maintenance|
        0000000c

        $ echo 0b6d61696e74656e616e6365 | xxd -r -ps | vis
        \^Kmaintenance

        $ echo 0b6d61696e74656e616e6365 | xxd -r -ps | vis | hexdump -C
        00000000  5c 5e 4b 6d 61 69 6e 74  65 6e 61 6e 63 65        |\^Kmaintenance|
        0000000e

In any case, it is the vendor duty to not emit invalid XML... I recomend
you reach out to JTAC-- because from what you shared it seems there is
more work to be done in the Junos implementation.

Kind regards,

Job
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/NVTJ3N34FYGE6JH6N2AKGEEPJDUPVYU6/