Re: [Int-dir] INT directorate review of draft-ietf-dhc-dhcpv6-active-leasequery

[Kim Kinnear <[e-mail]>]

Brian, Ted,

We have published new versions of both of the DHCPv6 Active Leasequery
draft as well as the DHCPv4 Active Leasequery draft (since they are
essentially identical in all but the specifics of the v4/v6 data).

https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-active-leasequery/

https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-active-leasequery/

I believe that we have covered all of the issues raised by Ted.

After submission, I did notice two things that we need to change:

  1. Both drafts have a sentence: "Alternatively, both requests could
  be issued over a single connection." which we didn't catch when we
  removed the capability to handle multiple simultaneous requests on a
  single connection.  This sentence will have to be removed.

  2. The DHCPv4 draft still has a sentence stating that the requestor
  can choose insecure or secure mode: "Alternatively, the server MAY
  allow the client to select the mode through transmission of a
  DHCPTLS to select the secure mode or transmission of an Active
  Leasequery request to select the insecure mode."  This sentence
  also needs to be removed.  Both drafts force the server to decide
  whether or not TLS is required.

While we could republish both drafts immediately, it seemed prudent to
let Ted review the changes to see if we have successfully responded to
his concerns.  We will certainly have to republish both drafts, if only
to fix these problems.

One more question.  Ted said (and we are fine with this):

> I think the most useful mode of operation here is the one you are leaving out. Nobody wants to pay a CA to sign certs for all their infrastructure servers, but having a local CA and just installing the local CA as a trusted root would work fine for this application; indeed you probably don't want to configure leasequery partners to accept the standard set of CA roots. 

We have put words in the draft(s) about certificates (here is one example):

> During the TLS handshake, the requestor MUST verify the DHCPv4
> server's digital certificates.

Ted, do you feel that we need to be more explicit regarding the
approach that you advocated regarding certificates, above, to allow
that as a reasonable option?  If so, any suggestions for the words
that we might use?  Thanks!

I have included the DHCWG mailing list on this email to ensure that the
progress these documents are making continues to be visible to the entire
DHC WG.  

Regards -- Kim


On May 28, 2015, at 1:52 PM, Kim Kinnear <[e-mail]> wrote:

> 
> Brian, Ted,
> 
> Here are our comments regarding Ted's review, inline below...
> 
> I believe that we need a new revision of the draft to include these
> changes (and the corresponding DHCPv4 draft, which has almost the same
> words in the same places).
> 
> That said, I don't believe that any of this requires a new WGLC, as we
> aren't really changing the intent of what we were trying to say in any
> really significant way.
> 
> The only substantive change is removing the multiple messages per
> connection, which *is* a change, but isn't a big deal in my view.  I
> say this in part because nobody had any comments about that as we were
> working this with the DHC WG.  I think the only person who cared was
> Bernie, and I've already checked with him and he's ok with it.
> 
> But that's just my opinion...
> 
> Regards -- Kim
> 
> 
> On May 26, 2015, at 3:23 PM, Brian Haberman <[e-mail]> wrote:
> 
>> Ted,
>>   Thanks for the review!
>> 
>> Authors,
>>    I would like you to respond to these so that we can determine the
>> best way forward.
>> 
>> Regards,
>> Brian
>> 
>> 
>> On 5/20/15 3:50 PM, Ted Lemon wrote:
>>> I am an assigned INT directorate reviewer for
>>> draft-ietf-dhc-dhcpv6-active-leasequery-02.txt.  These comments were
>>> written primarily for the benefit of the Internet Area Directors.
>>> Document editors and shepherd(s) should treat these comments just as
>>> they would treat comments from any other IETF contributors and
>>> resolve them along with any other Last Call comments that have been
>>> received.   For more details on the INT Directorate, see:
>>> http://www.ietf.org/iesg/directorate.html
>>> 
>>> Major issues:
>>> 
>>> The specification of TLS negotiation in section 8.2 allows for an
>>> MiTM attack: the man in the middle simply has to respond negatively
>>> to the STARTTLS message, and the communication will occur in the
>>> clear.  
> 
> 	This was not what we were trying to say in the document.
> 
> 	Ultimately, we expect that either the client or the server can
> 	be configured in one of three distinct ways regarding TLS:
> 
> 	  1. Require TLS for all communication with the partner.
> 
> 	  2. Support TLS if requested to do so by the partner, but allow
> 	  communications in the clear if TLS is not requested by the
> 	  partner.
> 
> 	  3. Not support TLS at all.  If the partner requires TLS, it
> 	  won't be communicating with us.  Period.
> 
> 	The intent in section 8.2 for the client is that if the DHCP
> 	server doesn't want to support TLS for this connection, then
> 	the client will respond based on how it is configured.  If it
> 	is configured as in #1, above, then it will not communicate
> 	with this server.  If it is configured as in #2 then it will
> 	continue with communications in the clear.  If the client was
> 	configured as in #3, it would not have sent the STARTTLS
> 	message.
> 
> 	We will add words in section 8.2 to make that clearer.
> 
>>> This could be addressed by requiring that if the DHCP server
>>> is configured to use TLS, it will not allow a connection to proceed
>>> without successfully completing the TLS handshake.
> 
> 	That is what we were trying to say, though we have a slightly
> 	nuanced interpretation of "use TLS".  Again, referring to the
> 	three configuration possibilities regarding TLS above:
> 
> 	  1. Require TLS for all communication with the partner.
> 
> 	  2. Support TLS if requested to do so by the partner, but allow
> 	  communications in the clear if TLS is not requested by the
> 	  partner.
> 
> 	  3. Not support TLS at all.  If the partner requires TLS, it
> 	  won't be communicating with us.  Period.
> 
> 	If the server is configured as in #1, the server will do
> 	exactly what Ted is requesting: the server will not allow the
> 	connection to proceed without completing the TLS handshake.
> 
>>>  In this case, an
>>> MiTM attack would simply prevent the connection from completing.   I
>>> guess this change would actually be made in section 9.1: if the
>>> requestor doesn't request TLS, and the server is configured to
>>> require it, then it will drop the connection.
> 
> 	Yes, we will put some words in section 9.1 to make these
> 	three possibilities (and their implications) hopefully
> 	much clearer.
>>> 
>>> I don't think support for STARTTLS should be optional, hence handling
>>> cases where it is not supported should be unnecessary.
> 
> 	We never intended that the STARTTLS message support itself
> 	was to be optional, but I can see where it might look like
> 	it was.  We will fix that.
>>> 
>>> Section 8.2 and 9.1 also do not talk about TLS cert validation, so it
>>> amounts to opportunistic encryption, and is still subject to MiTM
>>> attacks since the attacker can simply use a different key than the
>>> DHCP server.   To enable TLS support to actually provide security, it
>>> would be necessary for the requestor to use a client cert that the
>>> server validates, and for the server to use a cert that the requestor
>>> validates.   If the requestor's cert doesn't validate, the connection
>>> is dropped; if the server's cert doesn't validate, the requestor
>>> drops the connection.
> 
> 	Yes, and we left implicit our intent here, which was probably
> 	a mistake. 
> 
> 	We expect that a client or a server can be configured (or
> 	implemented directly) in one of two modes regarding TLS
> 	connections:
> 
> 	  a) Require TLS certificate validation (ensuring that you
> 	  are talking to the partner to whom you believe you are
> 	  talking to).
> 
> 	  b) Do not require TLS certificate validation (ensuring only
> 	  that your conversation cannot be eavesdropped on, but not
> 	  ensuring that you are talking to the correct partner).
> 
> 	We will make explicit these two possibilities, and describe
> 	the downsides of (b).  
> 
>>> 
>>> In section 8.4, if the connection is terminated while an active
>>> leasequery is in the catch-up state, I don't think the current
>>> recommendation for sending OPTION_LQ_BASE_TIME is adequate.   In this
>>> case the requestor will likely have to retry from the same starting
>>> time it had used previously.
> 
> 	Yes, we completely agree! I'm delighted that you got it!
> 
> 	Unfortunately, We think we said this explicitly at least
> 	three times, including:
>> 
>>   Prior to the completion of the
>>   catch-up phase, if the connection should go away or if the requestor
>>   receives a LEASEQUERY-DONE message, then when it reconnects it MUST
>>   use the base-time value from the previous connection and not any
>>   base-time value received from the recently closed connection.
> 
> 	and:
> 
>>   Therefore, until
>>   the catch-up phase is complete, the latest base-time value received
>>   from a DHCPv6 server processing an Active Leasequery request cannot
>>   be reset from the incoming messages (and used in a subsequent Active
>>   Leasequery's query-start-time option), because to do so would
>>   compromise the ability to recover lost information if the Active
>>   Leasequery were to terminate prior to the completion of the catch-up
>>   phase.
> 
> 	and:
> 
>>   The updates sent by the DHCPv6 server during the catch-up phase are
>>   not in the order that the lease state data was updated.  Therefore,
>>   the OPTION_LQ_BASE_TIME option from messages during this phase MUST
>>   NOT be saved and used to compute the subsequent ACTIVELEASEQUERY
>>   message's OPTION_LQ_START_TIME option.
> 
> 
> 	so ... either I don't understand your concern, or we are 
> 	really not able to communicate this information in a way
> 	that makes any sense.
> 
>>> 
>>> Minor issues:
>>> 
>>> Section 2, definition for "Absolute Time", is the 32-bit quantity
>>> signed or unsigned?
> 	
> 	Good catch, unsigned is the DHCPv6 approach, which is from 
> 	RFC 3315:
> 
>> 	The time value is the time that the DUID is
>>   	generated represented in seconds since midnight (UTC), January 1,
>>   	2000, modulo 2^32.
> 
> 
>>> Definition for "binding change/update", aren't "DHCPv6 binding state"
>>> and "data stored on the DHCPv6 server related to binding" synonyms?
>>> If so, perhaps what you really need here is an additional definition
>>> for "DHCPv6 binding state" which is "data stored on the DHCPv6 server
>>> relating to binding."   I don't think this is a big deal, but might
>>> be a nice edit for clarity.
> 
> 	Sure, no problem.
>>> 
>>> Similarly, why not split "catch-up information" and "catch-up phase"
>>> into two separate definitions?
> 
> 	Ok, sure.
>>> 
>>> Last paragraph of section 3 says "The messages sent by the server in
>>> response to an Active Leasequery request SHOULD be identical to the
>>> messages sent by the server to a Bulk Leasequery request regarding
>>> the way the data is encoded into the Active Leasequery responses.  In
>>> addition, the actions taken by the Active Leasequery requestor to
>>> interpret the responses to an Active Leasequery request SHOULD be
>>> identical to the way that the requestor interprets the responses to a
>>> Bulk Leasequery request."   What is the purpose of the normative
>>> SHOULDs here?   Are there exceptional cases where this normative
>>> advice would not be followed?   Is this text really intended to be
>>> normative?
> 
> 	Somehow I'm always kind of iffy when it comes to the
> 	difference between SHOULD and should.   MUST and must, I've
> 	got that, but SHOULD and should -- they challenge me.
> 
> 	In this case, SHOULD seemed stronger than should, which I
> 	wanted, but I wasn't up for MUST since I think that there
> 	might be exceptions of which I am unaware and I didn't want to
> 	needlessly constrain folks.
> 
> 	I'll drop the normative language and just say "should" and
> 	move on here.
>>> 
>>> Section 4 paragraph 2 says "applications which employ Active
>>> Leasequery ... will usually use an initial Bulk Leasequery ..."
>>> What are the exceptions where this would not happen?   Or is this
>>> just the flow you expect Leasequery requestors to follow, but they
>>> could just do an Active Leasequery starting at T=0 or something?   I
>>> don't think this is going to cause an interop problem, but for
>>> clarity it might be worth figuring out what you mean here by
>>> "usually."   If you really just mean that this is how it is done,
>>> then you should probably say so more affirmatively.
> 
> 	Ok, we'll be more affirmative, but not normative. 
>>> 
>>> The organization of 6.2 is a bit odd: the first message is in 6.2,
>>> and subsequent messages are in 6.2.1 and 6.2.2.   This definitely
>>> isn't going to cause interop problems, but it might make the table of
>>> contents look nicer if you put LEASEQUERY-REPLY in its own 6.2.x
>>> subhead.
> 
> 	We did it this way because we are not defining a new message
> 	in 6.2 -- LEASEQUERY-REPLY is already defined in RFC5007.
> 
> 	But we'll put that paragraph in its own section since you feel
> 	it will be clearer.
>>> 
>>> In section 9.4, why all the text about multiple queries over the same
>>> connection?   If the recommendation is to use two connections, why
>>> not just require that?   This seems like needless complexity.
> 
> 	Ok, we'll take it out.  One connection per query.
>>> 
>>> In 9.5, why does it make sense for the server to finish processing
>>> outstanding requests _after_ it has determined that the requestor end
>>> of the connection has been closed?   If you mean that the requestor
>>> has shut down transmission but is still receiving, then wouldn't this
>>> mean for an active leasequery that the server would continue sending
>>> updates indefinitely after that?
> 
> 	Hmmm.  Well, yes, I suppose that it does.  I'll remove
> 	that last sentence.
>>> 
>>> In 10, I don't think you need to talk about SYN flood attacks: this
>>> is something that's typically dealt with in the stack.
> 	
> 	Always happy to remove stuff.  Its gone!
>>> 
>>> When you say that servers should restrict connections to certain
>>> requestors, you don't say how those requestors are identified.   I
>>> would suggest that you use the client cert, or a local-CA-cert
>>> signing the client cert, as that mechanism.   Otherwise I think
>>> you're relying on IP addresses, which would be a PITA to configure.
>>> Which I suppose means I'm suggesting that you not bother with this
>>> other than for TLS-secured connections.
> 
> 	Ok, we'll take that out too.
>>> 
>>> Aside from this modest set of comments, LGTM!   :)
>>> 
>>> _______________________________________________ Int-dir mailing list 
>>> [e-mail] https://www.ietf.org/mailman/listinfo/int-dir
>>> 
>> 
>