Subject: [Dhcpv6bis] [dhcpv6bis] #138 (XML 3315): Security considerations update needed

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 07 Jan 2015 11:26:00 -0000

#138: Security considerations update needed

 There's a lot to update in the security considerations section.

 First, we should consider splitting it into security considerations proper
 and privacy considerations. Not sure if it should be a separate section on
 maybe a new subsection.

 Second, references to existing DHCP privacy work should be added,
 preferably with a short overview of the issues.

 Another issue that should probably be at least mentioned is the case where
 a server sends reconfigure-key and then crashes. Any other server will not
 have necessary key information, so it can't trigger reconfigure. Perhaps
 this issue should be discussed in a separate subsection and only
 referenced in security considerations?

-- 
----------------------------------------+-----------------------------
 Reporter:  [email-masked]  |      Owner:
     Type:  task                        |     Status:  new
 Priority:  P1 blocker                  |  Milestone:  E Editor issues
Component:  XML 3315                    |   Keywords:
 Due Date:  04/02/2015                  |
----------------------------------------+-----------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/138>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Jan 2015 09:51:24 -0500

> and privacy considerations. Not sure if it should be a separate section on

I think that this is a good idea.

    > referenced in security considerations?

Could the servers do a 3-way (well, n+1 way, for n servers) handshake
beforehand?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 07 Jan 2015 16:16:15 +0100

> I think that this is a good idea.
Cool.

> Could the servers do a 3-way (well, n+1 way, for n servers) handshake
Yes, the protocol to do that is called failover :) I was thinking that
the reasonable thing to do here is to just mention the issue that if
your server generates keys and hands them over to clients, the
replacement server will not be able to take advantage of the
reconfiguration process. The text could possibly add that implementors
may develop a mechanism for sharing the keys between servers, but it's
outside of scope for this document. Also, we could reference failover
drafts to point out to possible way to share client information between
the servers.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 7 Jan 2015 18:02:41 +0000

There are bigger problems if the server loses its state - such as which addresses are assigned/prefixes delegated. Not really sure this is worth the effort.

Perhaps if anything we should just cover the general issue that when a server loses its state database, a lot of things occur. On the flip side, there aren't any good workarounds for this other than failover either since performing periodic backups isn't really useable. (I guess the solutions are failover or a database that is persisted by multiple nodes so there is no single point of failure).

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Wednesday, January 07, 2015 10:16 AM
To: Michael Richardson; [email-masked]
Subject: Re: [Dhcpv6bis] [dhcpv6bis] #138 (XML 3315): Security considerations update needed

Cool.

> Could the servers do a 3-way (well, n+1 way, for n servers) handshake 
Yes, the protocol to do that is called failover :) I was thinking that the reasonable thing to do here is to just mention the issue that if your server generates keys and hands them over to clients, the replacement server will not be able to take advantage of the reconfiguration process. The text could possibly add that implementors may develop a mechanism for sharing the keys between servers, but it's outside of scope for this document. Also, we could reference failover drafts to point out to possible way to share client information between the servers.

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Jan 2015 13:44:09 -0500

> drafts to point out to possible way to share client information between

I think the text should explain the problem, and should say that
synchronization of keys is out of scope; may be implementation specific,
but that the failover protocol is a good place to start.
(not knowing anything about the failover protocol, I'm guessing that the
failover protocol can be used for this, but it might occur in an
implementation specific way)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 7 Jan 2015 19:05:46 +0000

>not knowing anything about the failover protocol, I'm guessing that the failover protocol can be used for this, but it might occur in an implementation specific way)

Yes it can.

Though there is always the question of what checking a client will do - for example, does it check both the server-identifier option AND the reconfigure key or just the key. I think the protocol . 21.5.3 kind of implies that just the Reconfigure Key (regardless of server-identifier option)  is what matters, but hopefully clients don't associate a Reconfigure-key with a particular server. Ideally any server that presents a valid reconfigure message should be accepted to trigger the Reconfigure. Not sure if we should add something about this explicitly (and it might be there but I just missed it). Again, it never says to use the server-identifier so it may be OK as is.

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Wednesday, January 07, 2015 1:44 PM
To: Tomek Mrugalski
Cc: [email-masked]
Subject: Re: [Dhcpv6bis] [dhcpv6bis] #138 (XML 3315): Security considerations update needed

    > drafts to point out to possible way to share client information between

I think the text should explain the problem, and should say that synchronization of keys is out of scope; may be implementation specific, but that the failover protocol is a good place to start.
(not knowing anything about the failover protocol, I'm guessing that the failover protocol can be used for this, but it might occur in an implementation specific way)