[LACNIC/Seguridad] El riesgo geopolítico en clave de la Info y Ciber SEC

Jeimy Cano jjcano en yahoo.com
Dom Feb 5 14:23:12 BRST 2017

Estimados profesionales,

Comparto reflexión corta sobre el riesgo geopolítico en clave de la seguridad y la ciberseguridad. Espero sea de su interés.


On Sun, 2/5/17, seguridad-request en lacnic.net <seguridad-request en lacnic.net> wrote:

 Subject: Resumen de Seguridad, Vol 129, Envío 1
 To: seguridad en lacnic.net
 Date: Sunday, February 5, 2017, 9:00 AM
 Envíe los mensajes para la lista
 Seguridad a
     seguridad en lacnic.net
 Para subscribirse o anular su subscripción a través de la
 O por correo electrónico, enviando un mensaje con el texto
 "help" en
 el asunto (subject) o en el cuerpo a:
     seguridad-request en lacnic.net
 Puede contactar con el responsable de la lista escribiendo
     seguridad-owner en lacnic.net
 Si responde a algún contenido de este mensaje, por favor,
 edite la
 linea del asunto (subject) para que el texto sea mas
 especifico que:
 "Re: Contents of Seguridad digest...". Además, por favor,
 incluya en
 la respuesta sólo aquellas partes del mensaje a las que
 Asuntos del día:
    1. Fwd: Re: Last Call:
       (Internet Protocol, Version 6 (IPv6)
 Specification) to Internet
       Standard (Fernando Gont)
 Message: 1
 Date: Sat, 4 Feb 2017 17:14:30 -0300
 From: Fernando Gont <fgont en si6networks.com>
 To: "lactf en lac.ipv6tf.org"
 <lactf en lac.ipv6tf.org>,
 Lista para
     discusión de seguridad en redes y
 sistemas informaticos de la región
     <seguridad en lacnic.net>
 Cc: Latin America and Caribbean Region Network Operators
     <lacnog en lacnic.net>,
 Ivan Arce <ivan.w.arce en gmail.com>
 Subject: [LACNIC/Seguridad] Fwd: Re: Last Call:
 (Internet Protocol, Version 6
     (IPv6) Specification) to Internet
 Message-ID: <64577642-cf1a-9545-c34a-239aff337e1f en si6networks.com>
 Content-Type: text/plain; charset=windows-1252
 No es muy frecuente escuchar a alguien con las agallas para
 llamar las
 cosas por su nombre, y la punteria como para dar en el
 Una buena lectura, para que alguno se de una idea cuanto
 cuestan hacer
 las cosas desde la región, cuando no se tien atrás ningun
 Saludos codiales,
 -------- Forwarded Message --------
 Subject: Re: Last Call:
 <draft-ietf-6man-rfc2460bis-08.txt> (Internet
 Protocol, Version 6 (IPv6) Specification) to Internet
 Date: Sat, 4 Feb 2017 20:06:35 +0100
 From: Enno Rey <erey en ernw.de>
 To: draft-ietf-6man-rfc2460bis en tools.ietf.org,
 ietf en ietf.org,
 6man-chairs en ietf.org
 CC: fgont en si6networks.com,
 otroan en employees.org
 On Sat, Feb 04, 2017 at 09:32:37AM +0100, Fernando Gont
 > Everyone has agreed (including the authors of RFC2460)
 that EH insertion
 > has never been allowed.
 > [...]
 > > Permitting header insertion in the sense of
 specifying how header
 > > insertion could possibly work is of course outside
 the scope of
 > > advancing RFC2460.
 > Explicitly allowing EH insertion would most likely be
 out of scope, too:
 > It completely changes a very basic aspect of IPv6.
 > FWIW, I think that publishing a spec with what some
 have considered to
 > be ambiguous text (subsequently leading to 600+
 messages on the very
 > group that specifies the protocol) would be a lousy job
 on our side.
 > Either explicitly ban extension header insertion, or
 explicitly allow it.
 The first talk I gave about IPv6 was in 1999 (with an
 experimental IPv6
 stack of Windows NT and being connected to the 6Bone). I
 don't remember
 much of it but I'm pretty sure I explained that the desire
 to restore
 the pre-middlebox, pre-NAT end-to-end character of the
 Internet was one
 of the main design drivers of IPv6 (hint: you may also look
 at the
 "Acknowledgments" section of RFC 2460).
 Quite a few IPv6 books of the time (we still have them in
 the library,
 feel free to reach out for examples) explicitly mentioned
 end-to-end as
 a major property of IPv6 and many guys giving IPv6 talks
 & trainings
 since 15+ years now have it on their introductory slides.
 several adjustments of the main IPv6 header (e.g. removing
 the checksum)
 and barring fragmentation performed by intermediate points
 indicate the message: "in general we don't want devices to
 mangle with
 packets in transit".
 So, from my personal perspective, it's painfully obvious
 that there was
 never any intent to allow the modification of IPv6 packets
 in transit
 (besides very specific exceptions which were clearly
 described), and
 this has been an undisputed principle of IPv6 for a long
 So one may be tempted to ask: why do we have this discussion
 at all?
 Well I think the answer is quite simple: as so often in
 life, it's about
 agendas and politics. Before I comment on this in a bit more
 detail, let
 me add two disclaimers:
 Disclaimer (1): in the following rant on how certain things
 happening at the IETF I can only speak for IPv6-related
 Disclaimer (2): addressing such a rant in direct to an IETF
 mailing list
 means I will tap on the feet of many people. Feel free to
 personally let
 me know your strong opinion or just ignore me/stare into
 direction from now on when we meet. There's only a small
 chance this
 will happen at an IETF meeting anyway, for reasons laid out
 Let's look at how the actual discussion (and subsequent
 work is done at the IETF, similar to other voluntary
 organizations: on
 mailing lists and in (f2f) meetings. As we all know, these
 meetings take
 place three times a year, each on a different continent
 (yes, I'm aware
 of remote participation, but let's be honest: at the end of
 the day how
 much impact on specification did this have this in past, in
 in heavily old boys' clubs dominated WGs like 6man?).
 Further fact is: if you look at the lists of participants of
 meetings, the vast majority of it is vendor personnel. This
 is not
 surprising when reflecting on the incentives different
 parties may have
 to send people to IETF meetings. How would, say, an
 enterprise person
 argue in front of her boss to attend the 51st (!) IETF
 meeting since the
 publication of RFC 2460 (especially considerung the ongoing
 of deployment in large parts of that space. it's up to the
 reader to
 connect that state with the things I describe here...)?
 But it's not like vendor people don't have to justify these
 nice trips
 to their bosses. Of course they have to. Here's two
 prevalent strategies:
 - "we have that new feature. let's try to push it into an
 RFC, as this
 strengthens our market position (in general and for selling
 the specific
 - "you know, there's this future thing called IPv6. I'm in
 one of the
 working groups where we come up with lots of creative ideas
 how to even
 make it better. my name is on one of the draft documents so
 I'll have to
 be there, at the next meeting (and we, as a vendor,
 demonstrated our
 contribution also)".
 For quite some of the stakeholders (namely both the vendor
 in question
 and the respective participant[s]) these are not only
 legitimate but
 fully understandable. It's just: does this drive things in
 the right
 direction of the greater good & community? Me seems we
 have a classic
 tragedy of the commons here...
 I'm in the very privileged position that my employer would
 (and did so
 several times in the past) actually pay for week-long trips
 to nice
 cities and expensive hotels (and release me from other
 contributing to short-term productivity, let alone revenue)
 three times
 per year. Still I do know many people *very* unhappy with
 the current
 state of IPv6 specs - and scratching their heads in light of
 the present
 discussion - who are not.
 We/you guys don't have to care about the esteem of IPv6
 community (at
 least the part I myself can speak for) and you might even
 feel obliged
 to ignore it ("we know better what's good for them").
 But we should at least be honest as for the obvious agenda
 quite some
 vendor guys are pushing as for EH insertion (I don't have to
 mention SR,
 do I?) and you Ole, as a 6man chair, have probably noticed
 that there's
 not much support for the idea from anybody outside Cisco
 space (yes, I'm
 aware of the poll. but I followed the mailing list
 discussions as well).
 There you have it. I don't even think that this was anything
 new for
 most of you. Still at times it helps to name the obvious.
 If any socio anthropologist wanted to find a textbook
 example for "how
 voluntary bodies claiming to be open for anyone get
 compromised over
 time by vested interests" the EH insertion thing would be
 For the protocol: given the fundamental role of RFC 2460 I,
 too, think
 that an implementor must be able to get a clear answer to
 the question
 "is EH insertion allowed or not?" during its lecture,
 without going
 through 600+ e-mails in an archive (just to find out that
 "even the
 experts didn't agree on that, at the time"). So I support
 request of > Either explicitly ban extension header
 insertion, or
 explicitly allow it.
 Enno Rey
 ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg -
 Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173
 Handelsregister Mannheim: HRB 337135
 Geschaeftsfuehrer: Enno Rey
 Blog: www.insinuator.net || Conference: www.troopers.de
 Twitter: @Enno_Insinuator
 Subject: Pié de página del digest
 Seguridad mailing list
 Seguridad en lacnic.net
 Fin de Resumen de Seguridad, Vol 129, Envío 1

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