Subject: [dhcwg] DNA Issue 40: DHCP Client Identifier

From: Bernard Aboba <[email-masked]>
Date: Wed, 23 Nov 2005 08:30:57 -0800 (PST)

Issue 40: DHCP Client Identifier
Submitter name: David Hankins
Submitter email address: [email-masked]
Date first submitted: November 11, 2005
Reference: 
Document: DNA-17
Comment type: T
Priority: S
Section: 1.1
Rationale/Explanation of issue: 

There was recent re-talk about the 3315 id for v4 on the wg mailing
list recently, reminding me of the clause in section 1.1:

  the correct one. For example, eliminating a candidate
  configuration because it was obtained on a different physical
  interface would not be wise. In the case of an Ethernet link
  and an 802.11 wireless link bridged together, an IP address and
  default gateway on the Ethernet link may continue to represent
  a valid and usable configuration if the host loses its Ethernet
  connection and switches to 802.11 wireless.

Maybe needs to explicitly say something about client identifier? Or
else remove the example.

I don't know the answer, I'm asking. People get awful confused about
this. I would hate to think that someone used dnav4 as an excuse to
reuse a lease that was granted to a different client-identifier.

Perhaps the example should be removed? I can't think of how to put
the client identifier in that paragraph without sounding clunky and
too technical for an intro.

Maybe I'm just being paranoid.

[Stuart Cheshire] Why?

Looking at the big picture, if my machine has an IP address, with life 
left on the lease, and can ARP the expected associated gateway, what 
reason is there for us to decide to make that not work?

If your answer is enforcement of some security policy, then 802.1X is the 
way to enforce security policies.

Suppose a machine has dual Ethernet ports (as many do these days) and the 
user connects the Ethernet cable to the other port. Should DNAv4 refuse 
to work in that case, just because the Ethernet packets are coming in 
through the wrong PHY?

[David Hankins]

> If your answer is enforcement of some security policy, then 802.1X is 
> the way to enforce security policies.

Nono, I am the client identifier poster boy of the DHC WG, "DHCP
security" is one of those things I just giggle at.

> Suppose a machine has dual Ethernet ports (as many do these days) and the 
> user connects the Ethernet cable to the other port. Should DNAv4 refuse 
> to work in that case, just because the Ethernet packets are coming in 
> through the wrong PHY?

In my opinion, "Maybe".

If the client uses the same client-identifier (which may be a DUID:IAID
pair within a client-identifier option) on both interfaces, DNAv4 should
accept that lease from the other interface as valid and go ahead and use
it. "Yes."

If the client uses a different identifier on the two interfaces in
question, or any other example of "differing identities", DNAv4 should
refuse to adopt the lease and ask DHCP instead. "No."

Because: In the second case, when the lease is renewed, a DHCP server
properly implementing the protocol /will/ identify the client as distinct
from the client it originally assigned the lease to, and /will/ NAK it,
causing the client to change leases anyway, this time more probably at
a time when the client is actually making active use of the network.

The server has assigned that lease to a client identifier (or chaddr).
It has not assigned it to a DUID or hardware address or "vague notion
of 'client'".

Additional: The client must be prepared to use the same address on
multiple interfaces in the case where the client has not moved a single
connection to the physical network from one interface to another, but
rather has connected the same physical network to both interfaces. It
may only have enough information to learn that this has happened at a
later time.

In such a case, accepting the other interface's address may be disruptive
to the system, if it is not prepared to handle that condition. If it is
prepared to handle that condition, I would think the client would be using
the same client identifier for each interface.

I think all of this is may be too complicated to encode in the DNAv4
document, or at least in that section of the document. The example as
it stands I think is too liberal, and might lead someone to think they
should do the "No" case above.

I would like to see the example cite that the candidate lease from an
alternate interface MUST be so identically identified as I've described
(although it need not cite 3315-id-in-v4, just identical-client-id
values).

I think since this may be a great number of words, the example perhaps
should just be omitted, but I'm not fixed on that point.

At least, I can't see a way to fit that into the example without making
it very hard to read.

I can take a stab at it if you'd prefer to keep the example.

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

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 30 Nov 2005 13:00:34 -0800

> Rationale/Explanation of issue: 

... snip ...

> I can take a stab at it if you'd prefer to keep the example.

In the meantime, Mr. Aboba has updated the draft to level 18, removing
the example and adding the client-id to the list of explicit things
a client implementing dna should remember about a candidate
configuration.

This is great, but it solves the problem of the pink elephant in our
living room by simply choosing not to talk about it.

So, I would like to suggest that section 2.1 receive a fourth
condition for a DNAv4 client to skip candidate configurations;

    [d] The contents of the DHCP Client Identifier option the client
	used to obtain the candidate configuration is, even slightly,
	different from the Client Identifier option the client intends
	to present on the interface now being addressed, or a comparison
	is impossible because either or both sources do not use Client
	Identifier options.  In these cases, it is anticipated that a
	DHCP server would NAK any request made by the client to acquire
	or extend the candidate configuration, since the two interfaces
	are presenting differing identities.

I think this is the neatest and lowest impact way to both suggest to the
implementor "hey, look at other interfaces maybe!" and give them precisely
the logic they need to avoid DHCP server NAKs later on in operating if
they do.

In hindsight now, it's possible the example removed in the 17->18 edits
could be reintroduced along with the above statement, but I still think
the example is provocative without being encumbered by so many words to
describe the failure modes as to crush it.

Perhaps with an explicit nod to the section 2.1 qualifications.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg