DHCP Server Identifier Override Suboption
draft-ietf-dhc-server-override-05

[Ballot comment]
I am carrying forward Ted's abstain vote.  I have reviewed the document
in depth, including the changes between -03 and -04 and do not believe
a serious effort was made to address Ted's legitimate concerns.  Indeed
between -03 and -04 it appears only 4 paragraphs were added all largely
unrelated to Ted's concerns.

To elaborate on Ted's concerns in my own words, this is a profound
model change to the security of DHCP.  The relay agent gains the
ability to intercept all DHCP traffic even if network topology might
not otherwise permit that.  The server MUST include the relay agent's
server identifier instead of its own regardless of the security
consequences of doing so.  And the client loses the ability to
identify the server that is actually processing the request.

Such a profound change should be motivated and the consequences
discussed in more detail.  The document would also be improved by
discussing the additional logging/diagnostic requirements this
introduces above those of a previous DHCP relay agent deployment.

[Ballot comment]
The latest draft seems to address Ted's concern years back about how the situation is handled when the DHCP server doesn't understand the option sent.  I think it also now handles Ted's security concerns but I don't know enough about DHCP security to be certain. 

FYI, the IANA Considerations section ends with "None." as a complete sentence which seems like a bug. 

Re: the sentence "In a situation where the DHCP Relay is configured to forward packets to more than one server, the DHCP Relay should forward all DHCP packets all servers":  Missing 'to', and should SHOULD be SHOULD.

[Ballot discuss]
Given there is a large discussion on DHCP-auth mechanisms in the WG and there will be changes, should this draft address any of the new (inevitable) mechanisms?

[Ballot discuss]
It's not clear to me why you would want the DHCP relay agent to repeat relay information on RENEWALs. Isn't that stuff unlikely to change during the duration of the lease?

[Ballot discuss]
This discuss has two parts.  Part A may already be satisfied by reference for readers with
more dhcp background.  Part B has a set of relatively straightforward issues that need to
be resolved in the security considerations section.

A. In general, this suboption is designed to cause no harm if the DHCP server cannot process
it.  That is, the DHCPREQUEST message will result in the same action by the server, regardless
of whether the suboption is recognized.  The only difference would be the value inserted in
the server identifier option.  As a general rule, this propoerty seems to hold, but there is
one scenario that concerns me.

There appears to be one case where a DHCP server will reject a request that it would
have honored, and it is unclear how the relay agent identifies this situation or how they
should respond.  As noted in Section3, paragraph 4, where the Server Identifier
Override Suboption and the Server Identifier Option specify the same address, then the
Server should accept the DHCPREQUEST packet for processing even if it does not match a
configured DHCP Server interface address.  However, a DHCP server that does not process
the new suboption will reject the same request.  The error message will indicate that the
value in the Server Identifier option is invalid when the real problem is that the server
override suboption was not recognized.

How does the relay agent differentiate or avoid this failure condition?

B. Steve Hanna identifed several issues with respect to the Secuirty Considerations section
in his SecDir Review.  These issues should also be addressed.

(1) The damage that a rogue DHCP relay could cause also includes changing
DHCP options in DHCPACK messages and extending leases when they should
not be extended. This should be noted.

(2) The current text implies that either DHCP authentication or DHCP Relay
Agent option authentication can be deployed to provide adequate protection
against the threats described. Actually, this is not accurate.  Both need to
be employed.  DHCP Relay Agent option authentication alone will not suffice
unless protection is in place against the introduction of rogue DHCP relays.
Without DHCP authentication, a rogue relay could simply
change the Server Identifier in the DHCPOFFER without detection.

(3) This draft does not add any new vulnerabilities
that were not already present, except in the case where
DHCP authentication is already in place and DHCP clients
require its use. This should be noted.

(4) This draft should recommend that either DHCP authentication
SHOULD be deployed or protection be provided against the insertion
of rogue DHCP relays and servers. Such protection continues
to be essential in protecting clients from misconfiguration.

(5) A discussion of the security benefits provided by this option
(if any) would also be useful. Apparently, this option extends
the benefits of the DHCP Relay Agent Info option as described
in section 4.0 of 3046 to cases where the DHCP client sends
unicast packets (like the RENEWING state). I'm not sure that
any of these benefits actually apply in that circumstance but
it would be good to describe any security benefits provided.

[Ballot discuss]
In general, this suboption is designed to cause no harm if the DHCP server cannot process
it.  That is, the DHCPREQUEST message will result in the same action by the server, regardless
of whether the suboption is recognized.  The only difference would be the value inserted in
the server identifier option.  As a general rule, this propoerty seems to hold, but there is
one scenario that concerns me.

There appears to be one case where a DHCP server will reject a request that it would
have honored, and it is unclear how the relay agent identifies this situation or how they
should respond.  As noted in Section3, paragraph 4, where the Server Identifier
Override Suboption and the Server Identifier Option specify the same address, then the
Server should accept the DHCPREQUEST packet for processing even if it does not match a
configured DHCP Server interface address.  However, a DHCP server that does not process
the new suboption will reject the same request.  The error message will indicate that the
value in the Server Identifier option is invalid when the real problem is that the server
override suboption was not recognized.  How does the relay agent differentiate or avoid
this failure condition?  Otherwise, this could potentially cause denial of service.

Steve Hanna identifed several issues with respect to the Secuirty Considerations section
in his SecDir Review.  These issues should also be addressed.

(1) The damage that a rogue DHCP relay could cause also includes changing
DHCP options in DHCPACK messages and extending leases when they should
not be extended. This should be noted.

(2) The current text implies that either DHCP authentication or DHCP Relay
Agent option authentication can be deployed to provide adequate protection
against the threats described. Actually, this is not accurate.  Both need to
be employed.  DHCP Relay Agent option authentication alone will not suffice
unless protection is in place against the introduction of rogue DHCP relays.
Without DHCP authentication, a rogue relay could simply
change the Server Identifier in the DHCPOFFER without detection.

(3) This draft does not add any new vulnerabilities
that were not already present, except in the case where
DHCP authentication is already in place and DHCP clients
require its use. This should be noted.

(4) This draft should recommend that either DHCP authentication
SHOULD be deployed or protection be provided against the insertion
of rogue DHCP relays and servers. Such protection continues
to be essential in protecting clients from misconfiguration.

(5) A discussion of the security benefits provided by this option
(if any) would also be useful. Apparently, this option extends
the benefits of the DHCP Relay Agent Info option as described
in section 4.0 of 3046 to cases where the DHCP client sends
unicast packets (like the RENEWING state). I'm not sure that
any of these benefits actually apply in that circumstance but
it would be good to describe any security benefits provided.

[Ballot comment]
From Steve Hanna's SecDir review:

On the last line of page 5, I think the phrase "all DHCP packets
all servers" should be "all DHCP packets to all servers".

The document should reference essential docs earlier, no later
than section 3. For example, RFC 3046 is not actually referenced
at all, although clearly section 5 intends to do so.

This document should reference DHCPv6, since it is referred to.

The references should be divided into normative and informative.

The reference in section 5 should be to [6] not [3].

[Ballot discuss]
In general, this suboption is designed to cause no harm if the DHCP server cannot process
it.  That is, the DHCPREQUEST message will result in the same action by the server, regardless
of whether the suboption is recognized.  The only difference would be the value inserted in
the server identifier option.  As a general rule, this propoerty seems to hold.

However, there appears to be one scenario where a DHCP server will reject a request that
it would have honored.  As noted in Section3, paragraph 4, where the Server Identifier
Override Suboption and the Server Identifier Option specify the same address, then the
Server should accept the DHCPREQUEST packet for processing even if it does not match a
configured DHCP Server interface address.  However, a DHCP server that does not process
the new suboption will reject the same request.  The error message will indicate that the
value in the Server Identifier option is invalid when the real problem is that the server
override suboption was not recognized.  How does the relay agent differentiate or avoid
this failure condition?

The remainder of my DISCUSS issues are taken from Steve Hanna's
SecDir Review:

The Security Considerations section of the document has a few
issues.

(1) The damage that a rogue DHCP relay could cause also includes changing
DHCP options in DHCPACK messages and extending leases when they should
not be extended. This should be noted.

(2) The current text implies that either DHCP authentication or DHCP Relay
Agent option authentication can be deployed to provide adequate protection
against the threats described. Actually, this is not accurate.  Both need to
be employed.  DHCP Relay Agent option authentication alone will not suffice
unless protection is in place against the introduction of rogue DHCP relays.
Without DHCP authentication, a rogue relay could simply
change the Server Identifier in the DHCPOFFER without detection.

(3) This draft does not add any new vulnerabilities
that were not already present, except in the case where
DHCP authentication is already in place and DHCP clients
require its use. This should be noted.

(4) This draft should recommend that either DHCP authentication
SHOULD be deployed or protection be provided against the insertion
of rogue DHCP relays and servers. Such protection continues
to be essential in protecting clients from misconfiguration.

(5) A discussion of the security benefits provided by this option
(if any) would also be useful. Apparently, this option extends
the benefits of the DHCP Relay Agent Info option as described
in section 4.0 of 3046 to cases where the DHCP client sends
unicast packets (like the RENEWING state). I'm not sure that
any of these benefits actually apply in that circumstance but
it would be good to describe any security benefits provided.

[Ballot comment]
Reviewing Allison and Ted comments I am seriously questioning the advancement of this document. At the same time I have not reveiwed to have any personal position. That would mean getting up to speed on DHCP.

[Ballot comment]
This document was reviewed by Allison and I am simply  taking over her position with little to no review. Mostly I have tried not to force documents though multiple reviews since each review only seem to uncover more problems. If you think I would come to a significantly different position than Allison and it turns out that my position is relevant to the disposition of this document, feel free to request that I review this.

[Ballot comment]
Section 6 seems not inline with the IPR words we require these days.
It is in fact redundant give the IPR text on page 10.

References are not split in normative and informative.

Sect 5. Last word "none" probably should be removed?

[Ballot comment]
I'm abstaining because Allison's comments made it clear that I don't
understand DHCP well enough to evaluate the issues and to say there
are no problems with this document.  If requested to do so I can come
up to speed on DHCP enough to either vote yes or to maintain an
abstain on this document.

[Ballot comment]
The claim is made that this brings DHCPv4 in line with DHCPv6:
  In short, this new suboption allows the DHCPv4 relay to function in
  the same fashion as the DHCPv6 relay currently does.
Reference?

I sent email to the IESG list about my abstention, forwarding a pretty
devastating comment on this draft, which had no followup that I could find:

I think the WG didn't do much about this document.
Issues about its problematic impact were raised by the
by the WG folks as well.

Nov.  It didn't go onto the Vancouver agenda.  AD's what was
up with the discussion of this document?

I can't find any WGLC discussion, but my personal archive may
not be complete.

IMO, IESG be generally supportive of duly chartered work and WG consenses.

But DHC auto-charters.  There is never review for the architectural
foundations of the new documents and extensions that they take up.
And if the WG consensus of a document is not great when
it comes to the IESG...we get here.

I don't want to leave a Discuss behind me.  What I'd propose 
for action items would be:

- New review of the concerns by discussants in the working
  group; were they addressed? do they* think the document needs
  a revision before returning to the IESG?  In other words,
  a return to WGLC
- A re-charter of DHC should look at the way extensions grow,
  particularly how new work is adopted.

Allison

------- Forwarded Message

Date:    Wed, 09 Nov 2005 00:22:31 +0000
From:    "David W. Hankins"
To:      dhcwg@ietf.org
Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-03.txt

Since this isn't on the agenda this week, I wanted to comment on this
again before I forget.

[you can find the rest in the archive]

[Ballot comment]
The claim is made that this brings DHCPv4 in line with DHCPv6:
  In short, this new suboption allows the DHCPv4 relay to function in
  the same fashion as the DHCPv6 relay currently does.
Reference?

IANA Comments:
Upon approval of this document the IANA will assign a suboption number for the Server Identifier Override Suboption from the DHCP Relay Agent Information  Option suboption number space. 

IANA needs clarification of where this assignment will go.  Does the "DHCP Relay Agent Information Option suboption registry" need to be created at the following?: http://www.iana.org/assignments/bootp-dhcp-parameters

There seems to be a "None" at the end of the IANA considerations section that doesn't belong there.

[Ballot comment]
I will abstain from this document for the following reason:

This option makes this relay-server interaction again more complicated,
while the motivation why we need this option is poorly documented (see Brian's comments).

I wonder whether it is in the interest of the DHCP users and operators that this protocol becomes more and more complicated while the perceived benefits are
unclear as they are insufficiently documented and motivated.

Is this feature in the interest of vendors to make it harder for competitors to
design fully standards compliant DHCP servers and relays ? Is there a real
need among operators to make their DHCP deployments even more complicated and
thus more prone to misconfiguration or security issues ?

[Ballot discuss]
Section 6 seems not inline with the IPR words we require these days.
It is in fact redundant give the IPR text on page 10.

References are not split in normative and informative.

Sect 5. Last word "none" probably should be removed?

[Ballot comment]
I've chosen to abstain on this.  There are two basic reasons.  I believe this makes a fundamental change to the DHCPv4 security model with respect to relay agents, and I think the draft neither motivates this sufficiently nor handles the new role behavior particularly well.  I also believe the case where the relay agent sends this and it is not understood by the server is handled poorly, as it amounts to "make sure it doesn't happen."

[Ballot comment]
John Loghney's Gen-ART review comments:

1) Intro says:

  There are many situations where the DHCP relay is involved and can
  insert a relay agent option with appropriate suboptions easily into
  DHCP DISCOVER messages. 

Of course, this begs the question - what are those situations?  Anyhow,
I think the intro is a bit short on motivation for this suboption.

[BC. Agreed, but not enough to hold the document.]

2) IANA Section says:

5.  IANA Considerations

  IANA is requested to assign a suboption number for the Server
  Identifier Override Suboption from the DHCP Relay Agent Information
  Option [3] suboption number space.  None.


I don't understand what the 'None.' refers to.

[BC. Indeed. I presume it should be deleted]