From pana-request@research.telcordia.com Tue Jul 1 08:07:06 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11050 for ; Tue, 1 Jul 2003 08:06:55 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h61C3UCH027068; Tue, 1 Jul 2003 08:03:30 -0400 (EDT) Resent-Date: Tue, 1 Jul 2003 08:03:30 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Message-ID: <3F01787C.8040008@alcatel.fr> Date: Tue, 01 Jul 2003 14:03:08 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: pana@research.telcordia.com Subject: PAA-EP protocol candidates References: <3F004B28.5030509@alcatel.fr> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/01/2003 14:03:08, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/01/2003 14:03:09, Serialize complete at 07/01/2003 14:03:09 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by amavisd-new X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hello, below is a list of protocols that could potentially be used for the PAA-EP interface in the PANA framework. does the working group find this is a good start before discussing the way each one supports the PANA-specific requirements ? [http://yacine.free.fr/ietf/draft-yacine-pana-paa-ep-reqs.txt :] 4.9 Re-use of an existing protocol This work hopefully will not involve any new protocol design, it may involve definition of new AVPs for existing protocols. The PANA working group should try to re-use one of the many protocols around to do this. The following protocols were mentioned for consideration: . SNMP [SNMP] . COPS-PR [COPS-PR] . DIAMETER [DIAMETER] . RADIUS [RADIUS] . ForCES [ForCES] thanks, yacine From pana-request@research.telcordia.com Tue Jul 1 22:50:56 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25606 for ; Tue, 1 Jul 2003 22:50:46 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h622krGc005595; Tue, 1 Jul 2003 22:46:53 -0400 (EDT) Resent-Date: Tue, 1 Jul 2003 22:46:53 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 01 Jul 2003 19:48:05 -0700 Subject: Re: PAA-EP protocol candidates From: Alper Yegin To: CC: Message-ID: In-Reply-To: <3F01787C.8040008@alcatel.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Folks, At this point, we'd like people who are familiar with these protocols to talk about if and how they can satisfy the PAA-to-EP protocol requirements. Feel free to add more to the candidate list. For each candidate, we need to understand if they are generally suitable for this provisioning task, if they already support the required data types, if there needs to be additional development (e.g., creating new AVPs). The end result of this exercise would be something like this: Protocol X, Y, Z can readily be used for this, P and Q require new AVPs, R and S do not help this at all. Let's use draft-ietf-pana-requirements-07.txt as the baseline for the requirements. Cheers, Alper > hello, > > below is a list of protocols that could potentially be used for the > PAA-EP interface in the PANA framework. does the working group find this > is a good start before discussing the way each one supports the > PANA-specific requirements ? > > [http://yacine.free.fr/ietf/draft-yacine-pana-paa-ep-reqs.txt :] > > 4.9 Re-use of an existing protocol > > This work hopefully will not involve any new protocol design, it may > involve definition of new AVPs for existing protocols. The PANA > working group should try to re-use one of the many protocols around > to do this. The following protocols were mentioned for consideration: > > . SNMP [SNMP] > . COPS-PR [COPS-PR] > . DIAMETER [DIAMETER] > . RADIUS [RADIUS] > . ForCES [ForCES] > > > > thanks, > yacine > > From pana-request@research.telcordia.com Wed Jul 2 06:00:23 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00203 for ; Wed, 2 Jul 2003 06:00:21 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h629nQZ9019875; Wed, 2 Jul 2003 05:49:26 -0400 (EDT) Resent-Date: Wed, 2 Jul 2003 05:49:26 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Message-ID: <3F02AA79.6000201@alcatel.fr> Date: Wed, 02 Jul 2003 11:48:41 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: Alper Yegin CC: pana@research.telcordia.com Subject: Re: PAA-EP protocol candidates References: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/02/2003 11:48:41, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/02/2003 11:49:07 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Alper Yegin a =E9crit: > Folks, >=20 > At this point, we'd like people who are familiar with these protocols to > talk about if and how they can satisfy the PAA-to-EP protocol requirement= s. > Feel free to add more to the candidate list. >=20 > For each candidate, we need to understand if they are generally suitable = for > this provisioning task, if they already support the required data types, = if > there needs to be additional development (e.g., creating new AVPs). >=20 > The end result of this exercise would be something like this: Protocol X,= Y, > Z can readily be used for this, P and Q require new AVPs, R and S do not > help this at all. >=20 > Let's use draft-ietf-pana-requirements-07.txt as the baseline for the > requirements. FYI, the corresponding section within this I-D says: - the protocol must carry DI and keys - there might be multiple EPs per PAA - the protocol must be secured - whether it must support push, pull, or both, depends on the PANA design. >=20 > Cheers, >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >>hello, >> >>below is a list of protocols that could potentially be used for the >>PAA-EP interface in the PANA framework. does the working group find this >>is a good start before discussing the way each one supports the >>PANA-specific requirements ? >> >>[http://yacine.free.fr/ietf/draft-yacine-pana-paa-ep-reqs.txt :] >> >>4.9 Re-use of an existing protocol >> >> This work hopefully will not involve any new protocol design, it may >> involve definition of new AVPs for existing protocols. The PANA >> working group should try to re-use one of the many protocols around >> to do this. The following protocols were mentioned for consideration: >> >> . SNMP [SNMP] >> . COPS-PR [COPS-PR] >> . DIAMETER [DIAMETER] >> . RADIUS [RADIUS] >> . ForCES [ForCES] >> >> >> >>thanks, >>yacine >> >> >=20 >=20 >=20 From pana-request@research.telcordia.com Wed Jul 2 23:30:42 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13063 for ; Wed, 2 Jul 2003 23:30:33 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h633LFLG017771; Wed, 2 Jul 2003 23:21:15 -0400 (EDT) Resent-Date: Wed, 2 Jul 2003 23:21:15 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 02 Jul 2003 20:22:32 -0700 Subject: IETF 57 PANA WG meeting agenda From: Alper Yegin To: CC: "'Basavaraj.Patil@nokia.com'" , Erik Nordmark , Thomas Narten Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit This is the proposed agenda for the IETF 57 PANA WG meeting. - Chairs Protocol for Carrying Authentication for Network Access (PANA) Monday, July 14 at 1300-1500 ============================== CHAIRS: Basavaraj Patil Alper Yegin AGENDA: 1. Preliminaries (bluesheets, minute takers, agenda bashing) : 5 min Chairs 2. PANA design update and open issues : 30 min I-D: draft-ietf-pana-pana-01.txt Yoshihiro Ohba 3. Securing the first hop in PANA using IPsec : 20 min I-D: draft-mohanp-pana-ipsec-00.txt Hannes Tschofenig 4. PAA-to-EP protocol considerations : 20 min Yacine El Mghazli 5. Roadmap : 5 min Chairs Status of WG I-Ds: - draft-ietf-pana-usage-scenarios-06.txt WG last call completed on 3/11. Draft is sent to ADs for IESG consideration. - draft-ietf-pana-requirements-07.txt WG last call completed on 6/12. Draft is sent to ADs for IESG consideration. - draft-ietf-pana-threats-eval-04.txt WG last call completed on 5/1. Draft is sent to ADs for IESG consideration. - draft-ietf-pana-pana-01.txt Work in progress. From pana-request@research.telcordia.com Thu Jul 3 14:23:57 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29780 for ; Thu, 3 Jul 2003 14:23:55 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h63IEq4M024096; Thu, 3 Jul 2003 14:14:52 -0400 (EDT) Resent-Date: Thu, 3 Jul 2003 14:14:52 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 03 Jul 2003 11:15:59 -0700 Subject: Review and provide feedback From: Alper Yegin To: Message-ID: In-Reply-To: <200307022033.QAA12974@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hello, The new version of PANA draft is available now. Please review and provide feedback before the IETF meeting. http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-01.txt Alper ------ Forwarded Message From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Wed, 02 Jul 2003 16:33:10 -0400 To: IETF-Announce: ; Cc: pana@research.telcordia.com Subject: I-D ACTION:draft-ietf-pana-pana-01.txt 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 : Protocol for Carrying Authentication for Network Access (PANA) Author(s) : D. Forsberg et al. Filename : draft-ietf-pana-pana-01.txt Pages : 52 Date : 2003-7-2 This document defines the Protocol for Carrying Authentication for Network Access (PANA), a link-layer agnostic transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. PANA can carry any authentication method that can be specified as an EAP method, and can be used on any link that can carry IP. PANA covers the client-to-network access authentication part of an overall secure network access framework, which additionally includes other protocols and mechanisms for service provisioning, access control as a result of initial authentication, and accounting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-pana-01.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-pana-01.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. ------ End of Forwarded Message From pana-request@research.telcordia.com Thu Jul 3 22:58:09 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01163 for ; Thu, 3 Jul 2003 22:58:04 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h642jx2O010557; Thu, 3 Jul 2003 22:45:59 -0400 (EDT) Resent-Date: Thu, 3 Jul 2003 22:45:59 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 3 Jul 2003 19:45:55 -0700 To: Yacine.El_Mghazli@alcatel.fr Cc: pana@research.telcordia.com Subject: Re: PAA-EP protocol requirements (cont'd) Message-ID: <20030704024517.GA4665@steelhead> Mail-Followup-To: Yacine.El_Mghazli@alcatel.fr, pana@research.telcordia.com References: <3F004B28.5030509@alcatel.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <3F004B28.5030509@alcatel.fr> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 57 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com First of all, I think this is a good document to understand the issues related to PAA-EP communication. Please see specific comments below. "4.3 One-to-many PAA-EP relation One PAA have to communicate with several Eps once a PaC is authenticated. The PAA-EP protocol must be able to handle this 1:n communication." I think there is some case in which one-to-many PAA-EP relation may not be necessary. For example, if EP and PAA are co-located with 802.11 APs and the APs are in the same LAN, the PAA on one AP does not need to communicate with EPs on another AP, since a PaC (or a 802.11 station with a specific MAC address) is always associated with a single AP at a time. If the PaC switches to a new AP, it might just perform PANA (re-)authentication with the PAA on the new AP which will then install filters on the co-located EP. "4.8 Accounting/Feedback from the EPs The PAA must have an efficient way to to get the accounting information of PaC from EP since the PAA may be a client of the AAA backend infrastructure." I think the PAA does not always need to get the accounting information of PaC from EP. For example, Diameter allows separation of accounting from authentication/authorization. EP can be a Diameter accounting application client while PAA can be a Diameter authentication/authorization application client. "4.9 Re-use of an existing protocol This work hopefully will not involve any new protocol design, it may involve definition of new AVPs for existing protocols. The PANA working group should try to re-use one of the many protocols around to do this. The following protocols were mentioned for consideration: . SNMP [SNMP] . COPS-PR [COPS-PR] . DIAMETER [DIAMETER] . RADIUS [RADIUS] . ForCES [ForCES]" The reference to ForCES seems to be missing in the draft. "DIAMETER" should be "Diameter". I think we can simply drop RADIUS from the list (perhaps with a short note), since Diameter covers all what RADIUS can do. Thanks, Yoshihiro Ohba From pana-request@research.telcordia.com Fri Jul 4 06:20:29 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22432 for ; Fri, 4 Jul 2003 06:20:26 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h649m83N022271; Fri, 4 Jul 2003 05:48:08 -0400 (EDT) Resent-Date: Fri, 4 Jul 2003 05:48:08 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Message-ID: <3F054D4A.80807@alcatel.fr> Date: Fri, 04 Jul 2003 11:47:54 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: Yoshihiro Ohba CC: pana@research.telcordia.com Subject: Re: PAA-EP protocol requirements (cont'd) References: <3F004B28.5030509@alcatel.fr> <20030704024517.GA4665@steelhead> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/04/2003 11:47:54, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/04/2003 11:47:59, Serialize complete at 07/04/2003 11:47:59 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-2022-JP X-Virus-Scanned: by amavisd-new X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit hi yoshihiro, Yoshihiro Ohba a e'crit: > > First of all, I think this is a good document to understand the issues > related to PAA-EP communication. Please see specific comments below. thx > > > "4.3 One-to-many PAA-EP relation > > One PAA have to communicate with several Eps once a PaC is > authenticated. The PAA-EP protocol must be able to handle this 1:n > communication." > > I think there is some case in which one-to-many PAA-EP relation may > not be necessary. For example, if EP and PAA are co-located with > 802.11 APs and the APs are in the same LAN, the PAA on one AP does not > need to communicate with EPs on another AP, since a PaC (or a 802.11 > station with a specific MAC address) is always associated with a > single AP at a time. If the PaC switches to a new AP, it might just > perform PANA (re-)authentication with the PAA on the new AP which will > then install filters on the co-located EP. 1) one-to-many includes one-to-one, this req is just to say a PAA may deal with several EPs. 2) if PAA and EP are co-located, there's no protocol at all. > > "4.8 Accounting/Feedback from the EPs > > The PAA must have an efficient way to to get the accounting > information of PaC from EP since the PAA may be a client of the AAA > backend infrastructure." > > I think the PAA does not always need to get the accounting information > of PaC from EP. For example, Diameter allows separation of accounting > from authentication/authorization. EP can be a Diameter accounting > application client while PAA can be a Diameter > authentication/authorization application client. agree this is not a hard requirement and agree also on the separation auth/acc. I guess it's only a nice-to-have functionality on this interface... FYI, at the origin of this req was: ftp://ftp.research.telcordia.com/pub/Group.archive/pana/webview/msg01664.html > > > "4.9 Re-use of an existing protocol > > This work hopefully will not involve any new protocol design, it may > involve definition of new AVPs for existing protocols. The PANA > working group should try to re-use one of the many protocols around > to do this. The following protocols were mentioned for consideration: > > . SNMP [SNMP] > . COPS-PR [COPS-PR] > . DIAMETER [DIAMETER] > . RADIUS [RADIUS] > . ForCES [ForCES]" > > The reference to ForCES seems to be missing in the draft. The protocol is under construction in the forces wg, but the frwk is available (see below). it deals with control/forwarding separation and forces is the protocol for the interface between the two. http://www.ietf.org/internet-drafts/draft-ietf-forces-framework-06.txt > "DIAMETER" should be "Diameter". ok. > > I think we can simply drop RADIUS from the list (perhaps with a short note), > since Diameter covers all what RADIUS can do. agree. > > > Thanks, > Yoshihiro Ohba > From pana-request@research.telcordia.com Fri Jul 4 10:48:31 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28543 for ; Fri, 4 Jul 2003 10:48:22 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h64EaceF001796; Fri, 4 Jul 2003 10:36:38 -0400 (EDT) Resent-Date: Fri, 4 Jul 2003 10:36:38 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Message-ID: <3F0590EA.6060708@alcatel.fr> Date: Fri, 04 Jul 2003 16:36:26 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: pana@research.telcordia.com Subject: PAA-EP prots comparison References: <3F02AA79.6000201@alcatel.fr> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/04/2003 16:36:26, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/04/2003 16:36:31, Serialize complete at 07/04/2003 16:36:31 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by amavisd-new X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit below is a brief comparison of SNMP, COPS-PR and Diameter protocols against the requirements in draft-ietf-pana-requirements-07.txt, please see inline: conclusion: BASED ON THESE REQUIREMENTS ONLY, all three protocols are nearly equivalent winners. SNMP and COPS -- explicit management protocols -- fits better (especially for the data contained: DI-rules, keys, etc.) the provioning context of the PAA-EP interface. now all depends on the PANA protocol design and working group expectations in term of functionalities on such a provisioning interface. thanks, yacine > - the protocol must carry DI and keys - SNMP: already defined MIBs (for filters, ipsec policy, etc.) can be re-used. if not sufficient, PANA-specific MIBs can be designed. - COPS-PR: already defined PIBs (for filters, ipsec policy, etc.) can be re-used. if not sufficient, PANA-specific PIBs can be designed. - Diameter: IPfilterRule data type available, but a new PANA application extension of Diameter would certainly have to be defined. > - there might be multiple EPs per PAA - SNMP: An SNMP manager (PAA) can communicate simultaneously with several agents (EPs). - COPS-PR: COPS-PR PDPs (PAAs) are designed to communicate with several PEPs (EPs). - Diameter: Diameter allows connection to more than one peer (and encourages this for improved reliability). Whether the Diameter connection state machine is too heavy to support the number of connections needed is a matter for discussion. > - the protocol must be secured - SNMP: SNMPv3 includes the User-based Security Model (USM, [RFC2574]), which defines three standardized methods for providing authentication, confidentiality, and integrity. Additionally, USM has specific built-in mechanisms for preventing replay attacks including unique protocol engine IDs, timers and counters per engine and time windows for the validity of messages. - COPS-PR: COPS-PR has built-in message level security for authentication, replay protection, and message integrity. COPS-PR can also use TLS or IPSec, thus reusing existing security mechanisms that have interoperated in the markets. - Diameter: Diameter relies on either IPSEC or TLS for these functions. > - whether it must support push, pull, or both, depends on the PANA > design. - SNMP: push model with bottom-up notifications. - COPS-PR: push, pull or both models supported. - Diameter: The Diameter protocol permits either peer in a connection to originate transactions. Thus the protocol supports EP-originated messages. From pana-request@research.telcordia.com Fri Jul 4 11:04:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28843 for ; Fri, 4 Jul 2003 11:04:51 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h64EsMMo002388; Fri, 4 Jul 2003 10:54:22 -0400 (EDT) Resent-Date: Fri, 4 Jul 2003 10:54:22 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Message-ID: <3F059517.3050506@alcatel.fr> Date: Fri, 04 Jul 2003 16:54:15 +0200 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: pana@research.telcordia.com Subject: Re: PAA-EP prots comparison References: <3F02AA79.6000201@alcatel.fr> <3F0590EA.6060708@alcatel.fr> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/04/2003 16:54:14, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 07/04/2003 16:54:15 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable the draft below about COPS-PR applicability: http://ietf.org/internet-drafts/draft-yacine-pana-cops-ep-00.txt it needs to be updated for taking into account the explicit PANA=20 requirements. thanks, yacine Yacine.El=5FMghazli@alcatel.fr a =E9crit: > below is a brief comparison of SNMP, COPS-PR and Diameter protocols=20 > against the requirements in draft-ietf-pana-requirements-07.txt, please=20 > see inline: >=20 > conclusion: > BASED ON THESE REQUIREMENTS ONLY, all three protocols are nearly=20 > equivalent winners. SNMP and COPS -- explicit management protocols --=20 > fits better (especially for the data contained: DI-rules, keys, etc.)=20 > the provioning context of the PAA-EP interface. >=20 > now all depends on the PANA protocol design and working group=20 > expectations in term of functionalities on such a provisioning interface. >=20 > thanks, > yacine >=20 >=20 >=20 > > - the protocol must carry DI and keys >=20 > - SNMP: already defined MIBs (for filters, ipsec policy, etc.) can be=20 > re-used. if not sufficient, PANA-specific MIBs can be designed. > - COPS-PR: already defined PIBs (for filters, ipsec policy, etc.) can be = > re-used. if not sufficient, PANA-specific PIBs can be designed. > - Diameter: IPfilterRule data type available, but a new PANA application = > extension of Diameter would certainly have to be defined. >=20 > > - there might be multiple EPs per PAA >=20 > - SNMP: An SNMP manager (PAA) can communicate simultaneously with=20 > several agents (EPs). > - COPS-PR: COPS-PR PDPs (PAAs) are designed to communicate with several=20 > PEPs (EPs). > - Diameter: Diameter allows connection to more than one peer (and=20 > encourages this for improved reliability). Whether the Diameter=20 > connection state machine is too heavy to support the number of=20 > connections needed is a matter for discussion. >=20 > > - the protocol must be secured >=20 > - SNMP: SNMPv3 includes the User-based Security Model (USM, [RFC2574]), = > which defines three standardized methods for providing authentication,=20 > confidentiality, and integrity. Additionally, USM has specific built-in = > mechanisms for preventing replay attacks including unique protocol=20 > engine IDs, timers and counters per engine and time windows for the=20 > validity of messages. > - COPS-PR: COPS-PR has built-in message level security for=20 > authentication, replay protection, and message integrity. COPS-PR can=20 > also use TLS or IPSec, thus reusing existing security mechanisms that=20 > have interoperated in the markets. > - Diameter: Diameter relies on either IPSEC or TLS for these functions. >=20 > > - whether it must support push, pull, or both, depends on the PANA > > design. >=20 > - SNMP: push model with bottom-up notifications. > - COPS-PR: push, pull or both models supported. > - Diameter: The Diameter protocol permits either peer in a connection to = > originate transactions. Thus the protocol supports EP-originated messages. >=20 >=20 >=20 From pana-request@research.telcordia.com Mon Jul 7 07:31:36 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21390 for ; Mon, 7 Jul 2003 07:31:35 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h67BHekW019020; Mon, 7 Jul 2003 07:17:40 -0400 (EDT) Resent-Date: Mon, 7 Jul 2003 07:17:40 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: To: nemo@nal.motlabs.com, manet@ietf.org, mobile-ip@sunroof.eng.sun.com, pana@research.telcordia.com Cc: inoue@isl.rdc.toshiba.co.jp Subject: CFP:: First International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2004) In-Reply-To: Your message of "Mon, 12 May 2003 20:42:52 +0900" <20030512204252N.inoue@isl.rdc.toshiba.co.jp> References: <20030512204252N.inoue@isl.rdc.toshiba.co.jp> X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030707201521A.inoue@isl.rdc.toshiba.co.jp> Date: Mon, 07 Jul 2003 20:15:21 +0900 From: Atsushi Inoue X-Dispatcher: imput version 980905(IM100) Lines: 84 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit (Apologies if you receive multiple copies) CALL FOR PAPERS =============== First International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2004) January 8 and 9, 2004 NTT DoCoMo R&D Center, Yokosuka Rsearch Park, Yokosuka, JAPAN http://www.ipsj.or.jp/sig/mbl/icmu2004/ Deadline for submissions: August 1 2003 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Co-sponsored by IPSJ SIG-MBL (Informaiton Processing Society of Japan, Special Interest Group of Mobile Computing and Ubiquitous Networking) and IPSJ SG-BCC (Study Group of Broadcast Communicaiton and Computing) Scope: ~~~~~~ Mobile computing aims at ubiquitous user access to computer application. To make it possible, networking technology which enables Internet access anytime and everywhere, i.e. ubiquitous networking is necessary. It is obvious that with the accelerating trends towards mobile networks, ad-hoc networks, and wireless networks, mobile computing and ubiquitous networking will play an important role in future network. This conference is aimed at providing researchers and practitioners in this hot research area a forum for discussion and collaboration. Authors are invited to submit papers addressing, but not limited to, the following topics: - Applications and services for mobile computing - Network architectures, protocols, or service models for ubiquitous networking - Network management for ubiquitous networking - Data management for mobile computing - Security in mobile computing and ubiquitous networking - Wireless and mobile communications - Nomadic computing - Ad-hoc networks - Mobile Internetworking - Performance evaluation for mobile computing and ubiquitous networking systems - Broadcast communication Submission Instructions: ~~~~~~~~~~~~~~~~~~~~~~~~ Papers are solicited as full papers of no more than 6 pages, each of which will be subject to a full review process. Submission should already follow the author guidelines as specified in the web site below. An electronic, PDF-based submission of papers is mandatory. Please check Submission Guideline (http://www.ipsj.or.jp/sig/mbl/icmu2004/guide.html) for further submission instructions. Important Dates: ~~~~~~~~~~~~~~~~ - Deadline for submissions August 1, 2003 - Notification of acceptance October 1, 2003 - Camera ready due November 1, 2003 - Conference January 8-9, 2004 Location and Date: ~~~~~~~~~~~~~~~~~~ The location of the NTT DoCoMo R&D Center is in the heart of Yokosuka Research Park(YRP) where a lot of wireless communication related research institutes are established. YRP is really the heart of wireless communications research in Japan. Japanese old city Kamakura, a famous historic city, is 30 minutes by train. Beginning of the year is one of the best seasons for visiting Japan. You can also get PDF version of Call for Papers from http://www.ipsj.or.jp/sig/mbl/icmu2004/cfp-icmu2004.pdf Atsushi Inoue # Phone: +81-44-549-2065 Communication Platform Lab. # Fax: +81-44-520-1806 TOSHIBA R&D Center # inoue@isl.rdc.toshiba.co.jp From pana-request@research.telcordia.com Tue Jul 8 21:54:29 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18880 for ; Tue, 8 Jul 2003 21:54:26 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h691gCvE007044; Tue, 8 Jul 2003 21:42:12 -0400 (EDT) Resent-Date: Tue, 8 Jul 2003 21:42:12 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 08 Jul 2003 18:43:33 -0700 Subject: IETF 57 PANA meeting agenda (final) From: Alper Yegin To: CC: "Patil Basavaraj (NET/Dallas)" , Erik Nordmark , Thomas Narten Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Protocol for Carrying Authentication for Network Access (PANA) Monday, July 14 at 1300-1500 ============================== CHAIRS: Basavaraj Patil Alper Yegin WEB PAGES: Official: http://ietf.org/html.charters/pana-charter.html Supplemental: http://www.toshiba.com/tari/pana/pana.htm AGENDA: 1. Preliminaries (bluesheets, minute takers, agenda bashing) : Chairs, 5 min 2. PANA design update and open issues : Yoshihiro Ohba, 40 min I-D: draft-ietf-pana-pana-01.txt. Please see http://danforsberg.info:8080/pana-issues/ for the current issues. The intent of this agenda item is to use the facetime to close some of the open issues via discussion. 3. Securing the first hop in PANA using IPsec : Hannes Tschofenig, 20 min I-D: draft-mohanp-pana-ipsec-00.txt. This I-D is proposing a mechanism for enabling IPsec-based per-packet authentication once the client is authenticated by using PANA. The purpose of this presentation is to gauge WG interest in the topic and solicit comments. The I-D will be proposed as a candidate WG item. 4. PAA-to-EP protocol considerations : Yacine El Mghazli, 20 min The PANA deployment may be such that the PAA and EP may be separate (for example, the WLAN AP which is the EP and the AR which would be the PAA). If that is the case then there is a need for a protocol that enables the ACLs or filters to be downloaded to the EP. WG has already identified the requirements for this protocol, but we need to evaluate what kind of protocols make sense. Especially people who are familiar with protocols like Diameter, COPS, SNMP, and ForCES are encouraged to participate. The purpose of this presentation is to gauge WG interest in this topic and solicit feedback. 5. Roadmap : 5 min Chairs STATUS of WG I-Ds: - draft-ietf-pana-usage-scenarios-06.txt WG last call completed on 3/11. Draft is sent to ADs for IESG consideration. - draft-ietf-pana-requirements-07.txt WG last call completed on 6/12. Draft is sent to ADs for IESG consideration. - draft-ietf-pana-threats-eval-04.txt WG last call completed on 5/1. Draft is sent to ADs for IESG consideration. - draft-ietf-pana-pana-01.txt Work in progress. I-D will be discussed at IETF 57. From pana-request@research.telcordia.com Wed Jul 9 09:41:11 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00546 for ; Wed, 9 Jul 2003 09:40:49 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h69DRwnZ002045; Wed, 9 Jul 2003 09:27:58 -0400 (EDT) Resent-Date: Wed, 9 Jul 2003 09:27:58 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 9 Jul 2003 15:25:53 +0200 From: Julien Bournelle To: Alper Yegin Cc: pana@research.telcordia.com Subject: Re: Review and provide feedback Message-ID: <20030709132553.GM2892@ipv6-5.int-evry.fr> References: <200307022033.QAA12974@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Julien Bournelle X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hello, Some quick comments: - In the terminology section we have: " PANA Security Association: ...This security association includes the device identifier of the peer, and a shared key when available" On the other hand, we have section 4.1.5 PANA Security Association: "A PANA SA is created of a PANA session when EAP authentication succeeds with a creation of a MSK" So I think that in a PANA SA we always have a shared key derived from the EAP authentication. Maybe we need a change in the terminology section. - In section 4.2 Discover and Initial Handshake Phase . I guess that it lacks a word at the end of the first paragraph p. 11 . Figure 2 p 12 s/PANA-Start-Answer(x,y)/PANA-Start-Answer(y,x) - Section 4.4 Re-authentication .s/PANA-PAA-Discovery/PANA-PAA-Discover .It is written that the PAA must search if it has an existing session with a PaC sending a PANA-PAA-Discovery message by using DI. Isn't there a potential risk of DoS attack ? .Figure 5: s/PANA-Reauth-Request/PANA-PAA-Discover ? - section 4.5 It is stated that all messages exchanged during the termination phase MSUT be protected by a MAC AVP. The problem is that it means that we need a PANA SA with a shared key, as such, PANA MUST only carry EAP methods enabling key derivation. Do I miss something ? - Section 9.4.7 we don't have the notion of Command as in Diameter so I'm not sure if it is necessary to incorporate the error COMMAND_UNSUPPORTED. Just my 0.2 euros, -- julien.bournelle@int-evry.fr From pana-request@research.telcordia.com Mon Jul 14 12:41:32 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03144 for ; Mon, 14 Jul 2003 12:41:25 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h6EGVWZX016903; Mon, 14 Jul 2003 12:31:32 -0400 (EDT) Resent-Date: Mon, 14 Jul 2003 12:31:32 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Message-ID: <20030714163005.30497.qmail@web40013.mail.yahoo.com> Date: Mon, 14 Jul 2003 09:30:05 -0700 (PDT) From: Reinaldo Penno Subject: Comments on pana-01 To: pana@research.telcordia.com Cc: rapenno@yahoo.com In-Reply-To: <3F02AA79.6000201@alcatel.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <4QOrCC.A.-HE.krtE_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hello, here it goes some comments on pana-01. I've been away for a while so please discard any issues that have already been discussed in the list. 1) There is a typo in Page 8, first phrase. It reads "...it is considered as valid..." I suggest "it is considered valid" 2) In the end of section 4.1.7 there is a TBD regarding non-acknowledgement error notification message MAY being returned to the sender. IMO such messages help quite a lot during troubleshooting in deployments and interoperability. If there is a concern of DoS attacks we could use a timer so that we return 1 error notification to each different sender each N seconds. 3) In section 4.2, paragraph 3 it is mentioned that "The result does not depend on which PAA PaC chooses. By default PaC chooses the PAA that sent the first reponse" This is the DHCP approach. Where all servers are equally good. I would propose that we think about incorporating something of the PPPoE protocol that is widespread, since PANA is more related to the PPPoE model. In the response of the Discovery message each PPPoE server include all the Service Profile (names) it supports (the definition is loose on purpose). Nowadays it is usually a list of ISPs or bandwidth packages a user can choose. I would argue that in the case of PANA (and specially in the case of NAP vs ISP authentication), PAA servers might support a very different set of attributes and a PaC might prefer one over the other if it new of each choices. We could have a AVP in PANA for that purpose in the answer to the Discovery message. it seems very simple, could be optional and will provide a crucial functionality for people that use PPPoE to migrate to PANA. 4) In page1, end of first paragraph there is a typo. It reads "...PAA MUST be protected by using. using what? 5) In page 13 the first two phrases of the second paragraph seem unrelated. The phrases are "...MUST contain a MAC AVP. The PANA-Bind-Request..." I guess what you are trying to say is that PANA-Bind-Request/Answer messages will be protected by the MAC AVP?? Maybe it's the timezone, but I feel the phrases are disconnected. 6) In section 4.7, the third paragraph has a lot of strong statements regarding what should be used as the device ID without any MUST ot SHOULD. If we want to make such a case we should capitalize the should(s) in the paragraph. regards, Reinaldo __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From pana-request@research.telcordia.com Tue Jul 15 02:45:34 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25570 for ; Tue, 15 Jul 2003 02:45:19 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h6F6Z0s8010149; Tue, 15 Jul 2003 02:35:00 -0400 (EDT) Resent-Date: Tue, 15 Jul 2003 02:35:00 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 14 Jul 2003 23:36:23 -0700 Subject: PANA-DHCP draft From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit PANA-DHCP (draft-tschofenig-pana-bootstrap-rfc3118-00.txt) draft will be presented at the DHC WG and EAP WG meetings: http://ietf.org/ietf/03jul/dhc.txt (this is Tuesday morning!) http://ietf.org/ietf/03jul/eap.txt (Thursday). Sorry for the late notice. Alper From pana-request@research.telcordia.com Tue Jul 15 12:05:05 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25439 for ; Tue, 15 Jul 2003 12:05:01 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h6FFtsIL004123; Tue, 15 Jul 2003 11:55:54 -0400 (EDT) Resent-Date: Tue, 15 Jul 2003 11:55:54 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 15 Jul 2003 08:57:11 -0700 Subject: IEEE Linksec From: Alper Yegin To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Please see the IEEE Linksec group information below: To get on the LinkSec email list: http://www.ieee802.org/linksec/reflector.html Let me know if you have any problems. The LinkSec home page is at: http://www.ieee802.org/linksec/ If you have trouble accessing it pleast let me know. It would be useful to understand what this group is doing, and its relation to PANA. Alper From pana-request@research.telcordia.com Wed Jul 16 11:59:37 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06892 for ; Wed, 16 Jul 2003 11:59:31 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h6GFoieG024842; Wed, 16 Jul 2003 11:50:44 -0400 (EDT) Resent-Date: Wed, 16 Jul 2003 11:50:44 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 16 Jul 2003 08:33:41 -0700 From: Yoshihiro Ohba Subject: Re: Comments on pana-01 In-reply-to: <20030714163005.30497.qmail@web40013.mail.yahoo.com> To: Reinaldo Penno Cc: pana@research.telcordia.com Message-id: <20030716153229.GA1479@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Reinaldo Penno , pana@research.telcordia.com User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 118 References: <3F02AA79.6000201@alcatel.fr> <20030714163005.30497.qmail@web40013.mail.yahoo.com> X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hi Reinaldo, Thanks for sending the comments. Please see my comments in line. On Mon, Jul 14, 2003 at 09:30:05AM -0700, Reinaldo Penno wrote: > Hello, > > here it goes some comments on pana-01. I've been away > for a while so please discard any issues that have > already been discussed in the list. > > 1) There is a typo in Page 8, first phrase. It reads > "...it is considered as valid..." > > I suggest "it is considered valid" > OK. > 2) In the end of section 4.1.7 there is a TBD > regarding non-acknowledgement error notification > message MAY being returned to the sender. > > IMO such messages help quite a lot during > troubleshooting in deployments and interoperability. I agree to define some informational exchange for error reporting. > > If there is a concern of DoS attacks we could use a > timer so that we return 1 error notification to each > different sender each N seconds. Yes, the rate of such informational message exchanges should be limited in implementations. We can discuss these things in issue 17 "Error handling". > > 3) In section 4.2, paragraph 3 it is mentioned that > "The result does not depend on which PAA PaC chooses. > By default PaC chooses the PAA that sent the first > reponse" > > This is the DHCP approach. Where all servers are > equally good. > > I would propose that we think about incorporating > something of the PPPoE protocol that is widespread, > since PANA is more related to the PPPoE model. > > In the response of the Discovery message each PPPoE > server include all the Service Profile (names) it > supports (the definition is loose on purpose). > Nowadays it is usually a list of ISPs or bandwidth > packages a user can choose. > > I would argue that in the case of PANA (and specially > in the case of NAP vs ISP authentication), PAA servers > might support a very different set of attributes and a > PaC might prefer one over the other if it new of each > choices. > > We could have a AVP in PANA for that purpose in the > answer to the Discovery message. it seems very simple, > could be optional and will provide a crucial > functionality for people that use PPPoE to migrate to > PANA. When we dicussed NAP and ISP separate authentication, I think the assumption is that there is a single PAA the PaC sees, and the NAI is used to choose a particular ISP. Why do you need multiple PAAs to support NAP and ISP separate authentication? > > 4) In page1, end of first paragraph there is a typo. > It reads "...PAA MUST be protected by using. > > using what? In the previous version, it said "... by using, e.g., IPsec." I think the text was accidentally cut during the editing process of the current version. > > 5) In page 13 the first two phrases of the second > paragraph seem unrelated. The phrases are "...MUST > contain a MAC AVP. The PANA-Bind-Request..." > > I guess what you are trying to say is that > PANA-Bind-Request/Answer messages will be protected by > the MAC AVP?? Maybe it's the timezone, but I feel the > phrases are disconnected. The two sentenses are unrelated but not written well. We will revise the text. Note that the first sentense is trying to say that PANA-Bind-Request/Answer messages and subsequent messages will be protected by MAC AVP. > > 6) In section 4.7, the third paragraph has a lot of > strong statements regarding what should be used as the > device ID without any MUST ot SHOULD. If we want to > make such a case we should capitalize the should(s) in > the paragraph. I agree. > > regards, > > Reinaldo > Thanks, Yoshihiro Ohba From pana-request@research.telcordia.com Wed Jul 16 14:57:34 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12698 for ; Wed, 16 Jul 2003 14:57:34 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h6GImSDi003628; Wed, 16 Jul 2003 14:48:28 -0400 (EDT) Resent-Date: Wed, 16 Jul 2003 14:48:28 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 16 Jul 2003 11:49:46 -0700 Subject: draft-mohanp-pana-ipsec-00.txt for WG item? From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Dear WG members, As you remember, at IETF 56 we arrived at a consensus to develop an informational RFC for turning PANA SA into IPsec SA for enabling IPsec-based access control. Given that this is the WG decision, we are asking PANA WG: Should draft-mohanp-pana-ipsec-00.txt be adopted as "the" WG item addressing this deliverable? Here is the result of the call: 15: yes, we should adopt this draft. 5: no, we should not adopt this draft. Please comment if you have any. Unless there is any substantial reason to change this result, the next version of draft-mohanp-pana-ipsec-00.txt will become official PANA WG item. - PANA WG chairs From pana-request@research.telcordia.com Thu Jul 24 19:05:42 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05474 for ; Thu, 24 Jul 2003 19:05:37 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h6OMuiMw018697; Thu, 24 Jul 2003 18:56:44 -0400 (EDT) Resent-Date: Thu, 24 Jul 2003 18:56:44 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Q: Implementations of PANA Protocol Date: Thu, 24 Jul 2003 17:56:37 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DB48A@daebe007.americas.nokia.com> Thread-Topic: Q: Implementations of PANA Protocol Thread-Index: AcNSNtct8OzU2xETS9msc/owARefbQ== From: To: X-OriginalArrivalTime: 24 Jul 2003 22:56:37.0644 (UTC) FILETIME=[D67884C0:01C35236] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Hello, At IETF57 we asked if there were people implementing the PANA protocol. We did have a positive response to this question and there are at least 3 implementations in progress currently. We would = like to do some sort of interoperability testing in the near future and hence would like to know if there are other folks (who were not at IETF57) who are implementing the protocol now or would be doing so in the near future? -Chairs From pana-request@research.telcordia.com Fri Jul 25 20:42:29 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03684 for ; Fri, 25 Jul 2003 20:42:28 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h6Q0X5D4010200; Fri, 25 Jul 2003 20:33:05 -0400 (EDT) Resent-Date: Fri, 25 Jul 2003 20:33:05 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Fri, 25 Jul 2003 17:32:55 -0700 From: Yoshihiro Ohba Subject: ietf57 slides To: pana@research.telcordia.com Message-id: <20030726003255.GA16406@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@research.telcordia.com User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 5 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com are available at: http://www.toshiba.com/tari/pana/ietf57-pana.html Yoshihiro Ohba From pana-request@research.telcordia.com Sat Jul 26 13:41:08 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13883 for ; Sat, 26 Jul 2003 13:41:08 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h6QHVMA8006906; Sat, 26 Jul 2003 13:31:22 -0400 (EDT) Resent-Date: Sat, 26 Jul 2003 13:31:22 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Sat, 26 Jul 2003 10:33:01 -0700 Subject: FW: [AAA-WG]: AAA WG last call on draft-ietf-aaa-diameter-nasreq-12.txt From: Alper Yegin To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit ------ Forwarded Message From: Bernard Aboba Date: Sat, 26 Jul 2003 09:45:04 -0700 (PDT) To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG last call on draft-ietf-aaa-diameter-nasreq-12.txt This is to announce AAA WG last call on the Diameter NASREQ draft, prior to sending it on to the IESG for consideration as an IETF Proposed Standard. The Diameter NASREQ draft is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-12.txt Comments should be sent to the AAA WG mailing list in the format specified in the AAA Issues Web page: http://www.drizzle.com/~aboba/AAA/issues.html AAA WG last call will last until August 15, 2003. ------ End of Forwarded Message From pana-request@research.telcordia.com Wed Jul 30 05:44:15 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25318 for ; Wed, 30 Jul 2003 05:44:15 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h6U9Yj5k010806; Wed, 30 Jul 2003 05:34:45 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 05:34:45 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: To: nemo@nal.motlabs.com, manet@ietf.org, mobile-ip@sunroof.eng.sun.com, pana@research.telcordia.com Cc: inoue@isl.rdc.toshiba.co.jp Subject: CFP:: First International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2004) In-Reply-To: Your message of "Mon, 07 Jul 2003 20:15:21 +0900" <20030707201521A.inoue@isl.rdc.toshiba.co.jp> References: <20030707201521A.inoue@isl.rdc.toshiba.co.jp> X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030730182713V.inoue@isl.rdc.toshiba.co.jp> Date: Wed, 30 Jul 2003 18:27:13 +0900 From: Atsushi Inoue X-Dispatcher: imput version 980905(IM100) Lines: 90 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit The deadline of submission (August 1st) is approaching. -- inoue (Apologies if you receive multiple copies) CALL FOR PAPERS =============== First International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2004) January 8 and 9, 2004 NTT DoCoMo R&D Center, Yokosuka Rsearch Park, Yokosuka, JAPAN http://www.ipsj.or.jp/sig/mbl/icmu2004/ Deadline for submissions: August 1 2003 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Co-sponsored by IPSJ SIG-MBL (Informaiton Processing Society of Japan, Special Interest Group of Mobile Computing and Ubiquitous Networking) and IPSJ SG-BCC (Study Group of Broadcast Communicaiton and Computing) Scope: ~~~~~~ Mobile computing aims at ubiquitous user access to computer application. To make it possible, networking technology which enables Internet access anytime and everywhere, i.e. ubiquitous networking is necessary. It is obvious that with the accelerating trends towards mobile networks, ad-hoc networks, and wireless networks, mobile computing and ubiquitous networking will play an important role in future network. This conference is aimed at providing researchers and practitioners in this hot research area a forum for discussion and collaboration. Authors are invited to submit papers addressing, but not limited to, the following topics: - Applications and services for mobile computing - Network architectures, protocols, or service models for ubiquitous networking - Network management for ubiquitous networking - Data management for mobile computing - Security in mobile computing and ubiquitous networking - Wireless and mobile communications - Nomadic computing - Ad-hoc networks - Mobile Internetworking - Performance evaluation for mobile computing and ubiquitous networking systems - Broadcast communication Submission Instructions: ~~~~~~~~~~~~~~~~~~~~~~~~ Papers are solicited as full papers of no more than 6 pages, each of which will be subject to a full review process. Submission should already follow the author guidelines as specified in the web site below. An electronic, PDF-based submission of papers is mandatory. Please check Submission Guideline (http://www.ipsj.or.jp/sig/mbl/icmu2004/guide.html) for further submission instructions. Important Dates: ~~~~~~~~~~~~~~~~ - Deadline for submissions August 1, 2003 - Notification of acceptance October 1, 2003 - Camera ready due November 1, 2003 - Conference January 8-9, 2004 Location and Date: ~~~~~~~~~~~~~~~~~~ The location of the NTT DoCoMo R&D Center is in the heart of Yokosuka Research Park(YRP) where a lot of wireless communication related research institutes are established. YRP is really the heart of wireless communications research in Japan. Japanese old city Kamakura, a famous historic city, is 30 minutes by train. Beginning of the year is one of the best seasons for visiting Japan. You can also get PDF version of Call for Papers from http://www.ipsj.or.jp/sig/mbl/icmu2004/cfp-icmu2004.pdf Atsushi Inoue # Phone: +81-44-549-2065 Communication Platform Lab. # Fax: +81-44-520-1806 TOSHIBA R&D Center # inoue@isl.rdc.toshiba.co.jp From pana-request@research.telcordia.com Wed Jul 30 14:35:48 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12223 for ; Wed, 30 Jul 2003 14:35:40 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h6UIPQSH006753; Wed, 30 Jul 2003 14:25:26 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 14:25:26 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 30 Jul 2003 11:26:56 -0700 Subject: IETF 57 PANA meeting minutes From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Hello, IETF 57 PANA meeting minutes are below. Please let us know if there is any need for corrections or additions. We'd like to thank Jayshree Bharatia and Paulo Pagliusi for taking these notes during the meeting. - Chairs Protocol for Carrying Authentication for Network Access (PANA) WG Meeting Minutes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Session: Monday, July 14 at 1300-1500 Chairs: Basavaraj Patil Alper Yegin Note Takers: Jayshree Bharatia, Paulo Pagliusi Topic 1. Drafts Status Short discussion on the current document status was given by the Alper Yegin. - draft-ietf-pana-usage-scenarios-06.txt WG last call completed on March 11, 2003. Draft is sent to ADs for IESG consideration. - draft-ietf-pana-requirements-07.txt WG last call completed on June 12, 2003. Draft is sent to ADs for IESG consideration. - draft-ietf-pana-threats-eval-04.txt WG last call completed on May 1, 2003. Draft is sent to ADs for IESG consideration. - draft-ietf-pana-pana-01.txt Work in progress. The draft will be discussed at IETF 57. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic 2- Securing the first hop in PANA using IPsec by Hannes Tschofenig The intent of the draft was discussed in brief. This draft provides a mechanism for enabling IPsec-based per-packet authentication between the PaC and EP, once the client is authenticated by using PANA. IKE pre-shared key is derived from the PANA SA, which is established when PaC and PAA authenticate to each other. Pre-shared key is derived from the PAN= A SA. It was mentioned that manual key distribution is not used. Main mode an= d aggressive mode are easily supported. There may not be any issues for IPv4= . For IPv6, the router and neighbor discovery related extensions are different. Also, the initial problem may be that IPSec selector can't be used as a traffic selector. All packets are tunneled to the link local address of the EP. The packets are protected twice, for local and the remot= e networks. IKE pre-shared key derivation is done from the PANA security association. The recommendation was to use the IPSec tunnel mode instead of the IP-IP Transport mode. Hesham Soliman - The problem of the selector seems like the implementation problem which may be solvable. This comments was revised later in the discussion based on the different understanding. ? - It is necessary for PANA WG to contact IPSec WG for solution of the selector problem. Keys are for the bootstrapping IKE. If this is the case than it will be more complicated. James Kempf - If PANA is already solving the PAA and host(MN) security problem, why it is necessary to have IKE exchanges? Alper Yegin - The current mechanism allows binding of the client ID to the data traffic. The PANA association is not exactly the IPSec association. There needs to be some kind of binding between them. James Kempf - Can't we just carry EAP inside IKEv2? Alper Yegin - Are you suggesting replacing PANA with IKEv2? James Kempf - No, run IKEv2 independent of and after PANA. Alper Yegin - Let's take this offline and discuss on the PANA mailing list. Brijesh Kumar - I am not convinced that the mechanism described in this particular I-D is useful, since link layer security mechanism already provides enough security. There is no need to run IPsec twice on a single client.=20 ? - The end points are different and they provide different level of security. The safe assumption here is that there may not be security suppor= t at the layer 2. =20 Chairs did a consensus call on whether or not to adapt this individual submission as an official WG item, given that the WG had already agreed to tackle this problem space. 15 people said agreed, 5 disagreed to the adoption of this draft. Conclusion: There is consensus on the adoption of this draft as an official WG item.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic 3. PAA-EP Protocol Considerations: By Yacine El Mghazli - Terminology like PAA, PaC, EP were discussed in brief along with the scenario description of PAA/EP separation (when PAA separated from AR and also when PAA co-located with AR. - The following PAA-EP Protocol Requirements were mentioned. The details of these requirements are noted at http://yacine.free.fr/ietf/draft-yacine-pana-paa-ep-reqs.txt. a. Discussion objectives - No new PANA protocol design - Use of existing protocol b. Core Requirements - pana-req-07 document is used as a base - Secure - one-many PAA-EP relationship - Provisioned data c. Nice to have functionality - Pull model - Inactive peer detection - recovery - The Protocol Comparison discussion included comparison of SNMP, COPS-PR, DIAMTER and ForCES protocols. 1. SNMP Applicability: Description on how SNMP satisfies the current requirements and also few pros and cons are discussed. 2. COPS-PR: Same as SNMP, it satisfies most of the requirements but seems like having more advantages. 3. DIAMETER: It satisfies all requirements but not meant to be used for provisioning. 4. ForCES: This protocol is still being discussed. Otherwise seems like satisfying most of the requirements. Gabriel Montenegro - What is the relationship between this subject and CAPWAP (BOF)? Alper Yegin - This is about provisioning, and it is not PANA protocol. CAPWAP has also some aspects of this. This is a good question, let's ask it at CAPWAP meeting as well. Ralph Droms - What about NETCONF as another PAA-EP protocol candidate? Alper Yegin - Sure, we should look at that too. Reinaldo Penno - Let=B9s do not waste too much time in the Protocol evaluatio= n process. Let=B9s make it quick and simple. Conclusion: The topic is still open to the discussion. There may be a need of coordination with other IETF work groups like netconf. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic 4. PANA Discussion and Open Issues: The list of PANA issues can be found at http://danforsberg.info:8080/pana-issues/. Issue 9: Issue: Message format not defined in the 00 draft Proposed solution: Diameter-like message format is suggested to be used (header+AVP) Issues 4,5,16: 1. Device ID needs to be updated Proposal is to use Re-auth command which contains new device ID. 2. MAC and IP address are used at the same time Couple of proposals are discussed: Support either MAC or IP address as DI and not both addresses at the same time or use both addresses (assuming that SEND will solve the issue). Alper Yegin - Is it really useful to bootstrap 2 layers of ciphering? Pasi Eronen - Both L2 and L3 may be useful, 3GPP does that. Alper Yegin - What is the purpose of two layers of ciphering in 3GPP? Pasi Eronen - One for the local access, one for the remote access to home domain. John Vollbrecht - Is this same as EAP with MASTER KEY and Multiple Session Keys? Alper Yegin - Yes, it is. 3. In single Device ID, use multiple IP addresses. PaC can have multiple IP addresses on the same interface. This may not be issue since it is not required to have different interfaces specified for all IP address, Is this sufficient or is there any need of mentioning all IP addresses as DI and bind to session. Melinda Shore - Why do we use DI in PANA (regarding the use of addresses as identifiers)? Alper Yegin - We need it to bind the authenticated client to its associated data traffic. =20 ? - Change of address in the middle of session should be looked at as well. Ralph Droms - What is the impact of IPv6 privacy addresses on DI? Alper Yegin - Generally link-local IPv6 address is used as Device ID. Hence, if the inner IP address change, there shouldn't be any problem. Issue 6: How can a PANA session identified? The proposal was to use new session-Id. Issue 3: New section is added to the document describing PANA security association establishment (section 5.0). Issue 8: The discussion took place on what parameter should PAA communicate to perform re-authentication. Session lifetime and Refresh interval were mentioned. Issue 11: For the PANA client notification, the author added new section 4.10. Also, PAA-EP protocol is evolved to solve this problem. Issue 7: Moving context from one PAA to another PAA may be required for the performance reason. The new section 4.9 (Mobility Handling) is added describing this. Issue 15:=20 It was mentioned that the cookie mechanism defined for the discovery and handshake phase might not be effective for controlling the on-link attackers. In Puzzle mechanism, PAA sends a challenge that does not need a shared secret for a PaC to respond but need some calculation on PaC. The current proposal is to make cookie as a default and study more on the security aspects of puzzle and include it in some separate document. Issues 18,19:=20 Some of the result codes ported from the DIAMETER are intended to be used for the PANA-Result-Request message. Issue 1,3:=20 The discussion took place whether PANA needs to support capability negotiation. The capability negotiation outside of the EAP can be placed fo= r downgrading the attack. The proposed solution is to support capability indication. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic 5. Next steps Basavaraj Patil talked about the next steps for the WG. PANA-IPsec draft will be updated based on the feedback. The goal is to finish the PANA protocol specification by next IETF. Provisioning protocol discussions will continue on the PANA mailing list. We will arrange an interoperability testing among the implementors of PANA. From pana-request@research.telcordia.com Wed Jul 30 14:43:58 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12465 for ; Wed, 30 Jul 2003 14:43:58 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h6UIZRtD007386; Wed, 30 Jul 2003 14:35:27 -0400 (EDT) Resent-Date: Wed, 30 Jul 2003 14:35:27 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 30 Jul 2003 11:36:59 -0700 Subject: PANA and IKE From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Lately there has been several discussions around PANA and IKE in various contexts. Here is an attempt to put them in perspective, so that people don't confuse one with the other... First, let's recap various environments PANA can be used (from the usage scenarios draft): [a] over physically secured links (e.g., DSL) [b] over cryptographically secured links prior to PANA (e.g., CDMA2000) [c] over links that uses PANA to enable link-layer ciphering (e.g., bootstraping WEP) [d] over links that have no lower-layer security, hence IPsec-based access control is enabled after PANA IKE needs to be used in conjunction with [d] as the PANA SA needs to be turned into an IPsec SA. In that case, PANA SA provides pre-shared keys for IKE. Please see draft-mohanp-pana-ipsec-00.txt for details. No modifications to IKE is necessary in here. On the other hand, none of the other scenarios need IKE in the picture. These are the PANA-IKE discussions we had in the past: [1] Can PANA use IKE-like messages? (Pasi Eronen, on the PANA ML) Getting inspired by other protocols is welcome. We are already doing this with Diameter-like messages. But note that this is a case-by-case decision for each part of PANA. Various parts of PANA design can get inspired by other protocols as we see fit. [2] Why do we have to do what pana-ipsec draft says, can't we run an independent IKEv2 with EAP after PANA (James Kempf, IETF57 PANA meeting)? As explained earlier, PANA does not generate IPsec SA (by design) and relies on another protocol (IKE) to turn PANA SA into IPsec SA. Once PANA is run, one can bypass EAP with IKE and use pre-shared secrets with IKE to generate IPsec SA. Running EAP both in PANA and IKEv2 does not make sense, because authenticating the client once is enough. Running EAP inside IKEv2 is not necessary. [3] How about using IKEv2 instead of PANA for network access authentication? People seemed to be inspired about this because IKEv2 carries EAP. But that does not make IKEv2 a network access authentication protocol. If one wants to turn IKEv2 into such a protocol, he/she needs to add all relevant bells and whistles (such as discovery, ability to run without an IP address, enabling L2 ciphers, EAP sequencing, NAP-ISP auth separation, mobility (fast re-auth), explicit net access termination, etc.). Only after than it can be useful for scenario [d]. For others, ([a], [b], [c]) IKEv2 would be too heavy-weight and now people would want to remove stuff from IKEv2. This is why it does not make sense to replace PANA with IKEv2. PANA protocol design is such that it fits all necessary scenarios and works in conjunction with other existing protocols (IPsec, IKE) when needed. Comments? Alper From pana-request@research.telcordia.com Thu Jul 31 15:26:24 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10155 for ; Thu, 31 Jul 2003 15:26:21 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h6VJHLeo000313; Thu, 31 Jul 2003 15:17:21 -0400 (EDT) Resent-Date: Thu, 31 Jul 2003 15:17:21 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 31 Jul 2003 12:18:54 -0700 Subject: Issue 15 From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <0Ue1xC.A.wE.BtWK_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hello, Let's get back on the issue list and continue resolving them. Issue 15 is about using cookie vs. puzzle for DoS prevention. The recommended resolution at the meeting was to: - only include (mandatory to implement, optional to use) cookie mechanism in the base draft - allow alternative mechanisms like puzzles defined in separate drafts. I, without my co-chair hat on, agree to this resolution. What do others think? If there is no objection, we can close this issue. Alper From pana-request@research.telcordia.com Thu Jul 31 15:32:13 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10647 for ; Thu, 31 Jul 2003 15:32:12 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h6VJOdpO000671; Thu, 31 Jul 2003 15:24:39 -0400 (EDT) Resent-Date: Thu, 31 Jul 2003 15:24:39 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 31 Jul 2003 12:26:23 -0700 Subject: Issue 8 From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit The resolution recommended at the IETF presentation was to carry only session lifetime in PANA-bind-request message sent from PAA. This would be a non-negotiable, informative parameter. Neither of grace period nor re-auth timers will be exchanged between PAA and PaC. Taking it one step further, we can also say it is the responsibility of the PAA to initiate PANA authentication before the session expires. Nevertheless, sending the lifetime to PaC is still useful as it helps PaC manage EAP SA and PANA SA efficiently. Comments? If there are no objections, let's close this issue. Alper From pana-request@research.telcordia.com Thu Jul 31 20:48:36 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20215 for ; Thu, 31 Jul 2003 20:48:18 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h710aGg3012764; Thu, 31 Jul 2003 20:36:16 -0400 (EDT) Resent-Date: Thu, 31 Jul 2003 20:36:16 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 15 Date: Thu, 31 Jul 2003 17:36:08 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C14E5@TNEXVS02.tahoenetworks.com> Thread-Topic: Issue 15 Thread-Index: AcNXmnEMPG9a/N7CSPuffDpA54iL/gAKmC+A From: "Mohan Parthasarathy" To: "Alper Yegin" , X-OriginalArrivalTime: 01 Aug 2003 00:36:09.0484 (UTC) FILETIME=[E6DB3CC0:01C357C4] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Yes, this makes sense and consitent with approaches in other protocols. -mohan > -----Original Message----- > From: Alper Yegin [mailto:alper@docomolabs-usa.com]=20 > Sent: Thursday, July 31, 2003 12:19 PM > To: pana@research.telcordia.com > Subject: Issue 15 >=20 >=20 > Hello, >=20 > Let's get back on the issue list and continue resolving them. >=20 > Issue 15 is about using cookie vs. puzzle for DoS prevention.=20 > The recommended resolution at the meeting was to: > - only include (mandatory to implement, optional to use)=20 > cookie mechanism in the base draft > - allow alternative mechanisms like puzzles defined in=20 > separate drafts. >=20 > I, without my co-chair hat on, agree to this resolution. What=20 > do others think? If there is no objection, we can close this issue. >=20 > Alper >=20 >=20 From pana-request@research.telcordia.com Thu Jul 31 21:03:05 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20583 for ; Thu, 31 Jul 2003 21:03:04 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h710tMd6013551; Thu, 31 Jul 2003 20:55:22 -0400 (EDT) Resent-Date: Thu, 31 Jul 2003 20:55:22 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 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: IETF 57 PANA meeting minutes Date: Thu, 31 Jul 2003 17:54:50 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4A2@TNEXVS02.tahoenetworks.com> Thread-Topic: IETF 57 PANA meeting minutes Thread-Index: AcNWyVxRJKjr7ryMSv61OzA0f3gQ5QA++wIA From: "Mohan Parthasarathy" To: "Alper Yegin" , X-OriginalArrivalTime: 01 Aug 2003 00:54:50.0919 (UTC) FILETIME=[8348A370:01C357C7] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable >=20 > The intent of the draft was discussed in brief. This draft=20 > provides a mechanism for enabling IPsec-based per-packet=20 > authentication between the PaC and EP, once the client is=20 > authenticated by using PANA. IKE pre-shared key is derived=20 > from the PANA SA, which is established when PaC and PAA=20 > authenticate to each other. Pre-shared key is derived from=20 > the PANA SA. It was mentioned that manual key distribution is=20 > not used. Main mode and aggressive mode are easily=20 > supported. There may not be any issues for IPv4. For IPv6,=20 > the router and neighbor discovery related extensions are=20 > different. Also, the initial problem may be that IPSec=20 > selector can't be used as a traffic selector. All packets are=20 > tunneled to the link local address of the EP. The packets are=20 > protected twice, for local and the remote networks. IKE=20 > pre-shared key derivation is done from the PANA security=20 > association. The recommendation was to use the IPSec tunnel=20 > mode instead of the IP-IP Transport mode. >=20 > Hesham Soliman - The problem of the selector seems like the=20 > implementation problem which may be solvable. This comments=20 > was revised later in the discussion based on the different=20 > understanding. ? - It is necessary for PANA WG to contact=20 > IPSec WG for solution of the selector problem. Keys are for=20 > the bootstrapping IKE. If this is the case than it will be=20 > more complicated. I am a bit confused by the above. There was a very recent discussion on icmp type selectors in the ipsec WG to be included in the revised version of RFC2401. I don't remember the consensus except that everyone voted for it. It might as well be there. Mobile IPv6 also needs it for fine grained selectors. So, I am not sure how big this issue is. We can potentially say that "these selectors are not needed once Ipsec provides the feature..". What else is needed ? What is the selector problem got to do with "more complicated" above ? What is more complicated ? Could you explain ? -mohan >=20 > James Kempf - If PANA is already solving the PAA and=20 > host(MN) security problem, why it is necessary to have IKE=20 > exchanges? Alper Yegin - The current mechanism allows binding=20 > of the client ID to the data traffic. The PANA association is=20 > not exactly the IPSec association. There needs to be some=20 > kind of binding between them. >=20 > James Kempf - Can't we just carry EAP inside IKEv2? > Alper Yegin - Are you suggesting replacing PANA with IKEv2?=20 > James Kempf - No, run IKEv2 independent of and after PANA.=20 > Alper Yegin - Let's take this offline and discuss on the PANA=20 > mailing list. >=20 > Brijesh Kumar - I am not convinced that the mechanism=20 > described in this particular I-D is useful, since link layer=20 > security mechanism already provides enough security. There is=20 > no need to run IPsec twice on a single client.=20 > ? - The end points are different and they provide different=20 > level of security. The safe assumption here is that there may=20 > not be security support at the layer 2. =20 >=20 > Chairs did a consensus call on whether or not to adapt this=20 > individual submission as an official WG item, given that the=20 > WG had already agreed to tackle this problem space. 15 people=20 > said agreed, 5 disagreed to the adoption of this draft. >=20 > Conclusion: There is consensus on the adoption of this draft=20 > as an official WG item.=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Topic 3. PAA-EP Protocol Considerations: By Yacine El Mghazli >=20 > - Terminology like PAA, PaC, EP were discussed in brief along with the > scenario description of PAA/EP separation (when PAA=20 > separated from AR and > also when PAA co-located with AR. > - The following PAA-EP Protocol Requirements were mentioned.=20 > The details of > these requirements are noted at > http://yacine.free.fr/ietf/draft-yacine-pana-paa-ep-reqs.txt. > a. Discussion objectives > - No new PANA protocol design > - Use of existing protocol > b. Core Requirements > - pana-req-07 document is used as a base > - Secure > - one-many PAA-EP relationship > - Provisioned data > c. Nice to have functionality > - Pull model > - Inactive peer detection > - recovery > - The Protocol Comparison discussion included comparison of SNMP, > COPS-PR, DIAMTER and ForCES protocols. > 1. SNMP Applicability: Description on how SNMP satisfies the current > requirements and also few pros and cons are discussed. > 2. COPS-PR: Same as SNMP, it satisfies most of the=20 > requirements but seems > like having more advantages. > 3. DIAMETER: It satisfies all requirements but not meant to=20 > be used for > provisioning. > 4. ForCES: This protocol is still being discussed.=20 > Otherwise seems like > satisfying most of the requirements. >=20 >=20 > Gabriel Montenegro - What is the relationship between this=20 > subject and CAPWAP (BOF)? Alper Yegin - This is about=20 > provisioning, and it is not PANA protocol. CAPWAP has also=20 > some aspects of this. This is a good question, let's ask it=20 > at CAPWAP meeting as well. >=20 > Ralph Droms - What about NETCONF as another PAA-EP protocol=20 > candidate? Alper Yegin - Sure, we should look at that too. >=20 > Reinaldo Penno - Let=B9s do not waste too much time in the=20 > Protocol evaluation process. Let=B9s make it quick and simple. >=20 > Conclusion: > The topic is still open to the discussion. There may be a=20 > need of coordination with other IETF work groups like netconf. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Topic 4. PANA Discussion and Open Issues: >=20 > The list of PANA issues can be found at=20 > http://danforsberg.info:8080/pana-issues/. >=20 > Issue 9: > Issue: Message format not defined in the 00 draft > Proposed solution: Diameter-like message format is suggested=20 > to be used > (header+AVP) >=20 > Issues 4,5,16: > 1. Device ID needs to be updated > Proposal is to use Re-auth command which contains new device ID. >=20 > 2. MAC and IP address are used at the same time > Couple of proposals are discussed: Support either MAC or=20 > IP address > as DI and not both addresses at the same time or use=20 > both addresses > (assuming that SEND will solve the issue). >=20 > Alper Yegin - Is it really useful to bootstrap 2 layers=20 > of ciphering? > Pasi Eronen - Both L2 and L3 may be useful, 3GPP does that. > Alper Yegin - What is the purpose of two layers of=20 > ciphering in 3GPP? > Pasi Eronen - One for the local access, one for the=20 > remote access to > home domain. >=20 > John Vollbrecht - Is this same as EAP with MASTER KEY=20 > and Multiple > Session Keys? > Alper Yegin - Yes, it is. >=20 > 3. In single Device ID, use multiple IP addresses. > PaC can have multiple IP addresses on the same=20 > interface. This may > not be issue since it is not required to have different=20 > interfaces > specified for all IP address, Is this sufficient or is=20 > there any need > of mentioning all IP addresses as DI and bind to session. >=20 >=20 > Melinda Shore - Why do we use DI in PANA (regarding the use of > addresses as identifiers)? > Alper Yegin - We need it to bind the authenticated client to > its associated data traffic. > =20 > ? - Change of address in the middle of session should be=20 > looked at as > well. >=20 > Ralph Droms - What is the impact of IPv6 privacy addresses on DI? > Alper Yegin - Generally link-local IPv6 address is used=20 > as Device ID. > Hence, if the inner IP address change, there shouldn't=20 > be any problem. >=20 > Issue 6: > How can a PANA session identified? The proposal was to use=20 > new session-Id. >=20 > Issue 3: > New section is added to the document describing PANA security=20 > association >=20 > establishment (section 5.0). >=20 > Issue 8: > The discussion took place on what parameter should PAA=20 > communicate to perform re-authentication. Session lifetime=20 > and Refresh interval were mentioned. >=20 > Issue 11: > For the PANA client notification, the author added new=20 > section 4.10. Also, PAA-EP protocol is evolved to solve this problem. >=20 > Issue 7: > Moving context from one PAA to another PAA may be required=20 > for the performance reason. The new section 4.9 (Mobility=20 > Handling) is added describing this. >=20 > Issue 15:=20 > It was mentioned that the cookie mechanism defined for the=20 > discovery and handshake phase might not be effective for=20 > controlling the on-link attackers. In Puzzle mechanism, PAA=20 > sends a challenge that does not need a shared secret for a=20 > PaC to respond but need some calculation on PaC. The current=20 > proposal is to make cookie as a default and study more on the=20 > security aspects of puzzle and include it in some separate document. >=20 > Issues 18,19:=20 >=20 > Some of the result codes ported from the DIAMETER are=20 > intended to be used for the PANA-Result-Request message. >=20 > Issue 1,3:=20 > The discussion took place whether PANA needs to support=20 > capability negotiation. The capability negotiation outside of=20 > the EAP can be placed for downgrading the attack. The=20 > proposed solution is to support capability indication. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Topic 5. Next steps >=20 > Basavaraj Patil talked about the next steps for the WG.=20 > PANA-IPsec draft will be updated based on the feedback. The=20 > goal is to finish the PANA protocol specification by next=20 > IETF. Provisioning protocol discussions will continue on the=20 > PANA mailing list. We will arrange an interoperability=20 > testing among the implementors of PANA. >=20 >=20 >=20 From pana-request@research.telcordia.com Thu Jul 31 21:36:22 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21106 for ; Thu, 31 Jul 2003 21:36:21 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h711T5WJ014672; Thu, 31 Jul 2003 21:29:05 -0400 (EDT) Resent-Date: Thu, 31 Jul 2003 21:29:05 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 8 Date: Thu, 31 Jul 2003 18:28:35 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4A3@TNEXVS02.tahoenetworks.com> Thread-Topic: Issue 8 Thread-Index: AcNXmxFchDfORzuZTBSuJtanxDBywQALJH8Q From: "Mohan Parthasarathy" To: "Alper Yegin" , X-OriginalArrivalTime: 01 Aug 2003 01:28:35.0517 (UTC) FILETIME=[3A09C6D0:01C357CC] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Alper, >=20 >=20 > The resolution recommended at the IETF presentation was to=20 > carry only session lifetime in PANA-bind-request message sent=20 > from PAA. This would be a non-negotiable, informative=20 > parameter. Neither of grace period nor re-auth timers will be=20 > exchanged between PAA and PaC. >=20 > Taking it one step further, we can also say it is the=20 > responsibility of the PAA to initiate PANA authentication=20 > before the session expires. Nevertheless, sending the=20 > lifetime to PaC is still useful as it helps PaC manage EAP SA=20 > and PANA SA efficiently. >=20 How does it help it to maintain efficiently ?=20 =20 -mohan > Comments? If there are no objections, let's close this issue. >=20 > Alper >=20 >=20