From pana-admin@ietf.org Mon Mar 1 02:25:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24590 for ; Mon, 1 Mar 2004 02:25:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhnR-0007cW-Jf; Mon, 01 Mar 2004 02:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axhn5-0007WI-B3 for pana@optimus.ietf.org; Mon, 01 Mar 2004 02:24:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24493 for ; Mon, 1 Mar 2004 02:24:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axhn1-0006UY-00 for pana@ietf.org; Mon, 01 Mar 2004 02:24:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhmB-0006P2-00 for pana@ietf.org; Mon, 01 Mar 2004 02:23:44 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AxhlM-0006If-00 for pana@ietf.org; Mon, 01 Mar 2004 02:22:52 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 7DAB36A901 for ; Mon, 1 Mar 2004 09:22:51 +0200 (EET) Message-ID: <4042E446.9020205@piuha.net> Date: Mon, 01 Mar 2004 09:20:38 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pana@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Pana] the question that I wanted to ask at the mike before the line was cut off... Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I guess I still don't understand how roaming works in PANA. Currently, Diameter, for instance, works through looking at the NAI at the NAS, and placing this value in the Destination-Realm AVP. All this happens in the NAS. But the NAS doesn't have to have all routing information to the possible realms. Instead, it would typically have a default router to the access provider's proxy or mediating network's proxy which makes the final routing selection. This is simple enough so far, but what's the problem with PANA? The issue is that I don't understand how you can use the ISP-Information at the PANA layer to fill in the Destination-Realm. Or you can use it in the case that the NAS has been configured to recognize the given ISP. But in a typical case the NAS would not be configured with the 1000 different home realms that you can be connected to. So, does PANA limit selected ISP to the ones it has advertised? If yes, then you would have to have all those 1000 ISPs configured in the PANA-enabled NASes. If you try to force one of the few known ISPs (bighome.com) but the user wanted to get to another one (smallandunknownisp.com), things would break, I think. This is because the Destination-Realm would be set to bighome.com whereas you really should have set it to smallandunknownisp.com. In either case the message should be directly sent to the bighome.com AAA server, but this can only route the request further if the Destination-Realm AVP is set correctly. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 1 02:27:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24722 for ; Mon, 1 Mar 2004 02:26:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axhou-00080M-8r for pana-archive@odin.ietf.org; Mon, 01 Mar 2004 02:26:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i217QWPr030699 for pana-archive@odin.ietf.org; Mon, 1 Mar 2004 02:26:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axhos-0007z2-2C for pana-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 02:26:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24665 for ; Mon, 1 Mar 2004 02:26:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axhoo-0006gN-00 for pana-web-archive@ietf.org; Mon, 01 Mar 2004 02:26:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axhnv-0006b7-00 for pana-web-archive@ietf.org; Mon, 01 Mar 2004 02:25:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxhnR-0006WA-00 for pana-web-archive@ietf.org; Mon, 01 Mar 2004 02:25:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhnR-0007cW-Jf; Mon, 01 Mar 2004 02:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axhn5-0007WI-B3 for pana@optimus.ietf.org; Mon, 01 Mar 2004 02:24:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24493 for ; Mon, 1 Mar 2004 02:24:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axhn1-0006UY-00 for pana@ietf.org; Mon, 01 Mar 2004 02:24:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhmB-0006P2-00 for pana@ietf.org; Mon, 01 Mar 2004 02:23:44 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AxhlM-0006If-00 for pana@ietf.org; Mon, 01 Mar 2004 02:22:52 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 7DAB36A901 for ; Mon, 1 Mar 2004 09:22:51 +0200 (EET) Message-ID: <4042E446.9020205@piuha.net> Date: Mon, 01 Mar 2004 09:20:38 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pana@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] the question that I wanted to ask at the mike before the line was cut off... Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I guess I still don't understand how roaming works in PANA. Currently, Diameter, for instance, works through looking at the NAI at the NAS, and placing this value in the Destination-Realm AVP. All this happens in the NAS. But the NAS doesn't have to have all routing information to the possible realms. Instead, it would typically have a default router to the access provider's proxy or mediating network's proxy which makes the final routing selection. This is simple enough so far, but what's the problem with PANA? The issue is that I don't understand how you can use the ISP-Information at the PANA layer to fill in the Destination-Realm. Or you can use it in the case that the NAS has been configured to recognize the given ISP. But in a typical case the NAS would not be configured with the 1000 different home realms that you can be connected to. So, does PANA limit selected ISP to the ones it has advertised? If yes, then you would have to have all those 1000 ISPs configured in the PANA-enabled NASes. If you try to force one of the few known ISPs (bighome.com) but the user wanted to get to another one (smallandunknownisp.com), things would break, I think. This is because the Destination-Realm would be set to bighome.com whereas you really should have set it to smallandunknownisp.com. In either case the message should be directly sent to the bighome.com AAA server, but this can only route the request further if the Destination-Realm AVP is set correctly. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From mailman-admin@ietf.org Mon Mar 1 09:06:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20512 for ; Mon, 1 Mar 2004 09:06:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axo3x-00062t-Rv for pana-archive@lists.ietf.org; Mon, 01 Mar 2004 09:06:29 -0500 Date: Mon, 01 Mar 2004 09:06:29 -0500 Message-ID: <20040301140629.27462.68476.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: pana-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, pana-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for pana-archive@lists.ietf.org: List Password // URL ---- -------- pana@ietf.org onobde https://www1.ietf.org/mailman/options/pana/pana-archive%40lists.ietf.org From pana-admin@ietf.org Mon Mar 1 21:06:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22585 for ; Mon, 1 Mar 2004 21:06:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzIJ-0004Fb-DS; Mon, 01 Mar 2004 21:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzHp-0004E2-AL for pana@optimus.ietf.org; Mon, 01 Mar 2004 21:05:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22491 for ; Mon, 1 Mar 2004 21:05:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzHm-0004ov-00 for pana@ietf.org; Mon, 01 Mar 2004 21:05:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzGs-0004gM-00 for pana@ietf.org; Mon, 01 Mar 2004 21:04:35 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1AxzGE-0004WP-00 for pana@ietf.org; Mon, 01 Mar 2004 21:03:54 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HTX005IEF1OQA@mailout1.samsung.com> for pana@ietf.org; Tue, 02 Mar 2004 11:03:24 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HTX00HCPEZ9DJ@mailout1.samsung.com> for pana@ietf.org; Tue, 02 Mar 2004 11:01:58 +0900 (KST) Received: from Alperyegin ([106.10.22.1]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTX00I51EZ373@mmp1.samsung.com> for pana@ietf.org; Tue, 02 Mar 2004 11:01:57 +0900 (KST) Date: Mon, 01 Mar 2004 18:01:51 -0800 From: Alper Yegin Subject: RE: [Pana] the question that I wanted to ask at the mike before the line was cut off... In-reply-to: <4042E446.9020205@piuha.net> To: jari.arkko@piuha.net, pana@ietf.org Message-id: <000001c3fffa$588cdf80$e3e025da@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > I guess I still don't understand how roaming works in PANA. > Currently, Diameter, for instance, works through looking at > the NAI at the NAS, and placing this value in the Destination-Realm > AVP. All this happens in the NAS. But the NAS doesn't have > to have all routing information to the possible realms. Instead, > it would typically have a default router to the access provider's > proxy or mediating network's proxy which makes the final routing > selection. > > This is simple enough so far, but what's the problem with PANA? > The issue is that I don't understand how you can use the ISP-Information > at the PANA layer to fill in the Destination-Realm. Or you can use > it in the case that the NAS has been configured to recognize the > given ISP. The NAS (PAA) should already be configured to advertise the ISP-info. Destination realm can be stored as an attribute of each ISP. > But in a typical case the NAS would not be configured with > the 1000 different home realms that you can be connected to. So, > does PANA limit selected ISP to the ones it has advertised? If yes, > then you would have to have all those 1000 ISPs configured in the > PANA-enabled NASes. Dealing with so many ISPs might be hard. In that case, the deployment might choose to rely on NAI-based selection (and no ISP advertisements). Btw, even if the PAA advertises a list of ISPs, PaC may not send an ISP-info back and instead expect the selection be made based on its NAI. We haven't thought whether the advertised ISP list should be considered an exclusive list. I guess we can go either way with the design. Or, even have a flag that indicates whether the list is exclusive or not. Alper > If you try to force one of the few known ISPs > (bighome.com) but the user wanted to get to another one > (smallandunknownisp.com), things would break, I think. This is because > the Destination-Realm would be set to bighome.com whereas you really > should have set it to smallandunknownisp.com. In either case the message > should be directly sent to the bighome.com AAA server, but this can > only route the request further if the Destination-Realm AVP is > set correctly. > > --Jari > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Mar 1 21:08:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22681 for ; Mon, 1 Mar 2004 21:08:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzKF-0004X1-VK; Mon, 01 Mar 2004 21:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzJV-0004Mi-QG for pana@optimus.ietf.org; Mon, 01 Mar 2004 21:07:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22648 for ; Mon, 1 Mar 2004 21:07:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzJT-00053p-00 for pana@ietf.org; Mon, 01 Mar 2004 21:07:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzIa-0004x7-00 for pana@ietf.org; Mon, 01 Mar 2004 21:06:21 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AxzIE-0004pq-00 for pana@ietf.org; Mon, 01 Mar 2004 21:05:58 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 1283A6A901; Tue, 2 Mar 2004 04:05:52 +0200 (EET) Message-ID: <4043EB79.9040101@piuha.net> Date: Tue, 02 Mar 2004 04:03:37 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: pana@ietf.org Subject: Re: [Pana] the question that I wanted to ask at the mike before the line was cut off... References: <000001c3fffa$588cdf80$e3e025da@sisa.samsung.com> In-Reply-To: <000001c3fffa$588cdf80$e3e025da@sisa.samsung.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alper Yegin wrote: > Btw, even if the PAA advertises a list of ISPs, PaC may not send an > ISP-info back and instead expect the selection be made based on its NAI. This would be sufficient to handle the very many ISPs case, I think. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 1 21:08:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22698 for ; Mon, 1 Mar 2004 21:08:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzKK-0004aE-OP for pana-archive@odin.ietf.org; Mon, 01 Mar 2004 21:08:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22288XG017612 for pana-archive@odin.ietf.org; Mon, 1 Mar 2004 21:08:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzKJ-0004Zj-Vp for pana-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 21:08:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22654 for ; Mon, 1 Mar 2004 21:08:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzKH-00059M-00 for pana-web-archive@ietf.org; Mon, 01 Mar 2004 21:08:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzJI-00052E-00 for pana-web-archive@ietf.org; Mon, 01 Mar 2004 21:07:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxzIL-0004uh-00 for pana-web-archive@ietf.org; Mon, 01 Mar 2004 21:06:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzIJ-0004Fb-DS; Mon, 01 Mar 2004 21:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzHp-0004E2-AL for pana@optimus.ietf.org; Mon, 01 Mar 2004 21:05:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22491 for ; Mon, 1 Mar 2004 21:05:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzHm-0004ov-00 for pana@ietf.org; Mon, 01 Mar 2004 21:05:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzGs-0004gM-00 for pana@ietf.org; Mon, 01 Mar 2004 21:04:35 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1AxzGE-0004WP-00 for pana@ietf.org; Mon, 01 Mar 2004 21:03:54 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HTX005IEF1OQA@mailout1.samsung.com> for pana@ietf.org; Tue, 02 Mar 2004 11:03:24 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HTX00HCPEZ9DJ@mailout1.samsung.com> for pana@ietf.org; Tue, 02 Mar 2004 11:01:58 +0900 (KST) Received: from Alperyegin ([106.10.22.1]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTX00I51EZ373@mmp1.samsung.com> for pana@ietf.org; Tue, 02 Mar 2004 11:01:57 +0900 (KST) Date: Mon, 01 Mar 2004 18:01:51 -0800 From: Alper Yegin Subject: RE: [Pana] the question that I wanted to ask at the mike before the line was cut off... In-reply-to: <4042E446.9020205@piuha.net> To: jari.arkko@piuha.net, pana@ietf.org Message-id: <000001c3fffa$588cdf80$e3e025da@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > I guess I still don't understand how roaming works in PANA. > Currently, Diameter, for instance, works through looking at > the NAI at the NAS, and placing this value in the Destination-Realm > AVP. All this happens in the NAS. But the NAS doesn't have > to have all routing information to the possible realms. Instead, > it would typically have a default router to the access provider's > proxy or mediating network's proxy which makes the final routing > selection. > > This is simple enough so far, but what's the problem with PANA? > The issue is that I don't understand how you can use the ISP-Information > at the PANA layer to fill in the Destination-Realm. Or you can use > it in the case that the NAS has been configured to recognize the > given ISP. The NAS (PAA) should already be configured to advertise the ISP-info. Destination realm can be stored as an attribute of each ISP. > But in a typical case the NAS would not be configured with > the 1000 different home realms that you can be connected to. So, > does PANA limit selected ISP to the ones it has advertised? If yes, > then you would have to have all those 1000 ISPs configured in the > PANA-enabled NASes. Dealing with so many ISPs might be hard. In that case, the deployment might choose to rely on NAI-based selection (and no ISP advertisements). Btw, even if the PAA advertises a list of ISPs, PaC may not send an ISP-info back and instead expect the selection be made based on its NAI. We haven't thought whether the advertised ISP list should be considered an exclusive list. I guess we can go either way with the design. Or, even have a flag that indicates whether the list is exclusive or not. Alper > If you try to force one of the few known ISPs > (bighome.com) but the user wanted to get to another one > (smallandunknownisp.com), things would break, I think. This is because > the Destination-Realm would be set to bighome.com whereas you really > should have set it to smallandunknownisp.com. In either case the message > should be directly sent to the bighome.com AAA server, but this can > only route the request further if the Destination-Realm AVP is > set correctly. > > --Jari > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 1 21:10:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22836 for ; Mon, 1 Mar 2004 21:10:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzMH-00053m-BO for pana-archive@odin.ietf.org; Mon, 01 Mar 2004 21:10:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i222A9Mx019444 for pana-archive@odin.ietf.org; Mon, 1 Mar 2004 21:10:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzMH-00053X-5D for pana-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 21:10:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22806 for ; Mon, 1 Mar 2004 21:10:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzME-0005Q4-00 for pana-web-archive@ietf.org; Mon, 01 Mar 2004 21:10:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzLF-0005Hm-00 for pana-web-archive@ietf.org; Mon, 01 Mar 2004 21:09:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxzKI-00059T-00 for pana-web-archive@ietf.org; Mon, 01 Mar 2004 21:08:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzKF-0004X1-VK; Mon, 01 Mar 2004 21:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzJV-0004Mi-QG for pana@optimus.ietf.org; Mon, 01 Mar 2004 21:07:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22648 for ; Mon, 1 Mar 2004 21:07:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzJT-00053p-00 for pana@ietf.org; Mon, 01 Mar 2004 21:07:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzIa-0004x7-00 for pana@ietf.org; Mon, 01 Mar 2004 21:06:21 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AxzIE-0004pq-00 for pana@ietf.org; Mon, 01 Mar 2004 21:05:58 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 1283A6A901; Tue, 2 Mar 2004 04:05:52 +0200 (EET) Message-ID: <4043EB79.9040101@piuha.net> Date: Tue, 02 Mar 2004 04:03:37 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: pana@ietf.org Subject: Re: [Pana] the question that I wanted to ask at the mike before the line was cut off... References: <000001c3fffa$588cdf80$e3e025da@sisa.samsung.com> In-Reply-To: <000001c3fffa$588cdf80$e3e025da@sisa.samsung.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alper Yegin wrote: > Btw, even if the PAA advertises a list of ISPs, PaC may not send an > ISP-info back and instead expect the selection be made based on its NAI. This would be sufficient to handle the very many ISPs case, I think. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Mar 8 07:27:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28160 for ; Mon, 8 Mar 2004 07:27:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0JqW-0005sv-PO; Mon, 08 Mar 2004 07:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0JqP-0005sU-72 for pana@optimus.ietf.org; Mon, 08 Mar 2004 07:26:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28135 for ; Mon, 8 Mar 2004 07:26:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0JqO-00056J-00 for pana@ietf.org; Mon, 08 Mar 2004 07:26:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0JpT-0004v5-00 for pana@ietf.org; Mon, 08 Mar 2004 07:25:55 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1B0Jog-0004gH-00 for pana@ietf.org; Mon, 08 Mar 2004 07:25:06 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HU900I05BSS52@mailout2.samsung.com> for pana@ietf.org; Mon, 08 Mar 2004 21:24:28 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HU900EFBBSRYG@mailout2.samsung.com> for pana@ietf.org; Mon, 08 Mar 2004 21:24:28 +0900 (KST) Received: from Alperyegin ([75.2.47.232]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HU900LZPBSRXK@mmp2.samsung.com> for pana@ietf.org; Mon, 08 Mar 2004 21:24:27 +0900 (KST) Date: Mon, 08 Mar 2004 04:24:28 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <004501c40508$4dca3030$e82f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] draft-yacine-pana-snmp-02: Adopt as a WG item? Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT http://yacine.free.fr/ietf59/pana/draft-yacine-pana-snmp-02.txt There was rough consensus at the IETF 59 PANA meeting to adopt pana-snmp draft as a WG item. Please register your opinion if you have an objection. Otherwise, the WG will move forward on this. - Chairs _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 8 07:29:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28229 for ; Mon, 8 Mar 2004 07:29:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0JsB-0005wd-Ot for pana-archive@odin.ietf.org; Mon, 08 Mar 2004 07:28:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28CShvS022847 for pana-archive@odin.ietf.org; Mon, 8 Mar 2004 07:28:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0JsB-0005wQ-H0 for pana-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 07:28:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28223 for ; Mon, 8 Mar 2004 07:28:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0JsA-0005Qu-00 for pana-web-archive@ietf.org; Mon, 08 Mar 2004 07:28:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0JrN-0005Hf-00 for pana-web-archive@ietf.org; Mon, 08 Mar 2004 07:27:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0Jqb-00056j-00 for pana-web-archive@ietf.org; Mon, 08 Mar 2004 07:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0JqW-0005sv-PO; Mon, 08 Mar 2004 07:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0JqP-0005sU-72 for pana@optimus.ietf.org; Mon, 08 Mar 2004 07:26:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28135 for ; Mon, 8 Mar 2004 07:26:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0JqO-00056J-00 for pana@ietf.org; Mon, 08 Mar 2004 07:26:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0JpT-0004v5-00 for pana@ietf.org; Mon, 08 Mar 2004 07:25:55 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1B0Jog-0004gH-00 for pana@ietf.org; Mon, 08 Mar 2004 07:25:06 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HU900I05BSS52@mailout2.samsung.com> for pana@ietf.org; Mon, 08 Mar 2004 21:24:28 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HU900EFBBSRYG@mailout2.samsung.com> for pana@ietf.org; Mon, 08 Mar 2004 21:24:28 +0900 (KST) Received: from Alperyegin ([75.2.47.232]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HU900LZPBSRXK@mmp2.samsung.com> for pana@ietf.org; Mon, 08 Mar 2004 21:24:27 +0900 (KST) Date: Mon, 08 Mar 2004 04:24:28 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <004501c40508$4dca3030$e82f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Pana] draft-yacine-pana-snmp-02: Adopt as a WG item? Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT http://yacine.free.fr/ietf59/pana/draft-yacine-pana-snmp-02.txt There was rough consensus at the IETF 59 PANA meeting to adopt pana-snmp draft as a WG item. Please register your opinion if you have an objection. Otherwise, the WG will move forward on this. - Chairs _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Mar 8 07:43:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28695 for ; Mon, 8 Mar 2004 07:43:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0K60-00072u-Qb; Mon, 08 Mar 2004 07:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0K5X-00072T-OH for pana@optimus.ietf.org; Mon, 08 Mar 2004 07:42:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28649 for ; Mon, 8 Mar 2004 07:42:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0K5W-0007Rh-00 for pana@ietf.org; Mon, 08 Mar 2004 07:42:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0K4h-0007Jv-00 for pana@ietf.org; Mon, 08 Mar 2004 07:41:39 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1B0K4F-0007Bh-00 for pana@ietf.org; Mon, 08 Mar 2004 07:41:11 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HU900I01CJRZO@mailout2.samsung.com> for pana@ietf.org; Mon, 08 Mar 2004 21:40:39 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HU9001Z1CJRDX@mailout2.samsung.com> for pana@ietf.org; Mon, 08 Mar 2004 21:40:39 +0900 (KST) Received: from Alperyegin ([75.2.47.232]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HU9003I2CJRFA@mmp1.samsung.com> for pana@ietf.org; Mon, 08 Mar 2004 21:40:39 +0900 (KST) Date: Mon, 08 Mar 2004 04:40:40 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <004701c4050a$90b8d2a0$e82f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] draft-ohba-pana-framework-00: Adopt as a WG item? Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT draft-ohba-pana-framework-00 There was rough consensus at the IETF 59 PANA meeting to adopt pana-framework draft as a WG item. Please register your opinion if you have any objections. Otherwise, the WG will move forward on this. - Chairs _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 8 07:45:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28757 for ; Mon, 8 Mar 2004 07:45:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0K7X-0007E4-4e for pana-archive@odin.ietf.org; Mon, 08 Mar 2004 07:44:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28CiYxr027766 for pana-archive@odin.ietf.org; Mon, 8 Mar 2004 07:44:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0K7W-0007Dh-Fn for pana-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 07:44:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28742 for ; Mon, 8 Mar 2004 07:44:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0K7U-0007kg-00 for pana-web-archive@ietf.org; Mon, 08 Mar 2004 07:44:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0K6b-0007bt-00 for pana-web-archive@ietf.org; Mon, 08 Mar 2004 07:43:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0K62-0007T7-00 for pana-web-archive@ietf.org; Mon, 08 Mar 2004 07:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0K60-00072u-Qb; Mon, 08 Mar 2004 07:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0K5X-00072T-OH for pana@optimus.ietf.org; Mon, 08 Mar 2004 07:42:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28649 for ; Mon, 8 Mar 2004 07:42:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0K5W-0007Rh-00 for pana@ietf.org; Mon, 08 Mar 2004 07:42:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0K4h-0007Jv-00 for pana@ietf.org; Mon, 08 Mar 2004 07:41:39 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1B0K4F-0007Bh-00 for pana@ietf.org; Mon, 08 Mar 2004 07:41:11 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HU900I01CJRZO@mailout2.samsung.com> for pana@ietf.org; Mon, 08 Mar 2004 21:40:39 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HU9001Z1CJRDX@mailout2.samsung.com> for pana@ietf.org; Mon, 08 Mar 2004 21:40:39 +0900 (KST) Received: from Alperyegin ([75.2.47.232]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HU9003I2CJRFA@mmp1.samsung.com> for pana@ietf.org; Mon, 08 Mar 2004 21:40:39 +0900 (KST) Date: Mon, 08 Mar 2004 04:40:40 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <004701c4050a$90b8d2a0$e82f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Pana] draft-ohba-pana-framework-00: Adopt as a WG item? Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT draft-ohba-pana-framework-00 There was rough consensus at the IETF 59 PANA meeting to adopt pana-framework draft as a WG item. Please register your opinion if you have any objections. Otherwise, the WG will move forward on this. - Chairs _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Mar 9 10:36:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01688 for ; Tue, 9 Mar 2004 10:36:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jHG-0003ml-Md; Tue, 09 Mar 2004 10:36:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0gxL-0001Ry-8V for pana@optimus.ietf.org; Tue, 09 Mar 2004 08:07:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25434 for ; Tue, 9 Mar 2004 08:07:33 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0gxK-0006vg-00 for pana@ietf.org; Tue, 09 Mar 2004 08:07:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0gwN-0006lJ-00 for pana@ietf.org; Tue, 09 Mar 2004 08:06:36 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B0gvS-0006aw-00 for pana@ietf.org; Tue, 09 Mar 2004 08:05:38 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i29D5Za08119; Tue, 9 Mar 2004 15:05:35 +0200 (EET) X-Scanned: Tue, 9 Mar 2004 15:05:28 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i29D5RnL021532; Tue, 9 Mar 2004 15:05:28 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 008EuAmF; Tue, 09 Mar 2004 15:05:27 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i29D5BH28754; Tue, 9 Mar 2004 15:05:12 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Mar 2004 15:05:10 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Mar 2004 15:05:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: [Pana] the question that I wanted to ask at the mike before the line was cut off... Date: Tue, 9 Mar 2004 15:05:10 +0200 Message-ID: Thread-Topic: [Pana] the question that I wanted to ask at the mike before the line was cut off... Thread-Index: AcP/Xo8COlocso/vQgq8+BVCAzPG9wGd4Kjg To: , X-OriginalArrivalTime: 09 Mar 2004 13:05:11.0245 (UTC) FILETIME=[27867FD0:01C405D7] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable NAP is connected to ISP(s). I guess NAP could provide WLAN APs, but the = ISP the backbone connection. If APs are shared among different ISPs, = then ISP selection comes into the picture. I guess the question is how = many ISPs could be connected to one NAP? Or what is the definition of = NAP and ISP.. and how far does the NAP-ISP border go. Is NAP the as ANP = (Access Network Provider)? :) So, my understanding currently is that I may use NAI like dan@visa.com = and when I'm attaching to a NAP it advertises me ISPs that are connected = to it, for example htv.fi, teliasonera.fi, and saunalahti.fi. Then I = select one, let's say htv.fi and send that selection in the PSA message = to the PAA. PAA then sends the AAA request to the htv.fi AAA gw/server, = but the destination realm is visa.com. - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > Jari Arkko > Sent: 01 March, 2004 09:21 > To: pana@ietf.org > Subject: [Pana] the question that I wanted to ask at the mike=20 > before the > line was cut off... >=20 >=20 >=20 > I guess I still don't understand how roaming works in PANA. > Currently, Diameter, for instance, works through looking at > the NAI at the NAS, and placing this value in the Destination-Realm > AVP. All this happens in the NAS. But the NAS doesn't have > to have all routing information to the possible realms. Instead, > it would typically have a default router to the access provider's > proxy or mediating network's proxy which makes the final routing > selection. >=20 > This is simple enough so far, but what's the problem with PANA? > The issue is that I don't understand how you can use the=20 > ISP-Information > at the PANA layer to fill in the Destination-Realm. Or you can use > it in the case that the NAS has been configured to recognize the > given ISP. But in a typical case the NAS would not be configured with > the 1000 different home realms that you can be connected to. So, > does PANA limit selected ISP to the ones it has advertised? If yes, > then you would have to have all those 1000 ISPs configured in the > PANA-enabled NASes. If you try to force one of the few known ISPs > (bighome.com) but the user wanted to get to another one > (smallandunknownisp.com), things would break, I think. This is because > the Destination-Realm would be set to bighome.com whereas you really > should have set it to smallandunknownisp.com. In either case=20 > the message > should be directly sent to the bighome.com AAA server, but this can > only route the request further if the Destination-Realm AVP is > set correctly. >=20 > --Jari >=20 >=20 >=20 > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana >=20 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Mar 9 10:50:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03990 for ; Tue, 9 Mar 2004 10:50:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jUT-0002Bf-AS for pana-archive@odin.ietf.org; Tue, 09 Mar 2004 10:49:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29FnvXO008406 for pana-archive@odin.ietf.org; Tue, 9 Mar 2004 10:49:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jUT-0002BV-5V for pana-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:49:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03788 for ; Tue, 9 Mar 2004 10:49:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jUQ-0004yf-00 for pana-web-archive@ietf.org; Tue, 09 Mar 2004 10:49:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jQF-0003er-00 for pana-web-archive@ietf.org; Tue, 09 Mar 2004 10:45:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0jMh-0002et-01 for pana-web-archive@ietf.org; Tue, 09 Mar 2004 10:41:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jHG-0003ml-Md; Tue, 09 Mar 2004 10:36:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0gxL-0001Ry-8V for pana@optimus.ietf.org; Tue, 09 Mar 2004 08:07:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25434 for ; Tue, 9 Mar 2004 08:07:33 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0gxK-0006vg-00 for pana@ietf.org; Tue, 09 Mar 2004 08:07:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0gwN-0006lJ-00 for pana@ietf.org; Tue, 09 Mar 2004 08:06:36 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B0gvS-0006aw-00 for pana@ietf.org; Tue, 09 Mar 2004 08:05:38 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i29D5Za08119; Tue, 9 Mar 2004 15:05:35 +0200 (EET) X-Scanned: Tue, 9 Mar 2004 15:05:28 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i29D5RnL021532; Tue, 9 Mar 2004 15:05:28 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 008EuAmF; Tue, 09 Mar 2004 15:05:27 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i29D5BH28754; Tue, 9 Mar 2004 15:05:12 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Mar 2004 15:05:10 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Mar 2004 15:05:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: [Pana] the question that I wanted to ask at the mike before the line was cut off... Date: Tue, 9 Mar 2004 15:05:10 +0200 Message-ID: Thread-Topic: [Pana] the question that I wanted to ask at the mike before the line was cut off... Thread-Index: AcP/Xo8COlocso/vQgq8+BVCAzPG9wGd4Kjg To: , X-OriginalArrivalTime: 09 Mar 2004 13:05:11.0245 (UTC) FILETIME=[27867FD0:01C405D7] Content-Transfer-Encoding: quoted-printable Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable NAP is connected to ISP(s). I guess NAP could provide WLAN APs, but the = ISP the backbone connection. If APs are shared among different ISPs, = then ISP selection comes into the picture. I guess the question is how = many ISPs could be connected to one NAP? Or what is the definition of = NAP and ISP.. and how far does the NAP-ISP border go. Is NAP the as ANP = (Access Network Provider)? :) So, my understanding currently is that I may use NAI like dan@visa.com = and when I'm attaching to a NAP it advertises me ISPs that are connected = to it, for example htv.fi, teliasonera.fi, and saunalahti.fi. Then I = select one, let's say htv.fi and send that selection in the PSA message = to the PAA. PAA then sends the AAA request to the htv.fi AAA gw/server, = but the destination realm is visa.com. - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > Jari Arkko > Sent: 01 March, 2004 09:21 > To: pana@ietf.org > Subject: [Pana] the question that I wanted to ask at the mike=20 > before the > line was cut off... >=20 >=20 >=20 > I guess I still don't understand how roaming works in PANA. > Currently, Diameter, for instance, works through looking at > the NAI at the NAS, and placing this value in the Destination-Realm > AVP. All this happens in the NAS. But the NAS doesn't have > to have all routing information to the possible realms. Instead, > it would typically have a default router to the access provider's > proxy or mediating network's proxy which makes the final routing > selection. >=20 > This is simple enough so far, but what's the problem with PANA? > The issue is that I don't understand how you can use the=20 > ISP-Information > at the PANA layer to fill in the Destination-Realm. Or you can use > it in the case that the NAS has been configured to recognize the > given ISP. But in a typical case the NAS would not be configured with > the 1000 different home realms that you can be connected to. So, > does PANA limit selected ISP to the ones it has advertised? If yes, > then you would have to have all those 1000 ISPs configured in the > PANA-enabled NASes. If you try to force one of the few known ISPs > (bighome.com) but the user wanted to get to another one > (smallandunknownisp.com), things would break, I think. This is because > the Destination-Realm would be set to bighome.com whereas you really > should have set it to smallandunknownisp.com. In either case=20 > the message > should be directly sent to the bighome.com AAA server, but this can > only route the request further if the Destination-Realm AVP is > set correctly. >=20 > --Jari >=20 >=20 >=20 > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana >=20 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Mar 11 11:12:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09029 for ; Thu, 11 Mar 2004 11:12:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Smv-0006bi-1R; Thu, 11 Mar 2004 11:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Sma-0006bN-ES for pana@optimus.ietf.org; Thu, 11 Mar 2004 11:11:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09018 for ; Thu, 11 Mar 2004 11:11:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1SmX-0006tK-00 for pana@ietf.org; Thu, 11 Mar 2004 11:11:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Sla-0006n8-00 for pana@ietf.org; Thu, 11 Mar 2004 11:10:39 -0500 Received: from viap100.atea.be ([194.78.143.100] helo=hrtades9.atea.be) by ietf-mx with esmtp (Exim 4.12) id 1B1Sl6-0006g4-00 for pana@ietf.org; Thu, 11 Mar 2004 11:10:08 -0500 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id D5YYHLTJ; Thu, 11 Mar 2004 17:09:36 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Mar 2004 17:09:36 +0100 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195692072@hrtades7.atea.be> From: Goeman Stefan To: "'pana@ietf.org'" Date: Thu, 11 Mar 2004 17:09:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40783.3F598C80" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Subject: [Pana] [Pana]: POPA configuration Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C40783.3F598C80 Content-Type: text/plain; charset="iso-8859-1" Hello All, I am reading draft-ohba-pana-framwork-00.txt. Section 5 is about IP address configuration. There is something I do not understand very well. It is about POPA (Post-Pana Address) configuration. The second bullet point, on page 12 of the draft mentions: "If the network uses IPsec for protecting the traffic on the link subsequent to PANA authentication, PaC may use the address configuration methods available within [RFC2409] or [I-D.ietf-ipsec-ikev2] or it may also use the mechanism described in [RFC3456]. ..." - The mechanism based on RFC 3456 I understand. - With IKEv2, I think I understand it. You can send informational messages, protected by the IKE_SA, which include the configuration payload. The configuration payload can be used to request an IP-address. - However, I have no idea how it could be done by using IKE [RFC2409]. Can somebody explain this? Greetings, Stefan. Stefan Goeman SIEMENS ICM/ICN Stefan.Goeman@siemens.com Mobile Solutions and Enabling Services http://www.ic.siemens.be Customer driven solution providers ------_=_NextPart_001_01C40783.3F598C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Pana]: POPA configuration

Hello All,

I am reading = draft-ohba-pana-framwork-00.txt. Section 5 is about IP address = configuration. There is something I do not understand very well. It is = about POPA (Post-Pana Address) configuration. The second bullet point, = on page 12 of the draft mentions:

"If the network uses IPsec for = protecting the traffic on the link subsequent to PANA authentication, = PaC may use the address configuration methods available within = [RFC2409] or [I-D.ietf-ipsec-ikev2] or it may also use the mechanism = described in [RFC3456]. ..."

- The mechanism based on RFC 3456 I = understand.
- With IKEv2, I think I understand = it. You can send informational messages, protected by the IKE_SA, which = include the configuration payload. The configuration payload can be = used to request an IP-address.

- However, I have no idea how it could = be done by using IKE [RFC2409]. Can somebody explain this?

Greetings,
Stefan.


Stefan = Goeman
SIEMENS ICM/ICN
Stefan.Goeman@siemens.com
       
Mobile Solutions=A0
and Enabling Services
http://www.ic.siemens.be        = =A0      
Customer driven solution providers =     

------_=_NextPart_001_01C40783.3F598C80-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Mar 11 11:17:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09201 for ; Thu, 11 Mar 2004 11:16:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1SrH-0006mg-Ql for pana-archive@odin.ietf.org; Thu, 11 Mar 2004 11:16:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BGGVLl026074 for pana-archive@odin.ietf.org; Thu, 11 Mar 2004 11:16:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1SrH-0006mT-LO for pana-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 11:16:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09113 for ; Thu, 11 Mar 2004 11:16:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1SrG-0007aq-00 for pana-web-archive@ietf.org; Thu, 11 Mar 2004 11:16:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1SpX-0007E1-00 for pana-web-archive@ietf.org; Thu, 11 Mar 2004 11:14:44 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1Sos-00076n-01 for pana-web-archive@ietf.org; Thu, 11 Mar 2004 11:14:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1Smz-0008Ds-8k for pana-web-archive@ietf.org; Thu, 11 Mar 2004 11:12:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Smv-0006bi-1R; Thu, 11 Mar 2004 11:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Sma-0006bN-ES for pana@optimus.ietf.org; Thu, 11 Mar 2004 11:11:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09018 for ; Thu, 11 Mar 2004 11:11:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1SmX-0006tK-00 for pana@ietf.org; Thu, 11 Mar 2004 11:11:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Sla-0006n8-00 for pana@ietf.org; Thu, 11 Mar 2004 11:10:39 -0500 Received: from viap100.atea.be ([194.78.143.100] helo=hrtades9.atea.be) by ietf-mx with esmtp (Exim 4.12) id 1B1Sl6-0006g4-00 for pana@ietf.org; Thu, 11 Mar 2004 11:10:08 -0500 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id D5YYHLTJ; Thu, 11 Mar 2004 17:09:36 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Mar 2004 17:09:36 +0100 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195692072@hrtades7.atea.be> From: Goeman Stefan To: "'pana@ietf.org'" Date: Thu, 11 Mar 2004 17:09:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40783.3F598C80" Subject: [Pana] [Pana]: POPA configuration Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C40783.3F598C80 Content-Type: text/plain; charset="iso-8859-1" Hello All, I am reading draft-ohba-pana-framwork-00.txt. Section 5 is about IP address configuration. There is something I do not understand very well. It is about POPA (Post-Pana Address) configuration. The second bullet point, on page 12 of the draft mentions: "If the network uses IPsec for protecting the traffic on the link subsequent to PANA authentication, PaC may use the address configuration methods available within [RFC2409] or [I-D.ietf-ipsec-ikev2] or it may also use the mechanism described in [RFC3456]. ..." - The mechanism based on RFC 3456 I understand. - With IKEv2, I think I understand it. You can send informational messages, protected by the IKE_SA, which include the configuration payload. The configuration payload can be used to request an IP-address. - However, I have no idea how it could be done by using IKE [RFC2409]. Can somebody explain this? Greetings, Stefan. Stefan Goeman SIEMENS ICM/ICN Stefan.Goeman@siemens.com Mobile Solutions and Enabling Services http://www.ic.siemens.be Customer driven solution providers ------_=_NextPart_001_01C40783.3F598C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Pana]: POPA configuration

Hello All,

I am reading = draft-ohba-pana-framwork-00.txt. Section 5 is about IP address = configuration. There is something I do not understand very well. It is = about POPA (Post-Pana Address) configuration. The second bullet point, = on page 12 of the draft mentions:

"If the network uses IPsec for = protecting the traffic on the link subsequent to PANA authentication, = PaC may use the address configuration methods available within = [RFC2409] or [I-D.ietf-ipsec-ikev2] or it may also use the mechanism = described in [RFC3456]. ..."

- The mechanism based on RFC 3456 I = understand.
- With IKEv2, I think I understand = it. You can send informational messages, protected by the IKE_SA, which = include the configuration payload. The configuration payload can be = used to request an IP-address.

- However, I have no idea how it could = be done by using IKE [RFC2409]. Can somebody explain this?

Greetings,
Stefan.


Stefan = Goeman
SIEMENS ICM/ICN
Stefan.Goeman@siemens.com
       
Mobile Solutions=A0
and Enabling Services
http://www.ic.siemens.be        = =A0      
Customer driven solution providers =     

------_=_NextPart_001_01C40783.3F598C80-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Mar 11 11:54:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11090 for ; Thu, 11 Mar 2004 11:54:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1TRY-0001z2-Mc; Thu, 11 Mar 2004 11:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1TRN-0001xv-Jm for pana@optimus.ietf.org; Thu, 11 Mar 2004 11:53:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11074 for ; Thu, 11 Mar 2004 11:53:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1TRM-0005f7-00 for pana@ietf.org; Thu, 11 Mar 2004 11:53:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1TQT-0005Wg-00 for pana@ietf.org; Thu, 11 Mar 2004 11:52:53 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B1TPp-0005OQ-00 for pana@ietf.org; Thu, 11 Mar 2004 11:52:14 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2BGqBKL018556; Fri, 12 Mar 2004 01:52:11 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2BGqBjH019577; Fri, 12 Mar 2004 01:52:11 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA19576 ; Fri, 12 Mar 2004 01:52:11 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA18688; Fri, 12 Mar 2004 01:52:11 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA29638; Fri, 12 Mar 2004 01:52:10 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2BGq9WH019726; Fri, 12 Mar 2004 01:52:10 +0900 (JST) Received: from steelhead ([159.119.168.92]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUF0024386V78@tsbpo1.po.toshiba.co.jp>; Fri, 12 Mar 2004 01:52:08 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AyyO0-0000mN-00; Thu, 04 Mar 2004 11:20:00 -0800 Date: Thu, 04 Mar 2004 11:19:59 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] [Pana]: POPA configuration In-reply-to: <57FD2C3A246F76438CA6FDAD8FE9F195692072@hrtades7.atea.be> To: Goeman Stefan Cc: "'pana@ietf.org'" Message-id: <20040304191959.GA2993@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Goeman Stefan , "'pana@ietf.org'" User-Agent: Mutt/1.5.5.1+cvs20040105i References: <57FD2C3A246F76438CA6FDAD8FE9F195692072@hrtades7.atea.be> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Thu, Mar 11, 2004 at 05:09:35PM +0100, Goeman Stefan wrote: > Hello All, > > I am reading draft-ohba-pana-framwork-00.txt. Section 5 is about IP address > configuration. There is something I do not understand very well. It is about > POPA (Post-Pana Address) configuration. The second bullet point, on page 12 > of the draft mentions: > "If the network uses IPsec for protecting the traffic on the link subsequent > to PANA authentication, PaC may use the address configuration methods > available within [RFC2409] or [I-D.ietf-ipsec-ikev2] or it may also use the > mechanism described in [RFC3456]. ..." > > - The mechanism based on RFC 3456 I understand. > - With IKEv2, I think I understand it. You can send informational messages, > protected by the IKE_SA, which include the configuration payload. The > configuration payload can be used to request an IP-address. > > - However, I have no idea how it could be done by using IKE [RFC2409]. Can > somebody explain this? For IKEv1, there is a non-standard method called "Mode Config" which is similar to Configuration Payload exchange in IKEv2. It is described in section 11.5 of Carlton R. Davis, "IPSec Securing VPNs", RSA Press. Yoshihiro Ohba > > Greetings, > Stefan. > > > Stefan Goeman > SIEMENS ICM/ICN > Stefan.Goeman@siemens.com > > Mobile Solutions > and Enabling Services > http://www.ic.siemens.be > > Customer driven solution providers > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Mar 11 11:56:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11207 for ; Thu, 11 Mar 2004 11:56:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1TTH-00023V-3K for pana-archive@odin.ietf.org; Thu, 11 Mar 2004 11:55:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BGtlmh007895 for pana-archive@odin.ietf.org; Thu, 11 Mar 2004 11:55:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1TTG-00023A-L1 for pana-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 11:55:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11172 for ; Thu, 11 Mar 2004 11:55:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1TTF-0005xt-00 for pana-web-archive@ietf.org; Thu, 11 Mar 2004 11:55:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1TSO-0005pF-00 for pana-web-archive@ietf.org; Thu, 11 Mar 2004 11:54:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1TRa-0005gr-00 for pana-web-archive@ietf.org; Thu, 11 Mar 2004 11:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1TRY-0001z2-Mc; Thu, 11 Mar 2004 11:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1TRN-0001xv-Jm for pana@optimus.ietf.org; Thu, 11 Mar 2004 11:53:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11074 for ; Thu, 11 Mar 2004 11:53:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1TRM-0005f7-00 for pana@ietf.org; Thu, 11 Mar 2004 11:53:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1TQT-0005Wg-00 for pana@ietf.org; Thu, 11 Mar 2004 11:52:53 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B1TPp-0005OQ-00 for pana@ietf.org; Thu, 11 Mar 2004 11:52:14 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2BGqBKL018556; Fri, 12 Mar 2004 01:52:11 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2BGqBjH019577; Fri, 12 Mar 2004 01:52:11 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA19576 ; Fri, 12 Mar 2004 01:52:11 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA18688; Fri, 12 Mar 2004 01:52:11 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA29638; Fri, 12 Mar 2004 01:52:10 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2BGq9WH019726; Fri, 12 Mar 2004 01:52:10 +0900 (JST) Received: from steelhead ([159.119.168.92]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUF0024386V78@tsbpo1.po.toshiba.co.jp>; Fri, 12 Mar 2004 01:52:08 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AyyO0-0000mN-00; Thu, 04 Mar 2004 11:20:00 -0800 Date: Thu, 04 Mar 2004 11:19:59 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] [Pana]: POPA configuration In-reply-to: <57FD2C3A246F76438CA6FDAD8FE9F195692072@hrtades7.atea.be> To: Goeman Stefan Cc: "'pana@ietf.org'" Message-id: <20040304191959.GA2993@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Goeman Stefan , "'pana@ietf.org'" User-Agent: Mutt/1.5.5.1+cvs20040105i References: <57FD2C3A246F76438CA6FDAD8FE9F195692072@hrtades7.atea.be> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, Mar 11, 2004 at 05:09:35PM +0100, Goeman Stefan wrote: > Hello All, > > I am reading draft-ohba-pana-framwork-00.txt. Section 5 is about IP address > configuration. There is something I do not understand very well. It is about > POPA (Post-Pana Address) configuration. The second bullet point, on page 12 > of the draft mentions: > "If the network uses IPsec for protecting the traffic on the link subsequent > to PANA authentication, PaC may use the address configuration methods > available within [RFC2409] or [I-D.ietf-ipsec-ikev2] or it may also use the > mechanism described in [RFC3456]. ..." > > - The mechanism based on RFC 3456 I understand. > - With IKEv2, I think I understand it. You can send informational messages, > protected by the IKE_SA, which include the configuration payload. The > configuration payload can be used to request an IP-address. > > - However, I have no idea how it could be done by using IKE [RFC2409]. Can > somebody explain this? For IKEv1, there is a non-standard method called "Mode Config" which is similar to Configuration Payload exchange in IKEv2. It is described in section 11.5 of Carlton R. Davis, "IPSec Securing VPNs", RSA Press. Yoshihiro Ohba > > Greetings, > Stefan. > > > Stefan Goeman > SIEMENS ICM/ICN > Stefan.Goeman@siemens.com > > Mobile Solutions > and Enabling Services > http://www.ic.siemens.be > > Customer driven solution providers > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Mar 12 21:15:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06907 for ; Fri, 12 Mar 2004 21:15:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yg2-0003AU-Fa; Fri, 12 Mar 2004 21:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yfu-0003A0-P3 for pana@optimus.ietf.org; Fri, 12 Mar 2004 21:14:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06900 for ; Fri, 12 Mar 2004 21:14:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1yfs-0003AW-00 for pana@ietf.org; Fri, 12 Mar 2004 21:14:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1yf0-00039R-00 for pana@ietf.org; Fri, 12 Mar 2004 21:13:58 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1B1yel-00037k-00 for pana@ietf.org; Fri, 12 Mar 2004 21:13:43 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUH00J05STOF4@mailout2.samsung.com> for pana@ietf.org; Sat, 13 Mar 2004 11:13:00 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUH00FS3STL36@mailout2.samsung.com> for pana@ietf.org; Sat, 13 Mar 2004 11:12:59 +0900 (KST) Received: from Alperyegin ([75.2.47.232]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUH00F2DSTF3B@mmp1.samsung.com> for pana@ietf.org; Sat, 13 Mar 2004 11:12:58 +0900 (KST) Date: Fri, 12 Mar 2004 18:12:54 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <002c01c408a0$b5e8f7f0$e82f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] Meeting minutes and slides (IETF 59) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hello, The meeting minutes and presentations slides for IETF 59 PANA meeting can be found at: http://www.toshiba.com/tari/pana/ietf59-pana.html Special thanks to Hannes and Yacine for taking notes, and Yoshihiro for hosting the proceedings on his site. If you have any suggested updates to the meeting minutes, please let the WG and chairs know before 3/19. - Chairs _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Mar 12 21:21:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07242 for ; Fri, 12 Mar 2004 21:21:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ylk-0003SA-4Q for pana-archive@odin.ietf.org; Fri, 12 Mar 2004 21:20:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D2KusY013268 for pana-archive@odin.ietf.org; Fri, 12 Mar 2004 21:20:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ylj-0003Rt-Nw for pana-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 21:20:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07097 for ; Fri, 12 Mar 2004 21:20:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ylh-0003SH-00 for pana-web-archive@ietf.org; Fri, 12 Mar 2004 21:20:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1yki-0003Ie-00 for pana-web-archive@ietf.org; Fri, 12 Mar 2004 21:19:53 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1yjl-0003Gd-02 for pana-web-archive@ietf.org; Fri, 12 Mar 2004 21:18:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1yg4-0000KB-6l for pana-web-archive@ietf.org; Fri, 12 Mar 2004 21:15:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yg2-0003AU-Fa; Fri, 12 Mar 2004 21:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yfu-0003A0-P3 for pana@optimus.ietf.org; Fri, 12 Mar 2004 21:14:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06900 for ; Fri, 12 Mar 2004 21:14:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1yfs-0003AW-00 for pana@ietf.org; Fri, 12 Mar 2004 21:14:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1yf0-00039R-00 for pana@ietf.org; Fri, 12 Mar 2004 21:13:58 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1B1yel-00037k-00 for pana@ietf.org; Fri, 12 Mar 2004 21:13:43 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUH00J05STOF4@mailout2.samsung.com> for pana@ietf.org; Sat, 13 Mar 2004 11:13:00 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUH00FS3STL36@mailout2.samsung.com> for pana@ietf.org; Sat, 13 Mar 2004 11:12:59 +0900 (KST) Received: from Alperyegin ([75.2.47.232]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUH00F2DSTF3B@mmp1.samsung.com> for pana@ietf.org; Sat, 13 Mar 2004 11:12:58 +0900 (KST) Date: Fri, 12 Mar 2004 18:12:54 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <002c01c408a0$b5e8f7f0$e82f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Pana] Meeting minutes and slides (IETF 59) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hello, The meeting minutes and presentations slides for IETF 59 PANA meeting can be found at: http://www.toshiba.com/tari/pana/ietf59-pana.html Special thanks to Hannes and Yacine for taking notes, and Yoshihiro for hosting the proceedings on his site. If you have any suggested updates to the meeting minutes, please let the WG and chairs know before 3/19. - Chairs _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Sun Mar 14 02:29:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06488 for ; Sun, 14 Mar 2004 02:29:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Q3S-0004l8-Me; Sun, 14 Mar 2004 02:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Q3H-0004gZ-CI for pana@optimus.ietf.org; Sun, 14 Mar 2004 02:28:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06455 for ; Sun, 14 Mar 2004 02:28:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Q3D-0001gh-00 for pana@ietf.org; Sun, 14 Mar 2004 02:28:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Q2J-0001cw-00 for pana@ietf.org; Sun, 14 Mar 2004 02:27:52 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B2Q1y-0001YY-00 for pana@ietf.org; Sun, 14 Mar 2004 02:27:30 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2E7RNKL024042; Sun, 14 Mar 2004 16:27:23 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2E7RNbt000540; Sun, 14 Mar 2004 16:27:23 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id SAA00539 ; Sun, 14 Mar 2004 16:27:23 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id QAA25735; Sun, 14 Mar 2004 16:27:23 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by toshiba.co.jp id QAA10715; Sun, 14 Mar 2004 16:27:22 +0900 (JST) Received: from steelhead (att01-031.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUK00E8C21J9Z@tsbpo1.po.toshiba.co.jp>; Sun, 14 Mar 2004 16:27:21 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B1uiO-0002av-00; Fri, 12 Mar 2004 14:01:12 -0800 Date: Fri, 12 Mar 2004 14:01:12 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] the question that I wanted to ask at the mike before the line was cut off... In-reply-to: To: Dan.Forsberg@nokia.com Cc: jari.arkko@piuha.net, pana@ietf.org Message-id: <20040312220112.GA9972@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, jari.arkko@piuha.net, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi Dan and Jari, On Tue, Mar 09, 2004 at 03:05:10PM +0200, Dan.Forsberg@nokia.com wrote: > NAP is connected to ISP(s). I guess NAP could provide WLAN APs, but the ISP the backbone connection. If APs are shared among different ISPs, then ISP selection comes into the picture. I guess the question is how many ISPs could be connected to one NAP? Or what is the definition of NAP and ISP.. and how far does the NAP-ISP border go. Is NAP the as ANP (Access Network Provider)? :) > > So, my understanding currently is that I may use NAI like dan@visa.com and when I'm attaching to a NAP it advertises me ISPs that are connected to it, for example htv.fi, teliasonera.fi, and saunalahti.fi. Then I select one, let's say htv.fi and send that selection in the PSA message to the PAA. PAA then sends the AAA request to the htv.fi AAA gw/server, but the destination realm is visa.com. If we consider the realm-based routing table in Diameter (section 2.7 of RFC3588), a PAA node with a single Diameter client might not be able to support this case, since the routing table does not contain the chosen ISP information. However, the case can be supported if multiple Diameter clients are running on the PAA node, where each Diameter client is dedicated to serve a particular ISP by having its own realm-based routing table. In this case, the PAA can generate a AAA request and pass it (via internal communication) to the Diameter client that serves for htv.fi, and the Diameter client will take care of the rest of AAA routing towards the visa.com Diameter server through the htv.fi network. Yoshihiro Ohba > > - Dan > > > -----Original Message----- > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > > Jari Arkko > > Sent: 01 March, 2004 09:21 > > To: pana@ietf.org > > Subject: [Pana] the question that I wanted to ask at the mike > > before the > > line was cut off... > > > > > > > > I guess I still don't understand how roaming works in PANA. > > Currently, Diameter, for instance, works through looking at > > the NAI at the NAS, and placing this value in the Destination-Realm > > AVP. All this happens in the NAS. But the NAS doesn't have > > to have all routing information to the possible realms. Instead, > > it would typically have a default router to the access provider's > > proxy or mediating network's proxy which makes the final routing > > selection. > > > > This is simple enough so far, but what's the problem with PANA? > > The issue is that I don't understand how you can use the > > ISP-Information > > at the PANA layer to fill in the Destination-Realm. Or you can use > > it in the case that the NAS has been configured to recognize the > > given ISP. But in a typical case the NAS would not be configured with > > the 1000 different home realms that you can be connected to. So, > > does PANA limit selected ISP to the ones it has advertised? If yes, > > then you would have to have all those 1000 ISPs configured in the > > PANA-enabled NASes. If you try to force one of the few known ISPs > > (bighome.com) but the user wanted to get to another one > > (smallandunknownisp.com), things would break, I think. This is because > > the Destination-Realm would be set to bighome.com whereas you really > > should have set it to smallandunknownisp.com. In either case > > the message > > should be directly sent to the bighome.com AAA server, but this can > > only route the request further if the Destination-Realm AVP is > > set correctly. > > > > --Jari > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Sun Mar 14 02:31:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06555 for ; Sun, 14 Mar 2004 02:31:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Q5G-0005QQ-Ew for pana-archive@odin.ietf.org; Sun, 14 Mar 2004 02:30:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2E7Us3Q020847 for pana-archive@odin.ietf.org; Sun, 14 Mar 2004 02:30:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Q5E-0005Q8-DP for pana-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 02:30:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06541 for ; Sun, 14 Mar 2004 02:30:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Q5A-0001yl-00 for pana-web-archive@ietf.org; Sun, 14 Mar 2004 02:30:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Q4C-0001lf-00 for pana-web-archive@ietf.org; Sun, 14 Mar 2004 02:29:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2Q3a-0001he-00 for pana-web-archive@ietf.org; Sun, 14 Mar 2004 02:29:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Q3S-0004l8-Me; Sun, 14 Mar 2004 02:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Q3H-0004gZ-CI for pana@optimus.ietf.org; Sun, 14 Mar 2004 02:28:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06455 for ; Sun, 14 Mar 2004 02:28:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Q3D-0001gh-00 for pana@ietf.org; Sun, 14 Mar 2004 02:28:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Q2J-0001cw-00 for pana@ietf.org; Sun, 14 Mar 2004 02:27:52 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B2Q1y-0001YY-00 for pana@ietf.org; Sun, 14 Mar 2004 02:27:30 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2E7RNKL024042; Sun, 14 Mar 2004 16:27:23 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2E7RNbt000540; Sun, 14 Mar 2004 16:27:23 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id SAA00539 ; Sun, 14 Mar 2004 16:27:23 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id QAA25735; Sun, 14 Mar 2004 16:27:23 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by toshiba.co.jp id QAA10715; Sun, 14 Mar 2004 16:27:22 +0900 (JST) Received: from steelhead (att01-031.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUK00E8C21J9Z@tsbpo1.po.toshiba.co.jp>; Sun, 14 Mar 2004 16:27:21 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B1uiO-0002av-00; Fri, 12 Mar 2004 14:01:12 -0800 Date: Fri, 12 Mar 2004 14:01:12 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] the question that I wanted to ask at the mike before the line was cut off... In-reply-to: To: Dan.Forsberg@nokia.com Cc: jari.arkko@piuha.net, pana@ietf.org Message-id: <20040312220112.GA9972@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, jari.arkko@piuha.net, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Dan and Jari, On Tue, Mar 09, 2004 at 03:05:10PM +0200, Dan.Forsberg@nokia.com wrote: > NAP is connected to ISP(s). I guess NAP could provide WLAN APs, but the ISP the backbone connection. If APs are shared among different ISPs, then ISP selection comes into the picture. I guess the question is how many ISPs could be connected to one NAP? Or what is the definition of NAP and ISP.. and how far does the NAP-ISP border go. Is NAP the as ANP (Access Network Provider)? :) > > So, my understanding currently is that I may use NAI like dan@visa.com and when I'm attaching to a NAP it advertises me ISPs that are connected to it, for example htv.fi, teliasonera.fi, and saunalahti.fi. Then I select one, let's say htv.fi and send that selection in the PSA message to the PAA. PAA then sends the AAA request to the htv.fi AAA gw/server, but the destination realm is visa.com. If we consider the realm-based routing table in Diameter (section 2.7 of RFC3588), a PAA node with a single Diameter client might not be able to support this case, since the routing table does not contain the chosen ISP information. However, the case can be supported if multiple Diameter clients are running on the PAA node, where each Diameter client is dedicated to serve a particular ISP by having its own realm-based routing table. In this case, the PAA can generate a AAA request and pass it (via internal communication) to the Diameter client that serves for htv.fi, and the Diameter client will take care of the rest of AAA routing towards the visa.com Diameter server through the htv.fi network. Yoshihiro Ohba > > - Dan > > > -----Original Message----- > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > > Jari Arkko > > Sent: 01 March, 2004 09:21 > > To: pana@ietf.org > > Subject: [Pana] the question that I wanted to ask at the mike > > before the > > line was cut off... > > > > > > > > I guess I still don't understand how roaming works in PANA. > > Currently, Diameter, for instance, works through looking at > > the NAI at the NAS, and placing this value in the Destination-Realm > > AVP. All this happens in the NAS. But the NAS doesn't have > > to have all routing information to the possible realms. Instead, > > it would typically have a default router to the access provider's > > proxy or mediating network's proxy which makes the final routing > > selection. > > > > This is simple enough so far, but what's the problem with PANA? > > The issue is that I don't understand how you can use the > > ISP-Information > > at the PANA layer to fill in the Destination-Realm. Or you can use > > it in the case that the NAS has been configured to recognize the > > given ISP. But in a typical case the NAS would not be configured with > > the 1000 different home realms that you can be connected to. So, > > does PANA limit selected ISP to the ones it has advertised? If yes, > > then you would have to have all those 1000 ISPs configured in the > > PANA-enabled NASes. If you try to force one of the few known ISPs > > (bighome.com) but the user wanted to get to another one > > (smallandunknownisp.com), things would break, I think. This is because > > the Destination-Realm would be set to bighome.com whereas you really > > should have set it to smallandunknownisp.com. In either case > > the message > > should be directly sent to the bighome.com AAA server, but this can > > only route the request further if the Destination-Realm AVP is > > set correctly. > > > > --Jari > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Mar 15 05:27:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19684 for ; Mon, 15 Mar 2004 05:27:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2pJF-0006TG-9X; Mon, 15 Mar 2004 05:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2pIz-0006Sq-2b for pana@optimus.ietf.org; Mon, 15 Mar 2004 05:26:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19675 for ; Mon, 15 Mar 2004 05:26:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2pIv-0006sv-00 for pana@ietf.org; Mon, 15 Mar 2004 05:26:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2pI8-0006n2-00 for pana@ietf.org; Mon, 15 Mar 2004 05:25:53 -0500 Received: from viap100.atea.be ([194.78.143.100] helo=hrtades9.atea.be) by ietf-mx with esmtp (Exim 4.12) id 1B2pHf-0006gl-00 for pana@ietf.org; Mon, 15 Mar 2004 05:25:23 -0500 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GZCFTYC5; Mon, 15 Mar 2004 11:24:53 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Mar 2004 11:24:53 +0100 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195692075@hrtades7.atea.be> From: Goeman Stefan To: pana@ietf.org Date: Mon, 15 Mar 2004 11:24:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40A77.C0F53D60" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Subject: [Pana] [Pana]: Pana and IEEE802.11i Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C40A77.C0F53D60 Content-Type: text/plain; charset="iso-8859-1" Hello, I am reading "draft-ohba-pana-framework-00.txt". It is unclear to me how PANA would work with IEEE802.11. That is using PANA for authentication and then using the shared key between STA and AP to derive the L2 keys. Section 10.2.2 mentions two methods, i.e. separate PAA and AP (section 10.2.2.1) and Co-located PAA and AP (section 10.2.2.2). 1. It is unclear to me how IP traffic is allowed before you are authenticated. I suppose that, before authentication, everything will go through the uncontrolled port. Section 5.9.1 of IEEE802.11i (page 13) mentions that protocols (IP-based protocols?) may need to bypass the authorization function and make use of the uncontrolled port. Then, how do you manage which IP-based protocols are allowed to go through the uncontrolled port? I don't find this in IEEE802.11i. 2. Section 10.2.2.1 describes the case where the PAA and the AP are separate. This case uses two VLAN (an unauthenticated VLAN and an authenticated VLAN), possible in one physical AP. I am not an LAN expert, but these two Virtual APs, do they have different MAC addresses (L2-addresses), on the "link" towards the PaC? It is also mentioned that the PaC runs PANA authentication on the unauthenticated VLAN to obtain the MAC address of the authenticated VLAN (So, here I suppose that there are indeed two MAC addresses). How does the PaC obtains this MAC address. Would this be an EP-Device-ID AVP, containing the MAC-address of the authenticated VLAN, included in the PANA-Binding-Request message? 3. You don't know the difference between the separate EP-PAA case and the co-located EP/PAA case until you receive this PANA-Binding-Request message, which indicates how the PaC should run the 4-way handshake protocol. It seems to me that section 10.2.2.1 suggests that this 4-way handshake protocol is run between the PaC and the authenticated VLAN; or, the 4-way handshake protocol is run over the controlled port. Is this so? Greetings, Stefan. Stefan Goeman SIEMENS ICM/ICN Stefan.Goeman@siemens.com Mobile Solutions and Enabling Services http://www.ic.siemens.be Customer driven solution providers ------_=_NextPart_001_01C40A77.C0F53D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Pana]: Pana and IEEE802.11i

Hello,

I am reading = "draft-ohba-pana-framework-00.txt". It is unclear to me how = PANA would work with IEEE802.11. That is using PANA for authentication = and then using the shared key between STA and AP to derive the L2 keys. =

Section 10.2.2 mentions two methods, = i.e. separate PAA and AP (section 10.2.2.1) and Co-located PAA and AP = (section 10.2.2.2).

1. It is unclear to me how IP traffic = is allowed before you are authenticated. I suppose that, before = authentication, everything will go through the uncontrolled port. = Section 5.9.1 of IEEE802.11i (page 13) mentions that protocols = (IP-based protocols?) may need to bypass the authorization function and = make use of the uncontrolled port. Then, how do you manage which = IP-based protocols are allowed to go through the uncontrolled port? I = don't find this in IEEE802.11i.

2. Section 10.2.2.1 describes the case = where the PAA and the AP are separate. This case uses two VLAN (an = unauthenticated VLAN and an authenticated VLAN), possible in one = physical AP. I am not an LAN expert, but these two Virtual APs, do they = have different MAC addresses (L2-addresses), on the "link" = towards the PaC? It is also mentioned that the PaC runs PANA = authentication on the unauthenticated VLAN to obtain the MAC address of = the authenticated VLAN (So, here I suppose that there are indeed two = MAC addresses). How does the PaC obtains this MAC address. Would this = be an EP-Device-ID AVP, containing the MAC-address of the authenticated = VLAN, included in the PANA-Binding-Request message?

3. You don't know the difference = between the separate EP-PAA case and the co-located EP/PAA case until = you receive this PANA-Binding-Request message, which indicates how the = PaC should run the 4-way handshake protocol. It seems to me that = section 10.2.2.1 suggests that this 4-way handshake protocol is run = between the PaC and the authenticated VLAN; or, the 4-way handshake = protocol is run over the controlled port. Is this so? 


Greetings,
Stefan.

Stefan = Goeman
SIEMENS ICM/ICN
Stefan.Goeman@siemens.com
Mobile Solutions=A0
and Enabling Services
http://www.ic.siemens.be        = =A0      
Customer driven solution providers =     

------_=_NextPart_001_01C40A77.C0F53D60-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 15 05:34:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19966 for ; Mon, 15 Mar 2004 05:34:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2pQ1-0006fB-RE for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 05:34:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FAY1ZR025594 for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 05:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2pPz-0006eh-SE for pana-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 05:33:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19855 for ; Mon, 15 Mar 2004 05:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2pPw-0007kK-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 05:33:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2pOu-0007VG-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 05:32:53 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B2pOD-0007Nq-01 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 05:32:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B2pJJ-0005MD-Kg for pana-web-archive@ietf.org; Mon, 15 Mar 2004 05:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2pJF-0006TG-9X; Mon, 15 Mar 2004 05:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2pIz-0006Sq-2b for pana@optimus.ietf.org; Mon, 15 Mar 2004 05:26:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19675 for ; Mon, 15 Mar 2004 05:26:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2pIv-0006sv-00 for pana@ietf.org; Mon, 15 Mar 2004 05:26:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2pI8-0006n2-00 for pana@ietf.org; Mon, 15 Mar 2004 05:25:53 -0500 Received: from viap100.atea.be ([194.78.143.100] helo=hrtades9.atea.be) by ietf-mx with esmtp (Exim 4.12) id 1B2pHf-0006gl-00 for pana@ietf.org; Mon, 15 Mar 2004 05:25:23 -0500 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GZCFTYC5; Mon, 15 Mar 2004 11:24:53 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Mar 2004 11:24:53 +0100 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195692075@hrtades7.atea.be> From: Goeman Stefan To: pana@ietf.org Date: Mon, 15 Mar 2004 11:24:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40A77.C0F53D60" Subject: [Pana] [Pana]: Pana and IEEE802.11i Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C40A77.C0F53D60 Content-Type: text/plain; charset="iso-8859-1" Hello, I am reading "draft-ohba-pana-framework-00.txt". It is unclear to me how PANA would work with IEEE802.11. That is using PANA for authentication and then using the shared key between STA and AP to derive the L2 keys. Section 10.2.2 mentions two methods, i.e. separate PAA and AP (section 10.2.2.1) and Co-located PAA and AP (section 10.2.2.2). 1. It is unclear to me how IP traffic is allowed before you are authenticated. I suppose that, before authentication, everything will go through the uncontrolled port. Section 5.9.1 of IEEE802.11i (page 13) mentions that protocols (IP-based protocols?) may need to bypass the authorization function and make use of the uncontrolled port. Then, how do you manage which IP-based protocols are allowed to go through the uncontrolled port? I don't find this in IEEE802.11i. 2. Section 10.2.2.1 describes the case where the PAA and the AP are separate. This case uses two VLAN (an unauthenticated VLAN and an authenticated VLAN), possible in one physical AP. I am not an LAN expert, but these two Virtual APs, do they have different MAC addresses (L2-addresses), on the "link" towards the PaC? It is also mentioned that the PaC runs PANA authentication on the unauthenticated VLAN to obtain the MAC address of the authenticated VLAN (So, here I suppose that there are indeed two MAC addresses). How does the PaC obtains this MAC address. Would this be an EP-Device-ID AVP, containing the MAC-address of the authenticated VLAN, included in the PANA-Binding-Request message? 3. You don't know the difference between the separate EP-PAA case and the co-located EP/PAA case until you receive this PANA-Binding-Request message, which indicates how the PaC should run the 4-way handshake protocol. It seems to me that section 10.2.2.1 suggests that this 4-way handshake protocol is run between the PaC and the authenticated VLAN; or, the 4-way handshake protocol is run over the controlled port. Is this so? Greetings, Stefan. Stefan Goeman SIEMENS ICM/ICN Stefan.Goeman@siemens.com Mobile Solutions and Enabling Services http://www.ic.siemens.be Customer driven solution providers ------_=_NextPart_001_01C40A77.C0F53D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Pana]: Pana and IEEE802.11i

Hello,

I am reading = "draft-ohba-pana-framework-00.txt". It is unclear to me how = PANA would work with IEEE802.11. That is using PANA for authentication = and then using the shared key between STA and AP to derive the L2 keys. =

Section 10.2.2 mentions two methods, = i.e. separate PAA and AP (section 10.2.2.1) and Co-located PAA and AP = (section 10.2.2.2).

1. It is unclear to me how IP traffic = is allowed before you are authenticated. I suppose that, before = authentication, everything will go through the uncontrolled port. = Section 5.9.1 of IEEE802.11i (page 13) mentions that protocols = (IP-based protocols?) may need to bypass the authorization function and = make use of the uncontrolled port. Then, how do you manage which = IP-based protocols are allowed to go through the uncontrolled port? I = don't find this in IEEE802.11i.

2. Section 10.2.2.1 describes the case = where the PAA and the AP are separate. This case uses two VLAN (an = unauthenticated VLAN and an authenticated VLAN), possible in one = physical AP. I am not an LAN expert, but these two Virtual APs, do they = have different MAC addresses (L2-addresses), on the "link" = towards the PaC? It is also mentioned that the PaC runs PANA = authentication on the unauthenticated VLAN to obtain the MAC address of = the authenticated VLAN (So, here I suppose that there are indeed two = MAC addresses). How does the PaC obtains this MAC address. Would this = be an EP-Device-ID AVP, containing the MAC-address of the authenticated = VLAN, included in the PANA-Binding-Request message?

3. You don't know the difference = between the separate EP-PAA case and the co-located EP/PAA case until = you receive this PANA-Binding-Request message, which indicates how the = PaC should run the 4-way handshake protocol. It seems to me that = section 10.2.2.1 suggests that this 4-way handshake protocol is run = between the PaC and the authenticated VLAN; or, the 4-way handshake = protocol is run over the controlled port. Is this so? 


Greetings,
Stefan.

Stefan = Goeman
SIEMENS ICM/ICN
Stefan.Goeman@siemens.com
Mobile Solutions=A0
and Enabling Services
http://www.ic.siemens.be        = =A0      
Customer driven solution providers =     

------_=_NextPart_001_01C40A77.C0F53D60-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Mar 15 06:49:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22042 for ; Mon, 15 Mar 2004 06:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2qab-0002cq-Gk; Mon, 15 Mar 2004 06:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2qaO-0002by-0k for pana@optimus.ietf.org; Mon, 15 Mar 2004 06:48:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22007 for ; Mon, 15 Mar 2004 06:48:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2qaJ-00012v-00 for pana@ietf.org; Mon, 15 Mar 2004 06:48:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2qZS-0000vN-00 for pana@ietf.org; Mon, 15 Mar 2004 06:47:51 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B2qYT-0000hP-00 for pana@ietf.org; Mon, 15 Mar 2004 06:46:49 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUM00C0S8P150@mailout3.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 20:46:13 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUM00FV48OKVP@mailout3.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 20:45:57 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUM004MR8OKJ4@mmp2.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 20:45:56 +0900 (KST) Date: Mon, 15 Mar 2004 03:45:59 -0800 From: Alper Yegin Subject: RE: [Pana] the question that I wanted to ask at the mike before the line was cut off... In-reply-to: <20040312220112.GA9972@steelhead> To: "'Yoshihiro Ohba'" , Dan.Forsberg@nokia.com Cc: jari.arkko@piuha.net, pana@ietf.org Message-id: <005301c40a83$15d439c0$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > So, my understanding currently is that I may use NAI like dan@visa.com > and when I'm attaching to a NAP it advertises me ISPs that are connected > to it, for example htv.fi, teliasonera.fi, and saunalahti.fi. Then I > select one, let's say htv.fi and send that selection in the PSA message to > the PAA. PAA then sends the AAA request to the htv.fi AAA gw/server, but > the destination realm is visa.com. > > If we consider the realm-based routing table in Diameter (section 2.7 > of RFC3588), a PAA node with a single Diameter client might not be > able to support this case, since the routing table does not contain > the chosen ISP information. However, the case can be supported if > multiple Diameter clients are running on the PAA node, where each > Diameter client is dedicated to serve a particular ISP by having its > own realm-based routing table. In this case, the PAA can generate a > AAA request and pass it (via internal communication) to the Diameter > client that serves for htv.fi, and the Diameter client will take care > of the rest of AAA routing towards the visa.com Diameter server > through the htv.fi network. I don't think we need to run multiple AAA clients on the NAS. Just have a table to map "ISP-info" to "ISP realms." Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 15 06:51:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22142 for ; Mon, 15 Mar 2004 06:51:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2qcT-0002jO-Tx for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 06:50:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FBovTS010492 for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 06:50:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2qcT-0002j9-O9 for pana-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 06:50:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22130 for ; Mon, 15 Mar 2004 06:50:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2qcP-0001KV-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 06:50:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2qbU-0001Co-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 06:49:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2qaZ-000152-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 06:48:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2qab-0002cq-Gk; Mon, 15 Mar 2004 06:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2qaO-0002by-0k for pana@optimus.ietf.org; Mon, 15 Mar 2004 06:48:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22007 for ; Mon, 15 Mar 2004 06:48:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2qaJ-00012v-00 for pana@ietf.org; Mon, 15 Mar 2004 06:48:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2qZS-0000vN-00 for pana@ietf.org; Mon, 15 Mar 2004 06:47:51 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B2qYT-0000hP-00 for pana@ietf.org; Mon, 15 Mar 2004 06:46:49 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUM00C0S8P150@mailout3.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 20:46:13 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUM00FV48OKVP@mailout3.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 20:45:57 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUM004MR8OKJ4@mmp2.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 20:45:56 +0900 (KST) Date: Mon, 15 Mar 2004 03:45:59 -0800 From: Alper Yegin Subject: RE: [Pana] the question that I wanted to ask at the mike before the line was cut off... In-reply-to: <20040312220112.GA9972@steelhead> To: "'Yoshihiro Ohba'" , Dan.Forsberg@nokia.com Cc: jari.arkko@piuha.net, pana@ietf.org Message-id: <005301c40a83$15d439c0$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > So, my understanding currently is that I may use NAI like dan@visa.com > and when I'm attaching to a NAP it advertises me ISPs that are connected > to it, for example htv.fi, teliasonera.fi, and saunalahti.fi. Then I > select one, let's say htv.fi and send that selection in the PSA message to > the PAA. PAA then sends the AAA request to the htv.fi AAA gw/server, but > the destination realm is visa.com. > > If we consider the realm-based routing table in Diameter (section 2.7 > of RFC3588), a PAA node with a single Diameter client might not be > able to support this case, since the routing table does not contain > the chosen ISP information. However, the case can be supported if > multiple Diameter clients are running on the PAA node, where each > Diameter client is dedicated to serve a particular ISP by having its > own realm-based routing table. In this case, the PAA can generate a > AAA request and pass it (via internal communication) to the Diameter > client that serves for htv.fi, and the Diameter client will take care > of the rest of AAA routing towards the visa.com Diameter server > through the htv.fi network. I don't think we need to run multiple AAA clients on the NAS. Just have a table to map "ISP-info" to "ISP realms." Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Mar 15 07:17:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22833 for ; Mon, 15 Mar 2004 07:17:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2r1h-0005Lr-Bx; Mon, 15 Mar 2004 07:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2r1S-0005LM-06 for pana@optimus.ietf.org; Mon, 15 Mar 2004 07:16:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22808 for ; Mon, 15 Mar 2004 07:16:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2r1R-0004Jb-00 for pana@ietf.org; Mon, 15 Mar 2004 07:16:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2r0S-0004Cm-00 for pana@ietf.org; Mon, 15 Mar 2004 07:15:44 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B2qzW-000417-00 for pana@ietf.org; Mon, 15 Mar 2004 07:14:46 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUM00D019ZQIY@mailout3.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:14:14 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUM00FCZ9ZPVP@mailout3.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:14:13 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUM0015X9ZPTQ@mmp2.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:14:13 +0900 (KST) Date: Mon, 15 Mar 2004 04:14:15 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <005401c40a87$08e0cef0$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] issue63: MAC AVP a SHOULD or a MUST Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Proposed text change. Section 4.4 Re-authentication: Change the following text: For any EAP-based re-authentication, if there is an established PANA SA, PANA-Auth-Request and PANA-Auth-Answer messages SHOULD be protected by adding a MAC AVP to each message. To: For any EAP-based re-authentication, if there is an established PANA SA, PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected by adding a MAC AVP to each message. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 15 07:19:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22883 for ; Mon, 15 Mar 2004 07:19:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2r3T-0005Qp-BX for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 07:18:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FCIpaG020873 for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 07:18:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2r3T-0005Qa-6R for pana-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 07:18:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22868 for ; Mon, 15 Mar 2004 07:18:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2r3S-0004Yu-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 07:18:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2r2V-0004Rd-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 07:17:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2r1j-0004LA-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 07:17:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2r1h-0005Lr-Bx; Mon, 15 Mar 2004 07:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2r1S-0005LM-06 for pana@optimus.ietf.org; Mon, 15 Mar 2004 07:16:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22808 for ; Mon, 15 Mar 2004 07:16:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2r1R-0004Jb-00 for pana@ietf.org; Mon, 15 Mar 2004 07:16:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2r0S-0004Cm-00 for pana@ietf.org; Mon, 15 Mar 2004 07:15:44 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B2qzW-000417-00 for pana@ietf.org; Mon, 15 Mar 2004 07:14:46 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUM00D019ZQIY@mailout3.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:14:14 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUM00FCZ9ZPVP@mailout3.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:14:13 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUM0015X9ZPTQ@mmp2.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:14:13 +0900 (KST) Date: Mon, 15 Mar 2004 04:14:15 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <005401c40a87$08e0cef0$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Pana] issue63: MAC AVP a SHOULD or a MUST Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Proposed text change. Section 4.4 Re-authentication: Change the following text: For any EAP-based re-authentication, if there is an established PANA SA, PANA-Auth-Request and PANA-Auth-Answer messages SHOULD be protected by adding a MAC AVP to each message. To: For any EAP-based re-authentication, if there is an established PANA SA, PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected by adding a MAC AVP to each message. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Mar 15 07:31:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23118 for ; Mon, 15 Mar 2004 07:31:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2rFF-0006B4-Ru; Mon, 15 Mar 2004 07:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2rF5-00069j-1C for pana@optimus.ietf.org; Mon, 15 Mar 2004 07:30:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23108 for ; Mon, 15 Mar 2004 07:30:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2rF4-0005u4-00 for pana@ietf.org; Mon, 15 Mar 2004 07:30:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2rE9-0005nt-00 for pana@ietf.org; Mon, 15 Mar 2004 07:29:53 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1B2rDq-0005hR-00 for pana@ietf.org; Mon, 15 Mar 2004 07:29:34 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUM00201AO9TX@mailout1.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:28:57 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUM002PYAO8PS@mailout1.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:28:56 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUM00H84AO71O@mmp1.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:28:56 +0900 (KST) Date: Mon, 15 Mar 2004 04:28:57 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <005601c40a89$17253c10$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] issue64: Two separate codes for Session ID AVP Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Based on the proposed solution to this issue, here is the proposed text change. Change from: 9.4.3 Session-Id AVP Session-Id AVP (Code 1026) has an opaque data field, which is assigned by the PAA. All messages pertaining to a specific PANA Session MUST include only one Session-Id AVP and the same value MUST be used throughout the lifetime of a session. When present, the Session-Id SHOULD appear immediately following the PANA header. The Session-Id MUST be globally and eternally unique, as it is meant to identify a PANA Session without reference to any other information, and may be needed to correlate historical authentication information with accounting information. The Session-Id AVP MAY use Diameter [RFC3588] message formatting. In this case the AVP code is 263. To: 9.4.3 Session-Id AVP All messages pertaining to a specific PANA session MUST include a Session-Id AVP (Code 1026) which carries a PAA-assigned fix value throughout the lifetime of a session. When present, the Session-Id SHOULD appear immediately following the PANA header. The Session-Id MUST be globally and eternally unique, as it is meant to identify a PANA Session without reference to any other information, and may be needed to correlate historical authentication information with accounting information. The PANA Session-Id AVP has the same format as the Diameter Session-Id AVP [RFC3588]. Comments welcome. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 15 07:33:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23201 for ; Mon, 15 Mar 2004 07:33:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2rH1-0006Tk-Ji for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 07:32:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FCWpli024900 for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 07:32:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2rH1-0006TX-ER for pana-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 07:32:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23183 for ; Mon, 15 Mar 2004 07:32:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2rH0-00068C-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 07:32:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2rG3-00061R-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 07:31:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2rFH-0005v3-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 07:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2rFF-0006B4-Ru; Mon, 15 Mar 2004 07:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2rF5-00069j-1C for pana@optimus.ietf.org; Mon, 15 Mar 2004 07:30:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23108 for ; Mon, 15 Mar 2004 07:30:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2rF4-0005u4-00 for pana@ietf.org; Mon, 15 Mar 2004 07:30:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2rE9-0005nt-00 for pana@ietf.org; Mon, 15 Mar 2004 07:29:53 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1B2rDq-0005hR-00 for pana@ietf.org; Mon, 15 Mar 2004 07:29:34 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUM00201AO9TX@mailout1.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:28:57 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUM002PYAO8PS@mailout1.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:28:56 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUM00H84AO71O@mmp1.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:28:56 +0900 (KST) Date: Mon, 15 Mar 2004 04:28:57 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <005601c40a89$17253c10$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Pana] issue64: Two separate codes for Session ID AVP Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Based on the proposed solution to this issue, here is the proposed text change. Change from: 9.4.3 Session-Id AVP Session-Id AVP (Code 1026) has an opaque data field, which is assigned by the PAA. All messages pertaining to a specific PANA Session MUST include only one Session-Id AVP and the same value MUST be used throughout the lifetime of a session. When present, the Session-Id SHOULD appear immediately following the PANA header. The Session-Id MUST be globally and eternally unique, as it is meant to identify a PANA Session without reference to any other information, and may be needed to correlate historical authentication information with accounting information. The Session-Id AVP MAY use Diameter [RFC3588] message formatting. In this case the AVP code is 263. To: 9.4.3 Session-Id AVP All messages pertaining to a specific PANA session MUST include a Session-Id AVP (Code 1026) which carries a PAA-assigned fix value throughout the lifetime of a session. When present, the Session-Id SHOULD appear immediately following the PANA header. The Session-Id MUST be globally and eternally unique, as it is meant to identify a PANA Session without reference to any other information, and may be needed to correlate historical authentication information with accounting information. The PANA Session-Id AVP has the same format as the Diameter Session-Id AVP [RFC3588]. Comments welcome. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 15 07:33:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23215 for ; Mon, 15 Mar 2004 07:33:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2rH3-0006U4-2A for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 07:32:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FCWrKs024918 for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 07:32:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2rH2-0006Tp-Ut for pana-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 07:32:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23187 for ; Mon, 15 Mar 2004 07:32:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2rH2-00068R-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 07:32:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2rG4-00061b-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 07:31:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2rFH-0005v4-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 07:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2rFF-0006Al-DB; Mon, 15 Mar 2004 07:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2rF4-00069e-By for pana@optimus.ietf.org; Mon, 15 Mar 2004 07:30:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23105 for ; Mon, 15 Mar 2004 07:30:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2rF3-0005tx-00 for pana@ietf.org; Mon, 15 Mar 2004 07:30:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2rE8-0005nl-00 for pana@ietf.org; Mon, 15 Mar 2004 07:29:53 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1B2rDp-0005hR-00 for pana@ietf.org; Mon, 15 Mar 2004 07:29:34 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUM00201AO8TT@mailout1.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:28:56 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUM002PYAO8PS@mailout1.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:28:56 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUM00H84AO71O@mmp1.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:28:56 +0900 (KST) Date: Mon, 15 Mar 2004 04:28:57 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <005501c40a89$1706b790$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Pana] issue65: Clarification on simultaneous per-packet protection Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Proposed text change from: 9.4.5 Protection-Capability AVP The Protection-Capability AVP (Code 1028) is of type Unsigned32. The AVP data is used as a collection of flags for different data protection capability indications. Below is a list of specified data protection capabilities: 0 UNKNOWN 1 L2_PROTECTION 2 IPSEC_PROTECTION to: 9.4.5 Protection-Capability AVP The Protection-Capability AVP (Code 1028) is of type Unsigned32. The AVP data indicates the cryptographic data protection capability supported by the EPs. Below is a list of specified data protection capabilities: 0 L2_PROTECTION 1 IPSEC_PROTECTION Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Mar 15 08:20:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23117 for ; Mon, 15 Mar 2004 07:31:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2rFF-0006Al-DB; Mon, 15 Mar 2004 07:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2rF4-00069e-By for pana@optimus.ietf.org; Mon, 15 Mar 2004 07:30:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23105 for ; Mon, 15 Mar 2004 07:30:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2rF3-0005tx-00 for pana@ietf.org; Mon, 15 Mar 2004 07:30:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2rE8-0005nl-00 for pana@ietf.org; Mon, 15 Mar 2004 07:29:53 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1B2rDp-0005hR-00 for pana@ietf.org; Mon, 15 Mar 2004 07:29:34 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUM00201AO8TT@mailout1.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:28:56 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUM002PYAO8PS@mailout1.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:28:56 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUM00H84AO71O@mmp1.samsung.com> for pana@ietf.org; Mon, 15 Mar 2004 21:28:56 +0900 (KST) Date: Mon, 15 Mar 2004 04:28:57 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <005501c40a89$1706b790$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] issue65: Clarification on simultaneous per-packet protection Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Proposed text change from: 9.4.5 Protection-Capability AVP The Protection-Capability AVP (Code 1028) is of type Unsigned32. The AVP data is used as a collection of flags for different data protection capability indications. Below is a list of specified data protection capabilities: 0 UNKNOWN 1 L2_PROTECTION 2 IPSEC_PROTECTION to: 9.4.5 Protection-Capability AVP The Protection-Capability AVP (Code 1028) is of type Unsigned32. The AVP data indicates the cryptographic data protection capability supported by the EPs. Below is a list of specified data protection capabilities: 0 L2_PROTECTION 1 IPSEC_PROTECTION Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Mar 15 13:27:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14782 for ; Mon, 15 Mar 2004 13:27:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wnm-0007lO-BU; Mon, 15 Mar 2004 13:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wmv-0007jn-Lk for pana@optimus.ietf.org; Mon, 15 Mar 2004 13:26:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14693 for ; Mon, 15 Mar 2004 13:26:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wmt-0002l2-00 for pana@ietf.org; Mon, 15 Mar 2004 13:26:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2wlz-0002id-00 for pana@ietf.org; Mon, 15 Mar 2004 13:25:12 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B2wlE-0002fg-00 for pana@ietf.org; Mon, 15 Mar 2004 13:24:25 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2FIONKL029925; Tue, 16 Mar 2004 03:24:23 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2FIONgi003969; Tue, 16 Mar 2004 03:24:23 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA03966 ; Tue, 16 Mar 2004 03:24:22 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA14426; Tue, 16 Mar 2004 03:24:22 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA12001; Tue, 16 Mar 2004 03:24:22 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2FIOLb9026451; Tue, 16 Mar 2004 03:24:21 +0900 (JST) Received: from steelhead (att01-016.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUM0044TR4IFY@tsbpo1.po.toshiba.co.jp>; Tue, 16 Mar 2004 03:24:20 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B1yU5-0002hC-00; Fri, 12 Mar 2004 18:02:41 -0800 Date: Fri, 12 Mar 2004 18:02:40 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] the question that I wanted to ask at the mike before the line was cut off... In-reply-to: <005301c40a83$15d439c0$ed2f024b@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , Dan.Forsberg@nokia.com, jari.arkko@piuha.net, pana@ietf.org Message-id: <20040313020240.GD10062@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , Dan.Forsberg@nokia.com, jari.arkko@piuha.net, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040312220112.GA9972@steelhead> <005301c40a83$15d439c0$ed2f024b@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Mon, Mar 15, 2004 at 03:45:59AM -0800, Alper Yegin wrote: > > > So, my understanding currently is that I may use NAI like > dan@visa.com > > and when I'm attaching to a NAP it advertises me ISPs that are > connected > > to it, for example htv.fi, teliasonera.fi, and saunalahti.fi. Then I > > select one, let's say htv.fi and send that selection in the PSA > message to > > the PAA. PAA then sends the AAA request to the htv.fi AAA gw/server, > but > > the destination realm is visa.com. > > > > If we consider the realm-based routing table in Diameter (section 2.7 > > of RFC3588), a PAA node with a single Diameter client might not be > > able to support this case, since the routing table does not contain > > the chosen ISP information. However, the case can be supported if > > multiple Diameter clients are running on the PAA node, where each > > Diameter client is dedicated to serve a particular ISP by having its > > own realm-based routing table. In this case, the PAA can generate a > > AAA request and pass it (via internal communication) to the Diameter > > client that serves for htv.fi, and the Diameter client will take care > > of the rest of AAA routing towards the visa.com Diameter server > > through the htv.fi network. > > I don't think we need to run multiple AAA clients on the NAS. Just have > a table to map "ISP-info" to "ISP realms." Can the NAS have such a table without changing the structure of realm-based routing table? Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 15 13:29:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14933 for ; Mon, 15 Mar 2004 13:29:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wpf-0007tG-Il for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 13:29:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FISxCt030324 for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 13:28:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wpf-0007t1-B4 for pana-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 13:28:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14894 for ; Mon, 15 Mar 2004 13:28:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wpd-0002sB-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 13:28:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2woh-0002pM-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 13:28:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2wnm-0002nU-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 13:27:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wnm-0007lO-BU; Mon, 15 Mar 2004 13:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2wmv-0007jn-Lk for pana@optimus.ietf.org; Mon, 15 Mar 2004 13:26:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14693 for ; Mon, 15 Mar 2004 13:26:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2wmt-0002l2-00 for pana@ietf.org; Mon, 15 Mar 2004 13:26:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2wlz-0002id-00 for pana@ietf.org; Mon, 15 Mar 2004 13:25:12 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B2wlE-0002fg-00 for pana@ietf.org; Mon, 15 Mar 2004 13:24:25 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2FIONKL029925; Tue, 16 Mar 2004 03:24:23 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2FIONgi003969; Tue, 16 Mar 2004 03:24:23 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA03966 ; Tue, 16 Mar 2004 03:24:22 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA14426; Tue, 16 Mar 2004 03:24:22 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA12001; Tue, 16 Mar 2004 03:24:22 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2FIOLb9026451; Tue, 16 Mar 2004 03:24:21 +0900 (JST) Received: from steelhead (att01-016.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUM0044TR4IFY@tsbpo1.po.toshiba.co.jp>; Tue, 16 Mar 2004 03:24:20 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B1yU5-0002hC-00; Fri, 12 Mar 2004 18:02:41 -0800 Date: Fri, 12 Mar 2004 18:02:40 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] the question that I wanted to ask at the mike before the line was cut off... In-reply-to: <005301c40a83$15d439c0$ed2f024b@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , Dan.Forsberg@nokia.com, jari.arkko@piuha.net, pana@ietf.org Message-id: <20040313020240.GD10062@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , Dan.Forsberg@nokia.com, jari.arkko@piuha.net, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040312220112.GA9972@steelhead> <005301c40a83$15d439c0$ed2f024b@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Mon, Mar 15, 2004 at 03:45:59AM -0800, Alper Yegin wrote: > > > So, my understanding currently is that I may use NAI like > dan@visa.com > > and when I'm attaching to a NAP it advertises me ISPs that are > connected > > to it, for example htv.fi, teliasonera.fi, and saunalahti.fi. Then I > > select one, let's say htv.fi and send that selection in the PSA > message to > > the PAA. PAA then sends the AAA request to the htv.fi AAA gw/server, > but > > the destination realm is visa.com. > > > > If we consider the realm-based routing table in Diameter (section 2.7 > > of RFC3588), a PAA node with a single Diameter client might not be > > able to support this case, since the routing table does not contain > > the chosen ISP information. However, the case can be supported if > > multiple Diameter clients are running on the PAA node, where each > > Diameter client is dedicated to serve a particular ISP by having its > > own realm-based routing table. In this case, the PAA can generate a > > AAA request and pass it (via internal communication) to the Diameter > > client that serves for htv.fi, and the Diameter client will take care > > of the rest of AAA routing towards the visa.com Diameter server > > through the htv.fi network. > > I don't think we need to run multiple AAA clients on the NAS. Just have > a table to map "ISP-info" to "ISP realms." Can the NAS have such a table without changing the structure of realm-based routing table? Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Mar 15 13:43:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15536 for ; Mon, 15 Mar 2004 13:43:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2x3F-0000Vc-24; Mon, 15 Mar 2004 13:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2x2H-0000UU-Nr for pana@optimus.ietf.org; Mon, 15 Mar 2004 13:42:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15467 for ; Mon, 15 Mar 2004 13:41:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2x2F-0003T1-00 for pana@ietf.org; Mon, 15 Mar 2004 13:41:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2x1K-0003RN-00 for pana@ietf.org; Mon, 15 Mar 2004 13:41:03 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B2x0T-0003Pt-00 for pana@ietf.org; Mon, 15 Mar 2004 13:40:10 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2FIe9KL003457; Tue, 16 Mar 2004 03:40:09 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2FIe8pn008165; Tue, 16 Mar 2004 03:40:08 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA08164 ; Tue, 16 Mar 2004 03:40:08 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA17430; Tue, 16 Mar 2004 03:40:08 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA11154; Tue, 16 Mar 2004 03:40:07 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2FIe6b9008645; Tue, 16 Mar 2004 03:40:07 +0900 (JST) Received: from steelhead (att01-016.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUM004C3RURFY@tsbpo1.po.toshiba.co.jp>; Tue, 16 Mar 2004 03:40:05 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B1yc0-0002hS-00; Fri, 12 Mar 2004 18:10:52 -0800 Date: Fri, 12 Mar 2004 18:10:51 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] [Pana]: Pana and IEEE802.11i In-reply-to: <57FD2C3A246F76438CA6FDAD8FE9F195692075@hrtades7.atea.be> To: Goeman Stefan Cc: pana@ietf.org Message-id: <20040313021051.GE10062@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Goeman Stefan , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <57FD2C3A246F76438CA6FDAD8FE9F195692075@hrtades7.atea.be> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Hi Stefan, On Mon, Mar 15, 2004 at 11:24:52AM +0100, Goeman Stefan wrote: > Hello, > > I am reading "draft-ohba-pana-framework-00.txt". It is unclear to me how > PANA would work with IEEE802.11. That is using PANA for authentication and > then using the shared key between STA and AP to derive the L2 keys. > > Section 10.2.2 mentions two methods, i.e. separate PAA and AP (section > 10.2.2.1) and Co-located PAA and AP (section 10.2.2.2). > > 1. It is unclear to me how IP traffic is allowed before you are > authenticated. I suppose that, before authentication, everything will go > through the uncontrolled port. Section 5.9.1 of IEEE802.11i (page 13) > mentions that protocols (IP-based protocols?) may need to bypass the > authorization function and make use of the uncontrolled port. Then, how do > you manage which IP-based protocols are allowed to go through the > uncontrolled port? I don't find this in IEEE802.11i. How specific IP packets go through the uncontrolled port depends on AP implementation and it is not described in IEEE 802.11i, BTW, in the case of separate PAA and AP, all IP traffic before PANA authentication goes through unauthenticated VLAN (virtual) AP which does not have controlled/uncontrolled port distinction, so the above issue does not apply to the separate PAA and AP case. > > 2. Section 10.2.2.1 describes the case where the PAA and the AP are > separate. This case uses two VLAN (an unauthenticated VLAN and an > authenticated VLAN), possible in one physical AP. I am not an LAN expert, > but these two Virtual APs, do they have different MAC addresses > (L2-addresses), on the "link" towards the PaC? There are several types of virtual APs, but sectioin 10.2.2.1 assumes that different APs have different ESSIDs (and MAC addresses are different). > It is also mentioned that the > PaC runs PANA authentication on the unauthenticated VLAN to obtain the MAC > address of the authenticated VLAN (So, here I suppose that there are indeed > two MAC addresses). How does the PaC obtains this MAC address. Would this be > an EP-Device-ID AVP, containing the MAC-address of the authenticated VLAN, > included in the PANA-Binding-Request message? Yes. > > 3. You don't know the difference between the separate EP-PAA case and the > co-located EP/PAA case until you receive this PANA-Binding-Request message, > which indicates how the PaC should run the 4-way handshake protocol. It > seems to me that section 10.2.2.1 suggests that this 4-way handshake > protocol is run between the PaC and the authenticated VLAN; or, the 4-way > handshake protocol is run over the controlled port. Is this so? In section 10.2.2.1, 4-way handshake is performed between the station (PaC) and authenticated VLAN AP. Also, in IEEE 802.11i, IEEE 802.1X messages including the ones used for 4-way handshake are processed at the IEEE 802.1X uncontrolled port of the AP. Yoshihiro Ohba > > > Greetings, > Stefan. > > Stefan Goeman > SIEMENS ICM/ICN > Stefan.Goeman@siemens.com > Mobile Solutions > and Enabling Services > http://www.ic.siemens.be > > Customer driven solution providers > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 15 13:45:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15641 for ; Mon, 15 Mar 2004 13:45:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2x59-0000iT-Ob for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 13:44:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FIix7B002747 for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 13:44:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2x59-0000iE-Jy for pana-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 13:44:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15597 for ; Mon, 15 Mar 2004 13:44:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2x57-0003be-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 13:44:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2x49-0003YD-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 13:43:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2x3H-0003Vp-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 13:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2x3F-0000Vc-24; Mon, 15 Mar 2004 13:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2x2H-0000UU-Nr for pana@optimus.ietf.org; Mon, 15 Mar 2004 13:42:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15467 for ; Mon, 15 Mar 2004 13:41:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2x2F-0003T1-00 for pana@ietf.org; Mon, 15 Mar 2004 13:41:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2x1K-0003RN-00 for pana@ietf.org; Mon, 15 Mar 2004 13:41:03 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B2x0T-0003Pt-00 for pana@ietf.org; Mon, 15 Mar 2004 13:40:10 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2FIe9KL003457; Tue, 16 Mar 2004 03:40:09 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2FIe8pn008165; Tue, 16 Mar 2004 03:40:08 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA08164 ; Tue, 16 Mar 2004 03:40:08 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA17430; Tue, 16 Mar 2004 03:40:08 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA11154; Tue, 16 Mar 2004 03:40:07 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2FIe6b9008645; Tue, 16 Mar 2004 03:40:07 +0900 (JST) Received: from steelhead (att01-016.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUM004C3RURFY@tsbpo1.po.toshiba.co.jp>; Tue, 16 Mar 2004 03:40:05 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B1yc0-0002hS-00; Fri, 12 Mar 2004 18:10:52 -0800 Date: Fri, 12 Mar 2004 18:10:51 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] [Pana]: Pana and IEEE802.11i In-reply-to: <57FD2C3A246F76438CA6FDAD8FE9F195692075@hrtades7.atea.be> To: Goeman Stefan Cc: pana@ietf.org Message-id: <20040313021051.GE10062@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Goeman Stefan , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <57FD2C3A246F76438CA6FDAD8FE9F195692075@hrtades7.atea.be> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Stefan, On Mon, Mar 15, 2004 at 11:24:52AM +0100, Goeman Stefan wrote: > Hello, > > I am reading "draft-ohba-pana-framework-00.txt". It is unclear to me how > PANA would work with IEEE802.11. That is using PANA for authentication and > then using the shared key between STA and AP to derive the L2 keys. > > Section 10.2.2 mentions two methods, i.e. separate PAA and AP (section > 10.2.2.1) and Co-located PAA and AP (section 10.2.2.2). > > 1. It is unclear to me how IP traffic is allowed before you are > authenticated. I suppose that, before authentication, everything will go > through the uncontrolled port. Section 5.9.1 of IEEE802.11i (page 13) > mentions that protocols (IP-based protocols?) may need to bypass the > authorization function and make use of the uncontrolled port. Then, how do > you manage which IP-based protocols are allowed to go through the > uncontrolled port? I don't find this in IEEE802.11i. How specific IP packets go through the uncontrolled port depends on AP implementation and it is not described in IEEE 802.11i, BTW, in the case of separate PAA and AP, all IP traffic before PANA authentication goes through unauthenticated VLAN (virtual) AP which does not have controlled/uncontrolled port distinction, so the above issue does not apply to the separate PAA and AP case. > > 2. Section 10.2.2.1 describes the case where the PAA and the AP are > separate. This case uses two VLAN (an unauthenticated VLAN and an > authenticated VLAN), possible in one physical AP. I am not an LAN expert, > but these two Virtual APs, do they have different MAC addresses > (L2-addresses), on the "link" towards the PaC? There are several types of virtual APs, but sectioin 10.2.2.1 assumes that different APs have different ESSIDs (and MAC addresses are different). > It is also mentioned that the > PaC runs PANA authentication on the unauthenticated VLAN to obtain the MAC > address of the authenticated VLAN (So, here I suppose that there are indeed > two MAC addresses). How does the PaC obtains this MAC address. Would this be > an EP-Device-ID AVP, containing the MAC-address of the authenticated VLAN, > included in the PANA-Binding-Request message? Yes. > > 3. You don't know the difference between the separate EP-PAA case and the > co-located EP/PAA case until you receive this PANA-Binding-Request message, > which indicates how the PaC should run the 4-way handshake protocol. It > seems to me that section 10.2.2.1 suggests that this 4-way handshake > protocol is run between the PaC and the authenticated VLAN; or, the 4-way > handshake protocol is run over the controlled port. Is this so? In section 10.2.2.1, 4-way handshake is performed between the station (PaC) and authenticated VLAN AP. Also, in IEEE 802.11i, IEEE 802.1X messages including the ones used for 4-way handshake are processed at the IEEE 802.1X uncontrolled port of the AP. Yoshihiro Ohba > > > Greetings, > Stefan. > > Stefan Goeman > SIEMENS ICM/ICN > Stefan.Goeman@siemens.com > Mobile Solutions > and Enabling Services > http://www.ic.siemens.be > > Customer driven solution providers > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Mar 15 19:39:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10327 for ; Mon, 15 Mar 2004 19:39:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B32bl-0001M9-1t; Mon, 15 Mar 2004 19:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B32bC-0001IH-MJ for pana@optimus.ietf.org; Mon, 15 Mar 2004 19:38:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10281 for ; Mon, 15 Mar 2004 19:38:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B32bA-0007HO-00 for pana@ietf.org; Mon, 15 Mar 2004 19:38:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B32aL-0007Cm-00 for pana@ietf.org; Mon, 15 Mar 2004 19:37:33 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B32Zc-00076P-00 for pana@ietf.org; Mon, 15 Mar 2004 19:36:48 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUN003018CBH7@mailout3.samsung.com> for pana@ietf.org; Tue, 16 Mar 2004 09:36:12 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUN00CU68CA2L@mailout3.samsung.com> for pana@ietf.org; Tue, 16 Mar 2004 09:36:11 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUN00KDQ8CAAY@mmp2.samsung.com> for pana@ietf.org; Tue, 16 Mar 2004 09:36:10 +0900 (KST) Date: Mon, 15 Mar 2004 16:36:13 -0800 From: Alper Yegin Subject: RE: [Pana] the question that I wanted to ask at the mike before the line was cut off... In-reply-to: <20040313020240.GD10062@steelhead> To: "'Yoshihiro Ohba'" Cc: Dan.Forsberg@nokia.com, jari.arkko@piuha.net, pana@ietf.org Message-id: <000401c40aee$afb3d8f0$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > I don't think we need to run multiple AAA clients on the NAS. Just have > > a table to map "ISP-info" to "ISP realms." > > Can the NAS have such a table without changing the structure of > realm-based routing table? This is just another level of lookup table, separate from the realm-based routing table. It maps "ISP-info" to realm information. Once the NAS knows the selected realm, the rest is the same as before. We don't need this additional lookup when we use NAI-based ISP selection, because the "realm" is already embedded in the NAI. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 15 19:41:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10424 for ; Mon, 15 Mar 2004 19:41:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B32dD-0001RN-H5 for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 19:40:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2G0eVgo005531 for pana-archive@odin.ietf.org; Mon, 15 Mar 2004 19:40:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B32dD-0001R8-BS for pana-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 19:40:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10397 for ; Mon, 15 Mar 2004 19:40:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B32dB-0007Sj-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 19:40:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B32cQ-0007Or-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 19:39:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B32bl-0007JD-00 for pana-web-archive@ietf.org; Mon, 15 Mar 2004 19:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B32bl-0001M9-1t; Mon, 15 Mar 2004 19:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B32bC-0001IH-MJ for pana@optimus.ietf.org; Mon, 15 Mar 2004 19:38:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10281 for ; Mon, 15 Mar 2004 19:38:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B32bA-0007HO-00 for pana@ietf.org; Mon, 15 Mar 2004 19:38:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B32aL-0007Cm-00 for pana@ietf.org; Mon, 15 Mar 2004 19:37:33 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B32Zc-00076P-00 for pana@ietf.org; Mon, 15 Mar 2004 19:36:48 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUN003018CBH7@mailout3.samsung.com> for pana@ietf.org; Tue, 16 Mar 2004 09:36:12 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUN00CU68CA2L@mailout3.samsung.com> for pana@ietf.org; Tue, 16 Mar 2004 09:36:11 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUN00KDQ8CAAY@mmp2.samsung.com> for pana@ietf.org; Tue, 16 Mar 2004 09:36:10 +0900 (KST) Date: Mon, 15 Mar 2004 16:36:13 -0800 From: Alper Yegin Subject: RE: [Pana] the question that I wanted to ask at the mike before the line was cut off... In-reply-to: <20040313020240.GD10062@steelhead> To: "'Yoshihiro Ohba'" Cc: Dan.Forsberg@nokia.com, jari.arkko@piuha.net, pana@ietf.org Message-id: <000401c40aee$afb3d8f0$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > I don't think we need to run multiple AAA clients on the NAS. Just have > > a table to map "ISP-info" to "ISP realms." > > Can the NAS have such a table without changing the structure of > realm-based routing table? This is just another level of lookup table, separate from the realm-based routing table. It maps "ISP-info" to realm information. Once the NAS knows the selected realm, the rest is the same as before. We don't need this additional lookup when we use NAI-based ISP selection, because the "realm" is already embedded in the NAI. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Mar 16 11:07:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08016 for ; Tue, 16 Mar 2004 11:07:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3H5o-000385-FJ; Tue, 16 Mar 2004 11:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3H5b-00037C-BQ for pana@optimus.ietf.org; Tue, 16 Mar 2004 11:06:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07975 for ; Tue, 16 Mar 2004 11:06:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3H5Y-0000if-00 for pana@ietf.org; Tue, 16 Mar 2004 11:06:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3H4h-0000ce-00 for pana@ietf.org; Tue, 16 Mar 2004 11:05:52 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3H3p-0000Wy-00 for pana@ietf.org; Tue, 16 Mar 2004 11:04:58 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2GG4tKL021158; Wed, 17 Mar 2004 01:04:55 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2GG4tt1000044; Wed, 17 Mar 2004 01:04:55 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA00043 ; Wed, 17 Mar 2004 01:04:55 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA04414; Wed, 17 Mar 2004 01:04:54 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA28794; Wed, 17 Mar 2004 01:04:54 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2GG4rb9009956; Wed, 17 Mar 2004 01:04:53 +0900 (JST) Received: from steelhead ([159.119.168.132]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUO00A2IFBZ0D@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 01:04:52 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B1qp3-0002TO-00; Fri, 12 Mar 2004 09:51:49 -0800 Date: Fri, 12 Mar 2004 09:51:49 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] the question that I wanted to ask at the mike before the line was cut off... In-reply-to: <20040312145901.GD6749@steelhead> To: Dan.Forsberg@nokia.com, jari.arkko@piuha.net, pana@ietf.org Message-id: <20040312175149.GO6749@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, jari.arkko@piuha.net, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040312145901.GD6749@steelhead> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Let me foward my reply which might have failed to send. Yoshihiro Ohba On Fri, Mar 12, 2004 at 06:59:01AM -0800, wrote: > On Tue, Mar 09, 2004 at 03:05:10PM +0200, Dan.Forsberg@nokia.com wrote: > > NAP is connected to ISP(s). I guess NAP could provide WLAN APs, but the ISP the backbone connection. If APs are shared among different ISPs, then ISP selection comes into the picture. I guess the question is how many ISPs could be connected to one NAP? Or what is the definition of NAP and ISP.. and how far does the NAP-ISP border go. Is NAP the as ANP (Access Network Provider)? :) > > > > So, my understanding currently is that I may use NAI like dan@visa.com and when I'm attaching to a NAP it advertises me ISPs that are connected to it, for example htv.fi, teliasonera.fi, and saunalahti.fi. Then I select one, let's say htv.fi and send that selection in the PSA message to the PAA. PAA then sends the AAA request to the htv.fi AAA gw/server, but the destination realm is visa.com. > > If we consider the realm-based routing table in Diameter (section 2.7 > of RFC3588), a PAA node with a single Diameter client might not be > able to support this case, since the routing table does not contain > the chosen ISP information. However, the case can be supported if > multiple Diameter clients are running on the PAA node, where each > Diameter client is dedicated to serve a particular ISP by having a > distinct realm-based routing table. In this case, the PAA can > generate a AAA request and pass it (via internal communication) to the > Diameter client corresponding to htv.fi, and the Diameter client will > take care of generating a Diameter-EAP-Request and forwarding it > towards a Diameter server of visa.com based on the distinct > realm-based routing table for the Diameter client. > > Yoshihiro Ohba > > > > > > - Dan > > > > > -----Original Message----- > > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > > > Jari Arkko > > > Sent: 01 March, 2004 09:21 > > > To: pana@ietf.org > > > Subject: [Pana] the question that I wanted to ask at the mike > > > before the > > > line was cut off... > > > > > > > > > > > > I guess I still don't understand how roaming works in PANA. > > > Currently, Diameter, for instance, works through looking at > > > the NAI at the NAS, and placing this value in the Destination-Realm > > > AVP. All this happens in the NAS. But the NAS doesn't have > > > to have all routing information to the possible realms. Instead, > > > it would typically have a default router to the access provider's > > > proxy or mediating network's proxy which makes the final routing > > > selection. > > > > > > This is simple enough so far, but what's the problem with PANA? > > > The issue is that I don't understand how you can use the > > > ISP-Information > > > at the PANA layer to fill in the Destination-Realm. Or you can use > > > it in the case that the NAS has been configured to recognize the > > > given ISP. But in a typical case the NAS would not be configured with > > > the 1000 different home realms that you can be connected to. So, > > > does PANA limit selected ISP to the ones it has advertised? If yes, > > > then you would have to have all those 1000 ISPs configured in the > > > PANA-enabled NASes. If you try to force one of the few known ISPs > > > (bighome.com) but the user wanted to get to another one > > > (smallandunknownisp.com), things would break, I think. This is because > > > the Destination-Realm would be set to bighome.com whereas you really > > > should have set it to smallandunknownisp.com. In either case > > > the message > > > should be directly sent to the bighome.com AAA server, but this can > > > only route the request further if the Destination-Realm AVP is > > > set correctly. > > > > > > --Jari > > > > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Mar 16 11:07:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08018 for ; Tue, 16 Mar 2004 11:07:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3H5o-00038E-S3; Tue, 16 Mar 2004 11:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3H5n-00037i-F6 for pana@optimus.ietf.org; Tue, 16 Mar 2004 11:06:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07981 for ; Tue, 16 Mar 2004 11:06:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3H5k-0000kO-00 for pana@ietf.org; Tue, 16 Mar 2004 11:06:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3H4p-0000dj-00 for pana@ietf.org; Tue, 16 Mar 2004 11:05:59 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3H3y-0000YI-00 for pana@ietf.org; Tue, 16 Mar 2004 11:05:06 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2GG55KL021289; Wed, 17 Mar 2004 01:05:05 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2GG55Ul000149; Wed, 17 Mar 2004 01:05:05 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA00148 ; Wed, 17 Mar 2004 01:05:05 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA04578; Wed, 17 Mar 2004 01:05:05 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA29448; Wed, 17 Mar 2004 01:05:04 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2GG53b9010120; Wed, 17 Mar 2004 01:05:03 +0900 (JST) Received: from steelhead ([159.119.168.132]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUO00A2IFBZ0D@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 01:05:02 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B1o7p-0002Fp-00; Fri, 12 Mar 2004 06:59:01 -0800 Date: Fri, 12 Mar 2004 06:59:01 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] the question that I wanted to ask at the mike before the line was cut off... In-reply-to: To: Dan.Forsberg@nokia.com Cc: jari.arkko@piuha.net, pana@ietf.org Message-id: <20040312145901.GD6749@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, jari.arkko@piuha.net, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,DATE_IN_PAST_96_XX autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Tue, Mar 09, 2004 at 03:05:10PM +0200, Dan.Forsberg@nokia.com wrote: > NAP is connected to ISP(s). I guess NAP could provide WLAN APs, but the ISP the backbone connection. If APs are shared among different ISPs, then ISP selection comes into the picture. I guess the question is how many ISPs could be connected to one NAP? Or what is the definition of NAP and ISP.. and how far does the NAP-ISP border go. Is NAP the as ANP (Access Network Provider)? :) > > So, my understanding currently is that I may use NAI like dan@visa.com and when I'm attaching to a NAP it advertises me ISPs that are connected to it, for example htv.fi, teliasonera.fi, and saunalahti.fi. Then I select one, let's say htv.fi and send that selection in the PSA message to the PAA. PAA then sends the AAA request to the htv.fi AAA gw/server, but the destination realm is visa.com. If we consider the realm-based routing table in Diameter (section 2.7 of RFC3588), a PAA node with a single Diameter client might not be able to support this case, since the routing table does not contain the chosen ISP information. However, the case can be supported if multiple Diameter clients are running on the PAA node, where each Diameter client is dedicated to serve a particular ISP by having a distinct realm-based routing table. In this case, the PAA can generate a AAA request and pass it (via internal communication) to the Diameter client corresponding to htv.fi, and the Diameter client will take care of generating a Diameter-EAP-Request and forwarding it towards a Diameter server of visa.com based on the distinct realm-based routing table for the Diameter client. Yoshihiro Ohba > > - Dan > > > -----Original Message----- > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > > Jari Arkko > > Sent: 01 March, 2004 09:21 > > To: pana@ietf.org > > Subject: [Pana] the question that I wanted to ask at the mike > > before the > > line was cut off... > > > > > > > > I guess I still don't understand how roaming works in PANA. > > Currently, Diameter, for instance, works through looking at > > the NAI at the NAS, and placing this value in the Destination-Realm > > AVP. All this happens in the NAS. But the NAS doesn't have > > to have all routing information to the possible realms. Instead, > > it would typically have a default router to the access provider's > > proxy or mediating network's proxy which makes the final routing > > selection. > > > > This is simple enough so far, but what's the problem with PANA? > > The issue is that I don't understand how you can use the > > ISP-Information > > at the PANA layer to fill in the Destination-Realm. Or you can use > > it in the case that the NAS has been configured to recognize the > > given ISP. But in a typical case the NAS would not be configured with > > the 1000 different home realms that you can be connected to. So, > > does PANA limit selected ISP to the ones it has advertised? If yes, > > then you would have to have all those 1000 ISPs configured in the > > PANA-enabled NASes. If you try to force one of the few known ISPs > > (bighome.com) but the user wanted to get to another one > > (smallandunknownisp.com), things would break, I think. This is because > > the Destination-Realm would be set to bighome.com whereas you really > > should have set it to smallandunknownisp.com. In either case > > the message > > should be directly sent to the bighome.com AAA server, but this can > > only route the request further if the Destination-Realm AVP is > > set correctly. > > > > --Jari > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Mar 16 11:09:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08168 for ; Tue, 16 Mar 2004 11:09:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3H7p-0003jy-Da for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 11:09:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GG95PE014372 for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 11:09:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3H7p-0003jX-4p for pana-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 11:09:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08128 for ; Tue, 16 Mar 2004 11:09:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3H7m-00014L-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 11:09:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3H6n-0000vF-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 11:08:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3H5s-0000lf-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 11:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3H5o-00038E-S3; Tue, 16 Mar 2004 11:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3H5n-00037i-F6 for pana@optimus.ietf.org; Tue, 16 Mar 2004 11:06:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07981 for ; Tue, 16 Mar 2004 11:06:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3H5k-0000kO-00 for pana@ietf.org; Tue, 16 Mar 2004 11:06:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3H4p-0000dj-00 for pana@ietf.org; Tue, 16 Mar 2004 11:05:59 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3H3y-0000YI-00 for pana@ietf.org; Tue, 16 Mar 2004 11:05:06 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2GG55KL021289; Wed, 17 Mar 2004 01:05:05 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2GG55Ul000149; Wed, 17 Mar 2004 01:05:05 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA00148 ; Wed, 17 Mar 2004 01:05:05 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA04578; Wed, 17 Mar 2004 01:05:05 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA29448; Wed, 17 Mar 2004 01:05:04 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2GG53b9010120; Wed, 17 Mar 2004 01:05:03 +0900 (JST) Received: from steelhead ([159.119.168.132]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUO00A2IFBZ0D@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 01:05:02 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B1o7p-0002Fp-00; Fri, 12 Mar 2004 06:59:01 -0800 Date: Fri, 12 Mar 2004 06:59:01 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] the question that I wanted to ask at the mike before the line was cut off... In-reply-to: To: Dan.Forsberg@nokia.com Cc: jari.arkko@piuha.net, pana@ietf.org Message-id: <20040312145901.GD6749@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, jari.arkko@piuha.net, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,DATE_IN_PAST_96_XX autolearn=no version=2.60 On Tue, Mar 09, 2004 at 03:05:10PM +0200, Dan.Forsberg@nokia.com wrote: > NAP is connected to ISP(s). I guess NAP could provide WLAN APs, but the ISP the backbone connection. If APs are shared among different ISPs, then ISP selection comes into the picture. I guess the question is how many ISPs could be connected to one NAP? Or what is the definition of NAP and ISP.. and how far does the NAP-ISP border go. Is NAP the as ANP (Access Network Provider)? :) > > So, my understanding currently is that I may use NAI like dan@visa.com and when I'm attaching to a NAP it advertises me ISPs that are connected to it, for example htv.fi, teliasonera.fi, and saunalahti.fi. Then I select one, let's say htv.fi and send that selection in the PSA message to the PAA. PAA then sends the AAA request to the htv.fi AAA gw/server, but the destination realm is visa.com. If we consider the realm-based routing table in Diameter (section 2.7 of RFC3588), a PAA node with a single Diameter client might not be able to support this case, since the routing table does not contain the chosen ISP information. However, the case can be supported if multiple Diameter clients are running on the PAA node, where each Diameter client is dedicated to serve a particular ISP by having a distinct realm-based routing table. In this case, the PAA can generate a AAA request and pass it (via internal communication) to the Diameter client corresponding to htv.fi, and the Diameter client will take care of generating a Diameter-EAP-Request and forwarding it towards a Diameter server of visa.com based on the distinct realm-based routing table for the Diameter client. Yoshihiro Ohba > > - Dan > > > -----Original Message----- > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > > Jari Arkko > > Sent: 01 March, 2004 09:21 > > To: pana@ietf.org > > Subject: [Pana] the question that I wanted to ask at the mike > > before the > > line was cut off... > > > > > > > > I guess I still don't understand how roaming works in PANA. > > Currently, Diameter, for instance, works through looking at > > the NAI at the NAS, and placing this value in the Destination-Realm > > AVP. All this happens in the NAS. But the NAS doesn't have > > to have all routing information to the possible realms. Instead, > > it would typically have a default router to the access provider's > > proxy or mediating network's proxy which makes the final routing > > selection. > > > > This is simple enough so far, but what's the problem with PANA? > > The issue is that I don't understand how you can use the > > ISP-Information > > at the PANA layer to fill in the Destination-Realm. Or you can use > > it in the case that the NAS has been configured to recognize the > > given ISP. But in a typical case the NAS would not be configured with > > the 1000 different home realms that you can be connected to. So, > > does PANA limit selected ISP to the ones it has advertised? If yes, > > then you would have to have all those 1000 ISPs configured in the > > PANA-enabled NASes. If you try to force one of the few known ISPs > > (bighome.com) but the user wanted to get to another one > > (smallandunknownisp.com), things would break, I think. This is because > > the Destination-Realm would be set to bighome.com whereas you really > > should have set it to smallandunknownisp.com. In either case > > the message > > should be directly sent to the bighome.com AAA server, but this can > > only route the request further if the Destination-Realm AVP is > > set correctly. > > > > --Jari > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Mar 16 11:09:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08167 for ; Tue, 16 Mar 2004 11:09:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3H7o-0003jR-GC for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 11:09:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GG94Gd014341 for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 11:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3H7o-0003jE-7G for pana-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 11:09:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08125 for ; Tue, 16 Mar 2004 11:08:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3H7l-00014G-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 11:09:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3H6m-0000v7-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 11:08:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3H5s-0000le-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 11:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3H5o-000385-FJ; Tue, 16 Mar 2004 11:07:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3H5b-00037C-BQ for pana@optimus.ietf.org; Tue, 16 Mar 2004 11:06:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07975 for ; Tue, 16 Mar 2004 11:06:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3H5Y-0000if-00 for pana@ietf.org; Tue, 16 Mar 2004 11:06:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3H4h-0000ce-00 for pana@ietf.org; Tue, 16 Mar 2004 11:05:52 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3H3p-0000Wy-00 for pana@ietf.org; Tue, 16 Mar 2004 11:04:58 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2GG4tKL021158; Wed, 17 Mar 2004 01:04:55 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2GG4tt1000044; Wed, 17 Mar 2004 01:04:55 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA00043 ; Wed, 17 Mar 2004 01:04:55 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA04414; Wed, 17 Mar 2004 01:04:54 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA28794; Wed, 17 Mar 2004 01:04:54 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2GG4rb9009956; Wed, 17 Mar 2004 01:04:53 +0900 (JST) Received: from steelhead ([159.119.168.132]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUO00A2IFBZ0D@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 01:04:52 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B1qp3-0002TO-00; Fri, 12 Mar 2004 09:51:49 -0800 Date: Fri, 12 Mar 2004 09:51:49 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] the question that I wanted to ask at the mike before the line was cut off... In-reply-to: <20040312145901.GD6749@steelhead> To: Dan.Forsberg@nokia.com, jari.arkko@piuha.net, pana@ietf.org Message-id: <20040312175149.GO6749@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, jari.arkko@piuha.net, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040312145901.GD6749@steelhead> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Let me foward my reply which might have failed to send. Yoshihiro Ohba On Fri, Mar 12, 2004 at 06:59:01AM -0800, wrote: > On Tue, Mar 09, 2004 at 03:05:10PM +0200, Dan.Forsberg@nokia.com wrote: > > NAP is connected to ISP(s). I guess NAP could provide WLAN APs, but the ISP the backbone connection. If APs are shared among different ISPs, then ISP selection comes into the picture. I guess the question is how many ISPs could be connected to one NAP? Or what is the definition of NAP and ISP.. and how far does the NAP-ISP border go. Is NAP the as ANP (Access Network Provider)? :) > > > > So, my understanding currently is that I may use NAI like dan@visa.com and when I'm attaching to a NAP it advertises me ISPs that are connected to it, for example htv.fi, teliasonera.fi, and saunalahti.fi. Then I select one, let's say htv.fi and send that selection in the PSA message to the PAA. PAA then sends the AAA request to the htv.fi AAA gw/server, but the destination realm is visa.com. > > If we consider the realm-based routing table in Diameter (section 2.7 > of RFC3588), a PAA node with a single Diameter client might not be > able to support this case, since the routing table does not contain > the chosen ISP information. However, the case can be supported if > multiple Diameter clients are running on the PAA node, where each > Diameter client is dedicated to serve a particular ISP by having a > distinct realm-based routing table. In this case, the PAA can > generate a AAA request and pass it (via internal communication) to the > Diameter client corresponding to htv.fi, and the Diameter client will > take care of generating a Diameter-EAP-Request and forwarding it > towards a Diameter server of visa.com based on the distinct > realm-based routing table for the Diameter client. > > Yoshihiro Ohba > > > > > > - Dan > > > > > -----Original Message----- > > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > > > Jari Arkko > > > Sent: 01 March, 2004 09:21 > > > To: pana@ietf.org > > > Subject: [Pana] the question that I wanted to ask at the mike > > > before the > > > line was cut off... > > > > > > > > > > > > I guess I still don't understand how roaming works in PANA. > > > Currently, Diameter, for instance, works through looking at > > > the NAI at the NAS, and placing this value in the Destination-Realm > > > AVP. All this happens in the NAS. But the NAS doesn't have > > > to have all routing information to the possible realms. Instead, > > > it would typically have a default router to the access provider's > > > proxy or mediating network's proxy which makes the final routing > > > selection. > > > > > > This is simple enough so far, but what's the problem with PANA? > > > The issue is that I don't understand how you can use the > > > ISP-Information > > > at the PANA layer to fill in the Destination-Realm. Or you can use > > > it in the case that the NAS has been configured to recognize the > > > given ISP. But in a typical case the NAS would not be configured with > > > the 1000 different home realms that you can be connected to. So, > > > does PANA limit selected ISP to the ones it has advertised? If yes, > > > then you would have to have all those 1000 ISPs configured in the > > > PANA-enabled NASes. If you try to force one of the few known ISPs > > > (bighome.com) but the user wanted to get to another one > > > (smallandunknownisp.com), things would break, I think. This is because > > > the Destination-Realm would be set to bighome.com whereas you really > > > should have set it to smallandunknownisp.com. In either case > > > the message > > > should be directly sent to the bighome.com AAA server, but this can > > > only route the request further if the Destination-Realm AVP is > > > set correctly. > > > > > > --Jari > > > > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Mar 16 18:46:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06084 for ; Tue, 16 Mar 2004 18:46:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OG1-0003fe-Dx; Tue, 16 Mar 2004 18:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OF3-0003eu-Gs for pana@optimus.ietf.org; Tue, 16 Mar 2004 18:45:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06036 for ; Tue, 16 Mar 2004 18:44:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3OF0-0004jq-00 for pana@ietf.org; Tue, 16 Mar 2004 18:44:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3OE4-0004fV-00 for pana@ietf.org; Tue, 16 Mar 2004 18:44:02 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3ODW-0004bY-00 for pana@ietf.org; Tue, 16 Mar 2004 18:43:27 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2GNhFKL007697; Wed, 17 Mar 2004 08:43:15 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2GNhFa5013239; Wed, 17 Mar 2004 08:43:15 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA13238 ; Wed, 17 Mar 2004 08:43:15 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA22709; Wed, 17 Mar 2004 08:43:15 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA24774; Wed, 17 Mar 2004 08:43:14 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2GNhDb9016668; Wed, 17 Mar 2004 08:43:14 +0900 (JST) Received: from steelhead ([159.119.168.132]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUP00MJR0JU2E@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 08:43:12 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3Nbq-0003cV-00; Tue, 16 Mar 2004 15:04:30 -0800 Date: Tue, 16 Mar 2004 15:04:30 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040316230430.GE13346@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] issue 52: proposed text Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , This is a new text for issue 52 (details of double authentication). Please input your comments. Summary on changes ------------------ o When separate NAP and ISP authentications are performed and two AAA-Keys are derived, one from NAP authentication and the other from ISP authentication, the PANA-MAC-Key is computed based on the two AAA-Keys (i.e., compound key). o New PANA messages PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages are introduced. The new messages are used at the end of the first EAP authentication (instead of PANA-Bind-Request/Answer) when the PaC and PAA negotiated to perform separate NAP and ISP authentications. o The PaC and PAA can choose not to perform the second EAP authentication when they negotiated to perform separate NAP and ISP authentications, but the first EAP authentication has failed. S-flag is reused for this purpose. Changes ------- - In order to support compound MAC key when separate NAP and ISP authentications are performed, change the first paragraph in section 4.1.5: "A PANA SA is created as an attribute of a PANA session when EAP authentication succeeds with a creation of a AAA-Key. A PANA SA is not created when the PANA authentication fails or no AAA-Key is produced by any EAP authentication method. In the case where two EAP authentications are performed in a sequence in a single PANA authentication, it is possible that two AAA-Keys are derived. If this happens, the PANA SA MUST be bound to the AAA-Key derived from the first EAP authentication. When a new AAA-Key is derived as a result of EAP-based re-authentication, any key derived from the old AAA-Key MUST be updated to a new one that is derived from the new AAA-Key. In order to distinguish the new AAA-Key from old ones, one Key-Id AVP MUST be carried in PANA-Bind-Request and PANA-Bind-Answer message at the end of the authentication phase which resulted in deriving a new AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a value that uniquely identifies the AAA-Key within the PANA session. The PANA-Bind-Answer message sent in response to a PANA-Bind-Request with a Key-Id AVP MUST contain a Key-Id AVP with the same AAA-Key identifier carried in the request. PANA-Bind-Request and PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC AVP whose value is computed by using the new AAA-Key. Although the specification does not mandate a particular method for calculation of Key-Id AVP value, a simple method is to use monotonically increasing numbers." to: "A PANA SA is created as an attribute of a PANA session when EAP authentication succeeds with a creation of a AAA-Key. A PANA SA is not created when the PANA authentication fails or no AAA-Key is produced by any EAP authentication method. In the case where two EAP authentications are performed in sequence in a single PANA authentication phase, it is possible that two AAA-Keys are derived. If this happens, the PANA SA MUST be bound to both AAA-Keys. When a new AAA-Key is derived as a result of EAP-based re-authentication, any key derived from the old AAA-Key MUST be updated to a new one that is derived from the new AAA-Key. In order to distinguish the new AAA-Key from old ones, one Key-Id AVP MUST be carried in PANA-Bind-Request and PANA-Bind-Answer messages or PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages at the end of the EAP authentication which resulted in deriving a new AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a value that uniquely identifies the AAA-Key within the PANA session. The PANA-Bind-Answer message (or the PANA-FirstAuth-End-Answer message) sent in response to a PANA-Bind-Request message (or a PANA-FirstAuth-End-Request message) with a Key-Id AVP MUST contain a Key-Id AVP with the same AAA-Key identifier carried in the request. PANA-Bind-Request, PANA-Bind-Answer, PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages with a Key-Id AVP MUST also carry a MAC AVP whose value is computed by using the new PANA-MAC-Key derived from the new AAA-Key (or the new pair of AAA-Keys when the PANA SA is bound to two AAA-Keys). Although the specification does not mandate a particular method for calculation of Key-Id AVP value, a simple method is to use monotonically increasing numbers." - In order to support compound MAC key when separate NAP and ISP authentications are performed, change the following paragraphs in section 4.1.5. " The PANA_MAC_Key is used to integrity protect PANA messages and derived from the AAA-Key in the following way: PANA_MAC_KEY = The first N bits of HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID) where the value of N depends on the integrity protection algorithm in use, i.e., N=160 for HMAC-SHA1. The length of AAA-Key MUST be N bits or longer. See Section 4.1.6 for the detailed usage of the PANA_MAC_Key. " to: The PANA_MAC_Key is used to integrity protect PANA messages. When the PANA_MAC_Key is derived from a single AAA-Key, it is computed in the following way: PANA_MAC_KEY = The first N bits of HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID) where the value of N depends on the integrity protection algorithm in use, i.e., N=160 for HMAC-SHA1. When the PANA_MAC_Key is derived from two AAA-Keys, it is computed in the following way: PANA_MAC_KEY = The first N bits of HMAC_SHA1(AAA-Key1, AAA-Key2, ISN_pac | ISN_paa | Session-ID) where AAA-Key1 and AAA-Key2 are AAA-Keys for the first and second EAP authentication in a single PANA authentication phase, respectively. The length of AAA-Key, AAA-Key1 and AAA-Key2 MUST be N bits or longer. See Section 4.1.6 and Section 4.3 for the detailed usage of the PANA_MAC_Key. " - In order to clarify that ISP-Information AVP can be included in PSA message even if PAA does not contain any ISP-Information AVP in PSR message, add the following paragraph in section 4.2: "The PaC can still choose an ISP and contain an ISP-Information AVP for the chosen ISP in a PANA-Start-Answer message even when there is no ISP-Information AVP contained in the PANA-Start-Request message." - In order to clarify that PSR message does not contain EAP Request while negotiating on performing separate authentication for NAP and ISP, change the following paragraphs in section 4.2 from: " When a Cookie-AVP is carried in a PANA-Start-Request message, the initial EAP Request MUST NOT be carried in the PANA-Start-Request message in order for the PAA to be stateless. When a Cookie-AVP is not carried in a PANA-Start-Request message, the PAA does not need to be stateless. In this case, the initial EAP Request message MAY be carried in the PANA-Start-Request message. If the initial EAP Request message is carried in the PANA-Start-Request message, an EAP Response message MUST be carried in the PANA-Start-Answer message returned to the PAA. " to: " When a Cookie-AVP is carried in a PANA-Start-Request message, the initial EAP Request MUST NOT be carried in the PANA-Start-Request message in order for the PAA to be stateless. When a Cookie-AVP is not carried in a PANA-Start-Request message, the PAA does not need to be stateless. In this case, the initial EAP Request message MAY be carried in the PANA-Start-Request message. When the S-flag is set in a PANA-Start-Request message, the initial EAP Request MUST NOT be carried in the PANA-Start-Request message. (If the initial EAP Request were contained in the PANA-Start-Request message during the S-flag negotiation, the PaC cannot tell whether the EAP Request is for NAP authentication or ISP authentication.) If the initial EAP Request message is carried in the PANA-Start-Request message, an EAP Response message MUST be carried in the PANA-Start-Answer message returned to the PAA. " Rewrite Section 4.3 as follows: 4.3 Authentication Phase The main task in authentication phase is to carry EAP messages between PaC and PAA. EAP Request messages are carried in PANA- Auth-Request messages and optionally carried in PANA-Start-Request messages. EAP Response messages are carried in PANA-Auth-Answer messages and optionally carried in PANA-Start-Answer messages. When an EAP Success/Failure message is sent from a PAA, the message is carried in a PANA-Bind-Request (PBR) or PANA-FirstAuth-End-Request (PFER) message. The PANA-FirstAuth-End-Reques message MUST be used at the end of the first EAP when the PaC and PAA have negotiated during the discovery and initial handshake phase to perform separate NAP and ISP authentications in a single PANA authentication phase. Otherwise, the PANA-Bind-Request message MUST be used. The PANA-Bind-Request and PANA-FirstAuth-End-Request messages MUST be acknowledged with a PANA-Bind-Answer (PBA) and a PANA-FirstAuth-End-Answer (PFEA) messages, respectively. When the PaC and PAA have negotiated during the discovery and initial handshake phase to perform separate NAP and ISP authentications, the S-flag of PANA-Auth-Request and PANA-Auth-Answer messages MUST be set. Otherwise, the S-flag MUST NOT be set. When separate NAP and ISP authentications are performed, the PAA determines the execution order of NAP authentication and ISP authentication. In this case, the PAA can indicate which EAP authentication is currently occurring by including a NAP-Information or an ISP-Information AVP of the corresponding EAP authentication in the first PANA-Auth-Request message sent to the PaC. In the case where the PaC agreed to perform separate authentications but did not specify its ISP choice in PANA-Start-Answer message, the PAA MUST include its NAP-Information AVP in PANA-Auth-Request message when it performs NAP authentication and MUST NOT include any service provider information AVP when it performs ISP authentication so that the PaC can always distinguish ISP authentication from NAP authentication. The PAA SHOULD stop including a NAP-Information or an ISP-Information AVP once it receives the first PANA-Auth-Answer message of the current EAP authentication. When separate NAP and ISP authentications are performed, if the first EAP authentication has failed, the PAA can choose not to perform the second EAP authentication by clearing the S-flag of the PANA-FirstAuth-End-Request message. In this case, the S-flag of the PANA-FirstAuth-End-Answer message sent by the PaC MUST be cleared. If the S-flag of the PANA-FirstAuth-End-Request message is set when the first EAP authentication has failed, the PaC can choose not to perform the second EAP authentication by clearing the S-flag of the PANA-FirstAuth-End-Answer message. If the first EAP authentication failed and the S-flag is not set in the PANA-FirstAuth-End-Answer message as a result of those operations, the PANA session MUST be immediately deleted. Otherwise, the second EAP authentication MUST be performed. Currently, use of multiple EAP methods in PANA is designed only for NAP-ISP authentication separation. It is not for arbitrary EAP method sequencing, or giving the PaC another chance when an authentication method fails. The NAP and ISP authentication are considered completely independent. Presence or success of one should not effect the other. Making an authentication decision based on the success or failure of each authentication is a network policy issue. PANA signals only the result of the immediately preceding EAP authentication method in PANA-Bind-Request messages. When an EAP method that is capable of deriving keys is used during the authentication phase and the keys are successfully derived, the PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer and/or PANA-Bind-Request and PANA-Bind-Answer messages, and all subsequent PANA messages MUST contain a MAC AVP. When separate NAP and ISP authentications are performed and the lower-layer is insecure, the two EAP methods MUST be capable of deriving keys. In this case, if the first EAP authentication is successful, the PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages as well as PANA-Auth-Request and PANA-Auth-Answer messages in the second EAP authentication MUST be protected with the key derived from the AAA-Key for the first EAP authentication. The PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent PANA messages MUST be protected either with the AAA-Key for the first EAP authentication if the first EAP authentication succeeds and the second EAP authentication fails, or with the AAA-Key for the second EAP authentication if the first EAP authentication fails and the second EAP authentication succeeds, or with the compound key derived from the two AAA-Keys, one for the first EAP authentication and the other from the second EAP authentication, if both the first and second EAP authentications succeed (see section 4.1.5 how the compound key is derived). The PANA-Bind-Request and the PANA-Bind-Answer message exchange is also used for binding device identifiers of the PaC and the PAA to the PANA SA. To achieve this, the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a device identifier of the PAA and the PaC, respectively, in a Device-Id AVP. The PaC MUST use the same type of device identifier as contained in the PANA-Bind-Request message. The PANA-Bind-Request message MAY also contain a Protection-Capability AVP to indicate if link-layer or network-layer ciphering should be initiated after PANA. No link layer or network layer specific information is included in the Protection-Capability AVP. When the information is preconfigured on the PaC and the PAA this AVP can be omitted. It is assumed that at least PAA is aware of the security capabilities of the access network. The PANA protocol does not specify how the PANA SA and the Protection-Capability AVP will be used to provide per-packet protection for data traffic. PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted based on the retransmission rule described in Appendix A. Add the following example in section 4.6: " Another PANA message sequence is illustrated in Figure X. The example assumes the following scenario: o PaC multicasts PANA-PAA-Discover message o The ISNs used by the PAA and the PaC are x and y, respectively. o PAA offers NAP and ISP separate authentication, as well as a choice of ISP from "ISP1" and "ISP2". o PaC accepts the offer from PAA, with choosing "ISP1" as the ISP. o An EAP sequence for NAP authentication and an EAP sequence for ISP authentication is performed in this order in authentication phase. o An EAP authentication method with a single round trip is used in each of EAP sequence. o The EAP authentication methods derive keys. Once the two EAP authenticatioins are successful, the PANA SA is bound to the two AAA-Keys. o After PANA SA is established, all messages are integrity and replay protected with the MAC AVP. o Re-authentication and termination phase are not shown. PaC PAA Message(tseq,rseq)[AVPs] ----------------------------------------------------- // Discovery and initial handshake phase -----> PANA-PAA-Discover (0,0) <----- PANA-Start-Request (x,0) // S-flag set [Cookie, ISP-Information("ISP1"), ISP-Information("ISP2"), NAP-Information("MyNAP")] -----> PANA-Start-Request-Answer (y,x) // S-flag set [Cookie, ISP-Information("ISP1")] // PaC chooses "ISP1" // Authentication phase <----- PANA-Auth-Request(x+1,y) // NAP authentication [EAP, NAP-Information("MyNAP")] // S-flag set -----> PANA-Auth-Answer(y+1,x+1)[EAP] // S-flag set <----- PANA-Auth-Request(x+2,y+1)[EAP] // S-flag set -----> PANA-Auth-Answer(y+2,x+2)[EAP] // S-flag set <----- PANA-FirstAuth-End-Request(x+3,y+2) // S-flag set [EAP{Success}, Key-Id, MAC] -----> PANA-FirstAuth-End-Answer(y+3,x+3)[Key-Id, MAC] // S-flag set <----- PANA-Auth-Request(x+3,y+4) // ISP authentication [EAP, ISP-Information("ISP1")] // S-flag set -----> PANA-Auth-Answer(y+4,x+4)[EAP] // S-flag set <----- PANA-Auth-Request(x+4,y+5)[EAP] // S-flag set -----> PANA-Auth-Answer(y+5,x+5)[EAP] // S-flag set <----- PANA-Bind-Request(x+5,y+6) // S-flag set [EAP{Success}, Device-Id, Key-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+6,x+5) // S-flag set [Device-Id, Key-Id, Protection-Cap., MAC] Figure X: A Message Sequence for NAP and ISP Separate Authentication " Change the following paragraph in section 9.1: " S(eparate) When the S-flag is set in a PANA-Start-Request message it indicates that PAA is willing to offer separate EAP authentication for NAP and ISP. When the S-flag is set in a PANA-Start-Answer message it indicates that PaC accepts on performing separate EAP authentication for NAP and ISP. " to: " S(eparate) When the S-flag is set in a PANA-Start-Request message it indicates that PAA is willing to offer separate EAP authentications for NAP and ISP. When the S-flag is set in a PANA-Start-Answer message it indicates that PaC accepts on performing separate EAP authentications for NAP and ISP. When the S-flag is set in a PANA-Auth-Request/Answer, PANA-FirstAuth-End-Request/Answer and PANA-Bind-Request/Answer messages it indicates that separate authentications are being performed in the authentication phase. " - Change Figure 9 as follows: " Message Direction: PaC---PAA ------------------------------------- PANA-PAA-Discover --------> PANA-Start-Request <-------- PANA-Start-Answer --------> PANA-Auth-Request <-------- PANA-Auth-Answer --------> PANA-FirstAuth-End-Request <-------- PANA-FirstAuth-End-Answer --------> PANA-Bind-Request <-------- PANA-Bind-Answer --------> PANA-Reauth-Request <-------> PANA-Reauth-Answer <-------> PANA-Termination-Request <-------> PANA-Termination-Answer <-------> PANA-Error <-------> " Add the following two sections: "9.3.X PANA-FirstAuth-End-Request (PFER) PANA-FirstAuth-End-Request (PFER) is sent by the PAA to the PaC. PANA-FirstAuth-End-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } [ Key-Id ] * [ AVP ] 0*1 < MAC > 9.3.Y PANA-FirstAuth-End-Answer (PFEA) PANA-FirstAuth-End-Answer (PFEA) is sent by the PaC to the PAA in response to a PANA-FirstAuth-End-Request message. PANA-FirstAuth-End--Answer ::= < PANA-Header: 4 > < Session-Id > < Device-Id > [ Key-Id ] * [ AVP ] 0*1 < MAC > " - Change the AVP occurrence table as follows: " +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0-1 | Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 | Protection-Cap. | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | Session-Lifetime | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ISP-Information | 0+ | 0-1 | 0-1 | 0 | 0 | 0 | 0 | NAP-Information | 0-1 | 0 | 0-1 | 0 | 0 | 0 | 0 | EP-Device-Id | 0 | 0 | 0 | 0 | 0+ | 0 | 0 | Key-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 | --------------------+-----+-----+-----+-----+-----+-----+-----+ +---------------------------------------------+ | Message | | Type | +------+------+-----+-----+-----+------+------+ Attribute Name | PRAR | PRAA | PTR | PTA | PER | PFER | PFEA | --------------------+------+------+-----+-----+-----+------+------+ Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 | Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1 | Termination-Cause | 0 | 0 | 1 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 0 | 0 | 0 | 1 | 0 | MAC | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | Device-Id | 1+ | 1+ | 0 | 0 | 0 | 0 | 0 | Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 1 | 0 | 0 | ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EP-Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Key-Id | 0 | 0 | 0 | 0 | 0 | 0-1 | 0-1 | --------------------+------+------+-----+-----+-----+------+------+ " Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Mar 16 18:48:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06155 for ; Tue, 16 Mar 2004 18:48:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OIG-0003m9-G7 for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 18:48:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GNmKRD014506 for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 18:48:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OIG-0003ls-6h for pana-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 18:48:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06134 for ; Tue, 16 Mar 2004 18:48:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3OID-00055Z-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 18:48:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3OGw-0004uG-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 18:47:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3OG2-0004pM-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 18:46:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OG1-0003fe-Dx; Tue, 16 Mar 2004 18:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OF3-0003eu-Gs for pana@optimus.ietf.org; Tue, 16 Mar 2004 18:45:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06036 for ; Tue, 16 Mar 2004 18:44:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3OF0-0004jq-00 for pana@ietf.org; Tue, 16 Mar 2004 18:44:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3OE4-0004fV-00 for pana@ietf.org; Tue, 16 Mar 2004 18:44:02 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3ODW-0004bY-00 for pana@ietf.org; Tue, 16 Mar 2004 18:43:27 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2GNhFKL007697; Wed, 17 Mar 2004 08:43:15 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2GNhFa5013239; Wed, 17 Mar 2004 08:43:15 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA13238 ; Wed, 17 Mar 2004 08:43:15 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA22709; Wed, 17 Mar 2004 08:43:15 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA24774; Wed, 17 Mar 2004 08:43:14 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2GNhDb9016668; Wed, 17 Mar 2004 08:43:14 +0900 (JST) Received: from steelhead ([159.119.168.132]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUP00MJR0JU2E@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 08:43:12 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3Nbq-0003cV-00; Tue, 16 Mar 2004 15:04:30 -0800 Date: Tue, 16 Mar 2004 15:04:30 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040316230430.GE13346@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i Subject: [Pana] issue 52: proposed text Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a new text for issue 52 (details of double authentication). Please input your comments. Summary on changes ------------------ o When separate NAP and ISP authentications are performed and two AAA-Keys are derived, one from NAP authentication and the other from ISP authentication, the PANA-MAC-Key is computed based on the two AAA-Keys (i.e., compound key). o New PANA messages PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages are introduced. The new messages are used at the end of the first EAP authentication (instead of PANA-Bind-Request/Answer) when the PaC and PAA negotiated to perform separate NAP and ISP authentications. o The PaC and PAA can choose not to perform the second EAP authentication when they negotiated to perform separate NAP and ISP authentications, but the first EAP authentication has failed. S-flag is reused for this purpose. Changes ------- - In order to support compound MAC key when separate NAP and ISP authentications are performed, change the first paragraph in section 4.1.5: "A PANA SA is created as an attribute of a PANA session when EAP authentication succeeds with a creation of a AAA-Key. A PANA SA is not created when the PANA authentication fails or no AAA-Key is produced by any EAP authentication method. In the case where two EAP authentications are performed in a sequence in a single PANA authentication, it is possible that two AAA-Keys are derived. If this happens, the PANA SA MUST be bound to the AAA-Key derived from the first EAP authentication. When a new AAA-Key is derived as a result of EAP-based re-authentication, any key derived from the old AAA-Key MUST be updated to a new one that is derived from the new AAA-Key. In order to distinguish the new AAA-Key from old ones, one Key-Id AVP MUST be carried in PANA-Bind-Request and PANA-Bind-Answer message at the end of the authentication phase which resulted in deriving a new AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a value that uniquely identifies the AAA-Key within the PANA session. The PANA-Bind-Answer message sent in response to a PANA-Bind-Request with a Key-Id AVP MUST contain a Key-Id AVP with the same AAA-Key identifier carried in the request. PANA-Bind-Request and PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC AVP whose value is computed by using the new AAA-Key. Although the specification does not mandate a particular method for calculation of Key-Id AVP value, a simple method is to use monotonically increasing numbers." to: "A PANA SA is created as an attribute of a PANA session when EAP authentication succeeds with a creation of a AAA-Key. A PANA SA is not created when the PANA authentication fails or no AAA-Key is produced by any EAP authentication method. In the case where two EAP authentications are performed in sequence in a single PANA authentication phase, it is possible that two AAA-Keys are derived. If this happens, the PANA SA MUST be bound to both AAA-Keys. When a new AAA-Key is derived as a result of EAP-based re-authentication, any key derived from the old AAA-Key MUST be updated to a new one that is derived from the new AAA-Key. In order to distinguish the new AAA-Key from old ones, one Key-Id AVP MUST be carried in PANA-Bind-Request and PANA-Bind-Answer messages or PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages at the end of the EAP authentication which resulted in deriving a new AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a value that uniquely identifies the AAA-Key within the PANA session. The PANA-Bind-Answer message (or the PANA-FirstAuth-End-Answer message) sent in response to a PANA-Bind-Request message (or a PANA-FirstAuth-End-Request message) with a Key-Id AVP MUST contain a Key-Id AVP with the same AAA-Key identifier carried in the request. PANA-Bind-Request, PANA-Bind-Answer, PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages with a Key-Id AVP MUST also carry a MAC AVP whose value is computed by using the new PANA-MAC-Key derived from the new AAA-Key (or the new pair of AAA-Keys when the PANA SA is bound to two AAA-Keys). Although the specification does not mandate a particular method for calculation of Key-Id AVP value, a simple method is to use monotonically increasing numbers." - In order to support compound MAC key when separate NAP and ISP authentications are performed, change the following paragraphs in section 4.1.5. " The PANA_MAC_Key is used to integrity protect PANA messages and derived from the AAA-Key in the following way: PANA_MAC_KEY = The first N bits of HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID) where the value of N depends on the integrity protection algorithm in use, i.e., N=160 for HMAC-SHA1. The length of AAA-Key MUST be N bits or longer. See Section 4.1.6 for the detailed usage of the PANA_MAC_Key. " to: The PANA_MAC_Key is used to integrity protect PANA messages. When the PANA_MAC_Key is derived from a single AAA-Key, it is computed in the following way: PANA_MAC_KEY = The first N bits of HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID) where the value of N depends on the integrity protection algorithm in use, i.e., N=160 for HMAC-SHA1. When the PANA_MAC_Key is derived from two AAA-Keys, it is computed in the following way: PANA_MAC_KEY = The first N bits of HMAC_SHA1(AAA-Key1, AAA-Key2, ISN_pac | ISN_paa | Session-ID) where AAA-Key1 and AAA-Key2 are AAA-Keys for the first and second EAP authentication in a single PANA authentication phase, respectively. The length of AAA-Key, AAA-Key1 and AAA-Key2 MUST be N bits or longer. See Section 4.1.6 and Section 4.3 for the detailed usage of the PANA_MAC_Key. " - In order to clarify that ISP-Information AVP can be included in PSA message even if PAA does not contain any ISP-Information AVP in PSR message, add the following paragraph in section 4.2: "The PaC can still choose an ISP and contain an ISP-Information AVP for the chosen ISP in a PANA-Start-Answer message even when there is no ISP-Information AVP contained in the PANA-Start-Request message." - In order to clarify that PSR message does not contain EAP Request while negotiating on performing separate authentication for NAP and ISP, change the following paragraphs in section 4.2 from: " When a Cookie-AVP is carried in a PANA-Start-Request message, the initial EAP Request MUST NOT be carried in the PANA-Start-Request message in order for the PAA to be stateless. When a Cookie-AVP is not carried in a PANA-Start-Request message, the PAA does not need to be stateless. In this case, the initial EAP Request message MAY be carried in the PANA-Start-Request message. If the initial EAP Request message is carried in the PANA-Start-Request message, an EAP Response message MUST be carried in the PANA-Start-Answer message returned to the PAA. " to: " When a Cookie-AVP is carried in a PANA-Start-Request message, the initial EAP Request MUST NOT be carried in the PANA-Start-Request message in order for the PAA to be stateless. When a Cookie-AVP is not carried in a PANA-Start-Request message, the PAA does not need to be stateless. In this case, the initial EAP Request message MAY be carried in the PANA-Start-Request message. When the S-flag is set in a PANA-Start-Request message, the initial EAP Request MUST NOT be carried in the PANA-Start-Request message. (If the initial EAP Request were contained in the PANA-Start-Request message during the S-flag negotiation, the PaC cannot tell whether the EAP Request is for NAP authentication or ISP authentication.) If the initial EAP Request message is carried in the PANA-Start-Request message, an EAP Response message MUST be carried in the PANA-Start-Answer message returned to the PAA. " Rewrite Section 4.3 as follows: 4.3 Authentication Phase The main task in authentication phase is to carry EAP messages between PaC and PAA. EAP Request messages are carried in PANA- Auth-Request messages and optionally carried in PANA-Start-Request messages. EAP Response messages are carried in PANA-Auth-Answer messages and optionally carried in PANA-Start-Answer messages. When an EAP Success/Failure message is sent from a PAA, the message is carried in a PANA-Bind-Request (PBR) or PANA-FirstAuth-End-Request (PFER) message. The PANA-FirstAuth-End-Reques message MUST be used at the end of the first EAP when the PaC and PAA have negotiated during the discovery and initial handshake phase to perform separate NAP and ISP authentications in a single PANA authentication phase. Otherwise, the PANA-Bind-Request message MUST be used. The PANA-Bind-Request and PANA-FirstAuth-End-Request messages MUST be acknowledged with a PANA-Bind-Answer (PBA) and a PANA-FirstAuth-End-Answer (PFEA) messages, respectively. When the PaC and PAA have negotiated during the discovery and initial handshake phase to perform separate NAP and ISP authentications, the S-flag of PANA-Auth-Request and PANA-Auth-Answer messages MUST be set. Otherwise, the S-flag MUST NOT be set. When separate NAP and ISP authentications are performed, the PAA determines the execution order of NAP authentication and ISP authentication. In this case, the PAA can indicate which EAP authentication is currently occurring by including a NAP-Information or an ISP-Information AVP of the corresponding EAP authentication in the first PANA-Auth-Request message sent to the PaC. In the case where the PaC agreed to perform separate authentications but did not specify its ISP choice in PANA-Start-Answer message, the PAA MUST include its NAP-Information AVP in PANA-Auth-Request message when it performs NAP authentication and MUST NOT include any service provider information AVP when it performs ISP authentication so that the PaC can always distinguish ISP authentication from NAP authentication. The PAA SHOULD stop including a NAP-Information or an ISP-Information AVP once it receives the first PANA-Auth-Answer message of the current EAP authentication. When separate NAP and ISP authentications are performed, if the first EAP authentication has failed, the PAA can choose not to perform the second EAP authentication by clearing the S-flag of the PANA-FirstAuth-End-Request message. In this case, the S-flag of the PANA-FirstAuth-End-Answer message sent by the PaC MUST be cleared. If the S-flag of the PANA-FirstAuth-End-Request message is set when the first EAP authentication has failed, the PaC can choose not to perform the second EAP authentication by clearing the S-flag of the PANA-FirstAuth-End-Answer message. If the first EAP authentication failed and the S-flag is not set in the PANA-FirstAuth-End-Answer message as a result of those operations, the PANA session MUST be immediately deleted. Otherwise, the second EAP authentication MUST be performed. Currently, use of multiple EAP methods in PANA is designed only for NAP-ISP authentication separation. It is not for arbitrary EAP method sequencing, or giving the PaC another chance when an authentication method fails. The NAP and ISP authentication are considered completely independent. Presence or success of one should not effect the other. Making an authentication decision based on the success or failure of each authentication is a network policy issue. PANA signals only the result of the immediately preceding EAP authentication method in PANA-Bind-Request messages. When an EAP method that is capable of deriving keys is used during the authentication phase and the keys are successfully derived, the PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer and/or PANA-Bind-Request and PANA-Bind-Answer messages, and all subsequent PANA messages MUST contain a MAC AVP. When separate NAP and ISP authentications are performed and the lower-layer is insecure, the two EAP methods MUST be capable of deriving keys. In this case, if the first EAP authentication is successful, the PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages as well as PANA-Auth-Request and PANA-Auth-Answer messages in the second EAP authentication MUST be protected with the key derived from the AAA-Key for the first EAP authentication. The PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent PANA messages MUST be protected either with the AAA-Key for the first EAP authentication if the first EAP authentication succeeds and the second EAP authentication fails, or with the AAA-Key for the second EAP authentication if the first EAP authentication fails and the second EAP authentication succeeds, or with the compound key derived from the two AAA-Keys, one for the first EAP authentication and the other from the second EAP authentication, if both the first and second EAP authentications succeed (see section 4.1.5 how the compound key is derived). The PANA-Bind-Request and the PANA-Bind-Answer message exchange is also used for binding device identifiers of the PaC and the PAA to the PANA SA. To achieve this, the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a device identifier of the PAA and the PaC, respectively, in a Device-Id AVP. The PaC MUST use the same type of device identifier as contained in the PANA-Bind-Request message. The PANA-Bind-Request message MAY also contain a Protection-Capability AVP to indicate if link-layer or network-layer ciphering should be initiated after PANA. No link layer or network layer specific information is included in the Protection-Capability AVP. When the information is preconfigured on the PaC and the PAA this AVP can be omitted. It is assumed that at least PAA is aware of the security capabilities of the access network. The PANA protocol does not specify how the PANA SA and the Protection-Capability AVP will be used to provide per-packet protection for data traffic. PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted based on the retransmission rule described in Appendix A. Add the following example in section 4.6: " Another PANA message sequence is illustrated in Figure X. The example assumes the following scenario: o PaC multicasts PANA-PAA-Discover message o The ISNs used by the PAA and the PaC are x and y, respectively. o PAA offers NAP and ISP separate authentication, as well as a choice of ISP from "ISP1" and "ISP2". o PaC accepts the offer from PAA, with choosing "ISP1" as the ISP. o An EAP sequence for NAP authentication and an EAP sequence for ISP authentication is performed in this order in authentication phase. o An EAP authentication method with a single round trip is used in each of EAP sequence. o The EAP authentication methods derive keys. Once the two EAP authenticatioins are successful, the PANA SA is bound to the two AAA-Keys. o After PANA SA is established, all messages are integrity and replay protected with the MAC AVP. o Re-authentication and termination phase are not shown. PaC PAA Message(tseq,rseq)[AVPs] ----------------------------------------------------- // Discovery and initial handshake phase -----> PANA-PAA-Discover (0,0) <----- PANA-Start-Request (x,0) // S-flag set [Cookie, ISP-Information("ISP1"), ISP-Information("ISP2"), NAP-Information("MyNAP")] -----> PANA-Start-Request-Answer (y,x) // S-flag set [Cookie, ISP-Information("ISP1")] // PaC chooses "ISP1" // Authentication phase <----- PANA-Auth-Request(x+1,y) // NAP authentication [EAP, NAP-Information("MyNAP")] // S-flag set -----> PANA-Auth-Answer(y+1,x+1)[EAP] // S-flag set <----- PANA-Auth-Request(x+2,y+1)[EAP] // S-flag set -----> PANA-Auth-Answer(y+2,x+2)[EAP] // S-flag set <----- PANA-FirstAuth-End-Request(x+3,y+2) // S-flag set [EAP{Success}, Key-Id, MAC] -----> PANA-FirstAuth-End-Answer(y+3,x+3)[Key-Id, MAC] // S-flag set <----- PANA-Auth-Request(x+3,y+4) // ISP authentication [EAP, ISP-Information("ISP1")] // S-flag set -----> PANA-Auth-Answer(y+4,x+4)[EAP] // S-flag set <----- PANA-Auth-Request(x+4,y+5)[EAP] // S-flag set -----> PANA-Auth-Answer(y+5,x+5)[EAP] // S-flag set <----- PANA-Bind-Request(x+5,y+6) // S-flag set [EAP{Success}, Device-Id, Key-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+6,x+5) // S-flag set [Device-Id, Key-Id, Protection-Cap., MAC] Figure X: A Message Sequence for NAP and ISP Separate Authentication " Change the following paragraph in section 9.1: " S(eparate) When the S-flag is set in a PANA-Start-Request message it indicates that PAA is willing to offer separate EAP authentication for NAP and ISP. When the S-flag is set in a PANA-Start-Answer message it indicates that PaC accepts on performing separate EAP authentication for NAP and ISP. " to: " S(eparate) When the S-flag is set in a PANA-Start-Request message it indicates that PAA is willing to offer separate EAP authentications for NAP and ISP. When the S-flag is set in a PANA-Start-Answer message it indicates that PaC accepts on performing separate EAP authentications for NAP and ISP. When the S-flag is set in a PANA-Auth-Request/Answer, PANA-FirstAuth-End-Request/Answer and PANA-Bind-Request/Answer messages it indicates that separate authentications are being performed in the authentication phase. " - Change Figure 9 as follows: " Message Direction: PaC---PAA ------------------------------------- PANA-PAA-Discover --------> PANA-Start-Request <-------- PANA-Start-Answer --------> PANA-Auth-Request <-------- PANA-Auth-Answer --------> PANA-FirstAuth-End-Request <-------- PANA-FirstAuth-End-Answer --------> PANA-Bind-Request <-------- PANA-Bind-Answer --------> PANA-Reauth-Request <-------> PANA-Reauth-Answer <-------> PANA-Termination-Request <-------> PANA-Termination-Answer <-------> PANA-Error <-------> " Add the following two sections: "9.3.X PANA-FirstAuth-End-Request (PFER) PANA-FirstAuth-End-Request (PFER) is sent by the PAA to the PaC. PANA-FirstAuth-End-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } [ Key-Id ] * [ AVP ] 0*1 < MAC > 9.3.Y PANA-FirstAuth-End-Answer (PFEA) PANA-FirstAuth-End-Answer (PFEA) is sent by the PaC to the PAA in response to a PANA-FirstAuth-End-Request message. PANA-FirstAuth-End--Answer ::= < PANA-Header: 4 > < Session-Id > < Device-Id > [ Key-Id ] * [ AVP ] 0*1 < MAC > " - Change the AVP occurrence table as follows: " +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0-1 | Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 | Protection-Cap. | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | Session-Lifetime | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ISP-Information | 0+ | 0-1 | 0-1 | 0 | 0 | 0 | 0 | NAP-Information | 0-1 | 0 | 0-1 | 0 | 0 | 0 | 0 | EP-Device-Id | 0 | 0 | 0 | 0 | 0+ | 0 | 0 | Key-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 | --------------------+-----+-----+-----+-----+-----+-----+-----+ +---------------------------------------------+ | Message | | Type | +------+------+-----+-----+-----+------+------+ Attribute Name | PRAR | PRAA | PTR | PTA | PER | PFER | PFEA | --------------------+------+------+-----+-----+-----+------+------+ Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 | Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1 | Termination-Cause | 0 | 0 | 1 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 0 | 0 | 0 | 1 | 0 | MAC | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | Device-Id | 1+ | 1+ | 0 | 0 | 0 | 0 | 0 | Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 1 | 0 | 0 | ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EP-Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Key-Id | 0 | 0 | 0 | 0 | 0 | 0-1 | 0-1 | --------------------+------+------+-----+-----+-----+------+------+ " Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Mar 16 19:11:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07208 for ; Tue, 16 Mar 2004 19:11:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OeC-0005Al-Uf; Tue, 16 Mar 2004 19:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OdH-000594-EH for pana@optimus.ietf.org; Tue, 16 Mar 2004 19:10:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07133 for ; Tue, 16 Mar 2004 19:09:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3OdE-0007iZ-00 for pana@ietf.org; Tue, 16 Mar 2004 19:10:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3OcH-0007c4-00 for pana@ietf.org; Tue, 16 Mar 2004 19:09:01 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3ObP-0007WL-00 for pana@ietf.org; Tue, 16 Mar 2004 19:08:07 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2H086KL024393; Wed, 17 Mar 2004 09:08:06 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2H086DP011774; Wed, 17 Mar 2004 09:08:06 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA11771 ; Wed, 17 Mar 2004 09:08:06 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA12336; Wed, 17 Mar 2004 09:08:05 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA16093; Wed, 17 Mar 2004 09:08:05 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2H084b9003337; Wed, 17 Mar 2004 09:08:04 +0900 (JST) Received: from steelhead ([159.119.168.132]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUP0012D1PEJB@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 09:08:03 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3Np7-0003ds-00; Tue, 16 Mar 2004 15:18:13 -0800 Date: Tue, 16 Mar 2004 15:18:13 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040316231813.GF13346@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] issue 57 (resolution) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , This is the resolution for issue 57 (PSR retransmission strategy). Basically the same as what I had proposed on the mailing list in February and presented in the IETF59 meeting. Further comments are appreciated. - Change the following paragraph in section " A PANA-Start-Request message is never retransmitted. A PANA-Start-Answer message is retransmitted based on timer in the same manner as other messages retransmitted at PANA-layer. " to: " A PANA-Start-Request message that carries a Cookie AVP is never retransmitted. A PANA-Start-Request message that does not carry a Cookie AVP is retransmitted based on timer. A PANA-Start-Answer message that carries a Cookie AVP is retransmitted based on timer. A PANA-Start-Answer message that does not carry a Cookie AVP is never retransmitted based on timer. " Change the first paragraph of section 10 to: "The PANA protocol provides retransmissions for all the message exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request messages carry EAP requests which are retransmitted by the EAP protocol entities when needed. The messages that need PANA-level retransmissions are listed below: PANA-PAA-Discover (PDI) PANA-Start-Request (PSR)* PANA-Start-Answer (PSA)** PANA-Bind-Request (PBR) PANA-FirstAuth-End-Request (PFER) PANA-Reauth-Request (PRAR) PANA-Termination-Request (PTR) *) PSR that carries a Cookie AVP is not retransmitted. **) PSA that does not carry a Cookie AVP is not retransmitted." (Note: PFER message is introduced for issue 52.) Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Mar 16 19:13:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07344 for ; Tue, 16 Mar 2004 19:13:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OgC-0005Uq-Tx for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 19:13:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H0D4g4021122 for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 19:13:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OgC-0005Ub-NU for pana-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 19:13:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07282 for ; Tue, 16 Mar 2004 19:13:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3OgB-0000HO-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 19:13:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3OfA-00008s-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 19:12:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3OeC-00001k-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 19:11:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OeC-0005Al-Uf; Tue, 16 Mar 2004 19:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3OdH-000594-EH for pana@optimus.ietf.org; Tue, 16 Mar 2004 19:10:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07133 for ; Tue, 16 Mar 2004 19:09:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3OdE-0007iZ-00 for pana@ietf.org; Tue, 16 Mar 2004 19:10:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3OcH-0007c4-00 for pana@ietf.org; Tue, 16 Mar 2004 19:09:01 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3ObP-0007WL-00 for pana@ietf.org; Tue, 16 Mar 2004 19:08:07 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2H086KL024393; Wed, 17 Mar 2004 09:08:06 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2H086DP011774; Wed, 17 Mar 2004 09:08:06 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA11771 ; Wed, 17 Mar 2004 09:08:06 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA12336; Wed, 17 Mar 2004 09:08:05 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA16093; Wed, 17 Mar 2004 09:08:05 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2H084b9003337; Wed, 17 Mar 2004 09:08:04 +0900 (JST) Received: from steelhead ([159.119.168.132]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUP0012D1PEJB@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 09:08:03 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3Np7-0003ds-00; Tue, 16 Mar 2004 15:18:13 -0800 Date: Tue, 16 Mar 2004 15:18:13 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040316231813.GF13346@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i Subject: [Pana] issue 57 (resolution) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is the resolution for issue 57 (PSR retransmission strategy). Basically the same as what I had proposed on the mailing list in February and presented in the IETF59 meeting. Further comments are appreciated. - Change the following paragraph in section " A PANA-Start-Request message is never retransmitted. A PANA-Start-Answer message is retransmitted based on timer in the same manner as other messages retransmitted at PANA-layer. " to: " A PANA-Start-Request message that carries a Cookie AVP is never retransmitted. A PANA-Start-Request message that does not carry a Cookie AVP is retransmitted based on timer. A PANA-Start-Answer message that carries a Cookie AVP is retransmitted based on timer. A PANA-Start-Answer message that does not carry a Cookie AVP is never retransmitted based on timer. " Change the first paragraph of section 10 to: "The PANA protocol provides retransmissions for all the message exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request messages carry EAP requests which are retransmitted by the EAP protocol entities when needed. The messages that need PANA-level retransmissions are listed below: PANA-PAA-Discover (PDI) PANA-Start-Request (PSR)* PANA-Start-Answer (PSA)** PANA-Bind-Request (PBR) PANA-FirstAuth-End-Request (PFER) PANA-Reauth-Request (PRAR) PANA-Termination-Request (PTR) *) PSR that carries a Cookie AVP is not retransmitted. **) PSA that does not carry a Cookie AVP is not retransmitted." (Note: PFER message is introduced for issue 52.) Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Mar 16 19:59:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09324 for ; Tue, 16 Mar 2004 19:59:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3POf-0000h7-GO; Tue, 16 Mar 2004 19:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PNq-0000g2-VG for pana@optimus.ietf.org; Tue, 16 Mar 2004 19:58:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09263 for ; Tue, 16 Mar 2004 19:58:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3PNp-0005Ki-00 for pana@ietf.org; Tue, 16 Mar 2004 19:58:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3PNN-0005Et-00 for pana@ietf.org; Tue, 16 Mar 2004 19:57:42 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3PMA-00058S-00 for pana@ietf.org; Tue, 16 Mar 2004 19:56:26 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2H0uOKL001663; Wed, 17 Mar 2004 09:56:24 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2H0uOqd016186; Wed, 17 Mar 2004 09:56:24 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA16184 ; Wed, 17 Mar 2004 09:56:24 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA24774; Wed, 17 Mar 2004 09:56:23 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA10204; Wed, 17 Mar 2004 09:56:13 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2H0u8b9003775; Wed, 17 Mar 2004 09:56:08 +0900 (JST) Received: from steelhead ([159.119.168.132]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUP0058Q3UR5L@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 09:54:27 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3ODb-0003eO-00; Tue, 16 Mar 2004 15:43:31 -0800 Date: Tue, 16 Mar 2004 15:43:27 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040316234327.GG13346@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] issue 53 (proposed text) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Here is the proposed text for issue 53 (Additional discovery information): - Append the following paragraph to section 4.9 (Mobility Handling): "If PAA has multiple interfaces connected to different IP links and PaC changes its attached network from one IP link to another among the IP links of the PAA, the DiameterIdentity part of the Session-Id contained in the PANA-Start-Answer message will be the same as that of the PAA. In this case, the PAA can share the PANA session attributes of the PaC for the previous and new IP links, without using an external communication mechanism to retrieve the attributes." Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Mar 16 20:01:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09416 for ; Tue, 16 Mar 2004 20:01:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PQc-0000qV-Nk for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 20:01:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H112xs003249 for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 20:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PQc-0000qK-IV for pana-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 20:01:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09387 for ; Tue, 16 Mar 2004 20:01:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3PQa-0005c0-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 20:01:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3PPb-0005VA-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 19:59:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3POf-0005P4-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 19:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3POf-0000h7-GO; Tue, 16 Mar 2004 19:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PNq-0000g2-VG for pana@optimus.ietf.org; Tue, 16 Mar 2004 19:58:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09263 for ; Tue, 16 Mar 2004 19:58:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3PNp-0005Ki-00 for pana@ietf.org; Tue, 16 Mar 2004 19:58:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3PNN-0005Et-00 for pana@ietf.org; Tue, 16 Mar 2004 19:57:42 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3PMA-00058S-00 for pana@ietf.org; Tue, 16 Mar 2004 19:56:26 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2H0uOKL001663; Wed, 17 Mar 2004 09:56:24 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2H0uOqd016186; Wed, 17 Mar 2004 09:56:24 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA16184 ; Wed, 17 Mar 2004 09:56:24 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA24774; Wed, 17 Mar 2004 09:56:23 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA10204; Wed, 17 Mar 2004 09:56:13 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2H0u8b9003775; Wed, 17 Mar 2004 09:56:08 +0900 (JST) Received: from steelhead ([159.119.168.132]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUP0058Q3UR5L@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 09:54:27 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3ODb-0003eO-00; Tue, 16 Mar 2004 15:43:31 -0800 Date: Tue, 16 Mar 2004 15:43:27 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040316234327.GG13346@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i Subject: [Pana] issue 53 (proposed text) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Here is the proposed text for issue 53 (Additional discovery information): - Append the following paragraph to section 4.9 (Mobility Handling): "If PAA has multiple interfaces connected to different IP links and PaC changes its attached network from one IP link to another among the IP links of the PAA, the DiameterIdentity part of the Session-Id contained in the PANA-Start-Answer message will be the same as that of the PAA. In this case, the PAA can share the PANA session attributes of the PaC for the previous and new IP links, without using an external communication mechanism to retrieve the attributes." Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Mar 16 20:05:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09637 for ; Tue, 16 Mar 2004 20:05:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PUT-00019V-Ql; Tue, 16 Mar 2004 20:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PTZ-00016m-7h for pana@optimus.ietf.org; Tue, 16 Mar 2004 20:04:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09550 for ; Tue, 16 Mar 2004 20:04:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3PTX-0005xm-00 for pana@ietf.org; Tue, 16 Mar 2004 20:04:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3PSd-0005pv-00 for pana@ietf.org; Tue, 16 Mar 2004 20:03:08 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3PRg-0005kP-00 for pana@ietf.org; Tue, 16 Mar 2004 20:02:09 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2H128KL006075; Wed, 17 Mar 2004 10:02:08 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2H128Wp024821; Wed, 17 Mar 2004 10:02:08 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA24813 ; Wed, 17 Mar 2004 10:02:08 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA00638; Wed, 17 Mar 2004 10:02:07 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA24592; Wed, 17 Mar 2004 10:01:36 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2H11Jb9006961; Wed, 17 Mar 2004 10:01:20 +0900 (JST) Received: from steelhead ([159.119.168.132]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUP0050544T0P@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 10:00:30 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3OH0-0003eZ-00; Tue, 16 Mar 2004 15:47:02 -0800 Date: Tue, 16 Mar 2004 15:47:02 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040316234702.GH13346@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] issue 54 (possible reject) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , According to the discussion in IETF59 on Issue 54 (mandatory cookie), mandatory including a Cookie AVP in PANA-Start-Request message can conflict with optionally carrying EAP-Request in PANA-Start-Request message (i.e., Cookie AVP requires stateless operation while generating EAP Request would require stateful operation for retransmission). As a result, we are rejecting this issue unless there is any objection. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Mar 16 20:18:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10172 for ; Tue, 16 Mar 2004 20:18:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Ph3-00023U-Aa; Tue, 16 Mar 2004 20:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Pg5-00021u-Ox for pana@optimus.ietf.org; Tue, 16 Mar 2004 20:17:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10165 for ; Tue, 16 Mar 2004 20:16:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Pg3-0007Mc-00 for pana@ietf.org; Tue, 16 Mar 2004 20:16:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Pf7-0007IX-00 for pana@ietf.org; Tue, 16 Mar 2004 20:16:02 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3PeU-0007EV-00 for pana@ietf.org; Tue, 16 Mar 2004 20:15:22 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2H1FLKL017405; Wed, 17 Mar 2004 10:15:21 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2H1FLLJ016648; Wed, 17 Mar 2004 10:15:21 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA16645 ; Wed, 17 Mar 2004 10:15:21 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA14865; Wed, 17 Mar 2004 10:15:20 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA19946; Wed, 17 Mar 2004 10:15:18 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2H1FEb9016482; Wed, 17 Mar 2004 10:15:15 +0900 (JST) Received: from steelhead ([159.119.168.132]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUP009074TD5O@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 10:15:13 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3OOf-0003f8-00; Tue, 16 Mar 2004 15:54:57 -0800 Date: Tue, 16 Mar 2004 15:54:57 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040316235457.GI13346@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] issue 55 (reject) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , With regard to issue 55 (client cookie), there was a rough concensus that client cookie does not provide any protection. Action: reject this issue. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Mar 16 20:25:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10384 for ; Tue, 16 Mar 2004 20:25:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Pnz-0002Dw-Gd for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 20:25:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H1PB3S008542 for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 20:25:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Pnz-0002Dh-Ah for pana-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 20:25:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10350 for ; Tue, 16 Mar 2004 20:25:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Pnx-0000R0-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 20:25:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3PlK-00000P-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 20:22:26 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3Pk1-0007h8-01 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 20:21:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3Ph8-0006Wj-Up for pana-web-archive@ietf.org; Tue, 16 Mar 2004 20:18:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Ph3-00023U-Aa; Tue, 16 Mar 2004 20:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Pg5-00021u-Ox for pana@optimus.ietf.org; Tue, 16 Mar 2004 20:17:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10165 for ; Tue, 16 Mar 2004 20:16:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Pg3-0007Mc-00 for pana@ietf.org; Tue, 16 Mar 2004 20:16:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Pf7-0007IX-00 for pana@ietf.org; Tue, 16 Mar 2004 20:16:02 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3PeU-0007EV-00 for pana@ietf.org; Tue, 16 Mar 2004 20:15:22 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2H1FLKL017405; Wed, 17 Mar 2004 10:15:21 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2H1FLLJ016648; Wed, 17 Mar 2004 10:15:21 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA16645 ; Wed, 17 Mar 2004 10:15:21 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA14865; Wed, 17 Mar 2004 10:15:20 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA19946; Wed, 17 Mar 2004 10:15:18 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2H1FEb9016482; Wed, 17 Mar 2004 10:15:15 +0900 (JST) Received: from steelhead ([159.119.168.132]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUP009074TD5O@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 10:15:13 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3OOf-0003f8-00; Tue, 16 Mar 2004 15:54:57 -0800 Date: Tue, 16 Mar 2004 15:54:57 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040316235457.GI13346@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i Subject: [Pana] issue 55 (reject) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 With regard to issue 55 (client cookie), there was a rough concensus that client cookie does not provide any protection. Action: reject this issue. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Mar 16 20:27:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10745 for ; Tue, 16 Mar 2004 20:27:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PpR-0002Ih-EN for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 20:26:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H1QfMd008837 for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 20:26:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PpR-0002IS-Aa for pana-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 20:26:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10537 for ; Tue, 16 Mar 2004 20:26:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3PpO-0000m9-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 20:26:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Pn8-0000I1-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 20:24:19 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3Pkg-0007h8-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 20:21:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3PUY-0005Zt-C8 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 20:05:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PUT-00019V-Ql; Tue, 16 Mar 2004 20:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PTZ-00016m-7h for pana@optimus.ietf.org; Tue, 16 Mar 2004 20:04:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09550 for ; Tue, 16 Mar 2004 20:04:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3PTX-0005xm-00 for pana@ietf.org; Tue, 16 Mar 2004 20:04:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3PSd-0005pv-00 for pana@ietf.org; Tue, 16 Mar 2004 20:03:08 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3PRg-0005kP-00 for pana@ietf.org; Tue, 16 Mar 2004 20:02:09 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2H128KL006075; Wed, 17 Mar 2004 10:02:08 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2H128Wp024821; Wed, 17 Mar 2004 10:02:08 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA24813 ; Wed, 17 Mar 2004 10:02:08 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA00638; Wed, 17 Mar 2004 10:02:07 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA24592; Wed, 17 Mar 2004 10:01:36 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2H11Jb9006961; Wed, 17 Mar 2004 10:01:20 +0900 (JST) Received: from steelhead ([159.119.168.132]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUP0050544T0P@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 10:00:30 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3OH0-0003eZ-00; Tue, 16 Mar 2004 15:47:02 -0800 Date: Tue, 16 Mar 2004 15:47:02 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040316234702.GH13346@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i Subject: [Pana] issue 54 (possible reject) Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 According to the discussion in IETF59 on Issue 54 (mandatory cookie), mandatory including a Cookie AVP in PANA-Start-Request message can conflict with optionally carrying EAP-Request in PANA-Start-Request message (i.e., Cookie AVP requires stateless operation while generating EAP Request would require stateful operation for retransmission). As a result, we are rejecting this issue unless there is any objection. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Mar 16 21:49:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14395 for ; Tue, 16 Mar 2004 21:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3R76-00078q-QC; Tue, 16 Mar 2004 21:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3R6K-00075l-Vx for pana@optimus.ietf.org; Tue, 16 Mar 2004 21:48:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14313 for ; Tue, 16 Mar 2004 21:48:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3R6I-0001lp-00 for pana@ietf.org; Tue, 16 Mar 2004 21:48:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3R5B-0001ez-00 for pana@ietf.org; Tue, 16 Mar 2004 21:47:01 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3R4C-0001V9-00 for pana@ietf.org; Tue, 16 Mar 2004 21:46:00 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2H2jvKL000549; Wed, 17 Mar 2004 11:45:57 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2H2jvEV006027; Wed, 17 Mar 2004 11:45:57 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id MAA06019 ; Wed, 17 Mar 2004 11:45:57 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id LAA16655; Wed, 17 Mar 2004 11:45:56 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id LAA01659; Wed, 17 Mar 2004 11:45:56 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2H2jtb9008922; Wed, 17 Mar 2004 11:45:55 +0900 (JST) Received: from steelhead ([159.119.168.63]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUP0021190HBV@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 11:45:54 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3PAW-0003hN-00; Tue, 16 Mar 2004 16:44:24 -0800 Date: Tue, 16 Mar 2004 16:44:23 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue64: Two separate codes for Session ID AVP In-reply-to: <005601c40a89$17253c10$ed2f024b@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040317004423.GN13346@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <005601c40a89$17253c10$ed2f024b@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Mon, Mar 15, 2004 at 04:28:57AM -0800, Alper Yegin wrote: > Based on the proposed solution to this issue, here is the proposed text > change. > > Change from: > > 9.4.3 Session-Id AVP > > Session-Id AVP (Code 1026) has an opaque data field, which is > assigned by the PAA. All messages pertaining to a specific PANA > Session MUST include only one Session-Id AVP and the same value MUST > be used throughout the lifetime of a session. When present, the > Session-Id SHOULD appear immediately following the PANA header. > > The Session-Id MUST be globally and eternally unique, as it is meant > to identify a PANA Session without reference to any other > information, and may be needed to correlate historical authentication > information with accounting information. > > The Session-Id AVP MAY use Diameter [RFC3588] message formatting. In > this case the AVP code is 263. > > To: > > 9.4.3 Session-Id AVP > > All messages pertaining to a specific PANA session MUST include a > Session-Id AVP (Code 1026) which carries a PAA-assigned fix value > throughout the lifetime of a session. When present, the Session-Id > SHOULD > appear immediately following the PANA header. > > The Session-Id MUST be globally and eternally unique, as it is meant > to > identify a PANA Session without reference to any other information, > and > may be needed to correlate historical authentication information with > > accounting information. The PANA Session-Id AVP has the same format > as > the Diameter Session-Id AVP [RFC3588]. > I agree on the proposed text, and I think that the last sentence also serves as a part of resolution for issue 53 (additional discovery information). Yoshihiro Ohba > > Comments welcome. > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Mar 16 21:51:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14495 for ; Tue, 16 Mar 2004 21:51:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3R9A-0007OL-JV for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 21:51:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H2p8nc028410 for pana-archive@odin.ietf.org; Tue, 16 Mar 2004 21:51:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3R9A-0007O9-D5 for pana-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 21:51:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14453 for ; Tue, 16 Mar 2004 21:51:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3R97-000270-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 21:51:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3R85-0001yx-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 21:50:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3R76-0001pw-00 for pana-web-archive@ietf.org; Tue, 16 Mar 2004 21:49:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3R76-00078q-QC; Tue, 16 Mar 2004 21:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3R6K-00075l-Vx for pana@optimus.ietf.org; Tue, 16 Mar 2004 21:48:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14313 for ; Tue, 16 Mar 2004 21:48:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3R6I-0001lp-00 for pana@ietf.org; Tue, 16 Mar 2004 21:48:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3R5B-0001ez-00 for pana@ietf.org; Tue, 16 Mar 2004 21:47:01 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3R4C-0001V9-00 for pana@ietf.org; Tue, 16 Mar 2004 21:46:00 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2H2jvKL000549; Wed, 17 Mar 2004 11:45:57 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2H2jvEV006027; Wed, 17 Mar 2004 11:45:57 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id MAA06019 ; Wed, 17 Mar 2004 11:45:57 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id LAA16655; Wed, 17 Mar 2004 11:45:56 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id LAA01659; Wed, 17 Mar 2004 11:45:56 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2H2jtb9008922; Wed, 17 Mar 2004 11:45:55 +0900 (JST) Received: from steelhead ([159.119.168.63]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUP0021190HBV@tsbpo1.po.toshiba.co.jp>; Wed, 17 Mar 2004 11:45:54 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3PAW-0003hN-00; Tue, 16 Mar 2004 16:44:24 -0800 Date: Tue, 16 Mar 2004 16:44:23 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue64: Two separate codes for Session ID AVP In-reply-to: <005601c40a89$17253c10$ed2f024b@sisa.samsung.com> To: Alper Yegin Cc: pana@ietf.org Message-id: <20040317004423.GN13346@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <005601c40a89$17253c10$ed2f024b@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, Mar 15, 2004 at 04:28:57AM -0800, Alper Yegin wrote: > Based on the proposed solution to this issue, here is the proposed text > change. > > Change from: > > 9.4.3 Session-Id AVP > > Session-Id AVP (Code 1026) has an opaque data field, which is > assigned by the PAA. All messages pertaining to a specific PANA > Session MUST include only one Session-Id AVP and the same value MUST > be used throughout the lifetime of a session. When present, the > Session-Id SHOULD appear immediately following the PANA header. > > The Session-Id MUST be globally and eternally unique, as it is meant > to identify a PANA Session without reference to any other > information, and may be needed to correlate historical authentication > information with accounting information. > > The Session-Id AVP MAY use Diameter [RFC3588] message formatting. In > this case the AVP code is 263. > > To: > > 9.4.3 Session-Id AVP > > All messages pertaining to a specific PANA session MUST include a > Session-Id AVP (Code 1026) which carries a PAA-assigned fix value > throughout the lifetime of a session. When present, the Session-Id > SHOULD > appear immediately following the PANA header. > > The Session-Id MUST be globally and eternally unique, as it is meant > to > identify a PANA Session without reference to any other information, > and > may be needed to correlate historical authentication information with > > accounting information. The PANA Session-Id AVP has the same format > as > the Diameter Session-Id AVP [RFC3588]. > I agree on the proposed text, and I think that the last sentence also serves as a part of resolution for issue 53 (additional discovery information). Yoshihiro Ohba > > Comments welcome. > > Alper > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Mar 17 06:49:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02256 for ; Wed, 17 Mar 2004 06:49:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ZXr-0002BN-El; Wed, 17 Mar 2004 06:49:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ZXG-0002Ah-1m for pana@optimus.ietf.org; Wed, 17 Mar 2004 06:48:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02223 for ; Wed, 17 Mar 2004 06:48:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3ZXB-0000by-00 for pana@ietf.org; Wed, 17 Mar 2004 06:48:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ZWM-0000Vb-00 for pana@ietf.org; Wed, 17 Mar 2004 06:47:39 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B3ZVt-0000MM-00 for pana@ietf.org; Wed, 17 Mar 2004 06:47:09 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUP00F01Y1LM5@mailout3.samsung.com> for pana@ietf.org; Wed, 17 Mar 2004 20:46:33 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUP0097OY1KT1@mailout3.samsung.com> for pana@ietf.org; Wed, 17 Mar 2004 20:46:33 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUP0081KY1K30@mmp1.samsung.com> for pana@ietf.org; Wed, 17 Mar 2004 20:46:32 +0900 (KST) Date: Wed, 17 Mar 2004 03:46:34 -0800 From: Alper Yegin Subject: RE: [Pana] issue 53 (proposed text) In-reply-to: <20040316234327.GG13346@steelhead> To: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <000001c40c15$7fb9b520$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Yoshi, > - Append the following paragraph to section 4.9 (Mobility Handling): > > "If PAA has multiple interfaces connected to different IP links and PaC > changes its attached network from one IP link to another among the IP > links of the PAA, the DiameterIdentity part of the Session-Id > contained in the PANA-Start-Answer message will be the same as that of > the PAA. In this case, the PAA can share the PANA session attributes > of the PaC for the previous and new IP links, without using an > external communication mechanism to retrieve the attributes." Actually it is not guaranteed that the DiameterIdentity would be the same. There might be separate Diameter instances running for each interface. Also, even if they are not the same, that doesn't matter. I think the point you are making is when the PAA node doesn't change, we don't need to run a protocol to retrieve PANA attributes from. (I think this is clear reading the current text, but I'm fine with an explicit text too). Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Mar 17 06:51:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02321 for ; Wed, 17 Mar 2004 06:51:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Za1-0002GR-Em for pana-archive@odin.ietf.org; Wed, 17 Mar 2004 06:51:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HBpPeL008699 for pana-archive@odin.ietf.org; Wed, 17 Mar 2004 06:51:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Za0-0002GE-Lw for pana-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 06:51:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02306 for ; Wed, 17 Mar 2004 06:51:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3ZZw-0000to-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 06:51:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ZYz-0000o9-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 06:50:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3ZY6-0000iO-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 06:49:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ZXr-0002BN-El; Wed, 17 Mar 2004 06:49:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ZXG-0002Ah-1m for pana@optimus.ietf.org; Wed, 17 Mar 2004 06:48:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02223 for ; Wed, 17 Mar 2004 06:48:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3ZXB-0000by-00 for pana@ietf.org; Wed, 17 Mar 2004 06:48:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ZWM-0000Vb-00 for pana@ietf.org; Wed, 17 Mar 2004 06:47:39 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B3ZVt-0000MM-00 for pana@ietf.org; Wed, 17 Mar 2004 06:47:09 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUP00F01Y1LM5@mailout3.samsung.com> for pana@ietf.org; Wed, 17 Mar 2004 20:46:33 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUP0097OY1KT1@mailout3.samsung.com> for pana@ietf.org; Wed, 17 Mar 2004 20:46:33 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUP0081KY1K30@mmp1.samsung.com> for pana@ietf.org; Wed, 17 Mar 2004 20:46:32 +0900 (KST) Date: Wed, 17 Mar 2004 03:46:34 -0800 From: Alper Yegin Subject: RE: [Pana] issue 53 (proposed text) In-reply-to: <20040316234327.GG13346@steelhead> To: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <000001c40c15$7fb9b520$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Yoshi, > - Append the following paragraph to section 4.9 (Mobility Handling): > > "If PAA has multiple interfaces connected to different IP links and PaC > changes its attached network from one IP link to another among the IP > links of the PAA, the DiameterIdentity part of the Session-Id > contained in the PANA-Start-Answer message will be the same as that of > the PAA. In this case, the PAA can share the PANA session attributes > of the PaC for the previous and new IP links, without using an > external communication mechanism to retrieve the attributes." Actually it is not guaranteed that the DiameterIdentity would be the same. There might be separate Diameter instances running for each interface. Also, even if they are not the same, that doesn't matter. I think the point you are making is when the PAA node doesn't change, we don't need to run a protocol to retrieve PANA attributes from. (I think this is clear reading the current text, but I'm fine with an explicit text too). Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Mar 17 07:30:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03165 for ; Wed, 17 Mar 2004 07:30:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aBP-0005cw-46; Wed, 17 Mar 2004 07:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aAv-0005b2-Ur for pana@optimus.ietf.org; Wed, 17 Mar 2004 07:29:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03159 for ; Wed, 17 Mar 2004 07:29:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3aAu-00051I-00 for pana@ietf.org; Wed, 17 Mar 2004 07:29:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3aA0-0004uu-00 for pana@ietf.org; Wed, 17 Mar 2004 07:28:37 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B3a9g-0004nl-00 for pana@ietf.org; Wed, 17 Mar 2004 07:28:16 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUP00H01ZY7P2@mailout3.samsung.com> for pana@ietf.org; Wed, 17 Mar 2004 21:27:44 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUP009UQZY7T1@mailout3.samsung.com> for pana@ietf.org; Wed, 17 Mar 2004 21:27:43 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUP00JPCZY7PN@mmp1.samsung.com> for pana@ietf.org; Wed, 17 Mar 2004 21:27:43 +0900 (KST) Date: Wed, 17 Mar 2004 04:27:44 -0800 From: Alper Yegin Subject: RE: [Pana] issue 57 (resolution) In-reply-to: <20040316231813.GF13346@steelhead> To: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <000001c40c1b$400cfda0$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Yoshi, Thinking a bit more on this (or confusing myself :)... I think whether a PDI/PSR/PSA retransmitted or not should not be indexed to cookie usage, but to solicited vs. unsolicited PSR. When PaC performs active discovery of PAAs by sending PDI, both PDI and PSA messages are retransmitted as needed, whereas PSR is not retransmitted by the PAA. When PAA discovery is performed in unsolicited fashion, PSR is retransmitted, and PSA is not. Does this make sense? Alper > " > A PANA-Start-Request message that carries a Cookie AVP is never > retransmitted. A PANA-Start-Request message that does not carry a > Cookie AVP is retransmitted based on timer. A PANA-Start-Answer > message that carries a Cookie AVP is retransmitted based on timer. > A PANA-Start-Answer message that does not carry a Cookie AVP is > never retransmitted based on timer. > " > > Change the first paragraph of section 10 to: > > "The PANA protocol provides retransmissions for all the message > exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request messages > carry EAP requests which are retransmitted by the EAP protocol > entities when needed. The messages that need PANA-level > retransmissions are listed below: > > PANA-PAA-Discover (PDI) > PANA-Start-Request (PSR)* > PANA-Start-Answer (PSA)** > PANA-Bind-Request (PBR) > PANA-FirstAuth-End-Request (PFER) > PANA-Reauth-Request (PRAR) > PANA-Termination-Request (PTR) > > *) PSR that carries a Cookie AVP is not retransmitted. > **) PSA that does not carry a Cookie AVP is not retransmitted." > > > (Note: PFER message is introduced for issue 52.) > > Regards, > Yoshihiro Ohba > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Mar 17 07:32:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03298 for ; Wed, 17 Mar 2004 07:32:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aD5-0005iw-HF for pana-archive@odin.ietf.org; Wed, 17 Mar 2004 07:31:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HCVjLE021990 for pana-archive@odin.ietf.org; Wed, 17 Mar 2004 07:31:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aD1-0005iR-00 for pana-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 07:31:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03282 for ; Wed, 17 Mar 2004 07:31:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3aD0-0005IG-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 07:31:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3aC3-0005Ag-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 07:30:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3aBU-000523-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 07:30:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aBP-0005cw-46; Wed, 17 Mar 2004 07:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3aAv-0005b2-Ur for pana@optimus.ietf.org; Wed, 17 Mar 2004 07:29:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03159 for ; Wed, 17 Mar 2004 07:29:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3aAu-00051I-00 for pana@ietf.org; Wed, 17 Mar 2004 07:29:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3aA0-0004uu-00 for pana@ietf.org; Wed, 17 Mar 2004 07:28:37 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B3a9g-0004nl-00 for pana@ietf.org; Wed, 17 Mar 2004 07:28:16 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUP00H01ZY7P2@mailout3.samsung.com> for pana@ietf.org; Wed, 17 Mar 2004 21:27:44 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUP009UQZY7T1@mailout3.samsung.com> for pana@ietf.org; Wed, 17 Mar 2004 21:27:43 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUP00JPCZY7PN@mmp1.samsung.com> for pana@ietf.org; Wed, 17 Mar 2004 21:27:43 +0900 (KST) Date: Wed, 17 Mar 2004 04:27:44 -0800 From: Alper Yegin Subject: RE: [Pana] issue 57 (resolution) In-reply-to: <20040316231813.GF13346@steelhead> To: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <000001c40c1b$400cfda0$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Yoshi, Thinking a bit more on this (or confusing myself :)... I think whether a PDI/PSR/PSA retransmitted or not should not be indexed to cookie usage, but to solicited vs. unsolicited PSR. When PaC performs active discovery of PAAs by sending PDI, both PDI and PSA messages are retransmitted as needed, whereas PSR is not retransmitted by the PAA. When PAA discovery is performed in unsolicited fashion, PSR is retransmitted, and PSA is not. Does this make sense? Alper > " > A PANA-Start-Request message that carries a Cookie AVP is never > retransmitted. A PANA-Start-Request message that does not carry a > Cookie AVP is retransmitted based on timer. A PANA-Start-Answer > message that carries a Cookie AVP is retransmitted based on timer. > A PANA-Start-Answer message that does not carry a Cookie AVP is > never retransmitted based on timer. > " > > Change the first paragraph of section 10 to: > > "The PANA protocol provides retransmissions for all the message > exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request messages > carry EAP requests which are retransmitted by the EAP protocol > entities when needed. The messages that need PANA-level > retransmissions are listed below: > > PANA-PAA-Discover (PDI) > PANA-Start-Request (PSR)* > PANA-Start-Answer (PSA)** > PANA-Bind-Request (PBR) > PANA-FirstAuth-End-Request (PFER) > PANA-Reauth-Request (PRAR) > PANA-Termination-Request (PTR) > > *) PSR that carries a Cookie AVP is not retransmitted. > **) PSA that does not carry a Cookie AVP is not retransmitted." > > > (Note: PFER message is introduced for issue 52.) > > Regards, > Yoshihiro Ohba > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Mar 17 11:04:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15016 for ; Wed, 17 Mar 2004 11:04:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dWT-0001O8-8g; Wed, 17 Mar 2004 11:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dW0-0001NZ-8w for pana@optimus.ietf.org; Wed, 17 Mar 2004 11:03:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14989 for ; Wed, 17 Mar 2004 11:03:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3dVx-0001Gq-00 for pana@ietf.org; Wed, 17 Mar 2004 11:03:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3dV0-0001AA-00 for pana@ietf.org; Wed, 17 Mar 2004 11:02:30 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3dU3-00012m-00 for pana@ietf.org; Wed, 17 Mar 2004 11:01:31 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2HG1TKL022388; Thu, 18 Mar 2004 01:01:29 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2HG1TP4012089; Thu, 18 Mar 2004 01:01:29 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA12088 ; Thu, 18 Mar 2004 01:01:28 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA29205; Thu, 18 Mar 2004 01:01:28 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA26196; Thu, 18 Mar 2004 01:01:27 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2HG1Qb9013031; Thu, 18 Mar 2004 01:01:26 +0900 (JST) Received: from steelhead (att01-024.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUQ00N3A9UB2L@tsbpo1.po.toshiba.co.jp>; Thu, 18 Mar 2004 01:01:25 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3QC4-0003oh-00; Tue, 16 Mar 2004 17:50:04 -0800 Date: Tue, 16 Mar 2004 17:50:04 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 57 (resolution) In-reply-to: <000001c40c1b$400cfda0$ed2f024b@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040317015004.GA14670@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040316231813.GF13346@steelhead> <000001c40c1b$400cfda0$ed2f024b@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Wed, Mar 17, 2004 at 04:27:44AM -0800, Alper Yegin wrote: > Yoshi, > > Thinking a bit more on this (or confusing myself :)... > > I think whether a PDI/PSR/PSA retransmitted or not should not be indexed > to cookie usage, but to solicited vs. unsolicited PSR. > > When PaC performs active discovery of PAAs by sending PDI, both PDI and > PSA messages are retransmitted as needed, whereas PSR is not > retransmitted by the PAA. > > When PAA discovery is performed in unsolicited fashion, PSR is > retransmitted, and PSA is not. > > Does this make sense? I think indexing to solicited vs. unsolicited PSR also works. A difference from indexing to cookie usage is that it is possible that PaC can operate in solicited mode while PAA is operating in unsolicited mode at the same time. For example, PaC operating in solicited mode sends PDI, while at the same time PAA operating in unsolicited mode sends PSR. If it happens, I think all PDI, PSR and PSA will be retransmitted if the retransmission strategy is based on solicited vs. unsolicited PSR, which seems to be less efficient. By indexing to cookie usage (or indexing to stateless vs stateful PAA), both PaC and PAA can always be synchronized to have the same mode of operation about the retransmission strategy, i.e., when PSR is retransmitted PSA is never retransmitted, and vise versa. What do you think? Yoshihiro Ohba - > > Alper > > > > " > > A PANA-Start-Request message that carries a Cookie AVP is never > > retransmitted. A PANA-Start-Request message that does not carry a > > Cookie AVP is retransmitted based on timer. A PANA-Start-Answer > > message that carries a Cookie AVP is retransmitted based on timer. > > A PANA-Start-Answer message that does not carry a Cookie AVP is > > never retransmitted based on timer. > > " > > > > Change the first paragraph of section 10 to: > > > > "The PANA protocol provides retransmissions for all the message > > exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request > messages > > carry EAP requests which are retransmitted by the EAP protocol > > entities when needed. The messages that need PANA-level > > retransmissions are listed below: > > > > PANA-PAA-Discover (PDI) > > PANA-Start-Request (PSR)* > > PANA-Start-Answer (PSA)** > > PANA-Bind-Request (PBR) > > PANA-FirstAuth-End-Request (PFER) > > PANA-Reauth-Request (PRAR) > > PANA-Termination-Request (PTR) > > > > *) PSR that carries a Cookie AVP is not retransmitted. > > **) PSA that does not carry a Cookie AVP is not retransmitted." > > > > > > (Note: PFER message is introduced for issue 52.) > > > > Regards, > > Yoshihiro Ohba > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Mar 17 11:36:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17980 for ; Wed, 17 Mar 2004 11:36:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dfN-0002BN-GE for pana-archive@odin.ietf.org; Wed, 17 Mar 2004 11:13:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HGD3LY008356 for pana-archive@odin.ietf.org; Wed, 17 Mar 2004 11:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dfC-0002AB-U0 for pana-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 11:13:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15675 for ; Wed, 17 Mar 2004 11:12:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3dex-0002r0-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 11:12:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3dc0-0002B8-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 11:09:45 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3dar-0001qQ-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 11:08:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3dWX-0002bQ-49 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 11:04:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dWT-0001O8-8g; Wed, 17 Mar 2004 11:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dW0-0001NZ-8w for pana@optimus.ietf.org; Wed, 17 Mar 2004 11:03:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14989 for ; Wed, 17 Mar 2004 11:03:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3dVx-0001Gq-00 for pana@ietf.org; Wed, 17 Mar 2004 11:03:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3dV0-0001AA-00 for pana@ietf.org; Wed, 17 Mar 2004 11:02:30 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3dU3-00012m-00 for pana@ietf.org; Wed, 17 Mar 2004 11:01:31 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2HG1TKL022388; Thu, 18 Mar 2004 01:01:29 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2HG1TP4012089; Thu, 18 Mar 2004 01:01:29 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA12088 ; Thu, 18 Mar 2004 01:01:28 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA29205; Thu, 18 Mar 2004 01:01:28 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA26196; Thu, 18 Mar 2004 01:01:27 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2HG1Qb9013031; Thu, 18 Mar 2004 01:01:26 +0900 (JST) Received: from steelhead (att01-024.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUQ00N3A9UB2L@tsbpo1.po.toshiba.co.jp>; Thu, 18 Mar 2004 01:01:25 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3QC4-0003oh-00; Tue, 16 Mar 2004 17:50:04 -0800 Date: Tue, 16 Mar 2004 17:50:04 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 57 (resolution) In-reply-to: <000001c40c1b$400cfda0$ed2f024b@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040317015004.GA14670@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040316231813.GF13346@steelhead> <000001c40c1b$400cfda0$ed2f024b@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 On Wed, Mar 17, 2004 at 04:27:44AM -0800, Alper Yegin wrote: > Yoshi, > > Thinking a bit more on this (or confusing myself :)... > > I think whether a PDI/PSR/PSA retransmitted or not should not be indexed > to cookie usage, but to solicited vs. unsolicited PSR. > > When PaC performs active discovery of PAAs by sending PDI, both PDI and > PSA messages are retransmitted as needed, whereas PSR is not > retransmitted by the PAA. > > When PAA discovery is performed in unsolicited fashion, PSR is > retransmitted, and PSA is not. > > Does this make sense? I think indexing to solicited vs. unsolicited PSR also works. A difference from indexing to cookie usage is that it is possible that PaC can operate in solicited mode while PAA is operating in unsolicited mode at the same time. For example, PaC operating in solicited mode sends PDI, while at the same time PAA operating in unsolicited mode sends PSR. If it happens, I think all PDI, PSR and PSA will be retransmitted if the retransmission strategy is based on solicited vs. unsolicited PSR, which seems to be less efficient. By indexing to cookie usage (or indexing to stateless vs stateful PAA), both PaC and PAA can always be synchronized to have the same mode of operation about the retransmission strategy, i.e., when PSR is retransmitted PSA is never retransmitted, and vise versa. What do you think? Yoshihiro Ohba - > > Alper > > > > " > > A PANA-Start-Request message that carries a Cookie AVP is never > > retransmitted. A PANA-Start-Request message that does not carry a > > Cookie AVP is retransmitted based on timer. A PANA-Start-Answer > > message that carries a Cookie AVP is retransmitted based on timer. > > A PANA-Start-Answer message that does not carry a Cookie AVP is > > never retransmitted based on timer. > > " > > > > Change the first paragraph of section 10 to: > > > > "The PANA protocol provides retransmissions for all the message > > exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request > messages > > carry EAP requests which are retransmitted by the EAP protocol > > entities when needed. The messages that need PANA-level > > retransmissions are listed below: > > > > PANA-PAA-Discover (PDI) > > PANA-Start-Request (PSR)* > > PANA-Start-Answer (PSA)** > > PANA-Bind-Request (PBR) > > PANA-FirstAuth-End-Request (PFER) > > PANA-Reauth-Request (PRAR) > > PANA-Termination-Request (PTR) > > > > *) PSR that carries a Cookie AVP is not retransmitted. > > **) PSA that does not carry a Cookie AVP is not retransmitted." > > > > > > (Note: PFER message is introduced for issue 52.) > > > > Regards, > > Yoshihiro Ohba > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Mar 17 12:58:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26590 for ; Wed, 17 Mar 2004 12:58:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fIp-0003kg-1H; Wed, 17 Mar 2004 12:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fIV-0003gV-53 for pana@optimus.ietf.org; Wed, 17 Mar 2004 12:57:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26458 for ; Wed, 17 Mar 2004 12:57:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3fIT-0006KK-00 for pana@ietf.org; Wed, 17 Mar 2004 12:57:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3fHT-000634-00 for pana@ietf.org; Wed, 17 Mar 2004 12:56:39 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3fG6-0005mm-00 for pana@ietf.org; Wed, 17 Mar 2004 12:55:14 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2HHtAKL022564; Thu, 18 Mar 2004 02:55:10 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2HHtAck023912; Thu, 18 Mar 2004 02:55:10 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA23909 ; Thu, 18 Mar 2004 02:55:10 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA07551; Thu, 18 Mar 2004 02:55:09 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA18537; Thu, 18 Mar 2004 02:55:09 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2HHt8b9008262; Thu, 18 Mar 2004 02:55:08 +0900 (JST) Received: from steelhead (att01-013.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUQ001PXF3TQH@tsbpo1.po.toshiba.co.jp>; Thu, 18 Mar 2004 02:55:07 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3R04-0003q1-00; Tue, 16 Mar 2004 18:41:44 -0800 Date: Tue, 16 Mar 2004 18:41:44 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 53 (proposed text) In-reply-to: <000001c40c15$7fb9b520$ed2f024b@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040317024144.GC14289@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040316234327.GG13346@steelhead> <000001c40c15$7fb9b520$ed2f024b@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Wed, Mar 17, 2004 at 03:46:34AM -0800, Alper Yegin wrote: > Yoshi, > > > - Append the following paragraph to section 4.9 (Mobility Handling): > > > > "If PAA has multiple interfaces connected to different IP links and > PaC > > changes its attached network from one IP link to another among the IP > > links of the PAA, the DiameterIdentity part of the Session-Id > > contained in the PANA-Start-Answer message will be the same as that of > > the PAA. In this case, the PAA can share the PANA session attributes > > of the PaC for the previous and new IP links, without using an > > external communication mechanism to retrieve the attributes." > > Actually it is not guaranteed that the DiameterIdentity would be the > same. There might be separate Diameter instances running for each > interface. OK. > > Also, even if they are not the same, that doesn't matter. I think the > point you are making is when the PAA node doesn't change, we don't need > to run a protocol to retrieve PANA attributes from. (I think this is > clear reading the current text, but I'm fine with an explicit text too). I prefer having an explicit text on this. How about the following text? "If PAA has multiple interfaces connected to different IP links and PaC changes its attached network from one IP link to another among the IP links of the PAA, the DiameterIdentity part of the Session-Id contained in the PANA-Start-Answer message will match one of the DiameterIdentity value(s) of the PAA. In this case, the PAA can share the PANA session attributes of the PaC for the previous and new IP links, without using an external communication mechanism to retrieve the attributes." Yoshihiro Ohba > > > Alper > > > > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Mar 17 13:00:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26711 for ; Wed, 17 Mar 2004 13:00:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fKq-0003sg-8Z for pana-archive@odin.ietf.org; Wed, 17 Mar 2004 13:00:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HI03r5014878 for pana-archive@odin.ietf.org; Wed, 17 Mar 2004 13:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fKl-0003rB-3I for pana-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 13:00:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26670 for ; Wed, 17 Mar 2004 12:59:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3fKU-0006fJ-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 12:59:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3fJY-0006Wb-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 12:58:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3fIs-0006OE-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 12:58:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fIp-0003kg-1H; Wed, 17 Mar 2004 12:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fIV-0003gV-53 for pana@optimus.ietf.org; Wed, 17 Mar 2004 12:57:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26458 for ; Wed, 17 Mar 2004 12:57:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3fIT-0006KK-00 for pana@ietf.org; Wed, 17 Mar 2004 12:57:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3fHT-000634-00 for pana@ietf.org; Wed, 17 Mar 2004 12:56:39 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3fG6-0005mm-00 for pana@ietf.org; Wed, 17 Mar 2004 12:55:14 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2HHtAKL022564; Thu, 18 Mar 2004 02:55:10 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2HHtAck023912; Thu, 18 Mar 2004 02:55:10 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA23909 ; Thu, 18 Mar 2004 02:55:10 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA07551; Thu, 18 Mar 2004 02:55:09 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA18537; Thu, 18 Mar 2004 02:55:09 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2HHt8b9008262; Thu, 18 Mar 2004 02:55:08 +0900 (JST) Received: from steelhead (att01-013.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUQ001PXF3TQH@tsbpo1.po.toshiba.co.jp>; Thu, 18 Mar 2004 02:55:07 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3R04-0003q1-00; Tue, 16 Mar 2004 18:41:44 -0800 Date: Tue, 16 Mar 2004 18:41:44 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 53 (proposed text) In-reply-to: <000001c40c15$7fb9b520$ed2f024b@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040317024144.GC14289@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040316234327.GG13346@steelhead> <000001c40c15$7fb9b520$ed2f024b@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 On Wed, Mar 17, 2004 at 03:46:34AM -0800, Alper Yegin wrote: > Yoshi, > > > - Append the following paragraph to section 4.9 (Mobility Handling): > > > > "If PAA has multiple interfaces connected to different IP links and > PaC > > changes its attached network from one IP link to another among the IP > > links of the PAA, the DiameterIdentity part of the Session-Id > > contained in the PANA-Start-Answer message will be the same as that of > > the PAA. In this case, the PAA can share the PANA session attributes > > of the PaC for the previous and new IP links, without using an > > external communication mechanism to retrieve the attributes." > > Actually it is not guaranteed that the DiameterIdentity would be the > same. There might be separate Diameter instances running for each > interface. OK. > > Also, even if they are not the same, that doesn't matter. I think the > point you are making is when the PAA node doesn't change, we don't need > to run a protocol to retrieve PANA attributes from. (I think this is > clear reading the current text, but I'm fine with an explicit text too). I prefer having an explicit text on this. How about the following text? "If PAA has multiple interfaces connected to different IP links and PaC changes its attached network from one IP link to another among the IP links of the PAA, the DiameterIdentity part of the Session-Id contained in the PANA-Start-Answer message will match one of the DiameterIdentity value(s) of the PAA. In this case, the PAA can share the PANA session attributes of the PaC for the previous and new IP links, without using an external communication mechanism to retrieve the attributes." Yoshihiro Ohba > > > Alper > > > > > > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Mar 17 19:50:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20480 for ; Wed, 17 Mar 2004 19:50:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ljV-0000iY-Qe; Wed, 17 Mar 2004 19:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ljQ-0000i9-L1 for pana@optimus.ietf.org; Wed, 17 Mar 2004 19:49:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20470 for ; Wed, 17 Mar 2004 19:49:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3ljO-0002Er-00 for pana@ietf.org; Wed, 17 Mar 2004 19:49:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3lia-00027P-00 for pana@ietf.org; Wed, 17 Mar 2004 19:49:05 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B3lhj-0001r0-00 for pana@ietf.org; Wed, 17 Mar 2004 19:48:11 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUQ0080BY7GKX@mailout3.samsung.com> for pana@ietf.org; Thu, 18 Mar 2004 09:47:40 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUQ008AMY731Y@mailout3.samsung.com> for pana@ietf.org; Thu, 18 Mar 2004 09:47:28 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUQ00LNYY7372@mmp2.samsung.com> for pana@ietf.org; Thu, 18 Mar 2004 09:47:27 +0900 (KST) Date: Wed, 17 Mar 2004 16:47:30 -0800 From: Alper Yegin Subject: RE: [Pana] issue 53 (proposed text) In-reply-to: <20040317024144.GC14289@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <004e01c40c82$97e18e80$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > I prefer having an explicit text on this. How about the following > text? > > "If PAA has multiple interfaces connected to different IP links and > PaC changes its attached network from one IP link to another among the > IP links of the PAA, the DiameterIdentity part of the Session-Id > contained in the PANA-Start-Answer message will match one of the > DiameterIdentity value(s) of the PAA. In this case, the PAA can share > the PANA session attributes of the PaC for the previous and new IP > links, without using an external communication mechanism to retrieve > the attributes." That looks good. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Mar 17 19:52:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20561 for ; Wed, 17 Mar 2004 19:52:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3llO-0000o9-Ry for pana-archive@odin.ietf.org; Wed, 17 Mar 2004 19:51:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I0pwfZ003104 for pana-archive@odin.ietf.org; Wed, 17 Mar 2004 19:51:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3llO-0000nz-NB for pana-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 19:51:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20553 for ; Wed, 17 Mar 2004 19:51:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3llM-0002V1-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 19:51:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3lkV-0002O9-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 19:51:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3ljb-0002Gf-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 19:50:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ljV-0000iY-Qe; Wed, 17 Mar 2004 19:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ljQ-0000i9-L1 for pana@optimus.ietf.org; Wed, 17 Mar 2004 19:49:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20470 for ; Wed, 17 Mar 2004 19:49:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3ljO-0002Er-00 for pana@ietf.org; Wed, 17 Mar 2004 19:49:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3lia-00027P-00 for pana@ietf.org; Wed, 17 Mar 2004 19:49:05 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B3lhj-0001r0-00 for pana@ietf.org; Wed, 17 Mar 2004 19:48:11 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUQ0080BY7GKX@mailout3.samsung.com> for pana@ietf.org; Thu, 18 Mar 2004 09:47:40 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUQ008AMY731Y@mailout3.samsung.com> for pana@ietf.org; Thu, 18 Mar 2004 09:47:28 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUQ00LNYY7372@mmp2.samsung.com> for pana@ietf.org; Thu, 18 Mar 2004 09:47:27 +0900 (KST) Date: Wed, 17 Mar 2004 16:47:30 -0800 From: Alper Yegin Subject: RE: [Pana] issue 53 (proposed text) In-reply-to: <20040317024144.GC14289@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <004e01c40c82$97e18e80$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > I prefer having an explicit text on this. How about the following > text? > > "If PAA has multiple interfaces connected to different IP links and > PaC changes its attached network from one IP link to another among the > IP links of the PAA, the DiameterIdentity part of the Session-Id > contained in the PANA-Start-Answer message will match one of the > DiameterIdentity value(s) of the PAA. In this case, the PAA can share > the PANA session attributes of the PaC for the previous and new IP > links, without using an external communication mechanism to retrieve > the attributes." That looks good. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Mar 17 20:05:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21076 for ; Wed, 17 Mar 2004 20:05:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ly3-0001Vh-9A; Wed, 17 Mar 2004 20:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3lxx-0001V6-TH for pana@optimus.ietf.org; Wed, 17 Mar 2004 20:04:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21071 for ; Wed, 17 Mar 2004 20:04:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3lxv-0004Gm-00 for pana@ietf.org; Wed, 17 Mar 2004 20:04:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3lx5-00049S-00 for pana@ietf.org; Wed, 17 Mar 2004 20:04:03 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1B3lwi-00041Z-00 for pana@ietf.org; Wed, 17 Mar 2004 20:03:41 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUQ00HWQYX9XH@mailout1.samsung.com> for pana@ietf.org; Thu, 18 Mar 2004 10:03:09 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUQ00G67YTAPD@mailout1.samsung.com> for pana@ietf.org; Thu, 18 Mar 2004 10:00:46 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUQ003P7YTAJL@mmp1.samsung.com> for pana@ietf.org; Thu, 18 Mar 2004 10:00:46 +0900 (KST) Date: Wed, 17 Mar 2004 17:00:49 -0800 From: Alper Yegin Subject: RE: [Pana] issue 57 (resolution) In-reply-to: <20040317015004.GA14670@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <006101c40c84$73c82750$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > I think whether a PDI/PSR/PSA retransmitted or not should not be indexed > > to cookie usage, but to solicited vs. unsolicited PSR. > > > > When PaC performs active discovery of PAAs by sending PDI, both PDI and > > PSA messages are retransmitted as needed, whereas PSR is not > > retransmitted by the PAA. > > > > When PAA discovery is performed in unsolicited fashion, PSR is > > retransmitted, and PSA is not. > > > > Does this make sense? > > I think indexing to solicited vs. unsolicited PSR also works. > > A difference from indexing to cookie usage is that it is possible that > PaC can operate in solicited mode while PAA is operating in > unsolicited mode at the same time. For example, PaC operating in > solicited mode sends PDI, while at the same time PAA operating in > unsolicited mode sends PSR. If it happens, I think all PDI, PSR and > PSA will be retransmitted if the retransmission strategy is based on > solicited vs. unsolicited PSR, which seems to be less efficient. > > By indexing to cookie usage (or indexing to stateless vs stateful > PAA), both PaC and PAA can always be synchronized to have the same > mode of operation about the retransmission strategy, i.e., when PSR is > retransmitted PSA is never retransmitted, and vise versa. > > What do you think? I see. You are using cookie as a tie-breaker. My concern, unless I'm missing something, is that there is no semantic relevance between the cookie usage and the retransmission policy. Some other clue could be used to stop one side from retransmitting. For example in my case, receipt of PDI by the PAA could cease the PSR retransmissions on the PAA. Alper > > Yoshihiro Ohba > - > > > > Alper > > > > > > > " > > > A PANA-Start-Request message that carries a Cookie AVP is never > > > retransmitted. A PANA-Start-Request message that does not carry a > > > Cookie AVP is retransmitted based on timer. A PANA-Start-Answer > > > message that carries a Cookie AVP is retransmitted based on timer. > > > A PANA-Start-Answer message that does not carry a Cookie AVP is > > > never retransmitted based on timer. > > > " > > > > > > Change the first paragraph of section 10 to: > > > > > > "The PANA protocol provides retransmissions for all the message > > > exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request > > messages > > > carry EAP requests which are retransmitted by the EAP protocol > > > entities when needed. The messages that need PANA-level > > > retransmissions are listed below: > > > > > > PANA-PAA-Discover (PDI) > > > PANA-Start-Request (PSR)* > > > PANA-Start-Answer (PSA)** > > > PANA-Bind-Request (PBR) > > > PANA-FirstAuth-End-Request (PFER) > > > PANA-Reauth-Request (PRAR) > > > PANA-Termination-Request (PTR) > > > > > > *) PSR that carries a Cookie AVP is not retransmitted. > > > **) PSA that does not carry a Cookie AVP is not retransmitted." > > > > > > > > > (Note: PFER message is introduced for issue 52.) > > > > > > Regards, > > > Yoshihiro Ohba > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Mar 17 20:07:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21225 for ; Wed, 17 Mar 2004 20:07:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3lzu-0001hK-TV for pana-archive@odin.ietf.org; Wed, 17 Mar 2004 20:06:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I16ws9006520 for pana-archive@odin.ietf.org; Wed, 17 Mar 2004 20:06:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3lzu-0001h5-PY for pana-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 20:06:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21199 for ; Wed, 17 Mar 2004 20:06:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3lzs-0004YE-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 20:06:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3lyv-0004Q8-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 20:05:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3ly3-0004ID-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 20:05:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ly3-0001Vh-9A; Wed, 17 Mar 2004 20:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3lxx-0001V6-TH for pana@optimus.ietf.org; Wed, 17 Mar 2004 20:04:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21071 for ; Wed, 17 Mar 2004 20:04:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3lxv-0004Gm-00 for pana@ietf.org; Wed, 17 Mar 2004 20:04:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3lx5-00049S-00 for pana@ietf.org; Wed, 17 Mar 2004 20:04:03 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1B3lwi-00041Z-00 for pana@ietf.org; Wed, 17 Mar 2004 20:03:41 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUQ00HWQYX9XH@mailout1.samsung.com> for pana@ietf.org; Thu, 18 Mar 2004 10:03:09 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUQ00G67YTAPD@mailout1.samsung.com> for pana@ietf.org; Thu, 18 Mar 2004 10:00:46 +0900 (KST) Received: from Alperyegin ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUQ003P7YTAJL@mmp1.samsung.com> for pana@ietf.org; Thu, 18 Mar 2004 10:00:46 +0900 (KST) Date: Wed, 17 Mar 2004 17:00:49 -0800 From: Alper Yegin Subject: RE: [Pana] issue 57 (resolution) In-reply-to: <20040317015004.GA14670@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <006101c40c84$73c82750$ed2f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > I think whether a PDI/PSR/PSA retransmitted or not should not be indexed > > to cookie usage, but to solicited vs. unsolicited PSR. > > > > When PaC performs active discovery of PAAs by sending PDI, both PDI and > > PSA messages are retransmitted as needed, whereas PSR is not > > retransmitted by the PAA. > > > > When PAA discovery is performed in unsolicited fashion, PSR is > > retransmitted, and PSA is not. > > > > Does this make sense? > > I think indexing to solicited vs. unsolicited PSR also works. > > A difference from indexing to cookie usage is that it is possible that > PaC can operate in solicited mode while PAA is operating in > unsolicited mode at the same time. For example, PaC operating in > solicited mode sends PDI, while at the same time PAA operating in > unsolicited mode sends PSR. If it happens, I think all PDI, PSR and > PSA will be retransmitted if the retransmission strategy is based on > solicited vs. unsolicited PSR, which seems to be less efficient. > > By indexing to cookie usage (or indexing to stateless vs stateful > PAA), both PaC and PAA can always be synchronized to have the same > mode of operation about the retransmission strategy, i.e., when PSR is > retransmitted PSA is never retransmitted, and vise versa. > > What do you think? I see. You are using cookie as a tie-breaker. My concern, unless I'm missing something, is that there is no semantic relevance between the cookie usage and the retransmission policy. Some other clue could be used to stop one side from retransmitting. For example in my case, receipt of PDI by the PAA could cease the PSR retransmissions on the PAA. Alper > > Yoshihiro Ohba > - > > > > Alper > > > > > > > " > > > A PANA-Start-Request message that carries a Cookie AVP is never > > > retransmitted. A PANA-Start-Request message that does not carry a > > > Cookie AVP is retransmitted based on timer. A PANA-Start-Answer > > > message that carries a Cookie AVP is retransmitted based on timer. > > > A PANA-Start-Answer message that does not carry a Cookie AVP is > > > never retransmitted based on timer. > > > " > > > > > > Change the first paragraph of section 10 to: > > > > > > "The PANA protocol provides retransmissions for all the message > > > exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request > > messages > > > carry EAP requests which are retransmitted by the EAP protocol > > > entities when needed. The messages that need PANA-level > > > retransmissions are listed below: > > > > > > PANA-PAA-Discover (PDI) > > > PANA-Start-Request (PSR)* > > > PANA-Start-Answer (PSA)** > > > PANA-Bind-Request (PBR) > > > PANA-FirstAuth-End-Request (PFER) > > > PANA-Reauth-Request (PRAR) > > > PANA-Termination-Request (PTR) > > > > > > *) PSR that carries a Cookie AVP is not retransmitted. > > > **) PSA that does not carry a Cookie AVP is not retransmitted." > > > > > > > > > (Note: PFER message is introduced for issue 52.) > > > > > > Regards, > > > Yoshihiro Ohba > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Mar 17 21:02:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24418 for ; Wed, 17 Mar 2004 21:02:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3mrC-0005S3-2Y; Wed, 17 Mar 2004 21:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3mqD-0005Ly-3z for pana@optimus.ietf.org; Wed, 17 Mar 2004 21:01:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24324 for ; Wed, 17 Mar 2004 21:00:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3mqA-0004qg-00 for pana@ietf.org; Wed, 17 Mar 2004 21:00:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3mpE-0004iv-00 for pana@ietf.org; Wed, 17 Mar 2004 21:00:01 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3moi-0004bj-00 for pana@ietf.org; Wed, 17 Mar 2004 20:59:28 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2I1xQKL019988; Thu, 18 Mar 2004 10:59:26 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2I1xQS1024726; Thu, 18 Mar 2004 10:59:26 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA24713 ; Thu, 18 Mar 2004 10:59:25 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA21333; Thu, 18 Mar 2004 10:59:25 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA25787; Thu, 18 Mar 2004 10:59:22 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2I1xLPb026721; Thu, 18 Mar 2004 10:59:22 +0900 (JST) Received: from steelhead (att01-009.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUR003QT1IUP6@tsbpo1.po.toshiba.co.jp>; Thu, 18 Mar 2004 10:59:20 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3TSV-0003ut-00; Tue, 16 Mar 2004 21:19:15 -0800 Date: Tue, 16 Mar 2004 21:19:15 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 57 (resolution) In-reply-to: <006101c40c84$73c82750$ed2f024b@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040317051915.GH14289@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040317015004.GA14670@steelhead> <006101c40c84$73c82750$ed2f024b@sisa.samsung.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Wed, Mar 17, 2004 at 05:00:49PM -0800, Alper Yegin wrote: > > > I think whether a PDI/PSR/PSA retransmitted or not should not be > indexed > > > to cookie usage, but to solicited vs. unsolicited PSR. > > > > > > When PaC performs active discovery of PAAs by sending PDI, both PDI > and > > > PSA messages are retransmitted as needed, whereas PSR is not > > > retransmitted by the PAA. > > > > > > When PAA discovery is performed in unsolicited fashion, PSR is > > > retransmitted, and PSA is not. > > > > > > Does this make sense? > > > > I think indexing to solicited vs. unsolicited PSR also works. > > > > A difference from indexing to cookie usage is that it is possible that > > PaC can operate in solicited mode while PAA is operating in > > unsolicited mode at the same time. For example, PaC operating in > > solicited mode sends PDI, while at the same time PAA operating in > > unsolicited mode sends PSR. If it happens, I think all PDI, PSR and > > PSA will be retransmitted if the retransmission strategy is based on > > solicited vs. unsolicited PSR, which seems to be less efficient. > > > > By indexing to cookie usage (or indexing to stateless vs stateful > > PAA), both PaC and PAA can always be synchronized to have the same > > mode of operation about the retransmission strategy, i.e., when PSR is > > retransmitted PSA is never retransmitted, and vise versa. > > > > What do you think? > > I see. You are using cookie as a tie-breaker. My concern, unless I'm > missing something, is that there is no semantic relevance between the > cookie usage and the retransmission policy. I understand your concern. Let me explain a semantic relevance as follows: - PDI is retransmitted whatever information is used as a tie-breaker. - As a general retransmission policy, in a request/answer exchange, the requester should take the responsibility of retransmission. - There is an exception. If the requester remains stateless after sending a request, the responder should take the responsibility of retransmission. This cases occurs only for PSR/PSA exchange, and retransmission of PDI and PSA can archieve the responsibility. The presence of the cookie indicates that the requester remains stateless. > Some other clue could be > used to stop one side from retransmitting. For example in my case, > receipt of PDI by the PAA could cease the PSR retransmissions on the > PAA. That is also possible. Which strategy do you think is better? Yoshihiro Ohba > > Alper > > > > > > > > > > > > > > Yoshihiro Ohba > > - > > > > > > Alper > > > > > > > > > > " > > > > A PANA-Start-Request message that carries a Cookie AVP is never > > > > retransmitted. A PANA-Start-Request message that does not > carry a > > > > Cookie AVP is retransmitted based on timer. A > PANA-Start-Answer > > > > message that carries a Cookie AVP is retransmitted based on > timer. > > > > A PANA-Start-Answer message that does not carry a Cookie AVP is > > > > never retransmitted based on timer. > > > > " > > > > > > > > Change the first paragraph of section 10 to: > > > > > > > > "The PANA protocol provides retransmissions for all the message > > > > exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request > > > messages > > > > carry EAP requests which are retransmitted by the EAP protocol > > > > entities when needed. The messages that need PANA-level > > > > retransmissions are listed below: > > > > > > > > PANA-PAA-Discover (PDI) > > > > PANA-Start-Request (PSR)* > > > > PANA-Start-Answer (PSA)** > > > > PANA-Bind-Request (PBR) > > > > PANA-FirstAuth-End-Request (PFER) > > > > PANA-Reauth-Request (PRAR) > > > > PANA-Termination-Request (PTR) > > > > > > > > *) PSR that carries a Cookie AVP is not retransmitted. > > > > **) PSA that does not carry a Cookie AVP is not retransmitted." > > > > > > > > > > > > (Note: PFER message is introduced for issue 52.) > > > > > > > > Regards, > > > > Yoshihiro Ohba > > > > > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Mar 17 21:04:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24574 for ; Wed, 17 Mar 2004 21:04:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3mt9-0005eV-M1 for pana-archive@odin.ietf.org; Wed, 17 Mar 2004 21:04:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I243hg021723 for pana-archive@odin.ietf.org; Wed, 17 Mar 2004 21:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3mt9-0005eI-GO for pana-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 21:04:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24530 for ; Wed, 17 Mar 2004 21:04:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3mt6-0005HU-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 21:04:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ms6-000580-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 21:02:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3mrD-0004zp-00 for pana-web-archive@ietf.org; Wed, 17 Mar 2004 21:02:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3mrC-0005S3-2Y; Wed, 17 Mar 2004 21:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3mqD-0005Ly-3z for pana@optimus.ietf.org; Wed, 17 Mar 2004 21:01:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24324 for ; Wed, 17 Mar 2004 21:00:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3mqA-0004qg-00 for pana@ietf.org; Wed, 17 Mar 2004 21:00:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3mpE-0004iv-00 for pana@ietf.org; Wed, 17 Mar 2004 21:00:01 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B3moi-0004bj-00 for pana@ietf.org; Wed, 17 Mar 2004 20:59:28 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2I1xQKL019988; Thu, 18 Mar 2004 10:59:26 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2I1xQS1024726; Thu, 18 Mar 2004 10:59:26 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA24713 ; Thu, 18 Mar 2004 10:59:25 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA21333; Thu, 18 Mar 2004 10:59:25 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id KAA25787; Thu, 18 Mar 2004 10:59:22 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2I1xLPb026721; Thu, 18 Mar 2004 10:59:22 +0900 (JST) Received: from steelhead (att01-009.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUR003QT1IUP6@tsbpo1.po.toshiba.co.jp>; Thu, 18 Mar 2004 10:59:20 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3TSV-0003ut-00; Tue, 16 Mar 2004 21:19:15 -0800 Date: Tue, 16 Mar 2004 21:19:15 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 57 (resolution) In-reply-to: <006101c40c84$73c82750$ed2f024b@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040317051915.GH14289@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , 'Yoshihiro Ohba' , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <20040317015004.GA14670@steelhead> <006101c40c84$73c82750$ed2f024b@sisa.samsung.com> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_12_24 autolearn=no version=2.60 On Wed, Mar 17, 2004 at 05:00:49PM -0800, Alper Yegin wrote: > > > I think whether a PDI/PSR/PSA retransmitted or not should not be > indexed > > > to cookie usage, but to solicited vs. unsolicited PSR. > > > > > > When PaC performs active discovery of PAAs by sending PDI, both PDI > and > > > PSA messages are retransmitted as needed, whereas PSR is not > > > retransmitted by the PAA. > > > > > > When PAA discovery is performed in unsolicited fashion, PSR is > > > retransmitted, and PSA is not. > > > > > > Does this make sense? > > > > I think indexing to solicited vs. unsolicited PSR also works. > > > > A difference from indexing to cookie usage is that it is possible that > > PaC can operate in solicited mode while PAA is operating in > > unsolicited mode at the same time. For example, PaC operating in > > solicited mode sends PDI, while at the same time PAA operating in > > unsolicited mode sends PSR. If it happens, I think all PDI, PSR and > > PSA will be retransmitted if the retransmission strategy is based on > > solicited vs. unsolicited PSR, which seems to be less efficient. > > > > By indexing to cookie usage (or indexing to stateless vs stateful > > PAA), both PaC and PAA can always be synchronized to have the same > > mode of operation about the retransmission strategy, i.e., when PSR is > > retransmitted PSA is never retransmitted, and vise versa. > > > > What do you think? > > I see. You are using cookie as a tie-breaker. My concern, unless I'm > missing something, is that there is no semantic relevance between the > cookie usage and the retransmission policy. I understand your concern. Let me explain a semantic relevance as follows: - PDI is retransmitted whatever information is used as a tie-breaker. - As a general retransmission policy, in a request/answer exchange, the requester should take the responsibility of retransmission. - There is an exception. If the requester remains stateless after sending a request, the responder should take the responsibility of retransmission. This cases occurs only for PSR/PSA exchange, and retransmission of PDI and PSA can archieve the responsibility. The presence of the cookie indicates that the requester remains stateless. > Some other clue could be > used to stop one side from retransmitting. For example in my case, > receipt of PDI by the PAA could cease the PSR retransmissions on the > PAA. That is also possible. Which strategy do you think is better? Yoshihiro Ohba > > Alper > > > > > > > > > > > > > > Yoshihiro Ohba > > - > > > > > > Alper > > > > > > > > > > " > > > > A PANA-Start-Request message that carries a Cookie AVP is never > > > > retransmitted. A PANA-Start-Request message that does not > carry a > > > > Cookie AVP is retransmitted based on timer. A > PANA-Start-Answer > > > > message that carries a Cookie AVP is retransmitted based on > timer. > > > > A PANA-Start-Answer message that does not carry a Cookie AVP is > > > > never retransmitted based on timer. > > > > " > > > > > > > > Change the first paragraph of section 10 to: > > > > > > > > "The PANA protocol provides retransmissions for all the message > > > > exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request > > > messages > > > > carry EAP requests which are retransmitted by the EAP protocol > > > > entities when needed. The messages that need PANA-level > > > > retransmissions are listed below: > > > > > > > > PANA-PAA-Discover (PDI) > > > > PANA-Start-Request (PSR)* > > > > PANA-Start-Answer (PSA)** > > > > PANA-Bind-Request (PBR) > > > > PANA-FirstAuth-End-Request (PFER) > > > > PANA-Reauth-Request (PRAR) > > > > PANA-Termination-Request (PTR) > > > > > > > > *) PSR that carries a Cookie AVP is not retransmitted. > > > > **) PSA that does not carry a Cookie AVP is not retransmitted." > > > > > > > > > > > > (Note: PFER message is introduced for issue 52.) > > > > > > > > Regards, > > > > Yoshihiro Ohba > > > > > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Mar 18 09:53:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15169 for ; Thu, 18 Mar 2004 09:53:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yrx-0004ZB-K2; Thu, 18 Mar 2004 09:51:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yqf-0004WE-I1 for pana@optimus.ietf.org; Thu, 18 Mar 2004 09:50:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14905; Thu, 18 Mar 2004 09:50:13 -0500 (EST) Message-Id: <200403181450.JAA14905@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: pana@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 18 Mar 2004 09:50:13 -0500 Subject: [Pana] I-D ACTION:draft-ietf-pana-ipsec-02.txt Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol for carrying Authentication for Network Access Working Group of the IETF. Title : PANA enabling IPsec based Access Control Author(s) : M. Parthasarathy Filename : draft-ietf-pana-ipsec-02.txt Pages : 13 Date : 2004-3-17 The PANA (Protocol for carrying Authentication for Network Access) working group is developing protocol for authenticating clients to the access network using IP based protocols. The PANA protocol authenticates the client and also establishes a PANA security association between the PANA client and PANA authentication agent at the end of a successful authentication. This document discusses the details for establishing an IPsec security association using the PANA security association for enabling IPsec based access control. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-ipsec-02.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-ipsec-02.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-ipsec-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-18101344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pana-ipsec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pana-ipsec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-18101344.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Mar 18 09:56:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15393 for ; Thu, 18 Mar 2004 09:56:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yvt-00054b-E5 for pana-archive@odin.ietf.org; Thu, 18 Mar 2004 09:55:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IEtVEv019468 for pana-archive@odin.ietf.org; Thu, 18 Mar 2004 09:55:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yvi-00053g-SB for pana-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 09:55:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15299 for ; Thu, 18 Mar 2004 09:55:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yva-0001IY-00 for pana-web-archive@ietf.org; Thu, 18 Mar 2004 09:55:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yub-00019J-00 for pana-web-archive@ietf.org; Thu, 18 Mar 2004 09:54:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3ytb-0000zh-00 for pana-web-archive@ietf.org; Thu, 18 Mar 2004 09:53:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yrx-0004ZB-K2; Thu, 18 Mar 2004 09:51:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yqf-0004WE-I1 for pana@optimus.ietf.org; Thu, 18 Mar 2004 09:50:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14905; Thu, 18 Mar 2004 09:50:13 -0500 (EST) Message-Id: <200403181450.JAA14905@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: pana@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 18 Mar 2004 09:50:13 -0500 Subject: [Pana] I-D ACTION:draft-ietf-pana-ipsec-02.txt Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol for carrying Authentication for Network Access Working Group of the IETF. Title : PANA enabling IPsec based Access Control Author(s) : M. Parthasarathy Filename : draft-ietf-pana-ipsec-02.txt Pages : 13 Date : 2004-3-17 The PANA (Protocol for carrying Authentication for Network Access) working group is developing protocol for authenticating clients to the access network using IP based protocols. The PANA protocol authenticates the client and also establishes a PANA security association between the PANA client and PANA authentication agent at the end of a successful authentication. This document discusses the details for establishing an IPsec security association using the PANA security association for enabling IPsec based access control. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-ipsec-02.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-ipsec-02.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-ipsec-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-3-18101344.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pana-ipsec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pana-ipsec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-3-18101344.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Mar 18 20:32:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21967 for ; Thu, 18 Mar 2004 20:32:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B48rg-0004ND-OD; Thu, 18 Mar 2004 20:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B48rO-0004Mj-86 for pana@optimus.ietf.org; Thu, 18 Mar 2004 20:31:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21939 for ; Thu, 18 Mar 2004 20:31:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B48rL-0007VO-00 for pana@ietf.org; Thu, 18 Mar 2004 20:31:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B48qN-0007Ry-00 for pana@ietf.org; Thu, 18 Mar 2004 20:30:40 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B48pS-0007MW-00 for pana@ietf.org; Thu, 18 Mar 2004 20:29:42 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUS00C04USOVQ@mailout3.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 10:29:12 +0900 (KST) Received: from ep_ms13_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUS00CGIUSN4H@mailout3.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 10:29:11 +0900 (KST) Received: from ep_spt04 (ms13.samsung.com [203.254.225.109]) by ms13.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUS008SMUSNA2@ms13.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 10:29:11 +0900 (KST) Content-return: prohibited Date: Fri, 19 Mar 2004 01:29:33 +0000 (GMT) From: Alper Yegin Subject: RE: [Pana] issue 57 (resolution) X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9TSVNBP1NlbmlvciBFbmdpbmVlcg==?= To: yohba@tari.toshiba.com, pana@ietf.org Reply-to: alper.yegin@samsung.com Message-id: <6521797.1079659714038.JavaMail.weblogic@ep_app35> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040319012834019@alper.yegin X-MTR: 20040319012834019@alper.yegin X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > - PDI is retransmitted whatever information is used as a tie-breaker. > > - As a general retransmission policy, in a request/answer exchange, the > requester should take the responsibility of retransmission. > > - There is an exception. If the requester remains stateless after > sending a request, the responder should take the responsibility of > retransmission. This cases occurs only for PSR/PSA exchange, and > retransmission of PDI and PSA can archieve the responsibility. The > presence of the cookie indicates that the requester remains stateless. If there is no PDI, and PSR is not retransmitted at all, when the single PSR is lost, the PANA exchange will hang. I understand your point. I guess the problem is, "being stateless" and "performing unsolicited PAA discovery" do not mix well. > > > Some other clue could be > > used to stop one side from retransmitting. For example in my case, > > receipt of PDI by the PAA could cease the PSR retransmissions on the > > PAA. > > That is also possible. Which strategy do you think is better? > > Yoshihiro Ohba Alper > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > Yoshihiro Ohba > > > - > > > > > > > > Alper > > > > > > > > > > > > > " > > > > > A PANA-Start-Request message that carries a Cookie AVP is never > > > > > retransmitted. A PANA-Start-Request message that does not > > carry a > > > > > Cookie AVP is retransmitted based on timer. A > > PANA-Start-Answer > > > > > message that carries a Cookie AVP is retransmitted based on > > timer. > > > > > A PANA-Start-Answer message that does not carry a Cookie AVP is > > > > > never retransmitted based on timer. > > > > > " > > > > > > > > > > Change the first paragraph of section 10 to: > > > > > > > > > > "The PANA protocol provides retransmissions for all the message > > > > > exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request > > > > messages > > > > > carry EAP requests which are retransmitted by the EAP protocol > > > > > entities when needed. The messages that need PANA-level > > > > > retransmissions are listed below: > > > > > > > > > > PANA-PAA-Discover (PDI) > > > > > PANA-Start-Request (PSR)* > > > > > PANA-Start-Answer (PSA)** > > > > > PANA-Bind-Request (PBR) > > > > > PANA-FirstAuth-End-Request (PFER) > > > > > PANA-Reauth-Request (PRAR) > > > > > PANA-Termination-Request (PTR) > > > > > > > > > > *) PSR that carries a Cookie AVP is not retransmitted. > > > > > **) PSA that does not carry a Cookie AVP is not retransmitted." > > > > > > > > > > > > > > > (Note: PFER message is introduced for issue 52.) > > > > > > > > > > Regards, > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pana mailing list > > > > > Pana@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Mar 18 20:34:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22034 for ; Thu, 18 Mar 2004 20:34:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B48tP-0004Rr-7m for pana-archive@odin.ietf.org; Thu, 18 Mar 2004 20:33:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J1XlcQ017098 for pana-archive@odin.ietf.org; Thu, 18 Mar 2004 20:33:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B48tO-0004Rh-Vn for pana-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 20:33:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22026 for ; Thu, 18 Mar 2004 20:33:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B48tM-0007cc-00 for pana-web-archive@ietf.org; Thu, 18 Mar 2004 20:33:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B48sU-0007Zo-00 for pana-web-archive@ietf.org; Thu, 18 Mar 2004 20:32:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B48rr-0007Wz-00 for pana-web-archive@ietf.org; Thu, 18 Mar 2004 20:32:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B48rg-0004ND-OD; Thu, 18 Mar 2004 20:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B48rO-0004Mj-86 for pana@optimus.ietf.org; Thu, 18 Mar 2004 20:31:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21939 for ; Thu, 18 Mar 2004 20:31:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B48rL-0007VO-00 for pana@ietf.org; Thu, 18 Mar 2004 20:31:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B48qN-0007Ry-00 for pana@ietf.org; Thu, 18 Mar 2004 20:30:40 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B48pS-0007MW-00 for pana@ietf.org; Thu, 18 Mar 2004 20:29:42 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUS00C04USOVQ@mailout3.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 10:29:12 +0900 (KST) Received: from ep_ms13_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUS00CGIUSN4H@mailout3.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 10:29:11 +0900 (KST) Received: from ep_spt04 (ms13.samsung.com [203.254.225.109]) by ms13.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUS008SMUSNA2@ms13.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 10:29:11 +0900 (KST) Content-return: prohibited Date: Fri, 19 Mar 2004 01:29:33 +0000 (GMT) From: Alper Yegin Subject: RE: [Pana] issue 57 (resolution) X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9TSVNBP1NlbmlvciBFbmdpbmVlcg==?= To: yohba@tari.toshiba.com, pana@ietf.org Reply-to: alper.yegin@samsung.com Message-id: <6521797.1079659714038.JavaMail.weblogic@ep_app35> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040319012834019@alper.yegin X-MTR: 20040319012834019@alper.yegin X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > - PDI is retransmitted whatever information is used as a tie-breaker. > > - As a general retransmission policy, in a request/answer exchange, the > requester should take the responsibility of retransmission. > > - There is an exception. If the requester remains stateless after > sending a request, the responder should take the responsibility of > retransmission. This cases occurs only for PSR/PSA exchange, and > retransmission of PDI and PSA can archieve the responsibility. The > presence of the cookie indicates that the requester remains stateless. If there is no PDI, and PSR is not retransmitted at all, when the single PSR is lost, the PANA exchange will hang. I understand your point. I guess the problem is, "being stateless" and "performing unsolicited PAA discovery" do not mix well. > > > Some other clue could be > > used to stop one side from retransmitting. For example in my case, > > receipt of PDI by the PAA could cease the PSR retransmissions on the > > PAA. > > That is also possible. Which strategy do you think is better? > > Yoshihiro Ohba Alper > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > Yoshihiro Ohba > > > - > > > > > > > > Alper > > > > > > > > > > > > > " > > > > > A PANA-Start-Request message that carries a Cookie AVP is never > > > > > retransmitted. A PANA-Start-Request message that does not > > carry a > > > > > Cookie AVP is retransmitted based on timer. A > > PANA-Start-Answer > > > > > message that carries a Cookie AVP is retransmitted based on > > timer. > > > > > A PANA-Start-Answer message that does not carry a Cookie AVP is > > > > > never retransmitted based on timer. > > > > > " > > > > > > > > > > Change the first paragraph of section 10 to: > > > > > > > > > > "The PANA protocol provides retransmissions for all the message > > > > > exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request > > > > messages > > > > > carry EAP requests which are retransmitted by the EAP protocol > > > > > entities when needed. The messages that need PANA-level > > > > > retransmissions are listed below: > > > > > > > > > > PANA-PAA-Discover (PDI) > > > > > PANA-Start-Request (PSR)* > > > > > PANA-Start-Answer (PSA)** > > > > > PANA-Bind-Request (PBR) > > > > > PANA-FirstAuth-End-Request (PFER) > > > > > PANA-Reauth-Request (PRAR) > > > > > PANA-Termination-Request (PTR) > > > > > > > > > > *) PSR that carries a Cookie AVP is not retransmitted. > > > > > **) PSA that does not carry a Cookie AVP is not retransmitted." > > > > > > > > > > > > > > > (Note: PFER message is introduced for issue 52.) > > > > > > > > > > Regards, > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pana mailing list > > > > > Pana@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > _______________________________________________ > > > > Pana mailing list > > > > Pana@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Mar 18 22:26:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25684 for ; Thu, 18 Mar 2004 22:26:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Ae2-0003NI-P9; Thu, 18 Mar 2004 22:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Adt-0003Ll-PN for pana@optimus.ietf.org; Thu, 18 Mar 2004 22:25:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25663 for ; Thu, 18 Mar 2004 22:25:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Adq-00072n-00 for pana@ietf.org; Thu, 18 Mar 2004 22:25:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Acy-0006ym-00 for pana@ietf.org; Thu, 18 Mar 2004 22:24:57 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B4AcE-0006u1-00 for pana@ietf.org; Thu, 18 Mar 2004 22:24:10 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2J3O9KL022557; Fri, 19 Mar 2004 12:24:09 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2J3O8SY005327; Fri, 19 Mar 2004 12:24:08 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id NAA05322 ; Fri, 19 Mar 2004 12:24:08 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id MAA07777; Fri, 19 Mar 2004 12:24:08 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id MAA26462; Fri, 19 Mar 2004 12:24:08 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2J3O6Db019802; Fri, 19 Mar 2004 12:24:07 +0900 (JST) Received: from steelhead (iVPN11-049.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUT00B8Q045LF@tsbpo1.po.toshiba.co.jp>; Fri, 19 Mar 2004 12:24:06 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3ZE9-0005eA-00; Wed, 17 Mar 2004 03:28:49 -0800 Date: Wed, 17 Mar 2004 03:28:49 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 57 (resolution) In-reply-to: <6521797.1079659714038.JavaMail.weblogic@ep_app35> To: Alper Yegin Cc: yohba@tari.toshiba.com, pana@ietf.org Message-id: <20040317112849.GA21689@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , yohba@tari.toshiba.com, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <6521797.1079659714038.JavaMail.weblogic@ep_app35> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Fri, Mar 19, 2004 at 01:29:33AM +0000, Alper Yegin wrote: > > - PDI is retransmitted whatever information is used as a tie-breaker. > > > > - As a general retransmission policy, in a request/answer exchange, the > > requester should take the responsibility of retransmission. > > > > - There is an exception. If the requester remains stateless after > > sending a request, the responder should take the responsibility of > > retransmission. This cases occurs only for PSR/PSA exchange, and > > retransmission of PDI and PSA can archieve the responsibility. The > > presence of the cookie indicates that the requester remains stateless. > > If there is no PDI, and PSR is not retransmitted at all, when the single PSR > is lost, the PANA exchange will hang. Right. That is why I used "retransmission of PDI and PSA". > > I understand your point. I guess the problem is, "being stateless" and > "performing unsolicited PAA discovery" do not mix well. Yes, When PAA is performing unsolicited PAA discovery, the PAA should be stateful, otherwise the PANA exchange will hang if PSR is lost. On the other hand, when PAA is perfomring solicited PAA discovery, it can be either stateless or stateful. Yoshihiro Ohba > > > > > > Some other clue could be > > > used to stop one side from retransmitting. For example in my case, > > > receipt of PDI by the PAA could cease the PSR retransmissions on the > > > PAA. > > > > That is also possible. Which strategy do you think is better? > > > > Yoshihiro Ohba > > Alper > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yoshihiro Ohba > > > > - > > > > > > > > > > Alper > > > > > > > > > > > > > > > > " > > > > > > A PANA-Start-Request message that carries a Cookie AVP is never > > > > > > retransmitted. A PANA-Start-Request message that does not > > > carry a > > > > > > Cookie AVP is retransmitted based on timer. A > > > PANA-Start-Answer > > > > > > message that carries a Cookie AVP is retransmitted based on > > > timer. > > > > > > A PANA-Start-Answer message that does not carry a Cookie AVP is > > > > > > never retransmitted based on timer. > > > > > > " > > > > > > > > > > > > Change the first paragraph of section 10 to: > > > > > > > > > > > > "The PANA protocol provides retransmissions for all the message > > > > > > exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request > > > > > messages > > > > > > carry EAP requests which are retransmitted by the EAP protocol > > > > > > entities when needed. The messages that need PANA-level > > > > > > retransmissions are listed below: > > > > > > > > > > > > PANA-PAA-Discover (PDI) > > > > > > PANA-Start-Request (PSR)* > > > > > > PANA-Start-Answer (PSA)** > > > > > > PANA-Bind-Request (PBR) > > > > > > PANA-FirstAuth-End-Request (PFER) > > > > > > PANA-Reauth-Request (PRAR) > > > > > > PANA-Termination-Request (PTR) > > > > > > > > > > > > *) PSR that carries a Cookie AVP is not retransmitted. > > > > > > **) PSA that does not carry a Cookie AVP is not retransmitted." > > > > > > > > > > > > > > > > > > (Note: PFER message is introduced for issue 52.) > > > > > > > > > > > > Regards, > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pana mailing list > > > > > > Pana@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pana mailing list > > > > > Pana@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Mar 18 22:28:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25835 for ; Thu, 18 Mar 2004 22:28:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Ag6-0003WM-5s for pana-archive@odin.ietf.org; Thu, 18 Mar 2004 22:28:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J3SAie013533 for pana-archive@odin.ietf.org; Thu, 18 Mar 2004 22:28:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Ag6-0003WC-1q for pana-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 22:28:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25802 for ; Thu, 18 Mar 2004 22:28:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Ag2-0007Hj-00 for pana-web-archive@ietf.org; Thu, 18 Mar 2004 22:28:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Af1-0007As-00 for pana-web-archive@ietf.org; Thu, 18 Mar 2004 22:27:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4Ae7-00075K-00 for pana-web-archive@ietf.org; Thu, 18 Mar 2004 22:26:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Ae2-0003NI-P9; Thu, 18 Mar 2004 22:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Adt-0003Ll-PN for pana@optimus.ietf.org; Thu, 18 Mar 2004 22:25:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25663 for ; Thu, 18 Mar 2004 22:25:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Adq-00072n-00 for pana@ietf.org; Thu, 18 Mar 2004 22:25:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Acy-0006ym-00 for pana@ietf.org; Thu, 18 Mar 2004 22:24:57 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B4AcE-0006u1-00 for pana@ietf.org; Thu, 18 Mar 2004 22:24:10 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2J3O9KL022557; Fri, 19 Mar 2004 12:24:09 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2J3O8SY005327; Fri, 19 Mar 2004 12:24:08 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id NAA05322 ; Fri, 19 Mar 2004 12:24:08 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id MAA07777; Fri, 19 Mar 2004 12:24:08 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id MAA26462; Fri, 19 Mar 2004 12:24:08 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2J3O6Db019802; Fri, 19 Mar 2004 12:24:07 +0900 (JST) Received: from steelhead (iVPN11-049.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUT00B8Q045LF@tsbpo1.po.toshiba.co.jp>; Fri, 19 Mar 2004 12:24:06 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3ZE9-0005eA-00; Wed, 17 Mar 2004 03:28:49 -0800 Date: Wed, 17 Mar 2004 03:28:49 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 57 (resolution) In-reply-to: <6521797.1079659714038.JavaMail.weblogic@ep_app35> To: Alper Yegin Cc: yohba@tari.toshiba.com, pana@ietf.org Message-id: <20040317112849.GA21689@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , yohba@tari.toshiba.com, pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <6521797.1079659714038.JavaMail.weblogic@ep_app35> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, Mar 19, 2004 at 01:29:33AM +0000, Alper Yegin wrote: > > - PDI is retransmitted whatever information is used as a tie-breaker. > > > > - As a general retransmission policy, in a request/answer exchange, the > > requester should take the responsibility of retransmission. > > > > - There is an exception. If the requester remains stateless after > > sending a request, the responder should take the responsibility of > > retransmission. This cases occurs only for PSR/PSA exchange, and > > retransmission of PDI and PSA can archieve the responsibility. The > > presence of the cookie indicates that the requester remains stateless. > > If there is no PDI, and PSR is not retransmitted at all, when the single PSR > is lost, the PANA exchange will hang. Right. That is why I used "retransmission of PDI and PSA". > > I understand your point. I guess the problem is, "being stateless" and > "performing unsolicited PAA discovery" do not mix well. Yes, When PAA is performing unsolicited PAA discovery, the PAA should be stateful, otherwise the PANA exchange will hang if PSR is lost. On the other hand, when PAA is perfomring solicited PAA discovery, it can be either stateless or stateful. Yoshihiro Ohba > > > > > > Some other clue could be > > > used to stop one side from retransmitting. For example in my case, > > > receipt of PDI by the PAA could cease the PSR retransmissions on the > > > PAA. > > > > That is also possible. Which strategy do you think is better? > > > > Yoshihiro Ohba > > Alper > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yoshihiro Ohba > > > > - > > > > > > > > > > Alper > > > > > > > > > > > > > > > > " > > > > > > A PANA-Start-Request message that carries a Cookie AVP is never > > > > > > retransmitted. A PANA-Start-Request message that does not > > > carry a > > > > > > Cookie AVP is retransmitted based on timer. A > > > PANA-Start-Answer > > > > > > message that carries a Cookie AVP is retransmitted based on > > > timer. > > > > > > A PANA-Start-Answer message that does not carry a Cookie AVP is > > > > > > never retransmitted based on timer. > > > > > > " > > > > > > > > > > > > Change the first paragraph of section 10 to: > > > > > > > > > > > > "The PANA protocol provides retransmissions for all the message > > > > > > exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request > > > > > messages > > > > > > carry EAP requests which are retransmitted by the EAP protocol > > > > > > entities when needed. The messages that need PANA-level > > > > > > retransmissions are listed below: > > > > > > > > > > > > PANA-PAA-Discover (PDI) > > > > > > PANA-Start-Request (PSR)* > > > > > > PANA-Start-Answer (PSA)** > > > > > > PANA-Bind-Request (PBR) > > > > > > PANA-FirstAuth-End-Request (PFER) > > > > > > PANA-Reauth-Request (PRAR) > > > > > > PANA-Termination-Request (PTR) > > > > > > > > > > > > *) PSR that carries a Cookie AVP is not retransmitted. > > > > > > **) PSA that does not carry a Cookie AVP is not retransmitted." > > > > > > > > > > > > > > > > > > (Note: PFER message is introduced for issue 52.) > > > > > > > > > > > > Regards, > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pana mailing list > > > > > > Pana@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pana mailing list > > > > > Pana@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Mar 18 23:30:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29033 for ; Thu, 18 Mar 2004 23:30:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Bdx-0006zy-Tu; Thu, 18 Mar 2004 23:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Bdu-0006zQ-HB for pana@optimus.ietf.org; Thu, 18 Mar 2004 23:29:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29015 for ; Thu, 18 Mar 2004 23:29:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Bds-0004tY-00 for pana@ietf.org; Thu, 18 Mar 2004 23:29:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Bcy-0004pc-00 for pana@ietf.org; Thu, 18 Mar 2004 23:29:01 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1B4BcY-0004lZ-00 for pana@ietf.org; Thu, 18 Mar 2004 23:28:34 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUT00M1Q32RJZ@mailout2.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 13:28:03 +0900 (KST) Received: from ep_ms13_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUT00BJE31Y0I@mailout2.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 13:27:34 +0900 (KST) Received: from ep_spt04 (ms13.samsung.com [203.254.225.109]) by ms13.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUT00BQC31YDM@ms13.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 13:27:34 +0900 (KST) Content-return: prohibited Date: Fri, 19 Mar 2004 04:27:56 +0000 (GMT) From: Alper Yegin Subject: RE: [Pana] issue 52: proposed text X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9TSVNBP1NlbmlvciBFbmdpbmVlcg==?= To: "yohba@tari.toshiba.com " , "pana@ietf.org " Reply-to: alper.yegin@samsung.com Message-id: <6427097.1079670447126.JavaMail.weblogic@ep_app07> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040319042727107@alper.yegin X-MTR: 20040319042727107@alper.yegin X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Yoshi, Thanks for taking care of this issue. Please see below for my comments. > to: > > "A PANA SA is created as an attribute of a PANA session when EAP > authentication succeeds with a creation of a AAA-Key. A PANA SA is > not created when the PANA authentication fails or no AAA-Key is > produced by any EAP authentication method. In the case where two > EAP authentications are performed in sequence in a single PANA > authentication phase, it is possible that two AAA-Keys are > derived. If this happens, the PANA SA MUST be bound to both Somehow "bound to" sounds like PANA SA has two keys. Eventually it has one PANA_MAC_KEY, that is generated from one or two AAA-keys. Maybe we s hould say "PANA SA is generated from both AAA-Keys". Actually, it is even "PANA SA is generated from the AAA-keys available at the time." After the first auth (NAP, for example), it is generated from the AAA-key if the auth was a success. After the second auth (ISP), again all the keys from the successful auth rounds are used with the resultant PANA SA. > to: > > " > When a Cookie-AVP is carried in a PANA-Start-Request message, the > initial EAP Request MUST NOT be carried in the PANA-Start-Request > message in order for the PAA to be stateless. > > When a Cookie-AVP is not carried in a PANA-Start-Request message, the > PAA does not need to be stateless. In this case, the initial EAP > Request message MAY be carried in the PANA-Start-Request message. The real "cause" to not use this optimization is the "stateless PAA discovery". Cookie usage is just another "result". So, I'd say: "Initial EAP Request MAY be optionally carried by the PANA-Start-Request (as opposed to by a later PANA-Auth-Request) message in order to reduce the number of round-trips. This optimization SHOULD not be used if the PAA discovery is desired to be stateless." > Rewrite Section 4.3 as follows: > > 4.3 Authentication Phase > > The main task in authentication phase is to carry EAP messages > between PaC and PAA. EAP Request messages are carried in PANA- > Auth-Request messages and optionally carried in PANA-Start-Request > messages. EAP Response messages are carried in PANA-Auth-Answer > messages and optionally carried in PANA-Start-Answer messages. > When an EAP Success/Failure message is sent from a PAA, the message > is carried in a PANA-Bind-Request (PBR) or > PANA-FirstAuth-End-Request (PFER) message. The > PANA-FirstAuth-End-Reques message MUST be used at the end of the > first EAP when the PaC and PAA have negotiated during the discovery > and initial handshake phase to perform separate NAP and ISP > authentications in a single PANA authentication phase. Otherwise, > the PANA-Bind-Request message MUST be used. The PANA-Bind-Request > and PANA-FirstAuth-End-Request messages MUST be acknowledged with a > PANA-Bind-Answer (PBA) and a PANA-FirstAuth-End-Answer (PFEA) > messages, respectively. > > When the PaC and PAA have negotiated during the discovery and > initial handshake phase to perform separate NAP and ISP > authentications, the S-flag of PANA-Auth-Request and > PANA-Auth-Answer messages MUST be set. Otherwise, the S-flag MUST > NOT be set. > > When separate NAP and ISP authentications are performed, the PAA > determines the execution order of NAP authentication and ISP > authentication. In this case, the PAA can indicate which EAP > authentication is currently occurring by including a > NAP-Information or an ISP-Information AVP of the corresponding EAP > authentication in the first PANA-Auth-Request message sent to the > PaC. I guess we could also use a single (or two) bit to indicate this is a NAP auth. round vs. ISP auth. round. > In the case where the PaC agreed to perform separate > authentications but did not specify its ISP choice in > PANA-Start-Answer message, the PAA MUST include its NAP-Information > AVP in PANA-Auth-Request message when it performs NAP > authentication and MUST NOT include any service provider > information AVP when it performs ISP authentication so that the PaC > can always distinguish ISP authentication from NAP authentication. "In the case where the PaC agreed to perform separate authentications, presence or absence of NAP-information AVP in PANA-Auth-Request message indicates the authentication type. The PAA MUST include its NAP-Information AVP when it performs NAP authentication, and it MUST NOT include it for the ISP authentication. PAA MUST include the ISP-information AVP for ISP authentication when the PaC has indicated its choice of ISP." > The PAA SHOULD stop including a NAP-Information or an > ISP-Information AVP once it receives the first PANA-Auth-Answer > message of the current EAP authentication. ... > policy issue. PANA signals only the result of the immediately > preceding EAP authentication method in PANA-Bind-Request messages. We don't need this statement anymore, because PANA-Bind is only used at the end (after both rounds of auth.) > Add the following example in section 4.6: ... > PaC PAA Message(tseq,rseq)[AVPs] > ----------------------------------------------------- > // Discovery and initial handshake phase > -----> PANA-PAA-Discover (0,0) > <----- PANA-Start-Request (x,0) // S-flag set > [Cookie, ISP-Information("ISP1"), > ISP-Information("ISP2"), > NAP-Information("MyNAP")] > -----> PANA-Start-Request-Answer (y,x) // S-flag set > [Cookie, ISP-Information("ISP1")] // PaC chooses > "ISP1" > > // Authentication phase > <----- PANA-Auth-Request(x+1,y) // NAP > authentication > [EAP, NAP-Information("MyNAP")] // S-flag set > -----> PANA-Auth-Answer(y+1,x+1)[EAP] // S-flag set > <----- PANA-Auth-Request(x+2,y+1)[EAP] // S-flag set > -----> PANA-Auth-Answer(y+2,x+2)[EAP] // S-flag set > <----- PANA-FirstAuth-End-Request(x+3,y+2) // S-flag set > [EAP{Success}, Key-Id, MAC] > -----> PANA-FirstAuth-End-Answer(y+3,x+3)[Key-Id, MAC] > // S-flag set > > <----- PANA-Auth-Request(x+3,y+4) // ISP > authentication > [EAP, ISP-Information("ISP1")] // S-flag set > -----> PANA-Auth-Answer(y+4,x+4)[EAP] // S-flag set > <----- PANA-Auth-Request(x+4,y+5)[EAP] // S-flag set > -----> PANA-Auth-Answer(y+5,x+5)[EAP] // S-flag set > <----- PANA-Bind-Request(x+5,y+6) // S-flag set > [EAP{Success}, Device-Id, Key-Id, > Lifetime, Protection-Cap., MAC] > -----> PANA-Bind-Answer(y+6,x+5) // S-flag set > [Device-Id, Key-Id, Protection-Cap., MAC] I think the MAC AVPs are missing in all messages of the second auth. round. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Mar 18 23:32:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29141 for ; Thu, 18 Mar 2004 23:32:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Bfn-00077T-Ff for pana-archive@odin.ietf.org; Thu, 18 Mar 2004 23:31:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J4Vt5n027366 for pana-archive@odin.ietf.org; Thu, 18 Mar 2004 23:31:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Bfn-00077J-8V for pana-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 23:31:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29105 for ; Thu, 18 Mar 2004 23:31:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Bfl-000537-00 for pana-web-archive@ietf.org; Thu, 18 Mar 2004 23:31:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Beq-0004yb-00 for pana-web-archive@ietf.org; Thu, 18 Mar 2004 23:30:57 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B4Bdz-0004ud-00 for pana-web-archive@ietf.org; Thu, 18 Mar 2004 23:30:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B4Be0-0005tK-TT for pana-web-archive@ietf.org; Thu, 18 Mar 2004 23:30:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Bdx-0006zy-Tu; Thu, 18 Mar 2004 23:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Bdu-0006zQ-HB for pana@optimus.ietf.org; Thu, 18 Mar 2004 23:29:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29015 for ; Thu, 18 Mar 2004 23:29:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Bds-0004tY-00 for pana@ietf.org; Thu, 18 Mar 2004 23:29:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Bcy-0004pc-00 for pana@ietf.org; Thu, 18 Mar 2004 23:29:01 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1B4BcY-0004lZ-00 for pana@ietf.org; Thu, 18 Mar 2004 23:28:34 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUT00M1Q32RJZ@mailout2.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 13:28:03 +0900 (KST) Received: from ep_ms13_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUT00BJE31Y0I@mailout2.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 13:27:34 +0900 (KST) Received: from ep_spt04 (ms13.samsung.com [203.254.225.109]) by ms13.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUT00BQC31YDM@ms13.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 13:27:34 +0900 (KST) Content-return: prohibited Date: Fri, 19 Mar 2004 04:27:56 +0000 (GMT) From: Alper Yegin Subject: RE: [Pana] issue 52: proposed text X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9TSVNBP1NlbmlvciBFbmdpbmVlcg==?= To: "yohba@tari.toshiba.com " , "pana@ietf.org " Reply-to: alper.yegin@samsung.com Message-id: <6427097.1079670447126.JavaMail.weblogic@ep_app07> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040319042727107@alper.yegin X-MTR: 20040319042727107@alper.yegin X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Yoshi, Thanks for taking care of this issue. Please see below for my comments. > to: > > "A PANA SA is created as an attribute of a PANA session when EAP > authentication succeeds with a creation of a AAA-Key. A PANA SA is > not created when the PANA authentication fails or no AAA-Key is > produced by any EAP authentication method. In the case where two > EAP authentications are performed in sequence in a single PANA > authentication phase, it is possible that two AAA-Keys are > derived. If this happens, the PANA SA MUST be bound to both Somehow "bound to" sounds like PANA SA has two keys. Eventually it has one PANA_MAC_KEY, that is generated from one or two AAA-keys. Maybe we s hould say "PANA SA is generated from both AAA-Keys". Actually, it is even "PANA SA is generated from the AAA-keys available at the time." After the first auth (NAP, for example), it is generated from the AAA-key if the auth was a success. After the second auth (ISP), again all the keys from the successful auth rounds are used with the resultant PANA SA. > to: > > " > When a Cookie-AVP is carried in a PANA-Start-Request message, the > initial EAP Request MUST NOT be carried in the PANA-Start-Request > message in order for the PAA to be stateless. > > When a Cookie-AVP is not carried in a PANA-Start-Request message, the > PAA does not need to be stateless. In this case, the initial EAP > Request message MAY be carried in the PANA-Start-Request message. The real "cause" to not use this optimization is the "stateless PAA discovery". Cookie usage is just another "result". So, I'd say: "Initial EAP Request MAY be optionally carried by the PANA-Start-Request (as opposed to by a later PANA-Auth-Request) message in order to reduce the number of round-trips. This optimization SHOULD not be used if the PAA discovery is desired to be stateless." > Rewrite Section 4.3 as follows: > > 4.3 Authentication Phase > > The main task in authentication phase is to carry EAP messages > between PaC and PAA. EAP Request messages are carried in PANA- > Auth-Request messages and optionally carried in PANA-Start-Request > messages. EAP Response messages are carried in PANA-Auth-Answer > messages and optionally carried in PANA-Start-Answer messages. > When an EAP Success/Failure message is sent from a PAA, the message > is carried in a PANA-Bind-Request (PBR) or > PANA-FirstAuth-End-Request (PFER) message. The > PANA-FirstAuth-End-Reques message MUST be used at the end of the > first EAP when the PaC and PAA have negotiated during the discovery > and initial handshake phase to perform separate NAP and ISP > authentications in a single PANA authentication phase. Otherwise, > the PANA-Bind-Request message MUST be used. The PANA-Bind-Request > and PANA-FirstAuth-End-Request messages MUST be acknowledged with a > PANA-Bind-Answer (PBA) and a PANA-FirstAuth-End-Answer (PFEA) > messages, respectively. > > When the PaC and PAA have negotiated during the discovery and > initial handshake phase to perform separate NAP and ISP > authentications, the S-flag of PANA-Auth-Request and > PANA-Auth-Answer messages MUST be set. Otherwise, the S-flag MUST > NOT be set. > > When separate NAP and ISP authentications are performed, the PAA > determines the execution order of NAP authentication and ISP > authentication. In this case, the PAA can indicate which EAP > authentication is currently occurring by including a > NAP-Information or an ISP-Information AVP of the corresponding EAP > authentication in the first PANA-Auth-Request message sent to the > PaC. I guess we could also use a single (or two) bit to indicate this is a NAP auth. round vs. ISP auth. round. > In the case where the PaC agreed to perform separate > authentications but did not specify its ISP choice in > PANA-Start-Answer message, the PAA MUST include its NAP-Information > AVP in PANA-Auth-Request message when it performs NAP > authentication and MUST NOT include any service provider > information AVP when it performs ISP authentication so that the PaC > can always distinguish ISP authentication from NAP authentication. "In the case where the PaC agreed to perform separate authentications, presence or absence of NAP-information AVP in PANA-Auth-Request message indicates the authentication type. The PAA MUST include its NAP-Information AVP when it performs NAP authentication, and it MUST NOT include it for the ISP authentication. PAA MUST include the ISP-information AVP for ISP authentication when the PaC has indicated its choice of ISP." > The PAA SHOULD stop including a NAP-Information or an > ISP-Information AVP once it receives the first PANA-Auth-Answer > message of the current EAP authentication. ... > policy issue. PANA signals only the result of the immediately > preceding EAP authentication method in PANA-Bind-Request messages. We don't need this statement anymore, because PANA-Bind is only used at the end (after both rounds of auth.) > Add the following example in section 4.6: ... > PaC PAA Message(tseq,rseq)[AVPs] > ----------------------------------------------------- > // Discovery and initial handshake phase > -----> PANA-PAA-Discover (0,0) > <----- PANA-Start-Request (x,0) // S-flag set > [Cookie, ISP-Information("ISP1"), > ISP-Information("ISP2"), > NAP-Information("MyNAP")] > -----> PANA-Start-Request-Answer (y,x) // S-flag set > [Cookie, ISP-Information("ISP1")] // PaC chooses > "ISP1" > > // Authentication phase > <----- PANA-Auth-Request(x+1,y) // NAP > authentication > [EAP, NAP-Information("MyNAP")] // S-flag set > -----> PANA-Auth-Answer(y+1,x+1)[EAP] // S-flag set > <----- PANA-Auth-Request(x+2,y+1)[EAP] // S-flag set > -----> PANA-Auth-Answer(y+2,x+2)[EAP] // S-flag set > <----- PANA-FirstAuth-End-Request(x+3,y+2) // S-flag set > [EAP{Success}, Key-Id, MAC] > -----> PANA-FirstAuth-End-Answer(y+3,x+3)[Key-Id, MAC] > // S-flag set > > <----- PANA-Auth-Request(x+3,y+4) // ISP > authentication > [EAP, ISP-Information("ISP1")] // S-flag set > -----> PANA-Auth-Answer(y+4,x+4)[EAP] // S-flag set > <----- PANA-Auth-Request(x+4,y+5)[EAP] // S-flag set > -----> PANA-Auth-Answer(y+5,x+5)[EAP] // S-flag set > <----- PANA-Bind-Request(x+5,y+6) // S-flag set > [EAP{Success}, Device-Id, Key-Id, > Lifetime, Protection-Cap., MAC] > -----> PANA-Bind-Answer(y+6,x+5) // S-flag set > [Device-Id, Key-Id, Protection-Cap., MAC] I think the MAC AVPs are missing in all messages of the second auth. round. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Mar 18 23:54:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00183 for ; Thu, 18 Mar 2004 23:54:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4C1A-00007G-HW; Thu, 18 Mar 2004 23:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4C0z-0008WN-1x for pana@optimus.ietf.org; Thu, 18 Mar 2004 23:53:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00130 for ; Thu, 18 Mar 2004 23:53:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4C0w-0006e8-00 for pana@ietf.org; Thu, 18 Mar 2004 23:53:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4C04-0006ZD-00 for pana@ietf.org; Thu, 18 Mar 2004 23:52:53 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1B4BzA-0006Px-00 for pana@ietf.org; Thu, 18 Mar 2004 23:51:56 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUT0060445PDG@mailout1.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 13:51:25 +0900 (KST) Received: from ep_ms13_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUT00MNV45PJT@mailout1.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 13:51:25 +0900 (KST) Received: from ep_spt02 (ms13.samsung.com [203.254.225.109]) by ms13.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUT00HNF45O4T@ms13.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 13:51:25 +0900 (KST) Content-return: prohibited Date: Fri, 19 Mar 2004 04:51:20 +0000 (GMT) From: Alper Yegin Subject: Re :Re: [Pana] issue 57 (resolution) X-Sender: =?SJIS?B?U2Ftc3VuZyBFbGVjdHJvbmljc4GpU0lTQYGpU2VuaW9yIEVuZ2luZWVy?= To: Yoshihiro Ohba Cc: "pana@ietf.org " Reply-to: alper.yegin@samsung.com Message-id: <7695533.1079671877524.JavaMail.weblogic@ep_app07> MIME-version: 1.0 Content-type: text/plain; charset=SJIS Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040319045117508@alper.yegin X-MTR: 20040319045117508@alper.yegin X-EPLocale: en_US.SJIS X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT > > > - There is an exception. If the requester remains stateless after > > > sending a request, the responder should take the responsibility of > > > retransmission. This cases occurs only for PSR/PSA exchange, and > > > retransmission of PDI and PSA can archieve the responsibility. The > > > presence of the cookie indicates that the requester remains stateless. > > > > If there is no PDI, and PSR is not retransmitted at all, when the single > PSR > > is lost, the PANA exchange will hang. > > Right. That is why I used "retransmission of PDI and PSA". Yes, but PDI is not always used. In case we are performing "data driven PAA discovery", we rely on unsolicited PSR. And if, at the same time, we want the PAA to stay stateless, there is a problem. According to your rule, if PSR is lost, there is no retransmission and hence no progress. This is a problem with your scheme. Do you agree? > > I understand your point. I guess the problem is, "being stateless" and > > "performing unsolicited PAA discovery" do not mix well. > > Yes, When PAA is performing unsolicited PAA discovery, the PAA should > be stateful, otherwise the PANA exchange will hang if PSR is lost. Hence PSR is always retransmitted in unsolicited discovery (we no longer care of we are trying to be stateless or not). If this is what you are saying too, we are in agreement. > On > the other hand, when PAA is perfomring solicited PAA discovery, it can > be either stateless or stateful. Yes. Alper > > Yoshihiro Ohba > > > > > > > > > > > Some other clue could be > > > > used to stop one side from retransmitting. For example in my case, > > > > receipt of PDI by the PAA could cease the PSR retransmissions on the > > > > PAA. > > > > > > That is also possible. Which strategy do you think is better? > > > > > > Yoshihiro Ohba > > > > Alper > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > - > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > " > > > > > > > A PANA-Start-Request message that carries a Cookie AVP is > never > > > > > > > retransmitted. A PANA-Start-Request message that does not > > > > carry a > > > > > > > Cookie AVP is retransmitted based on timer. A > > > > PANA-Start-Answer > > > > > > > message that carries a Cookie AVP is retransmitted based on > > > > timer. > > > > > > > A PANA-Start-Answer message that does not carry a Cookie > AVP is > > > > > > > never retransmitted based on timer. > > > > > > > " > > > > > > > > > > > > > > Change the first paragraph of section 10 to: > > > > > > > > > > > > > > "The PANA protocol provides retransmissions for all the > message > > > > > > > exchanges except PANA-Auth-Request/Answer. PANA-Auth- > Request > > > > > > messages > > > > > > > carry EAP requests which are retransmitted by the EAP > protocol > > > > > > > entities when needed. The messages that need PANA-level > > > > > > > retransmissions are listed below: > > > > > > > > > > > > > > PANA-PAA-Discover (PDI) > > > > > > > PANA-Start-Request (PSR)* > > > > > > > PANA-Start-Answer (PSA)** > > > > > > > PANA-Bind-Request (PBR) > > > > > > > PANA-FirstAuth-End-Request (PFER) > > > > > > > PANA-Reauth-Request (PRAR) > > > > > > > PANA-Termination-Request (PTR) > > > > > > > > > > > > > > *) PSR that carries a Cookie AVP is not retransmitted. > > > > > > > **) PSA that does not carry a Cookie AVP is not > retransmitted." > > > > > > > > > > > > > > > > > > > > > (Note: PFER message is introduced for issue 52.) > > > > > > > > > > > > > > Regards, > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Pana mailing list > > > > > > > Pana@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pana mailing list > > > > > > Pana@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Mar 18 23:56:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00365 for ; Thu, 18 Mar 2004 23:56:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4C35-0000ER-5P for pana-archive@odin.ietf.org; Thu, 18 Mar 2004 23:55:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J4txL3000885 for pana-archive@odin.ietf.org; Thu, 18 Mar 2004 23:55:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4C35-0000EC-1L for pana-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 23:55:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00297 for ; Thu, 18 Mar 2004 23:55:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4C32-0006sk-00 for pana-web-archive@ietf.org; Thu, 18 Mar 2004 23:55:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4C28-0006m0-00 for pana-web-archive@ietf.org; Thu, 18 Mar 2004 23:55:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4C1A-0006gS-00 for pana-web-archive@ietf.org; Thu, 18 Mar 2004 23:54:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4C1A-00007G-HW; Thu, 18 Mar 2004 23:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4C0z-0008WN-1x for pana@optimus.ietf.org; Thu, 18 Mar 2004 23:53:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00130 for ; Thu, 18 Mar 2004 23:53:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4C0w-0006e8-00 for pana@ietf.org; Thu, 18 Mar 2004 23:53:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4C04-0006ZD-00 for pana@ietf.org; Thu, 18 Mar 2004 23:52:53 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1B4BzA-0006Px-00 for pana@ietf.org; Thu, 18 Mar 2004 23:51:56 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUT0060445PDG@mailout1.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 13:51:25 +0900 (KST) Received: from ep_ms13_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUT00MNV45PJT@mailout1.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 13:51:25 +0900 (KST) Received: from ep_spt02 (ms13.samsung.com [203.254.225.109]) by ms13.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUT00HNF45O4T@ms13.samsung.com> for pana@ietf.org; Fri, 19 Mar 2004 13:51:25 +0900 (KST) Content-return: prohibited Date: Fri, 19 Mar 2004 04:51:20 +0000 (GMT) From: Alper Yegin Subject: Re :Re: [Pana] issue 57 (resolution) X-Sender: =?SJIS?B?U2Ftc3VuZyBFbGVjdHJvbmljc4GpU0lTQYGpU2VuaW9yIEVuZ2luZWVy?= To: Yoshihiro Ohba Cc: "pana@ietf.org " Reply-to: alper.yegin@samsung.com Message-id: <7695533.1079671877524.JavaMail.weblogic@ep_app07> MIME-version: 1.0 Content-type: text/plain; charset=SJIS Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040319045117508@alper.yegin X-MTR: 20040319045117508@alper.yegin X-EPLocale: en_US.SJIS X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Content-Transfer-Encoding: 7BIT Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > > - There is an exception. If the requester remains stateless after > > > sending a request, the responder should take the responsibility of > > > retransmission. This cases occurs only for PSR/PSA exchange, and > > > retransmission of PDI and PSA can archieve the responsibility. The > > > presence of the cookie indicates that the requester remains stateless. > > > > If there is no PDI, and PSR is not retransmitted at all, when the single > PSR > > is lost, the PANA exchange will hang. > > Right. That is why I used "retransmission of PDI and PSA". Yes, but PDI is not always used. In case we are performing "data driven PAA discovery", we rely on unsolicited PSR. And if, at the same time, we want the PAA to stay stateless, there is a problem. According to your rule, if PSR is lost, there is no retransmission and hence no progress. This is a problem with your scheme. Do you agree? > > I understand your point. I guess the problem is, "being stateless" and > > "performing unsolicited PAA discovery" do not mix well. > > Yes, When PAA is performing unsolicited PAA discovery, the PAA should > be stateful, otherwise the PANA exchange will hang if PSR is lost. Hence PSR is always retransmitted in unsolicited discovery (we no longer care of we are trying to be stateless or not). If this is what you are saying too, we are in agreement. > On > the other hand, when PAA is perfomring solicited PAA discovery, it can > be either stateless or stateful. Yes. Alper > > Yoshihiro Ohba > > > > > > > > > > > Some other clue could be > > > > used to stop one side from retransmitting. For example in my case, > > > > receipt of PDI by the PAA could cease the PSR retransmissions on the > > > > PAA. > > > > > > That is also possible. Which strategy do you think is better? > > > > > > Yoshihiro Ohba > > > > Alper > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > - > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > " > > > > > > > A PANA-Start-Request message that carries a Cookie AVP is > never > > > > > > > retransmitted. A PANA-Start-Request message that does not > > > > carry a > > > > > > > Cookie AVP is retransmitted based on timer. A > > > > PANA-Start-Answer > > > > > > > message that carries a Cookie AVP is retransmitted based on > > > > timer. > > > > > > > A PANA-Start-Answer message that does not carry a Cookie > AVP is > > > > > > > never retransmitted based on timer. > > > > > > > " > > > > > > > > > > > > > > Change the first paragraph of section 10 to: > > > > > > > > > > > > > > "The PANA protocol provides retransmissions for all the > message > > > > > > > exchanges except PANA-Auth-Request/Answer. PANA-Auth- > Request > > > > > > messages > > > > > > > carry EAP requests which are retransmitted by the EAP > protocol > > > > > > > entities when needed. The messages that need PANA-level > > > > > > > retransmissions are listed below: > > > > > > > > > > > > > > PANA-PAA-Discover (PDI) > > > > > > > PANA-Start-Request (PSR)* > > > > > > > PANA-Start-Answer (PSA)** > > > > > > > PANA-Bind-Request (PBR) > > > > > > > PANA-FirstAuth-End-Request (PFER) > > > > > > > PANA-Reauth-Request (PRAR) > > > > > > > PANA-Termination-Request (PTR) > > > > > > > > > > > > > > *) PSR that carries a Cookie AVP is not retransmitted. > > > > > > > **) PSA that does not carry a Cookie AVP is not > retransmitted." > > > > > > > > > > > > > > > > > > > > > (Note: PFER message is introduced for issue 52.) > > > > > > > > > > > > > > Regards, > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Pana mailing list > > > > > > > Pana@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pana mailing list > > > > > > Pana@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > _______________________________________________ > > Pana mailing list > > Pana@ietf.org > > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Mar 19 02:04:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09622 for ; Fri, 19 Mar 2004 02:04:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E31-0001xn-1i; Fri, 19 Mar 2004 02:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E2x-0001v3-1Y for pana@optimus.ietf.org; Fri, 19 Mar 2004 02:03:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08948 for ; Fri, 19 Mar 2004 02:03:56 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E2t-00006E-00 for pana@ietf.org; Fri, 19 Mar 2004 02:03:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E22-00003R-00 for pana@ietf.org; Fri, 19 Mar 2004 02:03:02 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1B4E1d-0007nZ-00 for pana@ietf.org; Fri, 19 Mar 2004 02:02:37 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J72bA24240 for ; Fri, 19 Mar 2004 09:02:37 +0200 (EET) X-Scanned: Fri, 19 Mar 2004 09:02:34 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i2J72Y9a018474 for ; Fri, 19 Mar 2004 09:02:34 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00KnYn18; Fri, 19 Mar 2004 09:02:33 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J72XF13152 for ; Fri, 19 Mar 2004 09:02:33 +0200 (EET) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 19 Mar 2004 09:02:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 19 Mar 2004 09:02:32 +0200 Message-ID: Thread-Topic: [issue72] Capability discovery during PAA discovery Thread-Index: AcQNf04XL8i41aCRTZ+0nOc3fpDQPgAALGlg To: X-OriginalArrivalTime: 19 Mar 2004 07:02:33.0300 (UTC) FILETIME=[26E91140:01C40D80] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue72] Capability discovery during PAA discovery Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 RnJvbSBBbHBlci4uDQoNCk5ldyBzdWJtaXNzaW9uIGZyb20gRGFuIEZvcnNiZXJnIDxkYW4uZm9y c2JlcmdAbm9raWEuY29tPjoNCg0KQ3VycmVudGx5IGNhcGFiaWxpdHkgZGlzY292ZXJ5IGlzIG5v dCBhY2NvbXBsaXNoZWQgdW50aWwgdGhlIGVuZCBvZg0KRUFQIGF1dGhlbnRpY2F0aW9uLiBDb3B5 aW5nIHNvbWUgYml0cywgc3VjaCBhcyBQT1BBIHR5cGVzIGFuZA0KcGVyLXBhY2tldCBwcm90ZWN0 aW9uIGNhcGFiaWxpdHksIHRvIFBBQSBkaXNjb3ZlcnkgbWF5IGJlIHVzZWZ1bCBmb3INCmRpc2Nv dmVyaW5nIGNhcGFiaWxpdHkgbWlzbWF0Y2ggZWFybHkgb24uDQoNCi0tLS0tLS0tLS0NCmNhdGVn b3J5OiBUZWNobmljYWwNCmRvY3VtZW50OiBkcmFmdC1pZXRmLXBhbmEtcGFuYS14eC50eHQNCm1l c3NhZ2VzOiAyNDMNCm5vc3k6IGRmb3JzYmVyDQpwcmlvcml0eTogU2hvdWxkIEZpeA0Kc3RhdHVz OiBQZW5kaW5nDQp0aXRsZTogQ2FwYWJpbGl0eSBkaXNjb3ZlcnkgZHVyaW5nIFBBQSBkaXNjb3Zl cnkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQ QU5BIElzc3VlcyA8cGFuYV9pc3N1ZXNAZGFuZm9yc2JlcmcuaW5mbz4NCjxodHRwOi8vZGFuZm9y c2JlcmcuaW5mbzo4MDgwL3BhbmEtaXNzdWVzL2lzc3VlNzI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Mar 19 02:06:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11578 for ; Fri, 19 Mar 2004 02:06:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E4x-00035g-Bq for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 02:06:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J762xo011806 for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 02:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E4u-000349-T6 for pana-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 02:06:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11018 for ; Fri, 19 Mar 2004 02:05:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E4r-0000FH-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:05:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E3x-0000BD-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:05:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4E31-000072-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E31-0001xn-1i; Fri, 19 Mar 2004 02:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E2x-0001v3-1Y for pana@optimus.ietf.org; Fri, 19 Mar 2004 02:03:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08948 for ; Fri, 19 Mar 2004 02:03:56 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E2t-00006E-00 for pana@ietf.org; Fri, 19 Mar 2004 02:03:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E22-00003R-00 for pana@ietf.org; Fri, 19 Mar 2004 02:03:02 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1B4E1d-0007nZ-00 for pana@ietf.org; Fri, 19 Mar 2004 02:02:37 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J72bA24240 for ; Fri, 19 Mar 2004 09:02:37 +0200 (EET) X-Scanned: Fri, 19 Mar 2004 09:02:34 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i2J72Y9a018474 for ; Fri, 19 Mar 2004 09:02:34 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00KnYn18; Fri, 19 Mar 2004 09:02:33 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J72XF13152 for ; Fri, 19 Mar 2004 09:02:33 +0200 (EET) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 19 Mar 2004 09:02:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 19 Mar 2004 09:02:32 +0200 Message-ID: Thread-Topic: [issue72] Capability discovery during PAA discovery Thread-Index: AcQNf04XL8i41aCRTZ+0nOc3fpDQPgAALGlg To: X-OriginalArrivalTime: 19 Mar 2004 07:02:33.0300 (UTC) FILETIME=[26E91140:01C40D80] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue72] Capability discovery during PAA discovery Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RnJvbSBBbHBlci4uDQoNCk5ldyBzdWJtaXNzaW9uIGZyb20gRGFuIEZvcnNiZXJnIDxkYW4uZm9y c2JlcmdAbm9raWEuY29tPjoNCg0KQ3VycmVudGx5IGNhcGFiaWxpdHkgZGlzY292ZXJ5IGlzIG5v dCBhY2NvbXBsaXNoZWQgdW50aWwgdGhlIGVuZCBvZg0KRUFQIGF1dGhlbnRpY2F0aW9uLiBDb3B5 aW5nIHNvbWUgYml0cywgc3VjaCBhcyBQT1BBIHR5cGVzIGFuZA0KcGVyLXBhY2tldCBwcm90ZWN0 aW9uIGNhcGFiaWxpdHksIHRvIFBBQSBkaXNjb3ZlcnkgbWF5IGJlIHVzZWZ1bCBmb3INCmRpc2Nv dmVyaW5nIGNhcGFiaWxpdHkgbWlzbWF0Y2ggZWFybHkgb24uDQoNCi0tLS0tLS0tLS0NCmNhdGVn b3J5OiBUZWNobmljYWwNCmRvY3VtZW50OiBkcmFmdC1pZXRmLXBhbmEtcGFuYS14eC50eHQNCm1l c3NhZ2VzOiAyNDMNCm5vc3k6IGRmb3JzYmVyDQpwcmlvcml0eTogU2hvdWxkIEZpeA0Kc3RhdHVz OiBQZW5kaW5nDQp0aXRsZTogQ2FwYWJpbGl0eSBkaXNjb3ZlcnkgZHVyaW5nIFBBQSBkaXNjb3Zl cnkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQ QU5BIElzc3VlcyA8cGFuYV9pc3N1ZXNAZGFuZm9yc2JlcmcuaW5mbz4NCjxodHRwOi8vZGFuZm9y c2JlcmcuaW5mbzo4MDgwL3BhbmEtaXNzdWVzL2lzc3VlNzI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Mar 19 02:07:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12630 for ; Fri, 19 Mar 2004 02:07:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E5u-0003OA-K0; Fri, 19 Mar 2004 02:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E4w-00034k-9q for pana@optimus.ietf.org; Fri, 19 Mar 2004 02:06:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11037 for ; Fri, 19 Mar 2004 02:05:59 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E4s-0000FR-00 for pana@ietf.org; Fri, 19 Mar 2004 02:05:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E3y-0000BT-00 for pana@ietf.org; Fri, 19 Mar 2004 02:05:03 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B4E32-000074-00 for pana@ietf.org; Fri, 19 Mar 2004 02:04:04 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J745a26010 for ; Fri, 19 Mar 2004 09:04:05 +0200 (EET) X-Scanned: Fri, 19 Mar 2004 09:04:02 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2J742jP014866 for ; Fri, 19 Mar 2004 09:04:02 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 0084qwyt; Fri, 19 Mar 2004 09:04:01 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J73ts09218 for ; Fri, 19 Mar 2004 09:03:55 +0200 (EET) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 19 Mar 2004 09:03:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 19 Mar 2004 09:03:55 +0200 Message-ID: Thread-Topic: [issue73] DI on DSL Thread-Index: AcQNf4g19RnvRNVpQVqIOZs2LFg9kwAAKAbQ To: X-OriginalArrivalTime: 19 Mar 2004 07:03:55.0763 (UTC) FILETIME=[580FEC30:01C40D80] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue73] DI on DSL Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 RnJvbSBBbHBlci4uDQoNCk5ldyBzdWJtaXNzaW9uIGZyb20gRGFuIEZvcnNiZXJnIDxkYW4uZm9y c2JlcmdAbm9raWEuY29tPjoNCg0KV2hhdCB0eXBlIG9mIERJIHdpbGwgYmUgdXNlZCBvbiBEU0wg bmV0d29ya3M/IEEgbG93ZXItbGF5ZXIgcGVyLXBhY2tldA0KaWRlbnRpZmllciAoc291cmNlIGFk ZHJlc3MpIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGUgaW4gYWxsIGRlcGxveW1lbnRzLiBJbg0KdGhh dCBjYXNlLCBhIGRpZmZlcmVudCB0eXBlIG9mIGlkZW50aWZpZXIsIHN1Y2ggYXMgInBoeXNpY2Fs IGludGVyZmFjZSBvbiB0aGUgDQpQQUEiIG1pZ2h0IGJlIHVzZWQuIFRoYXQgaW50ZXJmYWNlIG1p Z2h0IGJlIGEgdmlydHVhbCBjaXJjdWl0IGRlZGljYXRlZCB0byBhIA0KUGFDLg0KDQotLS0tLS0t LS0tDQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBhbmEt eHgudHh0DQptZXNzYWdlczogMjQ0DQpub3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IFNob3VsZCBG aXgNCnN0YXR1czogUGVuZGluZw0KdGl0bGU6IERJIG9uIERTTA0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEgSXNzdWVzIDxwYW5hX2lzc3Vl c0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVyZy5pbmZvOjgwODAvcGFuYS1p c3N1ZXMvaXNzdWU3Mz4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Mar 19 02:07:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12631 for ; Fri, 19 Mar 2004 02:07:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E5t-0003Ni-Gl; Fri, 19 Mar 2004 02:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E4z-00036a-C1 for pana@optimus.ietf.org; Fri, 19 Mar 2004 02:06:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11096 for ; Fri, 19 Mar 2004 02:06:03 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E4v-0000Fu-00 for pana@ietf.org; Fri, 19 Mar 2004 02:06:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E42-0000C3-00 for pana@ietf.org; Fri, 19 Mar 2004 02:05:06 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B4E3O-00007J-00 for pana@ietf.org; Fri, 19 Mar 2004 02:04:26 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J74Qp01485 for ; Fri, 19 Mar 2004 09:04:26 +0200 (EET) X-Scanned: Fri, 19 Mar 2004 09:04:16 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2J74Gnn015295 for ; Fri, 19 Mar 2004 09:04:16 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00GFMrCx; Fri, 19 Mar 2004 09:04:15 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J74Es09440 for ; Fri, 19 Mar 2004 09:04:14 +0200 (EET) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 19 Mar 2004 09:04:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 19 Mar 2004 09:04:14 +0200 Message-ID: Thread-Topic: [issue71] POPA mechanism discovery Thread-Index: AcQNf45yesDeLSoBRimtw9qIeLKXyQAAMqNw To: X-OriginalArrivalTime: 19 Mar 2004 07:04:14.0669 (UTC) FILETIME=[6354BFD0:01C40D80] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue71] POPA mechanism discovery Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 RnJvbSBBbHBlci4uDQoNCk5ldyBzdWJtaXNzaW9uIGZyb20gRGFuIEZvcnNiZXJnIDxkYW4uZm9y c2JlcmdAbm9raWEuY29tPjoNCg0KUEFOQS1CaW5kLVJlcXVlc3Qgc2hvdWxkIGluY2x1ZGUgdGhl IHR5cGVzIG9mIHBvc3QtUEFOQSBhZGRyZXNzDQpjb25maWd1cmF0aW9uIG1lY2hhbmlzbXMgYXZh aWxhYmxlLiBGb3IgZXhhbXBsZSBpbiBjYXNlIElQc2VjLWJhc2VkDQphY2Nlc3MgY29udHJvbCBp cyB1c2VkLCBib3RoIElLRXYyIGFuZCBSRkMzNDU2IGNhbiBiZSB1c2VkIGluIGFuDQphY2Nlc3Mg bmV0d29yayBmb3IgY29uZmlndXJpbmcgdHVubmVsIGlubmVyIGFkZHJlc3Nlcy4gUGFDIHNob3Vs ZA0Ka25vdyB3aGljaCBvbmVzIGFyZSBhdmFpbGFibGUuDQoNCi0tLS0tLS0tLS0NCmNhdGVnb3J5 OiBUZWNobmljYWwNCm1lc3NhZ2VzOiAyNDINCm5vc3k6IGRmb3JzYmVyDQpwcmlvcml0eTogU2hv dWxkIEZpeA0Kc3RhdHVzOiBQZW5kaW5nDQp0aXRsZTogUE9QQSBtZWNoYW5pc20gZGlzY292ZXJ5 DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUEFO QSBJc3N1ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmluZm8+DQo8aHR0cDovL2RhbmZvcnNi ZXJnLmluZm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTcxPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Mar 19 02:07:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12724 for ; Fri, 19 Mar 2004 02:07:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E5y-0003Qi-6p; Fri, 19 Mar 2004 02:07:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E5n-0003M0-3V for pana@optimus.ietf.org; Fri, 19 Mar 2004 02:06:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11924 for ; Fri, 19 Mar 2004 02:06:52 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E5j-0000J2-00 for pana@ietf.org; Fri, 19 Mar 2004 02:06:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E4p-0000F4-00 for pana@ietf.org; Fri, 19 Mar 2004 02:05:55 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B4E3w-0000B0-00 for pana@ietf.org; Fri, 19 Mar 2004 02:05:00 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J750p02356 for ; Fri, 19 Mar 2004 09:05:00 +0200 (EET) X-Scanned: Fri, 19 Mar 2004 09:04:38 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2J74c10015992 for ; Fri, 19 Mar 2004 09:04:38 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00by2inE; Fri, 19 Mar 2004 09:04:37 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J74as09758 for ; Fri, 19 Mar 2004 09:04:36 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 19 Mar 2004 09:04:36 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 19 Mar 2004 09:04:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 19 Mar 2004 09:04:36 +0200 Message-ID: Thread-Topic: [issue74] Using PBR/A instead of PRAR/A upon movement Thread-Index: AcQNgAlLt3haEHWyQDKq4LV6RYrWUgAAFuCA To: X-OriginalArrivalTime: 19 Mar 2004 07:04:35.0853 (UTC) FILETIME=[6FF52BD0:01C40D80] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue74] Using PBR/A instead of PRAR/A upon movement Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 RnJvbSBBbHBlci4uDQoNCk5ldyBzdWJtaXNzaW9uIGZyb20gRGFuIEZvcnNiZXJnIDxkYW4uZm9y c2JlcmdAbm9raWEuY29tPjoNCg0KVGhlIGN1cnJlbnQgZGVzaWduIGlzIHVzaW5nIFBSQVIgYW5k IFBSQUEgZm9yIG1vYmlsaXR5IG9wdGltaXphdGlvbi4NCg0KUGFDICAgICAgIFBBQQ0KLS0tLS0+ IFBESQ0KPC0tLS0tIFBTUg0KLS0tLS0+IFBTQStTZXNzaW9uSUQNCjwtLS0tLSBQUkFSDQotLS0t LT4gUFJBQQ0KDQpXZSBjYW4gdXNlIFBCUiBhbmQgUEJBIGluc3RlYWQsIHdoaWNoIHdpbGwgYmUg YmV0dGVyIGFsaWduZWQgd2l0aCANCnRoZSByZWd1bGFyIHNpZ25hbGxpbmcuDQoNCi0tLS0tLS0t LS0NCmNhdGVnb3J5OiBUZWNobmljYWwNCmRvY3VtZW50OiBkcmFmdC1pZXRmLXBhbmEtcGFuYS14 eC50eHQNCm1lc3NhZ2VzOiAyNDUNCm5vc3k6IGRmb3JzYmVyDQpwcmlvcml0eTogTWF5IEZpeA0K c3RhdHVzOiBQZW5kaW5nDQp0aXRsZTogVXNpbmcgUEJSL0EgaW5zdGVhZCBvZiBQUkFSL0EgdXBv biBtb3ZlbWVudA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClBBTkEgSXNzdWVzIDxwYW5hX2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6 Ly9kYW5mb3JzYmVyZy5pbmZvOjgwODAvcGFuYS1pc3N1ZXMvaXNzdWU3ND4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Mar 19 02:07:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12747 for ; Fri, 19 Mar 2004 02:07:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E60-0003UK-NO; Fri, 19 Mar 2004 02:07:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E5n-0003ML-Rz for pana@optimus.ietf.org; Fri, 19 Mar 2004 02:06:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11936 for ; Fri, 19 Mar 2004 02:06:53 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E5k-0000J7-00 for pana@ietf.org; Fri, 19 Mar 2004 02:06:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E4s-0000FW-00 for pana@ietf.org; Fri, 19 Mar 2004 02:05:59 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B4E3z-0000BY-00 for pana@ietf.org; Fri, 19 Mar 2004 02:05:03 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J753p02410 for ; Fri, 19 Mar 2004 09:05:03 +0200 (EET) X-Scanned: Fri, 19 Mar 2004 09:04:56 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2J74uvB016414 for ; Fri, 19 Mar 2004 09:04:56 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00x7M4Qd; Fri, 19 Mar 2004 09:04:53 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J74rs09943 for ; Fri, 19 Mar 2004 09:04:53 +0200 (EET) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 19 Mar 2004 09:04:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 19 Mar 2004 09:04:53 +0200 Message-ID: Thread-Topic: [issue76] Rate limitation on Reauth clarification neeeded Thread-Index: AcQNgGnwXv1xicFLQeu9DZgcjQSijgAAAeDQ To: X-OriginalArrivalTime: 19 Mar 2004 07:04:53.0947 (UTC) FILETIME=[7ABE18B0:01C40D80] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue76] Rate limitation on Reauth clarification neeeded Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 RnJvbSBBbHBlci4uDQoNCk5ldyBzdWJtaXNzaW9uIGZyb20gRGFuIEZvcnNiZXJnIDxkYW4uZm9y c2JlcmdAbm9raWEuY29tPjoNCg0KIkltcGxlbWVudGF0aW9ucyBNVVNUIGxpbWl0IHRoZSByYXRl IG9mIHBlcmZvcm1pbmcgcmUtYXV0aGVudGljYXRpb24NCiAgIGZvciBib3RoIHR5cGVzIG9mIHJl LWF1dGhlbnRpY2F0aW9uLiINCg0KRWFjaCBzaWRlIGNhbiBoYW5kbGUgcmF0ZSBsaW1pdGF0aW9u IG9uIHRoZWlyIG93biwNCnRoZXkgZG9uJ3QgaGF2ZSB0byBjb29yZGluYXRlIGluIGFueSB3YXku IFRoZXJlIGlzIG5vIG5lZ290aWF0aW9uDQpvZiB0aW1lcnMgZm9yIHRoaXMgY2FzZS4gV2Ugc2hv dWxkIGV4cGxpY2l0bHkgc3RhdGUgdGhhdC4NCg0KLS0tLS0tLS0tLQ0KY2F0ZWdvcnk6IFRlY2hu aWNhbA0KZG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGFuYS1wYW5hLXh4LnR4dA0KbWVzc2FnZXM6IDI0 Nw0Kbm9zeTogZGZvcnNiZXINCnByaW9yaXR5OiBTaG91bGQgRml4DQpzdGF0dXM6IENsYXJpZnlp bmcgVGV4dCBSZXF1aXJlZA0KdGl0bGU6IFJhdGUgbGltaXRhdGlvbiBvbiBSZWF1dGggY2xhcmlm aWNhdGlvbiBuZWVlZGVkDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KUEFOQSBJc3N1ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmluZm8+DQo8 aHR0cDovL2RhbmZvcnNiZXJnLmluZm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTc2Pg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Mar 19 02:09:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14623 for ; Fri, 19 Mar 2004 02:09:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E7n-0004IW-Va for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 02:09:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J78xxs016494 for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 02:08:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E7m-0004Ht-K3 for pana-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 02:08:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14071 for ; Fri, 19 Mar 2004 02:08:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E7j-0000UH-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:08:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E6n-0000P2-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:07:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4E5u-0000Kh-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E5t-0003Ni-Gl; Fri, 19 Mar 2004 02:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E4z-00036a-C1 for pana@optimus.ietf.org; Fri, 19 Mar 2004 02:06:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11096 for ; Fri, 19 Mar 2004 02:06:03 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E4v-0000Fu-00 for pana@ietf.org; Fri, 19 Mar 2004 02:06:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E42-0000C3-00 for pana@ietf.org; Fri, 19 Mar 2004 02:05:06 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B4E3O-00007J-00 for pana@ietf.org; Fri, 19 Mar 2004 02:04:26 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J74Qp01485 for ; Fri, 19 Mar 2004 09:04:26 +0200 (EET) X-Scanned: Fri, 19 Mar 2004 09:04:16 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2J74Gnn015295 for ; Fri, 19 Mar 2004 09:04:16 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00GFMrCx; Fri, 19 Mar 2004 09:04:15 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J74Es09440 for ; Fri, 19 Mar 2004 09:04:14 +0200 (EET) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 19 Mar 2004 09:04:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 19 Mar 2004 09:04:14 +0200 Message-ID: Thread-Topic: [issue71] POPA mechanism discovery Thread-Index: AcQNf45yesDeLSoBRimtw9qIeLKXyQAAMqNw To: X-OriginalArrivalTime: 19 Mar 2004 07:04:14.0669 (UTC) FILETIME=[6354BFD0:01C40D80] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue71] POPA mechanism discovery Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RnJvbSBBbHBlci4uDQoNCk5ldyBzdWJtaXNzaW9uIGZyb20gRGFuIEZvcnNiZXJnIDxkYW4uZm9y c2JlcmdAbm9raWEuY29tPjoNCg0KUEFOQS1CaW5kLVJlcXVlc3Qgc2hvdWxkIGluY2x1ZGUgdGhl IHR5cGVzIG9mIHBvc3QtUEFOQSBhZGRyZXNzDQpjb25maWd1cmF0aW9uIG1lY2hhbmlzbXMgYXZh aWxhYmxlLiBGb3IgZXhhbXBsZSBpbiBjYXNlIElQc2VjLWJhc2VkDQphY2Nlc3MgY29udHJvbCBp cyB1c2VkLCBib3RoIElLRXYyIGFuZCBSRkMzNDU2IGNhbiBiZSB1c2VkIGluIGFuDQphY2Nlc3Mg bmV0d29yayBmb3IgY29uZmlndXJpbmcgdHVubmVsIGlubmVyIGFkZHJlc3Nlcy4gUGFDIHNob3Vs ZA0Ka25vdyB3aGljaCBvbmVzIGFyZSBhdmFpbGFibGUuDQoNCi0tLS0tLS0tLS0NCmNhdGVnb3J5 OiBUZWNobmljYWwNCm1lc3NhZ2VzOiAyNDINCm5vc3k6IGRmb3JzYmVyDQpwcmlvcml0eTogU2hv dWxkIEZpeA0Kc3RhdHVzOiBQZW5kaW5nDQp0aXRsZTogUE9QQSBtZWNoYW5pc20gZGlzY292ZXJ5 DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUEFO QSBJc3N1ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmluZm8+DQo8aHR0cDovL2RhbmZvcnNi ZXJnLmluZm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTcxPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Mar 19 02:09:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14674 for ; Fri, 19 Mar 2004 02:09:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E7o-0004Ir-D8 for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 02:09:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J790HE016523 for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 02:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E7n-0004IC-Ae for pana-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 02:08:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14082 for ; Fri, 19 Mar 2004 02:08:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E7j-0000UM-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:08:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E6o-0000PA-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:07:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4E5u-0000Ki-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E5u-0003OA-K0; Fri, 19 Mar 2004 02:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E4w-00034k-9q for pana@optimus.ietf.org; Fri, 19 Mar 2004 02:06:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11037 for ; Fri, 19 Mar 2004 02:05:59 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E4s-0000FR-00 for pana@ietf.org; Fri, 19 Mar 2004 02:05:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E3y-0000BT-00 for pana@ietf.org; Fri, 19 Mar 2004 02:05:03 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B4E32-000074-00 for pana@ietf.org; Fri, 19 Mar 2004 02:04:04 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J745a26010 for ; Fri, 19 Mar 2004 09:04:05 +0200 (EET) X-Scanned: Fri, 19 Mar 2004 09:04:02 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2J742jP014866 for ; Fri, 19 Mar 2004 09:04:02 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 0084qwyt; Fri, 19 Mar 2004 09:04:01 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J73ts09218 for ; Fri, 19 Mar 2004 09:03:55 +0200 (EET) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 19 Mar 2004 09:03:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 19 Mar 2004 09:03:55 +0200 Message-ID: Thread-Topic: [issue73] DI on DSL Thread-Index: AcQNf4g19RnvRNVpQVqIOZs2LFg9kwAAKAbQ To: X-OriginalArrivalTime: 19 Mar 2004 07:03:55.0763 (UTC) FILETIME=[580FEC30:01C40D80] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue73] DI on DSL Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RnJvbSBBbHBlci4uDQoNCk5ldyBzdWJtaXNzaW9uIGZyb20gRGFuIEZvcnNiZXJnIDxkYW4uZm9y c2JlcmdAbm9raWEuY29tPjoNCg0KV2hhdCB0eXBlIG9mIERJIHdpbGwgYmUgdXNlZCBvbiBEU0wg bmV0d29ya3M/IEEgbG93ZXItbGF5ZXIgcGVyLXBhY2tldA0KaWRlbnRpZmllciAoc291cmNlIGFk ZHJlc3MpIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGUgaW4gYWxsIGRlcGxveW1lbnRzLiBJbg0KdGhh dCBjYXNlLCBhIGRpZmZlcmVudCB0eXBlIG9mIGlkZW50aWZpZXIsIHN1Y2ggYXMgInBoeXNpY2Fs IGludGVyZmFjZSBvbiB0aGUgDQpQQUEiIG1pZ2h0IGJlIHVzZWQuIFRoYXQgaW50ZXJmYWNlIG1p Z2h0IGJlIGEgdmlydHVhbCBjaXJjdWl0IGRlZGljYXRlZCB0byBhIA0KUGFDLg0KDQotLS0tLS0t LS0tDQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBhbmEt eHgudHh0DQptZXNzYWdlczogMjQ0DQpub3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IFNob3VsZCBG aXgNCnN0YXR1czogUGVuZGluZw0KdGl0bGU6IERJIG9uIERTTA0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEgSXNzdWVzIDxwYW5hX2lzc3Vl c0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVyZy5pbmZvOjgwODAvcGFuYS1p c3N1ZXMvaXNzdWU3Mz4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Mar 19 02:09:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14741 for ; Fri, 19 Mar 2004 02:09:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E7u-0004Ka-DP for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 02:09:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J795X4016629 for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 02:09:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E7s-0004Jl-Ll for pana-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 02:09:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14182 for ; Fri, 19 Mar 2004 02:09:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E7p-0000VA-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:09:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E6s-0000Pm-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:08:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4E5y-0000L7-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:07:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E5y-0003Qi-6p; Fri, 19 Mar 2004 02:07:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E5n-0003M0-3V for pana@optimus.ietf.org; Fri, 19 Mar 2004 02:06:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11924 for ; Fri, 19 Mar 2004 02:06:52 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E5j-0000J2-00 for pana@ietf.org; Fri, 19 Mar 2004 02:06:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E4p-0000F4-00 for pana@ietf.org; Fri, 19 Mar 2004 02:05:55 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B4E3w-0000B0-00 for pana@ietf.org; Fri, 19 Mar 2004 02:05:00 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J750p02356 for ; Fri, 19 Mar 2004 09:05:00 +0200 (EET) X-Scanned: Fri, 19 Mar 2004 09:04:38 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2J74c10015992 for ; Fri, 19 Mar 2004 09:04:38 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00by2inE; Fri, 19 Mar 2004 09:04:37 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J74as09758 for ; Fri, 19 Mar 2004 09:04:36 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 19 Mar 2004 09:04:36 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 19 Mar 2004 09:04:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 19 Mar 2004 09:04:36 +0200 Message-ID: Thread-Topic: [issue74] Using PBR/A instead of PRAR/A upon movement Thread-Index: AcQNgAlLt3haEHWyQDKq4LV6RYrWUgAAFuCA To: X-OriginalArrivalTime: 19 Mar 2004 07:04:35.0853 (UTC) FILETIME=[6FF52BD0:01C40D80] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue74] Using PBR/A instead of PRAR/A upon movement Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RnJvbSBBbHBlci4uDQoNCk5ldyBzdWJtaXNzaW9uIGZyb20gRGFuIEZvcnNiZXJnIDxkYW4uZm9y c2JlcmdAbm9raWEuY29tPjoNCg0KVGhlIGN1cnJlbnQgZGVzaWduIGlzIHVzaW5nIFBSQVIgYW5k IFBSQUEgZm9yIG1vYmlsaXR5IG9wdGltaXphdGlvbi4NCg0KUGFDICAgICAgIFBBQQ0KLS0tLS0+ IFBESQ0KPC0tLS0tIFBTUg0KLS0tLS0+IFBTQStTZXNzaW9uSUQNCjwtLS0tLSBQUkFSDQotLS0t LT4gUFJBQQ0KDQpXZSBjYW4gdXNlIFBCUiBhbmQgUEJBIGluc3RlYWQsIHdoaWNoIHdpbGwgYmUg YmV0dGVyIGFsaWduZWQgd2l0aCANCnRoZSByZWd1bGFyIHNpZ25hbGxpbmcuDQoNCi0tLS0tLS0t LS0NCmNhdGVnb3J5OiBUZWNobmljYWwNCmRvY3VtZW50OiBkcmFmdC1pZXRmLXBhbmEtcGFuYS14 eC50eHQNCm1lc3NhZ2VzOiAyNDUNCm5vc3k6IGRmb3JzYmVyDQpwcmlvcml0eTogTWF5IEZpeA0K c3RhdHVzOiBQZW5kaW5nDQp0aXRsZTogVXNpbmcgUEJSL0EgaW5zdGVhZCBvZiBQUkFSL0EgdXBv biBtb3ZlbWVudA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClBBTkEgSXNzdWVzIDxwYW5hX2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6 Ly9kYW5mb3JzYmVyZy5pbmZvOjgwODAvcGFuYS1pc3N1ZXMvaXNzdWU3ND4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Mar 19 02:11:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16772 for ; Fri, 19 Mar 2004 02:11:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E9m-00059Y-Km; Fri, 19 Mar 2004 02:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E8s-0004iE-9N for pana@optimus.ietf.org; Fri, 19 Mar 2004 02:10:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15253 for ; Fri, 19 Mar 2004 02:10:03 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E8o-0000ax-00 for pana@ietf.org; Fri, 19 Mar 2004 02:10:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E80-0000Wn-00 for pana@ietf.org; Fri, 19 Mar 2004 02:09:13 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B4E7O-0000Ru-00 for pana@ietf.org; Fri, 19 Mar 2004 02:08:34 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J78Yp05869 for ; Fri, 19 Mar 2004 09:08:34 +0200 (EET) X-Scanned: Fri, 19 Mar 2004 09:08:12 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2J78C3a022405 for ; Fri, 19 Mar 2004 09:08:12 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Kp4Yv4; Fri, 19 Mar 2004 09:07:44 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J77gs12287 for ; Fri, 19 Mar 2004 09:07:42 +0200 (EET) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 19 Mar 2004 09:07:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 19 Mar 2004 09:07:31 +0200 Message-ID: Thread-Topic: [issue75] Why is DI information exchanged during PBR/A? Thread-Index: AcQNgMvKvf2pfspnRo2EmTipxlP8MQAAAKHQ To: X-OriginalArrivalTime: 19 Mar 2004 07:07:32.0188 (UTC) FILETIME=[D90FC1C0:01C40D80] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue75] Why is DI information exchanged during PBR/A? Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 RnJvbSBBbHBlci4uDQoNCk5ldyBzdWJtaXNzaW9uIGZyb20gRGFuIEZvcnNiZXJnIDxkYW4uZm9y c2JlcmdAbm9raWEuY29tPjoNCg0KIlRoZSBQQU5BLUJpbmQtUmVxdWVzdCBhbmQgdGhlDQrCoMKg IFBBTkEtQmluZC1BbnN3ZXIgbWVzc2FnZSBleGNoYW5nZSBpcyBhbHNvIHVzZWQgZm9yIGJpbmRp bmcgZGV2aWNlDQrCoMKgIGlkZW50aWZpZXJzIG9mIHRoZSBQYUMgYW5kIHRoZSBQQUEgdG8gdGhl IFBBTkEgU0EuIFRvIGFjaGlldmUgdGhpcywNCsKgwqAgdGhlIFBBTkEtQmluZC1SZXF1ZXN0IGFu ZCB0aGUgUEFOQS1CaW5kLUFuc3dlciBTSE9VTEQgY29udGFpbiBhDQrCoMKgIGRldmljZSBpZGVu dGlmaWVyIG9mIHRoZSBQQUEgYW5kIHRoZSBQYUMsIHJlc3BlY3RpdmVseSwgaW4gYQ0KwqDCoCBE ZXZpY2UtSWQgQVZQLsKgIFRoZSBQYUMgTVVTVCB1c2UgdGhlIHNhbWUgdHlwZSBvZiBkZXZpY2Ug aWRlbnRpZmllcg0KwqDCoCBhcyBjb250YWluZWQgaW4gdGhlIFBBTkEtQmluZC1SZXF1ZXN0IG1l c3NhZ2UuIg0KDQpJdCdkIGJlIHVzZWZ1bCB0byBleHBsYWluIChvbmUgbGluZSBvciB0d28pIHdo eSBESSBpcyBleGNoYW5nZWQuICh0byBwcmV2ZW50DQpNaXRNIGF0dGFja3MpLg0KDQotLS0tLS0t LS0tDQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBhbmEt eHgudHh0DQptZXNzYWdlczogMjQ2DQpub3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IE11c3QgRml4 DQpzdGF0dXM6IENsYXJpZnlpbmcgVGV4dCBSZXF1aXJlZA0KdGl0bGU6IFdoeSBpcyBESSBpbmZv cm1hdGlvbiBleGNoYW5nZWQgZHVyaW5nIFBCUi9BPw0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEgSXNzdWVzIDxwYW5hX2lzc3Vlc0BkYW5m b3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVyZy5pbmZvOjgwODAvcGFuYS1pc3N1ZXMv aXNzdWU3NT4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Mar 19 02:13:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18062 for ; Fri, 19 Mar 2004 02:13:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4EBe-0005rs-P9 for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 02:12:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J7CvCT022534 for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 02:12:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4EBd-0005rB-5b for pana-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 02:12:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17986 for ; Fri, 19 Mar 2004 02:12:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4EBZ-0000pj-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:12:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4EAf-0000ku-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:11:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4E9m-0000gb-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:11:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E9m-00059Y-Km; Fri, 19 Mar 2004 02:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E8s-0004iE-9N for pana@optimus.ietf.org; Fri, 19 Mar 2004 02:10:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15253 for ; Fri, 19 Mar 2004 02:10:03 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E8o-0000ax-00 for pana@ietf.org; Fri, 19 Mar 2004 02:10:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E80-0000Wn-00 for pana@ietf.org; Fri, 19 Mar 2004 02:09:13 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B4E7O-0000Ru-00 for pana@ietf.org; Fri, 19 Mar 2004 02:08:34 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J78Yp05869 for ; Fri, 19 Mar 2004 09:08:34 +0200 (EET) X-Scanned: Fri, 19 Mar 2004 09:08:12 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2J78C3a022405 for ; Fri, 19 Mar 2004 09:08:12 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00Kp4Yv4; Fri, 19 Mar 2004 09:07:44 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J77gs12287 for ; Fri, 19 Mar 2004 09:07:42 +0200 (EET) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 19 Mar 2004 09:07:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 19 Mar 2004 09:07:31 +0200 Message-ID: Thread-Topic: [issue75] Why is DI information exchanged during PBR/A? Thread-Index: AcQNgMvKvf2pfspnRo2EmTipxlP8MQAAAKHQ To: X-OriginalArrivalTime: 19 Mar 2004 07:07:32.0188 (UTC) FILETIME=[D90FC1C0:01C40D80] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue75] Why is DI information exchanged during PBR/A? Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RnJvbSBBbHBlci4uDQoNCk5ldyBzdWJtaXNzaW9uIGZyb20gRGFuIEZvcnNiZXJnIDxkYW4uZm9y c2JlcmdAbm9raWEuY29tPjoNCg0KIlRoZSBQQU5BLUJpbmQtUmVxdWVzdCBhbmQgdGhlDQrCoMKg IFBBTkEtQmluZC1BbnN3ZXIgbWVzc2FnZSBleGNoYW5nZSBpcyBhbHNvIHVzZWQgZm9yIGJpbmRp bmcgZGV2aWNlDQrCoMKgIGlkZW50aWZpZXJzIG9mIHRoZSBQYUMgYW5kIHRoZSBQQUEgdG8gdGhl IFBBTkEgU0EuIFRvIGFjaGlldmUgdGhpcywNCsKgwqAgdGhlIFBBTkEtQmluZC1SZXF1ZXN0IGFu ZCB0aGUgUEFOQS1CaW5kLUFuc3dlciBTSE9VTEQgY29udGFpbiBhDQrCoMKgIGRldmljZSBpZGVu dGlmaWVyIG9mIHRoZSBQQUEgYW5kIHRoZSBQYUMsIHJlc3BlY3RpdmVseSwgaW4gYQ0KwqDCoCBE ZXZpY2UtSWQgQVZQLsKgIFRoZSBQYUMgTVVTVCB1c2UgdGhlIHNhbWUgdHlwZSBvZiBkZXZpY2Ug aWRlbnRpZmllcg0KwqDCoCBhcyBjb250YWluZWQgaW4gdGhlIFBBTkEtQmluZC1SZXF1ZXN0IG1l c3NhZ2UuIg0KDQpJdCdkIGJlIHVzZWZ1bCB0byBleHBsYWluIChvbmUgbGluZSBvciB0d28pIHdo eSBESSBpcyBleGNoYW5nZWQuICh0byBwcmV2ZW50DQpNaXRNIGF0dGFja3MpLg0KDQotLS0tLS0t LS0tDQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBhbmEt eHgudHh0DQptZXNzYWdlczogMjQ2DQpub3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IE11c3QgRml4 DQpzdGF0dXM6IENsYXJpZnlpbmcgVGV4dCBSZXF1aXJlZA0KdGl0bGU6IFdoeSBpcyBESSBpbmZv cm1hdGlvbiBleGNoYW5nZWQgZHVyaW5nIFBCUi9BPw0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEgSXNzdWVzIDxwYW5hX2lzc3Vlc0BkYW5m b3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVyZy5pbmZvOjgwODAvcGFuYS1pc3N1ZXMv aXNzdWU3NT4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Mar 19 03:02:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14750 for ; Fri, 19 Mar 2004 02:09:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E7u-0004Kd-J2 for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 02:09:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J795fw016636 for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 02:09:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E7t-0004K7-9Z for pana-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 02:09:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14195 for ; Fri, 19 Mar 2004 02:09:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E7p-0000VE-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:09:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E6t-0000Pw-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:08:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4E5y-0000L9-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 02:07:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E60-0003UK-NO; Fri, 19 Mar 2004 02:07:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E5n-0003ML-Rz for pana@optimus.ietf.org; Fri, 19 Mar 2004 02:06:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11936 for ; Fri, 19 Mar 2004 02:06:53 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E5k-0000J7-00 for pana@ietf.org; Fri, 19 Mar 2004 02:06:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E4s-0000FW-00 for pana@ietf.org; Fri, 19 Mar 2004 02:05:59 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B4E3z-0000BY-00 for pana@ietf.org; Fri, 19 Mar 2004 02:05:03 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J753p02410 for ; Fri, 19 Mar 2004 09:05:03 +0200 (EET) X-Scanned: Fri, 19 Mar 2004 09:04:56 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i2J74uvB016414 for ; Fri, 19 Mar 2004 09:04:56 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00x7M4Qd; Fri, 19 Mar 2004 09:04:53 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2J74rs09943 for ; Fri, 19 Mar 2004 09:04:53 +0200 (EET) Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 19 Mar 2004 09:04:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 19 Mar 2004 09:04:53 +0200 Message-ID: Thread-Topic: [issue76] Rate limitation on Reauth clarification neeeded Thread-Index: AcQNgGnwXv1xicFLQeu9DZgcjQSijgAAAeDQ To: X-OriginalArrivalTime: 19 Mar 2004 07:04:53.0947 (UTC) FILETIME=[7ABE18B0:01C40D80] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue76] Rate limitation on Reauth clarification neeeded Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RnJvbSBBbHBlci4uDQoNCk5ldyBzdWJtaXNzaW9uIGZyb20gRGFuIEZvcnNiZXJnIDxkYW4uZm9y c2JlcmdAbm9raWEuY29tPjoNCg0KIkltcGxlbWVudGF0aW9ucyBNVVNUIGxpbWl0IHRoZSByYXRl IG9mIHBlcmZvcm1pbmcgcmUtYXV0aGVudGljYXRpb24NCiAgIGZvciBib3RoIHR5cGVzIG9mIHJl LWF1dGhlbnRpY2F0aW9uLiINCg0KRWFjaCBzaWRlIGNhbiBoYW5kbGUgcmF0ZSBsaW1pdGF0aW9u IG9uIHRoZWlyIG93biwNCnRoZXkgZG9uJ3QgaGF2ZSB0byBjb29yZGluYXRlIGluIGFueSB3YXku IFRoZXJlIGlzIG5vIG5lZ290aWF0aW9uDQpvZiB0aW1lcnMgZm9yIHRoaXMgY2FzZS4gV2Ugc2hv dWxkIGV4cGxpY2l0bHkgc3RhdGUgdGhhdC4NCg0KLS0tLS0tLS0tLQ0KY2F0ZWdvcnk6IFRlY2hu aWNhbA0KZG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGFuYS1wYW5hLXh4LnR4dA0KbWVzc2FnZXM6IDI0 Nw0Kbm9zeTogZGZvcnNiZXINCnByaW9yaXR5OiBTaG91bGQgRml4DQpzdGF0dXM6IENsYXJpZnlp bmcgVGV4dCBSZXF1aXJlZA0KdGl0bGU6IFJhdGUgbGltaXRhdGlvbiBvbiBSZWF1dGggY2xhcmlm aWNhdGlvbiBuZWVlZGVkDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KUEFOQSBJc3N1ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmluZm8+DQo8 aHR0cDovL2RhbmZvcnNiZXJnLmluZm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTc2Pg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Mar 19 03:06:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21255 for ; Fri, 19 Mar 2004 03:06:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4F12-0004PC-8v; Fri, 19 Mar 2004 03:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4F0w-0004O3-Qx for pana@optimus.ietf.org; Fri, 19 Mar 2004 03:05:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21241 for ; Fri, 19 Mar 2004 03:05:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4F0s-0004J0-00 for pana@ietf.org; Fri, 19 Mar 2004 03:05:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Ezu-0004Ee-00 for pana@ietf.org; Fri, 19 Mar 2004 03:04:55 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B4Eyw-00049i-00 for pana@ietf.org; Fri, 19 Mar 2004 03:03:54 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2J83sKL025711; Fri, 19 Mar 2004 17:03:54 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2J83sTC010446; Fri, 19 Mar 2004 17:03:54 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id TAA10443 ; Fri, 19 Mar 2004 17:03:54 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id RAA29061; Fri, 19 Mar 2004 17:03:53 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id RAA13867; Fri, 19 Mar 2004 17:03:52 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2J83pDb015789; Fri, 19 Mar 2004 17:03:52 +0900 (JST) Received: from steelhead (att01-015.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUT0042SD2C62@tsbpo1.po.toshiba.co.jp>; Fri, 19 Mar 2004 17:03:50 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3ZpA-0005fH-00; Wed, 17 Mar 2004 04:07:04 -0800 Date: Wed, 17 Mar 2004 04:07:03 -0800 From: Yoshihiro Ohba Subject: Re: Re :Re: [Pana] issue 57 (resolution) In-reply-to: <7695533.1079671877524.JavaMail.weblogic@ep_app07> To: Alper Yegin Cc: Yoshihiro Ohba , "pana@ietf.org " Message-id: <20040317120703.GE16687@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , "pana@ietf.org " User-Agent: Mutt/1.5.5.1+cvs20040105i References: <7695533.1079671877524.JavaMail.weblogic@ep_app07> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Fri, Mar 19, 2004 at 04:51:20AM +0000, Alper Yegin wrote: > > > > - There is an exception. If the requester remains stateless after > > > > sending a request, the responder should take the responsibility of > > > > retransmission. This cases occurs only for PSR/PSA exchange, and > > > > retransmission of PDI and PSA can archieve the responsibility. The > > > > presence of the cookie indicates that the requester remains stateless. > > > > > > If there is no PDI, and PSR is not retransmitted at all, when the single > > PSR > > > is lost, the PANA exchange will hang. > > > > Right. That is why I used "retransmission of PDI and PSA". > > Yes, but PDI is not always used. In case we are performing "data driven > PAA discovery", we rely on unsolicited PSR. And if, at the same time, > we want the PAA to stay stateless, there is a problem. According to > your rule, if PSR is lost, there is no retransmission and hence no progress. > This is a problem with your scheme. Do you agree? I am not viewing it as a problem. Please see below. > > > > I understand your point. I guess the problem is, "being stateless" and > > > "performing unsolicited PAA discovery" do not mix well. > > > > Yes, When PAA is performing unsolicited PAA discovery, the PAA should > > be stateful, otherwise the PANA exchange will hang if PSR is lost. > > Hence PSR is always retransmitted in unsolicited discovery (we no longer > care of we are trying to be stateless or not). If this is what you are saying too, > we are in agreement. How can a PAA in unsolicited discovery retransmit PSR while being stateless? In order to retransmit PSR, PAA has to maintain some state for the PaC, including the Device-Id of the PaC, the initial tseq used for the PaC and the current number of retransmissions. It seems that unsoliciated discovery and statelessness are essentially conflicting features, and thus this should not be viewed as a problem. Yoshihiro Ohba > > > On > > the other hand, when PAA is perfomring solicited PAA discovery, it can > > be either stateless or stateful. > > Yes. > > Alper > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > Some other clue could be > > > > > used to stop one side from retransmitting. For example in my case, > > > > > receipt of PDI by the PAA could cease the PSR retransmissions on the > > > > > PAA. > > > > > > > > That is also possible. Which strategy do you think is better? > > > > > > > > Yoshihiro Ohba > > > > > > Alper > > > > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > - > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > " > > > > > > > > A PANA-Start-Request message that carries a Cookie AVP is > > never > > > > > > > > retransmitted. A PANA-Start-Request message that does not > > > > > carry a > > > > > > > > Cookie AVP is retransmitted based on timer. A > > > > > PANA-Start-Answer > > > > > > > > message that carries a Cookie AVP is retransmitted based on > > > > > timer. > > > > > > > > A PANA-Start-Answer message that does not carry a Cookie > > AVP is > > > > > > > > never retransmitted based on timer. > > > > > > > > " > > > > > > > > > > > > > > > > Change the first paragraph of section 10 to: > > > > > > > > > > > > > > > > "The PANA protocol provides retransmissions for all the > > message > > > > > > > > exchanges except PANA-Auth-Request/Answer. PANA-Auth- > > Request > > > > > > > messages > > > > > > > > carry EAP requests which are retransmitted by the EAP > > protocol > > > > > > > > entities when needed. The messages that need PANA-level > > > > > > > > retransmissions are listed below: > > > > > > > > > > > > > > > > PANA-PAA-Discover (PDI) > > > > > > > > PANA-Start-Request (PSR)* > > > > > > > > PANA-Start-Answer (PSA)** > > > > > > > > PANA-Bind-Request (PBR) > > > > > > > > PANA-FirstAuth-End-Request (PFER) > > > > > > > > PANA-Reauth-Request (PRAR) > > > > > > > > PANA-Termination-Request (PTR) > > > > > > > > > > > > > > > > *) PSR that carries a Cookie AVP is not retransmitted. > > > > > > > > **) PSA that does not carry a Cookie AVP is not > > retransmitted." > > > > > > > > > > > > > > > > > > > > > > > > (Note: PFER message is introduced for issue 52.) > > > > > > > > > > > > > > > > Regards, > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Pana mailing list > > > > > > > > Pana@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Pana mailing list > > > > > > > Pana@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Mar 19 03:08:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21316 for ; Fri, 19 Mar 2004 03:08:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4F2w-0004mC-Fd for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 03:08:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J882Gs018359 for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 03:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4F2v-0004ll-5N for pana-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 03:08:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21291 for ; Fri, 19 Mar 2004 03:07:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4F2r-0004SG-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 03:07:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4F1w-0004OJ-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 03:07:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4F14-0004Kp-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 03:06:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4F12-0004PC-8v; Fri, 19 Mar 2004 03:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4F0w-0004O3-Qx for pana@optimus.ietf.org; Fri, 19 Mar 2004 03:05:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21241 for ; Fri, 19 Mar 2004 03:05:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4F0s-0004J0-00 for pana@ietf.org; Fri, 19 Mar 2004 03:05:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Ezu-0004Ee-00 for pana@ietf.org; Fri, 19 Mar 2004 03:04:55 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B4Eyw-00049i-00 for pana@ietf.org; Fri, 19 Mar 2004 03:03:54 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2J83sKL025711; Fri, 19 Mar 2004 17:03:54 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2J83sTC010446; Fri, 19 Mar 2004 17:03:54 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id TAA10443 ; Fri, 19 Mar 2004 17:03:54 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id RAA29061; Fri, 19 Mar 2004 17:03:53 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id RAA13867; Fri, 19 Mar 2004 17:03:52 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2J83pDb015789; Fri, 19 Mar 2004 17:03:52 +0900 (JST) Received: from steelhead (att01-015.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUT0042SD2C62@tsbpo1.po.toshiba.co.jp>; Fri, 19 Mar 2004 17:03:50 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3ZpA-0005fH-00; Wed, 17 Mar 2004 04:07:04 -0800 Date: Wed, 17 Mar 2004 04:07:03 -0800 From: Yoshihiro Ohba Subject: Re: Re :Re: [Pana] issue 57 (resolution) In-reply-to: <7695533.1079671877524.JavaMail.weblogic@ep_app07> To: Alper Yegin Cc: Yoshihiro Ohba , "pana@ietf.org " Message-id: <20040317120703.GE16687@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , Yoshihiro Ohba , "pana@ietf.org " User-Agent: Mutt/1.5.5.1+cvs20040105i References: <7695533.1079671877524.JavaMail.weblogic@ep_app07> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, Mar 19, 2004 at 04:51:20AM +0000, Alper Yegin wrote: > > > > - There is an exception. If the requester remains stateless after > > > > sending a request, the responder should take the responsibility of > > > > retransmission. This cases occurs only for PSR/PSA exchange, and > > > > retransmission of PDI and PSA can archieve the responsibility. The > > > > presence of the cookie indicates that the requester remains stateless. > > > > > > If there is no PDI, and PSR is not retransmitted at all, when the single > > PSR > > > is lost, the PANA exchange will hang. > > > > Right. That is why I used "retransmission of PDI and PSA". > > Yes, but PDI is not always used. In case we are performing "data driven > PAA discovery", we rely on unsolicited PSR. And if, at the same time, > we want the PAA to stay stateless, there is a problem. According to > your rule, if PSR is lost, there is no retransmission and hence no progress. > This is a problem with your scheme. Do you agree? I am not viewing it as a problem. Please see below. > > > > I understand your point. I guess the problem is, "being stateless" and > > > "performing unsolicited PAA discovery" do not mix well. > > > > Yes, When PAA is performing unsolicited PAA discovery, the PAA should > > be stateful, otherwise the PANA exchange will hang if PSR is lost. > > Hence PSR is always retransmitted in unsolicited discovery (we no longer > care of we are trying to be stateless or not). If this is what you are saying too, > we are in agreement. How can a PAA in unsolicited discovery retransmit PSR while being stateless? In order to retransmit PSR, PAA has to maintain some state for the PaC, including the Device-Id of the PaC, the initial tseq used for the PaC and the current number of retransmissions. It seems that unsoliciated discovery and statelessness are essentially conflicting features, and thus this should not be viewed as a problem. Yoshihiro Ohba > > > On > > the other hand, when PAA is perfomring solicited PAA discovery, it can > > be either stateless or stateful. > > Yes. > > Alper > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > Some other clue could be > > > > > used to stop one side from retransmitting. For example in my case, > > > > > receipt of PDI by the PAA could cease the PSR retransmissions on the > > > > > PAA. > > > > > > > > That is also possible. Which strategy do you think is better? > > > > > > > > Yoshihiro Ohba > > > > > > Alper > > > > > > > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > - > > > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > " > > > > > > > > A PANA-Start-Request message that carries a Cookie AVP is > > never > > > > > > > > retransmitted. A PANA-Start-Request message that does not > > > > > carry a > > > > > > > > Cookie AVP is retransmitted based on timer. A > > > > > PANA-Start-Answer > > > > > > > > message that carries a Cookie AVP is retransmitted based on > > > > > timer. > > > > > > > > A PANA-Start-Answer message that does not carry a Cookie > > AVP is > > > > > > > > never retransmitted based on timer. > > > > > > > > " > > > > > > > > > > > > > > > > Change the first paragraph of section 10 to: > > > > > > > > > > > > > > > > "The PANA protocol provides retransmissions for all the > > message > > > > > > > > exchanges except PANA-Auth-Request/Answer. PANA-Auth- > > Request > > > > > > > messages > > > > > > > > carry EAP requests which are retransmitted by the EAP > > protocol > > > > > > > > entities when needed. The messages that need PANA-level > > > > > > > > retransmissions are listed below: > > > > > > > > > > > > > > > > PANA-PAA-Discover (PDI) > > > > > > > > PANA-Start-Request (PSR)* > > > > > > > > PANA-Start-Answer (PSA)** > > > > > > > > PANA-Bind-Request (PBR) > > > > > > > > PANA-FirstAuth-End-Request (PFER) > > > > > > > > PANA-Reauth-Request (PRAR) > > > > > > > > PANA-Termination-Request (PTR) > > > > > > > > > > > > > > > > *) PSR that carries a Cookie AVP is not retransmitted. > > > > > > > > **) PSA that does not carry a Cookie AVP is not > > retransmitted." > > > > > > > > > > > > > > > > > > > > > > > > (Note: PFER message is introduced for issue 52.) > > > > > > > > > > > > > > > > Regards, > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Pana mailing list > > > > > > > > Pana@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Pana mailing list > > > > > > > Pana@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > _______________________________________________ > > > Pana mailing list > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Mar 19 16:56:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26733 for ; Fri, 19 Mar 2004 16:56:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RyE-0003sh-Jl; Fri, 19 Mar 2004 16:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Rxl-0003re-MX for pana@optimus.ietf.org; Fri, 19 Mar 2004 16:55:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26719 for ; Fri, 19 Mar 2004 16:55:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Rxj-0007iO-00 for pana@ietf.org; Fri, 19 Mar 2004 16:55:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Rwt-0007da-00 for pana@ietf.org; Fri, 19 Mar 2004 16:54:40 -0500 Received: from smtp808.mail.sc5.yahoo.com ([66.163.168.187]) by ietf-mx with smtp (Exim 4.12) id 1B4RwL-0007Xd-00 for pana@ietf.org; Fri, 19 Mar 2004 16:54:05 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 19 Mar 2004 21:54:04 -0000 Message-ID: <015201c40dfc$b1327450$861167c0@adithya> From: "Mohan Parthasarathy" To: , References: Subject: Re: [Pana] NEW: [issue72] Capability discovery during PAA discovery Date: Fri, 19 Mar 2004 13:54:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA26720 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > From Alper.. > > New submission from Dan Forsberg : > > Currently capability discovery is not accomplished until the end of > EAP authentication. Copying some bits, such as POPA types and > per-packet protection capability, to PAA discovery may be useful for > discovering capability mismatch early on. > So, there are two issues here. 1) Adding some capability AVPs to PANA-start-request message. 2) Enabling verification later on to compensate for the lack of security = in the discovery phase (i guess when the Pana-bind-request message is received) Is that right ? I can see it being useful in general, but how useful it is to know early = on the POPA type and per-protection capabilities ? -thanks mohan > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 243 > nosy: dforsber > priority: Should Fix > status: Pending > title: Capability discovery during PAA discovery > __________________________________________________ > PANA Issues > > __________________________________________________ > =3D=DA=99x%Ojv=CB=A2z =08m? 0 '~ ffX) Z _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Mar 19 16:58:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26778 for ; Fri, 19 Mar 2004 16:58:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Rzg-0003zQ-Nd for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 16:57:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JLvW3F015335 for pana-archive@odin.ietf.org; Fri, 19 Mar 2004 16:57:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Rzg-0003zG-J0 for pana-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 16:57:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26770 for ; Fri, 19 Mar 2004 16:57:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Rze-00007M-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 16:57:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Rym-00001J-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 16:56:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4RyI-0007jK-00 for pana-web-archive@ietf.org; Fri, 19 Mar 2004 16:56:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RyE-0003sh-Jl; Fri, 19 Mar 2004 16:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Rxl-0003re-MX for pana@optimus.ietf.org; Fri, 19 Mar 2004 16:55:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26719 for ; Fri, 19 Mar 2004 16:55:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Rxj-0007iO-00 for pana@ietf.org; Fri, 19 Mar 2004 16:55:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Rwt-0007da-00 for pana@ietf.org; Fri, 19 Mar 2004 16:54:40 -0500 Received: from smtp808.mail.sc5.yahoo.com ([66.163.168.187]) by ietf-mx with smtp (Exim 4.12) id 1B4RwL-0007Xd-00 for pana@ietf.org; Fri, 19 Mar 2004 16:54:05 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 19 Mar 2004 21:54:04 -0000 Message-ID: <015201c40dfc$b1327450$861167c0@adithya> From: "Mohan Parthasarathy" To: , References: Subject: Re: [Pana] NEW: [issue72] Capability discovery during PAA discovery Date: Fri, 19 Mar 2004 13:54:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA26720 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > From Alper.. > > New submission from Dan Forsberg : > > Currently capability discovery is not accomplished until the end of > EAP authentication. Copying some bits, such as POPA types and > per-packet protection capability, to PAA discovery may be useful for > discovering capability mismatch early on. > So, there are two issues here. 1) Adding some capability AVPs to PANA-start-request message. 2) Enabling verification later on to compensate for the lack of security = in the discovery phase (i guess when the Pana-bind-request message is received) Is that right ? I can see it being useful in general, but how useful it is to know early = on the POPA type and per-protection capabilities ? -thanks mohan > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 243 > nosy: dforsber > priority: Should Fix > status: Pending > title: Capability discovery during PAA discovery > __________________________________________________ > PANA Issues > > __________________________________________________ > =3D=DA=99x%Ojv=CB=A2z =08m? 0 '~ ffX) Z _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Mar 22 01:19:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22463 for ; Mon, 22 Mar 2004 01:19:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Im4-00014O-Od; Mon, 22 Mar 2004 01:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Ilf-00013K-KR for pana@optimus.ietf.org; Mon, 22 Mar 2004 01:18:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22359 for ; Mon, 22 Mar 2004 01:18:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Ilc-0001UT-00 for pana@ietf.org; Mon, 22 Mar 2004 01:18:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Ikd-0001Lh-00 for pana@ietf.org; Mon, 22 Mar 2004 01:17:32 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B5Iju-0001AH-00 for pana@ietf.org; Mon, 22 Mar 2004 01:16:46 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUY00L0RS2XNT@mailout3.samsung.com> for pana@ietf.org; Mon, 22 Mar 2004 15:16:09 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUY001JKRU5K6@mailout3.samsung.com> for pana@ietf.org; Mon, 22 Mar 2004 15:10:53 +0900 (KST) Received: from Alperyegin ([75.2.47.51]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUY00AKHRU467@mmp2.samsung.com> for pana@ietf.org; Mon, 22 Mar 2004 15:10:53 +0900 (KST) Date: Sun, 21 Mar 2004 22:10:55 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <001d01c40fd4$700dea20$332f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] Issue 58 and issue 74: proposed text Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Here is an attempt to resolve issues 58 and 74. Outline of the changes: - pointing deployment considerations for this optimization as analyzed in the EAP keying framework document. - previous PAA is determined based on the new session-ID AVP format. - PANA-reauth exchange is replaced by PANA-Bind exchange. - Computation of context transferred AAA-key is included in the draft. It can be removed if and when the EAP keying framework document incorporates it. (note: that draft already describes how this is done for proactive optimizations, but not the ones based on context transfers) Here we go.... New text for section 4.9: 4.9 Mobility Handling Upon changing its point of attachment, a PaC that wants to quickly resume its ongoing PANA session without running EAP MAY send the unexpired PANA session identifier in its PANA-Start-Answer message. This will signal PaC's desire to perform the mobility optimization. In the absence of a Session-Id AVP in this message, PANA session takes its usual course (i.e., EAP-based authentication is performed). If PAA receives a session identifier in the PANA-Start-Answer message, and it is configured to enable fast re-authentication, it SHOULD retrieve the PANA session attributes from the previous PAA of the PaC. Current PAA determines the identity of the previous PAA by looking at the DiameterIdentity part of the PANA session identifier. The mechanism required to retrieve the session attributes from the previous PAA is outside the scope of this protocol. Seamoby Context Transfer Protocol [I-D.ietf-seamoby-ctp] might be useful for this purpose. When the previous or current PAA is not configured to enable fast re-authentication, the current PAA can not retrieve the PANA session attributes, or the PANA session has already expired (i.e., session lifetime is zero), the PAA MUST send the PANA-Auth-Request message with the new session identifier and let the PANA exchange take its usual course. This action will engage EAP-based authentication and create a fresh PANA session from scratch. In case the current PAA can retrieve the on-going PANA session attributes from the previous PAA, the PANA session continues with a PANA-Bind exchange. The required AAA-Key is provided by the previous PAA to the current PAA. PAA and PaC perform the following computation for generating the new AAA-Key: AAA-Key-new = The first N bits of HMAC-SHA1(EMSK(0,63), AAA-Key | DiameterIdentity | Session-ID) The value of N depends on the integrity protection algorithm in use, i.e., N=160 for HMAC-SHA1. EMSK and AAA-Key are the EAP-based keys that were made available to previous PAA and PaC as a result of the earlier EAP authentication. Due to the reliance on EMSK, this optimization only works when PaC has performed an EAP-based authentication on the previous PAA. DiameterIdentity is the identifier of the current PAA. Session-ID is the identifier of the PaC's PANA session with the previous PAA. New PANA_MAC_Key is computed based on the algorithm described in section 4.1.5, by using the new AAA-Key and the new Session-ID assigned by the current PAA. The MAC AVP contained in the PANA-Bind messages MUST be generated and verified by using the new PANA_MAC_Key. Session-ID AVP MUST include a new session identifier assigned by the current PAA. A new PANA session is created upon successful completion of this exchange. Note that correct operation of this optimization relies on many factors, including applicability of authorization state from one network attachment to another. [I-D.ietf-eap-keying] identifies this operation as "fast handoff" and provides deployment considerations. Operators are recommended to take those guidelines into account when using this optimization in their networks. Change section 9.3.7 from: 9.3.7 PANA-Bind-Request (PBR) PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > to: 9.3.7 PANA-Bind-Request (PBR) PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > [ EAP-Payload ] { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > Update the AVP occurrence table from: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | To: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 0-1 | 0 | 0 | Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 22 01:20:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22504 for ; Mon, 22 Mar 2004 01:20:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5InP-0001Cb-LB for pana-archive@odin.ietf.org; Mon, 22 Mar 2004 01:20:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2M6KNM9004615 for pana-archive@odin.ietf.org; Mon, 22 Mar 2004 01:20:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5InP-0001CM-BD for pana-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 01:20:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22501 for ; Mon, 22 Mar 2004 01:20:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5InM-0001iw-00 for pana-web-archive@ietf.org; Mon, 22 Mar 2004 01:20:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ImT-0001cw-00 for pana-web-archive@ietf.org; Mon, 22 Mar 2004 01:19:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5Im7-0001WK-00 for pana-web-archive@ietf.org; Mon, 22 Mar 2004 01:19:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Im4-00014O-Od; Mon, 22 Mar 2004 01:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Ilf-00013K-KR for pana@optimus.ietf.org; Mon, 22 Mar 2004 01:18:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22359 for ; Mon, 22 Mar 2004 01:18:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Ilc-0001UT-00 for pana@ietf.org; Mon, 22 Mar 2004 01:18:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Ikd-0001Lh-00 for pana@ietf.org; Mon, 22 Mar 2004 01:17:32 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1B5Iju-0001AH-00 for pana@ietf.org; Mon, 22 Mar 2004 01:16:46 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HUY00L0RS2XNT@mailout3.samsung.com> for pana@ietf.org; Mon, 22 Mar 2004 15:16:09 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HUY001JKRU5K6@mailout3.samsung.com> for pana@ietf.org; Mon, 22 Mar 2004 15:10:53 +0900 (KST) Received: from Alperyegin ([75.2.47.51]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HUY00AKHRU467@mmp2.samsung.com> for pana@ietf.org; Mon, 22 Mar 2004 15:10:53 +0900 (KST) Date: Sun, 21 Mar 2004 22:10:55 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <001d01c40fd4$700dea20$332f024b@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Pana] Issue 58 and issue 74: proposed text Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Here is an attempt to resolve issues 58 and 74. Outline of the changes: - pointing deployment considerations for this optimization as analyzed in the EAP keying framework document. - previous PAA is determined based on the new session-ID AVP format. - PANA-reauth exchange is replaced by PANA-Bind exchange. - Computation of context transferred AAA-key is included in the draft. It can be removed if and when the EAP keying framework document incorporates it. (note: that draft already describes how this is done for proactive optimizations, but not the ones based on context transfers) Here we go.... New text for section 4.9: 4.9 Mobility Handling Upon changing its point of attachment, a PaC that wants to quickly resume its ongoing PANA session without running EAP MAY send the unexpired PANA session identifier in its PANA-Start-Answer message. This will signal PaC's desire to perform the mobility optimization. In the absence of a Session-Id AVP in this message, PANA session takes its usual course (i.e., EAP-based authentication is performed). If PAA receives a session identifier in the PANA-Start-Answer message, and it is configured to enable fast re-authentication, it SHOULD retrieve the PANA session attributes from the previous PAA of the PaC. Current PAA determines the identity of the previous PAA by looking at the DiameterIdentity part of the PANA session identifier. The mechanism required to retrieve the session attributes from the previous PAA is outside the scope of this protocol. Seamoby Context Transfer Protocol [I-D.ietf-seamoby-ctp] might be useful for this purpose. When the previous or current PAA is not configured to enable fast re-authentication, the current PAA can not retrieve the PANA session attributes, or the PANA session has already expired (i.e., session lifetime is zero), the PAA MUST send the PANA-Auth-Request message with the new session identifier and let the PANA exchange take its usual course. This action will engage EAP-based authentication and create a fresh PANA session from scratch. In case the current PAA can retrieve the on-going PANA session attributes from the previous PAA, the PANA session continues with a PANA-Bind exchange. The required AAA-Key is provided by the previous PAA to the current PAA. PAA and PaC perform the following computation for generating the new AAA-Key: AAA-Key-new = The first N bits of HMAC-SHA1(EMSK(0,63), AAA-Key | DiameterIdentity | Session-ID) The value of N depends on the integrity protection algorithm in use, i.e., N=160 for HMAC-SHA1. EMSK and AAA-Key are the EAP-based keys that were made available to previous PAA and PaC as a result of the earlier EAP authentication. Due to the reliance on EMSK, this optimization only works when PaC has performed an EAP-based authentication on the previous PAA. DiameterIdentity is the identifier of the current PAA. Session-ID is the identifier of the PaC's PANA session with the previous PAA. New PANA_MAC_Key is computed based on the algorithm described in section 4.1.5, by using the new AAA-Key and the new Session-ID assigned by the current PAA. The MAC AVP contained in the PANA-Bind messages MUST be generated and verified by using the new PANA_MAC_Key. Session-ID AVP MUST include a new session identifier assigned by the current PAA. A new PANA session is created upon successful completion of this exchange. Note that correct operation of this optimization relies on many factors, including applicability of authorization state from one network attachment to another. [I-D.ietf-eap-keying] identifies this operation as "fast handoff" and provides deployment considerations. Operators are recommended to take those guidelines into account when using this optimization in their networks. Change section 9.3.7 from: 9.3.7 PANA-Bind-Request (PBR) PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > to: 9.3.7 PANA-Bind-Request (PBR) PANA-Bind-Request (PBR) is sent by the PAA to the PaC. PANA-Bind-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > [ EAP-Payload ] { Result-Code } [ Session-Lifetime ] [ Protection-Capability ] [ Key-Id ] * [ EP-Device-Id ] * [ AVP ] 0*1 < MAC > Update the AVP occurrence table from: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | To: +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 0-1 | 0 | 0 | Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Mar 22 11:28:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04226 for ; Mon, 22 Mar 2004 11:28:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5SGr-00073h-Ci; Mon, 22 Mar 2004 11:27:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5SGC-00070s-EU for pana@optimus.ietf.org; Mon, 22 Mar 2004 11:26:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04010 for ; Mon, 22 Mar 2004 11:26:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5SG7-0007hW-00 for pana@ietf.org; Mon, 22 Mar 2004 11:26:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5SEn-0007S9-00 for pana@ietf.org; Mon, 22 Mar 2004 11:25:18 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B5SDv-0007G8-00 for pana@ietf.org; Mon, 22 Mar 2004 11:24:23 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2MGOHKL002657; Tue, 23 Mar 2004 01:24:17 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2MGOHik009589; Tue, 23 Mar 2004 01:24:17 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA09588 ; Tue, 23 Mar 2004 01:24:17 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA19781; Tue, 23 Mar 2004 01:24:16 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA07290; Tue, 23 Mar 2004 01:24:16 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2MGOF8j023540; Tue, 23 Mar 2004 01:24:15 +0900 (JST) Received: from steelhead (JT01-058.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUZ00MM9K8CM0@tsbpo1.po.toshiba.co.jp>; Tue, 23 Mar 2004 01:24:14 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3fu4-0005pF-00; Wed, 17 Mar 2004 10:36:32 -0800 Date: Wed, 17 Mar 2004 10:36:31 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 52: proposed text In-reply-to: <6427097.1079670447126.JavaMail.weblogic@ep_app07> To: Alper Yegin Cc: "yohba@tari.toshiba.com " , "pana@ietf.org " Message-id: <20040317183631.GN21811@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , "yohba@tari.toshiba.com " , "pana@ietf.org " User-Agent: Mutt/1.5.5.1+cvs20040105i References: <6427097.1079670447126.JavaMail.weblogic@ep_app07> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , On Fri, Mar 19, 2004 at 04:27:56AM +0000, Alper Yegin wrote: > Hi Yoshi, > > Thanks for taking care of this issue. > Please see below for my comments. > > > to: > > > > "A PANA SA is created as an attribute of a PANA session when EAP > > authentication succeeds with a creation of a AAA-Key. A PANA SA is > > not created when the PANA authentication fails or no AAA-Key is > > produced by any EAP authentication method. In the case where two > > EAP authentications are performed in sequence in a single PANA > > authentication phase, it is possible that two AAA-Keys are > > derived. If this happens, the PANA SA MUST be bound to both > > Somehow "bound to" sounds like PANA SA has two keys. Eventually it has > one PANA_MAC_KEY, that is generated from one or two AAA-keys. Maybe we s > hould say "PANA SA is generated from both AAA-Keys". > > Actually, it is even "PANA SA is generated from the AAA-keys available at > the time." After the first auth (NAP, for example), it is generated from the AAA-key > if the auth was a success. After the second auth (ISP), again all the keys > from the successful auth rounds are used with the resultant PANA SA. OK. > > > to: > > > > " > > When a Cookie-AVP is carried in a PANA-Start-Request message, the > > initial EAP Request MUST NOT be carried in the PANA-Start-Request > > message in order for the PAA to be stateless. > > > > When a Cookie-AVP is not carried in a PANA-Start-Request message, the > > PAA does not need to be stateless. In this case, the initial EAP > > Request message MAY be carried in the PANA-Start-Request message. > > The real "cause" to not use this optimization is the "stateless PAA discovery". > Cookie usage is just another "result". So, I'd say: > > "Initial EAP Request MAY be optionally carried by the PANA-Start-Request (as > opposed to by a later PANA-Auth-Request) message in order to reduce > the number of round-trips. This optimization SHOULD not be used if the > PAA discovery is desired to be stateless." OK. > > > Rewrite Section 4.3 as follows: > > > > 4.3 Authentication Phase > > > > The main task in authentication phase is to carry EAP messages > > between PaC and PAA. EAP Request messages are carried in PANA- > > Auth-Request messages and optionally carried in PANA-Start-Request > > messages. EAP Response messages are carried in PANA-Auth-Answer > > messages and optionally carried in PANA-Start-Answer messages. > > When an EAP Success/Failure message is sent from a PAA, the message > > is carried in a PANA-Bind-Request (PBR) or > > PANA-FirstAuth-End-Request (PFER) message. The > > PANA-FirstAuth-End-Reques message MUST be used at the end of the > > first EAP when the PaC and PAA have negotiated during the discovery > > and initial handshake phase to perform separate NAP and ISP > > authentications in a single PANA authentication phase. Otherwise, > > the PANA-Bind-Request message MUST be used. The PANA-Bind-Request > > and PANA-FirstAuth-End-Request messages MUST be acknowledged with a > > PANA-Bind-Answer (PBA) and a PANA-FirstAuth-End-Answer (PFEA) > > messages, respectively. > > > > When the PaC and PAA have negotiated during the discovery and > > initial handshake phase to perform separate NAP and ISP > > authentications, the S-flag of PANA-Auth-Request and > > PANA-Auth-Answer messages MUST be set. Otherwise, the S-flag MUST > > NOT be set. > > > > When separate NAP and ISP authentications are performed, the PAA > > determines the execution order of NAP authentication and ISP > > authentication. In this case, the PAA can indicate which EAP > > authentication is currently occurring by including a > > NAP-Information or an ISP-Information AVP of the corresponding EAP > > authentication in the first PANA-Auth-Request message sent to the > > PaC. > > I guess we could also use a single (or two) bit to indicate this is a NAP auth. > round vs. ISP auth. round. Yes. I think that is a good idea. I will try to introduce a flag when I send updated text on issue 52. > > > In the case where the PaC agreed to perform separate > > authentications but did not specify its ISP choice in > > PANA-Start-Answer message, the PAA MUST include its NAP-Information > > AVP in PANA-Auth-Request message when it performs NAP > > authentication and MUST NOT include any service provider > > information AVP when it performs ISP authentication so that the PaC > > can always distinguish ISP authentication from NAP authentication. > > "In the case where the PaC agreed to perform separate > authentications, presence or absence of NAP-information > AVP in PANA-Auth-Request message indicates the > authentication type. The PAA MUST include its NAP-Information > AVP when it performs NAP authentication, and it MUST NOT include > it for the ISP authentication. PAA MUST include the ISP-information > AVP for ISP authentication when the PaC has indicated its choice > of ISP." > > > The PAA SHOULD stop including a NAP-Information or an > > ISP-Information AVP once it receives the first PANA-Auth-Answer > > message of the current EAP authentication. > > ... > > > policy issue. PANA signals only the result of the immediately > > preceding EAP authentication method in PANA-Bind-Request messages. > > We don't need this statement anymore, because PANA-Bind is only used at the > end (after both rounds of auth.) OK. > > > Add the following example in section 4.6: > ... > > PaC PAA Message(tseq,rseq)[AVPs] > > ----------------------------------------------------- > > // Discovery and initial handshake phase > > -----> PANA-PAA-Discover (0,0) > > <----- PANA-Start-Request (x,0) // S-flag set > > [Cookie, ISP-Information("ISP1"), > > ISP-Information("ISP2"), > > NAP-Information("MyNAP")] > > -----> PANA-Start-Request-Answer (y,x) // S-flag set > > [Cookie, ISP-Information("ISP1")] // PaC chooses > > "ISP1" > > > > // Authentication phase > > <----- PANA-Auth-Request(x+1,y) // NAP > > authentication > > [EAP, NAP-Information("MyNAP")] // S-flag set > > -----> PANA-Auth-Answer(y+1,x+1)[EAP] // S-flag set > > <----- PANA-Auth-Request(x+2,y+1)[EAP] // S-flag set > > -----> PANA-Auth-Answer(y+2,x+2)[EAP] // S-flag set > > <----- PANA-FirstAuth-End-Request(x+3,y+2) // S-flag set > > [EAP{Success}, Key-Id, MAC] > > -----> PANA-FirstAuth-End-Answer(y+3,x+3)[Key-Id, MAC] > > // S-flag set > > > > <----- PANA-Auth-Request(x+3,y+4) // ISP > > authentication > > [EAP, ISP-Information("ISP1")] // S-flag set > > -----> PANA-Auth-Answer(y+4,x+4)[EAP] // S-flag set > > <----- PANA-Auth-Request(x+4,y+5)[EAP] // S-flag set > > -----> PANA-Auth-Answer(y+5,x+5)[EAP] // S-flag set > > <----- PANA-Bind-Request(x+5,y+6) // S-flag set > > [EAP{Success}, Device-Id, Key-Id, > > Lifetime, Protection-Cap., MAC] > > -----> PANA-Bind-Answer(y+6,x+5) // S-flag set > > [Device-Id, Key-Id, Protection-Cap., MAC] > > I think the MAC AVPs are missing in all messages of the second auth. round. OK. Yoshihiro Ohba > > Alper > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 22 11:38:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05162 for ; Mon, 22 Mar 2004 11:38:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5SRW-0008AA-Tk for pana-archive@odin.ietf.org; Mon, 22 Mar 2004 11:38:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MGcQVQ031346 for pana-archive@odin.ietf.org; Mon, 22 Mar 2004 11:38:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5SRU-00088e-PE for pana-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 11:38:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04969 for ; Mon, 22 Mar 2004 11:38:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5SRQ-0001ux-00 for pana-web-archive@ietf.org; Mon, 22 Mar 2004 11:38:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5SPC-0001Pe-00 for pana-web-archive@ietf.org; Mon, 22 Mar 2004 11:36:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5SN8-0000tM-00 for pana-web-archive@ietf.org; Mon, 22 Mar 2004 11:33:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5SH4-0002gX-89 for pana-web-archive@ietf.org; Mon, 22 Mar 2004 11:27:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5SGr-00073h-Ci; Mon, 22 Mar 2004 11:27:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5SGC-00070s-EU for pana@optimus.ietf.org; Mon, 22 Mar 2004 11:26:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04010 for ; Mon, 22 Mar 2004 11:26:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5SG7-0007hW-00 for pana@ietf.org; Mon, 22 Mar 2004 11:26:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5SEn-0007S9-00 for pana@ietf.org; Mon, 22 Mar 2004 11:25:18 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B5SDv-0007G8-00 for pana@ietf.org; Mon, 22 Mar 2004 11:24:23 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2MGOHKL002657; Tue, 23 Mar 2004 01:24:17 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2MGOHik009589; Tue, 23 Mar 2004 01:24:17 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA09588 ; Tue, 23 Mar 2004 01:24:17 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA19781; Tue, 23 Mar 2004 01:24:16 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA07290; Tue, 23 Mar 2004 01:24:16 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2MGOF8j023540; Tue, 23 Mar 2004 01:24:15 +0900 (JST) Received: from steelhead (JT01-058.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HUZ00MM9K8CM0@tsbpo1.po.toshiba.co.jp>; Tue, 23 Mar 2004 01:24:14 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B3fu4-0005pF-00; Wed, 17 Mar 2004 10:36:32 -0800 Date: Wed, 17 Mar 2004 10:36:31 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] issue 52: proposed text In-reply-to: <6427097.1079670447126.JavaMail.weblogic@ep_app07> To: Alper Yegin Cc: "yohba@tari.toshiba.com " , "pana@ietf.org " Message-id: <20040317183631.GN21811@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , "yohba@tari.toshiba.com " , "pana@ietf.org " User-Agent: Mutt/1.5.5.1+cvs20040105i References: <6427097.1079670447126.JavaMail.weblogic@ep_app07> Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Fri, Mar 19, 2004 at 04:27:56AM +0000, Alper Yegin wrote: > Hi Yoshi, > > Thanks for taking care of this issue. > Please see below for my comments. > > > to: > > > > "A PANA SA is created as an attribute of a PANA session when EAP > > authentication succeeds with a creation of a AAA-Key. A PANA SA is > > not created when the PANA authentication fails or no AAA-Key is > > produced by any EAP authentication method. In the case where two > > EAP authentications are performed in sequence in a single PANA > > authentication phase, it is possible that two AAA-Keys are > > derived. If this happens, the PANA SA MUST be bound to both > > Somehow "bound to" sounds like PANA SA has two keys. Eventually it has > one PANA_MAC_KEY, that is generated from one or two AAA-keys. Maybe we s > hould say "PANA SA is generated from both AAA-Keys". > > Actually, it is even "PANA SA is generated from the AAA-keys available at > the time." After the first auth (NAP, for example), it is generated from the AAA-key > if the auth was a success. After the second auth (ISP), again all the keys > from the successful auth rounds are used with the resultant PANA SA. OK. > > > to: > > > > " > > When a Cookie-AVP is carried in a PANA-Start-Request message, the > > initial EAP Request MUST NOT be carried in the PANA-Start-Request > > message in order for the PAA to be stateless. > > > > When a Cookie-AVP is not carried in a PANA-Start-Request message, the > > PAA does not need to be stateless. In this case, the initial EAP > > Request message MAY be carried in the PANA-Start-Request message. > > The real "cause" to not use this optimization is the "stateless PAA discovery". > Cookie usage is just another "result". So, I'd say: > > "Initial EAP Request MAY be optionally carried by the PANA-Start-Request (as > opposed to by a later PANA-Auth-Request) message in order to reduce > the number of round-trips. This optimization SHOULD not be used if the > PAA discovery is desired to be stateless." OK. > > > Rewrite Section 4.3 as follows: > > > > 4.3 Authentication Phase > > > > The main task in authentication phase is to carry EAP messages > > between PaC and PAA. EAP Request messages are carried in PANA- > > Auth-Request messages and optionally carried in PANA-Start-Request > > messages. EAP Response messages are carried in PANA-Auth-Answer > > messages and optionally carried in PANA-Start-Answer messages. > > When an EAP Success/Failure message is sent from a PAA, the message > > is carried in a PANA-Bind-Request (PBR) or > > PANA-FirstAuth-End-Request (PFER) message. The > > PANA-FirstAuth-End-Reques message MUST be used at the end of the > > first EAP when the PaC and PAA have negotiated during the discovery > > and initial handshake phase to perform separate NAP and ISP > > authentications in a single PANA authentication phase. Otherwise, > > the PANA-Bind-Request message MUST be used. The PANA-Bind-Request > > and PANA-FirstAuth-End-Request messages MUST be acknowledged with a > > PANA-Bind-Answer (PBA) and a PANA-FirstAuth-End-Answer (PFEA) > > messages, respectively. > > > > When the PaC and PAA have negotiated during the discovery and > > initial handshake phase to perform separate NAP and ISP > > authentications, the S-flag of PANA-Auth-Request and > > PANA-Auth-Answer messages MUST be set. Otherwise, the S-flag MUST > > NOT be set. > > > > When separate NAP and ISP authentications are performed, the PAA > > determines the execution order of NAP authentication and ISP > > authentication. In this case, the PAA can indicate which EAP > > authentication is currently occurring by including a > > NAP-Information or an ISP-Information AVP of the corresponding EAP > > authentication in the first PANA-Auth-Request message sent to the > > PaC. > > I guess we could also use a single (or two) bit to indicate this is a NAP auth. > round vs. ISP auth. round. Yes. I think that is a good idea. I will try to introduce a flag when I send updated text on issue 52. > > > In the case where the PaC agreed to perform separate > > authentications but did not specify its ISP choice in > > PANA-Start-Answer message, the PAA MUST include its NAP-Information > > AVP in PANA-Auth-Request message when it performs NAP > > authentication and MUST NOT include any service provider > > information AVP when it performs ISP authentication so that the PaC > > can always distinguish ISP authentication from NAP authentication. > > "In the case where the PaC agreed to perform separate > authentications, presence or absence of NAP-information > AVP in PANA-Auth-Request message indicates the > authentication type. The PAA MUST include its NAP-Information > AVP when it performs NAP authentication, and it MUST NOT include > it for the ISP authentication. PAA MUST include the ISP-information > AVP for ISP authentication when the PaC has indicated its choice > of ISP." > > > The PAA SHOULD stop including a NAP-Information or an > > ISP-Information AVP once it receives the first PANA-Auth-Answer > > message of the current EAP authentication. > > ... > > > policy issue. PANA signals only the result of the immediately > > preceding EAP authentication method in PANA-Bind-Request messages. > > We don't need this statement anymore, because PANA-Bind is only used at the > end (after both rounds of auth.) OK. > > > Add the following example in section 4.6: > ... > > PaC PAA Message(tseq,rseq)[AVPs] > > ----------------------------------------------------- > > // Discovery and initial handshake phase > > -----> PANA-PAA-Discover (0,0) > > <----- PANA-Start-Request (x,0) // S-flag set > > [Cookie, ISP-Information("ISP1"), > > ISP-Information("ISP2"), > > NAP-Information("MyNAP")] > > -----> PANA-Start-Request-Answer (y,x) // S-flag set > > [Cookie, ISP-Information("ISP1")] // PaC chooses > > "ISP1" > > > > // Authentication phase > > <----- PANA-Auth-Request(x+1,y) // NAP > > authentication > > [EAP, NAP-Information("MyNAP")] // S-flag set > > -----> PANA-Auth-Answer(y+1,x+1)[EAP] // S-flag set > > <----- PANA-Auth-Request(x+2,y+1)[EAP] // S-flag set > > -----> PANA-Auth-Answer(y+2,x+2)[EAP] // S-flag set > > <----- PANA-FirstAuth-End-Request(x+3,y+2) // S-flag set > > [EAP{Success}, Key-Id, MAC] > > -----> PANA-FirstAuth-End-Answer(y+3,x+3)[Key-Id, MAC] > > // S-flag set > > > > <----- PANA-Auth-Request(x+3,y+4) // ISP > > authentication > > [EAP, ISP-Information("ISP1")] // S-flag set > > -----> PANA-Auth-Answer(y+4,x+4)[EAP] // S-flag set > > <----- PANA-Auth-Request(x+4,y+5)[EAP] // S-flag set > > -----> PANA-Auth-Answer(y+5,x+5)[EAP] // S-flag set > > <----- PANA-Bind-Request(x+5,y+6) // S-flag set > > [EAP{Success}, Device-Id, Key-Id, > > Lifetime, Protection-Cap., MAC] > > -----> PANA-Bind-Answer(y+6,x+5) // S-flag set > > [Device-Id, Key-Id, Protection-Cap., MAC] > > I think the MAC AVPs are missing in all messages of the second auth. round. OK. Yoshihiro Ohba > > Alper > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Mar 29 13:49:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17268 for ; Mon, 29 Mar 2004 13:49:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B81oj-0007NL-1h; Mon, 29 Mar 2004 13:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B81oK-0007Mn-Od for pana@optimus.ietf.org; Mon, 29 Mar 2004 13:48:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17248 for ; Mon, 29 Mar 2004 13:48:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B81oI-0001fW-00 for pana@ietf.org; Mon, 29 Mar 2004 13:48:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B81nM-0001Yq-00 for pana@ietf.org; Mon, 29 Mar 2004 13:47:38 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B81mY-0001S7-00 for pana@ietf.org; Mon, 29 Mar 2004 13:46:47 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2TIkii5006560; Tue, 30 Mar 2004 03:46:44 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2TIkivY023512; Tue, 30 Mar 2004 03:46:44 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA23509 ; Tue, 30 Mar 2004 03:46:44 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA09077; Tue, 30 Mar 2004 03:46:43 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA02379; Tue, 30 Mar 2004 03:46:42 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2TIkePD003096; Tue, 30 Mar 2004 03:46:41 +0900 (JST) Received: from steelhead (iVPN01-036.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HVC00CPGPHNRN@tsbpo1.po.toshiba.co.jp>; Tue, 30 Mar 2004 03:46:37 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B80Ab-0000BG-00; Mon, 29 Mar 2004 09:03:29 -0800 Date: Mon, 29 Mar 2004 09:03:29 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040329170329.GH31606@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Pana] issue 52: revised text Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , This is revised text for issue 52, reflecting Alper's comments. Summary on changes ------------------ o When separate NAP and ISP authentications are performed and two AAA-Keys are derived, one from NAP authentication and the other from ISP authentication, the PANA-MAC-Key is computed based on the two AAA-Keys (i.e., compound key) o New PANA messages PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages are introduced. The new messages are used at the end of the first EAP authentication (instead of PANA-Bind-Request/Answer) when the PaC and PAA negotiated to perform separate NAP and ISP authentications. o The PaC and PAA can choose not to perform the second EAP authentication when they negotiated to perform separate NAP and ISP authentications, but the first EAP authentication has failed. S-flag is reused for this purpose. o A new N-flag is introduced to indicate whether NAP or ISP authentication is performed in NAP and ISP separate authentications. Changes ------- - In order to support compound MAC key when separate NAP and ISP authentications are performed, change the first paragraph in section 4.1.5: "A PANA SA is created as an attribute of a PANA session when EAP authentication succeeds with a creation of a AAA-Key. A PANA SA is not created when the PANA authentication fails or no AAA-Key is produced by any EAP authentication method. In the case where two EAP authentications are performed in a sequence in a single PANA authentication, it is possible that two AAA-Keys are derived. If this happens, the PANA SA MUST be bound to the AAA-Key derived from the first EAP authentication. When a new AAA-Key is derived as a result of EAP-based re-authentication, any key derived from the old AAA-Key MUST be updated to a new one that is derived from the new AAA-Key. In order to distinguish the new AAA-Key from old ones, one Key-Id AVP MUST be carried in PANA-Bind-Request and PANA-Bind-Answer message at the end of the authentication phase which resulted in deriving a new AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a value that uniquely identifies the AAA-Key within the PANA session. The PANA-Bind-Answer message sent in response to a PANA-Bind-Request with a Key-Id AVP MUST contain a Key-Id AVP with the same AAA-Key identifier carried in the request. PANA-Bind-Request and PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC AVP whose value is computed by using the new AAA-Key. Although the specification does not mandate a particular method for calculation of Key-Id AVP value, a simple method is to use monotonically increasing numbers." to: "A PANA SA is created as an attribute of a PANA session when EAP authentication succeeds with a creation of a AAA-Key. A PANA SA is not created when the PANA authentication fails or no AAA-Key is produced by any EAP authentication method. In the case where two EAP authentications are performed in sequence in a single PANA authentication phase, it is possible that two AAA-Keys are derived. If this happens, the PANA SA MUST be generated from both AAA-Keys. When a new AAA-Key is derived as a result of EAP-based re-authentication, any key derived from the old AAA-Key MUST be updated to a new one that is derived from the new AAA-Key. In order to distinguish the new AAA-Key from old ones, one Key-Id AVP MUST be carried in PANA-Bind-Request and PANA-Bind-Answer messages or PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages at the end of the EAP authentication which resulted in deriving a new AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a value that uniquely identifies the AAA-Key within the PANA session. The PANA-Bind-Answer message (or the PANA-FirstAuth-End-Answer message) sent in response to a PANA-Bind-Request message (or a PANA-FirstAuth-End-Request message) with a Key-Id AVP MUST contain a Key-Id AVP with the same AAA-Key identifier carried in the request. PANA-Bind-Request, PANA-Bind-Answer, PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages with a Key-Id AVP MUST also carry a MAC AVP whose value is computed by using the new PANA-MAC-Key derived from the new AAA-Key (or the new pair of AAA-Keys when the PANA_MAC_KEY is derived from two AAA-Keys). Although the specification does not mandate a particular method for calculation of Key-Id AVP value, a simple method is to use monotonically increasing numbers." - In order to support compound MAC key when separate NAP and ISP authentications are performed, change the following paragraphs in section 4.1.5. " The PANA_MAC_Key is used to integrity protect PANA messages and derived from the AAA-Key in the following way: PANA_MAC_KEY = The first N bits of HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID) where the value of N depends on the integrity protection algorithm in use, i.e., N=160 for HMAC-SHA1. The length of AAA-Key MUST be N bits or longer. See Section 4.1.6 for the detailed usage of the PANA_MAC_Key. " to: The PANA_MAC_Key is used to integrity protect PANA messages. When the PANA_MAC_Key is derived from a single AAA-Key, it is computed in the following way: PANA_MAC_KEY = The first N bits of HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID) where the value of N depends on the integrity protection algorithm in use, i.e., N=160 for HMAC-SHA1. When the PANA_MAC_Key is derived from two AAA-Keys, it is computed in the following way: PANA_MAC_KEY = The first N bits of HMAC_SHA1(AAA-Key1, AAA-Key2, ISN_pac | ISN_paa | Session-ID) where AAA-Key1 and AAA-Key2 are AAA-Keys for the first and second EAP authentication in a single PANA authentication phase, respectively. The length of AAA-Key, AAA-Key1 and AAA-Key2 MUST be N bits or longer. See Section 4.1.6 and Section 4.3 for the detailed usage of the PANA_MAC_Key. " - In order to clarify that ISP-Information AVP can be included in PSA message even if PAA does not contain any ISP-Information AVP in PSR message, add the following paragraph in section 4.2: "The PaC can still choose an ISP and contain an ISP-Information AVP for the chosen ISP in a PANA-Start-Answer message even when there is no ISP-Information AVP contained in the PANA-Start-Request message." - In order to clarify that PSR message does not contain EAP Request while negotiating on performing separate authentication for NAP and ISP, change the following paragraphs in section 4.2 from: " When a Cookie-AVP is carried in a PANA-Start-Request message, the initial EAP Request MUST NOT be carried in the PANA-Start-Request message in order for the PAA to be stateless. When a Cookie-AVP is not carried in a PANA-Start-Request message, the PAA does not need to be stateless. In this case, the initial EAP Request message MAY be carried in the PANA-Start-Request message. If the initial EAP Request message is carried in the PANA-Start-Request message, an EAP Response message MUST be carried in the PANA-Start-Answer message returned to the PAA. " to: " When a Cookie-AVP is carried in a PANA-Start-Request message, the initial EAP Request MUST NOT be carried in the PANA-Start-Request message in order for the PAA to be stateless. Initial EAP Request MAY be optionally carried by the PANA-Start-Request (as opposed to by a later PANA-Auth-Request) message in order to reduce the number of round-trips. This optimization SHOULD NOT be used if the PAA discovery is desired to be stateless. When the S-flag is set in a PANA-Start-Request message, the initial EAP Request MUST NOT be carried in the PANA-Start-Request message. (If the initial EAP Request were contained in the PANA-Start-Request message during the S-flag negotiation, the PaC cannot tell whether the EAP Request is for NAP authentication or ISP authentication.) If the initial EAP Request message is carried in the PANA-Start-Request message, an EAP Response message MUST be carried in the PANA-Start-Answer message returned to the PAA. " Rewrite Section 4.3 as follows: 4.3 Authentication Phase The main task in authentication phase is to carry EAP messages between PaC and PAA. EAP Request messages are carried in PANA- Auth-Request messages and optionally carried in PANA-Start-Request messages. EAP Response messages are carried in PANA-Auth-Answer messages and optionally carried in PANA-Start-Answer messages. When an EAP Success/Failure message is sent from a PAA, the message is carried in a PANA-Bind-Request (PBR) or PANA-FirstAuth-End-Request (PFER) message. The PANA-FirstAuth-End-Reques message MUST be used at the end of the first EAP when the PaC and PAA have negotiated during the discovery and initial handshake phase to perform separate NAP and ISP authentications in a single PANA authentication phase. Otherwise, the PANA-Bind-Request message MUST be used. The PANA-Bind-Request and PANA-FirstAuth-End-Request messages MUST be acknowledged with a PANA-Bind-Answer (PBA) and a PANA-FirstAuth-End-Answer (PFEA) messages, respectively. When the PaC and PAA have negotiated during the discovery and initial handshake phase to perform separate NAP and ISP authentications, the S-flag of PANA-Auth-Request and PANA-Auth-Answer messages MUST be set. Otherwise, the S-flag MUST NOT be set. When separate NAP and ISP authentications are performed, the PAA determines the execution order of NAP authentication and ISP authentication. In this case, the PAA can indicate which EAP authentication is currently occurring by using N-flag in the PANA message header. When NAP authentication is performed, the N-flag MUST be set. When ISP authentication is performed, the N-flag MUST NOT be set. The N-flag MUST NOT be set when S-flag is not set. When separate NAP and ISP authentications are performed, if the first EAP authentication has failed, the PAA can choose not to perform the second EAP authentication by clearing the S-flag of the PANA-FirstAuth-End-Request message. In this case, the S-flag of the PANA-FirstAuth-End-Answer message sent by the PaC MUST be cleared. If the S-flag of the PANA-FirstAuth-End-Request message is set when the first EAP authentication has failed, the PaC can choose not to perform the second EAP authentication by clearing the S-flag of the PANA-FirstAuth-End-Answer message. If the first EAP authentication failed and the S-flag is not set in the PANA-FirstAuth-End-Answer message as a result of those operations, the PANA session MUST be immediately deleted. Otherwise, the second EAP authentication MUST be performed. Currently, use of multiple EAP methods in PANA is designed only for NAP-ISP authentication separation. It is not for arbitrary EAP method sequencing, or giving the PaC another chance when an authentication method fails. The NAP and ISP authentication are considered completely independent. Presence or success of one should not effect the other. Making an authentication decision based on the success or failure of each authentication is a network policy issue. When an EAP method that is capable of deriving keys is used during the authentication phase and the keys are successfully derived, the PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer and/or PANA-Bind-Request and PANA-Bind-Answer messages, and all subsequent PANA messages MUST contain a MAC AVP. When separate NAP and ISP authentications are performed and the lower-layer is insecure, the two EAP methods MUST be capable of deriving keys. In this case, if the first EAP authentication is successful, the PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages as well as PANA-Auth-Request and PANA-Auth-Answer messages in the second EAP authentication MUST be protected with the key derived from the AAA-Key for the first EAP authentication. The PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent PANA messages MUST be protected either with the AAA-Key for the first EAP authentication if the first EAP authentication succeeds and the second EAP authentication fails, or with the AAA-Key for the second EAP authentication if the first EAP authentication fails and the second EAP authentication succeeds, or with the compound key derived from the two AAA-Keys, one for the first EAP authentication and the other from the second EAP authentication, if both the first and second EAP authentications succeed (see section 4.1.5 how the compound key is derived). The PANA-Bind-Request and the PANA-Bind-Answer message exchange is also used for binding device identifiers of the PaC and the PAA to the PANA SA. To achieve this, the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a device identifier of the PAA and the PaC, respectively, in a Device-Id AVP. The PaC MUST use the same type of device identifier as contained in the PANA-Bind-Request message. The PANA-Bind-Request message MAY also contain a Protection-Capability AVP to indicate if link-layer or network-layer ciphering should be initiated after PANA. No link layer or network layer specific information is included in the Protection-Capability AVP. When the information is preconfigured on the PaC and the PAA this AVP can be omitted. It is assumed that at least PAA is aware of the security capabilities of the access network. The PANA protocol does not specify how the PANA SA and the Protection-Capability AVP will be used to provide per-packet protection for data traffic. PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted based on the retransmission rule described in Appendix A. Add the following example in section 4.6: " Another PANA message sequence is illustrated in Figure X. The example assumes the following scenario: o PaC multicasts PANA-PAA-Discover message o The ISNs used by the PAA and the PaC are x and y, respectively. o PAA offers NAP and ISP separate authentication, as well as a choice of ISP from "ISP1" and "ISP2". o PaC accepts the offer from PAA, with choosing "ISP1" as the ISP. o An EAP sequence for NAP authentication and an EAP sequence for ISP authentication is performed in this order in authentication phase. o An EAP authentication method with a single round trip is used in each of EAP sequence. o The EAP authentication methods derive keys. Once the two EAP authenticatioins are successful, the PANA_MAC_KEY is derived from the two AAA-Keys. o After PANA SA is established, all messages are integrity and replay protected with the MAC AVP. o Re-authentication and termination phase are not shown. PaC PAA Message(tseq,rseq)[AVPs] ----------------------------------------------------- // Discovery and initial handshake phase -----> PANA-PAA-Discover (0,0) <----- PANA-Start-Request (x,0) // S-flag set [Cookie, ISP-Information("ISP1"), ISP-Information("ISP2"), NAP-Information("MyNAP")] -----> PANA-Start-Request-Answer (y,x) // S-flag set [Cookie, ISP-Information("ISP1")] // PaC chooses "ISP1" // Authentication phase <----- PANA-Auth-Request(x+1,y)[EAP] // NAP authentication // S- and N-flags set -----> PANA-Auth-Answer(y+1,x+1)[EAP] // S- and N-flags set <----- PANA-Auth-Request(x+2,y+1)[EAP] // S- and N-flags set -----> PANA-Auth-Answer(y+2,x+2)[EAP] // S- and N-flags set <----- PANA-FirstAuth-End-Request(x+3,y+2) // S- and N-flags set [EAP{Success}, Key-Id, MAC] -----> PANA-FirstAuth-End-Answer(y+3,x+3) // S- and N-flags set [Key-Id, MAC] <----- PANA-Auth-Request(x+3,y+4)[EAP, MAC]// ISP authentication // S-flag set -----> PANA-Auth-Answer(y+4,x+4)[EAP, MAC] // S-flag set <----- PANA-Auth-Request(x+4,y+5)[EAP, MAC]// S-flag set -----> PANA-Auth-Answer(y+5,x+5)[EAP, MAC] // S-flag set <----- PANA-Bind-Request(x+5,y+6) // S-flag set [EAP{Success}, Device-Id, Key-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+6,x+5) // S-flag set [Device-Id, Key-Id, Protection-Cap., MAC] Figure X: A Message Sequence for NAP and ISP Separate Authentication " Add N-flag in the header as follows: " 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R r r r S N r r| +-+-+-+-+-+-+-+-+ " Change the following paragraph in section 9.1: " S(eparate) When the S-flag is set in a PANA-Start-Request message it indicates that PAA is willing to offer separate EAP authentication for NAP and ISP. When the S-flag is set in a PANA-Start-Answer message it indicates that PaC accepts on performing separate EAP authentication for NAP and ISP. " to: " S(eparate) When the S-flag is set in a PANA-Start-Request message it indicates that PAA is willing to offer separate EAP authentications for NAP and ISP. When the S-flag is set in a PANA-Start-Answer message it indicates that PaC accepts on performing separate EAP authentications for NAP and ISP. When the S-flag is set in a PANA-Auth-Request/Answer, PANA-FirstAuth-End-Request/Answer and PANA-Bind-Request/Answer messages it indicates that separate authentications are being performed in the authentication phase. N(AP authentication) When the N-flag is set in a PANA-Auth-Request message, it indicates that PAA is performing NAP authentication. When the N-flag is unset in a PANA-Auth-Request message, it indicates that PAA is performing ISP authentication. The N-flag MUST NOT be set when S-flag is not set. " - Change Figure 9 as follows: " Message Direction: PaC---PAA ------------------------------------- PANA-PAA-Discover --------> PANA-Start-Request <-------- PANA-Start-Answer --------> PANA-Auth-Request <-------- PANA-Auth-Answer --------> PANA-FirstAuth-End-Request <-------- PANA-FirstAuth-End-Answer --------> PANA-Bind-Request <-------- PANA-Bind-Answer --------> PANA-Reauth-Request <-------> PANA-Reauth-Answer <-------> PANA-Termination-Request <-------> PANA-Termination-Answer <-------> PANA-Error <-------> " Remove NAP-Information and ISP-Information AVPs from the ABNF for PAR message as follows: " PANA-Auth-Request ::= < PANA-Header: 3, REQ > < Session-Id > < EAP-Payload > * [ AVP ] 0*1 < MAC > " Add the following two sections: "9.3.X PANA-FirstAuth-End-Request (PFER) PANA-FirstAuth-End-Request (PFER) is sent by the PAA to the PaC. PANA-FirstAuth-End-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } [ Key-Id ] * [ AVP ] 0*1 < MAC > 9.3.Y PANA-FirstAuth-End-Answer (PFEA) PANA-FirstAuth-End-Answer (PFEA) is sent by the PaC to the PAA in response to a PANA-FirstAuth-End-Request message. PANA-FirstAuth-End--Answer ::= < PANA-Header: 4 > < Session-Id > < Device-Id > [ Key-Id ] * [ AVP ] 0*1 < MAC > " - Change the AVP occurrence table as follows: " +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0-1 | Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 | Protection-Cap. | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | Session-Lifetime | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ISP-Information | 0+ | 0-1 | 0 | 0 | 0 | 0 | 0 | NAP-Information | 0-1 | 0 | 0 | 0 | 0 | 0 | 0 | EP-Device-Id | 0 | 0 | 0 | 0 | 0+ | 0 | 0 | Key-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 | --------------------+-----+-----+-----+-----+-----+-----+-----+ +---------------------------------------------+ | Message | | Type | +------+------+-----+-----+-----+------+------+ Attribute Name | PRAR | PRAA | PTR | PTA | PER | PFER | PFEA | --------------------+------+------+-----+-----+-----+------+------+ Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 | Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1 | Termination-Cause | 0 | 0 | 1 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 0 | 0 | 0 | 1 | 0 | MAC | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | Device-Id | 1+ | 1+ | 0 | 0 | 0 | 0 | 0 | Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 1 | 0 | 0 | ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EP-Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Key-Id | 0 | 0 | 0 | 0 | 0 | 0-1 | 0-1 | --------------------+------+------+-----+-----+-----+------+------+ " Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Mar 29 13:51:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17333 for ; Mon, 29 Mar 2004 13:51:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B81qE-0007Vw-4u for pana-archive@odin.ietf.org; Mon, 29 Mar 2004 13:50:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TIoYtv028878 for pana-archive@odin.ietf.org; Mon, 29 Mar 2004 13:50:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B81qD-0007Vh-Ul for pana-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 13:50:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17310 for ; Mon, 29 Mar 2004 13:50:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B81qB-0001tM-00 for pana-web-archive@ietf.org; Mon, 29 Mar 2004 13:50:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B81pH-0001n8-00 for pana-web-archive@ietf.org; Mon, 29 Mar 2004 13:49:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B81ok-0001gx-00 for pana-web-archive@ietf.org; Mon, 29 Mar 2004 13:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B81oj-0007NL-1h; Mon, 29 Mar 2004 13:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B81oK-0007Mn-Od for pana@optimus.ietf.org; Mon, 29 Mar 2004 13:48:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17248 for ; Mon, 29 Mar 2004 13:48:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B81oI-0001fW-00 for pana@ietf.org; Mon, 29 Mar 2004 13:48:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B81nM-0001Yq-00 for pana@ietf.org; Mon, 29 Mar 2004 13:47:38 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1B81mY-0001S7-00 for pana@ietf.org; Mon, 29 Mar 2004 13:46:47 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i2TIkii5006560; Tue, 30 Mar 2004 03:46:44 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i2TIkivY023512; Tue, 30 Mar 2004 03:46:44 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA23509 ; Tue, 30 Mar 2004 03:46:44 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA09077; Tue, 30 Mar 2004 03:46:43 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA02379; Tue, 30 Mar 2004 03:46:42 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i2TIkePD003096; Tue, 30 Mar 2004 03:46:41 +0900 (JST) Received: from steelhead (iVPN01-036.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HVC00CPGPHNRN@tsbpo1.po.toshiba.co.jp>; Tue, 30 Mar 2004 03:46:37 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1B80Ab-0000BG-00; Mon, 29 Mar 2004 09:03:29 -0800 Date: Mon, 29 Mar 2004 09:03:29 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040329170329.GH31606@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i Subject: [Pana] issue 52: revised text Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 This is revised text for issue 52, reflecting Alper's comments. Summary on changes ------------------ o When separate NAP and ISP authentications are performed and two AAA-Keys are derived, one from NAP authentication and the other from ISP authentication, the PANA-MAC-Key is computed based on the two AAA-Keys (i.e., compound key) o New PANA messages PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages are introduced. The new messages are used at the end of the first EAP authentication (instead of PANA-Bind-Request/Answer) when the PaC and PAA negotiated to perform separate NAP and ISP authentications. o The PaC and PAA can choose not to perform the second EAP authentication when they negotiated to perform separate NAP and ISP authentications, but the first EAP authentication has failed. S-flag is reused for this purpose. o A new N-flag is introduced to indicate whether NAP or ISP authentication is performed in NAP and ISP separate authentications. Changes ------- - In order to support compound MAC key when separate NAP and ISP authentications are performed, change the first paragraph in section 4.1.5: "A PANA SA is created as an attribute of a PANA session when EAP authentication succeeds with a creation of a AAA-Key. A PANA SA is not created when the PANA authentication fails or no AAA-Key is produced by any EAP authentication method. In the case where two EAP authentications are performed in a sequence in a single PANA authentication, it is possible that two AAA-Keys are derived. If this happens, the PANA SA MUST be bound to the AAA-Key derived from the first EAP authentication. When a new AAA-Key is derived as a result of EAP-based re-authentication, any key derived from the old AAA-Key MUST be updated to a new one that is derived from the new AAA-Key. In order to distinguish the new AAA-Key from old ones, one Key-Id AVP MUST be carried in PANA-Bind-Request and PANA-Bind-Answer message at the end of the authentication phase which resulted in deriving a new AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a value that uniquely identifies the AAA-Key within the PANA session. The PANA-Bind-Answer message sent in response to a PANA-Bind-Request with a Key-Id AVP MUST contain a Key-Id AVP with the same AAA-Key identifier carried in the request. PANA-Bind-Request and PANA-Bind-Answer messages with a Key-Id AVP MUST also carry a MAC AVP whose value is computed by using the new AAA-Key. Although the specification does not mandate a particular method for calculation of Key-Id AVP value, a simple method is to use monotonically increasing numbers." to: "A PANA SA is created as an attribute of a PANA session when EAP authentication succeeds with a creation of a AAA-Key. A PANA SA is not created when the PANA authentication fails or no AAA-Key is produced by any EAP authentication method. In the case where two EAP authentications are performed in sequence in a single PANA authentication phase, it is possible that two AAA-Keys are derived. If this happens, the PANA SA MUST be generated from both AAA-Keys. When a new AAA-Key is derived as a result of EAP-based re-authentication, any key derived from the old AAA-Key MUST be updated to a new one that is derived from the new AAA-Key. In order to distinguish the new AAA-Key from old ones, one Key-Id AVP MUST be carried in PANA-Bind-Request and PANA-Bind-Answer messages or PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages at the end of the EAP authentication which resulted in deriving a new AAA-Key. The Key-Id AVP is of type Unsigned32 and MUST contain a value that uniquely identifies the AAA-Key within the PANA session. The PANA-Bind-Answer message (or the PANA-FirstAuth-End-Answer message) sent in response to a PANA-Bind-Request message (or a PANA-FirstAuth-End-Request message) with a Key-Id AVP MUST contain a Key-Id AVP with the same AAA-Key identifier carried in the request. PANA-Bind-Request, PANA-Bind-Answer, PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages with a Key-Id AVP MUST also carry a MAC AVP whose value is computed by using the new PANA-MAC-Key derived from the new AAA-Key (or the new pair of AAA-Keys when the PANA_MAC_KEY is derived from two AAA-Keys). Although the specification does not mandate a particular method for calculation of Key-Id AVP value, a simple method is to use monotonically increasing numbers." - In order to support compound MAC key when separate NAP and ISP authentications are performed, change the following paragraphs in section 4.1.5. " The PANA_MAC_Key is used to integrity protect PANA messages and derived from the AAA-Key in the following way: PANA_MAC_KEY = The first N bits of HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID) where the value of N depends on the integrity protection algorithm in use, i.e., N=160 for HMAC-SHA1. The length of AAA-Key MUST be N bits or longer. See Section 4.1.6 for the detailed usage of the PANA_MAC_Key. " to: The PANA_MAC_Key is used to integrity protect PANA messages. When the PANA_MAC_Key is derived from a single AAA-Key, it is computed in the following way: PANA_MAC_KEY = The first N bits of HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID) where the value of N depends on the integrity protection algorithm in use, i.e., N=160 for HMAC-SHA1. When the PANA_MAC_Key is derived from two AAA-Keys, it is computed in the following way: PANA_MAC_KEY = The first N bits of HMAC_SHA1(AAA-Key1, AAA-Key2, ISN_pac | ISN_paa | Session-ID) where AAA-Key1 and AAA-Key2 are AAA-Keys for the first and second EAP authentication in a single PANA authentication phase, respectively. The length of AAA-Key, AAA-Key1 and AAA-Key2 MUST be N bits or longer. See Section 4.1.6 and Section 4.3 for the detailed usage of the PANA_MAC_Key. " - In order to clarify that ISP-Information AVP can be included in PSA message even if PAA does not contain any ISP-Information AVP in PSR message, add the following paragraph in section 4.2: "The PaC can still choose an ISP and contain an ISP-Information AVP for the chosen ISP in a PANA-Start-Answer message even when there is no ISP-Information AVP contained in the PANA-Start-Request message." - In order to clarify that PSR message does not contain EAP Request while negotiating on performing separate authentication for NAP and ISP, change the following paragraphs in section 4.2 from: " When a Cookie-AVP is carried in a PANA-Start-Request message, the initial EAP Request MUST NOT be carried in the PANA-Start-Request message in order for the PAA to be stateless. When a Cookie-AVP is not carried in a PANA-Start-Request message, the PAA does not need to be stateless. In this case, the initial EAP Request message MAY be carried in the PANA-Start-Request message. If the initial EAP Request message is carried in the PANA-Start-Request message, an EAP Response message MUST be carried in the PANA-Start-Answer message returned to the PAA. " to: " When a Cookie-AVP is carried in a PANA-Start-Request message, the initial EAP Request MUST NOT be carried in the PANA-Start-Request message in order for the PAA to be stateless. Initial EAP Request MAY be optionally carried by the PANA-Start-Request (as opposed to by a later PANA-Auth-Request) message in order to reduce the number of round-trips. This optimization SHOULD NOT be used if the PAA discovery is desired to be stateless. When the S-flag is set in a PANA-Start-Request message, the initial EAP Request MUST NOT be carried in the PANA-Start-Request message. (If the initial EAP Request were contained in the PANA-Start-Request message during the S-flag negotiation, the PaC cannot tell whether the EAP Request is for NAP authentication or ISP authentication.) If the initial EAP Request message is carried in the PANA-Start-Request message, an EAP Response message MUST be carried in the PANA-Start-Answer message returned to the PAA. " Rewrite Section 4.3 as follows: 4.3 Authentication Phase The main task in authentication phase is to carry EAP messages between PaC and PAA. EAP Request messages are carried in PANA- Auth-Request messages and optionally carried in PANA-Start-Request messages. EAP Response messages are carried in PANA-Auth-Answer messages and optionally carried in PANA-Start-Answer messages. When an EAP Success/Failure message is sent from a PAA, the message is carried in a PANA-Bind-Request (PBR) or PANA-FirstAuth-End-Request (PFER) message. The PANA-FirstAuth-End-Reques message MUST be used at the end of the first EAP when the PaC and PAA have negotiated during the discovery and initial handshake phase to perform separate NAP and ISP authentications in a single PANA authentication phase. Otherwise, the PANA-Bind-Request message MUST be used. The PANA-Bind-Request and PANA-FirstAuth-End-Request messages MUST be acknowledged with a PANA-Bind-Answer (PBA) and a PANA-FirstAuth-End-Answer (PFEA) messages, respectively. When the PaC and PAA have negotiated during the discovery and initial handshake phase to perform separate NAP and ISP authentications, the S-flag of PANA-Auth-Request and PANA-Auth-Answer messages MUST be set. Otherwise, the S-flag MUST NOT be set. When separate NAP and ISP authentications are performed, the PAA determines the execution order of NAP authentication and ISP authentication. In this case, the PAA can indicate which EAP authentication is currently occurring by using N-flag in the PANA message header. When NAP authentication is performed, the N-flag MUST be set. When ISP authentication is performed, the N-flag MUST NOT be set. The N-flag MUST NOT be set when S-flag is not set. When separate NAP and ISP authentications are performed, if the first EAP authentication has failed, the PAA can choose not to perform the second EAP authentication by clearing the S-flag of the PANA-FirstAuth-End-Request message. In this case, the S-flag of the PANA-FirstAuth-End-Answer message sent by the PaC MUST be cleared. If the S-flag of the PANA-FirstAuth-End-Request message is set when the first EAP authentication has failed, the PaC can choose not to perform the second EAP authentication by clearing the S-flag of the PANA-FirstAuth-End-Answer message. If the first EAP authentication failed and the S-flag is not set in the PANA-FirstAuth-End-Answer message as a result of those operations, the PANA session MUST be immediately deleted. Otherwise, the second EAP authentication MUST be performed. Currently, use of multiple EAP methods in PANA is designed only for NAP-ISP authentication separation. It is not for arbitrary EAP method sequencing, or giving the PaC another chance when an authentication method fails. The NAP and ISP authentication are considered completely independent. Presence or success of one should not effect the other. Making an authentication decision based on the success or failure of each authentication is a network policy issue. When an EAP method that is capable of deriving keys is used during the authentication phase and the keys are successfully derived, the PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer and/or PANA-Bind-Request and PANA-Bind-Answer messages, and all subsequent PANA messages MUST contain a MAC AVP. When separate NAP and ISP authentications are performed and the lower-layer is insecure, the two EAP methods MUST be capable of deriving keys. In this case, if the first EAP authentication is successful, the PANA-FirstAuth-End-Request and PANA-FirstAuth-End-Answer messages as well as PANA-Auth-Request and PANA-Auth-Answer messages in the second EAP authentication MUST be protected with the key derived from the AAA-Key for the first EAP authentication. The PANA-Bind-Request and PANA-Bind-Answer messages and all subsequent PANA messages MUST be protected either with the AAA-Key for the first EAP authentication if the first EAP authentication succeeds and the second EAP authentication fails, or with the AAA-Key for the second EAP authentication if the first EAP authentication fails and the second EAP authentication succeeds, or with the compound key derived from the two AAA-Keys, one for the first EAP authentication and the other from the second EAP authentication, if both the first and second EAP authentications succeed (see section 4.1.5 how the compound key is derived). The PANA-Bind-Request and the PANA-Bind-Answer message exchange is also used for binding device identifiers of the PaC and the PAA to the PANA SA. To achieve this, the PANA-Bind-Request and the PANA-Bind-Answer SHOULD contain a device identifier of the PAA and the PaC, respectively, in a Device-Id AVP. The PaC MUST use the same type of device identifier as contained in the PANA-Bind-Request message. The PANA-Bind-Request message MAY also contain a Protection-Capability AVP to indicate if link-layer or network-layer ciphering should be initiated after PANA. No link layer or network layer specific information is included in the Protection-Capability AVP. When the information is preconfigured on the PaC and the PAA this AVP can be omitted. It is assumed that at least PAA is aware of the security capabilities of the access network. The PANA protocol does not specify how the PANA SA and the Protection-Capability AVP will be used to provide per-packet protection for data traffic. PANA-Bind-Request and PANA-Bind-Answer messages MUST be retransmitted based on the retransmission rule described in Appendix A. Add the following example in section 4.6: " Another PANA message sequence is illustrated in Figure X. The example assumes the following scenario: o PaC multicasts PANA-PAA-Discover message o The ISNs used by the PAA and the PaC are x and y, respectively. o PAA offers NAP and ISP separate authentication, as well as a choice of ISP from "ISP1" and "ISP2". o PaC accepts the offer from PAA, with choosing "ISP1" as the ISP. o An EAP sequence for NAP authentication and an EAP sequence for ISP authentication is performed in this order in authentication phase. o An EAP authentication method with a single round trip is used in each of EAP sequence. o The EAP authentication methods derive keys. Once the two EAP authenticatioins are successful, the PANA_MAC_KEY is derived from the two AAA-Keys. o After PANA SA is established, all messages are integrity and replay protected with the MAC AVP. o Re-authentication and termination phase are not shown. PaC PAA Message(tseq,rseq)[AVPs] ----------------------------------------------------- // Discovery and initial handshake phase -----> PANA-PAA-Discover (0,0) <----- PANA-Start-Request (x,0) // S-flag set [Cookie, ISP-Information("ISP1"), ISP-Information("ISP2"), NAP-Information("MyNAP")] -----> PANA-Start-Request-Answer (y,x) // S-flag set [Cookie, ISP-Information("ISP1")] // PaC chooses "ISP1" // Authentication phase <----- PANA-Auth-Request(x+1,y)[EAP] // NAP authentication // S- and N-flags set -----> PANA-Auth-Answer(y+1,x+1)[EAP] // S- and N-flags set <----- PANA-Auth-Request(x+2,y+1)[EAP] // S- and N-flags set -----> PANA-Auth-Answer(y+2,x+2)[EAP] // S- and N-flags set <----- PANA-FirstAuth-End-Request(x+3,y+2) // S- and N-flags set [EAP{Success}, Key-Id, MAC] -----> PANA-FirstAuth-End-Answer(y+3,x+3) // S- and N-flags set [Key-Id, MAC] <----- PANA-Auth-Request(x+3,y+4)[EAP, MAC]// ISP authentication // S-flag set -----> PANA-Auth-Answer(y+4,x+4)[EAP, MAC] // S-flag set <----- PANA-Auth-Request(x+4,y+5)[EAP, MAC]// S-flag set -----> PANA-Auth-Answer(y+5,x+5)[EAP, MAC] // S-flag set <----- PANA-Bind-Request(x+5,y+6) // S-flag set [EAP{Success}, Device-Id, Key-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+6,x+5) // S-flag set [Device-Id, Key-Id, Protection-Cap., MAC] Figure X: A Message Sequence for NAP and ISP Separate Authentication " Add N-flag in the header as follows: " 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |R r r r S N r r| +-+-+-+-+-+-+-+-+ " Change the following paragraph in section 9.1: " S(eparate) When the S-flag is set in a PANA-Start-Request message it indicates that PAA is willing to offer separate EAP authentication for NAP and ISP. When the S-flag is set in a PANA-Start-Answer message it indicates that PaC accepts on performing separate EAP authentication for NAP and ISP. " to: " S(eparate) When the S-flag is set in a PANA-Start-Request message it indicates that PAA is willing to offer separate EAP authentications for NAP and ISP. When the S-flag is set in a PANA-Start-Answer message it indicates that PaC accepts on performing separate EAP authentications for NAP and ISP. When the S-flag is set in a PANA-Auth-Request/Answer, PANA-FirstAuth-End-Request/Answer and PANA-Bind-Request/Answer messages it indicates that separate authentications are being performed in the authentication phase. N(AP authentication) When the N-flag is set in a PANA-Auth-Request message, it indicates that PAA is performing NAP authentication. When the N-flag is unset in a PANA-Auth-Request message, it indicates that PAA is performing ISP authentication. The N-flag MUST NOT be set when S-flag is not set. " - Change Figure 9 as follows: " Message Direction: PaC---PAA ------------------------------------- PANA-PAA-Discover --------> PANA-Start-Request <-------- PANA-Start-Answer --------> PANA-Auth-Request <-------- PANA-Auth-Answer --------> PANA-FirstAuth-End-Request <-------- PANA-FirstAuth-End-Answer --------> PANA-Bind-Request <-------- PANA-Bind-Answer --------> PANA-Reauth-Request <-------> PANA-Reauth-Answer <-------> PANA-Termination-Request <-------> PANA-Termination-Answer <-------> PANA-Error <-------> " Remove NAP-Information and ISP-Information AVPs from the ABNF for PAR message as follows: " PANA-Auth-Request ::= < PANA-Header: 3, REQ > < Session-Id > < EAP-Payload > * [ AVP ] 0*1 < MAC > " Add the following two sections: "9.3.X PANA-FirstAuth-End-Request (PFER) PANA-FirstAuth-End-Request (PFER) is sent by the PAA to the PaC. PANA-FirstAuth-End-Request ::= < PANA-Header: 4, REQ > < Session-Id > < Device-Id > { EAP-Payload } { Result-Code } [ Key-Id ] * [ AVP ] 0*1 < MAC > 9.3.Y PANA-FirstAuth-End-Answer (PFEA) PANA-FirstAuth-End-Answer (PFEA) is sent by the PaC to the PAA in response to a PANA-FirstAuth-End-Request message. PANA-FirstAuth-End--Answer ::= < PANA-Header: 4 > < Session-Id > < Device-Id > [ Key-Id ] * [ AVP ] 0*1 < MAC > " - Change the AVP occurrence table as follows: " +-----------------------------------------+ | Message | | Type | +-----+-----+-----+-----+-----+-----+-----+ Attribute Name | PSR | PSA | PAR | PAN | PBR | PBA | PDI | --------------------+-----+-----+-----+-----+-----+-----+-----+ Result-Code | 0 | 0 | 0 | 0 | 1 | 0 | 0 | Session-Id | 0 | 0 | 1 | 1 | 1 | 1 | 0-1 | Termination-Cause | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 1 | 1 | 1 | 0 | 0 | MAC | 0 | 0 | 0-1 | 0-1 | 0-1 | 0-1 | 0 | Device-Id | 0 | 0 | 0 | 0 | 1+ | 1+ | 0-1 | Cookie | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 0 | Protection-Cap. | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | Session-Lifetime | 0 | 0 | 0 | 0 | 0-1 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ISP-Information | 0+ | 0-1 | 0 | 0 | 0 | 0 | 0 | NAP-Information | 0-1 | 0 | 0 | 0 | 0 | 0 | 0 | EP-Device-Id | 0 | 0 | 0 | 0 | 0+ | 0 | 0 | Key-Id | 0 | 0 | 0 | 0 | 0-1 | 0-1 | 0 | --------------------+-----+-----+-----+-----+-----+-----+-----+ +---------------------------------------------+ | Message | | Type | +------+------+-----+-----+-----+------+------+ Attribute Name | PRAR | PRAA | PTR | PTA | PER | PFER | PFEA | --------------------+------+------+-----+-----+-----+------+------+ Result-Code | 0 | 0 | 0 | 0 | 1 | 1 | 0 | Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 1 | Termination-Cause | 0 | 0 | 1 | 0 | 0 | 0 | 0 | EAP-Payload | 0-1 | 0-1 | 0 | 0 | 0 | 1 | 0 | MAC | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | Device-Id | 1+ | 1+ | 0 | 0 | 0 | 0 | 0 | Cookie | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Protection-Cap. | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Session-Lifetime | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Failed-AVP | 0 | 0 | 0 | 0 | 1 | 0 | 0 | ISP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | NAP-Information | 0 | 0 | 0 | 0 | 0 | 0 | 0 | EP-Device-Id | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Key-Id | 0 | 0 | 0 | 0 | 0 | 0-1 | 0-1 | --------------------+------+------+-----+-----+-----+------+------+ " Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Mar 30 17:47:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19978 for ; Tue, 30 Mar 2004 17:47:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjj-0006YH-L9 for pana-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0HlwD017630 for pana-archive@odin.ietf.org; Tue, 27 Jan 2004 19:17:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldOt-0004aH-Dg for pana-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:17:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03434 for ; Tue, 27 Jan 2004 19:17:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AldOr-00071Z-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 19:17:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AldMj-0006Vq-00 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 19:15:34 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AldKY-0005tK-01 for pana-web-archive@ietf.org; Tue, 27 Jan 2004 19:13:18 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ald5X-000494-QG for pana-web-archive@ietf.org; Tue, 27 Jan 2004 18:57:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald5L-0005V7-4O; Tue, 27 Jan 2004 18:57:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Al9JK-0000EN-U6 for pana@optimus.ietf.org; Mon, 26 Jan 2004 11:10:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10813 for ; Mon, 26 Jan 2004 11:09:59 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al9JI-00050F-00 for pana@ietf.org; Mon, 26 Jan 2004 11:10:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al9IN-0004xy-00 for pana@ietf.org; Mon, 26 Jan 2004 11:09:04 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Al9Hr-0004vk-00 for pana@ietf.org; Mon, 26 Jan 2004 11:08:31 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i0QG8UV15941 for ; Mon, 26 Jan 2004 18:08:30 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 26 Jan 2004 18:08:29 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 26 Jan 2004 18:08:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Pana] EAP-Payload in PBR (new issue) Date: Mon, 26 Jan 2004 18:08:28 +0200 Message-ID: Thread-Topic: [Pana] EAP-Payload in PBR (new issue) Thread-Index: AcPkJjBbJUtMFvHvR3iiolUQeoUfEAAAGJgg To: Cc: X-OriginalArrivalTime: 26 Jan 2004 16:08:28.0744 (UTC) FILETIME=[A2C86C80:01C3E426] Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree - Dan > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 26 January, 2004 17:28 > To: Forsberg Dan (Nokia-NRC/Helsinki) > Cc: yohba@tari.toshiba.com; pana@ietf.org > Subject: Re: [Pana] EAP-Payload in PBR (new issue) > > > On Mon, Jan 26, 2004 at 12:23:51PM +0200, > Dan.Forsberg@nokia.com wrote: > > Ok. In EAP state machine the AAA timeout results as a > timeout_failure. > > If PBR is used, the result-code AVP should clarify this. I > coulnd't find > > any directly suitable result-code from rfc3588, though. One > that is near > > could be this one: > > > > DIAMETER_UNABLE_TO_COMPLY 5012 > > This error is returned when a request is rejected for > unspecified > > reasons. > > > > => > > > > PANA_UNABLE_TO_COMPLY 5012 > > > > This could then happen in any stage in which the EAP protocol is > > involved. > > I agree. How about having more detailed text (please see below)? > > " PANA_UNABLE_TO_COMPLY 5012 > > This error is returned when a request is rejected for > unspecified reasons. For example, when an EAP authentication > fails at an EAP pass-through authenticator without passing an > EAP-Failure message to the PAA, a Result-Code AVP with this > error code is carried in PANA-Bind-Request message without an > EAP-Payload AVP." > > > Regards, > > Yoshihiro Ohba > > > > > > > > - Dan > > > > > -----Original Message----- > > > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: 22 January, 2004 19:18 > > > To: Forsberg Dan (Nokia-NRC/Helsinki) > > > Cc: yohba@tari.toshiba.com; pana@ietf.org > > > Subject: Re: [Pana] EAP-Payload in PBR (new issue) > > > > > > > > > I thought that PANA-Error message is used for errors > occured within > > > PANA. But in this case, the error is an EAP > authentication failure > > > and I think it should be carried by PANA authentication > > > success/failure message (i.e., PBR). > > > > > > (There is another problem with using PANA-Error for this case: > > > Which AVP is considered invalid and carried in Failed-AVP?) > > > > > > Yoshihiro Ohba > > > > > > > > > On Thu, Jan 22, 2004 at 05:36:40PM +0200, > > > Dan.Forsberg@nokia.com wrote: > > > > I guess an error should be sent instead then, not the PBR msg. > > > > - Dan > > > > > > > > > -----Original Message----- > > > > > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On > > > > > Behalf Of ext Yoshihiro Ohba > > > > > Sent: 17 January, 2004 02:44 > > > > > To: pana@ietf.org > > > > > Subject: [Pana] EAP-Payload in PBR (new issue) > > > > > > > > > > > > > > > In the current PANA spec, EAP-Payload AVP is a > required AVP for > > > > > PANA-Bind-Request. However, it is possible that EAP > conversation > > > > > fails without generating a EAP-Success or EAP-Failure message, > > > > > specifically when a AAA timeout occurs (please see EAP Full > > > > > Authenticator State Machine diagram in the EAP state > > > machines draft, > > > > > pdf version). > > > > > > > > > > Thus, EAP-Payload AVP should be optional for > PANA-Bind-Request. > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pana mailing list > > > > > Pana@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Mar 30 17:50:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20585 for ; Tue, 30 Mar 2004 17:50:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rji-0006Zv-OQ for pana-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K9QNni024787 for pana-archive@odin.ietf.org; Fri, 20 Feb 2004 04:26:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au6vP-0006LQ-64 for pana-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 04:26:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11698 for ; Fri, 20 Feb 2004 04:26:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au6vB-0005LI-00 for pana-web-archive@ietf.org; Fri, 20 Feb 2004 04:26:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au6u4-0005Bn-00 for pana-web-archive@ietf.org; Fri, 20 Feb 2004 04:25:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au6tQ-00055b-00 for pana-web-archive@ietf.org; Fri, 20 Feb 2004 04:24:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au6tP-0005Wr-DY; Fri, 20 Feb 2004 04:24:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au6CH-00032B-4M for pana@optimus.ietf.org; Fri, 20 Feb 2004 03:39:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10090 for ; Fri, 20 Feb 2004 03:39:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au6CE-0002Jz-00 for pana@ietf.org; Fri, 20 Feb 2004 03:39:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au6BI-0002Hg-00 for pana@ietf.org; Fri, 20 Feb 2004 03:38:45 -0500 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1Au6AQ-0002De-00 for pana@ietf.org; Fri, 20 Feb 2004 03:37:51 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i1K8ZmIE032724; Fri, 20 Feb 2004 09:36:08 +0100 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2004022009355388:1565 ; Fri, 20 Feb 2004 09:35:53 +0100 Message-ID: <4035C6EA.1080708@alcatel.fr> Date: Fri, 20 Feb 2004 09:35:54 +0100 From: Yacine.El_Mghazli@alcatel.fr Organization: Alcatel R&I User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-gb, fr-fr, en, fr MIME-Version: 1.0 To: Alper Yegin Cc: pana@ietf.org, narten@us.ibm.com, margaret@thingmagic.com Subject: Re: [Pana] PANA meeting agenda References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 02/20/2004 09:35:54, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 02/20/2004 09:36:09, Serialize complete at 02/20/2004 09:36:09 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi pana fellows, > 4. SNMP usage for PAA-2-EP interface: 20 min, Yacine El Mghazli > > draft-yacine-pana-snmp-01.txt. This is a new I-D. The WG's opinion will > be solicited for accepting this I-D as an official working group item. looks like we had some problems publishing the lattest version on the IETF repository. anyway, there are only very few changes since the -01 (some refs corrected). please find the -02 at the following URL: http://yacine.free.fr/ietf59/pana/draft-yacine-pana-snmp-02.html http://yacine.free.fr/ietf59/pana/draft-yacine-pana-snmp-02.txt ...and you might want to browse the whole MIB set: http://yacine.free.fr/ietf59/pana/dev/ thanks, yacine _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Mar 30 18:13:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26594 for ; Tue, 30 Mar 2004 18:13:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjU-0006Xa-6F for pana-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08FmaYU027689 for pana-archive@odin.ietf.org; Thu, 8 Jan 2004 10:48:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecOh-0007CE-2T for pana-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 10:48:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28802 for ; Thu, 8 Jan 2004 10:48:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AecOd-0002bc-00 for pana-web-archive@ietf.org; Thu, 08 Jan 2004 10:48:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AecHf-0002Bs-00 for pana-web-archive@ietf.org; Thu, 08 Jan 2004 10:41:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AecCu-0001o5-00 for pana-web-archive@ietf.org; Thu, 08 Jan 2004 10:36:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecCY-0005lk-48; Thu, 08 Jan 2004 10:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AecBe-0005fe-0V for pana@optimus.ietf.org; Thu, 08 Jan 2004 10:35:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28137 for ; Thu, 8 Jan 2004 10:34:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AecBR-0001lo-00 for pana@ietf.org; Thu, 08 Jan 2004 10:34:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aec5P-0001SG-00 for pana@ietf.org; Thu, 08 Jan 2004 10:28:40 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AebzJ-000194-00 for pana@ietf.org; Thu, 08 Jan 2004 10:22:21 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id i08FM9r13066; Thu, 8 Jan 2004 16:22:10 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i08FM8L00898; Thu, 8 Jan 2004 16:22:09 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 8 Jan 2004 16:21:40 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC054F@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Mohan Parthasarathy'" Cc: "'Yoshihiro Ohba'" , "'pana@ietf.org'" Subject: RE: [Pana] Unique identifier per session Date: Thu, 8 Jan 2004 16:21:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 hi mohan, > Hannes, > > > hi mohan, > > hi yoshi, > > > > i am also in favor of including information into the > PANA-Bind-Request > > message for this purpose. but i am still not sure whether > you need to > update > > the pre-shared secret for the ike run with every eap > "reauthentication" > > protocol run.. > Updating the pre-shared secret does not mean you negotiate a > new IKE/IPSec SA. good. > It says that "in the future if you > negotiate new SA, use the new pre-shared key". What is the > problem with updating it everytime ? adding a new pre-shared secret is no problem. but you need to specify whether you run a new ike exchange as a result of a new eap exchange. i guess in ieee 802.11i/8002.1x you establish a new link layer security association if you execute a new eap exchange. is there someone who has a preference? > > > instead i would argue that you should not do it. using > this approach > > you could leave it to the network to trigger a change of the > pre-shared > > secret. > > > Do you mean a new message ? i personally think that you only need a new AVP which is carried within a PANA-Bind-Request message. ciao hannes > > -mohan > > > > ciao > > hannes > > > > > > > -----Original Message----- > > > From: Mohan Parthasarathy [mailto:mohanp@sbcglobal.net] > > > Sent: Mittwoch, 31. Dezember 2003 18:33 > > > To: Tschofenig Hannes > > > Cc: 'Yoshihiro Ohba'; pana@ietf.org > > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > > > > > a few comments on the ability to have multiple IKE > > > > > pre-shared secrets > > > > > > currently for IKE protocol runs: > > > > > > > > > > > > ike does not support this type of scenario easily. as stated > in > > > > > [ipsec-pana] > > > > > > in aggressive mode you could use the ID_KEY_ID with the > > > > > (session id || > > > > > > version number) as a key name. this would ensure that you > always > > > > > select > > > > > the > > > > > > > > > > What do you mean by version number ? > > > > > > > > if you have multiple IKE pre-shared secrets concurrently > > > then you need > > > to > > > > have a way to distinguish a more recent key from an older one. > > > > additionally you need to indicate this somehow. when entity > > > A selects > > > > key X then entity B needs to know that X was selected. > > > > > > > > the key version number could be an integer which is increased by > one > > > if > > > you > > > > add a new version of the key. > > > > > > > How do you propose to exchange this information between > PAA and PaC > > > ? See the other discussion between me and Yoshihiro. Explicit > > > communication seems better. I think this should be > another AVP. What > > > do you think ? > > > > > > -mohan > > > > > > > > > > > > > > most recent key and in case of failures it would be possible > to > > > > > fallback > > > > > to > > > > > > the previous sa. however, this does not work with ike main > mode > > > > > (pre-shared > > > > > > secret authentication) since the ID payload is sent after > > > > > authentication > > > > > > (with message 5). this already caused problems in road > > > > > warrior cases. > > > > > > > > > > > > from this point of view it would be good to use aggressive > mode > > > only > > > > > (also > > > > > > from the number of messages). however, the availability of > > > > > aggressive > > > > > mode > > > > > > in existing implementations is not widespread. > > > > > > > > > > > My next update (soon to be out) already clarifies that only > > > > > aggressive mode MUST be supported because of the problem you > > > > > mention above with main-mode. > > > > > > > > great. > > > > > > > > ciao > > > > hannes > > > > > > > > > > > > > > -mohan > > > > > > > > > > > ciao > > > > > > hannes > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > > > > Sent: Dienstag, 30. Dezember 2003 08:24 > > > > > > > To: Mohan Parthasarathy > > > > > > > Cc: Yoshihiro Ohba; pana@ietf.org > > > > > > > Subject: Re: [Pana] Unique identifier per session > > > > > > > > > > > > > > > > > > > > > Hi Mohan, > > > > > > > > > > > > > > On Thu, Dec 18, 2003 at 03:00:28PM -0800, Mohan > > > > > Parthasarathy wrote: > > > > > > > > > > > > > > > > > On Wed, Dec 17, 2003 at 09:02:09PM -0800, Mohan > > > > > > > Parthasarathy wrote: > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > PANA session ID uniquely identifies a > session. But, it > > > also > > > > > does > > > > > > > not > > > > > > > > change > > > > > > > > > > across a reauthentication. > > > > > > > > > > The PANA-IPsec draft needs something unique to > identify > > > the > > > > > > > pre-shared > > > > > > > > keys > > > > > > > > > > within a sub-session. > > > > > > > > > > Two possibilities. > > > > > > > > > > > > > > > > > > > > 1) During re-authentication, change the session > > > ID also in > > > > > > > > reauth-answer. > > > > > > > > > > 2) Invent another ID that changes with every reauth > > > > > and hence > > > > > > > uniquely > > > > > > > > > > identifies the keys derived > > > > > > > > > > during a reauth. > > > > > > > > > > > > > > > > > > I think it does not make sense to change the PANA > > > > > > > Session-ID across > > > > > > > > > (re-)authentications just for this purpose. > > > > > > > > > > > > > > > > > > How about using | as the IKE > > > pre-shared > > > > > key > > > > > > > > > identifier, where N is the number of EAP-based > > > > > re-authentications > > > > > > > > > occured for the Session-ID? > > > > > > > > > > > > > > > > > Can N go out of sync between the PAA and PaC ? > > > > > > > > I am assuming that "N" is implicitly and independently > > > > > > > arrived by PaC > > > > > > > and > > > > > > > > PAA. > > > > > > > > > > > > > > > > 1) PAA sends a reauth request > > > > > > > > 2) PaC sends a reauth answer and increments N by 1. This > > > message > > > > > is > > > > > > > lost. > > > > > > > > 3) PAA retransmits reauth request > > > > > > > > 4) PaC sends a reauth answer and increments N by 1. This > > > message > > > > > is > > > > > > > > successful. > > > > > > > > 5) PAA increments N by 1. > > > > > > > > > > > > > > Which type of "reauth" do you mean? I am assuming > > > that the IKE > > > > > > > pre-shared key is updated when an EAP-based > re-authentication > > > > > > > occurs. When the other type of reauthentication based on > > > > > > > PANA-Reauth-Request/Answer exchange occurs, I don't think > the > > > IKE > > > > > > > pre-shared key needs to be updated because there is no > > > > > change in the > > > > > > > EAP Master Session Key in this case. For EAP-based > > > > > > > re-authentication, synchronization on EAP Master > Session Key > > > > > > > derivation can be made because PANA-Bind-Request that > > > carries an > > > > > > > EAP-Success message is acknowledged with PANA-Bind-Answer > > > message. > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As you can see, N is out of sync. Is the above > possible ? > > > > > > > From what i > > > > > > > can > > > > > > > > understand > > > > > > > > about retransmissions (section 4.1.4 of PANA protocol), > > > > > the above > > > > > > > looks > > > > > > > > possible. > > > > > > > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any other possibilities ? > > > > > > > > > > > > > > > > > > > > -mohan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Pana mailing list > > > > > > > > > > Pana@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Pana mailing list > > > > > > > > > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Pana mailing list > > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Pana mailing list > > > > > > Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana > > > > > > > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Mar 30 18:14:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26774 for ; Tue, 30 Mar 2004 18:14:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjT-0006Xa-HV for pana-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15A6t0v030553 for pana-archive@odin.ietf.org; Thu, 5 Feb 2004 05:06:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AogPO-0007wf-RM for pana-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 05:06:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09591 for ; Thu, 5 Feb 2004 05:06:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AogPL-0003cA-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 05:06:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AogOP-0003WJ-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 05:05:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AogNe-0003Qt-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 05:05:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AogNc-0007qY-Us; Thu, 05 Feb 2004 05:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AogNQ-0007pV-Vr for pana@optimus.ietf.org; Thu, 05 Feb 2004 05:04:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09523 for ; Thu, 5 Feb 2004 05:04:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AogNN-0003Q2-00 for pana@ietf.org; Thu, 05 Feb 2004 05:04:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AogMT-0003L3-00 for pana@ietf.org; Thu, 05 Feb 2004 05:03:54 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1AogM3-0003Fp-00 for pana@ietf.org; Thu, 05 Feb 2004 05:03:27 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id i15A3Ro11090; Thu, 5 Feb 2004 11:03:27 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id i15A3Lw27899; Thu, 5 Feb 2004 11:03:21 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 5 Feb 2004 11:02:46 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC069D@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'jari.arkko@piuha.net'" , Yoshihiro Ohba Cc: pana@ietf.org Subject: RE: [Pana] review of the pana protocol Date: Thu, 5 Feb 2004 11:03:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 hi jari, i have a question regarding the MSK and AAA-Key. please see my comment inline: > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Thursday, February 05, 2004 9:36 AM > To: Yoshihiro Ohba > Cc: pana@ietf.org > Subject: Re: [Pana] review of the pana protocol > > > Yoshihiro Ohba wrote: > > I have one question to Jari on the definition of MSK (please > > see my comments below). > > > Master Session Key (MSK) > > > > Keying material (at least 64 octets) that is derived between > > the EAP client and server and exported by the EAP method. > > " > > > > OHBA: Is the definition (copied from > draft-ietf-eap-keying-01.txt) of > > MSK correct? I am a bit confused about the distinction between MSK > > and AAA-Key. > > > The definition is right. But there is a question of whether you > should actually use AAA-Key and not MSK. > > The difference between the MSK and the AAA-Key is that the MSK > is held by the EAP server i.e. an AAA node, whereas the AAA-Key > is the value that is communicated to the actual authenticator > i.e. PAA. So from this it is pretty clear that your draft should > really talk about the AAA-Key. On the other hand, while different > designs have been discussed in the EAP WG, in 802.11i the AAA-Key > is octets 0-31 of the MSK. it is said that the AAA-Key is derived from the MSK and EMSK. the eap-keying document does not specify how this key derivation is achieved. worse, in Section 4.2.1 the text says: " The AAA-Key is derived from the keying material exported by the EAP method (MSK and EMSK). This derivation occurs on the AAA server. In many existing protocols that use EAP, the AAA-Key and MSK are equivalent, but more complicated mechanisms are possible (see Appendix E for details). " appendix e, however, does not help since it talks only about a very special case, namely fast handoff. in our eap keying design team phone conferences i suggested to have something standardized here and that the document (i guess i also included this issue in my comments for the eap-keying draft). unfortunately, i never got a single comment. i personally think that example key derivation procedures, as for example shown in appendix E, etc. do not really help. instead it would be more helpful to offer one mechanism which should be used. i personally think that this is somewhat vague and should be specified since the EAP peer and the Authenticator are supposed to end up with the same key after the EAP protocol exchange is finished. ciao hannes _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Mar 30 18:35:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02441 for ; Tue, 30 Mar 2004 18:35:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjF-0006a4-Oy for pana-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALfG3l018096 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 16:41:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqfcx-0004hn-6B for pana-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:41:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20378 for ; Tue, 10 Feb 2004 16:41:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqfcv-0000Jn-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 16:41:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqfbx-00009Q-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 16:40:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqfay-0007mT-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 16:39:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqfav-0001h6-Iu; Tue, 10 Feb 2004 16:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfaS-0001du-Oa for pana@optimus.ietf.org; Tue, 10 Feb 2004 16:38:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20097 for ; Tue, 10 Feb 2004 16:38:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfaQ-0007ed-00 for pana@ietf.org; Tue, 10 Feb 2004 16:38:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfZD-0007Qj-00 for pana@ietf.org; Tue, 10 Feb 2004 16:37:18 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AqfXn-00074P-00 for pana@ietf.org; Tue, 10 Feb 2004 16:35:47 -0500 Date: Tue, 10 Feb 2004 13:35:58 -0800 Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy From: Alper Yegin To: Yoshihiro Ohba , Message-ID: In-Reply-To: <20040209225949.GB15608@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pana-admin@ietf.org Errors-To: pana-admin@ietf.org X-BeenThere: pana@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Protocol for carrying Authentication for Network Access List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It is possible that both PAA and PaC initiate the discovery and initial handshake procedure at the same time, i.e., the PAA sends a PANA-Start-Request message while the PaC sends a PANA-PAA-Discover message. To resolve the race condition, the PAA SHOULD silently discard the PANA-PAA-Discover message received from the PaC after it has sent a PANA-Start-Request message with creating a state for the PaC. JARI: (Substantial) Since you said above that a PANA-Start-Request message is never retransmitted, what if this message is lost AND you at the same time silently discard all PANA-PAA-Discover messages? Seems like you would be stuck, or did I miss something? Couldn't we solve this by simply PAA responding to PDI even if it already sent an unsolicited PSR? Of course the PaC would know not to respond to all PSRs it receives. Alper On 2/9/04 2:59 PM, "Yoshihiro Ohba" wrote: > On Thu, Feb 05, 2004 at 11:41:51AM +0200, Dan.Forsberg@nokia.com wrote: >> New submission from Dan Forsberg : >> >> From Jari Arkko: >>> - "PSR retransmission strategy" >>> >>> In Section 4.2 I also had a possible issue with retransmission >>> strategy in case PSR is lost. The document seems to say that >>> PSRs are never retransmitted but at the same time the PDIs >>> are silently discarded. This could lead to a deadlock. >> >> Alper Yegin: >> Another issue to open. > > As Jari pointed out, I think the deadlock situation can occur. > > There are two cases when a PSR is sent. > > - A PSR is sent with creating a PANA session state. > > This cases occurs when a Cookie AVP is not included in the PSR (i.e., > stateful discovery). Since the PAA does create a state, the deadlock > can occur if PAA discards PDI after sending the PSR. I think that the > PAA should retransmit the PSR in this case to avoid the deadlock. > > - A PSR is sent without creating a PANA session state. > > This cases occurs when a Cookie AVP is included in the PSR (i.e., > stateless discovery). Since the PAA does not have a state, the > deadlock cannot not occur. > > What about PSA? I think in the case where a PSR is retransmitted, the > PSA does not need to be retransmitted. > > > Suggested changes: > > In section 4.2, change: > > "A PANA-Start-Request message is never retransmitted. A > PANA-Start-Answer message is retransmitted based on timer in the same > manner as other messages retransmitted at PANA-layer." > > to: > > "If a PANA-Start-Request message is sent without carrying a Cookie > AVP, the PAA MUST retransmit the message. Otherwise, if a > PANA-Start-Request message is sent with carrying a Cookie AVP, the > PAA MUST NOT retransmit the message. On the other hand, if a > PANA-Start-Answer message is sent without carrying a Cookie AVP, the > PaC MUST NOT retransmit the message. Otherwise, if a > PANA-Start-Answer message is sent with carrying > a Cookie AVP, the PaC MUST retransmit the message." > > > Change the first paragraph of section 10 to: > > "The PANA protocol provides retransmissions for all the message > exchanges except PANA-Auth-Request/Answer. PANA-Auth-Request messages > carry EAP requests which are retransmitted by the EAP protocol > entities when needed. The messages that need PANA-level > retransmissions are listed below: > > PANA-PAA-Discover (PDI) > PANA-Start-Request (PSR)* > PANA-Start-Answer (PSA)** > PANA-Bind-Request (PBR) > PANA-Reauth-Request (PRAR) > PANA-Termination-Request (PTR) > > *) PSR that carries a Cookie AVP is not retransmitted. > **) PSA that does not carry a Cookie AVP is not retransmitted." > > > Yoshihiro Ohba > > _______________________________________________ > Pana mailing list > Pana@ietf.org > https://www1.ietf.org/mailman/listinfo/pana > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana