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

From: Ted Lemon <[email-masked]>
Date: Wed, 20 May 2015 15:50:08 -0400

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

I don't think support for STARTTLS should be optional, hence handling cases where it is not supported should be unnecessary.

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.

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.

Minor issues:

Section 2, definition for "Absolute Time", is the 32-bit quantity signed or unsigned?

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.

Similarly, why not split "catch-up information" and "catch-up phase" into two separate definitions?

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?

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.

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.

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.

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?

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.

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.

Aside from this modest set of comments, LGTM!   :)

---

From: Brian Haberman <[email-masked]>
Date: Tue, 26 May 2015 15:23:44 -0400

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 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.   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.
> 
> I don't think support for STARTTLS should be optional, hence handling
> cases where it is not supported should be unnecessary.
> 
> 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.
> 
> 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.
> 
> Minor issues:
> 
> 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.
> 
> 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?
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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?
> 
> 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.
> 
> 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.
> 
> _______________________________________________ Int-dir mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/int-dir
>

---

From: Kim Kinnear <[email-masked]>
Date: Tue, 26 May 2015 15:31:10 -0400

Brian,

We'll get back to you in a few days, after we have had a chance
to digest and discuss these comments.

Regards -- Kim

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 28 May 2015 13:52:15 -0400

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 <[email-masked]> wrote:

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

	Yes, we will put some words in section 9.1 to make these
	three possibilities (and their implications) hopefully
	much clearer.
>> 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.
>> is dropped; if the server's cert doesn't validate, the requestor

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

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

>> Section 2, definition for "Absolute Time", is the 32-bit quantity
	
	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.

>> be a nice edit for clarity.

	Sure, no problem.
>> into two separate definitions?

	Ok, sure.
>> advice would not be followed?   Is this text really intended to be

	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.
>> then you should probably say so more affirmatively.

	Ok, we'll be more affirmative, but not normative. 
>> contents look nicer if you put LEASEQUERY-REPLY in its own 6.2.x

	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.
>> not just require that?   This seems like needless complexity.

	Ok, we'll take it out.  One connection per query.
>> updates indefinitely after that?

	Hmmm.  Well, yes, I suppose that it does.  I'll remove
	that last sentence.
>> is something that's typically dealt with in the stack.
	
	Always happy to remove stuff.  Its gone!
>> other than for TLS-secured connections.

	Ok, we'll take that out too.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 29 May 2015 08:06:07 -0400

>      communications in the clear if TLS is not requested by the

This is what I am objecting to. The only time it makes sense to use TLS is if there is a risk of confidential data being snooped. If such a risk exists, then you can't allow the client to negotiate no TLS, because in so doing it will be exposing the confidential data. So if the server is configured to do TLS, it's not okay for the client to insist on operating in the clear.  This is equivalent to the SMTP STARTTLS vulnerability that made the news about a month ago. 

If you have clients that do not support TLS, then the server should just be configured not to use TLS. But personally I think you should just make TLS MTI. That way the server administrator has the freedom to configure it or not, without worrying about downgrade attacks. Back in the day we might have thought that making TLS MTI was too much to ask, but I don't think it is anymore.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 29 May 2015 08:14:13 -0400

>      ensuring that you are talking to the correct partner).

This ensures that your conversation can only be intercepted by an active attack, not a passive attack.  A man in the middle can still eavesdrop. I wonder if there's some security area document you could refer to that explains the options here. What I said in my review is a lot more detailed and nuanced than you're repeating back to me, and while I'm sympathetic to the desire to keep it simple, I think the text change you've proposed is arguably too simple, because it advocates for only one of the use cases I described in my comment.

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.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 29 May 2015 08:16:14 -0400

>>   base-time value received from the recently closed connection.

I did indeed miss this. Glad to see it's accounted for!

---

From: Ted Lemon <[email-masked]>
Date: Fri, 29 May 2015 08:20:51 -0400

Thanks for the quick response to my comments!  Sorry for replying with a flurry of messages—I'm still doing email on my iPad, so long replies are difficult.