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

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Dec 2006 12:24:25 +0200

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:[email-masked]] 
>> Envoyé : mardi 31 octobre 2006 12:22
>> À : Alper Yegin; MORAND Lionel RD-CORE-ISS
>> Cc : [email-masked]
>> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Dec 2006 12:24:30 +0200

> Would replacing the second sentence with the one below improve clarity?
>
> 	Presence of these DHCP options does not indicate PANA must be used
> in 
> 	the network.
>   
I prefer Lionel's text on this. If you wanted
to write it in the above way, I think you
should add also the part about lack of
these options not indicating PANA is
not needed.

--Jari

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Mon, 18 Dec 2006 09:50:55 +0100

Thanks for your feedback!
I will submit the new draft version today.

Lionel

> Envoyé : lundi 18 décembre 2006 06:59
> À : Alper Yegin
> Cc : MORAND Lionel RD-CORE-ISS; [email-masked]
> This works for me too.
> Alper Yegin kirjoitti:
> > I think it is best if we didn't get into "L2 point of view 
> security," etc.
> > I'd like to suggest this re-write instead:
> >
> >
> > In most of the networks, the DHCP exchange that delivers 
> the options 
> > prior to network access authentication is neither integrity 
> protected 
> > nor origin authenticated. 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, using the 
> presence (or 
> > absence) of these DHCP options as an indication of network 
> mandating 
> > PANA authentication (or not) is such a negotiation. This 
> negotiation 
> > would allow bidding down attacks by making the clients 
> choose to use a 
> > lower-grade security mechanism (or even no security at all).
> >
> > Alper
> >
> >
> >   
> >> -----Original Message-----
> >> From: MORAND Lionel RD-CORE-ISS 
> >> [mailto:[email-masked]]
> >> Sent: Friday, December 15, 2006 7:53 PM
> >> To: Jari Arkko
> >> Cc: Alper Yegin; [email-masked]
> >> Subject: RE: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt
> >>
> >> 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
> >>
> >>
> >>     
> >>> De : Jari Arkko [mailto:[email-masked]] Envoyé : 
> mercredi 13 
> >>> décembre 2006 11:24 À : MORAND Lionel RD-CORE-ISS Cc : 
> Alper Yegin; 
> >>> [email-masked] 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
> >>>
> >>>> 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
> >>>       
> >>>>    "This document specifies DHCPv4 [RFC2131] and DHCPv6
> >>>>         
> >>> [RFC3315] options
> >>>       
> >>>>    that allow PANA client (PaC) to discover PANA
> >>>>         
> >>> Authentication Agents
> >>>       
> >>>> #2- in the introduction (section 1), extend the existing
> >>>>         
> >>> section with the following text:
> >>>       
> >>>>    discovery mechanism. These DHCP options MUST NOT be used
> >>>>         
> >>> to perform
> >>>       
> >>>> #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
> >>>       
> >>>>    The DHCPv4 client MUST try the records in the order
> >>>>         
> >>> listed in the PAA
> >>>       
> >>>>    DHCPv4 option."
> >>>>
> >>>> To:
> >>>>
> >>>>    A PaC (DHCPv4 client) receiving the PAA DHCPv4 option
> >>>>         
> >>> SHOULD use the
> >>>       
> >>>>    The PaC (DHCPv4 client) MUST try the records in the
> >>>>         
> >>> order listed in
> >>>       
> >>>> #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
> >>>       
> >>>>    The DHCPv6 client MUST try the records in the order
> >>>>         
> >>> listed in the PAA
> >>>       
> >>>>    DHCPv6 option."
> >>>>
> >>>> To:
> >>>>
> >>>>    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
> >>>       
> >>>>    A PaC (DHCPv6 client) receiving the PAA DHCPv6 option
> >>>>         
> >>> SHOULD use the
> >>>       
> >>>>    The PaC (DHCPv6 client) MUST try the records in the
> >>>>         
> >>> order listed in the
> >>>       
> >>>>    PAA DHCPv6 option."
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>         
> >>>>> De : Jari Arkko [mailto:[email-masked]] Envoyé : mardi 31 
> >>>>> octobre 2006 12:22 À : Alper Yegin; MORAND Lionel 
> RD-CORE-ISS Cc :
> >>>>> [email-masked] 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.
> document. It 
> >>>>> would also be useful to have a warning that there are
> >>>>>           
> >>> issues if you
> >>>       
> >>>>> attempt to do otherwise.
> >>>>>
> >>> starts and
> >>>>> I can move the draft along after that.
> >>>>>
> >>>>>           
> >>>>>> "A PaC SHOULD request the PAA DHCPv4 Option in a
> >>>>>>             
> >>> Parameter Request
> >>>       
> >>> also like
> >>>>> to see
> >>>>> 2) Explanation that the option is not used for turning
> >>>>>           
> >>> PANA on/off,
> >>>       
> >>>>> along with the warning
> >>>>>
> >>>>> --Jari
> >>>>>
> >>>>>
> >>>>>
> >>>>>           
> >>>>
> >>>>         
> >>>       
> >
> >
> >
> >   
> 
>