From mailman-admin@ietf.org Sun Feb 1 09:06:55 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11918 for ; Sun, 1 Feb 2004 09:06: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 1AnIF3-0007Nk-7R for pana-archive@lists.ietf.org; Sun, 01 Feb 2004 09:06:29 -0500 Date: Sun, 01 Feb 2004 09:06:29 -0500 Message-ID: <20040201140629.1364.42748.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 Feb 2 20:59:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00454 for ; Mon, 2 Feb 2004 20:59: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 1Anpq9-00089C-ER; Mon, 02 Feb 2004 20: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 1Anpq8-000891-Sr for pana@optimus.ietf.org; Mon, 02 Feb 2004 20:59:00 -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 UAA00427 for ; Mon, 2 Feb 2004 20:58:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anpq6-0007HO-00 for pana@ietf.org; Mon, 02 Feb 2004 20:58:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anpp8-0007CT-00 for pana@ietf.org; Mon, 02 Feb 2004 20:57:59 -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 1AnpoT-00078D-00 for pana@ietf.org; Mon, 02 Feb 2004 20:57:17 -0500 Date: Mon, 02 Feb 2004 17:57:18 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-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] FW: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea 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 FYI.... ---------- Forwarded message ---------- Date: Mon, 02 Feb 2004 10:48:25 -0500 From: internet-drafts@ietf.org To: IETF-Announce: ; Subject: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea There are two (2) Internet-Draft cutoff dates for the 59th IETF Meeting in Seoul, Korea: February 9th: Cutoff Date for Initial Internet-Draft Submissions (new documents) All initial Internet-Drafts (-00) and updates to initial Internet-Drafts must be submitted by Monday, February 9th, at 09:00 ET. As always, all initial submissions (-00) with a filename beginning with "draft-ietf" MUST be approved by the appropriateWG Chair before they can be processed or announced. WG Chair approval MUST be received by Wednesday, February 4th, at 09:00 ET. February 16th: Cutoff Date for Revised Internet-Draft Submissions (-01 and higher) All revised Internet-Drafts (-01 and higher) must be submitted by Monday, February 16th, at 09:00 ET. Initial and revised Internet-Drafts received after their respective cutoff dates will NOT be made available in the Internet-Drafts directory OR announced, and will have to be resubmitted. Please do NOT wait until the last minute to submit. The Secretariat will begin accepting Internet-Draft submissions starting Monday, March 8th. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. FYI: The Internet-Draft cutoff dates as well as other significant dates for the 59th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_59.html. _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Feb 2 21:01:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00562 for ; Mon, 2 Feb 2004 21:01: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 1Anps5-0008U5-TM for pana-archive@odin.ietf.org; Mon, 02 Feb 2004 21:01:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13211k9032607 for pana-archive@odin.ietf.org; Mon, 2 Feb 2004 21:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anps5-0008Tq-PG for pana-web-archive@optimus.ietf.org; Mon, 02 Feb 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 VAA00532 for ; Mon, 2 Feb 2004 21:00:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anps3-0007Sc-00 for pana-web-archive@ietf.org; Mon, 02 Feb 2004 21:00:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anpr5-0007Mu-00 for pana-web-archive@ietf.org; Mon, 02 Feb 2004 21:00:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Anpq9-0007Hx-00 for pana-web-archive@ietf.org; Mon, 02 Feb 2004 20: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 1Anpq9-00089C-ER; Mon, 02 Feb 2004 20: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 1Anpq8-000891-Sr for pana@optimus.ietf.org; Mon, 02 Feb 2004 20:59:00 -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 UAA00427 for ; Mon, 2 Feb 2004 20:58:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anpq6-0007HO-00 for pana@ietf.org; Mon, 02 Feb 2004 20:58:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anpp8-0007CT-00 for pana@ietf.org; Mon, 02 Feb 2004 20:57:59 -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 1AnpoT-00078D-00 for pana@ietf.org; Mon, 02 Feb 2004 20:57:17 -0500 Date: Mon, 02 Feb 2004 17:57:18 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] FW: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea 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 FYI.... ---------- Forwarded message ---------- Date: Mon, 02 Feb 2004 10:48:25 -0500 From: internet-drafts@ietf.org To: IETF-Announce: ; Subject: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea There are two (2) Internet-Draft cutoff dates for the 59th IETF Meeting in Seoul, Korea: February 9th: Cutoff Date for Initial Internet-Draft Submissions (new documents) All initial Internet-Drafts (-00) and updates to initial Internet-Drafts must be submitted by Monday, February 9th, at 09:00 ET. As always, all initial submissions (-00) with a filename beginning with "draft-ietf" MUST be approved by the appropriateWG Chair before they can be processed or announced. WG Chair approval MUST be received by Wednesday, February 4th, at 09:00 ET. February 16th: Cutoff Date for Revised Internet-Draft Submissions (-01 and higher) All revised Internet-Drafts (-01 and higher) must be submitted by Monday, February 16th, at 09:00 ET. Initial and revised Internet-Drafts received after their respective cutoff dates will NOT be made available in the Internet-Drafts directory OR announced, and will have to be resubmitted. Please do NOT wait until the last minute to submit. The Secretariat will begin accepting Internet-Draft submissions starting Monday, March 8th. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. FYI: The Internet-Draft cutoff dates as well as other significant dates for the 59th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_59.html. _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Feb 4 04:29: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 EAA27501 for ; Wed, 4 Feb 2004 04:29: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 1AoJLB-0006As-Hn; Wed, 04 Feb 2004 04:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJKE-00069R-AR for pana@optimus.ietf.org; Wed, 04 Feb 2004 04:28: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 EAA27437 for ; Wed, 4 Feb 2004 04:27:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJKB-00037X-00 for pana@ietf.org; Wed, 04 Feb 2004 04:27:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJJF-00031a-00 for pana@ietf.org; Wed, 04 Feb 2004 04:27:02 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AoJIK-0002wU-00 for pana@ietf.org; Wed, 04 Feb 2004 04:26:04 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 122586A902 for ; Wed, 4 Feb 2004 11:26:04 +0200 (EET) Message-ID: <4020BA4D.1010905@piuha.net> Date: Wed, 04 Feb 2004 11:24:29 +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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Pana] review of the pana protocol 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, I have read draft-ietf-pana-pana-03b. You can find my comments from http://www.arkko.com/publications/pana/pana_03b_review.txt For your convenience, the overall comments are copied below: In general, I was quite positively surprised by this document. The basic design is sound as far as I can see, and in some aspects better than competing link layer designs. I did have quite many questions and technical issues, however, so we should work to address them. Note: My review comments have been marked like this, and classified either as Substantial, Technical, Editorial, Comment, or Question. The substantial issues I identified are listed also below: - "key generation mandatory" Consider requiring only key generating EAP methods, as then the security properties of the PANA protocol are much better and can be described in a much easier way. Note that you do NOT have to use data protection for the benefits to be realized. State synchronization issues are avoided as you can confirm success with the MACs in the Bind Request and Answer. Or termination can be done securely. Note: EAP-TLS, EAP-SIM, EAP-AKA, EAP-Archie, EAP-IKEv2, EAP-MSCHAPV2, and all tunnel methods provide keys. I have understood that for all legacy EAP methods that do not provide keys, there exists newer variants that do and which can still reuse the old credentials. - "Details of double authentication" Perhaps its just me, but I did not find all the details regarding the use of two (NAP and ISP) authentications. Is this supported or not? Are they performed in sequence? Does it look like a re-authentication, or do you provide a bit somewhere that indicates whether this EAP run relates to the NAP or the ISP authentication? Is there a PANA Bind Request - Answer pair in between or not? Is it really necessary to provide to separate authentications? Traditionally, NAP - ISP separation has been achieved through roaming relationships in AAA, i.e., you just authenticate to the access network but they forward the AAA transaction to the home network. Why is there no problem with the mitm attacks in the PANA authentication sequences, as there are in other EAP sequencing? - "Additional discovery information?" I'm not sure if there is a need to provide some additional information in the discovery phase. For instance, is there a need to identify the NAS/PAA in a scenario where the NAS/PAA has multiple interfaces and multiple addresses? Knowing you are still connected to the same NAS might help future handoff designs. - "Cookie mandatory" I would like the inclusion of the cookie to in the start exchange to be mandatory. - "Client cookie useful?" Would it be useful for the client to provide its own cookie as well, such that for solicited PSRs, the client's cookie would be copied back. This would cost very little, but protect the client against blind PAA spoofing attempts. - "AAA routing based on NAI vs. ISP choice" Section 4.2 claims that AAA routing is based on the ISP choice. I believe the first hop decision can be based on this, but further on in the network it must be based on the NAI (unless you revise AAA protocols). - "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. (It would be very useful to see a state machines filled in.) - "Fast-reauthentication and authorization issues" I have reservations about the inclusion of the fast re-authentication scheme in the base PANA document. There are a number of security issues at the system level when you try to do this. See draft-ietf-eap-keying-01.txt, Sections 1.4 and 1.4.1 in particular for some examples. Note also that many EAP methods provide fast re-authentication. - "TTL and other IP layer details" I think you should specify in more detail the contents of the IP and UDP headers associated with PANA messages. For instance, the document implies that TTL can be used to limit the ability of attackers to send PANA messages, but I did not find a place where the document would actually require setting or checking the TTL. Or did I miss it? _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Feb 4 04: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 EAA27617 for ; Wed, 4 Feb 2004 04: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 1AoJNA-0006TD-GJ for pana-archive@odin.ietf.org; Wed, 04 Feb 2004 04:31:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i149V40R024861 for pana-archive@odin.ietf.org; Wed, 4 Feb 2004 04:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJN9-0006Sr-N2 for pana-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 04:31: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 EAA27578 for ; Wed, 4 Feb 2004 04:31:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJN6-0003PM-00 for pana-web-archive@ietf.org; Wed, 04 Feb 2004 04:31:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJM8-0003Jj-00 for pana-web-archive@ietf.org; Wed, 04 Feb 2004 04:30:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoJLC-0003ES-00 for pana-web-archive@ietf.org; Wed, 04 Feb 2004 04:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJLB-0006As-Hn; Wed, 04 Feb 2004 04:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoJKE-00069R-AR for pana@optimus.ietf.org; Wed, 04 Feb 2004 04:28: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 EAA27437 for ; Wed, 4 Feb 2004 04:27:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoJKB-00037X-00 for pana@ietf.org; Wed, 04 Feb 2004 04:27:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoJJF-00031a-00 for pana@ietf.org; Wed, 04 Feb 2004 04:27:02 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AoJIK-0002wU-00 for pana@ietf.org; Wed, 04 Feb 2004 04:26:04 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 122586A902 for ; Wed, 4 Feb 2004 11:26:04 +0200 (EET) Message-ID: <4020BA4D.1010905@piuha.net> Date: Wed, 04 Feb 2004 11:24:29 +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] review of the pana protocol 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 Hi, I have read draft-ietf-pana-pana-03b. You can find my comments from http://www.arkko.com/publications/pana/pana_03b_review.txt For your convenience, the overall comments are copied below: In general, I was quite positively surprised by this document. The basic design is sound as far as I can see, and in some aspects better than competing link layer designs. I did have quite many questions and technical issues, however, so we should work to address them. Note: My review comments have been marked like this, and classified either as Substantial, Technical, Editorial, Comment, or Question. The substantial issues I identified are listed also below: - "key generation mandatory" Consider requiring only key generating EAP methods, as then the security properties of the PANA protocol are much better and can be described in a much easier way. Note that you do NOT have to use data protection for the benefits to be realized. State synchronization issues are avoided as you can confirm success with the MACs in the Bind Request and Answer. Or termination can be done securely. Note: EAP-TLS, EAP-SIM, EAP-AKA, EAP-Archie, EAP-IKEv2, EAP-MSCHAPV2, and all tunnel methods provide keys. I have understood that for all legacy EAP methods that do not provide keys, there exists newer variants that do and which can still reuse the old credentials. - "Details of double authentication" Perhaps its just me, but I did not find all the details regarding the use of two (NAP and ISP) authentications. Is this supported or not? Are they performed in sequence? Does it look like a re-authentication, or do you provide a bit somewhere that indicates whether this EAP run relates to the NAP or the ISP authentication? Is there a PANA Bind Request - Answer pair in between or not? Is it really necessary to provide to separate authentications? Traditionally, NAP - ISP separation has been achieved through roaming relationships in AAA, i.e., you just authenticate to the access network but they forward the AAA transaction to the home network. Why is there no problem with the mitm attacks in the PANA authentication sequences, as there are in other EAP sequencing? - "Additional discovery information?" I'm not sure if there is a need to provide some additional information in the discovery phase. For instance, is there a need to identify the NAS/PAA in a scenario where the NAS/PAA has multiple interfaces and multiple addresses? Knowing you are still connected to the same NAS might help future handoff designs. - "Cookie mandatory" I would like the inclusion of the cookie to in the start exchange to be mandatory. - "Client cookie useful?" Would it be useful for the client to provide its own cookie as well, such that for solicited PSRs, the client's cookie would be copied back. This would cost very little, but protect the client against blind PAA spoofing attempts. - "AAA routing based on NAI vs. ISP choice" Section 4.2 claims that AAA routing is based on the ISP choice. I believe the first hop decision can be based on this, but further on in the network it must be based on the NAI (unless you revise AAA protocols). - "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. (It would be very useful to see a state machines filled in.) - "Fast-reauthentication and authorization issues" I have reservations about the inclusion of the fast re-authentication scheme in the base PANA document. There are a number of security issues at the system level when you try to do this. See draft-ietf-eap-keying-01.txt, Sections 1.4 and 1.4.1 in particular for some examples. Note also that many EAP methods provide fast re-authentication. - "TTL and other IP layer details" I think you should specify in more detail the contents of the IP and UDP headers associated with PANA messages. For instance, the document implies that TTL can be used to limit the ability of attackers to send PANA messages, but I did not find a place where the document would actually require setting or checking the TTL. Or did I miss it? _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Feb 4 17:58: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 RAA05748 for ; Wed, 4 Feb 2004 17:58: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 1AoVy5-00073z-3o; Wed, 04 Feb 2004 17:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVxj-00072V-1h for pana@optimus.ietf.org; Wed, 04 Feb 2004 17:57: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 RAA05685 for ; Wed, 4 Feb 2004 17:57:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoVxg-00041R-00 for pana@ietf.org; Wed, 04 Feb 2004 17:57:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoVwb-0003tZ-00 for pana@ietf.org; Wed, 04 Feb 2004 17:56:30 -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 1AoVvh-0003o8-00 for pana@ietf.org; Wed, 04 Feb 2004 17:55:33 -0500 Date: Wed, 04 Feb 2004 14:55:38 -0800 Subject: Re: [Pana] review of the pana protocol From: Alper Yegin To: , Message-ID: In-Reply-To: <4020BA4D.1010905@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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 Hi Jari, Thank you very much for this detailed review. It is very helpful. Please see my brief response below. We will open new issues in the PANA tracking system, so that we can trace the relevant discussions and decisions. > The substantial issues I identified are listed also below: > > - "key generation mandatory" > > Consider requiring only key generating EAP methods, as then > the security properties of the PANA protocol are much better > and can be described in a much easier way. Note that you do > NOT have to use data protection for the benefits to be > realized. State synchronization issues are avoided as you can > confirm success with the MACs in the Bind Request and > Answer. Or termination can be done securely. Note: EAP-TLS, > EAP-SIM, EAP-AKA, EAP-Archie, EAP-IKEv2, EAP-MSCHAPV2, and all > tunnel methods provide keys. I have understood that for all > legacy EAP methods that do not provide keys, there exists > newer variants that do and which can still reuse the old > credentials. I agree that making this assumption would simplify the PANA specification. But as an EAP lower-layer, I don't think we can do that. We should be able to carry EAP which might carry any EAP method. As long as there are such legacy methods and networks using them, making key generation mandatory would appear as a limitation of the PANA. > > - "Details of double authentication" > > Perhaps its just me, but I did not find all the details > regarding the use of two (NAP and ISP) authentications. Is > this supported or not? Are they performed in sequence? Does it > look like a re-authentication, or do you provide a bit > somewhere that indicates whether this EAP run relates to the > NAP or the ISP authentication? Is there a PANA Bind Request - > Answer pair in between or not? This says the text is not sufficient. We shall open an issue on this and try to clearly answer your questions. > > Is it really necessary to provide to separate authentications? > Traditionally, NAP - ISP separation has been achieved through > roaming relationships in AAA, i.e., you just authenticate to > the access network but they forward the AAA transaction to the > home network. This was discussed during the requirements stage. Some (DSL) operators indicated that separately authenticating the user to the NAP and ISP is a desirable feature. This helps them provide differentiated services through the user's subscription to both service providers. This is an enhancement to the current picture as you described. > Why is there no problem with the mitm attacks in the PANA > authentication sequences, as there are in other EAP sequencing? Along with revising the text, we should also analize this. > > - "Additional discovery information?" > > I'm not sure if there is a need to provide some additional > information in the discovery phase. For instance, is there a > need to identify the NAS/PAA in a scenario where the NAS/PAA > has multiple interfaces and multiple addresses? Knowing you > are still connected to the same NAS might help future handoff > designs. This sounds like a useful feature. I'd recommend we open an issue and investigate this. It can assist movement detection. > > - "Cookie mandatory" > > I would like the inclusion of the cookie to in the start > exchange to be mandatory. > > - "Client cookie useful?" > > Would it be useful for the client to provide its own cookie as > well, such that for solicited PSRs, the client's cookie would > be copied back. This would cost very little, but protect the > client against blind PAA spoofing attempts. OK, we shall open an issue and track this. > > - "AAA routing based on NAI vs. ISP choice" > > Section 4.2 claims that AAA routing is based on the ISP > choice. I believe the first hop decision can be based on > this, but further on in the network it must be based on the > NAI (unless you revise AAA protocols). Another issue to open (at least to clarify the text). > > - "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. Another issue to open. > > (It would be very useful to see a state machines filled in.) We have on-going state machine work. http://danforsberg.info:8080/pana-issues/issue28 . > - "Fast-reauthentication and authorization issues" > > I have reservations about the inclusion of the fast > re-authentication scheme in the base PANA document. There are > a number of security issues at the system level when you try > to do this. See draft-ietf-eap-keying-01.txt, Sections 1.4 and > 1.4.1 in particular for some examples. > > Note also that many EAP methods provide fast re-authentication. I think we should open an issue and investigate this. > > - "TTL and other IP layer details" > > I think you should specify in more detail the contents of the > IP and UDP headers associated with PANA messages. For > instance, the document implies that TTL can be used to limit > the ability of attackers to send PANA messages, but I did not > find a place where the document would actually require setting > or checking the TTL. Or did I miss it? Yes, this is missing. We can clarify this in the text (new issue). Thank you. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Feb 4 18:00: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 SAA05914 for ; Wed, 4 Feb 2004 18:00: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 1AoVzn-0007Ej-Ln for pana-archive@odin.ietf.org; Wed, 04 Feb 2004 17:59:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14MxlCH027811 for pana-archive@odin.ietf.org; Wed, 4 Feb 2004 17:59:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVzn-0007EU-Ft for pana-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 17:59: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 RAA05866 for ; Wed, 4 Feb 2004 17:59:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoVzk-0004Ji-00 for pana-web-archive@ietf.org; Wed, 04 Feb 2004 17:59:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoVys-0004CD-00 for pana-web-archive@ietf.org; Wed, 04 Feb 2004 17:58:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoVy5-00044U-00 for pana-web-archive@ietf.org; Wed, 04 Feb 2004 17:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVy5-00073z-3o; Wed, 04 Feb 2004 17:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoVxj-00072V-1h for pana@optimus.ietf.org; Wed, 04 Feb 2004 17:57: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 RAA05685 for ; Wed, 4 Feb 2004 17:57:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoVxg-00041R-00 for pana@ietf.org; Wed, 04 Feb 2004 17:57:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoVwb-0003tZ-00 for pana@ietf.org; Wed, 04 Feb 2004 17:56:30 -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 1AoVvh-0003o8-00 for pana@ietf.org; Wed, 04 Feb 2004 17:55:33 -0500 Date: Wed, 04 Feb 2004 14:55:38 -0800 Subject: Re: [Pana] review of the pana protocol From: Alper Yegin To: , Message-ID: In-Reply-To: <4020BA4D.1010905@piuha.net> 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 Hi Jari, Thank you very much for this detailed review. It is very helpful. Please see my brief response below. We will open new issues in the PANA tracking system, so that we can trace the relevant discussions and decisions. > The substantial issues I identified are listed also below: > > - "key generation mandatory" > > Consider requiring only key generating EAP methods, as then > the security properties of the PANA protocol are much better > and can be described in a much easier way. Note that you do > NOT have to use data protection for the benefits to be > realized. State synchronization issues are avoided as you can > confirm success with the MACs in the Bind Request and > Answer. Or termination can be done securely. Note: EAP-TLS, > EAP-SIM, EAP-AKA, EAP-Archie, EAP-IKEv2, EAP-MSCHAPV2, and all > tunnel methods provide keys. I have understood that for all > legacy EAP methods that do not provide keys, there exists > newer variants that do and which can still reuse the old > credentials. I agree that making this assumption would simplify the PANA specification. But as an EAP lower-layer, I don't think we can do that. We should be able to carry EAP which might carry any EAP method. As long as there are such legacy methods and networks using them, making key generation mandatory would appear as a limitation of the PANA. > > - "Details of double authentication" > > Perhaps its just me, but I did not find all the details > regarding the use of two (NAP and ISP) authentications. Is > this supported or not? Are they performed in sequence? Does it > look like a re-authentication, or do you provide a bit > somewhere that indicates whether this EAP run relates to the > NAP or the ISP authentication? Is there a PANA Bind Request - > Answer pair in between or not? This says the text is not sufficient. We shall open an issue on this and try to clearly answer your questions. > > Is it really necessary to provide to separate authentications? > Traditionally, NAP - ISP separation has been achieved through > roaming relationships in AAA, i.e., you just authenticate to > the access network but they forward the AAA transaction to the > home network. This was discussed during the requirements stage. Some (DSL) operators indicated that separately authenticating the user to the NAP and ISP is a desirable feature. This helps them provide differentiated services through the user's subscription to both service providers. This is an enhancement to the current picture as you described. > Why is there no problem with the mitm attacks in the PANA > authentication sequences, as there are in other EAP sequencing? Along with revising the text, we should also analize this. > > - "Additional discovery information?" > > I'm not sure if there is a need to provide some additional > information in the discovery phase. For instance, is there a > need to identify the NAS/PAA in a scenario where the NAS/PAA > has multiple interfaces and multiple addresses? Knowing you > are still connected to the same NAS might help future handoff > designs. This sounds like a useful feature. I'd recommend we open an issue and investigate this. It can assist movement detection. > > - "Cookie mandatory" > > I would like the inclusion of the cookie to in the start > exchange to be mandatory. > > - "Client cookie useful?" > > Would it be useful for the client to provide its own cookie as > well, such that for solicited PSRs, the client's cookie would > be copied back. This would cost very little, but protect the > client against blind PAA spoofing attempts. OK, we shall open an issue and track this. > > - "AAA routing based on NAI vs. ISP choice" > > Section 4.2 claims that AAA routing is based on the ISP > choice. I believe the first hop decision can be based on > this, but further on in the network it must be based on the > NAI (unless you revise AAA protocols). Another issue to open (at least to clarify the text). > > - "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. Another issue to open. > > (It would be very useful to see a state machines filled in.) We have on-going state machine work. http://danforsberg.info:8080/pana-issues/issue28 . > - "Fast-reauthentication and authorization issues" > > I have reservations about the inclusion of the fast > re-authentication scheme in the base PANA document. There are > a number of security issues at the system level when you try > to do this. See draft-ietf-eap-keying-01.txt, Sections 1.4 and > 1.4.1 in particular for some examples. > > Note also that many EAP methods provide fast re-authentication. I think we should open an issue and investigate this. > > - "TTL and other IP layer details" > > I think you should specify in more detail the contents of the > IP and UDP headers associated with PANA messages. For > instance, the document implies that TTL can be used to limit > the ability of attackers to send PANA messages, but I did not > find a place where the document would actually require setting > or checking the TTL. Or did I miss it? Yes, this is missing. We can clarify this in the text (new issue). Thank you. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Feb 4 21: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 VAA13440 for ; Wed, 4 Feb 2004 21: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 1AoYyr-00005V-Fv; Wed, 04 Feb 2004 21:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoYyT-0008Vq-Vw for pana@optimus.ietf.org; Wed, 04 Feb 2004 21:10:38 -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 VAA13403 for ; Wed, 4 Feb 2004 21:10:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoYyR-0007IH-00 for pana@ietf.org; Wed, 04 Feb 2004 21:10:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoYxW-0007CI-00 for pana@ietf.org; Wed, 04 Feb 2004 21:09:40 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AoYwd-000761-00 for pana@ietf.org; Wed, 04 Feb 2004 21:08:43 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1528aN9029312; Thu, 5 Feb 2004 11:08:36 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1528auJ009657; Thu, 5 Feb 2004 11:08:36 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id MAA09656 ; Thu, 5 Feb 2004 11:08:36 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id LAA20562; Thu, 5 Feb 2004 11:08:35 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id LAA06494; Thu, 5 Feb 2004 11:08:26 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1528ONT014425; Thu, 5 Feb 2004 11:08:25 +0900 (JST) Received: from steelhead ([159.119.168.123]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSL004VG9XY5U@tsbpo1.po.toshiba.co.jp>; Thu, 5 Feb 2004 11:08:24 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AoYvs-0004YN-00; Wed, 04 Feb 2004 18:07:56 -0800 Date: Wed, 04 Feb 2004 18:07:56 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] review of the pana protocol In-reply-to: <4020BA4D.1010905@piuha.net> To: Jari Arkko Cc: pana@ietf.org Message-id: <20040205020756.GQ12173@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Jari Arkko , pana@ietf.org User-Agent: Mutt/1.5.4i References: <4020BA4D.1010905@piuha.net> 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: , Thanks Jari for your detailed review. I first try to resolve Editorial issues first, so that the editorial changes are quickly reflected to the upcoming -03 draft. Your 18 editorial comments (as well as 3 "Comment" comments) are all valid. I have one question to Jari on the definition of MSK (please see my comments below). ------- Currently there is no standard network-layer solution for authenticating clients for network access. [I-D.ietf-pana-usage-scenarios] describes the problem statement that led to the development of PANA. Scope of this working group is identified as designing a link-layer JARI: (Editorial) s/working group/work/? OHBA: OK. ----- agnostic transport for network access authentication methods. PANA Working Group has identified EAP [RFC2284] as the payload for this protocol and carrier for authentication methods. JARI: (Editorial) Maybe replace with "The Extensible Authentication Protocol (EAP) [RFC2284bis] provides such authentication methods." OHBA: OK. ---- Various environments and usage models for PANA are identified in the [I-D.ietf-pana-usage-scenarios] Internet-Draft. Potential security threats for network-layer access authentication protocol is discussed JARI: (Editorial) s/is/are/ OHBA: OK. ----- This Internet-Draft makes an attempt for defining the PANA protocol based on the other drafts discussed above. Special care has been given to ensure the currently stated scope is observed and to keep the protocol as simple as possible. The current state of this draft is not complete, but it should be regarded as a work in progress. The authors made effort to capture the common understanding developed within the working group as much as possible. The design choices being made in this draft should not be considered as cast in stone. JARI: (Editorial) Yes, but this is assumed for I-Ds anyway. You could probably remove the paragraph. OHBA: I agree. Let's remove it. ------- The definition of the terms PANA Client (PaC), PANA Authentication Agent (PAA), Enforcement Point (EP) and Device Identifier (DI) can be found in [I-D.ietf-pana-requirements]. JARI: (Editorial) If its just 4 definitions, I would prefer them to be copied here too. OHBA: Yes, it is better. So I would replace the above paragraph with the following text (copied from [I-D.ietf-pana-requirements]): " PANA Client (PaC) The client side of the protocol that resides in the host device which is responsible for providing the credentials to prove its identity for network access authorization. Device Identifier (DI) The identifier used by the network as a handle to control and police the network access of a client. Depending on the access technology, this identifier might contain any of IP address, link-layer address, switch port number, etc. of a connected device. PANA Authentication Agent (PAA) The access network side entity of the protocol whose responsibility is to verify the credentials provided by a PANA client and grant network access service to the device associated with the client and identified by a DI. Enforcement Point (EP) A node on the access network where per-packet enforcement policies (i.e., filters) are applied on the inbound and outbound traffic of client devices. Information such as DI and (optionally) cryptographic keys are provided by PAA per client for constructing filters on the EP. " OHBA: Also, I will add the following definitions here to reflect your other comments: Network Access Provider (NAP) A service provider that provides physical and link-layer connectivity to an access network it manages. 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. ------- 3. Protocol Overview The PANA protocol involves two functional entities namely the PaC and the PAA. The EP, mentioned in the context with PANA, is a logical entity. There is, however, the option that the EP is not physically co-located with the PAA. In case that the PAA and the EP are co-located only an API is required for intercommunication instead of a separate protocol. In the case where the PAA is separated from the EP, a separate protocol will be used between the PAA and the EP for managing access control. The protocol and messaging between the PAA and EP for access authorization is outside the scope of this draft and will be dealt separately. JARI: (Editorial) For the clarity of presentation, maybe you should talk about the EP case later, and not start with it. OHBA: I agree. How about re-arranging the contents of section 3 like: " 3. Protocol Overview The PANA protocol involves two functional entities namely the PaC and the PAA. The protocol resides above the transport layer and the details are explained in Section 4. The placement of the entities used in PANA largely depends on a certain architecture. The PAA may optionally interact with a AAA backend to authenticate the user (PaC). The EP, mentioned in the context with PANA, is a logical entity. There is, however, the option that the EP is not physically co-located with the PAA. In case that the PAA and the EP are co-located only an API is required for intercommunication instead of a separate protocol. In the case where the PAA is separated from the EP, a separate protocol will be used between the PAA and the EP for managing access control. The protocol and messaging between the PAA and EP for access authorization is outside the scope of this draft and will be dealt separately. Figure 1 illustrates the interactions in a simplified manner: PaC EP PAA AAA --- --- --- --- PAA Discovery <---------------------o------------> (1) PANA Authentication AAA interaction <----------------------------------><------------> (2) Authorization <------------- (3) Figure 1: PANA Framework (End of Section 3) ------ o Session-Id AVP: contains the session identifier value. o Session-Lifetime AVP: contains the duration of authorized access. o Failed-AVP: contains the offending AVP that caused a failure. o NAP-Information AVP, ISP-Information AVP: contains the information on a NAP and an ISP, respectively. JARI: (Editorial) NAP term not yet defined. Add to defs section. OHBA: OK. o Key-Id AVP: contains an MSK identifier. JARI: (Editorial) MSK not yet defined. Add to defs section. OHBA: OK. ----- unicast. PaC MAY use unspecified IP address for communicating with PAA. JARI: (Comment) I think I have said it in the past that I have reservations about the use of the unspecified address. But I forget what the resolution of this was. Reading on... OHBA: The use of unspecified address will be removed in -03. ------ PANA_MAC_KEY = The first N-bit of HMAC_SHA1(MSK, ISN_pac | ISN_paa | Session-ID) JARI: (Editorial) s/N-bit/N bits/ OHBA: OK. ------ where the value of N depends on the integrity protection algorithm in use, i.e., N=128 for HMAC-MD5 and N=160 for HMAC-SHA1. The length of MSK MUST be N-bit or longer. See Section 4.1.6 for the JARI: (Editorial) s/N-bit/N bits/ OHBA: OK. --------- imply the PAA being stateful? Most often the initial EAP request is an identity request, which has just one potentially changing field, the EAP level sequence number. However, this sequence number could presumably be the same random number for all clients connecting around the same time, since the PANA sessions, if they are established, are identified by the device identifiers. peer or EAP (pass-through) authenticator." JARI: (Editorial) Extra quote at the end. OHBA: OK, I'll remove it. -- The reason for termination is indicated in the Termination-Cause AVP. When there is an established PANA SA established between the PaC and the PAA, all messages exchanged during the termination phase MUST be protected with a MAC AVP. When the sender of the PANA- JARI: (Comment) Great, so this is better than 802.11i! OHBA: Yes!! And PANA with bootstrapping WPA/IEEE 802.11i PSK mode can improve wireless LAN security. You may be interested in pana-framework draft which will be submitted in a couple of days (there is a PANA WLAN example in the draft). -- 4.12 PaC Implications o PaC state machine. [TBD] 4.13 PAA Implications o PAA state machine. [TBD] JARI: (Comment) Experience from EAP indicates that protocol should not be considered complete until the state machine exists. OHBA: I agree, and we are working on it now. -- PANA relies on EAP and the EAP methods to provide a session key in order to establish a PANA security association. An example of such a method is EAP-TLS [RFC2716], whereas EAP-MD5 [RFC2284] is an example of a method that cannot create such keying material. The choice of EAP method becomes important, as already discussed in the next section. JARI: (Editorial) s/already// OHBA: OK. -- encryption of IP packets. Fresh and unique session key derived from the EAP method is still insufficient to produce an IPsec SA since both traffic selectors and other IPsec SA parameters are missing. The shared secret can be used in conjunction with a key management protocol like IKE [RFC2409] to turn a simple shared secret into the required IPsec SA. The details of this mechanism is outside the scope of PANA protocol [I-D.ietf-pana-ipsec], PANA provides bootstrapping functionality for such a mechanism by carrying EAP methods that can generate initial keying material. JARI: (Editorial) I think the last sentence would be clearer as "The details of such mechanisms are outside the scope of this document and can be found in [I-D.ietf-pana-ipsec]." OHBA: Yes, that is clearer. I'll change the sentence as such. ------- Using network-layer ciphers should be regarded as a substitute for link-layer ciphers when the latter is not available. IKE involves several message exchanges which can incur additional delay in getting basic IP connectivity for a mobile device. Such a latency is JARI: (Comment) And additional header overhead. OHBA: OK, I'll modify the sentence to: "IKE involves several message exchanges which can incur additional delay and header overhead in getting basic IP connectivity for a mobile device." -- the EAP method allows session key derivation and that the generated session key has a good quality. For further discussion about the importance of the session key generation refer to the next subsection (d) about compound authentication. The session key available for the PaC is established as part of the authentication and key exchange procedure of the selected EAP method. The PAA obtains the session key via the AAA infrastructure (if used). Security issues raised with this session key transport are described in [I-D.walker-aaa-key-distribution]. JARI: (Editorial) And draft-ietf-eap-keying? OHBA: Yes, it should be draft-ietf-eap-keying. -- g) Liveness test Network access authentication is done for a very specific purpose and often charging procedures are involved which allow restricting network resource usage based on some policies. In mobility JARI: (Editorial) s/mobility/mobile/ OHBA: OK. ---- [I-D.ietf-pana-requirements] Yegin, A. and Y. Ohba, "Protocol for Carrying Authentication for Network Access (PANA)Requirements", draft-ietf-pana-requirements-07 (work in progress), June 2003. JARI: (Editorial) If you move a couple of terms to this draft, you can make this reference informational. OHBA: I'll move it to the informative references section. ---- [I-D.ietf-aaa-eap] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", draft-ietf-aaa-eap-03 (work in progress), October 2003. JARI: (Editorial) Strictly speaking, why is this normative? I don't think you require the backend AAA protocol to be Diameter, it could be RADIUS too, right? Are you copying AVPs or what? OHBA: You are right. Dimemeter EAP application is not mandatory for PANA to work. I'll move it to the informative references section. [I-D.irtf-aaaarch-handoff] Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to RADIUS", draft-irtf-aaaarch-handoff-03 (work in progress), October 2003. [I-D.orman-public-key-lengths] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", draft-orman-public-key-lengths-05 (work in progress), January 2002. [I-D.puthenkulam-eap-binding] Puthenkulam, J., "The Compound Authentication Binding Problem", draft-puthenkulam-eap-binding-04 (work in progress), October 2003. JARI: (Editorial) I wonder if the above three are really informative. OHBA: I agree. The three references should be informative. I'll move them to informative references section. Best regards, Yoshihiro Ohba (Editor) _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Feb 4 21:13: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 VAA13493 for ; Wed, 4 Feb 2004 21:13: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 1AoZ0P-0000B6-48 for pana-archive@odin.ietf.org; Wed, 04 Feb 2004 21:12:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i152CbIS000683 for pana-archive@odin.ietf.org; Wed, 4 Feb 2004 21:12:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoZ0O-0000Av-To for pana-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 21:12: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 VAA13487 for ; Wed, 4 Feb 2004 21:12:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoZ0M-0007UH-00 for pana-web-archive@ietf.org; Wed, 04 Feb 2004 21:12:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoYzU-0007PM-00 for pana-web-archive@ietf.org; Wed, 04 Feb 2004 21:11:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoYyt-0007Jy-00 for pana-web-archive@ietf.org; Wed, 04 Feb 2004 21:11:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoYyr-00005V-Fv; Wed, 04 Feb 2004 21:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoYyT-0008Vq-Vw for pana@optimus.ietf.org; Wed, 04 Feb 2004 21:10:38 -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 VAA13403 for ; Wed, 4 Feb 2004 21:10:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoYyR-0007IH-00 for pana@ietf.org; Wed, 04 Feb 2004 21:10:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoYxW-0007CI-00 for pana@ietf.org; Wed, 04 Feb 2004 21:09:40 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AoYwd-000761-00 for pana@ietf.org; Wed, 04 Feb 2004 21:08:43 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1528aN9029312; Thu, 5 Feb 2004 11:08:36 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1528auJ009657; Thu, 5 Feb 2004 11:08:36 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id MAA09656 ; Thu, 5 Feb 2004 11:08:36 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id LAA20562; Thu, 5 Feb 2004 11:08:35 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id LAA06494; Thu, 5 Feb 2004 11:08:26 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1528ONT014425; Thu, 5 Feb 2004 11:08:25 +0900 (JST) Received: from steelhead ([159.119.168.123]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSL004VG9XY5U@tsbpo1.po.toshiba.co.jp>; Thu, 5 Feb 2004 11:08:24 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AoYvs-0004YN-00; Wed, 04 Feb 2004 18:07:56 -0800 Date: Wed, 04 Feb 2004 18:07:56 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] review of the pana protocol In-reply-to: <4020BA4D.1010905@piuha.net> To: Jari Arkko Cc: pana@ietf.org Message-id: <20040205020756.GQ12173@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Jari Arkko , pana@ietf.org User-Agent: Mutt/1.5.4i References: <4020BA4D.1010905@piuha.net> 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 Thanks Jari for your detailed review. I first try to resolve Editorial issues first, so that the editorial changes are quickly reflected to the upcoming -03 draft. Your 18 editorial comments (as well as 3 "Comment" comments) are all valid. I have one question to Jari on the definition of MSK (please see my comments below). ------- Currently there is no standard network-layer solution for authenticating clients for network access. [I-D.ietf-pana-usage-scenarios] describes the problem statement that led to the development of PANA. Scope of this working group is identified as designing a link-layer JARI: (Editorial) s/working group/work/? OHBA: OK. ----- agnostic transport for network access authentication methods. PANA Working Group has identified EAP [RFC2284] as the payload for this protocol and carrier for authentication methods. JARI: (Editorial) Maybe replace with "The Extensible Authentication Protocol (EAP) [RFC2284bis] provides such authentication methods." OHBA: OK. ---- Various environments and usage models for PANA are identified in the [I-D.ietf-pana-usage-scenarios] Internet-Draft. Potential security threats for network-layer access authentication protocol is discussed JARI: (Editorial) s/is/are/ OHBA: OK. ----- This Internet-Draft makes an attempt for defining the PANA protocol based on the other drafts discussed above. Special care has been given to ensure the currently stated scope is observed and to keep the protocol as simple as possible. The current state of this draft is not complete, but it should be regarded as a work in progress. The authors made effort to capture the common understanding developed within the working group as much as possible. The design choices being made in this draft should not be considered as cast in stone. JARI: (Editorial) Yes, but this is assumed for I-Ds anyway. You could probably remove the paragraph. OHBA: I agree. Let's remove it. ------- The definition of the terms PANA Client (PaC), PANA Authentication Agent (PAA), Enforcement Point (EP) and Device Identifier (DI) can be found in [I-D.ietf-pana-requirements]. JARI: (Editorial) If its just 4 definitions, I would prefer them to be copied here too. OHBA: Yes, it is better. So I would replace the above paragraph with the following text (copied from [I-D.ietf-pana-requirements]): " PANA Client (PaC) The client side of the protocol that resides in the host device which is responsible for providing the credentials to prove its identity for network access authorization. Device Identifier (DI) The identifier used by the network as a handle to control and police the network access of a client. Depending on the access technology, this identifier might contain any of IP address, link-layer address, switch port number, etc. of a connected device. PANA Authentication Agent (PAA) The access network side entity of the protocol whose responsibility is to verify the credentials provided by a PANA client and grant network access service to the device associated with the client and identified by a DI. Enforcement Point (EP) A node on the access network where per-packet enforcement policies (i.e., filters) are applied on the inbound and outbound traffic of client devices. Information such as DI and (optionally) cryptographic keys are provided by PAA per client for constructing filters on the EP. " OHBA: Also, I will add the following definitions here to reflect your other comments: Network Access Provider (NAP) A service provider that provides physical and link-layer connectivity to an access network it manages. 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. ------- 3. Protocol Overview The PANA protocol involves two functional entities namely the PaC and the PAA. The EP, mentioned in the context with PANA, is a logical entity. There is, however, the option that the EP is not physically co-located with the PAA. In case that the PAA and the EP are co-located only an API is required for intercommunication instead of a separate protocol. In the case where the PAA is separated from the EP, a separate protocol will be used between the PAA and the EP for managing access control. The protocol and messaging between the PAA and EP for access authorization is outside the scope of this draft and will be dealt separately. JARI: (Editorial) For the clarity of presentation, maybe you should talk about the EP case later, and not start with it. OHBA: I agree. How about re-arranging the contents of section 3 like: " 3. Protocol Overview The PANA protocol involves two functional entities namely the PaC and the PAA. The protocol resides above the transport layer and the details are explained in Section 4. The placement of the entities used in PANA largely depends on a certain architecture. The PAA may optionally interact with a AAA backend to authenticate the user (PaC). The EP, mentioned in the context with PANA, is a logical entity. There is, however, the option that the EP is not physically co-located with the PAA. In case that the PAA and the EP are co-located only an API is required for intercommunication instead of a separate protocol. In the case where the PAA is separated from the EP, a separate protocol will be used between the PAA and the EP for managing access control. The protocol and messaging between the PAA and EP for access authorization is outside the scope of this draft and will be dealt separately. Figure 1 illustrates the interactions in a simplified manner: PaC EP PAA AAA --- --- --- --- PAA Discovery <---------------------o------------> (1) PANA Authentication AAA interaction <----------------------------------><------------> (2) Authorization <------------- (3) Figure 1: PANA Framework (End of Section 3) ------ o Session-Id AVP: contains the session identifier value. o Session-Lifetime AVP: contains the duration of authorized access. o Failed-AVP: contains the offending AVP that caused a failure. o NAP-Information AVP, ISP-Information AVP: contains the information on a NAP and an ISP, respectively. JARI: (Editorial) NAP term not yet defined. Add to defs section. OHBA: OK. o Key-Id AVP: contains an MSK identifier. JARI: (Editorial) MSK not yet defined. Add to defs section. OHBA: OK. ----- unicast. PaC MAY use unspecified IP address for communicating with PAA. JARI: (Comment) I think I have said it in the past that I have reservations about the use of the unspecified address. But I forget what the resolution of this was. Reading on... OHBA: The use of unspecified address will be removed in -03. ------ PANA_MAC_KEY = The first N-bit of HMAC_SHA1(MSK, ISN_pac | ISN_paa | Session-ID) JARI: (Editorial) s/N-bit/N bits/ OHBA: OK. ------ where the value of N depends on the integrity protection algorithm in use, i.e., N=128 for HMAC-MD5 and N=160 for HMAC-SHA1. The length of MSK MUST be N-bit or longer. See Section 4.1.6 for the JARI: (Editorial) s/N-bit/N bits/ OHBA: OK. --------- imply the PAA being stateful? Most often the initial EAP request is an identity request, which has just one potentially changing field, the EAP level sequence number. However, this sequence number could presumably be the same random number for all clients connecting around the same time, since the PANA sessions, if they are established, are identified by the device identifiers. peer or EAP (pass-through) authenticator." JARI: (Editorial) Extra quote at the end. OHBA: OK, I'll remove it. -- The reason for termination is indicated in the Termination-Cause AVP. When there is an established PANA SA established between the PaC and the PAA, all messages exchanged during the termination phase MUST be protected with a MAC AVP. When the sender of the PANA- JARI: (Comment) Great, so this is better than 802.11i! OHBA: Yes!! And PANA with bootstrapping WPA/IEEE 802.11i PSK mode can improve wireless LAN security. You may be interested in pana-framework draft which will be submitted in a couple of days (there is a PANA WLAN example in the draft). -- 4.12 PaC Implications o PaC state machine. [TBD] 4.13 PAA Implications o PAA state machine. [TBD] JARI: (Comment) Experience from EAP indicates that protocol should not be considered complete until the state machine exists. OHBA: I agree, and we are working on it now. -- PANA relies on EAP and the EAP methods to provide a session key in order to establish a PANA security association. An example of such a method is EAP-TLS [RFC2716], whereas EAP-MD5 [RFC2284] is an example of a method that cannot create such keying material. The choice of EAP method becomes important, as already discussed in the next section. JARI: (Editorial) s/already// OHBA: OK. -- encryption of IP packets. Fresh and unique session key derived from the EAP method is still insufficient to produce an IPsec SA since both traffic selectors and other IPsec SA parameters are missing. The shared secret can be used in conjunction with a key management protocol like IKE [RFC2409] to turn a simple shared secret into the required IPsec SA. The details of this mechanism is outside the scope of PANA protocol [I-D.ietf-pana-ipsec], PANA provides bootstrapping functionality for such a mechanism by carrying EAP methods that can generate initial keying material. JARI: (Editorial) I think the last sentence would be clearer as "The details of such mechanisms are outside the scope of this document and can be found in [I-D.ietf-pana-ipsec]." OHBA: Yes, that is clearer. I'll change the sentence as such. ------- Using network-layer ciphers should be regarded as a substitute for link-layer ciphers when the latter is not available. IKE involves several message exchanges which can incur additional delay in getting basic IP connectivity for a mobile device. Such a latency is JARI: (Comment) And additional header overhead. OHBA: OK, I'll modify the sentence to: "IKE involves several message exchanges which can incur additional delay and header overhead in getting basic IP connectivity for a mobile device." -- the EAP method allows session key derivation and that the generated session key has a good quality. For further discussion about the importance of the session key generation refer to the next subsection (d) about compound authentication. The session key available for the PaC is established as part of the authentication and key exchange procedure of the selected EAP method. The PAA obtains the session key via the AAA infrastructure (if used). Security issues raised with this session key transport are described in [I-D.walker-aaa-key-distribution]. JARI: (Editorial) And draft-ietf-eap-keying? OHBA: Yes, it should be draft-ietf-eap-keying. -- g) Liveness test Network access authentication is done for a very specific purpose and often charging procedures are involved which allow restricting network resource usage based on some policies. In mobility JARI: (Editorial) s/mobility/mobile/ OHBA: OK. ---- [I-D.ietf-pana-requirements] Yegin, A. and Y. Ohba, "Protocol for Carrying Authentication for Network Access (PANA)Requirements", draft-ietf-pana-requirements-07 (work in progress), June 2003. JARI: (Editorial) If you move a couple of terms to this draft, you can make this reference informational. OHBA: I'll move it to the informative references section. ---- [I-D.ietf-aaa-eap] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", draft-ietf-aaa-eap-03 (work in progress), October 2003. JARI: (Editorial) Strictly speaking, why is this normative? I don't think you require the backend AAA protocol to be Diameter, it could be RADIUS too, right? Are you copying AVPs or what? OHBA: You are right. Dimemeter EAP application is not mandatory for PANA to work. I'll move it to the informative references section. [I-D.irtf-aaaarch-handoff] Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to RADIUS", draft-irtf-aaaarch-handoff-03 (work in progress), October 2003. [I-D.orman-public-key-lengths] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", draft-orman-public-key-lengths-05 (work in progress), January 2002. [I-D.puthenkulam-eap-binding] Puthenkulam, J., "The Compound Authentication Binding Problem", draft-puthenkulam-eap-binding-04 (work in progress), October 2003. JARI: (Editorial) I wonder if the above three are really informative. OHBA: I agree. The three references should be informative. I'll move them to informative references section. Best regards, Yoshihiro Ohba (Editor) _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 5 03:28: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 DAA06850 for ; Thu, 5 Feb 2004 03:28: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 1Aoeri-0001in-9v; Thu, 05 Feb 2004 03:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoerT-0001i7-7D for pana@optimus.ietf.org; Thu, 05 Feb 2004 03:27: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 DAA06822 for ; Thu, 5 Feb 2004 03:27:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoerQ-0002Py-00 for pana@ietf.org; Thu, 05 Feb 2004 03:27:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoeqT-0002Gy-00 for pana@ietf.org; Thu, 05 Feb 2004 03:26:46 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AoepZ-0002AJ-00 for pana@ietf.org; Thu, 05 Feb 2004 03:25:49 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i158PoZ27914; Thu, 5 Feb 2004 09:25:50 +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 i158Pnw16579; Thu, 5 Feb 2004 09:25:49 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 5 Feb 2004 09:25:15 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC069B@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Alper Yegin'" , jari.arkko@piuha.net, pana@ietf.org Subject: RE: [Pana] review of the pana protocol Date: Thu, 5 Feb 2004 09:25:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" 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 alper, hi jari, thanks for your comments jari. just a quick comment: ~snip~snip > > - "Cookie mandatory" > > > > I would like the inclusion of the cookie to in the start > > exchange to be mandatory. > > > > - "Client cookie useful?" > > > > Would it be useful for the client to provide its own > cookie as > > well, such that for solicited PSRs, the client's cookie would > > be copied back. This would cost very little, but protect the > > client against blind PAA spoofing attempts. > > OK, we shall open an issue and track this. alper, i have written a detailed text for this some time ago. we might want to look at it again. i don't know why we "dropped" it. the text which is used that time as input can be found in Section 16.1 of http://www.tschofenig.com/drafts/draft-schulzrinne-nsis-casp-00.pdf (Scout is a discovery mechanism.) maybe we can find the original text. ciao hannes _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 5 03:30: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 DAA06908 for ; Thu, 5 Feb 2004 03:30: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 1AoetU-0001sW-Ib for pana-archive@odin.ietf.org; Thu, 05 Feb 2004 03:29:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i158Tqhs007221 for pana-archive@odin.ietf.org; Thu, 5 Feb 2004 03:29:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoetU-0001sO-1w for pana-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 03:29: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 DAA06876 for ; Thu, 5 Feb 2004 03:29:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoetR-0002g2-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 03:29:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoesW-0002ZF-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 03:28:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aoerl-0002SY-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 03:28:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoeri-0001in-9v; Thu, 05 Feb 2004 03:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoerT-0001i7-7D for pana@optimus.ietf.org; Thu, 05 Feb 2004 03:27: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 DAA06822 for ; Thu, 5 Feb 2004 03:27:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoerQ-0002Py-00 for pana@ietf.org; Thu, 05 Feb 2004 03:27:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoeqT-0002Gy-00 for pana@ietf.org; Thu, 05 Feb 2004 03:26:46 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AoepZ-0002AJ-00 for pana@ietf.org; Thu, 05 Feb 2004 03:25:49 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i158PoZ27914; Thu, 5 Feb 2004 09:25:50 +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 i158Pnw16579; Thu, 5 Feb 2004 09:25:49 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 5 Feb 2004 09:25:15 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC069B@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Alper Yegin'" , jari.arkko@piuha.net, pana@ietf.org Subject: RE: [Pana] review of the pana protocol Date: Thu, 5 Feb 2004 09:25:33 +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 alper, hi jari, thanks for your comments jari. just a quick comment: ~snip~snip > > - "Cookie mandatory" > > > > I would like the inclusion of the cookie to in the start > > exchange to be mandatory. > > > > - "Client cookie useful?" > > > > Would it be useful for the client to provide its own > cookie as > > well, such that for solicited PSRs, the client's cookie would > > be copied back. This would cost very little, but protect the > > client against blind PAA spoofing attempts. > > OK, we shall open an issue and track this. alper, i have written a detailed text for this some time ago. we might want to look at it again. i don't know why we "dropped" it. the text which is used that time as input can be found in Section 16.1 of http://www.tschofenig.com/drafts/draft-schulzrinne-nsis-casp-00.pdf (Scout is a discovery mechanism.) maybe we can find the original text. ciao hannes _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 5 03:39: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 DAA07205 for ; Thu, 5 Feb 2004 03:39: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 1Aof2M-0002c9-Dw; Thu, 05 Feb 2004 03:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aof29-0002aD-Ez for pana@optimus.ietf.org; Thu, 05 Feb 2004 03:38: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 DAA07202 for ; Thu, 5 Feb 2004 03:38:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aof27-0003VM-00 for pana@ietf.org; Thu, 05 Feb 2004 03:38:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aof1B-0003QS-00 for pana@ietf.org; Thu, 05 Feb 2004 03:37:49 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Aof0i-0003LU-00 for pana@ietf.org; Thu, 05 Feb 2004 03:37:20 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 26B556A907; Thu, 5 Feb 2004 10:37:15 +0200 (EET) Message-ID: <4022005A.9090503@piuha.net> Date: Thu, 05 Feb 2004 10:35: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: Yoshihiro Ohba Cc: pana@ietf.org Subject: Re: [Pana] review of the pana protocol References: <4020BA4D.1010905@piuha.net> <20040205020756.GQ12173@steelhead> In-Reply-To: <20040205020756.GQ12173@steelhead> Content-Type: text/plain; charset=us-ascii 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.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 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. > JARI: (Editorial) For the clarity of presentation, maybe you should > talk about the EP case later, and not start with it. > > OHBA: I agree. How about re-arranging the contents of section 3 like: Looks good, thanks. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 5 03:41: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 DAA07286 for ; Thu, 5 Feb 2004 03:41: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 1Aof47-0002lr-U0 for pana-archive@odin.ietf.org; Thu, 05 Feb 2004 03:40:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i158epek010648 for pana-archive@odin.ietf.org; Thu, 5 Feb 2004 03:40:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aof47-0002lf-FU for pana-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 03:40: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 DAA07263 for ; Thu, 5 Feb 2004 03:40:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aof45-0003iM-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 03:40:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aof3G-0003cP-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 03:39:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aof2N-0003Wa-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 03:39:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aof2M-0002c9-Dw; Thu, 05 Feb 2004 03:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aof29-0002aD-Ez for pana@optimus.ietf.org; Thu, 05 Feb 2004 03:38: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 DAA07202 for ; Thu, 5 Feb 2004 03:38:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aof27-0003VM-00 for pana@ietf.org; Thu, 05 Feb 2004 03:38:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aof1B-0003QS-00 for pana@ietf.org; Thu, 05 Feb 2004 03:37:49 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Aof0i-0003LU-00 for pana@ietf.org; Thu, 05 Feb 2004 03:37:20 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 26B556A907; Thu, 5 Feb 2004 10:37:15 +0200 (EET) Message-ID: <4022005A.9090503@piuha.net> Date: Thu, 05 Feb 2004 10:35: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: Yoshihiro Ohba Cc: pana@ietf.org Subject: Re: [Pana] review of the pana protocol References: <4020BA4D.1010905@piuha.net> <20040205020756.GQ12173@steelhead> In-Reply-To: <20040205020756.GQ12173@steelhead> 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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. > JARI: (Editorial) For the clarity of presentation, maybe you should > talk about the EP case later, and not start with it. > > OHBA: I agree. How about re-arranging the contents of section 3 like: Looks good, thanks. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 5 04:42: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 EAA08674 for ; Thu, 5 Feb 2004 04:42: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 1Aog1J-0006Pd-2c; Thu, 05 Feb 2004 04:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog1A-0006PB-NR for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:41: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 EAA08666 for ; Thu, 5 Feb 2004 04:41:50 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog17-0001Gz-00 for pana@ietf.org; Thu, 05 Feb 2004 04:41:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog0E-0001CE-00 for pana@ietf.org; Thu, 05 Feb 2004 04:40:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Aofzu-00016o-00 for pana@ietf.org; Thu, 05 Feb 2004 04:40:34 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i159eY218075 for ; Thu, 5 Feb 2004 11:40:34 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:40:33 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:40: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: Thu, 5 Feb 2004 11:40:32 +0200 Message-ID: Thread-Topic: [issue53] Additional discovery information Thread-Index: AcPrysCidwcoz32PRQOJbSLrsaO/swAAU5aw To: X-OriginalArrivalTime: 05 Feb 2004 09:40:32.0872 (UTC) FILETIME=[1969B680:01C3EBCC] 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 [issue53] Additional discovery information 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQo+IEphcmkgQXJra286DQo+ICAgICAgLSAiQWRkaXRpb25hbCBkaXNjb3ZlcnkgaW5mb3Jt YXRpb24/Ig0KPiAgICAgICAgSSdtIG5vdCBzdXJlIGlmIHRoZXJlIGlzIGEgbmVlZCB0byBwcm92 aWRlIHNvbWUgYWRkaXRpb25hbA0KPiAgICAgICAgaW5mb3JtYXRpb24gaW4gdGhlIGRpc2NvdmVy eSBwaGFzZS4gRm9yIGluc3RhbmNlLCBpcyB0aGVyZSBhDQo+ICAgICAgICBuZWVkIHRvIGlkZW50 aWZ5IHRoZSBOQVMvUEFBIGluIGEgc2NlbmFyaW8gd2hlcmUgdGhlIE5BUy9QQUENCj4gICAgICAg IGhhcyBtdWx0aXBsZSBpbnRlcmZhY2VzIGFuZCBtdWx0aXBsZSBhZGRyZXNzZXM/IEtub3dpbmcg eW91DQo+IGFyZSBzdGlsbCBjb25uZWN0ZWQgdG8gdGhlIHNhbWUgTkFTIG1pZ2h0IGhlbHAgZnV0 dXJlIGhhbmRvZmYNCj4gZGVzaWducy4NCg0KQWxwZXIgWWVnaW46DQpUaGlzIHNvdW5kcyBsaWtl IGEgdXNlZnVsIGZlYXR1cmUuIEknZCByZWNvbW1lbmQgd2Ugb3BlbiBhbiBpc3N1ZSBhbmQNCmlu dmVzdGlnYXRlIHRoaXMuIEl0IGNhbiBhc3Npc3QgbW92ZW1lbnQgZGV0ZWN0aW9uLg0KDQotLS0t LS0tLS0tDQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBh bmEteHgudHh0DQptZXNzYWdlczogMTkyDQpub3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IE1heSBG aXgNCnN0YXR1czogUGVuZGluZw0KdGl0bGU6IEFkZGl0aW9uYWwgZGlzY292ZXJ5IGluZm9ybWF0 aW9uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K UEFOQSBJc3N1ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmluZm8+DQo8aHR0cDovL2RhbmZv cnNiZXJnLmluZm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTUzPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 5 04:43: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 EAA08706 for ; Thu, 5 Feb 2004 04:43: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 1Aog2H-0006TW-K7; Thu, 05 Feb 2004 04: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 1Aog24-0006T1-6G for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:42: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 EAA08692 for ; Thu, 5 Feb 2004 04:42:45 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog21-0001Lo-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog15-0001Ge-00 for pana@ietf.org; Thu, 05 Feb 2004 04:41:47 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Aog0C-0001Bi-00 for pana@ietf.org; Thu, 05 Feb 2004 04:40:52 -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 i159eqM27562 for ; Thu, 5 Feb 2004 11:40:52 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:40:52 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:40:51 +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: Thu, 5 Feb 2004 11:40:50 +0200 Message-ID: Thread-Topic: [issue52] Details of double authentication Thread-Index: AcPrytVhLpG0IJaPRwKrSyzQLwqLgQAAUbLw To: X-OriginalArrivalTime: 05 Feb 2004 09:40:51.0228 (UTC) FILETIME=[245A9DC0:01C3EBCC] 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: [issue52] Details of double authentication 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 RGFuIEZvcnNiZXJnIDxkYW4uZm9yc2JlcmdAbm9raWEuY29tPiBhZGRlZCB0aGUgY29tbWVudDoN Cg0KPkphcmkgQXJra28gd3JvdGU6DQo+ICAgICAgLSAiRGV0YWlscyBvZiBkb3VibGUgYXV0aGVu dGljYXRpb24iDQo+IA0KPiAgICAgICAgUGVyaGFwcyBpdHMganVzdCBtZSwgYnV0IEkgZGlkIG5v dCBmaW5kIGFsbCB0aGUgZGV0YWlscw0KPiAgICAgICAgcmVnYXJkaW5nIHRoZSB1c2Ugb2YgdHdv IChOQVAgYW5kIElTUCkgYXV0aGVudGljYXRpb25zLiBJcw0KPiAgICAgICAgdGhpcyBzdXBwb3J0 ZWQgb3Igbm90PyBBcmUgdGhleSBwZXJmb3JtZWQgaW4gc2VxdWVuY2U/IERvZXMgaXQNCj4gICAg ICAgIGxvb2sgbGlrZSBhIHJlLWF1dGhlbnRpY2F0aW9uLCBvciBkbyB5b3UgcHJvdmlkZSBhIGJp dA0KPiAgICAgICAgc29tZXdoZXJlIHRoYXQgaW5kaWNhdGVzIHdoZXRoZXIgdGhpcyBFQVAgcnVu IHJlbGF0ZXMgdG8gdGhlDQo+ICAgICAgICBOQVAgb3IgdGhlIElTUCBhdXRoZW50aWNhdGlvbj8g SXMgdGhlcmUgYSBQQU5BIEJpbmQgUmVxdWVzdCAtDQo+ICAgICAgICBBbnN3ZXIgcGFpciBpbiBi ZXR3ZWVuIG9yIG5vdD8NCg0KQWxwZXIgWWVnaW46DQpUaGlzIHNheXMgdGhlIHRleHQgaXMgbm90 IHN1ZmZpY2llbnQuIFdlIHNoYWxsIG9wZW4gYW4gaXNzdWUgb24gdGhpcyBhbmQgdHJ5DQp0byBj bGVhcmx5IGFuc3dlciB5b3VyIHF1ZXN0aW9ucy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpQQU5BIElzc3VlcyA8cGFuYV9pc3N1ZXNAZGFuZm9y c2JlcmcuaW5mbz4NCjxodHRwOi8vZGFuZm9yc2JlcmcuaW5mbzo4MDgwL3BhbmEtaXNzdWVzL2lz c3VlNTI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0K _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 5 04:43: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 EAA08723 for ; Thu, 5 Feb 2004 04:43: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 1Aog2I-0006UA-EV; Thu, 05 Feb 2004 04:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog26-0006TC-3n for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:42: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 EAA08698 for ; Thu, 5 Feb 2004 04:42:47 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog23-0001M6-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog18-0001HD-00 for pana@ietf.org; Thu, 05 Feb 2004 04:41:51 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Aog0S-0001CN-00 for pana@ietf.org; Thu, 05 Feb 2004 04:41:08 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i159f9218981 for ; Thu, 5 Feb 2004 11:41:09 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:41:08 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:41:08 +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: Thu, 5 Feb 2004 11:41:07 +0200 Message-ID: Thread-Topic: [issue54] Client cookie mandatory Thread-Index: AcPryw+73lFV48DcRICZIQc84fGdugAARZtw To: X-OriginalArrivalTime: 05 Feb 2004 09:41:08.0352 (UTC) FILETIME=[2E8F8800:01C3EBCC] 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: [issue54] Client cookie mandatory 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIEphcmkgQXJra286DQo+ICAgICAgLSAiQ29va2llIG1hbmRhdG9yeSINCj4gDQo+ ICAgICAgICBJIHdvdWxkIGxpa2UgdGhlIGluY2x1c2lvbiBvZiB0aGUgY29va2llIHRvIGluIHRo ZSBzdGFydA0KPiAgICAgICAgZXhjaGFuZ2UgdG8gYmUgbWFuZGF0b3J5Lg0KDQotLS0tLS0tLS0t DQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBhbmEteHgu dHh0DQptZXNzYWdlczogMTk0DQpub3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IFNob3VsZCBGaXgN CnN0YXR1czogUGVuZGluZw0KdGl0bGU6IENsaWVudCBjb29raWUgbWFuZGF0b3J5DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUEFOQSBJc3N1ZXMg PHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmluZm8+DQo8aHR0cDovL2RhbmZvcnNiZXJnLmluZm86 ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTU0Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 5 04:43: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 EAA08740 for ; Thu, 5 Feb 2004 04:43: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 1Aog2K-0006Yu-6C; Thu, 05 Feb 2004 04:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog2C-0006TI-Jt for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:42: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 EAA08701 for ; Thu, 5 Feb 2004 04:42:54 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog29-0001MH-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog19-0001HT-00 for pana@ietf.org; Thu, 05 Feb 2004 04:41:52 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Aog0y-0001CS-00 for pana@ietf.org; Thu, 05 Feb 2004 04:41:40 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i159fe219857 for ; Thu, 5 Feb 2004 11:41:40 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:41:40 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:41:39 +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: Thu, 5 Feb 2004 11:41:38 +0200 Message-ID: Thread-Topic: [issue56] AAA routing based on NAI vs. ISP choice clarification Thread-Index: AcPry0FuwiftffNZTBmc/KKN89nwiAAAPgRw To: X-OriginalArrivalTime: 05 Feb 2004 09:41:39.0923 (UTC) FILETIME=[4160E230:01C3EBCC] 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: [issue56] AAA routing based on NAI vs. ISP choice clarification 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIEphcmkgQXJra286DQo+ICAgICAgLSAiQUFBIHJvdXRpbmcgYmFzZWQgb24gTkFJ IHZzLiBJU1AgY2hvaWNlIg0KPiANCj4gICAgICAgIFNlY3Rpb24gNC4yIGNsYWltcyB0aGF0IEFB QSByb3V0aW5nIGlzIGJhc2VkIG9uIHRoZSBJU1ANCj4gICAgICAgIGNob2ljZS4gIEkgYmVsaWV2 ZSB0aGUgZmlyc3QgaG9wIGRlY2lzaW9uIGNhbiBiZSBiYXNlZCBvbg0KPiAgICAgICAgdGhpcywg YnV0IGZ1cnRoZXIgb24gaW4gdGhlIG5ldHdvcmsgaXQgbXVzdCBiZSBiYXNlZCBvbiB0aGUNCj4g ICAgICAgIE5BSSAodW5sZXNzIHlvdSByZXZpc2UgQUFBIHByb3RvY29scykuDQoNCkFscGVyIFll Z2luOg0KQW5vdGhlciBpc3N1ZSB0byBvcGVuIChhdCBsZWFzdCB0byBjbGFyaWZ5IHRoZSB0ZXh0 KS4NCg0KLS0tLS0tLS0tLQ0KY2F0ZWdvcnk6IEVkaXRvcmlhbA0KZG9jdW1lbnQ6IGRyYWZ0LWll dGYtcGFuYS1wYW5hLXh4LnR4dA0KbWVzc2FnZXM6IDE5Ng0Kbm9zeTogZGZvcnNiZXINCnByaW9y aXR5OiBNdXN0IEZpeA0Kc3RhdHVzOiBQZW5kaW5nDQp0aXRsZTogQUFBIHJvdXRpbmcgYmFzZWQg b24gTkFJIHZzLiBJU1AgY2hvaWNlIGNsYXJpZmljYXRpb24NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQQU5BIElzc3VlcyA8cGFuYV9pc3N1ZXNA ZGFuZm9yc2JlcmcuaW5mbz4NCjxodHRwOi8vZGFuZm9yc2JlcmcuaW5mbzo4MDgwL3BhbmEtaXNz dWVzL2lzc3VlNTY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0K _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 5 04:44:19 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 EAA08785 for ; Thu, 5 Feb 2004 04:44:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog35-0006ct-Fg for pana-archive@odin.ietf.org; Thu, 05 Feb 2004 04:43:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i159hpDA025467 for pana-archive@odin.ietf.org; Thu, 5 Feb 2004 04:43:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog33-0006cg-N6 for pana-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 04:43: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 EAA08763 for ; Thu, 5 Feb 2004 04:43:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog30-0001Ry-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:43:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog29-0001MM-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:42:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aog1J-0001Ha-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog1J-0006Pd-2c; Thu, 05 Feb 2004 04:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog1A-0006PB-NR for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:41: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 EAA08666 for ; Thu, 5 Feb 2004 04:41:50 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog17-0001Gz-00 for pana@ietf.org; Thu, 05 Feb 2004 04:41:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog0E-0001CE-00 for pana@ietf.org; Thu, 05 Feb 2004 04:40:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Aofzu-00016o-00 for pana@ietf.org; Thu, 05 Feb 2004 04:40:34 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i159eY218075 for ; Thu, 5 Feb 2004 11:40:34 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:40:33 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:40: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: Thu, 5 Feb 2004 11:40:32 +0200 Message-ID: Thread-Topic: [issue53] Additional discovery information Thread-Index: AcPrysCidwcoz32PRQOJbSLrsaO/swAAU5aw To: X-OriginalArrivalTime: 05 Feb 2004 09:40:32.0872 (UTC) FILETIME=[1969B680:01C3EBCC] Content-Transfer-Encoding: base64 Subject: [Pana] NEW [issue53] Additional discovery information 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQo+IEphcmkgQXJra286DQo+ICAgICAgLSAiQWRkaXRpb25hbCBkaXNjb3ZlcnkgaW5mb3Jt YXRpb24/Ig0KPiAgICAgICAgSSdtIG5vdCBzdXJlIGlmIHRoZXJlIGlzIGEgbmVlZCB0byBwcm92 aWRlIHNvbWUgYWRkaXRpb25hbA0KPiAgICAgICAgaW5mb3JtYXRpb24gaW4gdGhlIGRpc2NvdmVy eSBwaGFzZS4gRm9yIGluc3RhbmNlLCBpcyB0aGVyZSBhDQo+ICAgICAgICBuZWVkIHRvIGlkZW50 aWZ5IHRoZSBOQVMvUEFBIGluIGEgc2NlbmFyaW8gd2hlcmUgdGhlIE5BUy9QQUENCj4gICAgICAg IGhhcyBtdWx0aXBsZSBpbnRlcmZhY2VzIGFuZCBtdWx0aXBsZSBhZGRyZXNzZXM/IEtub3dpbmcg eW91DQo+IGFyZSBzdGlsbCBjb25uZWN0ZWQgdG8gdGhlIHNhbWUgTkFTIG1pZ2h0IGhlbHAgZnV0 dXJlIGhhbmRvZmYNCj4gZGVzaWducy4NCg0KQWxwZXIgWWVnaW46DQpUaGlzIHNvdW5kcyBsaWtl IGEgdXNlZnVsIGZlYXR1cmUuIEknZCByZWNvbW1lbmQgd2Ugb3BlbiBhbiBpc3N1ZSBhbmQNCmlu dmVzdGlnYXRlIHRoaXMuIEl0IGNhbiBhc3Npc3QgbW92ZW1lbnQgZGV0ZWN0aW9uLg0KDQotLS0t LS0tLS0tDQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBh bmEteHgudHh0DQptZXNzYWdlczogMTkyDQpub3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IE1heSBG aXgNCnN0YXR1czogUGVuZGluZw0KdGl0bGU6IEFkZGl0aW9uYWwgZGlzY292ZXJ5IGluZm9ybWF0 aW9uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K UEFOQSBJc3N1ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmluZm8+DQo8aHR0cDovL2RhbmZv cnNiZXJnLmluZm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTUzPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 5 04:44: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 EAA08802 for ; Thu, 5 Feb 2004 04:44: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 1Aog3F-0006dd-Fm; Thu, 05 Feb 2004 04:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog32-0006cb-Cm for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:43: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 EAA08758 for ; Thu, 5 Feb 2004 04:43:45 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog2z-0001Rk-00 for pana@ietf.org; Thu, 05 Feb 2004 04:43:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog21-0001Lt-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:45 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Aog17-0001Gu-00 for pana@ietf.org; Thu, 05 Feb 2004 04:41:49 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i159fnM29191 for ; Thu, 5 Feb 2004 11:41:49 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:41:25 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:41:25 +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: Thu, 5 Feb 2004 11:41:24 +0200 Message-ID: Thread-Topic: [issue55] Client cookie useful Thread-Index: AcPryyrsoDxubIAARyu7QFkjWcyXnwAAQSVA To: X-OriginalArrivalTime: 05 Feb 2004 09:41:25.0559 (UTC) FILETIME=[38D11C70:01C3EBCC] 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: [issue55] Client cookie useful 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIEphcmkgQXJra286DQo+ICAgICAgLSAiQ2xpZW50IGNvb2tpZSB1c2VmdWw/Ig0K PiANCj4gICAgICAgIFdvdWxkIGl0IGJlIHVzZWZ1bCBmb3IgdGhlIGNsaWVudCB0byBwcm92aWRl IGl0cyBvd24gY29va2llIGFzDQo+ICAgICAgICB3ZWxsLCBzdWNoIHRoYXQgZm9yIHNvbGljaXRl ZCBQU1JzLCB0aGUgY2xpZW50J3MgY29va2llIHdvdWxkDQo+ICAgICAgICBiZSBjb3BpZWQgYmFj ay4gVGhpcyB3b3VsZCBjb3N0IHZlcnkgbGl0dGxlLCBidXQgcHJvdGVjdCB0aGUNCj4gICAgICAg IGNsaWVudCBhZ2FpbnN0IGJsaW5kIFBBQSBzcG9vZmluZyBhdHRlbXB0cy4NCg0KQWxwZXIgWWVn aW46DQpPSywgd2Ugc2hhbGwgb3BlbiBhbiBpc3N1ZSBhbmQgdHJhY2sgdGhpcy4NCg0KLS0tLS0t LS0tLQ0KY2F0ZWdvcnk6IFRlY2huaWNhbA0KZG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGFuYS1wYW5h LXh4LnR4dA0KbWVzc2FnZXM6IDE5NQ0Kbm9zeTogZGZvcnNiZXINCnByaW9yaXR5OiBTaG91bGQg Rml4DQpzdGF0dXM6IFBlbmRpbmcNCnRpdGxlOiBDbGllbnQgY29va2llIHVzZWZ1bA0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEgSXNzdWVz IDxwYW5hX2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVyZy5pbmZv OjgwODAvcGFuYS1pc3N1ZXMvaXNzdWU1NT4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 5 04:44: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 EAA08819 for ; Thu, 5 Feb 2004 04:44: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 1Aog3G-0006fE-Mv; Thu, 05 Feb 2004 04:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog34-0006cm-F2 for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:43: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 EAA08766 for ; Thu, 5 Feb 2004 04:43:48 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog31-0001S3-00 for pana@ietf.org; Thu, 05 Feb 2004 04:43:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog2A-0001MU-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:55 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Aog1M-0001Hc-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:04 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i159g4M29727 for ; Thu, 5 Feb 2004 11:42:04 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:41:53 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:41:52 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:41:52 +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: Thu, 5 Feb 2004 11:41:51 +0200 Message-ID: Thread-Topic: [issue57] PSR retransmission strategy Thread-Index: AcPry42MtMa6vCKDRYOxiX2B4xYUeAAALRZQ To: X-OriginalArrivalTime: 05 Feb 2004 09:41:52.0197 (UTC) FILETIME=[48B1BF50:01C3EBCC] 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: [issue57] PSR retransmission strategy 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIEphcmkgQXJra286DQo+ICAgICAgLSAiUFNSIHJldHJhbnNtaXNzaW9uIHN0cmF0 ZWd5Ig0KPiANCj4gICAgICAgIEluIFNlY3Rpb24gNC4yIEkgYWxzbyBoYWQgYSBwb3NzaWJsZSBp c3N1ZSB3aXRoIHJldHJhbnNtaXNzaW9uDQo+ICAgICAgICBzdHJhdGVneSBpbiBjYXNlIFBTUiBp cyBsb3N0LiBUaGUgZG9jdW1lbnQgc2VlbXMgdG8gc2F5IHRoYXQNCj4gUFNScyBhcmUgbmV2ZXIg cmV0cmFuc21pdHRlZCBidXQgYXQgdGhlIHNhbWUgdGltZSB0aGUgUERJcw0KPiBhcmUgc2lsZW50 bHkgZGlzY2FyZGVkLiBUaGlzIGNvdWxkIGxlYWQgdG8gYSBkZWFkbG9jay4NCg0KQWxwZXIgWWVn aW46DQpBbm90aGVyIGlzc3VlIHRvIG9wZW4uDQoNCi0tLS0tLS0tLS0NCmNhdGVnb3J5OiBUZWNo bmljYWwNCmRvY3VtZW50OiBkcmFmdC1pZXRmLXBhbmEtcGFuYS14eC50eHQNCm1lc3NhZ2VzOiAx OTcNCm5vc3k6IGRmb3JzYmVyDQpwcmlvcml0eTogTXVzdCBGaXgNCnN0YXR1czogUGVuZGluZw0K dGl0bGU6IFBTUiByZXRyYW5zbWlzc2lvbiBzdHJhdGVneQ0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEgSXNzdWVzIDxwYW5hX2lzc3Vlc0Bk YW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVyZy5pbmZvOjgwODAvcGFuYS1pc3N1 ZXMvaXNzdWU1Nz4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 5 04:44: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 EAA08836 for ; Thu, 5 Feb 2004 04:44: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 1Aog3I-0006iu-3S; Thu, 05 Feb 2004 04:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog35-0006cw-Sj for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:43: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 EAA08769 for ; Thu, 5 Feb 2004 04:43:49 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog32-0001SE-00 for pana@ietf.org; Thu, 05 Feb 2004 04:43:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog2C-0001Mk-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:57 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Aog1T-0001He-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:11 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i159gB220625 for ; Thu, 5 Feb 2004 11:42:11 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:42:06 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:42:05 +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: Thu, 5 Feb 2004 11:42:05 +0200 Message-ID: Thread-Topic: [issue58] Fast-reauthentication and authorization issues Thread-Index: AcPry7l0qNo05M/1QXCPHl2rr9PI8AAAJBig To: X-OriginalArrivalTime: 05 Feb 2004 09:42:05.0857 (UTC) FILETIME=[50D61910:01C3EBCC] 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: [issue58] Fast-reauthentication and authorization issues 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIEphcmkgQXJra286DQo+ICAgICAgLSAiRmFzdC1yZWF1dGhlbnRpY2F0aW9uIGFu ZCBhdXRob3JpemF0aW9uIGlzc3VlcyINCj4gDQo+ICAgICAgICBJIGhhdmUgcmVzZXJ2YXRpb25z IGFib3V0IHRoZSBpbmNsdXNpb24gb2YgdGhlIGZhc3QNCj4gICAgICAgIHJlLWF1dGhlbnRpY2F0 aW9uIHNjaGVtZSBpbiB0aGUgYmFzZSBQQU5BIGRvY3VtZW50LiBUaGVyZSBhcmUNCj4gICAgICAg IGEgbnVtYmVyIG9mIHNlY3VyaXR5IGlzc3VlcyBhdCB0aGUgc3lzdGVtIGxldmVsIHdoZW4geW91 IHRyeQ0KPiAgICAgICAgdG8gZG8gdGhpcy4gU2VlIGRyYWZ0LWlldGYtZWFwLWtleWluZy0wMS50 eHQsIFNlY3Rpb25zIDEuNCBhbmQNCj4gICAgICAgIDEuNC4xIGluIHBhcnRpY3VsYXIgZm9yIHNv bWUgZXhhbXBsZXMuDQo+IA0KPiAgICAgICAgTm90ZSBhbHNvIHRoYXQgbWFueSBFQVAgbWV0aG9k cyBwcm92aWRlIGZhc3QgcmUtYXV0aGVudGljYXRpb24uDQoNCkFscGVyIFllZ2luOg0KSSB0aGlu ayB3ZSBzaG91bGQgb3BlbiBhbiBpc3N1ZSBhbmQgaW52ZXN0aWdhdGUgdGhpcy4NCg0KLS0tLS0t LS0tLQ0KY2F0ZWdvcnk6IFRlY2huaWNhbA0KZG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGFuYS1wYW5h LXh4LnR4dA0KbWVzc2FnZXM6IDE5OA0Kbm9zeTogZGZvcnNiZXINCnByaW9yaXR5OiBNdXN0IEZp eA0Kc3RhdHVzOiBQZW5kaW5nDQp0aXRsZTogRmFzdC1yZWF1dGhlbnRpY2F0aW9uIGFuZCBhdXRo b3JpemF0aW9uIGlzc3Vlcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClBBTkEgSXNzdWVzIDxwYW5hX2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0K PGh0dHA6Ly9kYW5mb3JzYmVyZy5pbmZvOjgwODAvcGFuYS1pc3N1ZXMvaXNzdWU1OD4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 5 04:44: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 EAA08853 for ; Thu, 5 Feb 2004 04:44: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 1Aog3K-0006mc-Mb; Thu, 05 Feb 2004 04:44:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog37-0006d8-6M for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:43: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 EAA08773 for ; Thu, 5 Feb 2004 04:43:50 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog34-0001SS-00 for pana@ietf.org; Thu, 05 Feb 2004 04:43:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog2E-0001N0-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:59 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Aog1a-0001Hi-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:18 -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 i159gIM00078 for ; Thu, 5 Feb 2004 11:42:18 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:42:18 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:42:18 +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: Thu, 5 Feb 2004 11:42:18 +0200 Message-ID: Thread-Topic: [issue59] TTL and other IP layer details Thread-Index: AcPry+gUu4Kut+OgTraki8YwtFIRvAAAGmoA To: X-OriginalArrivalTime: 05 Feb 2004 09:42:18.0528 (UTC) FILETIME=[58638A00:01C3EBCC] 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: [issue59] TTL and other IP layer details 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIEphcmkgQXJra286DQo+ICAgICAgLSAiVFRMIGFuZCBvdGhlciBJUCBsYXllciBk ZXRhaWxzIg0KPiANCj4gICAgICAgIEkgdGhpbmsgeW91IHNob3VsZCBzcGVjaWZ5IGluIG1vcmUg ZGV0YWlsIHRoZSBjb250ZW50cyBvZiB0aGUNCj4gICAgICAgIElQIGFuZCBVRFAgaGVhZGVycyBh c3NvY2lhdGVkIHdpdGggUEFOQSBtZXNzYWdlcy4gRm9yDQo+ICAgICAgICBpbnN0YW5jZSwgdGhl IGRvY3VtZW50IGltcGxpZXMgdGhhdCBUVEwgY2FuIGJlIHVzZWQgdG8gbGltaXQNCj4gICAgICAg IHRoZSBhYmlsaXR5IG9mIGF0dGFja2VycyB0byBzZW5kIFBBTkEgbWVzc2FnZXMsIGJ1dCBJIGRp ZCBub3QNCj4gICAgICAgIGZpbmQgYSBwbGFjZSB3aGVyZSB0aGUgZG9jdW1lbnQgd291bGQgYWN0 dWFsbHkgcmVxdWlyZSBzZXR0aW5nDQo+ICAgICAgICBvciBjaGVja2luZyB0aGUgVFRMLiBPciBk aWQgSSBtaXNzIGl0Pw0KDQpBbHBlciBZZWdpbjoNClllcywgdGhpcyBpcyBtaXNzaW5nLiBXZSBj YW4gY2xhcmlmeSB0aGlzIGluIHRoZSB0ZXh0IChuZXcgaXNzdWUpLg0KDQotLS0tLS0tLS0tDQpj YXRlZ29yeTogRWRpdG9yaWFsDQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBhbmEtMDIudHh0 DQptZXNzYWdlczogMTk5DQpub3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IFNob3VsZCBGaXgNCnN0 YXR1czogUGVuZGluZw0KdGl0bGU6IFRUTCBhbmQgb3RoZXIgSVAgbGF5ZXIgZGV0YWlscw0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEgSXNz dWVzIDxwYW5hX2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVyZy5p bmZvOjgwODAvcGFuYS1pc3N1ZXMvaXNzdWU1OT4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 5 04:45:19 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 EAA08902 for ; Thu, 5 Feb 2004 04:45:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog43-0006p8-CC for pana-archive@odin.ietf.org; Thu, 05 Feb 2004 04:44:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i159ipY0026231 for pana-archive@odin.ietf.org; Thu, 5 Feb 2004 04:44:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog42-0006p0-So for pana-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 04:44: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 EAA08873 for ; Thu, 5 Feb 2004 04:44:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog3z-0001Yu-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:44:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog35-0001Sc-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:43:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aog2F-0001ND-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:42:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog2H-0006TW-K7; Thu, 05 Feb 2004 04: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 1Aog24-0006T1-6G for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:42: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 EAA08692 for ; Thu, 5 Feb 2004 04:42:45 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog21-0001Lo-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog15-0001Ge-00 for pana@ietf.org; Thu, 05 Feb 2004 04:41:47 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Aog0C-0001Bi-00 for pana@ietf.org; Thu, 05 Feb 2004 04:40:52 -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 i159eqM27562 for ; Thu, 5 Feb 2004 11:40:52 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:40:52 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:40:51 +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: Thu, 5 Feb 2004 11:40:50 +0200 Message-ID: Thread-Topic: [issue52] Details of double authentication Thread-Index: AcPrytVhLpG0IJaPRwKrSyzQLwqLgQAAUbLw To: X-OriginalArrivalTime: 05 Feb 2004 09:40:51.0228 (UTC) FILETIME=[245A9DC0:01C3EBCC] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue52] Details of double authentication 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 RGFuIEZvcnNiZXJnIDxkYW4uZm9yc2JlcmdAbm9raWEuY29tPiBhZGRlZCB0aGUgY29tbWVudDoN Cg0KPkphcmkgQXJra28gd3JvdGU6DQo+ICAgICAgLSAiRGV0YWlscyBvZiBkb3VibGUgYXV0aGVu dGljYXRpb24iDQo+IA0KPiAgICAgICAgUGVyaGFwcyBpdHMganVzdCBtZSwgYnV0IEkgZGlkIG5v dCBmaW5kIGFsbCB0aGUgZGV0YWlscw0KPiAgICAgICAgcmVnYXJkaW5nIHRoZSB1c2Ugb2YgdHdv IChOQVAgYW5kIElTUCkgYXV0aGVudGljYXRpb25zLiBJcw0KPiAgICAgICAgdGhpcyBzdXBwb3J0 ZWQgb3Igbm90PyBBcmUgdGhleSBwZXJmb3JtZWQgaW4gc2VxdWVuY2U/IERvZXMgaXQNCj4gICAg ICAgIGxvb2sgbGlrZSBhIHJlLWF1dGhlbnRpY2F0aW9uLCBvciBkbyB5b3UgcHJvdmlkZSBhIGJp dA0KPiAgICAgICAgc29tZXdoZXJlIHRoYXQgaW5kaWNhdGVzIHdoZXRoZXIgdGhpcyBFQVAgcnVu IHJlbGF0ZXMgdG8gdGhlDQo+ICAgICAgICBOQVAgb3IgdGhlIElTUCBhdXRoZW50aWNhdGlvbj8g SXMgdGhlcmUgYSBQQU5BIEJpbmQgUmVxdWVzdCAtDQo+ICAgICAgICBBbnN3ZXIgcGFpciBpbiBi ZXR3ZWVuIG9yIG5vdD8NCg0KQWxwZXIgWWVnaW46DQpUaGlzIHNheXMgdGhlIHRleHQgaXMgbm90 IHN1ZmZpY2llbnQuIFdlIHNoYWxsIG9wZW4gYW4gaXNzdWUgb24gdGhpcyBhbmQgdHJ5DQp0byBj bGVhcmx5IGFuc3dlciB5b3VyIHF1ZXN0aW9ucy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpQQU5BIElzc3VlcyA8cGFuYV9pc3N1ZXNAZGFuZm9y c2JlcmcuaW5mbz4NCjxodHRwOi8vZGFuZm9yc2JlcmcuaW5mbzo4MDgwL3BhbmEtaXNzdWVzL2lz c3VlNTI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0K _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 5 04:45: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 EAA08920 for ; Thu, 5 Feb 2004 04:45: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 1Aog45-0006pl-AS for pana-archive@odin.ietf.org; Thu, 05 Feb 2004 04:44:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i159irf8026262 for pana-archive@odin.ietf.org; Thu, 5 Feb 2004 04:44:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog45-0006pM-1N for pana-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 04:44: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 EAA08877 for ; Thu, 5 Feb 2004 04:44:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog41-0001Z4-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:44:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog37-0001Sy-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:43:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aog2G-0001NN-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog2I-0006UA-EV; Thu, 05 Feb 2004 04:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog26-0006TC-3n for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:42: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 EAA08698 for ; Thu, 5 Feb 2004 04:42:47 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog23-0001M6-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog18-0001HD-00 for pana@ietf.org; Thu, 05 Feb 2004 04:41:51 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Aog0S-0001CN-00 for pana@ietf.org; Thu, 05 Feb 2004 04:41:08 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i159f9218981 for ; Thu, 5 Feb 2004 11:41:09 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:41:08 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:41:08 +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: Thu, 5 Feb 2004 11:41:07 +0200 Message-ID: Thread-Topic: [issue54] Client cookie mandatory Thread-Index: AcPryw+73lFV48DcRICZIQc84fGdugAARZtw To: X-OriginalArrivalTime: 05 Feb 2004 09:41:08.0352 (UTC) FILETIME=[2E8F8800:01C3EBCC] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue54] Client cookie mandatory 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIEphcmkgQXJra286DQo+ICAgICAgLSAiQ29va2llIG1hbmRhdG9yeSINCj4gDQo+ ICAgICAgICBJIHdvdWxkIGxpa2UgdGhlIGluY2x1c2lvbiBvZiB0aGUgY29va2llIHRvIGluIHRo ZSBzdGFydA0KPiAgICAgICAgZXhjaGFuZ2UgdG8gYmUgbWFuZGF0b3J5Lg0KDQotLS0tLS0tLS0t DQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBhbmEteHgu dHh0DQptZXNzYWdlczogMTk0DQpub3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IFNob3VsZCBGaXgN CnN0YXR1czogUGVuZGluZw0KdGl0bGU6IENsaWVudCBjb29raWUgbWFuZGF0b3J5DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUEFOQSBJc3N1ZXMg PHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmluZm8+DQo8aHR0cDovL2RhbmZvcnNiZXJnLmluZm86 ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTU0Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 5 04:45: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 EAA08937 for ; Thu, 5 Feb 2004 04:45: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 1Aog46-0006qB-NA for pana-archive@odin.ietf.org; Thu, 05 Feb 2004 04:44:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i159isuW026289 for pana-archive@odin.ietf.org; Thu, 5 Feb 2004 04:44:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog46-0006pw-Gs for pana-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 04:44: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 EAA08887 for ; Thu, 5 Feb 2004 04:44:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog43-0001ZK-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:44:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog39-0001TM-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:43:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aog2Q-0001Nd-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:43:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog2K-0006Yu-6C; Thu, 05 Feb 2004 04:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog2C-0006TI-Jt for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:42: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 EAA08701 for ; Thu, 5 Feb 2004 04:42:54 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog29-0001MH-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog19-0001HT-00 for pana@ietf.org; Thu, 05 Feb 2004 04:41:52 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Aog0y-0001CS-00 for pana@ietf.org; Thu, 05 Feb 2004 04:41:40 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i159fe219857 for ; Thu, 5 Feb 2004 11:41:40 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:41:40 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:41:39 +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: Thu, 5 Feb 2004 11:41:38 +0200 Message-ID: Thread-Topic: [issue56] AAA routing based on NAI vs. ISP choice clarification Thread-Index: AcPry0FuwiftffNZTBmc/KKN89nwiAAAPgRw To: X-OriginalArrivalTime: 05 Feb 2004 09:41:39.0923 (UTC) FILETIME=[4160E230:01C3EBCC] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue56] AAA routing based on NAI vs. ISP choice clarification 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIEphcmkgQXJra286DQo+ICAgICAgLSAiQUFBIHJvdXRpbmcgYmFzZWQgb24gTkFJ IHZzLiBJU1AgY2hvaWNlIg0KPiANCj4gICAgICAgIFNlY3Rpb24gNC4yIGNsYWltcyB0aGF0IEFB QSByb3V0aW5nIGlzIGJhc2VkIG9uIHRoZSBJU1ANCj4gICAgICAgIGNob2ljZS4gIEkgYmVsaWV2 ZSB0aGUgZmlyc3QgaG9wIGRlY2lzaW9uIGNhbiBiZSBiYXNlZCBvbg0KPiAgICAgICAgdGhpcywg YnV0IGZ1cnRoZXIgb24gaW4gdGhlIG5ldHdvcmsgaXQgbXVzdCBiZSBiYXNlZCBvbiB0aGUNCj4g ICAgICAgIE5BSSAodW5sZXNzIHlvdSByZXZpc2UgQUFBIHByb3RvY29scykuDQoNCkFscGVyIFll Z2luOg0KQW5vdGhlciBpc3N1ZSB0byBvcGVuIChhdCBsZWFzdCB0byBjbGFyaWZ5IHRoZSB0ZXh0 KS4NCg0KLS0tLS0tLS0tLQ0KY2F0ZWdvcnk6IEVkaXRvcmlhbA0KZG9jdW1lbnQ6IGRyYWZ0LWll dGYtcGFuYS1wYW5hLXh4LnR4dA0KbWVzc2FnZXM6IDE5Ng0Kbm9zeTogZGZvcnNiZXINCnByaW9y aXR5OiBNdXN0IEZpeA0Kc3RhdHVzOiBQZW5kaW5nDQp0aXRsZTogQUFBIHJvdXRpbmcgYmFzZWQg b24gTkFJIHZzLiBJU1AgY2hvaWNlIGNsYXJpZmljYXRpb24NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQQU5BIElzc3VlcyA8cGFuYV9pc3N1ZXNA ZGFuZm9yc2JlcmcuaW5mbz4NCjxodHRwOi8vZGFuZm9yc2JlcmcuaW5mbzo4MDgwL3BhbmEtaXNz dWVzL2lzc3VlNTY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0K _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 5 04:46:18 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 EAA09007 for ; Thu, 5 Feb 2004 04:46:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog50-0006uH-G3 for pana-archive@odin.ietf.org; Thu, 05 Feb 2004 04:45:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i159jnf0026529 for pana-archive@odin.ietf.org; Thu, 5 Feb 2004 04:45:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog4z-0006tl-8T for pana-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 04:45: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 EAA08963 for ; Thu, 5 Feb 2004 04:45:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog4w-0001fZ-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:45:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog46-0001Zj-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:44:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aog3D-0001Ty-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog3F-0006dd-Fm; Thu, 05 Feb 2004 04:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog32-0006cb-Cm for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:43: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 EAA08758 for ; Thu, 5 Feb 2004 04:43:45 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog2z-0001Rk-00 for pana@ietf.org; Thu, 05 Feb 2004 04:43:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog21-0001Lt-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:45 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Aog17-0001Gu-00 for pana@ietf.org; Thu, 05 Feb 2004 04:41:49 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i159fnM29191 for ; Thu, 5 Feb 2004 11:41:49 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:41:25 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:41:25 +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: Thu, 5 Feb 2004 11:41:24 +0200 Message-ID: Thread-Topic: [issue55] Client cookie useful Thread-Index: AcPryyrsoDxubIAARyu7QFkjWcyXnwAAQSVA To: X-OriginalArrivalTime: 05 Feb 2004 09:41:25.0559 (UTC) FILETIME=[38D11C70:01C3EBCC] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue55] Client cookie useful 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIEphcmkgQXJra286DQo+ICAgICAgLSAiQ2xpZW50IGNvb2tpZSB1c2VmdWw/Ig0K PiANCj4gICAgICAgIFdvdWxkIGl0IGJlIHVzZWZ1bCBmb3IgdGhlIGNsaWVudCB0byBwcm92aWRl IGl0cyBvd24gY29va2llIGFzDQo+ICAgICAgICB3ZWxsLCBzdWNoIHRoYXQgZm9yIHNvbGljaXRl ZCBQU1JzLCB0aGUgY2xpZW50J3MgY29va2llIHdvdWxkDQo+ICAgICAgICBiZSBjb3BpZWQgYmFj ay4gVGhpcyB3b3VsZCBjb3N0IHZlcnkgbGl0dGxlLCBidXQgcHJvdGVjdCB0aGUNCj4gICAgICAg IGNsaWVudCBhZ2FpbnN0IGJsaW5kIFBBQSBzcG9vZmluZyBhdHRlbXB0cy4NCg0KQWxwZXIgWWVn aW46DQpPSywgd2Ugc2hhbGwgb3BlbiBhbiBpc3N1ZSBhbmQgdHJhY2sgdGhpcy4NCg0KLS0tLS0t LS0tLQ0KY2F0ZWdvcnk6IFRlY2huaWNhbA0KZG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGFuYS1wYW5h LXh4LnR4dA0KbWVzc2FnZXM6IDE5NQ0Kbm9zeTogZGZvcnNiZXINCnByaW9yaXR5OiBTaG91bGQg Rml4DQpzdGF0dXM6IFBlbmRpbmcNCnRpdGxlOiBDbGllbnQgY29va2llIHVzZWZ1bA0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEgSXNzdWVz IDxwYW5hX2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVyZy5pbmZv OjgwODAvcGFuYS1pc3N1ZXMvaXNzdWU1NT4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 5 04:46:19 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 EAA09011 for ; Thu, 5 Feb 2004 04:46:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog51-0006uu-1i for pana-archive@odin.ietf.org; Thu, 05 Feb 2004 04:45:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i159joUg026580 for pana-archive@odin.ietf.org; Thu, 5 Feb 2004 04:45:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog50-0006uX-NV for pana-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 04:45: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 EAA08969 for ; Thu, 5 Feb 2004 04:45:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog4x-0001fj-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:45:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog47-0001Zz-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:44:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aog3F-0001U3-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog3I-0006iu-3S; Thu, 05 Feb 2004 04:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog35-0006cw-Sj for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:43: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 EAA08769 for ; Thu, 5 Feb 2004 04:43:49 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog32-0001SE-00 for pana@ietf.org; Thu, 05 Feb 2004 04:43:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog2C-0001Mk-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:57 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1Aog1T-0001He-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:11 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i159gB220625 for ; Thu, 5 Feb 2004 11:42:11 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:42:06 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:42:05 +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: Thu, 5 Feb 2004 11:42:05 +0200 Message-ID: Thread-Topic: [issue58] Fast-reauthentication and authorization issues Thread-Index: AcPry7l0qNo05M/1QXCPHl2rr9PI8AAAJBig To: X-OriginalArrivalTime: 05 Feb 2004 09:42:05.0857 (UTC) FILETIME=[50D61910:01C3EBCC] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue58] Fast-reauthentication and authorization issues 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIEphcmkgQXJra286DQo+ICAgICAgLSAiRmFzdC1yZWF1dGhlbnRpY2F0aW9uIGFu ZCBhdXRob3JpemF0aW9uIGlzc3VlcyINCj4gDQo+ICAgICAgICBJIGhhdmUgcmVzZXJ2YXRpb25z IGFib3V0IHRoZSBpbmNsdXNpb24gb2YgdGhlIGZhc3QNCj4gICAgICAgIHJlLWF1dGhlbnRpY2F0 aW9uIHNjaGVtZSBpbiB0aGUgYmFzZSBQQU5BIGRvY3VtZW50LiBUaGVyZSBhcmUNCj4gICAgICAg IGEgbnVtYmVyIG9mIHNlY3VyaXR5IGlzc3VlcyBhdCB0aGUgc3lzdGVtIGxldmVsIHdoZW4geW91 IHRyeQ0KPiAgICAgICAgdG8gZG8gdGhpcy4gU2VlIGRyYWZ0LWlldGYtZWFwLWtleWluZy0wMS50 eHQsIFNlY3Rpb25zIDEuNCBhbmQNCj4gICAgICAgIDEuNC4xIGluIHBhcnRpY3VsYXIgZm9yIHNv bWUgZXhhbXBsZXMuDQo+IA0KPiAgICAgICAgTm90ZSBhbHNvIHRoYXQgbWFueSBFQVAgbWV0aG9k cyBwcm92aWRlIGZhc3QgcmUtYXV0aGVudGljYXRpb24uDQoNCkFscGVyIFllZ2luOg0KSSB0aGlu ayB3ZSBzaG91bGQgb3BlbiBhbiBpc3N1ZSBhbmQgaW52ZXN0aWdhdGUgdGhpcy4NCg0KLS0tLS0t LS0tLQ0KY2F0ZWdvcnk6IFRlY2huaWNhbA0KZG9jdW1lbnQ6IGRyYWZ0LWlldGYtcGFuYS1wYW5h LXh4LnR4dA0KbWVzc2FnZXM6IDE5OA0Kbm9zeTogZGZvcnNiZXINCnByaW9yaXR5OiBNdXN0IEZp eA0Kc3RhdHVzOiBQZW5kaW5nDQp0aXRsZTogRmFzdC1yZWF1dGhlbnRpY2F0aW9uIGFuZCBhdXRo b3JpemF0aW9uIGlzc3Vlcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClBBTkEgSXNzdWVzIDxwYW5hX2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0K PGh0dHA6Ly9kYW5mb3JzYmVyZy5pbmZvOjgwODAvcGFuYS1pc3N1ZXMvaXNzdWU1OD4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 5 04:46: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 EAA09054 for ; Thu, 5 Feb 2004 04:46: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 1Aog52-0006vH-Bg for pana-archive@odin.ietf.org; Thu, 05 Feb 2004 04:45:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i159jqxi026605 for pana-archive@odin.ietf.org; Thu, 5 Feb 2004 04:45:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog52-0006v2-2f for pana-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 04:45: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 EAA08978 for ; Thu, 5 Feb 2004 04:45:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog4z-0001fx-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:45:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog49-0001aF-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:44:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aog3I-0001U7-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog3K-0006mc-Mb; Thu, 05 Feb 2004 04:44:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog37-0006d8-6M for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:43: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 EAA08773 for ; Thu, 5 Feb 2004 04:43:50 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog34-0001SS-00 for pana@ietf.org; Thu, 05 Feb 2004 04:43:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog2E-0001N0-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:59 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Aog1a-0001Hi-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:18 -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 i159gIM00078 for ; Thu, 5 Feb 2004 11:42:18 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:42:18 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:42:18 +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: Thu, 5 Feb 2004 11:42:18 +0200 Message-ID: Thread-Topic: [issue59] TTL and other IP layer details Thread-Index: AcPry+gUu4Kut+OgTraki8YwtFIRvAAAGmoA To: X-OriginalArrivalTime: 05 Feb 2004 09:42:18.0528 (UTC) FILETIME=[58638A00:01C3EBCC] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue59] TTL and other IP layer details 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIEphcmkgQXJra286DQo+ICAgICAgLSAiVFRMIGFuZCBvdGhlciBJUCBsYXllciBk ZXRhaWxzIg0KPiANCj4gICAgICAgIEkgdGhpbmsgeW91IHNob3VsZCBzcGVjaWZ5IGluIG1vcmUg ZGV0YWlsIHRoZSBjb250ZW50cyBvZiB0aGUNCj4gICAgICAgIElQIGFuZCBVRFAgaGVhZGVycyBh c3NvY2lhdGVkIHdpdGggUEFOQSBtZXNzYWdlcy4gRm9yDQo+ICAgICAgICBpbnN0YW5jZSwgdGhl IGRvY3VtZW50IGltcGxpZXMgdGhhdCBUVEwgY2FuIGJlIHVzZWQgdG8gbGltaXQNCj4gICAgICAg IHRoZSBhYmlsaXR5IG9mIGF0dGFja2VycyB0byBzZW5kIFBBTkEgbWVzc2FnZXMsIGJ1dCBJIGRp ZCBub3QNCj4gICAgICAgIGZpbmQgYSBwbGFjZSB3aGVyZSB0aGUgZG9jdW1lbnQgd291bGQgYWN0 dWFsbHkgcmVxdWlyZSBzZXR0aW5nDQo+ICAgICAgICBvciBjaGVja2luZyB0aGUgVFRMLiBPciBk aWQgSSBtaXNzIGl0Pw0KDQpBbHBlciBZZWdpbjoNClllcywgdGhpcyBpcyBtaXNzaW5nLiBXZSBj YW4gY2xhcmlmeSB0aGlzIGluIHRoZSB0ZXh0IChuZXcgaXNzdWUpLg0KDQotLS0tLS0tLS0tDQpj YXRlZ29yeTogRWRpdG9yaWFsDQpkb2N1bWVudDogZHJhZnQtaWV0Zi1wYW5hLXBhbmEtMDIudHh0 DQptZXNzYWdlczogMTk5DQpub3N5OiBkZm9yc2Jlcg0KcHJpb3JpdHk6IFNob3VsZCBGaXgNCnN0 YXR1czogUGVuZGluZw0KdGl0bGU6IFRUTCBhbmQgb3RoZXIgSVAgbGF5ZXIgZGV0YWlscw0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEgSXNz dWVzIDxwYW5hX2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVyZy5p bmZvOjgwODAvcGFuYS1pc3N1ZXMvaXNzdWU1OT4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 5 05:05: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 FAA09532 for ; Thu, 5 Feb 2004 05:05: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 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" 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 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 Thu Feb 5 05:32:06 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 EAA09009 for ; Thu, 5 Feb 2004 04:46:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog50-0006uY-N1 for pana-archive@odin.ietf.org; Thu, 05 Feb 2004 04:45:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i159jos6026557 for pana-archive@odin.ietf.org; Thu, 5 Feb 2004 04:45:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog4z-0006uB-VS for pana-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 04:45: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 EAA08966 for ; Thu, 5 Feb 2004 04:45:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog4w-0001fe-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:45:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog47-0001Zr-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:44:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aog3E-0001U1-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 04:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog3G-0006fE-Mv; Thu, 05 Feb 2004 04:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aog34-0006cm-F2 for pana@optimus.ietf.org; Thu, 05 Feb 2004 04:43: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 EAA08766 for ; Thu, 5 Feb 2004 04:43:48 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aog31-0001S3-00 for pana@ietf.org; Thu, 05 Feb 2004 04:43:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aog2A-0001MU-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:55 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1Aog1M-0001Hc-00 for pana@ietf.org; Thu, 05 Feb 2004 04:42:04 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i159g4M29727 for ; Thu, 5 Feb 2004 11:42:04 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 5 Feb 2004 11:41:53 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:41:52 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 5 Feb 2004 11:41:52 +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: Thu, 5 Feb 2004 11:41:51 +0200 Message-ID: Thread-Topic: [issue57] PSR retransmission strategy Thread-Index: AcPry42MtMa6vCKDRYOxiX2B4xYUeAAALRZQ To: X-OriginalArrivalTime: 05 Feb 2004 09:41:52.0197 (UTC) FILETIME=[48B1BF50:01C3EBCC] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue57] PSR retransmission strategy 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpGcm9tIEphcmkgQXJra286DQo+ICAgICAgLSAiUFNSIHJldHJhbnNtaXNzaW9uIHN0cmF0 ZWd5Ig0KPiANCj4gICAgICAgIEluIFNlY3Rpb24gNC4yIEkgYWxzbyBoYWQgYSBwb3NzaWJsZSBp c3N1ZSB3aXRoIHJldHJhbnNtaXNzaW9uDQo+ICAgICAgICBzdHJhdGVneSBpbiBjYXNlIFBTUiBp cyBsb3N0LiBUaGUgZG9jdW1lbnQgc2VlbXMgdG8gc2F5IHRoYXQNCj4gUFNScyBhcmUgbmV2ZXIg cmV0cmFuc21pdHRlZCBidXQgYXQgdGhlIHNhbWUgdGltZSB0aGUgUERJcw0KPiBhcmUgc2lsZW50 bHkgZGlzY2FyZGVkLiBUaGlzIGNvdWxkIGxlYWQgdG8gYSBkZWFkbG9jay4NCg0KQWxwZXIgWWVn aW46DQpBbm90aGVyIGlzc3VlIHRvIG9wZW4uDQoNCi0tLS0tLS0tLS0NCmNhdGVnb3J5OiBUZWNo bmljYWwNCmRvY3VtZW50OiBkcmFmdC1pZXRmLXBhbmEtcGFuYS14eC50eHQNCm1lc3NhZ2VzOiAx OTcNCm5vc3k6IGRmb3JzYmVyDQpwcmlvcml0eTogTXVzdCBGaXgNCnN0YXR1czogUGVuZGluZw0K dGl0bGU6IFBTUiByZXRyYW5zbWlzc2lvbiBzdHJhdGVneQ0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEgSXNzdWVzIDxwYW5hX2lzc3Vlc0Bk YW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVyZy5pbmZvOjgwODAvcGFuYS1pc3N1 ZXMvaXNzdWU1Nz4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 5 11:32: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 LAA22522 for ; Thu, 5 Feb 2004 11:32: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 1AomQ4-0001zY-IH; Thu, 05 Feb 2004 11: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 1AomPC-0001qa-FX for pana@optimus.ietf.org; Thu, 05 Feb 2004 11:31: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 LAA22473 for ; Thu, 5 Feb 2004 11:31:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomPB-000151-00 for pana@ietf.org; Thu, 05 Feb 2004 11:31:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomOM-0000zj-00 for pana@ietf.org; Thu, 05 Feb 2004 11:30:14 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AomNY-0000tD-00 for pana@ietf.org; Thu, 05 Feb 2004 11:29:25 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i15GTNN9018481; Fri, 6 Feb 2004 01:29:23 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i15GTNJY019641; Fri, 6 Feb 2004 01:29:23 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA19640 ; Fri, 6 Feb 2004 01:29:23 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA08824; Fri, 6 Feb 2004 01:29:22 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA15979; Fri, 6 Feb 2004 01:29:22 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i15GTKKn029966; Fri, 6 Feb 2004 01:29:21 +0900 (JST) Received: from steelhead ([159.119.168.131]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSM009QHDSV1P@tsbpo1.po.toshiba.co.jp>; Fri, 6 Feb 2004 01:29:20 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AomKl-00051g-00; Thu, 05 Feb 2004 08:26:31 -0800 Date: Thu, 05 Feb 2004 08:26:31 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] review of the pana protocol In-reply-to: <2A8DB02E3018D411901B009027FD3A3F03BC069D@mchp905a.mch.sbs.de> To: Tschofenig Hannes Cc: "'jari.arkko@piuha.net'" , Yoshihiro Ohba , pana@ietf.org Message-id: <20040205162631.GE17931@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Tschofenig Hannes , "'jari.arkko@piuha.net'" , Yoshihiro Ohba , pana@ietf.org User-Agent: Mutt/1.5.4i References: <2A8DB02E3018D411901B009027FD3A3F03BC069D@mchp905a.mch.sbs.de> 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: , I think Hannes' point is valid. Since eap keying draft made a distinction between AAA-Key and MSK, it should be the responsibility of the keying draft to define an algorithm to unambiguously calculate AAA-Key from MSK. I think we can simply: - Replace "MSK" in the PANA specification draft with "AAA-Key" and - Ask EAP Keying design team to define an algorithm (or algorithms, one per usage case?) to derive AAA-Key from MSK. Note that the same thing would also apply to pana-ipsec draft. Yoshihiro Ohba On Thu, Feb 05, 2004 at 11:03:03AM +0100, Tschofenig Hannes wrote: > 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 Thu Feb 5 11:34: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 LAA22639 for ; Thu, 5 Feb 2004 11:34: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 1AomS6-0002ET-4y for pana-archive@odin.ietf.org; Thu, 05 Feb 2004 11:34:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15GY6ZE008580 for pana-archive@odin.ietf.org; Thu, 5 Feb 2004 11:34:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomS6-0002EJ-03 for pana-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 11:34: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 LAA22614 for ; Thu, 5 Feb 2004 11:34:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomS4-0001Mt-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 11:34:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomR3-0001GY-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 11:33:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AomQ9-0001B0-00 for pana-web-archive@ietf.org; Thu, 05 Feb 2004 11:32:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomQ4-0001zY-IH; Thu, 05 Feb 2004 11: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 1AomPC-0001qa-FX for pana@optimus.ietf.org; Thu, 05 Feb 2004 11:31: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 LAA22473 for ; Thu, 5 Feb 2004 11:31:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomPB-000151-00 for pana@ietf.org; Thu, 05 Feb 2004 11:31:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomOM-0000zj-00 for pana@ietf.org; Thu, 05 Feb 2004 11:30:14 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AomNY-0000tD-00 for pana@ietf.org; Thu, 05 Feb 2004 11:29:25 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i15GTNN9018481; Fri, 6 Feb 2004 01:29:23 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i15GTNJY019641; Fri, 6 Feb 2004 01:29:23 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA19640 ; Fri, 6 Feb 2004 01:29:23 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA08824; Fri, 6 Feb 2004 01:29:22 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA15979; Fri, 6 Feb 2004 01:29:22 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i15GTKKn029966; Fri, 6 Feb 2004 01:29:21 +0900 (JST) Received: from steelhead ([159.119.168.131]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSM009QHDSV1P@tsbpo1.po.toshiba.co.jp>; Fri, 6 Feb 2004 01:29:20 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AomKl-00051g-00; Thu, 05 Feb 2004 08:26:31 -0800 Date: Thu, 05 Feb 2004 08:26:31 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] review of the pana protocol In-reply-to: <2A8DB02E3018D411901B009027FD3A3F03BC069D@mchp905a.mch.sbs.de> To: Tschofenig Hannes Cc: "'jari.arkko@piuha.net'" , Yoshihiro Ohba , pana@ietf.org Message-id: <20040205162631.GE17931@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Tschofenig Hannes , "'jari.arkko@piuha.net'" , Yoshihiro Ohba , pana@ietf.org User-Agent: Mutt/1.5.4i References: <2A8DB02E3018D411901B009027FD3A3F03BC069D@mchp905a.mch.sbs.de> 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 I think Hannes' point is valid. Since eap keying draft made a distinction between AAA-Key and MSK, it should be the responsibility of the keying draft to define an algorithm to unambiguously calculate AAA-Key from MSK. I think we can simply: - Replace "MSK" in the PANA specification draft with "AAA-Key" and - Ask EAP Keying design team to define an algorithm (or algorithms, one per usage case?) to derive AAA-Key from MSK. Note that the same thing would also apply to pana-ipsec draft. Yoshihiro Ohba On Thu, Feb 05, 2004 at 11:03:03AM +0100, Tschofenig Hannes wrote: > 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 pana-admin@ietf.org Fri Feb 6 13: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 NAA09261 for ; Fri, 6 Feb 2004 13:56: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 1ApB8z-0002zR-S8; Fri, 06 Feb 2004 13:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApB8q-0002yw-IH for pana@optimus.ietf.org; Fri, 06 Feb 2004 13:55: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 NAA09238 for ; Fri, 6 Feb 2004 13:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApB8o-0002oM-00 for pana@ietf.org; Fri, 06 Feb 2004 13:55:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApB7p-0002lE-00 for pana@ietf.org; Fri, 06 Feb 2004 13:54:50 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1ApB6s-0002g6-00 for pana@ietf.org; Fri, 06 Feb 2004 13:53:50 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i16IrhGv017548; Sat, 7 Feb 2004 03:53:43 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i16Irhi9007345; Sat, 7 Feb 2004 03:53:43 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA07344 ; Sat, 7 Feb 2004 03:53:43 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA06142; Sat, 7 Feb 2004 03:53:42 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA10359; Sat, 7 Feb 2004 03:53:42 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i16IrfLT017539; Sat, 7 Feb 2004 03:53:41 +0900 (JST) Received: from steelhead ([159.119.168.194]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSO00BZUF5FKD@tsbpo1.po.toshiba.co.jp>; Sat, 7 Feb 2004 03:53:40 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ApB6B-00074f-00; Fri, 06 Feb 2004 10:53:07 -0800 Date: Fri, 06 Feb 2004 10:53:07 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040206185307.GQ21752@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.4i 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] PANA specification snapshot (03c) 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: , The latest PANA specification snapshot (draft-ietf-pana-pana-03c) is available at: http://www.toshiba.com/tari/pana/pana-spec.html Changes: - Reflected Jari's editorial comments (Jari's technical issues are carried to future version of draft after -03 is submitted.) - Prohibition of the use of unspecified address (Issue 51 accepted) - Rejected Issue 41 - Moved more references from normative section to informative section Remaining issue before submission of -03: - MSK vs AAA-Key. Currently, MSK is used in -03c draft. This issue is under discussion in the EAP WG. If the issue is going to be resolved before the I-D submission cutoff date, we can wait. Otherwise, it might be better to submit this version as -03. What should we do? Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Feb 6 13:58: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 NAA09369 for ; Fri, 6 Feb 2004 13:58: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 1ApBAo-0003Gl-NC for pana-archive@odin.ietf.org; Fri, 06 Feb 2004 13:57:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16IvsNd012566 for pana-archive@odin.ietf.org; Fri, 6 Feb 2004 13:57:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApBAo-0003Gb-JJ for pana-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 13:57: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 NAA09343 for ; Fri, 6 Feb 2004 13:57:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApBAm-0002vx-00 for pana-web-archive@ietf.org; Fri, 06 Feb 2004 13:57:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApB9r-0002sY-00 for pana-web-archive@ietf.org; Fri, 06 Feb 2004 13:56:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApB90-0002pW-00 for pana-web-archive@ietf.org; Fri, 06 Feb 2004 13:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApB8z-0002zR-S8; Fri, 06 Feb 2004 13:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApB8q-0002yw-IH for pana@optimus.ietf.org; Fri, 06 Feb 2004 13:55: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 NAA09238 for ; Fri, 6 Feb 2004 13:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApB8o-0002oM-00 for pana@ietf.org; Fri, 06 Feb 2004 13:55:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApB7p-0002lE-00 for pana@ietf.org; Fri, 06 Feb 2004 13:54:50 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1ApB6s-0002g6-00 for pana@ietf.org; Fri, 06 Feb 2004 13:53:50 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i16IrhGv017548; Sat, 7 Feb 2004 03:53:43 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i16Irhi9007345; Sat, 7 Feb 2004 03:53:43 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA07344 ; Sat, 7 Feb 2004 03:53:43 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA06142; Sat, 7 Feb 2004 03:53:42 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA10359; Sat, 7 Feb 2004 03:53:42 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i16IrfLT017539; Sat, 7 Feb 2004 03:53:41 +0900 (JST) Received: from steelhead ([159.119.168.194]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSO00BZUF5FKD@tsbpo1.po.toshiba.co.jp>; Sat, 7 Feb 2004 03:53:40 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ApB6B-00074f-00; Fri, 06 Feb 2004 10:53:07 -0800 Date: Fri, 06 Feb 2004 10:53:07 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040206185307.GQ21752@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.4i Subject: [Pana] PANA specification snapshot (03c) 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 The latest PANA specification snapshot (draft-ietf-pana-pana-03c) is available at: http://www.toshiba.com/tari/pana/pana-spec.html Changes: - Reflected Jari's editorial comments (Jari's technical issues are carried to future version of draft after -03 is submitted.) - Prohibition of the use of unspecified address (Issue 51 accepted) - Rejected Issue 41 - Moved more references from normative section to informative section Remaining issue before submission of -03: - MSK vs AAA-Key. Currently, MSK is used in -03c draft. This issue is under discussion in the EAP WG. If the issue is going to be resolved before the I-D submission cutoff date, we can wait. Otherwise, it might be better to submit this version as -03. What should we do? Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Feb 6 19:48: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 TAA01868 for ; Fri, 6 Feb 2004 19:48: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 1ApGdc-0003iw-Oo; Fri, 06 Feb 2004 19:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApGch-0003hi-ET for pana@optimus.ietf.org; Fri, 06 Feb 2004 19:47: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 TAA01774 for ; Fri, 6 Feb 2004 19:47:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApGcf-0000mf-00 for pana@ietf.org; Fri, 06 Feb 2004 19:47:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApGbh-0000ja-00 for pana@ietf.org; Fri, 06 Feb 2004 19:46:01 -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 1ApGah-0000eg-00 for pana@ietf.org; Fri, 06 Feb 2004 19:45:00 -0500 Date: Fri, 06 Feb 2004 16:45:09 -0800 From: Alper Yegin To: Jari Arkko , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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] issue58: Fast-reauthentication and authorization issues 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 >> From Jari Arkko: >> - "Fast-reauthentication and authorization issues" >> >> I have reservations about the inclusion of the fast >> re-authentication scheme in the base PANA document. There are >> a number of security issues at the system level when you try >> to do this. See draft-ietf-eap-keying-01.txt, Sections 1.4 and >> 1.4.1 in particular for some examples. >> >> Note also that many EAP methods provide fast re-authentication. The method we are proposing is described as "fast handoff" in the eap-keying draft. You are right that there are system level issues, and section "1.4.1 Correctness in fast handoff" elaborates on that. I think we should minimally update the text to take people's attention to these issues. I think the eap-keying draft is identifying this scenario, but also warning about several limitations and considerations. The other relevant text is in the Appendix E. AAA-key derivation. Although the eap-keying draft identifies two different approaches to fast handoffs (namely, based on context transfers, and pre-emptive state distribution), the appendix only outlines how keys are generated for the latter case. Note that PANA is using the former approach. As I understand simply passing MSK (or AAA-key) from one PAA to another is not recommended. So, we'd need to specify how derivative keys are generated for this. So, overall I'm under the impression that what PANA aims is an application of so-called fast handoffs as defined in eap-keying draft. Providing the above enhancements should be sufficient. Unless I'm missing something... What do you think? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Feb 6 19:50: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 TAA01921 for ; Fri, 6 Feb 2004 19:50: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 1ApGfb-0003rM-R0 for pana-archive@odin.ietf.org; Fri, 06 Feb 2004 19:50:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i170o3iO014830 for pana-archive@odin.ietf.org; Fri, 6 Feb 2004 19:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApGfb-0003r7-MZ for pana-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 19:50: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 TAA01898 for ; Fri, 6 Feb 2004 19:50:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApGfZ-0000vW-00 for pana-web-archive@ietf.org; Fri, 06 Feb 2004 19:50:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApGeb-0000sM-00 for pana-web-archive@ietf.org; Fri, 06 Feb 2004 19:49:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApGdd-0000pZ-00 for pana-web-archive@ietf.org; Fri, 06 Feb 2004 19:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApGdc-0003iw-Oo; Fri, 06 Feb 2004 19:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApGch-0003hi-ET for pana@optimus.ietf.org; Fri, 06 Feb 2004 19:47: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 TAA01774 for ; Fri, 6 Feb 2004 19:47:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApGcf-0000mf-00 for pana@ietf.org; Fri, 06 Feb 2004 19:47:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApGbh-0000ja-00 for pana@ietf.org; Fri, 06 Feb 2004 19:46:01 -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 1ApGah-0000eg-00 for pana@ietf.org; Fri, 06 Feb 2004 19:45:00 -0500 Date: Fri, 06 Feb 2004 16:45:09 -0800 From: Alper Yegin To: Jari Arkko , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] issue58: Fast-reauthentication and authorization issues 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 >> From Jari Arkko: >> - "Fast-reauthentication and authorization issues" >> >> I have reservations about the inclusion of the fast >> re-authentication scheme in the base PANA document. There are >> a number of security issues at the system level when you try >> to do this. See draft-ietf-eap-keying-01.txt, Sections 1.4 and >> 1.4.1 in particular for some examples. >> >> Note also that many EAP methods provide fast re-authentication. The method we are proposing is described as "fast handoff" in the eap-keying draft. You are right that there are system level issues, and section "1.4.1 Correctness in fast handoff" elaborates on that. I think we should minimally update the text to take people's attention to these issues. I think the eap-keying draft is identifying this scenario, but also warning about several limitations and considerations. The other relevant text is in the Appendix E. AAA-key derivation. Although the eap-keying draft identifies two different approaches to fast handoffs (namely, based on context transfers, and pre-emptive state distribution), the appendix only outlines how keys are generated for the latter case. Note that PANA is using the former approach. As I understand simply passing MSK (or AAA-key) from one PAA to another is not recommended. So, we'd need to specify how derivative keys are generated for this. So, overall I'm under the impression that what PANA aims is an application of so-called fast handoffs as defined in eap-keying draft. Providing the above enhancements should be sufficient. Unless I'm missing something... What do you think? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Feb 6 20:33: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 UAA03760 for ; Fri, 6 Feb 2004 20:33: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 1ApHLA-0006hP-GG; Fri, 06 Feb 2004 20:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHKH-0006g9-S2 for pana@optimus.ietf.org; Fri, 06 Feb 2004 20:32: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 UAA03736 for ; Fri, 6 Feb 2004 20:32:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHKF-000443-00 for pana@ietf.org; Fri, 06 Feb 2004 20:32:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHJH-00040X-00 for pana@ietf.org; Fri, 06 Feb 2004 20:31:04 -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 1ApHII-0003vP-00 for pana@ietf.org; Fri, 06 Feb 2004 20:30:02 -0500 Date: Fri, 06 Feb 2004 17:30:12 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-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] issue54: Client cookie mandatory 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 > >> From Jari Arkko: >> - "Cookie mandatory" >> >> I would like the inclusion of the cookie to in the start >> exchange to be mandatory. JARI: (Substantial) Great, but why a MAY? There does not appear to be any performance of complexity penalty of calculating such simple cookies. Why not do it every time? In some environments, such as physically secured DSL networks, use of cookies is not necessary. If a PaC launches a DoS attack, it'd be really easy to detect and disable it. This is why we had made it a MAY. It is left to the operator to decide. Even though it is a low-cost operation, we thought operators might mind it given that they have alternative means. Maybe we should provide such explanations around it. Cookie = | HMAC_SHA1( | ) where is a randomly generated secret known only to the PAA, is an index used for choosing the secret for generating the cookie and '|' indicates concatenation. The secret- version should be changed frequently enough to prevent replay attacks. The secret key is locally known to the PAA only and valid for a certain time frame. JARI: (Question) Is there a need to ensure that the cookies for two different sessions with the same device are different? The above does not provide that. The cookie does not have any significance other than proving that the sender really received and processed the previous message. So I think using the same cookie even when the PaC is engaged in two separate sessions is fine. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Feb 6 20:34: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 UAA03785 for ; Fri, 6 Feb 2004 20:34: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 1ApHMH-0006ky-WD for pana-archive@odin.ietf.org; Fri, 06 Feb 2004 20:34:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i171Y9ZP025968 for pana-archive@odin.ietf.org; Fri, 6 Feb 2004 20:34:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHMH-0006kl-SM for pana-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 20:34: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 UAA03781 for ; Fri, 6 Feb 2004 20:34:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHMF-0004AW-00 for pana-web-archive@ietf.org; Fri, 06 Feb 2004 20:34:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHLH-00047d-00 for pana-web-archive@ietf.org; Fri, 06 Feb 2004 20:33:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApHLA-00044p-00 for pana-web-archive@ietf.org; Fri, 06 Feb 2004 20:33:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHLA-0006hP-GG; Fri, 06 Feb 2004 20:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHKH-0006g9-S2 for pana@optimus.ietf.org; Fri, 06 Feb 2004 20:32: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 UAA03736 for ; Fri, 6 Feb 2004 20:32:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHKF-000443-00 for pana@ietf.org; Fri, 06 Feb 2004 20:32:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHJH-00040X-00 for pana@ietf.org; Fri, 06 Feb 2004 20:31:04 -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 1ApHII-0003vP-00 for pana@ietf.org; Fri, 06 Feb 2004 20:30:02 -0500 Date: Fri, 06 Feb 2004 17:30:12 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] issue54: Client cookie mandatory 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 > >> From Jari Arkko: >> - "Cookie mandatory" >> >> I would like the inclusion of the cookie to in the start >> exchange to be mandatory. JARI: (Substantial) Great, but why a MAY? There does not appear to be any performance of complexity penalty of calculating such simple cookies. Why not do it every time? In some environments, such as physically secured DSL networks, use of cookies is not necessary. If a PaC launches a DoS attack, it'd be really easy to detect and disable it. This is why we had made it a MAY. It is left to the operator to decide. Even though it is a low-cost operation, we thought operators might mind it given that they have alternative means. Maybe we should provide such explanations around it. Cookie = | HMAC_SHA1( | ) where is a randomly generated secret known only to the PAA, is an index used for choosing the secret for generating the cookie and '|' indicates concatenation. The secret- version should be changed frequently enough to prevent replay attacks. The secret key is locally known to the PAA only and valid for a certain time frame. JARI: (Question) Is there a need to ensure that the cookies for two different sessions with the same device are different? The above does not provide that. The cookie does not have any significance other than proving that the sender really received and processed the previous message. So I think using the same cookie even when the PaC is engaged in two separate sessions is fine. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Feb 6 20:44: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 UAA04049 for ; Fri, 6 Feb 2004 20:44: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 1ApHVp-0007q3-2Z; Fri, 06 Feb 2004 20:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHUw-0007oc-QG for pana@optimus.ietf.org; Fri, 06 Feb 2004 20:43: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 UAA04026 for ; Fri, 6 Feb 2004 20:43:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHUu-0004d9-00 for pana@ietf.org; Fri, 06 Feb 2004 20:43:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHU0-0004aa-00 for pana@ietf.org; Fri, 06 Feb 2004 20:42:09 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ApHTG-0004Xa-00 for pana@ietf.org; Fri, 06 Feb 2004 20:41:23 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 797616A906; Sat, 7 Feb 2004 03:41:17 +0200 (EET) Message-ID: <402441DB.3090200@piuha.net> Date: Sat, 07 Feb 2004 03:39:39 +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] issue54: Client cookie mandatory References: In-Reply-To: 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.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 Alper Yegin wrote: >>>From Jari Arkko: >>> - "Cookie mandatory" >>> >>> I would like the inclusion of the cookie to in the start >>> exchange to be mandatory. > > > JARI: (Substantial) Great, but why a MAY? There does not appear to > be any performance of complexity penalty of calculating > such simple cookies. Why not do it every time? > > In some environments, such as physically secured DSL networks, use of > cookies is not necessary. If a PaC launches a DoS attack, it'd be really > easy to detect and disable it. This is why we had made it a MAY. It is left > to the operator to decide. Even though it is a low-cost operation, we > thought operators might mind it given that they have alternative means. > Maybe we should provide such explanations around it. I understand, but I think the tradeoff is not good enough. It costs very little, but making it optional implies another type of cost in terms of configuration knobs, interop testing, danger of the configuration knob being set wrong, and so forth. The less moving parts, the better... --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Feb 6 20:45: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 UAA04086 for ; Fri, 6 Feb 2004 20:45:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHWw-00085h-I8 for pana-archive@odin.ietf.org; Fri, 06 Feb 2004 20:45:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i171jADT031095 for pana-archive@odin.ietf.org; Fri, 6 Feb 2004 20:45:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHWw-00085Q-Dn for pana-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 20:45: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 UAA04083 for ; Fri, 6 Feb 2004 20:45:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHWu-0004kn-00 for pana-web-archive@ietf.org; Fri, 06 Feb 2004 20:45:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHVy-0004hr-00 for pana-web-archive@ietf.org; Fri, 06 Feb 2004 20:44:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApHVp-0004eX-00 for pana-web-archive@ietf.org; Fri, 06 Feb 2004 20:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHVp-0007q3-2Z; Fri, 06 Feb 2004 20:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHUw-0007oc-QG for pana@optimus.ietf.org; Fri, 06 Feb 2004 20:43: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 UAA04026 for ; Fri, 6 Feb 2004 20:43:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHUu-0004d9-00 for pana@ietf.org; Fri, 06 Feb 2004 20:43:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHU0-0004aa-00 for pana@ietf.org; Fri, 06 Feb 2004 20:42:09 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ApHTG-0004Xa-00 for pana@ietf.org; Fri, 06 Feb 2004 20:41:23 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 797616A906; Sat, 7 Feb 2004 03:41:17 +0200 (EET) Message-ID: <402441DB.3090200@piuha.net> Date: Sat, 07 Feb 2004 03:39:39 +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] issue54: Client cookie mandatory References: In-Reply-To: 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alper Yegin wrote: >>>From Jari Arkko: >>> - "Cookie mandatory" >>> >>> I would like the inclusion of the cookie to in the start >>> exchange to be mandatory. > > > JARI: (Substantial) Great, but why a MAY? There does not appear to > be any performance of complexity penalty of calculating > such simple cookies. Why not do it every time? > > In some environments, such as physically secured DSL networks, use of > cookies is not necessary. If a PaC launches a DoS attack, it'd be really > easy to detect and disable it. This is why we had made it a MAY. It is left > to the operator to decide. Even though it is a low-cost operation, we > thought operators might mind it given that they have alternative means. > Maybe we should provide such explanations around it. I understand, but I think the tradeoff is not good enough. It costs very little, but making it optional implies another type of cost in terms of configuration knobs, interop testing, danger of the configuration knob being set wrong, and so forth. The less moving parts, the better... --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Feb 6 21:03: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 VAA04358 for ; Fri, 6 Feb 2004 21:03: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 1ApHoD-00006D-2y; Fri, 06 Feb 2004 21:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHnP-0008Vm-LT for pana@optimus.ietf.org; Fri, 06 Feb 2004 21:02: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 VAA04335 for ; Fri, 6 Feb 2004 21:02:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHnN-0005am-00 for pana@ietf.org; Fri, 06 Feb 2004 21:02:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHmR-0005XQ-00 for pana@ietf.org; Fri, 06 Feb 2004 21:01:12 -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 1ApHlU-0005UR-00 for pana@ietf.org; Fri, 06 Feb 2004 21:00:12 -0500 Date: Fri, 06 Feb 2004 18:00:22 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-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] issue55: Client cookie useful 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 >> From Jari Arkko: >> - "Client cookie useful?" >> >> Would it be useful for the client to provide its own cookie as >> well, such that for solicited PSRs, the client's cookie would >> be copied back. This would cost very little, but protect the >> client against blind PAA spoofing attempts. The type of DoS attacks between the PaCs and PAAs are not symmetrical. Unless protected against it, a PAA would engage in PANA with any PaC that initiates a session. On the other hand, a PaC would only engage in PANA with one PAA at a time for accessing the network it is attached on an interface. Therefore, the same DoS attack does not exist on the PaC. Also, if this means adding a cookie to PDI (PANA-PAA-Discover), I don't think this helps, because this is the first message sent and it is multicasted. Any node can respond to it, as many times as it likes. There is no return routability in this. If we want to shift the cookie exchange to later where unicast traffic begins between the PaC and PAA, I think this is too late as PaC can readily be victimized by the PAA stalling. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Feb 6 21:04: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 VAA04383 for ; Fri, 6 Feb 2004 21:04:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHpK-0000Ab-JR for pana-archive@odin.ietf.org; Fri, 06 Feb 2004 21:04:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1724ApZ000647 for pana-archive@odin.ietf.org; Fri, 6 Feb 2004 21:04:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHpK-0000AM-FJ for pana-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 21:04: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 VAA04379 for ; Fri, 6 Feb 2004 21:04:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHpI-0005hf-00 for pana-web-archive@ietf.org; Fri, 06 Feb 2004 21:04:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHoM-0005ei-00 for pana-web-archive@ietf.org; Fri, 06 Feb 2004 21:03:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApHoC-0005bb-00 for pana-web-archive@ietf.org; Fri, 06 Feb 2004 21:03:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHoD-00006D-2y; Fri, 06 Feb 2004 21:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApHnP-0008Vm-LT for pana@optimus.ietf.org; Fri, 06 Feb 2004 21:02: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 VAA04335 for ; Fri, 6 Feb 2004 21:02:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApHnN-0005am-00 for pana@ietf.org; Fri, 06 Feb 2004 21:02:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApHmR-0005XQ-00 for pana@ietf.org; Fri, 06 Feb 2004 21:01:12 -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 1ApHlU-0005UR-00 for pana@ietf.org; Fri, 06 Feb 2004 21:00:12 -0500 Date: Fri, 06 Feb 2004 18:00:22 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] issue55: Client cookie useful 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 >> From Jari Arkko: >> - "Client cookie useful?" >> >> Would it be useful for the client to provide its own cookie as >> well, such that for solicited PSRs, the client's cookie would >> be copied back. This would cost very little, but protect the >> client against blind PAA spoofing attempts. The type of DoS attacks between the PaCs and PAAs are not symmetrical. Unless protected against it, a PAA would engage in PANA with any PaC that initiates a session. On the other hand, a PaC would only engage in PANA with one PAA at a time for accessing the network it is attached on an interface. Therefore, the same DoS attack does not exist on the PaC. Also, if this means adding a cookie to PDI (PANA-PAA-Discover), I don't think this helps, because this is the first message sent and it is multicasted. Any node can respond to it, as many times as it likes. There is no return routability in this. If we want to shift the cookie exchange to later where unicast traffic begins between the PaC and PAA, I think this is too late as PaC can readily be victimized by the PAA stalling. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Feb 9 07:25: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 HAA15193 for ; Mon, 9 Feb 2004 07: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 1AqATF-0002j0-Ko; Mon, 09 Feb 2004 07: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 1AqASG-0002h7-35 for pana@optimus.ietf.org; Mon, 09 Feb 2004 07:24:00 -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 HAA15114 for ; Mon, 9 Feb 2004 07:23:58 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqASF-0006RC-00 for pana@ietf.org; Mon, 09 Feb 2004 07:23:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqARO-0006NA-00 for pana@ietf.org; Mon, 09 Feb 2004 07:23:06 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqARA-0006IX-00 for pana@ietf.org; Mon, 09 Feb 2004 07:22:52 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i19CMnv00917 for ; Mon, 9 Feb 2004 14:22:49 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Feb 2004 14:22:46 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 14:22:45 +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] issue54: Client cookie mandatory Date: Mon, 9 Feb 2004 14:22:44 +0200 Message-ID: Thread-Topic: [Pana] issue54: Client cookie mandatory Thread-Index: AcPtG+Sf2lMqpjqERXmq0ePNgbJilQB62VRw To: , Cc: X-OriginalArrivalTime: 09 Feb 2004 12:22:45.0120 (UTC) FILETIME=[6BEFE800:01C3EF07] 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 I tend to agree on this. - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > Jari Arkko > Sent: 07 February, 2004 03:40 > To: Alper Yegin > Cc: pana@ietf.org > Subject: Re: [Pana] issue54: Client cookie mandatory >=20 >=20 > Alper Yegin wrote: > >>>From Jari Arkko: > >>> - "Cookie mandatory" > >>> > >>> I would like the inclusion of the cookie to in the start > >>> exchange to be mandatory. > >=20 > >=20 > > JARI: (Substantial) Great, but why a MAY? There does not appear to > > be any performance of complexity penalty of calculating > > such simple cookies. Why not do it every time? > >=20 > > In some environments, such as physically secured DSL=20 > networks, use of > > cookies is not necessary. If a PaC launches a DoS attack,=20 > it'd be really > > easy to detect and disable it. This is why we had made it a=20 > MAY. It is left > > to the operator to decide. Even though it is a low-cost=20 > operation, we > > thought operators might mind it given that they have=20 > alternative means. > > Maybe we should provide such explanations around it. >=20 > I understand, but I think the tradeoff is not good enough. It > costs very little, but making it optional implies another type > of cost in terms of configuration knobs, interop testing, danger > of the configuration knob being set wrong, and so forth. >=20 > The less moving parts, the better... >=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 Mon Feb 9 07:27: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 HAA15280 for ; Mon, 9 Feb 2004 07:27: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 1AqAVA-0002p4-RF for pana-archive@odin.ietf.org; Mon, 09 Feb 2004 07:27:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19CR0Bi010844 for pana-archive@odin.ietf.org; Mon, 9 Feb 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 1AqAVA-0002op-L6 for pana-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 07:27:00 -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 HAA15249 for ; Mon, 9 Feb 2004 07:26:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqAVA-0006hX-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 07:27:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqAUH-0006cP-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 07:26:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqATI-0006XL-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 07:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqATF-0002j0-Ko; Mon, 09 Feb 2004 07: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 1AqASG-0002h7-35 for pana@optimus.ietf.org; Mon, 09 Feb 2004 07:24:00 -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 HAA15114 for ; Mon, 9 Feb 2004 07:23:58 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqASF-0006RC-00 for pana@ietf.org; Mon, 09 Feb 2004 07:23:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqARO-0006NA-00 for pana@ietf.org; Mon, 09 Feb 2004 07:23:06 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqARA-0006IX-00 for pana@ietf.org; Mon, 09 Feb 2004 07:22:52 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i19CMnv00917 for ; Mon, 9 Feb 2004 14:22:49 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Feb 2004 14:22:46 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 14:22:45 +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] issue54: Client cookie mandatory Date: Mon, 9 Feb 2004 14:22:44 +0200 Message-ID: Thread-Topic: [Pana] issue54: Client cookie mandatory Thread-Index: AcPtG+Sf2lMqpjqERXmq0ePNgbJilQB62VRw To: , Cc: X-OriginalArrivalTime: 09 Feb 2004 12:22:45.0120 (UTC) FILETIME=[6BEFE800:01C3EF07] 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 I tend to agree on this. - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > Jari Arkko > Sent: 07 February, 2004 03:40 > To: Alper Yegin > Cc: pana@ietf.org > Subject: Re: [Pana] issue54: Client cookie mandatory >=20 >=20 > Alper Yegin wrote: > >>>From Jari Arkko: > >>> - "Cookie mandatory" > >>> > >>> I would like the inclusion of the cookie to in the start > >>> exchange to be mandatory. > >=20 > >=20 > > JARI: (Substantial) Great, but why a MAY? There does not appear to > > be any performance of complexity penalty of calculating > > such simple cookies. Why not do it every time? > >=20 > > In some environments, such as physically secured DSL=20 > networks, use of > > cookies is not necessary. If a PaC launches a DoS attack,=20 > it'd be really > > easy to detect and disable it. This is why we had made it a=20 > MAY. It is left > > to the operator to decide. Even though it is a low-cost=20 > operation, we > > thought operators might mind it given that they have=20 > alternative means. > > Maybe we should provide such explanations around it. >=20 > I understand, but I think the tradeoff is not good enough. It > costs very little, but making it optional implies another type > of cost in terms of configuration knobs, interop testing, danger > of the configuration knob being set wrong, and so forth. >=20 > The less moving parts, the better... >=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 Mon Feb 9 08: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 IAA17898 for ; Mon, 9 Feb 2004 08: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 1AqBUE-0000BE-En; Mon, 09 Feb 2004 08:30:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBTF-0006O7-M0 for pana@optimus.ietf.org; Mon, 09 Feb 2004 08:29: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 IAA17878 for ; Mon, 9 Feb 2004 08:29: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 1AqBTE-0005F5-00 for pana@ietf.org; Mon, 09 Feb 2004 08:29:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqBSI-00059E-00 for pana@ietf.org; Mon, 09 Feb 2004 08:28:06 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqBRZ-00054a-00 for pana@ietf.org; Mon, 09 Feb 2004 08:27:21 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i19DRKq16908 for ; Mon, 9 Feb 2004 15:27:20 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 9 Feb 2004 15:27:18 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 15:27:18 +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: Mon, 9 Feb 2004 15:27:16 +0200 Message-ID: Thread-Topic: [issue60] AAA-Key versus MSK Thread-Index: AcPvDEjHhZP5vHmhTqmu7B1ldRrpEwABB7kA To: X-OriginalArrivalTime: 09 Feb 2004 13:27:18.0324 (UTC) FILETIME=[708BEF40:01C3EF10] 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: [issue60] AAA-Key versus MSK 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpJIHRoaW5rIEhhbm5lcycgcG9pbnQgaXMgdmFsaWQuICBTaW5jZSBlYXAga2V5aW5nIGRy YWZ0IG1hZGUgYSBkaXN0aW5jdGlvbiANCmJldHdlZW4gQUFBLUtleSBhbmQgTVNLLCBpdCBzaG91 bGQgYmUgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBrZXlpbmcgZHJhZnQgDQp0byBkZWZpbmUg YW4gYWxnb3JpdGhtIHRvIHVuYW1iaWd1b3VzbHkgY2FsY3VsYXRlIEFBQS1LZXkgZnJvbSBNU0su DQoNCkkgdGhpbmsgd2UgY2FuIHNpbXBseToNCg0KLSBSZXBsYWNlICJNU0siIGluIHRoZSBQQU5B IHNwZWNpZmljYXRpb24gZHJhZnQgd2l0aCAiQUFBLUtleSINCg0KYW5kDQoNCi0gQXNrIEVBUCBL ZXlpbmcgZGVzaWduIHRlYW0gdG8gZGVmaW5lIGFuIGFsZ29yaXRobSAob3IgYWxnb3JpdGhtcywN CiAgb25lIHBlciB1c2FnZSBjYXNlPykgdG8gZGVyaXZlIEFBQS1LZXkgZnJvbSBNU0suDQoNCk5v dGUgdGhhdCB0aGUgc2FtZSB0aGluZyB3b3VsZCBhbHNvIGFwcGx5IHRvIHBhbmEtaXBzZWMgZHJh ZnQuDQoNCllvc2hpaGlybyBPaGJhDQoNCi0tLS0tLS0tLS0NCmNhdGVnb3J5OiBUZWNobmljYWwN CmRvY3VtZW50OiBkcmFmdC1pZXRmLXBhbmEtcGFuYS14eC50eHQNCm1lc3NhZ2VzOiAyMDENCm5v c3k6IGRmb3JzYmVyDQpwcmlvcml0eTogTXVzdCBGaXgNCnN0YXR1czogQ2xhcmlmeWluZyBUZXh0 IFJlcXVpcmVkDQp0aXRsZTogQUFBLUtleSB2ZXJzdXMgTVNLDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUEFOQSBJc3N1ZXMgPHBhbmFfaXNzdWVz QGRhbmZvcnNiZXJnLmluZm8+DQo8aHR0cDovL2RhbmZvcnNiZXJnLmluZm86ODA4MC9wYW5hLWlz c3Vlcy9pc3N1ZTYwPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Feb 9 08:32: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 IAA17989 for ; Mon, 9 Feb 2004 08:32: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 1AqBW9-0000Y0-C6 for pana-archive@odin.ietf.org; Mon, 09 Feb 2004 08:32:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19DW5bc002098 for pana-archive@odin.ietf.org; Mon, 9 Feb 2004 08:32:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBW9-0000Xl-6q for pana-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 08:32: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 IAA17966 for ; Mon, 9 Feb 2004 08:32:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqBW8-0005d3-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 08:32:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqBVC-0005V4-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 08:31:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqBUG-0005Lm-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 08: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 1AqBUE-0000BE-En; Mon, 09 Feb 2004 08:30:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqBTF-0006O7-M0 for pana@optimus.ietf.org; Mon, 09 Feb 2004 08:29: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 IAA17878 for ; Mon, 9 Feb 2004 08:29: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 1AqBTE-0005F5-00 for pana@ietf.org; Mon, 09 Feb 2004 08:29:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqBSI-00059E-00 for pana@ietf.org; Mon, 09 Feb 2004 08:28:06 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqBRZ-00054a-00 for pana@ietf.org; Mon, 09 Feb 2004 08:27:21 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i19DRKq16908 for ; Mon, 9 Feb 2004 15:27:20 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 9 Feb 2004 15:27:18 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 9 Feb 2004 15:27:18 +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: Mon, 9 Feb 2004 15:27:16 +0200 Message-ID: Thread-Topic: [issue60] AAA-Key versus MSK Thread-Index: AcPvDEjHhZP5vHmhTqmu7B1ldRrpEwABB7kA To: X-OriginalArrivalTime: 09 Feb 2004 13:27:18.0324 (UTC) FILETIME=[708BEF40:01C3EF10] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue60] AAA-Key versus MSK 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpJIHRoaW5rIEhhbm5lcycgcG9pbnQgaXMgdmFsaWQuICBTaW5jZSBlYXAga2V5aW5nIGRy YWZ0IG1hZGUgYSBkaXN0aW5jdGlvbiANCmJldHdlZW4gQUFBLUtleSBhbmQgTVNLLCBpdCBzaG91 bGQgYmUgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBrZXlpbmcgZHJhZnQgDQp0byBkZWZpbmUg YW4gYWxnb3JpdGhtIHRvIHVuYW1iaWd1b3VzbHkgY2FsY3VsYXRlIEFBQS1LZXkgZnJvbSBNU0su DQoNCkkgdGhpbmsgd2UgY2FuIHNpbXBseToNCg0KLSBSZXBsYWNlICJNU0siIGluIHRoZSBQQU5B IHNwZWNpZmljYXRpb24gZHJhZnQgd2l0aCAiQUFBLUtleSINCg0KYW5kDQoNCi0gQXNrIEVBUCBL ZXlpbmcgZGVzaWduIHRlYW0gdG8gZGVmaW5lIGFuIGFsZ29yaXRobSAob3IgYWxnb3JpdGhtcywN CiAgb25lIHBlciB1c2FnZSBjYXNlPykgdG8gZGVyaXZlIEFBQS1LZXkgZnJvbSBNU0suDQoNCk5v dGUgdGhhdCB0aGUgc2FtZSB0aGluZyB3b3VsZCBhbHNvIGFwcGx5IHRvIHBhbmEtaXBzZWMgZHJh ZnQuDQoNCllvc2hpaGlybyBPaGJhDQoNCi0tLS0tLS0tLS0NCmNhdGVnb3J5OiBUZWNobmljYWwN CmRvY3VtZW50OiBkcmFmdC1pZXRmLXBhbmEtcGFuYS14eC50eHQNCm1lc3NhZ2VzOiAyMDENCm5v c3k6IGRmb3JzYmVyDQpwcmlvcml0eTogTXVzdCBGaXgNCnN0YXR1czogQ2xhcmlmeWluZyBUZXh0 IFJlcXVpcmVkDQp0aXRsZTogQUFBLUtleSB2ZXJzdXMgTVNLDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUEFOQSBJc3N1ZXMgPHBhbmFfaXNzdWVz QGRhbmZvcnNiZXJnLmluZm8+DQo8aHR0cDovL2RhbmZvcnNiZXJnLmluZm86ODA4MC9wYW5hLWlz c3Vlcy9pc3N1ZTYwPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Feb 9 09:09: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 JAA19871 for ; Mon, 9 Feb 2004 09:09:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqC5s-0003wS-Kh; Mon, 09 Feb 2004 09: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 1AqC4y-0003na-GJ for pana@optimus.ietf.org; Mon, 09 Feb 2004 09:08: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 JAA19802 for ; Mon, 9 Feb 2004 09:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqC4w-0001Mw-00 for pana@ietf.org; Mon, 09 Feb 2004 09:08:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqC40-0001HV-00 for pana@ietf.org; Mon, 09 Feb 2004 09:07:05 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AqC3C-0001CP-00 for pana@ietf.org; Mon, 09 Feb 2004 09:06:14 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id E4D8E6A901; Mon, 9 Feb 2004 16:06:12 +0200 (EET) Message-ID: <4027936E.90807@piuha.net> Date: Mon, 09 Feb 2004 16:04:30 +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: Dan.Forsberg@nokia.com Cc: pana@ietf.org Subject: Re: [Pana] NEW: [issue60] AAA-Key versus MSK References: In-Reply-To: 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 Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > I think Hannes' point is valid. Since eap keying draft made a distinction > between AAA-Key and MSK, it should be the responsibility of the keying draft > to define an algorithm to unambiguously calculate AAA-Key from MSK. > > I think we can simply: > > - Replace "MSK" in the PANA specification draft with "AAA-Key" > > and > > - Ask EAP Keying design team to define an algorithm (or algorithms, > one per usage case?) to derive AAA-Key from MSK. This seems appropriate. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Feb 9 09:11: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 JAA19937 for ; Mon, 9 Feb 2004 09:11: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 1AqC7r-00045Q-Ad for pana-archive@odin.ietf.org; Mon, 09 Feb 2004 09:11:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19EB3XX015702 for pana-archive@odin.ietf.org; Mon, 9 Feb 2004 09:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqC7r-00045B-1g for pana-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 09:11: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 JAA19901 for ; Mon, 9 Feb 2004 09:11:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqC7p-0001cR-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 09:11:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqC6s-0001XA-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 09:10:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqC62-0001SV-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 09:09:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqC5s-0003wS-Kh; Mon, 09 Feb 2004 09: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 1AqC4y-0003na-GJ for pana@optimus.ietf.org; Mon, 09 Feb 2004 09:08: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 JAA19802 for ; Mon, 9 Feb 2004 09:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqC4w-0001Mw-00 for pana@ietf.org; Mon, 09 Feb 2004 09:08:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqC40-0001HV-00 for pana@ietf.org; Mon, 09 Feb 2004 09:07:05 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AqC3C-0001CP-00 for pana@ietf.org; Mon, 09 Feb 2004 09:06:14 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id E4D8E6A901; Mon, 9 Feb 2004 16:06:12 +0200 (EET) Message-ID: <4027936E.90807@piuha.net> Date: Mon, 09 Feb 2004 16:04:30 +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: Dan.Forsberg@nokia.com Cc: pana@ietf.org Subject: Re: [Pana] NEW: [issue60] AAA-Key versus MSK References: In-Reply-To: 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 Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > I think Hannes' point is valid. Since eap keying draft made a distinction > between AAA-Key and MSK, it should be the responsibility of the keying draft > to define an algorithm to unambiguously calculate AAA-Key from MSK. > > I think we can simply: > > - Replace "MSK" in the PANA specification draft with "AAA-Key" > > and > > - Ask EAP Keying design team to define an algorithm (or algorithms, > one per usage case?) to derive AAA-Key from MSK. This seems appropriate. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Feb 9 10:18: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 KAA23529 for ; Mon, 9 Feb 2004 10:18: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 1AqDAf-0005FX-HY; Mon, 09 Feb 2004 10: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 1AqD9m-000535-MR for pana@optimus.ietf.org; Mon, 09 Feb 2004 10:17: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 KAA23406 for ; Mon, 9 Feb 2004 10:17:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqD9k-0007B1-00 for pana@ietf.org; Mon, 09 Feb 2004 10:17:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqD8m-000779-00 for pana@ietf.org; Mon, 09 Feb 2004 10:16:05 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AqD7u-00073O-00 for pana@ietf.org; Mon, 09 Feb 2004 10:15:10 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i19FF7Gv008485; Tue, 10 Feb 2004 00:15:07 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i19FF70r020320; Tue, 10 Feb 2004 00:15:07 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA20317 ; Tue, 10 Feb 2004 00:15:07 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA06968; Tue, 10 Feb 2004 00:15:07 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id AAA22818; Tue, 10 Feb 2004 00:15:06 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i19FF5QX011112; Tue, 10 Feb 2004 00:15:05 +0900 (JST) Received: from steelhead ([159.119.168.70]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HST00DCWP138E@tsbpo1.po.toshiba.co.jp>; Tue, 10 Feb 2004 00:15:04 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AqD6C-0002D0-00; Mon, 09 Feb 2004 07:13:24 -0800 Date: Mon, 09 Feb 2004 07:13:21 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue60] AAA-Key versus MSK In-reply-to: <4027936E.90807@piuha.net> To: Jari Arkko Cc: Dan.Forsberg@nokia.com, pana@ietf.org Message-id: <20040209151321.GK1745@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Jari Arkko , Dan.Forsberg@nokia.com, pana@ietf.org User-Agent: Mutt/1.5.4i References: <4027936E.90807@piuha.net> 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: , OK. I will do the editorial change on this and submit -03 draft. Thanks, Yoshihiro Ohba On Mon, Feb 09, 2004 at 04:04:30PM +0200, Jari Arkko wrote: > Dan.Forsberg@nokia.com wrote: > >New submission from Dan Forsberg : > > > >I think Hannes' point is valid. Since eap keying draft made a distinction > >between AAA-Key and MSK, it should be the responsibility of the keying > >draft to define an algorithm to unambiguously calculate AAA-Key from MSK. > > > >I think we can simply: > > > >- Replace "MSK" in the PANA specification draft with "AAA-Key" > > > >and > > > >- Ask EAP Keying design team to define an algorithm (or algorithms, > > one per usage case?) to derive AAA-Key from MSK. > > This seems appropriate. > > --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 Feb 9 10:20: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 KAA23690 for ; Mon, 9 Feb 2004 10:20: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 1AqDCg-0005z6-KM for pana-archive@odin.ietf.org; Mon, 09 Feb 2004 10:20:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19FK66k022982 for pana-archive@odin.ietf.org; Mon, 9 Feb 2004 10:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDCf-0005yZ-BB for pana-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 10:20: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 KAA23642 for ; Mon, 9 Feb 2004 10:20:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqDCd-0007Ok-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 10:20:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqDBe-0007JH-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 10:19:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqDAg-0007EV-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 10:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqDAf-0005FX-HY; Mon, 09 Feb 2004 10: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 1AqD9m-000535-MR for pana@optimus.ietf.org; Mon, 09 Feb 2004 10:17: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 KAA23406 for ; Mon, 9 Feb 2004 10:17:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqD9k-0007B1-00 for pana@ietf.org; Mon, 09 Feb 2004 10:17:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqD8m-000779-00 for pana@ietf.org; Mon, 09 Feb 2004 10:16:05 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AqD7u-00073O-00 for pana@ietf.org; Mon, 09 Feb 2004 10:15:10 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i19FF7Gv008485; Tue, 10 Feb 2004 00:15:07 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i19FF70r020320; Tue, 10 Feb 2004 00:15:07 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA20317 ; Tue, 10 Feb 2004 00:15:07 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA06968; Tue, 10 Feb 2004 00:15:07 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id AAA22818; Tue, 10 Feb 2004 00:15:06 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i19FF5QX011112; Tue, 10 Feb 2004 00:15:05 +0900 (JST) Received: from steelhead ([159.119.168.70]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HST00DCWP138E@tsbpo1.po.toshiba.co.jp>; Tue, 10 Feb 2004 00:15:04 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AqD6C-0002D0-00; Mon, 09 Feb 2004 07:13:24 -0800 Date: Mon, 09 Feb 2004 07:13:21 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue60] AAA-Key versus MSK In-reply-to: <4027936E.90807@piuha.net> To: Jari Arkko Cc: Dan.Forsberg@nokia.com, pana@ietf.org Message-id: <20040209151321.GK1745@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Jari Arkko , Dan.Forsberg@nokia.com, pana@ietf.org User-Agent: Mutt/1.5.4i References: <4027936E.90807@piuha.net> 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 OK. I will do the editorial change on this and submit -03 draft. Thanks, Yoshihiro Ohba On Mon, Feb 09, 2004 at 04:04:30PM +0200, Jari Arkko wrote: > Dan.Forsberg@nokia.com wrote: > >New submission from Dan Forsberg : > > > >I think Hannes' point is valid. Since eap keying draft made a distinction > >between AAA-Key and MSK, it should be the responsibility of the keying > >draft to define an algorithm to unambiguously calculate AAA-Key from MSK. > > > >I think we can simply: > > > >- Replace "MSK" in the PANA specification draft with "AAA-Key" > > > >and > > > >- Ask EAP Keying design team to define an algorithm (or algorithms, > > one per usage case?) to derive AAA-Key from MSK. > > This seems appropriate. > > --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 Feb 9 11:35: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 LAA26623 for ; Mon, 9 Feb 2004 11:35: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 1AqEND-0003CZ-U8; Mon, 09 Feb 2004 11:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEMT-00037W-Uj for pana@optimus.ietf.org; Mon, 09 Feb 2004 11:34: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 LAA26292 for ; Mon, 9 Feb 2004 11:34:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEMS-0006De-00 for pana@ietf.org; Mon, 09 Feb 2004 11:34:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEJw-0005oR-00 for pana@ietf.org; Mon, 09 Feb 2004 11:31:40 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AqEIs-0005ep-00 for pana@ietf.org; Mon, 09 Feb 2004 11:30:35 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i19GUWGv004194; Tue, 10 Feb 2004 01:30:32 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i19GUWd4021534; Tue, 10 Feb 2004 01:30:32 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA21533 ; Tue, 10 Feb 2004 01:30:32 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA28293; Tue, 10 Feb 2004 01:30:31 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA25415; Tue, 10 Feb 2004 01:30:31 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i19GUUQX010830; Tue, 10 Feb 2004 01:30:30 +0900 (JST) Received: from steelhead ([159.119.168.70]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HST00HRJSISYB@tsbpo1.po.toshiba.co.jp>; Tue, 10 Feb 2004 01:30:29 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AqEHJ-0002Yk-00; Mon, 09 Feb 2004 08:28:57 -0800 Date: Mon, 09 Feb 2004 08:28:57 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040209162857.GN1745@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.4i 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] [pana-ipsec] ID_KEY_ID 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: , In Section 5: "Aggressive mode with pre-shared key MUST be supported. PaC and EP SHOULD use its PANA session ID [PANA-PROT] as the payload of ID_KEY_ID in aggressive mode for establishing the phase I SA." Since a PANA session can generate a fresh IKE pre-shared secret when a AAA-Key (or an MSK in the current draft) is updated, I think the payload of ID_KEY_ID should include not only PANA Session-Id but also the value of PANA Key-Id AVP to uniquely identify different versions of IKE pre-shared secrets within a PANA session. (Also, the word "MSK" in pana-ipsec draft should be replaced with "AAA-Key".) Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Feb 9 11:38: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 LAA26948 for ; Mon, 9 Feb 2004 11:38: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 1AqEQR-0003y5-Qr for pana-archive@odin.ietf.org; Mon, 09 Feb 2004 11:38:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19GcNbF015247 for pana-archive@odin.ietf.org; Mon, 9 Feb 2004 11:38:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEQR-0003xq-Ds for pana-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 11:38: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 LAA26853 for ; Mon, 9 Feb 2004 11:38:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEQQ-00077I-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 11:38:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEOU-0006iU-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 11:36:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqENI-0006PB-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 11:35:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEND-0003CZ-U8; Mon, 09 Feb 2004 11:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEMT-00037W-Uj for pana@optimus.ietf.org; Mon, 09 Feb 2004 11:34: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 LAA26292 for ; Mon, 9 Feb 2004 11:34:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEMS-0006De-00 for pana@ietf.org; Mon, 09 Feb 2004 11:34:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEJw-0005oR-00 for pana@ietf.org; Mon, 09 Feb 2004 11:31:40 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AqEIs-0005ep-00 for pana@ietf.org; Mon, 09 Feb 2004 11:30:35 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i19GUWGv004194; Tue, 10 Feb 2004 01:30:32 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i19GUWd4021534; Tue, 10 Feb 2004 01:30:32 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA21533 ; Tue, 10 Feb 2004 01:30:32 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA28293; Tue, 10 Feb 2004 01:30:31 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA25415; Tue, 10 Feb 2004 01:30:31 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i19GUUQX010830; Tue, 10 Feb 2004 01:30:30 +0900 (JST) Received: from steelhead ([159.119.168.70]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HST00HRJSISYB@tsbpo1.po.toshiba.co.jp>; Tue, 10 Feb 2004 01:30:29 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AqEHJ-0002Yk-00; Mon, 09 Feb 2004 08:28:57 -0800 Date: Mon, 09 Feb 2004 08:28:57 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040209162857.GN1745@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.4i Subject: [Pana] [pana-ipsec] ID_KEY_ID 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 In Section 5: "Aggressive mode with pre-shared key MUST be supported. PaC and EP SHOULD use its PANA session ID [PANA-PROT] as the payload of ID_KEY_ID in aggressive mode for establishing the phase I SA." Since a PANA session can generate a fresh IKE pre-shared secret when a AAA-Key (or an MSK in the current draft) is updated, I think the payload of ID_KEY_ID should include not only PANA Session-Id but also the value of PANA Key-Id AVP to uniquely identify different versions of IKE pre-shared secrets within a PANA session. (Also, the word "MSK" in pana-ipsec draft should be replaced with "AAA-Key".) Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Feb 9 12:39: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 MAA29916 for ; Mon, 9 Feb 2004 12:39: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 1AqFN7-0001Vw-A1; Mon, 09 Feb 2004 12: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 1AqFMN-0001Hc-MC for pana@optimus.ietf.org; Mon, 09 Feb 2004 12:38: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 MAA29842 for ; Mon, 9 Feb 2004 12:38:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqFML-00056P-00 for pana@ietf.org; Mon, 09 Feb 2004 12:38:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqFLS-00051K-00 for pana@ietf.org; Mon, 09 Feb 2004 12:37:19 -0500 Received: from smtp805.mail.sc5.yahoo.com ([66.163.168.184]) by ietf-mx with smtp (Exim 4.12) id 1AqFKv-0004w7-00 for pana@ietf.org; Mon, 09 Feb 2004 12:36:45 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 9 Feb 2004 17:36:38 -0000 Message-ID: <001701c3ef33$46454060$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , References: <20040209162857.GN1745@steelhead> Subject: Re: [Pana] [pana-ipsec] ID_KEY_ID Date: Mon, 9 Feb 2004 09:36:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit 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=none 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 > In Section 5: > > "Aggressive mode with pre-shared key MUST be > supported. PaC and EP SHOULD use its PANA session ID [PANA-PROT] as > the payload of ID_KEY_ID in aggressive mode for establishing the > phase I SA." > > Since a PANA session can generate a fresh IKE pre-shared secret when a > AAA-Key (or an MSK in the current draft) is updated, I think the > payload of ID_KEY_ID should include not only PANA Session-Id but also > the value of PANA Key-Id AVP to uniquely identify different versions > of IKE pre-shared secrets within a PANA session. > > (Also, the word "MSK" in pana-ipsec draft should be replaced with > "AAA-Key".) Agreed. The next version should have these changes. I will also open an issue to track this. -mohan > > 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 Mon Feb 9 12:41: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 MAA00022 for ; Mon, 9 Feb 2004 12:41: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 1AqFOf-0001iE-5f for pana-archive@odin.ietf.org; Mon, 09 Feb 2004 12:40:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19Hebf7006576 for pana-archive@odin.ietf.org; Mon, 9 Feb 2004 12:40:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFOe-0001hz-VU for pana-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 12:40:37 -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 MAA29987 for ; Mon, 9 Feb 2004 12:40:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqFOd-0005Lm-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 12:40:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqFNq-0005FK-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 12:39:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqFN8-00057t-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 12:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFN7-0001Vw-A1; Mon, 09 Feb 2004 12: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 1AqFMN-0001Hc-MC for pana@optimus.ietf.org; Mon, 09 Feb 2004 12:38: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 MAA29842 for ; Mon, 9 Feb 2004 12:38:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqFML-00056P-00 for pana@ietf.org; Mon, 09 Feb 2004 12:38:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqFLS-00051K-00 for pana@ietf.org; Mon, 09 Feb 2004 12:37:19 -0500 Received: from smtp805.mail.sc5.yahoo.com ([66.163.168.184]) by ietf-mx with smtp (Exim 4.12) id 1AqFKv-0004w7-00 for pana@ietf.org; Mon, 09 Feb 2004 12:36:45 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.16.104 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 9 Feb 2004 17:36:38 -0000 Message-ID: <001701c3ef33$46454060$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , References: <20040209162857.GN1745@steelhead> Subject: Re: [Pana] [pana-ipsec] ID_KEY_ID Date: Mon, 9 Feb 2004 09:36:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit 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: 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > In Section 5: > > "Aggressive mode with pre-shared key MUST be > supported. PaC and EP SHOULD use its PANA session ID [PANA-PROT] as > the payload of ID_KEY_ID in aggressive mode for establishing the > phase I SA." > > Since a PANA session can generate a fresh IKE pre-shared secret when a > AAA-Key (or an MSK in the current draft) is updated, I think the > payload of ID_KEY_ID should include not only PANA Session-Id but also > the value of PANA Key-Id AVP to uniquely identify different versions > of IKE pre-shared secrets within a PANA session. > > (Also, the word "MSK" in pana-ipsec draft should be replaced with > "AAA-Key".) Agreed. The next version should have these changes. I will also open an issue to track this. -mohan > > 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 Mon Feb 9 13:58: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 NAA04375 for ; Mon, 9 Feb 2004 13:58: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 1AqGbZ-0007TB-C7; Mon, 09 Feb 2004 13:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGam-0007QW-3l for pana@optimus.ietf.org; Mon, 09 Feb 2004 13:57:12 -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 NAA04343 for ; Mon, 9 Feb 2004 13:57:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGaj-0005nl-00 for pana@ietf.org; Mon, 09 Feb 2004 13:57:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGZl-0005ip-00 for pana@ietf.org; Mon, 09 Feb 2004 13:56:10 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AqGYp-0005dh-00 for pana@ietf.org; Mon, 09 Feb 2004 13:55:12 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i19ItBGv013625; Tue, 10 Feb 2004 03:55:11 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i19ItBtw007685; Tue, 10 Feb 2004 03:55:11 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA07684 ; Tue, 10 Feb 2004 03:55:10 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA10955; Tue, 10 Feb 2004 03:55:10 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA16578; Tue, 10 Feb 2004 03:55:10 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i19It9QX003249; Tue, 10 Feb 2004 03:55:09 +0900 (JST) Received: from steelhead ([159.119.168.187]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HST00LDNZ7VJ0@tsbpo1.po.toshiba.co.jp>; Tue, 10 Feb 2004 03:55:08 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AqGXs-0003hZ-00; Mon, 09 Feb 2004 10:54:12 -0800 Date: Mon, 09 Feb 2004 10:54:12 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040209185412.GS1745@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.4i 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] pana-pana-03 submitted 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: , draft-ietf-pana-pana-03.txt has been submitted. Until the draft appears in the I-D repository in a few days, you may now obtain a copy of the submitted manuscript from: http://www.toshiba.com/tari/pana/pana-spec.html Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Feb 9 13:59: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 NAA04407 for ; Mon, 9 Feb 2004 13:59: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 1AqGco-0007jI-VO for pana-archive@odin.ietf.org; Mon, 09 Feb 2004 13:59:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19IxIVF029706 for pana-archive@odin.ietf.org; Mon, 9 Feb 2004 13:59:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGco-0007j3-RD for pana-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 13:59:18 -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 NAA04399 for ; Mon, 9 Feb 2004 13:59:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGcm-0005xi-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 13:59:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGbm-0005t8-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 13:58:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqGbZ-0005p2-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 13:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGbZ-0007TB-C7; Mon, 09 Feb 2004 13:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqGam-0007QW-3l for pana@optimus.ietf.org; Mon, 09 Feb 2004 13:57:12 -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 NAA04343 for ; Mon, 9 Feb 2004 13:57:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqGaj-0005nl-00 for pana@ietf.org; Mon, 09 Feb 2004 13:57:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqGZl-0005ip-00 for pana@ietf.org; Mon, 09 Feb 2004 13:56:10 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AqGYp-0005dh-00 for pana@ietf.org; Mon, 09 Feb 2004 13:55:12 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i19ItBGv013625; Tue, 10 Feb 2004 03:55:11 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i19ItBtw007685; Tue, 10 Feb 2004 03:55:11 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA07684 ; Tue, 10 Feb 2004 03:55:10 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA10955; Tue, 10 Feb 2004 03:55:10 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA16578; Tue, 10 Feb 2004 03:55:10 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i19It9QX003249; Tue, 10 Feb 2004 03:55:09 +0900 (JST) Received: from steelhead ([159.119.168.187]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HST00LDNZ7VJ0@tsbpo1.po.toshiba.co.jp>; Tue, 10 Feb 2004 03:55:08 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AqGXs-0003hZ-00; Mon, 09 Feb 2004 10:54:12 -0800 Date: Mon, 09 Feb 2004 10:54:12 -0800 From: Yoshihiro Ohba To: pana@ietf.org Message-id: <20040209185412.GS1745@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.4i Subject: [Pana] pana-pana-03 submitted 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 draft-ietf-pana-pana-03.txt has been submitted. Until the draft appears in the I-D repository in a few days, you may now obtain a copy of the submitted manuscript from: http://www.toshiba.com/tari/pana/pana-spec.html Regards, Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Feb 9 16:22: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 QAA13925 for ; Mon, 9 Feb 2004 16:22: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 1AqIqw-0002ot-9Z; Mon, 09 Feb 2004 16:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIqF-0002ky-V3 for pana@optimus.ietf.org; Mon, 09 Feb 2004 16:21:19 -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 QAA13720 for ; Mon, 9 Feb 2004 16:21:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqIqE-0003Iv-00 for pana@ietf.org; Mon, 09 Feb 2004 16:21:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIoi-0002za-00 for pana@ietf.org; Mon, 09 Feb 2004 16:19:45 -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 1AqInk-0002nl-00 for pana@ietf.org; Mon, 09 Feb 2004 16:18:45 -0500 Date: Mon, 09 Feb 2004 13:18:47 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: <200402062042.PAA15236@ietf.org> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3159177531_31542251" 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] FW: I-D ACTION:draft-ohba-pana-framework-00.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: , > 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. --B_3159177531_31542251 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Please see the PANA Framework draft announcement below. This draft will be presented and discussed at the coming IETF meeting. WG members' early feedback to the mailing list is highly encouraged. Cheers, Alper ------ Forwarded Message From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Fri, 06 Feb 2004 15:42:35 -0500 To: IETF-Announce: ; Subject: I-D ACTION:draft-ohba-pana-framework-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PANA Framework Author(s) : P. Jayaraman Filename : draft-ohba-pana-framework-00.txt Pages : 46 Date : 2004-2-6 PANA design provides support for various types of deployments. Access networks can differ based on the availability of lower-layer security, placement of PANA entities, choice of client IP configuration and authentication methods, etc. This I-D defines a general framework for describing how these various deployment choices are handled by PANA and the access network architectures. Additionally, two possible deployments are described in detail: using PANA over DSL networks and WLAN networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ohba-pana-framework-00.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-ohba-pana-framework-00.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-ohba-pana-framework-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------ End of Forwarded Message --B_3159177531_31542251 Content-type: message/external-body; name="Attachment (Anarchie document).url"; x-mac-type="4155524C" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA0LTItNjE1NTgxNy5J LURAaWV0Zi5vcmc+DQ1FTkNPRElORyBtaW1lDUZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1vaGJhLXBhbmEtZnJhbWV3b3JrLTAwLnR4dA0N --B_3159177531_31542251 Content-type: application/octet-stream; name="draft-ohba-pana-framework-00.txt" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA0LTItNjE1NTgxNy5J LURAaWV0Zi5vcmc+DQ0= --B_3159177531_31542251-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Feb 9 16:26: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 QAA14611 for ; Mon, 9 Feb 2004 16:26: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 1AqIvD-0003eq-Bc for pana-archive@odin.ietf.org; Mon, 09 Feb 2004 16:26:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19LQR6T014056 for pana-archive@odin.ietf.org; Mon, 9 Feb 2004 16:26:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIvD-0003ed-76 for pana-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 16:26:27 -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 QAA14516 for ; Mon, 9 Feb 2004 16:26:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqIvB-0004OJ-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 16:26:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIso-0003sP-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 16:24:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqIqz-0003Ri-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 16:22:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIqw-0002ot-9Z; Mon, 09 Feb 2004 16:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqIqF-0002ky-V3 for pana@optimus.ietf.org; Mon, 09 Feb 2004 16:21:19 -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 QAA13720 for ; Mon, 9 Feb 2004 16:21:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqIqE-0003Iv-00 for pana@ietf.org; Mon, 09 Feb 2004 16:21:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqIoi-0002za-00 for pana@ietf.org; Mon, 09 Feb 2004 16:19:45 -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 1AqInk-0002nl-00 for pana@ietf.org; Mon, 09 Feb 2004 16:18:45 -0500 Date: Mon, 09 Feb 2004 13:18:47 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: <200402062042.PAA15236@ietf.org> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3159177531_31542251" Subject: [Pana] FW: I-D ACTION:draft-ohba-pana-framework-00.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.0 required=5.0 tests=AWL 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. --B_3159177531_31542251 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Please see the PANA Framework draft announcement below. This draft will be presented and discussed at the coming IETF meeting. WG members' early feedback to the mailing list is highly encouraged. Cheers, Alper ------ Forwarded Message From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Fri, 06 Feb 2004 15:42:35 -0500 To: IETF-Announce: ; Subject: I-D ACTION:draft-ohba-pana-framework-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PANA Framework Author(s) : P. Jayaraman Filename : draft-ohba-pana-framework-00.txt Pages : 46 Date : 2004-2-6 PANA design provides support for various types of deployments. Access networks can differ based on the availability of lower-layer security, placement of PANA entities, choice of client IP configuration and authentication methods, etc. This I-D defines a general framework for describing how these various deployment choices are handled by PANA and the access network architectures. Additionally, two possible deployments are described in detail: using PANA over DSL networks and WLAN networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ohba-pana-framework-00.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-ohba-pana-framework-00.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-ohba-pana-framework-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------ End of Forwarded Message --B_3159177531_31542251 Content-type: message/external-body; name="Attachment (Anarchie document).url"; x-mac-type="4155524C" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA0LTItNjE1NTgxNy5J LURAaWV0Zi5vcmc+DQ1FTkNPRElORyBtaW1lDUZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1vaGJhLXBhbmEtZnJhbWV3b3JrLTAwLnR4dA0N --B_3159177531_31542251 Content-type: application/octet-stream; name="draft-ohba-pana-framework-00.txt" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA0LTItNjE1NTgxNy5J LURAaWV0Zi5vcmc+DQ0= --B_3159177531_31542251-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Feb 9 17:06: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 RAA20391 for ; Mon, 9 Feb 2004 17:06: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 1AqJXU-0008CO-Rz; Mon, 09 Feb 2004 17:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJWj-00085i-Ea for pana@optimus.ietf.org; Mon, 09 Feb 2004 17:05:13 -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 RAA20119 for ; Mon, 9 Feb 2004 17:05:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJWh-0003lA-00 for pana@ietf.org; Mon, 09 Feb 2004 17:05:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJUy-0003Or-00 for pana@ietf.org; Mon, 09 Feb 2004 17:03:25 -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 1AqJSh-0002xY-00 for pana@ietf.org; Mon, 09 Feb 2004 17:01:03 -0500 Date: Mon, 09 Feb 2004 14:01:10 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: <200402092107.QAA11997@ietf.org> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3159180074_31704494" 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] FW: I-D ACTION:draft-yegin-eap-boot-rfc3118-00.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: , > 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. --B_3159180074_31704494 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit FYI... Alper ------ Forwarded Message From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Mon, 09 Feb 2004 16:07:49 -0500 To: IETF-Announce: ; Subject: I-D ACTION:draft-yegin-eap-boot-rfc3118-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network Access Authentication Author(s) : A. Yegin, H. Tschofenig, D. Forsberg Filename : draft-yegin-eap-boot-rfc3118-00.txt Pages : 20 Date : 2004-2-9 DHCP authentication extension (RFC3118) cannot be widely deployed due to lack of an out-of-band key agreement protocol for DHCP clients and servers. This draft outlines how EAP-based network access authentication mechanisms can be used to establish a local trust relation and generate keys that can be used in conjunction with RFC3118. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yegin-eap-boot-rfc3118-00.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-yegin-eap-boot-rfc3118-00.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-yegin-eap-boot-rfc3118-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------ End of Forwarded Message --B_3159180074_31704494 Content-type: message/external-body; name="Attachment (Anarchie document).url"; x-mac-type="4155524C" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA0LTItOTE2MDgxMC5J LURAaWV0Zi5vcmc+DQ1FTkNPRElORyBtaW1lDUZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFm dC15ZWdpbi1lYXAtYm9vdC1yZmMzMTE4LTAwLnR4dA0N --B_3159180074_31704494 Content-type: application/octet-stream; name="draft-yegin-eap-boot-rfc3118-00.txt" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA0LTItOTE2MDgxMC5J LURAaWV0Zi5vcmc+DQ0= --B_3159180074_31704494-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Feb 9 17:20:49 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 RAA22215 for ; Mon, 9 Feb 2004 17:20: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 1AqJlN-00012S-FW for pana-archive@odin.ietf.org; Mon, 09 Feb 2004 17:20:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19MKK61003982 for pana-archive@odin.ietf.org; Mon, 9 Feb 2004 17:20:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJlL-000125-6E for pana-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 17:20:19 -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 RAA22005 for ; Mon, 9 Feb 2004 17:20:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJlI-0006K2-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 17:20:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJj4-0005rm-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 17:17:59 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqJhs-0005ag-03 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 17:16:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqJXY-0001dV-R8 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 17: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 1AqJXU-0008CO-Rz; Mon, 09 Feb 2004 17:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJWj-00085i-Ea for pana@optimus.ietf.org; Mon, 09 Feb 2004 17:05:13 -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 RAA20119 for ; Mon, 9 Feb 2004 17:05:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJWh-0003lA-00 for pana@ietf.org; Mon, 09 Feb 2004 17:05:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJUy-0003Or-00 for pana@ietf.org; Mon, 09 Feb 2004 17:03:25 -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 1AqJSh-0002xY-00 for pana@ietf.org; Mon, 09 Feb 2004 17:01:03 -0500 Date: Mon, 09 Feb 2004 14:01:10 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: <200402092107.QAA11997@ietf.org> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3159180074_31704494" Subject: [Pana] FW: I-D ACTION:draft-yegin-eap-boot-rfc3118-00.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.0 required=5.0 tests=AWL 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. --B_3159180074_31704494 Content-type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit FYI... Alper ------ Forwarded Message From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Mon, 09 Feb 2004 16:07:49 -0500 To: IETF-Announce: ; Subject: I-D ACTION:draft-yegin-eap-boot-rfc3118-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based Network Access Authentication Author(s) : A. Yegin, H. Tschofenig, D. Forsberg Filename : draft-yegin-eap-boot-rfc3118-00.txt Pages : 20 Date : 2004-2-9 DHCP authentication extension (RFC3118) cannot be widely deployed due to lack of an out-of-band key agreement protocol for DHCP clients and servers. This draft outlines how EAP-based network access authentication mechanisms can be used to establish a local trust relation and generate keys that can be used in conjunction with RFC3118. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yegin-eap-boot-rfc3118-00.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-yegin-eap-boot-rfc3118-00.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-yegin-eap-boot-rfc3118-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------ End of Forwarded Message --B_3159180074_31704494 Content-type: message/external-body; name="Attachment (Anarchie document).url"; x-mac-type="4155524C" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA0LTItOTE2MDgxMC5J LURAaWV0Zi5vcmc+DQ1FTkNPRElORyBtaW1lDUZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFm dC15ZWdpbi1lYXAtYm9vdC1yZmMzMTE4LTAwLnR4dA0N --B_3159180074_31704494 Content-type: application/octet-stream; name="draft-yegin-eap-boot-rfc3118-00.txt" Content-disposition: attachment Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDA0LTItOTE2MDgxMC5J LURAaWV0Zi5vcmc+DQ0= --B_3159180074_31704494-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Feb 9 18:04:42 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 SAA27118 for ; Mon, 9 Feb 2004 18:04:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKRn-00069P-9Y; Mon, 09 Feb 2004 18:04:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKRO-0005tC-5h for pana@optimus.ietf.org; Mon, 09 Feb 2004 18:03: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 SAA26977 for ; Mon, 9 Feb 2004 18:03:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqKRL-00052z-00 for pana@ietf.org; Mon, 09 Feb 2004 18:03:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqKQZ-0004vV-00 for pana@ietf.org; Mon, 09 Feb 2004 18:02:55 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AqKPo-0004mJ-00 for pana@ietf.org; Mon, 09 Feb 2004 18:02:08 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i19N22Gv024255; Tue, 10 Feb 2004 08:02:02 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i19N22PS004802; Tue, 10 Feb 2004 08:02:02 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA04793 ; Tue, 10 Feb 2004 08:02:02 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA10902; Tue, 10 Feb 2004 08:02:01 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA10996; Tue, 10 Feb 2004 08:02:01 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i19N1xQX022791; Tue, 10 Feb 2004 08:02:00 +0900 (JST) Received: from steelhead ([159.119.168.99]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSU005ANANAAE@tsbpo1.po.toshiba.co.jp>; Tue, 10 Feb 2004 08:01:59 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AqKNZ-0004CY-00; Mon, 09 Feb 2004 14:59:49 -0800 Date: Mon, 09 Feb 2004 14:59:49 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy In-reply-to: To: pana@ietf.org Message-id: <20040209225949.GB15608@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.4i 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=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, 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 From exim@www1.ietf.org Mon Feb 9 18:06:17 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 SAA27353 for ; Mon, 9 Feb 2004 18:06:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKTO-0006gk-O8 for pana-archive@odin.ietf.org; Mon, 09 Feb 2004 18:05:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19N5ot9025701 for pana-archive@odin.ietf.org; Mon, 9 Feb 2004 18:05:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKTO-0006gN-JG for pana-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 18:05: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 SAA27304 for ; Mon, 9 Feb 2004 18:05:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqKTL-0005LQ-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 18:05:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqKSP-0005CK-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 18:04:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqKRq-00054J-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 18:04:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKRn-00069P-9Y; Mon, 09 Feb 2004 18:04:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKRO-0005tC-5h for pana@optimus.ietf.org; Mon, 09 Feb 2004 18:03: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 SAA26977 for ; Mon, 9 Feb 2004 18:03:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqKRL-00052z-00 for pana@ietf.org; Mon, 09 Feb 2004 18:03:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqKQZ-0004vV-00 for pana@ietf.org; Mon, 09 Feb 2004 18:02:55 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AqKPo-0004mJ-00 for pana@ietf.org; Mon, 09 Feb 2004 18:02:08 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i19N22Gv024255; Tue, 10 Feb 2004 08:02:02 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i19N22PS004802; Tue, 10 Feb 2004 08:02:02 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA04793 ; Tue, 10 Feb 2004 08:02:02 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA10902; Tue, 10 Feb 2004 08:02:01 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA10996; Tue, 10 Feb 2004 08:02:01 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i19N1xQX022791; Tue, 10 Feb 2004 08:02:00 +0900 (JST) Received: from steelhead ([159.119.168.99]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSU005ANANAAE@tsbpo1.po.toshiba.co.jp>; Tue, 10 Feb 2004 08:01:59 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AqKNZ-0004CY-00; Mon, 09 Feb 2004 14:59:49 -0800 Date: Mon, 09 Feb 2004 14:59:49 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy In-reply-to: To: pana@ietf.org Message-id: <20040209225949.GB15608@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.4i 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=AWL autolearn=no version=2.60 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 From pana-admin@ietf.org Mon Feb 9 18:31: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 SAA00310 for ; Mon, 9 Feb 2004 18:31: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 1AqKrm-0003Wh-2s; Mon, 09 Feb 2004 18:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKrC-0003UP-Bg for pana@optimus.ietf.org; Mon, 09 Feb 2004 18:30:26 -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 SAA00124 for ; Mon, 9 Feb 2004 18:30:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqKr9-0000dm-00 for pana@ietf.org; Mon, 09 Feb 2004 18:30:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqKqG-0000Tv-00 for pana@ietf.org; Mon, 09 Feb 2004 18:29:29 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AqKpH-0000GB-00 for pana@ietf.org; Mon, 09 Feb 2004 18:28:27 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i19NSLGv006356; Tue, 10 Feb 2004 08:28:21 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i19NSLjm023292; Tue, 10 Feb 2004 08:28:21 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA23290 ; Tue, 10 Feb 2004 08:28:21 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA23580; Tue, 10 Feb 2004 08:28:20 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA15309; Tue, 10 Feb 2004 08:28:20 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i19NSJQX001771; Tue, 10 Feb 2004 08:28:19 +0900 (JST) Received: from steelhead ([159.119.168.99]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSU006PGBV5L6@tsbpo1.po.toshiba.co.jp>; Tue, 10 Feb 2004 08:28:18 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AqKoc-0004GL-00; Mon, 09 Feb 2004 15:27:46 -0800 Date: Mon, 09 Feb 2004 15:27:46 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue54] Client cookie mandatory In-reply-to: To: Dan.Forsberg@nokia.com Cc: pana@ietf.org Message-id: <20040209232746.GA16181@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, pana@ietf.org User-Agent: Mutt/1.5.4i 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=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, Feb 05, 2004 at 11:41:07AM +0200, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > From Jari Arkko: > > - "Cookie mandatory" > > > > I would like the inclusion of the cookie to in the start > > exchange to be mandatory. >From optimization point of view, mandating the cookie does not allow EAP message to be carried in PSR and PSA any more. This is because cookie operation needs PAA to be stateless. Jari also has a technical comment on this. It is true that authenticator can generate EAP-Request message without creating state if we do not consider retransmission of EAP-Request. However, if we consider the fact that EAP-Request needs to be retransmitted by the authenticator, some state needs to be created at the authenticator. If authentictor generates EAP-Request but without retransmission, then such an implmentation does not really comply with RFC2284bis. Yoshihiro Ohba > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 194 > nosy: dforsber > priority: Should Fix > status: Pending > title: Client cookie mandatory > __________________________________________________ > PANA Issues > > __________________________________________________ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Feb 9 18:33:12 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 SAA00418 for ; Mon, 9 Feb 2004 18:33:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKtS-0003bB-44 for pana-archive@odin.ietf.org; Mon, 09 Feb 2004 18:32:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19NWkuO013829 for pana-archive@odin.ietf.org; Mon, 9 Feb 2004 18:32:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKtR-0003ay-Tg for pana-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 18:32: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 SAA00400 for ; Mon, 9 Feb 2004 18:32:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqKtP-0000wa-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 18:32:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqKsQ-0000oo-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 18:31:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqKrl-0000i8-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 18:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKrm-0003Wh-2s; Mon, 09 Feb 2004 18:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqKrC-0003UP-Bg for pana@optimus.ietf.org; Mon, 09 Feb 2004 18:30:26 -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 SAA00124 for ; Mon, 9 Feb 2004 18:30:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqKr9-0000dm-00 for pana@ietf.org; Mon, 09 Feb 2004 18:30:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqKqG-0000Tv-00 for pana@ietf.org; Mon, 09 Feb 2004 18:29:29 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AqKpH-0000GB-00 for pana@ietf.org; Mon, 09 Feb 2004 18:28:27 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i19NSLGv006356; Tue, 10 Feb 2004 08:28:21 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i19NSLjm023292; Tue, 10 Feb 2004 08:28:21 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA23290 ; Tue, 10 Feb 2004 08:28:21 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA23580; Tue, 10 Feb 2004 08:28:20 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA15309; Tue, 10 Feb 2004 08:28:20 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i19NSJQX001771; Tue, 10 Feb 2004 08:28:19 +0900 (JST) Received: from steelhead ([159.119.168.99]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSU006PGBV5L6@tsbpo1.po.toshiba.co.jp>; Tue, 10 Feb 2004 08:28:18 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AqKoc-0004GL-00; Mon, 09 Feb 2004 15:27:46 -0800 Date: Mon, 09 Feb 2004 15:27:46 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue54] Client cookie mandatory In-reply-to: To: Dan.Forsberg@nokia.com Cc: pana@ietf.org Message-id: <20040209232746.GA16181@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, pana@ietf.org User-Agent: Mutt/1.5.4i 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=AWL autolearn=no version=2.60 On Thu, Feb 05, 2004 at 11:41:07AM +0200, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > From Jari Arkko: > > - "Cookie mandatory" > > > > I would like the inclusion of the cookie to in the start > > exchange to be mandatory. >From optimization point of view, mandating the cookie does not allow EAP message to be carried in PSR and PSA any more. This is because cookie operation needs PAA to be stateless. Jari also has a technical comment on this. It is true that authenticator can generate EAP-Request message without creating state if we do not consider retransmission of EAP-Request. However, if we consider the fact that EAP-Request needs to be retransmitted by the authenticator, some state needs to be created at the authenticator. If authentictor generates EAP-Request but without retransmission, then such an implmentation does not really comply with RFC2284bis. Yoshihiro Ohba > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 194 > nosy: dforsber > priority: Should Fix > status: Pending > title: Client cookie mandatory > __________________________________________________ > PANA Issues > > __________________________________________________ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Feb 9 20:23: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 UAA08966 for ; Mon, 9 Feb 2004 20:23: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 1AqMc8-0000xD-PP; Mon, 09 Feb 2004 20:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMbb-0000ww-Mx for pana@optimus.ietf.org; Mon, 09 Feb 2004 20:22:27 -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 UAA08924 for ; Mon, 9 Feb 2004 20:22:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqMbZ-0007C9-00 for pana@ietf.org; Mon, 09 Feb 2004 20:22:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqMae-00078H-00 for pana@ietf.org; Mon, 09 Feb 2004 20:21:28 -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 1AqMZt-00074P-00 for pana@ietf.org; Mon, 09 Feb 2004 20:20:41 -0500 Date: Mon, 09 Feb 2004 17:20:55 -0800 From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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] Mobility 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 >From Jari's review comments: In case the new PAA retrieves the on-going PANA session attributes from the previous PAA, the PANA session continues with a PANA-Reauth exchange. The MAC AVP contained in the PANA-Reauth messages MUST be generated and verified by using the retrieved PANA SA attributes. This exchange MUST also include Session-Id AVP that contains the newly assigned session identifier, and Device-Id AVP. A new PANA session is created upon successful completion of this exchange. This session inherits only the session lifetime, protection capability, and MSK attributes from the previous session. Other attributes are generated based on the PANA exchanges on the new link. While MSK stays the same, a new PANA_MAC_Key is computed using the new parameters. Subsequent MAC-AVPs are processed using this new PANA SA. JARI: (Question) I presume that the link or IPsec layer protection is not inherited when you move? Such a movement would be hard, given the IPsec reliance on IP addresses which may have changed as a result of the authentication. That's right. The secure association protocol needs to rerun following successful PANA SA establishment on the new link. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Feb 9 20:29:58 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 UAA09143 for ; Mon, 9 Feb 2004 20:29:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMiP-00019u-P1 for pana-archive@odin.ietf.org; Mon, 09 Feb 2004 20:29:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A1TTmW004454 for pana-archive@odin.ietf.org; Mon, 9 Feb 2004 20:29:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMiP-00019l-Er for pana-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 20:29:29 -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 UAA09073 for ; Mon, 9 Feb 2004 20:29:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqMiN-0007n7-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 20:29:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqMhR-0007bm-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 20:28:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqMgR-0007Rq-00 for pana-web-archive@ietf.org; Mon, 09 Feb 2004 20:27:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqMcE-0004Mx-7q for pana-web-archive@ietf.org; Mon, 09 Feb 2004 20:23:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMc8-0000xD-PP; Mon, 09 Feb 2004 20:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqMbb-0000ww-Mx for pana@optimus.ietf.org; Mon, 09 Feb 2004 20:22:27 -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 UAA08924 for ; Mon, 9 Feb 2004 20:22:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqMbZ-0007C9-00 for pana@ietf.org; Mon, 09 Feb 2004 20:22:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqMae-00078H-00 for pana@ietf.org; Mon, 09 Feb 2004 20:21:28 -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 1AqMZt-00074P-00 for pana@ietf.org; Mon, 09 Feb 2004 20:20:41 -0500 Date: Mon, 09 Feb 2004 17:20:55 -0800 From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] Mobility 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 >From Jari's review comments: In case the new PAA retrieves the on-going PANA session attributes from the previous PAA, the PANA session continues with a PANA-Reauth exchange. The MAC AVP contained in the PANA-Reauth messages MUST be generated and verified by using the retrieved PANA SA attributes. This exchange MUST also include Session-Id AVP that contains the newly assigned session identifier, and Device-Id AVP. A new PANA session is created upon successful completion of this exchange. This session inherits only the session lifetime, protection capability, and MSK attributes from the previous session. Other attributes are generated based on the PANA exchanges on the new link. While MSK stays the same, a new PANA_MAC_Key is computed using the new parameters. Subsequent MAC-AVPs are processed using this new PANA SA. JARI: (Question) I presume that the link or IPsec layer protection is not inherited when you move? Such a movement would be hard, given the IPsec reliance on IP addresses which may have changed as a result of the authentication. That's right. The secure association protocol needs to rerun following successful PANA SA establishment on the new link. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Feb 10 02:11: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 CAA02203 for ; Tue, 10 Feb 2004 02:11: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 1AqS2x-00056u-3o; Tue, 10 Feb 2004 02:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS2X-0004yj-Ra for pana@optimus.ietf.org; Tue, 10 Feb 2004 02:10:37 -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 CAA01636 for ; Tue, 10 Feb 2004 02:10:35 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS2U-0001FF-00 for pana@ietf.org; Tue, 10 Feb 2004 02:10:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS1W-00019q-00 for pana@ietf.org; Tue, 10 Feb 2004 02:09:34 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqS0a-000157-00 for pana@ietf.org; Tue, 10 Feb 2004 02:08:36 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1A78bv23053 for ; Tue, 10 Feb 2004 09:08:37 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 09:08:36 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 09:08:36 +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: Tue, 10 Feb 2004 09:08:35 +0200 Message-ID: Thread-Topic: [issue61] PANA SA definition Thread-Index: AcPvo/p0ZUcL0xbLStm+Euvfg/g0zgAALBJA To: X-OriginalArrivalTime: 10 Feb 2004 07:08:36.0002 (UTC) FILETIME=[B3668020:01C3EFA4] 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: [issue61] PANA SA definition 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpQQU5BIFNlY3VyaXR5IEFzc29jaWF0aW9uOg0KDQogICAgICBUaGUgcmVwcmVzZW50YXRp b24gb2YgdGhlIHRydXN0IHJlbGF0aW9uIGJldHdlZW4gdGhlIFBhQyBhbmQgdGhlDQogICAgICBQ QUEgdGhhdCBpcyBjcmVhdGVkIGF0IHRoZSBlbmQgb2YgdGhlIGF1dGhlbnRpY2F0aW9uIHBoYXNl LiBUaGlzDQogICAgICBzZWN1cml0eSBhc3NvY2lhdGlvbiBpbmNsdWRlcyB0aGUgZGV2aWNlIGlk ZW50aWZpZXIgb2YgdGhlIHBlZXIsDQogICAgICBhbmQgYSBzaGFyZWQga2V5IHdoZW4gYXZhaWxh YmxlLg0KDQpKQVJJOiAoVGVjaG5pY2FsKSBIbW1tLi4uLiB0aGlzIHNlZW1zIHRvIG9taXQgc29t ZSB0aGluZ3MsIGxpa2UNCiAgICAgIGNyeXB0b2dyYXBoaWMgY29udGV4dC4gV2h5IHdvdWxkIGEg c2hhcmVkIGtleSBub3QgYmUgYXZhaWxhYmxlPw0KICAgICAgVW50aWwgaXQgaXMgYXZhaWxhYmxl LCB5b3UgZG9uJ3QgaGF2ZSBhbiBTQSwgcmlnaHQ/IEhlcmUncw0KICAgICAgYW5vdGhlciBjdXQg YXQgdGhpcyBkZWZpbml0aW9uOiAiQSBQQU5BIHNlY3VyaXR5IGFzc29jaWF0aW9uIGlzDQogICAg ICBhIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBQYUMgYW5kIFBBQSwgZm9ybWVkIGJ5IHRoZSBz aGFyaW5nIG9mDQogICAgICBjcnlwdG9ncmFwaGljIGtleWluZyBtYXRlcmlhbCBhbmQgYXNzb2Np YXRlZCBjb250ZXh0LiAgU2VjdXJpdHkNCiAgICAgIGFzc29jaWF0aW9ucyBhcmUgZHVwbGV4LiAg VGhhdCBpcywgb25lIHNlY3VyaXR5IGFzc29jaWF0aW9uIGlzDQogICAgICBuZWVkZWQgdG8gcHJv dGVjdCB0aGUgYmlkaXJlY3Rpb25hbCB0cmFmZmljIGJldHdlZW4gdGhlIFBhQyBhbmQNCiAgICAg IHRoZSBQQUFBLiINCg0KLS0tLS0tLS0tLQ0KY2F0ZWdvcnk6IFRlY2huaWNhbA0KZG9jdW1lbnQ6 IGRyYWZ0LWlldGYtcGFuYS1wYW5hLXh4LnR4dA0KbWVzc2FnZXM6IDIwMg0Kbm9zeTogZGZvcnNi ZXINCnByaW9yaXR5OiBNdXN0IEZpeA0Kc3RhdHVzOiBQZW5kaW5nDQp0aXRsZTogUEFOQSBTQSBk ZWZpbml0aW9uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KUEFOQSBJc3N1ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmluZm8+DQo8aHR0cDov L2RhbmZvcnNiZXJnLmluZm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTYxPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Feb 10 02:11: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 CAA02202 for ; Tue, 10 Feb 2004 02:11: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 1AqS2y-00057M-16; Tue, 10 Feb 2004 02:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS2b-0004za-IE for pana@optimus.ietf.org; Tue, 10 Feb 2004 02:10: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 CAA01699 for ; Tue, 10 Feb 2004 02:10:38 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS2X-0001Fg-00 for pana@ietf.org; Tue, 10 Feb 2004 02:10:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS1i-0001Ak-00 for pana@ietf.org; Tue, 10 Feb 2004 02:09:47 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqS0r-00015s-00 for pana@ietf.org; Tue, 10 Feb 2004 02:08:53 -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 i1A78rq16713 for ; Tue, 10 Feb 2004 09:08:53 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 09:08:52 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 09:08:52 +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: Tue, 10 Feb 2004 09:08:51 +0200 Message-ID: Thread-Topic: [issue62] PAA discovery triggered by data traffic Thread-Index: AcPvpDScfgzn/q8AR0O+As02btCEmAAAIFcA To: X-OriginalArrivalTime: 10 Feb 2004 07:08:52.0164 (UTC) FILETIME=[BD08A040:01C3EFA4] 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: [issue62] PAA discovery triggered by data traffic 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 RGFuIEZvcnNiZXJnIDxkYW4uZm9yc2JlcmdAbm9raWEuY29tPiBhZGRlZCB0aGUgY29tbWVudDoN Cg0KNC4yIERpc2NvdmVyeSBhbmQgSW5pdGlhbCBIYW5kc2hha2UgUGhhc2UNCg0KDQogICAuLi4N Cg0KICAgUGFDIG1heSBhbHNvIGNob29zZSB0byBzdGFydCBzZW5kaW5nIHBhY2tldHMgYmVmb3Jl IGdldHRpbmcNCiAgIGF1dGhlbnRpY2F0ZWQuIEluIHRoYXQgY2FzZSwgdGhlIG5ldHdvcmsgc2hv dWxkIGRldGVjdCB0aGlzIGFuZCBzZW5kDQogICBhbiB1bnNvbGljaXRlZCBQQU5BLVN0YXJ0LVJl cXVlc3QgbWVzc2FnZSB0byBQYUMuIEVQIGlzIHRoZSBub2RlIHRoYXQNCg0KSmFyaTogKFRlY2hu aWNhbCkgS2V5d29yZHMgbm90IGluIHVwcGVyIGNhc2UuIEFyZSB0aGVzZSBmdW5jdGlvbnMNCiAg ICAgIHJlcXVpcmVkIG9yIG5vdD8NCg0KICAgY2FuIGRldGVjdCBzdWNoIGFjdGl2aXR5LiBJZiBF UCBhbmQgUEFBIGFyZSBjby1sb2NhdGVkLCB0aGVuIGFuDQogICBpbnRlcm5hbCBtZWNoYW5pc20g KGUuZy4gQVBJKSBiZXR3ZWVuIHRoZSBFUCBtb2R1bGUgYW5kIHRoZSBQQUENCiAgIG1vZHVsZSBv biB0aGUgc2FtZSBob3N0IGNhbiBwcm9tcHQgUEFBIHRvIHN0YXJ0IFBBTkEuIEluIGNhc2UgdGhl eQ0KICAgYXJlIHNlcGFyYXRlLCB0aGVyZSBuZWVkcyB0byBiZSBhbiBleHBsaWNpdCBtZXNzYWdl IHRvIHByb21wdCBQQUEuDQogICBVcG9uIGRldGVjdGluZyB0aGUgbmVlZCB0byBhdXRoZW50aWNh dGUgYSBjbGllbnQsIEVQIGNhbiBzZW5kIGENCiAgIFBBTkEtUEFBLURpc2NvdmVyIG1lc3NhZ2Ug dG8gdGhlIFBBQSBvbiBiZWhhbGYgb2YgdGhlIFBhQy4gVGhpcw0KICAgbWVzc2FnZSBjYXJyaWVz IGEgZGV2aWNlIGlkZW50aWZpZXIgb2YgdGhlIFBhQyBpbiBhIERldmljZS1JRCBBVlAuIFNvDQog ICB0aGF0LCB0aGUgUEFBIGNhbiBzZW5kIHRoZSB1bnNvbGljaXRlZCBQQU5BLVN0YXJ0LVJlcXVl c3QgbWVzc2FnZQ0KICAgZGlyZWN0bHkgdG8gdGhlIFBhQy4gIElmIHRoZSBsaW5rIGJldHdlZW4g dGhlIEVQIGFuZCBQQUEgaXMgbm90DQogICBzZWN1cmUsIHRoZSBQQU5BLVBBQS1EaXNjb3ZlciBt ZXNzYWdlIHNlbnQgZnJvbSB0aGUgRVAgdG8gdGhlIFBBQQ0KICAgTVVTVCBiZSBwcm90ZWN0ZWQg YnkgdXNpbmcsIGUuZy4sIElQc2VjLg0KDQpKQVJJOiAoVGVjaG5pY2FsKSBUaGlzIGlzIGEgYml0 IHdlYWsuIEluIGFueSBjYXNlLCB0aGUgaW50cm9kdWN0aW9uDQogICAgICBwcm9taXNlZCB0byBu b3QgdGFsayBhYm91dCB0aGUgRVAtUEFBIHByb3RvY29sLiBOb3cgeW91IGFyZSB0YWxraW5nDQog ICAgICBhYm91dCBpdCEgSXQgbWlnaHQgYmUgYmV0dGVyIGZvciB0aGlzIGRvY3VtZW50IHRvIHNl ZSB0aGUNCiAgICAgIEVQLVBBQSBhcyBhIHNpbmdsZSBlbnRpdHkuDQoNCjQuMTAgRXZlbnQgTm90 aWZpY2F0aW9uDQoNCiAgIFVwb24gZGV0ZWN0aW5nIHRoZSBuZWVkIHRvIGF1dGhlbnRpY2F0ZSBh IGNsaWVudCwgRVAgY2FuIHNlbmQgYQ0KICAgdHJpZ2dlciBtZXNzYWdlIHRvIHRoZSBQQUEgb24g YmVoYWxmIG9mIHRoZSBQYUMuIFRoaXMgY2FuIGJlIG9uZSBvZg0KICAgdGhlIG1lc3NhZ2VzIHBy b3ZpZGVkIGJ5IHRoZSBQQUEtdG8tRVAgcHJvdG9jb2wsIG9yLCBpbiB0aGUgYWJzZW5jZQ0KICAg b2Ygc3VjaCBhIGZhY2lsaXR5LCBQQU5BLVBBQV9EaXNjb3ZlciBjYW4gYmUgdXNlZCBhcyB3ZWxs LiBUaGlzDQogICBtZXNzYWdlIE1VU1QgY2FycnkgdGhlIGRldmljZSBpZGVudGlmaWVyIG9mIHRo ZSBQYUMuIFNvIHRoYXQsIHRoZSBQQUENCiAgIGNhbiBzZW5kIHRoZSB1bnNvbGljaXRlZCBQQU5B LVN0YXJ0LVJlcXVlc3QgbWVzc2FnZSBkaXJlY3RseSB0byB0aGUNCiAgIFBhQy4gIElmIHRoZSBs aW5rIGJldHdlZW4gdGhlIEVQIGFuZCBQQUEgaXMgbm90IHBoeXNpY2FsbHkgc2VjdXJlZCwNCiAg IHRoaXMgbWVzc2FnZSBzZW50IGZyb20gRVAgdG8gUEFBIE1VU1QgYmUgY3J5cHRvZ3JhcGhpY2Fs bHkgcHJvdGVjdGVkDQogICAoZS5nLiwgYnkgdXNpbmcgSVBzZWMpLg0KDQpKQVJJOiAoVGVjaG5p Y2FsKSBBcyBjb21tZW50ZWQgcHJldmlvdXNseSwgcGVyaGFwcyBpdCB3b3VsZCBiZSBiZXR0ZXIN CiAgICAgIGlmIHRoZSBBUC1QQUEgY29uc2lkZXJhdGlvbnMgd2VyZSBrZXB0IG91dCBvZiB0aGlz IGRvY3VtZW50LiBUaHVzDQogICAgICB0aGUgYWJvdmUgdHJpZ2dlciBtZXNzYWdpbmcgY291bGQg cGVyaGFwcyBiZSBvbWl0dGVkIGhlcmU/IFNlY3Rpb24NCiAgICAgIDQuMTEsIGhvd2V2ZXIsIGlz IG5lY2Vzc2FyeS4NCg0KTm90ZSBieSBBbHBlcjogV2UgY2FuIGNvbnNpZGVyIGRlcHJlY2F0aW5n IHRoZSBQQU5BLWJhc2VkIEVQLVBBQSBtZXNzYWdpbmcNCnNpbmNlIHRoZSBtYW5kYXRvcnkgRVAt dG8tUEFBIHByb3RvY29sLCBTTk1QLCBhbHJlYWR5IHN1cHBvcnRzIHNpZ25hbGxpbmcgdG8NCnRo YXQgZWZmZWN0Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClBBTkEgSXNzdWVzIDxwYW5hX2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6 Ly9kYW5mb3JzYmVyZy5pbmZvOjgwODAvcGFuYS1pc3N1ZXMvaXNzdWU2Mj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Feb 10 02:12: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 CAA02326 for ; Tue, 10 Feb 2004 02:12: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 1AqS3s-0005ZK-6S; Tue, 10 Feb 2004 02:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS3Y-0005Rc-0B for pana@optimus.ietf.org; Tue, 10 Feb 2004 02: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 CAA02263 for ; Tue, 10 Feb 2004 02:11:37 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS3U-0001LS-00 for pana@ietf.org; Tue, 10 Feb 2004 02:11:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS2b-0001GA-00 for pana@ietf.org; Tue, 10 Feb 2004 02:10:41 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqS1o-0001BU-00 for pana@ietf.org; Tue, 10 Feb 2004 02:09:52 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1A79pv25128 for ; Tue, 10 Feb 2004 09:09:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 09:09:47 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 09:09:47 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 09:09:46 +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: Tue, 10 Feb 2004 09:09:46 +0200 Message-ID: Thread-Topic: [issue65] Clarification on simultaneous per-packet protection Thread-Index: AcPvpKN9q4ePcaOzQVyXKFkzKMXM2QAADE9A To: X-OriginalArrivalTime: 10 Feb 2004 07:09:46.0354 (UTC) FILETIME=[DD555D20:01C3EFA4] 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: [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: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQo5LjQuNSBQcm90ZWN0aW9uLUNhcGFiaWxpdHkgQVZQDQoNCiAgIFRoZSBQcm90ZWN0aW9u LUNhcGFiaWxpdHkgQVZQIChDb2RlIDEwMjgpIGlzIG9mIHR5cGUgVW5zaWduZWQzMi4gIFRoZQ0K ICAgQVZQIGRhdGEgaXMgdXNlZCBhcyBhIGNvbGxlY3Rpb24gb2YgZmxhZ3MgZm9yIGRpZmZlcmVu dCBkYXRhDQogICBwcm90ZWN0aW9uIGNhcGFiaWxpdHkgaW5kaWNhdGlvbnMuIEJlbG93IGlzIGEg bGlzdCBvZiBzcGVjaWZpZWQgZGF0YQ0KICAgcHJvdGVjdGlvbiBjYXBhYmlsaXRpZXM6DQoNCiAg ICAgICAgIDAgICAgICAgICAgVU5LTk9XTg0KICAgICAgICAgMSAgICAgICAgICBMMl9QUk9URUNU SU9ODQogICAgICAgICAyICAgICAgICAgIElQU0VDX1BST1RFQ1RJT04NCg0KDQpKQVJJOiAoVGVj aG5pY2FsKSBBcmUgdGhlc2UgaW50ZWdlcnMgb3IgYml0cz8gQ2FuIHlvdSBoYXZlIGEgY2FwYWJp bGl0eQ0KICAgICAgZm9yIGJvdGggTDIgYW5kIElQc2VjIHByb3RlY3Rpb24/DQoNCk5vdGUgYnkg QWxwZXI6IFRoZXNlIGFyZSBzdXBwb3NlZCB0byBiZSBpbnRlZ2Vycy4gVGhlIGN1cnJlbnQgZGVz aWduIGFzc3VtZXMNCm9ubHkgb25lIG9mIHRoZXNlIHdpbGwgYmUgZW5hYmxlZCAoVU5LTk9XTiBt ZWFuaW5nIC4uLj8hPykgYWZ0ZXIgUEFOQS4gV2UNCnNoYWxsIGNsYXJpZnkgdGhpcyBpbiB0aGUg dGV4dC4NCg0KLS0tLS0tLS0tLQ0KY2F0ZWdvcnk6IFRlY2huaWNhbA0KZG9jdW1lbnQ6IGRyYWZ0 LWlldGYtcGFuYS1wYW5hLXh4LnR4dA0KbWVzc2FnZXM6IDIwNw0Kbm9zeTogZGZvcnNiZXINCnBy aW9yaXR5OiBTaG91bGQgRml4DQpzdGF0dXM6IENsYXJpZnlpbmcgVGV4dCBSZXF1aXJlZA0KdGl0 bGU6IENsYXJpZmljYXRpb24gb24gc2ltdWx0YW5lb3VzIHBlci1wYWNrZXQgcHJvdGVjdGlvbg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEg SXNzdWVzIDxwYW5hX2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVy Zy5pbmZvOjgwODAvcGFuYS1pc3N1ZXMvaXNzdWU2NT4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Feb 10 02:13: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 CAA02445 for ; Tue, 10 Feb 2004 02:13: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 1AqS4h-0005r2-PL for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 02:12:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A7CppQ022479 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 02:12:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS4g-0005qS-N2 for pana-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 02:12: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 CAA02391 for ; Tue, 10 Feb 2004 02:12:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS4d-0001Sz-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 02:12:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS3a-0001MX-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 02:11:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqS2y-0001Gr-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 02:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS2y-00057M-16; Tue, 10 Feb 2004 02:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS2b-0004za-IE for pana@optimus.ietf.org; Tue, 10 Feb 2004 02:10: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 CAA01699 for ; Tue, 10 Feb 2004 02:10:38 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS2X-0001Fg-00 for pana@ietf.org; Tue, 10 Feb 2004 02:10:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS1i-0001Ak-00 for pana@ietf.org; Tue, 10 Feb 2004 02:09:47 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqS0r-00015s-00 for pana@ietf.org; Tue, 10 Feb 2004 02:08:53 -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 i1A78rq16713 for ; Tue, 10 Feb 2004 09:08:53 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 09:08:52 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 09:08:52 +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: Tue, 10 Feb 2004 09:08:51 +0200 Message-ID: Thread-Topic: [issue62] PAA discovery triggered by data traffic Thread-Index: AcPvpDScfgzn/q8AR0O+As02btCEmAAAIFcA To: X-OriginalArrivalTime: 10 Feb 2004 07:08:52.0164 (UTC) FILETIME=[BD08A040:01C3EFA4] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue62] PAA discovery triggered by data traffic 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 RGFuIEZvcnNiZXJnIDxkYW4uZm9yc2JlcmdAbm9raWEuY29tPiBhZGRlZCB0aGUgY29tbWVudDoN Cg0KNC4yIERpc2NvdmVyeSBhbmQgSW5pdGlhbCBIYW5kc2hha2UgUGhhc2UNCg0KDQogICAuLi4N Cg0KICAgUGFDIG1heSBhbHNvIGNob29zZSB0byBzdGFydCBzZW5kaW5nIHBhY2tldHMgYmVmb3Jl IGdldHRpbmcNCiAgIGF1dGhlbnRpY2F0ZWQuIEluIHRoYXQgY2FzZSwgdGhlIG5ldHdvcmsgc2hv dWxkIGRldGVjdCB0aGlzIGFuZCBzZW5kDQogICBhbiB1bnNvbGljaXRlZCBQQU5BLVN0YXJ0LVJl cXVlc3QgbWVzc2FnZSB0byBQYUMuIEVQIGlzIHRoZSBub2RlIHRoYXQNCg0KSmFyaTogKFRlY2hu aWNhbCkgS2V5d29yZHMgbm90IGluIHVwcGVyIGNhc2UuIEFyZSB0aGVzZSBmdW5jdGlvbnMNCiAg ICAgIHJlcXVpcmVkIG9yIG5vdD8NCg0KICAgY2FuIGRldGVjdCBzdWNoIGFjdGl2aXR5LiBJZiBF UCBhbmQgUEFBIGFyZSBjby1sb2NhdGVkLCB0aGVuIGFuDQogICBpbnRlcm5hbCBtZWNoYW5pc20g KGUuZy4gQVBJKSBiZXR3ZWVuIHRoZSBFUCBtb2R1bGUgYW5kIHRoZSBQQUENCiAgIG1vZHVsZSBv biB0aGUgc2FtZSBob3N0IGNhbiBwcm9tcHQgUEFBIHRvIHN0YXJ0IFBBTkEuIEluIGNhc2UgdGhl eQ0KICAgYXJlIHNlcGFyYXRlLCB0aGVyZSBuZWVkcyB0byBiZSBhbiBleHBsaWNpdCBtZXNzYWdl IHRvIHByb21wdCBQQUEuDQogICBVcG9uIGRldGVjdGluZyB0aGUgbmVlZCB0byBhdXRoZW50aWNh dGUgYSBjbGllbnQsIEVQIGNhbiBzZW5kIGENCiAgIFBBTkEtUEFBLURpc2NvdmVyIG1lc3NhZ2Ug dG8gdGhlIFBBQSBvbiBiZWhhbGYgb2YgdGhlIFBhQy4gVGhpcw0KICAgbWVzc2FnZSBjYXJyaWVz IGEgZGV2aWNlIGlkZW50aWZpZXIgb2YgdGhlIFBhQyBpbiBhIERldmljZS1JRCBBVlAuIFNvDQog ICB0aGF0LCB0aGUgUEFBIGNhbiBzZW5kIHRoZSB1bnNvbGljaXRlZCBQQU5BLVN0YXJ0LVJlcXVl c3QgbWVzc2FnZQ0KICAgZGlyZWN0bHkgdG8gdGhlIFBhQy4gIElmIHRoZSBsaW5rIGJldHdlZW4g dGhlIEVQIGFuZCBQQUEgaXMgbm90DQogICBzZWN1cmUsIHRoZSBQQU5BLVBBQS1EaXNjb3ZlciBt ZXNzYWdlIHNlbnQgZnJvbSB0aGUgRVAgdG8gdGhlIFBBQQ0KICAgTVVTVCBiZSBwcm90ZWN0ZWQg YnkgdXNpbmcsIGUuZy4sIElQc2VjLg0KDQpKQVJJOiAoVGVjaG5pY2FsKSBUaGlzIGlzIGEgYml0 IHdlYWsuIEluIGFueSBjYXNlLCB0aGUgaW50cm9kdWN0aW9uDQogICAgICBwcm9taXNlZCB0byBu b3QgdGFsayBhYm91dCB0aGUgRVAtUEFBIHByb3RvY29sLiBOb3cgeW91IGFyZSB0YWxraW5nDQog ICAgICBhYm91dCBpdCEgSXQgbWlnaHQgYmUgYmV0dGVyIGZvciB0aGlzIGRvY3VtZW50IHRvIHNl ZSB0aGUNCiAgICAgIEVQLVBBQSBhcyBhIHNpbmdsZSBlbnRpdHkuDQoNCjQuMTAgRXZlbnQgTm90 aWZpY2F0aW9uDQoNCiAgIFVwb24gZGV0ZWN0aW5nIHRoZSBuZWVkIHRvIGF1dGhlbnRpY2F0ZSBh IGNsaWVudCwgRVAgY2FuIHNlbmQgYQ0KICAgdHJpZ2dlciBtZXNzYWdlIHRvIHRoZSBQQUEgb24g YmVoYWxmIG9mIHRoZSBQYUMuIFRoaXMgY2FuIGJlIG9uZSBvZg0KICAgdGhlIG1lc3NhZ2VzIHBy b3ZpZGVkIGJ5IHRoZSBQQUEtdG8tRVAgcHJvdG9jb2wsIG9yLCBpbiB0aGUgYWJzZW5jZQ0KICAg b2Ygc3VjaCBhIGZhY2lsaXR5LCBQQU5BLVBBQV9EaXNjb3ZlciBjYW4gYmUgdXNlZCBhcyB3ZWxs LiBUaGlzDQogICBtZXNzYWdlIE1VU1QgY2FycnkgdGhlIGRldmljZSBpZGVudGlmaWVyIG9mIHRo ZSBQYUMuIFNvIHRoYXQsIHRoZSBQQUENCiAgIGNhbiBzZW5kIHRoZSB1bnNvbGljaXRlZCBQQU5B LVN0YXJ0LVJlcXVlc3QgbWVzc2FnZSBkaXJlY3RseSB0byB0aGUNCiAgIFBhQy4gIElmIHRoZSBs aW5rIGJldHdlZW4gdGhlIEVQIGFuZCBQQUEgaXMgbm90IHBoeXNpY2FsbHkgc2VjdXJlZCwNCiAg IHRoaXMgbWVzc2FnZSBzZW50IGZyb20gRVAgdG8gUEFBIE1VU1QgYmUgY3J5cHRvZ3JhcGhpY2Fs bHkgcHJvdGVjdGVkDQogICAoZS5nLiwgYnkgdXNpbmcgSVBzZWMpLg0KDQpKQVJJOiAoVGVjaG5p Y2FsKSBBcyBjb21tZW50ZWQgcHJldmlvdXNseSwgcGVyaGFwcyBpdCB3b3VsZCBiZSBiZXR0ZXIN CiAgICAgIGlmIHRoZSBBUC1QQUEgY29uc2lkZXJhdGlvbnMgd2VyZSBrZXB0IG91dCBvZiB0aGlz IGRvY3VtZW50LiBUaHVzDQogICAgICB0aGUgYWJvdmUgdHJpZ2dlciBtZXNzYWdpbmcgY291bGQg cGVyaGFwcyBiZSBvbWl0dGVkIGhlcmU/IFNlY3Rpb24NCiAgICAgIDQuMTEsIGhvd2V2ZXIsIGlz IG5lY2Vzc2FyeS4NCg0KTm90ZSBieSBBbHBlcjogV2UgY2FuIGNvbnNpZGVyIGRlcHJlY2F0aW5n IHRoZSBQQU5BLWJhc2VkIEVQLVBBQSBtZXNzYWdpbmcNCnNpbmNlIHRoZSBtYW5kYXRvcnkgRVAt dG8tUEFBIHByb3RvY29sLCBTTk1QLCBhbHJlYWR5IHN1cHBvcnRzIHNpZ25hbGxpbmcgdG8NCnRo YXQgZWZmZWN0Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClBBTkEgSXNzdWVzIDxwYW5hX2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6 Ly9kYW5mb3JzYmVyZy5pbmZvOjgwODAvcGFuYS1pc3N1ZXMvaXNzdWU2Mj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Feb 10 02:13: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 CAA02447 for ; Tue, 10 Feb 2004 02:13: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 1AqS4i-0005rX-6Q for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 02:12:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A7CqfS022529 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 02:12:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS4i-0005rE-0R for pana-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 02:12: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 CAA02399 for ; Tue, 10 Feb 2004 02:12:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS4e-0001T9-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 02:12:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS3b-0001Mn-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 02:11:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqS2y-0001Gv-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 02:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS30-00058b-9O; Tue, 10 Feb 2004 02:11:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS2e-00050u-2Q for pana@optimus.ietf.org; Tue, 10 Feb 2004 02:10: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 CAA01744 for ; Tue, 10 Feb 2004 02:10:41 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS2a-0001G0-00 for pana@ietf.org; Tue, 10 Feb 2004 02:10:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS1l-0001BG-00 for pana@ietf.org; Tue, 10 Feb 2004 02:09:49 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqS1P-000163-00 for pana@ietf.org; Tue, 10 Feb 2004 02:09:27 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1A79Rv24375 for ; Tue, 10 Feb 2004 09:09:27 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 09:09:25 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 09:09:25 +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: Tue, 10 Feb 2004 09:09:25 +0200 Message-ID: Thread-Topic: [issue63] MAC AVP a SHOULD or a MUST Thread-Index: AcPvpIgiuBl8ApFASPGXri/dw03qAAAAD+Ng To: X-OriginalArrivalTime: 10 Feb 2004 07:09:25.0431 (UTC) FILETIME=[D0DCC470:01C3EFA4] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQppbmhlcml0ZWQgZnJvbSB0aGUgcHJldmlvdXMgKHJlLSlhdXRoZW50aWNhdGlvbi4gIEZv ciBhbnkgRUFQLWJhc2VkDQogICByZS1hdXRoZW50aWNhdGlvbiwgaWYgdGhlcmUgaXMgYW4gZXN0 YWJsaXNoZWQgUEFOQSBTQSwNCiAgIFBBTkEtQXV0aC1SZXF1ZXN0IGFuZCBQQU5BLUF1dGgtQW5z d2VyIG1lc3NhZ2VzIFNIT1VMRCBiZSBwcm90ZWN0ZWQNCiAgIGJ5IGFkZGluZyBhIE1BQyBBVlAg dG8gZWFjaCBtZXNzYWdlLg0KDQpKQVJJOiAoVGVjaG5pY2FsKSBIb3cgYWJvdXQgYSBNVVNUPyBP dGhlcndpc2UsIGltcGxlbWVudGF0aW9ucyBoYXZlDQogICAgICB0byBkZWFsIHdpdGggdGhlIE1B QyBlaXRoZXIgYmVpbmcgcHJlc2VudCBvciBub3QgcHJlc2VudC4gQW5kIHRoZXJlDQogICAgICBo YXMgdG8gYmUgYSBjb25maWcgc3dpdGNoIHRvIGVpdGhlciBhbGxvdyBvciBkaXNhbGxvdyB0aGlz Lg0KDQotLS0tLS0tLS0tDQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkb2N1bWVudDogZHJhZnQtaWV0 Zi1wYW5hLXBhbmEteHgudHh0DQptZXNzYWdlczogMjA1DQpub3N5OiBkZm9yc2Jlcg0KcHJpb3Jp dHk6IE11c3QgRml4DQpzdGF0dXM6IENsYXJpZnlpbmcgVGV4dCBSZXF1aXJlZA0KdGl0bGU6IE1B QyBBVlAgYSBTSE9VTEQgb3IgYSBNVVNUDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KUEFOQSBJc3N1ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJn LmluZm8+DQo8aHR0cDovL2RhbmZvcnNiZXJnLmluZm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTYz Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Feb 10 02:14: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 CAA02621 for ; Tue, 10 Feb 2004 02:14:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS5f-00069e-Tf for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 02:13:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A7DpjL023646 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 02:13:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS5f-00069C-Ee for pana-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 02:13: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 CAA02564 for ; Tue, 10 Feb 2004 02:13:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS5c-0001ZS-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 02:13:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS4n-0001TY-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 02:12:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqS3q-0001NA-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 02:11:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS3s-0005ZK-6S; Tue, 10 Feb 2004 02:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS3Y-0005Rc-0B for pana@optimus.ietf.org; Tue, 10 Feb 2004 02: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 CAA02263 for ; Tue, 10 Feb 2004 02:11:37 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS3U-0001LS-00 for pana@ietf.org; Tue, 10 Feb 2004 02:11:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS2b-0001GA-00 for pana@ietf.org; Tue, 10 Feb 2004 02:10:41 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqS1o-0001BU-00 for pana@ietf.org; Tue, 10 Feb 2004 02:09:52 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1A79pv25128 for ; Tue, 10 Feb 2004 09:09:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 09:09:47 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 09:09:47 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 09:09:46 +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: Tue, 10 Feb 2004 09:09:46 +0200 Message-ID: Thread-Topic: [issue65] Clarification on simultaneous per-packet protection Thread-Index: AcPvpKN9q4ePcaOzQVyXKFkzKMXM2QAADE9A To: X-OriginalArrivalTime: 10 Feb 2004 07:09:46.0354 (UTC) FILETIME=[DD555D20:01C3EFA4] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQo5LjQuNSBQcm90ZWN0aW9uLUNhcGFiaWxpdHkgQVZQDQoNCiAgIFRoZSBQcm90ZWN0aW9u LUNhcGFiaWxpdHkgQVZQIChDb2RlIDEwMjgpIGlzIG9mIHR5cGUgVW5zaWduZWQzMi4gIFRoZQ0K ICAgQVZQIGRhdGEgaXMgdXNlZCBhcyBhIGNvbGxlY3Rpb24gb2YgZmxhZ3MgZm9yIGRpZmZlcmVu dCBkYXRhDQogICBwcm90ZWN0aW9uIGNhcGFiaWxpdHkgaW5kaWNhdGlvbnMuIEJlbG93IGlzIGEg bGlzdCBvZiBzcGVjaWZpZWQgZGF0YQ0KICAgcHJvdGVjdGlvbiBjYXBhYmlsaXRpZXM6DQoNCiAg ICAgICAgIDAgICAgICAgICAgVU5LTk9XTg0KICAgICAgICAgMSAgICAgICAgICBMMl9QUk9URUNU SU9ODQogICAgICAgICAyICAgICAgICAgIElQU0VDX1BST1RFQ1RJT04NCg0KDQpKQVJJOiAoVGVj aG5pY2FsKSBBcmUgdGhlc2UgaW50ZWdlcnMgb3IgYml0cz8gQ2FuIHlvdSBoYXZlIGEgY2FwYWJp bGl0eQ0KICAgICAgZm9yIGJvdGggTDIgYW5kIElQc2VjIHByb3RlY3Rpb24/DQoNCk5vdGUgYnkg QWxwZXI6IFRoZXNlIGFyZSBzdXBwb3NlZCB0byBiZSBpbnRlZ2Vycy4gVGhlIGN1cnJlbnQgZGVz aWduIGFzc3VtZXMNCm9ubHkgb25lIG9mIHRoZXNlIHdpbGwgYmUgZW5hYmxlZCAoVU5LTk9XTiBt ZWFuaW5nIC4uLj8hPykgYWZ0ZXIgUEFOQS4gV2UNCnNoYWxsIGNsYXJpZnkgdGhpcyBpbiB0aGUg dGV4dC4NCg0KLS0tLS0tLS0tLQ0KY2F0ZWdvcnk6IFRlY2huaWNhbA0KZG9jdW1lbnQ6IGRyYWZ0 LWlldGYtcGFuYS1wYW5hLXh4LnR4dA0KbWVzc2FnZXM6IDIwNw0Kbm9zeTogZGZvcnNiZXINCnBy aW9yaXR5OiBTaG91bGQgRml4DQpzdGF0dXM6IENsYXJpZnlpbmcgVGV4dCBSZXF1aXJlZA0KdGl0 bGU6IENsYXJpZmljYXRpb24gb24gc2ltdWx0YW5lb3VzIHBlci1wYWNrZXQgcHJvdGVjdGlvbg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEg SXNzdWVzIDxwYW5hX2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVy Zy5pbmZvOjgwODAvcGFuYS1pc3N1ZXMvaXNzdWU2NT4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Feb 10 02:57:58 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 CAA02204 for ; Tue, 10 Feb 2004 02:11: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 1AqS30-00058b-9O; Tue, 10 Feb 2004 02:11:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS2e-00050u-2Q for pana@optimus.ietf.org; Tue, 10 Feb 2004 02:10: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 CAA01744 for ; Tue, 10 Feb 2004 02:10:41 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS2a-0001G0-00 for pana@ietf.org; Tue, 10 Feb 2004 02:10:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS1l-0001BG-00 for pana@ietf.org; Tue, 10 Feb 2004 02:09:49 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqS1P-000163-00 for pana@ietf.org; Tue, 10 Feb 2004 02:09:27 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1A79Rv24375 for ; Tue, 10 Feb 2004 09:09:27 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 09:09:25 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 09:09:25 +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: Tue, 10 Feb 2004 09:09:25 +0200 Message-ID: Thread-Topic: [issue63] MAC AVP a SHOULD or a MUST Thread-Index: AcPvpIgiuBl8ApFASPGXri/dw03qAAAAD+Ng To: X-OriginalArrivalTime: 10 Feb 2004 07:09:25.0431 (UTC) FILETIME=[D0DCC470:01C3EFA4] 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: [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: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQppbmhlcml0ZWQgZnJvbSB0aGUgcHJldmlvdXMgKHJlLSlhdXRoZW50aWNhdGlvbi4gIEZv ciBhbnkgRUFQLWJhc2VkDQogICByZS1hdXRoZW50aWNhdGlvbiwgaWYgdGhlcmUgaXMgYW4gZXN0 YWJsaXNoZWQgUEFOQSBTQSwNCiAgIFBBTkEtQXV0aC1SZXF1ZXN0IGFuZCBQQU5BLUF1dGgtQW5z d2VyIG1lc3NhZ2VzIFNIT1VMRCBiZSBwcm90ZWN0ZWQNCiAgIGJ5IGFkZGluZyBhIE1BQyBBVlAg dG8gZWFjaCBtZXNzYWdlLg0KDQpKQVJJOiAoVGVjaG5pY2FsKSBIb3cgYWJvdXQgYSBNVVNUPyBP dGhlcndpc2UsIGltcGxlbWVudGF0aW9ucyBoYXZlDQogICAgICB0byBkZWFsIHdpdGggdGhlIE1B QyBlaXRoZXIgYmVpbmcgcHJlc2VudCBvciBub3QgcHJlc2VudC4gQW5kIHRoZXJlDQogICAgICBo YXMgdG8gYmUgYSBjb25maWcgc3dpdGNoIHRvIGVpdGhlciBhbGxvdyBvciBkaXNhbGxvdyB0aGlz Lg0KDQotLS0tLS0tLS0tDQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkb2N1bWVudDogZHJhZnQtaWV0 Zi1wYW5hLXBhbmEteHgudHh0DQptZXNzYWdlczogMjA1DQpub3N5OiBkZm9yc2Jlcg0KcHJpb3Jp dHk6IE11c3QgRml4DQpzdGF0dXM6IENsYXJpZnlpbmcgVGV4dCBSZXF1aXJlZA0KdGl0bGU6IE1B QyBBVlAgYSBTSE9VTEQgb3IgYSBNVVNUDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KUEFOQSBJc3N1ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJn LmluZm8+DQo8aHR0cDovL2RhbmZvcnNiZXJnLmluZm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTYz Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Feb 10 02:57:59 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 CAA02205 for ; Tue, 10 Feb 2004 02:11: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 1AqS2z-00057z-K4; Tue, 10 Feb 2004 02:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS2c-00050K-RD for pana@optimus.ietf.org; Tue, 10 Feb 2004 02:10:42 -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 CAA01721 for ; Tue, 10 Feb 2004 02:10:40 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS2Z-0001Fq-00 for pana@ietf.org; Tue, 10 Feb 2004 02:10:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS1k-0001B0-00 for pana@ietf.org; Tue, 10 Feb 2004 02:09:48 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqS16-00015z-00 for pana@ietf.org; Tue, 10 Feb 2004 02:09:08 -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 i1A798q17048 for ; Tue, 10 Feb 2004 09:09:09 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 09:09:08 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 09:09:07 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 09:09:06 +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: Tue, 10 Feb 2004 09:09:06 +0200 Message-ID: Thread-Topic: [issue64] Two separate codes for Session ID AVP Thread-Index: AcPvpH7NVwO4BPKGQ/2lcExtfGNkfwAAD9pw To: X-OriginalArrivalTime: 10 Feb 2004 07:09:06.0635 (UTC) FILETIME=[C5A8B9B0:01C3EFA4] 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: [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: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQo5LjQuMyBTZXNzaW9uLUlkIEFWUA0KDQogICBTZXNzaW9uLUlkIEFWUCAoQ29kZSAxMDI2 KSBoYXMgYW4gb3BhcXVlIGRhdGEgZmllbGQsIHdoaWNoIGlzDQogICBhc3NpZ25lZCBieSB0aGUg UEFBLiBBbGwgbWVzc2FnZXMgcGVydGFpbmluZyB0byBhIHNwZWNpZmljIFBBTkENCiAgIFNlc3Np b24gTVVTVCBpbmNsdWRlIG9ubHkgb25lIFNlc3Npb24tSWQgQVZQIGFuZCB0aGUgc2FtZSB2YWx1 ZSBNVVNUDQogICBiZSB1c2VkIHRocm91Z2hvdXQgdGhlIGxpZmV0aW1lIG9mIGEgc2Vzc2lvbi4g IFdoZW4gcHJlc2VudCwgdGhlDQogICBTZXNzaW9uLUlkIFNIT1VMRCBhcHBlYXIgaW1tZWRpYXRl bHkgZm9sbG93aW5nIHRoZSBQQU5BIGhlYWRlci4NCg0KICAgVGhlIFNlc3Npb24tSWQgTVVTVCBi ZSBnbG9iYWxseSBhbmQgZXRlcm5hbGx5IHVuaXF1ZSwgYXMgaXQgaXMgbWVhbnQNCiAgIHRvIGlk ZW50aWZ5IGEgUEFOQSBTZXNzaW9uIHdpdGhvdXQgcmVmZXJlbmNlIHRvIGFueSBvdGhlcg0KICAg aW5mb3JtYXRpb24sIGFuZCBtYXkgYmUgbmVlZGVkIHRvIGNvcnJlbGF0ZSBoaXN0b3JpY2FsIGF1 dGhlbnRpY2F0aW9uDQogICBpbmZvcm1hdGlvbiB3aXRoIGFjY291bnRpbmcgaW5mb3JtYXRpb24u DQoNCiAgIFRoZSBTZXNzaW9uLUlkIEFWUCBNQVkgdXNlIERpYW1ldGVyIFtSRkMzNTg4XSBtZXNz YWdlIGZvcm1hdHRpbmcuIEluDQogICB0aGlzIGNhc2UgdGhlIEFWUCBjb2RlIGlzIDI2My4NCg0K SkFSSTogKFRlY2huaWNhbCkgU3VyZWx5IHRoZSBBVlAgY29kZSBpcyBhbHdheXMgMjYzLCBkZXNw aXRlIHRoZQ0KICAgICAgdHlwZSBvZiBmb3JtYXR0aW5nIHVzZWQgaW4gdGhlIGFjdHVhbCBpZGVu dGlmaWVyPw0KDQotLS0tLS0tLS0tDQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkb2N1bWVudDogZHJh ZnQtaWV0Zi1wYW5hLXBhbmEteHgudHh0DQptZXNzYWdlczogMjA2DQpub3N5OiBkZm9yc2Jlcg0K cHJpb3JpdHk6IFNob3VsZCBGaXgNCnN0YXR1czogQ2xhcmlmeWluZyBUZXh0IFJlcXVpcmVkDQp0 aXRsZTogVHdvIHNlcGFyYXRlIGNvZGVzIGZvciBTZXNzaW9uIElEIEFWUA0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEgSXNzdWVzIDxwYW5h X2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVyZy5pbmZvOjgwODAv cGFuYS1pc3N1ZXMvaXNzdWU2ND4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Feb 10 03:02:58 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 CAA02444 for ; Tue, 10 Feb 2004 02:13: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 1AqS4h-0005qz-OW for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 02:12:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A7CpDF022465 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 02:12:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS4g-0005qC-08 for pana-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 02:12: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 CAA02388 for ; Tue, 10 Feb 2004 02:12:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS4c-0001Su-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 02:12:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS3Z-0001MP-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 02:11:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqS2y-0001Gq-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 02:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS2x-00056u-3o; Tue, 10 Feb 2004 02:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS2X-0004yj-Ra for pana@optimus.ietf.org; Tue, 10 Feb 2004 02:10:37 -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 CAA01636 for ; Tue, 10 Feb 2004 02:10:35 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS2U-0001FF-00 for pana@ietf.org; Tue, 10 Feb 2004 02:10:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS1W-00019q-00 for pana@ietf.org; Tue, 10 Feb 2004 02:09:34 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AqS0a-000157-00 for pana@ietf.org; Tue, 10 Feb 2004 02:08:36 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1A78bv23053 for ; Tue, 10 Feb 2004 09:08:37 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 09:08:36 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 09:08:36 +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: Tue, 10 Feb 2004 09:08:35 +0200 Message-ID: Thread-Topic: [issue61] PANA SA definition Thread-Index: AcPvo/p0ZUcL0xbLStm+Euvfg/g0zgAALBJA To: X-OriginalArrivalTime: 10 Feb 2004 07:08:36.0002 (UTC) FILETIME=[B3668020:01C3EFA4] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [issue61] PANA SA definition 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 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQpQQU5BIFNlY3VyaXR5IEFzc29jaWF0aW9uOg0KDQogICAgICBUaGUgcmVwcmVzZW50YXRp b24gb2YgdGhlIHRydXN0IHJlbGF0aW9uIGJldHdlZW4gdGhlIFBhQyBhbmQgdGhlDQogICAgICBQ QUEgdGhhdCBpcyBjcmVhdGVkIGF0IHRoZSBlbmQgb2YgdGhlIGF1dGhlbnRpY2F0aW9uIHBoYXNl LiBUaGlzDQogICAgICBzZWN1cml0eSBhc3NvY2lhdGlvbiBpbmNsdWRlcyB0aGUgZGV2aWNlIGlk ZW50aWZpZXIgb2YgdGhlIHBlZXIsDQogICAgICBhbmQgYSBzaGFyZWQga2V5IHdoZW4gYXZhaWxh YmxlLg0KDQpKQVJJOiAoVGVjaG5pY2FsKSBIbW1tLi4uLiB0aGlzIHNlZW1zIHRvIG9taXQgc29t ZSB0aGluZ3MsIGxpa2UNCiAgICAgIGNyeXB0b2dyYXBoaWMgY29udGV4dC4gV2h5IHdvdWxkIGEg c2hhcmVkIGtleSBub3QgYmUgYXZhaWxhYmxlPw0KICAgICAgVW50aWwgaXQgaXMgYXZhaWxhYmxl LCB5b3UgZG9uJ3QgaGF2ZSBhbiBTQSwgcmlnaHQ/IEhlcmUncw0KICAgICAgYW5vdGhlciBjdXQg YXQgdGhpcyBkZWZpbml0aW9uOiAiQSBQQU5BIHNlY3VyaXR5IGFzc29jaWF0aW9uIGlzDQogICAg ICBhIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBQYUMgYW5kIFBBQSwgZm9ybWVkIGJ5IHRoZSBz aGFyaW5nIG9mDQogICAgICBjcnlwdG9ncmFwaGljIGtleWluZyBtYXRlcmlhbCBhbmQgYXNzb2Np YXRlZCBjb250ZXh0LiAgU2VjdXJpdHkNCiAgICAgIGFzc29jaWF0aW9ucyBhcmUgZHVwbGV4LiAg VGhhdCBpcywgb25lIHNlY3VyaXR5IGFzc29jaWF0aW9uIGlzDQogICAgICBuZWVkZWQgdG8gcHJv dGVjdCB0aGUgYmlkaXJlY3Rpb25hbCB0cmFmZmljIGJldHdlZW4gdGhlIFBhQyBhbmQNCiAgICAg IHRoZSBQQUFBLiINCg0KLS0tLS0tLS0tLQ0KY2F0ZWdvcnk6IFRlY2huaWNhbA0KZG9jdW1lbnQ6 IGRyYWZ0LWlldGYtcGFuYS1wYW5hLXh4LnR4dA0KbWVzc2FnZXM6IDIwMg0Kbm9zeTogZGZvcnNi ZXINCnByaW9yaXR5OiBNdXN0IEZpeA0Kc3RhdHVzOiBQZW5kaW5nDQp0aXRsZTogUEFOQSBTQSBk ZWZpbml0aW9uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KUEFOQSBJc3N1ZXMgPHBhbmFfaXNzdWVzQGRhbmZvcnNiZXJnLmluZm8+DQo8aHR0cDov L2RhbmZvcnNiZXJnLmluZm86ODA4MC9wYW5hLWlzc3Vlcy9pc3N1ZTYxPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg== _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Feb 10 03:02:59 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 CAA02443 for ; Tue, 10 Feb 2004 02:13:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS4h-0005rA-U2 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 02:12:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A7CpX0022501 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 02:12:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS4h-0005qm-Aq for pana-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 02:12: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 CAA02394 for ; Tue, 10 Feb 2004 02:12:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS4d-0001T4-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 02:12:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS3b-0001Mf-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 02:11:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqS2y-0001Gt-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 02:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS2z-00057z-K4; Tue, 10 Feb 2004 02:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqS2c-00050K-RD for pana@optimus.ietf.org; Tue, 10 Feb 2004 02:10:42 -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 CAA01721 for ; Tue, 10 Feb 2004 02:10:40 -0500 (EST) From: Dan.Forsberg@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqS2Z-0001Fq-00 for pana@ietf.org; Tue, 10 Feb 2004 02:10:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqS1k-0001B0-00 for pana@ietf.org; Tue, 10 Feb 2004 02:09:48 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AqS16-00015z-00 for pana@ietf.org; Tue, 10 Feb 2004 02:09:08 -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 i1A798q17048 for ; Tue, 10 Feb 2004 09:09:09 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 10 Feb 2004 09:09:08 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 09:09:07 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 09:09:06 +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: Tue, 10 Feb 2004 09:09:06 +0200 Message-ID: Thread-Topic: [issue64] Two separate codes for Session ID AVP Thread-Index: AcPvpH7NVwO4BPKGQ/2lcExtfGNkfwAAD9pw To: X-OriginalArrivalTime: 10 Feb 2004 07:09:06.0635 (UTC) FILETIME=[C5A8B9B0:01C3EFA4] Content-Transfer-Encoding: base64 Subject: [Pana] NEW: [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.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TmV3IHN1Ym1pc3Npb24gZnJvbSBEYW4gRm9yc2JlcmcgPGRhbi5mb3JzYmVyZ0Bub2tpYS5jb20+ Og0KDQo5LjQuMyBTZXNzaW9uLUlkIEFWUA0KDQogICBTZXNzaW9uLUlkIEFWUCAoQ29kZSAxMDI2 KSBoYXMgYW4gb3BhcXVlIGRhdGEgZmllbGQsIHdoaWNoIGlzDQogICBhc3NpZ25lZCBieSB0aGUg UEFBLiBBbGwgbWVzc2FnZXMgcGVydGFpbmluZyB0byBhIHNwZWNpZmljIFBBTkENCiAgIFNlc3Np b24gTVVTVCBpbmNsdWRlIG9ubHkgb25lIFNlc3Npb24tSWQgQVZQIGFuZCB0aGUgc2FtZSB2YWx1 ZSBNVVNUDQogICBiZSB1c2VkIHRocm91Z2hvdXQgdGhlIGxpZmV0aW1lIG9mIGEgc2Vzc2lvbi4g IFdoZW4gcHJlc2VudCwgdGhlDQogICBTZXNzaW9uLUlkIFNIT1VMRCBhcHBlYXIgaW1tZWRpYXRl bHkgZm9sbG93aW5nIHRoZSBQQU5BIGhlYWRlci4NCg0KICAgVGhlIFNlc3Npb24tSWQgTVVTVCBi ZSBnbG9iYWxseSBhbmQgZXRlcm5hbGx5IHVuaXF1ZSwgYXMgaXQgaXMgbWVhbnQNCiAgIHRvIGlk ZW50aWZ5IGEgUEFOQSBTZXNzaW9uIHdpdGhvdXQgcmVmZXJlbmNlIHRvIGFueSBvdGhlcg0KICAg aW5mb3JtYXRpb24sIGFuZCBtYXkgYmUgbmVlZGVkIHRvIGNvcnJlbGF0ZSBoaXN0b3JpY2FsIGF1 dGhlbnRpY2F0aW9uDQogICBpbmZvcm1hdGlvbiB3aXRoIGFjY291bnRpbmcgaW5mb3JtYXRpb24u DQoNCiAgIFRoZSBTZXNzaW9uLUlkIEFWUCBNQVkgdXNlIERpYW1ldGVyIFtSRkMzNTg4XSBtZXNz YWdlIGZvcm1hdHRpbmcuIEluDQogICB0aGlzIGNhc2UgdGhlIEFWUCBjb2RlIGlzIDI2My4NCg0K SkFSSTogKFRlY2huaWNhbCkgU3VyZWx5IHRoZSBBVlAgY29kZSBpcyBhbHdheXMgMjYzLCBkZXNw aXRlIHRoZQ0KICAgICAgdHlwZSBvZiBmb3JtYXR0aW5nIHVzZWQgaW4gdGhlIGFjdHVhbCBpZGVu dGlmaWVyPw0KDQotLS0tLS0tLS0tDQpjYXRlZ29yeTogVGVjaG5pY2FsDQpkb2N1bWVudDogZHJh ZnQtaWV0Zi1wYW5hLXBhbmEteHgudHh0DQptZXNzYWdlczogMjA2DQpub3N5OiBkZm9yc2Jlcg0K cHJpb3JpdHk6IFNob3VsZCBGaXgNCnN0YXR1czogQ2xhcmlmeWluZyBUZXh0IFJlcXVpcmVkDQp0 aXRsZTogVHdvIHNlcGFyYXRlIGNvZGVzIGZvciBTZXNzaW9uIElEIEFWUA0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClBBTkEgSXNzdWVzIDxwYW5h X2lzc3Vlc0BkYW5mb3JzYmVyZy5pbmZvPg0KPGh0dHA6Ly9kYW5mb3JzYmVyZy5pbmZvOjgwODAv cGFuYS1pc3N1ZXMvaXNzdWU2ND4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo= _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Feb 10 04:26: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 EAA07153 for ; Tue, 10 Feb 2004 04:26: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 1AqU9Z-0001sk-SC; Tue, 10 Feb 2004 04:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqU9F-0001s5-Jq for pana@optimus.ietf.org; Tue, 10 Feb 2004 04:25: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 EAA07117 for ; Tue, 10 Feb 2004 04:25:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqU9C-0005ho-00 for pana@ietf.org; Tue, 10 Feb 2004 04:25:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqU8I-0005ct-00 for pana@ietf.org; Tue, 10 Feb 2004 04:24:43 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AqU7S-0005T9-00 for pana@ietf.org; Tue, 10 Feb 2004 04:23:50 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i1A9N9ID017549 for ; Tue, 10 Feb 2004 10:23:09 +0100 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2004021010230789:2075 ; Tue, 10 Feb 2004 10:23:07 +0100 Message-ID: <4028A2FC.6090405@alcatel.fr> Date: Tue, 10 Feb 2004 10:23:08 +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: pana@ietf.org Subject: Re: [Pana] NEW: [issue62] PAA discovery triggered by data traffic References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 02/10/2004 10:23:08, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 02/10/2004 10:23:09 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Alcanet-MTA-scanned-and-authorized: yes 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: 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 hello, please see a couple of comments below: > Dan Forsberg added the comment: >=20 > 4.2 Discovery and Initial Handshake Phase >=20 >=20 > ... >=20 > PaC may also choose to start sending packets before getting > authenticated. In that case, the network should detect this and send > an unsolicited PANA-Start-Request message to PaC. EP is the node that >=20 > Jari: (Technical) Keywords not in upper case. Are these functions > required or not? >=20 > can detect such activity. If EP and PAA are co-located, then an > internal mechanism (e.g. API) between the EP module and the PAA > module on the same host can prompt PAA to start PANA. In case they > are separate, there needs to be an explicit message to prompt PAA. > Upon detecting the need to authenticate a client, EP can send a > PANA-PAA-Discover message to the PAA on behalf of the PaC. This > message carries a device identifier of the PaC in a Device-ID AVP. So > that, the PAA can send the unsolicited PANA-Start-Request message > directly to the PaC. If the link between the EP and PAA is not > secure, the PANA-PAA-Discover message sent from the EP to the PAA > MUST be protected by using, e.g., IPsec. >=20 > JARI: (Technical) This is a bit weak. In any case, the introduction > promised to not talk about the EP-PAA protocol. Now you are talking > about it! It might be better for this document to see the > EP-PAA as a single entity. >=20 1) agree. moreover both paragraph quoted above say the same thing. I=20 would suggest to replace this part of 4.2, dealing with the case where=20 EP and PAA are separated: Upon detecting the need to authenticate a client, EP can send a PANA-PAA-Discover message to the PAA on behalf of the PaC. This message carries a device identifier of the PaC in a Device-ID AVP. So that, the PAA can send the unsolicited PANA-Start-Request message directly to the PaC. If the link between the EP and PAA is not secure, the PANA-PAA-Discover message sent from the EP to the PAA MUST be protected by using, e.g., IPsec. by a nice "see section 4.10 for further details on this case" > 4.10 Event Notification >=20 > Upon detecting the need to authenticate a client, EP can send a > trigger message to the PAA on behalf of the PaC. This can be one of > the messages provided by the PAA-to-EP protocol, or, in the absence > of such a facility, PANA-PAA=5FDiscover can be used as well. This > message MUST carry the device identifier of the PaC. So that, the PAA > can send the unsolicited PANA-Start-Request message directly to the > PaC. If the link between the EP and PAA is not physically secured, > this message sent from EP to PAA MUST be cryptographically protected > (e.g., by using IPsec). >=20 > JARI: (Technical) As commented previously, perhaps it would be better > if the AP-PAA considerations were kept out of this document. Thus > the above trigger messaging could perhaps be omitted here? Section > 4.11, however, is necessary. >=20 > Note by Alper: We can consider deprecating the PANA-based EP-PAA messaging > since the mandatory EP-to-PAA protocol, SNMP, already supports signalling= to > that effect. 2) agree. if we finally go this way, we might group 4.10 and 4.11 under=20 a single "Support for Separate EP" section, as suggested by Jari. thanks, yacine > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > PANA Issues > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > =3D?=DA=99???x%??Ojv?z??=08m????=0C0?'?~???f??f??X??)=DF=A3?Zna=3D=3D _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Feb 10 04:28:12 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 EAA07229 for ; Tue, 10 Feb 2004 04:28:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqUBE-0001x6-20 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 04:27:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A9RiJw007503 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 04:27:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqUBD-0001ww-9a for pana-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 04:27: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 EAA07210 for ; Tue, 10 Feb 2004 04:27:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqUBA-0005tt-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 04:27:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqUAH-0005oe-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 04:26:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqU9a-0005jb-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 04:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqU9Z-0001sk-SC; Tue, 10 Feb 2004 04:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqU9F-0001s5-Jq for pana@optimus.ietf.org; Tue, 10 Feb 2004 04:25: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 EAA07117 for ; Tue, 10 Feb 2004 04:25:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqU9C-0005ho-00 for pana@ietf.org; Tue, 10 Feb 2004 04:25:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqU8I-0005ct-00 for pana@ietf.org; Tue, 10 Feb 2004 04:24:43 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail3.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AqU7S-0005T9-00 for pana@ietf.org; Tue, 10 Feb 2004 04:23:50 -0500 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id i1A9N9ID017549 for ; Tue, 10 Feb 2004 10:23:09 +0100 Received: from alcatel.fr ([172.25.72.141]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2004021010230789:2075 ; Tue, 10 Feb 2004 10:23:07 +0100 Message-ID: <4028A2FC.6090405@alcatel.fr> Date: Tue, 10 Feb 2004 10:23:08 +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: pana@ietf.org Subject: Re: [Pana] NEW: [issue62] PAA discovery triggered by data traffic References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 02/10/2004 10:23:08, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 02/10/2004 10:23:09 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Alcanet-MTA-scanned-and-authorized: yes 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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable hello, please see a couple of comments below: > Dan Forsberg added the comment: >=20 > 4.2 Discovery and Initial Handshake Phase >=20 >=20 > ... >=20 > PaC may also choose to start sending packets before getting > authenticated. In that case, the network should detect this and send > an unsolicited PANA-Start-Request message to PaC. EP is the node that >=20 > Jari: (Technical) Keywords not in upper case. Are these functions > required or not? >=20 > can detect such activity. If EP and PAA are co-located, then an > internal mechanism (e.g. API) between the EP module and the PAA > module on the same host can prompt PAA to start PANA. In case they > are separate, there needs to be an explicit message to prompt PAA. > Upon detecting the need to authenticate a client, EP can send a > PANA-PAA-Discover message to the PAA on behalf of the PaC. This > message carries a device identifier of the PaC in a Device-ID AVP. So > that, the PAA can send the unsolicited PANA-Start-Request message > directly to the PaC. If the link between the EP and PAA is not > secure, the PANA-PAA-Discover message sent from the EP to the PAA > MUST be protected by using, e.g., IPsec. >=20 > JARI: (Technical) This is a bit weak. In any case, the introduction > promised to not talk about the EP-PAA protocol. Now you are talking > about it! It might be better for this document to see the > EP-PAA as a single entity. >=20 1) agree. moreover both paragraph quoted above say the same thing. I=20 would suggest to replace this part of 4.2, dealing with the case where=20 EP and PAA are separated: Upon detecting the need to authenticate a client, EP can send a PANA-PAA-Discover message to the PAA on behalf of the PaC. This message carries a device identifier of the PaC in a Device-ID AVP. So that, the PAA can send the unsolicited PANA-Start-Request message directly to the PaC. If the link between the EP and PAA is not secure, the PANA-PAA-Discover message sent from the EP to the PAA MUST be protected by using, e.g., IPsec. by a nice "see section 4.10 for further details on this case" > 4.10 Event Notification >=20 > Upon detecting the need to authenticate a client, EP can send a > trigger message to the PAA on behalf of the PaC. This can be one of > the messages provided by the PAA-to-EP protocol, or, in the absence > of such a facility, PANA-PAA=5FDiscover can be used as well. This > message MUST carry the device identifier of the PaC. So that, the PAA > can send the unsolicited PANA-Start-Request message directly to the > PaC. If the link between the EP and PAA is not physically secured, > this message sent from EP to PAA MUST be cryptographically protected > (e.g., by using IPsec). >=20 > JARI: (Technical) As commented previously, perhaps it would be better > if the AP-PAA considerations were kept out of this document. Thus > the above trigger messaging could perhaps be omitted here? Section > 4.11, however, is necessary. >=20 > Note by Alper: We can consider deprecating the PANA-based EP-PAA messaging > since the mandatory EP-to-PAA protocol, SNMP, already supports signalling= to > that effect. 2) agree. if we finally go this way, we might group 4.10 and 4.11 under=20 a single "Support for Separate EP" section, as suggested by Jari. thanks, yacine > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > PANA Issues > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > =3D?=DA=99???x%??Ojv?z??=08m????=0C0?'?~???f??f??X??)=DF=A3?Zna=3D=3D _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Feb 10 13:32: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 NAA01436 for ; Tue, 10 Feb 2004 13:32: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 1Aqcfx-0005yB-P5; Tue, 10 Feb 2004 13:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqcfv-0005xn-Jh for pana@optimus.ietf.org; Tue, 10 Feb 2004 13:31: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 NAA01420 for ; Tue, 10 Feb 2004 13:31:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqcft-00076r-00 for pana@ietf.org; Tue, 10 Feb 2004 13:31:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqcev-00070r-00 for pana@ietf.org; Tue, 10 Feb 2004 13:30:57 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Aqcdv-0006qJ-00 for pana@ietf.org; Tue, 10 Feb 2004 13:29:55 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1AITrGv020158; Wed, 11 Feb 2004 03:29:53 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1AITrGA012649; Wed, 11 Feb 2004 03:29:53 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA12646 ; Wed, 11 Feb 2004 03:29:53 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA29149; Wed, 11 Feb 2004 03:29:53 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA28221; Wed, 11 Feb 2004 03:29:52 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1AITpQX022727; Wed, 11 Feb 2004 03:29:52 +0900 (JST) Received: from steelhead ([159.119.168.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSV006ILSPQ5Q@tsbpo1.po.toshiba.co.jp>; Wed, 11 Feb 2004 03:29:50 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Aqccl-00053Y-00; Tue, 10 Feb 2004 10:28:43 -0800 Date: Tue, 10 Feb 2004 10:28:42 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW [issue53] Additional discovery information In-reply-to: To: pana@ietf.org Message-id: <20040210182842.GH16181@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.4i 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=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, Feb 05, 2004 at 11:40:32AM +0200, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > > Jari Arkko: > > - "Additional discovery information?" > > I'm not sure if there is a need to provide some additional > > information in the discovery phase. For instance, is there a > > need to identify the NAS/PAA in a scenario where the NAS/PAA > > has multiple interfaces and multiple addresses? Knowing you > > are still connected to the same NAS might help future handoff > > designs. > > Alper Yegin: > This sounds like a useful feature. I'd recommend we open an issue and > investigate this. It can assist movement detection. I agree that this might be a useful feature. This might help the VLAN hopping scenario described in section 10.2.2.1 of the PANA Framework draft. How about defining a PAA-Identifier AVP that contains one of the global addresses of the PAA? Usage: - A PAA-Identifier AVP MAY be contained in PANA-Start-Request message. - A PAA-Identifier AVP and a Session-Id AVP MAY be contained in a PANA-PAA-Discover message. (Note that the current specification already allows a Session-Id AVP to be carried in PDI.) - When a PAA receives a PANA-PAA-Discover message with a known PANA session identifier in a Session-Id AVP and its own PAA identifier in a PAA-Identifier AVP, it initiates a PANA-ReAuth-Request/Answer exchange. Yoshihiro Ohba > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 192 > nosy: dforsber > priority: May Fix > status: Pending > title: Additional discovery information > __________________________________________________ > PANA Issues > > __________________________________________________ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Feb 10 13:34: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 NAA01526 for ; Tue, 10 Feb 2004 13:34: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 1Aqchw-0006BX-L9 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 13:34:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AIY4Ca023775 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 13:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqchw-0006BO-Ec for pana-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 13:34: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 NAA01495 for ; Tue, 10 Feb 2004 13:34:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqchu-0007Lv-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 13:34:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqcgw-0007ER-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 13:33:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqcfz-00077r-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 13:32:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqcfx-0005yB-P5; Tue, 10 Feb 2004 13:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqcfv-0005xn-Jh for pana@optimus.ietf.org; Tue, 10 Feb 2004 13:31: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 NAA01420 for ; Tue, 10 Feb 2004 13:31:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqcft-00076r-00 for pana@ietf.org; Tue, 10 Feb 2004 13:31:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqcev-00070r-00 for pana@ietf.org; Tue, 10 Feb 2004 13:30:57 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Aqcdv-0006qJ-00 for pana@ietf.org; Tue, 10 Feb 2004 13:29:55 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1AITrGv020158; Wed, 11 Feb 2004 03:29:53 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1AITrGA012649; Wed, 11 Feb 2004 03:29:53 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id DAA12646 ; Wed, 11 Feb 2004 03:29:53 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id DAA29149; Wed, 11 Feb 2004 03:29:53 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id DAA28221; Wed, 11 Feb 2004 03:29:52 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1AITpQX022727; Wed, 11 Feb 2004 03:29:52 +0900 (JST) Received: from steelhead ([159.119.168.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSV006ILSPQ5Q@tsbpo1.po.toshiba.co.jp>; Wed, 11 Feb 2004 03:29:50 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Aqccl-00053Y-00; Tue, 10 Feb 2004 10:28:43 -0800 Date: Tue, 10 Feb 2004 10:28:42 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW [issue53] Additional discovery information In-reply-to: To: pana@ietf.org Message-id: <20040210182842.GH16181@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.4i 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=AWL autolearn=no version=2.60 On Thu, Feb 05, 2004 at 11:40:32AM +0200, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > > Jari Arkko: > > - "Additional discovery information?" > > I'm not sure if there is a need to provide some additional > > information in the discovery phase. For instance, is there a > > need to identify the NAS/PAA in a scenario where the NAS/PAA > > has multiple interfaces and multiple addresses? Knowing you > > are still connected to the same NAS might help future handoff > > designs. > > Alper Yegin: > This sounds like a useful feature. I'd recommend we open an issue and > investigate this. It can assist movement detection. I agree that this might be a useful feature. This might help the VLAN hopping scenario described in section 10.2.2.1 of the PANA Framework draft. How about defining a PAA-Identifier AVP that contains one of the global addresses of the PAA? Usage: - A PAA-Identifier AVP MAY be contained in PANA-Start-Request message. - A PAA-Identifier AVP and a Session-Id AVP MAY be contained in a PANA-PAA-Discover message. (Note that the current specification already allows a Session-Id AVP to be carried in PDI.) - When a PAA receives a PANA-PAA-Discover message with a known PANA session identifier in a Session-Id AVP and its own PAA identifier in a PAA-Identifier AVP, it initiates a PANA-ReAuth-Request/Answer exchange. Yoshihiro Ohba > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 192 > nosy: dforsber > priority: May Fix > status: Pending > title: Additional discovery information > __________________________________________________ > PANA Issues > > __________________________________________________ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Feb 10 14:55: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 OAA05495 for ; Tue, 10 Feb 2004 14:55: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 1AqdyH-0004Vg-Di; Tue, 10 Feb 2004 14:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqdxP-0004U2-RP for pana@optimus.ietf.org; Tue, 10 Feb 2004 14:54: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 OAA05436 for ; Tue, 10 Feb 2004 14:54:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqdxN-0000P0-00 for pana@ietf.org; Tue, 10 Feb 2004 14:54:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqdwP-0000Jz-00 for pana@ietf.org; Tue, 10 Feb 2004 14:53:06 -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 1Aqdvm-0000Ep-00 for pana@ietf.org; Tue, 10 Feb 2004 14:52:26 -0500 Date: Tue, 10 Feb 2004 11:52:39 -0800 From: Alper Yegin To: CC: "Patil Basavaraj (NET/Dallas)" , Thomas Narten , Margaret Wasserman Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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] IETF 59 PANA meeting agenda (early draft) 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 These are the proposed agenda items for the PANA meeting at IETF 59. 1. Preliminaries 2. PANA protocol update and open issues 3. SNMP for PAA-to-EP protocol 4. PANA framework 5. PANA-IPsec update and open issues 6. Next steps Details will be filled in later. Please let us know if you have comments... - Chairs _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Feb 10 14:57: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 OAA05606 for ; Tue, 10 Feb 2004 14:57: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 1Aqe0H-0004dO-04 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 14:57:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AJv4Zp017810 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 14:57:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqe0G-0004dB-QM for pana-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 14:57: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 OAA05555 for ; Tue, 10 Feb 2004 14:57:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqe0E-0000gi-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 14:57:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqdzE-0000Z2-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 14:56:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqdyH-0000Tn-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 14:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqdyH-0004Vg-Di; Tue, 10 Feb 2004 14:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqdxP-0004U2-RP for pana@optimus.ietf.org; Tue, 10 Feb 2004 14:54: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 OAA05436 for ; Tue, 10 Feb 2004 14:54:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqdxN-0000P0-00 for pana@ietf.org; Tue, 10 Feb 2004 14:54:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqdwP-0000Jz-00 for pana@ietf.org; Tue, 10 Feb 2004 14:53:06 -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 1Aqdvm-0000Ep-00 for pana@ietf.org; Tue, 10 Feb 2004 14:52:26 -0500 Date: Tue, 10 Feb 2004 11:52:39 -0800 From: Alper Yegin To: CC: "Patil Basavaraj (NET/Dallas)" , Thomas Narten , Margaret Wasserman Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Pana] IETF 59 PANA meeting agenda (early draft) 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 These are the proposed agenda items for the PANA meeting at IETF 59. 1. Preliminaries 2. PANA protocol update and open issues 3. SNMP for PAA-to-EP protocol 4. PANA framework 5. PANA-IPsec update and open issues 6. Next steps Details will be filled in later. Please let us know if you have comments... - Chairs _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Feb 10 16:04: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 QAA14855 for ; Tue, 10 Feb 2004 16:04: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 1Aqf32-0004zb-I8; Tue, 10 Feb 2004 16:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf2D-0004yO-Pg for pana@optimus.ietf.org; Tue, 10 Feb 2004 16:03: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 QAA14710 for ; Tue, 10 Feb 2004 16:03:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf2C-0000mo-00 for pana@ietf.org; Tue, 10 Feb 2004 16:03:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqf1L-0000hi-00 for pana@ietf.org; Tue, 10 Feb 2004 16:02:15 -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 1Aqf14-0000bk-00 for pana@ietf.org; Tue, 10 Feb 2004 16:01:59 -0500 Date: Tue, 10 Feb 2004 13:02:12 -0800 Subject: Re: [Pana] NEW [issue53] Additional discovery information From: Alper Yegin To: Yoshihiro Ohba , Message-ID: In-Reply-To: <20040210182842.GH16181@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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 >>> Jari Arkko: >>> - "Additional discovery information?" >>> I'm not sure if there is a need to provide some additional >>> information in the discovery phase. For instance, is there a >>> need to identify the NAS/PAA in a scenario where the NAS/PAA >>> has multiple interfaces and multiple addresses? Knowing you >>> are still connected to the same NAS might help future handoff >>> designs. >> >> Alper Yegin: >> This sounds like a useful feature. I'd recommend we open an issue and >> investigate this. It can assist movement detection. > > I agree that this might be a useful feature. This might help the VLAN > hopping scenario described in section 10.2.2.1 of the PANA Framework > draft. How about defining a PAA-Identifier AVP that contains one of > the global addresses of the PAA? > > Usage: > > - A PAA-Identifier AVP MAY be contained in PANA-Start-Request message. > > - A PAA-Identifier AVP and a Session-Id AVP MAY be contained in > a PANA-PAA-Discover message. (Note that the current specification already > allows a Session-Id AVP to be carried in PDI.) > > - When a PAA receives a PANA-PAA-Discover message with a known PANA > session identifier in a Session-Id AVP and its own PAA identifier in a > PAA-Identifier AVP, it initiates a PANA-ReAuth-Request/Answer exchange. I guess we don't want to use PAA device ID for this, because that can be a link-local address. Is that right? We might consider PAA-id to be an opaque value, and mention that it can be an IP address of the PAA. Is it worth having this flexibility? There is some text in 4.9 Mobility Management that talks about how to determine the previous PAA. We shall remember to update that text too. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Feb 10 16:06: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 QAA15191 for ; Tue, 10 Feb 2004 16:06: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 1Aqf54-0005Fv-Tz for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 16:06:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AL66kd020200 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 16:06:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf54-0005Fj-Oz for pana-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:06: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 QAA15064 for ; Tue, 10 Feb 2004 16:06:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf53-000178-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 16:06:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqf46-0000xy-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 16:05:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf37-0000rk-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 16: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 1Aqf32-0004zb-I8; Tue, 10 Feb 2004 16:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqf2D-0004yO-Pg for pana@optimus.ietf.org; Tue, 10 Feb 2004 16:03: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 QAA14710 for ; Tue, 10 Feb 2004 16:03:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqf2C-0000mo-00 for pana@ietf.org; Tue, 10 Feb 2004 16:03:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqf1L-0000hi-00 for pana@ietf.org; Tue, 10 Feb 2004 16:02:15 -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 1Aqf14-0000bk-00 for pana@ietf.org; Tue, 10 Feb 2004 16:01:59 -0500 Date: Tue, 10 Feb 2004 13:02:12 -0800 Subject: Re: [Pana] NEW [issue53] Additional discovery information From: Alper Yegin To: Yoshihiro Ohba , Message-ID: In-Reply-To: <20040210182842.GH16181@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 >>> Jari Arkko: >>> - "Additional discovery information?" >>> I'm not sure if there is a need to provide some additional >>> information in the discovery phase. For instance, is there a >>> need to identify the NAS/PAA in a scenario where the NAS/PAA >>> has multiple interfaces and multiple addresses? Knowing you >>> are still connected to the same NAS might help future handoff >>> designs. >> >> Alper Yegin: >> This sounds like a useful feature. I'd recommend we open an issue and >> investigate this. It can assist movement detection. > > I agree that this might be a useful feature. This might help the VLAN > hopping scenario described in section 10.2.2.1 of the PANA Framework > draft. How about defining a PAA-Identifier AVP that contains one of > the global addresses of the PAA? > > Usage: > > - A PAA-Identifier AVP MAY be contained in PANA-Start-Request message. > > - A PAA-Identifier AVP and a Session-Id AVP MAY be contained in > a PANA-PAA-Discover message. (Note that the current specification already > allows a Session-Id AVP to be carried in PDI.) > > - When a PAA receives a PANA-PAA-Discover message with a known PANA > session identifier in a Session-Id AVP and its own PAA identifier in a > PAA-Identifier AVP, it initiates a PANA-ReAuth-Request/Answer exchange. I guess we don't want to use PAA device ID for this, because that can be a link-local address. Is that right? We might consider PAA-id to be an opaque value, and mention that it can be an IP address of the PAA. Is it worth having this flexibility? There is some text in 4.9 Mobility Management that talks about how to determine the previous PAA. We shall remember to update that text too. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Feb 10 16:22: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 QAA18031 for ; Tue, 10 Feb 2004 16:22: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 1AqfKT-0008BO-0K; Tue, 10 Feb 2004 16:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfJl-0008AL-1O for pana@optimus.ietf.org; Tue, 10 Feb 2004 16:21: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 QAA17827 for ; Tue, 10 Feb 2004 16:21:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfJj-0004Dq-00 for pana@ietf.org; Tue, 10 Feb 2004 16:21:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfIk-00041P-00 for pana@ietf.org; Tue, 10 Feb 2004 16:20:15 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AqfHh-0003l6-00 for pana@ietf.org; Tue, 10 Feb 2004 16:19:09 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1ALJ2Gv001943; Wed, 11 Feb 2004 06:19:02 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1ALJ2dh029249; Wed, 11 Feb 2004 06:19:02 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA29248 ; Wed, 11 Feb 2004 06:19:02 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA01549; Wed, 11 Feb 2004 06:19:02 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id GAA25137; Wed, 11 Feb 2004 06:19:01 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1ALJ0QX016332; Wed, 11 Feb 2004 06:19:01 +0900 (JST) Received: from steelhead ([159.119.168.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSW00A3T0JNBW@tsbpo1.po.toshiba.co.jp>; Wed, 11 Feb 2004 06:19:00 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AqfGm-0005Pc-00; Tue, 10 Feb 2004 13:18:12 -0800 Date: Tue, 10 Feb 2004 13:18:12 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW [issue53] Additional discovery information In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040210211812.GK16181@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.4i References: <20040210182842.GH16181@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: , On Tue, Feb 10, 2004 at 01:02:12PM -0800, Alper Yegin wrote: > >>> Jari Arkko: > >>> - "Additional discovery information?" > >>> I'm not sure if there is a need to provide some additional > >>> information in the discovery phase. For instance, is there a > >>> need to identify the NAS/PAA in a scenario where the NAS/PAA > >>> has multiple interfaces and multiple addresses? Knowing you > >>> are still connected to the same NAS might help future handoff > >>> designs. > >> > >> Alper Yegin: > >> This sounds like a useful feature. I'd recommend we open an issue and > >> investigate this. It can assist movement detection. > > > > I agree that this might be a useful feature. This might help the VLAN > > hopping scenario described in section 10.2.2.1 of the PANA Framework > > draft. How about defining a PAA-Identifier AVP that contains one of > > the global addresses of the PAA? > > > > Usage: > > > > - A PAA-Identifier AVP MAY be contained in PANA-Start-Request message. > > > > - A PAA-Identifier AVP and a Session-Id AVP MAY be contained in > > a PANA-PAA-Discover message. (Note that the current specification already > > allows a Session-Id AVP to be carried in PDI.) > > > > - When a PAA receives a PANA-PAA-Discover message with a known PANA > > session identifier in a Session-Id AVP and its own PAA identifier in a > > PAA-Identifier AVP, it initiates a PANA-ReAuth-Request/Answer exchange. > > I guess we don't want to use PAA device ID for this, because that can be a > link-local address. Is that right? Yes. > > We might consider PAA-id to be an opaque value, and mention that it can be > an IP address of the PAA. Is it worth having this flexibility? If global uniqueness is required (I think it is), allowing an opaque value will introduce ambiguity. > > There is some text in 4.9 Mobility Management that talks about how to > determine the previous PAA. We shall remember to update that text too. OK. Yoshihiro Ohba > > Alper > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Feb 10 16:30: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 QAA18799 for ; Tue, 10 Feb 2004 16:30: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 1AqfS5-0000Te-M0 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 16:29:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ALTrLI001828 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 16:29:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfS5-0000TP-HJ for pana-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 16:29: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 QAA18633 for ; Tue, 10 Feb 2004 16:29:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfS3-0005fJ-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 16:29:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfPo-00059c-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 16:27:33 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqfOV-0004tD-02 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 16:26:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqfKe-0002aC-Ik for pana-web-archive@ietf.org; Tue, 10 Feb 2004 16:22:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfKT-0008BO-0K; Tue, 10 Feb 2004 16:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqfJl-0008AL-1O for pana@optimus.ietf.org; Tue, 10 Feb 2004 16:21: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 QAA17827 for ; Tue, 10 Feb 2004 16:21:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqfJj-0004Dq-00 for pana@ietf.org; Tue, 10 Feb 2004 16:21:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqfIk-00041P-00 for pana@ietf.org; Tue, 10 Feb 2004 16:20:15 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AqfHh-0003l6-00 for pana@ietf.org; Tue, 10 Feb 2004 16:19:09 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1ALJ2Gv001943; Wed, 11 Feb 2004 06:19:02 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1ALJ2dh029249; Wed, 11 Feb 2004 06:19:02 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA29248 ; Wed, 11 Feb 2004 06:19:02 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA01549; Wed, 11 Feb 2004 06:19:02 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id GAA25137; Wed, 11 Feb 2004 06:19:01 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1ALJ0QX016332; Wed, 11 Feb 2004 06:19:01 +0900 (JST) Received: from steelhead ([159.119.168.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSW00A3T0JNBW@tsbpo1.po.toshiba.co.jp>; Wed, 11 Feb 2004 06:19:00 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AqfGm-0005Pc-00; Tue, 10 Feb 2004 13:18:12 -0800 Date: Tue, 10 Feb 2004 13:18:12 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW [issue53] Additional discovery information In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040210211812.GK16181@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.4i References: <20040210182842.GH16181@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 On Tue, Feb 10, 2004 at 01:02:12PM -0800, Alper Yegin wrote: > >>> Jari Arkko: > >>> - "Additional discovery information?" > >>> I'm not sure if there is a need to provide some additional > >>> information in the discovery phase. For instance, is there a > >>> need to identify the NAS/PAA in a scenario where the NAS/PAA > >>> has multiple interfaces and multiple addresses? Knowing you > >>> are still connected to the same NAS might help future handoff > >>> designs. > >> > >> Alper Yegin: > >> This sounds like a useful feature. I'd recommend we open an issue and > >> investigate this. It can assist movement detection. > > > > I agree that this might be a useful feature. This might help the VLAN > > hopping scenario described in section 10.2.2.1 of the PANA Framework > > draft. How about defining a PAA-Identifier AVP that contains one of > > the global addresses of the PAA? > > > > Usage: > > > > - A PAA-Identifier AVP MAY be contained in PANA-Start-Request message. > > > > - A PAA-Identifier AVP and a Session-Id AVP MAY be contained in > > a PANA-PAA-Discover message. (Note that the current specification already > > allows a Session-Id AVP to be carried in PDI.) > > > > - When a PAA receives a PANA-PAA-Discover message with a known PANA > > session identifier in a Session-Id AVP and its own PAA identifier in a > > PAA-Identifier AVP, it initiates a PANA-ReAuth-Request/Answer exchange. > > I guess we don't want to use PAA device ID for this, because that can be a > link-local address. Is that right? Yes. > > We might consider PAA-id to be an opaque value, and mention that it can be > an IP address of the PAA. Is it worth having this flexibility? If global uniqueness is required (I think it is), allowing an opaque value will introduce ambiguity. > > There is some text in 4.9 Mobility Management that talks about how to > determine the previous PAA. We shall remember to update that text too. OK. Yoshihiro Ohba > > Alper > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Feb 10 16:39: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 QAA20225 for ; Tue, 10 Feb 2004 16:39: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 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 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 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 From pana-admin@ietf.org Tue Feb 10 17:45: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 RAA27003 for ; Tue, 10 Feb 2004 17:45: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 1Aqgcn-0002Bd-Ab; Tue, 10 Feb 2004 17:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgby-0002AZ-4r for pana@optimus.ietf.org; Tue, 10 Feb 2004 17:44: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 RAA26994 for ; Tue, 10 Feb 2004 17:44:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgbv-0002q9-00 for pana@ietf.org; Tue, 10 Feb 2004 17:44:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqgb0-0002lp-00 for pana@ietf.org; Tue, 10 Feb 2004 17:43:11 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AqgaW-0002hF-00 for pana@ietf.org; Tue, 10 Feb 2004 17:42:41 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1AMgbGv025172; Wed, 11 Feb 2004 07:42:37 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1AMgaXZ026353; Wed, 11 Feb 2004 07:42:36 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA26352 ; Wed, 11 Feb 2004 07:42:36 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA19932; Wed, 11 Feb 2004 07:42:36 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA28223; Wed, 11 Feb 2004 07:42:35 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1AMgZQX001192; Wed, 11 Feb 2004 07:42:35 +0900 (JST) Received: from steelhead ([159.119.168.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSW00C2U4EXJ7@tsbpo1.po.toshiba.co.jp>; Wed, 11 Feb 2004 07:42:34 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AqgaK-0005cP-00; Tue, 10 Feb 2004 14:42:28 -0800 Date: Tue, 10 Feb 2004 14:42:28 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040210224228.GB21495@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.4i References: <20040209225949.GB15608@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: , On Tue, Feb 10, 2004 at 01:35:58PM -0800, Alper Yegin wrote: > > 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. That is possible. But I think (timer-based) retransmission is needed anyway for unsolicited PSR. In addition, when PSR carries EAP-Request, timer-based retransmission of PSR should not occur in PANA. Instead, PAA should rely on retransmission at EAP layer, like PANA-Auth-Request message. Yoshihiro Ohba > > 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 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Feb 10 17:46:44 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 RAA27048 for ; Tue, 10 Feb 2004 17:46:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgdx-0002Mt-TO for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 17:46:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AMkDbR009097 for pana-archive@odin.ietf.org; Tue, 10 Feb 2004 17:46:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgdx-0002Me-JO for pana-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 17:46:13 -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 RAA27044 for ; Tue, 10 Feb 2004 17:46:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgdv-00030r-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 17:46:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqgcy-0002vp-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 17:45:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgcp-0002qi-00 for pana-web-archive@ietf.org; Tue, 10 Feb 2004 17:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgcn-0002Bd-Ab; Tue, 10 Feb 2004 17:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgby-0002AZ-4r for pana@optimus.ietf.org; Tue, 10 Feb 2004 17:44: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 RAA26994 for ; Tue, 10 Feb 2004 17:44:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgbv-0002q9-00 for pana@ietf.org; Tue, 10 Feb 2004 17:44:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqgb0-0002lp-00 for pana@ietf.org; Tue, 10 Feb 2004 17:43:11 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AqgaW-0002hF-00 for pana@ietf.org; Tue, 10 Feb 2004 17:42:41 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1AMgbGv025172; Wed, 11 Feb 2004 07:42:37 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1AMgaXZ026353; Wed, 11 Feb 2004 07:42:36 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA26352 ; Wed, 11 Feb 2004 07:42:36 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA19932; Wed, 11 Feb 2004 07:42:36 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA28223; Wed, 11 Feb 2004 07:42:35 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1AMgZQX001192; Wed, 11 Feb 2004 07:42:35 +0900 (JST) Received: from steelhead ([159.119.168.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSW00C2U4EXJ7@tsbpo1.po.toshiba.co.jp>; Wed, 11 Feb 2004 07:42:34 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AqgaK-0005cP-00; Tue, 10 Feb 2004 14:42:28 -0800 Date: Tue, 10 Feb 2004 14:42:28 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040210224228.GB21495@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.4i References: <20040209225949.GB15608@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 On Tue, Feb 10, 2004 at 01:35:58PM -0800, Alper Yegin wrote: > > 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. That is possible. But I think (timer-based) retransmission is needed anyway for unsolicited PSR. In addition, when PSR carries EAP-Request, timer-based retransmission of PSR should not occur in PANA. Instead, PAA should rely on retransmission at EAP layer, like PANA-Auth-Request message. Yoshihiro Ohba > > 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 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Feb 11 15:17: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 PAA19408 for ; Wed, 11 Feb 2004 15:17: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 1Ar0n6-0008OM-EJ; Wed, 11 Feb 2004 15:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0mw-0008Le-Iy for pana@optimus.ietf.org; Wed, 11 Feb 2004 15:16: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 PAA19301 for ; Wed, 11 Feb 2004 15:16:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0mv-0007RZ-00 for pana@ietf.org; Wed, 11 Feb 2004 15:16:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar0m6-0007Lh-00 for pana@ietf.org; Wed, 11 Feb 2004 15:15:59 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0l1-0007GN-00 for pana@ietf.org; Wed, 11 Feb 2004 15:14:51 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1BKEmGv018109; Thu, 12 Feb 2004 05:14:48 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1BKEmRf028487; Thu, 12 Feb 2004 05:14:48 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA28486 ; Thu, 12 Feb 2004 05:14:48 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA16106; Thu, 12 Feb 2004 05:14:47 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA22538; Thu, 12 Feb 2004 05:14:47 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1BKEkQX016973; Thu, 12 Feb 2004 05:14:47 +0900 (JST) Received: from steelhead ([159.119.168.157]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSX004KKS8KF6@tsbpo1.po.toshiba.co.jp>; Thu, 12 Feb 2004 05:14:45 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ar0jj-0008N2-00; Wed, 11 Feb 2004 12:13:31 -0800 Date: Wed, 11 Feb 2004 12:13:30 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue52] Details of double authentication In-reply-to: To: pana@ietf.org Message-id: <20040211201330.GG28754@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.4i 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=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, Feb 05, 2004 at 11:40:50AM +0200, Dan.Forsberg@nokia.com wrote: > Dan Forsberg added the comment: > > >Jari Arkko wrote: > > - "Details of double authentication" > > > > Perhaps its just me, but I did not find all the details > > regarding the use of two (NAP and ISP) authentications. Is > > this supported or not? Are they performed in sequence? PANA supports two EAP sequences, one for NAP authentication and the other ISP authentication. They are performed in sequence. These are not explicitly specified in the draft and need to be revised. Here is my suggested text on this: - Change the first paragraph of section 4.3 " The main task in authentication phase is to carry EAP messages between PaC and PAA. All EAP messages except for EAP Success/Failure messages are carried in the PANA-Auth-Request/PANA-Auth-Answer messages. When an EAP Success/Failure message is sent from a PAA, the message is carried in the PANA-Bind-Request message. The PANA- Bind-Request message is acknowledged with a PANA-Bind-Answer. It is possible to carry multiple EAP sequences in a single PANA session. " to: " The main task in authentication phase is to carry EAP messages between PaC and PAA. All EAP messages except for EAP Success/Failure messages are carried in the PANA-Auth-Request/PANA-Auth-Answer messages. When an EAP Success/Failure message is sent from a PAA, the message is carried in the PANA-Bind-Request message. The PANA-Bind-Request message is acknowledged with a PANA-Bind-Answer. PANA supports two EAP sequences to be sequencially performed in a single PANA session, where an PANA-Bind-Request/Answer exchange occurs at the end of each EAP sequence. " > > Does it > > look like a re-authentication, or do you provide a bit > > somewhere that indicates whether this EAP run relates to the > > NAP or the ISP authentication? Is there a PANA Bind Request - > > Answer pair in between or not? PAA can indicate which EAP sequence is for which (NAP or ISP) authentication. This is specified in section 4.3. Also, I think it might be good to add the following example of NAP and ISP separate authentication as well as ISP selection in section 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. The PANA SA is established based on the unique and fresh session key provided by the EAP method in the first EAP sequence. 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")] -----> PANA-Auth-Answer(y+1,x+1)[EAP] <----- PANA-Auth-Request(x+2,y+1)[EAP] -----> PANA-Auth-Answer(y+2,x+2)[EAP] <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Key-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Key-Id, Protection-Cap., MAC] <----- PANA-Auth-Request(x+3,y+4) // ISP authentication [EAP, ISP-Information("ISP1")] -----> PANA-Auth-Answer(y+4,x+4)[EAP] <----- PANA-Auth-Request(x+4,y+5)[EAP] -----> PANA-Auth-Answer(y+5,x+5)[EAP] <----- PANA-Bind-Request(x+5,y+6) [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+6,x+5) [Device-Id, Protection-Cap., MAC] Figure X: A Message Sequence for NAP and ISP Separate Authentication " Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Feb 11 15:19: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 PAA19627 for ; Wed, 11 Feb 2004 15:19: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 1Ar0ov-0000uR-EP for pana-archive@odin.ietf.org; Wed, 11 Feb 2004 15:18:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKIrFT003486 for pana-archive@odin.ietf.org; Wed, 11 Feb 2004 15:18:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0ov-0000u3-9F for pana-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 15:18: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 PAA19560 for ; Wed, 11 Feb 2004 15:18:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0ou-0007fC-00 for pana-web-archive@ietf.org; Wed, 11 Feb 2004 15:18:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar0ny-0007Yb-00 for pana-web-archive@ietf.org; Wed, 11 Feb 2004 15:17:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0n9-0007T6-00 for pana-web-archive@ietf.org; Wed, 11 Feb 2004 15: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 1Ar0n6-0008OM-EJ; Wed, 11 Feb 2004 15:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0mw-0008Le-Iy for pana@optimus.ietf.org; Wed, 11 Feb 2004 15:16: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 PAA19301 for ; Wed, 11 Feb 2004 15:16:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0mv-0007RZ-00 for pana@ietf.org; Wed, 11 Feb 2004 15:16:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar0m6-0007Lh-00 for pana@ietf.org; Wed, 11 Feb 2004 15:15:59 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0l1-0007GN-00 for pana@ietf.org; Wed, 11 Feb 2004 15:14:51 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1BKEmGv018109; Thu, 12 Feb 2004 05:14:48 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1BKEmRf028487; Thu, 12 Feb 2004 05:14:48 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA28486 ; Thu, 12 Feb 2004 05:14:48 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA16106; Thu, 12 Feb 2004 05:14:47 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA22538; Thu, 12 Feb 2004 05:14:47 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1BKEkQX016973; Thu, 12 Feb 2004 05:14:47 +0900 (JST) Received: from steelhead ([159.119.168.157]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSX004KKS8KF6@tsbpo1.po.toshiba.co.jp>; Thu, 12 Feb 2004 05:14:45 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ar0jj-0008N2-00; Wed, 11 Feb 2004 12:13:31 -0800 Date: Wed, 11 Feb 2004 12:13:30 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue52] Details of double authentication In-reply-to: To: pana@ietf.org Message-id: <20040211201330.GG28754@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.4i 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=AWL autolearn=no version=2.60 On Thu, Feb 05, 2004 at 11:40:50AM +0200, Dan.Forsberg@nokia.com wrote: > Dan Forsberg added the comment: > > >Jari Arkko wrote: > > - "Details of double authentication" > > > > Perhaps its just me, but I did not find all the details > > regarding the use of two (NAP and ISP) authentications. Is > > this supported or not? Are they performed in sequence? PANA supports two EAP sequences, one for NAP authentication and the other ISP authentication. They are performed in sequence. These are not explicitly specified in the draft and need to be revised. Here is my suggested text on this: - Change the first paragraph of section 4.3 " The main task in authentication phase is to carry EAP messages between PaC and PAA. All EAP messages except for EAP Success/Failure messages are carried in the PANA-Auth-Request/PANA-Auth-Answer messages. When an EAP Success/Failure message is sent from a PAA, the message is carried in the PANA-Bind-Request message. The PANA- Bind-Request message is acknowledged with a PANA-Bind-Answer. It is possible to carry multiple EAP sequences in a single PANA session. " to: " The main task in authentication phase is to carry EAP messages between PaC and PAA. All EAP messages except for EAP Success/Failure messages are carried in the PANA-Auth-Request/PANA-Auth-Answer messages. When an EAP Success/Failure message is sent from a PAA, the message is carried in the PANA-Bind-Request message. The PANA-Bind-Request message is acknowledged with a PANA-Bind-Answer. PANA supports two EAP sequences to be sequencially performed in a single PANA session, where an PANA-Bind-Request/Answer exchange occurs at the end of each EAP sequence. " > > Does it > > look like a re-authentication, or do you provide a bit > > somewhere that indicates whether this EAP run relates to the > > NAP or the ISP authentication? Is there a PANA Bind Request - > > Answer pair in between or not? PAA can indicate which EAP sequence is for which (NAP or ISP) authentication. This is specified in section 4.3. Also, I think it might be good to add the following example of NAP and ISP separate authentication as well as ISP selection in section 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. The PANA SA is established based on the unique and fresh session key provided by the EAP method in the first EAP sequence. 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")] -----> PANA-Auth-Answer(y+1,x+1)[EAP] <----- PANA-Auth-Request(x+2,y+1)[EAP] -----> PANA-Auth-Answer(y+2,x+2)[EAP] <----- PANA-Bind-Request(x+3,y+2) [EAP{Success}, Device-Id, Key-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+3,x+3) [Device-Id, Key-Id, Protection-Cap., MAC] <----- PANA-Auth-Request(x+3,y+4) // ISP authentication [EAP, ISP-Information("ISP1")] -----> PANA-Auth-Answer(y+4,x+4)[EAP] <----- PANA-Auth-Request(x+4,y+5)[EAP] -----> PANA-Auth-Answer(y+5,x+5)[EAP] <----- PANA-Bind-Request(x+5,y+6) [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC] -----> PANA-Bind-Answer(y+6,x+5) [Device-Id, Protection-Cap., MAC] Figure X: A Message Sequence for NAP and ISP Separate Authentication " Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Feb 11 15:26: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 PAA20047 for ; Wed, 11 Feb 2004 15:26: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 1Ar0vp-00026T-3f; Wed, 11 Feb 2004 15:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0vf-00025z-H8 for pana@optimus.ietf.org; Wed, 11 Feb 2004 15:25: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 PAA20035 for ; Wed, 11 Feb 2004 15:25:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0ve-0000XI-00 for pana@ietf.org; Wed, 11 Feb 2004 15:25:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar0uh-0000Qv-00 for pana@ietf.org; Wed, 11 Feb 2004 15:24:52 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0tn-0000L3-00 for pana@ietf.org; Wed, 11 Feb 2004 15:23:55 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1BKNtGv020800 for ; Thu, 12 Feb 2004 05:23:55 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1BKNtPP001707 for ; Thu, 12 Feb 2004 05:23:55 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA01706 ; Thu, 12 Feb 2004 05:23:54 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA18317; Thu, 12 Feb 2004 05:23:54 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA26648; Thu, 12 Feb 2004 05:23:54 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1BKNrQX018168 for ; Thu, 12 Feb 2004 05:23:53 +0900 (JST) Received: from steelhead ([159.119.168.157]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSX004MISNRF6@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Thu, 12 Feb 2004 05:23:52 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ar0sy-0008Oi-00 for ; Wed, 11 Feb 2004 12:23:04 -0800 Date: Wed, 11 Feb 2004 12:23:04 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue61] PANA SA definition In-reply-to: To: pana@ietf.org Message-id: <20040211202304.GH28754@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.4i 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=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 Tue, Feb 10, 2004 at 09:08:35AM +0200, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > PANA Security Association: > > The representation of the trust relation between the PaC and the > PAA that is created at the end of the authentication phase. This > security association includes the device identifier of the peer, > and a shared key when available. > > JARI: (Technical) Hmmm.... this seems to omit some things, like > cryptographic context. Why would a shared key not be available? > Until it is available, you don't have an SA, right? Here's > another cut at this definition: "A PANA security association is > a relationship between the PaC and PAA, formed by the sharing of > cryptographic keying material and associated context. Security > associations are duplex. That is, one security association is > needed to protect the bidirectional traffic between the PaC and > the PAAA." I agree on the suggested change. Yoshihiro Ohba > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 202 > nosy: dforsber > priority: Must Fix > status: Pending > title: PANA SA definition > __________________________________________________ > PANA Issues > > __________________________________________________ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Feb 11 15:28: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 PAA20158 for ; Wed, 11 Feb 2004 15:28: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 1Ar0xi-0002D1-54 for pana-archive@odin.ietf.org; Wed, 11 Feb 2004 15:27:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKRw42008485 for pana-archive@odin.ietf.org; Wed, 11 Feb 2004 15:27:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0xh-0002Cm-Vi for pana-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 15:27: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 PAA20126 for ; Wed, 11 Feb 2004 15:27:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0xg-0000nI-00 for pana-web-archive@ietf.org; Wed, 11 Feb 2004 15:27:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar0wm-0000gS-00 for pana-web-archive@ietf.org; Wed, 11 Feb 2004 15:27:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0vs-0000Zj-00 for pana-web-archive@ietf.org; Wed, 11 Feb 2004 15:26:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0vp-00026T-3f; Wed, 11 Feb 2004 15:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0vf-00025z-H8 for pana@optimus.ietf.org; Wed, 11 Feb 2004 15:25: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 PAA20035 for ; Wed, 11 Feb 2004 15:25:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0ve-0000XI-00 for pana@ietf.org; Wed, 11 Feb 2004 15:25:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar0uh-0000Qv-00 for pana@ietf.org; Wed, 11 Feb 2004 15:24:52 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0tn-0000L3-00 for pana@ietf.org; Wed, 11 Feb 2004 15:23:55 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1BKNtGv020800 for ; Thu, 12 Feb 2004 05:23:55 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1BKNtPP001707 for ; Thu, 12 Feb 2004 05:23:55 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA01706 ; Thu, 12 Feb 2004 05:23:54 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA18317; Thu, 12 Feb 2004 05:23:54 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA26648; Thu, 12 Feb 2004 05:23:54 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1BKNrQX018168 for ; Thu, 12 Feb 2004 05:23:53 +0900 (JST) Received: from steelhead ([159.119.168.157]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSX004MISNRF6@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Thu, 12 Feb 2004 05:23:52 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ar0sy-0008Oi-00 for ; Wed, 11 Feb 2004 12:23:04 -0800 Date: Wed, 11 Feb 2004 12:23:04 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue61] PANA SA definition In-reply-to: To: pana@ietf.org Message-id: <20040211202304.GH28754@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.4i 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=AWL autolearn=no version=2.60 On Tue, Feb 10, 2004 at 09:08:35AM +0200, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > PANA Security Association: > > The representation of the trust relation between the PaC and the > PAA that is created at the end of the authentication phase. This > security association includes the device identifier of the peer, > and a shared key when available. > > JARI: (Technical) Hmmm.... this seems to omit some things, like > cryptographic context. Why would a shared key not be available? > Until it is available, you don't have an SA, right? Here's > another cut at this definition: "A PANA security association is > a relationship between the PaC and PAA, formed by the sharing of > cryptographic keying material and associated context. Security > associations are duplex. That is, one security association is > needed to protect the bidirectional traffic between the PaC and > the PAAA." I agree on the suggested change. Yoshihiro Ohba > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 202 > nosy: dforsber > priority: Must Fix > status: Pending > title: PANA SA definition > __________________________________________________ > PANA Issues > > __________________________________________________ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Feb 11 15:37:44 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 PAA20795 for ; Wed, 11 Feb 2004 15:37:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar16T-0002gM-Se; Wed, 11 Feb 2004 15:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar15l-0002bc-VH for pana@optimus.ietf.org; Wed, 11 Feb 2004 15:36: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 PAA20675 for ; Wed, 11 Feb 2004 15:36:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar15k-0001n1-00 for pana@ietf.org; Wed, 11 Feb 2004 15:36:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar14m-0001e5-00 for pana@ietf.org; Wed, 11 Feb 2004 15:35:17 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ar13m-0001V6-00 for pana@ietf.org; Wed, 11 Feb 2004 15:34:14 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1BKYBGv023256 for ; Thu, 12 Feb 2004 05:34:11 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1BKYB6O004372 for ; Thu, 12 Feb 2004 05:34:11 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA04371 ; Thu, 12 Feb 2004 05:34:11 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA20151; Thu, 12 Feb 2004 05:34:10 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA20694; Thu, 12 Feb 2004 05:34:10 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1BKY9QX019496 for ; Thu, 12 Feb 2004 05:34:10 +0900 (JST) Received: from steelhead ([159.119.168.157]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSX004P9T4WF6@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Thu, 12 Feb 2004 05:34:08 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ar12q-0008PY-00 for ; Wed, 11 Feb 2004 12:33:16 -0800 Date: Wed, 11 Feb 2004 12:33:16 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue64] Two separate codes for Session ID AVP In-reply-to: To: pana@ietf.org Message-id: <20040211203316.GI28754@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.4i 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=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 Tue, Feb 10, 2004 at 09:09:06AM +0200, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > 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. > > JARI: (Technical) Surely the AVP code is always 263, despite the > type of formatting used in the actual identifier? I agree with Jari. When we say "globally and eternally unique" we need to specify the exact format in order to possible ambiguity. Based on this, re-using the same formatting rule as Diameter is the easiest way to specify the PANA Session-Id format. On the other hand, the code can still be 1026 instead of 263... Yoshihiro Ohba > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 206 > nosy: dforsber > priority: Should Fix > status: Clarifying Text Required > title: Two separate codes for Session ID AVP > __________________________________________________ > PANA Issues > > __________________________________________________ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Feb 11 15:39: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 PAA21003 for ; Wed, 11 Feb 2004 15:39:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar18Y-0003Si-CJ for pana-archive@odin.ietf.org; Wed, 11 Feb 2004 15:39:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKdA6k013302 for pana-archive@odin.ietf.org; Wed, 11 Feb 2004 15:39:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar18Y-0003SS-5B for pana-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 15:39: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 PAA20958 for ; Wed, 11 Feb 2004 15:39:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar18W-0002D8-00 for pana-web-archive@ietf.org; Wed, 11 Feb 2004 15:39:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar17a-00023n-00 for pana-web-archive@ietf.org; Wed, 11 Feb 2004 15:38:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar16g-0001vc-00 for pana-web-archive@ietf.org; Wed, 11 Feb 2004 15:37:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar16T-0002gM-Se; Wed, 11 Feb 2004 15:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar15l-0002bc-VH for pana@optimus.ietf.org; Wed, 11 Feb 2004 15:36: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 PAA20675 for ; Wed, 11 Feb 2004 15:36:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar15k-0001n1-00 for pana@ietf.org; Wed, 11 Feb 2004 15:36:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar14m-0001e5-00 for pana@ietf.org; Wed, 11 Feb 2004 15:35:17 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ar13m-0001V6-00 for pana@ietf.org; Wed, 11 Feb 2004 15:34:14 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1BKYBGv023256 for ; Thu, 12 Feb 2004 05:34:11 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1BKYB6O004372 for ; Thu, 12 Feb 2004 05:34:11 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA04371 ; Thu, 12 Feb 2004 05:34:11 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA20151; Thu, 12 Feb 2004 05:34:10 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA20694; Thu, 12 Feb 2004 05:34:10 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1BKY9QX019496 for ; Thu, 12 Feb 2004 05:34:10 +0900 (JST) Received: from steelhead ([159.119.168.157]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSX004P9T4WF6@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Thu, 12 Feb 2004 05:34:08 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ar12q-0008PY-00 for ; Wed, 11 Feb 2004 12:33:16 -0800 Date: Wed, 11 Feb 2004 12:33:16 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue64] Two separate codes for Session ID AVP In-reply-to: To: pana@ietf.org Message-id: <20040211203316.GI28754@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.4i 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=AWL autolearn=no version=2.60 On Tue, Feb 10, 2004 at 09:09:06AM +0200, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > 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. > > JARI: (Technical) Surely the AVP code is always 263, despite the > type of formatting used in the actual identifier? I agree with Jari. When we say "globally and eternally unique" we need to specify the exact format in order to possible ambiguity. Based on this, re-using the same formatting rule as Diameter is the easiest way to specify the PANA Session-Id format. On the other hand, the code can still be 1026 instead of 263... Yoshihiro Ohba > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 206 > nosy: dforsber > priority: Should Fix > status: Clarifying Text Required > title: Two separate codes for Session ID AVP > __________________________________________________ > PANA Issues > > __________________________________________________ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Feb 11 16:17: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 QAA25496 for ; Wed, 11 Feb 2004 16:17: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 1Ar1jB-0007HE-Mz; Wed, 11 Feb 2004 16: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 1Ar1j1-0007Go-57 for pana@optimus.ietf.org; Wed, 11 Feb 2004 16:16: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 QAA25329 for ; Wed, 11 Feb 2004 16:16:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1iz-0007iq-00 for pana@ietf.org; Wed, 11 Feb 2004 16:16:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1ho-0007QV-00 for pana@ietf.org; Wed, 11 Feb 2004 16:15:37 -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 1Ar1gc-00078p-00 for pana@ietf.org; Wed, 11 Feb 2004 16:14:22 -0500 Date: Wed, 11 Feb 2004 13:14:33 -0800 Subject: Re: [Pana] NEW: [issue64] Two separate codes for Session ID AVP From: Alper Yegin To: Yoshihiro Ohba , Message-ID: In-Reply-To: <20040211203316.GI28754@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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 >> 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. >> >> JARI: (Technical) Surely the AVP code is always 263, despite the >> type of formatting used in the actual identifier? > > I agree with Jari. When we say "globally and eternally unique" we > need to specify the exact format in order to possible ambiguity. > Based on this, re-using the same formatting rule as Diameter is the > easiest way to specify the PANA Session-Id format. On the other hand, > the code can still be 1026 instead of 263... As we discussed under issue 23, we don't care about Diameter codes. So I suggest we only use one code (1026), while borrowing the formatting from Diameter spec. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Feb 11 16:24: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 QAA26500 for ; Wed, 11 Feb 2004 16:24: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 1Ar1px-00088e-46 for pana-archive@odin.ietf.org; Wed, 11 Feb 2004 16:24:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BLO0nk031275 for pana-archive@odin.ietf.org; Wed, 11 Feb 2004 16:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1pw-00088M-Ng for pana-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 16:24:00 -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 QAA26389 for ; Wed, 11 Feb 2004 16:23:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1pu-0001N3-00 for pana-web-archive@ietf.org; Wed, 11 Feb 2004 16:23:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1oL-0000zG-00 for pana-web-archive@ietf.org; Wed, 11 Feb 2004 16:22:22 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar1nR-0000m6-00 for pana-web-archive@ietf.org; Wed, 11 Feb 2004 16:21:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar1jQ-0006LU-Od for pana-web-archive@ietf.org; Wed, 11 Feb 2004 16:17:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1jB-0007HE-Mz; Wed, 11 Feb 2004 16: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 1Ar1j1-0007Go-57 for pana@optimus.ietf.org; Wed, 11 Feb 2004 16:16: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 QAA25329 for ; Wed, 11 Feb 2004 16:16:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1iz-0007iq-00 for pana@ietf.org; Wed, 11 Feb 2004 16:16:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1ho-0007QV-00 for pana@ietf.org; Wed, 11 Feb 2004 16:15:37 -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 1Ar1gc-00078p-00 for pana@ietf.org; Wed, 11 Feb 2004 16:14:22 -0500 Date: Wed, 11 Feb 2004 13:14:33 -0800 Subject: Re: [Pana] NEW: [issue64] Two separate codes for Session ID AVP From: Alper Yegin To: Yoshihiro Ohba , Message-ID: In-Reply-To: <20040211203316.GI28754@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 >> 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. >> >> JARI: (Technical) Surely the AVP code is always 263, despite the >> type of formatting used in the actual identifier? > > I agree with Jari. When we say "globally and eternally unique" we > need to specify the exact format in order to possible ambiguity. > Based on this, re-using the same formatting rule as Diameter is the > easiest way to specify the PANA Session-Id format. On the other hand, > the code can still be 1026 instead of 263... As we discussed under issue 23, we don't care about Diameter codes. So I suggest we only use one code (1026), while borrowing the formatting from Diameter spec. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 12 00:34: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 AAA25444 for ; Thu, 12 Feb 2004 00:34: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 1Ar9U9-0005VE-Ow; Thu, 12 Feb 2004 00: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 1Ar9U5-0005Um-Nx for pana@optimus.ietf.org; Thu, 12 Feb 2004 00:33: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 AAA25429 for ; Thu, 12 Feb 2004 00:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9U3-00052u-00 for pana@ietf.org; Thu, 12 Feb 2004 00:33:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar9T7-0004xX-00 for pana@ietf.org; Thu, 12 Feb 2004 00:32:58 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9S9-0004rJ-00 for pana@ietf.org; Thu, 12 Feb 2004 00:31:57 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 18FAA6A908; Thu, 12 Feb 2004 07:31:52 +0200 (EET) Message-ID: <402B0F5D.80702@piuha.net> Date: Thu, 12 Feb 2004 07:30:05 +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: Yoshihiro Ohba , pana@ietf.org Subject: Re: [Pana] NEW: [issue64] Two separate codes for Session ID AVP References: In-Reply-To: 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: >>>JARI: (Technical) Surely the AVP code is always 263, despite the >>> type of formatting used in the actual identifier? >> >>I agree with Jari. When we say "globally and eternally unique" we >>need to specify the exact format in order to possible ambiguity. >>Based on this, re-using the same formatting rule as Diameter is the >>easiest way to specify the PANA Session-Id format. On the other hand, >>the code can still be 1026 instead of 263... > > > As we discussed under issue 23, we don't care about Diameter codes. So I > suggest we only use one code (1026), while borrowing the formatting from > Diameter spec. Ok. My only complaint was that the AVP code appeared to depend on the specific formatting inside the AVP value. So 1026 is fine. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 12 00:42: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 AAA25776 for ; Thu, 12 Feb 2004 00:42: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 1Ar9c0-0006CX-Is for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 00:42:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C5g8lt023831 for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 00:42:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9c0-0006CI-E3 for pana-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 00:42: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 AAA25679 for ; Thu, 12 Feb 2004 00:42:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9bx-0005r9-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 00:42:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar9b5-0005gB-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 00:41:11 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar9Zz-0005YR-03 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 00:40:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar9UC-0005sm-Hd for pana-web-archive@ietf.org; Thu, 12 Feb 2004 00:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar9U9-0005VE-Ow; Thu, 12 Feb 2004 00: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 1Ar9U5-0005Um-Nx for pana@optimus.ietf.org; Thu, 12 Feb 2004 00:33: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 AAA25429 for ; Thu, 12 Feb 2004 00:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9U3-00052u-00 for pana@ietf.org; Thu, 12 Feb 2004 00:33:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar9T7-0004xX-00 for pana@ietf.org; Thu, 12 Feb 2004 00:32:58 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Ar9S9-0004rJ-00 for pana@ietf.org; Thu, 12 Feb 2004 00:31:57 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 18FAA6A908; Thu, 12 Feb 2004 07:31:52 +0200 (EET) Message-ID: <402B0F5D.80702@piuha.net> Date: Thu, 12 Feb 2004 07:30:05 +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: Yoshihiro Ohba , pana@ietf.org Subject: Re: [Pana] NEW: [issue64] Two separate codes for Session ID AVP References: In-Reply-To: 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: >>>JARI: (Technical) Surely the AVP code is always 263, despite the >>> type of formatting used in the actual identifier? >> >>I agree with Jari. When we say "globally and eternally unique" we >>need to specify the exact format in order to possible ambiguity. >>Based on this, re-using the same formatting rule as Diameter is the >>easiest way to specify the PANA Session-Id format. On the other hand, >>the code can still be 1026 instead of 263... > > > As we discussed under issue 23, we don't care about Diameter codes. So I > suggest we only use one code (1026), while borrowing the formatting from > Diameter spec. Ok. My only complaint was that the AVP code appeared to depend on the specific formatting inside the AVP value. So 1026 is fine. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 12 14:48: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 OAA09684 for ; Thu, 12 Feb 2004 14:48: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 1ArMob-0005hR-4q; Thu, 12 Feb 2004 14:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArMo0-0005gz-3F for pana@optimus.ietf.org; Thu, 12 Feb 2004 14:47: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 OAA09653 for ; Thu, 12 Feb 2004 14:47:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArMnv-0003Wf-00 for pana@ietf.org; Thu, 12 Feb 2004 14:47:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArMn6-0003SD-00 for pana@ietf.org; Thu, 12 Feb 2004 14:46:29 -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 1ArMmK-0003Mx-00 for pana@ietf.org; Thu, 12 Feb 2004 14:45:40 -0500 Date: Thu, 12 Feb 2004 11:45:56 -0800 Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy From: Alper Yegin To: Yoshihiro Ohba CC: Message-ID: In-Reply-To: <20040210224228.GB21495@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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 OK, I thought a bit more about this. Unless we want to rely on the PaC re-doing whatever it did to trigger the unsolicited PSR, it is reasonable to rely on retransmission of PSR. In that case, how about: a- PDI is always retransmitted b- PSR and PSA are never retransmitted at the PANA layer when they carry EAP AVP. (PSR gets retransmitted when the EAP layer retransmits) c- PSA is retransmitted in solicited case (no EAP payload) d- PSR is retransmitted in unsolicited case (no EAP payload) Note 1: In case there are multiple PAAs on the link, the PSR retransmission (at PANA layer or due to EAP retransmission) creates inefficiency, because the PaC will pick one PAA and ignore others until they give up. Note 2: For the sake of simplifying the protocol, we could combine (c) and (d) and say: "PSR is retransmitted (no EAP payload)." Though, per Note 1, this would create additional inefficiency. Comments? Alper On 2/10/04 2:42 PM, "Yoshihiro Ohba" wrote: > On Tue, Feb 10, 2004 at 01:35:58PM -0800, Alper Yegin wrote: >> >> 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. > > That is possible. But I think (timer-based) retransmission is needed > anyway for unsolicited PSR. In addition, when PSR carries > EAP-Request, timer-based retransmission of PSR should not occur in > PANA. Instead, PAA should rely on retransmission at EAP layer, like > PANA-Auth-Request message. > > Yoshihiro Ohba > > >> >> 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 > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 12 14:50: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 OAA09782 for ; Thu, 12 Feb 2004 14:50:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArMq4-0005x3-GX for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 14:49:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CJnWsX022876 for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 14:49:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArMq4-0005ws-95 for pana-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 14:49: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 OAA09737 for ; Thu, 12 Feb 2004 14:49:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArMpz-0003i8-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 14:49:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArMp4-0003ch-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 14:48:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArMoa-0003Xn-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 14:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArMob-0005hR-4q; Thu, 12 Feb 2004 14:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArMo0-0005gz-3F for pana@optimus.ietf.org; Thu, 12 Feb 2004 14:47: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 OAA09653 for ; Thu, 12 Feb 2004 14:47:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArMnv-0003Wf-00 for pana@ietf.org; Thu, 12 Feb 2004 14:47:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArMn6-0003SD-00 for pana@ietf.org; Thu, 12 Feb 2004 14:46:29 -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 1ArMmK-0003Mx-00 for pana@ietf.org; Thu, 12 Feb 2004 14:45:40 -0500 Date: Thu, 12 Feb 2004 11:45:56 -0800 Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy From: Alper Yegin To: Yoshihiro Ohba CC: Message-ID: In-Reply-To: <20040210224228.GB21495@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 OK, I thought a bit more about this. Unless we want to rely on the PaC re-doing whatever it did to trigger the unsolicited PSR, it is reasonable to rely on retransmission of PSR. In that case, how about: a- PDI is always retransmitted b- PSR and PSA are never retransmitted at the PANA layer when they carry EAP AVP. (PSR gets retransmitted when the EAP layer retransmits) c- PSA is retransmitted in solicited case (no EAP payload) d- PSR is retransmitted in unsolicited case (no EAP payload) Note 1: In case there are multiple PAAs on the link, the PSR retransmission (at PANA layer or due to EAP retransmission) creates inefficiency, because the PaC will pick one PAA and ignore others until they give up. Note 2: For the sake of simplifying the protocol, we could combine (c) and (d) and say: "PSR is retransmitted (no EAP payload)." Though, per Note 1, this would create additional inefficiency. Comments? Alper On 2/10/04 2:42 PM, "Yoshihiro Ohba" wrote: > On Tue, Feb 10, 2004 at 01:35:58PM -0800, Alper Yegin wrote: >> >> 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. > > That is possible. But I think (timer-based) retransmission is needed > anyway for unsolicited PSR. In addition, when PSR carries > EAP-Request, timer-based retransmission of PSR should not occur in > PANA. Instead, PAA should rely on retransmission at EAP layer, like > PANA-Auth-Request message. > > Yoshihiro Ohba > > >> >> 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 > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 12 15:10: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 PAA11087 for ; Thu, 12 Feb 2004 15:10: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 1ArN9u-0008RN-Ql; Thu, 12 Feb 2004 15:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArN9X-0008KF-5U for pana@optimus.ietf.org; Thu, 12 Feb 2004 15:09: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 PAA10932 for ; Thu, 12 Feb 2004 15:09:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArN9S-0005gb-00 for pana@ietf.org; Thu, 12 Feb 2004 15:09:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArN8T-0005aK-00 for pana@ietf.org; Thu, 12 Feb 2004 15:08:34 -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 1ArN8B-0005UQ-00 for pana@ietf.org; Thu, 12 Feb 2004 15:08:15 -0500 Date: Thu, 12 Feb 2004 12:08:31 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-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] 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 On 2/9/04 11:09 PM, "Dan.Forsberg@nokia.com" wrote: > New submission from Dan Forsberg : > > inherited from the previous (re-)authentication. 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. > > JARI: (Technical) How about a MUST? Otherwise, implementations have > to deal with the MAC either being present or not present. And there > has to be a config switch to either allow or disallow this. I think MUST is better. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 12 15:11: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 PAA11366 for ; Thu, 12 Feb 2004 15:11: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 1ArNBJ-0000aP-RS for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 15:11:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CKBTNF002244 for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 15:11:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNBJ-0000a1-LX for pana-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 15:11:29 -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 PAA11249 for ; Thu, 12 Feb 2004 15:11:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNBE-0005uO-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:11:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNAU-0005p7-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:10:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArN9s-0005iR-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:10:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArN9u-0008RN-Ql; Thu, 12 Feb 2004 15:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArN9X-0008KF-5U for pana@optimus.ietf.org; Thu, 12 Feb 2004 15:09: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 PAA10932 for ; Thu, 12 Feb 2004 15:09:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArN9S-0005gb-00 for pana@ietf.org; Thu, 12 Feb 2004 15:09:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArN8T-0005aK-00 for pana@ietf.org; Thu, 12 Feb 2004 15:08:34 -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 1ArN8B-0005UQ-00 for pana@ietf.org; Thu, 12 Feb 2004 15:08:15 -0500 Date: Thu, 12 Feb 2004 12:08:31 -0800 From: Alper Yegin To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 2/9/04 11:09 PM, "Dan.Forsberg@nokia.com" wrote: > New submission from Dan Forsberg : > > inherited from the previous (re-)authentication. 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. > > JARI: (Technical) How about a MUST? Otherwise, implementations have > to deal with the MAC either being present or not present. And there > has to be a config switch to either allow or disallow this. I think MUST is better. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 12 15:16: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 PAA12081 for ; Thu, 12 Feb 2004 15:16: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 1ArNFj-0002XP-6d; Thu, 12 Feb 2004 15:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNFa-0002Ui-R8 for pana@optimus.ietf.org; Thu, 12 Feb 2004 15:15: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 PAA11978 for ; Thu, 12 Feb 2004 15:15:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNFX-0006SB-00 for pana@ietf.org; Thu, 12 Feb 2004 15:15:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNEb-0006JZ-00 for pana@ietf.org; Thu, 12 Feb 2004 15:14:54 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1ArNDt-0006AV-00 for pana@ietf.org; Thu, 12 Feb 2004 15:14:09 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1CKE7Gv004438; Fri, 13 Feb 2004 05:14:07 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1CKE7bO029071; Fri, 13 Feb 2004 05:14:07 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA29066 ; Fri, 13 Feb 2004 05:14:06 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA04806; Fri, 13 Feb 2004 05:14:06 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA19118; Fri, 13 Feb 2004 05:14:06 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1CKE5EP013833; Fri, 13 Feb 2004 05:14:05 +0900 (JST) Received: from steelhead ([159.119.168.123]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSZ00MGVMVF0L@tsbpo1.po.toshiba.co.jp>; Fri, 13 Feb 2004 05:14:04 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ArMKP-0005LU-00; Thu, 12 Feb 2004 11:16:49 -0800 Date: Thu, 12 Feb 2004 11:16:49 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040212191649.GE19857@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: <20040210224228.GB21495@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: , On Thu, Feb 12, 2004 at 11:45:56AM -0800, Alper Yegin wrote: > > OK, I thought a bit more about this. > > Unless we want to rely on the PaC re-doing whatever it did to trigger the > unsolicited PSR, it is reasonable to rely on retransmission of PSR. > > In that case, how about: > > a- PDI is always retransmitted > b- PSR and PSA are never retransmitted at the PANA layer when they carry EAP > AVP. (PSR gets retransmitted when the EAP layer retransmits) > c- PSA is retransmitted in solicited case (no EAP payload) > d- PSR is retransmitted in unsolicited case (no EAP payload) > > Note 1: In case there are multiple PAAs on the link, the PSR retransmission > (at PANA layer or due to EAP retransmission) creates inefficiency, because > the PaC will pick one PAA and ignore others until they give up. For solicited case, yes. For unsolicited case, it depends on whether the EP that found the presence of PaC informs multiple PAAs or not. If the EP informs one PAA only, then the inefficiency does not apply. > > Note 2: For the sake of simplifying the protocol, we could combine (c) and > (d) and say: "PSR is retransmitted (no EAP payload)." Though, per Note 1, > this would create additional inefficiency. Yes. So which do you suggest, combining (c) and (d) or separating? Yoshihiro Ohba > > Comments? > > Alper > > > > > On 2/10/04 2:42 PM, "Yoshihiro Ohba" wrote: > > > On Tue, Feb 10, 2004 at 01:35:58PM -0800, Alper Yegin wrote: > >> > >> 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. > > > > That is possible. But I think (timer-based) retransmission is needed > > anyway for unsolicited PSR. In addition, when PSR carries > > EAP-Request, timer-based retransmission of PSR should not occur in > > PANA. Instead, PAA should rely on retransmission at EAP layer, like > > PANA-Auth-Request message. > > > > Yoshihiro Ohba > > > > > >> > >> 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 > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 12 15:18: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 PAA12265 for ; Thu, 12 Feb 2004 15:18: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 1ArNHA-00031U-5z for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 15:17:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CKHWbO011612 for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 15:17:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNHA-000319-1V for pana-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 15:17: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 PAA12207 for ; Thu, 12 Feb 2004 15:17:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNH7-0006fL-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:17:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNGF-0006ZQ-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:16:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArNFi-0006T8-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNFj-0002XP-6d; Thu, 12 Feb 2004 15:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNFa-0002Ui-R8 for pana@optimus.ietf.org; Thu, 12 Feb 2004 15:15: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 PAA11978 for ; Thu, 12 Feb 2004 15:15:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNFX-0006SB-00 for pana@ietf.org; Thu, 12 Feb 2004 15:15:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNEb-0006JZ-00 for pana@ietf.org; Thu, 12 Feb 2004 15:14:54 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1ArNDt-0006AV-00 for pana@ietf.org; Thu, 12 Feb 2004 15:14:09 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1CKE7Gv004438; Fri, 13 Feb 2004 05:14:07 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1CKE7bO029071; Fri, 13 Feb 2004 05:14:07 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA29066 ; Fri, 13 Feb 2004 05:14:06 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA04806; Fri, 13 Feb 2004 05:14:06 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA19118; Fri, 13 Feb 2004 05:14:06 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1CKE5EP013833; Fri, 13 Feb 2004 05:14:05 +0900 (JST) Received: from steelhead ([159.119.168.123]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSZ00MGVMVF0L@tsbpo1.po.toshiba.co.jp>; Fri, 13 Feb 2004 05:14:04 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ArMKP-0005LU-00; Thu, 12 Feb 2004 11:16:49 -0800 Date: Thu, 12 Feb 2004 11:16:49 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040212191649.GE19857@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: <20040210224228.GB21495@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 On Thu, Feb 12, 2004 at 11:45:56AM -0800, Alper Yegin wrote: > > OK, I thought a bit more about this. > > Unless we want to rely on the PaC re-doing whatever it did to trigger the > unsolicited PSR, it is reasonable to rely on retransmission of PSR. > > In that case, how about: > > a- PDI is always retransmitted > b- PSR and PSA are never retransmitted at the PANA layer when they carry EAP > AVP. (PSR gets retransmitted when the EAP layer retransmits) > c- PSA is retransmitted in solicited case (no EAP payload) > d- PSR is retransmitted in unsolicited case (no EAP payload) > > Note 1: In case there are multiple PAAs on the link, the PSR retransmission > (at PANA layer or due to EAP retransmission) creates inefficiency, because > the PaC will pick one PAA and ignore others until they give up. For solicited case, yes. For unsolicited case, it depends on whether the EP that found the presence of PaC informs multiple PAAs or not. If the EP informs one PAA only, then the inefficiency does not apply. > > Note 2: For the sake of simplifying the protocol, we could combine (c) and > (d) and say: "PSR is retransmitted (no EAP payload)." Though, per Note 1, > this would create additional inefficiency. Yes. So which do you suggest, combining (c) and (d) or separating? Yoshihiro Ohba > > Comments? > > Alper > > > > > On 2/10/04 2:42 PM, "Yoshihiro Ohba" wrote: > > > On Tue, Feb 10, 2004 at 01:35:58PM -0800, Alper Yegin wrote: > >> > >> 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. > > > > That is possible. But I think (timer-based) retransmission is needed > > anyway for unsolicited PSR. In addition, when PSR carries > > EAP-Request, timer-based retransmission of PSR should not occur in > > PANA. Instead, PAA should rely on retransmission at EAP layer, like > > PANA-Auth-Request message. > > > > Yoshihiro Ohba > > > > > >> > >> 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 > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 12 15:23: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 PAA12685 for ; Thu, 12 Feb 2004 15:23: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 1ArNMT-0004qF-28; Thu, 12 Feb 2004 15:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNLx-0004gk-6i for pana@optimus.ietf.org; Thu, 12 Feb 2004 15:22:29 -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 PAA12630 for ; Thu, 12 Feb 2004 15:22:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNLt-00073h-00 for pana@ietf.org; Thu, 12 Feb 2004 15:22:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNKr-0006zD-00 for pana@ietf.org; Thu, 12 Feb 2004 15:21:22 -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 1ArNK3-0006vH-00 for pana@ietf.org; Thu, 12 Feb 2004 15:20:31 -0500 Date: Thu, 12 Feb 2004 12:20:46 -0800 Subject: Re: [Pana] NEW [issue53] Additional discovery information From: Alper Yegin To: Yoshihiro Ohba CC: Message-ID: In-Reply-To: <20040210211812.GK16181@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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 If we mandate the Session-ID AVP format to same as Diameter's, do we still need a PAA-ID AVP? PAA identity would be embedded in the session-id: ;;[;] Alper On 2/10/04 1:18 PM, "Yoshihiro Ohba" wrote: > On Tue, Feb 10, 2004 at 01:02:12PM -0800, Alper Yegin wrote: >>>>> Jari Arkko: >>>>> - "Additional discovery information?" >>>>> I'm not sure if there is a need to provide some additional >>>>> information in the discovery phase. For instance, is there a >>>>> need to identify the NAS/PAA in a scenario where the NAS/PAA >>>>> has multiple interfaces and multiple addresses? Knowing you >>>>> are still connected to the same NAS might help future handoff >>>>> designs. >>>> >>>> Alper Yegin: >>>> This sounds like a useful feature. I'd recommend we open an issue and >>>> investigate this. It can assist movement detection. >>> >>> I agree that this might be a useful feature. This might help the VLAN >>> hopping scenario described in section 10.2.2.1 of the PANA Framework >>> draft. How about defining a PAA-Identifier AVP that contains one of >>> the global addresses of the PAA? >>> >>> Usage: >>> >>> - A PAA-Identifier AVP MAY be contained in PANA-Start-Request message. >>> >>> - A PAA-Identifier AVP and a Session-Id AVP MAY be contained in >>> a PANA-PAA-Discover message. (Note that the current specification already >>> allows a Session-Id AVP to be carried in PDI.) >>> >>> - When a PAA receives a PANA-PAA-Discover message with a known PANA >>> session identifier in a Session-Id AVP and its own PAA identifier in a >>> PAA-Identifier AVP, it initiates a PANA-ReAuth-Request/Answer exchange. >> >> I guess we don't want to use PAA device ID for this, because that can be a >> link-local address. Is that right? > > Yes. > >> >> We might consider PAA-id to be an opaque value, and mention that it can be >> an IP address of the PAA. Is it worth having this flexibility? > > If global uniqueness is required (I think it is), allowing an opaque > value will introduce ambiguity. > >> >> There is some text in 4.9 Mobility Management that talks about how to >> determine the previous PAA. We shall remember to update that text too. > > OK. > > Yoshihiro Ohba > > >> >> Alper >> >> > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 12 15:25: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 PAA12812 for ; Thu, 12 Feb 2004 15:25: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 1ArNOl-0005Zv-OJ for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 15:25:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CKPN5C021433 for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 15:25:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNOl-0005Zc-JI for pana-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 15:25: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 PAA12748 for ; Thu, 12 Feb 2004 15:25:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNOi-0007Ny-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:25:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNNG-0007DE-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:23:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArNMT-00074h-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:23:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNMT-0004qF-28; Thu, 12 Feb 2004 15:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNLx-0004gk-6i for pana@optimus.ietf.org; Thu, 12 Feb 2004 15:22:29 -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 PAA12630 for ; Thu, 12 Feb 2004 15:22:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNLt-00073h-00 for pana@ietf.org; Thu, 12 Feb 2004 15:22:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNKr-0006zD-00 for pana@ietf.org; Thu, 12 Feb 2004 15:21:22 -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 1ArNK3-0006vH-00 for pana@ietf.org; Thu, 12 Feb 2004 15:20:31 -0500 Date: Thu, 12 Feb 2004 12:20:46 -0800 Subject: Re: [Pana] NEW [issue53] Additional discovery information From: Alper Yegin To: Yoshihiro Ohba CC: Message-ID: In-Reply-To: <20040210211812.GK16181@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 If we mandate the Session-ID AVP format to same as Diameter's, do we still need a PAA-ID AVP? PAA identity would be embedded in the session-id: ;;[;] Alper On 2/10/04 1:18 PM, "Yoshihiro Ohba" wrote: > On Tue, Feb 10, 2004 at 01:02:12PM -0800, Alper Yegin wrote: >>>>> Jari Arkko: >>>>> - "Additional discovery information?" >>>>> I'm not sure if there is a need to provide some additional >>>>> information in the discovery phase. For instance, is there a >>>>> need to identify the NAS/PAA in a scenario where the NAS/PAA >>>>> has multiple interfaces and multiple addresses? Knowing you >>>>> are still connected to the same NAS might help future handoff >>>>> designs. >>>> >>>> Alper Yegin: >>>> This sounds like a useful feature. I'd recommend we open an issue and >>>> investigate this. It can assist movement detection. >>> >>> I agree that this might be a useful feature. This might help the VLAN >>> hopping scenario described in section 10.2.2.1 of the PANA Framework >>> draft. How about defining a PAA-Identifier AVP that contains one of >>> the global addresses of the PAA? >>> >>> Usage: >>> >>> - A PAA-Identifier AVP MAY be contained in PANA-Start-Request message. >>> >>> - A PAA-Identifier AVP and a Session-Id AVP MAY be contained in >>> a PANA-PAA-Discover message. (Note that the current specification already >>> allows a Session-Id AVP to be carried in PDI.) >>> >>> - When a PAA receives a PANA-PAA-Discover message with a known PANA >>> session identifier in a Session-Id AVP and its own PAA identifier in a >>> PAA-Identifier AVP, it initiates a PANA-ReAuth-Request/Answer exchange. >> >> I guess we don't want to use PAA device ID for this, because that can be a >> link-local address. Is that right? > > Yes. > >> >> We might consider PAA-id to be an opaque value, and mention that it can be >> an IP address of the PAA. Is it worth having this flexibility? > > If global uniqueness is required (I think it is), allowing an opaque > value will introduce ambiguity. > >> >> There is some text in 4.9 Mobility Management that talks about how to >> determine the previous PAA. We shall remember to update that text too. > > OK. > > Yoshihiro Ohba > > >> >> Alper >> >> > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 12 15:36: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 PAA13378 for ; Thu, 12 Feb 2004 15:36: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 1ArNZ3-0001y5-5U; Thu, 12 Feb 2004 15:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNYU-0001wF-Gl for pana@optimus.ietf.org; Thu, 12 Feb 2004 15:35:26 -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 PAA13311 for ; Thu, 12 Feb 2004 15:35:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNYR-0000Xr-00 for pana@ietf.org; Thu, 12 Feb 2004 15:35:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNXT-0000TI-00 for pana@ietf.org; Thu, 12 Feb 2004 15:34:24 -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 1ArNX4-0000Oy-00 for pana@ietf.org; Thu, 12 Feb 2004 15:33:58 -0500 Date: Thu, 12 Feb 2004 12:34:13 -0800 Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy From: Alper Yegin To: Yoshihiro Ohba CC: Message-ID: In-Reply-To: <20040212191649.GE19857@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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 >> OK, I thought a bit more about this. >> >> Unless we want to rely on the PaC re-doing whatever it did to trigger the >> unsolicited PSR, it is reasonable to rely on retransmission of PSR. >> >> In that case, how about: >> >> a- PDI is always retransmitted >> b- PSR and PSA are never retransmitted at the PANA layer when they carry EAP >> AVP. (PSR gets retransmitted when the EAP layer retransmits) >> c- PSA is retransmitted in solicited case (no EAP payload) >> d- PSR is retransmitted in unsolicited case (no EAP payload) >> >> Note 1: In case there are multiple PAAs on the link, the PSR retransmission >> (at PANA layer or due to EAP retransmission) creates inefficiency, because >> the PaC will pick one PAA and ignore others until they give up. > > For solicited case, yes. For unsolicited case, it depends on whether > the EP that found the presence of PaC informs multiple PAAs or not. > If the EP informs one PAA only, then the inefficiency does not apply. Good point. > >> >> Note 2: For the sake of simplifying the protocol, we could combine (c) and >> (d) and say: "PSR is retransmitted (no EAP payload)." Though, per Note 1, >> this would create additional inefficiency. > > Yes. So which do you suggest, combining (c) and (d) or separating? I'm inclined to say combined. Alper > > Yoshihiro Ohba > > >> >> Comments? >> >> Alper >> >> >> >> >> On 2/10/04 2:42 PM, "Yoshihiro Ohba" wrote: >> >>> On Tue, Feb 10, 2004 at 01:35:58PM -0800, Alper Yegin wrote: >>>> >>>> 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. >>> >>> That is possible. But I think (timer-based) retransmission is needed >>> anyway for unsolicited PSR. In addition, when PSR carries >>> EAP-Request, timer-based retransmission of PSR should not occur in >>> PANA. Instead, PAA should rely on retransmission at EAP layer, like >>> PANA-Auth-Request message. >>> >>> Yoshihiro Ohba >>> >>> >>>> >>>> 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 >>> >> > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 12 15:37: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 PAA13439 for ; Thu, 12 Feb 2004 15:37: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 1ArNaQ-00028w-C7 for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 15:37:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CKbQ0I008229 for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 15:37:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNaP-00028Z-TW for pana-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 15:37: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 PAA13429 for ; Thu, 12 Feb 2004 15:37:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNaM-0000hi-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:37:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNZT-0000dP-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:36:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArNZ2-0000Yh-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNZ3-0001y5-5U; Thu, 12 Feb 2004 15:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNYU-0001wF-Gl for pana@optimus.ietf.org; Thu, 12 Feb 2004 15:35:26 -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 PAA13311 for ; Thu, 12 Feb 2004 15:35:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNYR-0000Xr-00 for pana@ietf.org; Thu, 12 Feb 2004 15:35:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNXT-0000TI-00 for pana@ietf.org; Thu, 12 Feb 2004 15:34:24 -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 1ArNX4-0000Oy-00 for pana@ietf.org; Thu, 12 Feb 2004 15:33:58 -0500 Date: Thu, 12 Feb 2004 12:34:13 -0800 Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy From: Alper Yegin To: Yoshihiro Ohba CC: Message-ID: In-Reply-To: <20040212191649.GE19857@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 >> OK, I thought a bit more about this. >> >> Unless we want to rely on the PaC re-doing whatever it did to trigger the >> unsolicited PSR, it is reasonable to rely on retransmission of PSR. >> >> In that case, how about: >> >> a- PDI is always retransmitted >> b- PSR and PSA are never retransmitted at the PANA layer when they carry EAP >> AVP. (PSR gets retransmitted when the EAP layer retransmits) >> c- PSA is retransmitted in solicited case (no EAP payload) >> d- PSR is retransmitted in unsolicited case (no EAP payload) >> >> Note 1: In case there are multiple PAAs on the link, the PSR retransmission >> (at PANA layer or due to EAP retransmission) creates inefficiency, because >> the PaC will pick one PAA and ignore others until they give up. > > For solicited case, yes. For unsolicited case, it depends on whether > the EP that found the presence of PaC informs multiple PAAs or not. > If the EP informs one PAA only, then the inefficiency does not apply. Good point. > >> >> Note 2: For the sake of simplifying the protocol, we could combine (c) and >> (d) and say: "PSR is retransmitted (no EAP payload)." Though, per Note 1, >> this would create additional inefficiency. > > Yes. So which do you suggest, combining (c) and (d) or separating? I'm inclined to say combined. Alper > > Yoshihiro Ohba > > >> >> Comments? >> >> Alper >> >> >> >> >> On 2/10/04 2:42 PM, "Yoshihiro Ohba" wrote: >> >>> On Tue, Feb 10, 2004 at 01:35:58PM -0800, Alper Yegin wrote: >>>> >>>> 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. >>> >>> That is possible. But I think (timer-based) retransmission is needed >>> anyway for unsolicited PSR. In addition, when PSR carries >>> EAP-Request, timer-based retransmission of PSR should not occur in >>> PANA. Instead, PAA should rely on retransmission at EAP layer, like >>> PANA-Auth-Request message. >>> >>> Yoshihiro Ohba >>> >>> >>>> >>>> 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 >>> >> > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 12 15:42: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 PAA13651 for ; Thu, 12 Feb 2004 15:42: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 1ArNes-0002cA-3Y; Thu, 12 Feb 2004 15:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNeE-0002ab-Tx for pana@optimus.ietf.org; Thu, 12 Feb 2004 15:41:22 -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 PAA13563 for ; Thu, 12 Feb 2004 15:41:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNeB-00011X-00 for pana@ietf.org; Thu, 12 Feb 2004 15:41:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNdD-0000vq-00 for pana@ietf.org; Thu, 12 Feb 2004 15:40:19 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1ArNcH-0000qd-00 for pana@ietf.org; Thu, 12 Feb 2004 15:39:21 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1CKdKGv011093; Fri, 13 Feb 2004 05:39:20 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1CKdJLr006295; Fri, 13 Feb 2004 05:39:19 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA06290 ; Fri, 13 Feb 2004 05:39:19 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA10009; Fri, 13 Feb 2004 05:39:19 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA21875; Fri, 13 Feb 2004 05:39:19 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1CKdIEP017462; Fri, 13 Feb 2004 05:39:18 +0900 (JST) Received: from steelhead ([159.119.168.123]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSZ00MQZO1G0L@tsbpo1.po.toshiba.co.jp>; Fri, 13 Feb 2004 05:39:17 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ArNXi-0005Oa-00; Thu, 12 Feb 2004 12:34:38 -0800 Date: Thu, 12 Feb 2004 12:34:38 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW [issue53] Additional discovery information In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040212203438.GF19857@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: <20040210211812.GK16181@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: , On Thu, Feb 12, 2004 at 12:20:46PM -0800, Alper Yegin wrote: > > > If we mandate the Session-ID AVP format to same as Diameter's, do we still > need a PAA-ID AVP? > > PAA identity would be embedded in the session-id: > > ;;[;] > Yes, DiameterIdentity in Session-Id AVP can be used for identifying PAA, and an additional PAA-ID AVP is not needed. Yoshihiro Ohba > Alper > > > > > > On 2/10/04 1:18 PM, "Yoshihiro Ohba" wrote: > > > On Tue, Feb 10, 2004 at 01:02:12PM -0800, Alper Yegin wrote: > >>>>> Jari Arkko: > >>>>> - "Additional discovery information?" > >>>>> I'm not sure if there is a need to provide some additional > >>>>> information in the discovery phase. For instance, is there a > >>>>> need to identify the NAS/PAA in a scenario where the NAS/PAA > >>>>> has multiple interfaces and multiple addresses? Knowing you > >>>>> are still connected to the same NAS might help future handoff > >>>>> designs. > >>>> > >>>> Alper Yegin: > >>>> This sounds like a useful feature. I'd recommend we open an issue and > >>>> investigate this. It can assist movement detection. > >>> > >>> I agree that this might be a useful feature. This might help the VLAN > >>> hopping scenario described in section 10.2.2.1 of the PANA Framework > >>> draft. How about defining a PAA-Identifier AVP that contains one of > >>> the global addresses of the PAA? > >>> > >>> Usage: > >>> > >>> - A PAA-Identifier AVP MAY be contained in PANA-Start-Request message. > >>> > >>> - A PAA-Identifier AVP and a Session-Id AVP MAY be contained in > >>> a PANA-PAA-Discover message. (Note that the current specification already > >>> allows a Session-Id AVP to be carried in PDI.) > >>> > >>> - When a PAA receives a PANA-PAA-Discover message with a known PANA > >>> session identifier in a Session-Id AVP and its own PAA identifier in a > >>> PAA-Identifier AVP, it initiates a PANA-ReAuth-Request/Answer exchange. > >> > >> I guess we don't want to use PAA device ID for this, because that can be a > >> link-local address. Is that right? > > > > Yes. > > > >> > >> We might consider PAA-id to be an opaque value, and mention that it can be > >> an IP address of the PAA. Is it worth having this flexibility? > > > > If global uniqueness is required (I think it is), allowing an opaque > > value will introduce ambiguity. > > > >> > >> There is some text in 4.9 Mobility Management that talks about how to > >> determine the previous PAA. We shall remember to update that text too. > > > > OK. > > > > Yoshihiro Ohba > > > > > >> > >> Alper > >> > >> > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 12 15:43: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 PAA13702 for ; Thu, 12 Feb 2004 15:43: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 1ArNgC-0002vN-Qq for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 15:43:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CKhOt6011235 for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 15:43:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNgC-0002v8-Mb for pana-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 15:43: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 PAA13674 for ; Thu, 12 Feb 2004 15:43:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNg9-0001EN-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:43:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNfH-000193-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:42:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArNer-000141-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNes-0002cA-3Y; Thu, 12 Feb 2004 15:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNeE-0002ab-Tx for pana@optimus.ietf.org; Thu, 12 Feb 2004 15:41:22 -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 PAA13563 for ; Thu, 12 Feb 2004 15:41:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNeB-00011X-00 for pana@ietf.org; Thu, 12 Feb 2004 15:41:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNdD-0000vq-00 for pana@ietf.org; Thu, 12 Feb 2004 15:40:19 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1ArNcH-0000qd-00 for pana@ietf.org; Thu, 12 Feb 2004 15:39:21 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1CKdKGv011093; Fri, 13 Feb 2004 05:39:20 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1CKdJLr006295; Fri, 13 Feb 2004 05:39:19 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA06290 ; Fri, 13 Feb 2004 05:39:19 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA10009; Fri, 13 Feb 2004 05:39:19 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA21875; Fri, 13 Feb 2004 05:39:19 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1CKdIEP017462; Fri, 13 Feb 2004 05:39:18 +0900 (JST) Received: from steelhead ([159.119.168.123]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSZ00MQZO1G0L@tsbpo1.po.toshiba.co.jp>; Fri, 13 Feb 2004 05:39:17 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ArNXi-0005Oa-00; Thu, 12 Feb 2004 12:34:38 -0800 Date: Thu, 12 Feb 2004 12:34:38 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW [issue53] Additional discovery information In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040212203438.GF19857@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: <20040210211812.GK16181@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 On Thu, Feb 12, 2004 at 12:20:46PM -0800, Alper Yegin wrote: > > > If we mandate the Session-ID AVP format to same as Diameter's, do we still > need a PAA-ID AVP? > > PAA identity would be embedded in the session-id: > > ;;[;] > Yes, DiameterIdentity in Session-Id AVP can be used for identifying PAA, and an additional PAA-ID AVP is not needed. Yoshihiro Ohba > Alper > > > > > > On 2/10/04 1:18 PM, "Yoshihiro Ohba" wrote: > > > On Tue, Feb 10, 2004 at 01:02:12PM -0800, Alper Yegin wrote: > >>>>> Jari Arkko: > >>>>> - "Additional discovery information?" > >>>>> I'm not sure if there is a need to provide some additional > >>>>> information in the discovery phase. For instance, is there a > >>>>> need to identify the NAS/PAA in a scenario where the NAS/PAA > >>>>> has multiple interfaces and multiple addresses? Knowing you > >>>>> are still connected to the same NAS might help future handoff > >>>>> designs. > >>>> > >>>> Alper Yegin: > >>>> This sounds like a useful feature. I'd recommend we open an issue and > >>>> investigate this. It can assist movement detection. > >>> > >>> I agree that this might be a useful feature. This might help the VLAN > >>> hopping scenario described in section 10.2.2.1 of the PANA Framework > >>> draft. How about defining a PAA-Identifier AVP that contains one of > >>> the global addresses of the PAA? > >>> > >>> Usage: > >>> > >>> - A PAA-Identifier AVP MAY be contained in PANA-Start-Request message. > >>> > >>> - A PAA-Identifier AVP and a Session-Id AVP MAY be contained in > >>> a PANA-PAA-Discover message. (Note that the current specification already > >>> allows a Session-Id AVP to be carried in PDI.) > >>> > >>> - When a PAA receives a PANA-PAA-Discover message with a known PANA > >>> session identifier in a Session-Id AVP and its own PAA identifier in a > >>> PAA-Identifier AVP, it initiates a PANA-ReAuth-Request/Answer exchange. > >> > >> I guess we don't want to use PAA device ID for this, because that can be a > >> link-local address. Is that right? > > > > Yes. > > > >> > >> We might consider PAA-id to be an opaque value, and mention that it can be > >> an IP address of the PAA. Is it worth having this flexibility? > > > > If global uniqueness is required (I think it is), allowing an opaque > > value will introduce ambiguity. > > > >> > >> There is some text in 4.9 Mobility Management that talks about how to > >> determine the previous PAA. We shall remember to update that text too. > > > > OK. > > > > Yoshihiro Ohba > > > > > >> > >> Alper > >> > >> > > > _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 12 15:58: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 PAA15065 for ; Thu, 12 Feb 2004 15:58: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 1ArNuL-00052Q-OS; Thu, 12 Feb 2004 15:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNu2-00050z-FS for pana@optimus.ietf.org; Thu, 12 Feb 2004 15:57:42 -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 PAA14973 for ; Thu, 12 Feb 2004 15:57:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNtz-0003D2-00 for pana@ietf.org; Thu, 12 Feb 2004 15:57:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNt1-000358-00 for pana@ietf.org; Thu, 12 Feb 2004 15:56:40 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1ArNsG-0002y6-00 for pana@ietf.org; Thu, 12 Feb 2004 15:55:52 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1CKtpGv014973; Fri, 13 Feb 2004 05:55:51 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1CKtpRx010682; Fri, 13 Feb 2004 05:55:51 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA10681 ; Fri, 13 Feb 2004 05:55:50 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA13343; Fri, 13 Feb 2004 05:55:50 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA14234; Fri, 13 Feb 2004 05:55:50 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1CKtnEP020253; Fri, 13 Feb 2004 05:55:49 +0900 (JST) Received: from steelhead ([159.119.168.123]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSZ00MXQOSZ0L@tsbpo1.po.toshiba.co.jp>; Fri, 13 Feb 2004 05:55:48 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ArNgK-0005QC-00; Thu, 12 Feb 2004 12:43:32 -0800 Date: Thu, 12 Feb 2004 12:43:32 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040212204332.GG19857@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: <20040212191649.GE19857@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: , Doesn't the combining approach conflict with stateless discovery? Yoshihiro Ohba On Thu, Feb 12, 2004 at 12:34:13PM -0800, Alper Yegin wrote: > >> OK, I thought a bit more about this. > >> > >> Unless we want to rely on the PaC re-doing whatever it did to trigger the > >> unsolicited PSR, it is reasonable to rely on retransmission of PSR. > >> > >> In that case, how about: > >> > >> a- PDI is always retransmitted > >> b- PSR and PSA are never retransmitted at the PANA layer when they carry EAP > >> AVP. (PSR gets retransmitted when the EAP layer retransmits) > >> c- PSA is retransmitted in solicited case (no EAP payload) > >> d- PSR is retransmitted in unsolicited case (no EAP payload) > >> > >> Note 1: In case there are multiple PAAs on the link, the PSR retransmission > >> (at PANA layer or due to EAP retransmission) creates inefficiency, because > >> the PaC will pick one PAA and ignore others until they give up. > > > > For solicited case, yes. For unsolicited case, it depends on whether > > the EP that found the presence of PaC informs multiple PAAs or not. > > If the EP informs one PAA only, then the inefficiency does not apply. > > Good point. > > > > >> > >> Note 2: For the sake of simplifying the protocol, we could combine (c) and > >> (d) and say: "PSR is retransmitted (no EAP payload)." Though, per Note 1, > >> this would create additional inefficiency. > > > > Yes. So which do you suggest, combining (c) and (d) or separating? > > I'm inclined to say combined. > > Alper > > > > > Yoshihiro Ohba > > > > > >> > >> Comments? > >> > >> Alper > >> > >> > >> > >> > >> On 2/10/04 2:42 PM, "Yoshihiro Ohba" wrote: > >> > >>> On Tue, Feb 10, 2004 at 01:35:58PM -0800, Alper Yegin wrote: > >>>> > >>>> 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. > >>> > >>> That is possible. But I think (timer-based) retransmission is needed > >>> anyway for unsolicited PSR. In addition, when PSR carries > >>> EAP-Request, timer-based retransmission of PSR should not occur in > >>> PANA. Instead, PAA should rely on retransmission at EAP layer, like > >>> PANA-Auth-Request message. > >>> > >>> Yoshihiro Ohba > >>> > >>> > >>>> > >>>> 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 > >>> > >> > > > > > _______________________________________________ > 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 Feb 12 16:00: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 QAA15251 for ; Thu, 12 Feb 2004 16:00: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 1ArNw0-0005BX-IJ for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 15:59:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CKxigQ019925 for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 15:59:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNw0-0005BI-Co for pana-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 15:59: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 PAA15209 for ; Thu, 12 Feb 2004 15:59:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNvx-0003V0-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:59:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNv7-0003ND-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:58:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArNuK-0003FU-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 15:58:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNuL-00052Q-OS; Thu, 12 Feb 2004 15:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNu2-00050z-FS for pana@optimus.ietf.org; Thu, 12 Feb 2004 15:57:42 -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 PAA14973 for ; Thu, 12 Feb 2004 15:57:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNtz-0003D2-00 for pana@ietf.org; Thu, 12 Feb 2004 15:57:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNt1-000358-00 for pana@ietf.org; Thu, 12 Feb 2004 15:56:40 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1ArNsG-0002y6-00 for pana@ietf.org; Thu, 12 Feb 2004 15:55:52 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1CKtpGv014973; Fri, 13 Feb 2004 05:55:51 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1CKtpRx010682; Fri, 13 Feb 2004 05:55:51 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA10681 ; Fri, 13 Feb 2004 05:55:50 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA13343; Fri, 13 Feb 2004 05:55:50 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA14234; Fri, 13 Feb 2004 05:55:50 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1CKtnEP020253; Fri, 13 Feb 2004 05:55:49 +0900 (JST) Received: from steelhead ([159.119.168.123]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSZ00MXQOSZ0L@tsbpo1.po.toshiba.co.jp>; Fri, 13 Feb 2004 05:55:48 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ArNgK-0005QC-00; Thu, 12 Feb 2004 12:43:32 -0800 Date: Thu, 12 Feb 2004 12:43:32 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040212204332.GG19857@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: <20040212191649.GE19857@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 Doesn't the combining approach conflict with stateless discovery? Yoshihiro Ohba On Thu, Feb 12, 2004 at 12:34:13PM -0800, Alper Yegin wrote: > >> OK, I thought a bit more about this. > >> > >> Unless we want to rely on the PaC re-doing whatever it did to trigger the > >> unsolicited PSR, it is reasonable to rely on retransmission of PSR. > >> > >> In that case, how about: > >> > >> a- PDI is always retransmitted > >> b- PSR and PSA are never retransmitted at the PANA layer when they carry EAP > >> AVP. (PSR gets retransmitted when the EAP layer retransmits) > >> c- PSA is retransmitted in solicited case (no EAP payload) > >> d- PSR is retransmitted in unsolicited case (no EAP payload) > >> > >> Note 1: In case there are multiple PAAs on the link, the PSR retransmission > >> (at PANA layer or due to EAP retransmission) creates inefficiency, because > >> the PaC will pick one PAA and ignore others until they give up. > > > > For solicited case, yes. For unsolicited case, it depends on whether > > the EP that found the presence of PaC informs multiple PAAs or not. > > If the EP informs one PAA only, then the inefficiency does not apply. > > Good point. > > > > >> > >> Note 2: For the sake of simplifying the protocol, we could combine (c) and > >> (d) and say: "PSR is retransmitted (no EAP payload)." Though, per Note 1, > >> this would create additional inefficiency. > > > > Yes. So which do you suggest, combining (c) and (d) or separating? > > I'm inclined to say combined. > > Alper > > > > > Yoshihiro Ohba > > > > > >> > >> Comments? > >> > >> Alper > >> > >> > >> > >> > >> On 2/10/04 2:42 PM, "Yoshihiro Ohba" wrote: > >> > >>> On Tue, Feb 10, 2004 at 01:35:58PM -0800, Alper Yegin wrote: > >>>> > >>>> 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. > >>> > >>> That is possible. But I think (timer-based) retransmission is needed > >>> anyway for unsolicited PSR. In addition, when PSR carries > >>> EAP-Request, timer-based retransmission of PSR should not occur in > >>> PANA. Instead, PAA should rely on retransmission at EAP layer, like > >>> PANA-Auth-Request message. > >>> > >>> Yoshihiro Ohba > >>> > >>> > >>>> > >>>> 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 > >>> > >> > > > > > _______________________________________________ > 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 Feb 12 16:07: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 QAA15716 for ; Thu, 12 Feb 2004 16:07: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 1ArO33-0005nD-0U; Thu, 12 Feb 2004 16: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 1ArO2S-0005lm-OE for pana@optimus.ietf.org; Thu, 12 Feb 2004 16:06: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 QAA15597 for ; Thu, 12 Feb 2004 16:06:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArO2P-0004Iw-00 for pana@ietf.org; Thu, 12 Feb 2004 16:06:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArO1U-0004Bz-00 for pana@ietf.org; Thu, 12 Feb 2004 16:05:25 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1ArO0a-00044E-00 for pana@ietf.org; Thu, 12 Feb 2004 16:04:28 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1CL4TGv017254 for ; Fri, 13 Feb 2004 06:04:29 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1CL4Tg3013034 for ; Fri, 13 Feb 2004 06:04:29 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA13033 ; Fri, 13 Feb 2004 06:04:29 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA15279; Fri, 13 Feb 2004 06:04:29 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id GAA08069; Fri, 13 Feb 2004 06:04:28 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1CL4REP022224 for ; Fri, 13 Feb 2004 06:04:28 +0900 (JST) Received: from steelhead ([159.119.168.123]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSZ0002VP7DI6@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Fri, 13 Feb 2004 06:04:26 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ArNks-0005Qn-00 for ; Thu, 12 Feb 2004 12:48:14 -0800 Date: Thu, 12 Feb 2004 12:48:14 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue65] Clarification on simultaneous per-packet protection In-reply-to: To: pana@ietf.org Message-id: <20040212204814.GH19857@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 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=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 Tue, Feb 10, 2004 at 09:09:46AM +0200, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > 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 > > > JARI: (Technical) Are these integers or bits? Can you have a capability > for both L2 and IPsec protection? > > Note by Alper: These are supposed to be integers. The current design assumes > only one of these will be enabled (UNKNOWN meaning ...?!?) after PANA. We > shall clarify this in the text. I agree. The wording "a collection of flags" is incorrect. Also, we can delete the UNKNOWN code. What about this? " The Protection-Capability AVP (Code 1028) is of type Unsigned32. The AVP data indicates the data protection capability supported by EP. Below is a list of specified data protection capabilities: 1 L2_PROTECTION 2 IPSEC_PROTECTION " Yoshihiro Ohba > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 207 > nosy: dforsber > priority: Should Fix > status: Clarifying Text Required > title: Clarification on simultaneous per-packet protection > __________________________________________________ > PANA Issues > > __________________________________________________ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 12 16:09:03 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 QAA15817 for ; Thu, 12 Feb 2004 16:09:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArO4Y-0006Bb-NM for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 16:08:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CL8YwZ023771 for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 16:08:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArO4Y-0006BC-8Y for pana-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 16:08: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 QAA15774 for ; Thu, 12 Feb 2004 16:08:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArO4U-0004aK-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 16:08:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArO3c-0004Sp-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 16:07:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArO32-0004Ml-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 16:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArO33-0005nD-0U; Thu, 12 Feb 2004 16: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 1ArO2S-0005lm-OE for pana@optimus.ietf.org; Thu, 12 Feb 2004 16:06: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 QAA15597 for ; Thu, 12 Feb 2004 16:06:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArO2P-0004Iw-00 for pana@ietf.org; Thu, 12 Feb 2004 16:06:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArO1U-0004Bz-00 for pana@ietf.org; Thu, 12 Feb 2004 16:05:25 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1ArO0a-00044E-00 for pana@ietf.org; Thu, 12 Feb 2004 16:04:28 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1CL4TGv017254 for ; Fri, 13 Feb 2004 06:04:29 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1CL4Tg3013034 for ; Fri, 13 Feb 2004 06:04:29 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA13033 ; Fri, 13 Feb 2004 06:04:29 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA15279; Fri, 13 Feb 2004 06:04:29 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id GAA08069; Fri, 13 Feb 2004 06:04:28 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1CL4REP022224 for ; Fri, 13 Feb 2004 06:04:28 +0900 (JST) Received: from steelhead ([159.119.168.123]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSZ0002VP7DI6@tsbpo1.po.toshiba.co.jp> for pana@ietf.org; Fri, 13 Feb 2004 06:04:26 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ArNks-0005Qn-00 for ; Thu, 12 Feb 2004 12:48:14 -0800 Date: Thu, 12 Feb 2004 12:48:14 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue65] Clarification on simultaneous per-packet protection In-reply-to: To: pana@ietf.org Message-id: <20040212204814.GH19857@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 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=AWL autolearn=no version=2.60 On Tue, Feb 10, 2004 at 09:09:46AM +0200, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > 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 > > > JARI: (Technical) Are these integers or bits? Can you have a capability > for both L2 and IPsec protection? > > Note by Alper: These are supposed to be integers. The current design assumes > only one of these will be enabled (UNKNOWN meaning ...?!?) after PANA. We > shall clarify this in the text. I agree. The wording "a collection of flags" is incorrect. Also, we can delete the UNKNOWN code. What about this? " The Protection-Capability AVP (Code 1028) is of type Unsigned32. The AVP data indicates the data protection capability supported by EP. Below is a list of specified data protection capabilities: 1 L2_PROTECTION 2 IPSEC_PROTECTION " Yoshihiro Ohba > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 207 > nosy: dforsber > priority: Should Fix > status: Clarifying Text Required > title: Clarification on simultaneous per-packet protection > __________________________________________________ > PANA Issues > > __________________________________________________ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 12 16:15: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 QAA16445 for ; Thu, 12 Feb 2004 16:15: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 1ArOAn-0007Mn-QL; Thu, 12 Feb 2004 16:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOAI-00074o-O1 for pana@optimus.ietf.org; Thu, 12 Feb 2004 16:14: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 QAA16381 for ; Thu, 12 Feb 2004 16:14:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArOAF-0005La-00 for pana@ietf.org; Thu, 12 Feb 2004 16:14:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArO9H-0005GF-00 for pana@ietf.org; Thu, 12 Feb 2004 16:13:28 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ArO8U-0005AY-00 for pana@ietf.org; Thu, 12 Feb 2004 16:12:38 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id C02786A906; Thu, 12 Feb 2004 23:12:34 +0200 (EET) Message-ID: <402BEBD8.10907@piuha.net> Date: Thu, 12 Feb 2004 23:10:48 +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: Yoshihiro Ohba Cc: pana@ietf.org Subject: Re: [Pana] NEW: [issue65] Clarification on simultaneous per-packet protection References: <20040212204814.GH19857@steelhead> In-Reply-To: <20040212204814.GH19857@steelhead> Content-Type: text/plain; charset=us-ascii 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 Yoshihiro Ohba wrote: > I agree. The wording "a collection of flags" is incorrect. Also, we > can delete the UNKNOWN code. What about this? > > " > The Protection-Capability AVP (Code 1028) is of type Unsigned32. The > AVP data indicates the data protection capability supported by > EP. Below is a list of specified data protection capabilities: > > 1 L2_PROTECTION > 2 IPSEC_PROTECTION > " Ok. Thanks. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 12 16: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 QAA16551 for ; Thu, 12 Feb 2004 16: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 1ArOCE-0007SO-TJ for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 16:16:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CLGUGC028658 for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 16:16:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOCE-0007S9-Lv for pana-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 16:16: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 QAA16505 for ; Thu, 12 Feb 2004 16:16:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArOCA-0005Yb-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 16:16:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArOBE-0005SR-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 16:15:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArOAn-0005N4-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 16:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOAn-0007Mn-QL; Thu, 12 Feb 2004 16:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOAI-00074o-O1 for pana@optimus.ietf.org; Thu, 12 Feb 2004 16:14: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 QAA16381 for ; Thu, 12 Feb 2004 16:14:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArOAF-0005La-00 for pana@ietf.org; Thu, 12 Feb 2004 16:14:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArO9H-0005GF-00 for pana@ietf.org; Thu, 12 Feb 2004 16:13:28 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1ArO8U-0005AY-00 for pana@ietf.org; Thu, 12 Feb 2004 16:12:38 -0500 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id C02786A906; Thu, 12 Feb 2004 23:12:34 +0200 (EET) Message-ID: <402BEBD8.10907@piuha.net> Date: Thu, 12 Feb 2004 23:10:48 +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: Yoshihiro Ohba Cc: pana@ietf.org Subject: Re: [Pana] NEW: [issue65] Clarification on simultaneous per-packet protection References: <20040212204814.GH19857@steelhead> In-Reply-To: <20040212204814.GH19857@steelhead> 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 Yoshihiro Ohba wrote: > I agree. The wording "a collection of flags" is incorrect. Also, we > can delete the UNKNOWN code. What about this? > > " > The Protection-Capability AVP (Code 1028) is of type Unsigned32. The > AVP data indicates the data protection capability supported by > EP. Below is a list of specified data protection capabilities: > > 1 L2_PROTECTION > 2 IPSEC_PROTECTION > " Ok. Thanks. --Jari _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 12 19:41: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 TAA28468 for ; Thu, 12 Feb 2004 19:41: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 1ArROA-0006kj-H2; Thu, 12 Feb 2004 19:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArRNn-0006jd-Dk for pana@optimus.ietf.org; Thu, 12 Feb 2004 19:40: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 TAA28455 for ; Thu, 12 Feb 2004 19:40:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArRNj-0003aj-00 for pana@ietf.org; Thu, 12 Feb 2004 19:40:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArRMm-0003Vt-00 for pana@ietf.org; Thu, 12 Feb 2004 19:39:37 -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 1ArRMW-0003Qg-00 for pana@ietf.org; Thu, 12 Feb 2004 19:39:20 -0500 Date: Thu, 12 Feb 2004 16:39:37 -0800 Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy From: Alper Yegin To: Yoshihiro Ohba CC: Message-ID: In-Reply-To: <20040212204332.GG19857@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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 > Doesn't the combining approach conflict with stateless discovery? Hmmm, yes it does. Are you suggesting we keep (c) and (d) as is? The unsolicited case will still be stateful, due to (d). Now solicited case where EAP AVP is not carried in PSR-PSA is the only one that can keep the PAA stateless (until PaC engages in authentication). Alper > > Yoshihiro Ohba > > > On Thu, Feb 12, 2004 at 12:34:13PM -0800, Alper Yegin wrote: >>>> OK, I thought a bit more about this. >>>> >>>> Unless we want to rely on the PaC re-doing whatever it did to trigger the >>>> unsolicited PSR, it is reasonable to rely on retransmission of PSR. >>>> >>>> In that case, how about: >>>> >>>> a- PDI is always retransmitted >>>> b- PSR and PSA are never retransmitted at the PANA layer when they carry >>>> EAP >>>> AVP. (PSR gets retransmitted when the EAP layer retransmits) >>>> c- PSA is retransmitted in solicited case (no EAP payload) >>>> d- PSR is retransmitted in unsolicited case (no EAP payload) >>>> >>>> Note 1: In case there are multiple PAAs on the link, the PSR retransmission >>>> (at PANA layer or due to EAP retransmission) creates inefficiency, because >>>> the PaC will pick one PAA and ignore others until they give up. >>> >>> For solicited case, yes. For unsolicited case, it depends on whether >>> the EP that found the presence of PaC informs multiple PAAs or not. >>> If the EP informs one PAA only, then the inefficiency does not apply. >> >> Good point. >> >>> >>>> >>>> Note 2: For the sake of simplifying the protocol, we could combine (c) and >>>> (d) and say: "PSR is retransmitted (no EAP payload)." Though, per Note 1, >>>> this would create additional inefficiency. >>> >>> Yes. So which do you suggest, combining (c) and (d) or separating? >> >> I'm inclined to say combined. >> >> Alper >> >>> >>> Yoshihiro Ohba >>> >>> >>>> >>>> Comments? >>>> >>>> Alper >>>> >>>> >>>> >>>> >>>> On 2/10/04 2:42 PM, "Yoshihiro Ohba" wrote: >>>> >>>>> On Tue, Feb 10, 2004 at 01:35:58PM -0800, Alper Yegin wrote: >>>>>> >>>>>> 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. >>>>> >>>>> That is possible. But I think (timer-based) retransmission is needed >>>>> anyway for unsolicited PSR. In addition, when PSR carries >>>>> EAP-Request, timer-based retransmission of PSR should not occur in >>>>> PANA. Instead, PAA should rely on retransmission at EAP layer, like >>>>> PANA-Auth-Request message. >>>>> >>>>> Yoshihiro Ohba >>>>> >>>>> >>>>>> >>>>>> 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 >>>>> >>>> >>> >> >> >> _______________________________________________ >> 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 Feb 12 19:43: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 TAA28541 for ; Thu, 12 Feb 2004 19:43: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 1ArRPi-0006u6-59 for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 19:42:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D0gcVV026532 for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 19:42:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArRPi-0006tr-0N for pana-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 19:42:38 -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 TAA28532 for ; Thu, 12 Feb 2004 19:42:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArRPe-0003lD-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 19:42:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArROs-0003gQ-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 19:41:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArRO9-0003bH-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 19:41:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArROA-0006kj-H2; Thu, 12 Feb 2004 19:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArRNn-0006jd-Dk for pana@optimus.ietf.org; Thu, 12 Feb 2004 19:40: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 TAA28455 for ; Thu, 12 Feb 2004 19:40:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArRNj-0003aj-00 for pana@ietf.org; Thu, 12 Feb 2004 19:40:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArRMm-0003Vt-00 for pana@ietf.org; Thu, 12 Feb 2004 19:39:37 -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 1ArRMW-0003Qg-00 for pana@ietf.org; Thu, 12 Feb 2004 19:39:20 -0500 Date: Thu, 12 Feb 2004 16:39:37 -0800 Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy From: Alper Yegin To: Yoshihiro Ohba CC: Message-ID: In-Reply-To: <20040212204332.GG19857@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 > Doesn't the combining approach conflict with stateless discovery? Hmmm, yes it does. Are you suggesting we keep (c) and (d) as is? The unsolicited case will still be stateful, due to (d). Now solicited case where EAP AVP is not carried in PSR-PSA is the only one that can keep the PAA stateless (until PaC engages in authentication). Alper > > Yoshihiro Ohba > > > On Thu, Feb 12, 2004 at 12:34:13PM -0800, Alper Yegin wrote: >>>> OK, I thought a bit more about this. >>>> >>>> Unless we want to rely on the PaC re-doing whatever it did to trigger the >>>> unsolicited PSR, it is reasonable to rely on retransmission of PSR. >>>> >>>> In that case, how about: >>>> >>>> a- PDI is always retransmitted >>>> b- PSR and PSA are never retransmitted at the PANA layer when they carry >>>> EAP >>>> AVP. (PSR gets retransmitted when the EAP layer retransmits) >>>> c- PSA is retransmitted in solicited case (no EAP payload) >>>> d- PSR is retransmitted in unsolicited case (no EAP payload) >>>> >>>> Note 1: In case there are multiple PAAs on the link, the PSR retransmission >>>> (at PANA layer or due to EAP retransmission) creates inefficiency, because >>>> the PaC will pick one PAA and ignore others until they give up. >>> >>> For solicited case, yes. For unsolicited case, it depends on whether >>> the EP that found the presence of PaC informs multiple PAAs or not. >>> If the EP informs one PAA only, then the inefficiency does not apply. >> >> Good point. >> >>> >>>> >>>> Note 2: For the sake of simplifying the protocol, we could combine (c) and >>>> (d) and say: "PSR is retransmitted (no EAP payload)." Though, per Note 1, >>>> this would create additional inefficiency. >>> >>> Yes. So which do you suggest, combining (c) and (d) or separating? >> >> I'm inclined to say combined. >> >> Alper >> >>> >>> Yoshihiro Ohba >>> >>> >>>> >>>> Comments? >>>> >>>> Alper >>>> >>>> >>>> >>>> >>>> On 2/10/04 2:42 PM, "Yoshihiro Ohba" wrote: >>>> >>>>> On Tue, Feb 10, 2004 at 01:35:58PM -0800, Alper Yegin wrote: >>>>>> >>>>>> 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. >>>>> >>>>> That is possible. But I think (timer-based) retransmission is needed >>>>> anyway for unsolicited PSR. In addition, when PSR carries >>>>> EAP-Request, timer-based retransmission of PSR should not occur in >>>>> PANA. Instead, PAA should rely on retransmission at EAP layer, like >>>>> PANA-Auth-Request message. >>>>> >>>>> Yoshihiro Ohba >>>>> >>>>> >>>>>> >>>>>> 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 >>>>> >>>> >>> >> >> >> _______________________________________________ >> 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 Feb 12 20:06: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 UAA29206 for ; Thu, 12 Feb 2004 20:06: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 1ArRmO-0007yb-G1; Thu, 12 Feb 2004 20: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 1ArRm0-0007wz-3a for pana@optimus.ietf.org; Thu, 12 Feb 2004 20:05: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 UAA29101 for ; Thu, 12 Feb 2004 20:05:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArRlw-0005iQ-00 for pana@ietf.org; Thu, 12 Feb 2004 20:05:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArRkg-0005RI-00 for pana@ietf.org; Thu, 12 Feb 2004 20:04:19 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ArRjo-0005Fs-04 for pana@ietf.org; Thu, 12 Feb 2004 20:03:24 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ArRV3-0005ln-7m for pana@ietf.org; Thu, 12 Feb 2004 19:48:09 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1D0luGv028924; Fri, 13 Feb 2004 09:47:56 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1D0luIl014710; Fri, 13 Feb 2004 09:47:56 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA14706 ; Fri, 13 Feb 2004 09:47:55 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA29310; Fri, 13 Feb 2004 09:47:55 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA21247; Fri, 13 Feb 2004 09:47:54 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1D0lrEP027492; Fri, 13 Feb 2004 09:47:53 +0900 (JST) Received: from steelhead ([159.119.168.115]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSZ00C0BZJPGI@tsbpo1.po.toshiba.co.jp>; Fri, 13 Feb 2004 09:47:52 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ArQcw-0005qG-00; Thu, 12 Feb 2004 15:52:14 -0800 Date: Thu, 12 Feb 2004 15:52:13 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040212235213.GL19857@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: <20040212204332.GG19857@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: , On Thu, Feb 12, 2004 at 04:39:37PM -0800, Alper Yegin wrote: > > Doesn't the combining approach conflict with stateless discovery? > > Hmmm, yes it does. Are you suggesting we keep (c) and (d) as is? Yes. > > The unsolicited case will still be stateful, due to (d). > Now solicited case where EAP AVP is not carried in PSR-PSA is the only one > that can keep the PAA stateless (until PaC engages in authentication). Correct. Yoshihiro Ohba > > Alper > > > > > > Yoshihiro Ohba > > > > > > On Thu, Feb 12, 2004 at 12:34:13PM -0800, Alper Yegin wrote: > >>>> OK, I thought a bit more about this. > >>>> > >>>> Unless we want to rely on the PaC re-doing whatever it did to trigger the > >>>> unsolicited PSR, it is reasonable to rely on retransmission of PSR. > >>>> > >>>> In that case, how about: > >>>> > >>>> a- PDI is always retransmitted > >>>> b- PSR and PSA are never retransmitted at the PANA layer when they carry > >>>> EAP > >>>> AVP. (PSR gets retransmitted when the EAP layer retransmits) > >>>> c- PSA is retransmitted in solicited case (no EAP payload) > >>>> d- PSR is retransmitted in unsolicited case (no EAP payload) > >>>> > >>>> Note 1: In case there are multiple PAAs on the link, the PSR retransmission > >>>> (at PANA layer or due to EAP retransmission) creates inefficiency, because > >>>> the PaC will pick one PAA and ignore others until they give up. > >>> > >>> For solicited case, yes. For unsolicited case, it depends on whether > >>> the EP that found the presence of PaC informs multiple PAAs or not. > >>> If the EP informs one PAA only, then the inefficiency does not apply. > >> > >> Good point. > >> > >>> > >>>> > >>>> Note 2: For the sake of simplifying the protocol, we could combine (c) and > >>>> (d) and say: "PSR is retransmitted (no EAP payload)." Though, per Note 1, > >>>> this would create additional inefficiency. > >>> > >>> Yes. So which do you suggest, combining (c) and (d) or separating? > >> > >> I'm inclined to say combined. > >> > >> Alper > >> > >>> > >>> Yoshihiro Ohba > >>> > >>> > >>>> > >>>> Comments? > >>>> > >>>> Alper > >>>> > >>>> > >>>> > >>>> > >>>> On 2/10/04 2:42 PM, "Yoshihiro Ohba" wrote: > >>>> > >>>>> On Tue, Feb 10, 2004 at 01:35:58PM -0800, Alper Yegin wrote: > >>>>>> > >>>>>> 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. > >>>>> > >>>>> That is possible. But I think (timer-based) retransmission is needed > >>>>> anyway for unsolicited PSR. In addition, when PSR carries > >>>>> EAP-Request, timer-based retransmission of PSR should not occur in > >>>>> PANA. Instead, PAA should rely on retransmission at EAP layer, like > >>>>> PANA-Auth-Request message. > >>>>> > >>>>> Yoshihiro Ohba > >>>>> > >>>>> > >>>>>> > >>>>>> 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 > >>>>> > >>>> > >>> > >> > >> > >> _______________________________________________ > >> 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 Feb 12 20:09:03 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 UAA29603 for ; Thu, 12 Feb 2004 20:09:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArRoo-0008WE-5t for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 20:08:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D18YJP032740 for pana-archive@odin.ietf.org; Thu, 12 Feb 2004 20:08:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArRon-0008Vz-VY for pana-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 20:08: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 UAA29521 for ; Thu, 12 Feb 2004 20:08:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArRok-0006FM-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 20:08:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArRne-00061r-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 20:07:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArRmN-0005mQ-00 for pana-web-archive@ietf.org; Thu, 12 Feb 2004 20:06:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArRmO-0007yb-G1; Thu, 12 Feb 2004 20: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 1ArRm0-0007wz-3a for pana@optimus.ietf.org; Thu, 12 Feb 2004 20:05: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 UAA29101 for ; Thu, 12 Feb 2004 20:05:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArRlw-0005iQ-00 for pana@ietf.org; Thu, 12 Feb 2004 20:05:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArRkg-0005RI-00 for pana@ietf.org; Thu, 12 Feb 2004 20:04:19 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ArRjo-0005Fs-04 for pana@ietf.org; Thu, 12 Feb 2004 20:03:24 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ArRV3-0005ln-7m for pana@ietf.org; Thu, 12 Feb 2004 19:48:09 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1D0luGv028924; Fri, 13 Feb 2004 09:47:56 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1D0luIl014710; Fri, 13 Feb 2004 09:47:56 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id KAA14706 ; Fri, 13 Feb 2004 09:47:55 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id JAA29310; Fri, 13 Feb 2004 09:47:55 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id JAA21247; Fri, 13 Feb 2004 09:47:54 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1D0lrEP027492; Fri, 13 Feb 2004 09:47:53 +0900 (JST) Received: from steelhead ([159.119.168.115]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HSZ00C0BZJPGI@tsbpo1.po.toshiba.co.jp>; Fri, 13 Feb 2004 09:47:52 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ArQcw-0005qG-00; Thu, 12 Feb 2004 15:52:14 -0800 Date: Thu, 12 Feb 2004 15:52:13 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue57] PSR retransmission strategy In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040212235213.GL19857@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: <20040212204332.GG19857@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 On Thu, Feb 12, 2004 at 04:39:37PM -0800, Alper Yegin wrote: > > Doesn't the combining approach conflict with stateless discovery? > > Hmmm, yes it does. Are you suggesting we keep (c) and (d) as is? Yes. > > The unsolicited case will still be stateful, due to (d). > Now solicited case where EAP AVP is not carried in PSR-PSA is the only one > that can keep the PAA stateless (until PaC engages in authentication). Correct. Yoshihiro Ohba > > Alper > > > > > > Yoshihiro Ohba > > > > > > On Thu, Feb 12, 2004 at 12:34:13PM -0800, Alper Yegin wrote: > >>>> OK, I thought a bit more about this. > >>>> > >>>> Unless we want to rely on the PaC re-doing whatever it did to trigger the > >>>> unsolicited PSR, it is reasonable to rely on retransmission of PSR. > >>>> > >>>> In that case, how about: > >>>> > >>>> a- PDI is always retransmitted > >>>> b- PSR and PSA are never retransmitted at the PANA layer when they carry > >>>> EAP > >>>> AVP. (PSR gets retransmitted when the EAP layer retransmits) > >>>> c- PSA is retransmitted in solicited case (no EAP payload) > >>>> d- PSR is retransmitted in unsolicited case (no EAP payload) > >>>> > >>>> Note 1: In case there are multiple PAAs on the link, the PSR retransmission > >>>> (at PANA layer or due to EAP retransmission) creates inefficiency, because > >>>> the PaC will pick one PAA and ignore others until they give up. > >>> > >>> For solicited case, yes. For unsolicited case, it depends on whether > >>> the EP that found the presence of PaC informs multiple PAAs or not. > >>> If the EP informs one PAA only, then the inefficiency does not apply. > >> > >> Good point. > >> > >>> > >>>> > >>>> Note 2: For the sake of simplifying the protocol, we could combine (c) and > >>>> (d) and say: "PSR is retransmitted (no EAP payload)." Though, per Note 1, > >>>> this would create additional inefficiency. > >>> > >>> Yes. So which do you suggest, combining (c) and (d) or separating? > >> > >> I'm inclined to say combined. > >> > >> Alper > >> > >>> > >>> Yoshihiro Ohba > >>> > >>> > >>>> > >>>> Comments? > >>>> > >>>> Alper > >>>> > >>>> > >>>> > >>>> > >>>> On 2/10/04 2:42 PM, "Yoshihiro Ohba" wrote: > >>>> > >>>>> On Tue, Feb 10, 2004 at 01:35:58PM -0800, Alper Yegin wrote: > >>>>>> > >>>>>> 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. > >>>>> > >>>>> That is possible. But I think (timer-based) retransmission is needed > >>>>> anyway for unsolicited PSR. In addition, when PSR carries > >>>>> EAP-Request, timer-based retransmission of PSR should not occur in > >>>>> PANA. Instead, PAA should rely on retransmission at EAP layer, like > >>>>> PANA-Auth-Request message. > >>>>> > >>>>> Yoshihiro Ohba > >>>>> > >>>>> > >>>>>> > >>>>>> 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 > >>>>> > >>>> > >>> > >> > >> > >> _______________________________________________ > >> 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 Feb 13 02:55: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 CAA27231 for ; Fri, 13 Feb 2004 02:55: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 1ArYAA-0002EM-DG; Fri, 13 Feb 2004 02:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYA6-0002DX-42 for pana@optimus.ietf.org; Fri, 13 Feb 2004 02:54: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 CAA27171 for ; Fri, 13 Feb 2004 02:54: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 1ArY9y-0004LI-00 for pana@ietf.org; Fri, 13 Feb 2004 02:54:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArY97-0004F4-00 for pana@ietf.org; Fri, 13 Feb 2004 02:53:58 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArY8F-00048D-00 for pana@ietf.org; Fri, 13 Feb 2004 02:53:03 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1D7r5v22839 for ; Fri, 13 Feb 2004 09:53:05 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 13 Feb 2004 09:53:05 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 09:53:05 +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] issue63: MAC AVP a SHOULD or a MUST Date: Fri, 13 Feb 2004 09:53:04 +0200 Message-ID: Thread-Topic: [Pana] issue63: MAC AVP a SHOULD or a MUST Thread-Index: AcPxpmROCvLfUVEwRZyO5qOKpsUY9AAX/wsg To: X-OriginalArrivalTime: 13 Feb 2004 07:53:05.0879 (UTC) FILETIME=[6A02A670:01C3F206] 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 I agree on this as well. - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > Alper Yegin > Sent: 12 February, 2004 22:09 > To: pana@ietf.org > Subject: [Pana] issue63: MAC AVP a SHOULD or a MUST >=20 >=20 > On 2/9/04 11:09 PM, "Dan.Forsberg@nokia.com"=20 > wrote: >=20 > > New submission from Dan Forsberg : > >=20 > > inherited from the previous (re-)authentication. 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. > >=20 > > JARI: (Technical) How about a MUST? Otherwise, implementations have > > to deal with the MAC either being present or not=20 > present. And there > > has to be a config switch to either allow or disallow this. >=20 > I think MUST is better. >=20 > Alper >=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 Fri Feb 13 02:57:16 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 CAA27304 for ; Fri, 13 Feb 2004 02:57:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYBu-0002Kj-Rm for pana-archive@odin.ietf.org; Fri, 13 Feb 2004 02:56:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D7uoR1008969 for pana-archive@odin.ietf.org; Fri, 13 Feb 2004 02:56:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYBu-0002Ka-EZ for pana-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 02:56: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 CAA27269 for ; Fri, 13 Feb 2004 02:56:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArYBm-0004V2-00 for pana-web-archive@ietf.org; Fri, 13 Feb 2004 02:56:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArYAr-0004Qi-00 for pana-web-archive@ietf.org; Fri, 13 Feb 2004 02:55:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArYA6-0004MU-00 for pana-web-archive@ietf.org; Fri, 13 Feb 2004 02:54:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYAA-0002EM-DG; Fri, 13 Feb 2004 02:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYA6-0002DX-42 for pana@optimus.ietf.org; Fri, 13 Feb 2004 02:54: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 CAA27171 for ; Fri, 13 Feb 2004 02:54: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 1ArY9y-0004LI-00 for pana@ietf.org; Fri, 13 Feb 2004 02:54:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArY97-0004F4-00 for pana@ietf.org; Fri, 13 Feb 2004 02:53:58 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ArY8F-00048D-00 for pana@ietf.org; Fri, 13 Feb 2004 02:53:03 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1D7r5v22839 for ; Fri, 13 Feb 2004 09:53:05 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 13 Feb 2004 09:53:05 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 13 Feb 2004 09:53:05 +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] issue63: MAC AVP a SHOULD or a MUST Date: Fri, 13 Feb 2004 09:53:04 +0200 Message-ID: Thread-Topic: [Pana] issue63: MAC AVP a SHOULD or a MUST Thread-Index: AcPxpmROCvLfUVEwRZyO5qOKpsUY9AAX/wsg To: X-OriginalArrivalTime: 13 Feb 2004 07:53:05.0879 (UTC) FILETIME=[6A02A670:01C3F206] 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 I agree on this as well. - Dan > -----Original Message----- > From: pana-admin@ietf.org [mailto:pana-admin@ietf.org]On Behalf Of ext > Alper Yegin > Sent: 12 February, 2004 22:09 > To: pana@ietf.org > Subject: [Pana] issue63: MAC AVP a SHOULD or a MUST >=20 >=20 > On 2/9/04 11:09 PM, "Dan.Forsberg@nokia.com"=20 > wrote: >=20 > > New submission from Dan Forsberg : > >=20 > > inherited from the previous (re-)authentication. 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. > >=20 > > JARI: (Technical) How about a MUST? Otherwise, implementations have > > to deal with the MAC either being present or not=20 > present. And there > > has to be a config switch to either allow or disallow this. >=20 > I think MUST is better. >=20 > Alper >=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 Fri Feb 13 16:12: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 QAA04111 for ; Fri, 13 Feb 2004 16:12: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 1ArkbT-0004En-N5; Fri, 13 Feb 2004 16:12:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkaT-0003yQ-QR for pana@optimus.ietf.org; Fri, 13 Feb 2004 16:11:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03880; Fri, 13 Feb 2004 16:10:58 -0500 (EST) Message-Id: <200402132110.QAA03880@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: Fri, 13 Feb 2004 16:10:58 -0500 Subject: [Pana] I-D ACTION:draft-ietf-pana-pana-03.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 : Protocol for Carrying Authentication for Network Access (PANA) Author(s) : D. Forsberg Filename : draft-ietf-pana-pana-03.txt Pages : 71 Date : 2004-2-12 This document defines the Protocol for Carrying Authentication for Network Access (PANA), a link-layer agnostic transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. PANA can carry any authentication method that can be specified as an EAP method, and can be used on any link that can carry IP. PANA covers the client-to-network access authentication part of an overall secure network access framework, which additionally includes other protocols and mechanisms for service provisioning, access control as a result of initial authentication, and accounting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pana-pana-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pana-pana-03.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-2-13163328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pana-pana-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pana-pana-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-13163328.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Fri Feb 13 16:14: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 QAA04418 for ; Fri, 13 Feb 2004 16:14: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 1ArkdY-0004mA-Bs for pana-archive@odin.ietf.org; Fri, 13 Feb 2004 16:14:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DLEChW018352 for pana-archive@odin.ietf.org; Fri, 13 Feb 2004 16:14:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkdY-0004lv-6t for pana-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 16:14:12 -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 QAA04259 for ; Fri, 13 Feb 2004 16:14:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArkdW-0002LE-00 for pana-web-archive@ietf.org; Fri, 13 Feb 2004 16:14:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArkcZ-0002E4-00 for pana-web-archive@ietf.org; Fri, 13 Feb 2004 16:13:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arkbi-00028r-00 for pana-web-archive@ietf.org; Fri, 13 Feb 2004 16:12:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkbT-0004En-N5; Fri, 13 Feb 2004 16:12:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArkaT-0003yQ-QR for pana@optimus.ietf.org; Fri, 13 Feb 2004 16:11:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03880; Fri, 13 Feb 2004 16:10:58 -0500 (EST) Message-Id: <200402132110.QAA03880@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: Fri, 13 Feb 2004 16:10:58 -0500 Subject: [Pana] I-D ACTION:draft-ietf-pana-pana-03.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.4 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 : Protocol for Carrying Authentication for Network Access (PANA) Author(s) : D. Forsberg Filename : draft-ietf-pana-pana-03.txt Pages : 71 Date : 2004-2-12 This document defines the Protocol for Carrying Authentication for Network Access (PANA), a link-layer agnostic transport for Extensible Authentication Protocol (EAP) to enable network access authentication between clients and access networks. PANA can carry any authentication method that can be specified as an EAP method, and can be used on any link that can carry IP. PANA covers the client-to-network access authentication part of an overall secure network access framework, which additionally includes other protocols and mechanisms for service provisioning, access control as a result of initial authentication, and accounting. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pana-pana-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pana-pana-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pana-pana-03.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-2-13163328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pana-pana-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pana-pana-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-13163328.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Feb 16 05:05: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 FAA09054 for ; Mon, 16 Feb 2004 05:05: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 1Asfcb-0001Ae-Sp; Mon, 16 Feb 2004 05: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 1Asfby-00019F-Nm for pana@optimus.ietf.org; Mon, 16 Feb 2004 05:04:22 -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 FAA09006 for ; Mon, 16 Feb 2004 05:04:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asfbv-0007hI-00 for pana@ietf.org; Mon, 16 Feb 2004 05:04:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asfb2-0007a8-00 for pana@ietf.org; Mon, 16 Feb 2004 05:03:25 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1Asfa6-0007V8-00 for pana@ietf.org; Mon, 16 Feb 2004 05:02:26 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i1GA2Qt25430 for ; Mon, 16 Feb 2004 11:02:26 +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 i1GA2QV22267 for ; Mon, 16 Feb 2004 11:02:26 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 16 Feb 2004 11:01:49 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685D6B@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'pana@ietf.org'" Date: Mon, 16 Feb 2004 11:02:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" 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] PANA weblog (blog) 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 all, i have created a pana blog. please take a look at: http://www.tschofenig.com/cgi-bin/pana.cgi the aim of this page is to allow ietf members to retrieve up-to-date pana wg information. it should contain pana related draft and paper announcements, presentations and press news. ciao hannes _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Feb 16 05:07: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 FAA09179 for ; Mon, 16 Feb 2004 05:07: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 1Asfee-0001HG-W1 for pana-archive@odin.ietf.org; Mon, 16 Feb 2004 05:07:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GA787D004907 for pana-archive@odin.ietf.org; Mon, 16 Feb 2004 05: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 1Asfed-0001Gv-Ed for pana-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 05:07: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 FAA09091 for ; Mon, 16 Feb 2004 05:07:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asfea-00007K-00 for pana-web-archive@ietf.org; Mon, 16 Feb 2004 05:07:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asfdb-00001J-00 for pana-web-archive@ietf.org; Mon, 16 Feb 2004 05:06:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asfce-0007ka-00 for pana-web-archive@ietf.org; Mon, 16 Feb 2004 05:05:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asfcb-0001Ae-Sp; Mon, 16 Feb 2004 05: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 1Asfby-00019F-Nm for pana@optimus.ietf.org; Mon, 16 Feb 2004 05:04:22 -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 FAA09006 for ; Mon, 16 Feb 2004 05:04:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asfbv-0007hI-00 for pana@ietf.org; Mon, 16 Feb 2004 05:04:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asfb2-0007a8-00 for pana@ietf.org; Mon, 16 Feb 2004 05:03:25 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1Asfa6-0007V8-00 for pana@ietf.org; Mon, 16 Feb 2004 05:02:26 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id i1GA2Qt25430 for ; Mon, 16 Feb 2004 11:02:26 +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 i1GA2QV22267 for ; Mon, 16 Feb 2004 11:02:26 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Mon, 16 Feb 2004 11:01:49 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685D6B@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'pana@ietf.org'" Date: Mon, 16 Feb 2004 11:02:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Pana] PANA weblog (blog) 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 hi all, i have created a pana blog. please take a look at: http://www.tschofenig.com/cgi-bin/pana.cgi the aim of this page is to allow ietf members to retrieve up-to-date pana wg information. it should contain pana related draft and paper announcements, presentations and press news. ciao hannes _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Feb 17 21:58: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 VAA24838 for ; Tue, 17 Feb 2004 21:58: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 1AtHuT-0003bf-Ey; Tue, 17 Feb 2004 21:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtHu1-0003aS-BJ for pana@optimus.ietf.org; Tue, 17 Feb 2004 21:57: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 VAA24803 for ; Tue, 17 Feb 2004 21:57:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtHty-0001ud-00 for pana@ietf.org; Tue, 17 Feb 2004 21:57:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtHt2-0001sC-00 for pana@ietf.org; Tue, 17 Feb 2004 21:56:33 -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 1AtHsh-0001pn-00 for pana@ietf.org; Tue, 17 Feb 2004 21:56:12 -0500 Date: Tue, 17 Feb 2004 18:56:25 -0800 Subject: Re: [Pana] NEW: [issue52] Details of double authentication From: Alper Yegin To: Yoshihiro Ohba , Message-ID: In-Reply-To: <20040211201330.GG28754@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" 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 Hi Yoshi, Thanks for taking a stab at this. I have some comments below. > " > The main task in authentication phase is to carry EAP messages > between PaC and PAA. All EAP messages except for EAP > Success/Failure messages are carried in the > PANA-Auth-Request/PANA-Auth-Answer messages. When an EAP > Success/Failure message is sent from a PAA, the message is carried > in the PANA-Bind-Request message. The PANA-Bind-Request message is > acknowledged with a PANA-Bind-Answer. PANA supports two EAP > sequences to be sequencially performed in a single PANA session, > where an PANA-Bind-Request/Answer exchange occurs at the end of > each EAP sequence. > " Now that EAP messages can be carried over PSR-PSA, I think we need to reflect that to the text above. Btw, giving an example PANA sequence is a good idea. Your clarifications are good. Here are couple other things to consider for tying the loose ends: - I guess this scheme works even if the PAA does not advertise a list of ISPs. The PaC can still perform separate authentication. But I suspect we assume PAA must advertise a NAP-info, or else this doesn't work. Right? If so, we shall spell this out. Also, the assumption is that PAA belongs to a single NAP, hence at most one NAP-info is included at any time. - If the first round of EAP fails, and PaC does not want to continue, what happens? Maybe we should add something to PBA to signal that. Same with PAA wishing to abort the session? Some indication in PBR can be useful here. - We should note that if this is the first run of PANA, the per-packet protection kicks in only after the successful completion of PANA (i.e., after the second EAP run). - Including some AVPs after the first PBR doesn't make sense. For example device Id (?), session lifetime, protection capability... We might want to consider defining a new PANA message that is only used to delimeter to EAP sequences for split NAP-ISP authentication. This can provide overall simplification, I believe. - Also Jari had these comments: Why is there no problem with the mitm attacks in the PANA authentication sequences, as there are in other EAP sequencing? ... JARI: (Substantial) If the two MSKs are not somehow cryptographically bound to each other, a mitm attack remains a possibility. See draft-puthenkulam-eap-binding-04.txt. Any thoughts on this? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Feb 17 22:00: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 WAA24910 for ; Tue, 17 Feb 2004 22:00: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 1AtHw1-0003fc-Jf for pana-archive@odin.ietf.org; Tue, 17 Feb 2004 21:59:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I2xbFw014102 for pana-archive@odin.ietf.org; Tue, 17 Feb 2004 21:59:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtHw1-0003fM-9V for pana-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 21:59:37 -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 VAA24881 for ; Tue, 17 Feb 2004 21:59:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtHvy-00021H-00 for pana-web-archive@ietf.org; Tue, 17 Feb 2004 21:59:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtHv1-0001yF-00 for pana-web-archive@ietf.org; Tue, 17 Feb 2004 21:58:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtHuT-0001vF-00 for pana-web-archive@ietf.org; Tue, 17 Feb 2004 21:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtHuT-0003bf-Ey; Tue, 17 Feb 2004 21:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtHu1-0003aS-BJ for pana@optimus.ietf.org; Tue, 17 Feb 2004 21:57: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 VAA24803 for ; Tue, 17 Feb 2004 21:57:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtHty-0001ud-00 for pana@ietf.org; Tue, 17 Feb 2004 21:57:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtHt2-0001sC-00 for pana@ietf.org; Tue, 17 Feb 2004 21:56:33 -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 1AtHsh-0001pn-00 for pana@ietf.org; Tue, 17 Feb 2004 21:56:12 -0500 Date: Tue, 17 Feb 2004 18:56:25 -0800 Subject: Re: [Pana] NEW: [issue52] Details of double authentication From: Alper Yegin To: Yoshihiro Ohba , Message-ID: In-Reply-To: <20040211201330.GG28754@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 Hi Yoshi, Thanks for taking a stab at this. I have some comments below. > " > The main task in authentication phase is to carry EAP messages > between PaC and PAA. All EAP messages except for EAP > Success/Failure messages are carried in the > PANA-Auth-Request/PANA-Auth-Answer messages. When an EAP > Success/Failure message is sent from a PAA, the message is carried > in the PANA-Bind-Request message. The PANA-Bind-Request message is > acknowledged with a PANA-Bind-Answer. PANA supports two EAP > sequences to be sequencially performed in a single PANA session, > where an PANA-Bind-Request/Answer exchange occurs at the end of > each EAP sequence. > " Now that EAP messages can be carried over PSR-PSA, I think we need to reflect that to the text above. Btw, giving an example PANA sequence is a good idea. Your clarifications are good. Here are couple other things to consider for tying the loose ends: - I guess this scheme works even if the PAA does not advertise a list of ISPs. The PaC can still perform separate authentication. But I suspect we assume PAA must advertise a NAP-info, or else this doesn't work. Right? If so, we shall spell this out. Also, the assumption is that PAA belongs to a single NAP, hence at most one NAP-info is included at any time. - If the first round of EAP fails, and PaC does not want to continue, what happens? Maybe we should add something to PBA to signal that. Same with PAA wishing to abort the session? Some indication in PBR can be useful here. - We should note that if this is the first run of PANA, the per-packet protection kicks in only after the successful completion of PANA (i.e., after the second EAP run). - Including some AVPs after the first PBR doesn't make sense. For example device Id (?), session lifetime, protection capability... We might want to consider defining a new PANA message that is only used to delimeter to EAP sequences for split NAP-ISP authentication. This can provide overall simplification, I believe. - Also Jari had these comments: Why is there no problem with the mitm attacks in the PANA authentication sequences, as there are in other EAP sequencing? ... JARI: (Substantial) If the two MSKs are not somehow cryptographically bound to each other, a mitm attack remains a possibility. See draft-puthenkulam-eap-binding-04.txt. Any thoughts on this? Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Feb 18 17:15: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 RAA25744 for ; Wed, 18 Feb 2004 17:15: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 1AtZyB-00050F-Ob; Wed, 18 Feb 2004 17:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZxn-0004zZ-Ro for pana@optimus.ietf.org; Wed, 18 Feb 2004 17:14: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 RAA25732 for ; Wed, 18 Feb 2004 17:14:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtZxl-0004vz-00 for pana@ietf.org; Wed, 18 Feb 2004 17:14:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtZwp-0004uY-00 for pana@ietf.org; Wed, 18 Feb 2004 17:13:39 -0500 Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx with smtp (Exim 4.12) id 1AtZw3-0004tE-00 for pana@ietf.org; Wed, 18 Feb 2004 17:12:51 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.55.204 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 18 Feb 2004 22:12:50 -0000 Message-ID: <00f201c3f66c$5a02a710$6601a8c0@adithya> From: "Mohan Parthasarathy" To: Date: Wed, 18 Feb 2004 14:12:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Pana] 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: , Content-Transfer-Encoding: 7bit Folks, I have updated the draft with all of the open issues, but missed the deadline. Here is the temporary location of the draft. Please send your comments on the mailing list. http://yegin.org/IETF/draft-ietf-pana-ipsec-02.txt thanks -mohan _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Feb 18 17:17:06 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 RAA25812 for ; Wed, 18 Feb 2004 17:17:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZzj-00054c-Ey for pana-archive@odin.ietf.org; Wed, 18 Feb 2004 17:16:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IMGdkq019496 for pana-archive@odin.ietf.org; Wed, 18 Feb 2004 17:16:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZzj-00054N-1G for pana-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 17:16: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 RAA25789 for ; Wed, 18 Feb 2004 17:16:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtZzg-0004zd-00 for pana-web-archive@ietf.org; Wed, 18 Feb 2004 17:16:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtZyl-0004yU-00 for pana-web-archive@ietf.org; Wed, 18 Feb 2004 17:15:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtZyB-0004wt-00 for pana-web-archive@ietf.org; Wed, 18 Feb 2004 17:15:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZyB-00050F-Ob; Wed, 18 Feb 2004 17:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtZxn-0004zZ-Ro for pana@optimus.ietf.org; Wed, 18 Feb 2004 17:14: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 RAA25732 for ; Wed, 18 Feb 2004 17:14:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtZxl-0004vz-00 for pana@ietf.org; Wed, 18 Feb 2004 17:14:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtZwp-0004uY-00 for pana@ietf.org; Wed, 18 Feb 2004 17:13:39 -0500 Received: from smtp812.mail.sc5.yahoo.com ([66.163.170.82]) by ietf-mx with smtp (Exim 4.12) id 1AtZw3-0004tE-00 for pana@ietf.org; Wed, 18 Feb 2004 17:12:51 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.55.204 with login) by smtp812.mail.sc5.yahoo.com with SMTP; 18 Feb 2004 22:12:50 -0000 Message-ID: <00f201c3f66c$5a02a710$6601a8c0@adithya> From: "Mohan Parthasarathy" To: Date: Wed, 18 Feb 2004 14:12:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: 7bit Subject: [Pana] 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I have updated the draft with all of the open issues, but missed the deadline. Here is the temporary location of the draft. Please send your comments on the mailing list. http://yegin.org/IETF/draft-ietf-pana-ipsec-02.txt thanks -mohan _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Thu Feb 19 18:49: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 SAA04050 for ; Thu, 19 Feb 2004 18:49: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 1Atxue-0002gs-N1; Thu, 19 Feb 2004 18: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 1Atxu8-0002gJ-Tg for pana@optimus.ietf.org; Thu, 19 Feb 2004 18:48:29 -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 SAA04022 for ; Thu, 19 Feb 2004 18:48:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atxu5-0003Ok-00 for pana@ietf.org; Thu, 19 Feb 2004 18:48:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atxt9-0003Mz-00 for pana@ietf.org; Thu, 19 Feb 2004 18:47:28 -0500 Received: from law12-f104.law12.hotmail.com ([64.4.19.104] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1Atxsk-0003LJ-00 for pana@ietf.org; Thu, 19 Feb 2004 18:47:02 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 19 Feb 2004 15:46:32 -0800 Received: from 216.98.102.225 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 19 Feb 2004 23:46:32 GMT X-Originating-IP: [216.98.102.225] X-Originating-Email: [aeyegin@hotmail.com] X-Sender: aeyegin@hotmail.com From: "Alper Yegin" To: pana@ietf.org Cc: narten@us.ibm.com, margaret@thingmagic.com Date: Thu, 19 Feb 2004 15:46:32 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Feb 2004 23:46:32.0796 (UTC) FILETIME=[9A77F1C0:01C3F742] 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 Subject: [Pana] PANA meeting agenda 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: , Protocol for Carrying Authentication for Network Access WG (pana) Monday, March 1 at 1530-1730 ================================== CHAIRS: Basavaraj Patil Alper Yegin AGENDA: 1. Preliminaries (bluesheets, minute takers, agenda bashing) : 5 min Chairs 2. PANA protocol update and open issues: 30 min; Yoshihiro Ohba, Basavaraj Patil draft-ietf-pana-pana-03.txt. See "Change History" section of the draft for the list of issues closed in this revision. Detailed issue descriptions can be found at http://danforsberg.info:8080/pana-issues/ Newly closed issues and currently open issues will be covered in this presentation for confirming/achieving consensus. 3. PANA framework: 30 min, Alper Yegin draft-ohba-pana-framework-00.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. 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. 5. PANA-IPsec I-D update and open issues: 15 min; Hannes Tschofenig, Mohan Parthasarathy www.yegin.org/IETF/draft-ietf-pana-ipsec-02.txt. Objective is to discuss the latest changes (see Revision Log) and confirm consensus. 6. Next steps: 5 min, Chairs/ADs _________________________________________________________________ Take off on a romantic weekend or a family adventure to these great U.S. locations. http://special.msn.com/local/hotdestinations.armx _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Thu Feb 19 18:51:03 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 SAA04117 for ; Thu, 19 Feb 2004 18:51:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtxwD-0002qp-DJ for pana-archive@odin.ietf.org; Thu, 19 Feb 2004 18:50:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JNobkS010958 for pana-archive@odin.ietf.org; Thu, 19 Feb 2004 18:50:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtxwC-0002qb-Dc for pana-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 18:50: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 SAA04106 for ; Thu, 19 Feb 2004 18:50:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atxw9-0003Ve-00 for pana-web-archive@ietf.org; Thu, 19 Feb 2004 18:50:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtxvA-0003Se-00 for pana-web-archive@ietf.org; Thu, 19 Feb 2004 18:49:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atxue-0003Pk-00 for pana-web-archive@ietf.org; Thu, 19 Feb 2004 18: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 1Atxue-0002gs-N1; Thu, 19 Feb 2004 18: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 1Atxu8-0002gJ-Tg for pana@optimus.ietf.org; Thu, 19 Feb 2004 18:48:29 -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 SAA04022 for ; Thu, 19 Feb 2004 18:48:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atxu5-0003Ok-00 for pana@ietf.org; Thu, 19 Feb 2004 18:48:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atxt9-0003Mz-00 for pana@ietf.org; Thu, 19 Feb 2004 18:47:28 -0500 Received: from law12-f104.law12.hotmail.com ([64.4.19.104] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1Atxsk-0003LJ-00 for pana@ietf.org; Thu, 19 Feb 2004 18:47:02 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 19 Feb 2004 15:46:32 -0800 Received: from 216.98.102.225 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 19 Feb 2004 23:46:32 GMT X-Originating-IP: [216.98.102.225] X-Originating-Email: [aeyegin@hotmail.com] X-Sender: aeyegin@hotmail.com From: "Alper Yegin" To: pana@ietf.org Cc: narten@us.ibm.com, margaret@thingmagic.com Date: Thu, 19 Feb 2004 15:46:32 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Feb 2004 23:46:32.0796 (UTC) FILETIME=[9A77F1C0:01C3F742] Subject: [Pana] PANA meeting agenda 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 Protocol for Carrying Authentication for Network Access WG (pana) Monday, March 1 at 1530-1730 ================================== CHAIRS: Basavaraj Patil Alper Yegin AGENDA: 1. Preliminaries (bluesheets, minute takers, agenda bashing) : 5 min Chairs 2. PANA protocol update and open issues: 30 min; Yoshihiro Ohba, Basavaraj Patil draft-ietf-pana-pana-03.txt. See "Change History" section of the draft for the list of issues closed in this revision. Detailed issue descriptions can be found at http://danforsberg.info:8080/pana-issues/ Newly closed issues and currently open issues will be covered in this presentation for confirming/achieving consensus. 3. PANA framework: 30 min, Alper Yegin draft-ohba-pana-framework-00.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. 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. 5. PANA-IPsec I-D update and open issues: 15 min; Hannes Tschofenig, Mohan Parthasarathy www.yegin.org/IETF/draft-ietf-pana-ipsec-02.txt. Objective is to discuss the latest changes (see Revision Log) and confirm consensus. 6. Next steps: 5 min, Chairs/ADs _________________________________________________________________ Take off on a romantic weekend or a family adventure to these great U.S. locations. http://special.msn.com/local/hotdestinations.armx _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Fri Feb 20 04:24:50 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 EAA11535 for ; Fri, 20 Feb 2004 04:24:49 -0500 (EST) 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 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 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 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 pana-admin@ietf.org Mon Feb 23 03:18: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 DAA12916 for ; Mon, 23 Feb 2004 03:18: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 1AvBHs-0001HO-H9; Mon, 23 Feb 2004 03:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvBGx-0001DQ-76 for pana@optimus.ietf.org; Mon, 23 Feb 2004 03:17: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 DAA12870 for ; Mon, 23 Feb 2004 03:17:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvBGv-0003yr-00 for pana@ietf.org; Mon, 23 Feb 2004 03:17:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvBG1-0003w7-00 for pana@ietf.org; Mon, 23 Feb 2004 03:16:06 -0500 Received: from bay15-f34.bay15.hotmail.com ([65.54.185.34] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AvBFa-0003sx-00 for pana@ietf.org; Mon, 23 Feb 2004 03:15:38 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 23 Feb 2004 00:15:09 -0800 Received: from 67.161.72.171 by by15fd.bay15.hotmail.msn.com with HTTP; Mon, 23 Feb 2004 08:15:08 GMT X-Originating-IP: [67.161.72.171] X-Originating-Email: [aeyegin@hotmail.com] X-Sender: aeyegin@hotmail.com From: "Alper Yegin" To: pana@ietf.org Date: Mon, 23 Feb 2004 00:15:08 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Feb 2004 08:15:09.0210 (UTC) FILETIME=[26E86FA0:01C3F9E5] 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=FREE_TRIAL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA12871 Subject: [Pana] Reading list for the meeting 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 Dear WG members, In order to increase the productivity of the meeting, please come to the=20 meeting prepared. Please read the following new I-Ds. WG's opinion will be solicited during= =20 the meeting to accept these I-Ds as official WG items: - draft-ohba-pana-framework-00.txt - http://yacine.free.fr/ietf59/pana/draft-yacine-pana-snmp-02.txt Please be aware of the updates to the pana specification (see Change Hist= ory=20 of draft-ietf-pana-pana-03.txt), and the currently open issues (see=20 http://danforsberg.info:8080/pana-issues/ ) Same with the www.yegin.org/IETF/draft-ietf-pana-ipsec-02.txt. - Chairs _________________________________________________________________ Say =93good-bye=94 to spam, viruses and pop-ups with MSN Premium -- free = trial=20 offer! http://click.atdmt.com/AVE/go/onm00200359ave/direct/01/ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Feb 23 03:20: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 DAA12973 for ; Mon, 23 Feb 2004 03:20: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 1AvBJp-0001QN-Rj for pana-archive@odin.ietf.org; Mon, 23 Feb 2004 03:20:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N8K1JQ005458 for pana-archive@odin.ietf.org; Mon, 23 Feb 2004 03:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvBJo-0001Px-0p for pana-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 03:20:00 -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 DAA12956 for ; Mon, 23 Feb 2004 03:19:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvBJl-00048a-00 for pana-web-archive@ietf.org; Mon, 23 Feb 2004 03:19:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvBIp-00045R-00 for pana-web-archive@ietf.org; Mon, 23 Feb 2004 03:19:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvBHu-00042H-00 for pana-web-archive@ietf.org; Mon, 23 Feb 2004 03:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvBHs-0001HO-H9; Mon, 23 Feb 2004 03:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvBGx-0001DQ-76 for pana@optimus.ietf.org; Mon, 23 Feb 2004 03:17: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 DAA12870 for ; Mon, 23 Feb 2004 03:17:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvBGv-0003yr-00 for pana@ietf.org; Mon, 23 Feb 2004 03:17:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvBG1-0003w7-00 for pana@ietf.org; Mon, 23 Feb 2004 03:16:06 -0500 Received: from bay15-f34.bay15.hotmail.com ([65.54.185.34] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AvBFa-0003sx-00 for pana@ietf.org; Mon, 23 Feb 2004 03:15:38 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 23 Feb 2004 00:15:09 -0800 Received: from 67.161.72.171 by by15fd.bay15.hotmail.msn.com with HTTP; Mon, 23 Feb 2004 08:15:08 GMT X-Originating-IP: [67.161.72.171] X-Originating-Email: [aeyegin@hotmail.com] X-Sender: aeyegin@hotmail.com From: "Alper Yegin" To: pana@ietf.org Date: Mon, 23 Feb 2004 00:15:08 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Feb 2004 08:15:09.0210 (UTC) FILETIME=[26E86FA0:01C3F9E5] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA12871 Subject: [Pana] Reading list for the meeting 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=FREE_TRIAL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear WG members, In order to increase the productivity of the meeting, please come to the=20 meeting prepared. Please read the following new I-Ds. WG's opinion will be solicited during= =20 the meeting to accept these I-Ds as official WG items: - draft-ohba-pana-framework-00.txt - http://yacine.free.fr/ietf59/pana/draft-yacine-pana-snmp-02.txt Please be aware of the updates to the pana specification (see Change Hist= ory=20 of draft-ietf-pana-pana-03.txt), and the currently open issues (see=20 http://danforsberg.info:8080/pana-issues/ ) Same with the www.yegin.org/IETF/draft-ietf-pana-ipsec-02.txt. - Chairs _________________________________________________________________ Say =93good-bye=94 to spam, viruses and pop-ups with MSN Premium -- free = trial=20 offer! http://click.atdmt.com/AVE/go/onm00200359ave/direct/01/ _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Feb 23 10:30: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 KAA02521 for ; Mon, 23 Feb 2004 10: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 1AvI1y-00006K-I8; Mon, 23 Feb 2004 10:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvI1N-0008VE-7n for pana@optimus.ietf.org; Mon, 23 Feb 2004 10:29: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 KAA02352 for ; Mon, 23 Feb 2004 10:29:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvI1K-0005QX-00 for pana@ietf.org; Mon, 23 Feb 2004 10:29:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvI0L-0005LA-00 for pana@ietf.org; Mon, 23 Feb 2004 10:28:22 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AvHzm-0005HW-00 for pana@ietf.org; Mon, 23 Feb 2004 10:27:46 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1NFRf89021226; Tue, 24 Feb 2004 00:27:41 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1NFRe1I018720; Tue, 24 Feb 2004 00:27:40 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA18719 ; Tue, 24 Feb 2004 00:27:40 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA11754; Tue, 24 Feb 2004 00:27:40 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id AAA24582; Tue, 24 Feb 2004 00:27:39 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1NFRcKv008858; Tue, 24 Feb 2004 00:27:39 +0900 (JST) Received: from steelhead ([159.119.168.172]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HTJ00J49MXVNE@tsbpo1.po.toshiba.co.jp>; Tue, 24 Feb 2004 00:27:38 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AuOdJ-0002Ym-00; Fri, 20 Feb 2004 20:20:53 -0800 Date: Fri, 20 Feb 2004 20:20:53 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue52] Details of double authentication In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040221042053.GZ737@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: <20040211201330.GG28754@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: , On Tue, Feb 17, 2004 at 06:56:25PM -0800, Alper Yegin wrote: > Hi Yoshi, > > Thanks for taking a stab at this. I have some comments below. > > > " > > The main task in authentication phase is to carry EAP messages > > between PaC and PAA. All EAP messages except for EAP > > Success/Failure messages are carried in the > > PANA-Auth-Request/PANA-Auth-Answer messages. When an EAP > > Success/Failure message is sent from a PAA, the message is carried > > in the PANA-Bind-Request message. The PANA-Bind-Request message is > > acknowledged with a PANA-Bind-Answer. PANA supports two EAP > > sequences to be sequencially performed in a single PANA session, > > where an PANA-Bind-Request/Answer exchange occurs at the end of > > each EAP sequence. > > " > > Now that EAP messages can be carried over PSR-PSA, I think we need to > reflect that to the text above. OK. I think that when a PSR is sent with S-bit set, it should not contain an EAP message because the negotiation on NAP/ISP separate authentication is not done yet. > > Btw, giving an example PANA sequence is a good idea. > > Your clarifications are good. Here are couple other things to consider for > tying the loose ends: > > - I guess this scheme works even if the PAA does not advertise a list of > ISPs. The PaC can still perform separate authentication. But I suspect we > assume PAA must advertise a NAP-info, or else this doesn't work. Right? If > so, we shall spell this out. Also, the assumption is that PAA belongs to a > single NAP, hence at most one NAP-info is included at any time. I think the current text in the second paragraph of Section 4.3 already describes this. > > - If the first round of EAP fails, and PaC does not want to continue, what > happens? Maybe we should add something to PBA to signal that. In the current design, there is no option for a PaC that has accepted an offer from PAA to perform separate authentication in the discovery and initial handshake phase to decline the 2nd round of EAP. If we want to add the functionality to decline the 2nd round of EAP in this case, we might use S-bit not only for the discovery and initial handshake phase but also for the authenticatioin phase (i.e., When S-bit is cleared in PBA message while it is set in PBR message, it means that the PaC does not want to continue to 2nd EAP round). > > Same with PAA wishing to abort the session? Some indication in PBR can be > useful here. If the PAA aborts the session just because the 1st EAP round fails, PaC cannot continue to the 2nd EAP round even if it wishes to do it. I think PAA should not aborts the session once the PaC has accepted the offer to perform NAP/ISP separate authentications. > > - We should note that if this is the first run of PANA, the per-packet > protection kicks in only after the successful completion of PANA (i.e., > after the second EAP run). Yes. > > - Including some AVPs after the first PBR doesn't make sense. For example > device Id (?), session lifetime, protection capability... We might want to > consider defining a new PANA message that is only used to delimeter to EAP > sequences for split NAP-ISP authentication. This can provide overall > simplification, I believe. I agree. > > - Also Jari had these comments: > > Why is there no problem with the mitm attacks in the PANA > authentication sequences, as there are in other EAP sequencing? > ... > JARI: (Substantial) If the two MSKs are not somehow cryptographically > bound to each other, a mitm attack remains a possibility. See > draft-puthenkulam-eap-binding-04.txt. The two MSKs (or AAA-Keys) should be cryptographically bound to each other unless lower-layer is secured. When lower-layer is not secured, the PANA-Auth-Request/Answer exchange for the second EAP round must be protected with a MAC AVP. This means that the EAP method used in the first EAP round must generate a AAA-Key. Yoshihiro Ohba > > Any thoughts on this? > > 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 Feb 23 10:31:59 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 KAA02659 for ; Mon, 23 Feb 2004 10:31: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 1AvI3Q-0000FG-Ep for pana-archive@odin.ietf.org; Mon, 23 Feb 2004 10:31:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NFVWGW000940 for pana-archive@odin.ietf.org; Mon, 23 Feb 2004 10:31:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvI3Q-0000F4-7H for pana-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 10:31: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 KAA02629 for ; Mon, 23 Feb 2004 10:31:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvI3N-0005fK-00 for pana-web-archive@ietf.org; Mon, 23 Feb 2004 10:31:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvI2U-0005ZK-00 for pana-web-archive@ietf.org; Mon, 23 Feb 2004 10:30:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvI1y-0005Tc-00 for pana-web-archive@ietf.org; Mon, 23 Feb 2004 10:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvI1y-00006K-I8; Mon, 23 Feb 2004 10:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvI1N-0008VE-7n for pana@optimus.ietf.org; Mon, 23 Feb 2004 10:29: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 KAA02352 for ; Mon, 23 Feb 2004 10:29:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvI1K-0005QX-00 for pana@ietf.org; Mon, 23 Feb 2004 10:29:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvI0L-0005LA-00 for pana@ietf.org; Mon, 23 Feb 2004 10:28:22 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AvHzm-0005HW-00 for pana@ietf.org; Mon, 23 Feb 2004 10:27:46 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1NFRf89021226; Tue, 24 Feb 2004 00:27:41 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1NFRe1I018720; Tue, 24 Feb 2004 00:27:40 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA18719 ; Tue, 24 Feb 2004 00:27:40 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA11754; Tue, 24 Feb 2004 00:27:40 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id AAA24582; Tue, 24 Feb 2004 00:27:39 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1NFRcKv008858; Tue, 24 Feb 2004 00:27:39 +0900 (JST) Received: from steelhead ([159.119.168.172]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HTJ00J49MXVNE@tsbpo1.po.toshiba.co.jp>; Tue, 24 Feb 2004 00:27:38 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AuOdJ-0002Ym-00; Fri, 20 Feb 2004 20:20:53 -0800 Date: Fri, 20 Feb 2004 20:20:53 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue52] Details of double authentication In-reply-to: To: Alper Yegin Cc: Yoshihiro Ohba , pana@ietf.org Message-id: <20040221042053.GZ737@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: <20040211201330.GG28754@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 On Tue, Feb 17, 2004 at 06:56:25PM -0800, Alper Yegin wrote: > Hi Yoshi, > > Thanks for taking a stab at this. I have some comments below. > > > " > > The main task in authentication phase is to carry EAP messages > > between PaC and PAA. All EAP messages except for EAP > > Success/Failure messages are carried in the > > PANA-Auth-Request/PANA-Auth-Answer messages. When an EAP > > Success/Failure message is sent from a PAA, the message is carried > > in the PANA-Bind-Request message. The PANA-Bind-Request message is > > acknowledged with a PANA-Bind-Answer. PANA supports two EAP > > sequences to be sequencially performed in a single PANA session, > > where an PANA-Bind-Request/Answer exchange occurs at the end of > > each EAP sequence. > > " > > Now that EAP messages can be carried over PSR-PSA, I think we need to > reflect that to the text above. OK. I think that when a PSR is sent with S-bit set, it should not contain an EAP message because the negotiation on NAP/ISP separate authentication is not done yet. > > Btw, giving an example PANA sequence is a good idea. > > Your clarifications are good. Here are couple other things to consider for > tying the loose ends: > > - I guess this scheme works even if the PAA does not advertise a list of > ISPs. The PaC can still perform separate authentication. But I suspect we > assume PAA must advertise a NAP-info, or else this doesn't work. Right? If > so, we shall spell this out. Also, the assumption is that PAA belongs to a > single NAP, hence at most one NAP-info is included at any time. I think the current text in the second paragraph of Section 4.3 already describes this. > > - If the first round of EAP fails, and PaC does not want to continue, what > happens? Maybe we should add something to PBA to signal that. In the current design, there is no option for a PaC that has accepted an offer from PAA to perform separate authentication in the discovery and initial handshake phase to decline the 2nd round of EAP. If we want to add the functionality to decline the 2nd round of EAP in this case, we might use S-bit not only for the discovery and initial handshake phase but also for the authenticatioin phase (i.e., When S-bit is cleared in PBA message while it is set in PBR message, it means that the PaC does not want to continue to 2nd EAP round). > > Same with PAA wishing to abort the session? Some indication in PBR can be > useful here. If the PAA aborts the session just because the 1st EAP round fails, PaC cannot continue to the 2nd EAP round even if it wishes to do it. I think PAA should not aborts the session once the PaC has accepted the offer to perform NAP/ISP separate authentications. > > - We should note that if this is the first run of PANA, the per-packet > protection kicks in only after the successful completion of PANA (i.e., > after the second EAP run). Yes. > > - Including some AVPs after the first PBR doesn't make sense. For example > device Id (?), session lifetime, protection capability... We might want to > consider defining a new PANA message that is only used to delimeter to EAP > sequences for split NAP-ISP authentication. This can provide overall > simplification, I believe. I agree. > > - Also Jari had these comments: > > Why is there no problem with the mitm attacks in the PANA > authentication sequences, as there are in other EAP sequencing? > ... > JARI: (Substantial) If the two MSKs are not somehow cryptographically > bound to each other, a mitm attack remains a possibility. See > draft-puthenkulam-eap-binding-04.txt. The two MSKs (or AAA-Keys) should be cryptographically bound to each other unless lower-layer is secured. When lower-layer is not secured, the PANA-Auth-Request/Answer exchange for the second EAP round must be protected with a MAC AVP. This means that the EAP method used in the first EAP round must generate a AAA-Key. Yoshihiro Ohba > > Any thoughts on this? > > 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 Feb 23 22:10: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 WAA09338 for ; Mon, 23 Feb 2004 22:10: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 1AvSxM-0004Pp-Vo; Mon, 23 Feb 2004 22:10:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvSx1-0004Oj-7r for pana@optimus.ietf.org; Mon, 23 Feb 2004 22:09: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 WAA09333 for ; Mon, 23 Feb 2004 22:09:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvSwy-000455-00 for pana@ietf.org; Mon, 23 Feb 2004 22:09:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvSvy-00040w-00 for pana@ietf.org; Mon, 23 Feb 2004 22:08:34 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AvSv3-0003uZ-00 for pana@ietf.org; Mon, 23 Feb 2004 22:07:37 -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 <0HTK00I01JBVR4@mailout2.samsung.com> for pana@ietf.org; Tue, 24 Feb 2004 12:07:07 +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 <0HTK00ETSJBU3E@mailout2.samsung.com> for pana@ietf.org; Tue, 24 Feb 2004 12:07:06 +0900 (KST) Received: from Alperyegin ([105.144.32.84]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTK000YVJBSPB@mmp2.samsung.com> for pana@ietf.org; Tue, 24 Feb 2004 12:07:06 +0900 (KST) Date: Mon, 23 Feb 2004 19:07:00 -0800 From: Alper Yegin To: pana@ietf.org Cc: yacine@free.fr Message-id: <001501c3fa83$462c6440$54209069@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.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] paa2ep snmp comments... 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 Couple comments on the PAA2EP draft... When a PAA finds a dead or rebooted EP, the PAA should immediately terminate PANA sessions for PaCs that are authorized for access through the EP. There is a hidden assumption that the state is not preserved across reboots. In case it is preserved, I'd say the above is not the right behavior. We might need to re-consider this text. This "New PaC" notification (panaNewPacNotification) is triggered when the the EP detects traffic coming from an unauthorized source. An implementation might consider rate limiting for this notification. I couldn't see where the crypto key is carried with the Pana802Filters. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Feb 23 22:12: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 WAA09418 for ; Mon, 23 Feb 2004 22:12: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 1AvSz4-0004UD-Uo for pana-archive@odin.ietf.org; Mon, 23 Feb 2004 22:11:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O3BksM017239 for pana-archive@odin.ietf.org; Mon, 23 Feb 2004 22:11:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvSz4-0004Ty-PT for pana-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 22:11: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 WAA09406 for ; Mon, 23 Feb 2004 22:11:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvSz1-0004Es-00 for pana-web-archive@ietf.org; Mon, 23 Feb 2004 22:11:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvSy5-0004Aj-00 for pana-web-archive@ietf.org; Mon, 23 Feb 2004 22:10:46 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AvSxN-00046X-00 for pana-web-archive@ietf.org; Mon, 23 Feb 2004 22:10:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AvSxP-0006ox-EZ for pana-web-archive@ietf.org; Mon, 23 Feb 2004 22:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvSxM-0004Pp-Vo; Mon, 23 Feb 2004 22:10:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvSx1-0004Oj-7r for pana@optimus.ietf.org; Mon, 23 Feb 2004 22:09: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 WAA09333 for ; Mon, 23 Feb 2004 22:09:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvSwy-000455-00 for pana@ietf.org; Mon, 23 Feb 2004 22:09:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvSvy-00040w-00 for pana@ietf.org; Mon, 23 Feb 2004 22:08:34 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AvSv3-0003uZ-00 for pana@ietf.org; Mon, 23 Feb 2004 22:07:37 -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 <0HTK00I01JBVR4@mailout2.samsung.com> for pana@ietf.org; Tue, 24 Feb 2004 12:07:07 +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 <0HTK00ETSJBU3E@mailout2.samsung.com> for pana@ietf.org; Tue, 24 Feb 2004 12:07:06 +0900 (KST) Received: from Alperyegin ([105.144.32.84]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTK000YVJBSPB@mmp2.samsung.com> for pana@ietf.org; Tue, 24 Feb 2004 12:07:06 +0900 (KST) Date: Mon, 23 Feb 2004 19:07:00 -0800 From: Alper Yegin To: pana@ietf.org Cc: yacine@free.fr Message-id: <001501c3fa83$462c6440$54209069@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] paa2ep snmp comments... 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 autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Couple comments on the PAA2EP draft... When a PAA finds a dead or rebooted EP, the PAA should immediately terminate PANA sessions for PaCs that are authorized for access through the EP. There is a hidden assumption that the state is not preserved across reboots. In case it is preserved, I'd say the above is not the right behavior. We might need to re-consider this text. This "New PaC" notification (panaNewPacNotification) is triggered when the the EP detects traffic coming from an unauthorized source. An implementation might consider rate limiting for this notification. I couldn't see where the crypto key is carried with the Pana802Filters. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Mon Feb 23 23:30: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 XAA12613 for ; Mon, 23 Feb 2004 23:30: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 1AvUCo-0000Cj-Hk; Mon, 23 Feb 2004 23:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvUCT-0000C2-PV for pana@optimus.ietf.org; Mon, 23 Feb 2004 23:29: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 XAA12607 for ; Mon, 23 Feb 2004 23:29:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvUCR-0003Fv-00 for pana@ietf.org; Mon, 23 Feb 2004 23:29:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvUBV-0003Cd-00 for pana@ietf.org; Mon, 23 Feb 2004 23:28:42 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1AvUAx-00037B-00 for pana@ietf.org; Mon, 23 Feb 2004 23:28:07 -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 <0HTK00K01N1XEP@mailout1.samsung.com> for pana@ietf.org; Tue, 24 Feb 2004 13:27:33 +0900 (KST) Received: from ep_mmp2 (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 <0HTK00BTSN1WGA@mailout1.samsung.com> for pana@ietf.org; Tue, 24 Feb 2004 13:27:33 +0900 (KST) Received: from Alperyegin ([105.144.32.84]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTK009ZTN1TQ0@mmp2.samsung.com> for pana@ietf.org; Tue, 24 Feb 2004 13:27:32 +0900 (KST) Date: Mon, 23 Feb 2004 20:27:24 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <001e01c3fa8e$82bf48e0$54209069@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.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] pana-ipsec-02 comments... 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 Comments on PANA-IPsec draft. This document assumes that the following have already happened before the IKE exchange starts. ... 4) PaC configures a routable or global address as discussed in section 4 of this document. Well, that's not strictly accurate when we consider IP address configuration during IKEv2. After a successful authentication, the client configures a routable or global address using [DHCP][DHCPV6] before running [IKE][IKEv2] or running address auto-configuration methods available within [IKE] or [IKEv2] by using a configuration payload or running DHCP over a special IPsec tunnel mode SA [RFC3456] or auto-configures an address using stateless auto-configuration [IPv6-ND] before running [IKE] or [IKEv2] if IPv6 is being used. This text is a bit hard to follow... - IPv6 address autoconf, DHCP, and DHCPv6 can (and normally would) happen even before PANA. - RFC3456 and IKEv2 configurations would happen after PANA. In IPv4, all packets are tunneled using IPsec tunnel mode SA with the inner and outer source address same as the routable address. Is that the case even when the global IP address is configured via IKEv2? If the network chooses IPsec to secure the link between PaC and EP, PAA should communicate the IKE pre-shared key, the link-local address of the PaC (in IPv6 only), routable address of the PaC and the PANA session ID to EP before the IKE exchange begins. I don't think the routable address of PaC is delivered to EP... The draft has a discussion on that in section 6.0 anyways. In the case of address configuration using [RFC3456] or [IKE] [IKEV2] or [DHCP] [DHCPV6], EP can learn the address allocated to the client and hence setup the SPD before the IKE exchange starts. The case for DHCP is different than the rfc3456 and IKE ones. In the latter, the IP address configuration is part of the protocol executions, hence EP can know the allocated address. In DHCP case, I guess the assumption is that DHCP server/relay is co-located with the EP, hence EP can learn the address indirectly. If that's the case, some explanation in the I-D would be useful. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Mon Feb 23 23:32:12 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 XAA12695 for ; Mon, 23 Feb 2004 23:32:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvUES-0000KS-QH for pana-archive@odin.ietf.org; Mon, 23 Feb 2004 23:31:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1O4ViVh001258 for pana-archive@odin.ietf.org; Mon, 23 Feb 2004 23:31:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvUES-0000KD-M2 for pana-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 23: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 XAA12679 for ; Mon, 23 Feb 2004 23:31:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvUEQ-0003P1-00 for pana-web-archive@ietf.org; Mon, 23 Feb 2004 23:31:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvUDU-0003Kh-00 for pana-web-archive@ietf.org; Mon, 23 Feb 2004 23:30:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvUCp-0003Gz-00 for pana-web-archive@ietf.org; Mon, 23 Feb 2004 23:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvUCo-0000Cj-Hk; Mon, 23 Feb 2004 23:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvUCT-0000C2-PV for pana@optimus.ietf.org; Mon, 23 Feb 2004 23:29: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 XAA12607 for ; Mon, 23 Feb 2004 23:29:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvUCR-0003Fv-00 for pana@ietf.org; Mon, 23 Feb 2004 23:29:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvUBV-0003Cd-00 for pana@ietf.org; Mon, 23 Feb 2004 23:28:42 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1AvUAx-00037B-00 for pana@ietf.org; Mon, 23 Feb 2004 23:28:07 -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 <0HTK00K01N1XEP@mailout1.samsung.com> for pana@ietf.org; Tue, 24 Feb 2004 13:27:33 +0900 (KST) Received: from ep_mmp2 (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 <0HTK00BTSN1WGA@mailout1.samsung.com> for pana@ietf.org; Tue, 24 Feb 2004 13:27:33 +0900 (KST) Received: from Alperyegin ([105.144.32.84]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTK009ZTN1TQ0@mmp2.samsung.com> for pana@ietf.org; Tue, 24 Feb 2004 13:27:32 +0900 (KST) Date: Mon, 23 Feb 2004 20:27:24 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <001e01c3fa8e$82bf48e0$54209069@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] pana-ipsec-02 comments... 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 Comments on PANA-IPsec draft. This document assumes that the following have already happened before the IKE exchange starts. ... 4) PaC configures a routable or global address as discussed in section 4 of this document. Well, that's not strictly accurate when we consider IP address configuration during IKEv2. After a successful authentication, the client configures a routable or global address using [DHCP][DHCPV6] before running [IKE][IKEv2] or running address auto-configuration methods available within [IKE] or [IKEv2] by using a configuration payload or running DHCP over a special IPsec tunnel mode SA [RFC3456] or auto-configures an address using stateless auto-configuration [IPv6-ND] before running [IKE] or [IKEv2] if IPv6 is being used. This text is a bit hard to follow... - IPv6 address autoconf, DHCP, and DHCPv6 can (and normally would) happen even before PANA. - RFC3456 and IKEv2 configurations would happen after PANA. In IPv4, all packets are tunneled using IPsec tunnel mode SA with the inner and outer source address same as the routable address. Is that the case even when the global IP address is configured via IKEv2? If the network chooses IPsec to secure the link between PaC and EP, PAA should communicate the IKE pre-shared key, the link-local address of the PaC (in IPv6 only), routable address of the PaC and the PANA session ID to EP before the IKE exchange begins. I don't think the routable address of PaC is delivered to EP... The draft has a discussion on that in section 6.0 anyways. In the case of address configuration using [RFC3456] or [IKE] [IKEV2] or [DHCP] [DHCPV6], EP can learn the address allocated to the client and hence setup the SPD before the IKE exchange starts. The case for DHCP is different than the rfc3456 and IKE ones. In the latter, the IP address configuration is part of the protocol executions, hence EP can know the allocated address. In DHCP case, I guess the assumption is that DHCP server/relay is co-located with the EP, hence EP can learn the address indirectly. If that's the case, some explanation in the I-D would be useful. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Feb 24 13: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 NAA03821 for ; Tue, 24 Feb 2004 13:58: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 1Avhkn-00075t-H2; Tue, 24 Feb 2004 13:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avhk8-00074v-Hm for pana@optimus.ietf.org; Tue, 24 Feb 2004 13:57: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 NAA03785 for ; Tue, 24 Feb 2004 13:57:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avhk6-0005db-00 for pana@ietf.org; Tue, 24 Feb 2004 13:57:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvhjB-0005YY-00 for pana@ietf.org; Tue, 24 Feb 2004 13:56:22 -0500 Received: from smtp800.mail.sc5.yahoo.com ([66.163.168.179]) by ietf-mx with smtp (Exim 4.12) id 1Avhip-0005T5-00 for pana@ietf.org; Tue, 24 Feb 2004 13:55:59 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.201 with login) by smtp800.mail.sc5.yahoo.com with SMTP; 24 Feb 2004 18:55:57 -0000 Message-ID: <009801c3fb07$d7978480$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , References: <001e01c3fa8e$82bf48e0$54209069@sisa.samsung.com> Subject: Re: [Pana] pana-ipsec-02 comments... Date: Tue, 24 Feb 2004 10:55:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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=none 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 > Comments on PANA-IPsec draft. > > This document assumes that the following have already happened before > > the IKE exchange starts. > ... > 4) PaC configures a routable or global address as discussed in > section 4 of this document. > > Well, that's not strictly accurate when we consider IP address > configuration during IKEv2. > Perhaps it can be reomved from that section. > After a successful authentication, the client configures a routable > or global address using [DHCP][DHCPV6] before running [IKE][IKEv2] or > > running address auto-configuration methods available within [IKE] or > > [IKEv2] by using a configuration payload or running DHCP over a > special IPsec tunnel mode SA [RFC3456] or auto-configures an address > > using stateless auto-configuration [IPv6-ND] before running [IKE] or > > [IKEv2] if IPv6 is being used. > > This text is a bit hard to follow... > > - IPv6 address autoconf, DHCP, and DHCPv6 can (and normally would) > happen even before PANA. > - RFC3456 and IKEv2 configurations would happen after PANA. > Will open an issue on this one. > > In IPv4, all packets are tunneled > using IPsec tunnel mode SA with the inner and outer source address > same as the routable address. > > Is that the case even when the global IP address is configured via > IKEv2? > If we have to assume that the pre-PANA address will be unconfigured, then we have no choice. > > If the network chooses IPsec to secure the link between PaC and EP, > PAA should communicate the IKE pre-shared key, the link-local address > > of the PaC (in IPv6 only), routable address of the PaC and the PANA > session ID to EP before the IKE exchange begins. > > I don't think the routable address of PaC is delivered to EP... The > draft has a discussion on that in section 6.0 anyways. > In the cases where the address is known a priori, it is communicated so that the SPD entries can be setup. It also needs to send the Key-ID along with session ID and need to specify how both are communicated in the ID payload. Will open an issue on this one also.. > In the case of address configuration > using [RFC3456] or [IKE] [IKEV2] or [DHCP] [DHCPV6], EP can learn the > > address allocated to the client and hence setup the SPD before the > IKE exchange starts. > > The case for DHCP is different than the rfc3456 and IKE ones. In the > latter, the IP address configuration is part of the protocol executions, > hence EP can know the allocated address. In DHCP case, I guess the > assumption is that DHCP server/relay is co-located with the EP, hence EP > can learn the address indirectly. If that's the case, some explanation > in the I-D would be useful. > But we are already assuming EP and AR are co-located. Then how bad this assumption would be ? -mohan > 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 Feb 24 14:00: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 OAA03945 for ; Tue, 24 Feb 2004 14:00: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 1AvhmG-0007Bm-V2 for pana-archive@odin.ietf.org; Tue, 24 Feb 2004 13:59:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OIxWYl027633 for pana-archive@odin.ietf.org; Tue, 24 Feb 2004 13:59:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvhmG-0007Bc-NO for pana-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 13:59: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 NAA03903 for ; Tue, 24 Feb 2004 13:59:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvhmE-0005rt-00 for pana-web-archive@ietf.org; Tue, 24 Feb 2004 13:59:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvhlE-0005lS-00 for pana-web-archive@ietf.org; Tue, 24 Feb 2004 13:58:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avhkq-0005ei-00 for pana-web-archive@ietf.org; Tue, 24 Feb 2004 13:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avhkn-00075t-H2; Tue, 24 Feb 2004 13:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avhk8-00074v-Hm for pana@optimus.ietf.org; Tue, 24 Feb 2004 13:57: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 NAA03785 for ; Tue, 24 Feb 2004 13:57:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avhk6-0005db-00 for pana@ietf.org; Tue, 24 Feb 2004 13:57:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvhjB-0005YY-00 for pana@ietf.org; Tue, 24 Feb 2004 13:56:22 -0500 Received: from smtp800.mail.sc5.yahoo.com ([66.163.168.179]) by ietf-mx with smtp (Exim 4.12) id 1Avhip-0005T5-00 for pana@ietf.org; Tue, 24 Feb 2004 13:55:59 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.201 with login) by smtp800.mail.sc5.yahoo.com with SMTP; 24 Feb 2004 18:55:57 -0000 Message-ID: <009801c3fb07$d7978480$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , References: <001e01c3fa8e$82bf48e0$54209069@sisa.samsung.com> Subject: Re: [Pana] pana-ipsec-02 comments... Date: Tue, 24 Feb 2004 10:55:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Comments on PANA-IPsec draft. > > This document assumes that the following have already happened before > > the IKE exchange starts. > ... > 4) PaC configures a routable or global address as discussed in > section 4 of this document. > > Well, that's not strictly accurate when we consider IP address > configuration during IKEv2. > Perhaps it can be reomved from that section. > After a successful authentication, the client configures a routable > or global address using [DHCP][DHCPV6] before running [IKE][IKEv2] or > > running address auto-configuration methods available within [IKE] or > > [IKEv2] by using a configuration payload or running DHCP over a > special IPsec tunnel mode SA [RFC3456] or auto-configures an address > > using stateless auto-configuration [IPv6-ND] before running [IKE] or > > [IKEv2] if IPv6 is being used. > > This text is a bit hard to follow... > > - IPv6 address autoconf, DHCP, and DHCPv6 can (and normally would) > happen even before PANA. > - RFC3456 and IKEv2 configurations would happen after PANA. > Will open an issue on this one. > > In IPv4, all packets are tunneled > using IPsec tunnel mode SA with the inner and outer source address > same as the routable address. > > Is that the case even when the global IP address is configured via > IKEv2? > If we have to assume that the pre-PANA address will be unconfigured, then we have no choice. > > If the network chooses IPsec to secure the link between PaC and EP, > PAA should communicate the IKE pre-shared key, the link-local address > > of the PaC (in IPv6 only), routable address of the PaC and the PANA > session ID to EP before the IKE exchange begins. > > I don't think the routable address of PaC is delivered to EP... The > draft has a discussion on that in section 6.0 anyways. > In the cases where the address is known a priori, it is communicated so that the SPD entries can be setup. It also needs to send the Key-ID along with session ID and need to specify how both are communicated in the ID payload. Will open an issue on this one also.. > In the case of address configuration > using [RFC3456] or [IKE] [IKEV2] or [DHCP] [DHCPV6], EP can learn the > > address allocated to the client and hence setup the SPD before the > IKE exchange starts. > > The case for DHCP is different than the rfc3456 and IKE ones. In the > latter, the IP address configuration is part of the protocol executions, > hence EP can know the allocated address. In DHCP case, I guess the > assumption is that DHCP server/relay is co-located with the EP, hence EP > can learn the address indirectly. If that's the case, some explanation > in the I-D would be useful. > But we are already assuming EP and AR are co-located. Then how bad this assumption would be ? -mohan > 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 Tue Feb 24 16:28: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 QAA12072 for ; Tue, 24 Feb 2004 16:28: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 1Avk5w-0003O5-QE; Tue, 24 Feb 2004 16:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avk5U-0003M4-Ay for pana@optimus.ietf.org; Tue, 24 Feb 2004 16:27: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 QAA12017 for ; Tue, 24 Feb 2004 16:27:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avk5S-0004UW-00 for pana@ietf.org; Tue, 24 Feb 2004 16:27:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avk4X-0004Nz-00 for pana@ietf.org; Tue, 24 Feb 2004 16:26:34 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1Avk41-0004Ga-00 for pana@ietf.org; Tue, 24 Feb 2004 16:26:01 -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 <0HTL00109Y6IMH@mailout2.samsung.com> for pana@ietf.org; Wed, 25 Feb 2004 06:25:30 +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 <0HTL00I9OY6H2V@mailout2.samsung.com> for pana@ietf.org; Wed, 25 Feb 2004 06:25:29 +0900 (KST) Received: from Alperyegin ([105.144.32.84]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTL00JLXY6EZG@mmp1.samsung.com> for pana@ietf.org; Wed, 25 Feb 2004 06:25:29 +0900 (KST) Date: Tue, 24 Feb 2004 13:25:26 -0800 From: Alper Yegin Subject: RE: [Pana] NEW: [issue52] Details of double authentication In-reply-to: <20040221042053.GZ737@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <001a01c3fb1c$b9ac03a0$54209069@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.3 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 this scheme works even if the PAA does not advertise a list of > > ISPs. The PaC can still perform separate authentication. But I suspect > we > > assume PAA must advertise a NAP-info, or else this doesn't work. Right? > If > > so, we shall spell this out. Also, the assumption is that PAA belongs to > a > > single NAP, hence at most one NAP-info is included at any time. > > I think the current text in the second paragraph of Section 4.3 > already describes this. Right, it is implicitly there. That's fine. > > > > > - If the first round of EAP fails, and PaC does not want to continue, > what > > happens? Maybe we should add something to PBA to signal that. > > In the current design, there is no option for a PaC that has accepted > an offer from PAA to perform separate authentication in the discovery > and initial handshake phase to decline the 2nd round of EAP. If we > want to add the functionality to decline the 2nd round of EAP in this > case, we might use S-bit not only for the discovery and initial > handshake phase but also for the authenticatioin phase (i.e., When > S-bit is cleared in PBA message while it is set in PBR message, it > means that the PaC does not want to continue to 2nd EAP round). Or a separate, dedicated bit can be defined... > > > > > Same with PAA wishing to abort the session? Some indication in PBR can > be > > useful here. > > If the PAA aborts the session just because the 1st EAP round fails, > PaC cannot continue to the 2nd EAP round even if it wishes to do it. > I think PAA should not aborts the session once the PaC has accepted > the offer to perform NAP/ISP separate authentications. The actions to be taken when NAP auth fails/succeeds, and ISP auth fails/succeeds are left to the deployment. Along with this flexibility, I thought we should also allow the access network to abort the AAA when first round AAA fails. > > - Also Jari had these comments: > > > > Why is there no problem with the mitm attacks in the PANA > > authentication sequences, as there are in other EAP sequencing? > > ... > > JARI: (Substantial) If the two MSKs are not somehow cryptographically > > bound to each other, a mitm attack remains a possibility. See > > draft-puthenkulam-eap-binding-04.txt. > > The two MSKs (or AAA-Keys) should be cryptographically bound to each > other unless lower-layer is secured. When lower-layer is not secured, > the PANA-Auth-Request/Answer exchange for the second EAP round must be > protected with a MAC AVP. This means that the EAP method used in the > first EAP round must generate a AAA-Key. Alper > > Yoshihiro Ohba > > > > > Any thoughts on this? > > > > 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 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Feb 24 16:30: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 QAA12237 for ; Tue, 24 Feb 2004 16:30: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 1Avk7e-0003UC-1c for pana-archive@odin.ietf.org; Tue, 24 Feb 2004 16:29:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OLTkS3013400 for pana-archive@odin.ietf.org; Tue, 24 Feb 2004 16:29:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avk7d-0003U3-SO for pana-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 16:29: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 QAA12170 for ; Tue, 24 Feb 2004 16:29:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avk7c-0004jI-00 for pana-web-archive@ietf.org; Tue, 24 Feb 2004 16:29:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avk6W-0004cb-00 for pana-web-archive@ietf.org; Tue, 24 Feb 2004 16:28:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avk60-0004W2-00 for pana-web-archive@ietf.org; Tue, 24 Feb 2004 16:28:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avk5w-0003O5-QE; Tue, 24 Feb 2004 16:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avk5U-0003M4-Ay for pana@optimus.ietf.org; Tue, 24 Feb 2004 16:27: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 QAA12017 for ; Tue, 24 Feb 2004 16:27:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avk5S-0004UW-00 for pana@ietf.org; Tue, 24 Feb 2004 16:27:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avk4X-0004Nz-00 for pana@ietf.org; Tue, 24 Feb 2004 16:26:34 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1Avk41-0004Ga-00 for pana@ietf.org; Tue, 24 Feb 2004 16:26:01 -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 <0HTL00109Y6IMH@mailout2.samsung.com> for pana@ietf.org; Wed, 25 Feb 2004 06:25:30 +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 <0HTL00I9OY6H2V@mailout2.samsung.com> for pana@ietf.org; Wed, 25 Feb 2004 06:25:29 +0900 (KST) Received: from Alperyegin ([105.144.32.84]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTL00JLXY6EZG@mmp1.samsung.com> for pana@ietf.org; Wed, 25 Feb 2004 06:25:29 +0900 (KST) Date: Tue, 24 Feb 2004 13:25:26 -0800 From: Alper Yegin Subject: RE: [Pana] NEW: [issue52] Details of double authentication In-reply-to: <20040221042053.GZ737@steelhead> To: "'Yoshihiro Ohba'" Cc: pana@ietf.org Message-id: <001a01c3fb1c$b9ac03a0$54209069@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.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > - I guess this scheme works even if the PAA does not advertise a list of > > ISPs. The PaC can still perform separate authentication. But I suspect > we > > assume PAA must advertise a NAP-info, or else this doesn't work. Right? > If > > so, we shall spell this out. Also, the assumption is that PAA belongs to > a > > single NAP, hence at most one NAP-info is included at any time. > > I think the current text in the second paragraph of Section 4.3 > already describes this. Right, it is implicitly there. That's fine. > > > > > - If the first round of EAP fails, and PaC does not want to continue, > what > > happens? Maybe we should add something to PBA to signal that. > > In the current design, there is no option for a PaC that has accepted > an offer from PAA to perform separate authentication in the discovery > and initial handshake phase to decline the 2nd round of EAP. If we > want to add the functionality to decline the 2nd round of EAP in this > case, we might use S-bit not only for the discovery and initial > handshake phase but also for the authenticatioin phase (i.e., When > S-bit is cleared in PBA message while it is set in PBR message, it > means that the PaC does not want to continue to 2nd EAP round). Or a separate, dedicated bit can be defined... > > > > > Same with PAA wishing to abort the session? Some indication in PBR can > be > > useful here. > > If the PAA aborts the session just because the 1st EAP round fails, > PaC cannot continue to the 2nd EAP round even if it wishes to do it. > I think PAA should not aborts the session once the PaC has accepted > the offer to perform NAP/ISP separate authentications. The actions to be taken when NAP auth fails/succeeds, and ISP auth fails/succeeds are left to the deployment. Along with this flexibility, I thought we should also allow the access network to abort the AAA when first round AAA fails. > > - Also Jari had these comments: > > > > Why is there no problem with the mitm attacks in the PANA > > authentication sequences, as there are in other EAP sequencing? > > ... > > JARI: (Substantial) If the two MSKs are not somehow cryptographically > > bound to each other, a mitm attack remains a possibility. See > > draft-puthenkulam-eap-binding-04.txt. > > The two MSKs (or AAA-Keys) should be cryptographically bound to each > other unless lower-layer is secured. When lower-layer is not secured, > the PANA-Auth-Request/Answer exchange for the second EAP round must be > protected with a MAC AVP. This means that the EAP method used in the > first EAP round must generate a AAA-Key. Alper > > Yoshihiro Ohba > > > > > Any thoughts on this? > > > > 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 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Tue Feb 24 18:28: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 SAA16922 for ; Tue, 24 Feb 2004 18:28: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 1Avly5-000801-0c; Tue, 24 Feb 2004 18:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvlxU-0007zT-0r for pana@optimus.ietf.org; Tue, 24 Feb 2004 18:27: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 SAA16887 for ; Tue, 24 Feb 2004 18:27:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvlxR-0006Py-00 for pana@ietf.org; Tue, 24 Feb 2004 18:27:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvlwV-0006Li-00 for pana@ietf.org; Tue, 24 Feb 2004 18:26:24 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1Avlvu-0006CT-00 for pana@ietf.org; Tue, 24 Feb 2004 18:25:46 -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 <0HTM007013PWBP@mailout2.samsung.com> for pana@ietf.org; Wed, 25 Feb 2004 08:25:08 +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 <0HTM0007G3PVOE@mailout2.samsung.com> for pana@ietf.org; Wed, 25 Feb 2004 08:25:08 +0900 (KST) Received: from Alperyegin ([105.144.32.84]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTM00J0D3PTZG@mmp1.samsung.com> for pana@ietf.org; Wed, 25 Feb 2004 08:25:07 +0900 (KST) Date: Tue, 24 Feb 2004 15:25:05 -0800 From: Alper Yegin Subject: RE: [Pana] pana-ipsec-02 comments... In-reply-to: <009801c3fb07$d7978480$c91167c0@adithya> To: "'Mohan Parthasarathy'" , pana@ietf.org Message-id: <002901c3fb2d$706652c0$54209069@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.3 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 > > If the network chooses IPsec to secure the link between PaC and EP, > > PAA should communicate the IKE pre-shared key, the link-local address > > > > of the PaC (in IPv6 only), routable address of the PaC and the PANA > > session ID to EP before the IKE exchange begins. > > > > I don't think the routable address of PaC is delivered to EP... The > > draft has a discussion on that in section 6.0 anyways. > > > In the cases where the address is known a priori, it is communicated so > that > the SPD entries can be setup. Which case is that? It is not when the routable address is configured via: - IKEv2, - rfc3456, - stateless autoconf, or - dhcpv6 Maybe when PaC uses static IP or DHCPv4... This is when PRPA is a globally routable address, and PAA learns this address prior to talking to EP. > It also needs to send the Key-ID along with > session ID and need to specify how both are communicated in the ID payload. > Will open an issue on this one also.. > > > > In the case of address configuration > > using [RFC3456] or [IKE] [IKEV2] or [DHCP] [DHCPV6], EP can learn the > > > > address allocated to the client and hence setup the SPD before the > > IKE exchange starts. > > > > The case for DHCP is different than the rfc3456 and IKE ones. In the > > latter, the IP address configuration is part of the protocol executions, > > hence EP can know the allocated address. In DHCP case, I guess the > > assumption is that DHCP server/relay is co-located with the EP, hence EP > > can learn the address indirectly. If that's the case, some explanation > > in the I-D would be useful. > > > But we are already assuming EP and AR are co-located. Then how bad > this assumption would be ? I wasn't thinking in terms of validity of this assumption. Just suggesting that we document it in the I-D. Alper > > -mohan > > > 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 Feb 24 18:29: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 SAA16995 for ; Tue, 24 Feb 2004 18:29: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 1AvlzL-00083R-35 for pana-archive@odin.ietf.org; Tue, 24 Feb 2004 18:29:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ONTJ21030960 for pana-archive@odin.ietf.org; Tue, 24 Feb 2004 18:29:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvlzK-00083D-K0 for pana-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 18:29:18 -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 SAA16992 for ; Tue, 24 Feb 2004 18:29:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvlzH-0006X6-00 for pana-web-archive@ietf.org; Tue, 24 Feb 2004 18:29:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvlyK-0006Tj-00 for pana-web-archive@ietf.org; Tue, 24 Feb 2004 18:28:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avly7-0006QI-00 for pana-web-archive@ietf.org; Tue, 24 Feb 2004 18:28:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avly5-000801-0c; Tue, 24 Feb 2004 18:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvlxU-0007zT-0r for pana@optimus.ietf.org; Tue, 24 Feb 2004 18:27: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 SAA16887 for ; Tue, 24 Feb 2004 18:27:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvlxR-0006Py-00 for pana@ietf.org; Tue, 24 Feb 2004 18:27:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvlwV-0006Li-00 for pana@ietf.org; Tue, 24 Feb 2004 18:26:24 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1Avlvu-0006CT-00 for pana@ietf.org; Tue, 24 Feb 2004 18:25:46 -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 <0HTM007013PWBP@mailout2.samsung.com> for pana@ietf.org; Wed, 25 Feb 2004 08:25:08 +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 <0HTM0007G3PVOE@mailout2.samsung.com> for pana@ietf.org; Wed, 25 Feb 2004 08:25:08 +0900 (KST) Received: from Alperyegin ([105.144.32.84]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTM00J0D3PTZG@mmp1.samsung.com> for pana@ietf.org; Wed, 25 Feb 2004 08:25:07 +0900 (KST) Date: Tue, 24 Feb 2004 15:25:05 -0800 From: Alper Yegin Subject: RE: [Pana] pana-ipsec-02 comments... In-reply-to: <009801c3fb07$d7978480$c91167c0@adithya> To: "'Mohan Parthasarathy'" , pana@ietf.org Message-id: <002901c3fb2d$706652c0$54209069@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.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > If the network chooses IPsec to secure the link between PaC and EP, > > PAA should communicate the IKE pre-shared key, the link-local address > > > > of the PaC (in IPv6 only), routable address of the PaC and the PANA > > session ID to EP before the IKE exchange begins. > > > > I don't think the routable address of PaC is delivered to EP... The > > draft has a discussion on that in section 6.0 anyways. > > > In the cases where the address is known a priori, it is communicated so > that > the SPD entries can be setup. Which case is that? It is not when the routable address is configured via: - IKEv2, - rfc3456, - stateless autoconf, or - dhcpv6 Maybe when PaC uses static IP or DHCPv4... This is when PRPA is a globally routable address, and PAA learns this address prior to talking to EP. > It also needs to send the Key-ID along with > session ID and need to specify how both are communicated in the ID payload. > Will open an issue on this one also.. > > > > In the case of address configuration > > using [RFC3456] or [IKE] [IKEV2] or [DHCP] [DHCPV6], EP can learn the > > > > address allocated to the client and hence setup the SPD before the > > IKE exchange starts. > > > > The case for DHCP is different than the rfc3456 and IKE ones. In the > > latter, the IP address configuration is part of the protocol executions, > > hence EP can know the allocated address. In DHCP case, I guess the > > assumption is that DHCP server/relay is co-located with the EP, hence EP > > can learn the address indirectly. If that's the case, some explanation > > in the I-D would be useful. > > > But we are already assuming EP and AR are co-located. Then how bad > this assumption would be ? I wasn't thinking in terms of validity of this assumption. Just suggesting that we document it in the I-D. Alper > > -mohan > > > 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 Tue Feb 24 23: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 XAA26006 for ; Tue, 24 Feb 2004 23: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 1AvqdQ-0007tn-Ol; Tue, 24 Feb 2004 23: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 1Avqcw-0007sT-0p for pana@optimus.ietf.org; Tue, 24 Feb 2004 23: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 XAA25969 for ; Tue, 24 Feb 2004 23:26:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avqcu-0007Gq-00 for pana@ietf.org; Tue, 24 Feb 2004 23:26:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avqbw-0007Ch-00 for pana@ietf.org; Tue, 24 Feb 2004 23:25:29 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AvqbU-00078h-00 for pana@ietf.org; Tue, 24 Feb 2004 23:25:00 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1P4Om89029931; Wed, 25 Feb 2004 13:24:48 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1P4Omqh023246; Wed, 25 Feb 2004 13:24:48 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id PAA23242 ; Wed, 25 Feb 2004 13:24:47 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id NAA11002; Wed, 25 Feb 2004 13:24:47 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id NAA05713; Wed, 25 Feb 2004 13:24:47 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1P4OkKv021897; Wed, 25 Feb 2004 13:24:46 +0900 (JST) Received: from steelhead ([159.119.168.70]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HTM00ADHHL8ZC@tsbpo1.po.toshiba.co.jp>; Wed, 25 Feb 2004 13:24:45 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AvoPk-0005DN-00; Tue, 24 Feb 2004 18:04:44 -0800 Date: Tue, 24 Feb 2004 18:04:44 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] pana-ipsec-02 comments... In-reply-to: <009801c3fb07$d7978480$c91167c0@adithya> To: Mohan Parthasarathy Cc: Alper Yegin , pana@ietf.org Message-id: <20040225020443.GI10963@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <001e01c3fa8e$82bf48e0$54209069@sisa.samsung.com> <009801c3fb07$d7978480$c91167c0@adithya> 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: , Hi Mohan, I have some comments (please see below). On Tue, Feb 24, 2004 at 10:55:59AM -0800, Mohan Parthasarathy wrote: > > > Comments on PANA-IPsec draft. > > > > This document assumes that the following have already happened before > > > > the IKE exchange starts. > > ... > > 4) PaC configures a routable or global address as discussed in > > section 4 of this document. > > > > Well, that's not strictly accurate when we consider IP address > > configuration during IKEv2. > > > Perhaps it can be reomved from that section. > > > After a successful authentication, the client configures a routable > > or global address using [DHCP][DHCPV6] before running [IKE][IKEv2] or > > > > running address auto-configuration methods available within [IKE] or > > > > [IKEv2] by using a configuration payload or running DHCP over a > > special IPsec tunnel mode SA [RFC3456] or auto-configures an address > > > > using stateless auto-configuration [IPv6-ND] before running [IKE] or > > > > [IKEv2] if IPv6 is being used. > > > > This text is a bit hard to follow... > > > > - IPv6 address autoconf, DHCP, and DHCPv6 can (and normally would) > > happen even before PANA. > > - RFC3456 and IKEv2 configurations would happen after PANA. > > > Will open an issue on this one. > > > > > In IPv4, all packets are tunneled > > using IPsec tunnel mode SA with the inner and outer source address > > same as the routable address. > > > > Is that the case even when the global IP address is configured via > > IKEv2? > > > If we have to assume that the pre-PANA address will be unconfigured, > then we have no choice. > > > > > If the network chooses IPsec to secure the link between PaC and EP, > > PAA should communicate the IKE pre-shared key, the link-local address > > > > of the PaC (in IPv6 only), routable address of the PaC and the PANA > > session ID to EP before the IKE exchange begins. > > > > I don't think the routable address of PaC is delivered to EP... The > > draft has a discussion on that in section 6.0 anyways. > > > In the cases where the address is known a priori, it is communicated so that > the SPD entries can be setup. Since the address is not always known a priori, carrying the routable address only when the address is known a priori is not much useful. Also, delivering the routable address from PAA to EP is not consistent with the design policy of staying away from inner address authorization. > It also needs to send the Key-ID along with > session ID and need to specify how both are communicated in the ID payload. > Will open an issue on this one also.. > > > > In the case of address configuration > > using [RFC3456] or [IKE] [IKEV2] or [DHCP] [DHCPV6], EP can learn the > > > > address allocated to the client and hence setup the SPD before the > > IKE exchange starts. > > > > The case for DHCP is different than the rfc3456 and IKE ones. In the > > latter, the IP address configuration is part of the protocol executions, > > hence EP can know the allocated address. In DHCP case, I guess the > > assumption is that DHCP server/relay is co-located with the EP, hence EP > > can learn the address indirectly. If that's the case, some explanation > > in the I-D would be useful. > > > But we are already assuming EP and AR are co-located. Then how bad > this assumption would be ? DHCP server/relay may be separated from EP and AR. In addition, I think that the DHCP case and auto-configuration case are the same in that EP may not be able to setup the SPD entries before IKE exchange starts. Yoshihiro Ohba > > -mohan > > > 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 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Tue Feb 24 23:29:03 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 XAA26057 for ; Tue, 24 Feb 2004 23:29:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avqew-0007y9-70 for pana-archive@odin.ietf.org; Tue, 24 Feb 2004 23:28:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P4SYIw030627 for pana-archive@odin.ietf.org; Tue, 24 Feb 2004 23:28:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avqew-0007xu-0N for pana-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 23:28: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 XAA26053 for ; Tue, 24 Feb 2004 23:28:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avqeu-0007Rx-00 for pana-web-archive@ietf.org; Tue, 24 Feb 2004 23:28:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avqdz-0007NA-00 for pana-web-archive@ietf.org; Tue, 24 Feb 2004 23:27:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvqdV-0007I9-00 for pana-web-archive@ietf.org; Tue, 24 Feb 2004 23: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 1AvqdQ-0007tn-Ol; Tue, 24 Feb 2004 23: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 1Avqcw-0007sT-0p for pana@optimus.ietf.org; Tue, 24 Feb 2004 23: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 XAA25969 for ; Tue, 24 Feb 2004 23:26:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avqcu-0007Gq-00 for pana@ietf.org; Tue, 24 Feb 2004 23:26:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avqbw-0007Ch-00 for pana@ietf.org; Tue, 24 Feb 2004 23:25:29 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AvqbU-00078h-00 for pana@ietf.org; Tue, 24 Feb 2004 23:25:00 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1P4Om89029931; Wed, 25 Feb 2004 13:24:48 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1P4Omqh023246; Wed, 25 Feb 2004 13:24:48 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id PAA23242 ; Wed, 25 Feb 2004 13:24:47 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id NAA11002; Wed, 25 Feb 2004 13:24:47 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id NAA05713; Wed, 25 Feb 2004 13:24:47 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1P4OkKv021897; Wed, 25 Feb 2004 13:24:46 +0900 (JST) Received: from steelhead ([159.119.168.70]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HTM00ADHHL8ZC@tsbpo1.po.toshiba.co.jp>; Wed, 25 Feb 2004 13:24:45 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AvoPk-0005DN-00; Tue, 24 Feb 2004 18:04:44 -0800 Date: Tue, 24 Feb 2004 18:04:44 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] pana-ipsec-02 comments... In-reply-to: <009801c3fb07$d7978480$c91167c0@adithya> To: Mohan Parthasarathy Cc: Alper Yegin , pana@ietf.org Message-id: <20040225020443.GI10963@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <001e01c3fa8e$82bf48e0$54209069@sisa.samsung.com> <009801c3fb07$d7978480$c91167c0@adithya> 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 Hi Mohan, I have some comments (please see below). On Tue, Feb 24, 2004 at 10:55:59AM -0800, Mohan Parthasarathy wrote: > > > Comments on PANA-IPsec draft. > > > > This document assumes that the following have already happened before > > > > the IKE exchange starts. > > ... > > 4) PaC configures a routable or global address as discussed in > > section 4 of this document. > > > > Well, that's not strictly accurate when we consider IP address > > configuration during IKEv2. > > > Perhaps it can be reomved from that section. > > > After a successful authentication, the client configures a routable > > or global address using [DHCP][DHCPV6] before running [IKE][IKEv2] or > > > > running address auto-configuration methods available within [IKE] or > > > > [IKEv2] by using a configuration payload or running DHCP over a > > special IPsec tunnel mode SA [RFC3456] or auto-configures an address > > > > using stateless auto-configuration [IPv6-ND] before running [IKE] or > > > > [IKEv2] if IPv6 is being used. > > > > This text is a bit hard to follow... > > > > - IPv6 address autoconf, DHCP, and DHCPv6 can (and normally would) > > happen even before PANA. > > - RFC3456 and IKEv2 configurations would happen after PANA. > > > Will open an issue on this one. > > > > > In IPv4, all packets are tunneled > > using IPsec tunnel mode SA with the inner and outer source address > > same as the routable address. > > > > Is that the case even when the global IP address is configured via > > IKEv2? > > > If we have to assume that the pre-PANA address will be unconfigured, > then we have no choice. > > > > > If the network chooses IPsec to secure the link between PaC and EP, > > PAA should communicate the IKE pre-shared key, the link-local address > > > > of the PaC (in IPv6 only), routable address of the PaC and the PANA > > session ID to EP before the IKE exchange begins. > > > > I don't think the routable address of PaC is delivered to EP... The > > draft has a discussion on that in section 6.0 anyways. > > > In the cases where the address is known a priori, it is communicated so that > the SPD entries can be setup. Since the address is not always known a priori, carrying the routable address only when the address is known a priori is not much useful. Also, delivering the routable address from PAA to EP is not consistent with the design policy of staying away from inner address authorization. > It also needs to send the Key-ID along with > session ID and need to specify how both are communicated in the ID payload. > Will open an issue on this one also.. > > > > In the case of address configuration > > using [RFC3456] or [IKE] [IKEV2] or [DHCP] [DHCPV6], EP can learn the > > > > address allocated to the client and hence setup the SPD before the > > IKE exchange starts. > > > > The case for DHCP is different than the rfc3456 and IKE ones. In the > > latter, the IP address configuration is part of the protocol executions, > > hence EP can know the allocated address. In DHCP case, I guess the > > assumption is that DHCP server/relay is co-located with the EP, hence EP > > can learn the address indirectly. If that's the case, some explanation > > in the I-D would be useful. > > > But we are already assuming EP and AR are co-located. Then how bad > this assumption would be ? DHCP server/relay may be separated from EP and AR. In addition, I think that the DHCP case and auto-configuration case are the same in that EP may not be able to setup the SPD entries before IKE exchange starts. Yoshihiro Ohba > > -mohan > > > 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 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Feb 25 11:39: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 LAA27788 for ; Wed, 25 Feb 2004 11:39: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 1Aw23q-0008Ar-0J; Wed, 25 Feb 2004 11:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw23e-0008AN-Sf for pana@optimus.ietf.org; Wed, 25 Feb 2004 11:38: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 LAA27780 for ; Wed, 25 Feb 2004 11:38:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw23d-0005vL-00 for pana@ietf.org; Wed, 25 Feb 2004 11:38:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw22l-0005qN-00 for pana@ietf.org; Wed, 25 Feb 2004 11:37:56 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Aw21r-0005kn-00 for pana@ietf.org; Wed, 25 Feb 2004 11:36:59 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1PGau89025284; Thu, 26 Feb 2004 01:36:56 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1PGauNA014743; Thu, 26 Feb 2004 01:36:56 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA14742 ; Thu, 26 Feb 2004 01:36:56 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA26175; Thu, 26 Feb 2004 01:36:56 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA22124; Thu, 26 Feb 2004 01:36:55 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1PGasKv022292; Thu, 26 Feb 2004 01:36:55 +0900 (JST) Received: from steelhead ([159.119.168.172]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HTN0080BFHHUN@tsbpo1.po.toshiba.co.jp>; Thu, 26 Feb 2004 01:36:53 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Avs2y-0005Nh-00; Tue, 24 Feb 2004 21:57:28 -0800 Date: Tue, 24 Feb 2004 21:57:28 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue52] Details of double authentication In-reply-to: <001a01c3fb1c$b9ac03a0$54209069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040225055728.GF20356@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: <20040221042053.GZ737@steelhead> <001a01c3fb1c$b9ac03a0$54209069@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_06_12 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, Feb 24, 2004 at 01:25:26PM -0800, Alper Yegin wrote: > > > > > > > > - If the first round of EAP fails, and PaC does not want to > continue, > > what > > > happens? Maybe we should add something to PBA to signal that. > > > > In the current design, there is no option for a PaC that has accepted > > an offer from PAA to perform separate authentication in the discovery > > and initial handshake phase to decline the 2nd round of EAP. If we > > want to add the functionality to decline the 2nd round of EAP in this > > case, we might use S-bit not only for the discovery and initial > > handshake phase but also for the authenticatioin phase (i.e., When > > S-bit is cleared in PBA message while it is set in PBR message, it > > means that the PaC does not want to continue to 2nd EAP round). > > Or a separate, dedicated bit can be defined... In the state machine, a variable SEPARATE controls whether to perform separate authentication and it is tied with S-bit. I think the same variable can be used for this scenario and using the same S-bit for changing the same variable seems reasonable to me. > > > > > > > > > Same with PAA wishing to abort the session? Some indication in PBR > can > > be > > > useful here. > > > > If the PAA aborts the session just because the 1st EAP round fails, > > PaC cannot continue to the 2nd EAP round even if it wishes to do it. > > I think PAA should not aborts the session once the PaC has accepted > > the offer to perform NAP/ISP separate authentications. > > The actions to be taken when NAP auth fails/succeeds, and ISP auth > fails/succeeds are left to the deployment. Along with this flexibility, > I thought we should also allow the access network to abort the AAA when > first round AAA fails. OK. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Feb 25 11:41: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 LAA27902 for ; Wed, 25 Feb 2004 11:41: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 1Aw25i-00006A-3o for pana-archive@odin.ietf.org; Wed, 25 Feb 2004 11:40:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PGewJK000379 for pana-archive@odin.ietf.org; Wed, 25 Feb 2004 11:40:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw25h-000062-O8 for pana-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 11:40: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 LAA27861 for ; Wed, 25 Feb 2004 11:40:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw25g-0006AJ-00 for pana-web-archive@ietf.org; Wed, 25 Feb 2004 11:40:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw24n-00063A-00 for pana-web-archive@ietf.org; Wed, 25 Feb 2004 11:40:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw23s-0005xQ-00 for pana-web-archive@ietf.org; Wed, 25 Feb 2004 11: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 1Aw23q-0008Ar-0J; Wed, 25 Feb 2004 11:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw23e-0008AN-Sf for pana@optimus.ietf.org; Wed, 25 Feb 2004 11:38: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 LAA27780 for ; Wed, 25 Feb 2004 11:38:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw23d-0005vL-00 for pana@ietf.org; Wed, 25 Feb 2004 11:38:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw22l-0005qN-00 for pana@ietf.org; Wed, 25 Feb 2004 11:37:56 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Aw21r-0005kn-00 for pana@ietf.org; Wed, 25 Feb 2004 11:36:59 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1PGau89025284; Thu, 26 Feb 2004 01:36:56 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1PGauNA014743; Thu, 26 Feb 2004 01:36:56 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA14742 ; Thu, 26 Feb 2004 01:36:56 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA26175; Thu, 26 Feb 2004 01:36:56 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA22124; Thu, 26 Feb 2004 01:36:55 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1PGasKv022292; Thu, 26 Feb 2004 01:36:55 +0900 (JST) Received: from steelhead ([159.119.168.172]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HTN0080BFHHUN@tsbpo1.po.toshiba.co.jp>; Thu, 26 Feb 2004 01:36:53 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Avs2y-0005Nh-00; Tue, 24 Feb 2004 21:57:28 -0800 Date: Tue, 24 Feb 2004 21:57:28 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] NEW: [issue52] Details of double authentication In-reply-to: <001a01c3fb1c$b9ac03a0$54209069@sisa.samsung.com> To: Alper Yegin Cc: "'Yoshihiro Ohba'" , pana@ietf.org Message-id: <20040225055728.GF20356@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: <20040221042053.GZ737@steelhead> <001a01c3fb1c$b9ac03a0$54209069@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_06_12 autolearn=no version=2.60 On Tue, Feb 24, 2004 at 01:25:26PM -0800, Alper Yegin wrote: > > > > > > > > - If the first round of EAP fails, and PaC does not want to > continue, > > what > > > happens? Maybe we should add something to PBA to signal that. > > > > In the current design, there is no option for a PaC that has accepted > > an offer from PAA to perform separate authentication in the discovery > > and initial handshake phase to decline the 2nd round of EAP. If we > > want to add the functionality to decline the 2nd round of EAP in this > > case, we might use S-bit not only for the discovery and initial > > handshake phase but also for the authenticatioin phase (i.e., When > > S-bit is cleared in PBA message while it is set in PBR message, it > > means that the PaC does not want to continue to 2nd EAP round). > > Or a separate, dedicated bit can be defined... In the state machine, a variable SEPARATE controls whether to perform separate authentication and it is tied with S-bit. I think the same variable can be used for this scenario and using the same S-bit for changing the same variable seems reasonable to me. > > > > > > > > > Same with PAA wishing to abort the session? Some indication in PBR > can > > be > > > useful here. > > > > If the PAA aborts the session just because the 1st EAP round fails, > > PaC cannot continue to the 2nd EAP round even if it wishes to do it. > > I think PAA should not aborts the session once the PaC has accepted > > the offer to perform NAP/ISP separate authentications. > > The actions to be taken when NAP auth fails/succeeds, and ISP auth > fails/succeeds are left to the deployment. Along with this flexibility, > I thought we should also allow the access network to abort the AAA when > first round AAA fails. OK. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Feb 25 14:09: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 OAA05743 for ; Wed, 25 Feb 2004 14:09: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 1Aw4Oz-0004lX-Jx; Wed, 25 Feb 2004 14:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4O3-0004eR-FX for pana@optimus.ietf.org; Wed, 25 Feb 2004 14:08: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 OAA05720 for ; Wed, 25 Feb 2004 14:08:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4O1-0006Am-00 for pana@ietf.org; Wed, 25 Feb 2004 14:08:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4N5-000663-00 for pana@ietf.org; Wed, 25 Feb 2004 14:07:03 -0500 Received: from smtp800.mail.sc5.yahoo.com ([66.163.168.179]) by ietf-mx with smtp (Exim 4.12) id 1Aw4MX-00061H-00 for pana@ietf.org; Wed, 25 Feb 2004 14:06:30 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.201 with login) by smtp800.mail.sc5.yahoo.com with SMTP; 25 Feb 2004 19:06:28 -0000 Message-ID: <008901c3fbd2$7a25d6f0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , References: <002901c3fb2d$706652c0$54209069@sisa.samsung.com> Subject: Re: [Pana] pana-ipsec-02 comments... Date: Wed, 25 Feb 2004 11:06:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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=none 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 > > > > If the network chooses IPsec to secure the link between PaC and > EP, > > > PAA should communicate the IKE pre-shared key, the link-local > address > > > > > > of the PaC (in IPv6 only), routable address of the PaC and the > PANA > > > session ID to EP before the IKE exchange begins. > > > > > > I don't think the routable address of PaC is delivered to EP... The > > > draft has a discussion on that in section 6.0 anyways. > > > > > In the cases where the address is known a priori, it is communicated > so > > that > > the SPD entries can be setup. > > Which case is that? It is not when the routable address is configured > via: > - IKEv2, > - rfc3456, > - stateless autoconf, or > - dhcpv6 > Agreed. > Maybe when PaC uses static IP or DHCPv4... This is when PRPA is a > globally routable address, and PAA learns this address prior to talking > to EP. > Yes. > > > It also needs to send the Key-ID along with > > session ID and need to specify how both are communicated in the ID > payload. > > Will open an issue on this one also.. > > > > > > > In the case of address configuration > > > using [RFC3456] or [IKE] [IKEV2] or [DHCP] [DHCPV6], EP can learn > the > > > > > > address allocated to the client and hence setup the SPD before > the > > > IKE exchange starts. > > > > > > The case for DHCP is different than the rfc3456 and IKE ones. In the > > > latter, the IP address configuration is part of the protocol > executions, > > > hence EP can know the allocated address. In DHCP case, I guess the > > > assumption is that DHCP server/relay is co-located with the EP, > hence EP > > > can learn the address indirectly. If that's the case, some > explanation > > > in the I-D would be useful. > > > > > But we are already assuming EP and AR are co-located. Then how bad > > this assumption would be ? > > I wasn't thinking in terms of validity of this assumption. Just > suggesting that we document it in the I-D. > Ok. -mohan > Alper > > > > > -mohan > > > > > 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 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Feb 25 14:11: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 OAA05802 for ; Wed, 25 Feb 2004 14:11: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 1Aw4Qt-0004q9-7E for pana-archive@odin.ietf.org; Wed, 25 Feb 2004 14:10:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PJAxll018595 for pana-archive@odin.ietf.org; Wed, 25 Feb 2004 14:10:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4Qr-0004pq-RD for pana-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 14:10: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 OAA05788 for ; Wed, 25 Feb 2004 14:10:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4Qp-0006Os-00 for pana-web-archive@ietf.org; Wed, 25 Feb 2004 14:10:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4Pu-0006KG-00 for pana-web-archive@ietf.org; Wed, 25 Feb 2004 14:09:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4Oz-0006G0-00 for pana-web-archive@ietf.org; Wed, 25 Feb 2004 14:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4Oz-0004lX-Jx; Wed, 25 Feb 2004 14:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4O3-0004eR-FX for pana@optimus.ietf.org; Wed, 25 Feb 2004 14:08: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 OAA05720 for ; Wed, 25 Feb 2004 14:08:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4O1-0006Am-00 for pana@ietf.org; Wed, 25 Feb 2004 14:08:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4N5-000663-00 for pana@ietf.org; Wed, 25 Feb 2004 14:07:03 -0500 Received: from smtp800.mail.sc5.yahoo.com ([66.163.168.179]) by ietf-mx with smtp (Exim 4.12) id 1Aw4MX-00061H-00 for pana@ietf.org; Wed, 25 Feb 2004 14:06:30 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.201 with login) by smtp800.mail.sc5.yahoo.com with SMTP; 25 Feb 2004 19:06:28 -0000 Message-ID: <008901c3fbd2$7a25d6f0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , References: <002901c3fb2d$706652c0$54209069@sisa.samsung.com> Subject: Re: [Pana] pana-ipsec-02 comments... Date: Wed, 25 Feb 2004 11:06:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > > If the network chooses IPsec to secure the link between PaC and > EP, > > > PAA should communicate the IKE pre-shared key, the link-local > address > > > > > > of the PaC (in IPv6 only), routable address of the PaC and the > PANA > > > session ID to EP before the IKE exchange begins. > > > > > > I don't think the routable address of PaC is delivered to EP... The > > > draft has a discussion on that in section 6.0 anyways. > > > > > In the cases where the address is known a priori, it is communicated > so > > that > > the SPD entries can be setup. > > Which case is that? It is not when the routable address is configured > via: > - IKEv2, > - rfc3456, > - stateless autoconf, or > - dhcpv6 > Agreed. > Maybe when PaC uses static IP or DHCPv4... This is when PRPA is a > globally routable address, and PAA learns this address prior to talking > to EP. > Yes. > > > It also needs to send the Key-ID along with > > session ID and need to specify how both are communicated in the ID > payload. > > Will open an issue on this one also.. > > > > > > > In the case of address configuration > > > using [RFC3456] or [IKE] [IKEV2] or [DHCP] [DHCPV6], EP can learn > the > > > > > > address allocated to the client and hence setup the SPD before > the > > > IKE exchange starts. > > > > > > The case for DHCP is different than the rfc3456 and IKE ones. In the > > > latter, the IP address configuration is part of the protocol > executions, > > > hence EP can know the allocated address. In DHCP case, I guess the > > > assumption is that DHCP server/relay is co-located with the EP, > hence EP > > > can learn the address indirectly. If that's the case, some > explanation > > > in the I-D would be useful. > > > > > But we are already assuming EP and AR are co-located. Then how bad > > this assumption would be ? > > I wasn't thinking in terms of validity of this assumption. Just > suggesting that we document it in the I-D. > Ok. -mohan > Alper > > > > > -mohan > > > > > 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 _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Feb 25 14:12: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 OAA05841 for ; Wed, 25 Feb 2004 14:12: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 1Aw4Ru-0004ry-0T; Wed, 25 Feb 2004 14:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4Rs-0004rd-F8 for pana@optimus.ietf.org; Wed, 25 Feb 2004 14:12:00 -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 OAA05835 for ; Wed, 25 Feb 2004 14:11:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4Rq-0006Ui-00 for pana@ietf.org; Wed, 25 Feb 2004 14:11:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4Qv-0006Pt-00 for pana@ietf.org; Wed, 25 Feb 2004 14:11:02 -0500 Received: from smtp805.mail.sc5.yahoo.com ([66.163.168.184]) by ietf-mx with smtp (Exim 4.12) id 1Aw4Qa-0006LC-00 for pana@ietf.org; Wed, 25 Feb 2004 14:10:40 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.201 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 25 Feb 2004 19:10:39 -0000 Message-ID: <009301c3fbd3$0fac30c0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Alper Yegin" , References: <001e01c3fa8e$82bf48e0$54209069@sisa.samsung.com> <009801c3fb07$d7978480$c91167c0@adithya> <20040225020443.GI10963@steelhead> Subject: Re: [Pana] pana-ipsec-02 comments... Date: Wed, 25 Feb 2004 11:10:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit 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=none 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 Mohan, > > I have some comments (please see below). > > On Tue, Feb 24, 2004 at 10:55:59AM -0800, Mohan Parthasarathy wrote: > > > > > Comments on PANA-IPsec draft. > > > > > > This document assumes that the following have already happened before > > > > > > the IKE exchange starts. > > > ... > > > 4) PaC configures a routable or global address as discussed in > > > section 4 of this document. > > > > > > Well, that's not strictly accurate when we consider IP address > > > configuration during IKEv2. > > > > > Perhaps it can be reomved from that section. > > > > > After a successful authentication, the client configures a routable > > > or global address using [DHCP][DHCPV6] before running [IKE][IKEv2] or > > > > > > running address auto-configuration methods available within [IKE] or > > > > > > [IKEv2] by using a configuration payload or running DHCP over a > > > special IPsec tunnel mode SA [RFC3456] or auto-configures an address > > > > > > using stateless auto-configuration [IPv6-ND] before running [IKE] or > > > > > > [IKEv2] if IPv6 is being used. > > > > > > This text is a bit hard to follow... > > > > > > - IPv6 address autoconf, DHCP, and DHCPv6 can (and normally would) > > > happen even before PANA. > > > - RFC3456 and IKEv2 configurations would happen after PANA. > > > > > Will open an issue on this one. > > > > > > > > In IPv4, all packets are tunneled > > > using IPsec tunnel mode SA with the inner and outer source address > > > same as the routable address. > > > > > > Is that the case even when the global IP address is configured via > > > IKEv2? > > > > > If we have to assume that the pre-PANA address will be unconfigured, > > then we have no choice. > > > > > > > > If the network chooses IPsec to secure the link between PaC and EP, > > > PAA should communicate the IKE pre-shared key, the link-local address > > > > > > of the PaC (in IPv6 only), routable address of the PaC and the PANA > > > session ID to EP before the IKE exchange begins. > > > > > > I don't think the routable address of PaC is delivered to EP... The > > > draft has a discussion on that in section 6.0 anyways. > > > > > In the cases where the address is known a priori, it is communicated so that > > the SPD entries can be setup. > > Since the address is not always known a priori, carrying the routable > address only when the address is known a priori is not much useful. > Also, delivering the routable address from PAA to EP is not consistent > with the design policy of staying away from inner address > authorization. > Okay, i will remove it in the next version. > > It also needs to send the Key-ID along with > > session ID and need to specify how both are communicated in the ID payload. > > Will open an issue on this one also.. > > > > > > > In the case of address configuration > > > using [RFC3456] or [IKE] [IKEV2] or [DHCP] [DHCPV6], EP can learn the > > > > > > address allocated to the client and hence setup the SPD before the > > > IKE exchange starts. > > > > > > The case for DHCP is different than the rfc3456 and IKE ones. In the > > > latter, the IP address configuration is part of the protocol executions, > > > hence EP can know the allocated address. In DHCP case, I guess the > > > assumption is that DHCP server/relay is co-located with the EP, hence EP > > > can learn the address indirectly. If that's the case, some explanation > > > in the I-D would be useful. > > > > > But we are already assuming EP and AR are co-located. Then how bad > > this assumption would be ? > > DHCP server/relay may be separated from EP and AR. In addition, I How is this possible ? Either DHCP server or the relay has to be on the first IP hop and if it is not AR or EP, where can it be ? > think that the DHCP case and auto-configuration case are the same in > that EP may not be able to setup the SPD entries before IKE exchange > starts. > Agreed. But EP can verify whether the given client can use a given address or not in the case of DHCP as it can learn which address was given to the PaC assuming EP (and AR is co-located) is in the path of DHCP messages. -mohan > Yoshihiro Ohba > > > > > > > -mohan > > > > > 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 > > _______________________________________________ > 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 Feb 25 14:14: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 OAA06025 for ; Wed, 25 Feb 2004 14:14: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 1Aw4Tn-0004yO-1K for pana-archive@odin.ietf.org; Wed, 25 Feb 2004 14:13:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PJDwRX019110 for pana-archive@odin.ietf.org; Wed, 25 Feb 2004 14:13:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4Tm-0004y5-Iw for pana-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 14:13: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 OAA05921 for ; Wed, 25 Feb 2004 14:13:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4Tk-0006j5-00 for pana-web-archive@ietf.org; Wed, 25 Feb 2004 14:13:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4Sq-0006bl-00 for pana-web-archive@ietf.org; Wed, 25 Feb 2004 14:13:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4Rw-0006Vj-00 for pana-web-archive@ietf.org; Wed, 25 Feb 2004 14:12:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4Ru-0004ry-0T; Wed, 25 Feb 2004 14:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4Rs-0004rd-F8 for pana@optimus.ietf.org; Wed, 25 Feb 2004 14:12:00 -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 OAA05835 for ; Wed, 25 Feb 2004 14:11:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4Rq-0006Ui-00 for pana@ietf.org; Wed, 25 Feb 2004 14:11:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4Qv-0006Pt-00 for pana@ietf.org; Wed, 25 Feb 2004 14:11:02 -0500 Received: from smtp805.mail.sc5.yahoo.com ([66.163.168.184]) by ietf-mx with smtp (Exim 4.12) id 1Aw4Qa-0006LC-00 for pana@ietf.org; Wed, 25 Feb 2004 14:10:40 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.201 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 25 Feb 2004 19:10:39 -0000 Message-ID: <009301c3fbd3$0fac30c0$c91167c0@adithya> From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: "Alper Yegin" , References: <001e01c3fa8e$82bf48e0$54209069@sisa.samsung.com> <009801c3fb07$d7978480$c91167c0@adithya> <20040225020443.GI10963@steelhead> Subject: Re: [Pana] pana-ipsec-02 comments... Date: Wed, 25 Feb 2004 11:10:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit 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: 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=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Hi Mohan, > > I have some comments (please see below). > > On Tue, Feb 24, 2004 at 10:55:59AM -0800, Mohan Parthasarathy wrote: > > > > > Comments on PANA-IPsec draft. > > > > > > This document assumes that the following have already happened before > > > > > > the IKE exchange starts. > > > ... > > > 4) PaC configures a routable or global address as discussed in > > > section 4 of this document. > > > > > > Well, that's not strictly accurate when we consider IP address > > > configuration during IKEv2. > > > > > Perhaps it can be reomved from that section. > > > > > After a successful authentication, the client configures a routable > > > or global address using [DHCP][DHCPV6] before running [IKE][IKEv2] or > > > > > > running address auto-configuration methods available within [IKE] or > > > > > > [IKEv2] by using a configuration payload or running DHCP over a > > > special IPsec tunnel mode SA [RFC3456] or auto-configures an address > > > > > > using stateless auto-configuration [IPv6-ND] before running [IKE] or > > > > > > [IKEv2] if IPv6 is being used. > > > > > > This text is a bit hard to follow... > > > > > > - IPv6 address autoconf, DHCP, and DHCPv6 can (and normally would) > > > happen even before PANA. > > > - RFC3456 and IKEv2 configurations would happen after PANA. > > > > > Will open an issue on this one. > > > > > > > > In IPv4, all packets are tunneled > > > using IPsec tunnel mode SA with the inner and outer source address > > > same as the routable address. > > > > > > Is that the case even when the global IP address is configured via > > > IKEv2? > > > > > If we have to assume that the pre-PANA address will be unconfigured, > > then we have no choice. > > > > > > > > If the network chooses IPsec to secure the link between PaC and EP, > > > PAA should communicate the IKE pre-shared key, the link-local address > > > > > > of the PaC (in IPv6 only), routable address of the PaC and the PANA > > > session ID to EP before the IKE exchange begins. > > > > > > I don't think the routable address of PaC is delivered to EP... The > > > draft has a discussion on that in section 6.0 anyways. > > > > > In the cases where the address is known a priori, it is communicated so that > > the SPD entries can be setup. > > Since the address is not always known a priori, carrying the routable > address only when the address is known a priori is not much useful. > Also, delivering the routable address from PAA to EP is not consistent > with the design policy of staying away from inner address > authorization. > Okay, i will remove it in the next version. > > It also needs to send the Key-ID along with > > session ID and need to specify how both are communicated in the ID payload. > > Will open an issue on this one also.. > > > > > > > In the case of address configuration > > > using [RFC3456] or [IKE] [IKEV2] or [DHCP] [DHCPV6], EP can learn the > > > > > > address allocated to the client and hence setup the SPD before the > > > IKE exchange starts. > > > > > > The case for DHCP is different than the rfc3456 and IKE ones. In the > > > latter, the IP address configuration is part of the protocol executions, > > > hence EP can know the allocated address. In DHCP case, I guess the > > > assumption is that DHCP server/relay is co-located with the EP, hence EP > > > can learn the address indirectly. If that's the case, some explanation > > > in the I-D would be useful. > > > > > But we are already assuming EP and AR are co-located. Then how bad > > this assumption would be ? > > DHCP server/relay may be separated from EP and AR. In addition, I How is this possible ? Either DHCP server or the relay has to be on the first IP hop and if it is not AR or EP, where can it be ? > think that the DHCP case and auto-configuration case are the same in > that EP may not be able to setup the SPD entries before IKE exchange > starts. > Agreed. But EP can verify whether the given client can use a given address or not in the case of DHCP as it can learn which address was given to the PaC assuming EP (and AR is co-located) is in the path of DHCP messages. -mohan > Yoshihiro Ohba > > > > > > > -mohan > > > > > 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 > > _______________________________________________ > 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 Feb 25 14:27: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 OAA06868 for ; Wed, 25 Feb 2004 14:27: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 1Aw4gP-00068f-Fw; Wed, 25 Feb 2004 14: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 1Aw4fW-00061y-TB for pana@optimus.ietf.org; Wed, 25 Feb 2004 14:26: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 OAA06783 for ; Wed, 25 Feb 2004 14:26:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4fU-0000O5-00 for pana@ietf.org; Wed, 25 Feb 2004 14:26:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4eY-0000J7-00 for pana@ietf.org; Wed, 25 Feb 2004 14:25:06 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4dw-0000Dm-00 for pana@ietf.org; Wed, 25 Feb 2004 14:24:28 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1PJOQ89029886; Thu, 26 Feb 2004 04:24:26 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1PJOQS2028192; Thu, 26 Feb 2004 04:24:26 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA28191 ; Thu, 26 Feb 2004 04:24:26 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA21231; Thu, 26 Feb 2004 04:24:25 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA01865; Thu, 26 Feb 2004 04:24:25 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1PJONKv029468; Thu, 26 Feb 2004 04:24:24 +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 <0HTN00D0XN8L9T@tsbpo1.po.toshiba.co.jp>; Thu, 26 Feb 2004 04:24:23 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AvtVn-0005Yi-00; Tue, 24 Feb 2004 23:31:19 -0800 Date: Tue, 24 Feb 2004 23:31:18 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] pana-ipsec-02 comments... In-reply-to: <009301c3fbd3$0fac30c0$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040225073118.GJ20356@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <001e01c3fa8e$82bf48e0$54209069@sisa.samsung.com> <009801c3fb07$d7978480$c91167c0@adithya> <20040225020443.GI10963@steelhead> <009301c3fbd3$0fac30c0$c91167c0@adithya> 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 Wed, Feb 25, 2004 at 11:10:41AM -0800, Mohan Parthasarathy wrote: > > > > In the case of address configuration > > > > using [RFC3456] or [IKE] [IKEV2] or [DHCP] [DHCPV6], EP can learn the > > > > > > > > address allocated to the client and hence setup the SPD before the > > > > IKE exchange starts. > > > > > > > > The case for DHCP is different than the rfc3456 and IKE ones. In the > > > > latter, the IP address configuration is part of the protocol executions, > > > > hence EP can know the allocated address. In DHCP case, I guess the > > > > assumption is that DHCP server/relay is co-located with the EP, hence EP > > > > can learn the address indirectly. If that's the case, some explanation > > > > in the I-D would be useful. > > > > > > > But we are already assuming EP and AR are co-located. Then how bad > > > this assumption would be ? > > > > DHCP server/relay may be separated from EP and AR. In addition, I > > How is this possible ? Either DHCP server or the relay has to be on the first > IP hop and if it is not AR or EP, where can it be ? DHCP server or relay can be put just anywhere on the first IP hop. EP is placed on the data traffic path to the Internet. On the other hand, it does not matter whether DHCP signaling path is on the same path as the data traffic as long as the server can assign an IP address. Figures in Section 10.2 draft-ohba-pana-framework-00.txt do not assume that DHCP server or relay is always co-located with EP(AR). > > > think that the DHCP case and auto-configuration case are the same in > > that EP may not be able to setup the SPD entries before IKE exchange > > starts. > > > Agreed. But EP can verify whether the given client can use a given address > or not in the case of DHCP as it can learn which address was given to > the PaC assuming EP (and AR is co-located) is in the path of DHCP messages. I don't think the assumption is generic enough. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Feb 25 14: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 OAA06951 for ; Wed, 25 Feb 2004 14: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 1Aw4iL-0006Iv-Gf for pana-archive@odin.ietf.org; Wed, 25 Feb 2004 14:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PJT1jC024227 for pana-archive@odin.ietf.org; Wed, 25 Feb 2004 14:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4iL-0006Ig-Bw for pana-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 14:29: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 OAA06916 for ; Wed, 25 Feb 2004 14:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4iI-0000eX-00 for pana-web-archive@ietf.org; Wed, 25 Feb 2004 14:28:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4hM-0000YO-00 for pana-web-archive@ietf.org; Wed, 25 Feb 2004 14:28:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4gP-0000TD-00 for pana-web-archive@ietf.org; Wed, 25 Feb 2004 14:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4gP-00068f-Fw; Wed, 25 Feb 2004 14: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 1Aw4fW-00061y-TB for pana@optimus.ietf.org; Wed, 25 Feb 2004 14:26: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 OAA06783 for ; Wed, 25 Feb 2004 14:26:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4fU-0000O5-00 for pana@ietf.org; Wed, 25 Feb 2004 14:26:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4eY-0000J7-00 for pana@ietf.org; Wed, 25 Feb 2004 14:25:06 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4dw-0000Dm-00 for pana@ietf.org; Wed, 25 Feb 2004 14:24:28 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1PJOQ89029886; Thu, 26 Feb 2004 04:24:26 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1PJOQS2028192; Thu, 26 Feb 2004 04:24:26 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA28191 ; Thu, 26 Feb 2004 04:24:26 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA21231; Thu, 26 Feb 2004 04:24:25 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA01865; Thu, 26 Feb 2004 04:24:25 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i1PJONKv029468; Thu, 26 Feb 2004 04:24:24 +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 <0HTN00D0XN8L9T@tsbpo1.po.toshiba.co.jp>; Thu, 26 Feb 2004 04:24:23 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AvtVn-0005Yi-00; Tue, 24 Feb 2004 23:31:19 -0800 Date: Tue, 24 Feb 2004 23:31:18 -0800 From: Yoshihiro Ohba Subject: Re: [Pana] pana-ipsec-02 comments... In-reply-to: <009301c3fbd3$0fac30c0$c91167c0@adithya> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Alper Yegin , pana@ietf.org Message-id: <20040225073118.GJ20356@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Alper Yegin , pana@ietf.org User-Agent: Mutt/1.5.5.1+cvs20040105i References: <001e01c3fa8e$82bf48e0$54209069@sisa.samsung.com> <009801c3fb07$d7978480$c91167c0@adithya> <20040225020443.GI10963@steelhead> <009301c3fbd3$0fac30c0$c91167c0@adithya> 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 Wed, Feb 25, 2004 at 11:10:41AM -0800, Mohan Parthasarathy wrote: > > > > In the case of address configuration > > > > using [RFC3456] or [IKE] [IKEV2] or [DHCP] [DHCPV6], EP can learn the > > > > > > > > address allocated to the client and hence setup the SPD before the > > > > IKE exchange starts. > > > > > > > > The case for DHCP is different than the rfc3456 and IKE ones. In the > > > > latter, the IP address configuration is part of the protocol executions, > > > > hence EP can know the allocated address. In DHCP case, I guess the > > > > assumption is that DHCP server/relay is co-located with the EP, hence EP > > > > can learn the address indirectly. If that's the case, some explanation > > > > in the I-D would be useful. > > > > > > > But we are already assuming EP and AR are co-located. Then how bad > > > this assumption would be ? > > > > DHCP server/relay may be separated from EP and AR. In addition, I > > How is this possible ? Either DHCP server or the relay has to be on the first > IP hop and if it is not AR or EP, where can it be ? DHCP server or relay can be put just anywhere on the first IP hop. EP is placed on the data traffic path to the Internet. On the other hand, it does not matter whether DHCP signaling path is on the same path as the data traffic as long as the server can assign an IP address. Figures in Section 10.2 draft-ohba-pana-framework-00.txt do not assume that DHCP server or relay is always co-located with EP(AR). > > > think that the DHCP case and auto-configuration case are the same in > > that EP may not be able to setup the SPD entries before IKE exchange > > starts. > > > Agreed. But EP can verify whether the given client can use a given address > or not in the case of DHCP as it can learn which address was given to > the PaC assuming EP (and AR is co-located) is in the path of DHCP messages. I don't think the assumption is generic enough. Yoshihiro Ohba _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From pana-admin@ietf.org Wed Feb 25 19:40: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 TAA27022 for ; Wed, 25 Feb 2004 19:40: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 1Aw9ZJ-0004Er-Bo; Wed, 25 Feb 2004 19:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw9YP-0004D5-5N for pana@optimus.ietf.org; Wed, 25 Feb 2004 19:39: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 TAA27007 for ; Wed, 25 Feb 2004 19:39:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw9YN-0004aU-00 for pana@ietf.org; Wed, 25 Feb 2004 19:39:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw9XR-0004Wk-00 for pana@ietf.org; Wed, 25 Feb 2004 19:38:06 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1Aw9Wd-0004Np-00 for pana@ietf.org; Wed, 25 Feb 2004 19:37:15 -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 <0HTO00C041P2HV@mailout2.samsung.com> for pana@ietf.org; Thu, 26 Feb 2004 09:36:39 +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 <0HTO003N91P2MH@mailout2.samsung.com> for pana@ietf.org; Thu, 26 Feb 2004 09:36:38 +0900 (KST) Received: from Alperyegin ([105.144.32.84]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTO00DKA1P0SH@mmp2.samsung.com> for pana@ietf.org; Thu, 26 Feb 2004 09:36:38 +0900 (KST) Date: Wed, 25 Feb 2004 16:36:32 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <004501c3fc00$962a25d0$54209069@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.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Pana] issue56: AAA routing based on NAI vs. ISP choice clarification 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 >From Jari Arkko: > - "AAA routing based on NAI vs. ISP choice" > > Section 4.2 claims that AAA routing is based on the ISP > choice. I believe the first hop decision can be based on > this, but further on in the network it must be based on the > NAI (unless you revise AAA protocols). Actually only the destination-host/destination-realm can be inferred from the ISP choice. You are right, this does not dictate the routing, but just the final destination of AAA traffic. Once the destination-host/realm is set, the AAA routing will take these values into account (not ISP choice or NAI) as I understand. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana From exim@www1.ietf.org Wed Feb 25 19:42: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 TAA27067 for ; Wed, 25 Feb 2004 19:42: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 1Aw9bJ-0004Kh-HW for pana-archive@odin.ietf.org; Wed, 25 Feb 2004 19:42:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q0g5Y7016652 for pana-archive@odin.ietf.org; Wed, 25 Feb 2004 19:42:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw9bJ-0004KT-8k for pana-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 19:42: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 TAA27058 for ; Wed, 25 Feb 2004 19:42:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw9bH-0004nI-00 for pana-web-archive@ietf.org; Wed, 25 Feb 2004 19:42:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw9aJ-0004j6-00 for pana-web-archive@ietf.org; Wed, 25 Feb 2004 19:41:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw9ZN-0004et-00 for pana-web-archive@ietf.org; Wed, 25 Feb 2004 19:40:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw9ZJ-0004Er-Bo; Wed, 25 Feb 2004 19:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw9YP-0004D5-5N for pana@optimus.ietf.org; Wed, 25 Feb 2004 19:39: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 TAA27007 for ; Wed, 25 Feb 2004 19:39:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw9YN-0004aU-00 for pana@ietf.org; Wed, 25 Feb 2004 19:39:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw9XR-0004Wk-00 for pana@ietf.org; Wed, 25 Feb 2004 19:38:06 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1Aw9Wd-0004Np-00 for pana@ietf.org; Wed, 25 Feb 2004 19:37:15 -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 <0HTO00C041P2HV@mailout2.samsung.com> for pana@ietf.org; Thu, 26 Feb 2004 09:36:39 +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 <0HTO003N91P2MH@mailout2.samsung.com> for pana@ietf.org; Thu, 26 Feb 2004 09:36:38 +0900 (KST) Received: from Alperyegin ([105.144.32.84]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTO00DKA1P0SH@mmp2.samsung.com> for pana@ietf.org; Thu, 26 Feb 2004 09:36:38 +0900 (KST) Date: Wed, 25 Feb 2004 16:36:32 -0800 From: Alper Yegin To: pana@ietf.org Message-id: <004501c3fc00$962a25d0$54209069@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] issue56: AAA routing based on NAI vs. ISP choice clarification 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 autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT >From Jari Arkko: > - "AAA routing based on NAI vs. ISP choice" > > Section 4.2 claims that AAA routing is based on the ISP > choice. I believe the first hop decision can be based on > this, but further on in the network it must be based on the > NAI (unless you revise AAA protocols). Actually only the destination-host/destination-realm can be inferred from the ISP choice. You are right, this does not dictate the routing, but just the final destination of AAA traffic. Once the destination-host/realm is set, the AAA routing will take these values into account (not ISP choice or NAI) as I understand. Alper _______________________________________________ Pana mailing list Pana@ietf.org https://www1.ietf.org/mailman/listinfo/pana