Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-v4-threat-analysis-03.txt

From: [email-masked]
Date: Thu, 15 Jun 2006 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis
	Author(s)	: R. Hibbs, et al.
	Filename	: draft-ietf-dhc-v4-threat-analysis-03.txt
	Pages		: 20
	Date		: 2006-6-15
	
DHCPv4 (RFC 2131) is a stable, widely used protocol for 
configuration of host systems in a TCP/IPv4 network.  It did not 
provide for authentication of clients and servers, nor did it 
provide for data confidentiality.  This is reflected in the original 
"Security Considerations" section of RFC 2131, which identifies a 
few threats and leaves development of any defenses against those 
threats to future work.  In about 1995, DHCP security began to 
attract attention from the Internet community, eventually resulting 
in the publication of RFC 3118 in 2001.  Although RFC 3118 was a 
mandatory prerequisite for the DHCPv4 Reconfigure Extension, RFC 
3203, it has had no known usage by any commercial or private 
implementation since its adoption.  The DHC Working Group adopted a 
work item for 2003 to review and modify or replace RFC 3118 to 
afford a workable, easily deployed security mechanism for DHCPv4.  
This memo provides a threat analysis of the Dynamic Host 
Configuration Protocol for Ipv4 (DHCPv4) for use both as RFC 2131 
advances from Draft Standard to Full Standard and to support our 
chartered work improving the acceptance and deployment of RFC 3118.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-v4-threat-analysis-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-v4-threat-analysis-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-v4-threat-analysis-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 16 Jun 2006 09:10:28 -0700

Another DHCP question. Suppose a set of DHCP clients
and relay/servers were connected to a "limited broadcast,
multiple access" link in which a DHCP client's broadcasts
are heard by some nodes on the link but not necessarily
all nodes. In that case, when a client node configures
a link-local address and sends NS(DAD) per (RFC2462,
Section 5.4) the client might fail to detect another
node on the link with a duplicate link-local address.

Is it possible to use DHCP to instate a DHCP-based
link-local DAD policy and procedure on such a link?
What I have in mind is:

  1) Client configures a link-local address and marks
     it as tentative per RFC2462.
  2) (Assuming for now two-message exchange) client sends
     a DHCP SOLICIT to 'All_DHCP_Relay_Agents_and_Servers'
     with source address set to the tentative link-local
     address and the SOLICIT contains an IA Address option
     that also encodes the tentative link-local address.
  3) Server receives the SOLICIT and checks to see if the
     address encoded in the IA option can be assigned to
     the client.
  4) Server sends a REPLY back to the client with a status
     code in the IA Address option telling whether/not the
     tentative addess could be assigned.
  5) If the status code indicates success, the client claims
     the link-local address and assigns it to an interface.
     If the status code indicates failure, the client either
     discards the address and tries again with a different
     tentative link-local or it disables the interface.
  6) If the tentative address was actually a duplicate, the
     server's REPLY message might be sent to the true owner
     of the link-local address instead of the client that
     sent the SOLICIT. But, the true owner would discard the
     REPLY because the DUID and/or Transaction ID would be
     unrecognized. In that case the client that sent the
     SOLICIT would not receive the REPLY and would time out
     and assume the address was a duplicate.

Comments?

Fred
[email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Fri, 16 Jun 2006 14:55:46 -0400

Hi Fred.

> all nodes.

I don't understand what this means.

For one thing, you seem to be talking about IPv6, which has _no_
broadcast, only multicast. And it is the specific link-layer's job to
figure out to make IP multicast "reliable enough" on that link. It is
not DHC or some other higher-layer protocol's job to deal with
this. So in some sense, I think your entire line of questioning is out
of scope.

If in fact, multicast is not nearly reliable enough on a particular LL
(e.g., to have DAD work) that is a problem with the IPoverFoo spec for
that link layer rather than a DHC problem.

Which  LL technology are you talking about, and does an IPoverFoo spec
exist for that LL type? Should there be?

Thomas

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 16 Jun 2006 12:18:13 -0700

Hi Thomas, 

> I don't understand what this means.

We are building something in the NETLMM wg that could be
seen as either a bridged campus LAN or a multilink subnet.
It is not quite decided yet which way it will go yet, but
in the multilink subnet case link-scoped multicast will only
be seen by nodes on the local-link; they will not be seen
by nodes on other links that are joined together by the
multilink subnet.

> broadcast, only multicast.

Yes, IPv6. I only used the term "limited broadcast, multiple
access" for consistency with "non-broadcast, multiple access",
but I am meaning to imply link-scoped multicast for the IPv6
case.

> And it is the specific link-layer's job to
> this.

If we have a multilink subnet, then the links would be
glued together by routers instead of bridges and link-scoped
multicasts would be confined to the node's attached link, i.e.,
they would not span the entire subnet.

> So in some sense, I think your entire line of questioning is out
> of scope.
>

Well, some LLs like IEEE 802.11 don't have very reliable multicast,
and I don't think the IPoverFoo specs could fix that? I'm also
concerned with the MANET case, where we have time-varying links
based on node mobility but that need not be brought into the
scope of this discussion.

> exist for that LL type? Should there be?

We are working on such a spec right now in the NETLMM wg. It
could be seen as an interface spec that provides an overlay
over a (potentially) heterogeneous set of link layers, but
w/o any need for encapsulations. There should be a new version
of the spec announced soon, and it would be good if folks from
this wg could take a look at it. (I'll announce it here when
its ready.)

Thanks - Fred

Thomas

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 16 Jun 2006 13:45:55 -0700

> by nodes on other links that are joined together by the

Is there some reason you've already rejected locating one (or more)
DHCPv6 relay agent(s) upon every 'local-link'?

-- 
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

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 16 Jun 2006 13:51:17 -0700

David, 

> DHCPv6 relay agent(s) upon every 'local-link'?

We're actually depending on locating DHCPv6 relays/servers
on every link. Or, at least, we are depending on locating
one or more nodes that respond to DHCP client messages *as
if* they were DHCPv6 relays/servers on every link.

Thanks - Fred

-- 
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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Jun 2006 11:00:23 -0700

Thomas and others, 

> this wg could take a look at it. (I'll announce it here when

Here is the announcement for the interface spec I was talking
about:

  http://www1.ietf.org/mail-archive/web/netlmm/current/msg00237.html

Again, the spec speaks to joining together multiple links which
could comprise multiple LL technologies. It describes something
that could be seen as a hybrid fusion between a bridged campus
LAN and a multilink subnet.

The spec currently uses NS(DAD) to test for link-local address
uniqueness whereas the alternative I mentioned in the previous
messages was to use DHCP to do the link-local DAD. (Both methods
have their associated tradeoffs in the NETLMM context.) Comments
from this working group, in particular on the DHCP interface,
would be welcome.

Fred

---

From: Thomas Narten <[email-masked]>
Date: Tue, 20 Jun 2006 10:56:07 -0400

>From what I understand, netlmm is not chartered to extend/break the IP
subnet model, and a number of people would have a lot of qualms about
doing so. So I doubt seriously that netlmm is going to adopt multilink
subnets.

Presumably you are aware of
draft-thaler-intarea-multilink-subnet-issues-00.txt.

I think it is extremely premature to be coming to DHC with this sort
of problem, since I don't think netlmm should be going in such a
direction, precisely because netlmm would be _creating_ problems that
other protocols are then forced to deal with. This is not a DHC
problem and shouldn't be made into a DHC problem.

> and I don't think the IPoverFoo specs could fix that?

Yes they could, if they thought that multicast was too broken to use
for ND and other protocols. They could add a layer (e.g.,
retransmissions) to increase the reliability of multicast.

Thomas

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Jun 2006 08:29:04 -0700

Thomas, 

> draft-thaler-intarea-multilink-subnet-issues-00.txt.

Right; I know about that one, and I am not pushing for multilink
subnets. I also know about Dave's draft on Multi-subnet MANETs
(draft-thaler-autoconf-multisubnet-manets-00.txt) and that is
a model the NETLMM could easily adopt without running afoul of
multilink subnet issues.

> problem and shouldn't be made into a DHC problem.

I'm just asking about whether DHCP can be used to do DAD
for link-locals (i.e., instead of RFC2462 DAD). That
discussion doesn't need to bleed over into NETLMM,
multilink subnets, etc.

> retransmissions) to increase the reliability of multicast.

But take IEEE 802.11 for instance. It has CSMA with collision
*avoidance*; not collision *detection*. So the sender doesn't
get any indication of multicast delivery failure and has no
way of knowing that a retransmission is needed.

Fred

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Mon, 26 Jun 2006 06:51:48 -0400

Thomas - seems to me you're arguing that "reliable enough" multicast is a
fundamental requirement for IPv6 to be carried over any link layer
technology.  What is the definition of "reliable enough", where is it
defined?  Where is the list of requirements for "IPv6 over foo"?

- Ralph