Further to my email two and a half hours ago, it seems that the prefix causing OpenBGPd speakers to die is 18.104.22.168/23, which is originated by a 4-byte ASN speaker.
OpenBGPd is checking AS4_PATH to ensure that it contains only AS_SET and AS_SEQUENCE types, as per RFC4893. When processing the UPDATE for 22.214.171.124/23 it sees :
Path Attributes - Origin: Incomplete
Flags: 0x40 (Well-known, Transitive, Complete)
Origin: Incomplete (2)
AS_PATH: xx xx 35320 23456 (13 bytes)
AS4_PATH: (65044 65057) 196629 (7 bytes)
RFC4893 is clear on the matter :
To prevent the possible propagation of confederation path segments
outside of a confederation, the path segment types AS_CONFED_SEQUENCE
and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH
OpenBGPd is therefore dropping the sessions when this update is received. Unideal if this attribute is learned on multiple upstreams...
The impact today is fairly limited as there are relatively few bgp speakers honouring the 4-byte ASN protocol extension rules, but as code that support these features creeps around the internet, the next time this happens the impact could be much greater, so we need to understand which implementation of which BGP software caused this illegal origination.
Modifying the OpenBGPd software to permit AS_CONFED_SEQUENCE, AS_CONFED_SET in an as4_path causes the path to be accepted and the session is not torn down. This isn't a great fix.
From a software point of view, I agree that a configurable option to reject the route but keep the session, reject the route and drop the session, accept the route but log/send trap, etc. would be nicer, but this is an implementation thing and probably beyond the scope of this list.
For now, does anyone have contacts at 196629 or 35320 who can explain the implementation and fix the behaviour ?