Subject: [dhcwg] IESG Discusses/Comments on draft-ietf-dhc-dhcpv6-subid-00.txt

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 20 Jan 2006 12:13:00 -0500

The following DISCUSSED and COMMENTS were raised during IESG review of
/draft-ietf-dhc-dhcpv6-subid-00.txt (see
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&
ballot_id=1835&filename=draft-ietf-dhc-dhcpv6-remoteid):

DISCUSSES AND COMMENTS:
======================
Brian Carpenter:

Comment [2005-11-29]:
I did wonder whether reference [4] shouldn't be normative.

Ted Hardie:

Comment [2005-11-29]:
I agree with Brian that [4] is probably normative, as it is a normative
reference in RFC3993, which
is noted as a source document in the Acknowledgements.  This seems like
something that can
be fixed in AUTH48, though.

---
MY RESPONSE:

I have no issue in moving this into the normative references (provided
we keep the NVT ASCII format).

---

Allison Mankin:

Comment [2005-12-01]:
No further objection, but I agree with Mark, this one needs highlighted
security
 
comments - not just the usual pointer to the weak security of DHCP.

I think DHCP needs an a document like DNS's RFC 3833, which
might stimulate some action towards work about DHCP spoof prevention
which is not otherwise happening.

---
MY RESPONSE:

See below (Mark's comments).

There was a draft on DHCP security issues that has long since expired.
Perhaps the DHC WG should reactive this draft.

---

Mark Townsley:

Discuss [2005-11-30]:
This is a "subscriber ID" used for roaming between access points,
apparantly
sent in the clear. It seems to me that there should be some mention in
the
security considerations section that if this value is snooped, it could
be used
to aid in hijacking service of the subscriber.

---
MY RESPONSE:

This option is NOT used by clients. It is used between relay agents and
servers only. Thus, there is no issue regarding roaming (unless of
course the relay agents and servers are in different administrative
domains, but in this case there is likely some agreement between these
domains and the relay would likely only forward the information to the
appropriate server(s)).

---

Bert Wijnen:

Discuss [2005-12-01]:
Again I wonder how this document (targeted at standards track)
helps STANDARDIZE anything.

- the semantic information in the subscriber-ID string is vendor
specicic
  (without even a way to indicate which vendor it is coming from)??
- a relay agent MAY insert such a subscriebr-ID
- a server MAY do something or nothing.

And besides that, to make a subscriber-ID NVT ASCII seems very USA
centric

---
MY RESPONSE:

Just as I proposed with draft-ietf-dhc-dhcpv6-remoteid-00.txt, we could
insert the enterprise-id in the option data and thus the semantic
information is enterprise specific. We could also remove the requirement
to make this NVT-ASCII and leave it to the enterprise to define.
However, this requirement was based on the DHCPv4 version (see RFC
3993). Perhaps we change the wording to suggest NVT-ASCII, but leave it
for the enterprise to decide what is best for their needs.

There is no requirement that relay agents insert these options. This is
the whole idea behind options -- they are, in general, OPTIONAL. If a
relay agent is configured to insert this and it has the information to
insert, it will do so. As this option is for use between relay agents
and servers, these are typically in the same administrative domain and
thus to be useful, relay agents and servers that support this must be
purchased if the domain intends to use this capability.

---

- Bernie

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Jan 2006 12:40:05 -0700

> domains and the relay would likely only forward the information to the

Just to be clear, there are two different kinds of DHCPv6 packets - a naked 
packet from a client, and a relay packet from or two a relay agent, which 
encapsulates a naked packet from the client.   This option can only appear in 
the relay agent portion of the packet.   You guys have all read RFC3315, but 
memories fade, so I thought it might be worth pointing this out.

It _is_ possible for a DHCP client to construct a relay packet and send it to 
a relay.  That relay might forward the packet to the server.   Likewise, a 
client can construct a relay packet and send it directly to the server 
(although getting a response back would be problematic).   DHCPv6 allows 
multiple relay encapsulation, so there's no denying that it's possible to 
spoof an ID using the mechanism described here.

In practice, though, there are problems with this.   The likely result of this 
would be an error - the client would not get a valid configuration, and would 
not be able to use the network.   The worst that might happen is that if a 
client successfully perpetrated this attack, another client might experience 
a denial of service because the DHCP server might not be willing to hand out 
additional IP addresses to the same remote ID.

This still wouldn't be a problem if the DHCP server is managing the client's 
address space, because any attempt to exhaust a /48 would simply overwhelm 
the server, which you can do without using the remote ID option.   It would 
be a problem with prefix delegations, though, since presumably the ISP isn't 
going to assign an unlimited number of /48's to every subscriber.

However, protecting the remote ID by making it secret isn't necessary.   The 
DHCPv6 protocol defines a shared secret-based authentication mechanism, and 
furthermore it's possible for the relay agent and server to do IPsec, and to 
use IPsec to prove that the remote ID was inserted by the relay agent, not a 
client.

So I think the fix for this is to mention in the security considerations 
section that DHCPv6 servers and relay agents SHOULD use shared-secret-based 
authentication in cases where this option is used, and that in particular 
DHCPv6 servers SHOULD ignore the contents of this option if these contents 
have not been verified using shared-secret-based authentication or some other 
kind of secure authentication.

This still leaves open a possible hole if the DHCPv6 client sends a 
relay-forward packet to the DHCPv6 relay agent, but the DHCPv6 relay agent 
doesn't insert its own remote ID option.   However, in this case the server 
is not expecting a remote ID option, so I think this is okay.