Next steps for draft-das-mipshop-andsf-dhcp-options

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Next steps for draft-das-mipshop-andsf-dhcp-options

Jari Arkko-2
This document was discussed in yesterday's IESG call. It is not yet
approved, because there were a number of issues identified. I think they
are quite easily resolvable, however. Please address them as follows:

Lars Eggert's discuss (see below): I think he is right, please fix this.

Tim Polk's discuss (see below): He is asking good questions,
interpretation of what the text actually means. Please make the draft
explicit about these issues.

Ralph Drom's discuss and Ted' Lemon's suggestions (see below): These are
also valid issues, please correct. Ralph has suggested text already.

Sean Turner's discuss (see below): These are (mostly) valid issues. I am
not sure there is anything that we can specifically point to as an
alternative protection beyond L2 and DHCP authentication, though, so
unless there's something specific in the ANDSF specs, leave that part out.

Comments from Lars and Ralph (see
https://datatracker.ietf.org/doc/draft-das-mipshop-andsf-dhcp-options/): 
I think these too are worth addressing. Please fix them.

I am expecting a new revision.

Jari

Lars Eggert:

>
> *Discuss (2010-09-08)*
>
> Section 4.1.1, paragraph 3:
> >    If the mobile node receives no address, it may either try another
> >    server or may continue to retransmit the PRL message. However, it
> >    MUST limit the rate at which it retransmits the message and limit
> >    the duration of the time during which it retransmits the message.
>
>   DISCUSS: What is the purpose of retransmitting the request to the DHCP
>   server if the MN doesn't receive the response it asked for? It's not
>   like the DHCP server will suddenly include the requested response next
>   time. (And also, you'd need to more fully specify the rate and cutoff
>   for these retransmissions if this mechanism stays in - requiring an
>   otherwise unspecified scheme is not enough.)
>  

Tim Polk:

>
> *Discuss (2010-09-09)*
>
> The current text is probably straightforward to DHCP experts, but it ambiguous
> to my reading in a number of places.
> I think each of these issues can be easily
> addressed, though:
>
> (1) I assume the length field is in bytes?  There is no indication, and a design
> where length equaled the number of
> IPv4 addresses (in section 2) or IPv6
> addresses (in section 3) would be plausible as well.
>
> (2) Is zero a valid Length field?  That is, can the IP Address list be omitted?
> Text in 4.1.1 and 4.2.1 ("If the mobile
> node receives no address") could be
> interpreted that way, but there is no indication in Sections 2 or 3 that the
> address list is optional.
>
> (2a) Does the text "If the mobile node receives no address" mean the DHCP
> response did not contain the option,
> or the option had zero addresses?  (This
> issue may be resolved above, if zero is *not* a legal Length.)
>
> (3) The Security Considerations should note in paragraph 1 that a modified
> response could also be used to mount
> an amplification attack.  By inserting the
> victim's address as the preferred ADNSP server, every node that wanted
> network
> discover and selection assistance would begin by directing traffic to the
> victim.  Since the nodes would
> eventually move on to the server with address
> "a2" (as shown in the figure immediately before section 3), the client
> would
> experience minor delays but the victim could be significantly affected.
Ralph Droms:

> *Discuss (2010-09-08)*
>
> (Updated 2010-09-08, to include review by Ted Lemon at
> https://www.ietf.org/mailman/private/iesg/2010-September/078081.html)
>
> The Introduction states that this document defines address list options and
> domain list options.  I only see the address list options.
>
> What is the "ANDSF discovery procedure" referenced in section 4.1.1?
>
> After reviewing the discussion of this document on the dhc WG mailing list, I
> think the issue of DHCP server behavior when that server has not been configured
> with any ANDSF server addresses has been resolved.  However, I don't think the
> current text accurately reflects the resolution of the issue.    Text in section
> 4.1.2 should be changed:
>
> OLD:
>
>    When the DHCP server receives an ANDSF IPv4 Address Option in the
>    PRL, the DHCP server MUST include the option in its response
>    messages (as defined in [RFC2131]and [RFC2132])that may contain a
>    list of one or more IP addresses of the ANDSF server hosting the
>    service.
>
> NEW:
>
>    When the DHCP server receives an ANDSF IPv4 Address Option in the
>    PRL, the DHCP server MUST process and respond according to the
>    behavior specified in RFC 2131.
>
> Text in section 4.2.2 should also be changed:
>
> OLD:
>
>    When the DHCP Server receives an ANDSF IPv6 Address Option in the
>    ORO, the DHCP server MUST include the option in its response (as
>    defined in [RFC3315])that may contain a list of one or more IP
>    addresses of the ANDSF server hosting the service.
>
> NEW:
>
>    When the DHCP Server receives an ANDSF IPv6 Address Option in the
>    ORO, the DHCP server MUST process and respond according to the
>    behavior specified in RFC 3315.
>
> Ted: Strictly speaking, the correct thing to do is simply remove the
>    text.  The base protocol spec already says what to do when you
>    receive a PRL and have a value for the ANDSF option, and what to do
>    if you do not.  If the goal is simply to remind the implementor to
>    consult the RFC, this text might be better:
>
>      DHCP clients MAY request the ANDSF IPv6 Address option in an ORO
>      option.  DHCP server handling of ORO options is specified in
>      RFC3115, section FOO.
>
>    The same comment applies to the IPv4 option.
>
>    Only if the server behavior or client behavior ought to be
>    different ought there to be any text in the document talking about
>    what to do when the ANDSF option appears in the PRL.  But we would
>    tend to discourage this anyway, since options that require protocol
>    changes to the DHCP protocol really are trying to fit a square peg
>    into a round hole.
>
> Suppose the host receives no DHCP messages with the ANDSF option?  Is it allowed
> to continue without performing the ANDSF function?
>
> Ted: According to the DHCP protocol specs, it's allowed to consider
>    offers from multiple servers before selecting a particular server,
>    and this could be used as a criterion in making such a selection.
>    However, this would require a custom DHCP client, and hence is not
>    likely to be practical except in very restricted use cases.
>
>    [Regardless of the chosen behavior], this document is probably not the place
> to
>    specify that behavior.   As the abstract says, this document just
> defines the options--it doesn't specify a whole protocol.
>    Presumably the
> protocol part is specified somewhere else, and it
>    might well say "if no DHCP
> server responds with an ANDSF option, we
>    can't make forward progress."   But
> that would be out of scope for
>    this document.
>
> The formats of the diagrams describing the options are internally inconsistent
> and inconsistent with the diagrams in other DHCP RFCs.  I mention this issue
> here (rather than a COMMENT) because of the potential for misinterpretation and
> incorrect implementation.
Sean Turner:

> *Discuss (2010-09-09)*
>
> 1) Need to add RFC 2119 as a normative reference.
>
> 2) Sec 5 (really hoping this is just a typo):
>
> OLD:
>
> It is recommended to use DHCP authentication option ...
>
> NEW:
>
> It is RECOMMENDED to use DHCP authentication option ...
>
> My assumption is that you really do want to recommend (ala RFC 2119) language
> that the DHCP authentication optoin be used.
>
> 3) The last paragraph is troubling to me.  It says:
>
>    In deployments where DHCP authentication is not available, 3GPP
>    specific lower layer security services may be sufficient to protect
>    DHCP messages. 3GPP ANDSF framework also provides additional
>    mechanisms that protect message exchanges between ANDSF client and
>    server at the higher layer.
>
> I read that say yeah sometimes no authentication is provided sometimes lower
> layer services provide it sometimes they don't (i.e., the "may be sufficient
> part").  Shouldn't this be recommending that lower layer services be employed to
> ensure tat all the bad things you discussed don't happen?
>
> In the 2nd sentence, what are these additional protections?  Are you saying that
> there are other mechanisms that can protect the exchange if DHCP authentication
> is not supported?  Shouldn't these be recommended in the case DHCP
> authentication isn't supported?

_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Next steps for draft-das-mipshop-andsf-dhcp-options

Subir Das-2
Jari,
Thanks. We will address the issues and prepare a new version within next
couple of days.

-Subir

Jari Arkko wrote:

> This document was discussed in yesterday's IESG call. It is not yet
> approved, because there were a number of issues identified. I think
> they are quite easily resolvable, however. Please address them as
> follows:
>
> Lars Eggert's discuss (see below): I think he is right, please fix this.
>
> Tim Polk's discuss (see below): He is asking good questions,
> interpretation of what the text actually means. Please make the draft
> explicit about these issues.
>
> Ralph Drom's discuss and Ted' Lemon's suggestions (see below): These
> are also valid issues, please correct. Ralph has suggested text already.
>
> Sean Turner's discuss (see below): These are (mostly) valid issues. I
> am not sure there is anything that we can specifically point to as an
> alternative protection beyond L2 and DHCP authentication, though, so
> unless there's something specific in the ANDSF specs, leave that part
> out.
>
> Comments from Lars and Ralph (see
> https://datatracker.ietf.org/doc/draft-das-mipshop-andsf-dhcp-options/): 
> I think these too are worth addressing. Please fix them.
>
> I am expecting a new revision.
>
> Jari
>
> Lars Eggert:
>>
>> *Discuss (2010-09-08)*
>>
>> Section 4.1.1, paragraph 3:
>> >    If the mobile node receives no address, it may either try another
>> >    server or may continue to retransmit the PRL message. However, it
>> >    MUST limit the rate at which it retransmits the message and limit
>> >    the duration of the time during which it retransmits the message.
>>
>>   DISCUSS: What is the purpose of retransmitting the request to the DHCP
>>   server if the MN doesn't receive the response it asked for? It's not
>>   like the DHCP server will suddenly include the requested response next
>>   time. (And also, you'd need to more fully specify the rate and cutoff
>>   for these retransmissions if this mechanism stays in - requiring an
>>   otherwise unspecified scheme is not enough.)
>>  
>
> Tim Polk:
>>
>> *Discuss (2010-09-09)*
>>
>> The current text is probably straightforward to DHCP experts, but it
>> ambiguous
>> to my reading in a number of places.
>> I think each of these issues can be easily
>> addressed, though:
>>
>> (1) I assume the length field is in bytes?  There is no indication,
>> and a design
>> where length equaled the number of IPv4 addresses (in section 2) or IPv6
>> addresses (in section 3) would be plausible as well.
>>
>> (2) Is zero a valid Length field?  That is, can the IP Address list
>> be omitted?
>> Text in 4.1.1 and 4.2.1 ("If the mobile
>> node receives no address") could be
>> interpreted that way, but there is no indication in Sections 2 or 3
>> that the
>> address list is optional.
>>
>> (2a) Does the text "If the mobile node receives no address" mean the
>> DHCP
>> response did not contain the option,
>> or the option had zero addresses?  (This
>> issue may be resolved above, if zero is *not* a legal Length.)
>>
>> (3) The Security Considerations should note in paragraph 1 that a
>> modified
>> response could also be used to mount
>> an amplification attack.  By inserting the
>> victim's address as the preferred ADNSP server, every node that wanted
>> network
>> discover and selection assistance would begin by directing traffic to
>> the
>> victim.  Since the nodes would
>> eventually move on to the server with address
>> "a2" (as shown in the figure immediately before section 3), the client
>> would
>> experience minor delays but the victim could be significantly affected.
> Ralph Droms:
>
>> *Discuss (2010-09-08)*
>>
>> (Updated 2010-09-08, to include review by Ted Lemon at
>> https://www.ietf.org/mailman/private/iesg/2010-September/078081.html)
>>
>> The Introduction states that this document defines address list
>> options and
>> domain list options.  I only see the address list options.
>>
>> What is the "ANDSF discovery procedure" referenced in section 4.1.1?
>>
>> After reviewing the discussion of this document on the dhc WG mailing
>> list, I
>> think the issue of DHCP server behavior when that server has not been
>> configured
>> with any ANDSF server addresses has been resolved.  However, I don't
>> think the
>> current text accurately reflects the resolution of the issue.    Text
>> in section
>> 4.1.2 should be changed:
>>
>> OLD:
>>
>>    When the DHCP server receives an ANDSF IPv4 Address Option in the
>>    PRL, the DHCP server MUST include the option in its response    
>> messages (as defined in [RFC2131]and [RFC2132])that may contain a    
>> list of one or more IP addresses of the ANDSF server hosting the    
>> service.
>> NEW:
>>
>>    When the DHCP server receives an ANDSF IPv4 Address Option in the
>>    PRL, the DHCP server MUST process and respond according to the
>>    behavior specified in RFC 2131.
>>
>> Text in section 4.2.2 should also be changed:
>>
>> OLD:
>>
>>    When the DHCP Server receives an ANDSF IPv6 Address Option in the
>>    ORO, the DHCP server MUST include the option in its response (as
>>    defined in [RFC3315])that may contain a list of one or more IP    
>> addresses of the ANDSF server hosting the service.
>> NEW:
>>
>>    When the DHCP Server receives an ANDSF IPv6 Address Option in the
>>    ORO, the DHCP server MUST process and respond according to the
>>    behavior specified in RFC 3315.
>>
>> Ted: Strictly speaking, the correct thing to do is simply remove the
>>    text.  The base protocol spec already says what to do when you
>>    receive a PRL and have a value for the ANDSF option, and what to do
>>    if you do not.  If the goal is simply to remind the implementor to
>>    consult the RFC, this text might be better:
>>
>>      DHCP clients MAY request the ANDSF IPv6 Address option in an ORO
>>      option.  DHCP server handling of ORO options is specified in
>>      RFC3115, section FOO.
>>
>>    The same comment applies to the IPv4 option.
>>
>>    Only if the server behavior or client behavior ought to be
>>    different ought there to be any text in the document talking about
>>    what to do when the ANDSF option appears in the PRL.  But we would
>>    tend to discourage this anyway, since options that require protocol
>>    changes to the DHCP protocol really are trying to fit a square peg
>>    into a round hole.
>>
>> Suppose the host receives no DHCP messages with the ANDSF option?  Is
>> it allowed
>> to continue without performing the ANDSF function?
>>
>> Ted: According to the DHCP protocol specs, it's allowed to consider
>>    offers from multiple servers before selecting a particular server,
>>    and this could be used as a criterion in making such a selection.
>>    However, this would require a custom DHCP client, and hence is not
>>    likely to be practical except in very restricted use cases.
>>
>>    [Regardless of the chosen behavior], this document is probably not
>> the place
>> to
>>    specify that behavior.   As the abstract says, this document just
>> defines the options--it doesn't specify a whole protocol.
>>    Presumably the
>> protocol part is specified somewhere else, and it
>>    might well say "if no DHCP
>> server responds with an ANDSF option, we
>>    can't make forward progress."   But
>> that would be out of scope for
>>    this document.
>>
>> The formats of the diagrams describing the options are internally
>> inconsistent
>> and inconsistent with the diagrams in other DHCP RFCs.  I mention
>> this issue
>> here (rather than a COMMENT) because of the potential for
>> misinterpretation and
>> incorrect implementation.
> Sean Turner:
>
>> *Discuss (2010-09-09)*
>>
>> 1) Need to add RFC 2119 as a normative reference.
>>
>> 2) Sec 5 (really hoping this is just a typo):
>>
>> OLD:
>>
>> It is recommended to use DHCP authentication option ...
>>
>> NEW:
>>
>> It is RECOMMENDED to use DHCP authentication option ...
>>
>> My assumption is that you really do want to recommend (ala RFC 2119)
>> language
>> that the DHCP authentication optoin be used.
>>
>> 3) The last paragraph is troubling to me.  It says:
>>
>>    In deployments where DHCP authentication is not available, 3GPP    
>> specific lower layer security services may be sufficient to protect
>>    DHCP messages. 3GPP ANDSF framework also provides additional    
>> mechanisms that protect message exchanges between ANDSF client and    
>> server at the higher layer.
>> I read that say yeah sometimes no authentication is provided
>> sometimes lower
>> layer services provide it sometimes they don't (i.e., the "may be
>> sufficient
>> part").  Shouldn't this be recommending that lower layer services be
>> employed to
>> ensure tat all the bad things you discussed don't happen?
>>
>> In the 2nd sentence, what are these additional protections?  Are you
>> saying that
>> there are other mechanisms that can protect the exchange if DHCP
>> authentication
>> is not supported?  Shouldn't these be recommended in the case DHCP
>> authentication isn't supported?
>
> _______________________________________________
> Mipshop mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/mipshop
_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop