Subject: [dhcwg] Re: One more question

From: Ralph Droms <[email-masked]>
Date: Sat, 29 Oct 2005 08:02:20 -0400

There is ambiguity in RFC 3315 about which server a client responds to
when it receives a Reconfigure message:

19.4.1. Receipt of Reconfigure Messages

   Upon receipt of a valid Reconfigure message, the client responds with
   either a Renew message or an Information-request message as indicated
   by the Reconfigure Message option (as defined in section 22.19).

Does the client respond to the original server or the server that
transmitted the Reconfigure message?

We should probably write up the answer as an erratum to RFC 3315.

- Ralph

On Wed, 2005-10-05 at 14:12 -0600, D. R. Evans wrote:
> I suspect that this is answered clearly somewhere in the RFC, but I'm 
> having a hard time keeping it all in my head....
> 
> If a client receives a valid Reconfigure message from somewhere other 
> than the DHCP server that originally configured a given interface (i.e., 
> everything about the Reconfigure is fine, but the source IP v6 address 
> is not the IP address of the original DHCP server), then as far as I can 
> tell it accepts and acts on the Reconfigure. Assuming that is right: 
> when it sends the Renew or Information-request, to which device does it 
> send that message?
> 
>    Doc
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Shengyou Zeng \(szeng\)" <[email-masked]>
Date: Sun, 30 Oct 2005 07:26:23 -0500

I suggest the following: 

1. In Reconfigure validation (15.11), add a condition to "clients MUST
discard" list  

   - the message doesn't come from the server which granted the lease or
replied to Information-Request

This means clients will only accept Reconfigure from the original
server.  I don't see a lot of value in providing the capability to allow
another server to command Reconfigre.  If the server is down, Reconfigre
can wait; the client will be reconfigured when it next does Renew.

2. In 19.4.1 (Receipt of Reconfigure Messages), we specify that
responses to Reconfigure (Renew or Info-Req) be sent to the server that
issued the Reconfigure (which is the server that granted the lease
because of 1 above).  

Shengyou Zeng
Cisco Systems, Inc.
[email-masked]
978-936-1609
Boxborough, MA 01719

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Friday, October 28, 2005 5:16 PM
> To: [email-masked]
> Cc: Bernie Volz (volz); Shengyou Zeng (szeng); D. R. Evans; 
> Ralph Droms (rdroms)
> Subject: Re: [dhcwg] Re: One more question
> 
> On Saturday 29 October 2005 19:00, Bernie Volz (volz) wrote:
> > Think about a failover environment and the failover partner 
> that gave
> > out the addresses is down ...
> 
> I don't see how that's relevant.   If the protocol doesn't 
> work with failover 
> in the absence of reconfigure, that's a problem that needs to 
> be solved.   
> You can't solve it by being more specific about how the 
> client behaves in the 
> presence of reconfigure.
>

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sun, 30 Oct 2005 12:02:58 -0500

Why isn't the authentication sufficient for another server?

If we don't believe in the authentication mechanism, why did we bother
with it?

And, if a "fake server" can generate the authentication information,
don't you think it could also supply a the other server's server
identifier option (DUID)? That is the easy part (using the other
server's server identifier); the hard part is the authentication (or so
we believe).

- Bernie

> From: Shengyou Zeng (szeng) 
> Sent: Sunday, October 30, 2005 10:50 AM
> To: Bernie Volz (volz); Ralph Droms (rdroms); Josh Littlefield (joshl)
> Subject: RE: [dhcwg] Re: One more question
> 
> Hi Bernie,
> 
> > Reconfigure has authentication 
> 
> Authentication is adequate to allow the original server to 
> issue Reconfigure, but I think let other servers to dictate 
> Reconfigure requires more.  While the original server 
> apparently is authorized by virtue of Reconfigure Accept.  
> But how does the client know another server is authorized? 
> 
> -Shengyou  
> 
> > From: Bernie Volz (volz) 
> > Sent: Sunday, October 30, 2005 9:51 AM
> > To: Ted Lemon; [email-masked]
> > Cc: Shengyou Zeng (szeng); D. R. Evans; Ralph Droms (rdroms)
> > Subject: RE: [dhcwg] Re: One more question
> > 
> > Ted:
> > 
> > The protocol works just fine. Just like in DHCPv4, the 
> > partner server won't respond to RENEWs but will to REBINDs.
> > 
> > But what if you need to reconfigure the network while one of 
> > the partners is down. You wouldn't be able to reconfigure any 
> > client that gots its configuration from the partner that is 
> > down (until the client transitioned into REBIND state).
> > 
> > Reconfigure has authentication and it is presumed that the 
> > failover partners would communicate that authentication 
> > information. Therefore, what's the harm in having the client 
> > respond to the server that sent the Reconfigure (in most 
> > cases it will be the same server, but in some it may not be).
> > 
> > There are other alternatives for failover - such as having a 
> > "failover" server identifier instead of using the server's DUID.
> > 
> > I just think we'd be boxing ourselves in by forcing the 
> > client to communicate with the original server; especially 
> > since we have authentication and thus the client should be 
> > able to "trust" the server that sent it the Reconfigure.
> > 
> > - Bernie 
> >

---

From: "Shengyou Zeng \(szeng\)" <[email-masked]>
Date: Sun, 30 Oct 2005 14:47:49 -0500

> Sent: Sunday, October 30, 2005 12:03 PM
> To: Shengyou Zeng (szeng); Ralph Droms (rdroms); Josh 
> Littlefield (joshl)
> Cc: 'Ted Lemon'; [email-masked]'

In general security terms, the fact that I can verifiably know who you
are, doesn't mean that I will allow you to do what you attempt to do.
Not only do I need to know you really are who you claim to be
(authentication), I will also let you do only what you are supposed to
do (authorized).  

> 
> If we don't believe in the authentication mechanism, why did 
> we bother with it?

See above.

It is possible, though, to combine authorization with authentication:
whoever possesses a token automatically has the authority to do a
certain set of things.  Question is whether we want to do it here.  If
we do, should add text to explicitly say so.   

> 
> And, if a "fake server" can generate the authentication 
> information, don't you think it could also supply a the other 
> server's server identifier option (DUID)? That is the easy 
> part (using the other server's server identifier); the hard 
> part is the authentication (or so we believe).

Authorization is not to stop fake servers only, it also stop
unauthorized, though legitimate (i.e., authenticated), servers.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sun, 30 Oct 2005 20:00:36 -0500

I'd certainly be OK with REBIND and agree that makes more sense.

Do we change 3315 to allow REBIND as the msg-type in the Reconfigure
option? Or leave it RENEW and change the text to state if the client
receives an authenticated RECONFIGURE message from a server other than
the one it "negotiated" the binding with, it should send a REBIND (not a
RENEW).

My main goal was to assure that another server could trigger a
reconfiguration as in multi-server environments (such as failover
partners where they can exchange information such as the reconfigure
authentication) this is useful.

- Bernie

> Sent: Friday, October 28, 2005 5:46 PM
> To: Bernie Volz (volz)
> Cc: [email-masked]; Shengyou Zeng (szeng); D. R. Evans; Ralph 
> Droms (rdroms)
> On Sunday 30 October 2005 07:51, Bernie Volz (volz) wrote:
> > But what if you need to reconfigure the network while one of the
> > partners is down. You wouldn't be able to reconfigure any 
> client that
> > gots its configuration from the partner that is down (until 
> the client
> > transitioned into REBIND state).
> 
> It seems to me that the solution to this problem is to have 
> Reconfigure throw 
> the client into the REBIND state rather than the RENEW state. 
>   I'm not sure 
> what purpose it serves to throw the client into the RENEW state.
>