Port Randomization

1. Port Randomization Michael Larsen Fernando Gont Presented by Lars Eggert

2. Blind attacks against transport protocols • The IETF has been working on a number of mitigation techniques for blind attacks against transport protocols. E.g., • draft-ietf-tcpm-tcp-secure • draft-ietf-tcpm-icmp-attacks • All these attacks rely on the attacker’s ability to guess or know the four-tuple that identifies the transport-protocol instance to be attacked.

3. Port randomization • Mitigates “blind” attacks against transport protocols by obfuscating the four-tuple that identifies the target transport-protocol instance. • It’s a general & proactive mitigation technique: it increases the difficulty of performing any blind attack against a transport-protocol instance, even if the vulnerability is not yet known. • It can be implemented for all of our transport protocols (TCP, UDP, DCCP, SCTP, etc.) • Already implemented (for TCP & UDP) in a variety of operating systems (at least Linux, OpenBSD, and FreeBSD).

4. Requirements for a good port randomization algorithm • Minimize the predictability of the ephemeral port numbers used for future connections. (i.e., make it hard for an outsider to guess which port numbers will be used for future connections). • Maximize the port reuse cycle. (i.e. avoid port number “collisions”). • Avoid conflict with applications that depend on the use of specific port numbers. (i.e., don’t use for ephemeral ports those port numbers that may be needed by some applications)

5. Advice is needed on port randomization • Some implementations have bothered to implement attack-specific mitigations, yet they have not implemented the most obvious/general one: port randomization. • Different implementations use different (and too small!) ranges for ephemeral ports (e.g., 1024-4999). • Some port randomization approaches (together with small port number ranges) increase the chances of port number collisions, leading to interoperability problems (as reported on OpenBSD’s and FreeBSD’s mailing-lists). FreeBSD ended up including a hack to disable port randomization when the rate of outgoing connections is higher than some specified value

6. draft-larsen-tsvwg-port-randomization • Describes a number of port randomiztion approaches, some of which have already been implemented by popular operating systems. • Discusses potential problems that may arise as a result of some port randomization approaches. • Aims at encouraging implementation of port randomization in all of our transport protocols. • Has received a number of reviews, and some support to be adopted as a tsvwg document.

7. Pending changes • Include some randomization algorithms not yet present in the draft(as suggested by Mark Allman and Lars Eggert). • Include data about port number collisions (i.e. how often do port number collisions occur in practice?) (as suggested by Mark Allman) – there’s ongoing work on this one. • Do not encourage any specific randomization algorithm (as suggested by Mark Allman) – this one probably depends on the previous bullet. • Minor tweaks to include RTP as one of the protocols that would benefit from port randomization (as suggested by Dan Wing). • A number of miscellaneous changes (as suggested by Alfred Hoenes).

8. Moving forward • Should this document be adopted as a tsvwg item?