Skip to main content

DHCPv6 Active Leasequery
draft-ietf-dhc-dhcpv6-active-leasequery-04

Yes

(Brian Haberman)

No Objection

(Alia Atlas)
(Alvaro Retana)
(Barry Leiba)
(Deborah Brungard)
(Martin Stiemerling)
(Spencer Dawkins)
(Terry Manderson)

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

Brian Haberman Former IESG member
Yes
Yes (for -03) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2015-07-08 for -03) Unknown
I support Stephen's DISCUSS. I was wondering about the use cases as well.
Alvaro Retana Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2015-07-07 for -03) Unknown
-- general:
I understand this to be a way for a third party to "actively" monitor client DHCPv6 bindings.  Does that warrant some privacy considerations?

-- section 8.2:
The selection of secure vs insecure mode MAY be administratively selectable. It seems like there should a stronger requirement for an administrative option to force secure mode.
Benoît Claise Former IESG member
No Objection
No Objection (2015-07-06 for -03) Unknown
No objection, but if taken into account, Scott's OPS DIR feedback would improve the document.

=================================
Scott,

We totally agree that this protocol should be able to restrict who
gets the information about what is going on with the DHCP server.

We *thought* that we had that covered...

The current draft has TLS connections as a SHOULD, and includes the
following text at the end of section 9.1:

>    In the event that the DHCPv6 server sends a REPLY message without
>    DHCPv6 status code option included (which indicates success), the
>    requestor is supposed to initiate a TLS handshake [RFC5246] (see
>    Section 8.2).  During the TLS handshake, the DHCPv6 server MUST
>    verify the requestor's digital certificate.
>    If the TLS handshake is not successful in creating a TLS connection,
>    the server MUST drop the TCP connection.


The intent here is that in requiring the verification of the
requestor's digital certificate that the server would also be able to
restrict connections to requestors that it considered acceptable.

We recently took a lot of words out of the security considerations
section on restricting connections to acceptable requestors because
that would have required using IP addresses, which everyone thought
was useless.

We didn't put more words back in about the TLS certificates, but
perhaps we should have?

Anyway, there are several issues:

  1. Does the verification of the TLS certificates allow the server to
  be able to determine that a requestor is or is not allowed to access
  the active leasequery capability?

  2. We believe that there is more than one way to utilize
  certificates to decide if a requestor is allowed.   We also sort of
  assumed that was documented elsewhere and wasn't something that we
  needed to detail in this draft.  Do you know of a draft we could
  reference on how to do that, or failing that, know of text we could
  incorporate that explains how to do that.

If #1 is no, then we are confused because we thought that was the
point of verifying the digital certificates (instead of just using
the certificate to ensure that the link is encrypted).

===============================
Scott's answer:
it is always useful to spell out what is on your mind

if you are projecting that the use of certs equals access control you should just say that 

a few extra words would dog a LONG way

Scott
Deborah Brungard Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2015-07-08 for -03) Unknown
I believe the questions from Francis Dupon wrt TLS usage and full specification deserve at least an answer, if not even a clarification in the document. Please take a look!
Joel Jaeggli Former IESG member
No Objection
No Objection (2015-07-07 for -03) Unknown
I think opsdir feedback has been heard.
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-07-08 for -03) Unknown
I also support Stephen's discuss points.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2015-07-31) Unknown
Thanks for the various changes to improve the security and
privacy bits of this spec.
Terry Manderson Former IESG member
No Objection
No Objection (for -03) Unknown