Subject: [dhcwg] Ben Campbell's Discuss on draft-ietf-dhc-dhcpv4-active-leasequery-06: (with DISCUSS and COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 29 Sep 2015 20:52:28 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-dhc-dhcpv4-active-leasequery-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-active-leasequery/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Do you really want to discourage implementations that only support secure
mode? Is there a reason not to make secure mode MTI?

Do I understand correctly that insecure mode makes no attempt to
authorize requestors? If so, that should probably be mentioned in the
security considerations. (I note that 6926 had some words about access
control in the security considerations, but if this draft has the
equivalent, I missed it.)

The fact that insecure mode at the server does not allow a requester to
upgrade to secure mode seems brittle.  That is, it's easy to configure
things where the server and requester simply cannot talk.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Alissa's discuss questioning why this allows the insecure
mode at all.

The draft could use a general pass to clean up the use of 2119 keywords.
There are a lot of redundant normative statements between sections, and
within sections. There are  2119 keywords in places that really don't
need them--you don't need a MUST or a SHOULD to just describe the basic
workings of a protocol. They should be saved for places where an
implementer has a decision to make, or is likely to do the wrong thing.
I've captured some examples, but I know I didn't get them all.

-- 3: "server SHOULD provide a mechanism to control which data is
allowed"

Why not MUST?

  "with the exception that
   a server responding to an Active Leasequery request SHOULD be able to
   be configured to prevent specific data items from being included in
   the response to the requestor even if they were requested by
   inclusion in the dhcp-parameter-request-list option."

Redundant with previous. (Also, why not MUST)?

-- 7.1: "If the attempt fails,
   the Requestor MAY retry."

How many times? How often?

-- 7.2:  "A requestor SHOULD be able to operate in either insecure or
secure
   mode.  This MAY be a feature that is administratively controlled."

Why only MAY?

  "When operating in insecure mode, the requestor SHOULD proceed to send
   a DHCPACTIVELEASEQUERY request after the establishment of a TCP
   connection."

Why not MUST? Or more to the point, why does this need a 2119
keyword--it's simply how the protocol works?

  "The recommendations in [RFC7525] SHOULD be followed when negotiating
   this connection."

Why not MUST? (Or as Alissa commented, why not "The recommendations in
[RFC7525] apply")

  "the requestor SHOULD initiate the
   exchange of the messages involved in a TLS handshake "

Why not MUST? When might it not do so?

  "If the handshake exchange does not yield a functioning TLS
   connection, then the requester MUST close the TCP connection."

Is the requester allows to attempt a new connection in insecure mode?

-- 7.3: "The DHCPv4 request MUST have an
   xid (transaction-id) unique on the connection on which it is sent."

Redundant with previous statement.

  "the requester SHOULD place this
   highest base-time value into a query-start-time option"

Why does this need to be a 2119 keyword? It seems like the requester can
do this if it cares about catch-up data, otherwise skip it. (as indicated
by the next paragraph)

-- 7.4: "
  "Note that a DHCPACTIVELEASEQUERY request specifically requests the
   DHCPv4 server to create a long-lived connection "

I thought the Requester created the connections.

  "This SHOULD
   be the last message on that connection, and once the message has been
   transmitted, the server SHOULD close the connection."

Why are the SHOULDs not MUSTs? When might one send additional messages,
or not close the connection?

-- 7.4.1: "The requester MUST NOT assume that every individual state
change..."

Redundant with previous statement.

-- 8.1:

   "Any options appearing in a DHCPTLS message received by a DHCPv4
   server SHOULD be ignored."

Why not MUST? When might a server chose not to ignore them?

  "If for some reason the DHCPv4 server cannot or has been configured to
   not support a TLS connection, then it SHOULD send a DHCPTLS message
   with a dhcp-status-code of TLSConnectionRefused back to the
   requestor."

Why not MUST? When might it do something different?

-- 8.1.1:

Why not MUST?

-- 8.4:

  "The server MAY close its end of the TCP connection after sending its
   last message, a DHCPLEASEQUERYSTATUS message in response to a query."

This seems to contradict previous normative statements. But I suspect you
mean something to the effect of "The server MAY end communication by
sending a DHCPLEASEQUERYSTATUS and them immediately closing the TCP
connection."

-- 9:

The section seems to have a lot of redundant 2119 keywords.

*** Editorial: 

-- 7.3:, paragraph starting with "Note that until all the recent
data..."

This paragraph would make more sense after the explanation of base-time
in the following paragraph.

-- 8.2:

  "The DHCPv4 server SHOULD, but is not required to, keep track of a
   limited amount of previous binding activity"

I suggest " ... limit the amount of previous binding activity it keeps
track of..."

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 30 Sep 2015 17:00:18 -0400

Ben,

Thank you for your review.  I will respond to the specific issues
you raise below.

On Sep 29, 2015, at 11:52 PM, Ben Campbell <[email-masked]> wrote:

> mode?

	There are installations who would prefer to operate in
	insecure mode for operational reasons.  That said, we do allow
	implementation of secure only mode. 

	I don't think that "SHOULD be able to operate in either
	insecure or secure mode" is all that discouraging to an
	implementor who feels that secure mode is the only thing that
	their users want (or should want).

> Is there a reason not to make secure mode MTI?

	As I just said in response to Alissa Cooper:

	The basic reason for two modes of operation (insecure and
	secure mode) is because there are essentially two models of
	use for this protocol.  In one model, the requestor of an
	active leasequery is connected to the internet in an arbitrary
	location, and the information transmitted needs to be
	protected during transmission.  In addition, the identity of
	both requestor and server need to be verified.  For this model
	of use, the secure mode is appropriate.

	The other model of use is where the requestor of the active
	leasequery resides in a network element that is essentially
	"next to" the element containing the DHCP server, and both of
	these elements are inside a protected environment.  In this
	case, the insecure mode is sufficient since there are other,
	more global, protections in place to protect this information.

	Note that in discussions of the DHCPv6 Active Leasequery draft
	with Stephen Farrell, we have changed both this draft and the
	DHCPv6 version to require *two* explicit choices in
	configuration to use the insecure mode.  So nobody should be
	able to deploy a DHCP server and through ignorance or
	inattention allow someone to perform an insecure active
	leasequery.

	Kathleen Moriarty attached a comment to her ballot explaining
	why she didn't have an issue with this, and I agree
	wholeheartedly with her analysis.	

> authorize requestors?

	Correct.

> If so, that should probably be mentioned in the

	I will add this sentence to the Security Considerations
	section:

	"Operating in insecure mode (see Section 8.1) does not
	provide any way to validate the authorization of requestors
	of a DHCPV4 Active Leasequery request."

> things where the server and requester simply cannot talk.

	I don't disagree, and initially I had a negotiation approach
	written into the protocol.  In the Int-dir review of the
	DHCPv6 Active Leasequery draft (which is essentially identical
	in all respects to this draft) which was done in May 2015, Ted
	Lemon had me remove all of that and make it so that
	configuration on the server governed, period.  The theory was
	that, if the server could be contacted from insecure places
	(or if the data on the server was considered sufficiently
	confidential), that it would require secure access.  End of
	story.  The server knows what sort of data it has and
	(presumably, though less clearly) knows who can contact it.

	I will say that the current approach is *much* clearer than
	what went before, and while you can certainly configure things
	to not be able to talk, in practice I don't see that as a
	major problem.

	Bottom line:  I think we need to leave this one the way it is.

	Two reasons:

	1. I generally try to not create requirements as to how the
	administrative interface for a protocol works.  I think that
	my responsibility is to what is on the wire, and I try to give
	guidance on administrative controls but not requirements.  In
	some cases, (e.g. the configuration of insecure mode), I have
	made requirements in the draft, but for anything less
	important, I resist the temptation to tell people how to build
	their admin interfaces.

	2. There are legitimate differences as to how important
	controlling the information in an Active Leasequery response
	is.  We could discuss this at length (and we can if you
	desire), but for now I would just say that some people think
	this is really important, and some people see it as less
	important.
> Redundant with previous. (Also, why not MUST)?

	Both of these statements come after a reference to RFC 6926,
	and are explaining why you don't do it *exactly* like RFC
	6926.  As such, I don't see them as redundant.  In addition,
	they were put in due to Stephen Farrell's review of the DHCPv6
	Active Leasequery draft, and I wanted to make sure that I
	handled his issue in a way that nobody could miss it.

	I have explained why not a MUST in the item #1 of the
	previous section.
> How many times? How often? 

	In some protocols, the details of retry times and counts are 
	specified in depth.  I don't see this protocol as one of those
	that requires an in-depth specification of these values.  I expect
	that someone implementing a requestor will do something reasonable
	here.  If they don't, it won't work as well as if they did.

	I can take out this entire sentence if you think it would be better.

>   mode.  This MAY be a feature that is administratively controlled."

	Same answer as above -- I try to not make requirements on 
	administrative interfaces when I don't have to.
> keyword--it's simply how the protocol works?

	Good point.  I'll change this to "... the requestor sends a
	DHCPACTIVELEASEQUERY request ...".
> Why not MUST? (Or as Alissa commented, why not "The recommendations in

	Yes, I agreed with Alissa to make this "The recommendations in
	[RFC7525] apply."
> Why not MUST? When might it not do so?

	Good point, MUST makes more sense, I'll change it to MUST.
> Is the requester allows to attempt a new connection in insecure mode?

	The requestor can initiate a new connection in any mode
	it wants to.  
> Redundant with previous statement.

	I'm sorry, I don't understand.  There is no previous statement
	in this section that discusses the transaction-id, so ...
> do this if it cares about catch-up data, otherwise skip it. (as indicated

	Good point, I'll remove the 2119 keyword.
> I thought the Requester created the connections.

	Yes, you are correct.  This sentence is really designed to 
	tell people that the connection could be staying up for a good
	long time.  I'll change it to:

	"Note that the connection resulting from accepting a
	DHCPACTIVELEASEQUERY request may be long-lived, and may
	not have data transferring continuously during its lifetime."
> or not close the connection?

	I'll change them to MUSTS.
> Redundant with previous statement.

	I don't see this as redundant.  There is a similar statement
	in Section 6, but I think both are important to communicate 
	this rather critical piece of information.  But the implication
	of your statement is that this is redundant with something just
	immediately previous, and I don't see that, so I must be missing
	something.
> Why not MUST? When might a server chose not to ignore them?

	An interesting question.  I put this in due to a review on the
	DHCPv6 Active Leasequery draft, and the SHOULD instead of the
	MUST is just to allow someone to include some options someday
	in a DHCPTLS message (perhaps in support of some other protocol),
	and not have to "update" this draft where the DHCPTLS message
	is defined.

	If you feel strongly that this must be a MUST, I will change it.
> Why not MUST? When might it do something different?

	Good point, I'll change it to a MUST.
> Why not MUST?
	
	I'll change it to a MUST.
> sending a DHCPLEASEQUERYSTATUS and them immediately closing the TCP

	Yes, thanks, that is exactly what I mean.  I'll change it
	to your sentence, which is much clearer.
> The section seems to have a lot of redundant 2119 keywords.

	Well, lets get specific.  Here is the part of Section 9
	with 2119 keywords, and my response to each:

>    When operating in secure mode, TLS [RFC5246] is used to secure the
>    connection.  The recommendations in [RFC7525] SHOULD be followed when
>    negotiating a TLS connection.

	We've already agreed that this will get redone as per Alissa
	Cooper's comment.
> 
>    Servers SHOULD offer configuration parameters to limit the sources of
>    incoming connections through validation and use of the digital
>    certificates presented to create a TLS connection.  They SHOULD also
>    limit the number of accepted connections, and limit the period of
>    time during which an idle connection will be left open.

	The first sentence is offering a suggestion as to how to create
	an administrative interface.  We have already discussed how to
	do the actual connections, but not that you should be able to 
	configure anything about them.  So I think this is still valid.
> 
>    The data acquired by using an Active Leasequery is subject to the
>    same potential abuse as the data held by the DHCPv4 server from which
>    it was acquired, and SHOULD be secured by mechanisms as strong as
>    those used for the data held by that DHCPv4 server.  The data
>    acquired by using an Active Leasequery SHOULD be deleted as soon as
>    possible after the use for which it was acquired has passed.

	This is the first time we have said this, and I think the
	SHOULD's are useful here.  In actuality, there isn't much more
	strength in a MUST here, as we are really only trying to wake
	people up to the fact that this stuff is valuable data.

> 
>    Servers which implement the Bulk Leasequery protocol [RFC6926] but do
>    not implement the Active Leasequery protocol SHOULD implement the
>    update to [RFC6926] discussed in Section 8.1.1.

	Yes, we said this before.  Is this really a problem?  I could 
	take it out, I suppose.  

> in the following paragraph.

	Excellent!  I'll swap the paragraphs.
> I suggest " ... limit the amount of previous binding activity it keeps

	Okay.  I'll change it to:

	"The DHCPv4 server SHOULD keep track of previous binding activity.
	It SHOULD limit the amount of previous binding activity it keeps
	track of."

	Thanks -- Kim

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

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 30 Sep 2015 21:56:14 -0500

On 30 Sep 2015, at 16:00, Kim Kinnear wrote:

>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html

I interpreted SHOULD be able to operate in either mode to mean the same 
as SHOULD NOT be limited to just one mode. Is that not the intent?

> 	more global, protections in place to protect this information.

To be clear, I think Alissa asked why not just require secure mode all 
the time.  My question was different--I asked why not make it mandatory 
to _implement_.

> 	wholeheartedly with her analysis.

IIUC, Kathleen's comments were about why it's okay to allow the insecure 
mode. Again, that's different from my question about making secure mode 
mandatory to implement (MTI). (not to be confused with mandatory to 
_use_).

To clarify, when I talk about MTI, I mean something to the effect of 
saying implementations "MUST implement the secure mode, and SHOULD [or 
MAY] implement the insecure mode"

> 	of a DHCPV4 Active Leasequery request."

That helps, although I think the bigger issue is that even if the 
intended client sits on the same network, insecure mode doesn't prevent 
unauthorized clients _not_ on that network from connecting. I noticed 
that the bulk query draft had some language around using external 
network devices to control access.

> 	(presumably, though less clearly) knows who can contact it.

That seems to be an argument to allow the server to require secure 
access. I'm fine with that. But the draft also allows the server to 
forbid secure access, even if a client wants to connect securely. Is 
that the intent?

Also, you mention this should be controlled entirely by the server. But 
it's not, since you also allow the client to be configured for secure or 
insecure access. If I understand correctly, that means a client 
configured for secure access cannot talk to a server configured for 
insecure access.  (Note that I'm perfectly happy to say a client 
configured for insecure access cannot talk to a server configured for 
secure).

> 	Bottom line:  I think we need to leave this one the way it is.

You skipped this one--so let me point out it would be a good place to 
make the "As you said in response to Alissa" argument :-)

> 	this is really important, and some people see it as less

Shouldn't the people who think it's important always have the option to 
configure this?

> 	handled his issue in a way that nobody could miss it.

This is a non-blocking comment, but in my experience making the same 
normative statement more than once is error prone. It creates questions 
about which instance is authoritative in the case of a conflict. Even if 
there's no conflict _now_, a spec evolves over time with updates and 
errata. If the people making those updates have to track down several 
instances of the same requirement, they tend to get it wrong.

> 	I can take out this entire sentence if you think it would be better.

My concern is that such failures are likely to have resulted from 
congestion, and lots of retries will increase that congestion. OTOH, if 
it resulted from something other than congestion, then there's a high 
chance the retry will also fail. So my personal (again, non-blocking) 
preference would be to puts some limits on retries, even if they are 
fuzzy limits. The main point is to discourage implementations from 
retrying forever.

> 	administrative interfaces when I don't have to.

If a requestor allows both, but it's not administratively controlled, 
how would it work?

> 	DHCPACTIVELEASEQUERY request ...".

Thanks!

> 	Yes, I agreed with Alissa to make this "The recommendations in

Okay

> 	Good point, MUST makes more sense, I'll change it to MUST.

That's better, although I think saying "The requester initiates..." 
would be even better.

> 	The requestor can initiate a new connection in any mode

It seems like an implementation that tries secure mode but falls back to 
insecure mode if secure mode fails is vulnerable to bid-down attacks.

> 	in this section that discusses the transaction-id, so ...

Last paragraph of 7.1.

> 	Good point, I'll remove the 2119 keyword.

Thanks!

> 	not have data transferring continuously during its lifetime."

That works for me.

> 	I'll change them to MUSTS.

Okay

> 	immediately previous, and I don't see that, so I must be missing

I was referring to section 6. (It's previous, just not immediately 
previous).

See my previous comment about repeating normative statements. If you 
want to reinforce an idea, it's perfectly fine to have one of the 
instances restate the requirement descriptively, or to attribute it to 
the authoritative statement.

For example (assuming 7.4.1 is the authoritative version), 6 could say 
"The requestor cannot assume it gets every single state change", or it 
could say, "As specified in section 7.1.4, the requester MUST NOT 
assume...

(Again, this is a non-blocking comment, and I understand it may not be 
worth changing this sort of thing this late in the process.)

> 	If you feel strongly that this must be a MUST, I will change it.

My preference would be to either make it a MUST, or add a sentence 
explaining why it's not a MUST, to the effect of what you just said.  If 
you choose the MUST option, future specs can still modify it by updating 
the MUST.

> 	Good point, I'll change it to a MUST.

Okay. (or it could say "then it sends a DCHPTLS message...")

> 	I'll change it to a MUST.

Okay.

> 	to your sentence, which is much clearer.

Okay

> 	with 2119 keywords, and my response to each:

I appreciate the specifics--but in the interest of time I will just 
point out my previous comments about redundant normative language. (And 
also the fact that everything below the "comment" line is non-blocking.)

> 	It SHOULD limit the amount of previous binding activity it keeps

That works for me.

> 	Thanks -- Kim

Thanks for your patience with all of this!

Ben.