Decode BGP Shutdown Communication messages (RFC 8203)

[Ondrej Zajicek]

On Thu, Jul 27, 2017 at 05:55:40PM +0200, Job Snijders wrote:
> Hi all,
> 
> Here is a patch to decode received BGP shutdown communication messages
> as specified in RFC 8203. In the following example scenario I'm sending
> a shutdown communication with openbgpd:
> 
> 	$ bgpctl neighbor 94.142.241.204 down "TICKET-2331 we are upgrading, back in 30 min"
> 	request processed

Hi

Merged with some significant changes, with support for both RX and TX of
shutdown communication:

https://gitlab.labs.nic.cz/labs/bird/commit/cd1d99611e445c9fe2452d05627ccfc624f35c39

I generalized it a bit, so the message is not specific to BGP, but can be
attached to any protocol, so it makes sense that it can be changed by
general commands like disable, restart. That means it also changed the
output a bit:

bird> show protocols all bgp2
name     proto    table    state  since       info
bgp2     BGP      master   down   19:39:00    
  Description:    My BGP session
  Message:        Planned shutdown, back in 30 min
  Preference:     100
  Input filter:   ACCEPT
  Output filter:  (unnamed)
  BGP state:          Down
    Neighbor address: 10.0.1.1
    Neighbor AS:      10

Conceptually, it is one-item mailbox, which can be set by either the core
(using enable/disable/restart commands) or the protocol (received BGP
Notification with the RFC 8203 message). I am not sure if it would not be
better to have two separate mailboxes for both directions, but it
probably does not matter.

The message can be send from BIRD shell:

birdc> disable bgp1 "hi, we will upgrade to bird 1.6.4"

Unfortunately, that means that from Unix shell you have to do double qouting:

birdc disable bgp1 '"hi, we will upgrade to bird 1.6.4"'

Currently no support for message associated with 'disabled' in bird.conf
or for message associated with BIRD global shutdown.


Otherwise, there are some minor changes w.r.t. your patch:

1) Your patch requires that RFC 8203 message fills the entire space of
BGP notification (i.e. msg_len + 1 == remaining_len). I do not see any
such requirement in RFC 8203, so i accept if (msg_len + 1 <= remaining_len)

2) I reset the message not with any RX notification, but only with
administrative shutdown/reset notification. That prevents message reset
with subsequent errors unrelated to administrative notification.

3) Proper handling of zero-length messages (should be handled equally
like no message at all according to RFC 8203).

4) Some basic sanitization of received strings to avoid escape-attacks
and newlines in logs.

Any comments, suggestions, opposition?

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."