Re: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt

[Jari Arkko <jari.arkko at piuha.net>]

I think it is better to explain what the issues are.
Your text works for me -- make the changes and
submit a new version so that we can move this
draft forward!

Thanks,

Jari

MORAND Lionel RD-CORE-ISS kirjoitti:
> Hi Jari,
>
> I was assuming that the warning ("MUST NOT") in the introduction was enough.
> Anyway, if deemed necessary, I would propose to add the following text in the security considerations section:
>
>    "PANA is mainly designed for acces networks without underlying security.
>    In such environment, the DHCP exchange that delivers the options is not
>    secured from a L2 point of view. Therefore, the options defined in this
>    document MUST NOT be used to perform any negotiation on the use of PANA 
>    between the PaC and a PAA. For instance, presence (or absence) of these
>    DHCP options might indicate that the use of PANA would be required (or
>    not). However, this would allow bidding down attacks by making the 
>    clients choose to use a lower-grade security mechanisms (or even no 
>    security at all)."
>
> Any comment/suggestion will be very welcome!
>
> Lionel
>
>
>   
>> -----Message d'origine-----
>> De : Jari Arkko [mailto:jari.arkko at piuha.net] 
>> Envoyé : mercredi 13 décembre 2006 11:24
>> À : MORAND Lionel RD-CORE-ISS
>> Cc : Alper Yegin; pana at ietf.org
>> Objet : Re: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt
>>
>> All of these changes look good, but didn't we also agree to 
>> place some text in the Security Considerations section on the 
>> bad things that might happen if you did use this for negotiation?
>>
>> --Jari
>>
>> MORAND Lionel RD-CORE-ISS kirjoitti:
>>     
>>> Hi Jari, Alper
>>>
>>> According to the presentation made during the last IETF 
>>>       
>> meeting, here are the proposed changes to include in the next 
>> version of the PANA-DHCP document.
>>     
>>> Please consider the proposed modifications to make sure 
>>>       
>> that all the remaining issues are covered.
>>     
>>> I will submit a new version of the draft (v05) based on 
>>>       
>> your feedack.
>>     
>>> BR,
>>>
>>> Lionel
>>>
>>> ******************************************************************
>>>
>>> #1- in the introduction (section 1), at the end of the 3rd 
>>>       
>> paragraph, revise the text to remove "many"
>>     
>>> From:
>>>  
>>>    "This document specifies DHCPv4 [RFC2131] and DHCPv6 
>>>       
>> [RFC3315] options
>>     
>>>    that allow PANA client (PaC) to discover PANA 
>>>       
>> Authentication Agents
>>     
>>>    (PAA).  This is one of the many methods for locating PAAs."
>>>
>>> To:
>>>
>>>    "This document specifies DHCPv4 [RFC2131] and DHCPv6 
>>>       
>> [RFC3315] options
>>     
>>>    that allow PANA client (PaC) to discover PANA 
>>>       
>> Authentication Agents
>>     
>>>    (PAA).  This is one of the methods for locating PAAs."
>>>
>>> #2- in the introduction (section 1), extend the existing 
>>>       
>> section with the following text:
>>     
>>>    "The DHCP options defined in this document are used only as a PAA
>>>    discovery mechanism. These DHCP options MUST NOT be used 
>>>       
>> to perform 
>>     
>>>    any negotiation on the use of PANA between the PaC and a PAA."
>>>
>>> #3- At the end of the section 4 (DHCPv4 option), revise the 
>>>       
>> text to clarify the use of the DHCP options:
>>     
>>> From:
>>>
>>>    "A DHCPv4 client requests the PAA DHCPv4 Option in a 
>>>       
>> Parameter Request
>>     
>>>    List as described in [RFC2131] and [RFC2132].
>>>
>>>    The DHCPv4 client MUST try the records in the order 
>>>       
>> listed in the PAA
>>     
>>>    DHCPv4 option."
>>>
>>> To:
>>>
>>>    "A PaC (DHCPv4 client) SHOULD request the PAA DHCPv4 Option in a
>>>    Parameter Request List as described in [RFC2131] and [RFC2132].
>>>
>>>    If configured with a (list of) PAA address(es), a DHCPv4 
>>>       
>> server SHOULD
>>     
>>>    send a client with the PAA DHCPv4 option, even if this 
>>>       
>> option is not
>>     
>>>    explicitly requested by the client.
>>>
>>>    A PaC (DHCPv4 client) receiving the PAA DHCPv4 option 
>>>       
>> SHOULD use the
>>     
>>>    (list of) IP address(es) to locate PAA.
>>>
>>>    The PaC (DHCPv4 client) MUST try the records in the 
>>>       
>> order listed in 
>>     
>>>    the PAA DHCPv4 option received from the DHCPv4 server."
>>>
>>> #4- At the end of the section 5 (DHCPv6 option), revise the 
>>>       
>> text to clarify the client/server behavior:
>>     
>>> From:
>>>
>>>    "A DHCPv6 client requests the PAA DHCPv6 option in an 
>>>       
>> Options Request
>>     
>>>    Option (ORO) as described in the DHCPv6 specification [RFC3315].
>>>
>>>    The DHCPv6 client MUST try the records in the order 
>>>       
>> listed in the PAA
>>     
>>>    DHCPv6 option."
>>>
>>> To:
>>>
>>>    "A PaC (DHCPv6 client) SHOULD request the PAA DHCPv6 option in an
>>>    Options Request Option (ORO) as described in the DHCPv6 
>>>       
>> specification
>>     
>>>    [RFC3315].
>>>
>>>    If configured with a (list of) PAA address(es), a DHCPv6 
>>>       
>> server SHOULD
>>     
>>>    send a client with the PAA DHCPv6 option, even if this 
>>>       
>> option is not
>>     
>>>    explicitly requested by the client.
>>>
>>>    A PaC (DHCPv6 client) receiving the PAA DHCPv6 option 
>>>       
>> SHOULD use the
>>     
>>>    (list of) IP address(es) to locate PAA.
>>>
>>>    The PaC (DHCPv6 client) MUST try the records in the 
>>>       
>> order listed in the
>>     
>>>    PAA DHCPv6 option."
>>>
>>>
>>>
>>>
>>>   
>>>       
>>>> -----Message d'origine-----
>>>> De : Jari Arkko [mailto:jari.arkko at piuha.net] Envoyé : mardi 31 
>>>> octobre 2006 12:22 À : Alper Yegin; MORAND Lionel RD-CORE-ISS Cc : 
>>>> pana at ietf.org Objet : Re: [Pana] AD review of 
>>>> draft-ietf-dhc-paa-option-04.txt
>>>>
>>>> I am fine with the approach that the option is merely for 
>>>>         
>> PAA address 
>>     
>>>> discovery, not affecting whether PANA is on or not.
>>>> But I would like that to be explicitly stated in the document. It 
>>>> would also be useful to have a warning that there are 
>>>>         
>> issues if you 
>>     
>>>> attempt to do otherwise.
>>>>
>>>> Changes needed to state are likely fairly small.
>>>> If you submit the draft it probably appears when the IETF 
>>>>         
>> starts and 
>>     
>>>> I can move the draft along after that.
>>>>     
>>>>         
>>>>> "A PaC SHOULD request the PAA DHCPv4 Option in a 
>>>>>           
>> Parameter Request 
>>     
>>>>> List as described in [RFC2131] and [RFC2132].
>>>>> If configured with a (list of) PAA address(es), a DHCPv4
>>>>>       
>>>>>           
>>>> server SHOULD
>>>>     
>>>>         
>>>>> send a client with the PAA DHCPv4 option, even if this
>>>>>       
>>>>>           
>>>> option is not
>>>>     
>>>>         
>>>>> explicitly requested by the client."
>>>>>       
>>>>>           
>>>> This is a start. It defines what the nodes do, but I would 
>>>>         
>> also like 
>>     
>>>> to see
>>>>
>>>> 1) What the PaC does when it receives the option
>>>> 2) Explanation that the option is not used for turning 
>>>>         
>> PANA on/off, 
>>     
>>>> along with the warning
>>>>
>>>> --Jari
>>>>
>>>>
>>>>     
>>>>         
>>>   
>>>       
>>     
>
>
>   


_______________________________________________
Pana mailing list
Pana at ietf.org
https://www1.ietf.org/mailman/listinfo/pana