[LACNIC/Seguridad] Fwd: BCP 156, RFC 6056 on Recommendations for Transport-Protocol Port Randomization

[Carlos Martinez-Cagnazzo]

Felicitaciones Fernando!

2011/1/19 Fernando Gont <fernando en gont.com.ar>:
> Estimados,
>
> Se acaba de publicar el BCP/RFC titulado "Recommendations for
> Transport-Protocol Port Randomization". El mismo se encuentra disponible
> en: http://www.rfc-editor.org/rfc/rfc6056.txt
>
> Dado el tiempo que llevabamos trabajando en este documento, su
> publicación es una mezcla de alegria y alivio. :-)
>
> Pese a que no está suscripto a esta lista, mi agradecimiento publico va
> para Alfred Hoenes, quien tiene un credito implicito en todo lo que he
> publicado hasta el momento. Su dedicacion y rigurosidad han sido
> escenciales para mejorar la calidad del documento resultante.
>
> P.S.: Este RFC debe leerse tomando mate, con Canarias. ;-)
>
> Un abrazo,
>
> Fernando
>
>
>
>
> -------- Original Message --------
> Subject: BCP 156,       RFC 6056 on Recommendations for Transport-Protocol
> Port Randomization
> Date: Tue, 18 Jan 2011 12:31:58 -0800 (PST)
> From: rfc-editor en rfc-editor.org
> To: ietf-announce en ietf.org, rfc-dist en rfc-editor.org
> CC: tsvwg en ietf.org, rfc-editor en rfc-editor.org
>
>
> A new Request for Comments is now available in online RFC libraries.
>
>        BCP 156
>        RFC 6056
>
>        Title:      Recommendations for Transport-Protocol Port
>                    Randomization
>        Author:     M. Larsen, F. Gont
>        Status:     Best Current Practice
>        Stream:     IETF
>        Date:       January 2011
>        Mailbox:    michael.larsen en tieto.com,
>                    fernando en gont.com.ar
>        Pages:      29
>        Characters: 63913
>        See Also:   BCP0156
>
>        I-D Tag:    draft-ietf-tsvwg-port-randomization-09.txt
>
>        URL:        http://www.rfc-editor.org/rfc/rfc6056.txt
>
> During the last few years, awareness has been raised about a number
> of "blind" attacks that can be performed against the Transmission
> Control Protocol (TCP) and similar protocols.  The consequences of
> these attacks range from throughput reduction to broken connections
> or data corruption.  These attacks rely on the attacker's ability to
> guess or know the five-tuple (Protocol, Source Address, Destination
> Address, Source Port, Destination Port) that identifies the transport
> protocol instance to be attacked.  This document describes a number
> of simple and efficient methods for the selection of the client port
> number, such that the possibility of an attacker guessing the exact
> value is reduced.  While this is not a replacement for cryptographic
> methods for protecting the transport-protocol instance, the
> aforementioned port selection algorithms provide improved security
> with very little effort and without any key management overhead.  The
> algorithms described in this document are local policies that may be
> incrementally deployed and that do not violate the specifications of
> any of the transport protocols that may benefit from them, such as
> TCP, UDP, UDP-lite, Stream Control Transmission Protocol (SCTP),
> Datagram Congestion Control Protocol (DCCP), and RTP (provided that
> the RTP application explicitly signals the RTP and RTCP port
> numbers).  This memo documents an Internet Best Current Practice.
>
> This document is a product of the Transport Area Working Group Working
> Group of the IETF.
>
>
> BCP: This document specifies an Internet Best Current Practices for the
> Internet Community, and requests discussion and suggestions for
> improvements. Distribution of this memo is unlimited.
>
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>  http://www.ietf.org/mailman/listinfo/ietf-announce
>  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>
> For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
> For downloading RFCs, see http://www.rfc-editor.org/rfc.html.
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-editor en rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
>
> The RFC Editor Team
> Association Management Solutions, LLC
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce en ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
>



-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================