Subject: RE: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 8 Oct 2002 13:16:51 -0500

Thomas:

Perhaps I shouldn't raise this, but it seems like we should be worrying much
more about security on the first hop (client <-> server/relay) than the
relay <-> server hop. The latter is much easier to secure as IPsec, tunneling,
and other fairly standard techniques could be used.

Also, is the DHCPv6 draft strong enough in this area to satisfy the IESG (at
least around the relay <-> server security)?

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Tuesday, October 08, 2002 1:50 PM
To: Kim Kinnear
Cc: [email-masked]; [email-masked]
Subject: [dhcwg] status of draft-ietf-dhc-agent-subnet-selection

Hi Kim.

> I was trying to recover some lost ground and figure out where the
> drafts which I am editing are in the process.  The following mail
> is the last on the subject of the subnet-selection sub-option
> that I can find in my mail archives.

This document is tied up in IESG unhappiness with the WGs dealing with
security issues. Basically, the IESG thinks that the overall security
model of relay agent option is rather inadequate (it assumes that the
entire network from the relay agent to the DHC servers is
trustable/secure). This is not a new issue; it was a concern back when
the original relay agent option document was approved. However, the WG
keeps sending new relay agent options to the IESG without also working
on the security model.

One thing that was pointed out was that other WGs have been told flat
out "no approval until you get a realistic security story". So, the
issue that was raised was why should the DHC WG be held to a lesser
standard.

What the IESG wants to see is a credible story for the WG will get
deployable/useable DHC security. In the case of the relay agent
option, the technical issues seem fairly straightforward. Because
relay-agents need to be configured, and because relay agents only need
to talk (securely) with DHC servers, the key distribution problem can
be handled via static keys/configuration.

Bottom line: the IESG wants an updated charter that has a reasonable
story for getting better security, together with an indication that
there is meat behind the wording (e.g., a draft, and/or a design team
that includes security clueful folk, etc.)

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Oct 2002 13:59:08 -0500

> least around the relay <-> server security)?

Right, the relay<->server hop is regular IP, so there's no reason not 
to use IPsec to secure it.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 08 Oct 2002 15:08:42 -0400

> Perhaps I shouldn't raise this, but it seems like we should be
> worrying much more about security on the first hop (client <->
> server/relay) than the relay <-> server hop.

We should be worried about both. So, we do need to revisit the DHCP
authentication stuff to come up with something more deployable. I.e,
wouldn't it be nice to (say) before an IETF download a certificate
that identifies the DHC servers that will be available (and trustable)
while at the IETF meetings?

> The latter is much
> easier to secure as IPsec, tunneling, and other fairly standard
> techniques could be used.

Right. So, for the case of IPv4, it would be really nice to at least
have this. Right now, we don't.

> Also, is the DHCPv6 draft strong enough in this area to satisfy the
> IESG (at least around the relay <-> server security)?

Section 21.2 in the dhcpv6 doc seems good enough. Use IPsec, with
static keys. This seems deployable/manageable, if not ideal.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 08 Oct 2002 15:11:14 -0400

Ted Lemon <[email-masked]> writes:

> > worrying much
> > IESG (at

> to use IPsec to secure it.

In DHCPv6, using IPsec makes sense. The relay agent is originating a
new message that it sends to the DHC server.

But DHCPv4 is different, in that it relays the client packet. So IPsec
can't really be used there. But certainly a DHC-specific
authentication option could be defined for covering the relay agent
option and/or portions of the client request.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Tue, 08 Oct 2002 15:22:11 -0400

If I squint my eyes and stand back far enough, I don't see that the DHCPv4 
case is different.  While the relay agent is relaying a message on behalf 
of the client, it really is relaying that message in an independent UDP 
message, in which the source address belongs to the relay agent.  I don't 
think there is any reason the relay agent and server can't employ IPsec on 
the relay agent<->server messages.

Of course, IPsec may be problematic if there are multiple relay agents in 
the path - which is the problem Mark Stapp is trying to solve, right?

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Oct 2002 14:47:41 -0500

> option and/or portions of the client request.

IPsec is done at the IP header level.   The IP header for the DHCPv4 
relay agent is in fact newly-generated.   So I don't see how this would 
be a problem.   The difference between v4 and v6 relaying has to do 
with the format of the newly-generated packet, not with the IP header.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Oct 2002 14:49:00 -0500

> Of course, IPsec may be problematic if there are multiple relay agents 
> in the path - which is the problem Mark Stapp is trying to solve, 
> right?

Still not a problem, technically.   You just have one security 
association for each DHCP agent pair, so if you have a double relay, 
you have two security associations.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 09 Oct 2002 14:35:36 -0400

> case is different.

Conceptually similar, details are different.

> While the relay agent is relaying a message on behalf 
> message, in which the source address belongs to the relay agent.

Isn't the source address of the packet that of the client (and not the
relay agent)? This makes a huge differences with regards to IPsec.

Even worse, the client has no IP address yet, so the relayed packet
has no source address...

This can't be made to work trivially with stock IPsec. You'd need
extensions I'd suspect, defeating much of the purpose of trying to use
IPsec.

Note that the above also factored into why DHC needed something
specific to DHC rather than trying to somehow use IPsec.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Wed, 09 Oct 2002 14:58:58 -0400

The message from the relay agent to the server uses the relay agent's 
address as the source address.  The relay agent modifies and sends the DHCP 
message as the payload in a UDP message that appears to originate from the 
relay agent.  Section 4 of RFC1542 gives more details.  The difference 
between DHCPv4 and DHCPv6 is in the way in which the client message is 
processed by the relay agent (in DHCPv6, the message is encapsulated in a 
new message generated by the relay agent).

Yes, IPsec cannot be used from the client to the server.  The proposal for 
the use of IPsec under consideration here is to protect the message as it 
travels between the relay agent and the server.  The primary purpose is to 
protect any relay agent options, addressing an issue raised by the original 
relay option spec (RFC3046), which assumes no security is needed between 
the relay agent and the server.

- Ralph

---

From: Mark Stapp <[email-masked]>
Date: Wed, 09 Oct 2002 15:29:46 -0400

I had thought that the progressing relay-agent-authentication draft was the 
response to Thomas's issue. That seemed to me to be targetted at the 
specific problem of relay<->server communication, and to require relatively 
light-weight implementation and configuration changes while providing an 
appropriate level of security. That path still seems to me to offer the 
best cost/benefit/deployment balance. Will it be more difficult to deploy 
and configure an ipsec solution in heterogeneous or complex networks? Will 
any additional configuration work required provide any additional security? 
Will relays need separate SAs to all the dhcp failover server pairs? Will 
all the kinds of v4 devices that act as relays and servers be able to 
implement ipsec? I'm concerned that choosing ipsec may lead to reduced 
adoption of relay-agent security.

-- Mark

At 02:58 PM 10/9/2002 -0400, Ralph Droms wrote:
>address as the source address.  The relay agent modifies and sends the 
>DHCP message as the payload in a UDP message that appears to originate 
>from the relay agent.  Section 4 of RFC1542 gives more details.  The 
>difference between DHCPv4 and DHCPv6 is in the way in which the client 
>message is processed by the relay agent (in DHCPv6, the message is 
>encapsulated in a new message generated by the relay agent).
>
>protect any relay agent options, addressing an issue raised by the 
>original relay option spec (RFC3046), which assumes no security is needed 
>between the relay agent and the server.
>
>- Ralph
>

---

From: Thomas Narten <[email-masked]>
Date: Wed, 09 Oct 2002 15:40:21 -0400

> new message generated by the relay agent).

OK. I misunderstood how this worked. Because the relay agent mucks
with the giaddr field, I had never understood that the relay agent is
in fact sourcing a packet with its own source address (which contains
the same info as the giaddr field). I guess back then, getting the
source address of a packet out of the API was deemed to hard or
something?

So yes, I agree IPsec could be used to secure the relay-agent - server
path.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 09 Oct 2002 15:45:04 -0400

Mark Stapp <[email-masked]> writes:

> response to Thomas's issue.

You mean draft-ietf-dhc-auth-suboption-00.txt? That would seem to be a
good step!

But I think the IESG also has asked  for a recharter and a more
general plan for dealing with DHC security.

I also agree with Mark that using IPsec, while possible, isn't
necessarily the obvious answer. I think a very real question is
whether one could get IPsec deployed on the relay agent devices where
its usage is actually needed most.

Note also, that IPsec (without IKE) might be adequate too. Manual
keying may well be workable given the trust relationship between DHC
servers and relay agents.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Fri, 11 Oct 2002 13:05:07 -0400

Here's a revised draft WG charter, with edits based on feedback from 
mailing list discussion.  The primary changes in this revision are:

* Rewrote the authentication charter item to require
   require development of a threat model and analysis
   of RFC3118, with suggestions about specific issues
   to consider in the analysis.  Added separate charter
   item to develop mechanisms to address issues identified
   by threat model and analysis.
* Deleted references to specific options to be published
   as part of DHCPv6; deleted reference to prefix delegation,
   DNS configuration (see below for more details)
* Replaced charter item on acceptance of DHCP as Standard
   with analysis of problems with current spec that impede
   development of interoperable implementations.

We need consensus on whether the following charter items should be included 
in the charter:

- Develop extensions to DHCPv6 for prefix delegation, DNS
   configuration, etc.
- Determine the requirements for DHC to support the dynamic
   renumbering of networks using fast path delegation as CPE
   front end between ISP and Private Networks.

Please reply with comments...

- Ralph

=====

		   Dynamic Host Configuration (dhc)

The working group has the following primary objectives:

* Develop a threat model and analysis of the authentication
   protection provided by RFC3118; specific issues to be addressed
   include:
   - Improved key management and scalability
   - Security for messages passed between relay agents and servers
   - Threats of DoS attacks through FORCERENEW

* Develop requirements for any new protocols to address threats or
   other enhancement identified by the threat model and analysis of
   3118

* Complete the specification of DHCP for IPv6 (DHCPv6):
   - Gain acceptance and publication of current Internet Draft as
     Proposed Standard
   - Develop and publish specifications for options and other
     extensions to DHCPv6, including those already published as
     Internet Drafts
   - Encourage independent implementations and report on
     interoperability testing
   - Revise specification and publish for acceptance as Draft Standard
     by 10/18/2002

* Write an analysis of the DHCP specification, including RFC2131,
   RFC2132 and other RFCs defining additional options, which identifies
   ambiguities, contradictory specifications and other obstacles to
   development of interoperable implementations.  Recommend a process
   for resolving identified problems and incorporating the resolutions
   into the DHCP specification.

* Complete the specification and publish work in progress as
   standards:
   - Failover protocol
   - DHCP/DDNS interaction
   - SNMP MIB
   - Host name options
   - Leasequery
   - Other client and relay agent options

* Review new options for DHCP, as deemed appropriate by the working
   group and/or the Internet area directors

---

From: Thomas Narten <[email-masked]>
Date: Mon, 14 Oct 2002 14:16:43 -0400

some comments on the charter:

Nits:

Would be good to have a short intro sentence at the start something
like:

The base DHC protocol is documented in RFCs 2131 and 2132 as well as a
number of related extensions and options (e.g., RFC 3118). The working
group has the following primary objectives ...

>    - Improved key management and scalability

Sounds here like your already jumping ahead to the requirements for
new protocols. I.e., shouldn't this phase be focused on undertstanding
limiations of the current mechanisms? Is this just a wording issue?

>    other enhancement identified by the threat model and analysis of

What's missing above is a clear statement that this WG will develop
new authentication mechanisms that address the deployability problems
with the current schemes (whether through an extension to 3118 or
something else). Or that it will address the relay-agent to DHC server
path.

>      extensions to DHCPv6, including those already published as

General comment on options (both IPv4 and IPv6). I'd like the charter
to clearly indicate that the DHC WG will be reviewing options to make
sure they are  consistent with the protocol, other option usages, etc.

In terms of reviewing  options for their semantic contents, that
will be done by subject matter experts, which may well not be in this
WG. This WG is not to take on options as WG documents until such an
outside expert has been identified and, e.g., the relevant  WG has
agreed on the need for such an option. What I'd like to avoid is
having the DHC WG spend time on options for which there isn't a clear
customer. 

>    into the DHCP specification.

The way its written above, sounds like one big fat hard-to-write
document. :-) Can't we do something simpler,  such as just have folks
write IDs that take on specific  issues and advance  them as
standalone RFCs (as appropriate), incorporating them into the base
spec when the base spec is republished? I'm worried that the above
reads like a lot of work that no one will be foolish enough to sign up for.

>    - Other client and relay agent options

Are there IDs for all of the above? If so, citing them would be good.

Also, I don't like the "other client and relay agent options" as it is
too open ended. I think the WG needs a way of vetting potential
options before the WG takes them on officially.

>    group and/or the Internet area directors

See above.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Tue, 15 Oct 2002 09:06:44 -0400

>group has the following primary objectives ...

OK.

>limiations of the current mechanisms? Is this just a wording issue?

Perhaps it is a wording issue?  s/include/might include/ ??  The intended 
purpose for the bullet list is to capture current "common knowledge" about 
the threat model and RFC3118.

>something else). Or that it will address the relay-agent to DHC server

Can you explain this comment in a different way, as it seems to be at 
cross-purposes with your previous comment about "jumping ahead to the 
requirements".  I think we're in having a violent agreement that we want to 
(a) get some DHCP authentication out to the client deployed and common 
wisdom is that the best path is through new mechanisms in the RFC3118 
framework; and (b) secure communication between the DHCP relay agents and 
servers.

>sure they are  consistent with the protocol, other option usages, etc.

The charter has a separate bullet item for review of options.  Are you 
suggesting that the bullet item be extended to include "consistent with the 
protocol, other option usages, etc." as specific types of review?

>Are there IDs for all of the above? If so, citing them would be good.

OK.

>options before the WG takes them on officially.

There are other options currently in the pipeline; this "other ... options" 
bullet is intended to refer to those options that are "work in 
progress".  New work is intended to fall under the following bullet item.

---

From: Thomas Narten <[email-masked]>
Date: Mon, 21 Oct 2002 16:02:12 -0400

Hi Ralph.

> the threat model and RFC3118.

The word "improved" implies to me not analyzing/understanding the
current systems, but jumping to the next steps of what is
needed. Seems like the threat model/analysis should be focused on
understanding the limitations and threats of what we have specified
today.

Having said that, I don't doubt that improvements are needed. :-) So
this is a wording issue I think.

> framework; and (b) secure communication between the DHCP relay agents and 

Maybe what is needed is a context paragraph before the specific
tasks. It could say something like:

   RFC 3118 defines current security mechanisms for DHCP.
   Unfortunately, RFC 3118 has neither been implemented nor deployed
   to date. There is widespread feeling that its current restriction
   to manual keying of clients limits its deployability. It is the
   goal of this WG to rectify this situation by defining extensions
   that have better deployability properties. In order to achive this
   goal, the WG will perform the following security-related tasks:

   [and then list specific items]

> protocol, other option usages, etc." as specific types of review?

I think it would be useful to have more specific text that describes
how (and when) options will be reviewed by the WG, and when they will
be taken on by the WG. I.e, something like:

   This WG also is responsible for reviewing (and sometimes
   developing) DHC options (for both IPv4 and IPv6). The WG is
   expected to review all proposed DHC options to ensure that they are
   consistent with the DHC protocol, other option formats, that they
   do not duplicate existing options, etc.  The WG cannot (generally)
   be responsible for evaluating the semantic content of proposed
   options. Only subject matter experts for the technology the option
   relates to can do so. The DHC WG will not adopt new DHC option
   proposals as WG documents without first coordinating with other
   relevant WGs and determining who has the responsibility for
   reviewing the semantic content of an option.

I don't have a strong feeling about which WG owns a DHC option
document (when the option is needed by another WG). So long as the two
WGs coordinate, things should work out. But in anycase, the WG should
sign off on all DHC options no later than (and hopefully much sooner
than) IETF LC. But this level of detail can probably be left out of
the charter and dealt with on a case-by-case basis.

> progress".  New work is intended to fall under the following bullet

The problem is that once the charter is out, there is no context for
recalling which options were "in the pipeline" when the charter was
written and which are new. Thus, it would probably be better to just
list the IDs that the WG thinks it still has responsbility for.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Tue, 22 Oct 2002 09:18:39 -0400

WG members:

We *require* input from WG members regarding the revision of the WG 
charter.  This is *not* a task for just the WG chair and the AD.

Please review the current revised charter at 
http://www.dhcp.org/charter-update.html and contribute to the discussion 
thread.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Oct 2002 16:15:18 -0400

The posted charter has been revised based on Bernie's input...

- Ralph

At 02:37 PM 10/23/2002 -0500, Bernie Volz (EUD) wrote:

>Ralph:
>
>This looks OK!
>
>One minor nit ... "The working group now has four main objectives:",
>actually there are 6 listed. Perhaps best just to change this to:
>"The working group now has the following main objectives:"?
>
>And, in the list of DHCPv6 documents, what about your draft
>draft-droms-dhcpv6-stateless-guide-00.txt?
>
>Do we need to also do a new Goals & Milestones section?
>
>- Bernie
>
>From: Ralph Droms [<mailto:[email-masked]>mailto:[email-masked]]
>Sent: Wednesday, October 23, 2002 2:26 PM
>To: [email-masked]
>Subject: Re: [dhcwg] DHC WG charter
>
>Here's a revised charter, based on input from mailing list discussion (this
>charter also available at 
><http://www.dhcp.org/charter-update.html);>http://www.dhcp.org/charter-update.html); 
>
>comments or acknowledgments (this looks OK) strongly encouraged...
>
>
>The dhc working group (DHCWG) has developed DHCP for automated
>allocation, configuration and management of IP addresses and TCP/IP
>protocol stack parameters. DHCP is currently a "Draft Standard".  The
>base protocol is document in RFC2131 and RFC2132.  Additional options
>are documented in a series of RFCs (see
><http://www.dhcp.org/rfcs.html>http://www.dhcp.org/rfcs.html).  The 
>working group now has four main
>objectives:
>
>* RFC 3118 defines current security mechanisms for DHCPv4.
>    Unfortunately, RFC 3118 has neither been implemented nor deployed to
>    date. There is widespread feeling that its current restriction to
>    manual keying of clients limits its deployability. It is the goal of
>    DHCWG to rectify this situation by defining extensions that have
>    better deployability properties. In order to achive this goal, DHCWG
>    will develop a threat model and analysis of the authentication
>    might include:
>    - Complete or terminate work on published DHCPv6 options:
>        IPv6 Prefix Options for DHCPv6
>          <draft-troan-dhcpv6-opt-prefix-delegation-01.txt>
>        DSTM Options for DHCP
>          <draft-ietf-dhc-dhcpv6-opt-dstm-01.txt>
>        DSTM Ports Option for DHCPv6
>          <draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt>
>        DNS Configuration options for DHCPv6
>          <draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt>
>        Load Balancing for DHCPv6
>          <draft-ietf-dhc-dhcpv6-loadb-02.txt>
>        NIS Configuration Options for DHCPv6
>          <draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt>
>        Time Configuration Options for DHCPv6
>          <draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt>
>        Client Preferred Prefix option for DHCPv6
>          <draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt>
>* Complete or terminate work on DHCP extensions and new options that
>    are currently work in progress:
>    - Failover protocol
>    - DHCP/DDNS interaction
>      <draft-ietf-dhc-fqdn-option-04.txt>
>      <draft-ietf-dhc-ddns-resolution-04.txt>
>    - DHCP Server MIB
>      <draft-ietf-dhc-server-mib-07.txtDHCP MIB>
>    - Host name options (Smith/Lemon?)
>    - DHCP Leasequery
>    - DHCP Option for CableLabs Client Configuration
>      <draft-ietf-dhc-packetcable-03.txt>
>    - KDC Server Address Sub-option
>      <draft-ietf-dhc-suboptions-kdc-serveraddress-00.txt>
>    - DHCP Options for Internet Storage name Service
>      <draft-ietf-dhc-isnsoption-03.txt>
>    - The Authentication Suboption for the DHCP Relay Agent Option
>      <draft-ietf-dhc-auth-suboption-00.txt>
>    - Link Selection sub-option for the Relay Agent Information Option
>      <draft-ietf-dhc-agent-subnet-selection-03.txt>
>    - DHCP VPN Information Option
>    - VPN Identifier sub-option for the Relay Agent Information Option
>    - RADIUS Attributes Sub-option for the DHCP Relay Agent Information 
> Option
>
>* DHCWG is responsible for reviewing (and sometimes developing) DHCP
>    options or other extensions (for both IPv4 and IPv6). DHCWG is
>    expected to review all proposed extensions to DHCP to ensure that
>    they are consistent with the DHCP specification and other option
>    formats, that they do not duplicate existing mechanisms, etc.  DHCWG
>    will not (generally) be responsible for evaluating the semantic
>    content of proposed options. DHCWG will not adopt new proposals for
>    extensions to DHCP as working group documents without first
>    coordinating with other relevant working groups and determining who
>    has the responsibility for reviewing the semantic content of an
>    option.
>
><https://www1.ietf.org/mailman/listinfo/dhcwg>https://www1.ietf.org/mailman/listinfo/dhcwg 
>

---

From: Thomas Narten <[email-masked]>
Date: Thu, 24 Oct 2002 14:34:32 -0400

> The posted charter has been revised based on Bernie's input...

Looks pretty good overall.

But one thing seems odd:

> Complete or terminate work on DHCP ...

And then lists all the relevant WG drafts.

I think everyone will agree that the majority of the listed IDs stay
as WG items. Maybe a small number should be terminated?

We should have the discussion now about which documents are in and
which are no longer needed/appropriate. After all, the (re)chartering
process is about aligning the charter with the work being done.

There may be cases where there is a specific document that we don't
really know today what to do with it, that's OK, so long as it is
clear in the milestone (or charter) that the first order of business
is to figure out what to do with it (i.e., before additional work is
done on it).

But I don't think the charter should leave it so open ended as to
which IDs may or may not be kept.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Thu, 24 Oct 2002 16:24:42 -0400

The idea behind "complete or terminate..." was to be conscious about the 
progress (or lack thereof) on expired documents.  Mostly an explicit and 
visible sanity check with the authors to find out if progress will be made 
in the future (with a pretty low bar on "progress").

There may be some docs that the WG wants to take off the charter (but I 
doubt it).

- Ralph