<div dir="ltr">Voy a labrar en piedra la respuesta corta junto a otras máximas de la redes IP.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-04-27 3:55 GMT-04:00 Fernando Gont <span dir="ltr"><<a href="mailto:fgont@si6networks.com" target="_blank">fgont@si6networks.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 04/26/2016 07:10 PM, Julio Oses wrote:<br>
> Buenas Tardes.<br>
><br>
> Les escribo para consultarles , debido a temas de seguridad se nos ha<br>
> solicitado en una implementación de IPV6 ( La primera en mi empresa ),<br>
> reemplazar el uso de NDP con SEND que debe mejorar la seguridad del primero.<br>
<br>
</span>Sugiera enviar estas preguntas a <a href="mailto:seguridad@lacnic.net">seguridad@lacnic.net</a> (o en su defecto<br>
hacer CC a dicha lista).<br>
<span class=""><br>
<br>
<br>
> Inicialmente se esperaba utilizar NDP para brindarle a los clientes<br>
> autoconfiguration , pero por lo comentado anteriomente se nos solicita<br>
> usar SEND.<br>
><br>
> Verificando la información vemos que se requiere la utilización de un<br>
> servidor que maneje los certificados y este es el punto que no nos queda<br>
> claro.<br>
><br>
> Se acostumbra usar SEND contra los clientes a nivel masivo o esto es mas<br>
> orientado a sesiones contra proveedores.<br>
><br>
> Alguien posee documentación que pueda usar de referencia, nos estamos<br>
> basando en el RFC y los ejemplos que hemos encontrado navegando.<br>
<br>
</span>Respuesta corta: olvidate de usar SEND.<br>
<br>
<br>
Respuesta larga:<br>
<br>
1) La mayoria de los sistemas operativos de uso general no soportan SEND.<br>
<br>
2) Tal como lo indicas, el uso de SEND (al menos en lo que a SLAAC<br>
respecta) implica un PKI -- con todo lo que ello implica.<br>
<br>
3) Si los mensajes de SEND llegaran a necesitar fragmentacion, send te<br>
abriria la puerta a ataques de denegacion de servicio (utilizarias<br>
fragmentos IPv6 para lograr que los paquetes SEND sean descartados).<br>
(ver Seccion 3 de: <<a href="http://www.rfc-editor.org/rfc/rfc6980.txt" rel="noreferrer" target="_blank">http://www.rfc-editor.org/rfc/rfc6980.txt</a>>)<br>
<br>
4) Es terriblemente probable que en la red en cuestion tengas vetores de<br>
ataque mas importantes y mas faciles de mitigar. Cosas tales como<br>
RA-Guard (*), SAVI y demás pueden ser de ayuda.<br>
<br>
5) Estos dos articulos pueden ser de tu interes:<br>
<br>
*<br>
<<a href="http://searchnetworking.techtarget.com/tip/How-to-avoid-IPv6-neighbor-discovery-threats" rel="noreferrer" target="_blank">http://searchnetworking.techtarget.com/tip/How-to-avoid-IPv6-neighbor-discovery-threats</a>><br>
<br>
*<br>
<<a href="http://searchnetworking.techtarget.com/tip/Mitigating-IPv6-neighbor-discovery-attacks" rel="noreferrer" target="_blank">http://searchnetworking.techtarget.com/tip/Mitigating-IPv6-neighbor-discovery-attacks</a>><br>
<br>
<br>
<br>
(*) tener en cuenta cosas como estas:<br>
<<a href="http://www.rfc-editor.org/rfc/rfc7113.txt" rel="noreferrer" target="_blank">http://www.rfc-editor.org/rfc/rfc7113.txt</a>><br>
<br>
Saludos cordiales,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Fernando Gont<br>
SI6 Networks<br>
e-mail: <a href="mailto:fgont@si6networks.com">fgont@si6networks.com</a><br>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
_______________________________________________<br>
LACTF mailing list<br>
<a href="mailto:LACTF@lacnic.net">LACTF@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lactf" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lactf</a><br>
Cancelar suscripcion: <a href="mailto:lactf-unsubscribe@lacnic.net">lactf-unsubscribe@lacnic.net</a><br>
</div></div></blockquote></div><br></div>