On Feb 28, 2006, at 7:16 PM, David W. Hankins wrote:
On Thu, Feb 09, 2006 at 12:50:08PM -0500, Chuck Swiger wrote:
If you haven't read this:
http://files.stuartcheshire.org/draft-cheshire-ipv4-acd.txt
...it's worth considering the way it standardizes (or proposes to
standardize)
how ARP traffic from unconfigured IPs should be done to avoid
flooding large
networks, or polluting the ARP caches with traffic from
unconfigured hosts.
If we get enough demand for zeroconf, or funding for development, or
contributed patches, we can entertain it. Inarguably, such support
does belong in dhclient since you really only want to entertain
zeroconf when dhcp fails, consistently (and also doesn't supply the
relevant new options in DHCPNAK that tell clients not to entertain
zeroconf).
Doing address conflict detection just to probe the offered address in
DHCP is worthwhile, learning to do ARP also lets us pick up on Bernard
Aboba's DNAv4 draft, which (did I say this already?) I must admit I
have a fondness for, a desire to implement. If a complete lack of
demand from users (so this remains a far, far future).
Perhaps I'll be free to contribute some patches, as I've got code
that handles layer-2 ARP traffic per the recommendations in the link
above. But I don't own the software in question, it was for a
client, so I'll have to see whether I can get permission before I can
redistribute anything....
I think that exhausts your last DHCP related query that might
reasonably
have been a part of this thread. We should probably move the rest of
this off-list, if at all.
I didn't start the thread; and you asked for feedback about the usage
of ISC DHCP under FreeBSD and for suggestions on what you could improve:
"So I also still don't even know what base features would get ISC
back in the running for...I don't know...FreeBSD 7?"
"If anyone would like to work with me to produce a, I
shall term, "working implementation of DHCP" that's well suited to
FreeBSD's needs, I would like to hear your thoughts on needs and
requirements."
If you didn't actually want to be answered, then I apologize for
indulging your rhetorical questions.
[ ... ]
I suspect you may not realize this, so I'll point it out: You are
arguing with ISC's policy, to which as an employee I must adhere,
not me.
I'm not really interested in arguing with either you or ISC's policy,
frankly.
If the policy results in useful, reliable, and secure code,
great...but even two out of three isn't bad. I wish I could count on
ISC's policy to also deliver secure software, but this policy hasn't
done so in the past [1], and you've convinced me that I'd be wasting
my time discussing secure coding practices any further with you.
Later,
--
-Chuck
[1]: http://www.isc.org/index.pl?/sw/bind/bind-security.php
By my count, two-thirds of the bugs listed here (more than ten) were
buffer-overflow or bounds-checking failures; in particular:
Name: "maxdname bug"
Versions affected: 4.9.5, 4.9.5 patchlevel 1, 4.9.6, 4.9.7, 4.9.8,
8.1, 8.1.1, 8.1.2, 8.2, 8.2 patchlevel 1, 8.2.1, 8.2.2, 8.2.2
patchlevel 1
Severity: MINOR
Exploitable: Remotely
Type: Denial of service
Description: The use of sprintf() with data from the network can
result in a buffer overflow condition which may result in unexpected
behavior. Because of the placement of the buffer which might be
overflowed, it is unlikely this bug will result in serious
consequences, however the possibility of a remotely triggered server
crash cannot be ruled out.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
