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

["Ben Campbell" <[e-mail]>]

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?

>
>> 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"

> 	
>
>>
>> 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.

>
>>
>> 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?

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).

>
> 	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 :-)

>>
>> 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?


>>
>> "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.

>
> 	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.

>
>>
>> -- 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?

>>
>> "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.

>>

>> "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.

>>
>> -- 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.

>>
>> "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.)


> 	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.

>>
>> "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.)

>
>
>>  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.