[OPSEC] [Fwd: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH]

[Joel Jaeggli <[e-mail]>]

something to think about in the context of forwarding transitive
attributes that may not be understood by all devices in the path.

-------- Original Message --------
Subject: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH
Date: Fri, 16 Jan 2009 12:57:19 +0000
From: Rob Shakir <[e-mail]>
To: [e-mail], [e-mail]

Strict RFC 4893 (4-byte ASN support) BGP4 implementations are vulnerable
to a
session reset by distant (not directly connected) ASes. This
vulnerability is a
feature of the standard, and unless immediate action is taken an
increasingly
significant number of networks will be open to attack. Accidental
triggering of
this vulnerability has already been seen in the wild, although the limited
number of RFC 4893 deployments has limited its effect.

Summary:
It is possible to cause BGP sessions to remotely reset by injecting
invalid data
into the AS4_PATH attribute provided to store 4-byte ASN paths. Since
AS4_PATH
is an optional transitive attribute, the invalid data will be transited
through
many intermediate ASes which will not examine the content. To be
vulnerable, an
operator does not have to be actively using 4-byte AS support. This
problem was
first reported by Andy Davidson on NANOG in December 2008 [0],
furthermore we
have been able to demonstrate that a device running Cisco IOS release
12.0(32)S12 behaves as per this description.

Details:

When a prefix is learnt from a BGP neighbour that does not support
4-byte ASNs,
the AS4_PATH attribute is retained, and appended to UPDATE messages sent to
other neighbours [1, 3]. RFC4893 specifies that AS_CONFED_SEQUENCE and
AS_CONFED_SET are invalid in an AS4_PATH, the intention of which is to
ensure
that an AS with a mix of AS4-aware BGP speakers, and AS4-unaware BGP
speakers
does not propagate confederation AS paths outside of the confederation
[1, 3].
Upon receiving an invalid BGP UPDATE message, a BGP speaker must send a
NOTIFICATION message [2, 6.3], after a NOTIFICATION message, the BGP
connection
is closed [2, 4.5].

Analysis of the Reported Path:

On 10th December 2008, a BGP update was propagated with illegal/invalid
confederation attributes in the AS4_PATH.  When this update was received
by AS4
aware BGP speakers, the RFCs described above were interpreted literally
and the
session was torn down. Because the illegal attributes were learned on a
transit
session, an affected network can have global reachability impaired.

Please note that the analysis of this path describes what we expect to have
happened in this case, it has not been confirmed by any of the ASNs
involved.

91.207.218.0/23
	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)

In this data, the AS_PATH indicates that a prefix is announced by an AS4
speaker
(as indicated by AS23456) and propagated through by AS35320. The
AS4_PATH data
shows that the AS4 originator is AS196629, the rest of this path is an
AS_CONFED_SEQUENCE [3, 5]. It would appear that in this case, AS196629 peers
with AS35320, which is AS4-aware on this border. The prefix is then
propagated
through AS35320, with the AS4 aware routers appending their ASN to the
AS_CONFED_SEQUENCE. This is in contravention of RFC 4893 [1, 3]. The border
which announces this route to AS35320's upstream does not appear to be
AS4-aware. During normal announcements, the BGP speaker on a border with an
upstream ASN that is not part of the confederation will remove the left-most
AS_CONFED_SETs or AS_CONFED_SEQUENCEs that exist in the AS_PATH [3, 6.1] and
replace them with the confederation identifier. However, due to the fact
that
both AS_CONFED_SET and AS_CONFED_SEQUENCE are invalid in an AS4_PATH,
then no
such action is taken on the border between an AS4 aware AS, and a
non-AS4 aware
AS. In addition, since the AS35320 border is not AS4 aware, then it does not
update the AS4_PATH.

This malformed UPDATE is then sent to AS35320's upstream, if there are no
AS4-aware routers in the path between the AS35320 border, and an AS
receiving
this update, the AS4_PATH will not have been analysed. The first AS4-aware
router to receive this update will reset the session towards the
neighbour from
whom it receives the update.

The border which announces this route to AS35320's upstream does not
appear to
be AS4-aware; If it were a strict AS4 implementation it would reset the BGP
session due to the malformed AS4_PATH, and a broken implementation that
treats
AS4_PATH as an equivalent of the AS_PATH would sanitise the AS4_PATH. This
allows the AS4_PATH containing an AS_CONFED_SET to be passed to neighbouring
networks.

This escape of an AS_CONFED_SET from a network with only partial AS4
support is
exactly the situation that RFC 4893 attempts to avoid by forbidding the
presence
of an AS_CONFED_SET in the AS4_PATH. In the ideal world the neighbouring
network
receiving an UPDATE containing this obviously malformed AS4_PATH would
reset the
session, preventing further propagation and isolating the broken network.

Unfortunately the vast majority of networks do not support AS4 so pass
on this
malformed AS4_PATH to their neighbours. The first AS4-aware router to
receive
this update will reset the session towards the neighbour from whom it
received
the update.

Cisco IOS Behaviour:

In a lab environment, a Cisco 7200 running IOS 12.0(32)S12, which is able to
support 4-byte ASNs, was peered with a Cisco 2811 running 12.4(19). When
the BGP
session to the upstream 2811 is established by the 7200, the following log
messages are observed:

*Jan 16 11:29:58.531: %BGP-5-ADJCHANGE: neighbor 193.239.32.2 Up
*Jan 16 11:30:02.595: %BGP-6-ASPATH: Invalid AS path (65044 65048 65062)
3.21 23456 received from 193.239.32.2: Confederation found in AS4_PATH
*Jan 16 11:30:02.595: %BGP-5-ADJCHANGE: neighbor 193.239.32.2 Down BGP
Notification sent
*Jan 16 11:30:02.595: %BGP-3-NOTIFICATION: sent to neighbor 193.239.32.2
3/1 (update malformed) 27 bytes E0111803 030000FE 140000FE 180000FE 26
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0050 0200 0000 3540 0101 0240
020C 0205 3D25 2114 89F8 5BA0 5BA0 4003 04C1 EF20 02E0 1118 0303 0000
FE14 0000 FE18 0000 FE26 0202 0003 0015 0000 5BA0 175B CFDA

The configuration on the 7200 is as follows:

router bgp 65123
 no synchronization
 bgp log-neighbor-changes
 neighbor 193.239.32.2 remote-as 15653
 no auto-summary

The BGP session will continue to be reset each time the invalid AS4_PATH is
received.

Possible Impact:

During a BGP conversation, it is expected that a neighbour's UPDATE
messages are
sanitised by the immediate neighbour, during a 'normal' BGP
conversation, if a
BGP speaker receives an invalid UPDATE, it will teardown the session,
and this
invalid UPDATE will not propagate any further. In the case of optional
transitive attributes such as AS4_PATH, this invalid update can be transited
through many ASes, as the content of the invalid attribute in the UPDATE
message
is not examined.

In a hypothetical scenario, an AS4 aware service provider (A) has a transit
provider (T) that is not AS4 aware. BGP speaker B, a large distance from
A has a
bug affecting their equipment that introduces an AS_CONFED_SET in the
AS4_PATH.
Since B's updates are propagated through to A via T, A will tear down the
session to T due to the malformed attribute. This is an out of proportion
reaction as the update may affect only one prefix in a full BGP table.
If this
update is also propagated through A's other transit providers A may lose
full-table visibility until one of their transit providers filters the
route.
Examining the UPDATE message to establish which route caused session
teardown
may be a non-trivial activity.


Conclusion:

Whilst this description may be applied to invalid data in any optional
transitive element, it has a greater impact with AS4_PATH due to the large
number of BGP speakers that currently do not examine any 4-byte ASN data
in an
UPDATE. There has been a discussion of this matter on the IETF IDR
mailing list
[4], however, due to availability of Cisco IOS containing AS4 support
(12.0(32)S12), and an observation of this problem 'in the wild', we
believe that
it is of operational concern to those that are planning on deployment of
AS4-aware platforms [5].

Any input from the operational community relating to this problem is much
appreciated, either publicly, or privately.

Regards,
	Andy Davidson, NetSumo ([e-mail]),
	Jonathan Oddy, Hostway UK ([e-mail]),
	Rob Shakir, GX Networks ([e-mail])

References:
[0]: Andy Davidson - 91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 -
     announced with AS_CONFED_SEQUENCE in AS4_PATH - propagated by 35320,
     http://markmail.org/message/3ofvjyggayfxezna
[1]: rfc4893: BGP Support for Four-octet AS Number Space
[2]: rfc4271: A Border Gateway Protocol 4 (BGP-4)
[3]: rfc3054: Autonomous System Confederations for BGP
[4]: Kaliraj Vairavakkalai, Juniper Networks, [Idr] RFC-4893 handling
malformed
     AS4_PATH attributes,
     http://www.ietf.org/mail-archive/web/idr/current/msg03368.html
[5]: http://as4.cluepon.net/index.php/Software_Support

Thanks to Will Hargrave (LONAP) for assistance with this document.

_______________________________________________
OPSEC mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/opsec