Re: DHCP and secondaries
Mike Carney - Sun BOS Software <Mike.Carney@east.sun.com> Fri, 17 May 1996 17:30 UTC
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19615;
17 May 96 13:30 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19611;
17 May 96 13:30 EDT
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa12295;
17 May 96 13:30 EDT
Received: from localhost by reef.bucknell.edu with SMTP
(5.65/IDA-1.2.8) id AA17252; Fri, 17 May 1996 12:28:18 -0400
Date: Fri, 17 May 1996 12:28:18 -0400
Message-Id: <9605171520.AA19338@poori.East.Sun.COM>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
X-Orig-Sender: dhcp-v4@bucknell.edu
Precedence: bulk
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mike Carney - Sun BOS Software <Mike.Carney@east.sun.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Re: DHCP and secondaries
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
Mime-Version: 1.0
X-Mailer: Pronto E-Mail [Ver 2.04]
> > I would like to require that the
> > users of our dhcp service register the hardware addresses
> > of their NIC cards before the server allows the client to
> > be services from either an automatic or dynamic pool.
>
> I'd be curious to know why. The authentication proposal
> you mention allows clients to be assured that the DHCP
> responses are from legitimate servers. However, if a
> server refuses to serve a particular client, that client
> can still commandeer an IP address that the server "owns."
> If a rogue client has physical access to the lan, there's
> really no way to prevent it from claiming addresses from
> either one of your address pools. (Oh, perhaps with a sniffer
> or similar tool you can detect the rogue and on TR send it
> KILL frames or some such. There's also been talk
> about how to manage this problem with internal fire walls,
> but those are all ways to react to the problem, not how
> to prevent it.)
>
> Are you assuming a physically secure lan, and a group of
> users who all "play nice" together? If so, I can see how
> the registration might be useful for accounting and other
> administrivia.
>
> Edie
>
Hi Edie,
I feel the same way about DHCP authentication. Without link-level
(or IP level (SKIP)) security, anyone can connect to your lan, and snoop to
discover the network address and subnetmask, then use arp to find one not
in use. You could even snoop for DHCP packets, and find out about name
services, etc.
The only way DHCP could have strong authentication would be to add
a public key/secret key arrangement, which would require the secret key to
be stored on the client. Anytime you have to store IP configuration info on
the client (even the secret key), you lose, since the whole idea of DHCP is
to provide a central store for this information.
Using SKIP or link-level security is the only way to protect your
data and your network, since it's all encrypted.
Mike Carney
SunSoft PC Networking
Chelmsford, MA
- DHCP and secondaries Tim Peiffer
- Re: DHCP and secondaries Ted Lemon
- Re: DHCP and secondaries Erikas Aras Napjus
- Re: DHCP and secondaries David M. Meyer 503/346-1747
- Re: DHCP and secondaries John Miezitis
- Re: DHCP and secondaries Tim Peiffer
- Re: DHCP and secondaries Tim Peiffer
- Re: DHCP and secondaries Sam Wilson
- Re: DHCP and secondaries Ted Lemon
- Re: DHCP and secondaries Mike Carney - Sun BOS Software
- Re: DHCP and secondaries Erikas Aras Napjus
- Re: DHCP and secondaries Michael J. Lewis
- Re: DHCP and secondaries Richard Letts
- Re: DHCP and secondaries Christopher Davis
- Re: DHCP and secondaries Christopher Davis
- Re: DHCP and secondaries Richard Letts
- Re: DHCP and secondaries William Rippon
- Re: DHCP and secondaries Richard Letts
- Re: DHCP and secondaries John Miezitis
- Re: DHCP and secondaries William Rippon
- Re: DHCP and secondaries Edie E. Gunter
- Re: DHCP and secondaries Christopher Davis
- Re: DHCP and secondaries Mike Carney - Sun BOS Software
- Re: DHCP and secondaries Christopher Sulentic
- Re: DHCP and secondaries Zuwei liu