Recommendations for Transport-Protocol Port Randomization
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org> Subject: Protocol Action: 'Transport Protocol Port Randomization Recommendations' to BCP The IESG has approved the following document: - 'Transport Protocol Port Randomization Recommendations' <draft-ietf-tsvwg-port-randomization-09.txt> as a BCP This document is the product of the Transport Area Working Group. The IESG contact person is Lars Eggert. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-randomization/
Technical Summary Recently, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. 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 described port number obfuscation algorithms provide improved security/obfuscation with very little effort and without any key management overhead. Working Group Summary Understanding that 'strong' consensus is nearly impossible in an open area WG such as TSVWG, with 5-6 sub-groups within this WG divided along technology focuses -- there is unwavering consensus in the WG amongst interested parties to publish this document. It has been reviewed by several people in the WG last call. Comments raised have been addressed. Document Quality Several stacks implement different port randomization techniques. The techniques that this document describes include the ones implemented by FreeBSD, Linux, NetBSD, OpenBSD and OpenSolaris. Personnel James Polk (email@example.com) is the document Shepherd. Lars Eggert (firstname.lastname@example.org) is the responsible Area Director.