Source port randomisation on NetBSD?

[stephane+ (Stephane Bortzmeyer)]

Hello (and please copy me when replying, I'm not a subscriber of this
mailing list.)

The Internet-Draft "Transport Protocol Port Randomization
Recommendations" will be published as a RFC in a few days. Its current
state is AUTH48, last reading before publication,
<http://www.rfc-editor.org/queue.html#draft-ietf-tsvwg-port-randomization>.

It discusses at length the implementation of port randomization for
all the free Unices and NetBSD is mentioned as the only one without
this feature (Linux, FreeBSD, OpenBSD and OpenSolaris all have
it). Why is it so? Why not using the FreeBSD code?

[Christos Zoulas]

-=-=-=-=-=-
Hello (and please copy me when replying, I'm not a subscriber of this
mailing list.)
The Internet-Draft "Transport Protocol Port Randomization
Recommendations" will be published as a RFC in a few days. Its current
state is AUTH48, last reading before publication,
<http://www.rfc-editor.org/queue.html#draft-ietf-tsvwg-port-randomization>.
It discusses at length the implementation of port randomization for
all the free Unices and NetBSD is mentioned as the only one without
this feature (Linux, FreeBSD, OpenBSD and OpenSolaris all have
it). Why is it so? Why not using the FreeBSD code?

No particular reason. It is just that nobody implemented it so far.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

The draft is (maybe intentionally?) vague on the issues - what evil real life
attacks is this "protecting" from?

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Martin Husemann
The draft is (maybe intentionally?) vague on the issues - what evil real life
attacks is this "protecting" from?

It's protecting stupid protocols like DNS that are only secured by 16bit
entropy in the UDP case.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jeremy C. Reed]

Post by Christos Zoulas
No particular reason. It is just that nobody implemented it so far.

I implemented it over two years ago and sent the small patches to
tech-net (July 2008). I can toggle it with a sysctl tunable. I was told
others were going to implement it differently. I asked core about it in
October 2008 too.



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Geert Hendrickx]

Post by stephane+ (Stephane Bortzmeyer)
Hello (and please copy me when replying, I'm not a subscriber of this
mailing list.)
The Internet-Draft "Transport Protocol Port Randomization
Recommendations" will be published as a RFC in a few days. Its current
state is AUTH48, last reading before publication,
<http://www.rfc-editor.org/queue.html#draft-ietf-tsvwg-port-randomization>.
It discusses at length the implementation of port randomization for all
the free Unices and NetBSD is mentioned as the only one without this
feature (Linux, FreeBSD, OpenBSD and OpenSolaris all have it). Why is it
so? Why not using the FreeBSD code?

ipfilter/ipnat can do source port randomisation on NetBSD (since the
Kaminsky DNS issue).


Geert

[stephane+ (Stephane Bortzmeyer)]

On Sun, Oct 24, 2010 at 07:28:30PM +0200,

Post by Geert Hendrickx
ipfilter/ipnat can do source port randomisation on NetBSD (since the
Kaminsky DNS issue).

I must confess it is a bit terse to me. Does it mean that you need to
enable the firewall on the NetBSD machine, and scramble packets which
were generated with a predictable port number? It seems odd. (Unless
you refer only to NetBSD-as-a-router, while I was talking about
NetBSD-as-a-host.)

Also, ipnat(8) and ipnat(5), on a 5.0.1 machine, do not seem to
explain about how to do it (and Google was not my friend here).

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[John Nemeth]

On Mar 16, 3:30pm, Stephane Bortzmeyer wrote:
} On Sun, Oct 24, 2010 at 07:28:30PM +0200,
} Geert Hendrickx <***@telenet.be> wrote
} a message of 25 lines which said:
}
} > ipfilter/ipnat can do source port randomisation on NetBSD (since the
} > Kaminsky DNS issue).
}
} I must confess it is a bit terse to me. Does it mean that you need to
} enable the firewall on the NetBSD machine, and scramble packets which
} were generated with a predictable port number? It seems odd. (Unless
} you refer only to NetBSD-as-a-router, while I was talking about
} NetBSD-as-a-host.)

This would be more NetBSD-as-a-router.

} Also, ipnat(8) and ipnat(5), on a 5.0.1 machine, do not seem to
} explain about how to do it (and Google was not my friend here).

If you're using ipnat, you don't need to do anything. It's
automatic on NetBSD 4.0.1 or later.

NOTE: I believe that all reasonably recent versions of named
automatically use port randomisation. Beyond this, I don't know what
real world benefits port randomisation brings, if any, for the vast
majority of hosts. ipnat was changed to do port randomisation because
otherwise it would have turned named queries into sequential ports when
named was behind NetBSD-as-a-router.

}-- End of excerpt from Stephane Bortzmeyer

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[stephane+ (Stephane Bortzmeyer)]

On Sun, Oct 24, 2010 at 02:52:43PM -0700,

Post by John Nemeth
This would be more NetBSD-as-a-router.

OK. So there is indeed no solution for NetBSD-as-a-host.

Post by John Nemeth
NOTE: I believe that all reasonably recent versions of named
automatically use port randomisation.

They do but my main concern was not about the DNS but about TCP-based
services (SSH, BGP, etc).

Post by John Nemeth
Beyond this, I don't know what real world benefits port
randomisation brings, if any, for the vast majority of hosts.

I refer you to the soon-to-be-RFC
<ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tsvwg-port-randomization-09.txt>. I
copy here the survey of all free Unices:


Appendix A. Survey of the algorithms in use by some popular
implementations

A.1. FreeBSD

FreeBSD 8.0 implements Algorithm 1, and in response to this document
now uses a 'min_port' of 10000 and a 'max_port' of 65535. [FreeBSD]

A.2. Linux

Linux 2.6.15-53-386 implements Algorithm 3, with MD5 as the hash
algorithm. If the algorithm is faced with the corner-case scenario
described in Section 3.5, Algorithm 1 is used instead [Linux].

A.3. NetBSD

NetBSD 5.0.1 does not obfuscate its ephemeral port numbers. It
selects ephemeral port numbers from the range 49152-65535, starting
from port 65535, and decreasing the port number for each ephemeral
port number selected [NetBSD].

A.4. OpenBSD

OpenBSD 4.2 implements Algorithm 1, with a 'min_port' of 1024 and a
'max_port' of 49151. [OpenBSD]

A.5. OpenSolaris

OpenSolaris 2009.06 implements Algorithm 1, with a 'min_port' of
32768 and a 'max_port' of 65535. [OpenSolaris]


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by stephane+ (Stephane Bortzmeyer)
They do but my main concern was not about the DNS but about TCP-based
services (SSH, BGP, etc).

So, what is the threat here?

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Geert Hendrickx]

Post by stephane+ (Stephane Bortzmeyer)
On Sun, Oct 24, 2010 at 02:52:43PM -0700,

Post by John Nemeth
This would be more NetBSD-as-a-router.

OK. So there is indeed no solution for NetBSD-as-a-host.

You can use ipnat on an individual host as well (implementing "PAT", or
Port Address Translation, rather than NAT).


Geert

[stephane+ (Stephane Bortzmeyer)]

On Mon, Oct 25, 2010 at 01:50:17PM +0200,

Post by Martin Husemann
So, what is the threat here?

[Third time I post the link, to a document which explains much better
than what I would do.]

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-tsvwg-port-randomization-09.txt

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[stephane+ (Stephane Bortzmeyer)]

On Mon, Oct 25, 2010 at 01:55:27PM +0200,

Post by Geert Hendrickx
You can use ipnat on an individual host as well (implementing "PAT",
or Port Address Translation, rather than NAT).

As a way of obfuscating the source port number, it seems a very
baroque technique.

Certainly, choosing the source port number should be done by
the kernel, not by a third-party.



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by stephane+ (Stephane Bortzmeyer)
On Mon, Oct 25, 2010 at 01:50:17PM +0200,

Post by Martin Husemann
So, what is the threat here?

[Third time I post the link, to a document which explains much better
than what I would do.]

Has it occurred to you that other people participating in this thread
may have read the document you linked to and still not understand what
credible threat actually exists?

The document appears to be long on implementation results and short on
convincing rationale. Not good. One wonders what the IESG are up to
these days.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by stephane+ (Stephane Bortzmeyer)
On Mon, Oct 25, 2010 at 01:55:27PM +0200,

Post by Geert Hendrickx
You can use ipnat on an individual host as well (implementing "PAT",
or Port Address Translation, rather than NAT).

As a way of obfuscating the source port number, it seems a very
baroque technique.

It doesn't strike me as tremendously elegant, but neither does this
botch of a standards document.

Post by stephane+ (Stephane Bortzmeyer)
Certainly, choosing the source port number should be done by
the kernel, not by a third-party.

Where did you get the idea that ipf was not in the kernel?

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[stephane+ (Stephane Bortzmeyer)]

On Mon, Oct 25, 2010 at 08:08:27AM -0400,

Post by Thor Lancelot Simon
The document appears to be long on implementation results and short
on convincing rationale.

Ah, OK, here is the original alert, longer on the rationale side:

http://www.gont.com.ar/tools/icmp-attacks/bugtraq-icmp-reset.txt

And the other RFC on the subject:

RFC 4953 (see specially section 2.3 and 2.4)
RFC 5927 (see specially section 5.1)
RFC 5961 (see specially section 1.3)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Laight]

Talking of randomising values in the IP stack, isn't it time we fixed
the borked randomness added elsewhere that try to use a^b mod c without
verifying that a and b are even coprime.
I can't remember where this code is actually used, I just remember
fixing it at a simpler level without verifying that the underlying
maths was even approximately right!

David