Subject: Re: random ip_id must be configurable
To: None <firstname.lastname@example.org>
From: Darren Reed <email@example.com>
Date: 09/12/2003 02:36:49
> predictable IP fragment ID allows malicious parties to inject bogus
> fragment to your traffic, prohibiting your peer from reassembling your
> fragments. it is a very common knowledge that predictable IP fragment
> ID is a bad thing. nessus (http://www.nessus.org/) raises warning
> if your system uses predictable ip_id field. for instance, see this
> thread (on freebsd):
Let me quote the summary from this page:
Solution : Contact your vendor for a patch
Risk factor : Low
Now besides being "risk factor: low", this is security through obscurity
and as anyone who is serious about security will tell you, if you need to
rely on obscurity for you security then you don't have real security.
On top of that, for a *busy* machine, say cvs.netbsd.org, or www.cnn.com
or something else, even with monotomically increasing IPid field, it's
quite likely to appear "random" to any attacker. These attacks and
measurements that generate warnings are generally done on quiet systems.
Furthermore, if you're concerned about port scanning to the point of
needing to use this to defeat it, you have the wrong security model
in place that allows it to work in the first place. Port scanning
happens, so what. One way or another, an attacker who really wants
to know what you've got open is going to do it whether or not you
make this particular method unavailable and not using any IP address
that will obviously connect them to it.
And as far as someone who I'm working with said about the NAT problem,
"I'd have to be a paranoid schizophreniac to care about this."
Now so far as this particular commit goes, I'd like to see it backed
out until there is consensus about what form it should take. There
was quite a bit of discussion on the topic and that there was no consesus
arrived at should be read as an indication that further discussion is
required rather than ignoring it and comitting anyway. Just because it
is good enough for OpenBSD does not mean it is good enough for NetBSD.
This particular meme has arisen before in discussion and should serve
as a marker that people here are quite likely to have objections about
things and be somewhat upset if discussion is ignored in commit's.
btw, whatever the implementation is, I'd prefer it to be something
like a single function call (in ip_output.c?) that can be used by
other code (ie. inlining would be annoying if the symbol disappears
at link time) - e.g. packets generated by IPFilter should get their
IPid from this "generator" as well.