[Idr] Operational Recommendations on Handling Invalid AS4_PATH Attributes

[Rob Shakir <rjs at eng.gxn.net>]

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. 
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr