Wednesday, July 27, 2011

Hacking IPv6 Networks

We have launched a series of in-depth, hands-one trainings about IPv6 security.

The first edition was last June, at the Hack in Paris 2011 conference in Paris, France.

The next edition will be in Sao Paulo, Brazil.

Check out the training's web site!

Tuesday, July 5, 2011

IETF RFC 6274: Security Assessment of the Internet Protocol Version 4

The IETF has published RFC 6274, entitled "Security Assessment of the Internet Protocol Version 4", which is an IETF version of the IPv4 security assessment that had been published by CPNI in 2008. The Abstract of the RFC is:

This document contains a security assessment of the IETF
specifications of the Internet Protocol version 4 and of a number of
mechanisms and policies in use by popular IPv4 implementations.  It
is based on the results of a project carried out by the UK's Centre
for the Protection of National Infrastructure (CPNI).

The RFC is available here.

Requirements for secure IPv6 deployments include better IPv6 tester tools

An article that I've authored for has just been published. It is entitled "Requirements for secure IPv6 deployments include better IPv6 tester tools". The "abstract" of the article is:
This article, which is a part of the mini learning guide, IPv6 tutorial: Understanding IPv6 security issues, threats, defenses, discusses how a number of factors, such as a lack of trained personnel and limited IPv6 support in security devices, may affect the security of IPv6 network deployments. It also explains the potential effects of those factors, and suggests possible ways to mitigate these shortcomings.
The full article is available here.

World IPv6 Day recap ( has published and article entitled "World IPv6 Day recap" which comments on the outcome of the World IPv6 Day.

I have been quoted in that article noting that many people assume that during the World IPv6 Day, everyone accessed Google and Facebook with IPv6. But that's not the case: most users still accessed those sites with IPv4, since they had no IPv6 connectivity and/or their operating systems preferred IPv4 connectivity over the IPv6 connectivity they had available.

The full article is available here.

Wednesday, June 29, 2011

DEEPSEC 2009: Security Assessment of TCP and IPv4

The video of a talk I gave in 2009 (!) at DEEPSEC 2009 about some security assessment of TCP and IPv4 that I had carried out on behalf of CPNI has just been posted by the DEEPSEC folks. The video of the presentation is available here. (Note: the slides are available here, and the technical reports here).

Tuesday, June 28, 2011

Hack In Paris 2011: Hacking IPv6 Networks

Two weeks ago I travelled to Paris to attend the Hack In Paris 2011 conference, where I taught the training "Hacking IPv6 Networks". It was a cool experience, in particular because it was possible to do some real IPv6 hacking with some of the attendees (such as testing a stealth IPv6 scanning technique I had envisioned the night before one of the training sessions, while tweaking my slides).

I have uploaded the slides used for the aforementioned training, which cover (only) the theory contents of the training. The slides are available here.

Thursday, June 9, 2011

Lagging IPv6 security features, vulnerabilities could hamper transition has published an article entitled "Lagging IPv6 security features, vulnerabilities could hamper transition", authored by Robert Westervelt. The article includes some quotes from an interview I had with Robert.

Some of the quotes are not verbatim, and thus might be a bit misleading. When in doubt, check these slides from a presentation about IPv6 security I gave last year at LACNOG 2010.

Wednesday, June 8, 2011

RA-Guard Evasion: New revision of my IETF Internet-Drafts

I have posted a revision of both of my recently-published IETF Internet-Drafts about RA-Guard evasion:

    As always, any comments will be very appreciated.

    Thursday, June 2, 2011

    IPv6 security issues: IPv6 transition mechanisms

    Yet another article that I have authored for The "abstract" of the article is:

    IPv6, the “new” Internet Protocol, is meant to provide enough addresses to enable virtually unlimited Internet growth in the near future. However, since IPv6 is not backwards compatible with IPv4, a variety of transition/co-existence mechanisms have been devised so the introduction of IPv6 in the IPv4-dominant Internet, and the co-existence of both protocols is facilitated.

    In this tip, we’ll briefly introduce these transition/co-existence mechanisms, and explain why they present a variety of compelling security concerns for enterprises.

    You can find the article online here.

    Some talks about IPv6 security

    During the past few weeks I gave several talks about IPv6 security, at different venues. The first venue was LACNIC XV, held in Cancun (Mexico), where I gave a tutorial about IPv6 security, and a presentation about Neighbor Discovery vulnerabilities (the latter in the context of LACSEC 2011).

    They were followed by two presentations in Arequipa (Peru): one about IPv6 security during CONATEL 2011, and one about Neighbor Discovery vulnerabilities during the Cisco Academy Conference 2011.

    Finally, I travelled to London (UK), for a workshop about IPv6 transition organized by CPNI.

    The slides used for these presentations can be found here.

    IPv6 myths: Debunking misconceptions regarding IPv6 security features

    An article I authored for has just been published. The articled is entitled "IPv6 myths: Debunking misconceptions regarding IPv6 security features" and discusses a number of myths that have arisen over the years about IPv6 security.

    The article is available online, here.

    Tuesday, May 31, 2011

    Smartphones and location-tracking (Dilbert strip)

    Reminds me of the iPhone & Andriod issue that made the news a while ago:
    P.S.: No need to mention that I'm a DIlbert fan ;-)

    RA-Guard evasion and related vulnerabilities

    I've just published two new IETF Internet-Drafts, that document the problem of RA-Guard evasion, and propose mitigations.

    They are two Internet-Drafts:
    Any comments on these documents will be more than welcome.

    Wednesday, April 6, 2011

    RFC 6191: Reducing the TIME-WAIT State Using TCP Timestamps

    A new IETF RFC that I have authored has been published. It is RFC 6191, entitled "Reducing the TIME-WAIT State Using TCP Timestamps". The Abstract of the RFC is:
    This document describes an algorithm for processing incoming SYN
    segments that allows higher connection-establishment rates between
    any two TCP endpoints when a TCP Timestamps option is present in the
    incoming SYN segment.  This document only modifies processing of SYN
    segments received for connections in the TIME-WAIT state; processing
    in all other states is unchanged.

    The RFC is available here

    Wednesday, March 23, 2011

    The RSA SecurID Problem

    Steven Bellovin posted an analysis of the widely-publicized RSA SecurID issue. His analysis is available here.

    Biometric controls (Malaysia car thieves steal finger)

    From a BBC article:

    Malaysia car thieves steal finger

    Police in Malaysia are hunting for members of a violent gang who chopped off a car owner's finger to get round the vehicle's hi-tech security system.

    The full article is available here.

    Friday, February 4, 2011

    Friday, January 21, 2011

    Why IPv6 won't rid the Internet of Network Address Translation has published an article entitled "Why IPv6 won't rid the Internet of Network Address Translation" that I have authored for them.

    The article begins with:

    Why IPv6 won't rid the Internet of Network Address Translation

    One of the most common myths about IPv6 (Internet Protocol Version 6) is that it will restore the so-called end-to-end principle of the Internet. This article explains how the current ubiquity of Network Address Translation (NAT) across today's enterprise WANs make this very unlikely.
    The full article can be found here. Enjoy!

    Recommendations for Transport-Protocol Port Randomization (IETF RFC 6056)


    Our document "Recommendations for Transport-Protocol Port Randomization" has just been published as IETF RFC 6056.

    The Abstract of the RFC is:
    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.
    The RFC is available here.

    Wednesday, January 12, 2011

    IPv6 and NATs

    This was posted on the NANOG mailing-list by Jack Bates. Well-said!

    As my corp IT guy put it to me, PAT forces a routing disconnect between internal and external. There is no way to reach the hosts without the firewall performing it's NAT function. Given that the internal is exclusively PAT, the DMZ is public with stateful/proxy, this provides protection for the internal network while limiting the dmz exposure.

    The argument everyone makes is that a stateful firewall defaults to deny. However, a single mistake prior to the deny allows traffic in. The only equivalent in a PAT scenario is to screw up port forwarding which would cause a single host to expose a single port unknowingly per mistake (which said port/host combo may not be vulnerable). In a stateful firewall, a screw up could expose all ports on a host or multiple hosts in a single mistake.

    Then there are the firewall software bugs. In PAT, such bugs don't suddenly expose all your hosts behind the firewall for direct communication from the outside world. In v6 stateful firewall, such a bug could allow circumvention of the entire firewall ruleset and the hosts would be directly addressable from the outside.

    PAT offers the smallest of security safeguards. However, many corp IT personnel feel more secure having that small safeguard in place along with the many other safeguards they deploy. In a corporate environment where they often love to break everything and anything, I don't blame them.

    Then we go to the educational sector, where the admins often prefer as much openness as possible. In their case, they will prefer to do away with PAT.


    Friday, January 7, 2011

    Defending Against Sequence Number Attacks

    We have published an IETF Internet-Draft entitled "Defending Against Sequence Number Attacks", which is a revision of Steven Bellovin's RFC 1948. The Abstract of the I-D is:
    This document specifies an algorithm for the generation of TCP Initial Sequence Numbers (ISNs), such that the chances of an off-path attacker of guessing the sequence numbers in use by a target connection are reduced.  This document is a revision of RFC 1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track. 
    Our I-D is available here.


    Wednesday, January 5, 2011

    IETF RFC 6093: On the Implementation of the TCP Urgent Mechanism

    RFC 6093 (co-authored by Andrew Yourtchenko and me) has just been published by the RFC Editor.It is available at:

    The Abstract of the document is

    This document analyzes how current TCP implementations process TCP urgent indications and how the behavior of some widely deployed middleboxes affects how end systems process urgent indications.  This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications,
    raises awareness about the reliability of TCP urgent indications in the Internet, and recommends against the use of urgent indications (but provides advice to applications that do).

    Tuesday, January 4, 2011

    LACSEC 2011: 6th Network Security Event for Latin America and the Caribbean (Call for Presentations)

                           CALL FOR PRESENTATIONS
                                LACSEC 2011
           6th Network Security Event for Latin America and the Caribbean
                      May 17-20, 2011, Cancun, Mexico
    LACNIC ( is the international organization based
    in (Uruguay) that is responsible for administrating IP address space,
    Reverse Resolution, Autonomous System Numbers and other resources for
    the region of Latin America and the Caribbean on behalf of the Internet community.
    The “6th Network Security Event for Latin America and the Caribbean”
    will be held in Cancun, Mexico, within the framework of LACNIC's
    fifteenth annual meeting (LACNIC XV). This is a public call for
    presentations for that event.
    The topics of interest include, but are not limited to, the following:
    * Honeypots, network monitoring and situational awareness tools in general.
    * Fighting spam, particularly spam from origin (SPF, DKIM and related technologies. Email reputation)
    * Fighting phishing and pharming
    * Fighting malware
    * Internet protocol security
    * IPv6 security
    * DNSsec
    * Security of network infrastructure services (DNS, NTP, etc.)
    * Web security
    * DoS/DDoS response and mitigation, botnets
    * Authentication and access control
    * Security in the cloud
    * Protection of critical infrastructure
    * Security in mobile systems
    * Computer security incident response teams (CSIRTs): creation, management, experiences
    * Security in corporate environments, compliance and auditing, return on security investments
    * Security management (procedures, operational logs, records, etc.)
    * Risk management in Information Security
    * Computer forensics
    * Protection of privacy
    * Legal aspects relating to computer security
    Guidelines for Presenting Proposals
    Proposals for the “6th Network Security Event for Latin America and the Caribbean” (LACSEC 2011) must be presented taking into account the following considerations:
    * The presentation may or may not have one or more accompanying
    articles, but the Evaluation Committee may give priority to those that do.
    * Proposals may be presented in English, Portuguese or Spanish.
    * Proposals must be submitted in Portable Document Format (PDF)
    * Submissions must be created directly using a word processing system
    (scanned articles will not be accepted)
    * Presentations may not be longer than 30 minutes.
    Submitting a Proposal
    Those interested in presenting at LACSEC 2011 must send the following
    information to <> within the deadlines set
    forth below:
    * Full title of the presentation
    * Extended abstract and a draft of the slides or the full article if available. The extended abstract should not be longer than one thousand (1000) words. The Evaluation Committee may, at its sole discretion, request additional or complementary information.
    * Full name, email address and organization with which the author (or
    authors) of the submission is affiliated
    For more information, please don't hesitate to contact the Evaluation
    Committee at
    Proposal Evaluation
    The Evaluation Committee that has been created for this purpose will
    evaluate proposals based on the following basic criteria:
    * Originality
    * Technical quality
    * Relevance
    * Presentation
    * Applicability
    * Deadline for proposal reception: March 4th, 2011
    * Notification of acceptance: March 14th, 2011
    * Deadline for submitting the final version the presentation: May 9th, 2011
    “6th Network Security Event for Latin America and the Caribbean” (LACSEC 2011)
      Fernando Gont (UTN/FRH, Argentina)
    Evaluation Committee
      Eduardo Carozo (Amparo Project, Uruguay)
      Lorena Ferreyro (Independent consultant, Argentina)
      Javier Liendo (Cisco, Mexico)
      Fernando Maresca (ONTI, Argentina)
      Carlos Martinez Cagnazzo (LACNIC, Uruguay)
      Domingo Montanaro (iSight Partners, Brazil)
      Jose Miguel Parrella Romero (Debian developer, Ecuador)
      Patricia Prandini (ADACSI, Argentina)
      Juliano Rizzo (Netifera, Argentina)
      Javier Romero (JaCkSecurity, Peru)
      Arturo Servin (LACNIC, Uruguay)
      Liliana V. Solha (CAIS/RNP, Brazil)
      Lisandro Teszkiewicz (Independent consultant, Argentina)
      Leonardo Vidal (ISOC Uruguay Chapter, Uruguay)