Subject: Re: [dhcwg] dhcwg Digest, Vol 67, Issue 18

From: "Lu Huang" <[email-masked]>
Date: Thu, 19 Nov 2009 17:21:52 +0800

Hi, Bharat

See inline:

>What I like about this idea is that it fulfils all the use cases and it may work with existing DHCP servers as well.
>
>We had also proposed a new sub-option in our draft but the main difference is that 2nd and subsequent Relay Agent was creating this sub-option with option 82 of the received message.
>
>Now my question is whether it is ok to let a Relay Agent insert a sub-option in an already existing option 82 which was added by a previous Relay Agent. If yes, I think we could use this.

Will it invalidate the signiture?

BTW, to all: I wonder what's the scenerio where we use signiture in DHCP message? Anyone can say something on it?

Thanks.

>
>------------------------------
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>End of dhcwg Digest, Vol 67, Issue 18
>*************************************
>
>__________ Information from ESET NOD32 Antivirus, version of virus signature database 4614 (20091117) __________
>
>The message was checked by ESET NOD32 Antivirus.
>
>http://www.eset.com
>
>
>

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 19 Nov 2009 14:58:33 +0530

Hi Lu Huang,

> BTW, to all: I wonder what's the scenerio where we use signiture in DHCP message? Anyone can say something on it?

Even I do not really know how and when the signature in DHCP message is used? So I can not really comment on this.

But if you mean whether DHCP server can find out 'who added what part of the option' then I am sure that is not an issue at all.

Regards,
Bharat

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 19 Nov 2009 16:43:15 -0800

> Will it invalidate the signiture?

I think all of the discussed approaches will need a clear definition
of how and in what order signatures will be applied and
reversed/validated, but that it would basically be able to work.  The
extra-option approach for example would work if you can clearly
mandate and require that only the first relay in a chain use the new
option, or only the second relay in a chain use the new option, or
some other enforcement like this.  In this case, you can easily place
an order-of-operations on which signature to validate first, to remove
those contents, and so forth.

For example, even today inserting agent options breaks DHCPv4 client
authentication signatures - which is why you remove the agent options
prior to validating client signatures.

But even then if the client sent a series of PAD bytes at the end of
their 576 octet packet, the DHCPv4 server may not necessarily know
this, and the validation will fail (when the agent options are
inserted, they will fill the padded space, when they are removed, the
pad space is gone).  This happens whether the relay agent is
authenticating or not.

So these kinds of edge conditions need to be clearly defined (and are
not even well defined, IMO, in RFC 2131 today).  As I said before, I
think all the proposals can work if a clear order of operations is
declared.

Of course if some approach simply does not work with authentication
signatures, I think we have to de-select that approach. :)

But what does happen is we may get different results with some of the
approaches; in one approach, certain relays may be able to continue to
authenticate with the DHCP server without needing new software, in
others they may require forklift software upgrades, and it would be
good to at least know that when we're choosing an approach to move
forward with.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Nov 2009 23:49:49 -0500

> Will it invalidate the signiture?

If there is a relay agent authentication option, then it will invalidate that signature, yes.

> BTW, to all: I wonder what's the scenerio where we use signiture in DHCP message? Anyone can say something on it?

I don't know if anybody is doing it.   It certainly seems like a good idea in any situation where you don't have complete physical control over your relay agent infrastructure, and are depending on it to determine how to treat clients that connect through your relay agents.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Nov 2009 23:52:16 -0500

> pad space is gone).  This happens whether the relay agent is

Are you sure about this?  It's my understanding that the RFC requires you to leave all the options there except the END option, which is replaced upon removal of the relay agent options.

> think all the proposals can work if a clear order of operations is

Since the relay agent information option is defined in RFC3046, it's not surprising that RFC2131 doesn't talk about it!   :')

---

From: Stephen Jacob <[email-masked]>
Date: Fri, 20 Nov 2009 08:34:54 -0800

> those contents, and so forth.

In the approach suggested where the second relay agent would add a
sub-option to the existing relay-agent-information option, I don't
think there is any need to limit how many relays can add their
options and I don't think that further complicates the algorithm
for adding or checking a signature beyond what you're talking about
already.

It's kind of nasty not least because it's sort of inside-out versus
the way DHCPv6 does it, but as I understand it the idea was that a
new sub-option (I've arbitrarily picked the name
'next-relay-information' to represent it below) something like:

	relay-agent-information := encapsulation(agent)

	encapsulation(agent) := {
		circuit-id := octets,
		remote-id := octets,
		...
		next-relay-information := encapsulation(agent)
	}

So you could have a message arrive at the DHCP server containing
something like:

	relay-agent-information = {
		circuit-id = "added by relay closest to client"
		next-relay-information = {
			some-other-sub-option = "added by 2nd relay"
			next-relay-information = {
				some-other-sub-option = "added by 3rd relay"
				next-relay-information = {
					...
				}
			}
		}
	}

Dropping the 'next-relay-information' sub-option data in its entirity
from the top-level 'relay-agent-information' option before verifying
a signature works the same regardless of whether you allow recursing
to have multiple relay agents add their chosen relay agent information
sub-options.

> prior to validating client signatures.

Oh, right, good point ... so if we went with the sub-option of
relay-agent-information approach that I mentioned above (I forget
who it was who proposed it and I hope I am correctly representing
what they intended) then existing servers which know to drop the
relay-agent-information option before verifying a signature would
continue to work. That seems advantageous.

Regards,
Stephen
-- 
 Stephen Jacob | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000