[LACNIC/Seguridad] Análisis de seguridad del protocolo IP

Roque Gagliano roque en lacnic.net
Mie Ago 20 15:58:02 BRT 2008


Fernando:

Muy bueno el documento, como comentario general creo que a estas  
alturas habria que aclarar cuando se refiere a IP, es en general, es  
sobre IPv4 o IPv6 en particular.

Otro comentario:
En la sección 3.1, Header dice: in practice different versions of IP  
are identified by a different “Protocol Type”
number in the link-layer protocol header. For example, IPv4 datagrams  
are encapsulated
in Ethernet frames using a “Protocol Type” field of 0x0800, while IPv6  
datagrams are
encapsulated in Ethernet frames using a “Protocol Type” field of  
0x86DD [IANA, 2006a].
Therefore if an IPv4 module receives a packet, the Version field must  
be checked to be 4.
If this check fails the packet should be silently dropped

Eso no es correcto para medios que no son Ethernet. En particular hay  
otros medios como PPP IPv6 utiliza Ox0057 como Protocol field, y hay  
otros ejemplos como AAL5, etc. . Creo que debería quedar claro que el  
caso ethernet es un ejemplo.

r.


On Aug 14, 2008, at 3:47 PM, Fernando Gont wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hola a todos,
>
> El Centre for the Protection of National Infrastructure (CPNI) del  
> Reino
> Unido acaba de publicar el documento "Security Assessment of the  
> Internet
> Protocol", en el cual he trabajado durante estos últimos años.
>
> Lo que motivó este trabajo se encuentra detallado en el prefacio del
> documento, que dice:
>
> - ---- cut here ----
> The TCP/IP protocols were conceived during a time that was quite  
> different
> from the hostile environment they operate in now. Yet a direct  
> result of
> their
> effectiveness and widespread early adoption is that much of today’s
> global economy remains dependent upon them.
>
> While many textbooks and articles have created the myth that the  
> Internet
> Protocols (IP) were designed for warfare environments, the top level  
> goal
> for the DARPA Internet Program was the sharing of large service  
> machines on
> the ARPANET. As a result, many protocol specifications focus only on  
> the
> operational aspects of the protocols they specify and overlook their
> security implications.
>
> Though Internet technology has evolved, the building blocks are  
> basically
> the same core protocols adopted by the ARPANET more than two decades  
> ago.
> During the last twenty years many vulnerabilities have been  
> identified in
> the TCP/IP stacks of a number of systems. Some were flaws in protocol
> implementations which affect only a reduced number of systems.  
> Others were
> flaws in the protocols themselves affecting virtually every existing
> implementation. Even in the last couple of years researchers were  
> still
> working on security problems in the core protocols.
>
> The discovery of vulnerabilities in the TCP/IP protocols led to  
> reports
> being published by a number of CSIRTs (Computer Security Incident  
> Response
> Teams) and vendors, which helped to raise awareness about the  
> threats as
> well as the best mitigations known at the time the reports were  
> published.
>
> Much of the effort of the security community on the Internet  
> protocols did
> not result in official documents (RFCs) being issued by the IETF  
> (Internet
> Engineering Task Force) leading to a situation in which “known”
> security problems have not always been addressed by all vendors. In  
> many
> cases vendors have implemented quick “fixes” to protocol flaws without
> a careful analysis of their effectiveness and their impact on
> interoperability.
>
> As a result, any system built in the future according to the official
> TCP/IP specifications might reincarnate security flaws that have  
> already
> hit our communication systems in the past.
>
> Producing a secure TCP/IP implementation nowadays is a very  
> difficult task
> partly because of no single document that can serve as a security  
> roadmap
> for the
> protocols.
>
> There is clearly a need for a companion document to the IETF  
> specifications
> that discusses the security aspects and implications of the protocols,
> identifies the possible threats, proposes possible counter-measures,  
> and
> analyses their respective effectiveness.
>
> This document is the result of an assessment of the IETF  
> specifications of
> the Internet Protocol from a security point of view. Possible  
> threats were
> identified and, where possible, counter-measures were proposed.
> Additionally, many implementation flaws that have led to security
> vulnerabilities have been referenced in the hope that future
> implementations will not incur the same problems. This document does  
> not
> limit itself to performing a security assessment of the relevant IETF
> specification but also offers an assessment of common implementation
> strategies.
>
> Whilst not aiming to be the final word on the security of the IP, this
> document aims to raise awareness about the many security threats  
> based on
> the IP protocol that have been faced in the past, those that we are
> currently facing, and those we may still have to deal with in the  
> future.
> It provides advice for the secure implementation of the IP, and also
> insights about the security aspects of the IP that may be of help to  
> the
> Internet operations community.
>
> Feedback from the community is more than encouraged to help this  
> document
> be as accurate as possible and to keep it updated as new threats are
> discovered.
> - ---- cut here ----
>
> El documento en cuestión se encuentra disponible en el sitio de CPNI:
> http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx
>
> Saludos cordiales,
> Fernando Gont
>
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Desktop 9.5.3 (Build 5003) - not
> licensed for commercial use: www.pgp.com
>
> wsBVAwUBSKR9C2l+Jnd3SMmAAQgxnAf/YLIxsmYI8kx5f7yvjg8SHPIympTql6wQ
> 9uRayPbigeAR2qMsdq5hxnKw+ysYTnyrwdBuoOR8IdweFWQVzNc8oDxzP8qdU/qB
> aOFKV24PXdeBND4oy9OIHHvJYRdE5PcGrDqi91BGwaBgJ//dQf39l9tbV28zvWgJ
> Q+wAnJYGzMYr5HZb03GqojudvwBG68Cm2vdLEObelrDRIGhU34o/DvG/VOQG9Rys
> yrikSH+PZlLwka92O5O09WIz3PjloL0xJPcwr8xMi9ikzxKfPOHsbA2SyW2ZkTOt
> RECLQNV3GItmtmr4fjAc97pLrfmg9iWOHmpdGTHzYcbN17x2Wj/wJA==
> =mzXy
> -----END PGP SIGNATURE-----
>
>
> --
> Fernando Gont
> e-mail: fernando en gont.com.ar || fgont en acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20080820/2b31966e/attachment.html>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20080820/2b31966e/attachment.sig>


Más información sobre la lista de distribución Seguridad