BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH

Wed Jan 21 17:24:34 UTC 2009

Hi, folks:

We (IDR Chairs and co-authors) are working on updating RFC 4893 
regarding the handling of the confed related segments in the AS4_PATH 
attribute. Expect to have the revised draft this week.

Thanks.    -- Enke

Rob Shakir wrote:
> Hi,
>
> Further to the initial research sent to NANOG, after discussions with a number
> of operators, we have compiled some recommendations on the handling of invalid
> AS4_PATH attributes. 
>
> Any feedback on these recommendations is appreciated:
>
> As discussed on the IETF IDR list last month, there are concerns relating to the
> treatment of AS_CONFED_SET/SEQUENCE in AS4_PATH as described in RFC4893 [0].
> Since the last post to that thread the situation has been made more urgent with
> the release of Cisco IOS 12.0(32)S12, which responds to malformed AS4_PATH
> attributes by sending a NOTIFICATION to the neighbour, and tearing down the BGP
> adjacency. This behaviour seems to be required by RFC4721 section 6.3, as there
> is no alternative error handling defined in RFC4893. As posted last Friday [1],
> and discussed on the IDR list, this strict implementation introduces a new
> attack vector by which a BGP session can be torn down due to a an attribute
> populated by a distant BGP neighbour. These malformed attributes have already
> been seen in the wild as a result of a error in Juniper's implementation of
> RFC4893. 
>
> Following discussions with a number of operators, we have attempted to generate
> some recommendations relating to the behaviour that would be operationally most
> useful when treating the invalid data in the AS4_PATH optional transitive
> attribute.
>
> There are two cases to consider when an invalid AS4_PATH is received:
>    (1) A path to the prefix is not already known from that neighbour. 
>    (2) A path to the prefix has already been learnt from that neighbour; 
>    
> In case (1) we recommend that the BGP speaker should discard the UPDATE and log
> the fact. The log entry should include the received AS_PATH and
> AS4_PATH to aid in debugging.
>
> In case (2) we recommend that the BGP speaker should treat the UPDATE as a
> withdrawal of existing path to the prefix. As per case (1) a log entry should be
> raised to indicate that this has occurred.
>
> It is quite possible that in both cases this behaviour may result in the BGP
> speaker no longer having a valid path to the destination. We foresee that this
> lack of a prefix in a BGP speaker's routing table may cause some operational
> load initially, however, we feel that this is acceptable, considering the
> alternate behaviours.
>
> Should a prefix be injected into the global table with an invalid AS4_PATH, and
> should the newly advertised (invalid) path be selected by all upstreams
> available to a given ASN then this ASN will lose reachability to the prefix.
> Whilst this can be abused we do not see this as more serious than the existing
> possibility of malicious injection and blackholing of a prefix by a 3rd party.
> As long as the rejection of paths due to invalid AS4_PATHs is clearly reported
> to the administrator the source of the problem can be clearly identified. 
>
> We consider that attempting to extract a valid AS4 or AS_PATH from the invalid
> UPDATE is a mistake since this allows the propagation of invalid BGP data. In
> addition, incorrect implementation of this comparatively complex mechanism by a
> vendor may result in loops. By explicitly not installing prefixes with invalid
> AS_PATH or AS4_PATH into the routing table, the possibility of loops caused by
> these invalid paths is avoided.
>
> The defined behaviour in RFC4893 and RFC4271 has significantly harmful effects
> and it seems only by virtue of the fact that the implementations of many vendors
> do not strictly comply with the RFCs that this problem has not had the same
> impact for every vendor. At the current time, however, one cannot deploy a
> 4-byte capable Cisco IOS device, or an OpenBGP (current stable release) router
> into the global table, without risking teardown of a every session via which a
> global table is learnt.
>
> Further discussion of this issue would be much appreciated, as a common and
> consistent approach to rectifying the problem will benefit network operators far
> more than individual vendor implementing their own solution. Should a consensus
> be reached an update to the RFC is required in order to ensure that future
> implementations do not exhibit this harmful behaviour.
>
> Kind regards,
>         Andy Davidson (NetSumo), andy.davidson at netsumo.com
>         Jonathan Oddy (HostWay), jonathan.oddy at hostway.co.uk 
>         Rob Shakir (GX Networks), rjs at eng.gxn.net
>
> [0]: http://www.ietf.org/mail-archive/web/idr/current/msg03368.html
> [1]: http://www.merit.edu/mail.archives/nanog/msg14345.html
>
> Many thanks to David Freedman (Claranet) for assistance in developing the
> recommendations in this document. 
>
>
>
>
>
>   