[LAC-TF] No Export (Era Re: IPv6 networking: Bad news for small biz)

[Arturo Servin]

	 https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-discard-prefix/

"Remote triggered black hole filtering describes a method of
   mitigating the effects of denial-of-service attacks by selectively
   discarding traffic based on source or destination address.  Remote
   triggered black hole routing describes a method of selectively re-
   routing traffic into a sinkhole router (for further analysis) based
   on destination address.  This document updates RFC5156 by explaining
   why a unique IPv6 prefix should be formally assigned by IANA for the
   purpose of facilitating IPv6 remote triggered black hole filtering
   and routing."

Slds
as

On 13 Apr 2012, at 12:31, Carlos Martinez-Cagnazzo wrote:

> Si, ese es un topico relacionado excelente. Nosotros incluso podemos
> alojar un wiki o una pagina web donde documentar esas cosas, y donde los
> ISPs participantes se puedan anotar.
> 
> s2
> 
> Carlos
> 
> On 4/13/12 12:21 PM, Alejandro Acosta wrote:
>> Hola,
>>  Esto tópicos serían excelentes.
>>  En estos días reunidos con un ISP (tipo Data Center) y conversando
>> con un upstream provider conversamos sobre otro uso de communities que
>> me pareció super interesante. Lo explico:
>> 
>> 1)  Supongamos que yo tengo asignado un bloque /20, ahora bien me
>> estan atacando el host (o la red, no importa) ZZ.XX.CC.VV/24.
>> 
>> 2) Cuando esto ocurra, le publico ZZ.XX.CC.VV/24 a mi upstream
>> provider con el community NNN que quiere decir, "enrutalo a
>> null/drop". De esa manera evito el ataque aguas abajo, ahorro mi
>> enlace internacional, etc, etc. L
>> 
>> Saludos,
>> 
>> Alejandro,
>> 
>> 
>> 
>> On 4/13/12, Carlos Martinez-Cagnazzo <carlosm3011 at gmail.com> wrote:
>>> Creo que puede ser un muy buen topico para LACNOG el establecer
>>> practicas regionales de uso de communities, ademas de las 'well-known'
>>> como la NO_EXPORT.
>>> 
>>> On 4/13/12 11:58 AM, Arturo Servin wrote:
>>>> Cambie de subject y solo pego esta parte del correo porque me parecio
>>>> adecuado comentarlo separado.
>>>> 
>>>> Aqui lo que se debe hacer es anunciar el agregado por todos los
>>>> enlaces, por ejemplo un /20. Por cada uno de los enlaces anunciar el
>>>> bloque desagregado (por ejemplo /21) con una comunidad de no-export.
>>>> De esa forma puedes balancear tu tráfico sin llenar de rutas la tabla
>>>> de ruteo global.
>>>> 
>>>> Esto solo funciona si eres uni-homed, si eres multi-homed quiza si
>>>> tengas que partir tus bloques. Sin embargo, por lo que se ve en los
>>>> anuncios de ruteo, si la práctica de usar el "no-export" fuera más
>>>> usada podríamos reducir el número de rutas que generamos en la región.
>>>> 
>>>> Saludos,
>>>> .as
>>>> 
>>>> On 12 Apr 2012, at 10:51, Luis Carlos Solano wrote:
>>>> 
>>>>> Lo complicado de esto, sería un caso como este: supongamos que un ISP
>>>>> tiene un cliente tan grande, que le llena totalmente uno de sus
>>>>> enlaces de upstream de ahí que se deba anunciar a ese único cliente
>>>>> por aparte. Quizá no sea una mala configuración del ISP.
>>>> 
>>>> 
>>>> _______________________________________________
>>>> LACTF mailing list
>>>> lactf at lac.ipv6tf.org
>>>> https://mail.lacnic.net/mailman/listinfo/lactf
>> _______________________________________________
>> LACTF mailing list
>> lactf at lac.ipv6tf.org
>> https://mail.lacnic.net/mailman/listinfo/lactf
> _______________________________________________
> LACTF mailing list
> lactf at lac.ipv6tf.org
> https://mail.lacnic.net/mailman/listinfo/lactf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20120413/cc523359/attachment-0001.html>