Subject: WG: [dhcwg] ID's: Interface Information Option

From: "Rentschler, Markus" <[email-masked]>
Date: Thu, 6 Nov 2003 09:10:40 +0100

> [MR>]  Hi,
>  
> Assuming that a client SHOULD always send the IIO to the server, what does
> it fill it with in the original Discover?  At this point it has never
> recieved a Server->Client packet.
> [MR>]  Clients wouldn't be able provide the IIO at this time. They need at
> least one packet received from the server to determine the receiving
> interface. The IIO can therefore only be added to responses to the server,
> not to initial client messages. But since there is a four message exchange
> with DHCP, the client will always have the opportunity to get the IIO to
> the server.
> 
> What benefit does this particular option give over simply using the
> existing Client Identifier (Opt 61) to encode such information? 
> [MR>]  There are several benefits:
> 
> -- Another parameter for more tightly IP address allocation schemes for
> higher security. (The server configurator can for example say: a certain
> IP address/configuration is only allowed to a certain client (use MAC and
> /or Client-Id) on a certain location in the network topology (use Option
> 82) that is connected via a certain interface (use IIO).
> Any other useful combinations with other client's parameter as trigger
> conditions may be thought of...
> -- Possibility for topology discovery and therefore detection of
> misconfigured connections.
> 
	(Which still doesn't address what happens on the original Discover) 
	[MR>]  

> You note in section 1: 
> 
>    The relay agent information option [RFC 3046], which is added by 
>    a relay agent to a client's request to the server, contains in its 
>    Circuit ID sub option the number of the physical interface on which 
>    the relay received this client's request.. 
> 
> Keep in mind that devices using opt 82 aren't required to have a circuit
> ID.  The wording of the above should reflect that a device MAY add a
> circuit ID.  
> [MR>]  That's correct. I will change that.
> 
> As well, the service cannot assume what the contents of a Circuit ID
> represents.
> [MR>]  "ecxact string match" (as in RFC 3046 for the Circuit-ID)  is also
> required for the IIO.
> 
> Regards,
>        Markus
> 
> 
> -----Ursprüngliche Nachricht-----
> Von:	Kostur, Andre [SMTP:[email-masked]]
> Gesendet am:	Dienstag, 4. November 2003 18:14
> An:	'Rentschler, Markus'; [email-masked]
> Betreff:	RE: [dhcwg] ID's: Interface Information Option

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Barr Hibbs" <[email-masked]>
Date: Thu, 6 Nov 2003 11:15:25 -0800

comments inline....

--Barr

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Rentschler, Markus
> Sent: Thursday, November 06, 2003 00:11
> >
> > IP address/configuration is only allowed to a certain client
> > (use MAC and /or Client-Id) on a certain location in the network
topology
> > (use Option 82) that is connected via a certain interface (use IIO).
...you've obviously never had to manage an extremely large, widely dispersed
client population with a diverse technician workforce.  It is AN EXTREMELY
BAD IDEA to try to "lock-down" devices by insisting on strict, unchanging
relationships between MAC addresses, Client Identifiers, Host Names, hub,
switch, or router ports, and other network elements.

The principal benefit of DHCP is to reduce the need for detailed
recordkeeping and configuration which represents a huge savings in labor
costs, and reduced troubleshooting and repair times.

Don't arbitrarily throw out that major benefit in the pursuit of the elusive
goal of "improved security" -- when was the last time your organization, or
ANY organization of which you had knowledge, was penetrated by someone
plugging in an unauthorized network device?