[lacnog] Problemas de ruteo con nuevo atributo

Vie Sep 3 09:49:53 BRT 2010

On Thu, Sep 2, 2010 at 11:33 AM, Sanchez, Alvaro <asanchez en antel.com.uy> wrote:
> Muy bueno el artículo! Veo que una vez detectado el incidente, actuaron muy
> abiertamente, reconociendo mejoras a llevar adelante en futuras pruebas.
>
> Afortunadamente, la vulnerabilidad salió a luz por la acción de gente bien
> intencionada, que luego actuó constructivamente. Da para pensar . . .

Si bien el artículo dice "[t]he attribute used by the RIS had never
been announced on the Internet before, although it was in accordance
with the BGP specification", siendo RIPE/Duke bien podrían haber
averiguado previamente con Cisco et al. si sus routers lo soportaban.

Debemos pensar en la responsabilidad de estas "pruebas" en una red en
producción. Los que somos o fuimos operadores de red sabemos de la
importancia de esto. ¿Qué hubiera pasado si en vez de RIPE/Duke
University hubiera sido Corea del Norte el que hubiera hecho esta
prueba? ¿O si hubiera salido de alguno de nuestros paises? A la
primera la hubieran bombardeado, a nuestros paises los hubieran puesto
en algún blacklist. ¿Si son europeos es buena intención?

Tomás Lynch

>
> Saludos.
>
>
>
> ________________________________
>
> De: lacnog-bounces en lacnic.net [mailto:lacnog-bounces en lacnic.net] En nombre
> de Arturo Servin
> Enviado el: Miércoles, 01 de Septiembre de 2010 04:17 p.m.
> Para: Latin America and Caribbean Region Network Operators Group
> Asunto: Re: [lacnog] Problemas de ruteo con nuevo atributo
>
>
>
>
>
> RIPE NCC and Duke University BGP Experiment
>
> http://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment
>
>
>
> -as
>
>
>
> On 28 Aug 2010, at 18:36, Sanchez, Alvaro wrote:
>
> Gracias!
>
>
>
> ________________________________
>
> De: lacnog-bounces en lacnic.net
> Para: Latin America and Caribbean Region Network Operators Group
> Enviado: Fri Aug 27 19:44:40 2010
> Asunto: Re: [lacnog] Problemas de ruteo con nuevo atributo
>
>
>
>
>
> Lo que he leído en NANOG es que si estuvo bastante probado (en laboratorio
> claro) pero hubo algunos routers con bugs que no supieron manejar el
> atributo. En teoría por estándar los routers aunque no supieran acerca del
> atributo deberian haberlo manajedo diferente (no estoy seguro si ignorar el
> anuncio o dejarlo pasarlo sin modificar) pero en vez de eso lo modificaron
> con datos erroneos y eso hizo que las sesiones se resetearan.
>
>
>
> Slds,
>
> -as
>
>
>
> On 28 Aug 2010, at 06:26, Sanchez, Alvaro wrote:
>
> Interesante!
> No percibimos problemas.
> Espero que lo hayan probado exhaustivamente antes de ponerlo en operación .
> . .
> Saludos,
> Alvaro.
>
>
>
> ________________________________
>
> De: lacnog-bounces en lacnic.net
> Para: Latin America and Caribbean Region Network Operators Group
> Enviado: Fri Aug 27 16:57:56 2010
> Asunto: [lacnog] Problemas de ruteo con nuevo atributo
>
>
>
>
>
>
>
> Creo que este mensaje de RIPE NCC es importante para la comunidad de ruteo.
> No se si a alguno le haya impactado en sus operaciones.
>
>
>
> Slds
>
> asn
>
>
>
> Date: Fri, 27 Aug 2010 11:42:17 -0700 (PDT)
> From: Lucy Lynch <llynch en civil-tongue.net>
> Subject: Re: Did your BGP crash today?
> To: Grzegorz Janoszka <Grzegorz en Janoszka.pl>
> Cc: nanog en nanog.org
> Message-ID: <alpine.BSF.2.00.1008271141540.79214 en hiroshima.bogus.com>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> FYI:
>
> ----------------------------------------------------------------------
> Dear Colleagues,
>
> On Friday 27 August, from 08:41 to 09:08 UTC, the RIPE NCC Routing
> Information Service (RIS) announced a route with an experimental BGP
> attribute. During this announcement, some Internet Service Providers
> reported problems with their networking infrastructure.
>
> Investigation
> --------------
>
> Immediately after discovering this, we stopped the announcement and
> started investigating the problem. Our investigation has shown that the
> problem was likely to have been caused by certain router types
> incorrectly modifying the experimental attribute and then further
> announcing the malformed route to their peers. The announcements sent
> out by the RIS were correct and complied to all standards.
>
> The experimental attribute was part of an experiment conducted in
> collaboration with a group from Duke University. This involved
> announcing a large (3000 bytes) optional transitive attribute, using a
> modified version of Quagga. The attribute used type code 99. The data
> consisted of zeros. We used the prefix 93.175.144.0/24 for this and
> announced from AS 12654 on AMS-IX, NL-IX and GN-IX to all our peers.
>
> Reports from affected ISPs showed that the length of the attribute in
> the attribute header, as seen by their routers, was not correct. The
> header stated 233 bytes and the actual data in their samples was 237
> bytes. This caused some routers to drop the session with the peer that
> announced the route.
>
> We have built a test set-up which is running identical software and
> configurations to the live set-up. From this set-up, and the BGP packet
> dumps as made by the RIS, we have determined that the length of the data
> in the attribute as sent out by the RIS was indeed 3000 bytes and that
> all lengths recorded in the headers of the BGP updates were correct.
>
> Beyond the RIS systems, we can only do limited diagnosis. One possible
> explanation is that the affected routers did not correctly use the
> extended length flag on the attribute. This flag is set when the length
> of the attribute exceeds 255 bytes i.e. when two octets are needed to
> store the length.
>
> It may be that the routers may not add the higher octet of the length to
> the total length, which would lead, in our test set-up, to a total
> packet length of 236 bytes. If, in addition, the routers also
> incorrectly trim the attribute length, the problem could occur as
> observed. It is worth noting that the difference between the reported
> 233 and 237 bytes is the size of the flags, type code and length in the
> attribute.
>
> We will be further investigating this problem and will report any
> findings. We regret any inconvenience caused.
>
> Kind regards,
>
> Erik Romijn
>
> Information Services
> RIPE NCC
> _______________________________________________
> tech-l mailing list
> tech-l en ams-ix.net
> http://melix.ams-ix.net/mailman/listinfo/tech-l
>
>
>
> - Lucy
>
> ________________________________
>
[snip]
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
>
>