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

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

Hi, thanks for the response-response :-)

Based on your responses, and on discussion among the IESG on today's 
telechat, I will clear the discuss. Further comments inline. I've 
removed sections that don't seem to need further discussion. Unless I 
missed something, I think you've covered all my concerns.

Thanks!

Ben.

On 1 Oct 2015, at 13:04, Kim Kinnear wrote:

[...]

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

[...]

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

[...]

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

While I certainly would not object to that change, if the original text 
matches the intent, then I am okay with it.


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

[...]

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

Thanks for the explanation. We discussed this on the telechat today, and 
the security ADs are okay without the secure mode being MTI. So I guess 
I am, as well.

[...]

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

If you had a good reason to take it out, then I'm okay with 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.
>>>
>>> 	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.

Okay, thanks for the explanation. I will clear the DISCUSS.

>>>
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------

[...]

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

Okay.

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

Works for me, thanks!

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

I'm okay with that change. But due to other discussion about the two 
modes I'm okay if things stay as they were.

[...]

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

Okay. (I asked the security ADs about this, and they were okay with it.)

[...]

Ben.