Subject: Re: [Dhcpv6bis] [dhcpv6bis] #89 (XML 3315): Possibility of DoS Attack in DHCPv6 authentication

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 1 Apr 2014 18:23:44 +0000

Ralph:

Perhaps you'd have a chance to look at this particular issue and comment? See http://trac.tools.ietf.org/group/dhcpv6bis/ticket/89.

Or, see Section 5 of ​http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-clarify-auth-01.

Or do you recall who might have focused more on the Authentication material in RFC 3315?

- Bernie

-----Original Message-----
From: dhcpv6bis issue tracker [mailto:[email-masked]] 
Sent: Tuesday, April 01, 2014 2:19 PM
To: Bernie Volz (volz); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [dhcpv6bis] #89 (XML 3315): Possibility of DoS Attack in DHCPv6 authentication

#89: Possibility of DoS Attack in DHCPv6 authentication

Comment (by [email-masked]):

 I don't fully remember exactly what I thought when I wrote the draft, but  regarding your question:

 > One reason for this is that the current text refers to the ‘first  timeout period’, but what if the client already passed that period (i.e.,  retransmitted). How long does it wait then? No more time? Or let that  timeout expire? I think simplifying this to just ignore messages which  fail authentication keeps things simpler?

 I guess if the client already passed the initial timeout when it receives  a Reply that fails authentication, it's okay to fall back to restart the  whole DHCPv6 session from Solicit.  The main concern in this context was  that an attacker can quickly send a bogus Reply than a legitimate server  and force the client to go back to Solicit.  But if an initial timeout has  already passed, it's less likely that the failed Reply is for such kind of  DoS.

 That said, I don't necessarily insist on the original proposed solution of  mine.  If the editor team generally prefers the simplicity I'm okay with  that.  But in that case I'd at least suggest asking the original authors  of RFC3315 (Ralph and/or Ted?) for clarification on the intent of the  behavior described in RFC3315.  Silently discarding such packets should  actually be more common in cases like this, so there may have been a  specific reason why they didn't choose that in the first place.  With  understanding the intent we can be more confident about whatever solutions  we finally adopt.

-- 
-------------------------------+----------------------------------------
-------------------------------+-
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  task               |      Status:  new
 Priority:  P3 major           |   Milestone:  A easy, apply before merge
Component:  XML 3315           |  Resolution:
 Keywords:                     |
-------------------------------+----------------------------------------
-------------------------------+-

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/89#comment:4>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 11 Apr 2014 17:16:42 +0000

Hi Ralph:

http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-clarify-auth I think is 'dead' (it expired a long time ago). We are just working to incorporate these comments, where appropriate, into the BIS document - so the editorial issue won't exist.

If we do allow the MAY, I agree it would be good to provide a reason - there are also several MAYs in the original text so this clarification may be needed in multiple places.

The main question I was trying to resolve is what a client should do if the REPLY fails validation. I.E.:

   Section 21.4.4.5 of the RFC says as follows:

      If the Reply fails to pass the validation test, the client MUST
      restart the DHCP configuration process by sending a Solicit
      message.

The clarify-auth suggested that the client wait at least one retransmission period for authenticated REPLYs. I was thinking to simplify this to just make the client do all of its REQUEST retransmissions as normal (basically ignoring the REPLYs that failed validation).

The draft assumed this was because of:

   The purpose of this specification is probably to avoid a deadlock
   scenario when the server suddenly reboots forgetting the
   authentication key and/or the replay detection counter.

The downside of just ignoring responses that fail the validation test is that in this particular situation, it will take longer for the client to complete its operation with the server (i.e., fall back to Solicit and restart). The plus side is that a rogue response can't alter the behavior. The proposed text was in-between - assuring that the 'real' server had at least one retransmission timeout period to respond.

Thus the choices seem to be:
1. Leave it alone. This has the disadvantage that a rogue server that responds faster than the real can prevent the client from ever completing DHCP.
2. Assure that the client has waited at least one retransmission timeout period. To avoid the DoS issue in 1 above, the real server must respond within the initial timeout interval. In the deadlock scenario, this means only one timeout period before the Client restarts at Solicit.
3. Require the client to do its standard retransmissions (i.e., ignore the 'bad' packets). This assures DoS should not be possible, but increases the 'cost' should the server restart and lose any of the auth information it had saved 'in memory' for the Solicit.

2 is probably reasonable and favors the server restart case; 3 is simpler but penalizes operations for the 'normal' server restart case (i.e., when the server has not committed anything from the Solicit/Advertise into stable storage).

(There is a subtle tweak we could make to 2 - the client ignores Replies that fail authentication, but flags that it did receive a response. Then, at the next retransmission if the received flag was set, the client MAY restart the DHCP configuration process by sending a Solicit message. This avoids special casing the 'first' retransmission case.)

- Bernie

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Friday, April 11, 2014 12:12 PM
To: Bernie Volz (volz)
Subject: Re: [dhcpv6bis] #89 (XML 3315): Possibility of DoS Attack in DHCPv6 authentication

I was also wrestling with the transition to a new laptop (refresh) from a laptop that crashed just *before* that trip; had to get a minimal setup on a very old personal mac,  and then get to the new laptop from a backup.

Anyway, I agree with the analysis and the solution (in general).  I don't recall any additional considerations behind the behavior to failed message authentication that is described in RFC3315.

I have one small technical issue and a small editorial issue with section 5.2.

Under what circumstances would a client decide to accept an unauthenticated Reply message - it's often helpful to give the reasons on which to base a "MAY" decision.

The editorial issue is that I found it confusing to differentiate between section references to RFC3315 and draft-ietf-dhc-dhcpv6-clarify-auth.

- Ralph

On Apr 11, 2014, at 10:26 AM 4/11/14, Bernie Volz (volz) <[email-masked]> wrote:

> Ralph ... just a friendly reminder as I believe you were out or traveling when I sent this.
> 
> - Bernie
> 
> From: Bernie Volz (volz) 
> Sent: Tuesday, April 01, 2014 2:24 PM
> To: Ralph Droms (rdroms)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [dhcpv6bis] #89 (XML 3315): Possibility of DoS Attack in DHCPv6 authentication
> 
> Ralph:
>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 21 Apr 2014 15:21:57 -0700

Bernie - do I have it right that the problematic situation is that the server reboots somewhere between Advertise and Reply, so that it can't add proper authentication information to the Reply?

If I have that right, would the server be aware that it will be unable to authenticate the client?

- Ralph

On Apr 11, 2014, at 1:16 PM 4/11/14, Bernie Volz (volz) <[email-masked]> wrote:

> _______________________________________________
> Dhcpv6bis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcpv6bis

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 21 Apr 2014 23:44:54 +0000

That appears to be the situation that this particular text was regarding. Currently, as it reads, this can be a denial of service attack if someone can Reply to the client with an unauthenticated (or perhaps failed auth) response before the server does. So, the change proposed by Jinmei was to assure that the server is given some time to send a valid response (i.e., wait at least until the timeout). I'm wondering whether to do that or just keep it simple and have the client drop the unauthenticated responses and 'fallback' to Solicit after a normal Solicit/Advertise/Request timeout.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Monday, April 21, 2014 6:22 PM
To: Bernie Volz (volz)
Cc: [email-masked]; [email-masked]
Subject: Re: [Dhcpv6bis] [dhcpv6bis] #89 (XML 3315): Possibility of DoS Attack in DHCPv6 authentication

- Ralph

On Apr 11, 2014, at 1:16 PM 4/11/14, Bernie Volz (volz) <[email-masked]> wrote:

> (There is a subtle tweak we could make to 2 - the client ignores 
> Replies that fail authentication, but flags that it did receive a 
> response. Then, at the next retransmission if the received flag was 
> set, the client MAY restart the DHCP configuration process by sending 
> a Solicit message. This avoids special casing the 'first' 
> retransmission case.)
> 
> - Bernie
> 
> 
>> -------------------------------+-------------------------------------
>> -------------------------------+---
>> -------------------------------+-------------------------------------
>> -------------------------------+---
>> Ticket URL: 
>> <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/89#comment:4>

---

From: Ralph Droms <[email-masked]>
Date: Tue, 22 Apr 2014 10:08:32 -0700

> That appears to be the situation that this particular text was regarding. Currently, as it reads, this can be a denial of service attack if someone can Reply to the client with an unauthenticated (…

Simplicity wins for me.  I recommend simply discarding Advertise messages that fail authentication.  If I'm understanding the scenario correctly, and with the default values of REQ_MAX_RT == 30 secs and REQ_MAX_RC == 10, the time before the client restarts with a Solicit will be less than 300 seconds.  That delay seems acceptable for what should be a pretty unusual situation.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 22 Apr 2014 10:10:00 -0700

On Apr 22, 2014, at 9:48 AM 4/22/14, 神明達哉 <[email-masked]> wrote:

> At Mon, 21 Apr 2014 23:44:54 +0000,
> "Bernie Volz (volz)" <[email-masked]> wrote:
> 
>> That appears to be the situation that this particular text was
>> regarding. Currently, as it reads, this can be a denial of service
>> attack if someone can Reply to the client with an unauthenticated
>> (or perhaps failed auth) response before the server does. So, the
>> change proposed by Jinmei was to assure that the server is given
>> some time to send a valid response (i.e., wait at least until the
>> timeout). I'm wondering whether to do that or just keep it simple
>> and have the client drop the unauthenticated responses and
>> 'fallback' to Solicit after a normal Solicit/Advertise/Request
>> timeout.
> 
> BTW, I suggested to ask Ralph because he may remember the rationale of
> the original RFC3315 behavior.  Apparently it's not the case (or there
> was simply not a particular rationale), so I'm personally now fine
> with leaving it to the editors.

I don't recall if there was a specific rationale for the behavior specified in RFC 3315.

In my opinion, this scenario will be pretty rare and may be entirely hypothetical, so I would recommend the simplest operable solution.

- Ralph

>  Of course, if Ralph has his own
> suggestions on how to resolve the issue in 3315bis, that would be
> appreciated.  Or, if this is deemed to be worth wider attention, you
> might bring it to the wg list.
> 
> --
> JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Apr 2014 14:29:49 -0400

> In my opinion, this scenario will be pretty rare and may be entirely hypothetical, so I would recommend the simplest operable solution.

I think the "drop unauthenticated response" solution is good, assuming that I correctly understand that at this point an unauthenticated response is invalid.   The possibility of a server reboot between advertise and reply seems implausible.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 22 Apr 2014 09:48:08 -0700

with leaving it to the editors.  Of course, if Ralph has his own

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Tue, 22 Apr 2014 11:15:45 -0700

> Simplicity wins for me.  I recommend simply discarding Advertise messages that fail authentication.  If I'm understanding the scenario correctly, and with the default values of REQ_MAX_RT == 30 sec…

makes sense to me.

--
jinmei

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 22 Apr 2014 20:17:31 +0000

Thanks Ralph, Jinmei, and Ted ... I will go with simple (drop and ignore the responses). 

I guess if it ever gets widely used, we'll learn more and may need to adjust. I think this is all theoretical since not really sure if anyone has any deployment experience!

- Bernie