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

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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg