Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Apr 1999 11:41:03 -0400 (EDT)
From:      Robert Watson <robert@cyrus.watson.org>
To:        cjclark@home.com
Cc:        David Gilbert <dgilbert@velocet.ca>, Harry_M_Leitzell@cmu.edu, fred@fredbox.com, security@FreeBSD.ORG
Subject:   Re: DHCP (was Re: poink attack (was Re: ARP problem in Windows9X/NT))
Message-ID:  <Pine.BSF.3.96.990420113449.27597A-100000@fledge.watson.org>
In-Reply-To: <199904201515.LAA09694@cc942873-a.ewndsr1.nj.home.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Apr 1999, Crist J. Clark wrote:

> David Gilbert wrote,
> > Not this discussion 'should' be about what 'should' be, but wouldn't
> > it make sense to have the DHCP server be the 'athority' by which
> > hardware addresses are resolved?  I suppose there's little security
> > built into that protocol, too.  We recently went to implement it for a 
> > customer and were somewhat taken aback by what could happen if someone 
> > managed to just 'connect' a laptop to the network who wasn't supposed
> > to.
> 
> OK, I'll bite.
> 
> What happens when someone who is not supposed to connects to a DHCP
> served network? (Besides that they are connected to the network and are
> not supposed to be.)

Well, the quick answer would be denial of service.  I was on the DHCP
security working group for a while, and my conclusion was really that
there is no good answer; you can sort of do something if you have really
smart programmable switches, but that sort of violates the "they manage to
just connect..." assertion.

With crypto extensions, you can prevent the server from allocating
resources it shouldn't, and you can generate an audit trail for the client
in the event of spoofing (although you might not notice it).  In the end,
denial of service attacks are not something you can control in this
environment unless you can make guarantees about the medium.  As long as
crypto is used for all other applications and your software is right, it
doesn't go much beyond that, however.

  Robert N Watson 

robert@fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
Safeport Network Services             http://www.safeport.com/



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990420113449.27597A-100000>