Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt

[Maglione Roberta <[e-mail]>]

Please see answers inline.
Thanks,
Roberta

-----Original Message-----
From: Matthew Ryan [mailto:[e-mail]]
Sent: lunedì 13 febbraio 2012 19.57
To: Maglione Roberta
Cc: 'Menachem Dodge'; dhc WG; Wojciech Dec (wdec); '[e-mail]'; Ullio Mario; 'Ted Lemon'; 'Henderickx, Wim (Wim)'
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-forcerenew-nonce-03.txt

Minor item: The 'imbedded' typo in section 3.1.3 is still present.
[RM] sorry about that I'll correct the typo

While reviewing this, I noticed something I had missed before.
Section 3.1.4 indicates:
    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.

    The client MUST record the Forcerenew Nonce from any valid ACK it
    receives, if the ACK contains one.

There are two problems here.
[...]

This is in-line
with RFC-3315 (DHCPv6) behavior.  Perhaps someone who is more familiar
with the intent of RFC-3118 could confirm or deny that interpretation?

Assuming my read of RFC-3118 is correct, I would suggest the following
replacement text which should resolve both of those issues:

    If the server has indicated capability for Forcerenew Nonce
    Protocol authentication in the DHCP OFFER and the subsequent ACK
    received by the client while in the SELECTING state omits a valid
    DHCP authentication option for the Forcerenew Nonce Protocol, the
    client MUST discard the message and return to the INIT state.

    The client MUST record the Forcerenew Nonce from any valid ACK it
    receives, if the ACK contains one.

[RM] ok, I modify the text based on your proposal.

Roberta

 - Matt

On Feb 10, 2012, at 03:52 , Maglione Roberta 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:[e-mail]]
> Sent: venerdì 3 febbraio 2012 23.19
> To: Maglione Roberta
> Cc: dhc WG; '[e-mail]'; Wojciech Dec (wdec); '[e-mail]'; 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.
>
> <draft-ietf-dhc-forcerenew-nonce-04.txt>


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.