Skip to main content

Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option
draft-ietf-dhc-dhcpv6-subid-01

Yes

(Margaret Cullen)

No Objection

(Bert Wijnen)
(Bill Fenner)
(Jon Peterson)
(Russ Housley)
(Sam Hartman)
(Scott Hollenbeck)

Note: This ballot was opened for revision 01 and is now closed.

Margaret Cullen Former IESG member
Yes
Yes () Unknown

                            
Allison Mankin Former IESG member
No Objection
No Objection (2005-12-01) Unknown
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.
Bert Wijnen Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
No Objection
No Objection (2005-11-29) Unknown
I did wonder whether reference [4] shouldn't be normative.
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
(was Discuss) No Objection
No Objection (2006-01-26) Unknown
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.
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sam Hartman Former IESG member
No Objection
No Objection () Unknown

                            
Scott Hollenbeck Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection (2005-11-29) Unknown
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.