Re: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt
Jari Arkko <jari.arkko@piuha.net> Sun, 17 December 2006 16:17 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvyhT-0003PE-U2; Sun, 17 Dec 2006 11:17:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvyhS-0003P7-1t for pana@ietf.org; Sun, 17 Dec 2006 11:17:18 -0500
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvyhR-0003qY-Bk for pana@ietf.org; Sun, 17 Dec 2006 11:17:18 -0500
Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9EAA289895; Sun, 17 Dec 2006 18:17:11 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 42E0889892; Sun, 17 Dec 2006 18:17:11 +0200 (EET)
Message-ID: <45856D89.9010700@piuha.net>
Date: Sun, 17 Dec 2006 18:17:13 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.8 (X11/20061117)
MIME-Version: 1.0
To: MORAND Lionel RD-CORE-ISS <lionel.morand@orange-ftgroup.com>
Subject: Re: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt
References: <7DBAFEC6A76F3E42817DF1EBE64CB02604276546@FTRDMEL2.rd.francetelecom.fr>
In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02604276546@FTRDMEL2.rd.francetelecom.fr>
Content-Type: text/plain; charset="ISO-8859-1"
X-Virus-Scanned: ClamAV using ClamSMTP
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fe105289edd72640d9f392da880eefa2
Cc: pana@ietf.org
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
Errors-To: pana-bounces@ietf.org
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@piuha.net] >> Envoyé : mercredi 13 décembre 2006 11:24 >> À : MORAND Lionel RD-CORE-ISS >> Cc : Alper Yegin; pana@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@piuha.net] Envoyé : mardi 31 >>>> octobre 2006 12:22 À : Alper Yegin; MORAND Lionel RD-CORE-ISS Cc : >>>> pana@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@ietf.org https://www1.ietf.org/mailman/listinfo/pana
- [Pana] AD review of draft-ietf-dhc-paa-option-04.… Jari Arkko
- RE: [Pana] AD review of draft-ietf-dhc-paa-option… Alper Yegin
- RE: [Pana] AD review of draft-ietf-dhc-paa-option… MORAND Lionel RD-CORE-ISS
- Re: [Pana] AD review of draft-ietf-dhc-paa-option… Jari Arkko
- RE: [Pana] AD review of draft-ietf-dhc-paa-option… MORAND Lionel RD-CORE-ISS
- RE: [Pana] AD review of draft-ietf-dhc-paa-option… Alper Yegin
- Re: [Pana] AD review of draft-ietf-dhc-paa-option… Jari Arkko
- Re: [Pana] AD review of draft-ietf-dhc-paa-option… Jari Arkko
- RE: [Pana] AD review of draft-ietf-dhc-paa-option… MORAND Lionel RD-CORE-ISS
- Re: [Pana] AD review of draft-ietf-dhc-paa-option… Jari Arkko
- RE: [Pana] AD review of draft-ietf-dhc-paa-option… Alper Yegin
- Re: [Pana] AD review of draft-ietf-dhc-paa-option… Jari Arkko
- RE: [Pana] AD review of draft-ietf-dhc-paa-option… MORAND Lionel RD-CORE-ISS