Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Mar 2006 14:05:48 -0500
From:      Charles Swiger <cswiger@mac.com>
To:        "David W. Hankins" <David_Hankins@isc.org>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: dhclient in 6.0
Message-ID:  <7FBCD272-D73B-4EDC-9DC0-6845C186CE40@mac.com>
In-Reply-To: <20060301001626.GM21419@isc.org>
References:  <d8a4930a0602030429q50f6aa39o@mail.gmail.com> <54176.24.90.33.115.1138971301.squirrel@mail.el.net> <20060203130241.GJ44469@pegasus.dyndns.info> <c7aff4ef0602030524y3a2632d3w@mail.gmail.com> <60155.24.90.33.115.1138981486.squirrel@mail.el.net> <61418.24.90.33.115.1139004207.squirrel@mail.el.net> <20060204005501.GD7613@isc.org> <43E44BAD.50601@mac.com> <20060206225310.GA16149@isc.org> <43EB80D0.2090303@mac.com> <20060301001626.GM21419@isc.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7FBCD272-D73B-4EDC-9DC0-6845C186CE40>