From fernando en gont.com.ar Thu Aug 14 15:47:36 2008 From: fernando en gont.com.ar (Fernando Gont) Date: Thu, 14 Aug 2008 15:47:36 -0300 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de_seguridad_del_pro?= =?iso-8859-1?q?tocolo_IP?= Message-ID: <200808141851.m7EIpLiv006226@venus.xmundo.net> -----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 From me en mike.com.mx Sun Aug 17 14:26:16 2008 From: me en mike.com.mx (Miguel Hernandez y Lopez) Date: Sun, 17 Aug 2008 14:26:16 -0300 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de_seguridad=09del_p?= =?iso-8859-1?q?rotocolo_IP?= In-Reply-To: <200808141851.m7EIpLiv006226@venus.xmundo.net> References: <200808141851.m7EIpLiv006226@venus.xmundo.net> Message-ID: <1218993976.9533.6.camel@localhost> Excelente artículo. Buen trabajo Saludos, El jue, 14-08-2008 a las 15:47 -0300, Fernando Gont escribió: > -----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 -- ---- Miguel Hernandez y Lopez http://www.mike.com.mx / http://www.honeynet.org.mx Celular: 1536389434 / Nextel: 62*14*11154 PGP fingerprint: CA40 3439 DF49 A75D 17B2 4561 A31D D837 42FC BD83 "There's no place like 127.0.0.1" ------------ próxima parte ------------ Se ha borrado un mensaje que no está en formato texto plano... Nombre : no disponible Tipo : application/pgp-signature Tamaño : 189 bytes Descripción: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente Url : http://mail.lacnic.net/pipermail/seguridad/attachments/20080817/894ae624/attachment.pgp From roque en lacnic.net Wed Aug 20 15:58:02 2008 From: roque en lacnic.net (Roque Gagliano) Date: Wed, 20 Aug 2008 15:58:02 -0300 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de_seguridad_del_pro?= =?iso-8859-1?q?tocolo_IP?= In-Reply-To: <200808141851.m7EIpLiv006226@venus.xmundo.net> References: <200808141851.m7EIpLiv006226@venus.xmundo.net> Message-ID: 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: http://mail.lacnic.net/pipermail/seguridad/attachments/20080820/2b31966e/attachment.htm ------------ próxima parte ------------ Se ha borrado un mensaje que no está en formato texto plano... Nombre : PGP.sig Tipo : application/pgp-signature Tamaño : 194 bytes Descripción: This is a digitally signed message part Url : http://mail.lacnic.net/pipermail/seguridad/attachments/20080820/2b31966e/attachment.pgp From roque en lacnic.net Wed Aug 20 16:00:01 2008 From: roque en lacnic.net (Roque Gagliano) Date: Wed, 20 Aug 2008 16:00:01 -0300 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de_seguridad_del_pro?= =?iso-8859-1?q?tocolo_IP?= In-Reply-To: <200808141851.m7EIpLiv006226@venus.xmundo.net> References: <200808141851.m7EIpLiv006226@venus.xmundo.net> Message-ID: <34FD7F90-1896-4CB8-8199-D120BD5CFAA3@lacnic.net> Otra cosa Fernando, cuando dicen que no puede haber protocolos orientados a conexion sobre multicast, estudiaron los protocolos como los que se listan aqui: http://tldp.org/HOWTO/Multicast-HOWTO-9.html#sect-trans-prots ??? slds 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: http://mail.lacnic.net/pipermail/seguridad/attachments/20080820/f1279a60/attachment-0001.htm ------------ próxima parte ------------ Se ha borrado un mensaje que no está en formato texto plano... Nombre : PGP.sig Tipo : application/pgp-signature Tamaño : 194 bytes Descripción: This is a digitally signed message part Url : http://mail.lacnic.net/pipermail/seguridad/attachments/20080820/f1279a60/attachment-0001.pgp From fernando en gont.com.ar Wed Aug 20 18:27:42 2008 From: fernando en gont.com.ar (Fernando Gont) Date: Wed, 20 Aug 2008 18:27:42 -0300 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de__seguridad_del_pr?= =?iso-8859-1?q?otocolo_IP?= In-Reply-To: References: <200808141851.m7EIpLiv006226@venus.xmundo.net> Message-ID: <200808202131.m7KLVbOO006248@venus.xmundo.net> Hola, Roque, Millones de gracias por tus comentarios. Mis respuestas van entre lineas (seguí leyendo).... >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. Si, es cierto. Lo arreglaré en la próxima revisión del documento. >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. La idea acá es que el campo "versión" nunca se utiliza para demultiplexar los paquetes IP. En teoría, todas las versiones de IP se podrían identificar con el mismo valor de "Protocol Type" en la link layer y entonces todos los paquetes correspondientes a las distintas versiones del protocolo IP serían procesados por un mismo modulo de código ("general" para el protocolo IP... sin importar su versión). Luego, en base al campo "Version" del header IP, el paquete en cuestión se demultiplexaría al modulo de la versión particular del protocolo IP (por ej., el modulo de IPv4 o el módulo de IPv6). Sin embargo, debido a que directamente las distintas versiones de IP utilizan distintos valores para el campo "Protocol Type" de la link layer, es como que las distintas versiones del protocolo IP se consideran como "distintos protocolos". Y no hace falta utilizar el campo "Version" del header IP para distinguir de que version de IP se trata, ya que el valor del campo "Protocol Type" de la link layer indica implicitamente dicha información. Entonces no hay algo asi como un modulo de codigo "general" para lo que es el protocolo IP, sino que hay un modulo IPv4 al que se le demultiplexan unicamente los paquetes IPv4, y un modulo IPv6 al que se le demultiplexan unicamente los paquetes IPv6. Si el modulo IPv4 encuentra que el campo Version de un paquete que está procesando contiene por ejemplo el valor "6", entonces quiere decir que por ejemplo el campo "Protocol Type" del paquete Ethernet indicaba IPv4 (mediante el valor 0x0800), mientras que el campo Version del IP header indica IPv6. Esto es un error, y por ello el paquete debería ser descartado. Lo que vos decís es que el texto parece indicar que en la link layer *siempre* se utiliza el valor 0x0800 para indicar IPv4? Muchas gracias por tu feedback! Saludos codiales, -- 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: http://mail.lacnic.net/pipermail/seguridad/attachments/20080820/035b3d5f/attachment.htm From roque en lacnic.net Wed Aug 20 22:38:03 2008 From: roque en lacnic.net (Roque Gagliano) Date: Wed, 20 Aug 2008 22:38:03 -0300 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de__seguridad_del_pr?= =?iso-8859-1?q?otocolo_IP?= In-Reply-To: <200808202131.m7KLVbOO006248@venus.xmundo.net> References: <200808141851.m7EIpLiv006226@venus.xmundo.net> <200808202131.m7KLVbOO006248@venus.xmundo.net> Message-ID: Hola Fernando, > > Si el modulo IPv4 encuentra que el campo Version de un paquete que > está procesando contiene por ejemplo el valor "6", entonces quiere > decir que por ejemplo el campo "Protocol Type" del paquete Ethernet > indicaba IPv4 (mediante el valor 0x0800), mientras que el campo > Version del IP header indica IPv6. Esto es un error, y por ello el > paquete debería ser descartado. > > Lo que vos decís es que el texto parece indicar que en la link layer > *siempre* se utiliza el valor 0x0800 para indicar IPv4? > La verdad me cuesta generalizar, acordate que mismo en Ethernet lo que se usa generalmente es Ethernet II, pero existe 802.3, con LLC, existe tocken ring, etc, habria que chequear todas las implementaciones. Nunca he disenado stacks a este nivel, pero esa frase me llamo la atencion. slds r. > Muchas gracias por tu feedback! > > Saludos codiales, > -- > 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: http://mail.lacnic.net/pipermail/seguridad/attachments/20080820/3d4118f6/attachment.htm ------------ próxima parte ------------ Se ha borrado un mensaje que no está en formato texto plano... Nombre : PGP.sig Tipo : application/pgp-signature Tamaño : 194 bytes Descripción: This is a digitally signed message part Url : http://mail.lacnic.net/pipermail/seguridad/attachments/20080820/3d4118f6/attachment.pgp From niedbalski en ip6nw.com Thu Aug 21 00:13:32 2008 From: niedbalski en ip6nw.com (Jorge M. Niedbalski R.) Date: Wed, 20 Aug 2008 23:13:32 -0400 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de_seguridad_del_pro?= =?iso-8859-1?q?tocolo_IP?= In-Reply-To: References: <200808141851.m7EIpLiv006226@venus.xmundo.net> <200808202131.m7KLVbOO006248@venus.xmundo.net> Message-ID: <4fa41cc90808202013s31d6cd55hda4f770c1ef538de@mail.gmail.com> 2008/8/20 Roque Gagliano > Hola Fernando, > > > Si el modulo IPv4 encuentra que el campo Version de un paquete que está > procesando contiene por ejemplo el valor "6", entonces quiere decir que por > ejemplo el campo "Protocol Type" del paquete Ethernet indicaba IPv4 > (mediante el valor 0x0800), mientras que el campo Version del IP header > indica IPv6. Esto es un error, y por ello el paquete debería ser descartado. > > Lo que vos decís es que el texto parece indicar que en la link layer > *siempre* se utiliza el valor 0x0800 para indicar IPv4? > > > La verdad me cuesta generalizar, acordate que mismo en Ethernet lo que se > usa generalmente es Ethernet II, pero existe 802.3, con LLC, existe tocken > ring, etc, habria que chequear todas las implementaciones. Nunca he disenado > stacks a este nivel, pero esa frase me llamo la atencion. > > slds > r. > > > > Muchas gracias por tu feedback! > > Saludos codiales, > > -- > 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 > > > > _______________________________________________ > Seguridad mailing list > Seguridad en lacnic.net > https://mail.lacnic.net/mailman/listinfo/seguridad > Estimado Fernando : Concuerdo con Roque, lo propuesto en la seccion 3.1 solo es valido para 2 de los ethertypes 0x0800 (IPv4) e 0x86DD (IPv6). En el caso de otros ethertypes como 802.3, SPRITE, X.25 Segun el documento ¿ se deberia descartar el paquete , aun cuando se esta encapsulando adecuadamente sobre otro tipo de link layer ? Algunas otras definiciones : #define ETHERTYPE_8023 0x0004 /* IEEE 802.3 packet */ /* 0x0101 .. 0x1FF Experimental */ #define ETHERTYPE_PUP 0x0200 /* Xerox PUP protocol - see 0A00 */ #define ETHERTYPE_PUPAT 0x0200 /* PUP Address Translation - see 0A01 */ #define ETHERTYPE_SPRITE 0x0500 /* ??? */ /* 0x0400 Nixdorf */ #define ETHERTYPE_NS 0x0600 /* XNS */ #define ETHERTYPE_NSAT 0x0601 /* XNS Address Translation (3Mb only) */ #define ETHERTYPE_DLOG1 0x0660 /* DLOG (?) */ #define ETHERTYPE_DLOG2 0x0661 /* DLOG (?) */ #define ETHERTYPE_IP 0x0800 /* IP protocol */ #define ETHERTYPE_X75 0x0801 /* X.75 Internet */ #define ETHERTYPE_NBS 0x0802 /* NBS Internet */ #define ETHERTYPE_ECMA 0x0803 /* ECMA Internet */ #define ETHERTYPE_CHAOS 0x0804 /* CHAOSnet */ #define ETHERTYPE_X25 0x0805 /* X.25 Level 3 */ #define ETHERTYPE_ARP 0x0806 /* Address resolution protocol */ #define ETHERTYPE_NSCOMPAT 0x0807 /* XNS Compatibility */ #define ETHERTYPE_FRARP 0x0808 /* Frame Relay ARP (RFC1701) */ /* 0x081C Symbolics Private */ /* 0x0888 - 0x088A Xyplex */ #define ETHERTYPE_UBDEBUG 0x0900 /* Ungermann-Bass network debugger */ #define ETHERTYPE_IEEEPUP 0x0A00 /* Xerox IEEE802.3 PUP */ #define ETHERTYPE_IEEEPUPAT 0x0A01 /* Xerox IEEE802.3 PUP Address Translation */ #define ETHERTYPE_VINES 0x0BAD /* Banyan VINES */ #define ETHERTYPE_VINESLOOP 0x0BAE /* Banyan VINES Loopback */ #define ETHERTYPE_VINESECHO 0x0BAF /* Banyan VINES Echo */ -- Jorge Niedbalski R. ----------------------------------------- ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: http://mail.lacnic.net/pipermail/seguridad/attachments/20080820/99cb886f/attachment-0001.htm From fernando en gont.com.ar Thu Aug 21 02:26:27 2008 From: fernando en gont.com.ar (Fernando Gont) Date: Thu, 21 Aug 2008 02:26:27 -0300 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de__seguridad_del_pr?= =?iso-8859-1?q?_otocolo_IP?= In-Reply-To: References: <200808141851.m7EIpLiv006226@venus.xmundo.net> <200808202131.m7KLVbOO006248@venus.xmundo.net> Message-ID: <200808210530.m7L5UOoX025145@venus.xmundo.net> At 10:38 p.m. 20/08/2008, you wrote: >>Si el modulo IPv4 encuentra que el campo >>Version de un paquete que está procesando >>contiene por ejemplo el valor "6", entonces >>quiere decir que por ejemplo el campo "Protocol >>Type" del paquete Ethernet indicaba IPv4 >>(mediante el valor 0x0800), mientras que el >>campo Version del IP header indica IPv6. Esto >>es un error, y por ello el paquete debería ser descartado. >> >>Lo que vos decís es que el texto parece indicar >>que en la link layer *siempre* se utiliza el valor 0x0800 para indicar IPv4? > >La verdad me cuesta generalizar, acordate que >mismo en Ethernet lo que se usa generalmente es >Ethernet II, pero existe 802.3, con LLC, existe >tocken ring, etc, habria que chequear todas las >implementaciones. Nunca he disenado stacks a >este nivel, pero esa frase me llamo la atencion. El argumento del documento es que, para versiones distintas del protocolo IP (es decir, IPv6 vs. IPv6), siempre se usan valores distintos de "Protocol Type" a nivel link-layer. Por ello, los paquetes se demultiplexarán a distintos modulos de nivel software de la capa de red. Si el modulo de IPv4 termina procesando un paquete IPv6, es simplemente porque el campo "Protocol Type" de la link layer estaba falsificado (es decir, se puso un 0x0800 en vez de 0x86DD (que es lo que se debería haber puesto). Se entiende? (O es que me pasé algo por alto?) Saludos, -- 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: http://mail.lacnic.net/pipermail/seguridad/attachments/20080821/6b1fe483/attachment.htm From fernando en gont.com.ar Thu Aug 21 02:38:16 2008 From: fernando en gont.com.ar (Fernando Gont) Date: Thu, 21 Aug 2008 02:38:16 -0300 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de__seguridad_del_pr?= =?iso-8859-1?q?otocolo_IP?= In-Reply-To: <4fa41cc90808202013s31d6cd55hda4f770c1ef538de@mail.gmail.co m> References: <200808141851.m7EIpLiv006226@venus.xmundo.net> <200808202131.m7KLVbOO006248@venus.xmundo.net> <4fa41cc90808202013s31d6cd55hda4f770c1ef538de@mail.gmail.com> Message-ID: <200808210542.m7L5gGWN002555@venus.xmundo.net> Hola, Jorge, >Concuerdo con Roque, lo propuesto en la seccion >3.1 solo es valido para 2 de los ethertypes 0x0800 (IPv4) e 0x86DD (IPv6). > >En el caso de otros ethertypes como 802.3, >SPRITE, X.25 Segun el documento ¿ se deberia >descartar el paquete , aun cuando se esta >encapsulando adecuadamente sobre otro tipo de link layer ? mmmm.... no entiendo. El planteo es el siguiente: Si un frame ethernet llega a un host, y su payload se le pasa al modulo de IPv4, es porque el Ehertype del paquete Ethernet era 0x0800. Este valor de Ethertype indica que el payload del paquete Ethernet contiene un paquete IP. Si el Ethertype es 0x0800, pero lo que se encapsula es en realidad un paquete IPv6, esto es una error, ya que en tal caso el Ethertype deberia haber sido 0X86DD, y *no* 0x0800. Del mismo modo, si un modulo IPv6 llegara a "procesar" un paquete IPv4 que llego en un frame Ethernet, es porque el Ethertype fue 0x86DD, en vez de 0x0800, que es el que verdaderamente correspondia. Por tal motivo, esta es una condicion de error. Se entiende el argumento? Saludos cordiales, y gracias por el feedback! -- 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: http://mail.lacnic.net/pipermail/seguridad/attachments/20080821/d78186bd/attachment.htm From niedbalski en ip6nw.com Thu Aug 21 15:24:59 2008 From: niedbalski en ip6nw.com (Jorge M. Niedbalski R.) Date: Thu, 21 Aug 2008 14:24:59 -0400 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de_seguridad_del_pro?= =?iso-8859-1?q?tocolo_IP?= In-Reply-To: <200808210542.m7L5gGWN002555@venus.xmundo.net> References: <200808141851.m7EIpLiv006226@venus.xmundo.net> <200808202131.m7KLVbOO006248@venus.xmundo.net> <4fa41cc90808202013s31d6cd55hda4f770c1ef538de@mail.gmail.com> <200808210542.m7L5gGWN002555@venus.xmundo.net> Message-ID: <4fa41cc90808211124o6ca447d0tf94894aec3086995@mail.gmail.com> 2008/8/21 Fernando Gont > Hola, Jorge, > > > Concuerdo con Roque, lo propuesto en la seccion 3.1 solo es valido para 2 > de los ethertypes 0x0800 (IPv4) e 0x86DD (IPv6). > > En el caso de otros ethertypes como 802.3, SPRITE, X.25 Segun el documento > ¿ se deberia descartar el paquete , aun cuando se esta encapsulando > adecuadamente sobre otro tipo de link layer ? > > > mmmm.... no entiendo. > > El planteo es el siguiente: > Si un frame ethernet llega a un host, y su payload se le pasa al modulo de > IPv4, es porque el Ehertype del paquete Ethernet era 0x0800. > Este valor de Ethertype indica que el payload del paquete Ethernet > contiene un paquete IP. > > Si el Ethertype es 0x0800, pero lo que se encapsula es en realidad un > paquete IPv6, esto es una error, ya que en tal caso el Ethertype deberia > haber sido 0X86DD, y *no* 0x0800. > > Del mismo modo, si un modulo IPv6 llegara a "procesar" un paquete IPv4 que > llego en un frame Ethernet, es porque el Ethertype fue 0x86DD, en vez de > 0x0800, que es el que verdaderamente correspondia. Por tal motivo, esta es > una condicion de error. > > Se entiende el argumento? > > Saludos cordiales, y gracias por el feedback! > > -- > 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 > > Hola Fernando, Respondiendome a mi mismo y aclarando mi apreciacion, Supongamos el caso comun de un frame ethernet obviando algunos detalles , el flujo seria (solo consideraremos el procesamiento de entrada del frame) : rutina ether_input() se valida ETHER_HDR_LEN se valida M_PKTHDR Luego se extrae de la cabecera el ether_type etype = ntohs(eh->ether_type); Luego se setean algunos bits flags en caso de ser multicast,etc Al finalizar la rutina se llama a ether_demux() quien setea el isr con los NETISR apropiados para dicha mbuff. case ETHERTYPE_IP isr = NETISR_IP case ETHERTYPE_ARP isr = NETISR_ARP case ETHERTYPE_IPX isr = NETISR_IPX case ETHERTYPE_IPV6 isr = NETISR_IPV6 case ETHERTYPE_ATALK isr = NETISR_ATALK1 Luego con el ISR seteado se despacha al network interruption software routine netisr_dispatch(isr, mbuff) , que distingue 2 casos, cuando es un NETISR_MPSAFE (casos como ipsec) se setea directamente la funcion handler apropiada segun el isr , en caso contrario se envia al schednetisr(num). Para los casos de NETISR_IP y NETISR_IPV6 previamente se registran las rutinas de manejo de entrada. netisr_register(NETISR_IP, ip_input, &ipintrq, NETISR_MPSAFE); netisr_register(NETISR_IPV6, ip6_input, &ip6intrq, 0); En ambos casos la comprobacion es simple tanto en la rutina ip_input como ip6_input : if (ip->ip_v != IPVERSION) { ipstat.ips_badvers++; goto bad; } Lo mismo ocurre para el caso de una if_ppp , en tal caso switch (proto) { #ifdef INET case PPP_IP: /* * IP packet - take off the ppp header and pass it up to IP. */ if ((ifp->if_flags & IFF_UP) == 0 || sc->sc_npmode[NP_IP] != NPMODE_PASS) { /* interface is down - drop the packet. */ m_freem(m); return; } m->m_pkthdr.len -= PPP_HDRLEN; m->m_data += PPP_HDRLEN; m->m_len -= PPP_HDRLEN; if ((m = ip_fastforward(m)) == NULL) return; isr = NETISR_IP; break; Es decir que la rutina de interrupcion seguira siendo la registrada para NETISR_IP En definitiva centrandonos en el caso ethernet , considerando un ethertype 0x0800 esta es manejada por la rutina registrada para NETISR_IP (en stack 4.4BSD es ip_input) valida que el campo ip_v sea correcto, por lo tanto, esa comprobacion extra no es necesaria. -- Jorge Niedbalski R. ----------------------------------------- ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: http://mail.lacnic.net/pipermail/seguridad/attachments/20080821/1d4be728/attachment.htm From fernando en gont.com.ar Thu Aug 21 20:37:41 2008 From: fernando en gont.com.ar (Fernando Gont) Date: Thu, 21 Aug 2008 20:37:41 -0300 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de__seguridad_del_pr?= =?iso-8859-1?q?o_tocolo_IP?= In-Reply-To: <4fa41cc90808211124o6ca447d0tf94894aec3086995@mail.gmail.co m> References: <200808141851.m7EIpLiv006226@venus.xmundo.net> <200808202131.m7KLVbOO006248@venus.xmundo.net> <4fa41cc90808202013s31d6cd55hda4f770c1ef538de@mail.gmail.com> <200808210542.m7L5gGWN002555@venus.xmundo.net> <4fa41cc90808211124o6ca447d0tf94894aec3086995@mail.gmail.com> Message-ID: <200808212345.m7LNjIWf021742@venus.xmundo.net> At 03:24 p.m. 21/08/2008, you wrote: >En definitiva centrandonos en el caso ethernet , considerando un >ethertype 0x0800 esta es manejada por la rutina registrada para >NETISR_IP (en stack 4.4BSD es ip_input) valida que el campo ip_v sea >correcto, por lo tanto, esa comprobacion extra no es necesaria. Sigo sin entender.... Eso es exactamente lo que propone el documento. Cual es el cambio propuesto? Saludos cordiales, -- 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: http://mail.lacnic.net/pipermail/seguridad/attachments/20080821/ee1fe2c7/attachment.htm From niedbalski en ip6nw.com Fri Aug 22 00:43:57 2008 From: niedbalski en ip6nw.com (Jorge M. Niedbalski R.) Date: Thu, 21 Aug 2008 23:43:57 -0400 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de_seguridad_del_pro?= =?iso-8859-1?q?_tocolo_IP?= In-Reply-To: <200808212345.m7LNjIWf021742@venus.xmundo.net> References: <200808141851.m7EIpLiv006226@venus.xmundo.net> <200808202131.m7KLVbOO006248@venus.xmundo.net> <4fa41cc90808202013s31d6cd55hda4f770c1ef538de@mail.gmail.com> <200808210542.m7L5gGWN002555@venus.xmundo.net> <4fa41cc90808211124o6ca447d0tf94894aec3086995@mail.gmail.com> <200808212345.m7LNjIWf021742@venus.xmundo.net> Message-ID: <4fa41cc90808212043s1d51fed7k2e18cf4c5c2154be@mail.gmail.com> El 21 de agosto de 2008 19:37, Fernando Gont escribió: > At 03:24 p.m. 21/08/2008, you wrote: > > En definitiva centrandonos en el caso ethernet , considerando un ethertype > 0x0800 esta es manejada por la rutina registrada para NETISR_IP (en stack > 4.4BSD es ip_input) valida que el campo ip_v sea correcto, por lo tanto, esa > comprobacion extra no es necesaria. > > > Sigo sin entender.... > > Eso es exactamente lo que propone el documento. > > Cual es el cambio propuesto? > > Saludos cordiales, > > -- > 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 > > Fernando , No te propongo cambios respecto a ese punto, simplemente me estaba auto-respondiendo a la primera afirmacion que realice ya que habia comprehendido que en el documento estabas sugiriendo una validacion extra. Favor tomalo como una nota mental personal de multidifusion. Saludos, -- Jorge Niedbalski R. ----------------------------------------- ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: http://mail.lacnic.net/pipermail/seguridad/attachments/20080821/b107e5d6/attachment.htm From fernando en gont.com.ar Fri Aug 22 01:22:16 2008 From: fernando en gont.com.ar (Fernando Gont) Date: Fri, 22 Aug 2008 01:22:16 -0300 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de__seguridad_del_pr?= =?iso-8859-1?q?o_tocolo_IP?= In-Reply-To: <4fa41cc90808212043s1d51fed7k2e18cf4c5c2154be@mail.gmail.co m> References: <200808141851.m7EIpLiv006226@venus.xmundo.net> <200808202131.m7KLVbOO006248@venus.xmundo.net> <4fa41cc90808202013s31d6cd55hda4f770c1ef538de@mail.gmail.com> <200808210542.m7L5gGWN002555@venus.xmundo.net> <4fa41cc90808211124o6ca447d0tf94894aec3086995@mail.gmail.com> <200808212345.m7LNjIWf021742@venus.xmundo.net> <4fa41cc90808212043s1d51fed7k2e18cf4c5c2154be@mail.gmail.com> Message-ID: <200808220430.m7M4UFoI014521@venus.xmundo.net> At 12:43 a.m. 22/08/2008, you wrote: >No te propongo cambios respecto a ese punto, >simplemente me estaba auto-respondiendo a la >primera afirmacion que realice ya que habia >comprehendido que en el documento estabas sugiriendo una validacion extra. > >Favor tomalo como una nota mental personal de multidifusion. Si, está bárbaro. No me lo tomé a mal, ni nada de eso... Simplemente pensé en que seguía sin darme cuenta de algo... entonces pensé que estabas proponiendo un cambio, pero por no entender cual era, no lo podia aplicar. Es más, es bueno tener este tipo de "discusión". Y las referencias al código fueron impecables.... ;-) P.S.: Lo que mas quiero es justamente que el documento se evalue lo mas posible, y al mayor nivel de detalle posible. Eso es lo que va a permitir que mejore, y que sea mas util a la comunidad.... Saludos, y gracias! -- 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: http://mail.lacnic.net/pipermail/seguridad/attachments/20080822/ce9ae7e4/attachment-0001.htm From roque en lacnic.net Fri Aug 22 09:43:18 2008 From: roque en lacnic.net (Roque Gagliano) Date: Fri, 22 Aug 2008 09:43:18 -0300 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de_seguridad_del_pro?= =?iso-8859-1?q?tocolo_IP?= In-Reply-To: <4fa41cc90808211124o6ca447d0tf94894aec3086995@mail.gmail.com> References: <200808141851.m7EIpLiv006226@venus.xmundo.net> <200808202131.m7KLVbOO006248@venus.xmundo.net> <4fa41cc90808202013s31d6cd55hda4f770c1ef538de@mail.gmail.com> <200808210542.m7L5gGWN002555@venus.xmundo.net> <4fa41cc90808211124o6ca447d0tf94894aec3086995@mail.gmail.com> Message-ID: > ` > En definitiva centrandonos en el caso ethernet , considerando un > ethertype 0x0800 esta es manejada por la rutina registrada para > NETISR_IP (en stack 4.4BSD es ip_input) valida que el campo ip_v sea > correcto, por lo tanto, esa comprobacion extra no es necesaria. jorge, muchas gracias por la detallada información, se ve que tienes mucha más experiencia a bajo nivel que yo. Ahora, mi punto era otro. Mi punto es, tenemos claro que en todas las implementaciones de protocolo de capa de enlace ya se multiplexan los paquetes IPv4 vs IPv6 por el tipo de protocolo? yo solo tengo experiencia en Ethernet y PPP que en ambos casos la respuesta es si. slds r. > > > > -- > Jorge Niedbalski R. > ----------------------------------------- > > _______________________________________________ > 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: http://mail.lacnic.net/pipermail/seguridad/attachments/20080822/ca2be78b/attachment.htm ------------ próxima parte ------------ Se ha borrado un mensaje que no está en formato texto plano... Nombre : PGP.sig Tipo : application/pgp-signature Tamaño : 194 bytes Descripción: This is a digitally signed message part Url : http://mail.lacnic.net/pipermail/seguridad/attachments/20080822/ca2be78b/attachment.pgp From niedbalski en ip6nw.com Fri Aug 22 13:48:39 2008 From: niedbalski en ip6nw.com (Jorge M. Niedbalski R.) Date: Fri, 22 Aug 2008 12:48:39 -0400 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de_seguridad_del_pro?= =?iso-8859-1?q?tocolo_IP?= In-Reply-To: References: <200808141851.m7EIpLiv006226@venus.xmundo.net> <200808202131.m7KLVbOO006248@venus.xmundo.net> <4fa41cc90808202013s31d6cd55hda4f770c1ef538de@mail.gmail.com> <200808210542.m7L5gGWN002555@venus.xmundo.net> <4fa41cc90808211124o6ca447d0tf94894aec3086995@mail.gmail.com> Message-ID: <4fa41cc90808220948y70ad2432h5109aae4f522656b@mail.gmail.com> 2008/8/22 Roque Gagliano > ` > En definitiva centrandonos en el caso ethernet , considerando un ethertype > 0x0800 esta es manejada por la rutina registrada para NETISR_IP (en stack > 4.4BSD es ip_input) valida que el campo ip_v sea correcto, por lo tanto, esa > comprobacion extra no es necesaria. > > > jorge, > > muchas gracias por la detallada información, se ve que tienes mucha más > experiencia a bajo nivel que yo. > > Ahora, mi punto era otro. Mi punto es, tenemos claro que en todas las > implementaciones de protocolo de capa de enlace ya se multiplexan los > paquetes IPv4 vs IPv6 por el tipo de protocolo? yo solo tengo experiencia en > Ethernet y PPP que en ambos casos la respuesta es si. > > slds > r. > > > > > > -- > Jorge Niedbalski R. > ----------------------------------------- > > _______________________________________________ > Seguridad mailing list > Seguridad en lacnic.net > https://mail.lacnic.net/mailman/listinfo/seguridad > > > > _______________________________________________ > Seguridad mailing list > Seguridad en lacnic.net > https://mail.lacnic.net/mailman/listinfo/seguridad > > Estimado Roque, Como indique en el correo anterior en ambos casos ethernet y ppp como protocolos de nivel 2 la desmultiplexacion sigue el mismo flujo. El caso de ATM los isr son exactamente los mismos por tanto la rutina sera exactamente la misma que maneje la capa de layer 3 para ambos protocolos ipv4 e ipv6. Para todos los protocolos con el apellido oE (over Ethernet) la logica debiese ser la misma. Para los casos como trunk_input, vlan_input, bridge_input, carp_input, son manejados directamente en ether_input y es netamente transparente el posterior procesamiento. Saludos, -- Jorge Niedbalski R. ----------------------------------------- ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: http://mail.lacnic.net/pipermail/seguridad/attachments/20080822/5a79b410/attachment.htm From niedbalski en ip6nw.com Fri Aug 22 13:51:07 2008 From: niedbalski en ip6nw.com (Jorge M. Niedbalski R.) Date: Fri, 22 Aug 2008 12:51:07 -0400 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de_seguridad_del_pro?= =?iso-8859-1?q?_tocolo_IP?= In-Reply-To: <200808220430.m7M4UFoI014521@venus.xmundo.net> References: <200808141851.m7EIpLiv006226@venus.xmundo.net> <200808202131.m7KLVbOO006248@venus.xmundo.net> <4fa41cc90808202013s31d6cd55hda4f770c1ef538de@mail.gmail.com> <200808210542.m7L5gGWN002555@venus.xmundo.net> <4fa41cc90808211124o6ca447d0tf94894aec3086995@mail.gmail.com> <200808212345.m7LNjIWf021742@venus.xmundo.net> <4fa41cc90808212043s1d51fed7k2e18cf4c5c2154be@mail.gmail.com> <200808220430.m7M4UFoI014521@venus.xmundo.net> Message-ID: <4fa41cc90808220951p29aeb7fejd72823d907e81257@mail.gmail.com> El 22 de agosto de 2008 0:22, Fernando Gont escribió: > At 12:43 a.m. 22/08/2008, you wrote: > > No te propongo cambios respecto a ese punto, simplemente me estaba > auto-respondiendo a la primera afirmacion que realice ya que habia > comprehendido que en el documento estabas sugiriendo una validacion extra. > > Favor tomalo como una nota mental personal de multidifusion. > > > Si, está bárbaro. No me lo tomé a mal, ni nada de eso... Simplemente pensé > en que seguía sin darme cuenta de algo... entonces pensé que estabas > proponiendo un cambio, pero por no entender cual era, no lo podia aplicar. > > Es más, es bueno tener este tipo de "discusión". Y las referencias al > código fueron impecables.... ;-) > > P.S.: Lo que mas quiero es justamente que el documento se evalue lo mas > posible, y al mayor nivel de detalle posible. Eso es lo que va a permitir > que mejore, y que sea mas util a la comunidad.... > > Saludos, y gracias! > > -- > 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 > > Estimado Fernando : Estoy leyendolo con calma tu documento por que esta muy interesante y me sirve bastante para continuar mi aprendizaje. Si encuentro alguna acotacion de importancia te la hare llegar. PS: Te envie un mail personal con una duda, revisa tu casilla!. -- Jorge Niedbalski R. ----------------------------------------- ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: http://mail.lacnic.net/pipermail/seguridad/attachments/20080822/72df1639/attachment.htm From fernando en gont.com.ar Mon Aug 25 07:58:00 2008 From: fernando en gont.com.ar (Fernando Gont) Date: Mon, 25 Aug 2008 07:58:00 -0300 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de__seguridad_del_pr?= =?iso-8859-1?q?otocolo_IP?= In-Reply-To: References: <200808141851.m7EIpLiv006226@venus.xmundo.net> <200808202131.m7KLVbOO006248@venus.xmundo.net> <4fa41cc90808202013s31d6cd55hda4f770c1ef538de@mail.gmail.com> <200808210542.m7L5gGWN002555@venus.xmundo.net> <4fa41cc90808211124o6ca447d0tf94894aec3086995@mail.gmail.com> Message-ID: <200808251105.m7PB5tgc029842@venus.xmundo.net> At 09:43 a.m. 22/08/2008, Roque Gagliano wrote: >Ahora, mi punto era otro. Mi punto es, tenemos claro que en todas >las implementaciones de protocolo de capa de enlace ya se >multiplexan los paquetes IPv4 vs IPv6 por el tipo de protocolo? yo >solo tengo experiencia en Ethernet y PPP que en ambos casos la respuesta es si. Al menos todos los que yo he chequeado, si. Puesto de otro modo, al menos el codigo de los BSD y de Linux no contiene un unico modulo IP que demultiplexe de acuerdo al campo "version".... En lineas generales, salvo que tu link-layer soporte un unico protocolo, siempre vas a tener un campo "Protocol Type". Y dado que al fin y al cabo lo que es IPv4 se termina procesando por un modulo de codigo distinto al que procesa por ej IPv6 (ya que la sintaxis del protocolo cambia completamente), en la practica no tiene sentido demultiplexar por "version". Saludos, -- 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: http://mail.lacnic.net/pipermail/seguridad/attachments/20080825/d65fa74b/attachment.htm From fernando en gont.com.ar Mon Aug 25 08:11:51 2008 From: fernando en gont.com.ar (Fernando Gont) Date: Mon, 25 Aug 2008 08:11:51 -0300 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?An=E1lisis_de__seguridad_del_pr?= =?iso-8859-1?q?o_tocolo_IP?= In-Reply-To: <34FD7F90-1896-4CB8-8199-D120BD5CFAA3@lacnic.net> References: <200808141851.m7EIpLiv006226@venus.xmundo.net> <34FD7F90-1896-4CB8-8199-D120BD5CFAA3@lacnic.net> Message-ID: <200808251115.m7PBFs4a004351@venus.xmundo.net> At 04:00 p.m. 20/08/2008, Roque Gagliano wrote: >cuando dicen que no puede haber protocolos >orientados a conexion sobre multicast, >estudiaron los protocolos como los que se listan >aqui: >http://tldp.org/HOWTO/Multicast-HOWTO-9.html#sect-trans-prots >??? Estrictamente hablando, no. De cualquier modo, algunos comentarios: * Por lo que he visto sobre protocolos "confiables" ("reliable") sobre multicast, los mismos no son basados en conexion (en el sentido estricto de la palabra), sino que mas bien solo el cliente mantiene sierta sincronización, y envía algún tipo de NAK cuando detecta que hubo algún paquete se perdió. Pensando un poco en voz alta, se me ocurre que mantener "estado" del lado del servidor afectaría muy negativamente las propiedades de "scaling" del protocolo en cuestión. * Se me ocurre que uno podría salir (vergonzosamente :-) )"bien parado" de esta cuestión argumentando que dla cuestión de protocolos confiables sobre multicast está mas bien en estado de investigación... y que ninguno todavía ha sido estandarizado al menos por la IETF. * De cualquier modo, entiendo que tal vez se podría retocar un poco el documento, y cambiarlo de modo que mas bien diga algo asi como que "no se deben pasar paquetes al protocolo de transporte, si se sabe que dicho protocolo no puede trabajar con multiples end-points al mismo tiempo". Qué te parece? Saludos, y gracias! -- 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 ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: http://mail.lacnic.net/pipermail/seguridad/attachments/20080825/d87ad81f/attachment.htm From fernando en gont.com.ar Mon Aug 25 08:25:39 2008 From: fernando en gont.com.ar (Fernando Gont) Date: Mon, 25 Aug 2008 08:25:39 -0300 Subject: [LACNIC/Seguridad] DNS cache poisoning In-Reply-To: <4fa41cc90807141021s2a7aea53k5b0ef37652d177bc@mail.gmail.co m> References: <200807110424.m6B4OSkx006147@venus.xmundo.net> <200807140002.m6E02RR9025150@venus.xmundo.net> <4fa41cc90807141021s2a7aea53k5b0ef37652d177bc@mail.gmail.com> Message-ID: <200808251129.m7PBTgmQ011760@venus.xmundo.net> At 02:21 p.m. 14/07/2008, you wrote: >Estimado Fernando : > >En definitiva 2^32 sigue siendo insuficiente , >¿Cual es tu propuesta al respecto? En lineas generales, yo soy de la idea de atacar el problema por muchos lados. Lo que propone como solución al problema es DNSSEC, que consiste básicamente en firmar la información del DNS. Y como suele suceder con este tipo de soluciones, tampoco son perfectas... al menos no en la práctica. (por ej., mirá los comentarios de DJB en su sitio). 2^32 no es suficiente. Pero, en muchos escenarios, hace que la cosa sea un poco menos terrible de lo que puede llegar a ser. Fijate que, salvando las distancias ha sucedido algo parecido en estos últimos años en lo que respecta a TCP: durante los últimos años se "encontraron" una variedad de vectores para realizar ataques ciegos. La "solución definitiva" (si es que existe tal cosa) podría ser agregar autentificación como por ejemplo mediante la TCP-AO que está produciendo la IETF en este momento (una opcion TCP MD5 mejorada, por asi decirlo). Sin embargo, implementando las soluciones especificas a los vectores encontrados, y algunas generales (como "port randomization"), básicamente llevás la vulnerabilidad a ataques *ciegos* a niveles aceptables. Al menos en los casos generales, y por ahora.... :-) Saludos, -- 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 From fernando en gont.com.ar Sun Aug 31 10:29:14 2008 From: fernando en gont.com.ar (Fernando Gont) Date: Sun, 31 Aug 2008 10:29:14 -0300 Subject: [LACNIC/Seguridad] =?iso-8859-1?q?Nueva_revisi=F3n_de_nuestro_IET?= =?iso-8859-1?q?F_I-D_sobre__Port_Randomization?= Message-ID: <200808311333.m7VDXL2h008311@venus.xmundo.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hola a todos, Acabamos de publicar una revisión de nuestro IETF Internet-Draft sobre "Port Randomization". El mismo está disponible en el repositorio de la IETF, y en: http://www.gont.com.ar/drafts/port-randomization/draft-ietf-tsvwg-port-rand omization-02.txt (asimismo, pueden encontrar el mismo documento en formato HTML y PDF en: http://www.gont.com.ar/drafts/port-randomization/index.html) Esta nueva revisión intenta responder a los comentarios que recibimos de Amit Klein, Matthias Bethke, y Alfred Hoenes. El "Abstract" del documento es: - ---- cut here ---- Recently, 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 random 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, the described port number randomization algorithms provide improved security/obfuscation 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, SCTP, DCCP, and RTP. - ---- cut here ---- Cualquier comentario será bienvenido. Gracias! Saludos cordiales, - -- 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 -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) - not licensed for commercial use: www.pgp.com wsBVAwUBSLqcZpbuqe/Qdv/xAQhgZggAx4fdrVBMgX8OKOK60RC7mytaI0YUIloU jTf7GzyXNI7+mgYIiySRScHyXB0FtipsnYQ9Whw+yoJPQH2VCFtHMbkNR9IzlAGF Qzg763GiKvvaPnyf8MTrf2z+uof6gLBPOxfN5b8TkUuAkJNjDKNaXV7cZRkeZ9Lo WIe36EAHa94cj587qn6z34yLeQ87WmytQfFPhmlQWO5Zzkoi1HwlK25HALixY8Uq NYgw8vobeZzAg3qDLJna8sBSRnqEhj7cRwr738gt9Lvlcb19suUyFazmE4UwW8oS Yda7Iy/sHLm7wTcKeqjsXUjk5rCkKtwTbqGB55rw69xq411hgbTPJA== =O2+5 -----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