From pana-request@research.telcordia.com Fri Aug 1 07:22:25 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06118 for ; Fri, 1 Aug 2003 07:22:25 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h71BCuba006928; Fri, 1 Aug 2003 07:12:56 -0400 (EDT) Resent-Date: Fri, 1 Aug 2003 07:12:56 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: To: nemo@nal.motlabs.com, manet@ietf.org, mobile-ip@sunroof.eng.sun.com, pana@research.telcordia.com Cc: inoue@isl.rdc.toshiba.co.jp Subject: ICMU2004 Deadline extended, Paper due: August 20th X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20030801200553V.inoue@isl.rdc.toshiba.co.jp> Date: Fri, 01 Aug 2003 20:05:53 +0900 From: Atsushi Inoue X-Dispatcher: imput version 980905(IM100) Lines: 90 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit The deadline of paper submission for First International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2004) is now extended to August 20th. Atsushi Inoue, ICMU2004 Publicity ************************************************************* Deadline for paper submission to ICMU 2004 has been extended. Paper submission due: August 20, 2003. ************************************************************* (Apologies if you receive multiple copies) CALL FOR PAPERS =============== First International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2004) January 8 and 9, 2004 NTT DoCoMo R&D Center, Yokosuka Rsearch Park, Yokosuka, JAPAN http://www.ipsj.or.jp/sig/mbl/icmu2004/ Deadline for submissions: August 20 2003 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Co-sponsored by IPSJ SIG-MBL (Informaiton Processing Society of Japan, Special Interest Group of Mobile Computing and Ubiquitous Networking) and IPSJ SG-BCC (Study Group of Broadcast Communicaiton and Computing) Scope: ~~~~~~ Mobile computing aims at ubiquitous user access to computer application. To make it possible, networking technology which enables Internet access anytime and everywhere, i.e. ubiquitous networking is necessary. It is obvious that with the accelerating trends towards mobile networks, ad-hoc networks, and wireless networks, mobile computing and ubiquitous networking will play an important role in future network. This conference is aimed at providing researchers and practitioners in this hot research area a forum for discussion and collaboration. Authors are invited to submit papers addressing, but not limited to, the following topics: - Applications and services for mobile computing - Network architectures, protocols, or service models for ubiquitous networking - Network management for ubiquitous networking - Data management for mobile computing - Security in mobile computing and ubiquitous networking - Wireless and mobile communications - Nomadic computing - Ad-hoc networks - Mobile Internetworking - Performance evaluation for mobile computing and ubiquitous networking systems - Broadcast communication Submission Instructions: ~~~~~~~~~~~~~~~~~~~~~~~~ Papers are solicited as full papers of no more than 6 pages, each of which will be subject to a full review process. Submission should already follow the author guidelines as specified in the web site below. An electronic, PDF-based submission of papers is mandatory. Please check Submission Guideline (http://www.ipsj.or.jp/sig/mbl/icmu2004/guide.html) for further submission instructions. Important Dates: ~~~~~~~~~~~~~~~~ - Deadline for submissions August 20, 2003 - Notification of acceptance October 1, 2003 - Camera ready due November 1, 2003 - Conference January 8-9, 2004 Location and Date: ~~~~~~~~~~~~~~~~~~ The location of the NTT DoCoMo R&D Center is in the heart of Yokosuka Research Park(YRP) where a lot of wireless communication related research institutes are established. YRP is really the heart of wireless communications research in Japan. Japanese old city Kamakura, a famous historic city, is 30 minutes by train. Beginning of the year is one of the best seasons for visiting Japan. You can also get PDF version of Call for Papers from http://www.ipsj.or.jp/sig/mbl/icmu2004/cfp-icmu2004.pdf From pana-request@research.telcordia.com Fri Aug 1 14:14:45 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02947 for ; Fri, 1 Aug 2003 14:14:43 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h71I6Kn2023052; Fri, 1 Aug 2003 14:06:20 -0400 (EDT) Resent-Date: Fri, 1 Aug 2003 14:06:20 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Fri, 01 Aug 2003 11:07:51 -0700 Subject: Re: Issue 8 From: Alper Yegin To: Mohan Parthasarathy , Message-ID: In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4A3@TNEXVS02.tahoenetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Mohan, >> Taking it one step further, we can also say it is the >> responsibility of the PAA to initiate PANA authentication >> before the session expires. Nevertheless, sending the >> lifetime to PaC is still useful as it helps PaC manage EAP SA >> and PANA SA efficiently. >> > How does it help it to maintain efficiently ? If PaC leaves the network without exchanging PANA-termination messages, then the associated state would linger around indefinitely, unless it has a timer associated. So, knowing the session lifetime helps PaC set this timer. Alper From pana-request@research.telcordia.com Fri Aug 1 19:49:28 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17756 for ; Fri, 1 Aug 2003 19:49:21 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h71NemU2005023; Fri, 1 Aug 2003 19:40:48 -0400 (EDT) Resent-Date: Fri, 1 Aug 2003 19:40:48 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 8 Date: Fri, 1 Aug 2003 16:40:17 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4A6@TNEXVS02.tahoenetworks.com> Thread-Topic: Issue 8 Thread-Index: AcNYV50Ol2FfA/afSvmMW1+XhWtsCQALh+Xw From: "Mohan Parthasarathy" To: "Alper Yegin" , X-OriginalArrivalTime: 01 Aug 2003 23:40:17.0899 (UTC) FILETIME=[4391B3B0:01C35886] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <7ri7TB.A.WOB.AqvK_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable =20 > Mohan, >=20 > >> Taking it one step further, we can also say it is the > >> responsibility of the PAA to initiate PANA authentication > >> before the session expires. Nevertheless, sending the > >> lifetime to PaC is still useful as it helps PaC manage EAP SA > >> and PANA SA efficiently. > >>=20 > > How does it help it to maintain efficiently ? >=20 > If PaC leaves the network without exchanging PANA-termination=20 > messages, then > the associated state would linger around indefinitely, unless=20 > it has a timer > associated. So, knowing the session lifetime helps PaC set this timer. >=20 Ok, the "manage" above really meant "help clean up SAs". I am not = disagreeing with the conclusion as there is really no harm in sending this = information to the client. PAA can always terminate early i.e it is sort of advisory = i guess. In this specific example, the PaC does not want to rely on the link = layer information to clean up SAs as it may not be secure. So, the timer is = helpful i guess.=20 -mohan > Alper >=20 >=20 From pana-request@research.telcordia.com Mon Aug 4 16:30:11 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11179 for ; Mon, 4 Aug 2003 16:30:07 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h74KJc6n029593; Mon, 4 Aug 2003 16:19:38 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 16:19:38 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 04 Aug 2003 13:21:12 -0700 Subject: Ciphering choice From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Some of the discussions around the choice of device identifier for Pac is stemming from the choice of ciphering. If L2 ciphering will be used, than the L2 address must be the DI. If L3 ciphering will be used (i.e., IPsec), then the DI must be an IP address. Two questions: a) Does it make sense to leave the selection to PaC, or should PAA mandate which ciphering should be used? b) Does it make sense to enable both L2 and L3 ciphering at the same time? Based on the earlier discussions, in my personal opinion, the ciphering selection should be based on the access network policy. Hence, this is not something for the PaC to decide. I'd say PAA should mandate, and PaC should obey the decision. As for (b), it was not clear whether this is something needed and useful. In order to bind the client authentication to data traffic, one is sufficient. I recommend we let PAA specify which one of the two ciphering mechanisms will be used (L2 vs. L3), PaC has to obey or leave the network, and the device IDs are chosen accordingly. Comments? Alper From pana-request@research.telcordia.com Mon Aug 4 17:28:18 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12465 for ; Mon, 4 Aug 2003 17:28:18 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h74LLXau002265; Mon, 4 Aug 2003 17:21:33 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 17:21:33 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 04 Aug 2003 14:23:17 -0700 Subject: Issue17: Error Handling From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit The current PANA draft has a place holder for PANA-error message, but none of the details are included. We should decide when PANA-error should be sent, what should the receiver of this message do, and eventually the exact format of the message. PANA-error message MAY be sent by either PaC or PAA when a badly formed PANA message is received (see section 4.1.7). If the cause of this error message was a request message (e.g., PANA-PAA-Discover or *-Request), then the request MAY be transmitted immediately without waiting for its timer to go off. If the cause of the error was a response message, the receiver of the PANA-error SHOULD NOT resend the same response until it receives the next request. If the error persists and the PANA session is not making any progress, PANA peer SHOULD send a PANA-Terminate-Request to terminate the session. Comments? Alper From pana-request@research.telcordia.com Mon Aug 4 18:30:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14618 for ; Mon, 4 Aug 2003 18:30:47 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h74MN3qp004889; Mon, 4 Aug 2003 18:23:03 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 18:23:03 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 04 Aug 2003 15:22:47 -0700 From: Yoshihiro Ohba Subject: Re: Ciphering choice In-reply-to: To: Alper Yegin Cc: pana@research.telcordia.com Message-id: <20030804222247.GK27902@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@research.telcordia.com User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 41 References: X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <2x7uFB.A.OMB.HztL_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Mon, Aug 04, 2003 at 01:21:12PM -0700, Alper Yegin wrote: > > Some of the discussions around the choice of device identifier for Pac is > stemming from the choice of ciphering. If L2 ciphering will be used, than > the L2 address must be the DI. If L3 ciphering will be used (i.e., IPsec), > then the DI must be an IP address. > > Two questions: > a) Does it make sense to leave the selection to PaC, or should PAA mandate > which ciphering should be used? > b) Does it make sense to enable both L2 and L3 ciphering at the same time? > > Based on the earlier discussions, in my personal opinion, the ciphering > selection should be based on the access network policy. Hence, this is not > something for the PaC to decide. I'd say PAA should mandate, and PaC should > obey the decision. Agreed. > > As for (b), it was not clear whether this is something needed and useful. In > order to bind the client authentication to data traffic, one is sufficient. Now I don't mind binding the client authentication to either L2 or L3 ciphers, because there was not much support for bootstrapping both ciphers from PANA. > > I recommend we let PAA specify which one of the two ciphering mechanisms > will be used (L2 vs. L3), PaC has to obey or leave the network, and the > device IDs are chosen accordingly. OK. > > Comments? > > Alper > Yoshihiro Ohba From pana-request@research.telcordia.com Mon Aug 4 18:46:59 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14871 for ; Mon, 4 Aug 2003 18:46:58 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h74MeCmM005760; Mon, 4 Aug 2003 18:40:12 -0400 (EDT) Resent-Date: Mon, 4 Aug 2003 18:40:12 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 04 Aug 2003 15:39:59 -0700 From: Yoshihiro Ohba Subject: Re: Issue17: Error Handling In-reply-to: To: Alper Yegin Cc: pana@research.telcordia.com Message-id: <20030804223959.GL27902@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , pana@research.telcordia.com User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 35 References: X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Mon, Aug 04, 2003 at 02:23:17PM -0700, Alper Yegin wrote: > > The current PANA draft has a place holder for PANA-error message, but none > of the details are included. We should decide when PANA-error should be > sent, what should the receiver of this message do, and eventually the exact > format of the message. > > PANA-error message MAY be sent by either PaC or PAA when a badly formed PANA > message is received (see section 4.1.7). If the cause of this error message > was a request message (e.g., PANA-PAA-Discover or *-Request), then the > request MAY be transmitted immediately without waiting for its timer to go > off. If the cause of the error was a response message, the receiver of the > PANA-error SHOULD NOT resend the same response until it receives the next > request. > I have an additional text considering possible DoS attacks based on sending bogus error messages: When an error message is sent unprotected with MAC AVP and the lower-layer is insecure, the error message is treated as an informational message. The receiver of such an error message MUST NOT change its state unless the error persists and the PANA session is not making any progress. > If the error persists and the PANA session is not making any progress, PANA > peer SHOULD send a PANA-Terminate-Request to terminate the session. > > Comments? > > Alper > Yoshihiro Ohba From pana-request@research.telcordia.com Thu Aug 7 17:49:32 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04557 for ; Thu, 7 Aug 2003 17:49:26 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h77LeVgG005508; Thu, 7 Aug 2003 17:40:31 -0400 (EDT) Resent-Date: Thu, 7 Aug 2003 17:40:31 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 07 Aug 2003 14:42:10 -0700 Subject: Issue4: (new) Device identifier (types) From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit http://www.danforsberg.info:8080/pana-issues/issue4 The issue text refers to multi-homed hosts and device ID changes. These are covered under separate issues (#16 and #5). So, issue #4 should only be talking about new DI types. And the one mentioned in the text is "subnet prefix." Unless anyone has another proposed device ID type, let's discuss that. I'm trying to understand the utility of setting the DI as a subnet prefix. If this is proposed to enable mobile routers to connect to an access network, we can easily achive that by using either a mac address DI along with L2 ciphering, or a single IP address DI along with IPsec. In the latter case, any IP address can be used inside the IPsec tunnel. Aside from not needing it, I'm also not sure how we can use this DI as an IPsec end point. Unless anybody objects, I recommend we reject this issue. Comments please. Alper From pana-request@research.telcordia.com Thu Aug 7 18:06:51 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05377 for ; Thu, 7 Aug 2003 18:06:50 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h77LxaMJ006643; Thu, 7 Aug 2003 17:59:36 -0400 (EDT) Resent-Date: Thu, 7 Aug 2003 17:59:36 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 07 Aug 2003 15:01:15 -0700 Subject: Issue5: Updating the device identifier From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit As presented at IETF 57, the only valid case identified that requires a DI change is this: - A PaC performs PANA, configures an IP address via DHCP, binds the IP address to PANA session, performs IKE for IPsec-based access control. Needless to say, one wouldn't do this if physical security or L2 ciphering capability is available in the network. A L2 address can be used as DI, we won't need to use IKE or IPsec. This above is a very particular case where IPsec-based access control is used and the clients are not allocated IP address before they are authenticated. Unauthenticated hosts are allowed two types of traffic: PANA and DHCP. DHCP is secured by some means (pending DHCP WG's solution). Proposed solution was to handle this case by allowing PaC to send its new DI (i.e., the IP address obtained from DHCP) via PANA-reauth message. The new DI overwrite the previous one (0::0, or 0.0.0.0 in this case). Unless there is any objection, let's move forward with this solution. Comments please. Alper From pana-request@research.telcordia.com Mon Aug 11 11:52:48 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20805 for ; Mon, 11 Aug 2003 11:52:41 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7BFfXqI006212; Mon, 11 Aug 2003 11:41:33 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 11:41:33 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [issue8] Refresh Interval Negotiation Date: Mon, 11 Aug 2003 18:41:24 +0300 Message-ID: Thread-Topic: [issue8] Refresh Interval Negotiation Thread-Index: AcNgHskRRpRfT9tiScyOFjQOXVDVVAAADPRg From: To: X-OriginalArrivalTime: 11 Aug 2003 15:41:25.0674 (UTC) FILETIME=[05F598A0:01C3601F] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: Alper Yegin:=20 The resolution recommended at the IETF presentation was to carry only session lifetime in PANA-bind-request message sent from PAA. This would be a non-negotiable, informative parameter. Neither of grace period nor re-auth timers will be exchanged between PAA and PaC. Taking it one step further, we can also say it is the responsibility of the PAA to initiate PANA authentication before the session expires. Nevertheless, sending the lifetime to PaC is still useful as it helps PaC manage EAP SA and PANA SA efficiently. _______________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue8 _______________________________________________ From pana-request@research.telcordia.com Mon Aug 11 11:52:51 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20827 for ; Mon, 11 Aug 2003 11:52:51 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7BFfiHg006241; Mon, 11 Aug 2003 11:41:44 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 11:41:44 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [issue5] Updating the Device Identifier Date: Mon, 11 Aug 2003 18:41:35 +0300 Message-ID: Thread-Topic: [issue5] Updating the Device Identifier Thread-Index: AcNgHmonL8stIgHbTquvjs+I3FV03QAAJ6FQ From: To: X-OriginalArrivalTime: 11 Aug 2003 15:41:36.0207 (UTC) FILETIME=[0C3CCDF0:01C3601F] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: Alper Yegin:=20 As presented at IETF 57, the only valid case identified that requires a DI change is this: - A PaC performs PANA, configures an IP address via DHCP, binds the IP address to PANA session, performs IKE for IPsec-based access control. Needless to say, one wouldn't do this if physical security or L2 ciphering capability is available in the network. A L2 address can be used as DI, we won't need to use IKE or IPsec. This above is a very particular case where IPsec-based access control is used and the clients are not allocated IP address before they are authenticated. Unauthenticated hosts are allowed two types of traffic: PANA and DHCP. DHCP is secured by some means (pending DHCP WG's solution). Proposed solution was to handle this case by allowing PaC to send its new DI (i.e., the IP address obtained from DHCP) via PANA-reauth message. The new DI overwrite the previous one (0::0, or 0.0.0.0 in this case). Unless there is any objection, let's move forward with this solution. _______________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue5 _______________________________________________ From pana-request@research.telcordia.com Mon Aug 11 11:53:30 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20885 for ; Mon, 11 Aug 2003 11:53:30 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7BFkCsf006755; Mon, 11 Aug 2003 11:46:12 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 11:46:12 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [issue4] Device Identifier Date: Mon, 11 Aug 2003 18:42:16 +0300 Message-ID: Thread-Topic: [issue4] Device Identifier Thread-Index: AcNgHWlE9dL5OJTSS8KV0UJCfADyNgAAbEhA From: To: X-OriginalArrivalTime: 11 Aug 2003 15:42:17.0032 (UTC) FILETIME=[24923480:01C3601F] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: Alper Yegin: The issue text refers to multi-homed hosts and device ID changes. These are covered under separate issues (#16 and #5). So, issue #4 should only be talking about new DI types. And the one mentioned in the text is "subnet prefix." Unless anyone has another proposed device ID type, let's discuss that. I'm trying to understand the utility of setting the DI as a subnet prefix. If this is proposed to enable mobile routers to connect to an access network, we can easily achive that by using either a mac address DI along with L2 ciphering, or a single IP address DI along with IPsec. In the latter case, any IP address can be used inside the IPsec tunnel. Aside from not needing it, I'm also not sure how we can use this DI as an IPsec end point. Unless anybody objects, I recommend we reject this issue. _______________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue4 _______________________________________________ From pana-request@research.telcordia.com Mon Aug 11 11:53:49 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20901 for ; Mon, 11 Aug 2003 11:53:48 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7BFj2nM006395; Mon, 11 Aug 2003 11:45:02 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 11:45:02 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [issue15] enhanced dos protection based on client puzzles Date: Mon, 11 Aug 2003 18:41:01 +0300 Message-ID: Thread-Topic: [issue15] enhanced dos protection based on client puzzles Thread-Index: AcNgGwnDbJ1neA1+QHCPO420tNUmwgAA+Qbw From: To: X-OriginalArrivalTime: 11 Aug 2003 15:41:02.0114 (UTC) FILETIME=[F7EAA020:01C3601E] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: Issue 15 is about using cookie vs. puzzle for DoS prevention. The recommended resolution at the meeting=20 was to: - only include (mandatory to implement, optional to use) cookie mechanism in the base draft - allow alternative mechanisms like puzzles defined in separate drafts. ---------- status: No Discussion -> Clarifying Text Required ________________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue15 ________________________________________________ From pana-request@research.telcordia.com Mon Aug 11 11:53:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20900 for ; Mon, 11 Aug 2003 11:53:47 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7BFjjKY006700; Mon, 11 Aug 2003 11:45:45 -0400 (EDT) Resent-Date: Mon, 11 Aug 2003 11:45:45 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [issue17] Error handling Date: Mon, 11 Aug 2003 18:41:47 +0300 Message-ID: Thread-Topic: [issue17] Error handling Thread-Index: AcNgHgMkBcMuGHcLS2uk/y7MhvyxdAAAQwsg From: To: X-OriginalArrivalTime: 11 Aug 2003 15:41:48.0039 (UTC) FILETIME=[134A3970:01C3601F] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: Alper Yegin (with editorial fixes):=20 PANA-error message MAY be sent by either PaC or PAA when a badly formed PANA message is received (see section 4.1.7). If the cause of this error message was a request message (e.g., PANA-PAA-Discover or *-Request), then the request MAY be retransmitted immediately without waiting for its retransmission timer to go off. If the cause of the error was a response message, the receiver of the PANA-error SHOULD NOT resend the same response until it receives the next request. Yoshihiro Ohba: When an error message is sent unprotected with MAC AVP and the lower-layer is insecure, the error message is treated as an informational message. The receiver of such an error message MUST NOT change its state unless the error persists and the PANA session is not making any progress. ---------- status: No Discussion -> Text Proposed ________________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue17 ________________________________________________ From pana-request@research.telcordia.com Wed Aug 13 06:03:46 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14537 for ; Wed, 13 Aug 2003 06:03:32 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7D9se9B027632; Wed, 13 Aug 2003 05:54:40 -0400 (EDT) Resent-Date: Wed, 13 Aug 2003 05:54:40 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: new [issue20] Retransmission timers and counts Date: Wed, 13 Aug 2003 12:54:25 +0300 Message-ID: Thread-Topic: new [issue20] Retransmission timers and counts Thread-Index: AcNhgOEwCKIfCfLTToyIpgJoAYlA6w== From: To: X-OriginalArrivalTime: 13 Aug 2003 09:54:26.0429 (UTC) FILETIME=[E18C6AD0:01C36180] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <7cZ76C.A.nvG.grgO_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable http://danforsberg.info:8080/pana-issues/issue20 "Define default timer and retransmission counts for=20 the discover, start, reauth, bind, and terminate messages." From pana-request@research.telcordia.com Wed Aug 13 09:30:46 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18675 for ; Wed, 13 Aug 2003 09:30:39 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7DDL2TY008666; Wed, 13 Aug 2003 09:21:02 -0400 (EDT) Resent-Date: Wed, 13 Aug 2003 09:21:02 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 8 Date: Wed, 13 Aug 2003 16:20:56 +0300 Message-ID: Thread-Topic: Issue 8 Thread-Index: AcNXmWYQYvP8YZF/RcuJKJvDZLckHgJ+xwsQ From: To: , X-OriginalArrivalTime: 13 Aug 2003 13:20:57.0411 (UTC) FILETIME=[BB263930:01C3619D] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Couple of thoughts for this issue.. We have three levels of authentications with PANA.=20 1. PANA specific local re-auth. 2. EAP re-auth. 3. full EAP auth from scratch. How to manage these.. What lifetime does the "session lifetime" refer to in PANA? Diameter=20 specifies Session-Timeout (from RADIUS) and Authorization-Lifetime AVPs. = Authorization-Lifetime tells to the AAA Client when to do=20 re-authorization (EAP re-auth in PANA case?). 8.13 Session-Timeout AVP The Session-Timeout AVP (AVP Code 27) [RADIUS] is of type Unsigned32 and contains the maximum number of seconds of service to be provided to the user before termination of the session. When both the Session-Timeout and the Authorization-Lifetime AVPs are present in an answer message, the former MUST be equal to or greater than the value of the latter. If I have understood properly Session-Timeout tells when both the=20 authentication and authorization must be done from scratch, i.e. new=20 keys must be derived etc. (full EAP auth). So this is used to define=20 the session key lifetimes too? Action to be taken can also be specified according to the NASREQ. Sec. 4.10. talks about Session-Timeout and Authorization-Lifetime too: The Termination-Action AVP is of type Enumerated and indicates what action the NAS should take when the specified service is completed. This AVP SHOULD only be present in authorization responses. The following values are supported as listed in [RADIUSTypes]: DEFAULT 0 Upon termination of the authorized service the NAS MUST terminate the current session. AA-REQUEST 1 When the authorized service terminates, the NAS SHOULD NOT terminate the session or generate a Session-Termination-Request (STR) command. Instead, it SHOULD generate a new AAR command which contains the same value of the Session-Id AVP it sent in the previous AAR command. It SHOULD also include the State AVP from the previous AA-Answer (AAA) command, if it contained one. When used by 802.1X supplicants, the service typically terminates due to the expiry of the Session-Timeout AVP. The access device may then reauthenticate the user with a new AA-Request. The RECOMMENDED way to do this in Diameter is to use just the Authorization-Lifetime AVP rather than Session-Timeout and Termination-Action AVPs. However, the Termination-Action AVP MAY be present when copied from a RADIUS Access-Accept to a Diameter AA-Answer by a Translation Agent. So NASREQ recommends to use Authorization-Lifetime AVP only with = Diameter.=20 Does NASREQ here mean full auth or just re-auth? From Diameter: =09 8.12 Re-Auth-Request-Type AVP The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and is included in application-specific auth answers to inform the client of the action expected upon expiration of the Authorization-Lifetime. If the answer message contains an Authorization-Lifetime AVP with a positive value, the Re-Auth-Request-Type AVP MUST be present in an answer message. The following values are defined: AUTHORIZE_ONLY 0 An authorization only re-auth is expected upon expiration of the Authorization-Lifetime. This is the default value if the AVP is not present in answer messages that include the Authorization-Lifetime. AUTHORIZE_AUTHENTICATE 1 An authentication and authorization re-auth is expected upon expiration of the Authorization-Lifetime. So, if Authorization-Lifetime AVP is used in the AAA backend=20 Re-Auth-Request-Type AVP is there too. Number of possible = re-authentications=20 before full authentication should be limited too (recommendation from = some=20 EAP methods, like EAP-SIM). How to do this? -- I'm also a bit worried about the fuzzy (timing) use of = PANA-Reauth-Request=20 message. What if "session lifetime" is 2 days, but PaC looses connection = after 10 minutes? If we don't use refresh period, we could use = Idle-Timeout=20 AVP from NASREQ: 6.4. Idle-Timeout AVP The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 and sets the maximum number of consecutive seconds of idle connection allowed to the user before termination of the session or prompt. It MAY be used in an authentication and/or authorization request (or challenge) as a hint to the server that an idle timeout is desired, but the server is not required to honor the hint in the corresponding response. The default is none, or system specific. Also, how does PANA relate to link layer triggers (link up/down)? Should = PAA terminate session for PaC if it gets link-down notification for it? - Dan > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 31 July, 2003 22:26 > To: pana@research.telcordia.com > Subject: Issue 8 >=20 >=20 >=20 > The resolution recommended at the IETF presentation was to carry only > session lifetime in PANA-bind-request message sent from PAA.=20 > This would be a > non-negotiable, informative parameter. Neither of grace=20 > period nor re-auth > timers will be exchanged between PAA and PaC. >=20 > Taking it one step further, we can also say it is the=20 > responsibility of the > PAA to initiate PANA authentication before the session expires. > Nevertheless, sending the lifetime to PaC is still useful as=20 > it helps PaC > manage EAP SA and PANA SA efficiently. >=20 > Comments? If there are no objections, let's close this issue. >=20 > Alper >=20 >=20 From pana-request@research.telcordia.com Wed Aug 13 10:13:39 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20700 for ; Wed, 13 Aug 2003 10:13:34 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7DE6N2k010794; Wed, 13 Aug 2003 10:06:23 -0400 (EDT) Resent-Date: Wed, 13 Aug 2003 10:06:23 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue4: (new) Device identifier (types) Date: Wed, 13 Aug 2003 17:01:45 +0300 Message-ID: Thread-Topic: Issue4: (new) Device identifier (types) Thread-Index: AcNdLJR2PtxCeSV1RCuOMxGsruPB5AEdE1fA From: To: , X-OriginalArrivalTime: 13 Aug 2003 14:01:45.0277 (UTC) FILETIME=[6E30EED0:01C361A3] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable One of the questions in IETF57 PANA wg meeting was that should PAA=20 take care of authorizing IP addresses. I think it should, because=20 it informs the EPs about the filtering rules. If I've understood correctly IPSec tunnel is used between PaC and=20 EP/PAA with link local addresses. Then the inner IP address in the=20 IPSec tunnel should be PANA DI. In this case it could be a subnet=20 prefix, right? If PANA uses MAC as the DI (and even with IPSec tunnel), PAA/EP can't=20 control the IP addresses the PaC is using (inner IP address in the=20 IPSec tunnel). Anyway, I firmly believe that access networks wount=20 pass packets with ANY source IP address to the network (refusal to=20 route). So I don't think that any IP address can be used inside the=20 IPSec tunnel. - Dan > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 08 August, 2003 00:42 > To: pana@research.telcordia.com > Subject: Issue4: (new) Device identifier (types) >=20 >=20 >=20 > http://www.danforsberg.info:8080/pana-issues/issue4 >=20 > The issue text refers to multi-homed hosts and device ID=20 > changes. These are > covered under separate issues (#16 and #5). >=20 > So, issue #4 should only be talking about new DI types. And the one > mentioned in the text is "subnet prefix." Unless anyone has=20 > another proposed > device ID type, let's discuss that. >=20 > I'm trying to understand the utility of setting the DI as a=20 > subnet prefix. > If this is proposed to enable mobile routers to connect to an access > network, we can easily achive that by using either a mac=20 > address DI along > with L2 ciphering, or a single IP address DI along with=20 > IPsec. In the latter > case, any IP address can be used inside the IPsec tunnel.=20 > Aside from not > needing it, I'm also not sure how we can use this DI as an=20 > IPsec end point. >=20 > Unless anybody objects, I recommend we reject this issue. >=20 > Comments please. >=20 > Alper > =20 >=20 >=20 From pana-request@research.telcordia.com Wed Aug 13 10:33:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22042 for ; Wed, 13 Aug 2003 10:33:51 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7DEP3qm012077; Wed, 13 Aug 2003 10:25:03 -0400 (EDT) Resent-Date: Wed, 13 Aug 2003 10:25:03 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Ciphering choice Date: Wed, 13 Aug 2003 17:24:58 +0300 Message-ID: Thread-Topic: Ciphering choice Thread-Index: AcNaxci3tnhIm9LaSsioXW5233eP1AG3rIhg From: To: , X-OriginalArrivalTime: 13 Aug 2003 14:25:00.0036 (UTC) FILETIME=[AD884440:01C361A6] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable What about filtering based on IP address (PANA DI) in EP/PAA?=20 It is needed both with L2 ciphering and with IPSec.=20 This means that PAA must know the correct IP address for the=20 PaC. We just can't forget L3, when L2 ciphering is used. I think that with L2 ciphering we can use L2 MAC and that=20 is fine, but PANA needs to take care of IP traffic filtering=20 too. Or should we say that IP traffic filtering is the first priority since PANA is L3 solution. And no, this is not SEND problem. - Dan > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 04 August, 2003 23:21 > To: pana@research.telcordia.com > Subject: Ciphering choice >=20 >=20 >=20 > Some of the discussions around the choice of device=20 > identifier for Pac is > stemming from the choice of ciphering. If L2 ciphering will=20 > be used, than > the L2 address must be the DI. If L3 ciphering will be used=20 > (i.e., IPsec), > then the DI must be an IP address. >=20 > Two questions:=20 > a) Does it make sense to leave the selection to PaC, or=20 > should PAA mandate > which ciphering should be used? > b) Does it make sense to enable both L2 and L3 ciphering at=20 > the same time? >=20 > Based on the earlier discussions, in my personal opinion, the=20 > ciphering > selection should be based on the access network policy.=20 > Hence, this is not > something for the PaC to decide. I'd say PAA should mandate,=20 > and PaC should > obey the decision. >=20 > As for (b), it was not clear whether this is something needed=20 > and useful. In > order to bind the client authentication to data traffic, one=20 > is sufficient. >=20 > I recommend we let PAA specify which one of the two ciphering=20 > mechanisms > will be used (L2 vs. L3), PaC has to obey or leave the=20 > network, and the > device IDs are chosen accordingly. >=20 > Comments? >=20 > Alper >=20 >=20 From pana-request@research.telcordia.com Wed Aug 13 12:26:33 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25031 for ; Wed, 13 Aug 2003 12:26:26 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7DGGGNi016474; Wed, 13 Aug 2003 12:16:16 -0400 (EDT) Resent-Date: Wed, 13 Aug 2003 12:16:16 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 11 Aug 2003 09:28:19 -0700 From: Yoshihiro Ohba Subject: Re: Issue4: (new) Device identifier (types) In-reply-to: To: Dan.Forsberg@nokia.com Cc: alper@docomolabs-usa.com, pana@research.telcordia.com Message-id: <20030811162818.GA11479@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, alper@docomolabs-usa.com, pana@research.telcordia.com User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 86 References: X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <6MnFt.A.RBE.QRmO_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Wed, Aug 13, 2003 at 05:01:45PM +0300, Dan.Forsberg@nokia.com wrote: > One of the questions in IETF57 PANA wg meeting was that should PAA > take care of authorizing IP addresses. I think it should, because > it informs the EPs about the filtering rules. > > If I've understood correctly IPSec tunnel is used between PaC and > EP/PAA with link local addresses. Then the inner IP address in the > IPSec tunnel should be PANA DI. In this case it could be a subnet > prefix, right? The inner IP address in the IPsec tunnel is not necessarily be a PANA DI, since the outer IP address (i.e., a link local IP address) can be used as a PANA DI. Authorization for the inner IP address can be done in IKE negotiation by which an appropriate per-packet filtering rule for the inner IP address is set to IPsec SPD. IKE also supports negotiatin of subnet-prefix parameters for inner packets. > > If PANA uses MAC as the DI (and even with IPSec tunnel), PAA/EP can't > control the IP addresses the PaC is using (inner IP address in the > IPSec tunnel). Anyway, I firmly believe that access networks wount > pass packets with ANY source IP address to the network (refusal to > route). So I don't think that any IP address can be used inside the > IPSec tunnel. I think the required functionality of per-packet filtering for inner packets is already covered by the combination of: - Support of DI update (from MAC address to IP address). - Use of link-local address as a DI when bootstrapping IKE. - Use of IKE for establishing an tunnel mode IPsec SA between PaC and EP. (as a result, an SPD entry for inner packet filtering will be created.) - Use of IPsec tunnel (whether inner packet filtering is done based on the created SPD entry). Yoshihiro Ohba > > - Dan > > > -----Original Message----- > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > Sent: 08 August, 2003 00:42 > > To: pana@research.telcordia.com > > Subject: Issue4: (new) Device identifier (types) > > > > > > > > http://www.danforsberg.info:8080/pana-issues/issue4 > > > > The issue text refers to multi-homed hosts and device ID > > changes. These are > > covered under separate issues (#16 and #5). > > > > So, issue #4 should only be talking about new DI types. And the one > > mentioned in the text is "subnet prefix." Unless anyone has > > another proposed > > device ID type, let's discuss that. > > > > I'm trying to understand the utility of setting the DI as a > > subnet prefix. > > If this is proposed to enable mobile routers to connect to an access > > network, we can easily achive that by using either a mac > > address DI along > > with L2 ciphering, or a single IP address DI along with > > IPsec. In the latter > > case, any IP address can be used inside the IPsec tunnel. > > Aside from not > > needing it, I'm also not sure how we can use this DI as an > > IPsec end point. > > > > Unless anybody objects, I recommend we reject this issue. > > > > Comments please. > > > > Alper > > > > > > > From pana-request@research.telcordia.com Wed Aug 13 16:48:27 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05375 for ; Wed, 13 Aug 2003 16:48:24 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7DKdTu6026788; Wed, 13 Aug 2003 16:39:29 -0400 (EDT) Resent-Date: Wed, 13 Aug 2003 16:39:29 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue4: (new) Device identifier (types) Date: Wed, 13 Aug 2003 13:38:50 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4B4@TNEXVS02.tahoenetworks.com> Thread-Topic: Issue4: (new) Device identifier (types) Thread-Index: AcNdLJR2PtxCeSV1RCuOMxGsruPB5AEdE1fAAAulSmA= From: "Mohan Parthasarathy" To: , , X-OriginalArrivalTime: 13 Aug 2003 20:38:50.0419 (UTC) FILETIME=[E7151830:01C361DA] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable =20 > One of the questions in IETF57 PANA wg meeting was that should PAA=20 > take care of authorizing IP addresses. I think it should, because=20 > it informs the EPs about the filtering rules. >=20 > If I've understood correctly IPSec tunnel is used between PaC and=20 > EP/PAA with link local addresses. Then the inner IP address in the=20 > IPSec tunnel should be PANA DI. In this case it could be a subnet=20 > prefix, right? >=20 Why should it be a prefix ? For now, a simple address should suffice. > If PANA uses MAC as the DI (and even with IPSec tunnel), PAA/EP can't=20 > control the IP addresses the PaC is using (inner IP address in the=20 > IPSec tunnel). Anyway, I firmly believe that access networks wount=20 > pass packets with ANY source IP address to the network (refusal to=20 > route). So I don't think that any IP address can be used inside the=20 > IPSec tunnel. >=20 I think it is not possible to know the IP address always. In IPv6, the node could potentially use a RFC3041 private address and hard to know what that address would be. That's why the current pana-ipsec draft just relies only on the link-local address in IPv6 and that's what is bound to the selectors. If it uses tunnel mode, then the inner addresses would be unspecified during Ipsec SA negotiation. If we are using Ipsec or other L2 cipher for access control, the verification of the MIC should be enough for access control. I don't think we have to go beyond this in PANA i.e we don't need to provide all the details on how this can be done. -mohan > - Dan >=20 > > -----Original Message----- > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > Sent: 08 August, 2003 00:42 > > To: pana@research.telcordia.com > > Subject: Issue4: (new) Device identifier (types) > >=20 > >=20 > >=20 > > http://www.danforsberg.info:8080/pana-issues/issue4 > >=20 > > The issue text refers to multi-homed hosts and device ID > > changes. These are > > covered under separate issues (#16 and #5). > >=20 > > So, issue #4 should only be talking about new DI types. And the one=20 > > mentioned in the text is "subnet prefix." Unless anyone has another=20 > > proposed device ID type, let's discuss that. > >=20 > > I'm trying to understand the utility of setting the DI as a > > subnet prefix. > > If this is proposed to enable mobile routers to connect to an access > > network, we can easily achive that by using either a mac=20 > > address DI along > > with L2 ciphering, or a single IP address DI along with=20 > > IPsec. In the latter > > case, any IP address can be used inside the IPsec tunnel.=20 > > Aside from not > > needing it, I'm also not sure how we can use this DI as an=20 > > IPsec end point. > >=20 > > Unless anybody objects, I recommend we reject this issue. > >=20 > > Comments please. > >=20 > > Alper > > =20 > >=20 > >=20 >=20 >=20 From pana-request@research.telcordia.com Wed Aug 13 16:49:54 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05400 for ; Wed, 13 Aug 2003 16:49:54 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7DKgZU5027113; Wed, 13 Aug 2003 16:42:35 -0400 (EDT) Resent-Date: Wed, 13 Aug 2003 16:42:35 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ciphering choice Date: Wed, 13 Aug 2003 13:42:00 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C1512@TNEXVS02.tahoenetworks.com> Thread-Topic: Ciphering choice Thread-Index: AcNaxci3tnhIm9LaSsioXW5233eP1AG3rIhgAA2e5pA= From: "Mohan Parthasarathy" To: , , X-OriginalArrivalTime: 13 Aug 2003 20:42:01.0174 (UTC) FILETIME=[58C7FF60:01C361DB] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <3OKGPC.A.gnG.7KqO_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable =20 >=20 > What about filtering based on IP address (PANA DI) in EP/PAA?=20 > It is needed both with L2 ciphering and with IPSec.=20 >=20 > This means that PAA must know the correct IP address for the=20 > PaC. We just can't forget L3, when L2 ciphering is used. >=20 > I think that with L2 ciphering we can use L2 MAC and that=20 > is fine, but PANA needs to take care of IP traffic filtering=20 > too. Or should we say that IP traffic filtering is the first=20 > priority since PANA is L3 solution. >=20 > And no, this is not SEND problem. >=20 Please see my other mail. We need some mechanism to provide access control. Using Ipsec does help do this. And we can document this. Now using this to prevent spoofing etc. beyond the scope. -mohan > - Dan >=20 > > -----Original Message----- > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > Sent: 04 August, 2003 23:21 > > To: pana@research.telcordia.com > > Subject: Ciphering choice > >=20 > >=20 > >=20 > > Some of the discussions around the choice of device > > identifier for Pac is > > stemming from the choice of ciphering. If L2 ciphering will=20 > > be used, than > > the L2 address must be the DI. If L3 ciphering will be used=20 > > (i.e., IPsec), > > then the DI must be an IP address. > >=20 > > Two questions: > > a) Does it make sense to leave the selection to PaC, or=20 > > should PAA mandate > > which ciphering should be used? > > b) Does it make sense to enable both L2 and L3 ciphering at=20 > > the same time? > >=20 > > Based on the earlier discussions, in my personal opinion, the > > ciphering > > selection should be based on the access network policy.=20 > > Hence, this is not > > something for the PaC to decide. I'd say PAA should mandate,=20 > > and PaC should > > obey the decision. > >=20 > > As for (b), it was not clear whether this is something needed > > and useful. In > > order to bind the client authentication to data traffic, one=20 > > is sufficient. > >=20 > > I recommend we let PAA specify which one of the two ciphering > > mechanisms > > will be used (L2 vs. L3), PaC has to obey or leave the=20 > > network, and the > > device IDs are chosen accordingly. > >=20 > > Comments? > >=20 > > Alper > >=20 > >=20 >=20 >=20 From pana-request@research.telcordia.com Wed Aug 13 16:54:21 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05592 for ; Wed, 13 Aug 2003 16:54:20 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7DKlJQa027549; Wed, 13 Aug 2003 16:47:19 -0400 (EDT) Resent-Date: Wed, 13 Aug 2003 16:47:19 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue4: (new) Device identifier (types) Date: Wed, 13 Aug 2003 13:47:12 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C1513@TNEXVS02.tahoenetworks.com> Thread-Topic: Issue4: (new) Device identifier (types) Thread-Index: AcNhuGsbjkgsIxOkTnaF9w5wzhgfXwAIvEHA From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" , Cc: , X-OriginalArrivalTime: 13 Aug 2003 20:47:12.0463 (UTC) FILETIME=[1252EDF0:01C361DC] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable =20 >=20 > On Wed, Aug 13, 2003 at 05:01:45PM +0300,=20 > Dan.Forsberg@nokia.com wrote: > > One of the questions in IETF57 PANA wg meeting was that should PAA > > take care of authorizing IP addresses. I think it should, because=20 > > it informs the EPs about the filtering rules. > >=20 > > If I've understood correctly IPSec tunnel is used between PaC and > > EP/PAA with link local addresses. Then the inner IP address in the=20 > > IPSec tunnel should be PANA DI. In this case it could be a subnet=20 > > prefix, right? >=20 > The inner IP address in the IPsec tunnel is not necessarily=20 > be a PANA DI, since the outer IP address (i.e., a link local=20 > IP address) can be used as a PANA DI. Authorization for the=20 > inner IP address can be done in IKE negotiation by which an=20 > appropriate per-packet filtering rule for the inner IP=20 > address is set to IPsec SPD. IKE also supports negotiatin of=20 > subnet-prefix parameters for inner packets. >=20 It is not possible to know the inner IP addresses always i.e the dynamic SPD setup should be very simple. Just use the DI (link-local in IPv6 or the DHCP address in IPv4) for binding to the Ipsec SA. >=20 > >=20 > > If PANA uses MAC as the DI (and even with IPSec tunnel),=20 > PAA/EP can't > > control the IP addresses the PaC is using (inner IP address in the=20 > > IPSec tunnel). Anyway, I firmly believe that access networks wount=20 > > pass packets with ANY source IP address to the network (refusal to=20 > > route). So I don't think that any IP address can be used inside the=20 > > IPSec tunnel. >=20 > I think the required functionality of per-packet filtering=20 > for inner packets is already covered by the combination of: >=20 > - Support of DI update (from MAC address to IP address). >=20 > - Use of link-local address as a DI when bootstrapping IKE. >=20 > - Use of IKE for establishing an tunnel mode IPsec SA between=20 > PaC and EP. > (as a result, an SPD entry for inner packet filtering will=20 > be created.) >=20 As I mentioned in other mail, we don't need this. We are talking about access control. MIC is sufficient for authorization.=20 -mohan > - Use of IPsec tunnel (whether inner packet filtering is done > based on the created SPD entry). >=20 >=20 > Yoshihiro Ohba >=20 >=20 > >=20 > > - Dan > >=20 > > > -----Original Message----- > > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > > Sent: 08 August, 2003 00:42 > > > To: pana@research.telcordia.com > > > Subject: Issue4: (new) Device identifier (types) > > >=20 > > >=20 > > >=20 > > > http://www.danforsberg.info:8080/pana-issues/issue4 > > >=20 > > > The issue text refers to multi-homed hosts and device ID > > > changes. These are > > > covered under separate issues (#16 and #5). > > >=20 > > > So, issue #4 should only be talking about new DI types.=20 > And the one=20 > > > mentioned in the text is "subnet prefix." Unless anyone=20 > has another=20 > > > proposed device ID type, let's discuss that. > > >=20 > > > I'm trying to understand the utility of setting the DI as a > > > subnet prefix. > > > If this is proposed to enable mobile routers to connect=20 > to an access > > > network, we can easily achive that by using either a mac=20 > > > address DI along > > > with L2 ciphering, or a single IP address DI along with=20 > > > IPsec. In the latter > > > case, any IP address can be used inside the IPsec tunnel.=20 > > > Aside from not > > > needing it, I'm also not sure how we can use this DI as an=20 > > > IPsec end point. > > >=20 > > > Unless anybody objects, I recommend we reject this issue. > > >=20 > > > Comments please. > > >=20 > > > Alper > > > =20 > > >=20 > > >=20 > >=20 >=20 >=20 From pana-request@research.telcordia.com Thu Aug 14 04:28:06 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03449 for ; Thu, 14 Aug 2003 04:28:03 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7E8IQkE016242; Thu, 14 Aug 2003 04:18:26 -0400 (EDT) Resent-Date: Thu, 14 Aug 2003 04:18:26 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue4: (new) Device identifier (types) Date: Thu, 14 Aug 2003 11:18:21 +0300 Message-ID: Thread-Topic: Issue4: (new) Device identifier (types) Thread-Index: AcNhuGsbjkgsIxOkTnaF9w5wzhgfXwAIvEHAABgEumA= From: To: , Cc: , X-OriginalArrivalTime: 14 Aug 2003 08:18:22.0228 (UTC) FILETIME=[A03AE540:01C3623C] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Let's face the problem. If we don't bind the global=20 IP address to the PANA session, PaC is able to spoof=20 all the other (possibly authenticated) clients (and=20 in the worst case even network elements etc.). If you say this problem is out of scope of PANA, I don't agree with you. This is a question that needs to be=20 resolved in a standard. Otherwise vendors will do=20 something by their own. In short, PANA MUST provide support for IP address=20 spoofing prevention both with L2 and L3 ciphering, or=20 without ciphering at all. Otherwise we have a serious security problem. Since PANA has a SA and thus supports authenticated=20 messages between PaC and PAA, it is a proper protocol to use for IP address spoofing prevention. - Dan > -----Original Message----- > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > Sent: 13 August, 2003 23:47 > To: Yoshihiro Ohba; Forsberg Dan (NRC/Helsinki) > Cc: alper@docomolabs-usa.com; pana@research.telcordia.com > Subject: RE: Issue4: (new) Device identifier (types) >=20 >=20 >=20 > =20 > >=20 > > On Wed, Aug 13, 2003 at 05:01:45PM +0300,=20 > > Dan.Forsberg@nokia.com wrote: > > > One of the questions in IETF57 PANA wg meeting was that should PAA > > > take care of authorizing IP addresses. I think it should, because=20 > > > it informs the EPs about the filtering rules. > > >=20 > > > If I've understood correctly IPSec tunnel is used between PaC and > > > EP/PAA with link local addresses. Then the inner IP=20 > address in the=20 > > > IPSec tunnel should be PANA DI. In this case it could be a subnet=20 > > > prefix, right? > >=20 > > The inner IP address in the IPsec tunnel is not necessarily=20 > > be a PANA DI, since the outer IP address (i.e., a link local=20 > > IP address) can be used as a PANA DI. Authorization for the=20 > > inner IP address can be done in IKE negotiation by which an=20 > > appropriate per-packet filtering rule for the inner IP=20 > > address is set to IPsec SPD. IKE also supports negotiatin of=20 > > subnet-prefix parameters for inner packets. > >=20 > It is not possible to know the inner IP addresses always i.e the > dynamic SPD setup should be very simple. Just use the DI (link-local > in IPv6 or the DHCP address in IPv4) for binding to the Ipsec SA. >=20 > >=20 > > >=20 > > > If PANA uses MAC as the DI (and even with IPSec tunnel),=20 > > PAA/EP can't > > > control the IP addresses the PaC is using (inner IP=20 > address in the=20 > > > IPSec tunnel). Anyway, I firmly believe that access=20 > networks wount=20 > > > pass packets with ANY source IP address to the network=20 > (refusal to=20 > > > route). So I don't think that any IP address can be used=20 > inside the=20 > > > IPSec tunnel. > >=20 > > I think the required functionality of per-packet filtering=20 > > for inner packets is already covered by the combination of: > >=20 > > - Support of DI update (from MAC address to IP address). > >=20 > > - Use of link-local address as a DI when bootstrapping IKE. > >=20 > > - Use of IKE for establishing an tunnel mode IPsec SA between=20 > > PaC and EP. > > (as a result, an SPD entry for inner packet filtering will=20 > > be created.) > >=20 > As I mentioned in other mail, we don't need this. We are talking > about access control. MIC is sufficient for authorization.=20 >=20 > -mohan >=20 > > - Use of IPsec tunnel (whether inner packet filtering is done > > based on the created SPD entry). > >=20 > >=20 > > Yoshihiro Ohba > >=20 > >=20 > > >=20 > > > - Dan > > >=20 > > > > -----Original Message----- > > > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > > > Sent: 08 August, 2003 00:42 > > > > To: pana@research.telcordia.com > > > > Subject: Issue4: (new) Device identifier (types) > > > >=20 > > > >=20 > > > >=20 > > > > http://www.danforsberg.info:8080/pana-issues/issue4 > > > >=20 > > > > The issue text refers to multi-homed hosts and device ID > > > > changes. These are > > > > covered under separate issues (#16 and #5). > > > >=20 > > > > So, issue #4 should only be talking about new DI types.=20 > > And the one=20 > > > > mentioned in the text is "subnet prefix." Unless anyone=20 > > has another=20 > > > > proposed device ID type, let's discuss that. > > > >=20 > > > > I'm trying to understand the utility of setting the DI as a > > > > subnet prefix. > > > > If this is proposed to enable mobile routers to connect=20 > > to an access > > > > network, we can easily achive that by using either a mac=20 > > > > address DI along > > > > with L2 ciphering, or a single IP address DI along with=20 > > > > IPsec. In the latter > > > > case, any IP address can be used inside the IPsec tunnel.=20 > > > > Aside from not > > > > needing it, I'm also not sure how we can use this DI as an=20 > > > > IPsec end point. > > > >=20 > > > > Unless anybody objects, I recommend we reject this issue. > > > >=20 > > > > Comments please. > > > >=20 > > > > Alper > > > > =20 > > > >=20 > > > >=20 > > >=20 > >=20 > >=20 >=20 From pana-request@research.telcordia.com Thu Aug 14 12:08:38 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16539 for ; Thu, 14 Aug 2003 12:08:32 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7EFxSQl008192; Thu, 14 Aug 2003 11:59:28 -0400 (EDT) Resent-Date: Thu, 14 Aug 2003 11:59:28 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 12 Aug 2003 07:38:32 -0700 From: Yoshihiro Ohba Subject: Re: Issue4: (new) Device identifier (types) In-reply-to: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4B4@TNEXVS02.tahoenetworks.com> To: Mohan Parthasarathy Cc: Dan.Forsberg@nokia.com, alper@docomolabs-usa.com, pana@research.telcordia.com Message-id: <20030812143832.GA19909@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Dan.Forsberg@nokia.com, alper@docomolabs-usa.com, pana@research.telcordia.com User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 100 References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4B4@TNEXVS02.tahoenetworks.com> X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <1jHoJB.A.3_B.gH7O_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Wed, Aug 13, 2003 at 01:38:50PM -0700, Mohan Parthasarathy wrote: > > If PANA uses MAC as the DI (and even with IPSec tunnel), PAA/EP can't > > control the IP addresses the PaC is using (inner IP address in the > > IPSec tunnel). Anyway, I firmly believe that access networks wount > > pass packets with ANY source IP address to the network (refusal to > > route). So I don't think that any IP address can be used inside the > > IPSec tunnel. > > > I think it is not possible to know the IP address always. In IPv6, the > node could potentially use a RFC3041 private address and hard to know > what that address would be. That's why the current pana-ipsec draft > just relies only on the link-local address in IPv6 and that's what > is bound to the selectors. I'm not sure this is the only possible solution. One can bind the inner addresses to the selectors (via Identity payload exchange, or TS payload exchange in IKEv2) and update it when an inner address changes by re-negotiating the IPsec SA, or one can establish a distinct IPsec tunnel mode SA for each inner address with using IKE phase 2 Identity payload to construct the selector. > If it uses tunnel mode, then the > inner addresses would be unspecified during Ipsec SA negotiation. If we make the issue of inner address authorization out of the scope of PANA, then the inner addresses must be specified during IPsec SA negotiation. I am considering this method. If we make the issue of inner address authorization in the scope of PANA, then the inner addresses do not need to be specified during IPsec SA negotiation, but additional access control for the inner addresses will be needed outside the framework of IPsec. In this case, inner addresses should be used as PANA DI and communicated to the EP, as Dan is suggesting. > > If we are using Ipsec or other L2 cipher for access control, the > verification > of the MIC should be enough for access control. From the viewpoint of access control this is not enough. As Dan pointed out, authenticated attacker can spoof other authenticated clients' inner addresses. I think this should be prevented. > I don't think we > have to go beyond this in PANA i.e we don't need to provide all the > details on how this can be done. I think we need more discussion for the PANA-IPsec draft on the inner address authorization issue. Yoshihiro Ohba > > -mohan > > > - Dan > > > > > -----Original Message----- > > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > > Sent: 08 August, 2003 00:42 > > > To: pana@research.telcordia.com > > > Subject: Issue4: (new) Device identifier (types) > > > > > > > > > > > > http://www.danforsberg.info:8080/pana-issues/issue4 > > > > > > The issue text refers to multi-homed hosts and device ID > > > changes. These are > > > covered under separate issues (#16 and #5). > > > > > > So, issue #4 should only be talking about new DI types. And the one > > > mentioned in the text is "subnet prefix." Unless anyone has another > > > proposed device ID type, let's discuss that. > > > > > > I'm trying to understand the utility of setting the DI as a > > > subnet prefix. > > > If this is proposed to enable mobile routers to connect to an access > > > network, we can easily achive that by using either a mac > > > address DI along > > > with L2 ciphering, or a single IP address DI along with > > > IPsec. In the latter > > > case, any IP address can be used inside the IPsec tunnel. > > > Aside from not > > > needing it, I'm also not sure how we can use this DI as an > > > IPsec end point. > > > > > > Unless anybody objects, I recommend we reject this issue. > > > > > > Comments please. > > > > > > Alper > > > > > > > > > > > > > > From pana-request@research.telcordia.com Thu Aug 14 12:34:19 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17511 for ; Thu, 14 Aug 2003 12:34:18 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7EGQxW9009549; Thu, 14 Aug 2003 12:26:59 -0400 (EDT) Resent-Date: Thu, 14 Aug 2003 12:26:59 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 12 Aug 2003 08:06:19 -0700 From: Yoshihiro Ohba Subject: Re: Issue4: (new) Device identifier (types) In-reply-to: To: Dan.Forsberg@nokia.com Cc: mohanp@tahoenetworks.com, yohba@tari.toshiba.com, alper@docomolabs-usa.com, pana@research.telcordia.com Message-id: <20030812150619.GB19909@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, mohanp@tahoenetworks.com, yohba@tari.toshiba.com, alper@docomolabs-usa.com, pana@research.telcordia.com User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 173 References: X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Thu, Aug 14, 2003 at 11:18:21AM +0300, Dan.Forsberg@nokia.com wrote: > Let's face the problem. If we don't bind the global > IP address to the PANA session, PaC is able to spoof > all the other (possibly authenticated) clients (and > in the worst case even network elements etc.). I agree that inner address spoofing by authenticated attacker is a threat for the network access security. However, I don't think using the global IP address in addition to link local address is the only way to prevent the attack. As I mentioned in other email repled to Mohan, if inner address authorization is done in IPsec SA negotiation (and I think it can), the global IP address does not need to be directly bound to the PANA session and IPsec can perform inner address filtering based on the authorization result. > > If you say this problem is out of scope of PANA, I don't > agree with you. This is a question that needs to be > resolved in a standard. Otherwise vendors will do > something by their own. I agree that this needs to be resolved in a standard. But what I don't understand is why we can't rely on the functionality of IPsec for inner address authorization and resulting access control based on SPD. > > In short, PANA MUST provide support for IP address > spoofing prevention both with L2 and L3 ciphering, or > without ciphering at all. Otherwise we have a serious > security problem. Except for the following case: If neither L3 ciphering is used nor the lower-layer is physically secured, it is not possible to prevent IP address spoofing by authenticated attackers. > > Since PANA has a SA and thus supports authenticated > messages between PaC and PAA, it is a proper protocol > to use for IP address spoofing prevention. I believe IPsec is the proper protocol to use for IP address spoofing prevention. What PANA must do for this is to bootstap IPsec. Yoshihiro Ohba > > - Dan > > > -----Original Message----- > > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > Sent: 13 August, 2003 23:47 > > To: Yoshihiro Ohba; Forsberg Dan (NRC/Helsinki) > > Cc: alper@docomolabs-usa.com; pana@research.telcordia.com > > Subject: RE: Issue4: (new) Device identifier (types) > > > > > > > > > > > > > > On Wed, Aug 13, 2003 at 05:01:45PM +0300, > > > Dan.Forsberg@nokia.com wrote: > > > > One of the questions in IETF57 PANA wg meeting was that should PAA > > > > take care of authorizing IP addresses. I think it should, because > > > > it informs the EPs about the filtering rules. > > > > > > > > If I've understood correctly IPSec tunnel is used between PaC and > > > > EP/PAA with link local addresses. Then the inner IP > > address in the > > > > IPSec tunnel should be PANA DI. In this case it could be a subnet > > > > prefix, right? > > > > > > The inner IP address in the IPsec tunnel is not necessarily > > > be a PANA DI, since the outer IP address (i.e., a link local > > > IP address) can be used as a PANA DI. Authorization for the > > > inner IP address can be done in IKE negotiation by which an > > > appropriate per-packet filtering rule for the inner IP > > > address is set to IPsec SPD. IKE also supports negotiatin of > > > subnet-prefix parameters for inner packets. > > > > > It is not possible to know the inner IP addresses always i.e the > > dynamic SPD setup should be very simple. Just use the DI (link-local > > in IPv6 or the DHCP address in IPv4) for binding to the Ipsec SA. > > > > > > > > > > > > > If PANA uses MAC as the DI (and even with IPSec tunnel), > > > PAA/EP can't > > > > control the IP addresses the PaC is using (inner IP > > address in the > > > > IPSec tunnel). Anyway, I firmly believe that access > > networks wount > > > > pass packets with ANY source IP address to the network > > (refusal to > > > > route). So I don't think that any IP address can be used > > inside the > > > > IPSec tunnel. > > > > > > I think the required functionality of per-packet filtering > > > for inner packets is already covered by the combination of: > > > > > > - Support of DI update (from MAC address to IP address). > > > > > > - Use of link-local address as a DI when bootstrapping IKE. > > > > > > - Use of IKE for establishing an tunnel mode IPsec SA between > > > PaC and EP. > > > (as a result, an SPD entry for inner packet filtering will > > > be created.) > > > > > As I mentioned in other mail, we don't need this. We are talking > > about access control. MIC is sufficient for authorization. > > > > -mohan > > > > > - Use of IPsec tunnel (whether inner packet filtering is done > > > based on the created SPD entry). > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > - Dan > > > > > > > > > -----Original Message----- > > > > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > > > > Sent: 08 August, 2003 00:42 > > > > > To: pana@research.telcordia.com > > > > > Subject: Issue4: (new) Device identifier (types) > > > > > > > > > > > > > > > > > > > > http://www.danforsberg.info:8080/pana-issues/issue4 > > > > > > > > > > The issue text refers to multi-homed hosts and device ID > > > > > changes. These are > > > > > covered under separate issues (#16 and #5). > > > > > > > > > > So, issue #4 should only be talking about new DI types. > > > And the one > > > > > mentioned in the text is "subnet prefix." Unless anyone > > > has another > > > > > proposed device ID type, let's discuss that. > > > > > > > > > > I'm trying to understand the utility of setting the DI as a > > > > > subnet prefix. > > > > > If this is proposed to enable mobile routers to connect > > > to an access > > > > > network, we can easily achive that by using either a mac > > > > > address DI along > > > > > with L2 ciphering, or a single IP address DI along with > > > > > IPsec. In the latter > > > > > case, any IP address can be used inside the IPsec tunnel. > > > > > Aside from not > > > > > needing it, I'm also not sure how we can use this DI as an > > > > > IPsec end point. > > > > > > > > > > Unless anybody objects, I recommend we reject this issue. > > > > > > > > > > Comments please. > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Thu Aug 14 13:10:59 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18397 for ; Thu, 14 Aug 2003 13:10:58 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7EH3CP2011363; Thu, 14 Aug 2003 13:03:12 -0400 (EDT) Resent-Date: Thu, 14 Aug 2003 13:03:12 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue4: (new) Device identifier (types) Date: Thu, 14 Aug 2003 10:02:59 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4B5@TNEXVS02.tahoenetworks.com> Thread-Topic: Issue4: (new) Device identifier (types) Thread-Index: AcNhuGsbjkgsIxOkTnaF9w5wzhgfXwAIvEHAABgEumAAEnQo4A== From: "Mohan Parthasarathy" To: , Cc: , X-OriginalArrivalTime: 14 Aug 2003 17:02:59.0490 (UTC) FILETIME=[EA23E820:01C36285] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable >=20 > Let's face the problem. If we don't bind the global=20 > IP address to the PANA session, PaC is able to spoof=20 > all the other (possibly authenticated) clients (and=20 > in the worst case even network elements etc.). >=20 > If you say this problem is out of scope of PANA, I don't > agree with you. This is a question that needs to be=20 > resolved in a standard. Otherwise vendors will do=20 > something by their own. >=20 Please point to me where in requirements is this specified ? At least I don't remember reading one. The important goal of the working group is to specify PANA protocol. And we also agreed that we will come up with some mechanism to provide access control. We are documenting one way of doing this i.e using Ipsec. Now we can keep adding more to this list. We can explore to see if we can use Ipsec to solve all the problems. But is this really in scope ? If Ipsec solves it for free, then it is fine. But I still strongly feel that it is not in the scope. -mohan > In short, PANA MUST provide support for IP address=20 > spoofing prevention both with L2 and L3 ciphering, or=20 > without ciphering at all. Otherwise we have a serious > security problem. >=20 > Since PANA has a SA and thus supports authenticated=20 > messages between PaC and PAA, it is a proper protocol > to use for IP address spoofing prevention. >=20 > - Dan >=20 > > -----Original Message----- > > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > Sent: 13 August, 2003 23:47 > > To: Yoshihiro Ohba; Forsberg Dan (NRC/Helsinki) > > Cc: alper@docomolabs-usa.com; pana@research.telcordia.com > > Subject: RE: Issue4: (new) Device identifier (types) > >=20 > >=20 > >=20 > > =20 > > >=20 > > > On Wed, Aug 13, 2003 at 05:01:45PM +0300, > > > Dan.Forsberg@nokia.com wrote: > > > > One of the questions in IETF57 PANA wg meeting was that=20 > should PAA=20 > > > > take care of authorizing IP addresses. I think it=20 > should, because=20 > > > > it informs the EPs about the filtering rules. > > > >=20 > > > > If I've understood correctly IPSec tunnel is used=20 > between PaC and=20 > > > > EP/PAA with link local addresses. Then the inner IP > > address in the > > > > IPSec tunnel should be PANA DI. In this case it could=20 > be a subnet > > > > prefix, right? > > >=20 > > > The inner IP address in the IPsec tunnel is not necessarily > > > be a PANA DI, since the outer IP address (i.e., a link local=20 > > > IP address) can be used as a PANA DI. Authorization for the=20 > > > inner IP address can be done in IKE negotiation by which an=20 > > > appropriate per-packet filtering rule for the inner IP=20 > > > address is set to IPsec SPD. IKE also supports negotiatin of=20 > > > subnet-prefix parameters for inner packets. > > >=20 > > It is not possible to know the inner IP addresses always i.e the=20 > > dynamic SPD setup should be very simple. Just use the DI=20 > (link-local=20 > > in IPv6 or the DHCP address in IPv4) for binding to the Ipsec SA. > >=20 > > >=20 > > > >=20 > > > > If PANA uses MAC as the DI (and even with IPSec tunnel), > > > PAA/EP can't > > > > control the IP addresses the PaC is using (inner IP > > address in the > > > > IPSec tunnel). Anyway, I firmly believe that access > > networks wount > > > > pass packets with ANY source IP address to the network > > (refusal to > > > > route). So I don't think that any IP address can be used > > inside the > > > > IPSec tunnel. > > >=20 > > > I think the required functionality of per-packet filtering > > > for inner packets is already covered by the combination of: > > >=20 > > > - Support of DI update (from MAC address to IP address). > > >=20 > > > - Use of link-local address as a DI when bootstrapping IKE. > > >=20 > > > - Use of IKE for establishing an tunnel mode IPsec SA between > > > PaC and EP. > > > (as a result, an SPD entry for inner packet filtering will=20 > > > be created.) > > >=20 > > As I mentioned in other mail, we don't need this. We are=20 > talking about=20 > > access control. MIC is sufficient for authorization. > >=20 > > -mohan > >=20 > > > - Use of IPsec tunnel (whether inner packet filtering is done > > > based on the created SPD entry). > > >=20 > > >=20 > > > Yoshihiro Ohba > > >=20 > > >=20 > > > >=20 > > > > - Dan > > > >=20 > > > > > -----Original Message----- > > > > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > > > > Sent: 08 August, 2003 00:42 > > > > > To: pana@research.telcordia.com > > > > > Subject: Issue4: (new) Device identifier (types) > > > > >=20 > > > > >=20 > > > > >=20 > > > > > http://www.danforsberg.info:8080/pana-issues/issue4 > > > > >=20 > > > > > The issue text refers to multi-homed hosts and device ID=20 > > > > > changes. These are covered under separate issues (#16 and #5). > > > > >=20 > > > > > So, issue #4 should only be talking about new DI types. > > > And the one > > > > > mentioned in the text is "subnet prefix." Unless anyone > > > has another > > > > > proposed device ID type, let's discuss that. > > > > >=20 > > > > > I'm trying to understand the utility of setting the DI as a=20 > > > > > subnet prefix. If this is proposed to enable mobile=20 > routers to=20 > > > > > connect > > > to an access > > > > > network, we can easily achive that by using either a mac > > > > > address DI along > > > > > with L2 ciphering, or a single IP address DI along with=20 > > > > > IPsec. In the latter > > > > > case, any IP address can be used inside the IPsec tunnel.=20 > > > > > Aside from not > > > > > needing it, I'm also not sure how we can use this DI as an=20 > > > > > IPsec end point. > > > > >=20 > > > > > Unless anybody objects, I recommend we reject this issue. > > > > >=20 > > > > > Comments please. > > > > >=20 > > > > > Alper > > > > > =20 > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 >=20 From pana-request@research.telcordia.com Thu Aug 14 13:19:31 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18642 for ; Thu, 14 Aug 2003 13:19:30 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7EHCSSe012059; Thu, 14 Aug 2003 13:12:28 -0400 (EDT) Resent-Date: Thu, 14 Aug 2003 13:12:28 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue4: (new) Device identifier (types) Date: Thu, 14 Aug 2003 10:11:54 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4B6@TNEXVS02.tahoenetworks.com> Thread-Topic: Issue4: (new) Device identifier (types) Thread-Index: AcNifRCLslATG1Q3SACalWsisDnPBQACNveA From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: , , X-OriginalArrivalTime: 14 Aug 2003 17:11:54.0567 (UTC) FILETIME=[29122D70:01C36287] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable =20 >=20 > On Wed, Aug 13, 2003 at 01:38:50PM -0700, Mohan Parthasarathy wrote: > > > If PANA uses MAC as the DI (and even with IPSec tunnel), PAA/EP=20 > > > can't > > > control the IP addresses the PaC is using (inner IP=20 > address in the=20 > > > IPSec tunnel). Anyway, I firmly believe that access=20 > networks wount=20 > > > pass packets with ANY source IP address to the network=20 > (refusal to=20 > > > route). So I don't think that any IP address can be used=20 > inside the=20 > > > IPSec tunnel. > > >=20 > > I think it is not possible to know the IP address always.=20 > In IPv6, the=20 > > node could potentially use a RFC3041 private address and=20 > hard to know=20 > > what that address would be. That's why the current pana-ipsec draft=20 > > just relies only on the link-local address in IPv6 and=20 > that's what is=20 > > bound to the selectors. >=20 > I'm not sure this is the only possible solution. One can=20 > bind the inner addresses to the selectors (via Identity=20 > payload exchange, or TS payload exchange in IKEv2) and update=20 > it when an inner address changes by re-negotiating the IPsec=20 > SA, or one can establish a distinct IPsec tunnel mode SA for=20 > each inner address with using IKE phase 2 Identity payload to=20 > construct the selector. >=20 How does the EP know about these selectors ? Before the Ipsec negotiation starts, the other end should have a configured SPD entry for the addresses that you specify in the traffic selector. Tell me how the EP knows about these addresses. > > If it uses tunnel mode, then the > > inner addresses would be unspecified during Ipsec SA negotiation. >=20 > If we make the issue of inner address authorization out of=20 > the scope of PANA, then the inner addresses must be specified=20 > during IPsec SA negotiation. I am considering this method. >=20 I am not sure I understand this. Could you rephrase ? If it outside the scope, then why specify any inner address at all ? > If we make the issue of inner address authorization in the=20 > scope of PANA, then the inner addresses do not need to be=20 > specified during IPsec SA negotiation, but additional access=20 > control for the inner addresses will be needed outside the=20 > framework of IPsec. In this case, inner addresses should be=20 > used as PANA DI and communicated to the EP, as Dan is suggesting. >=20 I am not sure I understand this detail. Note that if someone wants to use Ipsec for preventing the spoofing problem, then it is fine. I just have one question mentioned above. All I am saying is we don't need to go in to a lot of details explaining how to do it. Perhaps we can mention briefly the issue in security consideration. > >=20 > > If we are using Ipsec or other L2 cipher for access control, the=20 > > verification of the MIC should be enough for access control. >=20 > From the viewpoint of access control this is not enough. As Dan=20 > pointed out, authenticated attacker can spoof other authenticated=20 > clients' inner addresses. I think this should be prevented. >=20 Why ? The client is authorized to use the network if he has the right key. Yes, we can do lots more. I am still not convinced that this is in the scope though. > > I don't think we > > have to go beyond this in PANA i.e we don't need to provide all the=20 > > details on how this can be done. >=20 > I think we need more discussion for the PANA-IPsec draft on the=20 > inner address authorization issue. >=20 Ok. Let us have the discussion here first as to what issues we need to solve. I am missing the requirements on this. -mohan > Yoshihiro Ohba >=20 >=20 > >=20 > > -mohan > >=20 > > > - Dan > > >=20 > > > > -----Original Message----- > > > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > > > Sent: 08 August, 2003 00:42 > > > > To: pana@research.telcordia.com > > > > Subject: Issue4: (new) Device identifier (types) > > > >=20 > > > >=20 > > > >=20 > > > > http://www.danforsberg.info:8080/pana-issues/issue4 > > > >=20 > > > > The issue text refers to multi-homed hosts and device=20 > ID changes.=20 > > > > These are covered under separate issues (#16 and #5). > > > >=20 > > > > So, issue #4 should only be talking about new DI types. And the=20 > > > > one > > > > mentioned in the text is "subnet prefix." Unless anyone=20 > has another=20 > > > > proposed device ID type, let's discuss that. > > > >=20 > > > > I'm trying to understand the utility of setting the DI=20 > as a subnet=20 > > > > prefix. If this is proposed to enable mobile routers to=20 > connect to=20 > > > > an access network, we can easily achive that by using=20 > either a mac > > > > address DI along > > > > with L2 ciphering, or a single IP address DI along with=20 > > > > IPsec. In the latter > > > > case, any IP address can be used inside the IPsec tunnel.=20 > > > > Aside from not > > > > needing it, I'm also not sure how we can use this DI as an=20 > > > > IPsec end point. > > > >=20 > > > > Unless anybody objects, I recommend we reject this issue. > > > >=20 > > > > Comments please. > > > >=20 > > > > Alper > > > > =20 > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 >=20 From pana-request@research.telcordia.com Thu Aug 14 14:14:09 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20911 for ; Thu, 14 Aug 2003 14:14:04 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7EI56AD014799; Thu, 14 Aug 2003 14:05:06 -0400 (EDT) Resent-Date: Thu, 14 Aug 2003 14:05:06 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Tue, 12 Aug 2003 09:46:38 -0700 From: Yoshihiro Ohba Subject: Re: Issue4: (new) Device identifier (types) In-reply-to: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4B6@TNEXVS02.tahoenetworks.com> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Dan.Forsberg@nokia.com, alper@docomolabs-usa.com, pana@research.telcordia.com Message-id: <20030812164638.GC19909@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Dan.Forsberg@nokia.com, alper@docomolabs-usa.com, pana@research.telcordia.com User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 120 References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4B6@TNEXVS02.tahoenetworks.com> X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <01-GcB.A.GnD.R98O_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Thu, Aug 14, 2003 at 10:11:54AM -0700, Mohan Parthasarathy wrote: > > > > > > On Wed, Aug 13, 2003 at 01:38:50PM -0700, Mohan Parthasarathy wrote: > > > > If PANA uses MAC as the DI (and even with IPSec tunnel), PAA/EP > > > > can't > > > > control the IP addresses the PaC is using (inner IP > > address in the > > > > IPSec tunnel). Anyway, I firmly believe that access > > networks wount > > > > pass packets with ANY source IP address to the network > > (refusal to > > > > route). So I don't think that any IP address can be used > > inside the > > > > IPSec tunnel. > > > > > > > I think it is not possible to know the IP address always. > > In IPv6, the > > > node could potentially use a RFC3041 private address and > > hard to know > > > what that address would be. That's why the current pana-ipsec draft > > > just relies only on the link-local address in IPv6 and > > that's what is > > > bound to the selectors. > > > > I'm not sure this is the only possible solution. One can > > bind the inner addresses to the selectors (via Identity > > payload exchange, or TS payload exchange in IKEv2) and update > > it when an inner address changes by re-negotiating the IPsec > > SA, or one can establish a distinct IPsec tunnel mode SA for > > each inner address with using IKE phase 2 Identity payload to > > construct the selector. > > > How does the EP know about these selectors ? Before the Ipsec > negotiation starts, the other end should have a configured > SPD entry for the addresses that you specify in the traffic > selector. Tell me how the EP knows about these addresses. The selectors can be dynamically negotiated by using IKE or IKEv2. Though some IPsec implementation may configure SPD IPsec negotiation, there is basically no need to have SPD configured before IPsec negotiation starts. As I mentioned above those inner addresses can be known by EP (which is an IKE or IKEv2 responder in this case) via IPsec SA negotiation through IKE or IKEv2. > > > > If it uses tunnel mode, then the > > > inner addresses would be unspecified during Ipsec SA negotiation. > > > > If we make the issue of inner address authorization out of > > the scope of PANA, then the inner addresses must be specified > > during IPsec SA negotiation. I am considering this method. > > > I am not sure I understand this. Could you rephrase ? If it outside > the scope, then why specify any inner address at all ? Let me rephrase this: If we make the issue of inner address authorization out of the scope of PANA *protocol*, then the inner addresses must be communicated from PaC to EP and authorized by the EP through IKE or IKEv2. > > > If we make the issue of inner address authorization in the > > scope of PANA, then the inner addresses do not need to be > > specified during IPsec SA negotiation, but additional access > > control for the inner addresses will be needed outside the > > framework of IPsec. In this case, inner addresses should be > > used as PANA DI and communicated to the EP, as Dan is suggesting. > > > I am not sure I understand this detail. Let me rephrase this: If we make the issue of inner address authorization in the scope of PANA *protocol*, then the inner addresses do not need to be communicated from PaC to EP through IKE or IKEv2, but additional access control for the inner addresses will be needed outside the framework of IPsec. In this case, inner addresses should be used as PANA DI and communicated to the EP, as Dan is suggesting. > > Note that if someone wants to use Ipsec for preventing the spoofing > problem, then it is fine. I just have one question mentioned above. > All I am saying is we don't need to go in to a lot of details > explaining > how to do it. Perhaps we can mention briefly the issue in security > consideration. This might be a way, if that is enough to maitain interoperability, but I'm not sure. > > > > > > > If we are using Ipsec or other L2 cipher for access control, the > > > verification of the MIC should be enough for access control. > > > > From the viewpoint of access control this is not enough. As Dan > > pointed out, authenticated attacker can spoof other authenticated > > clients' inner addresses. I think this should be prevented. > > > Why ? The client is authorized to use the network if he has the > right key. Yes, we can do lots more. I am still not convinced > that this is in the scope though. > > > > I don't think we > > > have to go beyond this in PANA i.e we don't need to provide all the > > > details on how this can be done. > > > > I think we need more discussion for the PANA-IPsec draft on the > > inner address authorization issue. > > > Ok. Let us have the discussion here first as to what issues we need > to solve. I am missing the requirements on this. > > -mohan > Yoshihiro Ohba From pana-request@research.telcordia.com Thu Aug 14 14:55:07 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21872 for ; Thu, 14 Aug 2003 14:55:07 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7EIllA2016857; Thu, 14 Aug 2003 14:47:47 -0400 (EDT) Resent-Date: Thu, 14 Aug 2003 14:47:47 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue4: (new) Device identifier (types) Date: Thu, 14 Aug 2003 11:47:40 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4B7@TNEXVS02.tahoenetworks.com> Thread-Topic: Issue4: (new) Device identifier (types) Thread-Index: AcNijpebmluLHk29SV+hWmlJwdTfrAAA5UXw From: "Mohan Parthasarathy" To: "Yoshihiro Ohba" Cc: , , X-OriginalArrivalTime: 14 Aug 2003 18:47:41.0182 (UTC) FILETIME=[8A5209E0:01C36294] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable =20 > > >=20 > > How does the EP know about these selectors ? Before the Ipsec=20 > > negotiation starts, the other end should have a configured=20 > SPD entry=20 > > for the addresses that you specify in the traffic selector. Tell me=20 > > how the EP knows about these addresses. >=20 > The selectors can be dynamically negotiated by using IKE or=20 > IKEv2. Though some IPsec implementation may configure SPD=20 > IPsec negotiation, there is basically no need to have SPD=20 > configured before IPsec negotiation starts. So, I can put in any address and the other end will accept it ? Note that we are talking about tunnel mode Sas and the addresses we are negotiating are inner addresses. If I can put in any address for the inner address and the other end will accept it, then we have not solved the problem yet. If you want to know whether I am authorized to use a particular address, you need SEND. In mobile IP, the home agent needs to maintain a table of ID - address, and it verifies this during the Ipsec SA setup whether the address specified in the traffic selector can be used by this ID. You need=20 > As I mentioned=20 > above those inner addresses can be known by EP (which is an=20 > IKE or IKEv2 responder in this case) via IPsec SA negotiation=20 > through IKE or IKEv2. =20 >=20 IKE responder address is DI - the link-local address. You still cannot possibly not know all the addresses the Pac will use. =20 > >=20 > > > > If it uses tunnel mode, then the > > > > inner addresses would be unspecified during Ipsec SA=20 > negotiation. > > >=20 > > > If we make the issue of inner address authorization out of > > > the scope of PANA, then the inner addresses must be specified=20 > > > during IPsec SA negotiation. I am considering this method. > > >=20 > > I am not sure I understand this. Could you rephrase ? If it outside=20 > > the scope, then why specify any inner address at all ? >=20 > Let me rephrase this: >=20 > If we make the issue of inner address authorization out of the scope > of PANA *protocol*, then the inner addresses must be=20 > communicated from PaC to > EP and authorized by the EP through IKE or IKEv2. How do you authorize the use of a given IP address using IKE or IKEv2 ? -mohan >=20 > >=20 > > > If we make the issue of inner address authorization in the > > > scope of PANA, then the inner addresses do not need to be=20 > > > specified during IPsec SA negotiation, but additional access=20 > > > control for the inner addresses will be needed outside the=20 > > > framework of IPsec. In this case, inner addresses should be=20 > > > used as PANA DI and communicated to the EP, as Dan is suggesting. > > >=20 > > I am not sure I understand this detail. >=20 > Let me rephrase this: >=20 > If we make the issue of inner address authorization in the scope of > PANA *protocol*, then the inner addresses do not need to be > communicated from PaC to EP through IKE or IKEv2, but additional > access control for the inner addresses will be needed outside the > framework of IPsec. In this case, inner addresses should be used as > PANA DI and communicated to the EP, as Dan is suggesting. >=20 > >=20 > > Note that if someone wants to use Ipsec for preventing the spoofing=20 > > problem, then it is fine. I just have one question mentioned above.=20 > > All I am saying is we don't need to go in to a lot of details=20 > > explaining how to do it. Perhaps we can mention briefly the=20 > issue in=20 > > security consideration. >=20 > This might be a way, if that is enough to maitain=20 > interoperability, but I'm not sure. > >=20 > >=20 > > > >=20 > > > > If we are using Ipsec or other L2 cipher for access control, the > > > > verification of the MIC should be enough for access control. > > >=20 > > > From the viewpoint of access control this is not enough. As Dan > > > pointed out, authenticated attacker can spoof other authenticated=20 > > > clients' inner addresses. I think this should be prevented. > > >=20 > > Why ? The client is authorized to use the network if he has=20 > the right=20 > > key. Yes, we can do lots more. I am still not convinced=20 > that this is=20 > > in the scope though. > >=20 > > > > I don't think we > > > > have to go beyond this in PANA i.e we don't need to provide all=20 > > > > the > > > > details on how this can be done. > > >=20 > > > I think we need more discussion for the PANA-IPsec draft on the > > > inner address authorization issue. > > >=20 > > Ok. Let us have the discussion here first as to what issues=20 > we need to=20 > > solve. I am missing the requirements on this. > >=20 > > -mohan > >=20 >=20 > Yoshihiro Ohba >=20 From pana-request@research.telcordia.com Fri Aug 15 03:26:44 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20482 for ; Fri, 15 Aug 2003 03:26:37 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7F7DDFp006107; Fri, 15 Aug 2003 03:13:13 -0400 (EDT) Resent-Date: Fri, 15 Aug 2003 03:13:13 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Issue4: (new) Device identifier (types) Date: Fri, 15 Aug 2003 10:12:45 +0300 Message-ID: Thread-Topic: Issue4: (new) Device identifier (types) Thread-Index: AcNigGnId7A4SF7cTa2Yg696OnN5NQAem4/g From: To: Cc: , , X-OriginalArrivalTime: 15 Aug 2003 07:12:46.0569 (UTC) FILETIME=[A0CEBD90:01C362FC] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > In short, PANA MUST provide support for IP address > > spoofing prevention both with L2 and L3 ciphering, or > > without ciphering at all. Otherwise we have a serious > > security problem. > > Except for the following case: If neither L3 ciphering is used nor the > lower-layer is physically secured, it is not possible to prevent IP > address spoofing by authenticated attackers. The security can be enhanced here too. If only authenticated nodes with authorized IP addresses can send packets, then spoofing other addresses (like IP addresses that are not currently authorized for usage and other network prefixes that are not on the same link) is not possible. > > > > Since PANA has a SA and thus supports authenticated > > messages between PaC and PAA, it is a proper protocol > > to use for IP address spoofing prevention. > > I believe IPsec is the proper protocol to use for IP address spoofing > prevention. What PANA must do for this is to bootstap IPsec. IPSec is not always used. Consider the case with physically secure links. I suggest that PANA lists all the IP addresses it is using. If changes are required, PANA-Reauth messages can be used (updating the list of IP addresses/prefixes in use). Authorization decision for the IP address usage can be set out of the scope of PANA. For example draft-tschofenig-pana-bootstrap-rfc3118-00.txt can help in this authorization decision. - Dan > > Yoshihiro Ohba > > > > > - Dan > > > > > -----Original Message----- > > > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > > Sent: 13 August, 2003 23:47 > > > To: Yoshihiro Ohba; Forsberg Dan (NRC/Helsinki) > > > Cc: alper@docomolabs-usa.com; pana@research.telcordia.com > > > Subject: RE: Issue4: (new) Device identifier (types) > > > > > > > > > > > > > > > > > > > > On Wed, Aug 13, 2003 at 05:01:45PM +0300, > > > > Dan.Forsberg@nokia.com wrote: > > > > > One of the questions in IETF57 PANA wg meeting was > that should PAA > > > > > take care of authorizing IP addresses. I think it > should, because > > > > > it informs the EPs about the filtering rules. > > > > > > > > > > If I've understood correctly IPSec tunnel is used > between PaC and > > > > > EP/PAA with link local addresses. Then the inner IP > > > address in the > > > > > IPSec tunnel should be PANA DI. In this case it could > be a subnet > > > > > prefix, right? > > > > > > > > The inner IP address in the IPsec tunnel is not necessarily > > > > be a PANA DI, since the outer IP address (i.e., a link local > > > > IP address) can be used as a PANA DI. Authorization for the > > > > inner IP address can be done in IKE negotiation by which an > > > > appropriate per-packet filtering rule for the inner IP > > > > address is set to IPsec SPD. IKE also supports negotiatin of > > > > subnet-prefix parameters for inner packets. > > > > > > > It is not possible to know the inner IP addresses always i.e the > > > dynamic SPD setup should be very simple. Just use the DI > (link-local > > > in IPv6 or the DHCP address in IPv4) for binding to the Ipsec SA. > > > > > > > > > > > > > > > > > If PANA uses MAC as the DI (and even with IPSec tunnel), > > > > PAA/EP can't > > > > > control the IP addresses the PaC is using (inner IP > > > address in the > > > > > IPSec tunnel). Anyway, I firmly believe that access > > > networks wount > > > > > pass packets with ANY source IP address to the network > > > (refusal to > > > > > route). So I don't think that any IP address can be used > > > inside the > > > > > IPSec tunnel. > > > > > > > > I think the required functionality of per-packet filtering > > > > for inner packets is already covered by the combination of: > > > > > > > > - Support of DI update (from MAC address to IP address). > > > > > > > > - Use of link-local address as a DI when bootstrapping IKE. > > > > > > > > - Use of IKE for establishing an tunnel mode IPsec SA between > > > > PaC and EP. > > > > (as a result, an SPD entry for inner packet filtering will > > > > be created.) > > > > > > > As I mentioned in other mail, we don't need this. We are talking > > > about access control. MIC is sufficient for authorization. > > > > > > -mohan > > > > > > > - Use of IPsec tunnel (whether inner packet filtering is done > > > > based on the created SPD entry). > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > - Dan > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > > > > > Sent: 08 August, 2003 00:42 > > > > > > To: pana@research.telcordia.com > > > > > > Subject: Issue4: (new) Device identifier (types) > > > > > > > > > > > > > > > > > > > > > > > > http://www.danforsberg.info:8080/pana-issues/issue4 > > > > > > > > > > > > The issue text refers to multi-homed hosts and device ID > > > > > > changes. These are > > > > > > covered under separate issues (#16 and #5). > > > > > > > > > > > > So, issue #4 should only be talking about new DI types. > > > > And the one > > > > > > mentioned in the text is "subnet prefix." Unless anyone > > > > has another > > > > > > proposed device ID type, let's discuss that. > > > > > > > > > > > > I'm trying to understand the utility of setting the DI as a > > > > > > subnet prefix. > > > > > > If this is proposed to enable mobile routers to connect > > > > to an access > > > > > > network, we can easily achive that by using either a mac > > > > > > address DI along > > > > > > with L2 ciphering, or a single IP address DI along with > > > > > > IPsec. In the latter > > > > > > case, any IP address can be used inside the IPsec tunnel. > > > > > > Aside from not > > > > > > needing it, I'm also not sure how we can use this DI as an > > > > > > IPsec end point. > > > > > > > > > > > > Unless anybody objects, I recommend we reject this issue. > > > > > > > > > > > > Comments please. > > > > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Fri Aug 15 03:49:39 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20801 for ; Fri, 15 Aug 2003 03:49:39 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7F7c6Hr006970; Fri, 15 Aug 2003 03:38:06 -0400 (EDT) Resent-Date: Fri, 15 Aug 2003 03:38:06 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue4: (new) Device identifier (types) Date: Fri, 15 Aug 2003 10:37:57 +0300 Message-ID: Thread-Topic: Issue4: (new) Device identifier (types) Thread-Index: AcNhuGsbjkgsIxOkTnaF9w5wzhgfXwAIvEHAABgEumAAEnQo4AAeArBg From: To: , Cc: , X-OriginalArrivalTime: 15 Aug 2003 07:37:57.0739 (UTC) FILETIME=[2588FBB0:01C36300] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Mohan, Here are some references to the requirements document. draft-ietf-pana-requirements-07.txt: 4.1.2. Authorization, Accounting and Access Control =20 =20 After a device is authenticated using PANA, it MUST be authorized=20 for "network access." That is, the core requirement of PANA is to=20 verify the authorization of a PaC so that PaC's device may send and=20 receive any IP packets. draft-ietf-pana-requirements-07.txt: 4.4. PAA-to-EP Protocol=20 =20 PANA does not assume that the PAA is always co-located with the=20 EP(s). Network access enforcement can be provided by one or more=20 nodes on the same IP subnet as the client (e.g., multiple routers),=20 or on another subnet in the access domain (e.g., gateway to the=20 Internet, depending on the network architecture). When the PAA and=20 the EP(s) are separated, there needs to be another transport for=20 client provisioning. This transport is needed to create access=20 control lists to allow authenticated and authorized clients' traffic=20 through the EPs. PANA Working Group will preferably identify an=20 existing protocol solution that allows the PAA to deliver the=20 authorization information to one or more EPs when the PAA is=20 separated from EPs. Authorization for "network access" includes IP address authorization.=20 The requirements spec (above) says "-- so that PaC's device may send and receive any IP packets". My interpretation about this is that in the=20 beginning PaC is able to communicate only to the PAA, but after=20 authentication and authorization PaC is able to really access the=20 Internet. Also, PAA needs to have the info of PaC's IP address(es) for PAA-to-EP=20 protocol to carry it to the EP that really needs this info for=20 access control. So, this really is in the scope of PANA. - Dan > -----Original Message----- > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > Sent: 14 August, 2003 20:03 > To: Forsberg Dan (NRC/Helsinki); yohba@tari.toshiba.com > Cc: alper@docomolabs-usa.com; pana@research.telcordia.com > Subject: RE: Issue4: (new) Device identifier (types) >=20 >=20 >=20 > >=20 > > Let's face the problem. If we don't bind the global=20 > > IP address to the PANA session, PaC is able to spoof=20 > > all the other (possibly authenticated) clients (and=20 > > in the worst case even network elements etc.). > >=20 > > If you say this problem is out of scope of PANA, I don't > > agree with you. This is a question that needs to be=20 > > resolved in a standard. Otherwise vendors will do=20 > > something by their own. > >=20 > Please point to me where in requirements is this specified ? > At least I don't remember reading one. >=20 > The important goal of the working group is to specify PANA > protocol. And we also agreed that we will come up with some > mechanism to provide access control. We are documenting > one way of doing this i.e using Ipsec. Now we can keep > adding more to this list. We can explore to see if we > can use Ipsec to solve all the problems. But is this > really in scope ? If Ipsec solves it for free, then it > is fine. But I still strongly feel that it is not in > the scope. >=20 > -mohan >=20 > > In short, PANA MUST provide support for IP address=20 > > spoofing prevention both with L2 and L3 ciphering, or=20 > > without ciphering at all. Otherwise we have a serious > > security problem. > >=20 > > Since PANA has a SA and thus supports authenticated=20 > > messages between PaC and PAA, it is a proper protocol > > to use for IP address spoofing prevention. > >=20 > > - Dan > >=20 > > > -----Original Message----- > > > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > > Sent: 13 August, 2003 23:47 > > > To: Yoshihiro Ohba; Forsberg Dan (NRC/Helsinki) > > > Cc: alper@docomolabs-usa.com; pana@research.telcordia.com > > > Subject: RE: Issue4: (new) Device identifier (types) > > >=20 > > >=20 > > >=20 > > > =20 > > > >=20 > > > > On Wed, Aug 13, 2003 at 05:01:45PM +0300, > > > > Dan.Forsberg@nokia.com wrote: > > > > > One of the questions in IETF57 PANA wg meeting was that=20 > > should PAA=20 > > > > > take care of authorizing IP addresses. I think it=20 > > should, because=20 > > > > > it informs the EPs about the filtering rules. > > > > >=20 > > > > > If I've understood correctly IPSec tunnel is used=20 > > between PaC and=20 > > > > > EP/PAA with link local addresses. Then the inner IP > > > address in the > > > > > IPSec tunnel should be PANA DI. In this case it could=20 > > be a subnet > > > > > prefix, right? > > > >=20 > > > > The inner IP address in the IPsec tunnel is not necessarily > > > > be a PANA DI, since the outer IP address (i.e., a link local=20 > > > > IP address) can be used as a PANA DI. Authorization for the=20 > > > > inner IP address can be done in IKE negotiation by which an=20 > > > > appropriate per-packet filtering rule for the inner IP=20 > > > > address is set to IPsec SPD. IKE also supports negotiatin of=20 > > > > subnet-prefix parameters for inner packets. > > > >=20 > > > It is not possible to know the inner IP addresses always i.e the=20 > > > dynamic SPD setup should be very simple. Just use the DI=20 > > (link-local=20 > > > in IPv6 or the DHCP address in IPv4) for binding to the Ipsec SA. > > >=20 > > > >=20 > > > > >=20 > > > > > If PANA uses MAC as the DI (and even with IPSec tunnel), > > > > PAA/EP can't > > > > > control the IP addresses the PaC is using (inner IP > > > address in the > > > > > IPSec tunnel). Anyway, I firmly believe that access > > > networks wount > > > > > pass packets with ANY source IP address to the network > > > (refusal to > > > > > route). So I don't think that any IP address can be used > > > inside the > > > > > IPSec tunnel. > > > >=20 > > > > I think the required functionality of per-packet filtering > > > > for inner packets is already covered by the combination of: > > > >=20 > > > > - Support of DI update (from MAC address to IP address). > > > >=20 > > > > - Use of link-local address as a DI when bootstrapping IKE. > > > >=20 > > > > - Use of IKE for establishing an tunnel mode IPsec SA between > > > > PaC and EP. > > > > (as a result, an SPD entry for inner packet filtering will=20 > > > > be created.) > > > >=20 > > > As I mentioned in other mail, we don't need this. We are=20 > > talking about=20 > > > access control. MIC is sufficient for authorization. > > >=20 > > > -mohan > > >=20 > > > > - Use of IPsec tunnel (whether inner packet filtering is done > > > > based on the created SPD entry). > > > >=20 > > > >=20 > > > > Yoshihiro Ohba > > > >=20 > > > >=20 > > > > >=20 > > > > > - Dan > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > > > > > Sent: 08 August, 2003 00:42 > > > > > > To: pana@research.telcordia.com > > > > > > Subject: Issue4: (new) Device identifier (types) > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > http://www.danforsberg.info:8080/pana-issues/issue4 > > > > > >=20 > > > > > > The issue text refers to multi-homed hosts and device ID=20 > > > > > > changes. These are covered under separate issues=20 > (#16 and #5). > > > > > >=20 > > > > > > So, issue #4 should only be talking about new DI types. > > > > And the one > > > > > > mentioned in the text is "subnet prefix." Unless anyone > > > > has another > > > > > > proposed device ID type, let's discuss that. > > > > > >=20 > > > > > > I'm trying to understand the utility of setting the DI as a=20 > > > > > > subnet prefix. If this is proposed to enable mobile=20 > > routers to=20 > > > > > > connect > > > > to an access > > > > > > network, we can easily achive that by using either a mac > > > > > > address DI along > > > > > > with L2 ciphering, or a single IP address DI along with=20 > > > > > > IPsec. In the latter > > > > > > case, any IP address can be used inside the IPsec tunnel.=20 > > > > > > Aside from not > > > > > > needing it, I'm also not sure how we can use this DI as an=20 > > > > > > IPsec end point. > > > > > >=20 > > > > > > Unless anybody objects, I recommend we reject this issue. > > > > > >=20 > > > > > > Comments please. > > > > > >=20 > > > > > > Alper > > > > > > =20 > > > > > >=20 > > > > > >=20 > > > > >=20 > > > >=20 > > > >=20 > > >=20 > >=20 >=20 From pana-request@research.telcordia.com Fri Aug 15 04:11:00 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21376 for ; Fri, 15 Aug 2003 04:10:59 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7F7xttl007670; Fri, 15 Aug 2003 03:59:55 -0400 (EDT) Resent-Date: Fri, 15 Aug 2003 03:59:55 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Ciphering choice Date: Fri, 15 Aug 2003 10:56:05 +0300 Message-ID: Thread-Topic: Ciphering choice Thread-Index: AcNaxci3tnhIm9LaSsioXW5233eP1AG3rIhgAA2e5pAASViZgA== From: To: , , X-OriginalArrivalTime: 15 Aug 2003 07:56:06.0163 (UTC) FILETIME=[AE494E30:01C36302] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable IPSec is just one possible(?) way to enforce the usage of=20 authorized IP addresses, but the more common approach is=20 plain packet filtering. Packet filtering and IPSec are out of the scope PANA,=20 since they are access control mechanisms. What is in the=20 scope of PANA is to give the right information so that=20 access control is possible. The case where PANA is bootstrapped without an IP address=20 (0::0, 0.0.0.0) and after DHCP (or something similar)=20 PANA-Rauth message is used to update the DI. This DI is=20 the IP address that PaC is allowed to use for accessing=20 the network (if IPSec is used then inside tunnel).=20 Currently the PANA protocol spec allows only one DI=20 to be specified. In the case of physically secure link or=20 with L2 ciphering IPSec is not needed, but IP address based=20 access control is (to prevent spoofin of other clients=20 etc.). With L2 ciphering MAC address is needed as the=20 DI(?), but also the IP address. So, we need to have support for multiple DI AVPs. In addition, PaC may want to use a=20 whole subnet (mobile router) or just multiple IP addresses. PANA must support this. - Dan > -----Original Message----- > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > Sent: 13 August, 2003 23:42 > To: Forsberg Dan (NRC/Helsinki); alper@docomolabs-usa.com; > pana@research.telcordia.com > Subject: RE: Ciphering choice >=20 >=20 >=20 > =20 > >=20 > > What about filtering based on IP address (PANA DI) in EP/PAA?=20 > > It is needed both with L2 ciphering and with IPSec.=20 > >=20 > > This means that PAA must know the correct IP address for the=20 > > PaC. We just can't forget L3, when L2 ciphering is used. > >=20 > > I think that with L2 ciphering we can use L2 MAC and that=20 > > is fine, but PANA needs to take care of IP traffic filtering=20 > > too. Or should we say that IP traffic filtering is the first=20 > > priority since PANA is L3 solution. > >=20 > > And no, this is not SEND problem. > >=20 > Please see my other mail. We need some mechanism to provide > access control. Using Ipsec does help do this. And we can > document this. Now using this to prevent spoofing etc. beyond > the scope. >=20 > -mohan >=20 > > - Dan > >=20 > > > -----Original Message----- > > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > > Sent: 04 August, 2003 23:21 > > > To: pana@research.telcordia.com > > > Subject: Ciphering choice > > >=20 > > >=20 > > >=20 > > > Some of the discussions around the choice of device > > > identifier for Pac is > > > stemming from the choice of ciphering. If L2 ciphering will=20 > > > be used, than > > > the L2 address must be the DI. If L3 ciphering will be used=20 > > > (i.e., IPsec), > > > then the DI must be an IP address. > > >=20 > > > Two questions: > > > a) Does it make sense to leave the selection to PaC, or=20 > > > should PAA mandate > > > which ciphering should be used? > > > b) Does it make sense to enable both L2 and L3 ciphering at=20 > > > the same time? > > >=20 > > > Based on the earlier discussions, in my personal opinion, the > > > ciphering > > > selection should be based on the access network policy.=20 > > > Hence, this is not > > > something for the PaC to decide. I'd say PAA should mandate,=20 > > > and PaC should > > > obey the decision. > > >=20 > > > As for (b), it was not clear whether this is something needed > > > and useful. In > > > order to bind the client authentication to data traffic, one=20 > > > is sufficient. > > >=20 > > > I recommend we let PAA specify which one of the two ciphering > > > mechanisms > > > will be used (L2 vs. L3), PaC has to obey or leave the=20 > > > network, and the > > > device IDs are chosen accordingly. > > >=20 > > > Comments? > > >=20 > > > Alper > > >=20 > > >=20 > >=20 > >=20 >=20 From pana-request@research.telcordia.com Fri Aug 15 12:50:32 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03071 for ; Fri, 15 Aug 2003 12:50:26 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7FGbhPq029170; Fri, 15 Aug 2003 12:37:43 -0400 (EDT) Resent-Date: Fri, 15 Aug 2003 12:37:43 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue4: (new) Device identifier (types) Date: Fri, 15 Aug 2003 09:37:11 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4B9@TNEXVS02.tahoenetworks.com> Thread-Topic: Issue4: (new) Device identifier (types) Thread-Index: AcNhuGsbjkgsIxOkTnaF9w5wzhgfXwAIvEHAABgEumAAEnQo4AAeArBgABMBH8A= From: "Mohan Parthasarathy" To: , Cc: , X-OriginalArrivalTime: 15 Aug 2003 16:37:11.0655 (UTC) FILETIME=[79F8C770:01C3634B] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <_Yv-0C.A.pHH.VxQP_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable =20 > Mohan, >=20 > Here are some references to the requirements document. >=20 > draft-ietf-pana-requirements-07.txt: > 4.1.2. Authorization, Accounting and Access Control =20 > =20 > After a device is authenticated using PANA, it MUST be authorized=20 > for "network access." That is, the core requirement of PANA is to=20 > verify the authorization of a PaC so that PaC's device may=20 > send and=20 > receive any IP packets. >=20 > draft-ietf-pana-requirements-07.txt: > 4.4. PAA-to-EP Protocol=20 > =20 > PANA does not assume that the PAA is always co-located with the=20 > EP(s). Network access enforcement can be provided by one or more=20 > nodes on the same IP subnet as the client (e.g., multiple=20 > routers),=20 > or on another subnet in the access domain (e.g., gateway to the=20 > Internet, depending on the network architecture). When the PAA and=20 > the EP(s) are separated, there needs to be another transport for=20 > client provisioning. This transport is needed to create access=20 > control lists to allow authenticated and authorized=20 > clients' traffic=20 > through the EPs. PANA Working Group will preferably identify an=20 > existing protocol solution that allows the PAA to deliver the=20 > authorization information to one or more EPs when the PAA is=20 > separated from EPs. >=20 > Authorization for "network access" includes IP address authorization.=20 > The requirements spec (above) says "-- so that PaC's device=20 > may send and receive any IP packets". My interpretation about=20 > this is that in the=20 > beginning PaC is able to communicate only to the PAA, but after=20 > authentication and authorization PaC is able to really access the=20 > Internet. >=20 If you just use the IP address for authorizing in shared links, then some one can spoof and steal the service. So, you need some stronger mechanism e.g. Ipsec. With Ipsec, you can be sure that the packets are being sent only by authenticated clients and there is no service theft in the network. If authenticated clients can spoof one another, they need to protect themselves using end-to-end mechanism. Sure, Access network can do something to prevent it. Unless there are some explicit words in the requirements, I disagree with this being a requirement. There was some discussion in the threats evaluation draft early on but later was removed.=20 > Also, PAA needs to have the info of PaC's IP address(es) for=20 > PAA-to-EP=20 > protocol to carry it to the EP that really needs this info for=20 > access control. >=20 Sure, but define access control please ? I see it as "only authenticated clients use my network". You want to see addditional things like no spoofing etc. Perhaps possible, but I would like to see the requirements more clear on this. SEND working group is working on ways to prevent stealing of IPv6 addresses. So, I am not sure what we need to do here. > So, this really is in the scope of PANA. >=20 Please see above. Are you saying that PANA should come up with some mechanism to prevent address spoofing ? -mohan > - Dan >=20 > > -----Original Message----- > > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > Sent: 14 August, 2003 20:03 > > To: Forsberg Dan (NRC/Helsinki); yohba@tari.toshiba.com > > Cc: alper@docomolabs-usa.com; pana@research.telcordia.com > > Subject: RE: Issue4: (new) Device identifier (types) > >=20 > >=20 > >=20 > > >=20 > > > Let's face the problem. If we don't bind the global > > > IP address to the PANA session, PaC is able to spoof=20 > > > all the other (possibly authenticated) clients (and=20 > > > in the worst case even network elements etc.). > > >=20 > > > If you say this problem is out of scope of PANA, I don't=20 > agree with=20 > > > you. This is a question that needs to be resolved in a standard.=20 > > > Otherwise vendors will do something by their own. > > >=20 > > Please point to me where in requirements is this specified=20 > ? At least=20 > > I don't remember reading one. > >=20 > > The important goal of the working group is to specify PANA=20 > protocol.=20 > > And we also agreed that we will come up with some mechanism=20 > to provide=20 > > access control. We are documenting one way of doing this i.e using=20 > > Ipsec. Now we can keep adding more to this list. We can=20 > explore to see=20 > > if we can use Ipsec to solve all the problems. But is this > > really in scope ? If Ipsec solves it for free, then it > > is fine. But I still strongly feel that it is not in > > the scope. > >=20 > > -mohan > >=20 > > > In short, PANA MUST provide support for IP address > > > spoofing prevention both with L2 and L3 ciphering, or=20 > > > without ciphering at all. Otherwise we have a serious > > > security problem. > > >=20 > > > Since PANA has a SA and thus supports authenticated > > > messages between PaC and PAA, it is a proper protocol > > > to use for IP address spoofing prevention. > > >=20 > > > - Dan > > >=20 > > > > -----Original Message----- > > > > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > > > Sent: 13 August, 2003 23:47 > > > > To: Yoshihiro Ohba; Forsberg Dan (NRC/Helsinki) > > > > Cc: alper@docomolabs-usa.com; pana@research.telcordia.com > > > > Subject: RE: Issue4: (new) Device identifier (types) > > > >=20 > > > >=20 > > > >=20 > > > > =20 > > > > >=20 > > > > > On Wed, Aug 13, 2003 at 05:01:45PM +0300,=20 > Dan.Forsberg@nokia.com=20 > > > > > wrote: > > > > > > One of the questions in IETF57 PANA wg meeting was that > > > should PAA > > > > > > take care of authorizing IP addresses. I think it > > > should, because > > > > > > it informs the EPs about the filtering rules. > > > > > >=20 > > > > > > If I've understood correctly IPSec tunnel is used > > > between PaC and > > > > > > EP/PAA with link local addresses. Then the inner IP > > > > address in the > > > > > > IPSec tunnel should be PANA DI. In this case it could > > > be a subnet > > > > > > prefix, right? > > > > >=20 > > > > > The inner IP address in the IPsec tunnel is not=20 > necessarily be a=20 > > > > > PANA DI, since the outer IP address (i.e., a link local IP=20 > > > > > address) can be used as a PANA DI. Authorization for=20 > the inner=20 > > > > > IP address can be done in IKE negotiation by which an=20 > > > > > appropriate per-packet filtering rule for the inner=20 > IP address=20 > > > > > is set to IPsec SPD. IKE also supports negotiatin of=20 > > > > > subnet-prefix parameters for inner packets. > > > > >=20 > > > > It is not possible to know the inner IP addresses always i.e the > > > > dynamic SPD setup should be very simple. Just use the DI=20 > > > (link-local > > > > in IPv6 or the DHCP address in IPv4) for binding to the=20 > Ipsec SA. > > > >=20 > > > > >=20 > > > > > >=20 > > > > > > If PANA uses MAC as the DI (and even with IPSec tunnel), > > > > > PAA/EP can't > > > > > > control the IP addresses the PaC is using (inner IP > > > > address in the > > > > > > IPSec tunnel). Anyway, I firmly believe that access > > > > networks wount > > > > > > pass packets with ANY source IP address to the network > > > > (refusal to > > > > > > route). So I don't think that any IP address can be used > > > > inside the > > > > > > IPSec tunnel. > > > > >=20 > > > > > I think the required functionality of per-packet=20 > filtering for=20 > > > > > inner packets is already covered by the combination of: > > > > >=20 > > > > > - Support of DI update (from MAC address to IP address). > > > > >=20 > > > > > - Use of link-local address as a DI when bootstrapping IKE. > > > > >=20 > > > > > - Use of IKE for establishing an tunnel mode IPsec SA between=20 > > > > > PaC and EP. > > > > > (as a result, an SPD entry for inner packet filtering will > > > > > be created.) > > > > >=20 > > > > As I mentioned in other mail, we don't need this. We are > > > talking about > > > > access control. MIC is sufficient for authorization. > > > >=20 > > > > -mohan > > > >=20 > > > > > - Use of IPsec tunnel (whether inner packet filtering is done > > > > > based on the created SPD entry). > > > > >=20 > > > > >=20 > > > > > Yoshihiro Ohba > > > > >=20 > > > > >=20 > > > > > >=20 > > > > > > - Dan > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > > > > > > Sent: 08 August, 2003 00:42 > > > > > > > To: pana@research.telcordia.com > > > > > > > Subject: Issue4: (new) Device identifier (types) > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > http://www.danforsberg.info:8080/pana-issues/issue4 > > > > > > >=20 > > > > > > > The issue text refers to multi-homed hosts and device ID > > > > > > > changes. These are covered under separate issues=20 > > (#16 and #5). > > > > > > >=20 > > > > > > > So, issue #4 should only be talking about new DI types. > > > > > And the one > > > > > > > mentioned in the text is "subnet prefix." Unless anyone > > > > > has another > > > > > > > proposed device ID type, let's discuss that. > > > > > > >=20 > > > > > > > I'm trying to understand the utility of setting=20 > the DI as a > > > > > > > subnet prefix. If this is proposed to enable mobile=20 > > > routers to > > > > > > > connect > > > > > to an access > > > > > > > network, we can easily achive that by using either a mac=20 > > > > > > > address DI along with L2 ciphering, or a single=20 > IP address=20 > > > > > > > DI along with IPsec. In the latter > > > > > > > case, any IP address can be used inside the IPsec tunnel.=20 > > > > > > > Aside from not > > > > > > > needing it, I'm also not sure how we can use this=20 > DI as an=20 > > > > > > > IPsec end point. > > > > > > >=20 > > > > > > > Unless anybody objects, I recommend we reject this issue. > > > > > > >=20 > > > > > > > Comments please. > > > > > > >=20 > > > > > > > Alper > > > > > > > =20 > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 From pana-request@research.telcordia.com Fri Aug 15 12:54:45 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03453 for ; Fri, 15 Aug 2003 12:54:44 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7FGhsBR029672; Fri, 15 Aug 2003 12:43:54 -0400 (EDT) Resent-Date: Fri, 15 Aug 2003 12:43:54 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Ciphering choice Date: Fri, 15 Aug 2003 09:43:47 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C151E@TNEXVS02.tahoenetworks.com> Thread-Topic: Ciphering choice Thread-Index: AcNaxci3tnhIm9LaSsioXW5233eP1AG3rIhgAA2e5pAASViZgAAS3bQA From: "Mohan Parthasarathy" To: , , X-OriginalArrivalTime: 15 Aug 2003 16:43:47.0603 (UTC) FILETIME=[65F9A630:01C3634C] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable =20 > IPSec is just one possible(?) way to enforce the usage of=20 > authorized IP addresses, but the more common approach is=20 > plain packet filtering. >=20 > Packet filtering and IPSec are out of the scope PANA,=20 > since they are access control mechanisms. What is in the=20 > scope of PANA is to give the right information so that=20 > access control is possible. >=20 > The case where PANA is bootstrapped without an IP address=20 > (0::0, 0.0.0.0) and after DHCP (or something similar)=20 > PANA-Rauth message is used to update the DI. This DI is=20 > the IP address that PaC is allowed to use for accessing=20 > the network (if IPSec is used then inside tunnel).=20 >=20 If DHCP is used to obtain the IP address and only that IP address is used for all communications, then it is possible to tie the IP adddress to a particular PaC securely and=20 perform access control. But I am still not sure whether this is in the scope and this mechainsm still seems limited. > Currently the PANA protocol spec allows only one DI=20 > to be specified. In the case of physically secure link or=20 > with L2 ciphering IPSec is not needed, but IP address based=20 > access control is (to prevent spoofin of other clients=20 > etc.). With L2 ciphering MAC address is needed as the=20 > DI(?), but also the IP address. So, we need to have support > for multiple DI AVPs. In addition, PaC may want to use a=20 > whole subnet (mobile router) or just multiple IP addresses.=20 > PANA must support this. >=20 PANA must be *extensible* to support this. I think we should keep it simple first. When we gain better understanding and there are more needs, we can extend it. -mohan > - Dan >=20 > > -----Original Message----- > > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > Sent: 13 August, 2003 23:42 > > To: Forsberg Dan (NRC/Helsinki); alper@docomolabs-usa.com;=20 > > pana@research.telcordia.com > > Subject: RE: Ciphering choice > >=20 > >=20 > >=20 > > =20 > > >=20 > > > What about filtering based on IP address (PANA DI) in EP/PAA? > > > It is needed both with L2 ciphering and with IPSec.=20 > > >=20 > > > This means that PAA must know the correct IP address for the > > > PaC. We just can't forget L3, when L2 ciphering is used. > > >=20 > > > I think that with L2 ciphering we can use L2 MAC and that > > > is fine, but PANA needs to take care of IP traffic filtering=20 > > > too. Or should we say that IP traffic filtering is the first=20 > > > priority since PANA is L3 solution. > > >=20 > > > And no, this is not SEND problem. > > >=20 > > Please see my other mail. We need some mechanism to provide access=20 > > control. Using Ipsec does help do this. And we can document=20 > this. Now=20 > > using this to prevent spoofing etc. beyond the scope. > >=20 > > -mohan > >=20 > > > - Dan > > >=20 > > > > -----Original Message----- > > > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > > > Sent: 04 August, 2003 23:21 > > > > To: pana@research.telcordia.com > > > > Subject: Ciphering choice > > > >=20 > > > >=20 > > > >=20 > > > > Some of the discussions around the choice of device=20 > identifier for=20 > > > > Pac is stemming from the choice of ciphering. If L2=20 > ciphering will > > > > be used, than > > > > the L2 address must be the DI. If L3 ciphering will be used=20 > > > > (i.e., IPsec), > > > > then the DI must be an IP address. > > > >=20 > > > > Two questions: > > > > a) Does it make sense to leave the selection to PaC, or > > > > should PAA mandate > > > > which ciphering should be used? > > > > b) Does it make sense to enable both L2 and L3 ciphering at=20 > > > > the same time? > > > >=20 > > > > Based on the earlier discussions, in my personal opinion, the=20 > > > > ciphering selection should be based on the access=20 > network policy. > > > > Hence, this is not > > > > something for the PaC to decide. I'd say PAA should mandate,=20 > > > > and PaC should > > > > obey the decision. > > > >=20 > > > > As for (b), it was not clear whether this is something=20 > needed and=20 > > > > useful. In order to bind the client authentication to data=20 > > > > traffic, one is sufficient. > > > >=20 > > > > I recommend we let PAA specify which one of the two ciphering=20 > > > > mechanisms will be used (L2 vs. L3), PaC has to obey or=20 > leave the > > > > network, and the > > > > device IDs are chosen accordingly. > > > >=20 > > > > Comments? > > > >=20 > > > > Alper > > > >=20 > > > >=20 > > >=20 > > >=20 > >=20 >=20 From pana-request@research.telcordia.com Fri Aug 15 13:38:17 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03070 for ; Fri, 15 Aug 2003 12:50:26 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7FGdCa6029240; Fri, 15 Aug 2003 12:39:12 -0400 (EDT) Resent-Date: Fri, 15 Aug 2003 12:39:12 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue4: (new) Device identifier (types) Date: Fri, 15 Aug 2003 09:39:04 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E016C151D@TNEXVS02.tahoenetworks.com> Thread-Topic: Issue4: (new) Device identifier (types) Thread-Index: AcNigGnId7A4SF7cTa2Yg696OnN5NQAem4/gABQtFlA= From: "Mohan Parthasarathy" To: , Cc: , X-OriginalArrivalTime: 15 Aug 2003 16:39:05.0299 (UTC) FILETIME=[BDB57A30:01C3634B] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable t on the same link) is not possible. >=20 > > >=20 > > > Since PANA has a SA and thus supports authenticated > > > messages between PaC and PAA, it is a proper protocol > > > to use for IP address spoofing prevention. > >=20 > > I believe IPsec is the proper protocol to use for IP=20 > address spoofing=20 > > prevention. What PANA must do for this is to bootstap IPsec. >=20 > IPSec is not always used. Consider the case with physically=20 > secure links. >=20 > I suggest that PANA lists all the IP addresses it is using.=20 Tell me how you want to stop the PaC from listing some other node's IP address. This is want SEND does. -mohan > If changes are required, PANA-Reauth messages can be used=20 > (updating the list of IP addresses/prefixes in use).=20 > Authorization decision for the IP address usage can be set=20 > out of the scope of PANA. For example=20 > draft-tschofenig-pana-bootstrap-rfc3118-00.txt can help in=20 > this authorization decision. >=20 > - Dan >=20 > >=20 > > Yoshihiro Ohba > >=20 > > >=20 > > > - Dan > > >=20 > > > > -----Original Message----- > > > > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > > > Sent: 13 August, 2003 23:47 > > > > To: Yoshihiro Ohba; Forsberg Dan (NRC/Helsinki) > > > > Cc: alper@docomolabs-usa.com; pana@research.telcordia.com > > > > Subject: RE: Issue4: (new) Device identifier (types) > > > >=20 > > > >=20 > > > >=20 > > > > =20 > > > > >=20 > > > > > On Wed, Aug 13, 2003 at 05:01:45PM +0300, > > > > > Dan.Forsberg@nokia.com wrote: > > > > > > One of the questions in IETF57 PANA wg meeting was > > that should PAA > > > > > > take care of authorizing IP addresses. I think it > > should, because > > > > > > it informs the EPs about the filtering rules. > > > > > >=20 > > > > > > If I've understood correctly IPSec tunnel is used > > between PaC and > > > > > > EP/PAA with link local addresses. Then the inner IP > > > > address in the > > > > > > IPSec tunnel should be PANA DI. In this case it could > > be a subnet > > > > > > prefix, right? > > > > >=20 > > > > > The inner IP address in the IPsec tunnel is not necessarily > > > > > be a PANA DI, since the outer IP address (i.e., a link local=20 > > > > > IP address) can be used as a PANA DI. Authorization for the=20 > > > > > inner IP address can be done in IKE negotiation by which an=20 > > > > > appropriate per-packet filtering rule for the inner IP=20 > > > > > address is set to IPsec SPD. IKE also supports negotiatin of=20 > > > > > subnet-prefix parameters for inner packets. > > > > >=20 > > > > It is not possible to know the inner IP addresses=20 > always i.e the=20 > > > > dynamic SPD setup should be very simple. Just use the DI > > (link-local > > > > in IPv6 or the DHCP address in IPv4) for binding to the=20 > Ipsec SA. > > > >=20 > > > > >=20 > > > > > >=20 > > > > > > If PANA uses MAC as the DI (and even with IPSec tunnel), > > > > > PAA/EP can't > > > > > > control the IP addresses the PaC is using (inner IP > > > > address in the > > > > > > IPSec tunnel). Anyway, I firmly believe that access > > > > networks wount > > > > > > pass packets with ANY source IP address to the network > > > > (refusal to > > > > > > route). So I don't think that any IP address can be used > > > > inside the > > > > > > IPSec tunnel. > > > > >=20 > > > > > I think the required functionality of per-packet filtering > > > > > for inner packets is already covered by the combination of: > > > > >=20 > > > > > - Support of DI update (from MAC address to IP address). > > > > >=20 > > > > > - Use of link-local address as a DI when bootstrapping IKE. > > > > >=20 > > > > > - Use of IKE for establishing an tunnel mode IPsec SA between > > > > > PaC and EP. > > > > > (as a result, an SPD entry for inner packet filtering will=20 > > > > > be created.) > > > > >=20 > > > > As I mentioned in other mail, we don't need this. We=20 > are talking=20 > > > > about access control. MIC is sufficient for authorization. > > > >=20 > > > > -mohan > > > >=20 > > > > > - Use of IPsec tunnel (whether inner packet filtering is done > > > > > based on the created SPD entry). > > > > >=20 > > > > >=20 > > > > > Yoshihiro Ohba > > > > >=20 > > > > >=20 > > > > > >=20 > > > > > > - Dan > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > > > > > > Sent: 08 August, 2003 00:42 > > > > > > > To: pana@research.telcordia.com > > > > > > > Subject: Issue4: (new) Device identifier (types) > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > http://www.danforsberg.info:8080/pana-issues/issue4 > > > > > > >=20 > > > > > > > The issue text refers to multi-homed hosts and device ID=20 > > > > > > > changes. These are covered under separate issues (#16 and=20 > > > > > > > #5). > > > > > > >=20 > > > > > > > So, issue #4 should only be talking about new DI types. > > > > > And the one > > > > > > > mentioned in the text is "subnet prefix." Unless anyone > > > > > has another > > > > > > > proposed device ID type, let's discuss that. > > > > > > >=20 > > > > > > > I'm trying to understand the utility of setting=20 > the DI as a=20 > > > > > > > subnet prefix. If this is proposed to enable=20 > mobile routers=20 > > > > > > > to connect > > > > > to an access > > > > > > > network, we can easily achive that by using either a mac > > > > > > > address DI along > > > > > > > with L2 ciphering, or a single IP address DI along with=20 > > > > > > > IPsec. In the latter > > > > > > > case, any IP address can be used inside the IPsec tunnel.=20 > > > > > > > Aside from not > > > > > > > needing it, I'm also not sure how we can use this=20 > DI as an=20 > > > > > > > IPsec end point. > > > > > > >=20 > > > > > > > Unless anybody objects, I recommend we reject this issue. > > > > > > >=20 > > > > > > > Comments please. > > > > > > >=20 > > > > > > > Alper > > > > > > > =20 > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > >=20 >=20 From pana-request@research.telcordia.com Fri Aug 15 19:43:33 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17952 for ; Fri, 15 Aug 2003 19:43:26 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7FNUiHU013055; Fri, 15 Aug 2003 19:30:44 -0400 (EDT) Resent-Date: Fri, 15 Aug 2003 19:30:44 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Fri, 15 Aug 2003 16:32:31 -0700 Subject: Re: Ciphering choice From: Alper Yegin To: Mohan Parthasarathy , , Message-ID: In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E016C151E@TNEXVS02.tahoenetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <7o1lAC.A.2LD.k0WP_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >> Currently the PANA protocol spec allows only one DI >> to be specified. In the case of physically secure link or >> with L2 ciphering IPSec is not needed, but IP address based >> access control is (to prevent spoofin of other clients >> etc.). No, if we are not dealing with IP address authorization problem (subject of the other thread), using L2 address for access control is sufficient when physical security or L2 security is in place. >> With L2 ciphering MAC address is needed as the >> DI(?), but also the IP address. So, we need to have support >> for multiple DI AVPs. In addition, PaC may want to use a >> whole subnet (mobile router) or just multiple IP addresses. >> PANA must support this. PANA can be readily used for authenticating a mobile router as well. Single DI is sufficient, any traffic is tunneled above it (be it carrying IP packets over a mac frame when DI is L2 address, or carrying IP packets over an IP tunnel when DI is an IP address). > PANA must be *extensible* to support this. I think we should > keep it simple first. When we gain better understanding > and there are more needs, we can extend it. This is the approach we should stick to. Alper > > -mohan > >> - Dan >> >>> -----Original Message----- >>> From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] >>> Sent: 13 August, 2003 23:42 >>> To: Forsberg Dan (NRC/Helsinki); alper@docomolabs-usa.com; >>> pana@research.telcordia.com >>> Subject: RE: Ciphering choice >>> >>> >>> >>> >>>> >>>> What about filtering based on IP address (PANA DI) in EP/PAA? >>>> It is needed both with L2 ciphering and with IPSec. >>>> >>>> This means that PAA must know the correct IP address for the >>>> PaC. We just can't forget L3, when L2 ciphering is used. >>>> >>>> I think that with L2 ciphering we can use L2 MAC and that >>>> is fine, but PANA needs to take care of IP traffic filtering >>>> too. Or should we say that IP traffic filtering is the first >>>> priority since PANA is L3 solution. >>>> >>>> And no, this is not SEND problem. >>>> >>> Please see my other mail. We need some mechanism to provide access >>> control. Using Ipsec does help do this. And we can document >> this. Now >>> using this to prevent spoofing etc. beyond the scope. >>> >>> -mohan >>> >>>> - Dan >>>> >>>>> -----Original Message----- >>>>> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] >>>>> Sent: 04 August, 2003 23:21 >>>>> To: pana@research.telcordia.com >>>>> Subject: Ciphering choice >>>>> >>>>> >>>>> >>>>> Some of the discussions around the choice of device >> identifier for >>>>> Pac is stemming from the choice of ciphering. If L2 >> ciphering will >>>>> be used, than >>>>> the L2 address must be the DI. If L3 ciphering will be used >>>>> (i.e., IPsec), >>>>> then the DI must be an IP address. >>>>> >>>>> Two questions: >>>>> a) Does it make sense to leave the selection to PaC, or >>>>> should PAA mandate >>>>> which ciphering should be used? >>>>> b) Does it make sense to enable both L2 and L3 ciphering at >>>>> the same time? >>>>> >>>>> Based on the earlier discussions, in my personal opinion, the >>>>> ciphering selection should be based on the access >> network policy. >>>>> Hence, this is not >>>>> something for the PaC to decide. I'd say PAA should mandate, >>>>> and PaC should >>>>> obey the decision. >>>>> >>>>> As for (b), it was not clear whether this is something >> needed and >>>>> useful. In order to bind the client authentication to data >>>>> traffic, one is sufficient. >>>>> >>>>> I recommend we let PAA specify which one of the two ciphering >>>>> mechanisms will be used (L2 vs. L3), PaC has to obey or >> leave the >>>>> network, and the >>>>> device IDs are chosen accordingly. >>>>> >>>>> Comments? >>>>> >>>>> Alper >>>>> >>>>> >>>> >>>> >>> >> > > > From pana-request@research.telcordia.com Fri Aug 15 19:57:57 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18191 for ; Fri, 15 Aug 2003 19:57:56 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7FNl3nB013762; Fri, 15 Aug 2003 19:47:03 -0400 (EDT) Resent-Date: Fri, 15 Aug 2003 19:47:03 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Fri, 15 Aug 2003 16:48:42 -0700 Subject: Re: Issue4: (new) Device identifier (types) From: Alper Yegin To: , , CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > draft-ietf-pana-requirements-07.txt: > 4.1.2. Authorization, Accounting and Access Control > > After a device is authenticated using PANA, it MUST be authorized > for "network access." That is, the core requirement of PANA is to > verify the authorization of a PaC so that PaC's device may send and > receive any IP packets. > Authorization for "network access" includes IP address authorization. No it doesn't. As we specifically said, this is all about "being authorized to send *any* IP packets", not "authorized to use an assigned IP address for sending and receiving IP packets". You are getting into finer granularity authorization which we explicitly kept out-of-scope. > The requirements spec (above) says "-- so that PaC's device may send and > receive any IP packets". My interpretation about this is that in the > beginning PaC is able to communicate only to the PAA, but after > authentication and authorization PaC is able to really access the > Internet. Yes, and that still does not have anything to do with "IP address ownership". > > Also, PAA needs to have the info of PaC's IP address(es) for PAA-to-EP > protocol to carry it to the EP that really needs this info for > access control. EP needs to know only one IP address when IPsec is used for access control. And this is the IP tunnel end point on the PaC. This is sufficient for ensuring "only authorized hosts access the network." > > So, this really is in the scope of PANA. I disagree. I'm not disagreeing that IP address spoofing is a problem. But, clearly this is an out-of-scope problem for PANA protocol. If one can solve this by using some IKE features, that's fine. But putting the burden on the PANA protocol design is not right. Alper > > - Dan > >> -----Original Message----- >> From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] >> Sent: 14 August, 2003 20:03 >> To: Forsberg Dan (NRC/Helsinki); yohba@tari.toshiba.com >> Cc: alper@docomolabs-usa.com; pana@research.telcordia.com >> Subject: RE: Issue4: (new) Device identifier (types) >> >> >> >>> >>> Let's face the problem. If we don't bind the global >>> IP address to the PANA session, PaC is able to spoof >>> all the other (possibly authenticated) clients (and >>> in the worst case even network elements etc.). >>> >>> If you say this problem is out of scope of PANA, I don't >>> agree with you. This is a question that needs to be >>> resolved in a standard. Otherwise vendors will do >>> something by their own. >>> >> Please point to me where in requirements is this specified ? >> At least I don't remember reading one. >> >> The important goal of the working group is to specify PANA >> protocol. And we also agreed that we will come up with some >> mechanism to provide access control. We are documenting >> one way of doing this i.e using Ipsec. Now we can keep >> adding more to this list. We can explore to see if we >> can use Ipsec to solve all the problems. But is this >> really in scope ? If Ipsec solves it for free, then it >> is fine. But I still strongly feel that it is not in >> the scope. >> >> -mohan >> >>> In short, PANA MUST provide support for IP address >>> spoofing prevention both with L2 and L3 ciphering, or >>> without ciphering at all. Otherwise we have a serious >>> security problem. >>> >>> Since PANA has a SA and thus supports authenticated >>> messages between PaC and PAA, it is a proper protocol >>> to use for IP address spoofing prevention. >>> >>> - Dan >>> >>>> -----Original Message----- >>>> From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] >>>> Sent: 13 August, 2003 23:47 >>>> To: Yoshihiro Ohba; Forsberg Dan (NRC/Helsinki) >>>> Cc: alper@docomolabs-usa.com; pana@research.telcordia.com >>>> Subject: RE: Issue4: (new) Device identifier (types) >>>> >>>> >>>> >>>> >>>>> >>>>> On Wed, Aug 13, 2003 at 05:01:45PM +0300, >>>>> Dan.Forsberg@nokia.com wrote: >>>>>> One of the questions in IETF57 PANA wg meeting was that >>> should PAA >>>>>> take care of authorizing IP addresses. I think it >>> should, because >>>>>> it informs the EPs about the filtering rules. >>>>>> >>>>>> If I've understood correctly IPSec tunnel is used >>> between PaC and >>>>>> EP/PAA with link local addresses. Then the inner IP >>>> address in the >>>>>> IPSec tunnel should be PANA DI. In this case it could >>> be a subnet >>>>>> prefix, right? >>>>> >>>>> The inner IP address in the IPsec tunnel is not necessarily >>>>> be a PANA DI, since the outer IP address (i.e., a link local >>>>> IP address) can be used as a PANA DI. Authorization for the >>>>> inner IP address can be done in IKE negotiation by which an >>>>> appropriate per-packet filtering rule for the inner IP >>>>> address is set to IPsec SPD. IKE also supports negotiatin of >>>>> subnet-prefix parameters for inner packets. >>>>> >>>> It is not possible to know the inner IP addresses always i.e the >>>> dynamic SPD setup should be very simple. Just use the DI >>> (link-local >>>> in IPv6 or the DHCP address in IPv4) for binding to the Ipsec SA. >>>> >>>>> >>>>>> >>>>>> If PANA uses MAC as the DI (and even with IPSec tunnel), >>>>> PAA/EP can't >>>>>> control the IP addresses the PaC is using (inner IP >>>> address in the >>>>>> IPSec tunnel). Anyway, I firmly believe that access >>>> networks wount >>>>>> pass packets with ANY source IP address to the network >>>> (refusal to >>>>>> route). So I don't think that any IP address can be used >>>> inside the >>>>>> IPSec tunnel. >>>>> >>>>> I think the required functionality of per-packet filtering >>>>> for inner packets is already covered by the combination of: >>>>> >>>>> - Support of DI update (from MAC address to IP address). >>>>> >>>>> - Use of link-local address as a DI when bootstrapping IKE. >>>>> >>>>> - Use of IKE for establishing an tunnel mode IPsec SA between >>>>> PaC and EP. >>>>> (as a result, an SPD entry for inner packet filtering will >>>>> be created.) >>>>> >>>> As I mentioned in other mail, we don't need this. We are >>> talking about >>>> access control. MIC is sufficient for authorization. >>>> >>>> -mohan >>>> >>>>> - Use of IPsec tunnel (whether inner packet filtering is done >>>>> based on the created SPD entry). >>>>> >>>>> >>>>> Yoshihiro Ohba >>>>> >>>>> >>>>>> >>>>>> - Dan >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] >>>>>>> Sent: 08 August, 2003 00:42 >>>>>>> To: pana@research.telcordia.com >>>>>>> Subject: Issue4: (new) Device identifier (types) >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://www.danforsberg.info:8080/pana-issues/issue4 >>>>>>> >>>>>>> The issue text refers to multi-homed hosts and device ID >>>>>>> changes. These are covered under separate issues >> (#16 and #5). >>>>>>> >>>>>>> So, issue #4 should only be talking about new DI types. >>>>> And the one >>>>>>> mentioned in the text is "subnet prefix." Unless anyone >>>>> has another >>>>>>> proposed device ID type, let's discuss that. >>>>>>> >>>>>>> I'm trying to understand the utility of setting the DI as a >>>>>>> subnet prefix. If this is proposed to enable mobile >>> routers to >>>>>>> connect >>>>> to an access >>>>>>> network, we can easily achive that by using either a mac >>>>>>> address DI along >>>>>>> with L2 ciphering, or a single IP address DI along with >>>>>>> IPsec. In the latter >>>>>>> case, any IP address can be used inside the IPsec tunnel. >>>>>>> Aside from not >>>>>>> needing it, I'm also not sure how we can use this DI as an >>>>>>> IPsec end point. >>>>>>> >>>>>>> Unless anybody objects, I recommend we reject this issue. >>>>>>> >>>>>>> Comments please. >>>>>>> >>>>>>> Alper >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > > From pana-request@research.telcordia.com Mon Aug 18 10:15:42 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20453 for ; Mon, 18 Aug 2003 10:15:38 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7IE6Hca015641; Mon, 18 Aug 2003 10:06:17 -0400 (EDT) Resent-Date: Mon, 18 Aug 2003 10:06:17 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue4: (new) Device identifier (types) Date: Mon, 18 Aug 2003 17:06:05 +0300 Message-ID: Thread-Topic: Issue4: (new) Device identifier (types) Thread-Index: AcNhuGsbjkgsIxOkTnaF9w5wzhgfXwAIvEHAABgEumAAEnQo4AAeArBgABMBH8AAkdf6QA== From: To: , Cc: , X-OriginalArrivalTime: 18 Aug 2003 14:06:05.0939 (UTC) FILETIME=[DD9F8C30:01C36591] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > So, this really is in the scope of PANA. > >=20 > Please see above. Are you saying that PANA should come up with some > mechanism to prevent address spoofing ? That is out of the scope, but PANA can act as a carrier for that = information. Or should we say that the addresses that PaC is using can = be bound to the PANA session within the PANA protocol - securely. I'm not saying that PANA should do something that is in the scope of = SEND. PAA could for example query other parties: - PANA and DHCP interworking,=20 - PANA and MIPv6/v4 interworking,=20 - PANA and SEND interworking,=20 - PANA and "local administration" interworking (network policies,=20 access control, packet filtering and firewalling) if the listed DIs are ok for the PaC. What do you think about this? - Dan From pana-request@research.telcordia.com Mon Aug 18 17:26:38 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05188 for ; Mon, 18 Aug 2003 17:26:36 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7ILHdxr000775; Mon, 18 Aug 2003 17:17:39 -0400 (EDT) Resent-Date: Mon, 18 Aug 2003 17:17:39 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 18 Aug 2003 14:13:05 -0700 From: Yoshihiro Ohba Subject: Re: Issue4: (new) Device identifier (types) In-reply-to: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4B7@TNEXVS02.tahoenetworks.com> To: Mohan Parthasarathy Cc: Yoshihiro Ohba , Dan.Forsberg@nokia.com, alper@docomolabs-usa.com, pana@research.telcordia.com Message-id: <20030818211305.GA2269@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Mohan Parthasarathy , Yoshihiro Ohba , Dan.Forsberg@nokia.com, alper@docomolabs-usa.com, pana@research.telcordia.com User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 33 References: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4B7@TNEXVS02.tahoenetworks.com> X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <19f9vB.A.-L.zJUQ_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Thu, Aug 14, 2003 at 11:47:40AM -0700, Mohan Parthasarathy wrote: > > > > > > > > > How does the EP know about these selectors ? Before the Ipsec > > > negotiation starts, the other end should have a configured > > SPD entry > > > for the addresses that you specify in the traffic selector. Tell me > > > how the EP knows about these addresses. > > > > The selectors can be dynamically negotiated by using IKE or > > IKEv2. Though some IPsec implementation may configure SPD > > IPsec negotiation, there is basically no need to have SPD > > configured before IPsec negotiation starts. > > So, I can put in any address and the other end will accept it ? > Note that we are talking about tunnel mode Sas and the addresses > we are negotiating are inner addresses. If I can put in any address > for the inner address and the other end will accept it, then > we have not solved the problem yet. You are right. I haven't thought of it. > If you want to know whether > I am authorized to use a particular address, you need SEND. Yes, if the IKE responder accepts only the inner IP addresses for which ownership is proven by the use of SEND, we are done, given that both inner and outer addresses should use the same 64-bit interface ID. Yoshihiro Ohba From pana-request@research.telcordia.com Tue Aug 19 14:02:44 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26651 for ; Tue, 19 Aug 2003 14:02:40 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7JHr84w011831; Tue, 19 Aug 2003 13:53:08 -0400 (EDT) Resent-Date: Tue, 19 Aug 2003 13:53:08 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue4: (new) Device identifier (types) Date: Tue, 19 Aug 2003 10:52:28 -0700 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4BF@TNEXVS02.tahoenetworks.com> Thread-Topic: Issue4: (new) Device identifier (types) Thread-Index: AcNhuGsbjkgsIxOkTnaF9w5wzhgfXwAIvEHAABgEumAAEnQo4AAeArBgABMBH8AAkdf6QAA4x3PA From: "Mohan Parthasarathy" To: , Cc: , X-OriginalArrivalTime: 19 Aug 2003 17:52:28.0591 (UTC) FILETIME=[A7ED83F0:01C3667A] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable =20 >=20 > > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > > > So, this really is in the scope of PANA. > > >=20 > > Please see above. Are you saying that PANA should come up with some=20 > > mechanism to prevent address spoofing ? >=20 > That is out of the scope, but PANA can act as a carrier for=20 > that information. Or should we say that the addresses that=20 > PaC is using can be bound to the PANA session within the PANA=20 > protocol - securely. >=20 I am not sure I parsed everything correctly. PANA protocol is about authenticating the clients. Are you saying that we should extend PANA protocol to interact with other protocols to authorize the addresses the clients can use ? I guess you are talking about how to bind the addresses to the PANA clients securely. =20 > I'm not saying that PANA should do something that is in the=20 > scope of SEND. PAA could for example query other parties: > - PANA and DHCP interworking,=20 > - PANA and MIPv6/v4 interworking,=20 > - PANA and SEND interworking,=20 > - PANA and "local administration" interworking (network policies,=20 > access control, packet filtering and firewalling) > if the listed DIs are ok for the PaC. >=20 > What do you think about this? >=20 Some of these would be interesting to analyse about. But it still might be a bit too much for this WG to handle. -mohan =20 > - Dan >=20 >=20 From pana-request@research.telcordia.com Wed Aug 20 07:08:03 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03941 for ; Wed, 20 Aug 2003 07:07:57 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7KAx7AG017777; Wed, 20 Aug 2003 06:59:07 -0400 (EDT) Resent-Date: Wed, 20 Aug 2003 06:59:07 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue4: (new) Device identifier (types) Date: Wed, 20 Aug 2003 13:58:45 +0300 Message-ID: Thread-Topic: Issue4: (new) Device identifier (types) Thread-Index: AcNhuGsbjkgsIxOkTnaF9w5wzhgfXwAIvEHAABgEumAAEnQo4AAeArBgABMBH8AAkdf6QAA4x3PAACTaS+A= From: To: , Cc: , X-OriginalArrivalTime: 20 Aug 2003 10:58:45.0710 (UTC) FILETIME=[06C036E0:01C3670A] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > I am not sure I parsed everything correctly. PANA protocol > is about authenticating the clients. Are you saying that > we should extend PANA protocol to interact with other protocols > to authorize the addresses the clients can use ? I guess > you are talking about how to bind the addresses to the > PANA clients securely. No, I'm not saying that we should extend the scope of PANA=20 protocol. Yes, I'm talking about to bind the addresses to=20 the PANA session. - Dan > =20 > > I'm not saying that PANA should do something that is in the=20 > > scope of SEND. PAA could for example query other parties: > > - PANA and DHCP interworking,=20 > > - PANA and MIPv6/v4 interworking,=20 > > - PANA and SEND interworking,=20 > > - PANA and "local administration" interworking (network policies,=20 > > access control, packet filtering and firewalling) > > if the listed DIs are ok for the PaC. > >=20 > > What do you think about this? > >=20 > Some of these would be interesting to analyse about. But it > still might be a bit too much for this WG to handle. >=20 > -mohan >=20 > =20 >=20 > > - Dan > >=20 > >=20 >=20 >=20 From pana-request@research.telcordia.com Wed Aug 20 16:44:53 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09529 for ; Wed, 20 Aug 2003 16:44:47 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7KKUO43008383; Wed, 20 Aug 2003 16:30:24 -0400 (EDT) Resent-Date: Wed, 20 Aug 2003 16:30:24 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 20 Aug 2003 13:24:18 -0700 From: Yoshihiro Ohba Subject: AVP alignment To: pana@research.telcordia.com Message-id: <20030820202417.GA701@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: pana@research.telcordia.com User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 16 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com The current PANA specification does not specify a rule to align AVPs. I think we should specify something about this. I'd suggest using the 32-bit alignment rule as Diameter does. Here is the suggested text (borrowed from Diameter speicfication): "Each AVP MUST be padded to align on a 32-bit boundary. A number of zero- valued bytes are added to the end of the AVP Data field till a word boundary is reached. The length of the padding is not reflected in the AVP Length field." Yoshihiro Ohba From pana-request@research.telcordia.com Wed Aug 20 16:53:39 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10344 for ; Wed, 20 Aug 2003 16:53:38 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7KKjbMd009278; Wed, 20 Aug 2003 16:45:37 -0400 (EDT) Resent-Date: Wed, 20 Aug 2003 16:45:37 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Message-Id: <4.3.2.7.2.20030820164422.07f408b8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 20 Aug 2003 16:45:19 -0400 To: pana@research.telcordia.com From: Ralph Droms Subject: Re: AVP alignment In-Reply-To: <20030820202417.GA701@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Our experience with implementations of DHCP is that alignment of AVPs (DHCP options) isn't an important issue... - Ralph At 01:24 PM 8/20/2003 -0700, Yoshihiro Ohba wrote: >The current PANA specification does not specify a rule to align AVPs. >I think we should specify something about this. I'd suggest using the >32-bit alignment rule as Diameter does. Here is the suggested text >(borrowed from Diameter speicfication): > > "Each AVP MUST be padded to align on a 32-bit boundary. A number of zero- > valued bytes are added to the end of the AVP Data field till a word > boundary is reached. The length of the padding is not reflected in > the AVP Length field." > > >Yoshihiro Ohba > > > From pana-request@research.telcordia.com Thu Aug 21 05:49:19 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25347 for ; Thu, 21 Aug 2003 05:49:18 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7L9aNNx002943; Thu, 21 Aug 2003 05:36:23 -0400 (EDT) Resent-Date: Thu, 21 Aug 2003 05:36:23 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [issue18] Termination-Cause AVP values? Date: Thu, 21 Aug 2003 12:36:17 +0300 Message-ID: Thread-Topic: [issue18] Termination-Cause AVP values? Thread-Index: AcNnx2t0OOQFLeRGTm+wI0vx57BmhQAADL0g From: To: X-OriginalArrivalTime: 21 Aug 2003 09:36:17.0892 (UTC) FILETIME=[AC08DA40:01C367C7] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Took away codes in parenthesis. -- These are from Diameter spec (17): LOGOUT 1 (PaC -> PAA) The user initiated a disconnect BAD_ANSWER 3 (PaC -> PAA) This value indicates that the authorization answer received by the access device was not processed successfully. ADMINISTRATIVE 4 (PAA -> Pac) The user was not granted access, or was=20 disconnected, due to administrative reasons,=20 such as the receipt of a Abort-Session-Request message. AUTH_EXPIRED 6 (PAA -> PaC) The user's access was terminated since its=20 authorized session time has expired. SESSION_TIMEOUT 8 (PAA -> PaC) The user's session has timed out, and service=20 has been terminated. ________________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue18 ________________________________________________ From pana-request@research.telcordia.com Thu Aug 21 06:01:14 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25768 for ; Thu, 21 Aug 2003 06:01:14 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7L9oZqD005870; Thu, 21 Aug 2003 05:50:35 -0400 (EDT) Resent-Date: Thu, 21 Aug 2003 05:50:35 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [issue9] Message format Date: Thu, 21 Aug 2003 12:46:47 +0300 Message-ID: Thread-Topic: [issue9] Message format Thread-Index: AcNnxtvrnxrNLNt/SNiM7Aa1QihypgAABYaAAAB79FA= From: To: X-OriginalArrivalTime: 21 Aug 2003 09:46:48.0442 (UTC) FILETIME=[23DF25A0:01C367C9] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: New version (f). Changes: - Changes from draft 01 incorporated. - Removed error codes: SERVICE_NOT_PROVIDED, LINK_BROKEN, USER_MOVED - Added Session-Timeout AVP (Session-Lifetime AVP is non-existent). - Added Session-Timeout AVP to the PANA-Bind-Request=20 message. - PANA-Error message included, but not specified. _______________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue9 _______________________________________________ From pana-request@research.telcordia.com Thu Aug 21 06:14:51 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26144 for ; Thu, 21 Aug 2003 06:14:50 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7LA4IGH008039; Thu, 21 Aug 2003 06:04:18 -0400 (EDT) Resent-Date: Thu, 21 Aug 2003 06:04:18 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AVP alignment Date: Thu, 21 Aug 2003 13:04:15 +0300 Message-ID: Thread-Topic: AVP alignment Thread-Index: AcNnXAW6/apE/OjuQlWa21ILdHLEbQAbyl6g From: To: , X-OriginalArrivalTime: 21 Aug 2003 10:04:15.0668 (UTC) FILETIME=[94112740:01C367CB] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <_niF1.A.e9B.ikJR_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable I would also suggest that we take the same approach than in=20 Diameter and also specify that the AVP header is transmitted=20 in network byte order. Actually the draft 17 says something=20 like this: "Each AVP of type OctetString MUST be padded to align on a 32-bit boundary, while other AVP types align naturally. A number of zero- valued bytes are added to the end of the AVP Data field till a word boundary is reached. The length of the padding is not reflected in the AVP Length field." - Dan > -----Original Message----- > From: ext Ralph Droms [mailto:rdroms@cisco.com] > Sent: 20 August, 2003 23:45 > To: pana@research.telcordia.com > Subject: Re: AVP alignment >=20 >=20 > Our experience with implementations of DHCP is that alignment=20 > of AVPs (DHCP > options) isn't an important issue... >=20 > - Ralph >=20 > At 01:24 PM 8/20/2003 -0700, Yoshihiro Ohba wrote: > >The current PANA specification does not specify a rule to align AVPs. > >I think we should specify something about this. I'd suggest=20 > using the > >32-bit alignment rule as Diameter does. Here is the suggested text > >(borrowed from Diameter speicfication): > > > > "Each AVP MUST be padded to align on a 32-bit boundary. A=20 > number of zero- > > valued bytes are added to the end of the AVP Data field=20 > till a word > > boundary is reached. The length of the padding is not reflected in > > the AVP Length field." > > > > > >Yoshihiro Ohba > > > >=20 > > >=20 >=20 From pana-request@research.telcordia.com Thu Aug 21 06:45:38 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27623 for ; Thu, 21 Aug 2003 06:45:38 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7LAZ5sp009252; Thu, 21 Aug 2003 06:35:05 -0400 (EDT) Resent-Date: Thu, 21 Aug 2003 06:35:05 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [issue17] Error handling Date: Thu, 21 Aug 2003 13:31:10 +0300 Message-ID: Thread-Topic: [issue17] Error handling Thread-Index: AcNnzyGL5rHK+oIRQBKqdY6UaKlUIgAACS+g From: To: X-OriginalArrivalTime: 21 Aug 2003 10:31:10.0689 (UTC) FILETIME=[56B1CD10:01C367CF] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Dan Forsberg added the comment: Error message handling: --------------------------------------------------------- PANA-error message MAY be sent by either PaC or PAA when a badly formed PANA message is received or in case of other errors. If the cause of this error message was a request message (e.g., PANA-PAA-Discover or *-Request), then the request MAY be retransmitted immediately without waiting for its retransmission timer to go off. If the cause of the error was a response message, the receiver of the PANA-error SHOULD NOT resend the same response until it receives the next request. To defend against DoS attacks a timer MAY be used. One (1) error notification is sent to each different sender each N seconds. N is a configurable parameter. =20 When an error message is sent unprotected with MAC AVP and the lower-layer is insecure, the error message is treated as an informational message. The receiver of such an error message MUST NOT change its state unless the error persists and the PANA session is not making any progress. Error message format: --------------------------------------------------------- PANA-Error ::=3D < PANA-Header: 12 > < Session-Id >=20 < Result-Code > { Failed-AVP } * [ AVP ]=20 0*1 < MAC > ________________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue17 ________________________________________________ From pana-request@research.telcordia.com Thu Aug 21 06:48:36 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27748 for ; Thu, 21 Aug 2003 06:48:36 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7LAcAT3009491; Thu, 21 Aug 2003 06:38:10 -0400 (EDT) Resent-Date: Thu, 21 Aug 2003 06:38:10 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [issue19] Result-Code AVP values? Date: Thu, 21 Aug 2003 13:38:00 +0300 Message-ID: Thread-Topic: [issue19] Result-Code AVP values? Thread-Index: AcNnz8ZghhUjayJqSuKpknU7iQXvrwAAIBjw From: To: X-OriginalArrivalTime: 21 Aug 2003 10:38:01.0414 (UTC) FILETIME=[4B817660:01C367D0] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable -----Original Message----- From: ext Dan Forsberg [mailto:pana_issues@danforsberg.info] Sent: 21 August, 2003 13:34 To: Forsberg Dan (NRC/Helsinki) Subject: [issue19] Result-Code AVP values? Dan Forsberg added the comment: Added more values for better error handling: CONTRADICTING_AVPS 5007 AVP_NOT_ALLOWED 5008 ________________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue19 ________________________________________________ From pana-request@research.telcordia.com Thu Aug 21 07:21:02 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28864 for ; Thu, 21 Aug 2003 07:21:00 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7LBA90G010608; Thu, 21 Aug 2003 07:10:09 -0400 (EDT) Resent-Date: Thu, 21 Aug 2003 07:10:09 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 8 Date: Thu, 21 Aug 2003 14:06:20 +0300 Message-ID: Thread-Topic: Issue 8 Thread-Index: AcNXmWYQYvP8YZF/RcuJKJvDZLckHgJ+xwsQAY9hvpA= From: To: X-OriginalArrivalTime: 21 Aug 2003 11:06:21.0306 (UTC) FILETIME=[40B865A0:01C367D4] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <4mmEK.A.nlC.QiKR_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable For more information concerning this problem see: http://www.merit.edu/mail.archives/aaa-wg/msg05043.html PANA could use Authorization-Lifetime, Idle-Timeout and=20 Session-Timeout AVPs. If I have interpreted Diameter correctly these could mean as=20 follows for PANA: PANA Session-Timeout AVP can be an optional=20 AVP (or the value 0 would mean unlimited time).=20 Authorization-Lifetime would mean the lifetime before next=20 EAP reauthentication or EAP full authentication MUST happen.=20 Idle-Timeout AVP is evident. What is missing is a timer for PANA specific local reauthentication/=20 refresh, but I guess we don't want it, at least if Idle-Timeout=20 is used. This question is still left: > Also, how does PANA relate to link layer triggers (link=20 > up/down)? Should PAA terminate session for PaC if it gets=20 > link-down notification for it? - Dan > -----Original Message----- > From: ext [mailto:Dan.Forsberg@nokia.com] > Sent: 13 August, 2003 16:21 > To: alper@docomolabs-usa.com; pana@research.telcordia.com > Subject: RE: Issue 8 >=20 >=20 > Couple of thoughts for this issue.. >=20 > We have three levels of authentications with PANA.=20 > 1. PANA specific local re-auth. > 2. EAP re-auth. > 3. full EAP auth from scratch. > How to manage these.. >=20 > What lifetime does the "session lifetime" refer to in PANA? Diameter=20 > specifies Session-Timeout (from RADIUS) and=20 > Authorization-Lifetime AVPs.=20 > Authorization-Lifetime tells to the AAA Client when to do=20 > re-authorization (EAP re-auth in PANA case?). >=20 > 8.13 Session-Timeout AVP >=20 > The Session-Timeout AVP (AVP Code 27) [RADIUS] is of type=20 > Unsigned32 > and contains the maximum number of seconds of service to=20 > be provided > to the user before termination of the session. When both the > Session-Timeout and the Authorization-Lifetime AVPs are=20 > present in an > answer message, the former MUST be equal to or greater=20 > than the value > of the latter. >=20 > If I have understood properly Session-Timeout tells when both the=20 > authentication and authorization must be done from scratch, i.e. new=20 > keys must be derived etc. (full EAP auth). So this is used to define=20 > the session key lifetimes too? >=20 > Action to be taken can also be specified according to the NASREQ. > Sec. 4.10. talks about Session-Timeout and Authorization-Lifetime too: >=20 > The Termination-Action AVP is of type Enumerated and indicates what > action the NAS should take when the specified service is completed. > This AVP SHOULD only be present in authorization responses. The > following values are supported as listed in [RADIUSTypes]: >=20 > DEFAULT 0 > Upon termination of the authorized service the NAS MUST > terminate the current session. >=20 > AA-REQUEST 1 > When the authorized service terminates, the NAS SHOULD NOT > terminate the session or generate a=20 > Session-Termination-Request > (STR) command. Instead, it SHOULD generate a new AAR command > which contains the same value of the Session-Id AVP=20 > it sent in > the previous AAR command. It SHOULD also include=20 > the State AVP > from the previous AA-Answer (AAA) command, if it=20 > contained one. >=20 > >=20 > When used by 802.1X supplicants, the service typically=20 > terminates due > to the expiry of the Session-Timeout AVP. The access=20 > device may then > reauthenticate the user with a new AA-Request. The RECOMMENDED way > to do this in Diameter is to use just the=20 > Authorization-Lifetime AVP > rather than Session-Timeout and Termination-Action AVPs. However, > the Termination-Action AVP MAY be present when copied from a RADIUS > Access-Accept to a Diameter AA-Answer by a Translation Agent. >=20 > So NASREQ recommends to use Authorization-Lifetime AVP only=20 > with Diameter.=20 > Does NASREQ here mean full auth or just re-auth? From Diameter: > =09 > 8.12 Re-Auth-Request-Type AVP >=20 > The Re-Auth-Request-Type AVP (AVP Code 285) is of type=20 > Enumerated and > is included in application-specific auth answers to inform=20 > the client > of the action expected upon expiration of the=20 > Authorization-Lifetime. > If the answer message contains an Authorization-Lifetime AVP with a > positive value, the Re-Auth-Request-Type AVP MUST be present in an > answer message. The following values are defined: >=20 > AUTHORIZE_ONLY 0 > An authorization only re-auth is expected upon expiration of > the Authorization-Lifetime. This is the default value if the > AVP is not present in answer messages that include the > Authorization-Lifetime. >=20 > AUTHORIZE_AUTHENTICATE 1 > An authentication and authorization re-auth is expected upon > expiration of the Authorization-Lifetime. >=20 > So, if Authorization-Lifetime AVP is used in the AAA backend=20 > Re-Auth-Request-Type AVP is there too. Number of possible=20 > re-authentications=20 > before full authentication should be limited too=20 > (recommendation from some=20 > EAP methods, like EAP-SIM). How to do this? >=20 > -- >=20 > I'm also a bit worried about the fuzzy (timing) use of=20 > PANA-Reauth-Request=20 > message. What if "session lifetime" is 2 days, but PaC looses=20 > connection=20 > after 10 minutes? If we don't use refresh period, we could=20 > use Idle-Timeout=20 > AVP from NASREQ: >=20 > 6.4. Idle-Timeout AVP >=20 > The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32=20 > and sets the > maximum number of consecutive seconds of idle connection allowed to > the user before termination of the session or prompt. It=20 > MAY be used > in an authentication and/or authorization request (or=20 > challenge) as a > hint to the server that an idle timeout is desired, but=20 > the server is > not required to honor the hint in the corresponding response. The > default is none, or system specific. >=20 > Also, how does PANA relate to link layer triggers (link=20 > up/down)? Should=20 > PAA terminate session for PaC if it gets link-down=20 > notification for it? >=20 >=20 > - Dan >=20 > > -----Original Message----- > > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > > Sent: 31 July, 2003 22:26 > > To: pana@research.telcordia.com > > Subject: Issue 8 > >=20 > >=20 > >=20 > > The resolution recommended at the IETF presentation was to=20 > carry only > > session lifetime in PANA-bind-request message sent from PAA.=20 > > This would be a > > non-negotiable, informative parameter. Neither of grace=20 > > period nor re-auth > > timers will be exchanged between PAA and PaC. > >=20 > > Taking it one step further, we can also say it is the=20 > > responsibility of the > > PAA to initiate PANA authentication before the session expires. > > Nevertheless, sending the lifetime to PaC is still useful as=20 > > it helps PaC > > manage EAP SA and PANA SA efficiently. > >=20 > > Comments? If there are no objections, let's close this issue. > >=20 > > Alper > >=20 > >=20 >=20 >=20 From pana-request@research.telcordia.com Thu Aug 21 08:06:27 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00705 for ; Thu, 21 Aug 2003 08:06:21 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7LBrwuP011902; Thu, 21 Aug 2003 07:53:58 -0400 (EDT) Resent-Date: Thu, 21 Aug 2003 07:53:58 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: new [issue20] Retransmission timers and counts Date: Thu, 21 Aug 2003 14:50:06 +0300 Message-ID: Thread-Topic: new [issue20] Retransmission timers and counts Thread-Index: AcNhgOEwCKIfCfLTToyIpgJoAYlA6wGV1KIw From: To: X-OriginalArrivalTime: 21 Aug 2003 11:50:06.0699 (UTC) FILETIME=[5D9393B0:01C367DA] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable How about this? Copied this text from mipv6 draft (24) with = modifications=20 for pana. In most cases PAA is doing retransmissions, but for = PANA-Discover=20 and PANA-Reauth-Request from PaC, PaC is doing retransmissions. The TIMEOUT values are not from any spec. ------------ The retransmissions MUST use an exponential back-off process, in which = the timeout period is doubled upon each retransmission until either the = node receives a response or the timeout period reaches the value = MAX_RESPONSE_TIMEOUT. The first timeout period is MIN_RESPONSE_TIMEOUT. = PaC MAY continue sending PANA-Discover messages indefinetly with = MIN_INDEFINIT_DISCOVER interval. MIN_INDEFINIT_DISCOVER_TIMEOUT 1s ?? MAX_RESPONSE_TIMEOUT 64s ?? MIN_RESPONSE_TIMEOUT 250ms ?? ------------ Br, - Dan > -----Original Message----- > From: ext [mailto:Dan.Forsberg@nokia.com] > Sent: 13 August, 2003 12:54 > To: pana@research.telcordia.com > Subject: new [issue20] Retransmission timers and counts >=20 >=20 > http://danforsberg.info:8080/pana-issues/issue20 > "Define default timer and retransmission counts for=20 > the discover, start, reauth, bind, and terminate > messages." >=20 >=20 From pana-request@research.telcordia.com Thu Aug 21 08:54:20 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00708 for ; Thu, 21 Aug 2003 08:06:24 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7LBt4OJ012174; Thu, 21 Aug 2003 07:55:04 -0400 (EDT) Resent-Date: Thu, 21 Aug 2003 07:55:04 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [issue21] Conformancy with RFC2284bis and draft-ietf-aaa-eap-02 Date: Thu, 21 Aug 2003 14:54:59 +0300 Message-ID: Thread-Topic: [issue21] Conformancy with RFC2284bis and draft-ietf-aaa-eap-02 Thread-Index: AcNn2vdUIKi8kkv/R3uOJF6AKSBnSAAAAjJw From: To: X-OriginalArrivalTime: 21 Aug 2003 11:55:00.0417 (UTC) FILETIME=[0CA56310:01C367DB] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable New submission from Dan Forsberg : In draft-ietf-aaa-eap-02.txt section 2.5 retransmission for EAP packets is explained. Here NAS is doing the retransmissions (or vice versa). = PANA MUST be conformant with this draft and also RFC2284bis. This means that=20 PAA is doing retransmissions for PANA-Auth-Request message also. In case = of PANA-Reauth-Request the sender retransmits (PaC or PAA). PANA MUST also honor Multi-Round-Time-Out AVP. ---- From draft-ietf-aaa-eap-02.txt: 2.5 Retransmission As noted in [RFC2284bis], if an EAP packet is lost in transit between the authenticating peer and the NAS (or vice versa), the NAS will retransmit. It may be necessary to adjust retransmission strategies and authentication timeouts in certain cases. For example, when a token card is used, additional time may be required to allow the user to find the card and enter the token. Since the NAS will typically not have knowledge of the required parameters, these need to be provided by the Diameter server. If a Multi-Round-Time-Out AVP [BASE] is present in an Diameter-EAP-Answer message that also contains an EAP-Payload AVP, that value is used to set the EAP retransmission timer for that EAP Request, and that Request alone. ________________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue21 ________________________________________________ From pana-request@research.telcordia.com Thu Aug 21 21:31:58 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13230 for ; Thu, 21 Aug 2003 21:31:51 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7M1MjdV009612; Thu, 21 Aug 2003 21:22:45 -0400 (EDT) Resent-Date: Thu, 21 Aug 2003 21:22:45 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 21 Aug 2003 18:24:27 -0700 Subject: Re: Issue 8 From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > We have three levels of authentications with PANA. > 1. PANA specific local re-auth. > 2. EAP re-auth. > 3. full EAP auth from scratch. From PANA's perspective, when to perform #2 or #3 depends on EAP. Whenever EAP decides to send an EAP packet (for re-auth or auth, it does not matter), PANA sends it to its peer. PANA would not care about these timers other than to know what to put in the session-lifetime AVP. As I understand, there are some RADIUS-Diameter-AAA specific confusion in there. http://www.merit.edu/mail.archives/aaa-wg/msg05043.html . Let's wait to see its resolution in the AAA WG. Than we can talk about what AAA parameter helps the PAA determine the session-lifetime. Even than, I think this is not for the base protocol spec to talk about, but maybe a separate document like draft-congdon-radius-8021x is needed. > Also, how does PANA relate to link layer triggers (link up/down)? Should > PAA terminate session for PaC if it gets link-down notification for it? I think this is an implementation/deployment optimization. If the network trusts the validity of its link-layer triggers, it can do that. I think we are fine as long as we do not prevent that by the protocol design. Alper From pana-request@research.telcordia.com Thu Aug 21 21:56:31 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13805 for ; Thu, 21 Aug 2003 21:56:26 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7M1nVUR010728; Thu, 21 Aug 2003 21:49:31 -0400 (EDT) Resent-Date: Thu, 21 Aug 2003 21:49:31 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 21 Aug 2003 18:51:27 -0700 Subject: Re: [issue21] Conformancy with RFC2284bis and draft-ietf-aaa-eap-02 From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > New submission from Dan Forsberg : > > In draft-ietf-aaa-eap-02.txt section 2.5 retransmission for EAP packets > is explained. Here NAS is doing the retransmissions (or vice versa). PANA > MUST be conformant with this draft and also RFC2284bis. This means that > PAA is doing retransmissions for PANA-Auth-Request message also. That draft talks about the responsibilities of the NAS (network access server). NAS would implement a collection of protocols, such as PANA (in the form of a PAA module), Diameter (in the form of a Diameter client), draft-ietf-aaa-eap as the glue, etc. I think what you see in draft-ietf-aaa-eap-02.txt is what the glue should be doing: retransmitting EAP packets when needed. Imo, as the lower-layer of EAP, PANA does not have to deal with this. It just transmits EAP packets when it is given one. Alper > In case > of PANA-Reauth-Request the sender retransmits (PaC or PAA). PANA MUST > also honor Multi-Round-Time-Out AVP. > > ---- >> From draft-ietf-aaa-eap-02.txt: > > 2.5 Retransmission > > As noted in [RFC2284bis], if an EAP packet is lost in transit between > the authenticating peer and the NAS (or vice versa), the NAS will > retransmit. > > It may be necessary to adjust retransmission strategies and > authentication timeouts in certain cases. For example, when a token > card is used, additional time may be required to allow the user to > find the card and enter the token. Since the NAS will typically not > have knowledge of the required parameters, these need to be provided > by the Diameter server. > > If a Multi-Round-Time-Out AVP [BASE] is present in an > Diameter-EAP-Answer message that also contains an EAP-Payload AVP, > that value is used to set the EAP retransmission timer for that EAP > Request, and that Request alone. > > ________________________________________________ > PANA Issues > http://danforsberg.info:8080/pana-issues/issue21 > ________________________________________________ > > > From pana-request@research.telcordia.com Fri Aug 22 10:11:36 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26120 for ; Fri, 22 Aug 2003 10:11:32 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7ME1XXv006008; Fri, 22 Aug 2003 10:01:33 -0400 (EDT) Resent-Date: Fri, 22 Aug 2003 10:01:33 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [issue21] Conformancy with RFC2284bis anddraft-ietf-aaa-eap-02 Date: Fri, 22 Aug 2003 16:57:42 +0300 Message-ID: Thread-Topic: [issue21] Conformancy with RFC2284bis anddraft-ietf-aaa-eap-02 Thread-Index: AcNoT5+ww6VgHfHPTPW/FBxfFkxkPQAZD4mw From: To: , X-OriginalArrivalTime: 22 Aug 2003 13:57:43.0096 (UTC) FILETIME=[5B8ECB80:01C368B5] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Alper, This becomes a problem if the EAP server is in the AAA infrastructure=20 and the EAP server really doesn't do retransmissions itself (like these=20 documents describe). There is no case where EAP server does = retransmission=20 when in the backend AAA infrastructure, because AAA protocol is reliable = and the NAS takes care of the reliability too. Now PANA can do the same, = which makes the system simpler (no need to decide if retransmission is=20 needed or not for this PANA packet). The documents have evolved since we last time discussed about this = issue. Br, - Dan > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 22 August, 2003 04:51 > To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > Subject: Re: [issue21] Conformancy with RFC2284bis > anddraft-ietf-aaa-eap-02 >=20 >=20 >=20 > > New submission from Dan Forsberg : > >=20 > > In draft-ietf-aaa-eap-02.txt section 2.5 retransmission for=20 > EAP packets > > is explained. Here NAS is doing the retransmissions (or=20 > vice versa). PANA > > MUST be conformant with this draft and also RFC2284bis.=20 > This means that > > PAA is doing retransmissions for PANA-Auth-Request message also. >=20 > That draft talks about the responsibilities of the NAS (network access > server). NAS would implement a collection of protocols, such=20 > as PANA (in the > form of a PAA module), Diameter (in the form of a Diameter client), > draft-ietf-aaa-eap as the glue, etc. I think what you see in > draft-ietf-aaa-eap-02.txt is what the glue should be doing:=20 > retransmitting > EAP packets when needed. >=20 > Imo, as the lower-layer of EAP, PANA does not have to deal=20 > with this. It > just transmits EAP packets when it is given one. >=20 > Alper >=20 >=20 >=20 > > In case=20 > > of PANA-Reauth-Request the sender retransmits (PaC or PAA).=20 > PANA MUST > > also honor Multi-Round-Time-Out AVP. > >=20 > > ---- > >> From draft-ietf-aaa-eap-02.txt: > >=20 > > 2.5 Retransmission > >=20 > > As noted in [RFC2284bis], if an EAP packet is lost in=20 > transit between > > the authenticating peer and the NAS (or vice versa), the NAS will > > retransmit. > >=20 > > It may be necessary to adjust retransmission strategies and > > authentication timeouts in certain cases. For example,=20 > when a token > > card is used, additional time may be required to allow the user to > > find the card and enter the token. Since the NAS will=20 > typically not > > have knowledge of the required parameters, these need to=20 > be provided > > by the Diameter server. > >=20 > > If a Multi-Round-Time-Out AVP [BASE] is present in an > > Diameter-EAP-Answer message that also contains an EAP-Payload AVP, > > that value is used to set the EAP retransmission timer for that EAP > > Request, and that Request alone. > >=20 > > ________________________________________________ > > PANA Issues > > http://danforsberg.info:8080/pana-issues/issue21 > > ________________________________________________ > >=20 > >=20 > >=20 >=20 >=20 From pana-request@research.telcordia.com Sat Aug 23 13:30:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18374 for ; Sat, 23 Aug 2003 13:30:52 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7NHKseb027131; Sat, 23 Aug 2003 13:20:54 -0400 (EDT) Resent-Date: Sat, 23 Aug 2003 13:20:54 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Sat, 23 Aug 2003 10:22:24 -0700 Subject: Re: [issue21] Conformancy with RFC2284bis anddraft-ietf-aaa-eap-02 From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Dan, From RFC2284bis: "In EAP, the authenticator retransmits Requests that have not yet received Responses, so that EAP does not assume that lower layers are reliable." "The authenticator is responsible for retransmitting requests as described in Section 4.1." "The EAP layer receives and transmits EAP packets via the lower layer, implements duplicate detection and retransmission, and delivers and receives EAP messages to and from EAP methods." So, PANA, as an EAP lower-layer, does not have to provide retransmissions for reliable EAP delivery. Alper > Alper, > > This becomes a problem if the EAP server is in the AAA infrastructure > and the EAP server really doesn't do retransmissions itself (like these > documents describe). There is no case where EAP server does retransmission > when in the backend AAA infrastructure, because AAA protocol is reliable > and the NAS takes care of the reliability too. Now PANA can do the same, > which makes the system simpler (no need to decide if retransmission is > needed or not for this PANA packet). > > The documents have evolved since we last time discussed about this issue. > > Br, > - Dan > >> -----Original Message----- >> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] >> Sent: 22 August, 2003 04:51 >> To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com >> Subject: Re: [issue21] Conformancy with RFC2284bis >> anddraft-ietf-aaa-eap-02 >> >> >> >>> New submission from Dan Forsberg : >>> >>> In draft-ietf-aaa-eap-02.txt section 2.5 retransmission for >> EAP packets >>> is explained. Here NAS is doing the retransmissions (or >> vice versa). PANA >>> MUST be conformant with this draft and also RFC2284bis. >> This means that >>> PAA is doing retransmissions for PANA-Auth-Request message also. >> >> That draft talks about the responsibilities of the NAS (network access >> server). NAS would implement a collection of protocols, such >> as PANA (in the >> form of a PAA module), Diameter (in the form of a Diameter client), >> draft-ietf-aaa-eap as the glue, etc. I think what you see in >> draft-ietf-aaa-eap-02.txt is what the glue should be doing: >> retransmitting >> EAP packets when needed. >> >> Imo, as the lower-layer of EAP, PANA does not have to deal >> with this. It >> just transmits EAP packets when it is given one. >> >> Alper >> >> >> >>> In case >>> of PANA-Reauth-Request the sender retransmits (PaC or PAA). >> PANA MUST >>> also honor Multi-Round-Time-Out AVP. >>> >>> ---- >>>> From draft-ietf-aaa-eap-02.txt: >>> >>> 2.5 Retransmission >>> >>> As noted in [RFC2284bis], if an EAP packet is lost in >> transit between >>> the authenticating peer and the NAS (or vice versa), the NAS will >>> retransmit. >>> >>> It may be necessary to adjust retransmission strategies and >>> authentication timeouts in certain cases. For example, >> when a token >>> card is used, additional time may be required to allow the user to >>> find the card and enter the token. Since the NAS will >> typically not >>> have knowledge of the required parameters, these need to >> be provided >>> by the Diameter server. >>> >>> If a Multi-Round-Time-Out AVP [BASE] is present in an >>> Diameter-EAP-Answer message that also contains an EAP-Payload AVP, >>> that value is used to set the EAP retransmission timer for that EAP >>> Request, and that Request alone. >>> >>> ________________________________________________ >>> PANA Issues >>> http://danforsberg.info:8080/pana-issues/issue21 >>> ________________________________________________ >>> >>> >>> >> >> > > From pana-request@research.telcordia.com Mon Aug 25 03:46:14 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00656 for ; Mon, 25 Aug 2003 03:46:09 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7P7bC0D026676; Mon, 25 Aug 2003 03:37:12 -0400 (EDT) Resent-Date: Mon, 25 Aug 2003 03:37:12 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [issue21] Conformancy with RFC2284bis anddraft-ietf-aaa-eap-02 Date: Mon, 25 Aug 2003 10:33:16 +0300 Message-ID: Thread-Topic: [issue21] Conformancy with RFC2284bis anddraft-ietf-aaa-eap-02 Thread-Index: AcNpmuGmkSuNP4YBTluiYrvl1Qg+cABPvyMA From: To: , X-OriginalArrivalTime: 25 Aug 2003 07:33:16.0618 (UTC) FILETIME=[261AD2A0:01C36ADB] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <7LB6b.A.rgG.nybS_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Alper, You didn't address the issue itself. Do you want to say that in order to = use PANA with backend AAA and EAP Server, PAA must be used together with = a NAS? This would mean that NAS takes care of EAP retransmission timer, = but PANA actually does the transmission. Do you see some problems if PANA provides reliable transport for EAP = messages? - Dan > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 23 August, 2003 20:22 > To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > Subject: Re: [issue21] Conformancy with RFC2284bis > anddraft-ietf-aaa-eap-02 >=20 >=20 > Dan, >=20 > From RFC2284bis:=20 >=20 > "In EAP, the authenticator retransmits Requests that have not=20 > yet received > Responses, so that EAP does not assume that lower layers are=20 > reliable." >=20 > "The authenticator is responsible for retransmitting requests=20 > as described > in Section 4.1." >=20 > "The EAP layer receives and transmits EAP packets via the lower layer, > implements duplicate detection and retransmission, and=20 > delivers and receives > EAP messages to and from EAP methods." >=20 > So, PANA, as an EAP lower-layer, does not have to provide=20 > retransmissions > for reliable EAP delivery. >=20 > Alper >=20 >=20 > > Alper, > >=20 > > This becomes a problem if the EAP server is in the AAA=20 > infrastructure > > and the EAP server really doesn't do retransmissions itself=20 > (like these > > documents describe). There is no case where EAP server does=20 > retransmission > > when in the backend AAA infrastructure, because AAA=20 > protocol is reliable > > and the NAS takes care of the reliability too. Now PANA can=20 > do the same, > > which makes the system simpler (no need to decide if=20 > retransmission is > > needed or not for this PANA packet). > >=20 > > The documents have evolved since we last time discussed=20 > about this issue. > >=20 > > Br, > > - Dan > >=20 > >> -----Original Message----- > >> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > >> Sent: 22 August, 2003 04:51 > >> To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > >> Subject: Re: [issue21] Conformancy with RFC2284bis > >> anddraft-ietf-aaa-eap-02 > >>=20 > >>=20 > >>=20 > >>> New submission from Dan Forsberg : > >>>=20 > >>> In draft-ietf-aaa-eap-02.txt section 2.5 retransmission for > >> EAP packets > >>> is explained. Here NAS is doing the retransmissions (or > >> vice versa). PANA > >>> MUST be conformant with this draft and also RFC2284bis. > >> This means that > >>> PAA is doing retransmissions for PANA-Auth-Request message also. > >>=20 > >> That draft talks about the responsibilities of the NAS=20 > (network access > >> server). NAS would implement a collection of protocols, such > >> as PANA (in the > >> form of a PAA module), Diameter (in the form of a Diameter client), > >> draft-ietf-aaa-eap as the glue, etc. I think what you see in > >> draft-ietf-aaa-eap-02.txt is what the glue should be doing: > >> retransmitting > >> EAP packets when needed. > >>=20 > >> Imo, as the lower-layer of EAP, PANA does not have to deal > >> with this. It > >> just transmits EAP packets when it is given one. > >>=20 > >> Alper > >>=20 > >>=20 > >>=20 > >>> In case=20 > >>> of PANA-Reauth-Request the sender retransmits (PaC or PAA). > >> PANA MUST > >>> also honor Multi-Round-Time-Out AVP. > >>>=20 > >>> ---- > >>>> From draft-ietf-aaa-eap-02.txt: > >>>=20 > >>> 2.5 Retransmission > >>>=20 > >>> As noted in [RFC2284bis], if an EAP packet is lost in > >> transit between > >>> the authenticating peer and the NAS (or vice versa), the NAS will > >>> retransmit. > >>>=20 > >>> It may be necessary to adjust retransmission strategies and > >>> authentication timeouts in certain cases. For example, > >> when a token > >>> card is used, additional time may be required to allow=20 > the user to > >>> find the card and enter the token. Since the NAS will > >> typically not > >>> have knowledge of the required parameters, these need to > >> be provided > >>> by the Diameter server. > >>>=20 > >>> If a Multi-Round-Time-Out AVP [BASE] is present in an > >>> Diameter-EAP-Answer message that also contains an=20 > EAP-Payload AVP, > >>> that value is used to set the EAP retransmission timer=20 > for that EAP > >>> Request, and that Request alone. > >>>=20 > >>> ________________________________________________ > >>> PANA Issues > >>> http://danforsberg.info:8080/pana-issues/issue21 > >>> ________________________________________________ > >>>=20 > >>>=20 > >>>=20 > >>=20 > >>=20 > >=20 > >=20 >=20 >=20 From pana-request@research.telcordia.com Mon Aug 25 04:10:03 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01451 for ; Mon, 25 Aug 2003 04:10:03 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7P831Fn027420; Mon, 25 Aug 2003 04:03:01 -0400 (EDT) Resent-Date: Mon, 25 Aug 2003 04:03:01 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Mon, 25 Aug 2003 01:04:52 -0700 Subject: Re: [issue21] Conformancy with RFC2284bis anddraft-ietf-aaa-eap-02 From: Alper Yegin To: , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Dan, > Alper, > > You didn't address the issue itself. Do you want to say that in order to use > PANA with backend AAA and EAP Server, PAA must be used together with a NAS? > This would mean that NAS takes care of EAP retransmission timer, but PANA > actually does the transmission. Generally, people would call the node that implements PAA a network access server (NAS). NAS is a functional entity in an access network (it might reside on AP with IEEE 802.11, BRAS with DSL, PDSN with CDMA2000 networks). It would implement PANA, Diameter, and draft-ietf-aaa-eap, and a bunch of other stuff. This collection takes care of the EAP retransmissions, without PANA having to deal with it. > > Do you see some problems if PANA provides reliable transport for EAP messages? > Yes, unjustified complexity for a functionality that is not PANA's responsibility and that is already taken care of by something else. Alper > - Dan > >> -----Original Message----- >> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] >> Sent: 23 August, 2003 20:22 >> To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com >> Subject: Re: [issue21] Conformancy with RFC2284bis >> anddraft-ietf-aaa-eap-02 >> >> >> Dan, >> >> From RFC2284bis: >> >> "In EAP, the authenticator retransmits Requests that have not >> yet received >> Responses, so that EAP does not assume that lower layers are >> reliable." >> >> "The authenticator is responsible for retransmitting requests >> as described >> in Section 4.1." >> >> "The EAP layer receives and transmits EAP packets via the lower layer, >> implements duplicate detection and retransmission, and >> delivers and receives >> EAP messages to and from EAP methods." >> >> So, PANA, as an EAP lower-layer, does not have to provide >> retransmissions >> for reliable EAP delivery. >> >> Alper >> >> >>> Alper, >>> >>> This becomes a problem if the EAP server is in the AAA >> infrastructure >>> and the EAP server really doesn't do retransmissions itself >> (like these >>> documents describe). There is no case where EAP server does >> retransmission >>> when in the backend AAA infrastructure, because AAA >> protocol is reliable >>> and the NAS takes care of the reliability too. Now PANA can >> do the same, >>> which makes the system simpler (no need to decide if >> retransmission is >>> needed or not for this PANA packet). >>> >>> The documents have evolved since we last time discussed >> about this issue. >>> >>> Br, >>> - Dan >>> >>>> -----Original Message----- >>>> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] >>>> Sent: 22 August, 2003 04:51 >>>> To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com >>>> Subject: Re: [issue21] Conformancy with RFC2284bis >>>> anddraft-ietf-aaa-eap-02 >>>> >>>> >>>> >>>>> New submission from Dan Forsberg : >>>>> >>>>> In draft-ietf-aaa-eap-02.txt section 2.5 retransmission for >>>> EAP packets >>>>> is explained. Here NAS is doing the retransmissions (or >>>> vice versa). PANA >>>>> MUST be conformant with this draft and also RFC2284bis. >>>> This means that >>>>> PAA is doing retransmissions for PANA-Auth-Request message also. >>>> >>>> That draft talks about the responsibilities of the NAS >> (network access >>>> server). NAS would implement a collection of protocols, such >>>> as PANA (in the >>>> form of a PAA module), Diameter (in the form of a Diameter client), >>>> draft-ietf-aaa-eap as the glue, etc. I think what you see in >>>> draft-ietf-aaa-eap-02.txt is what the glue should be doing: >>>> retransmitting >>>> EAP packets when needed. >>>> >>>> Imo, as the lower-layer of EAP, PANA does not have to deal >>>> with this. It >>>> just transmits EAP packets when it is given one. >>>> >>>> Alper >>>> >>>> >>>> >>>>> In case >>>>> of PANA-Reauth-Request the sender retransmits (PaC or PAA). >>>> PANA MUST >>>>> also honor Multi-Round-Time-Out AVP. >>>>> >>>>> ---- >>>>>> From draft-ietf-aaa-eap-02.txt: >>>>> >>>>> 2.5 Retransmission >>>>> >>>>> As noted in [RFC2284bis], if an EAP packet is lost in >>>> transit between >>>>> the authenticating peer and the NAS (or vice versa), the NAS will >>>>> retransmit. >>>>> >>>>> It may be necessary to adjust retransmission strategies and >>>>> authentication timeouts in certain cases. For example, >>>> when a token >>>>> card is used, additional time may be required to allow >> the user to >>>>> find the card and enter the token. Since the NAS will >>>> typically not >>>>> have knowledge of the required parameters, these need to >>>> be provided >>>>> by the Diameter server. >>>>> >>>>> If a Multi-Round-Time-Out AVP [BASE] is present in an >>>>> Diameter-EAP-Answer message that also contains an >> EAP-Payload AVP, >>>>> that value is used to set the EAP retransmission timer >> for that EAP >>>>> Request, and that Request alone. >>>>> >>>>> ________________________________________________ >>>>> PANA Issues >>>>> http://danforsberg.info:8080/pana-issues/issue21 >>>>> ________________________________________________ >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > > From pana-request@research.telcordia.com Mon Aug 25 06:40:14 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09202 for ; Mon, 25 Aug 2003 06:40:08 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7PAVi6n009038; Mon, 25 Aug 2003 06:31:44 -0400 (EDT) Resent-Date: Mon, 25 Aug 2003 06:31:44 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [issue21] Conformancy with RFC2284bis anddraft-ietf-aaa-eap-02 Date: Mon, 25 Aug 2003 13:27:44 +0300 Message-ID: Thread-Topic: [issue21] Conformancy with RFC2284bis anddraft-ietf-aaa-eap-02 Thread-Index: AcNq30t8V4SeLzYFQvyl5P62V8gg6AABB5Eg From: To: , X-OriginalArrivalTime: 25 Aug 2003 10:27:45.0441 (UTC) FILETIME=[86027110:01C36AF3] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable Alper, Ok, I see your viewpoint (not that EAP Server is doing retransmits). = Even though I think that PANA could do retransmits for all PANA packets, = I agree that in case of PAA together with NAS this is ok. This should be clarified in the draft. I.e. update: "PANA relies on EAP-layer retransmission for retransmitting EAP=20 Request based on timer. Other PANA layer messages that require a=20 response from the communicating peer are retransmitted based on=20 timer at PANA-layer until a response is received (in which case the=20 retransmission timer is stopped) or the number of retransmission=20 reaches the maximum value (in which case the PANA session MUST be=20 deleted immediately)." to: "PANA relies on EAP-layer retransmissions, or for example NAS=20 functionality, for retransmitting EAP Requests based on timer. =20 Other PANA layer..." - Dan > -----Original Message----- > From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > Sent: 25 August, 2003 11:05 > To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > Subject: Re: [issue21] Conformancy with RFC2284bis > anddraft-ietf-aaa-eap-02 >=20 >=20 > Dan, >=20 > > Alper, > >=20 > > You didn't address the issue itself. Do you want to say=20 > that in order to use > > PANA with backend AAA and EAP Server, PAA must be used=20 > together with a NAS? > > This would mean that NAS takes care of EAP retransmission=20 > timer, but PANA > > actually does the transmission. >=20 > Generally, people would call the node that implements PAA a=20 > network access > server (NAS). NAS is a functional entity in an access network=20 > (it might > reside on AP with IEEE 802.11, BRAS with DSL, PDSN with=20 > CDMA2000 networks). > It would implement PANA, Diameter, and draft-ietf-aaa-eap,=20 > and a bunch of > other stuff. This collection takes care of the EAP=20 > retransmissions, without > PANA having to deal with it. >=20 > >=20 > > Do you see some problems if PANA provides reliable=20 > transport for EAP messages? > >=20 >=20 > Yes, unjustified complexity for a functionality that is not PANA's > responsibility and that is already taken care of by something else. >=20 > Alper >=20 > > - Dan > >=20 > >> -----Original Message----- > >> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > >> Sent: 23 August, 2003 20:22 > >> To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > >> Subject: Re: [issue21] Conformancy with RFC2284bis > >> anddraft-ietf-aaa-eap-02 > >>=20 > >>=20 > >> Dan, > >>=20 > >> From RFC2284bis: > >>=20 > >> "In EAP, the authenticator retransmits Requests that have not > >> yet received > >> Responses, so that EAP does not assume that lower layers are > >> reliable." > >>=20 > >> "The authenticator is responsible for retransmitting requests > >> as described > >> in Section 4.1." > >>=20 > >> "The EAP layer receives and transmits EAP packets via the=20 > lower layer, > >> implements duplicate detection and retransmission, and > >> delivers and receives > >> EAP messages to and from EAP methods." > >>=20 > >> So, PANA, as an EAP lower-layer, does not have to provide > >> retransmissions > >> for reliable EAP delivery. > >>=20 > >> Alper > >>=20 > >>=20 > >>> Alper, > >>>=20 > >>> This becomes a problem if the EAP server is in the AAA > >> infrastructure > >>> and the EAP server really doesn't do retransmissions itself > >> (like these > >>> documents describe). There is no case where EAP server does > >> retransmission > >>> when in the backend AAA infrastructure, because AAA > >> protocol is reliable > >>> and the NAS takes care of the reliability too. Now PANA can > >> do the same, > >>> which makes the system simpler (no need to decide if > >> retransmission is > >>> needed or not for this PANA packet). > >>>=20 > >>> The documents have evolved since we last time discussed > >> about this issue. > >>>=20 > >>> Br, > >>> - Dan > >>>=20 > >>>> -----Original Message----- > >>>> From: ext Alper Yegin [mailto:alper@docomolabs-usa.com] > >>>> Sent: 22 August, 2003 04:51 > >>>> To: Forsberg Dan (NRC/Helsinki); pana@research.telcordia.com > >>>> Subject: Re: [issue21] Conformancy with RFC2284bis > >>>> anddraft-ietf-aaa-eap-02 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>> New submission from Dan Forsberg : > >>>>>=20 > >>>>> In draft-ietf-aaa-eap-02.txt section 2.5 retransmission for > >>>> EAP packets > >>>>> is explained. Here NAS is doing the retransmissions (or > >>>> vice versa). PANA > >>>>> MUST be conformant with this draft and also RFC2284bis. > >>>> This means that > >>>>> PAA is doing retransmissions for PANA-Auth-Request message also. > >>>>=20 > >>>> That draft talks about the responsibilities of the NAS > >> (network access > >>>> server). NAS would implement a collection of protocols, such > >>>> as PANA (in the > >>>> form of a PAA module), Diameter (in the form of a=20 > Diameter client), > >>>> draft-ietf-aaa-eap as the glue, etc. I think what you see in > >>>> draft-ietf-aaa-eap-02.txt is what the glue should be doing: > >>>> retransmitting > >>>> EAP packets when needed. > >>>>=20 > >>>> Imo, as the lower-layer of EAP, PANA does not have to deal > >>>> with this. It > >>>> just transmits EAP packets when it is given one. > >>>>=20 > >>>> Alper > >>>>=20 > >>>>=20 > >>>>=20 > >>>>> In case=20 > >>>>> of PANA-Reauth-Request the sender retransmits (PaC or PAA). > >>>> PANA MUST > >>>>> also honor Multi-Round-Time-Out AVP. > >>>>>=20 > >>>>> ---- > >>>>>> From draft-ietf-aaa-eap-02.txt: > >>>>>=20 > >>>>> 2.5 Retransmission > >>>>>=20 > >>>>> As noted in [RFC2284bis], if an EAP packet is lost in > >>>> transit between > >>>>> the authenticating peer and the NAS (or vice versa),=20 > the NAS will > >>>>> retransmit. > >>>>>=20 > >>>>> It may be necessary to adjust retransmission strategies and > >>>>> authentication timeouts in certain cases. For example, > >>>> when a token > >>>>> card is used, additional time may be required to allow > >> the user to > >>>>> find the card and enter the token. Since the NAS will > >>>> typically not > >>>>> have knowledge of the required parameters, these need to > >>>> be provided > >>>>> by the Diameter server. > >>>>>=20 > >>>>> If a Multi-Round-Time-Out AVP [BASE] is present in an > >>>>> Diameter-EAP-Answer message that also contains an > >> EAP-Payload AVP, > >>>>> that value is used to set the EAP retransmission timer > >> for that EAP > >>>>> Request, and that Request alone. > >>>>>=20 > >>>>> ________________________________________________ > >>>>> PANA Issues > >>>>> http://danforsberg.info:8080/pana-issues/issue21 > >>>>> ________________________________________________ > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>=20 > >>>>=20 > >>>=20 > >>>=20 > >>=20 > >>=20 > >=20 > >=20 > >=20 >=20 >=20 From pana-request@research.telcordia.com Wed Aug 27 11:37:31 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09890 for ; Wed, 27 Aug 2003 11:37:13 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7RFQGxu005770; Wed, 27 Aug 2003 11:26:16 -0400 (EDT) Resent-Date: Wed, 27 Aug 2003 11:26:16 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: New [issue23] PANA Message type/AVP numbers and Diameter command codes/AVPs Date: Wed, 27 Aug 2003 18:26:13 +0300 Message-ID: Thread-Topic: [issue23] PANA Message type/AVP numbers and Diameter command codes/AVPs Thread-Index: AcNrz6yEZ90LMtGIRVGlzV2GXiII+QAAjYMA From: To: X-OriginalArrivalTime: 27 Aug 2003 15:26:13.0443 (UTC) FILETIME=[8CD63130:01C36CAF] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable New submission from Dan Forsberg : To support smoother integration for PAA with a NAS,=20 (A) PANA message types should be conformant with RADIUS/DIAMETER command codes. (B) PANA AVP types should be conformant with RADIUS/DIAMETER AVP types. ---------- category: Technical document: draft-ietf-pana-pana-xx.txt messages: 74 nosy: dforsber priority: Should Fix status: Pending title: PANA Message type/AVP numbers and Diameter command codes/AVPs ________________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue23 ________________________________________________ From pana-request@research.telcordia.com Wed Aug 27 12:27:52 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09891 for ; Wed, 27 Aug 2003 11:37:13 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7RFU2r5006018; Wed, 27 Aug 2003 11:30:02 -0400 (EDT) Resent-Date: Wed, 27 Aug 2003 11:30:02 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: New [issue22] PANA Message Types Date: Wed, 27 Aug 2003 18:26:14 +0300 Message-ID: Thread-Topic: [issue22] PANA Message Types vrs. Diameter Command Codes Thread-Index: AcNrzzt2OQY/Eo/oQpigioRFPCYCqQAAlHTA From: To: X-OriginalArrivalTime: 27 Aug 2003 15:26:15.0193 (UTC) FILETIME=[8DE13890:01C36CAF] X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <774Lc.A.5dB.65MT_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable New submission from Dan Forsberg : Currently PANA requests and answers have different message types AND requests also use the REQ flag. This is redundant.=20 PANA should use the same message type for request and answers and differentiate them with the REQ flag. ---------- category: Technical document: draft-ietf-pana-pana-xx.txt messages: 73 nosy: dforsber priority: Must Fix status: No Discussion title: PANA Message Types ________________________________________________ PANA Issues http://danforsberg.info:8080/pana-issues/issue22 ________________________________________________ From pana-request@research.telcordia.com Wed Aug 27 17:14:59 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09094 for ; Wed, 27 Aug 2003 17:14:54 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7RL6C4w019909; Wed, 27 Aug 2003 17:06:12 -0400 (EDT) Resent-Date: Wed, 27 Aug 2003 17:06:12 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 27 Aug 2003 14:04:23 -0700 From: Yoshihiro Ohba Subject: Re: New [issue22] PANA Message Types In-reply-to: To: Dan.Forsberg@nokia.com Cc: pana@research.telcordia.com Message-id: <20030827210423.GA23382@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, pana@research.telcordia.com User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 27 References: X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com I agree. Yoshihiro Ohba On Wed, Aug 27, 2003 at 06:26:14PM +0300, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > Currently PANA requests and answers have different message types AND > requests also use the REQ flag. This is redundant. > > PANA should use the same message type for request and answers and > differentiate them with the REQ flag. > > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 73 > nosy: dforsber > priority: Must Fix > status: No Discussion > title: PANA Message Types > ________________________________________________ > PANA Issues > http://danforsberg.info:8080/pana-issues/issue22 > ________________________________________________ > From pana-request@research.telcordia.com Wed Aug 27 17:15:48 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09143 for ; Wed, 27 Aug 2003 17:15:43 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7RL8fK4020122; Wed, 27 Aug 2003 17:08:41 -0400 (EDT) Resent-Date: Wed, 27 Aug 2003 17:08:41 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 27 Aug 2003 14:07:38 -0700 From: Yoshihiro Ohba Subject: Re: New [issue23] PANA Message type/AVP numbers and Diameter command codes/AVPs In-reply-to: To: Dan.Forsberg@nokia.com Cc: pana@research.telcordia.com Message-id: <20030827210738.GB23382@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, pana@research.telcordia.com User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 32 References: X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Wed, Aug 27, 2003 at 06:26:13PM +0300, Dan.Forsberg@nokia.com wrote: > New submission from Dan Forsberg : > > To support smoother integration for PAA with a NAS, > > (A) PANA message types should be conformant with RADIUS/DIAMETER command > codes. What is the definition of "conformant" here? > > (B) PANA AVP types should be conformant with RADIUS/DIAMETER AVP types. I have the same question as above. Yoshihiro Ohba > > > ---------- > category: Technical > document: draft-ietf-pana-pana-xx.txt > messages: 74 > nosy: dforsber > priority: Should Fix > status: Pending > title: PANA Message type/AVP numbers and Diameter command codes/AVPs > ________________________________________________ > PANA Issues > http://danforsberg.info:8080/pana-issues/issue23 > ________________________________________________ > From pana-request@research.telcordia.com Wed Aug 27 20:59:16 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25087 for ; Wed, 27 Aug 2003 20:59:10 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7S0oEPU028694; Wed, 27 Aug 2003 20:50:14 -0400 (EDT) Resent-Date: Wed, 27 Aug 2003 20:50:14 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Wed, 27 Aug 2003 17:50:53 -0700 Subject: Re: new [issue20] Retransmission timers and counts From: Alper Yegin To: , Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi Dan, How about following the rfc3315 model? This spec first identifies the various components of a retransmission policy (section 14) and for each message it specifies what they should be (like in 17.1.2 where IRT=SOL_TIMEOUT for solicit messages). And finally defines the default values for the constants in 5.5 (e.g., SOL_TIMEOUT=1sec) The PANA messages that require retransmission are: PANA-PAA-Discover PANA-Start-Request PANA-Bind-Request PANA-Reauth-Request PANA-Termination-Request Comments? Alper > How about this? Copied this text from mipv6 draft (24) with modifications > for pana. In most cases PAA is doing retransmissions, but for PANA-Discover > and PANA-Reauth-Request from PaC, PaC is doing retransmissions. > > The TIMEOUT values are not from any spec. > > ------------ > The retransmissions MUST use an exponential back-off process, in which the > timeout period is doubled upon each retransmission until either the node > receives a response or the timeout period reaches the value > MAX_RESPONSE_TIMEOUT. The first timeout period is MIN_RESPONSE_TIMEOUT. PaC > MAY continue sending PANA-Discover messages indefinetly with > MIN_INDEFINIT_DISCOVER interval. > > MIN_INDEFINIT_DISCOVER_TIMEOUT 1s ?? > MAX_RESPONSE_TIMEOUT 64s ?? > MIN_RESPONSE_TIMEOUT 250ms ?? > ------------ > > > Br, > - Dan > >> -----Original Message----- >> From: ext [mailto:Dan.Forsberg@nokia.com] >> Sent: 13 August, 2003 12:54 >> To: pana@research.telcordia.com >> Subject: new [issue20] Retransmission timers and counts >> >> >> http://danforsberg.info:8080/pana-issues/issue20 >> "Define default timer and retransmission counts for >> the discover, start, reauth, bind, and terminate >> messages." >> >> > > > From pana-request@research.telcordia.com Thu Aug 28 16:15:15 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15004 for ; Thu, 28 Aug 2003 16:15:09 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7SK6Nnn012015; Thu, 28 Aug 2003 16:06:23 -0400 (EDT) Resent-Date: Thu, 28 Aug 2003 16:06:23 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 28 Aug 2003 13:02:18 -0700 From: Yoshihiro Ohba Subject: Re: new [issue20] Retransmission timers and counts In-reply-to: To: Alper Yegin Cc: Dan.Forsberg@nokia.com, pana@research.telcordia.com Message-id: <20030828200218.GD26446@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Alper Yegin , Dan.Forsberg@nokia.com, pana@research.telcordia.com User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 79 References: X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Wed, Aug 27, 2003 at 05:50:53PM -0700, Alper Yegin wrote: > > Hi Dan, > > How about following the rfc3315 model? This spec first identifies the > various components of a retransmission policy (section 14) and for each > message it specifies what they should be (like in 17.1.2 where > IRT=SOL_TIMEOUT for solicit messages). And finally defines the default > values for the constants in 5.5 (e.g., SOL_TIMEOUT=1sec) I agree on using the RFC3315 methodology for defining retransmission policy and default values. This is very nice. > > The PANA messages that require retransmission are: > > PANA-PAA-Discover > PANA-Start-Request Considering the case of using optional stateless cookie, I'd suggest retransmitting PANA-Start-Answer instead of PANA-Start-Request. > PANA-Bind-Request > PANA-Reauth-Request > PANA-Termination-Request Yoshihiro Ohba > > Comments? > > Alper > > > > > > > > > How about this? Copied this text from mipv6 draft (24) with modifications > > for pana. In most cases PAA is doing retransmissions, but for PANA-Discover > > and PANA-Reauth-Request from PaC, PaC is doing retransmissions. > > > > The TIMEOUT values are not from any spec. > > > > ------------ > > The retransmissions MUST use an exponential back-off process, in which the > > timeout period is doubled upon each retransmission until either the node > > receives a response or the timeout period reaches the value > > MAX_RESPONSE_TIMEOUT. The first timeout period is MIN_RESPONSE_TIMEOUT. PaC > > MAY continue sending PANA-Discover messages indefinetly with > > MIN_INDEFINIT_DISCOVER interval. > > > > MIN_INDEFINIT_DISCOVER_TIMEOUT 1s ?? > > MAX_RESPONSE_TIMEOUT 64s ?? > > MIN_RESPONSE_TIMEOUT 250ms ?? > > ------------ > > > > > > Br, > > - Dan > > > >> -----Original Message----- > >> From: ext [mailto:Dan.Forsberg@nokia.com] > >> Sent: 13 August, 2003 12:54 > >> To: pana@research.telcordia.com > >> Subject: new [issue20] Retransmission timers and counts > >> > >> > >> http://danforsberg.info:8080/pana-issues/issue20 > >> "Define default timer and retransmission counts for > >> the discover, start, reauth, bind, and terminate > >> messages." > >> > >> > > > > > > > From pana-request@research.telcordia.com Thu Aug 28 16:27:56 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15933 for ; Thu, 28 Aug 2003 16:27:56 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7SKKcWY012787; Thu, 28 Aug 2003 16:20:38 -0400 (EDT) Resent-Date: Thu, 28 Aug 2003 16:20:38 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 28 Aug 2003 13:21:11 -0700 Subject: Re: new [issue20] Retransmission timers and counts From: Alper Yegin To: Yoshihiro Ohba CC: , Message-ID: In-Reply-To: <20030828200218.GD26446@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit >> The PANA messages that require retransmission are: >> >> PANA-PAA-Discover >> PANA-Start-Request > > Considering the case of using optional stateless cookie, I'd suggest > retransmitting PANA-Start-Answer instead of PANA-Start-Request. I think this makes sense. Especially, if there are multiple PAAs on the link, and the PaC will choose one of them to move forward with the PANA exchange. > >> PANA-Bind-Request >> PANA-Reauth-Request >> PANA-Termination-Request Alper From pana-request@research.telcordia.com Thu Aug 28 17:10:15 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19246 for ; Thu, 28 Aug 2003 17:10:13 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7SL2uGx014985; Thu, 28 Aug 2003 17:02:56 -0400 (EDT) Resent-Date: Thu, 28 Aug 2003 17:02:56 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 28 Aug 2003 13:58:16 -0700 From: Yoshihiro Ohba Subject: Re: New [issue23] PANA Message type/AVP numbers and Diameter command codes/AVPs In-reply-to: To: Dan.Forsberg@nokia.com Cc: yohba@tari.toshiba.com, pana@research.telcordia.com Message-id: <20030828205816.GE26446@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, yohba@tari.toshiba.com, pana@research.telcordia.com User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 76 References: X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Thu, Aug 28, 2003 at 11:05:17AM +0300, Dan.Forsberg@nokia.com wrote: > Hi, > > Sorry for my english. I just meant that new AVPs and message type codes should take the same name space as the Diameter spec. i.e. the numbers should be reserved together with AAA WG. They are doing that right now or pretty soon. This would help the integration/co-operation with Diameter NAS:es. I agree, but with the following consideration. I think we might need to consider not only codes but also names (though names are not carried in protocol messages, but implementors could easily be confused.) For example, if we consider to share the same codes for Result-Code AVP Values between Diameter and PANA, Diameter uses: 2001 DIAMETER_SUCCESS [diameter] On the other hand, the PANA draft uses a different name "SUCCESS" (instead of "DIAMETER_SUCCESS) for the same Result Code AVP value. I think it might be better to explicitly mention the mapping from PANA naming to Diameter naming in the PANA specification, when differnet names are used by the two protocols for the same code (AVP type code or Result-Code AVP code). Yoshihiro Ohba > > - Dan > > > -----Original Message----- > > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: 28 August, 2003 00:08 > > To: Forsberg Dan (NRC/Helsinki) > > Cc: pana@research.telcordia.com > > Subject: Re: New [issue23] PANA Message type/AVP numbers and > > Diameter command codes/AVPs > > > > > > On Wed, Aug 27, 2003 at 06:26:13PM +0300, > > Dan.Forsberg@nokia.com wrote: > > > New submission from Dan Forsberg : > > > > > > To support smoother integration for PAA with a NAS, > > > > > > (A) PANA message types should be conformant with > > RADIUS/DIAMETER command > > > codes. > > > > What is the definition of "conformant" here? > > > > > > > > (B) PANA AVP types should be conformant with > > RADIUS/DIAMETER AVP types. > > > > I have the same question as above. > > > > Yoshihiro Ohba > > > > > > > > > > > ---------- > > > category: Technical > > > document: draft-ietf-pana-pana-xx.txt > > > messages: 74 > > > nosy: dforsber > > > priority: Should Fix > > > status: Pending > > > title: PANA Message type/AVP numbers and Diameter command codes/AVPs > > > ________________________________________________ > > > PANA Issues > > > http://danforsberg.info:8080/pana-issues/issue23 > > > ________________________________________________ > > > > > From pana-request@research.telcordia.com Thu Aug 28 17:38:37 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21357 for ; Thu, 28 Aug 2003 17:38:37 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7SLVmco016392; Thu, 28 Aug 2003 17:31:48 -0400 (EDT) Resent-Date: Thu, 28 Aug 2003 17:31:48 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 28 Aug 2003 14:27:43 -0700 From: Yoshihiro Ohba Subject: Re: Issue4: (new) Device identifier (types) In-reply-to: To: Dan.Forsberg@nokia.com Cc: mohanp@tahoenetworks.com, yohba@tari.toshiba.com, alper@docomolabs-usa.com, pana@research.telcordia.com Message-id: <20030828212743.GG26446@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline Mail-Followup-To: Dan.Forsberg@nokia.com, mohanp@tahoenetworks.com, yohba@tari.toshiba.com, alper@docomolabs-usa.com, pana@research.telcordia.com User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 37 References: X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Mon, Aug 18, 2003 at 05:06:05PM +0300, Dan.Forsberg@nokia.com wrote: > > From: ext Mohan Parthasarathy [mailto:mohanp@tahoenetworks.com] > > > > So, this really is in the scope of PANA. > > > > > Please see above. Are you saying that PANA should come up with some > > mechanism to prevent address spoofing ? > > That is out of the scope, but PANA can act as a carrier for that information. Or should we say that the addresses that PaC is using can be bound to the PANA session within the PANA protocol - securely. > > I'm not saying that PANA should do something that is in the scope of SEND. PAA could for example query other parties: > - PANA and DHCP interworking, > - PANA and MIPv6/v4 interworking, > - PANA and SEND interworking, I think this is already covered by allowing link-local address to be bound to PANA SA. > - PANA and "local administration" interworking (network policies, > access control, packet filtering and firewalling) > if the listed DIs are ok for the PaC. I'd like to know exactly what is not covered by just allowing link-local address to be bound to PANA SA in order to achieve this level of interworking. Note that we already identified that if we use SEND to assign an interface address and use IPsec tunneling for data packet protection between PaC and EP, then inner packet filtering is possible based on the SEND-generated interface-address that is also used for inner packets. Yoshihiro Ohba > > What do you think about this? > > - Dan > From pana-request@research.telcordia.com Thu Aug 28 19:43:57 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00822 for ; Thu, 28 Aug 2003 19:43:51 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7SNZ1rP020465; Thu, 28 Aug 2003 19:35:01 -0400 (EDT) Resent-Date: Thu, 28 Aug 2003 19:35:01 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 28 Aug 2003 16:35:41 -0700 Subject: Re: New [issue23] PANA Message type/AVP numbers and Diameter command codes/AVPs From: Alper Yegin To: Yoshihiro Ohba , CC: Message-ID: In-Reply-To: <20030828205816.GE26446@steelhead> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <0T5p_B.A.o_E.kGpT_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit So, what are the benefits of homogenizing PANA with a particular AAA backend protocol: (a) implementors easily figure out the translation between PANA messages and AAA messages (b) implementors easily code the translation. These are nice benefits. But note that these are not requirements, so let's treat these enhancements accordingly. I'm concerned that we might be already overdoing this. When overdone, here is what happens: (1) PANA looks more like an appendix to one AAA protocol (namely Diameter), and that might impact its "AAA backend independency." That can bite us down the road (or even now, if we find it conflicting with RADIUS, for example). (2) The simple, clean PANA protocol gets into strange shapes. For example: - See PANA header in section 9.1, where only 8 bits are allocated to flags whereas 24 bits are allocated to Message Type. This does not make sense. - 9.4.3: Session ID AVP is using two different codes. Normally we wouldn't do that, right? I don't think these impacts on PANA are justified. I suggest we take homogenity with various AAA protocols into consideration, especially when we have the choice, but not let it drive the design. For (a), a separate document similar to draft-congdon-radius-8021x-29.txt might be useful. Alper > On Thu, Aug 28, 2003 at 11:05:17AM +0300, Dan.Forsberg@nokia.com wrote: >> Hi, >> >> Sorry for my english. I just meant that new AVPs and message type codes >> should take the same name space as the Diameter spec. i.e. the numbers should >> be reserved together with AAA WG. They are doing that right now or pretty >> soon. This would help the integration/co-operation with Diameter NAS:es. > > I agree, but with the following consideration. > > I think we might need to consider not only codes but also names > (though names are not carried in protocol messages, but implementors > could easily be confused.) > > For example, if we consider to share the same codes for Result-Code > AVP Values between Diameter and PANA, Diameter uses: > > 2001 DIAMETER_SUCCESS [diameter] > > On the other hand, the PANA draft uses a different name "SUCCESS" > (instead of "DIAMETER_SUCCESS) for the same Result Code AVP value. > > I think it might be better to explicitly mention the mapping from PANA > naming to Diameter naming in the PANA specification, when differnet > names are used by the two protocols for the same code (AVP type code > or Result-Code AVP code). > > Yoshihiro Ohba > > > >> >> - Dan >> >>> -----Original Message----- >>> From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] >>> Sent: 28 August, 2003 00:08 >>> To: Forsberg Dan (NRC/Helsinki) >>> Cc: pana@research.telcordia.com >>> Subject: Re: New [issue23] PANA Message type/AVP numbers and >>> Diameter command codes/AVPs >>> >>> >>> On Wed, Aug 27, 2003 at 06:26:13PM +0300, >>> Dan.Forsberg@nokia.com wrote: >>>> New submission from Dan Forsberg : >>>> >>>> To support smoother integration for PAA with a NAS, >>>> >>>> (A) PANA message types should be conformant with >>> RADIUS/DIAMETER command >>>> codes. >>> >>> What is the definition of "conformant" here? >>> >>>> >>>> (B) PANA AVP types should be conformant with >>> RADIUS/DIAMETER AVP types. >>> >>> I have the same question as above. >>> >>> Yoshihiro Ohba >>> >>>> >>>> >>>> ---------- >>>> category: Technical >>>> document: draft-ietf-pana-pana-xx.txt >>>> messages: 74 >>>> nosy: dforsber >>>> priority: Should Fix >>>> status: Pending >>>> title: PANA Message type/AVP numbers and Diameter command codes/AVPs >>>> ________________________________________________ >>>> PANA Issues >>>> http://danforsberg.info:8080/pana-issues/issue23 >>>> ________________________________________________ >>>> >>> > > From pana-request@research.telcordia.com Thu Aug 28 21:28:46 2003 Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09375 for ; Thu, 28 Aug 2003 21:28:46 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.9/8.12.9) id h7T1M75S023830; Thu, 28 Aug 2003 21:22:07 -0400 (EDT) Resent-Date: Thu, 28 Aug 2003 21:22:07 -0400 (EDT) X-Authentication-Warning: thumper.research.telcordia.com: slmgr set sender to pana-request@research.telcordia.com using -f Old-Return-Path: Date: Thu, 28 Aug 2003 18:22:38 -0700 Subject: Will be away... From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Resent-Message-ID: <_CvkdC.A.N0F.-qqT_@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hello, I'll be on vacation between August 30th and September 21st. FYI... Alper