[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt
Hello Roberta,
Looks good to me.
Regards,
Woj.
On 10/02/2012 12:52, "Maglione Roberta" <roberta.maglione at telecomitalia.it>
wrote:
> Hello Matt, Menachem and All,
> I made some changes to the document in order to address your comments.
> Please see answers inline [RM].
> I attached a new version of the document I haven't posted it yet, please let
> me know if the new version covers your points and if you have additional
> comments.
> Thanks,
> Best regards,
> Roberta
>
> -----Original Message-----
> From: Matthew Ryan [mailto:Matt.Ryan at nominum.com]
> Sent: venerdì 3 febbraio 2012 23.19
> To: Maglione Roberta
> Cc: dhc WG; 'david.miles at alcatel-lucent.com'; Wojciech Dec (wdec);
> 'James.Bristow at swisscom.com'; Ullio Mario; 'Ted Lemon'
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt
>
>
> On Feb 3, 2012, at 07:26 , Maglione Roberta wrote:
>>
>> Section 3.1.4 states:
>> The client will receive a Forcerenew Nonce from the server in the
>> initial DHCP Ack message from the server.
>> which could be construed to imply that the nonce is only chosen
>> during the initial 4-way handshake.
>>
>> However, the protocol interaction diagram in section 3.1.1
>> seems to indicate that, during a renew, the server may/must
>> (unclear) create a new nonce.
>>
>> [RM] The idea is that the nonce is selected and sent by the server in the
>> initial DHCP exchange, then later on when the DHCP server needs to send a
>> Forcerenew message it includes the nonce previously created in the message
>> sent to the client. In this way the client can verify that the Forcerenew
>> message comes from a trusted DHCP server. Please let me know if you think
>> this behavior should better explained in the document
>
> I believe it's clear that a nonce should be returned in each
> ACK message. However, I think the document needs to be clarified
> as to which REQUEST messages (init-reboot, select, renew, rebind)
> or conditions should cause a server to generate a /new/ nonce.
> Specifically, when the server MUST generate a nonce, and when
> it MAY generate (or change) the nonce.
>
> [RM] I clarified this by adding the following sentences:
>
> The server SHOULD NOT include the nonce in an ACK when responding to
> a renew unless a nonce was generated. This minimizes the number of
> times the nonce is sent over the wire. (as per your proposal)
>
> If the server to which the DHCP Request message was sent at time T1
> has not responded, the client enters the REBINDING state and attempts
> to contact any server. The new Server receiving the DHCP message
> MUST generate a new nonce.
>
>
>
> Does the server ONLY generate a nonce the first time it sees the
> client? Is the server ONLY allowed to generate a nonce (even if
> it has no previous recorded) in response to a select, or can it do
> so for rebind and init-reboot as well? Can the server (perhaps on
> a timer or by admin instruction) choose to generate a new nonce for
> a client in response to a renew?
>
> [RM] In case of rebind the Server MUST generates a new nonce
>
> In addition, it should be clarified when a client should update
> its record of the nonce. The draft currently states this is done
> in response to the "initial DHCP Ack message". Depending on the
> answers to the server behavior question above, this may not be
> sufficient. If the server is allowed to generate a new nonce
> on rebind (which may need to happen in environments that have
> multiple DHCP servers that don't do failover), the client should
> probably update itself then as well.
>
> Also, what should happen in the case where the client indicates
> in a renew that it is capable, and the server is capable, but the
> server has no recollection of a nonce for the client? This condition
> can happen if the server support is enabled and the client already
> possesses an active lease from the server.
>
> [RM] Good points, I think the 3 points you propose below take care of these
> cases.
>
> I would probably recommend at the following:
> 1) The client MUST record the nonce from any valid ACK it receives,
> if the ACK contains one.
> 2) If a capable server receives a DISCOVER or REQUEST (any type)
> that indicates the client is capable, and the server has no
> previous nonce recorded, it MUST generate a nonce and include
> it in the ACK.
> 3) The server SHOULD NOT include the nonce in an ACK when responding
> to a renew unless a nonce was generated. This minimizes the
> number of times the nonce is sent over the wire.
>
> [RM] I added the 3 points you suggested
>
> That leaves open the question of whether a server MAY change
> an existing nonce, but that becomes a non-issue due to (1).
>
>
>
>
> My reading of the draft indicated that the server would send
> a nonce of type 0 in an OFFER (type 0 is not covered in section
> 3.1.2) - but there was no indication of what the value should be.
>
> I think, that, in the OFFER message, it is sufficient for the
> server to simply send the FORCERENEW_NONCE_CAPABLE, and omit
> the authentication option. So, I would change section 3.1.4
> from:
> The client MUST indicate Forcerenew nonce Capability by including the
> FORCERENEW_NONCE_CAPABLE(<TBD>) DHCP option (Section 2.1.1) in all
> DHCP Discover and Request messages. DHCP servers that support
> Forcerenew nonce Protocol authentication MUST include the DHCP
> Forcerenew Nonce protocol authentication option in DHCP Offers with
> type set to zero(0), allowing the client to use this capability in
> selecting DHCP servers should multiple Offers arrive.
>
> A DHCP server has indicates its support through the inclusion of the
> FORCERENEW_NONCE_CAPABLE(<TBD>) option in the DHCP Offer. The client
> MUST validate the DHCP Ack message contains a Forcerenew Nonce in a
> DHCP authentication option. If the server has indicated capability
> for Forcerenew Nonce Protocol authentication in the DHCP Offer and a
> subsequent Ack omits a valid DHCP authentication option for the
> Forcerenew Nonce Protocol, the client MUST send a DHCP Decline
> message and return to the DHCP Init state.
> to (changed lines marked, no rewrapping done for clarity):
> The client MUST indicate Forcerenew nonce Capability by including the
> FORCERENEW_NONCE_CAPABLE(<TBD>) DHCP option (Section 2.1.1) in all
> DHCP Discover and Request messages. DHCP servers that support
> * Forcerenew nonce Protocol authentication MUST include the
> * FORCERENEW_NONCE_CAPABLE(<TBD>) DHCP option (Section 2.1.1) in all
> * DHCP Offers, allowing the client to use this capability in
> selecting DHCP servers should multiple Offers arrive.
>
> * The client
> MUST validate the DHCP Ack message contains a Forcerenew Nonce in a
> DHCP authentication option. If the server has indicated capability
> for Forcerenew Nonce Protocol authentication in the DHCP Offer and a
> subsequent Ack omits a valid DHCP authentication option for the
> Forcerenew Nonce Protocol, the client MUST send a DHCP Decline
> message and return to the DHCP Init state.
>
> [RM] I modified the text as per your proposal
>
>
> - Matt
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the intended
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks.
>