From walliebaldwin@riscom.com Sun Jun 04 00:37:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmkMu-0000QX-Ie for pana-archive@lists.ietf.org; Sun, 04 Jun 2006 00:37:40 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmkMu-0005oD-Gj for pana-archive@lists.ietf.org; Sun, 04 Jun 2006 00:37:40 -0400 Received: from [60.52.56.254] (helo=BABY) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FmkLx-0005Jj-Rm for pana-archive@lists.ietf.org; Sun, 04 Jun 2006 00:37:40 -0400 Message-Id: <00ef01c68786$f7d5f700$dc063ea9@idfzi> From: "branden esposito" To: "leanna dorsey" Subject: Need cash, disk-bearing Date: Sat, 03 Jun 2006 23:28:52 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EF_01C68786.F7D5F700" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -1.3 (-) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is a multi-part message in MIME format. ------=_NextPart_000_00EF_01C68786.F7D5F700 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How much are you paying for your Home? To much?=20 You have been pre-approved to fill out for a ref inance laon,=20 if you need some cash to spend ANY way you like, or simply wish=20 to LOWER your monthly payments by a third or more, etc. We skip the middle man to save hundreds with deals we have!=20 This offer is for you, we DONT CARE about your credit.=20 Apply online now for your instant quote. Stop over paying...=20 http://gadst.org/d2/ messiah religion harvest lord strangler tree Kremnitz white biscuit porcela= in currant sawfly box shutter sea kittie dollar chaser gas cutting three-celled apple aphid medical man one-hundred-percenter pseudo martyrdom scale wax moderator lamp leaf-strewn six-foiled serous membrane squaw vine bull birch Panama rubber slow-foot dish wagon Sault whitefish spiric body elevator girl well-dissected sea cow five-acre ------=_NextPart_000_00EF_01C68786.F7D5F700 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
How much are you paying for your Home? To much?
You have been pre-approved to fill out for a ref inance laon,
if you need some cash to spend ANY way you like, or simply wish
to LOWER your monthly payments by a third or more, etc.

We skip the middle man to save hundreds with deals we have!
This offer is for you, we DONT CARE about your credit.

Apply online now for your instant quote. Stop over paying...

http://gadst.org/d2/

messiah religion harvest lord strangler tree Kremnitz white biscuit porcela= in
currant sawfly box shutter
sea kittie dollar chaser gas cutting three-celled apple aphid medical man one-hundred-percenter pseudo martyrdom scale wax moderator lamp leaf-strewn=
six-foiled serous membrane squaw vine
bull birch Panama rubber slow-foot
dish wagon Sault whitefish spiric body elevator girl well-dissected
sea cow five-acre
= ------=_NextPart_000_00EF_01C68786.F7D5F700-- From pana-bounces@ietf.org Tue Jun 06 05:18:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnXhs-00039v-PR; Tue, 06 Jun 2006 05:18:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnXhr-00039q-QT for pana@ietf.org; Tue, 06 Jun 2006 05:18:35 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnXho-0006ii-NX for pana@ietf.org; Tue, 06 Jun 2006 05:18:35 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0F00L7DM0OIP@szxga03-in.huawei.com> for pana@ietf.org; Tue, 06 Jun 2006 17:22:00 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0F00I5NM0OD4@szxga03-in.huawei.com> for pana@ietf.org; Tue, 06 Jun 2006 17:22:00 +0800 (CST) Received: from z49940 ([10.164.5.43]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0F00MODLN92U@szxml03-in.huawei.com> for pana@ietf.org; Tue, 06 Jun 2006 17:14:05 +0800 (CST) Date: Tue, 06 Jun 2006 17:12:52 +0800 From: selina To: pana@ietf.org Message-id: <000001c68949$67312610$2b05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Pana] PAA and EP authenticate? X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hello,everyone: I have a question.whether the communication between PAA and EP is security?Before PAA sends authorization information to EP, whether EP should be authenticated by PAA?I read the document and couldn't find the answer , who can tell me how to do it or where is the answer in the document? Selina Thanks _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Tue Jun 06 07:29:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnZkT-0001PZ-Pg; Tue, 06 Jun 2006 07:29:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnZkS-0001PU-83 for pana@ietf.org; Tue, 06 Jun 2006 07:29:24 -0400 Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnZkQ-0003sK-RK for pana@ietf.org; Tue, 06 Jun 2006 07:29:24 -0400 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k56BT39f010379; Tue, 6 Jun 2006 13:29:03 +0200 Received: from [172.25.78.35] ([172.25.78.35]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006060613290138:3923 ; Tue, 6 Jun 2006 13:29:01 +0200 Message-ID: <448566FE.1070704@alcatel.fr> Date: Tue, 06 Jun 2006 13:29:02 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: selina Subject: Re: [Pana] PAA and EP authenticate? References: <000001c68949$67312610$2b05a40a@china.huawei.com> In-Reply-To: <000001c68949$67312610$2b05a40a@china.huawei.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 06/06/2006 13:29:01, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 06/06/2006 13:29:02, Serialize complete at 06/06/2006 13:29:02 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hello Selina, SNMPv3 ensures PAA-EP security: PAA and EP authenticates each other thanks to pre-placed private keys. See RFC3411. yacine selina wrote: > Hello,everyone: > I have a question.whether the communication between PAA and EP > is security?Before PAA sends authorization information to EP, whether EP > should be authenticated by PAA?I read the document and couldn't find the > answer , who can tell me how to do it or where is the answer in the > document? > > Selina > Thanks > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Tue Jun 06 11:51:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FndqS-0002a6-7q; Tue, 06 Jun 2006 11:51:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FndqR-0002a1-0M for pana@ietf.org; Tue, 06 Jun 2006 11:51:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FndqQ-0001WY-VB for pana@ietf.org; Tue, 06 Jun 2006 11:51:50 -0400 Received: from mout.perfora.net ([217.160.230.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fndbj-0006MC-Rd for pana@ietf.org; Tue, 06 Jun 2006 11:36:43 -0400 Received: from [193.92.180.241] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1Fndbc1dRP-0006lx; Tue, 06 Jun 2006 11:36:36 -0400 From: "Alper Yegin" To: Date: Tue, 6 Jun 2006 08:36:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcaJfvOC9sxHCUUkTXWA5xO2188lDw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-ID: <0MKp2t-1Fndbc1dRP-0006lx@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: -2.3 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'Mark Townsley' , 'Jari Arkko' Subject: [Pana] IETF LC and discussion: Next steps X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Following the IETF last call and IETF mailing list discussions, we had a tele-chat with the ADs and identified a list of technical considerations for the PANA WG to discuss. The issues are mostly driven by the document readability and protocol complexity. We are asked to consider the following questions and make a decision. The decisions will be reflected on the documents before they proceed to the IESG review. We'll conclude the relevant discussions "before" the next IETF. For that, please participate in the discussions. Act now -- last minute surprises or late-comers are not welcome! Each point should be discussed under a separate thread. If you are the first one to tackle a question, start a new thread. With that in mind: [1] Can we remove the discovery part of the base specification? Can we mandate the DHCP-based discovery as specified in a separate document? [2] Do we really need to acknowledge PAA and EP separation and reflect it on the protocol design? [3] Do we need to specify PAA-to-EP protocol? Can't we mark it as out of scope and not specify anything? Some people have concerns about using SNMP for configuration. [4] Can we drop PANA-IPsec? Can't we only consider cases where the lower-layer is already secured? [5] Can we drop the enabling L2 security from the specs? People can still do that, but we'd avoid its discussion in the specs (which has raised many concerns, e.g., IEEE 802.11) [6] Can we remove the NAP-ISP separation support from the base spec? [7] Can we refocus and simplify the PANA framework document? For example, we can highlight the network access authentication aspect, and dim others (such as network selection, secure association, etc.). Also, we can remove section 10 (DSL and WiFi deployments). Chairs _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Tue Jun 06 14:15:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fng50-0008Of-64; Tue, 06 Jun 2006 14:15:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fng4y-0008NF-M3 for pana@ietf.org; Tue, 06 Jun 2006 14:15:00 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fng4w-0001UC-QW for pana@ietf.org; Tue, 06 Jun 2006 14:15:00 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k56IEsFT006934; Wed, 7 Jun 2006 03:14:54 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k56IGHuT019108; Wed, 7 Jun 2006 03:16:17 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id DAA19081; Wed, 7 Jun 2006 03:16:17 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k56IErdG003628; Wed, 7 Jun 2006 03:14:53 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k56IErdL011976; Wed, 7 Jun 2006 03:14:53 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0G00J86AONX1K0@mail.po.toshiba.co.jp>; Wed, 07 Jun 2006 03:14:53 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1Fng4c-0003eO-SA; Tue, 06 Jun 2006 11:14:38 -0700 Date: Tue, 06 Jun 2006 14:14:38 -0400 From: Yoshihiro Ohba Subject: Refocusing/simplifying pana-framework [was Re: [Pana] IETF LC and discussion: Next steps] To: Alper Yegin Mail-followup-to: Alper Yegin , pana@ietf.org, 'Mark Townsley' , 'Jari Arkko' Message-id: <20060606181438.GA13466@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'Mark Townsley' , 'Jari Arkko' , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org > > [7] Can we refocus and simplify the PANA framework document? For example, we > can highlight the network access authentication aspect, and dim others (such > as network selection, secure association, etc.). Also, we can remove section > 10 (DSL and WiFi deployments). > Looking at the recent IETF mailing list discussion, focusing on authentication aspect seems necessary for broader acceptance of the PANA framework draft. - Network selection section (Section 8) should be removed if NAP and ISP separate authentication is removed from the base specification. - Data traffic protection section (Section 6) can be removed because Section 4 also has brief text on enabling per-packet ciphering. - IP address configuration section (Section 5) should be described in the base specification because it contains several MUST/SHOULD. - I agree to remove Section 10. Some of the contents of Section 10 can be described in separate documents such as pana-ipsec and pana-ieee80211doti. Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Tue Jun 06 20:08:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnlb3-0006CE-Pi; Tue, 06 Jun 2006 20:08:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnlb2-0006C9-7M for pana@ietf.org; Tue, 06 Jun 2006 20:08:28 -0400 Received: from web80614.mail.yahoo.com ([66.94.235.81]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fnlaz-0005v3-Px for pana@ietf.org; Tue, 06 Jun 2006 20:08:28 -0400 Received: (qmail 38760 invoked by uid 60001); 7 Jun 2006 00:08:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ayxpGYF8G8+8wJsbFLsIvdLezXUlJKJdztvkgfW8xKrMiiFNYn8Rv3kdMxL4qhHtiT9yYKXPSvZzxLqRqBgGXXOFQ6uT2Qn/c0f1JQ3PtrnRlOAF1CUQuiXBpitbSxg52doUfgESoNkBQUg75a4sO4dH3b7+JfHXFU2tv7voJm4= ; Message-ID: <20060607000824.38758.qmail@web80614.mail.yahoo.com> Received: from [206.132.194.3] by web80614.mail.yahoo.com via HTTP; Tue, 06 Jun 2006 17:08:24 PDT Date: Tue, 6 Jun 2006 17:08:24 -0700 (PDT) From: Mohan Parthasarathy Subject: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) To: Alper Yegin , pana@ietf.org In-Reply-To: <0MKp2t-1Fndbc1dRP-0006lx@mrelay.perfora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: 'Mark Townsley' , 'Jari Arkko' X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org > [4] Can we drop PANA-IPsec? Can't we only consider > cases where the > lower-layer is already secured? > I am sort of neutral on this. There is a separate question about L2 security. If we drop that too, then PANA applies to only the physically secured link case which is very limiting. We were targeting informational for Pana-ipsec. If we are not really concerned about inter-op, then perhaps folks can figure out how to use IPsec without needing to read an RFC. I feel that L2 security makes more sense and probably we should keep that. -mohan _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Wed Jun 07 09:08:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnxlS-0004ED-Bi; Wed, 07 Jun 2006 09:08:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnxlQ-00047O-Sy for pana@ietf.org; Wed, 07 Jun 2006 09:08:00 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnxlN-0007dS-2u for pana@ietf.org; Wed, 07 Jun 2006 09:08:00 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k57D7ruH004050; Wed, 7 Jun 2006 22:07:53 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k57D9H1g006105; Wed, 7 Jun 2006 22:09:17 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id YAA06103; Wed, 7 Jun 2006 22:09:16 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k57D7r6k009880; Wed, 7 Jun 2006 22:07:53 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k57D7qmo012506; Wed, 7 Jun 2006 22:07:52 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0H00B7NR4ZS100@mail.po.toshiba.co.jp>; Wed, 07 Jun 2006 22:07:52 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1Fnxl6-0004SO-Kv; Wed, 07 Jun 2006 06:07:40 -0700 Date: Wed, 07 Jun 2006 09:07:40 -0400 From: Yoshihiro Ohba Subject: NAP and ISP separate authentication [was Re: [Pana] IETF LC and discussion: Next steps] In-reply-to: <0MKp2t-1Fndbc1dRP-0006lx@mrelay.perfora.net> To: Alper Yegin Mail-followup-to: Alper Yegin , pana@ietf.org, 'Mark Townsley' , 'Jari Arkko' Message-id: <20060607130740.GB16685@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <0MKp2t-1Fndbc1dRP-0006lx@mrelay.perfora.net> User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: 'Mark Townsley' , 'Jari Arkko' , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org > > [6] Can we remove the NAP-ISP separation support from the base spec? > I think we can remove NAP and ISP separate authentication from the base spec. Perhaps we can design the feature in more a generic way (e.g., allowing more than two EAP runs in parallel) in a separate document. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Wed Jun 07 10:59:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnzUz-0005TN-C3; Wed, 07 Jun 2006 10:59:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnzUx-0005Sp-MR for pana@ietf.org; Wed, 07 Jun 2006 10:59:07 -0400 Received: from smtp1.int-evry.fr ([157.159.10.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnzKn-0003Qw-Tw for pana@ietf.org; Wed, 07 Jun 2006 10:48:39 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp1.int-evry.fr (Postfix) with ESMTP id 5BD2D18D225; Wed, 7 Jun 2006 16:53:35 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FnzJD-0002gu-L6; Wed, 07 Jun 2006 16:46:59 +0200 Date: Wed, 7 Jun 2006 16:46:59 +0200 From: Julien Bournelle To: Mohan Parthasarathy Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) Message-ID: <20060607144659.GC10326@ipv6-3.int-evry.fr> References: <0MKp2t-1Fndbc1dRP-0006lx@mrelay.perfora.net> <20060607000824.38758.qmail@web80614.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060607000824.38758.qmail@web80614.mail.yahoo.com> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'Mark Townsley' , 'Jari Arkko' , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi all, On Tue, Jun 06, 2006 at 05:08:24PM -0700, Mohan Parthasarathy wrote: > > > > [4] Can we drop PANA-IPsec? Can't we only consider > > cases where the > > lower-layer is already secured? > > > I am sort of neutral on this. There is a separate > question about L2 security. If we drop that too, > then PANA applies to only the physically secured > link case which is very limiting. > > We were targeting informational for Pana-ipsec. > If we are not really concerned about inter-op, > then perhaps folks can figure out how to use IPsec > without needing to read an RFC. what's exactly the problem with keeping pana-ipsec ? > I feel that L2 security makes more sense and probably > we should keep that. I think we also need that but don't yet have WG document. Julien > > -mohan > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana -- julien.bournelle at int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Wed Jun 07 11:18:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnznS-0008UQ-Vd; Wed, 07 Jun 2006 11:18:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnznR-0008Q8-Ri for pana@ietf.org; Wed, 07 Jun 2006 11:18:13 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnznQ-0006vw-6c for pana@ietf.org; Wed, 07 Jun 2006 11:18:13 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k57FI8SW006020; Thu, 8 Jun 2006 00:18:08 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k57FJVP5010118; Thu, 8 Jun 2006 00:19:31 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id AAA10117; Thu, 8 Jun 2006 00:19:31 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k57FI7kV013193; Thu, 8 Jun 2006 00:18:07 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k57FI7Rm029869; Thu, 8 Jun 2006 00:18:07 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0H00B8HX61S140@mail.po.toshiba.co.jp>; Thu, 08 Jun 2006 00:18:07 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1Fnzn4-0004sF-GL; Wed, 07 Jun 2006 08:17:50 -0700 Date: Wed, 07 Jun 2006 11:17:50 -0400 From: Yoshihiro Ohba Subject: Re: NAP and ISP separate authentication [was Re: [Pana] IETF LC anddiscussion: Next steps] In-reply-to: <7DBAFEC6A76F3E42817DF1EBE64CB02603853DB1@FTRDMEL2.rd.francetelecom.fr> To: MORAND Lionel RD-CORE-ISS Mail-followup-to: MORAND Lionel RD-CORE-ISS , Yoshihiro Ohba , Alper Yegin , Mark Townsley , Jari Arkko , pana@ietf.org Message-id: <20060607151750.GA17637@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=euc-jp Content-disposition: inline References: <7DBAFEC6A76F3E42817DF1EBE64CB02603853DB1@FTRDMEL2.rd.francetelecom.fr> User-Agent: Mutt/1.5.11+cvs20060403 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ovp11.toshiba.co.jp id k57FI7kV013193 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Mark Townsley , Yoshihiro Ohba , Jari Arkko , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Lionel, There was a comment in IETF mailing list stating that NAP and ISP authentication is one part that adds complexity in the base specification. I agree with you on having the separate document for NAP and ISP authentication, probably in a generic way such as allowing more than two authentications in parallel. Regards, Yoshihiro Ohba On Wed, Jun 07, 2006 at 04:48:19PM +0200, MORAND Lionel RD-CORE-ISS wrote= : > What is the exact concern behind the request to remove this from the b= ase specification? There is a clear requirement to enable such a separate= authentication in a multi-players context and there are some proposals i= n other WG groups (e.g. EAP) to provide this functionaly at different lev= els. >=20 > If removing NAP/ISP authentication from the base spec would (maybe) sim= plify the scope of the specification, we should keep this option in a sep= arate document and define the required additional AVPs in the IANA contro= lled AVP Codes namespace. If it is the selected approach, I would propose= to provide the separate document along with the base protocol. >=20 > BR, >=20 > Lionel >=20 > -----Message d'origine----- > De : Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20 > Envoy=8F=AB=B1 : mercredi 7 juin 2006 15:08 > =8F=AA=A2 : Alper Yegin > Cc : 'Mark Townsley'; 'Jari Arkko'; pana@ietf.org > Objet : NAP and ISP separate authentication [was Re: [Pana] IETF LC and= discussion: Next steps] >=20 > >=20 > > [6] Can we remove the NAP-ISP separation support from the base spec? > >=20 >=20 > I think we can remove NAP and ISP separate authentication from the base= spec. Perhaps we can design the feature in more a generic way (e.g., al= lowing more than two EAP runs in parallel) in a separate document. >=20 > Yoshihiro Ohba >=20 > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana >=20 >=20 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Wed Jun 07 11:43:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0BO-0004Ya-AT; Wed, 07 Jun 2006 11:42:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0BN-0004XP-F5 for pana@ietf.org; Wed, 07 Jun 2006 11:42:57 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo0BM-0000Om-3B for pana@ietf.org; Wed, 07 Jun 2006 11:42:57 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2006 08:42:55 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="290680632:sNHT84756842" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k57FgtGP020084; Wed, 7 Jun 2006 08:42:55 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k57FgpJC010349; Wed, 7 Jun 2006 08:42:55 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 11:42:51 -0400 Received: from [10.83.1.98] ([10.83.1.98]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 11:42:50 -0400 Message-ID: <4486F3CF.30108@cisco.com> Date: Wed, 07 Jun 2006 17:42:07 +0200 From: Mark Townsley User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: MORAND Lionel RD-CORE-ISS , Yoshihiro Ohba , Alper Yegin , Mark Townsley , Jari Arkko , pana@ietf.org Subject: Re: NAP and ISP separate authentication [was Re: [Pana] IETF LC anddiscussion: Next steps] References: <7DBAFEC6A76F3E42817DF1EBE64CB02603853DB1@FTRDMEL2.rd.francetelecom.fr> <20060607151750.GA17637@steelhead> In-Reply-To: <20060607151750.GA17637@steelhead> Content-Type: text/plain; charset=EUC-JP Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Jun 2006 15:42:50.0972 (UTC) FILETIME=[08B149C0:01C68A49] DKIM-Signature: a=rsa-sha1; q=dns; l=2830; t=1149694975; x=1150558975; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:Mark=20Townsley=20 |Subject:Re=3A=20NAP=20and=20ISP=20separate=20authentication=20[was=20Re=3A=20[Pa na]=20IETF=20LC=20anddiscussion=3A=0A=20Next=20steps]; X=v=3Dcisco.com=3B=20h=3D9x0pmrojHShwGvZ7HHubnaF9d6I=3D; b=N8/UvOOe0K9QNcd5onI3RQYIZbWn9aOegX/v8mRXcNKZD2F6lZXDnTXLNT8g/U8KZse/zZac z18CDs5NpY4TCfxyfIHzxlweaB/XAzju5QoIo6hROKp7Qdi7bSzZYEGi; Authentication-Results: sj-dkim-7.cisco.com; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Yoshihiro Ohba wrote: > Hi Lionel, > > There was a comment in IETF mailing list stating that NAP and ISP > authentication is one part that adds complexity in the base > specification. > > I agree with you on having the separate document for NAP and ISP > authentication, probably in a generic way such as allowing more than > two authentications in parallel. > That sounds like a good plan to me. Anything that can reduce the complexity of the base specification will probably help the community digest PANA. There's more than one way to do that, moving things into a separate specification is a perfectly reasonable method (I had to do this myself back in 1998 to advance L2TP). I also like the idea of parallel, identical, authentication exchanges. This simplifies the protocol, particularly for the cases where two exchanges are unnecessary. There is precedent in other groups for advancing discovery separately from a base protocol (L2VPN/PWE3 and softwires, for example). Given that there are already multiple ways to do PANA discovery, I would consider pulling this out of the base specification as well, allowing it to advance as its own document. $0.02, - Mark > Regards, > Yoshihiro Ohba > > On Wed, Jun 07, 2006 at 04:48:19PM +0200, MORAND Lionel RD-CORE-ISS wrote: > >> What is the exact concern behind the request to remove this from the base specification? There is a clear requirement to enable such a separate authentication in a multi-players context and there are some proposals in other WG groups (e.g. EAP) to provide this functionaly at different levels. >> >> If removing NAP/ISP authentication from the base spec would (maybe) simplify the scope of the specification, we should keep this option in a separate document and define the required additional AVPs in the IANA controlled AVP Codes namespace. If it is the selected approach, I would propose to provide the separate document along with the base protocol. >> >> BR, >> >> Lionel >> >> -----Message d'origine----- >> De : Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] >> Envoy«± : mercredi 7 juin 2006 15:08 >> ª¢ : Alper Yegin >> Cc : 'Mark Townsley'; 'Jari Arkko'; pana@ietf.org >> Objet : NAP and ISP separate authentication [was Re: [Pana] IETF LC anddiscussion: Next steps] >> >> >>> [6] Can we remove the NAP-ISP separation support from the base spec? >>> >>> >> I think we can remove NAP and ISP separate authentication from the base spec. Perhaps we can design the feature in more a generic way (e.g., allowing more than two EAP runs in parallel) in a separate document. >> >> Yoshihiro Ohba >> >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www1.ietf.org/mailman/listinfo/pana >> >> >> > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Wed Jun 07 11:55:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0NR-0002MB-Ny; Wed, 07 Jun 2006 11:55:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0NQ-0002M6-Ia for pana@ietf.org; Wed, 07 Jun 2006 11:55:24 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo0NP-00028i-7f for pana@ietf.org; Wed, 07 Jun 2006 11:55:24 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id E36471FA8AC; Wed, 7 Jun 2006 17:55:19 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00779-01-81; Wed, 7 Jun 2006 17:55:19 +0200 (CEST) Received: from [207.3.232.157] (tari-dhcp157.research.telcordia.com [207.3.232.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id AB4EB1FA854; Wed, 7 Jun 2006 17:55:15 +0200 (CEST) Message-ID: <4486F69E.4090602@dif.um.es> Date: Wed, 07 Jun 2006 11:54:06 -0400 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Re: Refocusing/simplifying pana-framework [was Re: [Pana] IETF LC and discussion: Next steps] References: <20060606181438.GA13466@steelhead> In-Reply-To: <20060606181438.GA13466@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 'Mark Townsley' , 'Jari Arkko' , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Yoshi, I have been checking your proposed changes with the current text of PANA fwk. I agree with all of them. A minor comment below. >- I agree to remove Section 10. Some of the contents of Section 10 >can be described in separate documents such as pana-ipsec and >pana-ieee80211doti. > > I was wondering if a PANA-DSL scenario should be described also in a separated document because that is also included in section 10. >Regards, >Yoshihiro Ohba > >_______________________________________________ >Pana mailing list >Pana@ietf.org >https://www1.ietf.org/mailman/listinfo/pana > > > > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Wed Jun 07 12:07:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0ZP-0001lV-Ar; Wed, 07 Jun 2006 12:07:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0ZN-0001lM-K4 for pana@ietf.org; Wed, 07 Jun 2006 12:07:45 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo0ZM-0003Rf-7q for pana@ietf.org; Wed, 07 Jun 2006 12:07:45 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 18:07:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Refocusing/simplifying pana-framework [was Re: [Pana] IETF LCand discussion: Next steps] Date: Wed, 7 Jun 2006 18:07:08 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02603853E4F@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Refocusing/simplifying pana-framework [was Re: [Pana] IETF LCand discussion: Next steps] Thread-Index: AcaKSs7YU2GkUawWRkinOJKvK+l5JQAAWfMg From: "MORAND Lionel RD-CORE-ISS" To: "Rafa Marin Lopez" , "Yoshihiro Ohba" X-OriginalArrivalTime: 07 Jun 2006 16:07:37.0071 (UTC) FILETIME=[7E79FFF0:01C68A4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Mark Townsley , Jari Arkko , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org I think that the proposal is to have two separate documents describing = each network deployment scenario (DSL case and WLAN case).=20 -----Message d'origine----- De : Rafa Marin Lopez [mailto:rafa@dif.um.es]=20 Envoy=E9 : mercredi 7 juin 2006 17:54 =C0 : Yoshihiro Ohba Cc : 'Mark Townsley'; 'Jari Arkko'; pana@ietf.org Objet : Re: Refocusing/simplifying pana-framework [was Re: [Pana] IETF = LCand discussion: Next steps] Hi Yoshi, I have been checking your proposed changes with the current text of PANA = fwk. I agree with all of them. A minor comment below. >- I agree to remove Section 10. Some of the contents of Section 10 can = >be described in separate documents such as pana-ipsec and=20 >pana-ieee80211doti. > =20 > I was wondering if a PANA-DSL scenario should be described also in a = separated document because that is also included in section 10. >Regards, >Yoshihiro Ohba > >_______________________________________________ >Pana mailing list >Pana@ietf.org >https://www1.ietf.org/mailman/listinfo/pana > > > =20 > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Wed Jun 07 12:33:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0y6-0002Rv-Hg; Wed, 07 Jun 2006 12:33:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo0y5-0002Rq-Nh for pana@ietf.org; Wed, 07 Jun 2006 12:33:17 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo0y4-0006D6-8q for pana@ietf.org; Wed, 07 Jun 2006 12:33:17 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k57GXDjL002684; Wed, 7 Jun 2006 19:33:13 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 19:32:32 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 11:32:30 -0500 Received: from 172.21.155.88 ([172.21.155.88]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 7 Jun 2006 16:32:30 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 07 Jun 2006 19:32:33 +0300 Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) From: Basavaraj Patil To: ext Julien Bournelle , Mohan Parthasarathy Message-ID: Thread-Topic: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) Thread-Index: AcaKT/oeOI+jsPZDEdq6ugARJNUNiA== In-Reply-To: <20060607144659.GC10326@ipv6-3.int-evry.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Jun 2006 16:32:30.0788 (UTC) FILETIME=[F8CD2040:01C68A4F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 'Mark Townsley' , 'Jari Arkko' , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Inline: On 6/7/06 5:46 PM, "ext Julien Bournelle" wrote: > Hi all, > > > On Tue, Jun 06, 2006 at 05:08:24PM -0700, Mohan Parthasarathy wrote: >> >> >>> [4] Can we drop PANA-IPsec? Can't we only consider >>> cases where the >>> lower-layer is already secured? >>> >> I am sort of neutral on this. There is a separate >> question about L2 security. If we drop that too, >> then PANA applies to only the physically secured >> link case which is very limiting. >> >> We were targeting informational for Pana-ipsec. >> If we are not really concerned about inter-op, >> then perhaps folks can figure out how to use IPsec >> without needing to read an RFC. > > what's exactly the problem with keeping pana-ipsec ? The intent here is to simplify the PANA protocol. Does PANA without the IPsec part become hobbled or unusable? I don't think so. Without the IPsec part, PANA provides security that is equivalent to the http based logins at hotspots. For most scenarios, that may be sufficient. Additionally how realistic is it that a host will do IKE and setup an IPsec SA with the access network just for securing the user data traffic? If user data is critical, then the user will have VPNs or TLS to the server. So the use of IPsec is primarily for access control only. And since IPsec is optional we can possibly live without the specification being a core aspect of the PANA protocol. > >> I feel that L2 security makes more sense and probably >> we should keep that. > > I think we also need that but don't yet have WG document. We are trying to simplify the protocol by stripping out features that "MAY" be non-essential. So lets not add more now. -Raj > > Julien > >> >> -mohan >> >> >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Wed Jun 07 12:58:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1Mf-0007x8-3m; Wed, 07 Jun 2006 12:58:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo1Me-0007wr-AC for pana@ietf.org; Wed, 07 Jun 2006 12:58:40 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo1Mb-0002zn-VJ for pana@ietf.org; Wed, 07 Jun 2006 12:58:40 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2006 09:58:38 -0700 X-IronPort-AV: i="4.05,217,1146466800"; d="scan'208"; a="430090652:sNHT33888432" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k57GwbYV016012; Wed, 7 Jun 2006 09:58:37 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k57GwaIs028539; Wed, 7 Jun 2006 12:58:36 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 12:58:35 -0400 Received: from [10.83.1.98] ([10.83.1.98]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Jun 2006 12:58:35 -0400 Message-ID: <44870590.2020608@cisco.com> Date: Wed, 07 Jun 2006 18:57:52 +0200 From: Mark Townsley User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: MORAND Lionel RD-CORE-ISS Subject: Re: Refocusing/simplifying pana-framework [was Re: [Pana] IETF LCand discussion: Next steps] References: <7DBAFEC6A76F3E42817DF1EBE64CB02603853E4F@FTRDMEL2.rd.francetelecom.fr> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02603853E4F@FTRDMEL2.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Jun 2006 16:58:35.0472 (UTC) FILETIME=[9D6CF500:01C68A53] DKIM-Signature: a=rsa-sha1; q=dns; l=1956; t=1149699517; x=1150563517; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:Mark=20Townsley=20 |Subject:Re=3A=20Refocusing/simplifying=20pana-framework=20[was=20Re=3A=20[Pana]= 20IETF=09LCand=0A=20discussion=3A=20Next=20steps]; X=v=3Dcisco.com=3B=20h=3DMWhRd/nOuJ1BQWr+kaagMUJpJLE=3D; b=SFlf7/Qc6wm5LeN5qpz5Ri5scmM4xNK2RiCB97CseTZmfSgb5wGPq6NBv9+0i9hDgcycOkfM DvX9l06BEo9B7hWx01wBNPpfbETqPKYzIaiL73Q9dTNNjpG+3oeFdu3X; Authentication-Results: sj-dkim-4.cisco.com; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Yoshihiro Ohba , Jari Arkko , Rafa Marin Lopez , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org MORAND Lionel RD-CORE-ISS wrote: > I think that the proposal is to have two separate documents describing each network deployment scenario (DSL case and WLAN case). > That's probably a step in the right direction. It certainly makes it easier for someone considering use of your protocol in one of the particular scenarios to not have to wade through details about the other. - Mark > -----Message d'origine----- > De : Rafa Marin Lopez [mailto:rafa@dif.um.es] > Envoyé : mercredi 7 juin 2006 17:54 > À : Yoshihiro Ohba > Cc : 'Mark Townsley'; 'Jari Arkko'; pana@ietf.org > Objet : Re: Refocusing/simplifying pana-framework [was Re: [Pana] IETF LCand discussion: Next steps] > > Hi Yoshi, > > I have been checking your proposed changes with the current text of PANA fwk. > > I agree with all of them. A minor comment below. > > >> - I agree to remove Section 10. Some of the contents of Section 10 can >> be described in separate documents such as pana-ipsec and >> pana-ieee80211doti. >> >> >> > I was wondering if a PANA-DSL scenario should be described also in a separated document because that is also included in section 10. > > >> Regards, >> Yoshihiro Ohba >> >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www1.ietf.org/mailman/listinfo/pana >> >> >> >> >> > > > -- > ------------------------------------------------------ > Rafael Marin Lopez > Faculty of Computer Science-University of Murcia > 30071 Murcia - Spain > Telf: +34968367645 e-mail: rafa@dif.um.es > ------------------------------------------------------ > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Wed Jun 07 14:08:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2S1-0006v2-Ma; Wed, 07 Jun 2006 14:08:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo2S0-0006sl-8z for pana@ietf.org; Wed, 07 Jun 2006 14:08:16 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo2Ry-0003Wi-OX for pana@ietf.org; Wed, 07 Jun 2006 14:08:16 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id EBBDC1FA9D2; Wed, 7 Jun 2006 20:08:13 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12917-01-60; Wed, 7 Jun 2006 20:08:13 +0200 (CEST) Received: from [207.3.232.157] (tari-dhcp157.research.telcordia.com [207.3.232.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 4F8E91FAD56; Wed, 7 Jun 2006 20:08:06 +0200 (CEST) Message-ID: <448715C9.4090801@dif.um.es> Date: Wed, 07 Jun 2006 14:07:05 -0400 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ext Julien Bournelle , pana@ietf.org, Mohan Parthasarathy , 'Jari Arkko' , Rafa Marin Lopez , 'Mark Townsley' X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Raj, Currently PANA is supporting: a. Networks where a secure channel is already available prior to running PANA b. Networks where a secure channel is created after running PANA The general question would be whether we want PANA supporting both cases or not. To understand, are you saying PANA should not support b) in the base-spec? >> what's exactly the problem with keeping pana-ipsec ? >> >> > >The intent here is to simplify the PANA protocol. Does PANA without the >IPsec part become hobbled or unusable? I don't think so. Without the IPsec >part, PANA provides security that is equivalent to the http based logins at >hotspots. For most scenarios, that may be sufficient. >Additionally how realistic is it that a host will do IKE and setup an IPsec >SA with the access network just for securing the user data traffic? If user >data is critical, then the user will have VPNs or TLS to the server. So the >use of IPsec is primarily for access control only. And since IPsec is >optional we can possibly live without the specification being a core aspect >of the PANA protocol. > > >>>I feel that L2 security makes more sense and probably >>>we should keep that. >>> >>> >> I think we also need that but don't yet have WG document. >> >> > >We are trying to simplify the protocol by stripping out features that "MAY" >be non-essential. So lets not add more now. > > >-Raj > > > >> Julien >> >> >> >>>-mohan >>> >>> >>>_______________________________________________ >>>Pana mailing list >>>Pana@ietf.org >>>https://www1.ietf.org/mailman/listinfo/pana >>> >>> > > >_______________________________________________ >Pana mailing list >Pana@ietf.org >https://www1.ietf.org/mailman/listinfo/pana > > > > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Wed Jun 07 15:34:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3nb-0000OO-6F; Wed, 07 Jun 2006 15:34:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fo3nZ-0000OH-Pc for pana@ietf.org; Wed, 07 Jun 2006 15:34:37 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fo3nY-0005D9-3p for pana@ietf.org; Wed, 07 Jun 2006 15:34:37 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k57JYWHU029342; Thu, 8 Jun 2006 04:34:32 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k57JZtTP017157; Thu, 8 Jun 2006 04:35:55 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id EAA17136; Thu, 8 Jun 2006 04:35:55 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k57JYVe4010310; Thu, 8 Jun 2006 04:34:31 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k57JYUfm026439; Thu, 8 Jun 2006 04:34:30 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0I00BIE91AS1A0@mail.po.toshiba.co.jp>; Thu, 08 Jun 2006 04:34:30 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1Fo3mP-0005VI-3b; Wed, 07 Jun 2006 12:33:25 -0700 Date: Wed, 07 Jun 2006 15:33:25 -0400 From: Yoshihiro Ohba Subject: Discovery [was Re: [Pana] IETF LC and discussion: Next steps] In-reply-to: <0MKp2t-1Fndbc1dRP-0006lx@mrelay.perfora.net> To: Alper Yegin Mail-followup-to: Alper Yegin , pana@ietf.org, 'Mark Townsley' , 'Jari Arkko' Message-id: <20060607193324.GF17242@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <0MKp2t-1Fndbc1dRP-0006lx@mrelay.perfora.net> User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 'Mark Townsley' , 'Jari Arkko' , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org On Tue, Jun 06, 2006 at 08:36:17AM -0700, Alper Yegin wrote: > > [1] Can we remove the discovery part of the base specification? Can we > mandate the DHCP-based discovery as specified in a separate document? > Also, there is Mark's comment in another thread: > There is precedent in other groups for advancing discovery > separately from a base protocol (L2VPN/PWE3 and softwires, for > example). Given that there are already multiple ways to do PANA > discovery, I would consider pulling this out of the base > specification as well, allowing it to advance as its own document. Initially I thought discovery should be integral part of base specification. But going through comments in IETF mailing list (some person raised an issue on administrative scoped multicast in multi-hop environment and some person indicated anycast) and private discussion, now I have an impression that it might be good to define discovery in separate document(s). We can even define default preference among multiple discovery methods in a separate document. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jun 08 03:45:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoFCU-0002JM-KO; Thu, 08 Jun 2006 03:45:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoFCT-0002JH-1Y for pana@ietf.org; Thu, 08 Jun 2006 03:45:05 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoFCR-00072m-71 for pana@ietf.org; Thu, 08 Jun 2006 03:45:05 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0J00DAK78SFB@szxga03-in.huawei.com> for pana@ietf.org; Thu, 08 Jun 2006 15:53:17 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0J008FC78SX9@szxga03-in.huawei.com> for pana@ietf.org; Thu, 08 Jun 2006 15:53:16 +0800 (CST) Received: from z49940 ([10.164.5.43]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0J00KYF7AZMN@szxml04-in.huawei.com> for pana@ietf.org; Thu, 08 Jun 2006 15:54:44 +0800 (CST) Date: Thu, 08 Jun 2006 15:44:09 +0800 From: selina Subject: PAA-to-EP protocol ? (RE: [Pana] IETF LC and discussion: Next steps) In-reply-to: <0MKp2t-1Fndbc1dRP-0006lx@mrelay.perfora.net> To: pana@ietf.org Message-id: <000401c68acf$572650b0$2b05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi, everyone: > > [3] Do we need to specify PAA-to-EP protocol? Can't we mark > it as out of scope and not specify anything? Some people have > concerns about using SNMP for configuration. > I want to know the reason that SNMP is selected to act as PAA-to-EP protocol. And why the other protocols such as Radius/Diameter or COPS are not appropriate. Selina Thanks _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jun 08 05:00:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoGNS-0006xn-Li; Thu, 08 Jun 2006 05:00:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoGNR-0006xI-Bb for pana@ietf.org; Thu, 08 Jun 2006 05:00:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoFQm-0008Cz-CL for pana@ietf.org; Thu, 08 Jun 2006 03:59:52 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoFMQ-0000ou-IB for pana@ietf.org; Thu, 08 Jun 2006 03:55:24 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k587sp8v001990; Thu, 8 Jun 2006 10:55:02 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 10:54:26 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 02:54:22 -0500 Received: from 172.21.155.92 ([172.21.155.92]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 8 Jun 2006 07:54:23 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 08 Jun 2006 10:54:27 +0300 Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) From: Basavaraj Patil To: ext Rafa Marin Lopez Message-ID: Thread-Topic: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) Thread-Index: AcaK0MPVAkYQ7PbEEdqV1wARJNUNiA== In-Reply-To: <448715C9.4090801@dif.um.es> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Jun 2006 07:54:22.0482 (UTC) FILETIME=[C123D720:01C68AD0] X-Spam-Score: -2.6 (--) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: 'Mark Townsley' , ext Julien Bournelle , Mohan Parthasarathy , 'Jari Arkko' , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Rafa, Inline: On 6/7/06 9:07 PM, "ext Rafa Marin Lopez" wrote: > Hi Raj, > > Currently PANA is supporting: > > a. Networks where a secure channel is already available prior to > running PANA Raj> No need for a PANA-IPsec setup in this case. > > b. Networks where a secure channel is created after running PANA > Raj> The need for establishing a secure channel depends on the use case/scenario. Does PANA need to understand the underlying capability of the link (i.e in this case it is not secured)? Or does PANA basically enable network access and let the security for the user data be of no concern to PANA but to some other protocol? If a user needs to secure the data traffic, then its up to the user to establish a VPN or some other form of securing the traffic. What we should be more concerned about is if PANA authentication/authorization for network access is insufficient to prevent session hijacking and/or limit the ability to do access control. -Raj > > The general question would be whether we want PANA supporting both cases > or not. > > To understand, are you saying PANA should not support b) in the base-spec? What I am saying is that support for "b" is not a core aspect of PANA and hence need not be part of the base-spec. -Raj > >>> what's exactly the problem with keeping pana-ipsec ? >>> >>> >> >> The intent here is to simplify the PANA protocol. Does PANA without the >> IPsec part become hobbled or unusable? I don't think so. Without the IPsec >> part, PANA provides security that is equivalent to the http based logins at >> hotspots. For most scenarios, that may be sufficient. >> Additionally how realistic is it that a host will do IKE and setup an IPsec >> SA with the access network just for securing the user data traffic? If user >> data is critical, then the user will have VPNs or TLS to the server. So the >> use of IPsec is primarily for access control only. And since IPsec is >> optional we can possibly live without the specification being a core aspect >> of the PANA protocol. >> >> >>>> I feel that L2 security makes more sense and probably >>>> we should keep that. >>>> >>>> >>> I think we also need that but don't yet have WG document. >>> >>> >> >> We are trying to simplify the protocol by stripping out features that "MAY" >> be non-essential. So lets not add more now. >> >> >> -Raj >> >> >> >>> Julien >>> >>> >>> >>>> -mohan >>>> >>>> >>>> _______________________________________________ >>>> Pana mailing list >>>> Pana@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pana >>>> >>>> >> >> >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www1.ietf.org/mailman/listinfo/pana >> >> >> >> > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jun 08 05:59:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoHIt-0000Wo-UX; Thu, 08 Jun 2006 05:59:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoHIt-0000Wj-2H for pana@ietf.org; Thu, 08 Jun 2006 05:59:51 -0400 Received: from smtp1.int-evry.fr ([157.159.10.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoHIr-0007hB-LD for pana@ietf.org; Thu, 08 Jun 2006 05:59:51 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp1.int-evry.fr (Postfix) with ESMTP id 266E218D2FB; Thu, 8 Jun 2006 12:04:27 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FoHGm-0002wj-LT; Thu, 08 Jun 2006 11:57:40 +0200 Date: Thu, 8 Jun 2006 11:57:40 +0200 From: Julien Bournelle To: Basavaraj Patil Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) Message-ID: <20060608095740.GB11216@ipv6-3.int-evry.fr> References: <20060607144659.GC10326@ipv6-3.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ext Julien Bournelle , pana@ietf.org, Mohan Parthasarathy , 'Jari Arkko' , 'Mark Townsley' X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi all, On Wed, Jun 07, 2006 at 07:32:33PM +0300, Basavaraj Patil wrote: > >> > >> > >>> [4] Can we drop PANA-IPsec? Can't we only consider > >>> cases where the > >>> lower-layer is already secured? > >>> > >> I am sort of neutral on this. There is a separate > >> question about L2 security. If we drop that too, > >> then PANA applies to only the physically secured > >> link case which is very limiting. > >> > >> We were targeting informational for Pana-ipsec. > >> If we are not really concerned about inter-op, > >> then perhaps folks can figure out how to use IPsec > >> without needing to read an RFC. > > > > what's exactly the problem with keeping pana-ipsec ? > > The intent here is to simplify the PANA protocol. Does PANA without the > IPsec part become hobbled or unusable? I don't think so. Without the IPsec > part, PANA provides security that is equivalent to the http based logins at > hotspots. For most scenarios, that may be sufficient. agree. > Additionally how realistic is it that a host will do IKE and setup an IPsec > SA with the access network just for securing the user data traffic? If user > data is critical, then the user will have VPNs or TLS to the server. So the > use of IPsec is primarily for access control only. And since IPsec is > optional we can possibly live without the specification being a core aspect > of the PANA protocol. I didn't see pana-ipsec as a core aspect of the PANA protocol. We say that if you want to secure user data traffic between MN and the EP by IPsec, PANA can help you but you don't have to. Maybe I miss something ? Julien > > > > >> I feel that L2 security makes more sense and probably > >> we should keep that. > > > > I think we also need that but don't yet have WG document. > > We are trying to simplify the protocol by stripping out features that "MAY" > be non-essential. So lets not add more now. > > -Raj > > > > > Julien > > > >> > >> -mohan > >> > >> > >> _______________________________________________ > >> Pana mailing list > >> Pana@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pana > -- julien.bournelle at int-evry.fr _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jun 08 07:33:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoIl1-0004WM-Ak; Thu, 08 Jun 2006 07:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoIkz-0004W9-KO for pana@ietf.org; Thu, 08 Jun 2006 07:32:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoHuf-000223-0q for pana@ietf.org; Thu, 08 Jun 2006 06:38:53 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoHVa-0003dR-Vr for pana@ietf.org; Thu, 08 Jun 2006 06:12:59 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k58ACp0m007376; Thu, 8 Jun 2006 13:12:56 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 13:12:29 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 05:12:26 -0500 Received: from 172.21.155.92 ([172.21.155.92]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 8 Jun 2006 10:12:26 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 08 Jun 2006 13:12:30 +0300 Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) From: Basavaraj Patil To: ext Julien Bournelle Message-ID: Thread-Topic: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) Thread-Index: AcaK5AziS1oNKfbXEdqV1wARJNUNiA== In-Reply-To: <20060608095740.GB11216@ipv6-3.int-evry.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Jun 2006 10:12:26.0741 (UTC) FILETIME=[0AF17250:01C68AE4] X-Spam-Score: -2.6 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: 'Mark Townsley' , Mohan Parthasarathy , 'Jari Arkko' , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org On 6/8/06 12:57 PM, "ext Julien Bournelle" wrote: >> The intent here is to simplify the PANA protocol. Does PANA without the >> IPsec part become hobbled or unusable? I don't think so. Without the IPsec >> part, PANA provides security that is equivalent to the http based logins at >> hotspots. For most scenarios, that may be sufficient. > > agree. > >> Additionally how realistic is it that a host will do IKE and setup an IPsec >> SA with the access network just for securing the user data traffic? If user >> data is critical, then the user will have VPNs or TLS to the server. So the >> use of IPsec is primarily for access control only. And since IPsec is >> optional we can possibly live without the specification being a core aspect >> of the PANA protocol. > > I didn't see pana-ipsec as a core aspect of the PANA protocol. > We say that if you want to secure user data > traffic between MN and the EP by IPsec, PANA can help you but you don't > have to. Maybe I miss something ? I don't think you missed anything. It is true that currently the establishment of the IPsec SA between the PaC and the EP is optional and hence not a core aspect of the protocol. But within the context of PANA we have an I-D that explains how the SA is setup and the base spec/framework refers to this capability as well. If we were to say simply that securing user data is outside the scope of PANA, does it make the protocol any less useful? It is possible to have a document that explains how user-data is secured using IKE/IPsec with PANA as the authentication protocol as an Informational RFC but essentially not make PANA dependent on the existence of such a specification. -Raj > > Julien > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jun 08 11:39:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMbQ-0007gT-Gw; Thu, 08 Jun 2006 11:39:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMbO-0007gL-FS for pana@ietf.org; Thu, 08 Jun 2006 11:39:18 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoMbN-0002f2-08 for pana@ietf.org; Thu, 08 Jun 2006 11:39:18 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k58FcsPe018727; Thu, 8 Jun 2006 11:38:54 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Thu, 8 Jun 2006 11:38:46 -0400 To: Basavaraj Patil Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) Message-ID: <20060608153825.GA32462@steelhead> Mail-Followup-To: Basavaraj Patil , ext Rafa Marin Lopez , 'Mark Townsley' , ext Julien Bournelle , Mohan Parthasarathy , 'Jari Arkko' , pana@ietf.org References: <448715C9.4090801@dif.um.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 133 X-Spam-Score: -2.4 (--) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: ext Julien Bournelle , pana@ietf.org, Mohan Parthasarathy , 'Jari Arkko' , ext Rafa Marin Lopez , 'Mark Townsley' X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org On Thu, Jun 08, 2006 at 10:54:27AM +0300, Basavaraj Patil wrote: > > Hi Rafa, > > Inline: > > > On 6/7/06 9:07 PM, "ext Rafa Marin Lopez" wrote: > > > Hi Raj, > > > > Currently PANA is supporting: > > > > a. Networks where a secure channel is already available prior to > > running PANA > > Raj> No need for a PANA-IPsec setup in this case. > > > > > b. Networks where a secure channel is created after running PANA > > > > Raj> The need for establishing a secure channel depends on the use > case/scenario. Does PANA need to understand the underlying capability of the > link (i.e in this case it is not secured)? Or does PANA basically enable > network access and let the security for the user data be of no concern to > PANA but to some other protocol? > If a user needs to secure the data traffic, then its up to the user to > establish a VPN or some other form of securing the traffic. What we should > be more concerned about is if PANA authentication/authorization for network > access is insufficient to prevent session hijacking and/or limit the ability > to do access control. Protected PANA-Ping exchange would be effective to detect session hijacking. However, if users also care integrity and confidentiality of data packets and no VPN is used, the functionality to bootstrap per-packet ciphering is needed. As far as I understand, PANA proposal in 3GPP2 relied on this functionality. An issue here would be whether this general functionality (i.e., use of Protection-Capability AVP and PaC-EP-Master-Key) should be described in the base specification, or in a separate document in which case document structure (in terms of bootstrapping) could be: 1. Base specification draft 2. General bootstrapping per-pacet ciphering draft (defining Protection-Capability AVP and PaC-EP-Master-Key) 3. Lower-layer specific bootstrapping drafts (pana-ipsec, pana-ieee80211doti) Note that 2) is a small piece compared to other optional feature such as NAP and ISP separate authentication. Yoshihiro Ohba > > -Raj > > > > > The general question would be whether we want PANA supporting both cases > > or not. > > > > To understand, are you saying PANA should not support b) in the base-spec? > > What I am saying is that support for "b" is not a core aspect of PANA and > hence need not be part of the base-spec. > > -Raj > > > > >>> what's exactly the problem with keeping pana-ipsec ? > >>> > >>> > >> > >> The intent here is to simplify the PANA protocol. Does PANA without the > >> IPsec part become hobbled or unusable? I don't think so. Without the IPsec > >> part, PANA provides security that is equivalent to the http based logins at > >> hotspots. For most scenarios, that may be sufficient. > >> Additionally how realistic is it that a host will do IKE and setup an IPsec > >> SA with the access network just for securing the user data traffic? If user > >> data is critical, then the user will have VPNs or TLS to the server. So the > >> use of IPsec is primarily for access control only. And since IPsec is > >> optional we can possibly live without the specification being a core aspect > >> of the PANA protocol. > >> > >> > >>>> I feel that L2 security makes more sense and probably > >>>> we should keep that. > >>>> > >>>> > >>> I think we also need that but don't yet have WG document. > >>> > >>> > >> > >> We are trying to simplify the protocol by stripping out features that "MAY" > >> be non-essential. So lets not add more now. > >> > >> > >> -Raj > >> > >> > >> > >>> Julien > >>> > >>> > >>> > >>>> -mohan > >>>> > >>>> > >>>> _______________________________________________ > >>>> Pana mailing list > >>>> Pana@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/pana > >>>> > >>>> > >> > >> > >> _______________________________________________ > >> Pana mailing list > >> Pana@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pana > >> > >> > >> > >> > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jun 08 12:46:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNeC-00025N-1M; Thu, 08 Jun 2006 12:46:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNeA-00024g-Mc for pana@ietf.org; Thu, 08 Jun 2006 12:46:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoMxW-0006NY-Qa for pana@ietf.org; Thu, 08 Jun 2006 12:02:10 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoMoy-0002BS-3F for pana@ietf.org; Thu, 08 Jun 2006 11:53:22 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k58FrBT3018999; Thu, 8 Jun 2006 18:53:11 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 18:53:10 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 10:53:08 -0500 Received: from 172.21.151.152 ([172.21.151.152]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 8 Jun 2006 15:53:08 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 08 Jun 2006 18:53:11 +0300 Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) From: Basavaraj Patil To: ext Yoshihiro Ohba Message-ID: Thread-Topic: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) Thread-Index: AcaLE6Sr43M+pvcGEdq8FwARJNUNiA== In-Reply-To: <20060608153825.GA32462@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Jun 2006 15:53:08.0043 (UTC) FILETIME=[A2E899B0:01C68B13] X-Spam-Score: -2.6 (--) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: ext Julien Bournelle , pana@ietf.org, Mohan Parthasarathy , 'Jari Arkko' , ext Rafa Marin Lopez , 'Mark Townsley' X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Yoshi, On 6/8/06 6:38 PM, "ext Yoshihiro Ohba" wrote: > On Thu, Jun 08, 2006 at 10:54:27AM +0300, Basavaraj Patil wrote: >> >> Hi Rafa, >> >> Inline: >> >> >> On 6/7/06 9:07 PM, "ext Rafa Marin Lopez" wrote: >> >>> Hi Raj, >>> >>> Currently PANA is supporting: >>> >>> a. Networks where a secure channel is already available prior to >>> running PANA >> >> Raj> No need for a PANA-IPsec setup in this case. >> >>> >>> b. Networks where a secure channel is created after running PANA >>> >> >> Raj> The need for establishing a secure channel depends on the use >> case/scenario. Does PANA need to understand the underlying capability of the >> link (i.e in this case it is not secured)? Or does PANA basically enable >> network access and let the security for the user data be of no concern to >> PANA but to some other protocol? >> If a user needs to secure the data traffic, then its up to the user to >> establish a VPN or some other form of securing the traffic. What we should >> be more concerned about is if PANA authentication/authorization for network >> access is insufficient to prevent session hijacking and/or limit the ability >> to do access control. > > Protected PANA-Ping exchange would be effective to detect session > hijacking. I think this is what we really need to ensure is specified as part of core PANA protocol. > However, if users also care integrity and confidentiality > of data packets and no VPN is used, the functionality to bootstrap > per-packet ciphering is needed. This is optional as we have been said so in the past as well. And we need to de-couple this from the core PANA protocol. > As far as I understand, PANA proposal in 3GPP2 relied on this functionality. In the case of PP2 there is already capability to cipher traffic at the lower layer. So there is no reason to establish an IPsec SA for user traffic. But anyway, the PP2 discussion is irrelevant here and I don't want to go off on a tangent. > An issue here would be whether > this general functionality (i.e., use of Protection-Capability AVP and > PaC-EP-Master-Key) should be described in the base specification, or > in a separate document in which case document structure (in terms of > bootstrapping) could be: My view is that PANA should not be concerned at all about the user data protection (i.e using IPsec between the PaC and EP). > > 1. Base specification draft This I-D along with the capability that deals with sesssion hijacking (i.e protected PANA ping). > > 2. General bootstrapping per-pacet ciphering draft (defining > Protection-Capability AVP and > PaC-EP-Master-Key) I don't think this is needed. Per-packet ciphering and how this is enabled by PANA is not something that we want to get into. Not at this stage at least. > > 3. Lower-layer specific bootstrapping drafts (pana-ipsec, pana-ieee80211doti) These are informational and need not form a core aspect of what the WG should deliver. > > Note that 2) is a small piece compared to other optional feature such > as NAP and ISP separate authentication. Cheers, -Raj > > Yoshihiro Ohba > >> >> -Raj >> >>> >>> The general question would be whether we want PANA supporting both cases >>> or not. >>> >>> To understand, are you saying PANA should not support b) in the base-spec? >> >> What I am saying is that support for "b" is not a core aspect of PANA and >> hence need not be part of the base-spec. >> >> -Raj >> >>> >>>>> what's exactly the problem with keeping pana-ipsec ? >>>>> >>>>> >>>> >>>> The intent here is to simplify the PANA protocol. Does PANA without the >>>> IPsec part become hobbled or unusable? I don't think so. Without the IPsec >>>> part, PANA provides security that is equivalent to the http based logins at >>>> hotspots. For most scenarios, that may be sufficient. >>>> Additionally how realistic is it that a host will do IKE and setup an >>>> IPsec >>>> SA with the access network just for securing the user data traffic? If user >>>> data is critical, then the user will have VPNs or TLS to the server. So the >>>> use of IPsec is primarily for access control only. And since IPsec is >>>> optional we can possibly live without the specification being a core aspect >>>> of the PANA protocol. >>>> >>>> >>>>>> I feel that L2 security makes more sense and probably >>>>>> we should keep that. >>>>>> >>>>>> >>>>> I think we also need that but don't yet have WG document. >>>>> >>>>> >>>> >>>> We are trying to simplify the protocol by stripping out features that "MAY" >>>> be non-essential. So lets not add more now. >>>> >>>> >>>> -Raj >>>> >>>> >>>> >>>>> Julien >>>>> >>>>> >>>>> >>>>>> -mohan >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pana mailing list >>>>>> Pana@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/pana >>>>>> >>>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pana mailing list >>>> Pana@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/pana >>>> >>>> >>>> >>>> >>> >> >> >> _______________________________________________ >> Pana mailing list >> Pana@ietf.org >> https://www1.ietf.org/mailman/listinfo/pana >> > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jun 08 18:42:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoTDE-00020s-O0; Thu, 08 Jun 2006 18:42:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoTDD-00020n-Em for pana@ietf.org; Thu, 08 Jun 2006 18:42:47 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoTDC-00069E-N4 for pana@ietf.org; Thu, 08 Jun 2006 18:42:47 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k58MgNVC025887; Fri, 9 Jun 2006 07:42:23 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k58MhkcF005735; Fri, 9 Jun 2006 07:43:46 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id HAA05690; Fri, 9 Jun 2006 07:43:46 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k58MgMvU016189; Fri, 9 Jun 2006 07:42:22 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k58MgMX7007378; Fri, 9 Jun 2006 07:42:22 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0K002HOCEGEM70@mail.po.toshiba.co.jp>; Fri, 09 Jun 2006 07:42:22 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FoRFt-0000x7-0r; Thu, 08 Jun 2006 13:37:25 -0700 Date: Thu, 08 Jun 2006 16:37:24 -0400 From: Yoshihiro Ohba Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) In-reply-to: To: Basavaraj Patil Mail-followup-to: Basavaraj Patil , ext Yoshihiro Ohba , ext Julien Bournelle , pana@ietf.org, Mohan Parthasarathy , 'Jari Arkko' , ext Rafa Marin Lopez , 'Mark Townsley' Message-id: <20060608203724.GB3430@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20060608153825.GA32462@steelhead> User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: ext Julien Bournelle , ext Yoshihiro Ohba , pana@ietf.org, Mohan Parthasarathy , 'Jari Arkko' , ext Rafa Marin Lopez , 'Mark Townsley' X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Basavaraj, I have one comment. Please see below. On Thu, Jun 08, 2006 at 06:53:11PM +0300, Basavaraj Patil wrote: > > Hi Yoshi, > > > On 6/8/06 6:38 PM, "ext Yoshihiro Ohba" wrote: > > > On Thu, Jun 08, 2006 at 10:54:27AM +0300, Basavaraj Patil wrote: > >> > >> Hi Rafa, > >> > >> Inline: > >> > >> > >> On 6/7/06 9:07 PM, "ext Rafa Marin Lopez" wrote: > >> > >>> Hi Raj, > >>> > >>> Currently PANA is supporting: > >>> > >>> a. Networks where a secure channel is already available prior to > >>> running PANA > >> > >> Raj> No need for a PANA-IPsec setup in this case. > >> > >>> > >>> b. Networks where a secure channel is created after running PANA > >>> > >> > >> Raj> The need for establishing a secure channel depends on the use > >> case/scenario. Does PANA need to understand the underlying capability of the > >> link (i.e in this case it is not secured)? Or does PANA basically enable > >> network access and let the security for the user data be of no concern to > >> PANA but to some other protocol? > >> If a user needs to secure the data traffic, then its up to the user to > >> establish a VPN or some other form of securing the traffic. What we should > >> be more concerned about is if PANA authentication/authorization for network > >> access is insufficient to prevent session hijacking and/or limit the ability > >> to do access control. > > > > Protected PANA-Ping exchange would be effective to detect session > > hijacking. > > I think this is what we really need to ensure is specified as part of core > PANA protocol. > > > However, if users also care integrity and confidentiality > > of data packets and no VPN is used, the functionality to bootstrap > > per-packet ciphering is needed. > > This is optional as we have been said so in the past as well. And we need to > de-couple this from the core PANA protocol. > > > As far as I understand, PANA proposal in 3GPP2 relied on this functionality. > > In the case of PP2 there is already capability to cipher traffic at the > lower layer. So there is no reason to establish an IPsec SA for user > traffic. But anyway, the PP2 discussion is irrelevant here and I don't want > to go off on a tangent. > > > An issue here would be whether > > this general functionality (i.e., use of Protection-Capability AVP and > > PaC-EP-Master-Key) should be described in the base specification, or > > in a separate document in which case document structure (in terms of > > bootstrapping) could be: > > My view is that PANA should not be concerned at all about the user data > protection (i.e using IPsec between the PaC and EP). > > > > > 1. Base specification draft > > This I-D along with the capability that deals with sesssion hijacking (i.e > protected PANA ping). > > > > > 2. General bootstrapping per-pacet ciphering draft (defining > > Protection-Capability AVP and > > PaC-EP-Master-Key) > > I don't think this is needed. Per-packet ciphering and how this is enabled > by PANA is not something that we want to get into. Not at this stage at > least. > > > > > 3. Lower-layer specific bootstrapping drafts (pana-ipsec, pana-ieee80211doti) > > These are informational and need not form a core aspect of what the WG > should deliver. 3) is dependent on 2). So 3) cannot exist without 2). Yoshihiro Ohba > > > > > Note that 2) is a small piece compared to other optional feature such > > as NAP and ISP separate authentication. > > Cheers, > -Raj > > > > > Yoshihiro Ohba > > > >> > >> -Raj > >> > >>> > >>> The general question would be whether we want PANA supporting both cases > >>> or not. > >>> > >>> To understand, are you saying PANA should not support b) in the base-spec? > >> > >> What I am saying is that support for "b" is not a core aspect of PANA and > >> hence need not be part of the base-spec. > >> > >> -Raj > >> > >>> > >>>>> what's exactly the problem with keeping pana-ipsec ? > >>>>> > >>>>> > >>>> > >>>> The intent here is to simplify the PANA protocol. Does PANA without the > >>>> IPsec part become hobbled or unusable? I don't think so. Without the IPsec > >>>> part, PANA provides security that is equivalent to the http based logins at > >>>> hotspots. For most scenarios, that may be sufficient. > >>>> Additionally how realistic is it that a host will do IKE and setup an > >>>> IPsec > >>>> SA with the access network just for securing the user data traffic? If user > >>>> data is critical, then the user will have VPNs or TLS to the server. So the > >>>> use of IPsec is primarily for access control only. And since IPsec is > >>>> optional we can possibly live without the specification being a core aspect > >>>> of the PANA protocol. > >>>> > >>>> > >>>>>> I feel that L2 security makes more sense and probably > >>>>>> we should keep that. > >>>>>> > >>>>>> > >>>>> I think we also need that but don't yet have WG document. > >>>>> > >>>>> > >>>> > >>>> We are trying to simplify the protocol by stripping out features that "MAY" > >>>> be non-essential. So lets not add more now. > >>>> > >>>> > >>>> -Raj > >>>> > >>>> > >>>> > >>>>> Julien > >>>>> > >>>>> > >>>>> > >>>>>> -mohan > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Pana mailing list > >>>>>> Pana@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/pana > >>>>>> > >>>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Pana mailing list > >>>> Pana@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/pana > >>>> > >>>> > >>>> > >>>> > >>> > >> > >> > >> _______________________________________________ > >> Pana mailing list > >> Pana@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pana > >> > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jun 08 19:39:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoU5w-00064U-HB; Thu, 08 Jun 2006 19:39:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoU5v-00064M-Km for pana@ietf.org; Thu, 08 Jun 2006 19:39:19 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoU5u-0005GL-0k for pana@ietf.org; Thu, 08 Jun 2006 19:39:19 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k58NdF3L002659; Fri, 9 Jun 2006 08:39:15 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k58NedgE004120; Fri, 9 Jun 2006 08:40:39 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id JAA04119; Fri, 9 Jun 2006 08:40:38 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k58NdEQL020272; Fri, 9 Jun 2006 08:39:14 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k58NdEJj026303; Fri, 9 Jun 2006 08:39:14 +0900 (JST) Received: from steelhead ([172.30.24.47]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0K002DSF19EMB0@mail.po.toshiba.co.jp>; Fri, 09 Jun 2006 08:39:14 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FoU5U-0001Vo-Fa; Thu, 08 Jun 2006 16:38:52 -0700 Date: Thu, 08 Jun 2006 19:38:52 -0400 From: Yoshihiro Ohba Subject: PAA and EP separation [was Re: [Pana] IETF LC and discussion: Next steps] In-reply-to: <0MKp2t-1Fndbc1dRP-0006lx@mrelay.perfora.net> To: Alper Yegin Mail-followup-to: Alper Yegin , pana@ietf.org, 'Mark Townsley' , 'Jari Arkko' Message-id: <20060608233852.GC4985@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <0MKp2t-1Fndbc1dRP-0006lx@mrelay.perfora.net> User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: 'Mark Townsley' , 'Jari Arkko' , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org On Tue, Jun 06, 2006 at 08:36:17AM -0700, Alper Yegin wrote: > > [2] Do we really need to acknowledge PAA and EP separation and reflect it on > the protocol design? > IMO, this is an important functionality we should keep, considering modern wireless technologies that allows access points/base stations and their controllers to be separate entities. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jun 08 19:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoU92-0008PG-Df; Thu, 08 Jun 2006 19:42:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoU90-0008Hg-Vp for pana@ietf.org; Thu, 08 Jun 2006 19:42:30 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoU8z-0006ER-KE for pana@ietf.org; Thu, 08 Jun 2006 19:42:30 -0400 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.13.6/8.13.6) with ESMTP id k58NgSlh017501; Thu, 8 Jun 2006 16:42:28 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.13.6/8.12.11/Submit) with ESMTP id k58NgStg017498; Thu, 8 Jun 2006 16:42:28 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 8 Jun 2006 16:42:28 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Yoshihiro Ohba Subject: Re: PAA and EP separation [was Re: [Pana] IETF LC and discussion: Next steps] In-Reply-To: <20060608233852.GC4985@steelhead> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'Mark Townsley' , 'Jari Arkko' , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org HI, I cannot see PANA used in a CAPWAP environment. On Thu, 8 Jun 2006, Yoshihiro Ohba wrote: > On Tue, Jun 06, 2006 at 08:36:17AM -0700, Alper Yegin wrote: > > > > [2] Do we really need to acknowledge PAA and EP separation and reflect it on > > the protocol design? > > > > IMO, this is an important functionality we should keep, considering > modern wireless technologies that allows access points/base stations > and their controllers to be separate entities. > > Yoshihiro Ohba Regards, /david t. perkins _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jun 08 20:03:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoUSo-0002Ev-Iz; Thu, 08 Jun 2006 20:02:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoUSn-0002Eq-P3 for pana@ietf.org; Thu, 08 Jun 2006 20:02:57 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoUSm-00019Y-59 for pana@ietf.org; Thu, 08 Jun 2006 20:02:57 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k5902lxI019864; Fri, 9 Jun 2006 09:02:47 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k5904ASH023064; Fri, 9 Jun 2006 09:04:10 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id KAA23059; Fri, 9 Jun 2006 09:04:10 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k5902j5P005656; Fri, 9 Jun 2006 09:02:46 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k5902jkx027529; Fri, 9 Jun 2006 09:02:45 +0900 (JST) Received: from steelhead ([172.30.24.47]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0K002FTG4FEME0@mail.po.toshiba.co.jp>; Fri, 09 Jun 2006 09:02:45 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FoUSO-0001aP-34; Thu, 08 Jun 2006 17:02:32 -0700 Date: Thu, 08 Jun 2006 20:02:31 -0400 From: Yoshihiro Ohba Subject: Re: PAA and EP separation [was Re: [Pana] IETF LC and discussion: Next steps] In-reply-to: To: "David T. Perkins" Mail-followup-to: "David T. Perkins" , Yoshihiro Ohba , 'Mark Townsley' , 'Jari Arkko' , pana@ietf.org Message-id: <20060609000231.GA5958@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20060608233852.GC4985@steelhead> User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'Mark Townsley' , Yoshihiro Ohba , 'Jari Arkko' , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org There is no intention to use PANA in a CAPWAP environment where link-layer EAP transport is typically used. My point is that it is better to place enforcement points on edge devices while authentication agent does not have to be placed on the edge devices. Yoshihiro Ohba On Thu, Jun 08, 2006 at 04:42:28PM -0700, David T. Perkins wrote: > HI, > > I cannot see PANA used in a CAPWAP environment. > > On Thu, 8 Jun 2006, Yoshihiro Ohba wrote: > > On Tue, Jun 06, 2006 at 08:36:17AM -0700, Alper Yegin wrote: > > > > > > [2] Do we really need to acknowledge PAA and EP separation and reflect it on > > > the protocol design? > > > > > > > IMO, this is an important functionality we should keep, considering > > modern wireless technologies that allows access points/base stations > > and their controllers to be separate entities. > > > > Yoshihiro Ohba > > Regards, > /david t. perkins > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jun 08 20:51:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoVDW-0000Fj-R7; Thu, 08 Jun 2006 20:51:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoVDV-0000Au-4k for pana@ietf.org; Thu, 08 Jun 2006 20:51:13 -0400 Received: from web80607.mail.yahoo.com ([66.94.235.69]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FoVDT-0005TX-Kq for pana@ietf.org; Thu, 08 Jun 2006 20:51:13 -0400 Received: (qmail 39774 invoked by uid 60001); 9 Jun 2006 00:51:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GcNqb1huyoLORnCiUnauISqeH0SaidUX9VwD4xq3d0MWwcXtDDVp3yBvtUI8GEfArM+3XVz3V3j2jf6nIuGtwfYGf8V4LhJDF3v7eUL9y/oO1ID0uYo67KH235xs4rkLHl1iNzr6s+Sqk0pZrbFcFkPZOqJIJSZW4Hqa982GUQQ= ; Message-ID: <20060609005110.39772.qmail@web80607.mail.yahoo.com> Received: from [206.132.194.2] by web80607.mail.yahoo.com via HTTP; Thu, 08 Jun 2006 17:51:10 PDT Date: Thu, 8 Jun 2006 17:51:10 -0700 (PDT) From: Mohan Parthasarathy Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) To: Basavaraj Patil , ext Yoshihiro Ohba In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: ext Julien Bournelle , pana@ietf.org, Mohan Parthasarathy , 'Jari Arkko' , ext Rafa Marin Lopez , 'Mark Townsley' X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi, You need per-packet ciphering at L2 or L3 if the link-layer is not physically secured. Please see the threats document on why you need this. > > Protected PANA-Ping exchange would be effective to > detect session > > hijacking. > > I think this is what we really need to ensure is > specified as part of core > PANA protocol. > I don't know how this would work. How often you ping ? How does it work in PAA and EP separation case ? > > However, if users also care integrity and > confidentiality > > of data packets and no VPN is used, the > functionality to bootstrap > > per-packet ciphering is needed. > > This is optional as we have been said so in the past > as well. And we need to > de-couple this from the core PANA protocol. > How do you enforce that some malicious node is not getting free service without ciphering at L2 or L3 ? -mohan > > As far as I understand, PANA proposal in 3GPP2 > relied on this functionality. > > In the case of PP2 there is already capability to > cipher traffic at the > lower layer. So there is no reason to establish an > IPsec SA for user > traffic. But anyway, the PP2 discussion is > irrelevant here and I don't want > to go off on a tangent. > > > An issue here would be whether > > this general functionality (i.e., use of > Protection-Capability AVP and > > PaC-EP-Master-Key) should be described in the base > specification, or > > in a separate document in which case document > structure (in terms of > > bootstrapping) could be: > > My view is that PANA should not be concerned at all > about the user data > protection (i.e using IPsec between the PaC and EP). > > > > > 1. Base specification draft > > This I-D along with the capability that deals with > sesssion hijacking (i.e > protected PANA ping). > > > > > 2. General bootstrapping per-pacet ciphering draft > (defining > > Protection-Capability AVP and > > PaC-EP-Master-Key) > > I don't think this is needed. Per-packet ciphering > and how this is enabled > by PANA is not something that we want to get into. > Not at this stage at > least. > > > > > 3. Lower-layer specific bootstrapping drafts > (pana-ipsec, pana-ieee80211doti) > > These are informational and need not form a core > aspect of what the WG > should deliver. > > > > > Note that 2) is a small piece compared to other > optional feature such > > as NAP and ISP separate authentication. > > Cheers, > -Raj > > > > > Yoshihiro Ohba > > > >> > >> -Raj > >> > >>> > >>> The general question would be whether we want > PANA supporting both cases > >>> or not. > >>> > >>> To understand, are you saying PANA should not > support b) in the base-spec? > >> > >> What I am saying is that support for "b" is not a > core aspect of PANA and > >> hence need not be part of the base-spec. > >> > >> -Raj > >> > >>> > >>>>> what's exactly the problem with keeping > pana-ipsec ? > >>>>> > >>>>> > >>>> > >>>> The intent here is to simplify the PANA > protocol. Does PANA without the > >>>> IPsec part become hobbled or unusable? I don't > think so. Without the IPsec > >>>> part, PANA provides security that is equivalent > to the http based logins at > >>>> hotspots. For most scenarios, that may be > sufficient. > >>>> Additionally how realistic is it that a host > will do IKE and setup an > >>>> IPsec > >>>> SA with the access network just for securing > the user data traffic? If user > >>>> data is critical, then the user will have VPNs > or TLS to the server. So the > >>>> use of IPsec is primarily for access control > only. And since IPsec is > >>>> optional we can possibly live without the > specification being a core aspect > >>>> of the PANA protocol. > >>>> > >>>> > >>>>>> I feel that L2 security makes more sense and > probably > >>>>>> we should keep that. > >>>>>> > >>>>>> > >>>>> I think we also need that but don't yet have > WG document. > >>>>> > >>>>> > >>>> > >>>> We are trying to simplify the protocol by > stripping out features that "MAY" > >>>> be non-essential. So lets not add more now. > >>>> > >>>> > >>>> -Raj > >>>> > >>>> > >>>> > >>>>> Julien > >>>>> > >>>>> > >>>>> > >>>>>> -mohan > === message truncated === _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Fri Jun 09 03:28:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FobPh-0008HR-2a; Fri, 09 Jun 2006 03:28:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FobPf-0008HM-Ti for pana@ietf.org; Fri, 09 Jun 2006 03:28:11 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FobPd-0003T8-As for pana@ietf.org; Fri, 09 Jun 2006 03:28:11 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k597S4B3012041; Fri, 9 Jun 2006 10:28:04 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 10:28:05 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 02:28:01 -0500 Received: from 10.241.58.230 ([10.241.58.230]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 Jun 2006 07:28:01 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 09 Jun 2006 10:28:05 +0300 Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) From: Basavaraj Patil To: ext Mohan Parthasarathy , ext Yoshihiro Ohba Message-ID: Thread-Topic: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) Thread-Index: AcaLlj9Mfcr0zveJEdqNQgARJNUNiA== In-Reply-To: <20060609005110.39772.qmail@web80607.mail.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 07:28:01.0610 (UTC) FILETIME=[3D47AAA0:01C68B96] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: 'Mark Townsley' , ext Julien Bournelle , 'Jari Arkko' , ext Rafa Marin Lopez , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Mohan, On 6/9/06 3:51 AM, "ext Mohan Parthasarathy" wrote: > > Hi, > > You need per-packet ciphering at L2 or L3 if > the link-layer is not physically secured. Please > see the threats document on why you need this. No question about the vulnerabilities and threats that are exposed as a result of not ensuring security at the lower layers. But the point is if PANA needs to ensure that. PANA may enable it. But PANA need not be coupled tightly with the need for securing the user traffic. > > >>> Protected PANA-Ping exchange would be effective to >> detect session >>> hijacking. >> >> I think this is what we really need to ensure is >> specified as part of core >> PANA protocol. >> > I don't know how this would work. How often you > ping ? How does it work in PAA and EP separation > case ? Not clear about it. This was a proposal from Yoshi. > >>> However, if users also care integrity and >> confidentiality >>> of data packets and no VPN is used, the >> functionality to bootstrap >>> per-packet ciphering is needed. >> >> This is optional as we have been said so in the past >> as well. And we need to >> de-couple this from the core PANA protocol. >> > How do you enforce that some malicious node is > not getting free service without ciphering at > L2 or L3 ? You either rely on the existence of a L2 mechanism that is inherent to the link or you figure out some other means of enforcing access control which keeps malicious nodes from getting free service. So the question is: - Does PANA need to ensure that unsecured links have the ability to do access control? How would PANA be able to determine if a link is secure or not? Is there a way to figure that out? I don't think this can be easily accomplished. Because even if a link layer has the capability to cipher, it does not imply that it is enabled. -Raj > > -mohan > >>> As far as I understand, PANA proposal in 3GPP2 >> relied on this functionality. >> >> In the case of PP2 there is already capability to >> cipher traffic at the >> lower layer. So there is no reason to establish an >> IPsec SA for user >> traffic. But anyway, the PP2 discussion is >> irrelevant here and I don't want >> to go off on a tangent. >> >>> An issue here would be whether >>> this general functionality (i.e., use of >> Protection-Capability AVP and >>> PaC-EP-Master-Key) should be described in the base >> specification, or >>> in a separate document in which case document >> structure (in terms of >>> bootstrapping) could be: >> >> My view is that PANA should not be concerned at all >> about the user data >> protection (i.e using IPsec between the PaC and EP). >> >>> >>> 1. Base specification draft >> >> This I-D along with the capability that deals with >> sesssion hijacking (i.e >> protected PANA ping). >> >>> >>> 2. General bootstrapping per-pacet ciphering draft >> (defining >>> Protection-Capability AVP and >>> PaC-EP-Master-Key) >> >> I don't think this is needed. Per-packet ciphering >> and how this is enabled >> by PANA is not something that we want to get into. >> Not at this stage at >> least. >> >>> >>> 3. Lower-layer specific bootstrapping drafts >> (pana-ipsec, pana-ieee80211doti) >> >> These are informational and need not form a core >> aspect of what the WG >> should deliver. >> >>> >>> Note that 2) is a small piece compared to other >> optional feature such >>> as NAP and ISP separate authentication. >> >> Cheers, >> -Raj >> >>> >>> Yoshihiro Ohba >>> >>>> >>>> -Raj >>>> >>>>> >>>>> The general question would be whether we want >> PANA supporting both cases >>>>> or not. >>>>> >>>>> To understand, are you saying PANA should not >> support b) in the base-spec? >>>> >>>> What I am saying is that support for "b" is not a >> core aspect of PANA and >>>> hence need not be part of the base-spec. >>>> >>>> -Raj >>>> >>>>> >>>>>>> what's exactly the problem with keeping >> pana-ipsec ? >>>>>>> >>>>>>> >>>>>> >>>>>> The intent here is to simplify the PANA >> protocol. Does PANA without the >>>>>> IPsec part become hobbled or unusable? I don't >> think so. Without the IPsec >>>>>> part, PANA provides security that is equivalent >> to the http based logins at >>>>>> hotspots. For most scenarios, that may be >> sufficient. >>>>>> Additionally how realistic is it that a host >> will do IKE and setup an >>>>>> IPsec >>>>>> SA with the access network just for securing >> the user data traffic? If user >>>>>> data is critical, then the user will have VPNs >> or TLS to the server. So the >>>>>> use of IPsec is primarily for access control >> only. And since IPsec is >>>>>> optional we can possibly live without the >> specification being a core aspect >>>>>> of the PANA protocol. >>>>>> >>>>>> >>>>>>>> I feel that L2 security makes more sense and >> probably >>>>>>>> we should keep that. >>>>>>>> >>>>>>>> >>>>>>> I think we also need that but don't yet have >> WG document. >>>>>>> >>>>>>> >>>>>> >>>>>> We are trying to simplify the protocol by >> stripping out features that "MAY" >>>>>> be non-essential. So lets not add more now. >>>>>> >>>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> >>>>>>> Julien >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -mohan >> > === message truncated === > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Fri Jun 09 10:23:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fohtt-0000xE-Ht; Fri, 09 Jun 2006 10:23:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fohtr-0000qp-Ku for pana@ietf.org; Fri, 09 Jun 2006 10:23:47 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fohto-0004I6-Ku for pana@ietf.org; Fri, 09 Jun 2006 10:23:47 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k59ENYmE003256; Fri, 9 Jun 2006 23:23:34 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k59ENYp2016265; Fri, 9 Jun 2006 23:23:34 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id ZAA16264; Fri, 9 Jun 2006 23:23:34 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k59ENXAl010193; Fri, 9 Jun 2006 23:23:33 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k59ENWF3004790; Fri, 9 Jun 2006 23:23:32 +0900 (JST) Received: from steelhead ([172.30.24.47]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0L008ICJZ30AE0@mail.po.toshiba.co.jp>; Fri, 09 Jun 2006 23:23:32 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FohtT-0002OD-Kb; Fri, 09 Jun 2006 07:23:23 -0700 Date: Fri, 09 Jun 2006 10:23:23 -0400 From: Yoshihiro Ohba Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) In-reply-to: To: Basavaraj Patil Mail-followup-to: Basavaraj Patil , ext Mohan Parthasarathy , ext Yoshihiro Ohba , ext Julien Bournelle , pana@ietf.org, 'Jari Arkko' , ext Rafa Marin Lopez , 'Mark Townsley' Message-id: <20060609142323.GB8759@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <20060609005110.39772.qmail@web80607.mail.yahoo.com> User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: ext Julien Bournelle , ext Yoshihiro Ohba , pana@ietf.org, ext Mohan Parthasarathy , 'Jari Arkko' , ext Rafa Marin Lopez , 'Mark Townsley' X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org On Fri, Jun 09, 2006 at 10:28:05AM +0300, Basavaraj Patil wrote: > > Hi Mohan, > > > On 6/9/06 3:51 AM, "ext Mohan Parthasarathy" wrote: > > > > > Hi, > > > > You need per-packet ciphering at L2 or L3 if > > the link-layer is not physically secured. Please > > see the threats document on why you need this. > > No question about the vulnerabilities and threats that are exposed as a > result of not ensuring security at the lower layers. But the point is if > PANA needs to ensure that. PANA may enable it. But PANA need not be coupled > tightly with the need for securing the user traffic. > > > > > > >>> Protected PANA-Ping exchange would be effective to > >> detect session > >>> hijacking. > >> > >> I think this is what we really need to ensure is > >> specified as part of core > >> PANA protocol. > >> > > I don't know how this would work. How often you > > ping ? How does it work in PAA and EP separation > > case ? > > Not clear about it. This was a proposal from Yoshi. How often or in which case PANA-Ping is performed is an implementation issue which we would not get into. PANA-Ping must work transparently to EPs just like other PANA messages do. > > > > >>> However, if users also care integrity and > >> confidentiality > >>> of data packets and no VPN is used, the > >> functionality to bootstrap > >>> per-packet ciphering is needed. > >> > >> This is optional as we have been said so in the past > >> as well. And we need to > >> de-couple this from the core PANA protocol. > >> > > How do you enforce that some malicious node is > > not getting free service without ciphering at > > L2 or L3 ? > > You either rely on the existence of a L2 mechanism that is inherent to the > link or you figure out some other means of enforcing access control which > keeps malicious nodes from getting free service. > So the question is: > - Does PANA need to ensure that unsecured links have the ability to do > access control? How would PANA be able to determine if a link is secure or > not? Is there a way to figure that out? I don't think this can be easily > accomplished. Because even if a link layer has the capability to cipher, it > does not imply that it is enabled. There is no automatic way of knowing the security characteristics of the link. However, in the current PANA design, it is the PAA that determines (based on configuration) if a link is secure or not. The administrator that configures the PAA must have knowledge about the security characteristics of the link. PaCs need to follow the PAA's decision to use link layer ciphering determination or it will not get access. I don't think there is an issue in this design. Yoshihiro Ohba > > -Raj > > > > > > -mohan > > > >>> As far as I understand, PANA proposal in 3GPP2 > >> relied on this functionality. > >> > >> In the case of PP2 there is already capability to > >> cipher traffic at the > >> lower layer. So there is no reason to establish an > >> IPsec SA for user > >> traffic. But anyway, the PP2 discussion is > >> irrelevant here and I don't want > >> to go off on a tangent. > >> > >>> An issue here would be whether > >>> this general functionality (i.e., use of > >> Protection-Capability AVP and > >>> PaC-EP-Master-Key) should be described in the base > >> specification, or > >>> in a separate document in which case document > >> structure (in terms of > >>> bootstrapping) could be: > >> > >> My view is that PANA should not be concerned at all > >> about the user data > >> protection (i.e using IPsec between the PaC and EP). > >> > >>> > >>> 1. Base specification draft > >> > >> This I-D along with the capability that deals with > >> sesssion hijacking (i.e > >> protected PANA ping). > >> > >>> > >>> 2. General bootstrapping per-pacet ciphering draft > >> (defining > >>> Protection-Capability AVP and > >>> PaC-EP-Master-Key) > >> > >> I don't think this is needed. Per-packet ciphering > >> and how this is enabled > >> by PANA is not something that we want to get into. > >> Not at this stage at > >> least. > >> > >>> > >>> 3. Lower-layer specific bootstrapping drafts > >> (pana-ipsec, pana-ieee80211doti) > >> > >> These are informational and need not form a core > >> aspect of what the WG > >> should deliver. > >> > >>> > >>> Note that 2) is a small piece compared to other > >> optional feature such > >>> as NAP and ISP separate authentication. > >> > >> Cheers, > >> -Raj > >> > >>> > >>> Yoshihiro Ohba > >>> > >>>> > >>>> -Raj > >>>> > >>>>> > >>>>> The general question would be whether we want > >> PANA supporting both cases > >>>>> or not. > >>>>> > >>>>> To understand, are you saying PANA should not > >> support b) in the base-spec? > >>>> > >>>> What I am saying is that support for "b" is not a > >> core aspect of PANA and > >>>> hence need not be part of the base-spec. > >>>> > >>>> -Raj > >>>> > >>>>> > >>>>>>> what's exactly the problem with keeping > >> pana-ipsec ? > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> The intent here is to simplify the PANA > >> protocol. Does PANA without the > >>>>>> IPsec part become hobbled or unusable? I don't > >> think so. Without the IPsec > >>>>>> part, PANA provides security that is equivalent > >> to the http based logins at > >>>>>> hotspots. For most scenarios, that may be > >> sufficient. > >>>>>> Additionally how realistic is it that a host > >> will do IKE and setup an > >>>>>> IPsec > >>>>>> SA with the access network just for securing > >> the user data traffic? If user > >>>>>> data is critical, then the user will have VPNs > >> or TLS to the server. So the > >>>>>> use of IPsec is primarily for access control > >> only. And since IPsec is > >>>>>> optional we can possibly live without the > >> specification being a core aspect > >>>>>> of the PANA protocol. > >>>>>> > >>>>>> > >>>>>>>> I feel that L2 security makes more sense and > >> probably > >>>>>>>> we should keep that. > >>>>>>>> > >>>>>>>> > >>>>>>> I think we also need that but don't yet have > >> WG document. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> We are trying to simplify the protocol by > >> stripping out features that "MAY" > >>>>>> be non-essential. So lets not add more now. > >>>>>> > >>>>>> > >>>>>> -Raj > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Julien > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -mohan > >> > > === message truncated === > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Fri Jun 09 11:34:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foizq-0001EW-2Q; Fri, 09 Jun 2006 11:34:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foizo-0001EO-ST for pana@ietf.org; Fri, 09 Jun 2006 11:34:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foisl-0003bl-8E for pana@ietf.org; Fri, 09 Jun 2006 11:26:43 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoiPR-00026N-Hf for pana@ietf.org; Fri, 09 Jun 2006 10:56:27 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k59EuJOo012787; Fri, 9 Jun 2006 23:56:19 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k59EvhqI023212; Fri, 9 Jun 2006 23:57:43 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id ZAA23209; Fri, 9 Jun 2006 23:57:42 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k59EuIqe009128; Fri, 9 Jun 2006 23:56:19 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k59EuIH6014901; Fri, 9 Jun 2006 23:56:18 +0900 (JST) Received: from steelhead ([172.30.24.47]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J0L00835LHP0AF0@mail.po.toshiba.co.jp>; Fri, 09 Jun 2006 23:56:18 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FoiP2-0002Tt-S9; Fri, 09 Jun 2006 07:56:00 -0700 Date: Fri, 09 Jun 2006 10:56:00 -0400 From: Yoshihiro Ohba Subject: Re: PAA-to-EP protocol ? (RE: [Pana] IETF LC and discussion: Next steps) In-reply-to: <000401c68acf$572650b0$2b05a40a@china.huawei.com> To: selina Mail-followup-to: selina , pana@ietf.org Message-id: <20060609145600.GC8759@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <0MKp2t-1Fndbc1dRP-0006lx@mrelay.perfora.net> <000401c68acf$572650b0$2b05a40a@china.huawei.com> User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: -2.6 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Selina, As far as I remember, the decision is based on the evaluation made for MIDCOM protocol. The evaluation is published as RFC 4097. Yoshihiro Ohba On Thu, Jun 08, 2006 at 03:44:09PM +0800, selina wrote: > Hi, everyone: > > > > > [3] Do we need to specify PAA-to-EP protocol? Can't we mark > > it as out of scope and not specify anything? Some people have > > concerns about using SNMP for configuration. > > > > I want to know the reason that SNMP is selected to act as PAA-to-EP > protocol. > And why the other protocols such as Radius/Diameter or COPS are not > appropriate. > > Selina > Thanks > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Fri Jun 09 11:43:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foj8f-0002K7-Vv; Fri, 09 Jun 2006 11:43:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foj8f-0002Jx-6l for pana@ietf.org; Fri, 09 Jun 2006 11:43:09 -0400 Received: from smtp1.int-evry.fr ([157.159.10.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foj8c-0005jL-TA for pana@ietf.org; Fri, 09 Jun 2006 11:43:09 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp1.int-evry.fr (Postfix) with ESMTP id B85A918D308; Fri, 9 Jun 2006 17:48:29 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1Foj70-0003jU-Oj; Fri, 09 Jun 2006 17:41:26 +0200 Date: Fri, 9 Jun 2006 17:41:26 +0200 From: Julien Bournelle To: selina Subject: Re: PAA-to-EP protocol ? (RE: [Pana] IETF LC and discussion: Next steps) Message-ID: <20060609154126.GA14337@ipv6-3.int-evry.fr> References: <0MKp2t-1Fndbc1dRP-0006lx@mrelay.perfora.net> <000401c68acf$572650b0$2b05a40a@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000401c68acf$572650b0$2b05a40a@china.huawei.com> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi selina, you may also read: http://www.watersprings.org/pub/id/draft-yacine-pana-paa2ep-prot-eval-00.txt My 2 cents, Julien On Thu, Jun 08, 2006 at 03:44:09PM +0800, selina wrote: > Hi, everyone: > > > > > [3] Do we need to specify PAA-to-EP protocol? Can't we mark > > it as out of scope and not specify anything? Some people have > > concerns about using SNMP for configuration. > > > > I want to know the reason that SNMP is selected to act as PAA-to-EP > protocol. > And why the other protocols such as Radius/Diameter or COPS are not > appropriate. > > Selina > Thanks > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Fri Jun 09 12:48:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FokAC-0004cD-6f; Fri, 09 Jun 2006 12:48:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FokAA-0004Zi-L5 for pana@ietf.org; Fri, 09 Jun 2006 12:48:46 -0400 Received: from web80610.mail.yahoo.com ([66.94.235.72]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FokAA-0006Dg-4Q for pana@ietf.org; Fri, 09 Jun 2006 12:48:46 -0400 Received: (qmail 87339 invoked by uid 60001); 9 Jun 2006 16:42:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wuAyFyolSsUvd3UxT9cIksDBYexna/H7jhWFrwt1Jr6CwmSIx23PrgQTBMfPShiTuR7Ghdbs0/ZHTgE6i4yqsLsgbsC/fDWEfxlzd+eFUpfcy/+Z9PTjD77e9EiiEL+YIcWQgtDS5JiGNUjMs++BWv7F+rX5Jjnab+5HdA2saGw= ; Message-ID: <20060609164204.87337.qmail@web80610.mail.yahoo.com> Received: from [206.132.194.2] by web80610.mail.yahoo.com via HTTP; Fri, 09 Jun 2006 09:42:04 PDT Date: Fri, 9 Jun 2006 09:42:04 -0700 (PDT) From: Mohan Parthasarathy Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) To: Yoshihiro Ohba , Basavaraj Patil In-Reply-To: <20060609142323.GB8759@steelhead> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: ext Julien Bournelle , ext Yoshihiro Ohba , pana@ietf.org, ext Mohan Parthasarathy , 'Jari Arkko' , ext Rafa Marin Lopez , 'Mark Townsley' X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org > > > > Not clear about it. This was a proposal from > Yoshi. > > How often or in which case PANA-Ping is performed is > an implementation > issue which we would not get into. > > PANA-Ping must work transparently to EPs just like > other PANA > messages do. > I guess we should take this in a separate thread or offline..(Are you proposing this as an alterntive to L2 or L3 ciphering). > > > > > > > >>> However, if users also care integrity and > > >> confidentiality > > >>> of data packets and no VPN is used, the > > >> functionality to bootstrap > > >>> per-packet ciphering is needed. > > >> > > >> This is optional as we have been said so in the > past > > >> as well. And we need to > > >> de-couple this from the core PANA protocol. > > >> > > > How do you enforce that some malicious node is > > > not getting free service without ciphering at > > > L2 or L3 ? > > > > You either rely on the existence of a L2 mechanism > that is inherent to the > > link or you figure out some other means of > enforcing access control which > > keeps malicious nodes from getting free service. > > So the question is: > > - Does PANA need to ensure that unsecured links > have the ability to do > > access control? How would PANA be able to > determine if a link is secure or > > not? Is there a way to figure that out? I don't > think this can be easily > > accomplished. Because even if a link layer has the > capability to cipher, it > > does not imply that it is enabled. > > There is no automatic way of knowing the security > characteristics of > the link. However, in the current PANA design, it > is the PAA that > determines (based on configuration) if a link is > secure or not. The > administrator that configures the PAA must have > knowledge about the > security characteristics of the link. PaCs need to > follow the PAA's > decision to use link layer ciphering determination > or it will not get > access. I don't think there is an issue in this > design. > Yes, i agree that this is perfectly fine. -mohan > Yoshihiro Ohba > > > > > > > > -Raj > > > > > > > > > > -mohan > > > > > >>> As far as I understand, PANA proposal in 3GPP2 > > >> relied on this functionality. > > >> > > >> In the case of PP2 there is already capability > to > > >> cipher traffic at the > > >> lower layer. So there is no reason to establish > an > > >> IPsec SA for user > > >> traffic. But anyway, the PP2 discussion is > > >> irrelevant here and I don't want > > >> to go off on a tangent. > > >> > > >>> An issue here would be whether > > >>> this general functionality (i.e., use of > > >> Protection-Capability AVP and > > >>> PaC-EP-Master-Key) should be described in the > base > > >> specification, or > > >>> in a separate document in which case document > > >> structure (in terms of > > >>> bootstrapping) could be: > > >> > > >> My view is that PANA should not be concerned at > all > > >> about the user data > > >> protection (i.e using IPsec between the PaC and > EP). > > >> > > >>> > > >>> 1. Base specification draft > > >> > > >> This I-D along with the capability that deals > with > > >> sesssion hijacking (i.e > > >> protected PANA ping). > > >> > > >>> > > >>> 2. General bootstrapping per-pacet ciphering > draft > > >> (defining > > >>> Protection-Capability AVP and > > >>> PaC-EP-Master-Key) > > >> > > >> I don't think this is needed. Per-packet > ciphering > > >> and how this is enabled > > >> by PANA is not something that we want to get > into. > > >> Not at this stage at > > >> least. > > >> > > >>> > > >>> 3. Lower-layer specific bootstrapping drafts > > >> (pana-ipsec, pana-ieee80211doti) > > >> > > >> These are informational and need not form a > core > > >> aspect of what the WG > > >> should deliver. > > >> > > >>> > > >>> Note that 2) is a small piece compared to > other > > >> optional feature such > > >>> as NAP and ISP separate authentication. > > >> > > >> Cheers, > > >> -Raj > > >> > > >>> > > >>> Yoshihiro Ohba > > >>> > > >>>> > > >>>> -Raj > > >>>> > > >>>>> > > >>>>> The general question would be whether we > want > > >> PANA supporting both cases > > >>>>> or not. > > >>>>> > > >>>>> To understand, are you saying PANA should > not > > >> support b) in the base-spec? > > >>>> > > >>>> What I am saying is that support for "b" is > not a > > >> core aspect of PANA and > === message truncated === _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Fri Jun 09 18:20:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FopLB-0002TA-Ou; Fri, 09 Jun 2006 18:20:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FopLA-0002T5-Gt for pana@ietf.org; Fri, 09 Jun 2006 18:20:28 -0400 Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FopLA-0007JV-6A for pana@ietf.org; Fri, 09 Jun 2006 18:20:28 -0400 Received: from [207.62.244.232] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1FopKu0UYb-0004cA; Fri, 09 Jun 2006 18:20:23 -0400 From: "Alper Yegin" To: "'Mohan Parthasarathy'" , "'Yoshihiro Ohba'" , "'Basavaraj Patil'" Subject: RE: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) Date: Fri, 9 Jun 2006 15:19:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcaL5JVIvf/f9NN0SoSY7SAd37q+UAALMLAA In-Reply-To: <20060609164204.87337.qmail@web80610.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-ID: <0MKoyl-1FopKu0UYb-0004cA@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: 'ext Julien Bournelle' , 'ext Yoshihiro Ohba' , pana@ietf.org, 'Jari Arkko' , 'ext Rafa Marin Lopez' , 'Mark Townsley' X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org We know that client authentication is not sufficient to fully secure the network access. Per-packet integrity and origin authentication needs to be enabled. If we only consider the cases where such protection is enabled prior to PANA, that limits the deployment scenarios considerably. Besides, covering both types of cases has very limited impact on the base PANA protocol (a key derivation, and a capability exchange). For that, I don't think it makes sense to drop supporting the deployment case where aforementioned protection is enabled after successful PANA authentication. As for the use of IPsec, there is nothing specific to IPsec in the base protocol, aside from indicating its use via capability exchange. Whether PANA-IPsec I-D (draft-ietf-pana-ipsec-07.txt) is there or not is not going to make an impact on the base protocol specification. I think we need the PANA-IPsec I-D to ensure interoperability. My 0.02 cents. Alper > -----Original Message----- > From: Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] > Sent: Friday, June 09, 2006 9:42 AM > To: Yoshihiro Ohba; Basavaraj Patil > Cc: ext Julien Bournelle; ext Yoshihiro Ohba; pana@ietf.org; ext Mohan > Parthasarathy; 'Jari Arkko'; ext Rafa Marin Lopez; 'Mark Townsley' > Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next > steps) > > > > > > > > > Not clear about it. This was a proposal from > > Yoshi. > > > > How often or in which case PANA-Ping is performed is > > an implementation > > issue which we would not get into. > > > > PANA-Ping must work transparently to EPs just like > > other PANA > > messages do. > > > I guess we should take this in a separate > thread or offline..(Are you proposing this as an > alterntive to L2 or L3 ciphering). > > > > > > > > > > > >>> However, if users also care integrity and > > > >> confidentiality > > > >>> of data packets and no VPN is used, the > > > >> functionality to bootstrap > > > >>> per-packet ciphering is needed. > > > >> > > > >> This is optional as we have been said so in the > > past > > > >> as well. And we need to > > > >> de-couple this from the core PANA protocol. > > > >> > > > > How do you enforce that some malicious node is > > > > not getting free service without ciphering at > > > > L2 or L3 ? > > > > > > You either rely on the existence of a L2 mechanism > > that is inherent to the > > > link or you figure out some other means of > > enforcing access control which > > > keeps malicious nodes from getting free service. > > > So the question is: > > > - Does PANA need to ensure that unsecured links > > have the ability to do > > > access control? How would PANA be able to > > determine if a link is secure or > > > not? Is there a way to figure that out? I don't > > think this can be easily > > > accomplished. Because even if a link layer has the > > capability to cipher, it > > > does not imply that it is enabled. > > > > There is no automatic way of knowing the security > > characteristics of > > the link. However, in the current PANA design, it > > is the PAA that > > determines (based on configuration) if a link is > > secure or not. The > > administrator that configures the PAA must have > > knowledge about the > > security characteristics of the link. PaCs need to > > follow the PAA's > > decision to use link layer ciphering determination > > or it will not get > > access. I don't think there is an issue in this > > design. > > > Yes, i agree that this is perfectly fine. > > -mohan > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > -Raj > > > > > > > > > > > > > > -mohan > > > > > > > >>> As far as I understand, PANA proposal in 3GPP2 > > > >> relied on this functionality. > > > >> > > > >> In the case of PP2 there is already capability > > to > > > >> cipher traffic at the > > > >> lower layer. So there is no reason to establish > > an > > > >> IPsec SA for user > > > >> traffic. But anyway, the PP2 discussion is > > > >> irrelevant here and I don't want > > > >> to go off on a tangent. > > > >> > > > >>> An issue here would be whether > > > >>> this general functionality (i.e., use of > > > >> Protection-Capability AVP and > > > >>> PaC-EP-Master-Key) should be described in the > > base > > > >> specification, or > > > >>> in a separate document in which case document > > > >> structure (in terms of > > > >>> bootstrapping) could be: > > > >> > > > >> My view is that PANA should not be concerned at > > all > > > >> about the user data > > > >> protection (i.e using IPsec between the PaC and > > EP). > > > >> > > > >>> > > > >>> 1. Base specification draft > > > >> > > > >> This I-D along with the capability that deals > > with > > > >> sesssion hijacking (i.e > > > >> protected PANA ping). > > > >> > > > >>> > > > >>> 2. General bootstrapping per-pacet ciphering > > draft > > > >> (defining > > > >>> Protection-Capability AVP and > > > >>> PaC-EP-Master-Key) > > > >> > > > >> I don't think this is needed. Per-packet > > ciphering > > > >> and how this is enabled > > > >> by PANA is not something that we want to get > > into. > > > >> Not at this stage at > > > >> least. > > > >> > > > >>> > > > >>> 3. Lower-layer specific bootstrapping drafts > > > >> (pana-ipsec, pana-ieee80211doti) > > > >> > > > >> These are informational and need not form a > > core > > > >> aspect of what the WG > > > >> should deliver. > > > >> > > > >>> > > > >>> Note that 2) is a small piece compared to > > other > > > >> optional feature such > > > >>> as NAP and ISP separate authentication. > > > >> > > > >> Cheers, > > > >> -Raj > > > >> > > > >>> > > > >>> Yoshihiro Ohba > > > >>> > > > >>>> > > > >>>> -Raj > > > >>>> > > > >>>>> > > > >>>>> The general question would be whether we > > want > > > >> PANA supporting both cases > > > >>>>> or not. > > > >>>>> > > > >>>>> To understand, are you saying PANA should > > not > > > >> support b) in the base-spec? > > > >>>> > > > >>>> What I am saying is that support for "b" is > > not a > > > >> core aspect of PANA and > > > === message truncated === > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Fri Jun 09 18:32:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FopWL-00075s-Jh; Fri, 09 Jun 2006 18:32:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FopWJ-00075n-Rf for pana@ietf.org; Fri, 09 Jun 2006 18:31:59 -0400 Received: from mout.perfora.net ([217.160.230.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FopWI-00083H-JG for pana@ietf.org; Fri, 09 Jun 2006 18:31:59 -0400 Received: from [207.62.244.232] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1FopWB433S-00011u; Fri, 09 Jun 2006 18:31:56 -0400 From: "Alper Yegin" To: "'Yoshihiro Ohba'" Subject: RE: Discovery [was Re: [Pana] IETF LC and discussion: Next steps] Date: Fri, 9 Jun 2006 15:31:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcaKaW4Z58//c16aR2mMmvEcb/BcSQBqoEug In-Reply-To: <20060607193324.GF17242@steelhead> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-ID: <0MKp2t-1FopWB433S-00011u@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: 'Mark Townsley' , 'Jari Arkko' , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org If the separate document is going to say what we already have in the base specification, I don't see why we should spin it off. Especially given that the base document would have a dependency on the discovery document, which is likely to take a lot of time and unnecessarily delay the PANA standardization. Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Wednesday, June 07, 2006 12:33 PM > To: Alper Yegin > Cc: pana@ietf.org; 'Mark Townsley'; 'Jari Arkko' > Subject: Discovery [was Re: [Pana] IETF LC and discussion: Next steps] > > On Tue, Jun 06, 2006 at 08:36:17AM -0700, Alper Yegin wrote: > > > > [1] Can we remove the discovery part of the base specification? Can we > > mandate the DHCP-based discovery as specified in a separate document? > > > > Also, there is Mark's comment in another thread: > > There is precedent in other groups for advancing discovery > > separately from a base protocol (L2VPN/PWE3 and softwires, for > > example). Given that there are already multiple ways to do PANA > > discovery, I would consider pulling this out of the base > > specification as well, allowing it to advance as its own document. > > Initially I thought discovery should be integral part of base > specification. But going through comments in IETF mailing list (some > person raised an issue on administrative scoped multicast in multi-hop > environment and some person indicated anycast) and private discussion, > now I have an impression that it might be good to define discovery in > separate document(s). We can even define default preference among > multiple discovery methods in a separate document. > > Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Fri Jun 09 18:42:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fopgk-0007F6-TK; Fri, 09 Jun 2006 18:42:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fopgj-0007F1-Kl for pana@ietf.org; Fri, 09 Jun 2006 18:42:45 -0400 Received: from mout.perfora.net ([217.160.230.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fopgi-0001ET-Ey for pana@ietf.org; Fri, 09 Jun 2006 18:42:45 -0400 Received: from [207.62.244.232] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1Fopgd2z4z-00015O; Fri, 09 Jun 2006 18:42:44 -0400 From: "Alper Yegin" To: "'Yoshihiro Ohba'" Subject: RE: Refocusing/simplifying pana-framework [was Re: [Pana] IETF LC and discussion: Next steps] Date: Fri, 9 Jun 2006 15:42:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcaJlSRf4PIJXmFFR6WNSYQSSCS93gCgEmiA In-Reply-To: <20060606181438.GA13466@steelhead> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-ID: <0MKp2t-1Fopgd2z4z-00015O@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 'Mark Townsley' , 'Jari Arkko' , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org > - IP address configuration section (Section 5) should be described in > the base specification because it contains several MUST/SHOULD. I've looked at the text again. I think we can remove all MUST/SHOULDs. The original intent of that text was to be informational -- showing the different ways IP addresses can be configured in relation to PANA. I don't think we need that text be in the base specification. I'm inclined to keep the text in the PANA framework after stripping off the MUST/SHOULDs. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From brown_4_bbc@yahoo.co.jp Mon Jun 19 03:55:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsEbi-0005xW-TD for pana-archive@lists.ietf.org; Mon, 19 Jun 2006 03:55:38 -0400 Received: from [218.27.59.33] (helo=lists.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FsEbg-00086c-Sc for pana-archive@lists.ietf.org; Mon, 19 Jun 2006 03:55:38 -0400 To: From: =?iso-2022-jp?B?aGVzbw==?= Subject: =?iso-2022-jp?B?GyRCQmdKUSQqQlQkPyQ7JCQkPyQ3JF4kNyQ/GyhC?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 $B9b5iIX?M$H$NL5NA$N=P2q$$$rDs6!$7$F$^$9!#(B $B=w@-$OEPO?NA(B3$BK|1_!"CK@-$OL5NA$H$J$C$F$^$9$N$G!"??7u$J=w@-$7(B $B$+$*$j$^$;$s!#(B $B$9$Y$F$N%;%l%V$,4i2hA|$rE:$($F%a%k%"%I$b:\$;$F$*BT$A$G$9!#(B $B$*6b$O$"$k$,0&$K7C$^$l$J$$=w@-C#$r?HBN$GL~$7$F$"$2$F$/$@$5$$!#(B $B7n(B1$B!A(B3$B2s$N%G!<%H$G7n(B30$B$N5U%5%]$,:GDc8B$N%i%$%s$J$N$G!"(B $B=w@-$K$h$C$F$O$=$l0J>e$N5U%5%]$,4|BT$G$-$^$9$h(B(o^-') $B!!(B $B!!(Bhttp://rrnj.com?moot $B$5$i$K!"??7u$J8r:]$r4uK>$5$l$kJ}$N$?$a$K!"L5NA$G5.J}$N$*=;$^(B $B$$$N6a$/$N=w@-%;%l%V$rL5NA$G8!:w$9$k?7$7$$$4>R2p%5!<%S%9$rDs(B $B6!$$$?$7$^$9!#(B $B!!(B $B!!(Bhttp://rrnj.com?moot $B:#$J$i2q0wHq!&G/2qHqEy0l@ZL5NA!*(B $B$5$i$K(B6,500$B1_J,$NL5NA%]%$%s%H$r%W%l%<%s%H!*(B $B$* To: Date: Mon, 19 Jun 2006 13:19:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaT3aJew7DonCXmTb+heRkjELiIqw== Message-ID: <0MKp2t-1FsQDM1s9g-0007Vh@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: -2.3 (--) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Pana] IETF 66 PANA WG agenda X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org If you'd like to get on the IETF 66 PANA WG meeting agenda, please send in your requests to the WG chairs. Make sure to include the name of the I-D, presenter's name, objective, and the length of your talk. - Chairs _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Tue Jun 20 16:33:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmuT-0001ke-VL; Tue, 20 Jun 2006 16:33:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsmuS-0001hV-NM for pana@ietf.org; Tue, 20 Jun 2006 16:33:16 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsmuR-0001zL-8U for pana@ietf.org; Tue, 20 Jun 2006 16:33:16 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5KKXCEG021889 for ; Tue, 20 Jun 2006 23:33:14 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 23:33:14 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 15:32:02 -0500 Received: from 172.19.244.70 ([172.19.244.70]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Jun 2006 20:32:02 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 20 Jun 2006 15:32:13 -0500 From: Basavaraj Patil To: Message-ID: Thread-Topic: Agenda slots for IETF66 Thread-Index: AcaUqJyj2yoEwACbEdu6mAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 20:32:02.0679 (UTC) FILETIME=[967C6870:01C694A8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Pana] Agenda slots for IETF66 X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org If you need a slot on the agenda of the PANA WG meeting agenda at IETF66, please send Alper or myself a note. -Raj _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Tue Jun 20 22:15:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FssG0-0006TL-D6; Tue, 20 Jun 2006 22:15:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FssFz-0006Qh-Is for pana@ietf.org; Tue, 20 Jun 2006 22:15:51 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FssFy-0002Ee-QB for pana@ietf.org; Tue, 20 Jun 2006 22:15:51 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id D261723D192; Wed, 21 Jun 2006 04:15:47 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18195-01-42; Wed, 21 Jun 2006 04:15:47 +0200 (CEST) Received: from [207.3.232.157] (tari-dhcp157.research.telcordia.com [207.3.232.157]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id E5C0D23CA8B; Wed, 21 Jun 2006 04:15:37 +0200 (CEST) Message-ID: <4498AB99.1030102@dif.um.es> Date: Tue, 20 Jun 2006 22:14:49 -0400 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) References: <0MKoyl-1FopKu0UYb-0004cA@mrelay.perfora.net> In-Reply-To: <0MKoyl-1FopKu0UYb-0004cA@mrelay.perfora.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 Cc: 'ext Julien Bournelle' , 'Yoshihiro Ohba' , pana@ietf.org, 'Mohan Parthasarathy' , 'Jari Arkko' , Rafa Marin Lopez , 'Mark Townsley' , 'Basavaraj Patil' X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Alper, sorry for the delayed answer. I agree with your comments. Personally, I would prefer PANA base spec "had in mind" when link is unsecured and some kind of security association needs to be bootstrapped. Mohan gave also some reasons for that ("per-packet ciphering at L2 or L3 if the link-layer is not physically secured") Certainly PANA base spec does not need to be very specific on this (others I-D will do that), but at least maintaining certain kind of hooks like Protection-Capability AVP or PaC-EP-Master-Key generation would be needed.(though i have doubts if this PaC-EP-Master-Key generation should be specified in specific I-Ds explaining PANA-IPsec or PANA-ieee802.11i instead of pana-base spec). Also my 0.01 cents. Alper Yegin wrote: >We know that client authentication is not sufficient to fully secure the >network access. Per-packet integrity and origin authentication needs to be >enabled. > >If we only consider the cases where such protection is enabled prior to >PANA, that limits the deployment scenarios considerably. > >Besides, covering both types of cases has very limited impact on the base >PANA protocol (a key derivation, and a capability exchange). > >For that, I don't think it makes sense to drop supporting the deployment >case where aforementioned protection is enabled after successful PANA >authentication. > >As for the use of IPsec, there is nothing specific to IPsec in the base >protocol, aside from indicating its use via capability exchange. > >Whether PANA-IPsec I-D (draft-ietf-pana-ipsec-07.txt) is there or not is not >going to make an impact on the base protocol specification. > >I think we need the PANA-IPsec I-D to ensure interoperability. > >My 0.02 cents. > >Alper > > > > > > > >>-----Original Message----- >>From: Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] >>Sent: Friday, June 09, 2006 9:42 AM >>To: Yoshihiro Ohba; Basavaraj Patil >>Cc: ext Julien Bournelle; ext Yoshihiro Ohba; pana@ietf.org; ext Mohan >>Parthasarathy; 'Jari Arkko'; ext Rafa Marin Lopez; 'Mark Townsley' >>Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next >>steps) >> >> >> >> >> >>>>Not clear about it. This was a proposal from >>>> >>>> >>>Yoshi. >>> >>>How often or in which case PANA-Ping is performed is >>>an implementation >>>issue which we would not get into. >>> >>>PANA-Ping must work transparently to EPs just like >>>other PANA >>>messages do. >>> >>> >>> >>I guess we should take this in a separate >>thread or offline..(Are you proposing this as an >>alterntive to L2 or L3 ciphering). >> >> >> >>>>>>>However, if users also care integrity and >>>>>>> >>>>>>> >>>>>>confidentiality >>>>>> >>>>>> >>>>>>>of data packets and no VPN is used, the >>>>>>> >>>>>>> >>>>>>functionality to bootstrap >>>>>> >>>>>> >>>>>>>per-packet ciphering is needed. >>>>>>> >>>>>>> >>>>>>This is optional as we have been said so in the >>>>>> >>>>>> >>>past >>> >>> >>>>>>as well. And we need to >>>>>>de-couple this from the core PANA protocol. >>>>>> >>>>>> >>>>>> >>>>>How do you enforce that some malicious node is >>>>>not getting free service without ciphering at >>>>>L2 or L3 ? >>>>> >>>>> >>>>You either rely on the existence of a L2 mechanism >>>> >>>> >>>that is inherent to the >>> >>> >>>>link or you figure out some other means of >>>> >>>> >>>enforcing access control which >>> >>> >>>>keeps malicious nodes from getting free service. >>>>So the question is: >>>>- Does PANA need to ensure that unsecured links >>>> >>>> >>>have the ability to do >>> >>> >>>>access control? How would PANA be able to >>>> >>>> >>>determine if a link is secure or >>> >>> >>>>not? Is there a way to figure that out? I don't >>>> >>>> >>>think this can be easily >>> >>> >>>>accomplished. Because even if a link layer has the >>>> >>>> >>>capability to cipher, it >>> >>> >>>>does not imply that it is enabled. >>>> >>>> >>>There is no automatic way of knowing the security >>>characteristics of >>>the link. However, in the current PANA design, it >>>is the PAA that >>>determines (based on configuration) if a link is >>>secure or not. The >>>administrator that configures the PAA must have >>>knowledge about the >>>security characteristics of the link. PaCs need to >>>follow the PAA's >>>decision to use link layer ciphering determination >>>or it will not get >>>access. I don't think there is an issue in this >>>design. >>> >>> >>> >>Yes, i agree that this is perfectly fine. >> >>-mohan >> >> >> >> >> >>>Yoshihiro Ohba >>> >>> >>> >>> >>> >>> >>>>-Raj >>>> >>>> >>>> >>>> >>>>>-mohan >>>>> >>>>> >>>>> >>>>>>>As far as I understand, PANA proposal in 3GPP2 >>>>>>> >>>>>>> >>>>>>relied on this functionality. >>>>>> >>>>>>In the case of PP2 there is already capability >>>>>> >>>>>> >>>to >>> >>> >>>>>>cipher traffic at the >>>>>>lower layer. So there is no reason to establish >>>>>> >>>>>> >>>an >>> >>> >>>>>>IPsec SA for user >>>>>>traffic. But anyway, the PP2 discussion is >>>>>>irrelevant here and I don't want >>>>>>to go off on a tangent. >>>>>> >>>>>> >>>>>> >>>>>>>An issue here would be whether >>>>>>>this general functionality (i.e., use of >>>>>>> >>>>>>> >>>>>>Protection-Capability AVP and >>>>>> >>>>>> >>>>>>>PaC-EP-Master-Key) should be described in the >>>>>>> >>>>>>> >>>base >>> >>> >>>>>>specification, or >>>>>> >>>>>> >>>>>>>in a separate document in which case document >>>>>>> >>>>>>> >>>>>>structure (in terms of >>>>>> >>>>>> >>>>>>>bootstrapping) could be: >>>>>>> >>>>>>> >>>>>>My view is that PANA should not be concerned at >>>>>> >>>>>> >>>all >>> >>> >>>>>>about the user data >>>>>>protection (i.e using IPsec between the PaC and >>>>>> >>>>>> >>>EP). >>> >>> >>>>>>>1. Base specification draft >>>>>>> >>>>>>> >>>>>>This I-D along with the capability that deals >>>>>> >>>>>> >>>with >>> >>> >>>>>>sesssion hijacking (i.e >>>>>>protected PANA ping). >>>>>> >>>>>> >>>>>> >>>>>>>2. General bootstrapping per-pacet ciphering >>>>>>> >>>>>>> >>>draft >>> >>> >>>>>>(defining >>>>>> >>>>>> >>>>>>>Protection-Capability AVP and >>>>>>> PaC-EP-Master-Key) >>>>>>> >>>>>>> >>>>>>I don't think this is needed. Per-packet >>>>>> >>>>>> >>>ciphering >>> >>> >>>>>>and how this is enabled >>>>>>by PANA is not something that we want to get >>>>>> >>>>>> >>>into. >>> >>> >>>>>>Not at this stage at >>>>>>least. >>>>>> >>>>>> >>>>>> >>>>>>>3. Lower-layer specific bootstrapping drafts >>>>>>> >>>>>>> >>>>>>(pana-ipsec, pana-ieee80211doti) >>>>>> >>>>>>These are informational and need not form a >>>>>> >>>>>> >>>core >>> >>> >>>>>>aspect of what the WG >>>>>>should deliver. >>>>>> >>>>>> >>>>>> >>>>>>>Note that 2) is a small piece compared to >>>>>>> >>>>>>> >>>other >>> >>> >>>>>>optional feature such >>>>>> >>>>>> >>>>>>>as NAP and ISP separate authentication. >>>>>>> >>>>>>> >>>>>>Cheers, >>>>>>-Raj >>>>>> >>>>>> >>>>>> >>>>>>>Yoshihiro Ohba >>>>>>> >>>>>>> >>>>>>> >>>>>>>>-Raj >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>The general question would be whether we >>>>>>>>> >>>>>>>>> >>>want >>> >>> >>>>>>PANA supporting both cases >>>>>> >>>>>> >>>>>>>>>or not. >>>>>>>>> >>>>>>>>>To understand, are you saying PANA should >>>>>>>>> >>>>>>>>> >>>not >>> >>> >>>>>>support b) in the base-spec? >>>>>> >>>>>> >>>>>>>>What I am saying is that support for "b" is >>>>>>>> >>>>>>>> >>>not a >>> >>> >>>>>>core aspect of PANA and >>>>>> >>>>>> >>=== message truncated === >> >> >>_______________________________________________ >>Pana mailing list >>Pana@ietf.org >>https://www1.ietf.org/mailman/listinfo/pana >> >> > > > > > > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Sat Jun 24 10:31:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu9A6-00007g-0n; Sat, 24 Jun 2006 10:31:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu9A4-00007b-Sd for pana@ietf.org; Sat, 24 Jun 2006 10:31:00 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu9A3-0001au-EI for pana@ietf.org; Sat, 24 Jun 2006 10:31:00 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k5OEUfnf073332; Sat, 24 Jun 2006 10:30:47 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Sat, 24 Jun 2006 10:30:33 -0400 To: Alper Yegin Subject: Re: Discovery [was Re: [Pana] IETF LC and discussion: Next steps] Message-ID: <20060624143033.GE21004@steelhead> Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , 'Mark Townsley' , 'Jari Arkko' , pana@ietf.org References: <20060607193324.GF17242@steelhead> <0MKp2t-1FopWB433S-00011u@mrelay.perfora.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <0MKp2t-1FopWB433S-00011u@mrelay.perfora.net> User-Agent: Mutt/1.5.11+cvs20060403 From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 72 X-Spam-Score: -2.4 (--) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: 'Mark Townsley' , 'Yoshihiro Ohba' , 'Jari Arkko' , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org On Fri, Jun 09, 2006 at 03:31:41PM -0700, Alper Yegin wrote: > > If the separate document is going to say what we already have in the base > specification, I don't see why we should spin it off. Especially given that > the base document would have a dependency on the discovery document, which > is likely to take a lot of time and unnecessarily delay the PANA > standardization. As long as we can add other discovery mechanisms in separate documents when needed in a future, it is ok for me. From this perspective, let me analyse Section 4.3 of the PANA specification: " When the PaC knows the IP address of the PAA, it can send a unicast PANA-PAA-Discover message and initiate the PANA exchange. In other cases, the PaC MUST rely on dynamic discovery methods, such as multicast-based and a traffic-driven discovery. " For example, if we have a plan to define an anycast-based discovery mechansim, then we can define the mechanism as a case where the PaC knows the IP address of the PAA. So once the mechanism is defined and implmented, then we do not have to rely on the multicast-based discovery. The same discussion applies to DHCP-based discovery mechanism. Yoshihiro Ohba > > > Alper > > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Wednesday, June 07, 2006 12:33 PM > > To: Alper Yegin > > Cc: pana@ietf.org; 'Mark Townsley'; 'Jari Arkko' > > Subject: Discovery [was Re: [Pana] IETF LC and discussion: Next steps] > > > > On Tue, Jun 06, 2006 at 08:36:17AM -0700, Alper Yegin wrote: > > > > > > [1] Can we remove the discovery part of the base specification? Can we > > > mandate the DHCP-based discovery as specified in a separate document? > > > > > > > Also, there is Mark's comment in another thread: > > > There is precedent in other groups for advancing discovery > > > separately from a base protocol (L2VPN/PWE3 and softwires, for > > > example). Given that there are already multiple ways to do PANA > > > discovery, I would consider pulling this out of the base > > > specification as well, allowing it to advance as its own document. > > > > Initially I thought discovery should be integral part of base > > specification. But going through comments in IETF mailing list (some > > person raised an issue on administrative scoped multicast in multi-hop > > environment and some person indicated anycast) and private discussion, > > now I have an impression that it might be good to define discovery in > > separate document(s). We can even define default preference among > > multiple discovery methods in a separate document. > > > > Yoshihiro Ohba > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Sat Jun 24 10:51:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu9Tw-0006GQ-GZ; Sat, 24 Jun 2006 10:51:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu9Tu-0006FI-Jq for pana@ietf.org; Sat, 24 Jun 2006 10:51:30 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu9Tt-0003j2-7z for pana@ietf.org; Sat, 24 Jun 2006 10:51:30 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k5OEoDw9073388; Sat, 24 Jun 2006 10:50:14 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Sat, 24 Jun 2006 10:49:55 -0400 To: selina Subject: Re: PAA-to-EP protocol ? (RE: [Pana] IETF LC and discussion: Next steps) Message-ID: <20060624144955.GF21004@steelhead> Mail-Followup-To: selina , pana@ietf.org References: <0MKp2t-1Fndbc1dRP-0006lx@mrelay.perfora.net> <000401c68acf$572650b0$2b05a40a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <000401c68acf$572650b0$2b05a40a@china.huawei.com> User-Agent: Mutt/1.5.11+cvs20060403 From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 32 X-Spam-Score: -2.4 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Going back to the original question, if someone has concerns about using SNMP for configuration (I don't know why), then what we can do is to specify a PAA-to-EP protocol using SNMP but without mandating to implement one. Yoshihiro Ohba On Thu, Jun 08, 2006 at 03:44:09PM +0800, selina wrote: > Hi, everyone: > > > > > [3] Do we need to specify PAA-to-EP protocol? Can't we mark > > it as out of scope and not specify anything? Some people have > > concerns about using SNMP for configuration. > > > > I want to know the reason that SNMP is selected to act as PAA-to-EP > protocol. > And why the other protocols such as Radius/Diameter or COPS are not > appropriate. > > Selina > Thanks > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Sun Jun 25 00:05:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuLsZ-0005hB-6C; Sun, 25 Jun 2006 00:05:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuLrP-00059l-Np for pana@ietf.org; Sun, 25 Jun 2006 00:04:35 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuLce-00037T-CC for pana@ietf.org; Sat, 24 Jun 2006 23:49:23 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 6783623E4EC; Sun, 25 Jun 2006 05:49:19 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32695-01-26; Sun, 25 Jun 2006 05:49:18 +0200 (CEST) Received: from [192.168.2.7] (ool-44c590c4.dyn.optonline.net [68.197.144.196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 16CDE23E4DF; Sun, 25 Jun 2006 05:49:16 +0200 (CEST) Message-ID: <449E0775.5040306@dif.um.es> Date: Sat, 24 Jun 2006 23:48:05 -0400 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Re: PAA-to-EP protocol ? (RE: [Pana] IETF LC and discussion: Next steps) References: <0MKp2t-1Fndbc1dRP-0006lx@mrelay.perfora.net> <000401c68acf$572650b0$2b05a40a@china.huawei.com> <20060624144955.GF21004@steelhead> In-Reply-To: <20060624144955.GF21004@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi Yoshi... Yoshihiro Ohba wrote: >Going back to the original question, if someone has concerns about >using SNMP for configuration (I don't know why), then what we can do >is to specify a PAA-to-EP protocol using SNMP but without mandating to >implement one. > > I agree in this point. I do not see any specific concern about using SNMP. I would also say that SNMP is generally used in current devices. As it has been also pointed by Julien, some previous study http://www.watersprings.org/pub/id/draft-yacine-pana-paa2ep-prot-eval-00.txt explain reasons to use SNMP. In any case, as you say maybe no mandating to implement one might be a good option to avoid people concerns (if any). My 0.01 cents. >Yoshihiro Ohba > > >On Thu, Jun 08, 2006 at 03:44:09PM +0800, selina wrote: > > >>Hi, everyone: >> >> >> >>>[3] Do we need to specify PAA-to-EP protocol? Can't we mark >>>it as out of scope and not specify anything? Some people have >>>concerns about using SNMP for configuration. >>> >>> >>> >>I want to know the reason that SNMP is selected to act as PAA-to-EP >>protocol. >>And why the other protocols such as Radius/Diameter or COPS are not >>appropriate. >> >>Selina >>Thanks >> >> >> >>_______________________________________________ >>Pana mailing list >>Pana@ietf.org >>https://www1.ietf.org/mailman/listinfo/pana >> >> >> > >_______________________________________________ >Pana mailing list >Pana@ietf.org >https://www1.ietf.org/mailman/listinfo/pana > > > > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Mon Jun 26 16:05:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxLH-0005u3-LS; Mon, 26 Jun 2006 16:05:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxL7-0005Ty-2C; Mon, 26 Jun 2006 16:05:45 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuxL6-0001w6-W6; Mon, 26 Jun 2006 16:05:45 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FuxL5-0004TF-Ju; Mon, 26 Jun 2006 16:05:44 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5QJo1jx020722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fux5t-0005AH-JJ; Mon, 26 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 26 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pana@ietf.org Subject: [Pana] I-D ACTION:draft-ietf-pana-snmp-06.txt X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol for carrying Authentication for Network Access Working Group of the IETF. Title : SNMP usage for PAA-EP interface Author(s) : Y. Mghazli, et al. Filename : draft-ietf-pana-snmp-06.txt Pages : 47 Date : 2006-6-26 The PANA Authentication Agent (PAA) does not necessarily act as an Enforcement Point (EP) to prevent unauthorized access or usage of the network. When a PANA Client successfully authenticates itself to the PAA, EP(s) (e.g., access routers) will need to be suitably notified. The PANA working group recommends the use of Simple Network Management Protocol Version 3 (SNMPv3) to deliver the authorization information to one or more EPs when the PAA is separated from EPs. The present document provides the necessary information and extensions needed to use SNMPv3 as the PAA-EP protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-snmp-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pana-snmp-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pana-snmp-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-26145214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pana-snmp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pana-snmp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-26145214.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana --NextPart-- From mayamaya12@so-net.ne.jp Tue Jun 27 06:31:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvAqf-0008IN-9N for PANA-ARCHIVE@LISTS.IETF.ORG; Tue, 27 Jun 2006 06:31:13 -0400 Received: from [60.218.6.254] (helo=allabout.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvAqc-0000c1-7J for PANA-ARCHIVE@LISTS.IETF.ORG; Tue, 27 Jun 2006 06:31:13 -0400 Received: from tahp1 (unknown [71.130.112.85]) by smtp29 (Coremail) with SMTP id HbIpvLeDO7gmdcmH.1 for ; Sat, 14 Jun 2003 20:44:46 +0800 (CST) X-Originating-IP: [71.130.112.85] Subject: =?iso-2022-jp?B?GyRCPiE8aiRLJDQkYSRzJEokNSQkISIbKEI=?= From: =?shift-jis?B?g32DhA==?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: text/plain; Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed GyRCNS5KfSROJSIlSSVsJTkhIiUiJUklbCU5JHJHZCRDJEYkJCRrNkg8VCQrJGlHYyQkJF4kNyQ/ ISMkSSQmJDckRiRiQ0tALSRIQk4kTjRYNzgkSyRKJGokPyQvJEYhIiReJEA3UDgzJDckPzt2TDUk JCRzJEckOSEiJDMkQSRpJEcbKEJodHRwOi8vdnFsaC5jb20vP215MTYbJEI7ZCROPEw/PzNORyck NyRGISIkYiQ3GyhCT0sbJEIkRyQ3JD8kaSEiO2QkTiUiJUklbCU5JEslYSE8JWskLyRAJDUkJCEj JV4lZCRDJEYkJCQkJF4kOSEjGyhCDQoNCg0KDQobJEIlYSE8JWs8dT8uNXFIXRsoQg0KSSBkb24n dCB2ZWNlaXZlIHlvdXJtYWlsDQpwX3BlYWNlX2xvd2xpZmVAeWFob28uY28udWsNCg== From pana-bounces@ietf.org Wed Jun 28 20:26:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvkMv-00016t-Vr; Wed, 28 Jun 2006 20:26:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvkMv-000112-91 for pana@ietf.org; Wed, 28 Jun 2006 20:26:53 -0400 Received: from mout.perfora.net ([217.160.230.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvkMu-0004tk-0B for pana@ietf.org; Wed, 28 Jun 2006 20:26:53 -0400 Received: from [68.126.193.27] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1FvkMo40Z4-0003IF; Wed, 28 Jun 2006 20:26:51 -0400 From: "Alper Yegin" To: "'Yoshihiro Ohba'" Subject: RE: Discovery [was Re: [Pana] IETF LC and discussion: Next steps] Date: Wed, 28 Jun 2006 17:26:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <20060624143033.GE21004@steelhead> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-index: AcaXmtKPlcORHCjlTFGoHnCEpOEM3wDd9sUg Message-ID: <0MKp2t-1FvkMo40Z4-0003IF@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: 'Mark Townsley' , 'Jari Arkko' , 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org That makes sense to me. Alper > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Saturday, June 24, 2006 7:31 AM > To: Alper Yegin > Cc: 'Yoshihiro Ohba'; 'Mark Townsley'; 'Jari Arkko'; pana@ietf.org > Subject: Re: Discovery [was Re: [Pana] IETF LC and discussion: Next steps] > > On Fri, Jun 09, 2006 at 03:31:41PM -0700, Alper Yegin wrote: > > > > If the separate document is going to say what we already have in the > base > > specification, I don't see why we should spin it off. Especially given > that > > the base document would have a dependency on the discovery document, > which > > is likely to take a lot of time and unnecessarily delay the PANA > > standardization. > > As long as we can add other discovery mechanisms in separate documents > when needed in a future, it is ok for me. From this perspective, let > me analyse Section 4.3 of the PANA specification: > > " > When the PaC knows the IP address of the PAA, it can send a unicast > PANA-PAA-Discover message and initiate the PANA exchange. In other > cases, the PaC MUST rely on dynamic discovery methods, such as > multicast-based and a traffic-driven discovery. > " > > For example, if we have a plan to define an anycast-based discovery > mechansim, then we can define the mechanism as a case where the PaC > knows the IP address of the PAA. So once the mechanism is defined and > implmented, then we do not have to rely on the multicast-based > discovery. The same discussion applies to DHCP-based discovery > mechanism. > > Yoshihiro Ohba > > > > > > > > Alper > > > > > > > > > -----Original Message----- > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: Wednesday, June 07, 2006 12:33 PM > > > To: Alper Yegin > > > Cc: pana@ietf.org; 'Mark Townsley'; 'Jari Arkko' > > > Subject: Discovery [was Re: [Pana] IETF LC and discussion: Next steps] > > > > > > On Tue, Jun 06, 2006 at 08:36:17AM -0700, Alper Yegin wrote: > > > > > > > > [1] Can we remove the discovery part of the base specification? Can > we > > > > mandate the DHCP-based discovery as specified in a separate > document? > > > > > > > > > > Also, there is Mark's comment in another thread: > > > > There is precedent in other groups for advancing discovery > > > > separately from a base protocol (L2VPN/PWE3 and softwires, for > > > > example). Given that there are already multiple ways to do PANA > > > > discovery, I would consider pulling this out of the base > > > > specification as well, allowing it to advance as its own document. > > > > > > Initially I thought discovery should be integral part of base > > > specification. But going through comments in IETF mailing list (some > > > person raised an issue on administrative scoped multicast in multi-hop > > > environment and some person indicated anycast) and private discussion, > > > now I have an impression that it might be good to define discovery in > > > separate document(s). We can even define default preference among > > > multiple discovery methods in a separate document. > > > > > > Yoshihiro Ohba > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jun 29 04:52:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvsFu-00048H-FV; Thu, 29 Jun 2006 04:52:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvsFt-00048C-MA for pana@ietf.org; Thu, 29 Jun 2006 04:52:09 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvsFp-0007kl-Bq for pana@ietf.org; Thu, 29 Jun 2006 04:52:09 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 4745B2FE5E for ; Thu, 29 Jun 2006 10:52:02 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FvsHA-0006M5-Rd for pana@ietf.org; Thu, 29 Jun 2006 10:53:28 +0200 Date: Thu, 29 Jun 2006 10:53:28 +0200 From: Julien Bournelle To: pana@ietf.org Message-ID: <20060629085328.GA24409@ipv6-3.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Pana] New I-D: draft-bournelle-pana-mip6-01.txt X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org Hi all, FYI, we have submitted an I-D concerning use of PANA for the Mobile IPv6 Integrated case. The document explains how PANA could be used instead of DHCPv6 to deliver the HA information to the PaC/Mobile Node. You can found the draft at: http://www.ietf.org/internet-drafts/draft-bournelle-pana-mip6-01.txt Any comments welcome, Julien Bournelle _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-bounces@ietf.org Thu Jun 29 10:27:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxUi-0002dZ-R4; Thu, 29 Jun 2006 10:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvxUh-0002YE-Ik for pana@ietf.org; Thu, 29 Jun 2006 10:27:47 -0400 Received: from imx11.toshiba.co.jp ([61.202.160.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvxUg-00026r-MW for pana@ietf.org; Thu, 29 Jun 2006 10:27:47 -0400 Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149]) by imx11.toshiba.co.jp with ESMTP id k5TERRXR000309; Thu, 29 Jun 2006 23:27:27 +0900 (JST) Received: (from root@localhost) by wall11.toshiba.co.jp id k5TESufc016406; Thu, 29 Jun 2006 23:28:56 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by wall11.toshiba.co.jp with SMTP id ZAA16403; Thu, 29 Jun 2006 23:28:56 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id k5TERQf3025904; Thu, 29 Jun 2006 23:27:26 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k5TERQ7r007318; Thu, 29 Jun 2006 23:27:26 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0J1M009GJLHJH660@mail.po.toshiba.co.jp>; Thu, 29 Jun 2006 23:27:26 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.62) (envelope-from ) id 1FvxTt-0001lz-LW; Thu, 29 Jun 2006 07:26:57 -0700 Date: Thu, 29 Jun 2006 10:26:57 -0400 From: Yoshihiro Ohba Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next steps) In-reply-to: <4498AB99.1030102@dif.um.es> To: Rafa Marin Lopez Mail-followup-to: Rafa Marin Lopez , Alper Yegin , 'ext Julien Bournelle' , 'Yoshihiro Ohba' , pana@ietf.org, 'Mohan Parthasarathy' , 'Jari Arkko' , 'Mark Townsley' , 'Basavaraj Patil' Message-id: <20060629142657.GB6377@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: <0MKoyl-1FopKu0UYb-0004cA@mrelay.perfora.net> <4498AB99.1030102@dif.um.es> User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 Cc: 'ext Julien Bournelle' , 'Yoshihiro Ohba' , pana@ietf.org, 'Mohan Parthasarathy' , 'Jari Arkko' , 'Mark Townsley' , 'Basavaraj Patil' X-BeenThere: pana@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Protocol for carrying Authentication for Network Access List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pana-bounces@ietf.org On Tue, Jun 20, 2006 at 10:14:49PM -0400, Rafa Marin Lopez wrote: > Hi Alper, sorry for the delayed answer. > > I agree with your comments. > > Personally, I would prefer PANA base spec "had in mind" when link is > unsecured and some kind of security association needs to be bootstrapped. > Mohan gave also some reasons for that ("per-packet ciphering at L2 or L3 if > the link-layer is not physically secured") > > Certainly PANA base spec does not need to be very specific on this > (others I-D will do that), but at least maintaining certain kind of > hooks like Protection-Capability AVP or PaC-EP-Master-Key generation > would be needed.(though i have doubts if this PaC-EP-Master-Key generation > should be specified in specific I-Ds explaining PANA-IPsec or > PANA-ieee802.11i > instead of pana-base spec). I agree, and this answers to issue [5] as well. " [5] Can we drop the enabling L2 security from the specs? People can still do that, but we'd avoid its discussion in the specs (which has raised many concerns, e.g., IEEE 802.11) " Yoshihiro Ohba > > Also my 0.01 cents. > > Alper Yegin wrote: > > >We know that client authentication is not sufficient to fully secure the > >network access. Per-packet integrity and origin authentication needs to be > >enabled. > > > >If we only consider the cases where such protection is enabled prior to > >PANA, that limits the deployment scenarios considerably. > > > >Besides, covering both types of cases has very limited impact on the base > >PANA protocol (a key derivation, and a capability exchange). > > > >For that, I don't think it makes sense to drop supporting the deployment > >case where aforementioned protection is enabled after successful PANA > >authentication. > > > >As for the use of IPsec, there is nothing specific to IPsec in the base > >protocol, aside from indicating its use via capability exchange. > > > >Whether PANA-IPsec I-D (draft-ietf-pana-ipsec-07.txt) is there or not is > >not > >going to make an impact on the base protocol specification. > > > >I think we need the PANA-IPsec I-D to ensure interoperability. > > > >My 0.02 cents. > > > >Alper > > > > > > > > > > > > > > > >>-----Original Message----- > >>From: Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] > >>Sent: Friday, June 09, 2006 9:42 AM > >>To: Yoshihiro Ohba; Basavaraj Patil > >>Cc: ext Julien Bournelle; ext Yoshihiro Ohba; pana@ietf.org; ext Mohan > >>Parthasarathy; 'Jari Arkko'; ext Rafa Marin Lopez; 'Mark Townsley' > >>Subject: Re: Drop pana-ipsec (Re: [Pana] IETF LC and discussion: Next > >>steps) > >> > >> > >> > >> > >> > >>>>Not clear about it. This was a proposal from > >>>> > >>>> > >>>Yoshi. > >>> > >>>How often or in which case PANA-Ping is performed is > >>>an implementation > >>>issue which we would not get into. > >>> > >>>PANA-Ping must work transparently to EPs just like > >>>other PANA > >>>messages do. > >>> > >>> > >>> > >>I guess we should take this in a separate > >>thread or offline..(Are you proposing this as an > >>alterntive to L2 or L3 ciphering). > >> > >> > >> > >>>>>>>However, if users also care integrity and > >>>>>>> > >>>>>>> > >>>>>>confidentiality > >>>>>> > >>>>>> > >>>>>>>of data packets and no VPN is used, the > >>>>>>> > >>>>>>> > >>>>>>functionality to bootstrap > >>>>>> > >>>>>> > >>>>>>>per-packet ciphering is needed. > >>>>>>> > >>>>>>> > >>>>>>This is optional as we have been said so in the > >>>>>> > >>>>>> > >>>past > >>> > >>> > >>>>>>as well. And we need to > >>>>>>de-couple this from the core PANA protocol. > >>>>>> > >>>>>> > >>>>>> > >>>>>How do you enforce that some malicious node is > >>>>>not getting free service without ciphering at > >>>>>L2 or L3 ? > >>>>> > >>>>> > >>>>You either rely on the existence of a L2 mechanism > >>>> > >>>> > >>>that is inherent to the > >>> > >>> > >>>>link or you figure out some other means of > >>>> > >>>> > >>>enforcing access control which > >>> > >>> > >>>>keeps malicious nodes from getting free service. > >>>>So the question is: > >>>>- Does PANA need to ensure that unsecured links > >>>> > >>>> > >>>have the ability to do > >>> > >>> > >>>>access control? How would PANA be able to > >>>> > >>>> > >>>determine if a link is secure or > >>> > >>> > >>>>not? Is there a way to figure that out? I don't > >>>> > >>>> > >>>think this can be easily > >>> > >>> > >>>>accomplished. Because even if a link layer has the > >>>> > >>>> > >>>capability to cipher, it > >>> > >>> > >>>>does not imply that it is enabled. > >>>> > >>>> > >>>There is no automatic way of knowing the security > >>>characteristics of > >>>the link. However, in the current PANA design, it > >>>is the PAA that > >>>determines (based on configuration) if a link is > >>>secure or not. The > >>>administrator that configures the PAA must have > >>>knowledge about the > >>>security characteristics of the link. PaCs need to > >>>follow the PAA's > >>>decision to use link layer ciphering determination > >>>or it will not get > >>>access. I don't think there is an issue in this > >>>design. > >>> > >>> > >>> > >>Yes, i agree that this is perfectly fine. > >> > >>-mohan > >> > >> > >> > >> > >> > >>>Yoshihiro Ohba > >>> > >>> > >>> > >>> > >>> > >>> > >>>>-Raj > >>>> > >>>> > >>>> > >>>> > >>>>>-mohan > >>>>> > >>>>> > >>>>> > >>>>>>>As far as I understand, PANA proposal in 3GPP2 > >>>>>>> > >>>>>>> > >>>>>>relied on this functionality. > >>>>>> > >>>>>>In the case of PP2 there is already capability > >>>>>> > >>>>>> > >>>to > >>> > >>> > >>>>>>cipher traffic at the > >>>>>>lower layer. So there is no reason to establish > >>>>>> > >>>>>> > >>>an > >>> > >>> > >>>>>>IPsec SA for user > >>>>>>traffic. But anyway, the PP2 discussion is > >>>>>>irrelevant here and I don't want > >>>>>>to go off on a tangent. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>An issue here would be whether > >>>>>>>this general functionality (i.e., use of > >>>>>>> > >>>>>>> > >>>>>>Protection-Capability AVP and > >>>>>> > >>>>>> > >>>>>>>PaC-EP-Master-Key) should be described in the > >>>>>>> > >>>>>>> > >>>base > >>> > >>> > >>>>>>specification, or > >>>>>> > >>>>>> > >>>>>>>in a separate document in which case document > >>>>>>> > >>>>>>> > >>>>>>structure (in terms of > >>>>>> > >>>>>> > >>>>>>>bootstrapping) could be: > >>>>>>> > >>>>>>> > >>>>>>My view is that PANA should not be concerned at > >>>>>> > >>>>>> > >>>all > >>> > >>> > >>>>>>about the user data > >>>>>>protection (i.e using IPsec between the PaC and > >>>>>> > >>>>>> > >>>EP). > >>> > >>> > >>>>>>>1. Base specification draft > >>>>>>> > >>>>>>> > >>>>>>This I-D along with the capability that deals > >>>>>> > >>>>>> > >>>with > >>> > >>> > >>>>>>sesssion hijacking (i.e > >>>>>>protected PANA ping). > >>>>>> > >>>>>> > >>>>>> > >>>>>>>2. General bootstrapping per-pacet ciphering > >>>>>>> > >>>>>>> > >>>draft > >>> > >>> > >>>>>>(defining > >>>>>> > >>>>>> > >>>>>>>Protection-Capability AVP and > >>>>>>> PaC-EP-Master-Key) > >>>>>>> > >>>>>>> > >>>>>>I don't think this is needed. Per-packet > >>>>>> > >>>>>> > >>>ciphering > >>> > >>> > >>>>>>and how this is enabled > >>>>>>by PANA is not something that we want to get > >>>>>> > >>>>>> > >>>into. > >>> > >>> > >>>>>>Not at this stage at > >>>>>>least. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>3. Lower-layer specific bootstrapping drafts > >>>>>>> > >>>>>>> > >>>>>>(pana-ipsec, pana-ieee80211doti) > >>>>>> > >>>>>>These are informational and need not form a > >>>>>> > >>>>>> > >>>core > >>> > >>> > >>>>>>aspect of what the WG > >>>>>>should deliver. > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Note that 2) is a small piece compared to > >>>>>>> > >>>>>>> > >>>other > >>> > >>> > >>>>>>optional feature such > >>>>>> > >>>>>> > >>>>>>>as NAP and ISP separate authentication. > >>>>>>> > >>>>>>> > >>>>>>Cheers, > >>>>>>-Raj > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Yoshihiro Ohba > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>-Raj > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>The general question would be whether we > >>>>>>>>> > >>>>>>>>> > >>>want > >>> > >>> > >>>>>>PANA supporting both cases > >>>>>> > >>>>>> > >>>>>>>>>or not. > >>>>>>>>> > >>>>>>>>>To understand, are you saying PANA should > >>>>>>>>> > >>>>>>>>> > >>>not > >>> > >>> > >>>>>>support b) in the base-spec? > >>>>>> > >>>>>> > >>>>>>>>What I am saying is that support for "b" is > >>>>>>>> > >>>>>>>> > >>>not a > >>> > >>> > >>>>>>core aspect of PANA and > >>>>>> > >>>>>> > >>=== message truncated === > >> > >> > >>_______________________________________________ > >>Pana mailing list > >>Pana@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pana > >> > >> > > > > > > > > > > > > > > > -- > ------------------------------------------------------ > Rafael Marin Lopez > Faculty of Computer Science-University of Murcia > 30071 Murcia - Spain > Telf: +34968367645 e-mail: rafa@dif.um.es > ------------------------------------------------------ > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From addagency@1000agents.com Fri Jun 30 20:45:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwTcF-0003y4-CC for pana-archive@lists.ietf.org; Fri, 30 Jun 2006 20:45:43 -0400 Received: from 201-43-62-138.dsl.telesp.net.br ([201.43.62.138] helo=usuario-erd8bc8) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwTcB-00084k-Vw for pana-archive@lists.ietf.org; Fri, 30 Jun 2006 20:45:43 -0400 Date: Sat, 1 Jul 2006 00:46:14 +0180 From: "Cara Baxter" X-Mailer: The Bat! (v2.00.5) Personal Reply-To: "Cara Baxter" X-Priority: 3 (Normal) Message-ID: <3999982529.20060701004614@1000agents.com> To: pana-archive@lists.ietf.org Subject: Hi, nail-studded MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Even if you have no erectin problems SOFT CIAzLIS would help you to make BETTER SE X MORE OFTEN! and to bring unimagnable plesure to her. Just disolve half a pil under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medic ation were able to have PERFECT ER ECTI ON during 36 hours! VISIT US, AND GET OUR SPECIAL 70% DISC OUNT OFER! http://BBLP3J.solvedebate.com ========== very bright and quick with their lessons. But the old feeling came back, store for me here?" glowed in his eyes. "Tell me what to do," But they insisted that it was a powerful thunderbolt that blinded them. By gull in the Flock, and he had learned skills that the others were only Reports--every issue has an article or. the empties with photos. He turned to land on the beach, beating his wings to stop an inch in bottle, at least a bottle, of the hard stuff.