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

[Kim Kinnear <[e-mail]>]

Ben,

Thanks for the quick response.  I'll do one more reply inside of this
thread, and then we'll see where we are.  It is getting pretty nested.
See below...

On Sep 30, 2015, at 10:56 PM, Ben Campbell <[e-mail]> wrote:

> On 30 Sep 2015, at 16:00, Kim Kinnear wrote:
> 
>> 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 <[e-mail]> wrote:
>> 
>>> 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?
>> 
>> 	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).
> 
> 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?

	Yes, that is the intent.  I just don't think that SHOULD NOT or SHOULD
	will keep someone who thinks that secure mode is the only reasonable
	mode from implementing only it. 

	Would it meet your requirements if I were to say: 

	"A requestor SHOULD be able to operate secure mode."

	This way, we don't discourage someone from implementing just secure mode.
> 
>> 
>>> 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.
> 
> 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_.
> 
>> 
>> 	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.
> 
> 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"

	Thanks for the clarification.  I was not clear -- the
	reasoning for allowing insecure mode is the same as for not
	requiring implementation of secure mode.  I expect that some
	implementations will not wish to implement secure mode at all,
	since all of their deployments will be targeted toward
	environments which are protected by more global protections.

	One use of Active leasequery is an alternative to providing a
	direct connection to the DHCP server's lease state database.
	We want to standardize Active Leasequery in such a way as to
	facilitate that sort of implementation (which makes insecure
	mode appropriate) as well implementations of the more
	distributed sort which require secure mode.

> 
>> 	
>> 
>>> 
>>> Do I understand correctly that insecure mode makes no attempt to
>>> authorize requestors?
>> 
>> 	Correct.
>> 
>>> 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.)
>> 
>> 	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."
> 
> 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.

	Yes, and we had that in this draft too (word for word) and
	were told to remove it since it was too vague (or something
	like that).  I can put it back in if you want, but that always
	feels like I'm not following the rules.

	I don't actually remember who made us take it out.  If this is
	important to you I can go back and figure it out and see where
	they are with this.
> 
>> 
>>> 
>>> 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.
>> 
>> 	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.
> 
> 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?

	That is a result, not an intent.  We either put some level of
	negotiation in, or we don't.  Since we took it all out, we don't
	have any negotiation.  So, the result is that if a client wants
	to connect securely and the server doesn't allow it (either because
	of configuration or implementation) then they won't talk.  Then
	someone will either change the client, or they will talk to the
	folks that control the server and deal with it.
> 
> 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).

	Correct.  They won't talk.  Nothing bad will happen, they just
	won't talk.  This means that a client that thinks the data had
	better be secure won't connect to a server that has been
	configured to not support secure mode.

	The model of use of this protocol, even more so than bulk
	leasequery, is that the people writing Active Leasequery
	requestors are the same people managing the DHCP server.  They
	are writing Active Leasequery clients because they want to get
	at the data in the DHCP server.  There will in general be no
	more than one Active Leasequery requestor for a DHCP server at
	one time.  Sure, you *could* have more, but that isn't the
	design center here.

	I was all for negotiation, but since I took it out, I am
	much more pleased by the result.  The clarity is worth it.

	Bottom line -- since we took out negotiation, you can
	configure things that will not work.  Nothing bad will happen
	if you do, other than them not working, but certainly you can
	configure things that will not work.  I believe that is
	better than the complexity of negotiation, in the very
	small number of edge cases where it will come up.

> 
>> 
>> 	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.
>> 
>> 
>> 
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> I agree with Alissa's discuss questioning why this allows the insecure
>>> mode at all.
> 
> 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 :-)

	As I said in response to Alissa's argument...
> 
>>> 
>>> 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?
>> 
>> 	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.
> 
> Shouldn't the people who think it's important always have the option to configure this?

	while it is easy to say "of course" to that statement, it
	really depends on the value of "this".  For all values of
	"this", no.  For this particular value of "this", I would say
	that the server implementor should have the say as to what
	their server does.  There are things I don't think the server
	implementor should be allowed to decide, in which case I make
	them a MUST.  In this particular case, I believe that the
	actual risks of some data vs other data in a DHCP request is
	not a major issue that has to be mandated by the document.
	You should be able to support this standard without having a
	configuration capability to decide which of the DHCP options
	you will let or not let though an Active Leasequery.

	Not every implementation allows you to configure everything.
	If the server implementor didn't believe this was important,
	then if you *do* think it is important, you should use a
	different server.
> 
> 
>>> 
>>> "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)?
>> 
>> 	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.
> 
> 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.

	Ok, I'll fix this and make only one normative and reference that
	elsewhere.
> 
>> 
>> 	I have explained why not a MUST in the item #1 of the
>> 	previous section.
>>> 
>>> -- 7.1: "If the attempt fails,
>>> the Requestor MAY retry."
>>> 
>>> 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.
> 
> 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.

	I don't expect that the failure are likely to have resulted
	from congestion.  I suspect that they are because the DHCP
	server is not actually running at the moment (e.g., it crashed
	and it is being rebooted, the hardware it was running on died,
	etc.)  For what that is worth.

	Both you and Spencer Dawkins called this one out, and
	I will add: "Retries SHOULD NOT be more frequent than one
	every ACTIVE_LQ_IDLE_TIMEOUT (Section 5.3)."

	That means one retry per minute.  I don't see that stressing
	the network or congesting things.  I don't want limit
	the time on retries, as a DHCP server could be out of service
	for a couple of days (if the hardware dies and it has to be
	rebuilt), and then come back.  In a failover situation,
	that isn't all that uncommon.  I've seen it plenty of times.

> 
>> 
>>> 
>>> -- 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?
>> 
>> 	Same answer as above -- I try to not make requirements on
>> 	administrative interfaces when I don't have to.
> 
> If a requestor allows both, but it's not administratively controlled, how would it work?

	I assumed that you might build a requestor that operated in
	only one mode because that was the only thing you were willing
	to use.  If both are allowed, some control would be required.

	I will remove the statement "This MAY be a feature
	that is administratively controlled." altogether as a way
	of sidestepping specifying this one way or the other.
> 
>>> 
>>> "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?
>> 
>> 	Good point.  I'll change this to "... the requestor sends a
>> 	DHCPACTIVELEASEQUERY request ...".
> 
> Thanks!
> 
>>> 
>>> "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")
>> 
>> 	Yes, I agreed with Alissa to make this "The recommendations in
>> 	[RFC7525] apply."
> 
> Okay
> 
>>> 
>>> "the requestor SHOULD initiate the
>>> exchange of the messages involved in a TLS handshake "
>>> 
>>> Why not MUST? When might it not do so?
>> 
>> 	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.

	Ok, "The requestor initiates ..." it is.
> 
>>> 
> 
>>> "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?
>> 
>> 	The requestor can initiate a new connection in any mode
>> 	it wants to.
> 
> 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.

	An implementation which operates in insecure mode
	is insecure.  Unless it is operating in a secure
	environment.  If it needs to be secure, it should
	not retry 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.
>> 
>> 	I'm sorry, I don't understand.  There is no previous statement
>> 	in this section that discusses the transaction-id, so ...
> 
> Last paragraph of 7.1.

	Sure, I'll remove one of these altogether.  
> 
>>> 
>>> "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)
>> 
>> 	Good point, I'll remove the 2119 keyword.
> 
> Thanks!
> 
>>> 
>>> -- 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.
>> 
>> 	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."
> 
> That works for me.
> 
>>> 
>>> "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?
>> 
>> 	I'll change them to MUSTS.
> 
> Okay
> 
>>> 
>>> -- 7.4.1: "The requester MUST NOT assume that every individual state
>>> change..."
>>> 
>>> 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
> 
> 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.)

	I will make the change that you suggest.
> 
> 
>> 	something.
>>> 
>>> -- 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?
>> 
>> 	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.
> 
> 
> 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.

	For sure, but it is a pain to have to update an existing spec
	just to re-use the message that it defined.

	I'll explain this in the draft and leave it a SHOULD.
> 
>>> 
>>> "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?
>> 
>> 	Good point, I'll change it to a MUST.
> 
> Okay. (or it could say "then it sends a DCHPTLS message...")
> 
>>> 
>>> -- 8.1.1:
>>> 
>>> Why not MUST?
>> 	
>> 	I'll change it to a MUST.
> 
> Okay.
> 
>>> 
>>> -- 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."
>> 
>> 	Yes, thanks, that is exactly what I mean.  I'll change it
>> 	to your sentence, which is much clearer.
> 
> Okay
> 
>>> 
>>> -- 9:
>>> 
>>> 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:
> 
> 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.)

	I now understand your issue with two places in the same draft
	both having normative language.  I'll see what I can do 
	here, recognizing that, as you say, it is below the "comment"
	line.
> 
>> 
>> 
>>> 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.
>> 
>>> 
>>> 
>>> *** 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.
>> 
>> 	Excellent!  I'll swap the paragraphs.
>>> 
>>> -- 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..."
>> 
>> 	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."
> 
> That works for me.
> 
>> 
>> 	Thanks -- Kim
> 
> Thanks for your patience with all of this!
> 
> Ben.