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)