From pana-request@research.telcordia.com Mon Apr 1 09:57:56 2002 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 JAA00395 for ; Mon, 1 Apr 2002 09:57:55 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g31Ejr6t022843; Mon, 1 Apr 2002 09:45:53 -0500 (EST) Resent-Date: Mon, 1 Apr 2002 09:45:53 -0500 (EST) Old-Return-Path: Message-ID: <00006f163f59$00005fc5$00005b62@sussi.cressoft.com.pk=0> To: , , , , , <100666.1245@mci.com>, , Cc: , , , , , , , From: "bret" Subject: Become An Investigator 16445 Date: Mon, 01 Apr 2002 08:39:28 -1800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: quoted-printable
Interne= t Detective 5.0
 
The Internet's BEST Sel= ling Spy Software Is Now Better Than Ever!
 
Track, Locate, Or Conduct = A Complete Background Check On Anyone, At Anytime!  Protect Your Family From Imp= ostors Or People With Criminal Records.
 
Investigate Anyone Or Everyone = From The Privacy Of Your Home.  This Program Allows You To Tap Into The Very S= ame Information Sources That Are Used By Professional Private Investigators!!
 
ONLY $29.95
 
Click Here And Get It Now      http://netdet.direct2you.bz/?chck
 
 
To Be Removed From Further Mailings, Clic= k Here http://remove.direct2you.bz/
From pana-request@research.telcordia.com Wed Apr 3 19:49:05 2002 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 TAA20196 for ; Wed, 3 Apr 2002 19:48:56 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g340ht2D029688; Wed, 3 Apr 2002 19:43:55 -0500 (EST) Resent-Date: Wed, 3 Apr 2002 19:43:55 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Problem Statement and Scope of WG Date: Wed, 3 Apr 2002 18:39:45 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12B60@daebe007.NOE.Nokia.com> Thread-Topic: Problem Statement and Scope of WG Thread-Index: AcHbcTfe0zvkkkdUEdaxvgAAhj/HZA== From: To: X-OriginalArrivalTime: 04 Apr 2002 00:39:45.0482 (UTC) FILETIME=[37AAEAA0:01C1DB71] X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA20196 Hello, At IETF53, there were some questions about the scope of PANA and the problem that this WG was aiming to solve. Below is a brief description of the problem statement and also the scope of what we hope to do in this WG. If WG members think that this problem statement is clear enough we could modify the charter and make it more lucid. -Chairs PANA Problem Statement and Scope -------------------------------- Hosts need to provide credentials and authentication information before being allowed access to networks that require access authentication. This is a function that is normally performed at the link-layer by protocols such as PPP, PPPoE, 802.1x and protocols that are specific to cellular technologies (e.g.: GSM, CDMA, TDMA, etc.). Network authentication has two aspects: - Access authentication and authorization: To verify legitimacy of the clients before they gain access to the network. The goal of PANA is to enable this function. - Per-packet authentication/encryption: To provide data integrity and confidentiality, and to prevent service theft after clients gain access to the network. PANA can also enable per-packet authentication/encryption. While the former is a must, the latter is optional but in many cases required. EAP (Extensible Authentication Protocol) is a widely used protocol for network access authentication. It provides a framework that allows the use of multiple authentication mechanisms, and defines how it is encapsulated in PPP frames. EAP over Wireless (EAPOW) and EAP over LAN (EAPOL) of 802.1x are defined to carry EAP on IEEE 802 type links. And for any other link type that does not define its own encapsulation, PPP/PPPoE is used to carry EAP protocol. While EAP encapsulation capability of PPP/PPPoE is useful, the other functionalities of these protocols are not always needed but cannot be turned off either. Therefore using PPP/PPPoE as a media agnostic encapsulation for EAP creates sub-optimal solutions (extra round-trips, overhead of encapsulation and processing, forced topology into point-to-point), whereas this functionality can be easily provided by a simple protocol explicitly defined for this purpose. So to state it very simply: The goal of the PANA Working Group is to define a link-layer agnostic encapsulation for EAP. It will define a network-layer messaging protocol that enables access authentication and authorization. The general framework of all access control mechanisms is shown in the following figure. Authentication Agent------------Authentication Server | Client-------------Enforcement Point PANA does not change this model. The functional elements and framework used are identical to existing encapsulations (e.g.: EAPOW, PPP). PANA is used to encapsulate EAP between the Client and the Authentication Agent, whereas EAP is still encapsulated using protocols like Diameter or Radius between the Authentication Agent and the Authentication Server. The Authentication Agent can reside on any node in the network that can send/receive IP datagrams (i.e., has an IP stack). The Authentication Agent and the Enforcement Point can be co-located (as is the case with PPP and EAPOW), or be on separate nodes. PANA will identify a transport (e.g., AAA, SNMP, COPS, etc.) to carry access control information (such as filters) from the Authentication Agent to the Enforcement point when these two entities are separated. There are pros and cons associated with having the authentication agent beyond the first hop [NAS/AP/Rtr/etc.]. This is an issue that needs to be delved into by the WG. Where to use PANA ----------------- PANA can be used in networks that do not have mechanisms at the link-layer to authenticate hosts. Even when the link-layer provides access authentication, PANA can still be used as an EAP-enabler or to provide additional network-layer authentication (when required). Currently only IEEE 802 type links have a native encapsulation for EAP. None of the other link-types define how to carry EAP although they might have their own protocols for access authentication and authorization. Even when the link-layers have their own protocols, using EAP provides a standard, flexible, and extensible tool for authentication. This is where PANA will be used to provide the link-layer agnostic encapsulation for EAP. By using PANA, individual link-layers don't have to define their own speciic encapsulations to take advantage of EAP. PANA is even much more needed for link-layers that support neither access nor per-packet authentication. It can be used as the only means to provide access authentication. Per-packet authentication/ encryption can be achieved by the use of IPsec or other ciphering mechanisms. Per-packet authentication/encryption ------------------------------------ A number of EAP methods have key derivation and distribution capabilities. PANA does not change the model how these keys are generated or used. But as a network-layer transport, it provides the flexibility to use these keys either at the link-layer or at the network-layer. If the link-layer supports data authentication/encryption, then the keys may be provided to the link-layers of the Client and the Enforcement Point, so that traffic can be protected as provided by the link-layer. If the link-layer does not support link-layer authentication/ encryption, but per-packet protection is still required by the upper-layers, then the keys may be used by IPsec between the Client and the Enforcement Point to protect the traffic as required. From pana-request@research.telcordia.com Wed Apr 3 20:07:18 2002 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 UAA20450 for ; Wed, 3 Apr 2002 20:07:18 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3414WJQ003081; Wed, 3 Apr 2002 20:04:32 -0500 (EST) Resent-Date: Wed, 3 Apr 2002 20:04:32 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Question for vendors and operators Date: Wed, 3 Apr 2002 19:00:38 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12B62@daebe007.NOE.Nokia.com> Thread-Topic: Question for vendors and operators Thread-Index: AcHbdCM90zvkv0dUEdaxvgAAhj/HZA== From: To: X-OriginalArrivalTime: 04 Apr 2002 01:00:39.0106 (UTC) FILETIME=[22E2C220:01C1DB74] X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA20450 Hello, We would like to hear from vendors and operators if PANA would be something that solves a problem in their networks and hence would like to see it standardized. Would PANA be something that operators would deploy as an alternative to doing authentication via PPPoE or PPP or 802.1x or via http redirect? -Basavaraj From pana-request@research.telcordia.com Thu Apr 4 11:44:32 2002 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 LAA22103 for ; Thu, 4 Apr 2002 11:44:32 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g34Gepwg000323; Thu, 4 Apr 2002 11:40:51 -0500 (EST) Resent-Date: Thu, 4 Apr 2002 11:40:51 -0500 (EST) Old-Return-Path: Message-ID: <000d01c1dbf7$0a3d7750$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: <697DAA22C5004B4596E033803A7CEF44A12B60@daebe007.NOE.Nokia.com> Subject: Re: Problem Statement and Scope of WG Date: Thu, 4 Apr 2002 08:37:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Raj & Alper, I think it would be helpful to explicitly list nongoals of PANA. For example, I assume that one nongoal is to replace existing link layer authentication mechanisms for network access authentication. I would also dispute the following goal of PANA: > - Per-packet authentication/encryption: > To provide data integrity and confidentiality, and to prevent > service theft after clients gain access to the network. PANA > can also enable per-packet authentication/encryption. The implication I get from this goal is that PANA is proposing to replace the IPsec gateway mode, whereas, what I think you are really talking about is an alternative key distribution mechanism for session keys. That is, I get the impression that PANA will do the actual encryption/authentication. I think you need to be much clearer about this. Also, the wording on the following paragraph is somewhat cumbersome: > PANA is even much more needed for link-layers that support > neither access nor per-packet authentication. It can be used as the > only means to provide access authentication. Per-packet authentication/ > encryption can be achieved by the use of IPsec or other ciphering > mechanisms. > I would suggest: An even stronger case can be made for PANA for link layers that support neither access nor per-packet authentication. PANA can be used with such link layers as the exclusive means to provide access authentication. . jak From pana-request@research.telcordia.com Thu Apr 4 13:01:59 2002 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 NAA28565 for ; Thu, 4 Apr 2002 13:01:59 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g34HwGbw007584; Thu, 4 Apr 2002 12:58:16 -0500 (EST) Resent-Date: Thu, 4 Apr 2002 12:58:16 -0500 (EST) Old-Return-Path: Message-ID: <20020404175756.78481.qmail@web20404.mail.yahoo.com> Date: Thu, 4 Apr 2002 09:57:56 -0800 (PST) From: Reinaldo Penno Subject: Re: Question for vendors and operators To: Basavaraj.Patil@nokia.com, pana@research.telcordia.com In-Reply-To: <697DAA22C5004B4596E033803A7CEF44A12B62@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com without my co-author/presenter hat... I've been involved in my (big) share of all kinds of broadband wireline (some wireless) deployments: cable, adsl, ethernet, mmds. IMO the value that PANA brings is twofold: it provides ONE authentication method, and allows carriers to provide personalized services based on an access agnostic authentication method through username/password. More on this.. One of the requirements that I get 9 out of 10 times is that the provider/ISP wants some form of authentication/login (specially independent of the access technology). That's how they bill users, gather users statistics, make partnership with content providers, adequate their portals, provide "open access" to several ISPs, etc, etc Some cable/adsl providers deploy PPPoE/PPPoA *just because* of the authentication/login capabilities. If there was a layer 3 method to get authentication (username/password) they would rip PPPoE/PPPoA out of their networks today. They need some username/password in order to provide any of the so-called personalized service like content filtering, page assembly, news, etc Last but not least some carriers that I've worked with provide adsl and cable or wireless and adsl and they would like ONE authentication method, one client to distribute if needed. Anyway, I see PANA solving a real world problem that was long due, which is different from some other WGs, as the saying goes (ask you to get sick in order to abe able to give you medicine) regards, Reinaldo --- Basavaraj.Patil@nokia.com wrote: > > Hello, > > We would like to hear from vendors and operators if > PANA would be > something that solves a problem in their networks > and hence would like > to see it standardized. > Would PANA be something that operators would deploy > as an alternative > to doing authentication via PPPoE or PPP or 802.1x > or via http > redirect? > > -Basavaraj > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From pana-request@research.telcordia.com Thu Apr 4 13:46:48 2002 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 NAA03784 for ; Thu, 4 Apr 2002 13:46:32 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g34IhB5G011496; Thu, 4 Apr 2002 13:43:11 -0500 (EST) Resent-Date: Thu, 4 Apr 2002 13:43:11 -0500 (EST) Old-Return-Path: Message-Id: <4.3.2.7.2.20020404133357.03636008@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Apr 2002 13:41:06 -0500 To: From: John Schnizlein Subject: Re: Problem Statement and Scope of WG Cc: In-Reply-To: <697DAA22C5004B4596E033803A7CEF44A12B60@daebe007.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com It would be helpful if a short list of examples of the "other link-types" that lack link-layer authentication mechanisms were inserted here. The question persists: what is the size of the gap to be covered by PANA? John At 07:39 PM 4/3/2002, Basavaraj.Patil@nokia.com wrote: >... >Currently only IEEE 802 type links have a native encapsulation for EAP. >None of the other link-types define how to carry EAP although they might >have their own protocols for access authentication and authorization. >Even when the link-layers have their own protocols, using EAP provides >a standard, flexible, and extensible tool for authentication. This is >where PANA will be used to provide the link-layer agnostic encapsulation >for EAP. By using PANA, individual link-layers don't have to define >their own speciic encapsulations to take advantage of EAP. From pana-request@research.telcordia.com Thu Apr 4 14:07:08 2002 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 OAA04484 for ; Thu, 4 Apr 2002 14:07:07 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g34J4KKs014994; Thu, 4 Apr 2002 14:04:20 -0500 (EST) Resent-Date: Thu, 4 Apr 2002 14:04:20 -0500 (EST) Old-Return-Path: Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABCA9@ftmail> From: George Tsirtsis To: "'John Schnizlein'" , Basavaraj.Patil@nokia.com Cc: pana@research.telcordia.com Subject: RE: Problem Statement and Scope of WG Date: Thu, 4 Apr 2002 14:03:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com You mean things like DSL, ATM, FR, Cable? -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Thursday, April 04, 2002 7:41 PM To: Basavaraj.Patil@nokia.com Cc: pana@research.telcordia.com Subject: Re: Problem Statement and Scope of WG It would be helpful if a short list of examples of the "other link-types" that lack link-layer authentication mechanisms were inserted here. The question persists: what is the size of the gap to be covered by PANA? John At 07:39 PM 4/3/2002, Basavaraj.Patil@nokia.com wrote: >... >Currently only IEEE 802 type links have a native encapsulation for EAP. >None of the other link-types define how to carry EAP although they might >have their own protocols for access authentication and authorization. >Even when the link-layers have their own protocols, using EAP provides >a standard, flexible, and extensible tool for authentication. This is >where PANA will be used to provide the link-layer agnostic encapsulation >for EAP. By using PANA, individual link-layers don't have to define >their own speciic encapsulations to take advantage of EAP. From pana-request@research.telcordia.com Thu Apr 4 14:31:22 2002 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 OAA05750 for ; Thu, 4 Apr 2002 14:31:22 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g34JSK5M017220; Thu, 4 Apr 2002 14:28:20 -0500 (EST) Resent-Date: Thu, 4 Apr 2002 14:28:20 -0500 (EST) Old-Return-Path: Message-Id: <4.3.2.7.2.20020404141328.0361c6f8@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Apr 2002 14:26:16 -0500 To: George Tsirtsis From: John Schnizlein Subject: RE: Problem Statement and Scope of WG Cc: pana@research.telcordia.com In-Reply-To: <8C92E23A3E87FB479988285F9E22BE465ABCA9@ftmail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com That might be an appropriate list, but my impression is that hosts attach to these through either PPP or 802.1 bridging. Does anyone actually connect IP hosts directly to FR or Cable? The case for IP/ATM (without IP/PPP/ATM) is stronger, but didn't the market already choose against this for host attachments? John At 02:03 PM 4/4/2002, George Tsirtsis wrote: >You mean things like DSL, ATM, FR, Cable? > >-----Original Message----- >From: John Schnizlein [mailto:jschnizl@cisco.com] > >It would be helpful if a short list of examples of the "other link-types" >that lack link-layer authentication mechanisms were inserted here. >The question persists: what is the size of the gap to be covered by PANA? > >At 07:39 PM 4/3/2002, Basavaraj.Patil@nokia.com wrote: >>... >>Currently only IEEE 802 type links have a native encapsulation for EAP. >>None of the other link-types define how to carry EAP although they might >>have their own protocols for access authentication and authorization. >>Even when the link-layers have their own protocols, using EAP provides >>a standard, flexible, and extensible tool for authentication. This is >>where PANA will be used to provide the link-layer agnostic encapsulation >>for EAP. By using PANA, individual link-layers don't have to define >>their own speciic encapsulations to take advantage of EAP. From pana-request@research.telcordia.com Thu Apr 4 16:59:52 2002 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 QAA10482 for ; Thu, 4 Apr 2002 16:59:34 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g34LsJxM000969; Thu, 4 Apr 2002 16:54:19 -0500 (EST) Resent-Date: Thu, 4 Apr 2002 16:54:19 -0500 (EST) Old-Return-Path: Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABCAA@ftmail> From: George Tsirtsis To: "'John Schnizlein'" Cc: pana@research.telcordia.com Subject: RE: Problem Statement and Scope of WG Date: Thu, 4 Apr 2002 16:53:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <_ihmgB.A.BP.KuMr8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com John, People, at the moment have no choice...If you want to run native IP over ATM you can not authenticate the end points. PANA would allow you to do that. People involved with DSL (I personally used to be back in BT) can tell you that IP over frame over DSL would be much simpler, cheaper and better from IP perspective solution than the current solutions but the alternative can not authenticate the end points and thus is not practical. People also use PPPoE for exactly the same reason....but maybe you do not mind that either? Some of us do :) George -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Thursday, April 04, 2002 8:26 PM To: George Tsirtsis Cc: pana@research.telcordia.com Subject: RE: Problem Statement and Scope of WG That might be an appropriate list, but my impression is that hosts attach to these through either PPP or 802.1 bridging. Does anyone actually connect IP hosts directly to FR or Cable? The case for IP/ATM (without IP/PPP/ATM) is stronger, but didn't the market already choose against this for host attachments? John At 02:03 PM 4/4/2002, George Tsirtsis wrote: >You mean things like DSL, ATM, FR, Cable? > >-----Original Message----- >From: John Schnizlein [mailto:jschnizl@cisco.com] > >It would be helpful if a short list of examples of the "other link-types" >that lack link-layer authentication mechanisms were inserted here. >The question persists: what is the size of the gap to be covered by PANA? > >At 07:39 PM 4/3/2002, Basavaraj.Patil@nokia.com wrote: >>... >>Currently only IEEE 802 type links have a native encapsulation for EAP. >>None of the other link-types define how to carry EAP although they might >>have their own protocols for access authentication and authorization. >>Even when the link-layers have their own protocols, using EAP provides >>a standard, flexible, and extensible tool for authentication. This is >>where PANA will be used to provide the link-layer agnostic encapsulation >>for EAP. By using PANA, individual link-layers don't have to define >>their own speciic encapsulations to take advantage of EAP. From pana-request@research.telcordia.com Thu Apr 4 18:10:11 2002 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 SAA12263 for ; Thu, 4 Apr 2002 18:10:10 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g34N5xFV007028; Thu, 4 Apr 2002 18:05:59 -0500 (EST) Resent-Date: Thu, 4 Apr 2002 18:05:59 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Problem Statement and Scope of WG Date: Thu, 4 Apr 2002 17:05:34 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12B75@daebe007.NOE.Nokia.com> Thread-Topic: Problem Statement and Scope of WG Thread-Index: AcHb969Fvckh7QLiSW+DV0ZVt7CZvwANYO5w From: To: , X-OriginalArrivalTime: 04 Apr 2002 23:05:35.0094 (UTC) FILETIME=[3A2FE160:01C1DC2D] X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA12263 James, Thanks for the improvement suggestions. We will incorporate it in the next revision. A few rseponses inline: >Raj & Alper, > >I think it would be helpful to explicitly list nongoals of PANA. For >example, I assume that one nongoal is to replace existing link layer >authentication mechanisms for network access authentication. > Completely agree. However for scenarios involving PPPoE for network authentication, PANA MAY be a better alternative. >I would also dispute the following goal of PANA: > >> - Per-packet authentication/encryption: >> To provide data integrity and confidentiality, and to prevent >> service theft after clients gain access to the network. PANA >> can also enable per-packet authentication/encryption. > >The implication I get from this goal is that PANA is proposing to >replace the IPsec gateway mode, whereas, what I think you are really >talking about is an alternative key distribution mechanism for session >keys. That is, I get the impression that PANA will do the actual >encryption/authentication. I think you need to be much clearer about >this. Maybe the wording needs some improvement. What we are saying is that PANA can be a mechanism for delivering keys to a host and the AP. This key could be used by other encryption/ciphering mechanisms. So PANA would not be really the one doing per-packet auth/encryption, but rather enabling such functionality where required. > >Also, the wording on the following paragraph is somewhat cumbersome: > >> PANA is even much more needed for link-layers that support >> neither access nor per-packet authentication. It can be used as the >> only means to provide access authentication. Per-packet >authentication/ >> encryption can be achieved by the use of IPsec or other ciphering >> mechanisms. >> > >I would suggest: > > An even stronger case can be made for PANA for link layers that > support neither access nor per-packet authentication. PANA can > be used with such link layers as the exclusive means to provide > access authentication. >. Agreed. > > jak > -Basavaraj From pana-request@research.telcordia.com Thu Apr 4 18:28:02 2002 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 SAA12617 for ; Thu, 4 Apr 2002 18:28:02 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g34NOZwx008278; Thu, 4 Apr 2002 18:24:35 -0500 (EST) Resent-Date: Thu, 4 Apr 2002 18:24:35 -0500 (EST) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Problem Statement and Scope of WG Date: Thu, 4 Apr 2002 17:20:07 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12B76@daebe007.NOE.Nokia.com> Thread-Topic: Problem Statement and Scope of WG Thread-Index: AcHcCF7+/T9I62EqR7KRSNLBh6cfKAAJt0Mg From: To: Cc: X-OriginalArrivalTime: 04 Apr 2002 23:20:08.0021 (UTC) FILETIME=[427DF850:01C1DC2F] X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA12617 John, >It would be helpful if a short list of examples of the "other link-types" >that lack link-layer authentication mechanisms were inserted here. >The question persists: what is the size of the gap to be covered by >PANA? The size of the gap may be limited to begin with simply because you have all the entrenched mechanisms already in place. However DSL networks today use PPPoE for example in order to do authentication among other functions. Do you really need PPPoE in DSL networks? I would think not. So this is an area that may benefit from PANA. And another example would be Bluetooth. The Bluetooth forum is currently investigating authentication mechanisms. A protocol like PANA may be useful for BT. I believe they are leaning towards 802.1x, but what other choices do they have (other than PPP)? -Basavaraj > >John > >At 07:39 PM 4/3/2002, Basavaraj.Patil@nokia.com wrote: >>... >>Currently only IEEE 802 type links have a native encapsulation for EAP. >>None of the other link-types define how to carry EAP although they might >>have their own protocols for access authentication and authorization. >>Even when the link-layers have their own protocols, using EAP provides >>a standard, flexible, and extensible tool for authentication. This is >>where PANA will be used to provide the link-layer agnostic encapsulation >>for EAP. By using PANA, individual link-layers don't have to define >>their own speciic encapsulations to take advantage of EAP. From pana-request@research.telcordia.com Fri Apr 5 09:12:39 2002 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 JAA05331 for ; Fri, 5 Apr 2002 09:12:38 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g35E6xeR025524; Fri, 5 Apr 2002 09:06:59 -0500 (EST) Resent-Date: Fri, 5 Apr 2002 09:06:59 -0500 (EST) Old-Return-Path: Message-ID: From: MORAND Lionel FTRD/DAC/ISS To: "'Reinaldo Penno'" , Basavaraj.Patil@nokia.com, pana@research.telcordia.com Cc: MORAND Lionel FTRD/DAC/ISS Subject: RE: Question for vendors and operators Date: Fri, 5 Apr 2002 16:06:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-378cfbb5-486b-11d6-b1ea-00508b69ab48" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-378cfbb5-486b-11d6-b1ea-00508b69ab48 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCAB.182D3632" ------_=_NextPart_001_01C1DCAB.182D3632 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Considering the various studies on the various inter-technology = mobility scenarios, and in particular the ongoing work on 3GPP/WLAN interworking specifications (works have start in Juan.01), I think that the work = done in PANA WG will bring the generic block needed to build a more global = solution for inter-access mobility, taking into account mobility management, accounting, customized service offerings, etc.=20 Indeed mobility management is first and foremost based on the ability = to authenticate the same user roaming between access points. Of course, = various authentication schemes already exist according to the access technology and/or the access network considered, and they are sometimes = L2-dependent. This causes problems when you take into account the inter-access = mobility context. In the 3GPP/WLAN interworking for instance, one option for providing a common authentication mechanism is to re-use the SIM-based architecture = in the WLAN access network and to adapt consequently 802.1x to support the = 3GPP authentication procedures. However, another alternative is to define = and introduce a new mechanism, L2-agnostic and being so generic: it will be useful for the specific case of 3GPP/WLAN interworking and for any = other type of interworking (3GPP/ADSL for instance) without requiring heavy investigation/deployment cost overrun. And the scope of PANA seems to = fulfil such requirements. From a operator/ISP point of view, PANA will then enable a global = service offering, whatever the access technology considered (WLAN, LAN, ADSL, = GPRS, etc.), based on a generic user information profile with universal user security parameters (IDs, username/password, etc). To conclude, I think that a generic solution is definitely needed and = that the PANA WG seems to be on the right track. Regards, Lionel Morand France Telecom R&D +33145296257 lionel.morand@francetelecom.com -----Message d'origine----- De=A0: Reinaldo Penno [mailto:rapenno@yahoo.com] Envoy=E9=A0: jeudi 4 avril 2002 19:58 =C0=A0: Basavaraj.Patil@nokia.com; pana@research.telcordia.com Objet=A0: Re: Question for vendors and operators without my co-author/presenter hat... I've been involved in my (big) share of all kinds of broadband wireline (some wireless) deployments: cable, adsl, ethernet, mmds. IMO the value that PANA brings is twofold: it provides ONE authentication method, and allows carriers to provide personalized services based on an access agnostic authentication method through username/password. More on this..=20 One of the requirements that I get 9 out of 10 times is that the provider/ISP wants some form of authentication/login (specially independent of the access technology). That's how they bill users, gather users statistics, make partnership with content providers, adequate their portals, provide "open access" to several ISPs, etc, etc Some cable/adsl providers deploy PPPoE/PPPoA *just because* of the authentication/login capabilities. If there was a layer 3 method to get authentication (username/password) they would rip PPPoE/PPPoA out of their networks today.=20 They need some username/password in order to provide any of the so-called personalized service like content filtering, page assembly, news, etc Last but not least some carriers that I've worked with provide adsl and cable or wireless and adsl and they would like ONE authentication method, one client to distribute if needed.=20 Anyway, I see PANA solving a real world problem that was long due, which is different from some other WGs,=20 as the saying goes (ask you to get sick in order to abe able to give you medicine)=20 regards, Reinaldo --- Basavaraj.Patil@nokia.com wrote: >=20 > Hello, >=20 > We would like to hear from vendors and operators if > PANA would be > something that solves a problem in their networks > and hence would like > to see it standardized.=20 > Would PANA be something that operators would deploy > as an alternative > to doing authentication via PPPoE or PPP or 802.1x > or via http > redirect?=20 >=20 > -Basavaraj >=20 __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ ------_=_NextPart_001_01C1DCAB.182D3632 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Question for vendors and operators

Hi,

Considering the various studies on the various = inter-technology mobility scenarios, and in particular the ongoing work = on 3GPP/WLAN interworking specifications (works have start in Juan.01), = I think that the work done in PANA WG will bring the generic block = needed to build a more global solution for inter-access mobility, = taking into account mobility management, accounting, customized service = offerings, etc.

Indeed mobility management is first and foremost = based on the ability to authenticate the same user roaming between = access points. Of course, various authentication schemes already exist = according to the access technology and/or the access network = considered, and they are sometimes L2-dependent. This causes problems = when you take into account the inter-access mobility = context.

In the 3GPP/WLAN interworking for instance, one = option for providing a common authentication mechanism is to re-use the = SIM-based architecture in the WLAN access network and to adapt = consequently 802.1x to support the 3GPP authentication procedures. = However, another alternative is to define and introduce a new = mechanism, L2-agnostic and being so generic: it will be useful for the = specific case of 3GPP/WLAN interworking and for any other type of = interworking (3GPP/ADSL for instance) without requiring heavy = investigation/deployment cost overrun. And the scope of PANA seems to = fulfil such requirements.

From a operator/ISP point of view, PANA will then = enable a global service offering, whatever the access technology = considered (WLAN, LAN, ADSL, GPRS, etc.), based on a generic user = information profile with universal user security parameters (IDs, = username/password, etc).

To conclude, I think that a generic solution is = definitely needed and that the PANA WG seems to be on the right = track.

Regards,

Lionel Morand

France Telecom R&D
+33145296257
lionel.morand@francetelecom.com

-----Message d'origine-----
De=A0: Reinaldo Penno [mailto:rapenno@yahoo.com]
Envoy=E9=A0: jeudi 4 avril 2002 19:58
=C0=A0: Basavaraj.Patil@nokia.com; = pana@research.telcordia.com
Objet=A0: Re: Question for vendors and = operators


without my co-author/presenter hat...

I've been involved in my (big) share of all kinds = of
broadband wireline (some wireless) deployments: = cable,
adsl, ethernet, mmds.

IMO the value that PANA brings is twofold: it = provides
ONE authentication method, and allows carriers = to
provide personalized services based on an = access
agnostic authentication method through
username/password.

More on this..

One of the requirements that I get 9 out of 10 = times
is that the provider/ISP wants some form of
authentication/login (specially independent of = the
access technology). That's how they bill users, = gather
users statistics, make partnership with = content
providers, adequate their portals, provide = "open
access" to several ISPs, etc, etc

Some cable/adsl providers deploy PPPoE/PPPoA = *just
because* of the authentication/login capabilities. = If
there was a layer 3 method to get = authentication
(username/password) they would rip PPPoE/PPPoA out = of
their networks today.

They need some username/password in order to = provide
any of the so-called personalized service like = content
filtering, page assembly, news, etc

Last but not least some carriers that I've worked = with
provide adsl and cable or wireless and adsl and = they
would like ONE authentication method, one client = to
distribute if needed.

Anyway, I see PANA solving a real world problem = that
was long due, which is different from some other = WGs,
as the saying goes (ask you to get sick in order = to
abe able to give you medicine)

regards,

Reinaldo

--- Basavaraj.Patil@nokia.com wrote:
>
> Hello,
>
> We would like to hear from vendors and = operators if
> PANA would be
> something that solves a problem in their = networks
> and hence would like
> to see it standardized.
> Would PANA be something that operators would = deploy
> as an alternative
> to doing authentication via PPPoE or PPP or = 802.1x
> or via http
> redirect?
>
> -Basavaraj
>



__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with = TurboTax
http://taxes.yahoo.com/

------_=_NextPart_001_01C1DCAB.182D3632-- ------=_NextPartTM-000-378cfbb5-486b-11d6-b1ea-00508b69ab48-- From pana-request@research.telcordia.com Fri Apr 5 13:35:26 2002 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 NAA12526 for ; Fri, 5 Apr 2002 13:35:26 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g35IT5OY019580; Fri, 5 Apr 2002 13:29:05 -0500 (EST) Resent-Date: Fri, 5 Apr 2002 13:29:05 -0500 (EST) Old-Return-Path: Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABCC4@ftmail> From: George Tsirtsis To: "'Basavaraj.Patil@nokia.com'" , pana@research.telcordia.com Subject: RE: Question for vendors and operators Date: Fri, 5 Apr 2002 13:28:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com All, I have been encouraged to give Flarion's opinion/use of PANA which requires me to wear my vendor's hat...which feels a bit uncomfortable on an IETF mailing list... Still, I endure... /--------------------------... Here at Flarion we have developed a new link layer that we call Flash-OFDM. This is a wireless link layer designed for Wide Area Networks (WAN), cellular-type deployment and it is designed specifically for *data* i.e.: The Internet The technology is designed to localized all L2 effects to the air link ONLY i.e.: between the mobile node and an Access Router that each include a Flash-OFDM interface, while the rest of the network is simply IP routers and back end systems. Each Flash-OFDM interface on the Access Router/base station is a cell or sector of a cell. We happen to run IP directly over Flash-OFDM so we DO NOT use PPP, while we use Mobile IP for mobility management. NOTE that due to the one-hop nature of the link layer, there is no backend link layer infrastructure to protect using link layer security. Still, since this is intended for wide-area deployment by operators we need to be able to authenticate end users and we also need to encrypt the airlink. Clearly, we can use yet another link layer specific mechanism to carry whatever authentication we decide to use, but given the single hop focus of this L2 technology we gain nothing by doing it this way. On the other hand Flash-OFDM and our mobility management system is ideal for inter-technology handoffs (e.g.:Flash-OFDM to 802.11), and by using link layer authentication, we need two different authentication transports for two different technologies. So, if PANA existed today we would consider very seriously to adopt it and so allow an operator to provide a single authentication client that can be used for our own technology as well as for roaming to/from other technologies. PANA would offer our customers (operators) one piece of client authentication code and the ability to have exactly the same per user settings and behavior, whatever the underlying technology. \-------------------------... Removing my vendor's hat...aahh...feels better... I also believe that the Internet must have a way to authenticate end points to control points (especially the access router) in the infrastructure and vice versa. This is a fundamental function that is needed, no matter what a single vendors wants. Regards George -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: Thursday, April 04, 2002 2:01 AM To: pana@research.telcordia.com Subject: Question for vendors and operators Hello, We would like to hear from vendors and operators if PANA would be something that solves a problem in their networks and hence would like to see it standardized. Would PANA be something that operators would deploy as an alternative to doing authentication via PPPoE or PPP or 802.1x or via http redirect? -Basavaraj From pana-request@research.telcordia.com Fri Apr 5 16:27:46 2002 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 QAA19223 for ; Fri, 5 Apr 2002 16:27:46 -0500 (EST) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g35LMNiM005459; Fri, 5 Apr 2002 16:22:23 -0500 (EST) Resent-Date: Fri, 5 Apr 2002 16:22:23 -0500 (EST) Old-Return-Path: Message-ID: <3CAE149A.B4BE5837@interlinknetworks.com> Date: Fri, 05 Apr 2002 16:18:19 -0500 From: John Vollbrecht X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: George Tsirtsis Cc: "'Basavaraj.Patil@nokia.com'" , pana@research.telcordia.com Subject: Re: Question for vendors and operators References: <8C92E23A3E87FB479988285F9E22BE465ABCC4@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <_1VlsC.A.LVB.OWhr8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hi George - Thanks for sending this. I do have some clarifying questions below -- John George Tsirtsis wrote: > All, > > I have been encouraged to give Flarion's opinion/use of PANA which requires > me to wear my vendor's hat...which feels a bit uncomfortable on an IETF > mailing list... Still, I endure... > > /--------------------------... > Here at Flarion we have developed a new link layer that we call Flash-OFDM. > This is a wireless link layer designed for Wide Area Networks (WAN), > cellular-type deployment and it is designed specifically for *data* i.e.: > The Internet > > The technology is designed to localized all L2 effects to the air link ONLY > i.e.: between the mobile node and an Access Router that each include a > Flash-OFDM interface, while the rest of the network is simply IP routers and > back end systems. Each Flash-OFDM interface on the Access Router/base > station is a cell or sector of a cell. To be sure I understand - does this mean that an L2 connection is established prior to authentication? Does each L2 connection uses a unique cell or sector of a cell? > > > We happen to run IP directly over Flash-OFDM so we DO NOT use PPP, while we > use Mobile IP for mobility management. NOTE that due to the one-hop nature > of the link layer, there is no backend link layer infrastructure to protect > using link layer security. Still, since this is intended for wide-area > deployment by operators we need to be able to authenticate end users and we > also need to encrypt the airlink. Is authentication after L2 connection ok or does the L2 connection need to be authenticated? Is encryption done at L2? Is an authorization dialog needed to support the link encryption? > > Clearly, we can use yet another link layer specific mechanism to carry > whatever authentication we decide to use, but given the single hop focus of > this L2 technology we gain nothing by doing it this way. On the other hand > Flash-OFDM and our mobility management system is ideal for inter-technology > handoffs (e.g.:Flash-OFDM to 802.11), and by using link layer > authentication, we need two different authentication transports for two > different technologies. > Are you talking here about link encryption or authentication dialog? It would seem Flash-OFDM is already a different transport technology, so how would PANA play here? > > So, if PANA existed today we would consider very seriously to adopt it and > so allow an operator to provide a single authentication client that can be > used for our own technology as well as for roaming to/from other > technologies. PANA would offer our customers (operators) one piece of client > authentication code and the ability to have exactly the same per user > settings and behavior, whatever the underlying technology. This sounds more like what you would like is a Client interface that works accross all technologies - with a common authentication technique. What role would you see PANA playing? Would it do user authentication? L2 Data encryption? > > \-------------------------... > > Removing my vendor's hat...aahh...feels better... > > I also believe that the Internet must have a way to authenticate end points > to control points (especially the access router) in the infrastructure and > vice versa. This is a fundamental function that is needed, no matter what a > single vendors wants. > > Regards > George > > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Thursday, April 04, 2002 2:01 AM > To: pana@research.telcordia.com > Subject: Question for vendors and operators > > Hello, > > We would like to hear from vendors and operators if PANA would be > something that solves a problem in their networks and hence would like > to see it standardized. > Would PANA be something that operators would deploy as an alternative > to doing authentication via PPPoE or PPP or 802.1x or via http > redirect? > > -Basavaraj From pana-request@research.telcordia.com Mon Apr 8 11:52:59 2002 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 LAA27801 for ; Mon, 8 Apr 2002 11:52:59 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g38Fm3Pn002122; Mon, 8 Apr 2002 11:48:03 -0400 (EDT) Resent-Date: Mon, 8 Apr 2002 11:48:03 -0400 (EDT) Old-Return-Path: Message-ID: <4652644B98DFF34696801F8F3070D3FE02008312@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Basavaraj.Patil@nokia.com'" , pana@research.telcordia.com Cc: "Beadles, Mark A" Subject: RE: Question for vendors and operators Date: Mon, 8 Apr 2002 15:47:26 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com I work for an IP service software company. Our product enables service providers to deploy IP based service via policy based provisioning. Currently we support remote access IP service. Our vision is to support a broad range of remote access technology. We view PANA as a future IP service we can deploy and manage when the technology is implemented in the boxes. -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: Wednesday, April 03, 2002 8:01 PM To: pana@research.telcordia.com Subject: Question for vendors and operators Hello, We would like to hear from vendors and operators if PANA would be something that solves a problem in their networks and hence would like to see it standardized. Would PANA be something that operators would deploy as an alternative to doing authentication via PPPoE or PPP or 802.1x or via http redirect? -Basavaraj From pana-request@research.telcordia.com Mon Apr 8 12:35:25 2002 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 MAA29244 for ; Mon, 8 Apr 2002 12:35:20 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g38GW4CB006356; Mon, 8 Apr 2002 12:32:04 -0400 (EDT) Resent-Date: Mon, 8 Apr 2002 12:32:04 -0400 (EDT) Old-Return-Path: Subject: RE: Question for vendors and operators To: "Wang, Cliff" Cc: 'Basavaraj.Patil@nokia.com', "Beadles, Mark A"@smartpipes.com, pana@research.telcordia.com X-Mailer: Lotus Notes Release 5.0 1999. 4. 14 Message-ID: From: sun@cloudwave.com Date: Tue, 9 Apr 2002 01:20:46 +0900 X-MIMETrack: Serialize by Router on cloudwave/Cloudwave(Release 5.0.3|2000. 4. 21.) at 2002-04-09 01:20:52 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-2022-kr X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com $)C Hi, We are a company specializing in AAA for wired & wireless network, based in seoul,korea. We plan to offer 802.1x soultion(Funk Steel betled RADIUS) to major carriers such as Korea Telecom, Dacom and Hanaro, among others. I think PANA BURP is much better than 802.1x since it is Layer2 independent. Definitely, PANA would be a viable soultion to PPPoE and 802.1x, at least in korea. rgds, Sun Kim VP / Business Development Cloudwave Inc. Seoul 82-2-501-2552(office) 82-16-358-6317(mobile) "Wang, Cliff" , pes.com> pana@research.telcordia.com B|A6@N: "Beadles, Mark A" 2002-04-09 A&8q: RE: Question for vendors and operators 12:47 AM I work for an IP service software company. Our product enables service providers to deploy IP based service via policy based provisioning. Currently we support remote access IP service. Our vision is to support a broad range of remote access technology. We view PANA as a future IP service we can deploy and manage when the technology is implemented in the boxes. -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: Wednesday, April 03, 2002 8:01 PM To: pana@research.telcordia.com Subject: Question for vendors and operators Hello, We would like to hear from vendors and operators if PANA would be something that solves a problem in their networks and hence would like to see it standardized. Would PANA be something that operators would deploy as an alternative to doing authentication via PPPoE or PPP or 802.1x or via http redirect? -Basavaraj From pana-request@research.telcordia.com Mon Apr 8 14:41:09 2002 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 OAA02263 for ; Mon, 8 Apr 2002 14:41:05 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g38Ib1FA017989; Mon, 8 Apr 2002 14:37:01 -0400 (EDT) Resent-Date: Mon, 8 Apr 2002 14:37:01 -0400 (EDT) Old-Return-Path: Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABCD1@ftmail> From: George Tsirtsis To: "'John Vollbrecht'" Cc: pana@research.telcordia.com Subject: RE: Question for vendors and operators Date: Mon, 8 Apr 2002 14:36:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com John, I apologize because I will not be able to give you detailed answers since Flash-OFDM is not yet a public technology (which is another reason I do not like wearing my vendor's hat here). In terms of authentication/encryption we have similar needs to any other wireless link layer (e.g.: 802.11). The only difference is that instead of Access Points you get Access Routers with wireless interface (we call them RadioRouters). I claim that PANA can cover our needs and at the same time cover the end node's needs across multiple technologies. George -----Original Message----- From: John Vollbrecht [mailto:jrv@interlinknetworks.com] Sent: Friday, April 05, 2002 10:18 PM To: George Tsirtsis Cc: 'Basavaraj.Patil@nokia.com'; pana@research.telcordia.com Subject: Re: Question for vendors and operators Hi George - Thanks for sending this. I do have some clarifying questions below -- John George Tsirtsis wrote: > All, > > I have been encouraged to give Flarion's opinion/use of PANA which requires > me to wear my vendor's hat...which feels a bit uncomfortable on an IETF > mailing list... Still, I endure... > > /--------------------------... > Here at Flarion we have developed a new link layer that we call Flash-OFDM. > This is a wireless link layer designed for Wide Area Networks (WAN), > cellular-type deployment and it is designed specifically for *data* i.e.: > The Internet > > The technology is designed to localized all L2 effects to the air link ONLY > i.e.: between the mobile node and an Access Router that each include a > Flash-OFDM interface, while the rest of the network is simply IP routers and > back end systems. Each Flash-OFDM interface on the Access Router/base > station is a cell or sector of a cell. To be sure I understand - does this mean that an L2 connection is established prior to authentication? Does each L2 connection uses a unique cell or sector of a cell? > > > We happen to run IP directly over Flash-OFDM so we DO NOT use PPP, while we > use Mobile IP for mobility management. NOTE that due to the one-hop nature > of the link layer, there is no backend link layer infrastructure to protect > using link layer security. Still, since this is intended for wide-area > deployment by operators we need to be able to authenticate end users and we > also need to encrypt the airlink. Is authentication after L2 connection ok or does the L2 connection need to be authenticated? Is encryption done at L2? Is an authorization dialog needed to support the link encryption? > > Clearly, we can use yet another link layer specific mechanism to carry > whatever authentication we decide to use, but given the single hop focus of > this L2 technology we gain nothing by doing it this way. On the other hand > Flash-OFDM and our mobility management system is ideal for inter-technology > handoffs (e.g.:Flash-OFDM to 802.11), and by using link layer > authentication, we need two different authentication transports for two > different technologies. > Are you talking here about link encryption or authentication dialog? It would seem Flash-OFDM is already a different transport technology, so how would PANA play here? > > So, if PANA existed today we would consider very seriously to adopt it and > so allow an operator to provide a single authentication client that can be > used for our own technology as well as for roaming to/from other > technologies. PANA would offer our customers (operators) one piece of client > authentication code and the ability to have exactly the same per user > settings and behavior, whatever the underlying technology. This sounds more like what you would like is a Client interface that works accross all technologies - with a common authentication technique. What role would you see PANA playing? Would it do user authentication? L2 Data encryption? > > \-------------------------... > > Removing my vendor's hat...aahh...feels better... > > I also believe that the Internet must have a way to authenticate end points > to control points (especially the access router) in the infrastructure and > vice versa. This is a fundamental function that is needed, no matter what a > single vendors wants. > > Regards > George > > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Thursday, April 04, 2002 2:01 AM > To: pana@research.telcordia.com > Subject: Question for vendors and operators > > Hello, > > We would like to hear from vendors and operators if PANA would be > something that solves a problem in their networks and hence would like > to see it standardized. > Would PANA be something that operators would deploy as an alternative > to doing authentication via PPPoE or PPP or 802.1x or via http > redirect? > > -Basavaraj From pana-request@research.telcordia.com Mon Apr 8 15:21:43 2002 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 PAA03519 for ; Mon, 8 Apr 2002 15:21:43 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g38JISU0022798; Mon, 8 Apr 2002 15:18:28 -0400 (EDT) Resent-Date: Mon, 8 Apr 2002 15:18:28 -0400 (EDT) Old-Return-Path: MIME-Version: 1.0 Content-Type: text/plain; charset="euc-kr" Subject: RE: Question for vendors and operators X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message Date: Mon, 8 Apr 2002 14:17:53 -0500 Message-ID: <3FA57694E8161144953749B65C66B5E305A622@mail1.cyberpixie.com> Thread-Topic: Question for vendors and operators thread-index: AcHfGxFbrurQ8XgIRaShPBsnbchweQAE8mtg From: "Robert Boxall" To: X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id PAA03519 I have developed and have had implemented an EAPoUDP system that is in use in several locations in the states. This works between our public access gateway and client application (either windows or java in webpage). This is fully compatible with funk and several other major RADIUS servers and provides a clean layer 3 solution. We took this approach as 802.1x was/is a nightmare to use and a somewhat 802.11 centric kludge, we also wanted layer 2 agnostic solution. We have also added several nice features such as the ability to push URLs to users. We also have an IPSEC tunnel ability with AES that we developed. Keys are generated after mutual authentication. We found many problems with 802.1x and our EAPoUDP system during this exercise and I intend to fix this on the second iteration of my work. Robert -----Original Message----- From: sun@cloudwave.com [mailto:sun@cloudwave.com] Sent: Monday, April 08, 2002 11:21 AM To: Wang, Cliff Cc: Basavaraj.Patil@nokia.com; "Beadles, Mark A"@smartpipes.com; pana@research.telcordia.com Subject: RE: Question for vendors and operators Hi, We are a company specializing in AAA for wired & wireless network, based in seoul,korea. We plan to offer 802.1x soultion(Funk Steel betled RADIUS) to major carriers such as Korea Telecom, Dacom and Hanaro, among others. I think PANA BURP is much better than 802.1x since it is Layer2 independent. Definitely, PANA would be a viable soultion to PPPoE and 802.1x, at least in korea. rgds, Sun Kim VP / Business Development Cloudwave Inc. Seoul 82-2-501-2552(office) 82-16-358-6317(mobile) "Wang, Cliff" , pes.com> pana@research.telcordia.com ÂüÁ¶ÀÎ: "Beadles, Mark A" 2002-04-09 Á¦¸ñ: RE: Question for vendors and operators 12:47 AM I work for an IP service software company. Our product enables service providers to deploy IP based service via policy based provisioning. Currently we support remote access IP service. Our vision is to support a broad range of remote access technology. We view PANA as a future IP service we can deploy and manage when the technology is implemented in the boxes. -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: Wednesday, April 03, 2002 8:01 PM To: pana@research.telcordia.com Subject: Question for vendors and operators Hello, We would like to hear from vendors and operators if PANA would be something that solves a problem in their networks and hence would like to see it standardized. Would PANA be something that operators would deploy as an alternative to doing authentication via PPPoE or PPP or 802.1x or via http redirect? -Basavaraj From pana-request@research.telcordia.com Mon Apr 8 21:07:45 2002 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 VAA11964 for ; Mon, 8 Apr 2002 21:07:17 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3911kGJ020391; Mon, 8 Apr 2002 21:01:46 -0400 (EDT) Resent-Date: Mon, 8 Apr 2002 21:01:46 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Subject: RE: Question for vendors and operators Date: Mon, 8 Apr 2002 20:00:18 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12BEF@daebe007.NOE.Nokia.com> Thread-Topic: Question for vendors and operators Thread-Index: AcHfGxFbrurQ8XgIRaShPBsnbchweQAE8mtgAAyvDLA= From: To: , X-OriginalArrivalTime: 09 Apr 2002 01:00:18.0473 (UTC) FILETIME=[EAA72990:01C1DF61] X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA11964 And all we are trying to do in this WG is to develop a solution that would basically enable what you describe below. So I do believe there is a real need for such a solution to be standardized in the IETF. -Basavaraj > -----Original Message----- > From: ext Robert Boxall [mailto:robert.boxall@cyberpixie.com] > Sent: Monday, April 08, 2002 2:18 PM > To: pana@research.telcordia.com > Subject: RE: Question for vendors and operators > > > I have developed and have had implemented an EAPoUDP system that is in > use in several locations in the states. This works between our public > access gateway and client application (either windows or java in > webpage). > > This is fully compatible with funk and several other major RADIUS > servers and provides a clean layer 3 solution. We took this > approach as > 802.1x was/is a nightmare to use and a somewhat 802.11 centric kludge, > we also wanted layer 2 agnostic solution. We have also added several > nice features such as the ability to push URLs to users. We also have > an IPSEC tunnel ability with AES that we developed. Keys are generated > after mutual authentication. > > We found many problems with 802.1x and our EAPoUDP system during this > exercise and I intend to fix this on the second iteration of my work. > > Robert > > > -----Original Message----- > From: sun@cloudwave.com [mailto:sun@cloudwave.com] > Sent: Monday, April 08, 2002 11:21 AM > To: Wang, Cliff > Cc: Basavaraj.Patil@nokia.com; "Beadles, Mark A"@smartpipes.com; > pana@research.telcordia.com > Subject: RE: Question for vendors and operators > > > Hi, > We are a company specializing in AAA for wired & wireless network, > based in > seoul,korea. > We plan to offer 802.1x soultion(Funk Steel betled RADIUS) to major > carriers such as Korea Telecom, Dacom and Hanaro, among others. > I think PANA BURP is much better than 802.1x since it is Layer2 > independent. > Definitely, PANA would be a viable soultion to PPPoE and 802.1x, at > least > in korea. > > rgds, > > Sun Kim > VP / Business Development > Cloudwave Inc. Seoul > 82-2-501-2552(office) > 82-16-358-6317(mobile) > > > > > "Wang, Cliff" > > "'Basavaraj.Patil@nokia.com'" , > pes.com> pana@research.telcordia.com > > ÂüÁ¶ÀÎ: "Beadles, Mark > A" > 2002-04-09 Á¦¸ñ: RE: Question > for vendors and operators > 12:47 AM > > > > > > > > > > > I work for an IP service software company. Our product enables service > providers to deploy IP based service via policy based provisioning. > Currently we support remote access IP service. Our vision is > to support > a > broad range of remote access technology. We view PANA as a future IP > service > we can deploy and manage when the technology is implemented in the > boxes. > > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Wednesday, April 03, 2002 8:01 PM > To: pana@research.telcordia.com > Subject: Question for vendors and operators > > > > Hello, > > We would like to hear from vendors and operators if PANA would be > something > that solves a problem in their networks and hence would like to see it > standardized. > Would PANA be something that operators would deploy as an > alternative to > doing authentication via PPPoE or PPP or 802.1x or via http redirect? > > -Basavaraj > > > > > > From pana-request@research.telcordia.com Mon Apr 8 23:16:51 2002 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 XAA16261 for ; Mon, 8 Apr 2002 23:16:47 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g393BdCB027633; Mon, 8 Apr 2002 23:11:39 -0400 (EDT) Resent-Date: Mon, 8 Apr 2002 23:11:39 -0400 (EDT) Old-Return-Path: Message-ID: <01ba01c1df74$13144360$6220110a@docomo.docomogr.net> From: "Aoki Hidenori" To: References: <3FA57694E8161144953749B65C66B5E305A622@mail1.cyberpixie.com> Subject: Re: Question for vendors and operators Date: Tue, 9 Apr 2002 12:10:17 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit Hello I'm working for a celluar phone company in japan. We will start a trial wireless LAN hotspot service this month. In the trial system we employed two kinds of authentiction. One is http redirection which is a network layer authentication and push URL to the users.this is our system's main authentication. The other is mac address based authentcaiton in wirelss LAN access point which is a link layer authenticaion to reduce a threat of ip spoofing. We don't think mac address based authenticaion is enought to offer a public access service and PANA would be a solution to develop our system. Hidenori Aoki NTT DoCoMo Inc. Wireless Link Development Dep. Phone : +81-3-5156-1767 FAX : +81-3-5156-0285 E-mail : aokihid@nttdocomo.co.jp ----- Original Message ----- From: "Robert Boxall" To: Sent: Tuesday, April 09, 2002 4:17 AM Subject: RE: Question for vendors and operators > I have developed and have had implemented an EAPoUDP system that is in > use in several locations in the states. This works between our public > access gateway and client application (either windows or java in > webpage). > > This is fully compatible with funk and several other major RADIUS > servers and provides a clean layer 3 solution. We took this approach as > 802.1x was/is a nightmare to use and a somewhat 802.11 centric kludge, > we also wanted layer 2 agnostic solution. We have also added several > nice features such as the ability to push URLs to users. We also have > an IPSEC tunnel ability with AES that we developed. Keys are generated > after mutual authentication. > > We found many problems with 802.1x and our EAPoUDP system during this > exercise and I intend to fix this on the second iteration of my work. > > Robert > > > -----Original Message----- > From: sun@cloudwave.com [mailto:sun@cloudwave.com] > Sent: Monday, April 08, 2002 11:21 AM > To: Wang, Cliff > Cc: Basavaraj.Patil@nokia.com; "Beadles, Mark A"@smartpipes.com; > pana@research.telcordia.com > Subject: RE: Question for vendors and operators > > > Hi, > We are a company specializing in AAA for wired & wireless network, > based in > seoul,korea. > We plan to offer 802.1x soultion(Funk Steel betled RADIUS) to major > carriers such as Korea Telecom, Dacom and Hanaro, among others. > I think PANA BURP is much better than 802.1x since it is Layer2 > independent. > Definitely, PANA would be a viable soultion to PPPoE and 802.1x, at > least > in korea. > > rgds, > > Sun Kim > VP / Business Development > Cloudwave Inc. Seoul > 82-2-501-2552(office) > 82-16-358-6317(mobile) > > > > > "Wang, Cliff" > > "'Basavaraj.Patil@nokia.com'" , > pes.com> pana@research.telcordia.com > > ÂüÁ¶ÀÎ: "Beadles, Mark > A" > 2002-04-09 Á¦¸ñ: RE: Question > for vendors and operators > 12:47 AM > > > > > > > > > > > I work for an IP service software company. Our product enables service > providers to deploy IP based service via policy based provisioning. > Currently we support remote access IP service. Our vision is to support > a > broad range of remote access technology. We view PANA as a future IP > service > we can deploy and manage when the technology is implemented in the > boxes. > > -----Original Message----- > From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] > Sent: Wednesday, April 03, 2002 8:01 PM > To: pana@research.telcordia.com > Subject: Question for vendors and operators > > > > Hello, > > We would like to hear from vendors and operators if PANA would be > something > that solves a problem in their networks and hence would like to see it > standardized. > Would PANA be something that operators would deploy as an alternative to > doing authentication via PPPoE or PPP or 802.1x or via http redirect? > > -Basavaraj > > > > > > From pana-request@research.telcordia.com Tue Apr 9 12:22:11 2002 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 MAA11164 for ; Tue, 9 Apr 2002 12:22:09 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g39GH8pH018153; Tue, 9 Apr 2002 12:17:08 -0400 (EDT) Resent-Date: Tue, 9 Apr 2002 12:17:08 -0400 (EDT) Old-Return-Path: Message-ID: <4652644B98DFF34696801F8F3070D3FE01DB914C@D2CSPEXM001.smartpipes.com> From: "Beadles, Mark A" To: "'Basavaraj.Patil@nokia.com'" , pana@research.telcordia.com Subject: RE: Question for vendors and operators Date: Tue, 9 Apr 2002 16:16:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com From: Basavaraj.Patil@nokia.com: >And all we are trying to do in this WG is to develop a solution that >would basically enable what you describe below. So I do believe there >is a real need for such a solution to be standardized in the IETF. Basavaraj, In relation to the question you have posed and the responses I have seen, please help me understand the following question: "Is it the intent of this WG to specify a new protocol to replace the PPP protocol suite in _wired_ as well as wireless access scenarios?" If "yes", what reason is there to replace a standardized, deployed, accepted protocol which works well for wired access? (This question is rhetorical). If "no", then is the work of this WG limited to the wireless space? I suspect the answer is "no" since all the responses I have seen to this question have been specifically limited to wireless scenarios. Is my suspicion correct? Is the PANA intended to be limited to wireless or is it Intended to be more generic in scope? Thanks Mark + Mark Anthony Beadles + mbeadles@smartpipes.com + + Chief Architect + SmartPipes, Inc. + + Vox 614.923.5657 + Fax 614.923.6299 + From pana-request@research.telcordia.com Tue Apr 9 14:12:25 2002 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 OAA14867 for ; Tue, 9 Apr 2002 14:12:21 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g39I9ST9002312; Tue, 9 Apr 2002 14:09:28 -0400 (EDT) Resent-Date: Tue, 9 Apr 2002 14:09:28 -0400 (EDT) Old-Return-Path: Message-ID: <00c101c1dff0$7fe936e0$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Beadles, Mark A" , , References: <4652644B98DFF34696801F8F3070D3FE01DB914C@D2CSPEXM001.smartpipes.com> Subject: Re: Question for vendors and operators Date: Tue, 9 Apr 2002 11:00:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Mark, > From: Basavaraj.Patil@nokia.com: > >And all we are trying to do in this WG is to develop a solution that > >would basically enable what you describe below. So I do believe there > >is a real need for such a solution to be standardized in the IETF. > > Basavaraj, > > In relation to the question you have posed and the responses I have seen, > please help me understand the following question: > > "Is it the intent of this WG to specify a new protocol to replace the PPP > protocol suite in _wired_ as well as wireless access scenarios?" The intent is not to replace "PPP". But in scenarios where PPP is used *only* for its authentication capability, PANA can be used instead. (So, PANA can not replace all functionalities of PPP in every usage scenario). > > If "yes", what reason is there to replace a standardized, deployed, accepted > protocol which works well for wired access? (This question is rhetorical). > > If "no", then is the work of this WG limited to the wireless space? No, it is not. It runs over IP, and one can deploy this solution whereever IP runs. > > I suspect the answer is "no" since all the responses I have seen to this > question have been specifically limited to wireless scenarios. Is my > suspicion correct? Is the PANA intended to be limited to wireless or is it > Intended to be more generic in scope? Definitely generic. It's upto the people to deploy it in whatever environment they wish to. The protocol design doesn't have to assume wired or wireless. alper > > Thanks > Mark > > + Mark Anthony Beadles + mbeadles@smartpipes.com + > + Chief Architect + SmartPipes, Inc. + > + Vox 614.923.5657 + Fax 614.923.6299 + > > From pana-request@research.telcordia.com Tue Apr 9 16:04:38 2002 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 QAA19889 for ; Tue, 9 Apr 2002 16:04:38 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g39K0nDM013108; Tue, 9 Apr 2002 16:00:49 -0400 (EDT) Resent-Date: Tue, 9 Apr 2002 16:00:49 -0400 (EDT) Old-Return-Path: Message-ID: <4652644B98DFF34696801F8F3070D3FE01DB9153@D2CSPEXM001.smartpipes.com> From: "Beadles, Mark A" To: "'Alper E. YEGIN'" , Basavaraj.Patil@nokia.com, pana@research.telcordia.com Subject: RE: Question for vendors and operators Date: Tue, 9 Apr 2002 20:00:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Let me confirm my understanding of what you have stated by rephrasing. In situations that call for the use of PPP, the Authentication Protocol is: (PAP), CHAP, EAP, etc. The protocol that carries the authentication protocol is: PPP LCP In situations that do not call for the use of PPP, the Authentication Protocol is: EAP, etc. The protocol that carries the authentication protocol is: PANA So PANA proposes a protocol for carrying authentication for network access _in non-PPP scenarios_. Is this an accurate statement? + Mark Anthony Beadles + mbeadles@smartpipes.com + + Chief Architect + SmartPipes, Inc. + + Vox 614.923.5657 + Fax 614.923.6299 + -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Tuesday, 09 April 2002 14:01 To: Beadles, Mark A; Basavaraj.Patil@nokia.com; pana@research.telcordia.com Subject: Re: Question for vendors and operators Mark, > From: Basavaraj.Patil@nokia.com: > >And all we are trying to do in this WG is to develop a solution that > >would basically enable what you describe below. So I do believe there > >is a real need for such a solution to be standardized in the IETF. > > Basavaraj, > > In relation to the question you have posed and the responses I have > seen, please help me understand the following question: > > "Is it the intent of this WG to specify a new protocol to replace the > PPP protocol suite in _wired_ as well as wireless access scenarios?" The intent is not to replace "PPP". But in scenarios where PPP is used *only* for its authentication capability, PANA can be used instead. (So, PANA can not replace all functionalities of PPP in every usage scenario). > > If "yes", what reason is there to replace a standardized, deployed, accepted > protocol which works well for wired access? (This question is > rhetorical). > > If "no", then is the work of this WG limited to the wireless space? No, it is not. It runs over IP, and one can deploy this solution whereever IP runs. > > I suspect the answer is "no" since all the responses I have seen to > this question have been specifically limited to wireless scenarios. > Is my suspicion correct? Is the PANA intended to be limited to > wireless or is it > Intended to be more generic in scope? Definitely generic. It's upto the people to deploy it in whatever environment they wish to. The protocol design doesn't have to assume wired or wireless. alper > > Thanks > Mark > > + Mark Anthony Beadles + mbeadles@smartpipes.com + > + Chief Architect + SmartPipes, Inc. + > + Vox 614.923.5657 + Fax 614.923.6299 + > > From pana-request@research.telcordia.com Tue Apr 9 18:24:18 2002 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 SAA24715 for ; Tue, 9 Apr 2002 18:24:11 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g39MJNKM025258; Tue, 9 Apr 2002 18:19:23 -0400 (EDT) Resent-Date: Tue, 9 Apr 2002 18:19:23 -0400 (EDT) Old-Return-Path: Message-ID: <022501c1e013$6873bb20$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Beadles, Mark A" , , References: <4652644B98DFF34696801F8F3070D3FE01DB9153@D2CSPEXM001.smartpipes.com> Subject: Re: Question for vendors and operators Date: Tue, 9 Apr 2002 15:10:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > Let me confirm my understanding of what you have stated by rephrasing. > > In situations that call for the use of PPP, > the Authentication Protocol is: (PAP), CHAP, EAP, etc. > The protocol that carries the authentication protocol is: PPP LCP > > In situations that do not call for the use of PPP, > the Authentication Protocol is: EAP, etc. > The protocol that carries the authentication protocol is: PANA > > So PANA proposes a protocol for carrying authentication for network access > _in non-PPP scenarios_. Is this an accurate statement? if "non-PPP scenario" means "scenario where PPP can be used only for its EAP encapsulation capability", then yes. alper > > + Mark Anthony Beadles + mbeadles@smartpipes.com + > + Chief Architect + SmartPipes, Inc. + > + Vox 614.923.5657 + Fax 614.923.6299 + > > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Tuesday, 09 April 2002 14:01 > To: Beadles, Mark A; Basavaraj.Patil@nokia.com; pana@research.telcordia.com > Subject: Re: Question for vendors and operators > > > Mark, > > > From: Basavaraj.Patil@nokia.com: > > >And all we are trying to do in this WG is to develop a solution that > > >would basically enable what you describe below. So I do believe there > > >is a real need for such a solution to be standardized in the IETF. > > > > Basavaraj, > > > > In relation to the question you have posed and the responses I have > > seen, please help me understand the following question: > > > > "Is it the intent of this WG to specify a new protocol to replace the > > PPP protocol suite in _wired_ as well as wireless access scenarios?" > > The intent is not to replace "PPP". But in scenarios where PPP is used > *only* for its authentication capability, PANA can be used instead. (So, > PANA can not replace all functionalities of PPP in every usage scenario). > > > > > If "yes", what reason is there to replace a standardized, deployed, > accepted > > protocol which works well for wired access? (This question is > > rhetorical). > > > > If "no", then is the work of this WG limited to the wireless space? > > No, it is not. It runs over IP, and one can deploy this solution whereever > IP runs. > > > > > I suspect the answer is "no" since all the responses I have seen to > > this question have been specifically limited to wireless scenarios. > > Is my suspicion correct? Is the PANA intended to be limited to > > wireless or is > it > > Intended to be more generic in scope? > > Definitely generic. It's upto the people to deploy it in whatever > environment they wish to. The protocol design doesn't have to assume wired > or wireless. > > alper > > > > > Thanks > > Mark > > > > + Mark Anthony Beadles + mbeadles@smartpipes.com + > > + Chief Architect + SmartPipes, Inc. + > > + Vox 614.923.5657 + Fax 614.923.6299 + > > > > > From pana-request@research.telcordia.com Tue Apr 9 18:37:32 2002 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 SAA24893 for ; Tue, 9 Apr 2002 18:37:31 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g39MYhYn026318; Tue, 9 Apr 2002 18:34:43 -0400 (EDT) Resent-Date: Tue, 9 Apr 2002 18:34:43 -0400 (EDT) Old-Return-Path: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Question for vendors and operators Date: Tue, 9 Apr 2002 17:34:10 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12C10@daebe007.NOE.Nokia.com> Thread-Topic: Question for vendors and operators Thread-Index: AcHgATzBB/JCVSDKR46ayrtXI8kJ5gAFVtcQ From: To: , , X-OriginalArrivalTime: 09 Apr 2002 22:34:10.0442 (UTC) FILETIME=[AAE98EA0:01C1E016] X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA24893 >Let me confirm my understanding of what you have stated by rephrasing. > >In situations that call for the use of PPP, >the Authentication Protocol is: (PAP), CHAP, EAP, etc. >The protocol that carries the authentication protocol is: PPP LCP > >In situations that do not call for the use of PPP, >the Authentication Protocol is: EAP, etc. >The protocol that carries the authentication protocol is: PANA Yes. > >So PANA proposes a protocol for carrying authentication for network access >_in non-PPP scenarios_. Is this an accurate statement? Yes.... But remember that the non-PPP here implies only the authentication aspect of PPP. So there are two scenarios that should be considered: 1. A client connects to the network via PPP and authenticates at L2 using PPP LCP. The network in addition may also require an L3 authentication for various reasons (other than network access control). If that is the case PANA carries the authentication protocol. 2. Client connects to the network via PPP. Authentication for network access is done above L2. PANA would be the protocol that carries the authentication protocol. PPP is one example. 802.1x could be another. At no place is the suggestion that PANA replace PPP LCP or 802.1x. > >+ Mark Anthony Beadles + mbeadles@smartpipes.com + >+ Chief Architect + SmartPipes, Inc. + >+ Vox 614.923.5657 + Fax 614.923.6299 + > > -Basavaraj From pana-request@research.telcordia.com Wed Apr 10 05:00:39 2002 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 FAA14044 for ; Wed, 10 Apr 2002 05:00:20 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3A8u3X3027419; Wed, 10 Apr 2002 04:56:03 -0400 (EDT) Resent-Date: Wed, 10 Apr 2002 04:56:03 -0400 (EDT) Old-Return-Path: Message-ID: <90460-52499@greenrider.com> From: "dave" To: Subject: testing without animation Date: Wed Apr 10 12:56:21 EST 2002 MIME-Version: 1.0 MIME-Engine: GreenRider 1.01 Content-Type: multipart/mixed; boundary="----=_Next_Part_0000000000_mailer_90460-52499=----" X-Mailer: GreenRider 1.01 X-Unsubscribe: http://www.greenrider.com/cgi-bin/mailer/unsubscribe.cgi?UNSUBID=OTA0NjAtNTI0OTl8ZmFyc2lkZXxwYW5hQHJlc2VhcmNoLnRlbGNvcmRpYS5jb20= X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is a multi-part message in MIME format. ----=_Next_Part_0000000000_mailer_90460-52499=---- Content-Type: text/plain; charset="iso-8859-1" VKI STUDIOS Dynamic Internet Marketing for your website. 1-866-733-8899 "VKI increased our web traffic by 550% which resulted in a 20% increase in revenues in less than six months." John Keith-King, Curator, Granville Island Museums. Would you like to see if you can achieve similar results? Call us at 1-866-733-8899 or fill out our online consultation and receive a FREE Search Engine Report (value $75.00) Follow this link: http://www.vkistudios.org/form_internet_mkt.html THE BENEFITS * Your website will become highly visible * Your traffic will grow exponentially * Measurable and trackable results *You will have an ongoing strategy that adapts as search engines change THE ELEVATION * Strategy development * Keyword Formulation * Creation of keyword & description META tags * Creation of keyword entry pages * FTP file transfer to server * Submission of web address (URL) to search engines *Submission of web address (URL) to directory sites THE PUSH - ongoing maintenance! includes: * Optimization - HTML optimization to be search engine friendly * Submission - Proper submission protocol for each individual engine * Registration - Verification of successful submissions * Monitoring - Evaluation of server file logs for search engine activity * Positioning - Fine-tuning of submitted pages *Maintenance - Continuous attendance to all the above actions Online consultation - http://www.vkistudios.org/form_internet_mkt.html Many Search Engines are moving to paid listings so ACT NOW! Contact us today to take advantage of our limited time offer. Please call us: 1-866-733-8899 or (604) 733-1474 - VKI Studios Inc. We hope you enjoyed receiving this message. However, if you'd rather not receive future e-mails of this sort from us, please click on the following link to unsubscribe from our mailing list: http://www.greenrider.com/cgi-bin/mailer/unsubscribe.cgi?UNSUBID=OTA0NjAtNTI0OTl8ZmFyc2lkZXxwYW5hQHJlc2VhcmNoLnRlbGNvcmRpYS5jb20= This email was sent to: pana@research.telcordia.com ------=_Next_Part_0000000000_mailer_90460-52499=---- Content-Type: text/html; charset="iso-8859-1" Professional Internet Marketing, VKI Studios 1-866-733-8899
1-866-733-8899 
We hope you enjoyed receiving this message. However, if you'd rather not receive future e-mails of this sort from us, please click on the following link to unsubscribe from our mailing list: Unsubscribe

This email was sent to: pana@research.telcordia.com
------=_Next_Part_0000000000_mailer_90460-52499=------ From pana-request@research.telcordia.com Thu Apr 11 04:23:09 2002 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 EAA22088 for ; Thu, 11 Apr 2002 04:22:45 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3B8HKHc009673; Thu, 11 Apr 2002 04:17:20 -0400 (EDT) Resent-Date: Thu, 11 Apr 2002 04:17:20 -0400 (EDT) Old-Return-Path: Message-ID: <26580-34389@greenrider.com> From: "Sydney Ferguson" To: Subject: ADV: Professional Internet Marketing Date: Thu Apr 11 16:41:58 EST 2002 MIME-Version: 1.0 MIME-Engine: GreenRider 1.01 Content-Type: multipart/mixed; boundary="----=_Next_Part_0000000000_mailer_26580-34389=----" X-Mailer: GreenRider 1.01 X-Unsubscribe: http://www.greenrider.com/cgi-bin/mailer/unsubscribe.cgi?UNSUBID=MjY1ODAtMzQzODl8ZmFyc2lkZXxwYW5hQHJlc2VhcmNoLnRlbGNvcmRpYS5jb20= X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is a multi-part message in MIME format. ----=_Next_Part_0000000000_mailer_26580-34389=---- Content-Type: text/plain; charset="iso-8859-1" VKI STUDIOS Dynamic Internet Marketing for your website. 1-866-733-8899 "VKI increased our web traffic by 550% which resulted in a 20% increase in revenues in less than six months." John Keith-King, Curator, Granville Island Museums. Would you like to see if you can achieve similar results? Call us at 1-866-733-8899 or fill out our online consultation and receive a FREE Search Engine Report (value $75.00) Follow this link: http://www.vkistudios.org/form_internet_mkt.html THE BENEFITS * Your website will become highly visible * Your traffic will grow exponentially * Measurable and trackable results *You will have an ongoing strategy that adapts as search engines change THE ELEVATION * Strategy development * Keyword Formulation * Creation of keyword & description META tags * Creation of keyword entry pages * FTP file transfer to server * Submission of web address (URL) to search engines *Submission of web address (URL) to directory sites THE PUSH - ongoing maintenance! includes: * Optimization - HTML optimization to be search engine friendly * Submission - Proper submission protocol for each individual engine * Registration - Verification of successful submissions * Monitoring - Evaluation of server file logs for search engine activity * Positioning - Fine-tuning of submitted pages *Maintenance - Continuous attendance to all the above actions Online consultation - http://www.vkistudios.org/form_internet_mkt.html Many Search Engines are moving to paid listings so ACT NOW! Contact us today to take advantage of our limited time offer. Please call us: 1-866-733-8899 or (604) 733-1474 - VKI Studios Inc. We hope you enjoyed receiving this message. However, if you'd rather not receive future e-mails of this sort from us, please click on the following link to unsubscribe from our mailing list: http://www.greenrider.com/cgi-bin/mailer/unsubscribe.cgi?UNSUBID=MjY1ODAtMzQzODl8ZmFyc2lkZXxwYW5hQHJlc2VhcmNoLnRlbGNvcmRpYS5jb20= This email was sent to: pana@research.telcordia.com ------=_Next_Part_0000000000_mailer_26580-34389=---- Content-Type: text/html; charset="iso-8859-1" Professional Internet Marketing, VKI Studios 1-866-733-8899
1-866-733-8899 
We hope you enjoyed receiving this message. However, if you'd rather not receive future e-mails of this sort from us, please click on the following link to unsubscribe from our mailing list: Unsubscribe

This email was sent to: pana@research.telcordia.com
------=_Next_Part_0000000000_mailer_26580-34389=------ From pana-request@research.telcordia.com Thu Apr 11 17:06:03 2002 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 RAA14980 for ; Thu, 11 Apr 2002 17:05:51 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3BKx1ja013171; Thu, 11 Apr 2002 16:59:01 -0400 (EDT) Resent-Date: Thu, 11 Apr 2002 16:59:01 -0400 (EDT) Old-Return-Path: Date: Thu, 11 Apr 2002 16:58:52 -0400 (EDT) Message-Id: <200204112058.g3BKwqaD013133@thumper.research.telcordia.com> Subject: The Stainless Steel Network To: pana@research.telcordia.com From: "BuyStainlessOnline.com" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Unsubscribe by clicking the link at the bottom of this E-mail! It's quick and painless. The Stainless Steel Network is brought to you by www.buystainlessonline.com Stainless Tread (DIAMOND) Plate 304 1/8" x 48" x 120" 3760.lbs $1.00 ./lb 304 1/8" x 48" x 240" 4945.lbs FOB Bensalem Stainless Coils T-301 2b MAKE OFFER 038 x 25 1/2" - 16,075# 038 x 25 1/2" - 18,660# T-305 2b MAKE OFFER 038 x 25 1/2" - 5808# 038 x 25 1/2" - 5980# Stainless Sheet PRE-Buff 020 x 48 x 96 10,000.lbs $.85 Stainless Sheet 2b 024 x 48 x 120 5,000.lbs $.85 Stainless Round Bar 316L .5" x 144" 14,000.lbs $.95 /.lb 316 .625" x 144" 2,000.lbs $.85 /.lb 316 .750" x 144" 12,000.lbs $.90 /.lb 316 1" x 144" 1,798.lbs $.90 /.lb 304 .375" x 144" 3,370.lbs $.78 /.lb 304 1" x 144" 1,334.lbs $.76 /.lb Call us For FLAT BAR! www.BuyStainlessOnline.com Your Place for Stainless Today. Toll Free 800.664.2366 International 215.245.1600 Fax 215.245.6996 Click Here to REGISTER! https://www.buystainlessonline.com/registration/registration.php Unsubscribe By clicking below: http://www.buystainlessonline.com/email/mail.php?action=delete&eval=140896&email=pana@research.telcordia.com From pana-request@research.telcordia.com Thu Apr 11 18:47:16 2002 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 SAA18151 for ; Thu, 11 Apr 2002 18:47:16 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3BMhPFI021470; Thu, 11 Apr 2002 18:43:25 -0400 (EDT) Resent-Date: Thu, 11 Apr 2002 18:43:25 -0400 (EDT) Old-Return-Path: Sender: prakash@net.com Message-ID: <3CB6115E.2C34FB86@net.com> Date: Thu, 11 Apr 2002 15:42:38 -0700 From: Prakash Jayaraman Organization: N.E.T. http://www.net.com X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, en-GB, fr, de MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com CC: pana@research.telcordia.com Subject: Re: Question for vendors and operators References: <697DAA22C5004B4596E033803A7CEF44A12B62@daebe007.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Basavaraj.Patil@nokia.com wrote: > > Hello, > > We would like to hear from vendors and operators if PANA would be > something that solves a problem in their networks and hence would like > to see it standardized. > Would PANA be something that operators would deploy as an alternative > to doing authentication via PPPoE or PPP or 802.1x or via http > redirect? > > -Basavaraj In our NAS environment, we are looking for a solution to authorize, authenticate a user (a person) before we allow him/her to use the network. Note that NAS supports multiple providers for customers and so it supports dynamic provider selection. It also supports multiple contexts (multiple address spaces, overlapping or not) for administrative, billing and security reasons. The medium between the users and NAS is either P2P (traditional dialup lines, DSL, ATM links etc.) or broadcast (cable-modem network). 1) PPP - currently widely in use. * Only one PPP connection is allowed per link. * NAS authenticates the user using CHAP and assigns IP address using IPCP. * CHAP phase is also used to do "dynamic provider selection". 2) To support more than one user, * If you need to support more than one user with just PPP, NAT gets used at the customer-premises. CPE equipment to do this are widely available these days. * PPPoE - supports more than one user. - DISCOVERY stage also works as a signalling protocol to perform dynamic service selection. But in our implementation, we do not use this feature. We prefer to use out-of-band means to do service selection. 3) DHCP - not very widely in use. * NAS acts either as DHCP relay agent or as server (depending on the configuration). Problems with PPPoE: Have to install a special client on the CPE and it creates management trouble as it is not part of most clients. More software layers on the NAS - we would like to use less software if possible. Hardware switching becomes very tricky due to the extra 6-byte header. (Part of the reason is that when encapsulated in LLC-AAL5, the destination IP address is on the second cell. This is not an issue if we don't have this 6-byte header). Such tricks are not trivial and result in use of additional hardware resources. The solutions that we have are not easy to do and we prefer not having to go through such issues in the next-gen hardware. Since we are using PPPoE only to support multiple-clients at the customer-side, I prefer the customers use PPP+NAT to PPPoE or DHCP. Problems with PPP: We are using PPP for AAA and address assignment only, in a NAS application. We only support IP within PPP. Support for other protocols is of no practical use for the NAS application today. That being the case, we would like to support IP directly, but it is not that big a deal to support PPP (with or without NAT) and we don't intend to stop supporting it. PPP supports assignment of IP-address, DNS and WINS addresses only. Sometimes, we need to support some more configuration parameters for which we think DHCP would be the way to go. I don't think we will remove support for PPP even in a distant future, but we would like to discontinue support for PPPoE as soon as possible. Supporting PPP+NAT, requires intelligent CPE throughout the life of the connection. This could become a major issue for network and user administration. Problems with DHCP: * Does not have the authentication mechanism and so can't use it in untrusted environment. But then there are ISPs already that have begun to use DHCP on P2P links for the sole reason that there is absolutely no administrative overhead. * We are being asked to AAA the users before network-access is granted. We are using a proprietary application layer method to do so and that is not simple either and it does not seem to work in all situations. Problems in a network with statically assigned IP-address: * We would like to AAA the users before the machine is allowed to access the network. * Application layer proprietary AAA mechanism might work, but we would like to see a standard solution. AAA-ing the machine using layer-2 parameters is probably useful, but it is not sufficient for providing user-specific services. Any AAA phase before network-access (with and without the use of DHCP, before or after DHCP if DHCP is used) will be useful for our application. Any such mechanism should provide an NAS with both of the following. * dynamic service-provider selection (for IP-address assignment). * complete layer-2 independent two-way AAA mechanism. - prakash From pana-request@research.telcordia.com Thu Apr 11 21:24:37 2002 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 VAA24533 for ; Thu, 11 Apr 2002 21:24:37 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3C1JG6B000695; Thu, 11 Apr 2002 21:19:16 -0400 (EDT) Resent-Date: Thu, 11 Apr 2002 21:19:16 -0400 (EDT) Old-Return-Path: Message-ID: <03b801c1e1bf$11fcae20$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: <697DAA22C5004B4596E033803A7CEF44A12B60@daebe007.NOE.Nokia.com> Subject: Location of authentication agent Date: Thu, 11 Apr 2002 18:12:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > The Authentication Agent can reside on any node in the network that can > send/receive IP datagrams (i.e., has an IP stack). The Authentication > Agent and the Enforcement Point can be co-located (as is the case with > PPP and EAPOW), or be on separate nodes. PANA will identify a transport > (e.g., AAA, SNMP, COPS, etc.) to carry access control information > (such as filters) from the Authentication Agent to the Enforcement point > when these two entities are separated. > There are pros and cons associated with having the authentication > agent beyond the first hop [NAS/AP/Rtr/etc.]. This is an issue that > needs to be delved into by the WG. PANA provides the flexibility that the Authentication Agent and the Enforcement Point can be co-located or separate. Co-location is the model that is already used with the existing link-layer authentication protocols. Separation looks like a good feature, yet it requires using another transport between two. In order to better understand the value of separation, we need to look at some usage scenarios. Can people think of such scenarios? Comments please.. alper From pana-request@research.telcordia.com Fri Apr 12 09:21:57 2002 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 JAA20074 for ; Fri, 12 Apr 2002 09:21:56 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3CDHC7E010579; Fri, 12 Apr 2002 09:17:12 -0400 (EDT) Resent-Date: Fri, 12 Apr 2002 09:17:12 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC58@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Alper E. YEGIN'" , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Fri, 12 Apr 2002 15:06:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > > The Authentication Agent can reside on any node in the > network that can > > send/receive IP datagrams (i.e., has an IP stack). The > Authentication > > Agent and the Enforcement Point can be co-located (as is > the case with > > PPP and EAPOW), or be on separate nodes. PANA will > identify a transport > > (e.g., AAA, SNMP, COPS, etc.) to carry access control information > > (such as filters) from the Authentication Agent to the > Enforcement point > > when these two entities are separated. > > There are pros and cons associated with having the authentication > > agent beyond the first hop [NAS/AP/Rtr/etc.]. This is an > issue that > > needs to be delved into by the WG. > > PANA provides the flexibility that the Authentication Agent and the > Enforcement Point can be co-located or separate. Co-location is the > model that is already used with the existing link-layer > authentication > protocols. > Separation looks like a good feature, yet it requires using another > transport between two. > > In order to better understand the value of separation, we > need to look at > some > usage scenarios. Can people think of such scenarios? => More than the ones in the scenarios draft? Namely: Load sharing, limited free access and payment after a certain point..etc Hesham From pana-request@research.telcordia.com Fri Apr 12 11:47:07 2002 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 LAA08281 for ; Fri, 12 Apr 2002 11:47:02 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3CFehEm024659; Fri, 12 Apr 2002 11:40:43 -0400 (EDT) Resent-Date: Fri, 12 Apr 2002 11:40:43 -0400 (EDT) Old-Return-Path: Message-ID: <3CB6FFD9.40555B06@interlinknetworks.com> Date: Fri, 12 Apr 2002 11:40:09 -0400 From: John Vollbrecht X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" Cc: "'Alper E. YEGIN'" , pana@research.telcordia.com Subject: Re: Location of authentication agent References: <4DA6EA82906FD511BE2F00508BCF053802C6AC58@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit "Hesham Soliman (ERA)" wrote: > > > > > > In order to better understand the value of separation, we > > need to look at > > some > > usage scenarios. Can people think of such scenarios? > > => More than the ones in the scenarios draft? > Namely: Load sharing, limited free access and > payment after a certain point..etc > > Hesham I would be interested in understanding the model for each of these. I don't understand why separation of agent and enforcement point is needed for load sharing, for example. Could you draw the diagrams and explain what the role of each element is? For example - are you thinking of something like this? client ------- edge device/ enforcement point --------- Pana Agent -------- Pana Server Thanks -- John From pana-request@research.telcordia.com Fri Apr 12 17:43:04 2002 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 RAA04824 for ; Fri, 12 Apr 2002 17:42:43 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3CLHTpO029562; Fri, 12 Apr 2002 17:17:29 -0400 (EDT) Resent-Date: Fri, 12 Apr 2002 17:17:29 -0400 (EDT) Old-Return-Path: Message-ID: <016a01c1e266$72f31780$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Hesham Soliman \(ERA\)" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AC58@Esealnt861.al.sw.ericsson.se> Subject: Re: Location of authentication agent Date: Fri, 12 Apr 2002 14:10:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > > PANA provides the flexibility that the Authentication Agent and the > > Enforcement Point can be co-located or separate. Co-location is the > > model that is already used with the existing link-layer > > authentication > > protocols. > > Separation looks like a good feature, yet it requires using another > > transport between two. > > > > In order to better understand the value of separation, we > > need to look at > > some > > usage scenarios. Can people think of such scenarios? > > => More than the ones in the scenarios draft? > Namely: Load sharing, limited free access and > payment after a certain point..etc We should look closer at these scenarios. For example, in limited free access and payment after a certain point scenario, where would you put the authentication agent? It'd be good to take a look at the model and required interactions among protocol entities. While this scenario can be supported by separation of authentication agent from the enforcement point, does it really need that? Or can we achive the same when two are co-located? What component of this scenario requires the separation? Can you please provide more details... alper > > Hesham > From pana-request@research.telcordia.com Fri Apr 12 18:18:33 2002 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 SAA05417 for ; Fri, 12 Apr 2002 18:18:33 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3CMEWYo010703; Fri, 12 Apr 2002 18:14:32 -0400 (EDT) Resent-Date: Fri, 12 Apr 2002 18:14:32 -0400 (EDT) Old-Return-Path: Message-ID: <3CB75052.B2532AEA@research.telcordia.com> Date: Fri, 12 Apr 2002 17:23:30 -0400 From: subir Das X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Vollbrecht CC: "Hesham Soliman (ERA)" , "'Alper E. YEGIN'" , pana@research.telcordia.com Subject: Re: Location of authentication agent References: <4DA6EA82906FD511BE2F00508BCF053802C6AC58@Esealnt861.al.sw.ericsson.se> <3CB6FFD9.40555B06@interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <9T9mED.A.HnC.Hx1t8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit John, > For example - are you thinking of something like this? > > client ------- edge device/ enforcement point --------- Pana Agent > -------- Pana Server I would prefer following for limited free access: PANA Agent -----------------PANA Server | Client ------ edge device -------- enforcement point Thanks, Subir From pana-request@research.telcordia.com Fri Apr 12 20:52:39 2002 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 UAA07645 for ; Fri, 12 Apr 2002 20:52:29 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3D0lEK8019221; Fri, 12 Apr 2002 20:47:14 -0400 (EDT) Resent-Date: Fri, 12 Apr 2002 20:47:14 -0400 (EDT) Old-Return-Path: Message-ID: <002401c1e284$54543610$746015ac@T23KEMPF> From: "James Kempf" To: "Alper E. YEGIN" , References: <697DAA22C5004B4596E033803A7CEF44A12B60@daebe007.NOE.Nokia.com> <03b801c1e1bf$11fcae20$736015ac@AlperVAIO> Subject: Re: Location of authentication agent Date: Fri, 12 Apr 2002 17:38:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <7X1mi.A.NsE.RA4t8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit I question the value of separation, since it will require a separate protocol to transmit the enforcement decisions between the enforcement point and the authentication agent. I have, as yet, not seen a compelling need for complicating the traditional NAS architecture in this manner. jak ----- Original Message ----- From: "Alper E. YEGIN" To: Sent: Thursday, April 11, 2002 6:12 PM Subject: Location of authentication agent > > > The Authentication Agent can reside on any node in the network that can > > send/receive IP datagrams (i.e., has an IP stack). The Authentication > > Agent and the Enforcement Point can be co-located (as is the case with > > PPP and EAPOW), or be on separate nodes. PANA will identify a transport > > (e.g., AAA, SNMP, COPS, etc.) to carry access control information > > (such as filters) from the Authentication Agent to the Enforcement point > > when these two entities are separated. > > There are pros and cons associated with having the authentication > > agent beyond the first hop [NAS/AP/Rtr/etc.]. This is an issue that > > needs to be delved into by the WG. > > PANA provides the flexibility that the Authentication Agent and the > Enforcement Point can be co-located or separate. Co-location is the > model that is already used with the existing link-layer authentication > protocols. > Separation looks like a good feature, yet it requires using another > transport between two. > > In order to better understand the value of separation, we need to look at > some > usage scenarios. Can people think of such scenarios? > > Comments please.. > > alper > > > > > > > > > > From pana-request@research.telcordia.com Fri Apr 12 21:14:05 2002 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 VAA07941 for ; Fri, 12 Apr 2002 21:14:05 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3D18jbO020184; Fri, 12 Apr 2002 21:08:45 -0400 (EDT) Resent-Date: Fri, 12 Apr 2002 21:08:45 -0400 (EDT) Old-Return-Path: From: jorMTtNHT@yahoo.com Reply-To: Message-ID: To: Subject: toner cartridges Date: Fri, 12 Apr 2002 08:59:24 -0580 MiME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00D1_12G23J4K.L1454P76" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: QUALCOMM Windows Eudora Version 5.1 Importance: Normal X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com ------=_NextPart_000_00D1_12G23J4K.L1454P76 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4NCjxodG1sPg0KPGhlYWQ+DQogICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCiAgIDxtZXRhIG5hbWU9 IkF1dGhvciIgY29udGVudD0ic2FtIj4NCiAgIDxtZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVu dD0iTW96aWxsYS80LjYxIFtlbl0gKFdpbjk4OyBJKSBbTmV0c2NhcGVdIj4NCiAgIDx0aXRsZT5m Z2ZnPC90aXRsZT4NCjwvaGVhZD4NCjxib2R5Pg0KJm5ic3A7DQo8dGFibGUgQk9SREVSIENPTFM9 MSBXSURUSD0iMTAwJSIgSEVJR0hUPSIxNSUiIEJHQ09MT1I9IiM0MDgwODAiID4NCjx0cj4NCjx0 ZCBCR0NPTE9SPSIjNDA4MDgwIj4NCjxjZW50ZXI+PGI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBN UyI+PGZvbnQgY29sb3I9IiNGRkZGRkYiPjxmb250IHNpemU9KzM+VkVSVEVYDQpURUNITk9MT0dJ RVM8L2ZvbnQ+PC9mb250PjwvZm9udD48L2I+DQo8YnI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBN UyI+PGZvbnQgc2l6ZT0rMz4mbmJzcDs8Yj48Zm9udCBjb2xvcj0iI0ZGRkZGRiI+TGFzZXINClBy aW50ZXIgU3VwcGxpZXM8L2ZvbnQ+PC9iPjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0K PC90cj4NCjwvdGFibGU+DQoNCjxjZW50ZXI+DQo8cD48aT48Zm9udCBmYWNlPSJDb21pYyBTYW5z IE1TIj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rND5USEFOSw0KWU9VIEZPUiBW SVNJVElORyBPVVIgV0VCU0lURSAhITwvZm9udD48L2ZvbnQ+PC9mb250PjwvaT4NCjxwPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8Zm9udCBmYWNlPSJDb21pYyBT YW5zIE1TIj48Zm9udCBzaXplPSsyPkNPTVBBVElCTEUmbmJzcDsNCjwvZm9udD48dT48Zm9udCBj b2xvcj0iI0ZGMDAwMCI+PGZvbnQgc2l6ZT0rMz5TUEVDSUFMUw0KPC9mb250PjwvZm9udD48L3U+ PGZvbnQgc2l6ZT0rMj5USElTJm5ic3A7DQpXRUVLIE9OJm5ic3A7IExBU0VSIFBSSU5URVIgVE9O RVIgQU5EIENPUElFUiBDQVJUUklER0VTJm5ic3A7IFRPJm5ic3A7DQpGSVQgWU9VUiBNQUNISU5F PC9mb250PjwvZm9udD4NCjxwPiZuYnNwOzxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250 IGNvbG9yPSIjMDAwMDAwIj48Zm9udCBzaXplPSsyPk9SREVSDQpCWSBQSE9ORTogMS04ODgtMjg4 LTkwNDM8L2ZvbnQ+PC9mb250PjwvZm9udD4NCjxicj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1T Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGZvbnQgc2l6ZT0rMj5PUkRFUg0KQlkgRkFYOiAxLTg4 OC05NzctMTU3NzwvZm9udD48L2ZvbnQ+PC9mb250Pg0KPHA+PGZvbnQgZmFjZT0iQ29taWMgU2Fu cyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwQTAiPjxmb250IHNpemU9KzE+RU1BSUwNClJFTU9WQUwg TElORTogMS04ODgtMjQ4LTQ5MzA8L2ZvbnQ+PC9mb250PjwvZm9udD4NCjxwPjxmb250IGZhY2U9 IkNvbWljIFNhbnMgTVMiPiZuYnNwO09SREVSIEJZIFBBR0UgTlVNQkVSIEFORC9PUiBJVEVNIE5V TUJFUjwvZm9udD4NCjxwPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPkZPUiBPUkRFUklORyBJ TlNUUlVDVElPTlMgUExFQVNFIEdPIFRPJm5ic3A7DQpPVVIgTk9URVMvRVhDTFVTSU9OUzwvZm9u dD4NCjxicj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj5BVCBUSEUgRU5EIE9GIFRISVMgQURW RVJUSVNFTUVOVDwvZm9udD4NCjxicj4mbmJzcDsNCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ozxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPiZuYnNwOyA8dT48Zm9udCBjb2xvcj0iIzAwMDA5 OSI+PGZvbnQgc2l6ZT0rMj5Gb3INCkhld2xldHQgUGFja2FyZCBQcmludGVyczo8aT4gPC9pPihQ YWdlIDIpPC9mb250PjwvZm9udD48L3U+PC9mb250PjwvY2VudGVyPg0KDQo8cD48YnI+DQo8Y2Vu dGVyPjx0YWJsZSBCT1JERVIgV0lEVEg9IjgwJSIgSEVJR0hUPSIxMCUiIEJHQ09MT1I9IiNGRkZG Q0MiID4NCjx0ciBCR0NPTE9SPSIjNDA4MDgwIj4NCjx0ZCBCR0NPTE9SPSIjNDA4MDgwIj4NCjxj ZW50ZXI+PGI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiNGRkZGRkYi Pjxmb250IA0Kc2l6ZT0rMT5JVEVNPC9mb250PjwvZm9udD48L2ZvbnQ+PC9iPjwvY2VudGVyPg0K PC90ZD4NCg0KPHRkIEJHQ09MT1I9IiM0MDgwODAiPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21p YyBTYW5zIE1TIj48Zm9udCBzaXplPSsxPiZuYnNwOzxiPjxmb250IA0KY29sb3I9IiNGRkZGRkYi PkRFU0NSSVBUSU9OPC9mb250PjwvYj48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0K PHRkPg0KPGNlbnRlcj48Yj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0i I0ZGRkZGRiI+PGZvbnQgc2l6ZT0rMT5NRkcNCiM8L2ZvbnQ+PC9mb250PjwvZm9udD48L2I+PC9j ZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxiPjxmb250IGZhY2U9IkNvbWljIFNhbnMg TVMiPjxmb250IGNvbG9yPSIjRkZGRkZGIj48Zm9udCANCnNpemU9KzE+UFJJQ0U8L2ZvbnQ+PC9m b250PjwvZm9udD48L2I+PC9jZW50ZXI+DQo8L3RkPg0KPC90cj4NCg0KPHRyPg0KPHRkIEJHQ09M T1I9IiNGRkZGQ0MiPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBj b2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5JdGVtDQojMTwvZm9udD48L2ZvbnQ+PC9mb250 PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5z IE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5MYXNlcmpldA0KU2VyaWVz IDRMLCA0UCZuYnNwOzwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRk Pg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5 OSI+PGZvbnQgDQpzaXplPSsxPiZuYnNwOzkyMjc0QTwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2Vu dGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48 Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT4kNDQ8L2ZvbnQ+PC9mb250PjwvZm9u dD48L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0KDQo8dHI+DQo8dGQgQkdDT0xPUj0iI0ZGRkZDQyI+ DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5 Ij48Zm9udCBzaXplPSsxPkl0ZW0NCiMyPC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8 L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNv bG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkxhc2VyamV0DQpTZXJpZXMgMTEwMCwzMjAwPC9m b250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250 IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCANCnNpemU9 KzE+Jm5ic3A7QzQwOTI8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0 ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAw OTkiPjxmb250IA0Kc2l6ZT0rMT4mbmJzcDskNDQ8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRl cj4NCjwvdGQ+DQo8L3RyPg0KDQo8dHI+DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWlj IFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkl0ZW0NCiMzPC9m b250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250 IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsx PiZuYnNwO0xhc2VyamV0DQpTZXJpZXMmbmJzcDsgMjwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2Vu dGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48 Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT4mbmJzcDsNCjkyMjk1QTwvZm9udD48 L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNl PSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT4mbmJz cDsNCiQ0OTwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQoNCjx0 cj4NCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9 IiMwMDAwOTkiPjxmb250IHNpemU9KzE+Jm5ic3A7SXRlbQ0KIyA0PC9mb250PjwvZm9udD48L2Zv bnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQgV0lEVEg9IjcwJSI+DQo8Y2VudGVyPjxmb250IGZh Y2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPiZu YnNwO0xhc2VyamV0DQpTZXJpZXMmbmJzcDsgMlA8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRl cj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZv bnQgY29sb3I9IiMwMDAwOTkiPjxmb250IA0Kc2l6ZT0rMT4mbmJzcDs5MjI3NUE8L2ZvbnQ+PC9m b250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0i Q29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+Jm5ic3A7 DQokNTQ8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0KDQo8dHI+ DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIj MDAwMDk5Ij48Zm9udCBzaXplPSsxPiZuYnNwO0l0ZW0NCiM1PC9mb250PjwvZm9udD48L2ZvbnQ+ PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMg TVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPiZuYnNwO0xhc2VyamV0DQpT ZXJpZXMgNVAsNlAsIDVNUCwgNk1QPC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3Rk Pg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9y PSIjMDAwMDk5Ij48Zm9udCANCnNpemU9KzE+Jm5ic3A7MzYwM0E8L2ZvbnQ+PC9mb250PjwvZm9u dD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2Fu cyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IA0Kc2l6ZT0rMT4mbmJzcDskNDQ8L2Zv bnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0KDQo8dHI+DQo8dGQ+DQo8 Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48 Zm9udCBzaXplPSsxPkl0ZW0NCiM2PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3Rk Pg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9y PSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPiZuYnNwO0xhc2VyamV0DQpTZXJpZXMgNVNJLDgwMDA8 L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZv bnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IA0Kc2l6 ZT0rMT4mbmJzcDszOTA5QTwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0K PHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAw MDA5OSI+PGZvbnQgc2l6ZT0rMT4kOTU8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwv dGQ+DQo8L3RyPg0KDQo8dHI+DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMg TVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPiZuYnNwO0l0ZW0NCiM3Jm5i c3A7PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVy Pjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBz aXplPSsxPiZuYnNwO0xhc2VyamV0DQpTZXJpZXMgMjEwMCwgMjIwMCZuYnNwOzwvZm9udD48L2Zv bnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJD b21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgDQpzaXplPSsxPiZuYnNw O0M0MDk2PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2Vu dGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9u dCANCnNpemU9KzE+Jm5ic3A7JDc0PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3Rk Pg0KPC90cj4NCg0KPHRyPg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1T Ij48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT4mbmJzcDtJdGVtDQojODwvZm9u dD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBm YWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT4m bmJzcDtMYXNlcmpldA0KU2VyaWVzIDgxMDA8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4N CjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQg Y29sb3I9IiMwMDAwOTkiPjxmb250IA0Kc2l6ZT0rMT4mbmJzcDtDNDE4MjwvZm9udD48L2ZvbnQ+ PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21p YyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgDQpzaXplPSsxPiZuYnNwOyQx MTU8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0KDQo8dHI+DQo8 dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAw MDk5Ij48Zm9udCBzaXplPSsxPiZuYnNwO0l0ZW0NCiM5PC9mb250PjwvZm9udD48L2ZvbnQ+PC9j ZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMi Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkxhc2VyamV0DQpTZXJpZXMgNUwv Nkw8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+ PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IA0K c2l6ZT0rMT4mbmJzcDszOTA2QTwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4N Cg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0i IzAwMDA5OSI+PGZvbnQgDQpzaXplPSsxPiZuYnNwOyQzOTwvZm9udD48L2ZvbnQ+PC9mb250Pjwv Y2VudGVyPg0KPC90ZD4NCjwvdHI+DQoNCjx0cj4NCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0i Q29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+Jm5ic3A7 SXRlbQ0KIzEwJm5ic3A7PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8 dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAw MDk5Ij48Zm9udCBzaXplPSsxPkxhc2VyamV0DQpTZXJpZXMmbmJzcDsgNFY8L2ZvbnQ+PC9mb250 PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29t aWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IA0Kc2l6ZT0rMT5DMzkwMCZu YnNwOzwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRl cj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQg DQpzaXplPSsxPiZuYnNwOyQ5NTwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4N CjwvdHI+DQoNCjx0cj4NCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+ PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+Jm5ic3A7SXRlbQ0KIzExPC9mb250 PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZh Y2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkxh c2VyamV0DQpTZXJpZXMgNDAwMDwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4N Cg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0i IzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5DNDEyN1g8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRl cj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZv bnQgY29sb3I9IiMwMDAwOTkiPjxmb250IA0Kc2l6ZT0rMT4mbmJzcDskNzk8L2ZvbnQ+PC9mb250 PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0KDQo8dHI+DQo8dGQ+DQo8Y2VudGVyPjxm b250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXpl PSsxPiZuYnNwO0l0ZW0NCiMxMjwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4N Cg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0i IzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5MYXNlcmpldA0KU2VyaWVzIDNTSS80U0k8L2ZvbnQ+PC9m b250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0i Q29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IA0Kc2l6ZT0rMT4mbmJz cDs5MjI5MUEmbmJzcDs8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0 ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAw OTkiPjxmb250IHNpemU9KzE+JDU0PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3Rk Pg0KPC90cj4NCg0KPHRyPg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1T Ij48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT4mbmJzcDtJdGVtDQojMTM8L2Zv bnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQg ZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+ TGFzZXJqZXQNClNlcmllcyA0LDRNLDUsNU0mbmJzcDs8L2ZvbnQ+PC9mb250PjwvZm9udD48L2Nl bnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+ PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+OTIyOThBPC9mb250PjwvZm9udD48 L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWlj IFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPiQ0OTwvZm9udD48 L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQoNCjx0cj4NCjx0ZD4NCjxjZW50 ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250 IHNpemU9KzE+Jm5ic3A7SXRlbQ0KIzEzQTwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0K PC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBj b2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5MYXNlcmpldA0KU2VyaWVzIDUwMDA8L2ZvbnQ+ PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFj ZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+QzQx MjlYPC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVy Pjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBz aXplPSsxPiQxMjU8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0K DQo8dHI+DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNv bG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPiZuYnNwO0l0ZW0NCiMxM0I8L2ZvbnQ+PC9mb250 PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29t aWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+TGFzZXJqZXQN ClNlcmllcyAxMjAwPC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+ DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5 Ij48Zm9udCBzaXplPSsxPkM3MTE1QTwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90 ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xv cj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT4kNTk8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRl cj4NCjwvdGQ+DQo8L3RyPg0KDQo8dHI+DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWlj IFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPiZuYnNwO0l0ZW0N CiMxM0M8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50 ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250 IHNpemU9KzE+TGFzZXJqZXQNClNlcmllcyA0MTAwPC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50 ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxm b250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkM4MDYxWDwvZm9udD48L2ZvbnQ+PC9m b250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBT YW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT4kOTk8L2ZvbnQ+PC9m b250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0KDQo8dHI+DQo8dGQ+DQo8Y2VudGVy Pjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBz aXplPSsxPiZuYnNwO0l0ZW0NCiMxODwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90 ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xv cj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5MYXNlcmpldA0KU2VyaWVzJm5ic3A7IDMxMDA8L2Zv bnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQg ZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+ MzkwNkE8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50 ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250 IHNpemU9KzE+JDM5PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KPC90cj4N Cg0KPHRyPg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBj b2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT4mbmJzcDtJdGVtDQojMTk8L2ZvbnQ+PC9mb250 PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29t aWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+TGFzZXJqZXQN ClNlcmllcyA0NTAwIEJsYWNrPC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0K DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIj MDAwMDk5Ij48Zm9udCANCnNpemU9KzE+QzQxOTEmbmJzcDs8L2ZvbnQ+PC9mb250PjwvZm9udD48 L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBN UyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+JDY5PC9mb250PjwvZm9udD48 L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KPC90cj4NCg0KPHRyPg0KPHRkPg0KPGNlbnRlcj48Zm9u dCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0r MT4mbmJzcDtJdGVtDQojMjA8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoN Cjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMw MDAwOTkiPjxmb250IHNpemU9KzE+TGFzZXJqZXQNClNlcmllcyA0NTAwIENvbG9yPC9mb250Pjwv Zm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9 IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkNBTEw8 L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZv bnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9 KzE+JDg5PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KPC90cj4NCjwvdGFi bGU+PC9jZW50ZXI+DQoNCjxjZW50ZXI+PHByZT48dT48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1T Ij48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMj5Gb3IgSGV3bGV0dCBQYWNrYXJk IEZheDogKFBhZ2UgDQoyKTwvZm9udD48L2ZvbnQ+PC9mb250PjwvdT48L3ByZT48L2NlbnRlcj4N Cg0KPGNlbnRlcj48dGFibGUgQk9SREVSIFdJRFRIPSI4MCUiIEhFSUdIVD0iMTAlIiBCR0NPTE9S PSIjRkZGRkNDIiA+DQo8dHIgQUxJR049Q0VOVEVSIEJHQ09MT1I9IiM0MDgwODAiPg0KPHRkPg0K PGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iI0ZGRkZGRiI+ PGZvbnQgc2l6ZT0rMT5JVEVNPC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0K DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIj RkZGRkZGIj48Zm9udCANCnNpemU9KzE+REVTQ1JJUFRJT048L2ZvbnQ+PC9mb250PjwvZm9udD48 L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBN UyI+PGZvbnQgY29sb3I9IiNGRkZGRkYiPjxmb250IHNpemU9KzE+TUZHDQojPC9mb250PjwvZm9u dD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNv bWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjRkZGRkZGIj48Zm9udCBzaXplPSsxPlBSSUNFPC9m b250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KPC90cj4NCg0KPHRyPg0KPHRkPg0K PGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+ PGZvbnQgc2l6ZT0rMT5JdGVtDQojIDE0PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8 L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNv bG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkxlc2VyZmF4DQo1MDAsIDcwMDwvZm9udD48L2Zv bnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJD b21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5GWDE8L2Zv bnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQg ZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+ JDU5PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KPC90cj4NCg0KPHRyPg0K PHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAw MDA5OSI+PGZvbnQgc2l6ZT0rMT5JdGVtDQojIDE1PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50 ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxm b250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkxhc2VyZmF4DQo1MDAwLCA3MDAwPC9m b250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250 IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsx PkZYMjwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRl cj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQg c2l6ZT0rMT4kNjQ8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0K DQo8dHI+DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNv bG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkl0ZW0NCiMgMTY8L2ZvbnQ+PC9mb250PjwvZm9u dD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2Fu cyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+TGFzZXJmYXgNCjYwMDA8 L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZv bnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9 KzE+RlgzPC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2Vu dGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9u dCBzaXplPSsxPiQ1OTwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+ DQoNCjx0cj4NCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQg Y29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+SXRlbQ0KIzE3PC9mb250PjwvZm9udD48L2Zv bnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNh bnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkxhc2VyZmF4DQo4NTAw LCA5MDAwPC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2Vu dGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9u dCBzaXplPSsxPkZYNDwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRk Pg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5 OSI+PGZvbnQgc2l6ZT0rMT4kNTQ8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+ DQo8L3RyPg0KDQo8dHI+DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMi Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkl0ZW0NCiMxODwvZm9udD48L2Zv bnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJD b21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5MYXNlcmZh eA0KMzIwMDwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNl bnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZv bnQgc2l6ZT0rMT4zOTA2QTwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0K PHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAw MDA5OSI+PGZvbnQgc2l6ZT0rMT4kNDQ8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwv dGQ+DQo8L3RyPg0KPC90YWJsZT48L2NlbnRlcj4NCg0KPGNlbnRlcj4NCjxwPjx1Pjxmb250IGZh Y2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsyPkZv cg0KTGV4bWFyayAvIElCTSBNYWNoaW5lczo8aT4gKG9uIFBhZ2UgMyk8L2k+PC9mb250PjwvZm9u dD48L2ZvbnQ+PC91PjwvY2VudGVyPg0KDQo8Y2VudGVyPjx0YWJsZSBCT1JERVIgV0lEVEg9Ijgw JSIgSEVJR0hUPSIxOSUiIEJHQ09MT1I9IiNGRkZGQ0MiID4NCjx0ciBCR0NPTE9SPSIjNDA4MDgw Ij4NCjx0ZD4NCjxjZW50ZXI+PGZvbnQgY29sb3I9IiNGRkZGRkYiPjxiPjxmb250IGZhY2U9IkJv b2ttYW4gT2xkIFN0eWxlIj4mbmJzcDs8L2ZvbnQ+PC9iPjxmb250IGZhY2U9IkNvbWljIFNhbnMg DQpNUyI+PGZvbnQgc2l6ZT0rMT5JVEVNPC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8 L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNv bG9yPSIjRkZGRkZGIj48Zm9udCANCnNpemU9KzE+REVTQ1JJUFRJT048L2ZvbnQ+PC9mb250Pjwv Zm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMg U2FucyBNUyI+PGZvbnQgY29sb3I9IiNGRkZGRkYiPjxmb250IHNpemU9KzE+TUZHDQojPC9mb250 PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZh Y2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjRkZGRkZGIj48Zm9udCBzaXplPSsxPlBS SUNFPC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KPC90cj4NCg0KPHRyPg0K PHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAw MDA5OSI+PGZvbnQgc2l6ZT0rMT5JdGVtDQojMTwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVy Pg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5JQk0NCjQwMTkvNDAyOSZuYnNwOzwvZm9u dD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBm YWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgDQpzaXplPSsx PjEzODAyMDAmbmJzcDs8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0 ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAw OTkiPjxmb250IHNpemU9KzE+JDk1PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3Rk Pg0KPC90cj4NCg0KPHRyPg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1T Ij48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5JdGVtDQojMjwvZm9udD48L2Zv bnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJD b21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5PcHRyYQ0K Uiw0MDM5LCA0MDQ5PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+ DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5 Ij48Zm9udCBzaXplPSsxPjEzODIxNTA8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwv dGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29s b3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+JDExNzwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2Vu dGVyPg0KPC90ZD4NCjwvdHI+DQoNCjx0cj4NCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29t aWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+SXRlbQ0KIzM8 L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZv bnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9 KzE+T3B0cmENCkUzMTAsIEUzMTI8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+ DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9 IiMwMDAwOTkiPjxmb250IA0Kc2l6ZT0rMT4mbmJzcDsxMkEyMjAyPC9mb250PjwvZm9udD48L2Zv bnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNh bnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPiQ4OTwvZm9udD48L2Zv bnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQoNCjx0cj4NCjx0ZD4NCjxjZW50ZXI+ PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNp emU9KzE+SXRlbQ0KIzQ8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0 ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAw OTkiPjxmb250IHNpemU9KzE+T3B0cmENCkU8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4N CjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQg Y29sb3I9IiMwMDAwOTkiPjxmb250IA0Kc2l6ZT0rMT4mbmJzcDs2OUc4MjU2Jm5ic3A7PC9mb250 PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZh Y2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPiQ1 OTwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQoNCjx0cj4NCjx0 ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAw OTkiPjxmb250IHNpemU9KzE+SXRlbQ0KIzU8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4N CjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQg Y29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+T3B0cmENClM8L2ZvbnQ+PC9mb250PjwvZm9u dD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2Fu cyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IA0Kc2l6ZT0rMT4mbmJzcDsxMzgyNjI1 Jm5ic3A7PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2Vu dGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9u dCBzaXplPSsxPiQxMzU8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQo8L3Ry Pg0KDQo8dHI+DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250 IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkl0ZW0NCiM2PC9mb250PjwvZm9udD48L2Zv bnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNh bnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPk9wdHJhDQpUPC9mb250 PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZh Y2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPiZu YnNwOw0KMTJBNTg0MDwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRk Pg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5 OSI+PGZvbnQgc2l6ZT0rMT4kMTY1PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3Rk Pg0KPC90cj4NCg0KPHRyPg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1T Ij48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5JdGVtDQojNzwvZm9udD48L2Zv bnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJD b21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5PcHRyYQ0K RTQxMC80MTI8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxj ZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxm b250IHNpemU9KzE+Jm5ic3A7DQo0SzAwMTk4Jm5ic3A7PC9mb250PjwvZm9udD48L2ZvbnQ+PC9j ZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMi Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPiQxMTU8L2ZvbnQ+PC9mb250Pjwv Zm9udD48L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0KPC90YWJsZT48L2NlbnRlcj4NCg0KPGNlbnRl cj4NCjxwPjx1Pjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5 Ij48Zm9udCBzaXplPSsyPkZvcg0KQXBwbGUgUHJpbnRlcnM6PGk+IChvbiBQYWdlIDgpPC9pPjwv Zm9udD48L2ZvbnQ+PC9mb250PjwvdT48L2NlbnRlcj4NCg0KPGNlbnRlcj48dGFibGUgQk9SREVS IFdJRFRIPSI4MCUiIEhFSUdIVD0iMTAlIiBCR0NPTE9SPSIjRkZGRkNDIiA+DQo8dHIgQUxJR049 TEVGVCBCR0NPTE9SPSIjNDA4MDgwIj4NCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMg U2FucyBNUyI+PGZvbnQgY29sb3I9IiNGRkZGRkYiPjxmb250IHNpemU9KzE+SVRFTTwvZm9udD48 L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNl PSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iI0ZGRkZGRiI+PGZvbnQgDQpzaXplPSsxPkRF U0NSSVBUSU9OPC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8 Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjRkZGRkZGIj48 Zm9udCBzaXplPSsxPk1GRyM8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoN Cjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiNG RkZGRkYiPjxmb250IHNpemU9KzE+UFJJQ0U8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4N CjwvdGQ+DQo8L3RyPg0KDQo8dHI+DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNh bnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkl0ZW0mbmJzcDsNCiMx PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxm b250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXpl PSsxPlBlcnNvbmFsDQpMYXNlcldyaXRlcjwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0K PC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBj b2xvcj0iIzAwMDA5OSI+PGZvbnQgDQpzaXplPSsxPk0wMDg5TExBPC9mb250PjwvZm9udD48L2Zv bnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNh bnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPiQ1NDwvZm9udD48L2Zv bnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQoNCjx0cj4NCjx0ZD4NCjxjZW50ZXI+ PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNp emU9KzE+SXRlbQ0KIzI8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0 ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAw OTkiPjxmb250IHNpemU9KzE+TGFzZXJXcml0ZXINCjMwMFBYLyAzMjAtNEwsKzRNTDwvZm9udD48 L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNl PSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgDQpzaXplPSsxPk0y MDQ1R0E8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50 ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250 IHNpemU9KzE+JDU0PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KPC90cj4N Cg0KPHRyPg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBj b2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5JdGVtDQojMzwvZm9udD48L2ZvbnQ+PC9mb250 PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5z IE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5MYXNlcldyaXRlcg0KU2Vs ZWN0IDM2MDwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNl bnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZv bnQgDQpzaXplPSsxPk0xOTYwR0E8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+ DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9 IiMwMDAwOTkiPjxmb250IHNpemU9KzE+JDc0PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+ DQo8L3RkPg0KPC90cj4NCg0KPHRyPg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBT YW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5JdGVtDQojNDwvZm9u dD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBm YWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5M YXNlcldyaXRlcg0KMTYvIDYwMCBQcm8mbmJzcDs8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRl cj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZv bnQgY29sb3I9IiMwMDAwOTkiPjxmb250IA0Kc2l6ZT0rMT5NMjQ3M0dBPC9mb250PjwvZm9udD48 L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWlj IFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPiQ1OTwvZm9udD48 L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQoNCjx0cj4NCjx0ZD4NCjxjZW50 ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250 IHNpemU9KzE+SXRlbQ0KIzU8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoN Cjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMw MDAwOTkiPjxmb250IHNpemU9KzE+TGFzZXJXcml0ZXINCjEyLyA2NDAgUFM8L2ZvbnQ+PC9mb250 PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29t aWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IA0Kc2l6ZT0rMT5NNDY4M0dB Jm5ic3A7PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2Vu dGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9u dCBzaXplPSsxPiQ4OTwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+ DQoNCjx0cj4NCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQg Y29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+SXRlbQ0KIzY8L2ZvbnQ+PC9mb250PjwvZm9u dD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2Fu cyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+TGFzZXINCldyaXRlciBO VC8yTlQ8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50 ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250 IA0Kc2l6ZT0rMT5NNDUzMkdBPC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0K DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIj MDAwMDk5Ij48Zm9udCBzaXplPSsxPiQ0OTwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0K PC90ZD4NCjwvdHI+DQo8L3RhYmxlPjwvY2VudGVyPg0KDQo8Y2VudGVyPg0KPHA+PGZvbnQgZmFj ZT0iQ29taWMgU2FucyBNUyI+Jm5ic3A7PHU+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNp emU9KzI+Rm9yDQpDYW5ub24gQ29waWVyczogKFBhZ2UgMTApPC9mb250PjwvZm9udD48L3U+PC9m b250PjwvY2VudGVyPg0KDQo8cD48YnI+DQo8Y2VudGVyPjx0YWJsZSBCT1JERVIgV0lEVEg9Ijgw JSIgSEVJR0hUPSIxMCUiIEJHQ09MT1I9IiNGRkZGQ0MiID4NCjx0ciBCR0NPTE9SPSIjNDA4MDgw Ij4NCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9 IiNGRkZGRkYiPjxmb250IHNpemU9KzE+SVRFTTwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVy Pg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9u dCBjb2xvcj0iI0ZGRkZGRiI+PGZvbnQgDQpzaXplPSsxPkRFU0NSSVBUSU9OPC9mb250PjwvZm9u dD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNv bWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjRkZGRkZGIj48Zm9udCBzaXplPSsxPk1GRw0KIzwv Zm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9u dCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iI0ZGRkZGRiI+PGZvbnQgc2l6ZT0r MT5QUklDRTwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQoNCjx0 cj4NCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9 IiMwMDAwOTkiPjxmb250IHNpemU9KzE+SXRlbQ0KIyAxPC9mb250PjwvZm9udD48L2ZvbnQ+PC9j ZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMi Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPlBDDQo2LyA2UkUvIDcvIDgvIDEx LyAxMi8gNjU8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxj ZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxm b250IA0Kc2l6ZT0rMT4mbmJzcDtBMzAmbmJzcDs8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRl cj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZv bnQgY29sb3I9IiMwMDAwOTkiPjxmb250IHNpemU9KzE+JDY5PC9mb250PjwvZm9udD48L2ZvbnQ+ PC9jZW50ZXI+DQo8L3RkPg0KPC90cj4NCg0KPHRyPg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNl PSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5JdGVt DQojIDI8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50 ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250 IHNpemU9KzE+UEMNCjMwMC8zMjAvMzQwLzM2MCZuYnNwOyBBbGwgMzAwIFNlcmllczwvZm9udD48 L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNl PSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgDQpzaXplPSsxPiZu YnNwO0U0MCZuYnNwOzwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRk Pg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5 OSI+PGZvbnQgc2l6ZT0rMT4kODk8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+ DQo8L3RyPg0KDQo8dHI+DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMi Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkl0ZW0NCiMzPC9mb250PjwvZm9u dD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNv bWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPlBDDQo3MDAv NzIwLzc2MCZuYnNwOyBBbGwgNzAwIFNlcmllczwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVy Pg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgDQpzaXplPSsxPiZuYnNwO0U0MCZuYnNwOzwvZm9udD48 L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNl PSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT4kODk8 L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0KDQo8dHI+DQo8dGQ+ DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5 Ij48Zm9udCBzaXplPSsxPkl0ZW0NCiM0PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8 L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNv bG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPlBDDQo5MDAvOTEwLzkyMCZuYnNwOyBBbGwgOTAw IFNlcmllczwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNl bnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZv bnQgDQpzaXplPSsxPiZuYnNwO0U0MCZuYnNwOzwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVy Pg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT4kODk8L2ZvbnQ+PC9mb250PjwvZm9udD48 L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0KPC90YWJsZT48L2NlbnRlcj4NCg0KPGNlbnRlcj4NCjxw Pjx1Pjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9u dCBzaXplPSsyPkZvcg0KRXBzb24gYW5kIFBhbmFzb25pYyBQcmludGVyczoob24gUGFnZXMgNCAm YW1wOyA3KTwvZm9udD48L2ZvbnQ+PC9mb250PjwvdT48L2NlbnRlcj4NCg0KPHA+PGJyPg0KPGNl bnRlcj48dGFibGUgQk9SREVSIFdJRFRIPSI4MCUiIEhFSUdIVD0iMTAlIiBCR0NPTE9SPSIjRkZG RkNDIiA+DQo8dHIgQkdDT0xPUj0iIzQwODA4MCI+DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9 IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjRkZGRkZGIj5JVEVNPC9mb250PjwvZm9udD48 L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBN UyI+Jm5ic3A7PGZvbnQgY29sb3I9IiNGRkZGRkYiPkRFU0NSSVBUSU9OPC9mb250PjwvZm9udD48 L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBN UyI+PGZvbnQgY29sb3I9IiNGRkZGRkYiPk1GRyAjPC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwv dGQ+DQoNCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29s b3I9IiNGRkZGRkYiPlBSSUNFPC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0K DQo8dHI+DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNv bG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkl0ZW0NCiMgMTwvZm9udD48L2ZvbnQ+PC9mb250 PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5z IE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5FcHNvbg0KMTAwMC8xNTAw PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxm b250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCANCnNp emU9KzE+UzA1MTAxMSZuYnNwOzwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4N Cg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0i IzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT4kMTA1PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+ DQo8L3RkPg0KPC90cj4NCg0KPHRyPg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBT YW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT5JdGVtDQojMiZuYnNw OzwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48 Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6 ZT0rMT5FcHNvbg0KRVBMNzAwMC84MDAwJm5ic3A7PC9mb250PjwvZm9udD48L2ZvbnQ+PC9jZW50 ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxm b250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCANCnNpemU9KzE+UzA1MTIwMCZuYnNwOzwvZm9udD48 L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNl PSJDb21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+PGZvbnQgDQpzaXplPSsxPiQx MDUmbmJzcDs8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0KDQo8 dHI+DQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9y PSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPkl0ZW0NCiMzPC9mb250PjwvZm9udD48L2ZvbnQ+PC9j ZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMi Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij48Zm9udCBzaXplPSsxPlBhbmFzb25pYw0KOTAvOTUmbmJz cDs8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+ PGZvbnQgZmFjZT0iQ29taWMgU2FucyBNUyI+PGZvbnQgY29sb3I9IiMwMDAwOTkiPjxmb250IA0K c2l6ZT0rMT4tLS0tLS0tLS0tLS0tLS0tPjwvZm9udD48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0K PC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48Zm9udCBj b2xvcj0iIzAwMDA5OSI+PGZvbnQgc2l6ZT0rMT4kMTA1PC9mb250PjwvZm9udD48L2ZvbnQ+PC9j ZW50ZXI+DQo8L3RkPg0KPC90cj4NCjwvdGFibGU+PC9jZW50ZXI+DQoNCjxjZW50ZXI+DQo8cD48 Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj48dT48Zm9udCBzaXplPSszPlNvcnJ5LDwvZm9udD48 L3U+PGZvbnQgc2l6ZT0rMj4mbmJzcDsNClN0aWxsIG5vIElua2pldHMsIGJ1YmJsZSBqZXRzIG9y IFhlcm94IGluIHN0b2NrPC9mb250PjwvZm9udD4NCjxicj4mbmJzcDsNCjxwPjxpPjxmb250IGZh Y2U9IkNvbWljIFNhbnMgTVMiPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSs0PkhB VkUNCkEgPHU+R1JFQVQgPC91PkRBWSAhISEmbmJzcDsgTE9PSyZuYnNwOyBGT1JXQVJEIFRPIEhF QVJJTkcgRlJPTSANCllPVTwvZm9udD48L2ZvbnQ+PC9mb250PjwvaT48aT48Zm9udCBmYWNlPSJD b21pYyBTYW5zIE1TIj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgDQpzaXplPSs0PjwvZm9u dD48L2ZvbnQ+PC9mb250PjwvaT4NCjxwPjxiPjx1PkRJU0NMQUlNRVJTOjwvdT48L2I+DQo8cD4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQWxsIHRyYWRlbWFya3MsIGJyYW5kIG5hbWVzIGFuZCBk aWFncmFtcyBsaXN0ZWQNCm9yIHNob3duIGFib3ZlDQo8YnI+YXJlIHByb3BlcnR5IG9mIHRoZWly IHJlc3BlY3RpdmUgaG9sZGVycyZuYnNwOyZuYnNwOyBhbmQgdXNlZCBmb3IgZGVzY3JpcHRpdmUN CnB1cnBvc2VzIG9ubHkNCjxicj4uV2UgZG8gbm90IGNhcnJ5IGFueSBIUCBvZW0gcHJvZHVjdHMu IC4NCjxwPjxmb250IGZhY2U9IkNvbWljIFNhbnMgTVMiPjx1Pk5PVEVTPC91Pjo8L2ZvbnQ+DQo8 YnI+VW5pdmVyc2l0eSBhbmQgU2Nob29sIFB1cmNoYXNlIG9yZGVycyB3ZWxjb21lLiAoTm8gQ3Jl ZGl0IGFwcHJvdmFsDQpyZXF1aXJlZC4gQWxsIG90aGVyIFB1cmNoYXNlDQo8YnI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IG9yZGVycyByZXF1aXJlIGNyZWRpdCBhcHByb3ZhbA0KPGJyPiZuYnNwO1BheSBi eSBjaGVjayAoQy5PLkQuKSwgQ3JlZGl0IGNhcmQgb3IgcHVyY2hhc2Ugb3JkZXIgKE5ldCAzMA0K RGF5cykNCjxicj5TaGlwcGluZyBjaGFyZ2VzIHN0YXJ0IGF0ICQ0LjUgcGVyIGNhcnRyaWRnZS4g QWRkICQxLjUgZm9yIGVhY2ggYWRkaXRpb25hbA0KY2FydHJpZGdlLiBDYXJ0cmlkZ2VzDQo8YnI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlbGl2ZXJlZCBieSBGZWRlcmFsIEV4cHJlc3Mgd2l0aGluIDIg dG8gNSB3b3JraW5nDQpkYXlzIGRlcGVuZGluZyBvbiB5b3VyIGxvY2F0aW9uLg0KPGJyPlNoaXBw aW5nIGFuZCBiaWxsaW5nIGFkZHJlc3NlcyBhcmUgcmVxdWlyZWQgZm9yIFB1cmNoYXNlIE9yZGVy IHRyYW5zYWN0aW9ucy4NCllvdXIgaW52b2ljZSB3aWxsDQo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGJlIGF0dGFjaGVkIHRvIHlvdXIgcGFja2FnaW5nLiBQbGVhc2UgcGVhbCBhbmQgcGF5DQp3aXRo aW4gMzAgZGF5cy4NCjxicj4zMCBkYXkgc3RhbmRhcmQgcmV0dXJuIHBvbGljeSAobW9uZXkgYmFj ayBndWFyYW50ZWUpIG9uIGFsbCBtZXJjaGFuZGlzZS4NCjkwIGRheSB1bmxpbWl0ZWQgZXhjaGFu Z2UgcG9saWN5DQo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvciBkZWZlY3RpdmUgbWVyY2hhbmRp c2U8Zm9udCBmYWNlPSJDb21pYyBTYW5zIE1TIj4uPC9mb250Pg0KPHA+PHU+RVhDTFVTSU9OUzo8 L3U+DQo8cD48dT5XZSBkbyBub3QgY2Fycnk6PC91Pg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFhlcm94LCBCcm90aGVyLCBQYW5hc29uaWMsIG9yIEZ1aml0c3UgUHJvZHVjdHMNCjxicj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGVza2pldC9JbmtqZXQgb3IgQnViYmxlamV0IHByb2R1 Y3RzDQo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFueSBPZmZicmFuZHMgYmVzaWRlcyB0 aGUgb25lcyBsaXN0ZWQgYWJvdmUuDQpBbGwgY2FydHJpZGdlcw0KPGJyPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcmUgY29tcGF0aWJsZQ0K aGlnaCB5aWVsZCBwcm9kdWN0cy48L2NlbnRlcj4NCg0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0K PGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZuYnNw Ow0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZu YnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJy PiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0KPGJyPiZuYnNwOw0K PGJyPiZuYnNwOw0KPGRsPg0KPGR0Pg0KPC9kdD4NCjwvZGw+DQoNCjxicj4mbmJzcDsNCjxicj4m bmJzcDsNCjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjxi cj4mbmJzcDsNCjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjwvYm9keT4NCjwv aHRtbD4NCg== ------=_NextPart_000_00D1_12G23J4K.L1454P76-- From pana-request@research.telcordia.com Sat Apr 13 02:29:52 2002 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 CAA21666 for ; Sat, 13 Apr 2002 02:29:33 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3D6P17O002582; Sat, 13 Apr 2002 02:25:01 -0400 (EDT) Resent-Date: Sat, 13 Apr 2002 02:25:01 -0400 (EDT) Old-Return-Path: Message-ID: <20020413062447.80166.qmail@web20401.mail.yahoo.com> Date: Fri, 12 Apr 2002 23:24:47 -0700 (PDT) From: Reinaldo Penno Subject: Re: Location of authentication agent To: subir Das , John Vollbrecht Cc: "Hesham Soliman \(ERA\)" , "'Alper E. YEGIN'" , pana@research.telcordia.com In-Reply-To: <3CB75052.B2532AEA@research.telcordia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <4H-dy.A.Oo.988t8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Limited free access or "walled garden scenarios". Walled garden (or isles of content) where you actually pay for premium content that reside on a specific subnet/network. A separate PAA controls these types of accesses through several PEPs. Now, even if the PAA was co-located with one PEP, it would be remote to the other that controls access to the other island of content. regards, Reinaldo --- subir Das wrote: > > John, > > > For example - are you thinking of something like > this? > > > > client ------- edge device/ enforcement point > --------- Pana Agent > > -------- Pana Server > > I would prefer following for limited free access: > > PANA Agent > -----------------PANA > Server > | > Client ------ edge device -------- enforcement > point > > > Thanks, > > > Subir > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From pana-request@research.telcordia.com Mon Apr 15 03:45:28 2002 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 DAA08912 for ; Mon, 15 Apr 2002 03:45:13 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3F7cEDO026087; Mon, 15 Apr 2002 03:38:14 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 03:38:14 -0400 (EDT) Old-Return-Path: Message-Id: <200204150738.g3F7cAKW026066@thumper.research.telcordia.com> From: "Adam Erickson" To: Subject: Resume Writing and Distribution Sender: "Adam Erickson" Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Mon, 15 Apr 2002 03:38:36 -0400 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Dear Job Seeker,


How can we help you find your DREAM JOB?

Resume Author.com is an established resume writing and distribution firm that specializes in custom-tailored career development. We have a dedicated staff of resume writers and an Opt-In E-mail Distribution Network of over 19,000 recruiters and employers (We can have your professional resume in their hands in a matter of minutes).

We're so confident in the effectiveness of our services that we guarantee job interviews!!!

Learn more about the most effective career marketing services available.

Resume Writing & Editing Services Click Here
Starting at only 79.95

E-mail Resume Distribution Services Click Here
Starting at only 29.95


Best Regards,

Adam Erickson
Client Development,
Resume Author


Would you like to test our quality? We provide a FREE Resume Critique for all interested parties.




CONCERNED ABOUT JUNK MAIL? SO ARE WE.

As a ResumeAuthor.com Sales Representative, I believe you meet the criteria we look for in a resume writing and distribution customer. If, however, you feel that you have received this email in error, I apologize. We will comply with all removal requests. To be removed type "remove" in the subject line and MAIL TO:aerickson@resumeauthor.com this is the only way to be removed. Hitting reply will NOT remove you.

This message is sent in compliance of the new email bill section 301.Per Section 301, Paragraph (a)(2)(C) of S. 1618. From pana-request@research.telcordia.com Mon Apr 15 09:30:42 2002 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 JAA16836 for ; Mon, 15 Apr 2002 09:30:42 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FDOUkQ020281; Mon, 15 Apr 2002 09:24:30 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 09:24:30 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC68@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Alper E. YEGIN'" , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Mon, 15 Apr 2002 15:21:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Alper, > > => More than the ones in the scenarios draft? > > Namely: Load sharing, limited free access and > > payment after a certain point..etc > > We should look closer at these scenarios. > > For example, in limited free access and payment after a certain > point scenario, where would you put the authentication agent? It'd > be good to take a look at the model and required interactions among > protocol entities. => I would assume that you would put it at the border of the 'free'/'don't care' zone. But this was intentionally removed from the draft. We can certainly (and we should) discuss it on the mailing list, but I hope we don't do a full circle and include solutions in the draft again. > While this scenario can be supported by separation of > authentication agent > from the enforcement point, does it really need that? Or > can we achive the > same when two are co-located? What component of this > scenario requires > the separation? => Well, it depends on which case you refer to. In the load sharing case you need to separate the access enforcement from the authentication, otherwise you need to authenticate twice (unless there is some protocol running between the default routers). I don't know if someone has a better idea on how to do this. Of course the other question is: Why does it matter? That is, what is the cost incurred in separating the 2 entities and running SNMP/COPS/midcom ...etc between them ? I like to think of it as starting from the most flexible solution, then trading flexibility for cost. There were concerns raised during the meeting about the 'extra cost' associated with this separation, but I didn't get a clear idea about where this cost would come from. So maybe now is a good time to discuss this. Hesham From pana-request@research.telcordia.com Mon Apr 15 11:32:52 2002 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 LAA20553 for ; Mon, 15 Apr 2002 11:32:47 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FFPN1H003555; Mon, 15 Apr 2002 11:25:23 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 11:25:23 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC69@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , "Alper E. YEGIN" , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Mon, 15 Apr 2002 17:24:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com James, This separate protocol is already available everywhere. Is there any router that doesn't implenment SNMP for example? I don't understand the complication. Hesham > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Saturday, April 13, 2002 2:38 AM > To: Alper E. YEGIN; pana@research.telcordia.com > Subject: Re: Location of authentication agent > > > I question the value of separation, since it will require a separate > protocol to transmit the enforcement decisions between the > enforcement > point and the authentication agent. I have, as yet, not seen a > compelling need for complicating the traditional NAS architecture in > this manner. > > > jak > > ----- Original Message ----- > From: "Alper E. YEGIN" > To: > Sent: Thursday, April 11, 2002 6:12 PM > Subject: Location of authentication agent > > > > > > > The Authentication Agent can reside on any node in the > network that > can > > > send/receive IP datagrams (i.e., has an IP stack). The > Authentication > > > Agent and the Enforcement Point can be co-located (as > is the case > with > > > PPP and EAPOW), or be on separate nodes. PANA will identify a > transport > > > (e.g., AAA, SNMP, COPS, etc.) to carry access control > information > > > (such as filters) from the Authentication Agent to the > Enforcement > point > > > when these two entities are separated. > > > There are pros and cons associated with having the > authentication > > > agent beyond the first hop [NAS/AP/Rtr/etc.]. This is > an issue that > > > needs to be delved into by the WG. > > > > PANA provides the flexibility that the Authentication > Agent and the > > Enforcement Point can be co-located or separate. > Co-location is the > > model that is already used with the existing link-layer > authentication > > protocols. > > Separation looks like a good feature, yet it requires > using another > > transport between two. > > > > In order to better understand the value of separation, we > need to look > at > > some > > usage scenarios. Can people think of such scenarios? > > > > Comments please.. > > > > alper > > > > > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Mon Apr 15 12:03:23 2002 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 MAA21720 for ; Mon, 15 Apr 2002 12:03:14 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FFv2r7006987; Mon, 15 Apr 2002 11:57:02 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 11:57:02 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC6C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Mon, 15 Apr 2002 17:56:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > I still don't see any compelling need for complicating the > architecture. => There is no complication, this interface can be internal (most likely) within the NAS. Taking it on the wire is not that complex. > Why have two entities when one is sufficient? => It's not sufficient for the scenarios we discussed. Is there a solution that can satisfy the scenarios in the draft today? If so then there is no problem. What is the > application > that won't work with a traditional NAS-style architecture? => Have a look at the scenarios draft. You could question whether the scenarios are important enough, but there is no question that the scenarios exist and have been discussed when BURP started. Hesham From pana-request@research.telcordia.com Mon Apr 15 12:07:39 2002 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 MAA21936 for ; Mon, 15 Apr 2002 12:07:38 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FG5Qwi007912; Mon, 15 Apr 2002 12:05:26 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 12:05:26 -0400 (EDT) Old-Return-Path: Message-ID: <00b401c1e497$1a09a980$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "Alper E. YEGIN" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AC6C@Esealnt861.al.sw.ericsson.se> Subject: Re: Location of authentication agent Date: Mon, 15 Apr 2002 09:03:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > What is the > > application > > that won't work with a traditional NAS-style architecture? > > => Have a look at the scenarios draft. > You could question whether the scenarios are important > enough, but there is no question that the scenarios > exist and have been discussed when BURP started. > I've looked at the scenarios draft, and I don't find the arguments compelling. I will attempt to find the time to compose an email with a detailed description of why. jak From pana-request@research.telcordia.com Mon Apr 15 12:07:41 2002 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 MAA21948 for ; Mon, 15 Apr 2002 12:07:41 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FFs8bf006710; Mon, 15 Apr 2002 11:54:08 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 11:54:08 -0400 (EDT) Old-Return-Path: Message-ID: <008a01c1e495$5a096630$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "Alper E. YEGIN" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AC69@Esealnt861.al.sw.ericsson.se> Subject: Re: Location of authentication agent Date: Mon, 15 Apr 2002 08:51:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <6TiIgB.A.uoB.fevu8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > This separate protocol is already available > everywhere. Is there any router that > doesn't implenment SNMP for example? > I don't understand the complication. > I still don't see any compelling need for complicating the architecture. Why have two entities when one is sufficient? What is the application that won't work with a traditional NAS-style architecture? jak From pana-request@research.telcordia.com Mon Apr 15 12:09:08 2002 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 MAA22009 for ; Mon, 15 Apr 2002 12:09:07 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FG5tNV007966; Mon, 15 Apr 2002 12:05:55 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 12:05:55 -0400 (EDT) Old-Return-Path: Message-ID: <3CBAEE6E.ED4F5FB2@research.telcordia.com> Date: Mon, 15 Apr 2002 11:14:54 -0400 From: subir Das X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: "'Alper E. YEGIN'" , pana@research.telcordia.com Subject: Re: Location of authentication agent References: <4DA6EA82906FD511BE2F00508BCF053802C6AC68@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hesham, > > For example, in limited free access and payment after a certain > > point scenario, where would you put the authentication agent? It'd > > be good to take a look at the model and required interactions among > > protocol entities. > > => I would assume that you would put it at the border > of the 'free'/'don't care' zone. But this was intentionally > removed from the draft. We can certainly (and we should) > discuss it on the mailing list, but I hope we don't > do a full circle and include solutions in the > draft again. > > > While this scenario can be supported by separation of > > authentication agent > > from the enforcement point, does it really need that? Or > > can we achive the > > same when two are co-located? What component of this > > scenario requires > > the separation? > > => Well, it depends on which case you refer to. In the > load sharing case you need to separate the access > enforcement from the authentication, otherwise you > need to authenticate twice (unless there is some > protocol running between the default routers). If I understand you correctly, following are the abstractions: For limited free access: PANA Client ------- Edge device -------- Enforcement Point/PANA Agent ------ PANA Server For Load sharing: PANA Client ------ Edge Device/Enforcement Point ---- PANA Agent ------ PANA Server Subir From pana-request@research.telcordia.com Mon Apr 15 12:13:38 2002 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 MAA22154 for ; Mon, 15 Apr 2002 12:13:37 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FGBORH008290; Mon, 15 Apr 2002 12:11:24 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 12:11:24 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC6E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'subir Das'" , "Hesham Soliman (ERA)" Cc: "'Alper E. YEGIN'" , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Mon, 15 Apr 2002 18:10:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <6jaKkC.A.aBC.ruvu8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Subir, Yes. Hesham > > => Well, it depends on which case you refer to. In the > > load sharing case you need to separate the access > > enforcement from the authentication, otherwise you > > need to authenticate twice (unless there is some > > protocol running between the default routers). > > > If I understand you correctly, following are the abstractions: > > For limited free access: > > PANA Client ------- Edge device -------- Enforcement > Point/PANA Agent > ------ PANA Server > > > For Load sharing: > > PANA Client ------ Edge Device/Enforcement Point ---- PANA > Agent ------ > PANA Server > > > Subir > From pana-request@research.telcordia.com Mon Apr 15 15:15:20 2002 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 PAA03528 for ; Mon, 15 Apr 2002 15:15:12 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FJBB0Q026474; Mon, 15 Apr 2002 15:11:11 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 15:11:11 -0400 (EDT) Old-Return-Path: Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABCF4@ftmail> From: George Tsirtsis To: "'James Kempf'" , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Mon, 15 Apr 2002 15:10:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com James, I suggest you do that. Personally I do not care much about the split scenarios but that is not a reason for those to not exist. To put it another way, I do not see a reason to force collocation. Architecturally and conceptually the PANA Server and the Enforcement point ARE separate entities and artificially forcing them to co-exist does not give us anything. If they do co-exist then things are simple and we have the core protocol for PANA that deals with that. If they do not co-exist then a third protocol is also needed. SNMP is prime candidate for that as has been indicated before. PANA WG could choose to either say this is out of scope and PANA WG will not provide the details of this protocol (so vendors can develop their own solutions) or some people interested in interoperability (now or later) could write something up to show how SNMP could be used for that purpose. So, again, I do not understand what is the benefit of forcing colocation. George -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, April 15, 2002 12:04 PM To: Hesham Soliman (ERA); Alper E. YEGIN; pana@research.telcordia.com Subject: Re: Location of authentication agent > What is the > > application > > that won't work with a traditional NAS-style architecture? > > => Have a look at the scenarios draft. > You could question whether the scenarios are important > enough, but there is no question that the scenarios > exist and have been discussed when BURP started. > I've looked at the scenarios draft, and I don't find the arguments compelling. I will attempt to find the time to compose an email with a detailed description of why. jak From pana-request@research.telcordia.com Mon Apr 15 15:42:18 2002 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 PAA04382 for ; Mon, 15 Apr 2002 15:42:17 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FJcpOt028939; Mon, 15 Apr 2002 15:38:51 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 15:38:51 -0400 (EDT) Old-Return-Path: Message-ID: <018f01c1e4b4$e8c42760$7e6015ac@T23KEMPF> From: "James Kempf" To: "George Tsirtsis" , "Hesham Soliman \(ERA\)" , "Alper E. YEGIN" , References: <8C92E23A3E87FB479988285F9E22BE465ABCF4@ftmail> Subject: Re: Location of authentication agent Date: Mon, 15 Apr 2002 12:36:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > So, again, I do not understand what is the benefit of forcing colocation. > One word, George: S-I-M-P-L-I-C-I-T-Y jak From pana-request@research.telcordia.com Mon Apr 15 16:00:18 2002 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 QAA05056 for ; Mon, 15 Apr 2002 16:00:18 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FJtBNQ000721; Mon, 15 Apr 2002 15:55:11 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 15:55:11 -0400 (EDT) Old-Return-Path: Date: Mon, 15 Apr 2002 16:53:50 -0400 To: James Kempf Cc: George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com Subject: Re: Location of authentication agent Message-ID: <20020415205350.GC3140@catfish> Mail-Followup-To: James Kempf , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com References: <8C92E23A3E87FB479988285F9E22BE465ABCF4@ftmail> <018f01c1e4b4$e8c42760$7e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <018f01c1e4b4$e8c42760$7e6015ac@T23KEMPF> User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 18 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com I don't understand how it can be simple in the case of, for example, load sharing described in draft-ietf-ipv6-host-load-sharing-00.txt. Yoshihiro Ohba On Mon, Apr 15, 2002 at 12:36:59PM -0700, James Kempf wrote: > > > So, again, I do not understand what is the benefit of forcing > colocation. > > > > One word, George: > > S-I-M-P-L-I-C-I-T-Y > > jak > > From pana-request@research.telcordia.com Mon Apr 15 16:12:43 2002 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 QAA05403 for ; Mon, 15 Apr 2002 16:12:42 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FK9biW002480; Mon, 15 Apr 2002 16:09:37 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 16:09:37 -0400 (EDT) Old-Return-Path: Message-ID: <01af01c1e4b8$ed807a20$7e6015ac@T23KEMPF> From: "James Kempf" To: "Yoshihiro Ohba" Cc: "George Tsirtsis" , "Hesham Soliman \(ERA\)" , "Alper E. YEGIN" , References: <8C92E23A3E87FB479988285F9E22BE465ABCF4@ftmail> <018f01c1e4b4$e8c42760$7e6015ac@T23KEMPF> <20020415205350.GC3140@catfish> Subject: Re: Location of authentication agent Date: Mon, 15 Apr 2002 13:05:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <8k7tHC.A.om.AOzu8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Yoshi, By using the same method described in previous email to propogate the AAA info from the router hosting the NAS to another, i.e. SNMP. Secured, of course. This was brought up at Minneapolis. jak ----- Original Message ----- From: "Yoshihiro Ohba" To: "James Kempf" Cc: "George Tsirtsis" ; "Hesham Soliman (ERA)" ; "Alper E. YEGIN" ; Sent: Monday, April 15, 2002 1:53 PM Subject: Re: Location of authentication agent > I don't understand how it can be simple in the case of, for example, > load sharing described in draft-ietf-ipv6-host-load-sharing-00.txt. > > Yoshihiro Ohba > > On Mon, Apr 15, 2002 at 12:36:59PM -0700, James Kempf wrote: > > > > > So, again, I do not understand what is the benefit of forcing > > colocation. > > > > > > > One word, George: > > > > S-I-M-P-L-I-C-I-T-Y > > > > jak > > > > > From pana-request@research.telcordia.com Mon Apr 15 16:53:33 2002 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 QAA06447 for ; Mon, 15 Apr 2002 16:53:32 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FKmvXk007064; Mon, 15 Apr 2002 16:48:57 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 16:48:57 -0400 (EDT) Old-Return-Path: Date: Mon, 15 Apr 2002 17:47:50 -0400 To: James Kempf Cc: Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com Subject: Re: Location of authentication agent Message-ID: <20020415214750.GD3140@catfish> Mail-Followup-To: James Kempf , Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com References: <8C92E23A3E87FB479988285F9E22BE465ABCF4@ftmail> <018f01c1e4b4$e8c42760$7e6015ac@T23KEMPF> <20020415205350.GC3140@catfish> <01af01c1e4b8$ed807a20$7e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <01af01c1e4b8$ed807a20$7e6015ac@T23KEMPF> User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 50 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Mon, Apr 15, 2002 at 01:05:45PM -0700, James Kempf wrote: > Yoshi, > > By using the same method described in previous email to propogate the > AAA info from the router hosting the NAS to another, i.e. SNMP. Secured, > of course. This was brought up at Minneapolis. > > jak I think that requires N^2 security associations for N access routers sharing the load. If separation between PANA Agent and enforcement point is allowed, the number of security associations is reduced to N (PAA to each access router). Yoshihiro Ohba > > > ----- Original Message ----- > From: "Yoshihiro Ohba" > To: "James Kempf" > Cc: "George Tsirtsis" ; "Hesham Soliman (ERA)" > ; "Alper E. YEGIN" > ; > Sent: Monday, April 15, 2002 1:53 PM > Subject: Re: Location of authentication agent > > > > I don't understand how it can be simple in the case of, for example, > > load sharing described in draft-ietf-ipv6-host-load-sharing-00.txt. > > > > Yoshihiro Ohba > > > > On Mon, Apr 15, 2002 at 12:36:59PM -0700, James Kempf wrote: > > > > > > > So, again, I do not understand what is the benefit of forcing > > > colocation. > > > > > > > > > > One word, George: > > > > > > S-I-M-P-L-I-C-I-T-Y > > > > > > jak > > > > > > > > > > From pana-request@research.telcordia.com Mon Apr 15 17:25:54 2002 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 RAA06998 for ; Mon, 15 Apr 2002 17:25:53 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FLKQib010174; Mon, 15 Apr 2002 17:20:26 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 17:20:26 -0400 (EDT) Old-Return-Path: Message-ID: <01d801c1e4c3$0569cce0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "George Tsirtsis" , "Hesham Soliman \(ERA\)" , "Alper E. YEGIN" , References: <8C92E23A3E87FB479988285F9E22BE465ABCF4@ftmail> <018f01c1e4b4$e8c42760$7e6015ac@T23KEMPF> <20020415205350.GC3140@catfish> <01af01c1e4b8$ed807a20$7e6015ac@T23KEMPF> <20020415214750.GD3140@catfish> Subject: Re: Location of authentication agent Date: Mon, 15 Apr 2002 14:16:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > I think that requires N^2 security associations for N access routers > sharing the load. If separation between PANA Agent and enforcement > point is allowed, the number of security associations is reduced to N > (PAA to each access router). > The routers have to have those security associations anyway, to handle cryptographic security on their LSAs. Injecting the PANA agent requires N more than would otherwise be necessary. jak From pana-request@research.telcordia.com Mon Apr 15 17:31:01 2002 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 RAA07178 for ; Mon, 15 Apr 2002 17:31:01 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FLOD9e010640; Mon, 15 Apr 2002 17:24:13 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 17:24:13 -0400 (EDT) Old-Return-Path: Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABCF9@ftmail> From: George Tsirtsis To: "'James Kempf'" Cc: pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Mon, 15 Apr 2002 17:23:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com James, Why access routers HAVE to have SAs between them????? George -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, April 15, 2002 5:17 PM To: Yoshihiro Ohba Cc: Yoshihiro Ohba; George Tsirtsis; Hesham Soliman (ERA); Alper E. YEGIN; pana@research.telcordia.com Subject: Re: Location of authentication agent > I think that requires N^2 security associations for N access routers > sharing the load. If separation between PANA Agent and enforcement > point is allowed, the number of security associations is reduced to N > (PAA to each access router). > The routers have to have those security associations anyway, to handle cryptographic security on their LSAs. Injecting the PANA agent requires N more than would otherwise be necessary. jak From pana-request@research.telcordia.com Mon Apr 15 17:40:17 2002 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 RAA07355 for ; Mon, 15 Apr 2002 17:40:16 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FLbVEj011977; Mon, 15 Apr 2002 17:37:31 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 17:37:31 -0400 (EDT) Old-Return-Path: Date: Mon, 15 Apr 2002 18:36:16 -0400 To: James Kempf Cc: Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com Subject: Re: Location of authentication agent Message-ID: <20020415223616.GA3780@catfish> Mail-Followup-To: James Kempf , Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com References: <8C92E23A3E87FB479988285F9E22BE465ABCF4@ftmail> <018f01c1e4b4$e8c42760$7e6015ac@T23KEMPF> <20020415205350.GC3140@catfish> <01af01c1e4b8$ed807a20$7e6015ac@T23KEMPF> <20020415214750.GD3140@catfish> <01d801c1e4c3$0569cce0$7e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <01d801c1e4c3$0569cce0$7e6015ac@T23KEMPF> User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 22 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com The number of LSAs is not a problem at all since LSAs are dynamically established. The SAs between routers are static ones and that would increase management complexity, I think. Yoshihiro Ohba On Mon, Apr 15, 2002 at 02:16:49PM -0700, James Kempf wrote: > > > I think that requires N^2 security associations for N access routers > > sharing the load. If separation between PANA Agent and enforcement > > point is allowed, the number of security associations is reduced to N > > (PAA to each access router). > > > > The routers have to have those security associations anyway, to handle > cryptographic security on their LSAs. Injecting the PANA agent requires > N more than would otherwise be necessary. > > jak > > From pana-request@research.telcordia.com Mon Apr 15 18:03:25 2002 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 SAA07660 for ; Mon, 15 Apr 2002 18:03:24 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FLtV8M013415; Mon, 15 Apr 2002 17:55:31 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 17:55:31 -0400 (EDT) Old-Return-Path: Message-ID: <01ee01c1e4c7$d30f88c0$7e6015ac@T23KEMPF> From: "James Kempf" To: "George Tsirtsis" Cc: References: <8C92E23A3E87FB479988285F9E22BE465ABCF9@ftmail> Subject: Re: Location of authentication agent Date: Mon, 15 Apr 2002 14:52:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > Why access routers HAVE to have SAs between them????? > They don't necessarily but if the network operator is concerned about security and is using cryptographic security for exchange of LSAs, then they will. Injecting a PANA agent means that the network operator is concerned about security. Why would a network operator enable security on traffic with a PANA agent and not between access routers? jak From pana-request@research.telcordia.com Mon Apr 15 18:06:30 2002 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 SAA07843 for ; Mon, 15 Apr 2002 18:06:30 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FM2KdF014086; Mon, 15 Apr 2002 18:02:20 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 18:02:20 -0400 (EDT) Old-Return-Path: Message-ID: <01f801c1e4c8$b4350410$7e6015ac@T23KEMPF> From: "James Kempf" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "George Tsirtsis" , "Hesham Soliman \(ERA\)" , "Alper E. YEGIN" , References: <8C92E23A3E87FB479988285F9E22BE465ABCF4@ftmail> <018f01c1e4b4$e8c42760$7e6015ac@T23KEMPF> <20020415205350.GC3140@catfish> <01af01c1e4b8$ed807a20$7e6015ac@T23KEMPF> <20020415214750.GD3140@catfish> <01d801c1e4c3$0569cce0$7e6015ac@T23KEMPF> <20020415223616.GA3780@catfish> Subject: Re: Location of authentication agent Date: Mon, 15 Apr 2002 14:58:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <38aoEB.A.-bD.r30u8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > The number of LSAs is not a problem at all since LSAs are dynamically > established. The SAs between routers are static ones and that would > increase management complexity, I think. > LSA means "Link State Advertisement". It is the reachability information that is exchanged between routers. If a network operator is concerned about security, they will enable cryptographic security on their router traffic. If they are offering public access service and require PANA, then it makes a certain amount of sense that they do. Regarding the SAs being static, what's the problem? The routers can use Kerberos, IKE locally, or AAA to obtain keys, so the key distribution is taken care of. Of course, the network operator must enable that, but the same steps are needed for a separate PAA if you want to use Kerberos, IKE locally, or AAA for PAA key distribution. jak From pana-request@research.telcordia.com Mon Apr 15 18:11:54 2002 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 SAA07966 for ; Mon, 15 Apr 2002 18:11:53 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FM79uX014493; Mon, 15 Apr 2002 18:07:09 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 18:07:09 -0400 (EDT) Old-Return-Path: Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABCFB@ftmail> From: George Tsirtsis To: "'James Kempf'" Cc: pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Mon, 15 Apr 2002 18:06:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com James, It is typical for access routers to have SAs with backhaul servers e.g.: AAA servers, management stations and maybe now PANA servers. It is NOT common to have SAs between ALL the access routers in the domain...for obvious scaling issues. George -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Monday, April 15, 2002 5:52 PM To: George Tsirtsis Cc: pana@research.telcordia.com Subject: Re: Location of authentication agent > Why access routers HAVE to have SAs between them????? > They don't necessarily but if the network operator is concerned about security and is using cryptographic security for exchange of LSAs, then they will. Injecting a PANA agent means that the network operator is concerned about security. Why would a network operator enable security on traffic with a PANA agent and not between access routers? jak From pana-request@research.telcordia.com Mon Apr 15 18:30:24 2002 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 SAA08297 for ; Mon, 15 Apr 2002 18:30:22 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FMR1Qx015867; Mon, 15 Apr 2002 18:27:01 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 18:27:01 -0400 (EDT) Old-Return-Path: Message-ID: <024101c1e4cb$a8f61c80$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Pana \(E-mail\)" References: <8C92E23A3E87FB479988285F9E22BE465ABCF4@ftmail> <018f01c1e4b4$e8c42760$7e6015ac@T23KEMPF> <20020415205350.GC3140@catfish> <01af01c1e4b8$ed807a20$7e6015ac@T23KEMPF> <20020415214750.GD3140@catfish> <01d801c1e4c3$0569cce0$7e6015ac@T23KEMPF> <20020415223616.GA3780@catfish> <01f801c1e4c8$b4350410$7e6015ac@T23KEMPF> Subject: IETF 53 presentation slides Date: Mon, 15 Apr 2002 15:19:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit IETF 53 presentation slides can be found at: http://www.toshiba.com/tari/ietf53-pana.html Thanks to Yoshihiro Ohba for posting these on the web. alper From pana-request@research.telcordia.com Mon Apr 15 18:40:18 2002 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 SAA08698 for ; Mon, 15 Apr 2002 18:40:17 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3FMbaWh016540; Mon, 15 Apr 2002 18:37:36 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 18:37:36 -0400 (EDT) Old-Return-Path: Message-ID: <024201c1e4cd$e3c3e7a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "George Tsirtsis" Cc: References: <8C92E23A3E87FB479988285F9E22BE465ABCFB@ftmail> Subject: Re: Location of authentication agent Date: Mon, 15 Apr 2002 15:35:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > It is typical for access routers to have SAs with backhaul servers e.g.: AAA > servers, management stations and maybe now PANA servers. It is NOT common to > have SAs between ALL the access routers in the domain...for obvious scaling > issues. > IGP protocols have security features. What you are saying is that ISPs don't turn these features on today, because they view the management as burdensome. After the first report of a successful attack on the routing infrastructure because an ISP's IGP is not being secured, you can be sure that ISPs will quickly change their practice regardless of how burdensome it is. I don't believe we should predicate a major change in network access infrastructure on a current, somewhat questionable routing security practice. If the problem is the difficulty of managing cryptographic security on the routing infrastructure, then that problem should be solved. Adding a separate PAA as a workaround for a routing security management problem seems like a bad idea to me. But, of course, there may be other reasons why adding a separate PAA is a good idea, though I still haven't seen any. jak From pana-request@research.telcordia.com Mon Apr 15 20:56:58 2002 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 UAA10286 for ; Mon, 15 Apr 2002 20:56:50 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3G0o7ML024612; Mon, 15 Apr 2002 20:50:07 -0400 (EDT) Resent-Date: Mon, 15 Apr 2002 20:50:07 -0400 (EDT) Old-Return-Path: Message-ID: <032801c1e4df$a6411e90$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Hesham Soliman \(ERA\)" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AC68@Esealnt861.al.sw.ericsson.se> Subject: Re: Location of authentication agent Date: Mon, 15 Apr 2002 17:42:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > > > => More than the ones in the scenarios draft? > > > Namely: Load sharing, limited free access and > > > payment after a certain point..etc > > > > We should look closer at these scenarios. > > > > For example, in limited free access and payment after a certain > > point scenario, where would you put the authentication agent? It'd > > be good to take a look at the model and required interactions among > > protocol entities. > > => I would assume that you would put it at the border > of the 'free'/'don't care' zone. But this was intentionally > removed from the draft. We can certainly (and we should) > discuss it on the mailing list, but I hope we don't > do a full circle and include solutions in the > draft again. > > > While this scenario can be supported by separation of > > authentication agent > > from the enforcement point, does it really need that? Or > > can we achive the > > same when two are co-located? What component of this > > scenario requires > > the separation? > > => Well, it depends on which case you refer to. In the > load sharing case you need to separate the access > enforcement from the authentication, otherwise you > need to authenticate twice (unless there is some > protocol running between the default routers). > I don't know if someone has a better idea on how > to do this. Of course the other question is: Why So, the idea is to build a hierarchy of authentication. If the PaC gets authenticated to a PAA behind a set of access routers, we expect the PAA to automatically distribute state to all access routers within this PaC's reach. Can't we achive the same by relying on the local AAA server even when PAA is co-located with the access routers? Local AAA server is behind PAAs and it can distribute similar state upon the PaC getting authenticated. > does it matter? That is, what is the cost incurred > in separating the 2 entities and running SNMP/COPS/midcom ...etc > between them ? We'd need to identify what that transport is, and make sure it satisfies all the needs of access authentication (transporting keys?) The PAA discovery would be different as well, and harder I suspect. > I like to think of it as starting from the most flexible > solution, then trading flexibility for cost. A better approach is starting simple and seeing if it can serve the need. If not, expending on it, IMO. > There were concerns raised during the meeting about > the 'extra cost' associated with this separation, > but I didn't get a clear idea about where this cost > would come from. So maybe now is a good time to > discuss this. Yes, this is a good time to discuss the issue as we are clarifying the scope. alper From pana-request@research.telcordia.com Tue Apr 16 06:41:23 2002 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 GAA28618 for ; Tue, 16 Apr 2002 06:41:19 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GAarY1025882; Tue, 16 Apr 2002 06:36:53 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 06:36:53 -0400 (EDT) Old-Return-Path: Date: Tue, 16 Apr 2002 07:35:23 -0400 To: James Kempf Cc: Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com Subject: Re: Location of authentication agent Message-ID: <20020416113523.GA669@catfish> Mail-Followup-To: James Kempf , Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com References: <8C92E23A3E87FB479988285F9E22BE465ABCF4@ftmail> <018f01c1e4b4$e8c42760$7e6015ac@T23KEMPF> <20020415205350.GC3140@catfish> <01af01c1e4b8$ed807a20$7e6015ac@T23KEMPF> <20020415214750.GD3140@catfish> <01d801c1e4c3$0569cce0$7e6015ac@T23KEMPF> <20020415223616.GA3780@catfish> <01f801c1e4c8$b4350410$7e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <01f801c1e4c8$b4350410$7e6015ac@T23KEMPF> User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 33 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Mon, Apr 15, 2002 at 02:58:41PM -0700, James Kempf wrote: > > > The number of LSAs is not a problem at all since LSAs are dynamically > > established. The SAs between routers are static ones and that would > > increase management complexity, I think. > > > > LSA means "Link State Advertisement". It is the reachability information > that is exchanged between routers. If a network operator is concerned > about security, they will enable cryptographic security on their router > traffic. If they are offering public access service and require PANA, > then it makes a certain amount of sense that they do. > > Regarding the SAs being static, what's the problem? The routers can use > Kerberos, IKE locally, or AAA to obtain keys, so the key distribution is > taken care of. Of course, the network operator must enable that, but the > same steps are needed for a separate PAA if you want to use Kerberos, > IKE locally, or AAA for PAA key distribution. OK, static SA will not be the problem. Do you assume using the same SA for securing Link State Advertisement and securing SNMP? If you don't necessarily assume that, I don't still understand why co-location is simpler than separation. Moreover, it seems to me that allowing SNMP 'set' operation mutually among access routers is difficult to manage. Yoshihiro Ohba > > jak > > From pana-request@research.telcordia.com Tue Apr 16 07:08:27 2002 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 HAA29070 for ; Tue, 16 Apr 2002 07:08:26 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GB0kdl026894; Tue, 16 Apr 2002 07:00:46 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 07:00:46 -0400 (EDT) Old-Return-Path: Message-ID: <20020416110035.38685.qmail@web20410.mail.yahoo.com> Date: Tue, 16 Apr 2002 04:00:35 -0700 (PDT) From: Reinaldo Penno Subject: Re: Location of authentication agent To: "Alper E. YEGIN" , "Hesham Soliman \(ERA\)" , pana@research.telcordia.com In-Reply-To: <032801c1e4df$a6411e90$736015ac@AlperVAIO> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com I think one of the good arguments I heard is that PAA server and access router are separate entities anyway. Even if they reside on the same device, logically they will be separate entities. Second, we already have a good real world examaple on how it happened with PPP, Radius and NASes. We could authenticate users on the NAS/BRAS themselves, but that didn't stop people from having external Radius and even PEPs. Thirdly, when you have several access routers or policy point,s is better to have a single entity distributing policies than configuring on each one. As I said, even if the PAA reside on one of the access routers it would need to download the policies to the other ones, so we would be back to the same situation. finally, the limited free/premium content/walled garden and other variations imply sometimes more than on AR anyway since in some of these configurations the content does not even belong to the same entity that provides transport services. regards, Reinaldo --- "Alper E. YEGIN" wrote: > > > > => More than the ones in the scenarios > draft? > > > > Namely: Load sharing, limited free access > and > > > > payment after a certain point..etc > > > > > > We should look closer at these scenarios. > > > > > > For example, in limited free access and > payment after a certain > > > point scenario, where would you put the > authentication agent? It'd > > > be good to take a look at the model and > required interactions among > > > protocol entities. > > > > => I would assume that you would put it at the > border > > of the 'free'/'don't care' zone. But this was > intentionally > > removed from the draft. We can certainly (and we > should) > > discuss it on the mailing list, but I hope we > don't > > do a full circle and include solutions in the > > draft again. > > > > > While this scenario can be supported by > separation of > > > authentication agent > > > from the enforcement point, does it really > need that? Or > > > can we achive the > > > same when two are co-located? What component > of this > > > scenario requires > > > the separation? > > > > => Well, it depends on which case you refer to. In > the > > load sharing case you need to separate the access > > enforcement from the authentication, otherwise you > > > need to authenticate twice (unless there is some > > protocol running between the default routers). > > I don't know if someone has a better idea on how > > to do this. Of course the other question is: Why > > So, the idea is to build a hierarchy of > authentication. > If the PaC gets authenticated to a PAA behind a set > of > access routers, we expect the PAA to automatically > distribute state to all access routers within this > PaC's reach. > > Can't we achive the same by relying on the local AAA > server > even when PAA is co-located with the access routers? > Local > AAA server is behind PAAs and it can distribute > similar state > upon the PaC getting authenticated. > > > does it matter? That is, what is the cost incurred > > in separating the 2 entities and running > SNMP/COPS/midcom ...etc > > between them ? > > We'd need to identify what that transport is, and > make sure it satisfies > all the needs of access authentication (transporting > keys?) > > The PAA discovery would be different as well, and > harder I suspect. > > > I like to think of it as starting from the most > flexible > > solution, then trading flexibility for cost. > > A better approach is starting simple and seeing if > it can > serve the need. If not, expending on it, IMO. > > > There were concerns raised during the meeting > about > > the 'extra cost' associated with this separation, > > but I didn't get a clear idea about where this > cost > > would come from. So maybe now is a good time to > > discuss this. > > Yes, this is a good time to discuss the issue as we > are > clarifying the scope. > > alper > > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From pana-request@research.telcordia.com Tue Apr 16 08:51:56 2002 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 IAA01156 for ; Tue, 16 Apr 2002 08:51:52 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GChKYd001692; Tue, 16 Apr 2002 08:43:20 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 08:43:20 -0400 (EDT) Old-Return-Path: Message-Id: <4.3.2.7.2.20020416081720.019137f0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Apr 2002 08:41:19 -0400 To: Reinaldo Penno From: John Schnizlein Subject: Re: Location of authentication agent Cc: pana@research.telcordia.com In-Reply-To: <20020416110035.38685.qmail@web20410.mail.yahoo.com> References: <032801c1e4df$a6411e90$736015ac@AlperVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <9_Fvg.A.Ua.nxBv8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com At 07:00 AM 4/16/2002, Reinaldo Penno wrote: >Second, we already have a good real world examaple on >how it happened with PPP, Radius and NASes. We could >authenticate users on the NAS/BRAS themselves, but >that didn't stop people from having external Radius >and even PEPs. This analogy with the separation of NAS from Authentication Server (AS) does not fit the proposed separation of the authentication agent (AA) from the enforcement point (EP). The AS is separate in both cases. With PPP the EP and AA are co-located within the NAS. What is being proposed is yet another separation into EP, AA, then (optionally) an AS using Internet-Standard AAA protocols. If the EP and AA are separated, a protocol with complete analysis if its security considerations, robustness, etc. will have to be defined in addition to the PANA (which appears to reach only from the client to the AA). The argument for arbitrary location of the AA (on the edge?) seems to be for flexibility, although the cost tradeoff for this flexibility is not yet clear. Is it clear that the EP needs to be at the edge? John From pana-request@research.telcordia.com Tue Apr 16 10:29:15 2002 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 KAA06167 for ; Tue, 16 Apr 2002 10:29:14 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GEOhfv011734; Tue, 16 Apr 2002 10:24:43 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 10:24:43 -0400 (EDT) Old-Return-Path: Message-ID: <3CBC27E1.89C668DC@research.telcordia.com> Date: Tue, 16 Apr 2002 09:32:17 -0400 From: subir Das X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Schnizlein CC: Reinaldo Penno , pana@research.telcordia.com Subject: Re: Location of authentication agent References: <032801c1e4df$a6411e90$736015ac@AlperVAIO> <4.3.2.7.2.20020416081720.019137f0@diablo.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit John, John Schnizlein wrote: > > At 07:00 AM 4/16/2002, Reinaldo Penno wrote: > > >Second, we already have a good real world examaple on > >how it happened with PPP, Radius and NASes. We could > >authenticate users on the NAS/BRAS themselves, but > >that didn't stop people from having external Radius > >and even PEPs. > > This analogy with the separation of NAS from Authentication Server (AS) > does not fit the proposed separation of the authentication agent (AA) > from the enforcement point (EP). The AS is separate in both cases. > With PPP the EP and AA are co-located within the NAS. Agreed. > > What is being proposed is yet another separation into EP, AA, then > (optionally) an AS using Internet-Standard AAA protocols. If the EP > and AA are separated, a protocol with complete analysis if its > security considerations, robustness, etc. will have to be defined in > addition to the PANA (which appears to reach only from the client to > the AA). It is not clear to me why you say so. Let me describe what I understand: Case I: +-------+ +-------+ +--------+ +-------+ | Pac |-----------| Edge |---------| EP/AA |------| AS | + ------+ +-------+ +--------+ +-------+ <---------------- PANA ---------------> Case II: +-------+ +-------+ +--------+ +-------+ | Pac |-----------|Edge/EP |--------| AA |------| AS | + ------+ +-------+ +--------+ +-------+ <-------------- PANA ----------------> <----- (2)?? -----> If PANA can handle case I, it should be able to handle case II assuming that we know how to discover AA. Of course for case II, we have to design/specify protocol(2) which is between AA and EP. So I don't understand why you think that we have to define another protocol between Pac and AA apart from PANA. Am I missing something? >The argument for arbitrary location of the AA (on the edge?) > seems to be for flexibility, although the cost tradeoff for this > flexibility is not yet clear. I agree. Subir From pana-request@research.telcordia.com Tue Apr 16 10:44:53 2002 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 KAA06751 for ; Tue, 16 Apr 2002 10:44:52 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GEdqhR013419; Tue, 16 Apr 2002 10:39:52 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 10:39:52 -0400 (EDT) Old-Return-Path: Message-Id: <4.3.2.7.2.20020416102901.01913a18@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Apr 2002 10:37:44 -0400 To: subir Das From: John Schnizlein Subject: Re: Location of authentication agent Cc: Reinaldo Penno , pana@research.telcordia.com In-Reply-To: <3CBC27E1.89C668DC@research.telcordia.com> References: <032801c1e4df$a6411e90$736015ac@AlperVAIO> <4.3.2.7.2.20020416081720.019137f0@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Subir, You did not miss anything. What your diagram shows as protocol (2) EP - AA could easily be the additional protocol. I did not mean to say where this protocol would be. The other possibility is between the PANA client and the EP. You raise another issue that the proposed separation entails: choosing which of the three parties should have protocols between them. This choice should not be arbitrary either. The complexity of the separation is starting to emerge as we identify the issues that would require analysis. John At 09:32 AM 4/16/2002, subir Das wrote: >John Schnizlein wrote: >> >> What is being proposed is yet another separation into EP, AA, then >> (optionally) an AS using Internet-Standard AAA protocols. If the EP >> and AA are separated, a protocol with complete analysis if its >> security considerations, robustness, etc. will have to be defined in >> addition to the PANA (which appears to reach only from the client to >> the AA). > > It is not clear to me why you say so. Let me describe what I > understand: > >Case I: > > +-------+ +-------+ +--------+ +-------+ > | Pac |-----------| Edge |---------| EP/AA |------| AS | > + ------+ +-------+ +--------+ +-------+ > > <---------------- PANA ---------------> > >Case II: > > +-------+ +-------+ +--------+ +-------+ > | Pac |-----------|Edge/EP |--------| AA |------| AS | > + ------+ +-------+ +--------+ +-------+ > > <-------------- PANA ----------------> > > <----- (2)?? -----> > >If PANA can handle case I, it should be able to handle case II >assuming that we know how to discover AA. Of course for case II, >we have to design/specify protocol(2) which is between AA and EP. >So I don't understand why you think that we have to define another >protocol between Pac and AA apart from PANA. Am I missing something? From pana-request@research.telcordia.com Tue Apr 16 11:06:10 2002 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 LAA07441 for ; Tue, 16 Apr 2002 11:06:09 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GEwP9L015034; Tue, 16 Apr 2002 10:58:25 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 10:58:25 -0400 (EDT) Old-Return-Path: Message-ID: <3CBC2FCA.348FB04C@research.telcordia.com> Date: Tue, 16 Apr 2002 10:06:02 -0400 From: subir Das X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Schnizlein CC: Reinaldo Penno , pana@research.telcordia.com Subject: Re: Location of authentication agent References: <032801c1e4df$a6411e90$736015ac@AlperVAIO> <4.3.2.7.2.20020416081720.019137f0@diablo.cisco.com> <4.3.2.7.2.20020416102901.01913a18@diablo.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <6SYHGB.A.yqD.RwDv8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit John, John Schnizlein wrote: > > Subir, > > You did not miss anything. What your diagram shows as protocol (2) > EP - AA could easily be the additional protocol. I did not mean to > say where this protocol would be. The other possibility is between > the PANA client and the EP. > > You raise another issue that the proposed separation entails: choosing > which of the three parties should have protocols between them. This > choice should not be arbitrary either. The complexity of the separation > is starting to emerge as we identify the issues that would require > analysis. Completely agree with you. We have to clearly specify the model and understand the complexity. I think most of us agree with the fact that the existing model is simple but don't want to rule out other possibilities as well. Subir > > John > > At 09:32 AM 4/16/2002, subir Das wrote: > > >John Schnizlein wrote: > >> > >> What is being proposed is yet another separation into EP, AA, then > >> (optionally) an AS using Internet-Standard AAA protocols. If the EP > >> and AA are separated, a protocol with complete analysis if its > >> security considerations, robustness, etc. will have to be defined in > >> addition to the PANA (which appears to reach only from the client to > >> the AA). > > > > It is not clear to me why you say so. Let me describe what I > > understand: > > > >Case I: > > > > +-------+ +-------+ +--------+ +-------+ > > | Pac |-----------| Edge |---------| EP/AA |------| AS | > > + ------+ +-------+ +--------+ +-------+ > > > > <---------------- PANA ---------------> > > > >Case II: > > > > +-------+ +-------+ +--------+ +-------+ > > | Pac |-----------|Edge/EP |--------| AA |------| AS | > > + ------+ +-------+ +--------+ +-------+ > > > > <-------------- PANA ----------------> > > > > <----- (2)?? -----> > > > >If PANA can handle case I, it should be able to handle case II > >assuming that we know how to discover AA. Of course for case II, > >we have to design/specify protocol(2) which is between AA and EP. > >So I don't understand why you think that we have to define another > >protocol between Pac and AA apart from PANA. Am I missing something? From pana-request@research.telcordia.com Tue Apr 16 12:35:33 2002 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 MAA16049 for ; Tue, 16 Apr 2002 12:35:33 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GGQlBT024184; Tue, 16 Apr 2002 12:26:47 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 12:26:47 -0400 (EDT) Old-Return-Path: Message-ID: <004401c1e563$10c714d0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Alper E. YEGIN" , "Hesham Soliman \(ERA\)" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AC68@Esealnt861.al.sw.ericsson.se> <032801c1e4df$a6411e90$736015ac@AlperVAIO> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 09:23:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > Can't we achive the same by relying on the local AAA server > even when PAA is co-located with the access routers? Local > AAA server is behind PAAs and it can distribute similar state > upon the PaC getting authenticated. > Yes, exactly! This is the point that some of us have been trying to make in and since Minneapolis. The PAA is duplicating a lot of functionality of the AAA server. Keeping the PAA co-located with the access router and distributing the AAA server is more robust, and is consistent with the current NAS architecture. jak From pana-request@research.telcordia.com Tue Apr 16 12:51:34 2002 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 MAA18470 for ; Tue, 16 Apr 2002 12:51:32 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GGbAMp025265; Tue, 16 Apr 2002 12:37:10 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 12:37:10 -0400 (EDT) Old-Return-Path: Message-ID: <008801c1e564$72de0dd0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "George Tsirtsis" , "Hesham Soliman \(ERA\)" , "Alper E. YEGIN" , References: <8C92E23A3E87FB479988285F9E22BE465ABCF4@ftmail> <018f01c1e4b4$e8c42760$7e6015ac@T23KEMPF> <20020415205350.GC3140@catfish> <01af01c1e4b8$ed807a20$7e6015ac@T23KEMPF> <20020415214750.GD3140@catfish> <01d801c1e4c3$0569cce0$7e6015ac@T23KEMPF> <20020415223616.GA3780@catfish> <01f801c1e4c8$b4350410$7e6015ac@T23KEMPF> <20020416113523.GA669@catfish> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 09:33:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Whatever is used currently between a NAS and other routers on the link would work for a PAA as a NAS. jak ----- Original Message ----- From: "Yoshihiro Ohba" To: "James Kempf" Cc: "Yoshihiro Ohba" ; "George Tsirtsis" ; "Hesham Soliman (ERA)" ; "Alper E. YEGIN" ; Sent: Tuesday, April 16, 2002 4:35 AM Subject: Re: Location of authentication agent > On Mon, Apr 15, 2002 at 02:58:41PM -0700, James Kempf wrote: > > > > > The number of LSAs is not a problem at all since LSAs are dynamically > > > established. The SAs between routers are static ones and that would > > > increase management complexity, I think. > > > > > > > LSA means "Link State Advertisement". It is the reachability information > > that is exchanged between routers. If a network operator is concerned > > about security, they will enable cryptographic security on their router > > traffic. If they are offering public access service and require PANA, > > then it makes a certain amount of sense that they do. > > > > Regarding the SAs being static, what's the problem? The routers can use > > Kerberos, IKE locally, or AAA to obtain keys, so the key distribution is > > taken care of. Of course, the network operator must enable that, but the > > same steps are needed for a separate PAA if you want to use Kerberos, > > IKE locally, or AAA for PAA key distribution. > > OK, static SA will not be the problem. Do you assume using the same > SA for securing Link State Advertisement and securing SNMP? If you > don't necessarily assume that, I don't still understand why > co-location is simpler than separation. Moreover, it seems to me that > allowing SNMP 'set' operation mutually among access routers is > difficult to manage. > > Yoshihiro Ohba > > > > > > jak > > > > > From pana-request@research.telcordia.com Tue Apr 16 12:53:45 2002 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 MAA18734 for ; Tue, 16 Apr 2002 12:53:44 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GGiKZn025827; Tue, 16 Apr 2002 12:44:20 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 12:44:20 -0400 (EDT) Old-Return-Path: Message-ID: <009101c1e565$87bc5990$7e6015ac@T23KEMPF> From: "James Kempf" To: "Reinaldo Penno" , "Alper E. YEGIN" , "Hesham Soliman \(ERA\)" , References: <20020416110035.38685.qmail@web20410.mail.yahoo.com> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 09:41:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > I think one of the good arguments I heard is that PAA > server and access router are separate entities anyway. > Even if they reside on the same device, logically they > will be separate entities. > Much as I don't like alot about the way telephony people do network architecture and protocol design, one of the good things they do is make a distinction between a functional architecture and a network architecture. The functional architecture groups functionality into functional entities, the network architecture groups functional entites into boxes and defines interfaces between them on which protocols are defined. Like all good things, this distinction can be taken to unhealthy extremes, but I've found it a good starting point in many cases. What you are saying is that a PAA is a functional entity that can reside in a variety of network entities. What we are discussing and, to a certain extent disagreeing about, is in what network entity the PAA should reside. > Second, we already have a good real world examaple on > how it happened with PPP, Radius and NASes. We could > authenticate users on the NAS/BRAS themselves, but > that didn't stop people from having external Radius > and even PEPs. > > Thirdly, when you have several access routers or > policy point,s is better to have a single entity > distributing policies than configuring on each one. As > I said, even if the PAA reside on one of the access > routers it would need to download the policies to the > other ones, so we would be back to the same situation. > So what you are saying is that sticking with the existing NAS architecture will still allow multiple access routers on the link to be accommodated. > finally, the limited free/premium content/walled > garden and other variations imply sometimes more than > on AR anyway since in some of these configurations the > content does not even belong to the same entity that > provides transport services. > I'm not quite sure I understand what this has to do with separating the PAA into a separate network entity that can reside anywhere in the access network or keeping it as part of the default access router on the link. jak From pana-request@research.telcordia.com Tue Apr 16 13:15:36 2002 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 NAA21537 for ; Tue, 16 Apr 2002 13:15:36 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GGvnvt027150; Tue, 16 Apr 2002 12:57:49 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 12:57:49 -0400 (EDT) Old-Return-Path: Message-ID: <00b201c1e567$60170c80$7e6015ac@T23KEMPF> From: "James Kempf" To: "Reinaldo Penno" , "John Schnizlein" Cc: References: <032801c1e4df$a6411e90$736015ac@AlperVAIO> <4.3.2.7.2.20020416081720.019137f0@diablo.cisco.com> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 09:54:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <12X7IC.A.GoG.MgFv8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > What is being proposed is yet another separation into EP, AA, then > (optionally) an AS using Internet-Standard AAA protocols. If the EP > and AA are separated, a protocol with complete analysis if its > security considerations, robustness, etc. will have to be defined in > addition to the PANA (which appears to reach only from the client to > the AA). The argument for arbitrary location of the AA (on the edge?) > seems to be for flexibility, although the cost tradeoff for this > flexibility is not yet clear. Is it clear that the EP needs to be > at the edge? > This seems farily clear to me. The intent of the EP is to allow or deny service to a particular host. The first opportunity for gating this behavior is the access router. It makes logical sense to gate at that point. Is there some reason why one would want to gate further back in the network? jak From pana-request@research.telcordia.com Tue Apr 16 13:23:43 2002 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 NAA22352 for ; Tue, 16 Apr 2002 13:23:42 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GHJT7f029457; Tue, 16 Apr 2002 13:19:29 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 13:19:29 -0400 (EDT) Old-Return-Path: Message-ID: <00d901c1e56a$70631400$7e6015ac@T23KEMPF> From: "James Kempf" To: "subir Das" , "John Schnizlein" Cc: "Reinaldo Penno" , References: <032801c1e4df$a6411e90$736015ac@AlperVAIO> <4.3.2.7.2.20020416081720.019137f0@diablo.cisco.com> <3CBC27E1.89C668DC@research.telcordia.com> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 10:16:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Subir, There needs to be a protocol from PAA to EP to transfer enforcement decisions. Whether that's PANA or another protocol is another question. But this problem can be avoided entirely by making the PAA and EP be the same. Thus, PANA becomes very simple: a network layer transport for AAA between host and edge. jak ----- Original Message ----- From: "subir Das" To: "John Schnizlein" Cc: "Reinaldo Penno" ; Sent: Tuesday, April 16, 2002 6:32 AM Subject: Re: Location of authentication agent > > John, > > John Schnizlein wrote: > > > > At 07:00 AM 4/16/2002, Reinaldo Penno wrote: > > > > >Second, we already have a good real world examaple on > > >how it happened with PPP, Radius and NASes. We could > > >authenticate users on the NAS/BRAS themselves, but > > >that didn't stop people from having external Radius > > >and even PEPs. > > > > This analogy with the separation of NAS from Authentication Server (AS) > > does not fit the proposed separation of the authentication agent (AA) > > from the enforcement point (EP). The AS is separate in both cases. > > With PPP the EP and AA are co-located within the NAS. > > Agreed. > > > > What is being proposed is yet another separation into EP, AA, then > > (optionally) an AS using Internet-Standard AAA protocols. If the EP > > and AA are separated, a protocol with complete analysis if its > > security considerations, robustness, etc. will have to be defined in > > addition to the PANA (which appears to reach only from the client to > > the AA). > > It is not clear to me why you say so. Let me describe what I > understand: > > Case I: > > +-------+ +-------+ +--------+ +-------+ > | Pac |-----------| Edge |---------| EP/AA |------| AS | > + ------+ +-------+ +--------+ +-------+ > > <---------------- PANA ---------------> > > Case II: > > +-------+ +-------+ +--------+ +-------+ > | Pac |-----------|Edge/EP |--------| AA |------| AS | > + ------+ +-------+ +--------+ +-------+ > > <-------------- PANA ----------------> > > <----- (2)?? -----> > > If PANA can handle case I, it should be able to handle case II > assuming that we know how to discover AA. Of course for case II, > we have to design/specify protocol(2) which is between AA and EP. > So I don't understand why you think that we have to define another > protocol between Pac and AA apart from PANA. Am I missing something? > > > > >The argument for arbitrary location of the AA (on the edge?) > > seems to be for flexibility, although the cost tradeoff for this > > flexibility is not yet clear. > > I agree. > > > Subir > > From pana-request@research.telcordia.com Tue Apr 16 13:24:52 2002 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 NAA22450 for ; Tue, 16 Apr 2002 13:24:51 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GHLBMp029568; Tue, 16 Apr 2002 13:21:11 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 13:21:11 -0400 (EDT) Old-Return-Path: Message-ID: <20020416172041.83272.qmail@web20402.mail.yahoo.com> Date: Tue, 16 Apr 2002 10:20:41 -0700 (PDT) From: Reinaldo Penno Subject: Re: Location of authentication agent To: James Kempf , John Schnizlein Cc: pana@research.telcordia.com In-Reply-To: <00b201c1e567$60170c80$7e6015ac@T23KEMPF> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com I'm not sure I agree the EP should be only on the edge. That the example I was trying to articulate (but probably due to my coffee intake I used a lousy wording). There are situation where after the AR you have some walled garden content which have (each of them) their own EP. regards, Reinaldo --- James Kempf wrote: > > What is being proposed is yet another separation > into EP, AA, then > > (optionally) an AS using Internet-Standard AAA > protocols. If the EP > > and AA are separated, a protocol with complete > analysis if its > > security considerations, robustness, etc. will > have to be defined in > > addition to the PANA (which appears to reach only > from the client to > > the AA). The argument for arbitrary location of > the AA (on the edge?) > > seems to be for flexibility, although the cost > tradeoff for this > > flexibility is not yet clear. Is it clear that the > EP needs to be > > at the edge? > > > > This seems farily clear to me. The intent of the EP > is to allow or deny > service to a particular host. The first opportunity > for gating this > behavior is the access router. It makes logical > sense to gate at that > point. > > Is there some reason why one would want to gate > further back in the > network? > > jak > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From pana-request@research.telcordia.com Tue Apr 16 13:26:41 2002 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 NAA22700 for ; Tue, 16 Apr 2002 13:26:40 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GHNMFW029798; Tue, 16 Apr 2002 13:23:22 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 13:23:22 -0400 (EDT) Old-Return-Path: Message-ID: <00ed01c1e56a$f6350b10$7e6015ac@T23KEMPF> From: "James Kempf" To: "subir Das" , "John Schnizlein" Cc: "Reinaldo Penno" , References: <032801c1e4df$a6411e90$736015ac@AlperVAIO> <4.3.2.7.2.20020416081720.019137f0@diablo.cisco.com> <4.3.2.7.2.20020416102901.01913a18@diablo.cisco.com> <3CBC2FCA.348FB04C@research.telcordia.com> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 10:20:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > Completely agree with you. We have to clearly specify the model and > understand the complexity. I think most of us agree with the fact that > the existing model is simple but don't want to rule out other > possibilities as well. > In fact, I think we do want to rule out other possibilities. A more complex architecture provides more opportunity for security attacks, a longer design time, etc. If nobody can come up with a compelling reason why the current NAS architecture is insufficient, then I don't see any reason for changing it. What's the point of complicating things if there is no significant benefit? jak From pana-request@research.telcordia.com Tue Apr 16 13:29:17 2002 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 NAA22951 for ; Tue, 16 Apr 2002 13:29:16 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GHPKkK000082; Tue, 16 Apr 2002 13:25:20 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 13:25:20 -0400 (EDT) Old-Return-Path: Date: Tue, 16 Apr 2002 14:23:56 -0400 To: James Kempf Cc: Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com Subject: Re: Location of authentication agent Message-ID: <20020416182356.GA635@catfish> Mail-Followup-To: James Kempf , Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com References: <8C92E23A3E87FB479988285F9E22BE465ABCF4@ftmail> <018f01c1e4b4$e8c42760$7e6015ac@T23KEMPF> <20020415205350.GC3140@catfish> <01af01c1e4b8$ed807a20$7e6015ac@T23KEMPF> <20020415214750.GD3140@catfish> <01d801c1e4c3$0569cce0$7e6015ac@T23KEMPF> <20020415223616.GA3780@catfish> <01f801c1e4c8$b4350410$7e6015ac@T23KEMPF> <20020416113523.GA669@catfish> <008801c1e564$72de0dd0$7e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <008801c1e564$72de0dd0$7e6015ac@T23KEMPF> User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 74 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Jim, Your model is also based on separation of Authentication Agent (AA) and Enforcement Point (EP) in that an access router which acts as an AA distributes access control rules to other access routers (including itself) which are EPs. So you seem to basically agree on the separated model. Yoshihiro Ohba On Tue, Apr 16, 2002 at 09:33:32AM -0700, James Kempf wrote: > Whatever is used currently between a NAS and other routers on the link > would work for a PAA as a NAS. > > jak > > ----- Original Message ----- > From: "Yoshihiro Ohba" > To: "James Kempf" > Cc: "Yoshihiro Ohba" ; "George Tsirtsis" > ; "Hesham Soliman (ERA)" > ; "Alper E. YEGIN" > ; > Sent: Tuesday, April 16, 2002 4:35 AM > Subject: Re: Location of authentication agent > > > > On Mon, Apr 15, 2002 at 02:58:41PM -0700, James Kempf wrote: > > > > > > > The number of LSAs is not a problem at all since LSAs are > dynamically > > > > established. The SAs between routers are static ones and that > would > > > > increase management complexity, I think. > > > > > > > > > > LSA means "Link State Advertisement". It is the reachability > information > > > that is exchanged between routers. If a network operator is > concerned > > > about security, they will enable cryptographic security on their > router > > > traffic. If they are offering public access service and require > PANA, > > > then it makes a certain amount of sense that they do. > > > > > > Regarding the SAs being static, what's the problem? The routers can > use > > > Kerberos, IKE locally, or AAA to obtain keys, so the key > distribution is > > > taken care of. Of course, the network operator must enable that, but > the > > > same steps are needed for a separate PAA if you want to use > Kerberos, > > > IKE locally, or AAA for PAA key distribution. > > > > OK, static SA will not be the problem. Do you assume using the same > > SA for securing Link State Advertisement and securing SNMP? If you > > don't necessarily assume that, I don't still understand why > > co-location is simpler than separation. Moreover, it seems to me that > > allowing SNMP 'set' operation mutually among access routers is > > difficult to manage. > > > > Yoshihiro Ohba > > > > > > > > > > jak > > > > > > > > > > From pana-request@research.telcordia.com Tue Apr 16 13:29:21 2002 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 NAA22962 for ; Tue, 16 Apr 2002 13:29:21 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GHOZ7u000025; Tue, 16 Apr 2002 13:24:35 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 13:24:35 -0400 (EDT) Old-Return-Path: Message-ID: <20020416172414.1178.qmail@web20409.mail.yahoo.com> Date: Tue, 16 Apr 2002 10:24:14 -0700 (PDT) From: Reinaldo Penno Subject: Re: Location of authentication agent To: James Kempf , subir Das , John Schnizlein Cc: Reinaldo Penno , pana@research.telcordia.com In-Reply-To: <00d901c1e56a$70631400$7e6015ac@T23KEMPF> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com I agree we need another protocol, but the protocol is already out there. Actually we have more than one to choose from: COPS, midcom, snmp... Let me ask this. Can't we say PAA and EP can be on different devices or on the same device. If they are on different devices you need a protocol between them, which is out of scope. period. regards, Reinaldo --- James Kempf wrote: > Subir, > > There needs to be a protocol from PAA to EP to > transfer enforcement > decisions. Whether that's PANA or another protocol > is another question. > > But this problem can be avoided entirely by making > the PAA and EP be the > same. Thus, PANA becomes very simple: a network > layer transport for AAA > between host and edge. > > > jak > > > ----- Original Message ----- > From: "subir Das" > To: "John Schnizlein" > Cc: "Reinaldo Penno" ; > > Sent: Tuesday, April 16, 2002 6:32 AM > Subject: Re: Location of authentication agent > > > > > > John, > > > > John Schnizlein wrote: > > > > > > At 07:00 AM 4/16/2002, Reinaldo Penno wrote: > > > > > > >Second, we already have a good real world > examaple on > > > >how it happened with PPP, Radius and NASes. We > could > > > >authenticate users on the NAS/BRAS themselves, > but > > > >that didn't stop people from having external > Radius > > > >and even PEPs. > > > > > > This analogy with the separation of NAS from > Authentication Server > (AS) > > > does not fit the proposed separation of the > authentication agent > (AA) > > > from the enforcement point (EP). The AS is > separate in both cases. > > > With PPP the EP and AA are co-located within the > NAS. > > > > Agreed. > > > > > > What is being proposed is yet another separation > into EP, AA, then > > > (optionally) an AS using Internet-Standard AAA > protocols. If the EP > > > and AA are separated, a protocol with complete > analysis if its > > > security considerations, robustness, etc. will > have to be defined in > > > addition to the PANA (which appears to reach > only from the client to > > > the AA). > > > > It is not clear to me why you say so. Let me > describe what I > > understand: > > > > Case I: > > > > +-------+ +-------+ +--------+ > +-------+ > > | Pac |-----------| Edge |---------| EP/AA > |------| AS | > > + ------+ +-------+ +--------+ > +-------+ > > > > <---------------- PANA ---------------> > > > > Case II: > > > > +-------+ +-------+ +--------+ > +-------+ > > | Pac |-----------|Edge/EP |--------| AA > |------| AS | > > + ------+ +-------+ +--------+ > +-------+ > > > > <-------------- PANA ----------------> > > > > <----- (2)?? -----> > > > > If PANA can handle case I, it should be able to > handle case II > > assuming that we know how to discover AA. Of > course for case II, > > we have to design/specify protocol(2) which is > between AA and EP. > > So I don't understand why you think that we have > to define another > > protocol between Pac and AA apart from PANA. Am I > missing something? > > > > > > > > >The argument for arbitrary location of the AA (on > the edge?) > > > seems to be for flexibility, although the cost > tradeoff for this > > > flexibility is not yet clear. > > > > I agree. > > > > > > Subir > > > > > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From pana-request@research.telcordia.com Tue Apr 16 13:34:24 2002 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 NAA23618 for ; Tue, 16 Apr 2002 13:34:24 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GHT4PR000345; Tue, 16 Apr 2002 13:29:04 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 13:29:04 -0400 (EDT) Old-Return-Path: Message-ID: <3CBC5316.3CAF772C@research.telcordia.com> Date: Tue, 16 Apr 2002 12:36:38 -0400 From: subir Das X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: "Alper E. YEGIN" , "Hesham Soliman (ERA)" , pana@research.telcordia.com Subject: Re: Location of authentication agent References: <4DA6EA82906FD511BE2F00508BCF053802C6AC68@Esealnt861.al.sw.ericsson.se> <032801c1e4df$a6411e90$736015ac@AlperVAIO> <004401c1e563$10c714d0$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <2-31XD.A.RF.g9Fv8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit ALper/James, Are we assuming that there will be always a AAA infrastructure at the back end? Can you draw your model and explain? Subir James Kempf wrote: > > > Can't we achive the same by relying on the local AAA server > > even when PAA is co-located with the access routers? Local > > AAA server is behind PAAs and it can distribute similar state > > upon the PaC getting authenticated. > > > > Yes, exactly! This is the point that some of us have been > trying to make in and since Minneapolis. > > The PAA is duplicating a lot of functionality of the AAA server. > Keeping the PAA co-located with the access router and > distributing the AAA server is more robust, and is consistent > with the current NAS architecture. > > jak From pana-request@research.telcordia.com Tue Apr 16 13:52:31 2002 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 NAA26043 for ; Tue, 16 Apr 2002 13:52:31 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GHmtev002375; Tue, 16 Apr 2002 13:48:55 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 13:48:55 -0400 (EDT) Old-Return-Path: Message-ID: <3CBC57BA.BC029D58@research.telcordia.com> Date: Tue, 16 Apr 2002 12:56:26 -0400 From: subir Das X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: John Schnizlein , Reinaldo Penno , pana@research.telcordia.com Subject: Re: Location of authentication agent References: <032801c1e4df$a6411e90$736015ac@AlperVAIO> <4.3.2.7.2.20020416081720.019137f0@diablo.cisco.com> <4.3.2.7.2.20020416102901.01913a18@diablo.cisco.com> <3CBC2FCA.348FB04C@research.telcordia.com> <00ed01c1e56a$f6350b10$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit James, > > > Completely agree with you. We have to clearly specify the model and > > understand the complexity. I think most of us agree with the fact > that > > the existing model is simple but don't want to rule out other > > possibilities as well. > > > > In fact, I think we do want to rule out other possibilities. A more > complex architecture provides more opportunity for security attacks, a > longer design time, etc. If nobody can come up with a compelling reason > why the current NAS architecture is insufficient, then I don't see any > reason for changing it. What's the point of complicating things if there > is no significant benefit? Instead of debating like this, we should come up with some concrete points. May I request you to provide some analysis why you think this is very complex? We will also try. Subir From pana-request@research.telcordia.com Tue Apr 16 14:14:30 2002 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 OAA28354 for ; Tue, 16 Apr 2002 14:14:29 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GIAlc2005286; Tue, 16 Apr 2002 14:10:47 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 14:10:47 -0400 (EDT) Old-Return-Path: Message-ID: <017501c1e571$7dc915c0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "George Tsirtsis" , "Hesham Soliman \(ERA\)" , "Alper E. YEGIN" , References: <8C92E23A3E87FB479988285F9E22BE465ABCF4@ftmail> <018f01c1e4b4$e8c42760$7e6015ac@T23KEMPF> <20020415205350.GC3140@catfish> <01af01c1e4b8$ed807a20$7e6015ac@T23KEMPF> <20020415214750.GD3140@catfish> <01d801c1e4c3$0569cce0$7e6015ac@T23KEMPF> <20020415223616.GA3780@catfish> <01f801c1e4c8$b4350410$7e6015ac@T23KEMPF> <20020416113523.GA669@catfish> <008801c1e564$72de0dd0$7e6015ac@T23KEMPF> <20020416182356.GA635@catfish> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 11:06:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Yoshi, You are confusing the functional architecture and the network architecture. I agree that the AA and EP are two separate functional entities. I believe that they need to be grouped into the default router network entity, not that they can be arbitrarily assigned to a network entity somewhere in the access network. These are two very different network architectures. jak ----- Original Message ----- From: "Yoshihiro Ohba" To: "James Kempf" Cc: "Yoshihiro Ohba" ; "George Tsirtsis" ; "Hesham Soliman (ERA)" ; "Alper E. YEGIN" ; Sent: Tuesday, April 16, 2002 11:23 AM Subject: Re: Location of authentication agent > Jim, > > Your model is also based on separation of Authentication Agent (AA) > and Enforcement Point (EP) in that an access router which acts as an > AA distributes access control rules to other access routers (including > itself) which are EPs. So you seem to basically agree on the > separated model. > > Yoshihiro Ohba > > > On Tue, Apr 16, 2002 at 09:33:32AM -0700, James Kempf wrote: > > Whatever is used currently between a NAS and other routers on the link > > would work for a PAA as a NAS. > > > > jak > > > > ----- Original Message ----- > > From: "Yoshihiro Ohba" > > To: "James Kempf" > > Cc: "Yoshihiro Ohba" ; "George Tsirtsis" > > ; "Hesham Soliman (ERA)" > > ; "Alper E. YEGIN" > > ; > > Sent: Tuesday, April 16, 2002 4:35 AM > > Subject: Re: Location of authentication agent > > > > > > > On Mon, Apr 15, 2002 at 02:58:41PM -0700, James Kempf wrote: > > > > > > > > > The number of LSAs is not a problem at all since LSAs are > > dynamically > > > > > established. The SAs between routers are static ones and that > > would > > > > > increase management complexity, I think. > > > > > > > > > > > > > LSA means "Link State Advertisement". It is the reachability > > information > > > > that is exchanged between routers. If a network operator is > > concerned > > > > about security, they will enable cryptographic security on their > > router > > > > traffic. If they are offering public access service and require > > PANA, > > > > then it makes a certain amount of sense that they do. > > > > > > > > Regarding the SAs being static, what's the problem? The routers can > > use > > > > Kerberos, IKE locally, or AAA to obtain keys, so the key > > distribution is > > > > taken care of. Of course, the network operator must enable that, but > > the > > > > same steps are needed for a separate PAA if you want to use > > Kerberos, > > > > IKE locally, or AAA for PAA key distribution. > > > > > > OK, static SA will not be the problem. Do you assume using the same > > > SA for securing Link State Advertisement and securing SNMP? If you > > > don't necessarily assume that, I don't still understand why > > > co-location is simpler than separation. Moreover, it seems to me that > > > allowing SNMP 'set' operation mutually among access routers is > > > difficult to manage. > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Tue Apr 16 14:14:54 2002 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 OAA28402 for ; Tue, 16 Apr 2002 14:14:53 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GIARqP005250; Tue, 16 Apr 2002 14:10:27 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 14:10:27 -0400 (EDT) Old-Return-Path: Message-ID: <017d01c1e571$b872f010$7e6015ac@T23KEMPF> From: "James Kempf" To: "subir Das" Cc: "Alper E. YEGIN" , "Hesham Soliman \(ERA\)" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AC68@Esealnt861.al.sw.ericsson.se> <032801c1e4df$a6411e90$736015ac@AlperVAIO> <004401c1e563$10c714d0$7e6015ac@T23KEMPF> <3CBC5316.3CAF772C@research.telcordia.com> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 11:08:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Subir, It need not be RADIUS or Diameter but there does need to be something. The other issue is whether an implementation could bundle AAA/AA/EP in one entity. jak PS: I'm not very good at text drawings, sorry. ----- Original Message ----- From: "subir Das" To: "James Kempf" Cc: "Alper E. YEGIN" ; "Hesham Soliman (ERA)" ; Sent: Tuesday, April 16, 2002 9:36 AM Subject: Re: Location of authentication agent > ALper/James, > > Are we assuming that there will be always a AAA infrastructure at the > back end? > Can you draw your model and explain? > > Subir > > > > James Kempf wrote: > > > > > Can't we achive the same by relying on the local AAA server > > > even when PAA is co-located with the access routers? Local > > > AAA server is behind PAAs and it can distribute similar state > > > upon the PaC getting authenticated. > > > > > > > Yes, exactly! This is the point that some of us have been > > trying to make in and since Minneapolis. > > > > The PAA is duplicating a lot of functionality of the AAA server. > > Keeping the PAA co-located with the access router and > > distributing the AAA server is more robust, and is consistent > > with the current NAS architecture. > > > > jak > From pana-request@research.telcordia.com Tue Apr 16 14:30:35 2002 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 OAA00095 for ; Tue, 16 Apr 2002 14:30:35 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GIPdXn006789; Tue, 16 Apr 2002 14:25:39 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 14:25:39 -0400 (EDT) Old-Return-Path: Message-ID: <01ad01c1e573$db5253d0$7e6015ac@T23KEMPF> From: "James Kempf" To: "subir Das" Cc: "John Schnizlein" , "Reinaldo Penno" , References: <032801c1e4df$a6411e90$736015ac@AlperVAIO> <4.3.2.7.2.20020416081720.019137f0@diablo.cisco.com> <4.3.2.7.2.20020416102901.01913a18@diablo.cisco.com> <3CBC2FCA.348FB04C@research.telcordia.com> <00ed01c1e56a$f6350b10$7e6015ac@T23KEMPF> <3CBC57BA.BC029D58@research.telcordia.com> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 11:23:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > Instead of debating like this, we should come up with some concrete > points. May I request you to provide some analysis why you think this > is > very complex? We will also try. > OK, here's one point. Putting the PAA back in the network widens the scope of topology for DoS attacks. If the PAA is at the first hop, the only place a DoS attack can come from is on that link. Because the geographic span of the link is limited, it is much easier to find and disconnect the perpetrator than if the topological span is across multiple subnets, and thus across a larger geographic range. In addition, an attack on a PAA at the first hop disables access to just that link. An attack on a PAA back in the network could potentially disable access to an entire segment of the ISPs network, or potentially the entire network if the ISP has one PAA for the entire network. jak From pana-request@research.telcordia.com Tue Apr 16 14:42:50 2002 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 OAA01686 for ; Tue, 16 Apr 2002 14:42:49 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GIdYKU008297; Tue, 16 Apr 2002 14:39:34 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 14:39:34 -0400 (EDT) Old-Return-Path: Message-ID: <01c301c1e575$c49c3370$7e6015ac@T23KEMPF> From: "James Kempf" To: "Reinaldo Penno" , "John Schnizlein" Cc: References: <00b201c1e567$60170c80$7e6015ac@T23KEMPF> <4.3.2.7.2.20020416133848.01913a18@diablo.cisco.com> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 11:37:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > Is there some way to decide if rough consensus is to > make enabling walled gardens out of scope, if not > an explicit non-goal of the WG? > Technically, what do you think enabling walled gardens involves? IMHO, I see PANA as a simple network transport for EAP between the host and the edge. At the edge, the AAA protocol (Radius, Diameter) takes over. What actually happens at the edge depends on what is transported in the EAP and the ensuing AAA exchange, and thus out of scope of the WG. jak From pana-request@research.telcordia.com Tue Apr 16 14:47:24 2002 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 OAA02173 for ; Tue, 16 Apr 2002 14:47:22 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GIf8P5008466; Tue, 16 Apr 2002 14:41:08 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 14:41:08 -0400 (EDT) Old-Return-Path: Message-ID: <01c901c1e575$d8504c80$7e6015ac@T23KEMPF> From: "James Kempf" To: "subir Das" , "John Schnizlein" Cc: References: <4DA6EA82906FD511BE2F00508BCF053802C6AC68@Esealnt861.al.sw.ericsson.se> <032801c1e4df$a6411e90$736015ac@AlperVAIO> <004401c1e563$10c714d0$7e6015ac@T23KEMPF> <4.3.2.7.2.20020416135739.018c1ca0@diablo.cisco.com> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 11:38:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Agree! jak ----- Original Message ----- From: "John Schnizlein" To: "subir Das" Cc: "James Kempf" ; Sent: Tuesday, April 16, 2002 11:01 AM Subject: Re: Location of authentication agent > I don't think such a categorical assumption is necessary. > Instead, the simple model of co-locating the EP and AA, with > any separation of function that is necessary accomplished > through the Internet-Standard AAA protocol, is superior to > requiring yet another protocol required by yet another separation. > > John > > At 12:36 PM 4/16/2002, subir Das wrote: > > >Are we assuming that there will be always a AAA infrastructure > >at the back end? > > > >James Kempf wrote: > >> > >> > Can't we achive the same by relying on the local AAA server > >> > even when PAA is co-located with the access routers? Local > >> > AAA server is behind PAAs and it can distribute similar state > >> > upon the PaC getting authenticated. > >> > >> Yes, exactly! This is the point that some of us have been > >> trying to make in and since Minneapolis. > >> > >> The PAA is duplicating a lot of functionality of the AAA server. > >> Keeping the PAA co-located with the access router and > >> distributing the AAA server is more robust, and is consistent > >> with the current NAS architecture. > > From pana-request@research.telcordia.com Tue Apr 16 15:04:20 2002 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 PAA04738 for ; Tue, 16 Apr 2002 15:04:16 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GI2T9O003802; Tue, 16 Apr 2002 14:02:29 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 14:02:29 -0400 (EDT) Old-Return-Path: Message-Id: <4.3.2.7.2.20020416133848.01913a18@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Apr 2002 13:51:47 -0400 To: Reinaldo Penno From: John Schnizlein Subject: Re: Location of authentication agent Cc: James Kempf , pana@research.telcordia.com In-Reply-To: <20020416172041.83272.qmail@web20402.mail.yahoo.com> References: <00b201c1e567$60170c80$7e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <1AVVGC.A.K7.zcGv8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is just the sort of thing I was afraid of. We should find out as soon as possible if the WG wants PANA to be designed so that it supports walled gardens. The walled garden is about as antithetical to the fundamental principles of the Internet as anything I have seen. It is worth noting that the references to enabling walled gardens, which received negative comment early in the URP - BURP phase of BOFs was removed in the charter that got past the IESG. If this support again becomes part of the goal of the WG, the IESG should again be asked to review its status. Is there some way to decide if rough consensus is to make enabling walled gardens out of scope, if not an explicit non-goal of the WG? John At 01:20 PM 4/16/2002, Reinaldo Penno wrote: >I'm not sure I agree the EP should be only on the >edge... > >There are situation where after the AR you have some >walled garden content which have (each of them) their >own EP. > >--- James Kempf wrote: >> >> >Is it clear that the EP needs to be at the edge? >> >> This seems farily clear to me. >> The intent of the EP is to allow or deny >> service to a particular host. >> The first opportunity for gating this >> behavior is the access router. >> It makes logical sense to gate at that point. >> >> Is there some reason why one would want to gate >> further back in the network? From pana-request@research.telcordia.com Tue Apr 16 15:08:10 2002 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 PAA05284 for ; Tue, 16 Apr 2002 15:08:10 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GI2UMm003812; Tue, 16 Apr 2002 14:02:30 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 14:02:30 -0400 (EDT) Old-Return-Path: Message-Id: <4.3.2.7.2.20020416135739.018c1ca0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Apr 2002 14:01:18 -0400 To: subir Das From: John Schnizlein Subject: Re: Location of authentication agent Cc: James Kempf , pana@research.telcordia.com In-Reply-To: <3CBC5316.3CAF772C@research.telcordia.com> References: <4DA6EA82906FD511BE2F00508BCF053802C6AC68@Esealnt861.al.sw.ericsson.se> <032801c1e4df$a6411e90$736015ac@AlperVAIO> <004401c1e563$10c714d0$7e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com I don't think such a categorical assumption is necessary. Instead, the simple model of co-locating the EP and AA, with any separation of function that is necessary accomplished through the Internet-Standard AAA protocol, is superior to requiring yet another protocol required by yet another separation. John At 12:36 PM 4/16/2002, subir Das wrote: >Are we assuming that there will be always a AAA infrastructure >at the back end? > >James Kempf wrote: >> >> > Can't we achive the same by relying on the local AAA server >> > even when PAA is co-located with the access routers? Local >> > AAA server is behind PAAs and it can distribute similar state >> > upon the PaC getting authenticated. >> >> Yes, exactly! This is the point that some of us have been >> trying to make in and since Minneapolis. >> >> The PAA is duplicating a lot of functionality of the AAA server. >> Keeping the PAA co-located with the access router and >> distributing the AAA server is more robust, and is consistent >> with the current NAS architecture. From pana-request@research.telcordia.com Tue Apr 16 15:10:10 2002 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 PAA05631 for ; Tue, 16 Apr 2002 15:10:09 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GI3KXL003944; Tue, 16 Apr 2002 14:03:20 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 14:03:20 -0400 (EDT) Old-Return-Path: Message-ID: <015d01c1e570$714f3a00$7e6015ac@T23KEMPF> From: "James Kempf" To: "Reinaldo Penno" , "John Schnizlein" Cc: References: <20020416172041.83272.qmail@web20402.mail.yahoo.com> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 10:59:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > I'm not sure I agree the EP should be only on the > edge. That the example I was trying to articulate (but > probably due to my coffee intake I used a lousy > wording). > > There are situation where after the AR you have some > walled garden content which have (each of them) their > own EP. > I don't think anybody is arguing that content not have it's own EP. That is done today when you want to get into Web sites. There is work such as MS Passport/Liberty for single sign on in that area, but it is application level. The issue here is network access and perhaps access to specific ports/protocols (e.g. SIP, HTTP). This is a much larger granularity. jak From pana-request@research.telcordia.com Tue Apr 16 15:13:20 2002 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 PAA06020 for ; Tue, 16 Apr 2002 15:13:19 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GI3xgi004037; Tue, 16 Apr 2002 14:03:59 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 14:03:59 -0400 (EDT) Old-Return-Path: Message-ID: <016701c1e570$bd88c6c0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Reinaldo Penno" , "subir Das" , "John Schnizlein" Cc: "Reinaldo Penno" , References: <20020416172414.1178.qmail@web20409.mail.yahoo.com> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 11:01:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > Let me ask this. Can't we say PAA and EP can be on > different devices or on the same device. If they are > on different devices you need a protocol between them, > which is out of scope. period. > Why? I don't see any compelling reason for this. Opening up the architecture in this way sets it up for new kinds of security threats and other complications. I don't think we should go through the difficulty of having to completely redo the network access design unless there are compelling reasons. jak From pana-request@research.telcordia.com Tue Apr 16 15:20:21 2002 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 PAA06827 for ; Tue, 16 Apr 2002 15:20:21 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GJGtbM011822; Tue, 16 Apr 2002 15:16:55 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 15:16:55 -0400 (EDT) Old-Return-Path: Message-ID: <20020416191548.157.qmail@web20405.mail.yahoo.com> Date: Tue, 16 Apr 2002 12:15:48 -0700 (PDT) From: Reinaldo Penno Subject: Re: Location of authentication agent To: James Kempf , subir Das , John Schnizlein Cc: Reinaldo Penno , pana@research.telcordia.com In-Reply-To: <016701c1e570$bd88c6c0$7e6015ac@T23KEMPF> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hello James, the associated protocol is out of scope and also any associted security threats. It wouldn't make sense to say the protocol is out of scope but not the security threats. I'm curious, can you think of an IETF architecture where an assolciaed protocol is declared out of scope but people felt the need to deal with the security threats of this out of scopr protocol? IMHO this seems weird. regards, Reinaldo --- James Kempf wrote: > > Let me ask this. Can't we say PAA and EP can be on > > different devices or on the same device. If they > are > > on different devices you need a protocol between > them, > > which is out of scope. period. > > > > Why? I don't see any compelling reason for this. > Opening up the > architecture in this way sets it up for new kinds of > security threats > and other complications. I don't think we should go > through the > difficulty of having to completely redo the network > access design unless > there are compelling reasons. > > jak > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From pana-request@research.telcordia.com Tue Apr 16 15:21:31 2002 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 PAA06971 for ; Tue, 16 Apr 2002 15:21:30 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GJHaGo011927; Tue, 16 Apr 2002 15:17:36 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 15:17:36 -0400 (EDT) Old-Return-Path: Message-ID: <20020416191723.412.qmail@web20405.mail.yahoo.com> Date: Tue, 16 Apr 2002 12:17:23 -0700 (PDT) From: Reinaldo Penno Subject: Re: Location of authentication agent To: James Kempf , John Schnizlein Cc: pana@research.telcordia.com In-Reply-To: <015d01c1e570$714f3a00$7e6015ac@T23KEMPF> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com I do not agree this access is application level oriented. Today there are examples where the access is controlled on a src ip base to a given subnet. regards, Reinaldo --- James Kempf wrote: > > > I'm not sure I agree the EP should be only on the > > edge. That the example I was trying to articulate > (but > > probably due to my coffee intake I used a lousy > > wording). > > > > There are situation where after the AR you have > some > > walled garden content which have (each of them) > their > > own EP. > > > > I don't think anybody is arguing that content not > have it's own EP. That > is done today when you want to get into Web sites. > There is work such as > MS Passport/Liberty for single sign on in that area, > but it is > application level. > > The issue here is network access and perhaps access > to specific > ports/protocols (e.g. SIP, HTTP). This is a much > larger granularity. > > jak > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From pana-request@research.telcordia.com Tue Apr 16 15:22:47 2002 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 PAA07102 for ; Tue, 16 Apr 2002 15:22:47 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GJJI6J012118; Tue, 16 Apr 2002 15:19:18 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 15:19:18 -0400 (EDT) Old-Return-Path: Message-Id: <4.3.2.7.2.20020416144536.01997468@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Apr 2002 15:16:58 -0400 To: "James Kempf" From: John Schnizlein Subject: Re: Location of authentication agent Cc: "Reinaldo Penno" , In-Reply-To: <01c301c1e575$c49c3370$7e6015ac@T23KEMPF> References: <00b201c1e567$60170c80$7e6015ac@T23KEMPF> <4.3.2.7.2.20020416133848.01913a18@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com IMHO you clipped the context out of my earlier message. I recovered it and copied it at the end of this message. But maybe you wanted a different perspective.. In exactly the same way that the IETF decided not to consider technical modification to Internet protocols to serve the purpose of enabling "wire tapping", it should not be necessary to outline technically what enabling walled gardens involves before deciding that supporting walled gardens is not a goal. I understand walled gardens as Internet-like networks that do not subscribe to the principle of interconnected networks, but instead have a goal of capturing subscribers within an area in which only the provider's content is available. Because this abstract summary is undoubtedly insufficiently clear, an example might help. WAP has been seen as a protocol development that encouraged Internet-like walled gardens for cell-phone use. Instead of connecting the packet-transmission capability of some cell-phones to the Internet, some service providers limited the Web-like access to only their own servers. Market forces appeared to demand gateways from these walled gardens to other content servers on the Internet, but occasionally with modified content. One of the ideas that was prominent in early discussions of URP, then BURP, which has become PANA, was that subscribers would have unrestricted access to a walled garden portion of the Internet, but would need to authenticate and start billing in order to escape the walled garden and reach into the Internet. One of the technical implications drawn from the escape-walled-garden model was that the access control would not be at the edge between subscribers and Internet-like communication, but instead the edge would be defined between walled gardens. This "requirement" seems to have re-emerged when the question of locating the EP at the edge was asked explicitly. Making support for walled gardens a non-goal of the WG (instead of just removing it from the documents reviewed by the IESG) would allow finding other reasons (if they exist) for locating the EP somewhere other than the edge, but would avoid renewing this goal now that the WG has been chartered without it. John At 02:37 PM 4/16/2002, James Kempf wrote: >> Is there some way to decide if rough consensus is to >> make enabling walled gardens out of scope, if not >> an explicit non-goal of the WG? > >Technically, what do you think enabling walled gardens involves? > >IMHO, I see PANA as a simple network transport for EAP between the host >and the edge. At the edge, the AAA protocol (Radius, Diameter) takes >over. What actually happens at the edge depends on what is transported >in the EAP and the ensuing AAA exchange, and thus out of scope of the >WG. Previous context: >>This is just the sort of thing I was afraid of. >>We should find out as soon as possible if the WG >>wants PANA to be designed so that it supports >>walled gardens. The walled garden is about as >>antithetical to the fundamental principles of the >>Internet as anything I have seen. >> >>It is worth noting that the references to enabling >>walled gardens, which received negative comment early >>in the URP - BURP phase of BOFs was removed in the >>charter that got past the IESG. If this support again >>becomes part of the goal of the WG, the IESG should >>again be asked to review its status. >> >>Is there some way to decide if rough consensus is to >>make enabling walled gardens out of scope, if not >>an explicit non-goal of the WG? >> >>John >> >>At 01:20 PM 4/16/2002, Reinaldo Penno wrote: >>>I'm not sure I agree the EP should be only on the >>>edge... >>> >>>There are situation where after the AR you have some >>>walled garden content which have (each of them) their >>>own EP. From pana-request@research.telcordia.com Tue Apr 16 15:27:15 2002 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 PAA07584 for ; Tue, 16 Apr 2002 15:27:14 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GJNk1H012507; Tue, 16 Apr 2002 15:23:46 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 15:23:46 -0400 (EDT) Old-Return-Path: Date: Tue, 16 Apr 2002 16:22:27 -0400 To: James Kempf Cc: Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com Subject: Re: Location of authentication agent Message-ID: <20020416202226.GA659@catfish> Mail-Followup-To: James Kempf , Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com References: <20020415205350.GC3140@catfish> <01af01c1e4b8$ed807a20$7e6015ac@T23KEMPF> <20020415214750.GD3140@catfish> <01d801c1e4c3$0569cce0$7e6015ac@T23KEMPF> <20020415223616.GA3780@catfish> <01f801c1e4c8$b4350410$7e6015ac@T23KEMPF> <20020416113523.GA669@catfish> <008801c1e564$72de0dd0$7e6015ac@T23KEMPF> <20020416182356.GA635@catfish> <017501c1e571$7dc915c0$7e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <017501c1e571$7dc915c0$7e6015ac@T23KEMPF> User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 125 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com I don't think I'm confused. Let me explain more accurately. Your model is also based on the separated model in that it requires external communication between the AA functional entity of an access router network entity and the EP functional entities of other access router network entities. Only the communication between the AA and EP functional entities of the same access router network entity can occur internally. Hence, it seems to me that your co-located model is essentially no different from the separated model. Yet another case is that AA is in the same subnet as the PaC but is not co-located with any ARs on the same subnet. This case is similar to your model in that all EP and AA are placed at the edge. I still don't see a need for coupling AA and EP in access routers in load sharing scenario. Yoshihiro Ohba On Tue, Apr 16, 2002 at 11:06:54AM -0700, James Kempf wrote: > Yoshi, > > You are confusing the functional architecture and the network > architecture. I agree that the AA and EP are two separate functional > entities. I believe that they need to be grouped into the default router > network entity, not that they can be arbitrarily assigned to a network > entity somewhere in the access network. > > These are two very different network architectures. > > jak > > ----- Original Message ----- > From: "Yoshihiro Ohba" > To: "James Kempf" > Cc: "Yoshihiro Ohba" ; "George Tsirtsis" > ; "Hesham Soliman (ERA)" > ; "Alper E. YEGIN" > ; > Sent: Tuesday, April 16, 2002 11:23 AM > Subject: Re: Location of authentication agent > > > > Jim, > > > > Your model is also based on separation of Authentication Agent (AA) > > and Enforcement Point (EP) in that an access router which acts as an > > AA distributes access control rules to other access routers (including > > itself) which are EPs. So you seem to basically agree on the > > separated model. > > > > Yoshihiro Ohba > > > > > > On Tue, Apr 16, 2002 at 09:33:32AM -0700, James Kempf wrote: > > > Whatever is used currently between a NAS and other routers on the > link > > > would work for a PAA as a NAS. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Yoshihiro Ohba" > > > To: "James Kempf" > > > Cc: "Yoshihiro Ohba" ; "George Tsirtsis" > > > ; "Hesham Soliman (ERA)" > > > ; "Alper E. YEGIN" > > > ; > > > Sent: Tuesday, April 16, 2002 4:35 AM > > > Subject: Re: Location of authentication agent > > > > > > > > > > On Mon, Apr 15, 2002 at 02:58:41PM -0700, James Kempf wrote: > > > > > > > > > > > The number of LSAs is not a problem at all since LSAs are > > > dynamically > > > > > > established. The SAs between routers are static ones and that > > > would > > > > > > increase management complexity, I think. > > > > > > > > > > > > > > > > LSA means "Link State Advertisement". It is the reachability > > > information > > > > > that is exchanged between routers. If a network operator is > > > concerned > > > > > about security, they will enable cryptographic security on their > > > router > > > > > traffic. If they are offering public access service and require > > > PANA, > > > > > then it makes a certain amount of sense that they do. > > > > > > > > > > Regarding the SAs being static, what's the problem? The routers > can > > > use > > > > > Kerberos, IKE locally, or AAA to obtain keys, so the key > > > distribution is > > > > > taken care of. Of course, the network operator must enable that, > but > > > the > > > > > same steps are needed for a separate PAA if you want to use > > > Kerberos, > > > > > IKE locally, or AAA for PAA key distribution. > > > > > > > > OK, static SA will not be the problem. Do you assume using the > same > > > > SA for securing Link State Advertisement and securing SNMP? If > you > > > > don't necessarily assume that, I don't still understand why > > > > co-location is simpler than separation. Moreover, it seems to me > that > > > > allowing SNMP 'set' operation mutually among access routers is > > > > difficult to manage. > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Tue Apr 16 15:29:03 2002 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 PAA07759 for ; Tue, 16 Apr 2002 15:29:02 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GJJ5FO012086; Tue, 16 Apr 2002 15:19:05 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 15:19:05 -0400 (EDT) Old-Return-Path: Message-Id: <4.3.2.7.2.20020416140229.0199a650@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Apr 2002 14:15:25 -0400 To: Reinaldo Penno From: John Schnizlein Subject: Re: Location of authentication agent Cc: James Kempf , pana@research.telcordia.com In-Reply-To: <20020416172414.1178.qmail@web20409.mail.yahoo.com> References: <00d901c1e56a$70631400$7e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Choosing an already specified protocol to perform the linkage between the parts that result from splitting the NAS function into EP and AA does not resolve the problem of analyzing its operation and security. The candidates you suggested: COPS, midcom, snmp, have their own problems for distributing configuration parameters with access-control implications. Specifying that another new protocol is required, with its details declared out of scope, as part of resolving PANA seems to recurse on the generation of protocols. Not good. John At 01:24 PM 4/16/2002, Reinaldo Penno wrote: >I agree we need another protocol, but the protocol is >already out there. Actually we have more than one to >choose from: COPS, midcom, snmp... > >Let me ask this. Can't we say PAA and EP can be on >different devices or on the same device. If they are >on different devices you need a protocol between them, >which is out of scope. period. From pana-request@research.telcordia.com Tue Apr 16 16:42:50 2002 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 QAA16520 for ; Tue, 16 Apr 2002 16:42:50 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GKW6FW019510; Tue, 16 Apr 2002 16:32:06 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 16:32:06 -0400 (EDT) Old-Return-Path: Message-ID: <028801c1e585$79995eb0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Reinaldo Penno" , "subir Das" , "John Schnizlein" Cc: "Reinaldo Penno" , References: <20020416191548.157.qmail@web20405.mail.yahoo.com> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 13:29:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > the associated protocol is out of scope and also any > associted security threats. It wouldn't make sense to > say the protocol is out of scope but not the security > threats. > > I'm curious, can you think of an IETF architecture > where an assolciaed protocol is declared out of scope > but people felt the need to deal with the security > threats of this out of scopr protocol? IMHO this seems > weird. > If the WG is to propose a major architectural change, then neither the associated protocol nor the security is out of scope. jak From pana-request@research.telcordia.com Tue Apr 16 16:51:15 2002 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 QAA17616 for ; Tue, 16 Apr 2002 16:51:15 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GKZegB019811; Tue, 16 Apr 2002 16:35:40 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 16:35:40 -0400 (EDT) Old-Return-Path: Message-ID: <02a001c1e585$eecd2f40$7e6015ac@T23KEMPF> From: "James Kempf" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "George Tsirtsis" , "Hesham Soliman \(ERA\)" , "Alper E. YEGIN" , References: <20020415205350.GC3140@catfish> <01af01c1e4b8$ed807a20$7e6015ac@T23KEMPF> <20020415214750.GD3140@catfish> <01d801c1e4c3$0569cce0$7e6015ac@T23KEMPF> <20020415223616.GA3780@catfish> <01f801c1e4c8$b4350410$7e6015ac@T23KEMPF> <20020416113523.GA669@catfish> <008801c1e564$72de0dd0$7e6015ac@T23KEMPF> <20020416182356.GA635@catfish> <017501c1e571$7dc915c0$7e6015ac@T23KEMPF> <20020416202226.GA659@catfish> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 13:33:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit OK, but today the NAS model works fine with multiple access routers. Why does this need to be changed? jak ----- Original Message ----- From: "Yoshihiro Ohba" To: "James Kempf" Cc: "Yoshihiro Ohba" ; "George Tsirtsis" ; "Hesham Soliman (ERA)" ; "Alper E. YEGIN" ; Sent: Tuesday, April 16, 2002 1:22 PM Subject: Re: Location of authentication agent > I don't think I'm confused. Let me explain more accurately. Your > model is also based on the separated model in that it requires > external communication between the AA functional entity of an access > router network entity and the EP functional entities of other access > router network entities. Only the communication between the AA and EP > functional entities of the same access router network entity can occur > internally. Hence, it seems to me that your co-located model is > essentially no different from the separated model. > > Yet another case is that AA is in the same subnet as the PaC but is > not co-located with any ARs on the same subnet. This case is similar > to your model in that all EP and AA are placed at the edge. I still > don't see a need for coupling AA and EP in access routers in load > sharing scenario. > > Yoshihiro Ohba > > > On Tue, Apr 16, 2002 at 11:06:54AM -0700, James Kempf wrote: > > Yoshi, > > > > You are confusing the functional architecture and the network > > architecture. I agree that the AA and EP are two separate functional > > entities. I believe that they need to be grouped into the default router > > network entity, not that they can be arbitrarily assigned to a network > > entity somewhere in the access network. > > > > These are two very different network architectures. > > > > jak > > > > ----- Original Message ----- > > From: "Yoshihiro Ohba" > > To: "James Kempf" > > Cc: "Yoshihiro Ohba" ; "George Tsirtsis" > > ; "Hesham Soliman (ERA)" > > ; "Alper E. YEGIN" > > ; > > Sent: Tuesday, April 16, 2002 11:23 AM > > Subject: Re: Location of authentication agent > > > > > > > Jim, > > > > > > Your model is also based on separation of Authentication Agent (AA) > > > and Enforcement Point (EP) in that an access router which acts as an > > > AA distributes access control rules to other access routers (including > > > itself) which are EPs. So you seem to basically agree on the > > > separated model. > > > > > > Yoshihiro Ohba > > > > > > > > > On Tue, Apr 16, 2002 at 09:33:32AM -0700, James Kempf wrote: > > > > Whatever is used currently between a NAS and other routers on the > > link > > > > would work for a PAA as a NAS. > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Yoshihiro Ohba" > > > > To: "James Kempf" > > > > Cc: "Yoshihiro Ohba" ; "George Tsirtsis" > > > > ; "Hesham Soliman (ERA)" > > > > ; "Alper E. YEGIN" > > > > ; > > > > Sent: Tuesday, April 16, 2002 4:35 AM > > > > Subject: Re: Location of authentication agent > > > > > > > > > > > > > On Mon, Apr 15, 2002 at 02:58:41PM -0700, James Kempf wrote: > > > > > > > > > > > > > The number of LSAs is not a problem at all since LSAs are > > > > dynamically > > > > > > > established. The SAs between routers are static ones and that > > > > would > > > > > > > increase management complexity, I think. > > > > > > > > > > > > > > > > > > > LSA means "Link State Advertisement". It is the reachability > > > > information > > > > > > that is exchanged between routers. If a network operator is > > > > concerned > > > > > > about security, they will enable cryptographic security on their > > > > router > > > > > > traffic. If they are offering public access service and require > > > > PANA, > > > > > > then it makes a certain amount of sense that they do. > > > > > > > > > > > > Regarding the SAs being static, what's the problem? The routers > > can > > > > use > > > > > > Kerberos, IKE locally, or AAA to obtain keys, so the key > > > > distribution is > > > > > > taken care of. Of course, the network operator must enable that, > > but > > > > the > > > > > > same steps are needed for a separate PAA if you want to use > > > > Kerberos, > > > > > > IKE locally, or AAA for PAA key distribution. > > > > > > > > > > OK, static SA will not be the problem. Do you assume using the > > same > > > > > SA for securing Link State Advertisement and securing SNMP? If > > you > > > > > don't necessarily assume that, I don't still understand why > > > > > co-location is simpler than separation. Moreover, it seems to me > > that > > > > > allowing SNMP 'set' operation mutually among access routers is > > > > > difficult to manage. > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Tue Apr 16 16:51:17 2002 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 QAA17627 for ; Tue, 16 Apr 2002 16:51:16 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GKZDFu019786; Tue, 16 Apr 2002 16:35:13 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 16:35:13 -0400 (EDT) Old-Return-Path: Message-ID: <029601c1e585$c0fa3a40$7e6015ac@T23KEMPF> From: "James Kempf" To: "Reinaldo Penno" , "John Schnizlein" Cc: References: <20020416191723.412.qmail@web20405.mail.yahoo.com> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 13:31:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > I do not agree this access is application level > oriented. Today there are examples where the access is > controlled on a src ip base to a given subnet. > Examples? Like I said, if you are talking about opening a hole for a protocol/port like a firewall, then I think there is a place for it. If you are talking about charging for content, then PANA is probably not a good solution. jak From pana-request@research.telcordia.com Tue Apr 16 17:19:50 2002 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 RAA21173 for ; Tue, 16 Apr 2002 17:19:50 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GLD9bX023317; Tue, 16 Apr 2002 17:13:09 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 17:13:09 -0400 (EDT) Old-Return-Path: Date: Tue, 16 Apr 2002 18:11:49 -0400 To: James Kempf Cc: Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com Subject: Re: Location of authentication agent Message-ID: <20020416221149.GC659@catfish> Mail-Followup-To: James Kempf , Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com References: <20020415214750.GD3140@catfish> <01d801c1e4c3$0569cce0$7e6015ac@T23KEMPF> <20020415223616.GA3780@catfish> <01f801c1e4c8$b4350410$7e6015ac@T23KEMPF> <20020416113523.GA669@catfish> <008801c1e564$72de0dd0$7e6015ac@T23KEMPF> <20020416182356.GA635@catfish> <017501c1e571$7dc915c0$7e6015ac@T23KEMPF> <20020416202226.GA659@catfish> <02a001c1e585$eecd2f40$7e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <02a001c1e585$eecd2f40$7e6015ac@T23KEMPF> User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 176 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Tue, Apr 16, 2002 at 01:33:14PM -0700, James Kempf wrote: > OK, but today the NAS model works fine with multiple access routers. Why > does this need to be changed? Today's NAS model is based on PPP where a (PPP) client is always associated with a single AR even there are multiple ARs and thus no external communication occurs among access routers to carry access control information (thus co-locating AA and EP does make much sense). The scenario we are considering is already different from today's NAS model in that a client is to be assiciated with mulitple ARs at the same time and thus external communication inevitable between AA and EP (even in your model as I explained in the previous mail) to carry access control information. In this case, considering separation between AA and EP from the viewpoint of both functional architecture and network architecture makes much sense to me. Yoshihiro Ohba > > jak > > ----- Original Message ----- > From: "Yoshihiro Ohba" > To: "James Kempf" > Cc: "Yoshihiro Ohba" ; "George Tsirtsis" > ; "Hesham Soliman (ERA)" > ; "Alper E. YEGIN" > ; > Sent: Tuesday, April 16, 2002 1:22 PM > Subject: Re: Location of authentication agent > > > > I don't think I'm confused. Let me explain more accurately. Your > > model is also based on the separated model in that it requires > > external communication between the AA functional entity of an access > > router network entity and the EP functional entities of other access > > router network entities. Only the communication between the AA and EP > > functional entities of the same access router network entity can occur > > internally. Hence, it seems to me that your co-located model is > > essentially no different from the separated model. > > > > Yet another case is that AA is in the same subnet as the PaC but is > > not co-located with any ARs on the same subnet. This case is similar > > to your model in that all EP and AA are placed at the edge. I still > > don't see a need for coupling AA and EP in access routers in load > > sharing scenario. > > > > Yoshihiro Ohba > > > > > > On Tue, Apr 16, 2002 at 11:06:54AM -0700, James Kempf wrote: > > > Yoshi, > > > > > > You are confusing the functional architecture and the network > > > architecture. I agree that the AA and EP are two separate functional > > > entities. I believe that they need to be grouped into the default > router > > > network entity, not that they can be arbitrarily assigned to a > network > > > entity somewhere in the access network. > > > > > > These are two very different network architectures. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Yoshihiro Ohba" > > > To: "James Kempf" > > > Cc: "Yoshihiro Ohba" ; "George Tsirtsis" > > > ; "Hesham Soliman (ERA)" > > > ; "Alper E. YEGIN" > > > ; > > > Sent: Tuesday, April 16, 2002 11:23 AM > > > Subject: Re: Location of authentication agent > > > > > > > > > > Jim, > > > > > > > > Your model is also based on separation of Authentication Agent > (AA) > > > > and Enforcement Point (EP) in that an access router which acts as > an > > > > AA distributes access control rules to other access routers > (including > > > > itself) which are EPs. So you seem to basically agree on the > > > > separated model. > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > On Tue, Apr 16, 2002 at 09:33:32AM -0700, James Kempf wrote: > > > > > Whatever is used currently between a NAS and other routers on > the > > > link > > > > > would work for a PAA as a NAS. > > > > > > > > > > jak > > > > > > > > > > ----- Original Message ----- > > > > > From: "Yoshihiro Ohba" > > > > > To: "James Kempf" > > > > > Cc: "Yoshihiro Ohba" ; "George Tsirtsis" > > > > > ; "Hesham Soliman (ERA)" > > > > > ; "Alper E. YEGIN" > > > > > ; > > > > > Sent: Tuesday, April 16, 2002 4:35 AM > > > > > Subject: Re: Location of authentication agent > > > > > > > > > > > > > > > > On Mon, Apr 15, 2002 at 02:58:41PM -0700, James Kempf wrote: > > > > > > > > > > > > > > > The number of LSAs is not a problem at all since LSAs are > > > > > dynamically > > > > > > > > established. The SAs between routers are static ones and > that > > > > > would > > > > > > > > increase management complexity, I think. > > > > > > > > > > > > > > > > > > > > > > LSA means "Link State Advertisement". It is the reachability > > > > > information > > > > > > > that is exchanged between routers. If a network operator is > > > > > concerned > > > > > > > about security, they will enable cryptographic security on > their > > > > > router > > > > > > > traffic. If they are offering public access service and > require > > > > > PANA, > > > > > > > then it makes a certain amount of sense that they do. > > > > > > > > > > > > > > Regarding the SAs being static, what's the problem? The > routers > > > can > > > > > use > > > > > > > Kerberos, IKE locally, or AAA to obtain keys, so the key > > > > > distribution is > > > > > > > taken care of. Of course, the network operator must enable > that, > > > but > > > > > the > > > > > > > same steps are needed for a separate PAA if you want to use > > > > > Kerberos, > > > > > > > IKE locally, or AAA for PAA key distribution. > > > > > > > > > > > > OK, static SA will not be the problem. Do you assume using > the > > > same > > > > > > SA for securing Link State Advertisement and securing SNMP? > If > > > you > > > > > > don't necessarily assume that, I don't still understand why > > > > > > co-location is simpler than separation. Moreover, it seems to > me > > > that > > > > > > allowing SNMP 'set' operation mutually among access routers is > > > > > > difficult to manage. > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Tue Apr 16 18:35:33 2002 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 SAA29082 for ; Tue, 16 Apr 2002 18:35:33 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3GMTooh028873; Tue, 16 Apr 2002 18:29:50 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 18:29:50 -0400 (EDT) Old-Return-Path: Message-ID: <02fe01c1e595$de75e280$7e6015ac@T23KEMPF> From: "James Kempf" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "George Tsirtsis" , "Hesham Soliman \(ERA\)" , "Alper E. YEGIN" , References: <20020415214750.GD3140@catfish> <01d801c1e4c3$0569cce0$7e6015ac@T23KEMPF> <20020415223616.GA3780@catfish> <01f801c1e4c8$b4350410$7e6015ac@T23KEMPF> <20020416113523.GA669@catfish> <008801c1e564$72de0dd0$7e6015ac@T23KEMPF> <20020416182356.GA635@catfish> <017501c1e571$7dc915c0$7e6015ac@T23KEMPF> <20020416202226.GA659@catfish> <02a001c1e585$eecd2f40$7e6015ac@T23KEMPF> <20020416221149.GC659@catfish> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 15:27:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Sorry, I still don't see much point in separating the functional entities just for the point of separation. Having the EP and AA on a single default router, even if EP information needs to get sent to other routers, isolates the decision and enforcement point at the edge, where it belongs. More complication can be introduced via a distributed AAA infrastructure, if needed. For a strong security argument about why enforcement and decision at the edge are a good idea, see my previous email about DoS attackes. jak > On Tue, Apr 16, 2002 at 01:33:14PM -0700, James Kempf wrote: > > OK, but today the NAS model works fine with multiple access routers. Why > > does this need to be changed? > > Today's NAS model is based on PPP where a (PPP) client is always > associated with a single AR even there are multiple ARs and thus > no external communication occurs among access routers to carry > access control information (thus co-locating AA and EP does make > much sense). > > The scenario we are considering is already different from today's NAS > model in that a client is to be assiciated with mulitple ARs at the > same time and thus external communication inevitable between AA and EP > (even in your model as I explained in the previous mail) to carry > access control information. In this case, considering separation > between AA and EP from the viewpoint of both functional architecture > and network architecture makes much sense to me. > > Yoshihiro Ohba > > > > > jak > > > > ----- Original Message ----- > > From: "Yoshihiro Ohba" > > To: "James Kempf" > > Cc: "Yoshihiro Ohba" ; "George Tsirtsis" > > ; "Hesham Soliman (ERA)" > > ; "Alper E. YEGIN" > > ; > > Sent: Tuesday, April 16, 2002 1:22 PM > > Subject: Re: Location of authentication agent > > > > > > > I don't think I'm confused. Let me explain more accurately. Your > > > model is also based on the separated model in that it requires > > > external communication between the AA functional entity of an access > > > router network entity and the EP functional entities of other access > > > router network entities. Only the communication between the AA and EP > > > functional entities of the same access router network entity can occur > > > internally. Hence, it seems to me that your co-located model is > > > essentially no different from the separated model. > > > > > > Yet another case is that AA is in the same subnet as the PaC but is > > > not co-located with any ARs on the same subnet. This case is similar > > > to your model in that all EP and AA are placed at the edge. I still > > > don't see a need for coupling AA and EP in access routers in load > > > sharing scenario. > > > > > > Yoshihiro Ohba > > > > > > > > > On Tue, Apr 16, 2002 at 11:06:54AM -0700, James Kempf wrote: > > > > Yoshi, > > > > > > > > You are confusing the functional architecture and the network > > > > architecture. I agree that the AA and EP are two separate functional > > > > entities. I believe that they need to be grouped into the default > > router > > > > network entity, not that they can be arbitrarily assigned to a > > network > > > > entity somewhere in the access network. > > > > > > > > These are two very different network architectures. > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Yoshihiro Ohba" > > > > To: "James Kempf" > > > > Cc: "Yoshihiro Ohba" ; "George Tsirtsis" > > > > ; "Hesham Soliman (ERA)" > > > > ; "Alper E. YEGIN" > > > > ; > > > > Sent: Tuesday, April 16, 2002 11:23 AM > > > > Subject: Re: Location of authentication agent > > > > > > > > > > > > > Jim, > > > > > > > > > > Your model is also based on separation of Authentication Agent > > (AA) > > > > > and Enforcement Point (EP) in that an access router which acts as > > an > > > > > AA distributes access control rules to other access routers > > (including > > > > > itself) which are EPs. So you seem to basically agree on the > > > > > separated model. > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > On Tue, Apr 16, 2002 at 09:33:32AM -0700, James Kempf wrote: > > > > > > Whatever is used currently between a NAS and other routers on > > the > > > > link > > > > > > would work for a PAA as a NAS. > > > > > > > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Yoshihiro Ohba" > > > > > > To: "James Kempf" > > > > > > Cc: "Yoshihiro Ohba" ; "George Tsirtsis" > > > > > > ; "Hesham Soliman (ERA)" > > > > > > ; "Alper E. YEGIN" > > > > > > ; > > > > > > Sent: Tuesday, April 16, 2002 4:35 AM > > > > > > Subject: Re: Location of authentication agent > > > > > > > > > > > > > > > > > > > On Mon, Apr 15, 2002 at 02:58:41PM -0700, James Kempf wrote: > > > > > > > > > > > > > > > > > The number of LSAs is not a problem at all since LSAs are > > > > > > dynamically > > > > > > > > > established. The SAs between routers are static ones and > > that > > > > > > would > > > > > > > > > increase management complexity, I think. > > > > > > > > > > > > > > > > > > > > > > > > > LSA means "Link State Advertisement". It is the reachability > > > > > > information > > > > > > > > that is exchanged between routers. If a network operator is > > > > > > concerned > > > > > > > > about security, they will enable cryptographic security on > > their > > > > > > router > > > > > > > > traffic. If they are offering public access service and > > require > > > > > > PANA, > > > > > > > > then it makes a certain amount of sense that they do. > > > > > > > > > > > > > > > > Regarding the SAs being static, what's the problem? The > > routers > > > > can > > > > > > use > > > > > > > > Kerberos, IKE locally, or AAA to obtain keys, so the key > > > > > > distribution is > > > > > > > > taken care of. Of course, the network operator must enable > > that, > > > > but > > > > > > the > > > > > > > > same steps are needed for a separate PAA if you want to use > > > > > > Kerberos, > > > > > > > > IKE locally, or AAA for PAA key distribution. > > > > > > > > > > > > > > OK, static SA will not be the problem. Do you assume using > > the > > > > same > > > > > > > SA for securing Link State Advertisement and securing SNMP? > > If > > > > you > > > > > > > don't necessarily assume that, I don't still understand why > > > > > > > co-location is simpler than separation. Moreover, it seems to > > me > > > > that > > > > > > > allowing SNMP 'set' operation mutually among access routers is > > > > > > > difficult to manage. > > > > > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Tue Apr 16 22:29:17 2002 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 WAA23027 for ; Tue, 16 Apr 2002 22:29:12 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3H2N8jD011138; Tue, 16 Apr 2002 22:23:08 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 22:23:08 -0400 (EDT) Old-Return-Path: Message-ID: <050401c1e5b5$a315f110$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: "subir Das" , "James Kempf" Cc: "Hesham Soliman \(ERA\)" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AC68@Esealnt861.al.sw.ericsson.se> <032801c1e4df$a6411e90$736015ac@AlperVAIO> <004401c1e563$10c714d0$7e6015ac@T23KEMPF> <3CBC5316.3CAF772C@research.telcordia.com> Subject: Re: Location of authentication agent Date: Tue, 16 Apr 2002 19:14:42 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0501_01C1E57A.F69D2870" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <4FjrND.A.6tC.MyNv8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is a multi-part message in MIME format. ------=_NextPart_000_0501_01C1E57A.F69D2870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subir, With AAA as the backend: PaC --- EP/PAA ------- AAAlocal ------- AAAhome So, now we'd like to separate EP from PAA, so that PAA can control more than one EP: PaC --- EP --+- PAA ------- AAAlocal ------- AAAhome | --- EP --+ Why can't we do the same by relying on the AAAlocal: PaC --- EP/PAA --+--- AAAlocal ------- AAAhome | --- EP/PAA --+ This was the scenario using AAA as the backend. But we can replace "AAAlocal and AAAhome" with any other authentication backend. AAA is not a must. alper =20 ----- Original Message -----=20 From: "subir Das" To: "James Kempf" Cc: "Alper E. YEGIN" ; "Hesham Soliman (ERA)" = ; Sent: Tuesday, April 16, 2002 9:36 AM Subject: Re: Location of authentication agent > ALper/James, >=20 > Are we assuming that there will be always a AAA infrastructure at the > back end?=20 > Can you draw your model and explain?=20 >=20 > Subir >=20 >=20 >=20 > James Kempf wrote: > >=20 > > > Can't we achive the same by relying on the local AAA server > > > even when PAA is co-located with the access routers? Local > > > AAA server is behind PAAs and it can distribute similar state > > > upon the PaC getting authenticated. > > > > >=20 > > Yes, exactly! This is the point that some of us have been > > trying to make in and since Minneapolis. > >=20 > > The PAA is duplicating a lot of functionality of the AAA server. > > Keeping the PAA co-located with the access router and > > distributing the AAA server is more robust, and is consistent > > with the current NAS architecture. > >=20 > > jak >=20 ------=_NextPart_000_0501_01C1E57A.F69D2870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Subir,
 
With AAA as the = backend:
 
PaC --- EP/PAA ------- AAAlocal = -------=20 AAAhome
 
 
So, now we'd like to separate = EP from PAA,=20 so that
PAA can control more than one=20 EP:
 
PaC --- EP --+- PAA = ------- AAAlocal=20 ------- AAAhome
           &n= bsp;           &nb= sp;  =20 |
    --- EP = --+
 
 
Why can't we do the same by relying on = the=20 AAAlocal:
 
PaC --- EP/PAA --+--- = AAAlocal -------=20 AAAhome
           &n= bsp;           &nb= sp;          =20 |
    --- EP/PAA = --+
 
This was the scenario using AAA as the = backend.=20 But
we can replace "AAAlocal and AAAhome" = with any=20 other
authentication backend. AAA is not a=20 must.
 
 
 
alper
       =20
 
 
----- Original Message -----
From: "subir Das" <subir@research.telcordia.com>
To: "James Kempf" <kempf@docomolabs-usa.com>
Cc: "Alper E. YEGIN" <alper@docomolabs-usa.com>; "Hesham=20 Soliman (ERA)" <hesham.soliman@era.ericsson.se>; <pana@research.telcordia.com>
Sent: Tuesday, April 16, 2002 9:36 = AM
Subject: Re: Location of authentication = agent

> ALper/James,
> =
> Are we=20 assuming that there will be always a AAA infrastructure at the
> = back end?=20
> Can you draw your model and explain?
>
> = Subir
>=20
>
>
> James Kempf wrote:
> >
> > = >=20 Can't we achive the same by relying on the local AAA server
> > = >=20 even when PAA is co-located with the access routers? Local
> > = > AAA=20 server is behind PAAs and it can distribute similar state
> > = > upon=20 the PaC getting authenticated.
> > >
> >
> = > Yes,=20 exactly! This is the point that some of us have been
> > trying = to make=20 in and since Minneapolis.
> >
> > The PAA is = duplicating a=20 lot of functionality of the AAA server.
> > Keeping the PAA = co-located=20 with the access router and
> > distributing the AAA server is = more=20 robust, and is consistent
> > with the current NAS=20 architecture.
> >
>=20 >           &nb= sp;=20 jak
> ------=_NextPart_000_0501_01C1E57A.F69D2870-- From pana-request@research.telcordia.com Tue Apr 16 22:56:14 2002 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 WAA26269 for ; Tue, 16 Apr 2002 22:56:14 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3H2mI3i012550; Tue, 16 Apr 2002 22:48:18 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 22:48:18 -0400 (EDT) Old-Return-Path: Date: Wed, 17 Apr 2002 04:47:09 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Location of authentication agent To: "Hesham Soliman (ERA)" Cc: "'Alper E. YEGIN'" , pana@research.telcordia.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > I like to think of it as starting from the most flexible > solution, then trading flexibility for cost. Given that the BoF is in serious need of focus I'd advocate the opposite approach. Start with the minimal thing. Determine whether or not this minimal thing is useful by folks that think PANA will be useful. Use this to motivate strongly what needs to be added to the minimal thing until there is something which several people think is useful enough to consider including in future products. > There were concerns raised during the meeting about > the 'extra cost' associated with this separation, > but I didn't get a clear idea about where this cost > would come from. So maybe now is a good time to > discuss this. With the above approach the onus for motivating additions would be on those proposing additions, which is likely to lead to less complex solutions. Erik From pana-request@research.telcordia.com Tue Apr 16 22:56:15 2002 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 WAA26282 for ; Tue, 16 Apr 2002 22:56:14 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3H2labx012492; Tue, 16 Apr 2002 22:47:36 -0400 (EDT) Resent-Date: Tue, 16 Apr 2002 22:47:36 -0400 (EDT) Old-Return-Path: Date: Wed, 17 Apr 2002 04:46:49 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Location of authentication agent To: "Hesham Soliman (ERA)" Cc: "'Alper E. YEGIN'" , pana@research.telcordia.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <8clooC.A.EDD.IJOv8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > => More than the ones in the scenarios draft? > Namely: Load sharing, limited free access and > payment after a certain point..etc If I understand "load sharing" I think you can do this with a single PANA entity load sharing over multiple local AAA servers. I've had a hard time understanding the user interface issue in the "payment after a certain point". If an operator is going to provide different rates for "local" and "remote" access with the "remote" being usage-based (either connect time or packets/bytes) I as a user would certainly want to know when I'm being billed based on usage or not including having the ability to terminate the "remote" access. A possible way to make this visible to the user is to use different "login names" (NAI) for the two cases. Thus if I login as "room123@hotel" I get the free local access. To get Internet access I login as "erik.nordmark@sun.com". This would give me the ability to logout from the internet access session and stop being charged. And this doesn't require more than one PANA entity in the network - the PAA could be in the access router (or anywhere else). As I understand the "payment after a certain point" with a split PANA entity it would detect that packets are flowing towards the Internet and at that point ask my device to authenticate itself i.e. the network initiates that action. Will the network also initate loggin me out? Or does the user need to do that? How can the network reliably tell that my device has no existing communication with the Internet? Trying to understand, Erik From pana-request@research.telcordia.com Wed Apr 17 02:55:28 2002 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 CAA11540 for ; Wed, 17 Apr 2002 02:55:27 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3H6mgNK023507; Wed, 17 Apr 2002 02:48:42 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 02:48:42 -0400 (EDT) Old-Return-Path: From: ultimatehgh@yahoo.co.uk To: pana@prodigy.net CC: pana@psnw.com, pana@rcn.com, pana@redsuspenders.com, pana@research.telcordia.com Subject: Aging can be reversed with HGH Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit X-vsuite-type: e Date: Wed, 17 Apr 2002 14:45:37 +0800 Message-ID: X-OriginalArrivalTime: 17 Apr 2002 06:48:25.0256 (UTC) FILETIME=[DF735280:01C1E5DB] X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit


Hello, pana@prodigy.net,

As seen on NBC, CBS, CNN, and even Oprah! The health discovery that actually reverses aging while burning fat, without dieting or exercise! This proven discovery has even been reported on by the New England Journal of Medicine. Forget aging and dieting forever! And it's Guaranteed!


Click here

Would you like to lose weight while you sleep!
No dieting!
No hunger pains!
No Cravings!
No strenuous exercise!
Change your life forever!

1.Body Fat Loss 82% improvement.
2.Wrinkle Reduction 61% improvement.
3.Energy Level 84% improvement.
4.Muscle Strength 88% improvement.
5.Sexual Potency 75% improvement.
6.Emotional Stability 67% improvement.
7.Memory 62% improvement.

100% GUARANTEED!

 

You are receiving this email as a subscriber
to the Opt-In America Mailing List.
To remove yourself from all related maillists,
just Click Here

From pana-request@research.telcordia.com Wed Apr 17 05:06:49 2002 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 FAA12899 for ; Wed, 17 Apr 2002 05:06:49 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3H90I38028322; Wed, 17 Apr 2002 05:00:18 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 05:00:18 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC74@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Alper E. YEGIN'" , "Hesham Soliman (ERA)" , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Wed, 17 Apr 2002 10:59:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > > => Well, it depends on which case you refer to. In the > > load sharing case you need to separate the access > > enforcement from the authentication, otherwise you > > need to authenticate twice (unless there is some > > protocol running between the default routers). > > I don't know if someone has a better idea on how > > to do this. Of course the other question is: Why > > So, the idea is to build a hierarchy of authentication. => No there is no need for any different hierarchy from the configuration you mention. > If the PaC gets authenticated to a PAA behind a set of > access routers, we expect the PAA to automatically > distribute state to all access routers within this PaC's reach. => Does this work for the limited free access scenario? > > does it matter? That is, what is the cost incurred > > in separating the 2 entities and running SNMP/COPS/midcom ...etc > > between them ? > > We'd need to identify what that transport is, and make sure > it satisfies > all the needs of access authentication (transporting keys?) => Yes. > > The PAA discovery would be different as well, and harder I suspect. => No I don't think so. I can't even say it's different because there is no idea presented on how to discover an on-link PAA. Unless you assume (mandate) that every router in the world has to implement a PAA. > > > I like to think of it as starting from the most flexible > > solution, then trading flexibility for cost. > > A better approach is starting simple and seeing if it can > serve the need. If not, expending on it, IMO. => Why is this better? Also I could agree with your approach but it doesn't always work like that. If we make the assumption that the off link PAA is not important for now, people are most likely to ignore the 'for now' part and limit the design to the on-link case. I'm not being paranoid, given the existing division in the WG and existing proposals, this is very likely to happen. Which is why I hate talking about solutions before the requirements are finished. Hesham From pana-request@research.telcordia.com Wed Apr 17 05:12:36 2002 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 FAA12977 for ; Wed, 17 Apr 2002 05:12:36 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3H96LrU028729; Wed, 17 Apr 2002 05:06:21 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 05:06:21 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC77@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , Yoshihiro Ohba Cc: Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Wed, 17 Apr 2002 11:05:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > Whatever is used currently between a NAS and other routers > on the link > would work for a PAA as a NAS. > => Routing protocol security is _completely_ different from other IP security mechanisms. You can't assume that just because RIP or BGP are secure, the two _routers_ would have an SA to secure other traffic. Hesham > ----- Original Message ----- > From: "Yoshihiro Ohba" > To: "James Kempf" > Cc: "Yoshihiro Ohba" ; "George Tsirtsis" > ; "Hesham Soliman (ERA)" > ; "Alper E. YEGIN" > ; > Sent: Tuesday, April 16, 2002 4:35 AM > Subject: Re: Location of authentication agent > > > > On Mon, Apr 15, 2002 at 02:58:41PM -0700, James Kempf wrote: > > > > > > > The number of LSAs is not a problem at all since LSAs are > dynamically > > > > established. The SAs between routers are static ones and that > would > > > > increase management complexity, I think. > > > > > > > > > > LSA means "Link State Advertisement". It is the reachability > information > > > that is exchanged between routers. If a network operator is > concerned > > > about security, they will enable cryptographic security on their > router > > > traffic. If they are offering public access service and require > PANA, > > > then it makes a certain amount of sense that they do. > > > > > > Regarding the SAs being static, what's the problem? The > routers can > use > > > Kerberos, IKE locally, or AAA to obtain keys, so the key > distribution is > > > taken care of. Of course, the network operator must > enable that, but > the > > > same steps are needed for a separate PAA if you want to use > Kerberos, > > > IKE locally, or AAA for PAA key distribution. > > > > OK, static SA will not be the problem. Do you assume > using the same > > SA for securing Link State Advertisement and securing > SNMP? If you > > don't necessarily assume that, I don't still understand why > > co-location is simpler than separation. Moreover, it > seems to me that > > allowing SNMP 'set' operation mutually among access routers is > > difficult to manage. > > > > Yoshihiro Ohba > > > > > > > > > > jak > > > > > > > > > From pana-request@research.telcordia.com Wed Apr 17 05:13:53 2002 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 FAA13003 for ; Wed, 17 Apr 2002 05:13:53 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3H9A5r8028881; Wed, 17 Apr 2002 05:10:05 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 05:10:05 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC78@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Reinaldo Penno'" , James Kempf , subir Das , John Schnizlein Cc: pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Wed, 17 Apr 2002 11:09:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > I agree we need another protocol, but the protocol is > already out there. Actually we have more than one to > choose from: COPS, midcom, snmp... > > Let me ask this. Can't we say PAA and EP can be on > different devices or on the same device. If they are > on different devices you need a protocol between them, > which is out of scope. period. > => Amen! Hesham From pana-request@research.telcordia.com Wed Apr 17 05:27:29 2002 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 FAA13142 for ; Wed, 17 Apr 2002 05:27:29 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3H9FSN4029133; Wed, 17 Apr 2002 05:15:28 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 05:15:28 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC79@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , subir Das Cc: "Alper E. YEGIN" , "Hesham Soliman (ERA)" , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Wed, 17 Apr 2002 11:13:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > It need not be RADIUS or Diameter but there does need to be > something. > => No. A hotel doesn't have to be connected to any AAA infrastructure to give you access to the Internet. A local shared secret will do, like your room number! Hesham From pana-request@research.telcordia.com Wed Apr 17 05:31:12 2002 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 FAA13182 for ; Wed, 17 Apr 2002 05:31:11 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3H9RVIe000319; Wed, 17 Apr 2002 05:27:31 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 05:27:31 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC7A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , "Hesham Soliman (ERA)" Cc: "'Alper E. YEGIN'" , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Wed, 17 Apr 2002 11:27:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <55-A2D.A.3E.CAUv8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > > => More than the ones in the scenarios draft? > > Namely: Load sharing, limited free access and > > payment after a certain point..etc > > If I understand "load sharing" I think you can do this with a > single PANA entity load sharing over multiple local AAA servers. => Is this for the multiple AR case? I didn't understand what you meant. > > I've had a hard time understanding the user interface issue in the > "payment after a certain point". > If an operator is going to provide different rates for > "local" and "remote" > access with the "remote" being usage-based (either connect time or > packets/bytes) I as a user would certainly want to know > when I'm being > billed based on usage or not including having the ability > to terminate > the "remote" access. => Well, if you're in a hotel, they might tell you when you check in (in some way) that you can use the 'local' Hotel servers for free, but anything else you need to pay. The same in an Airport lounge, you could check flight information, or other airport stuff for free, but anything else you need to pay. They can inform you when you check in for example. > > A possible way to make this visible to the user is to use different > "login names" (NAI) for the two cases. => Sure, but you could also have a filter somewhere in the network (where if you cross it, you would have to pay). > Thus if I login as "room123@hotel" I get the free local access. > To get Internet access I login as "erik.nordmark@sun.com". > This would give me the ability to logout from the internet > access session > and stop being charged. > And this doesn't require more than one PANA entity in the > network - the PAA > could be in the access router (or anywhere else). => Yes, that can be done. > > As I understand the "payment after a certain point" with a > split PANA entity > it would detect that packets are flowing towards the Internet and > at that point ask my device to authenticate itself i.e. the network > initiates that action. Will the network also initate loggin > me out? Or > does the user need to do that? => I think that we should have a requirement for network initiated login (useful for re-authentication) and host initiated login. (sorry for the messay terminology but I think you will know what I mean ;) ) This is important regardless of the placement of the PAA IMHO. > How can the network reliably tell that my device has no existing > communication with the Internet? => Hmm, nice question! I suppose it depends on how you're getting charged. If you're charged by time, then your device would have to log you out after DEFAULT_IDLE_TIME perhaps. If you're charged per packet, then there would have to be a router (probably the same PEP that detected you were not authorised to go any further) that counts packets. This is my initial attempt, so there are probably some details missing. Hesham From pana-request@research.telcordia.com Wed Apr 17 05:56:30 2002 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 FAA13517 for ; Wed, 17 Apr 2002 05:56:21 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3H9kHGJ004692; Wed, 17 Apr 2002 05:46:17 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 05:46:17 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC7B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , "Hesham Soliman (ERA)" Cc: "'Alper E. YEGIN'" , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Wed, 17 Apr 2002 11:46:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > > > I like to think of it as starting from the most flexible > > solution, then trading flexibility for cost. > > Given that the BoF is in serious need of focus I'd advocate the > opposite approach. > > Start with the minimal thing. Determine whether or not this > minimal thing > is useful by folks that think PANA will be useful. > Use this to motivate strongly what needs to be added to the > minimal thing > until there is something which several people think is useful enough > to consider including in future products. => I can understand that, but my fear is 2 issues: 1. I just haven't been able to understand why minimal means on-link PAA. I could understand it more if there is a clear decision to eliminate the scenarios that won't work because of this decision. But perhaps people think all scenarios will work anyway. This might be clear by further discussions. 2. People will do the minimum without leaving any room for the additions. I think this is a very likely case. > > > There were concerns raised during the meeting about > > the 'extra cost' associated with this separation, > > but I didn't get a clear idea about where this cost > > would come from. So maybe now is a good time to > > discuss this. > > With the above approach the onus for motivating additions > would be on those > proposing additions, which is likely to lead to less > complex solutions. => We tried to document them in the scenarios draft. So we have 3 options I think: 1. Show that all scenarios work in the 'simple' case. 2. Remove the scenarios that won't work if 1) is not possible. 3. Go with the flexible placement of PAA. I don't mind either option as long as the decision is clear, but the discussion right now is not clear, because some people are saying this is complex and others are saying it's not complex. No reasons, (I haven't finished reading the mails yet though). Obviously I've been doing the same because I can't understand the complexity claim. Hesham > > Erik > From pana-request@research.telcordia.com Wed Apr 17 07:17:51 2002 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 HAA14489 for ; Wed, 17 Apr 2002 07:17:46 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3HBCgOn011034; Wed, 17 Apr 2002 07:12:42 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 07:12:42 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC81@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'John Schnizlein'" , Reinaldo Penno Cc: James Kempf , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Wed, 17 Apr 2002 13:11:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > This is just the sort of thing I was afraid of. > We should find out as soon as possible if the WG > wants PANA to be designed so that it supports > walled gardens. The walled garden is about as > antithetical to the fundamental principles of the > Internet as anything I have seen. => I don't think Reinaldo meant the same thing. Limited free access is another name (probably a bad one too). But it's definitely not a 'walled garden'. Hesham From pana-request@research.telcordia.com Wed Apr 17 08:43:28 2002 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 IAA15936 for ; Wed, 17 Apr 2002 08:43:09 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3HCdQ9q015364; Wed, 17 Apr 2002 08:39:26 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 08:39:26 -0400 (EDT) Old-Return-Path: Message-ID: <20020417123857.809.qmail@web20410.mail.yahoo.com> Date: Wed, 17 Apr 2002 05:38:57 -0700 (PDT) From: Reinaldo Penno Subject: Re: Location of authentication agent To: James Kempf , subir Das , John Schnizlein Cc: Reinaldo Penno , pana@research.telcordia.com In-Reply-To: <028801c1e585$79995eb0$7e6015ac@T23KEMPF> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Hello James, I only consider a major archiotectural change anything that changes the PANA protocol or entities per se. Saying in a certain scenario you need to use another protocol which is out of scope I do not consider a major architectural change. Reinaldo --- James Kempf wrote: > > the associated protocol is out of scope and also > any > > associted security threats. It wouldn't make sense > to > > say the protocol is out of scope but not the > security > > threats. > > > > I'm curious, can you think of an IETF architecture > > where an assolciaed protocol is declared out of > scope > > but people felt the need to deal with the security > > threats of this out of scopr protocol? IMHO this > seems > > weird. > > > > If the WG is to propose a major architectural > change, then neither the > associated protocol nor the security is out of > scope. > > jak > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From pana-request@research.telcordia.com Wed Apr 17 08:55:08 2002 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 IAA16127 for ; Wed, 17 Apr 2002 08:55:07 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3HCp7AV016011; Wed, 17 Apr 2002 08:51:07 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 08:51:07 -0400 (EDT) Old-Return-Path: Date: Wed, 17 Apr 2002 09:49:42 -0400 To: "Alper E. YEGIN" Cc: subir Das , James Kempf , "Hesham Soliman (ERA)" , pana@research.telcordia.com Subject: Re: Location of authentication agent Message-ID: <20020417134941.GA1767@catfish> Mail-Followup-To: "Alper E. YEGIN" , subir Das , James Kempf , "Hesham Soliman (ERA)" , pana@research.telcordia.com References: <4DA6EA82906FD511BE2F00508BCF053802C6AC68@Esealnt861.al.sw.ericsson.se> <032801c1e4df$a6411e90$736015ac@AlperVAIO> <004401c1e563$10c714d0$7e6015ac@T23KEMPF> <3CBC5316.3CAF772C@research.telcordia.com> <050401c1e5b5$a315f110$736015ac@AlperVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <050401c1e5b5$a315f110$736015ac@AlperVAIO> User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 79 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Tue, Apr 16, 2002 at 07:14:42PM -0700, Alper E. YEGIN wrote: > Subir, > > With AAA as the backend: > > PaC --- EP/PAA ------- AAAlocal ------- AAAhome > > > So, now we'd like to separate EP from PAA, so that > PAA can control more than one EP: > > PaC --- EP --+- PAA ------- AAAlocal ------- AAAhome > | > --- EP --+ > > > Why can't we do the same by relying on the AAAlocal: > > PaC --- EP/PAA --+--- AAAlocal ------- AAAhome > | > --- EP/PAA --+ > > This was the scenario using AAA as the backend. But > we can replace "AAAlocal and AAAhome" with any other > authentication backend. AAA is not a must. We cannot always expect for all the AAA signaling messages originated from those PAAs to pass through the same AAAlocal when there are multiple AAA local proxies, since AAA message routing topology can be arbitrary. In an extreme case, two AAA messages originated from different PAAs can take completely different paths to reach the AAAhome. Yoshihiro Ohba > > > > alper > > > > ----- Original Message ----- > From: "subir Das" > To: "James Kempf" > Cc: "Alper E. YEGIN" ; "Hesham Soliman (ERA)" ; > Sent: Tuesday, April 16, 2002 9:36 AM > Subject: Re: Location of authentication agent > > > > ALper/James, > > > > Are we assuming that there will be always a AAA infrastructure at the > > back end? > > Can you draw your model and explain? > > > > Subir > > > > > > > > James Kempf wrote: > > > > > > > Can't we achive the same by relying on the local AAA server > > > > even when PAA is co-located with the access routers? Local > > > > AAA server is behind PAAs and it can distribute similar state > > > > upon the PaC getting authenticated. > > > > > > > > > > Yes, exactly! This is the point that some of us have been > > > trying to make in and since Minneapolis. > > > > > > The PAA is duplicating a lot of functionality of the AAA server. > > > Keeping the PAA co-located with the access router and > > > distributing the AAA server is more robust, and is consistent > > > with the current NAS architecture. > > > > > > jak > > From pana-request@research.telcordia.com Wed Apr 17 10:08:22 2002 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 KAA18706 for ; Wed, 17 Apr 2002 10:08:22 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3HE3HPI022850; Wed, 17 Apr 2002 10:03:17 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 10:03:17 -0400 (EDT) Old-Return-Path: Date: Wed, 17 Apr 2002 11:01:50 -0400 To: James Kempf Cc: Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com Subject: Re: Location of authentication agent Message-ID: <20020417150150.GC1767@catfish> Mail-Followup-To: James Kempf , Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com References: <20020415223616.GA3780@catfish> <01f801c1e4c8$b4350410$7e6015ac@T23KEMPF> <20020416113523.GA669@catfish> <008801c1e564$72de0dd0$7e6015ac@T23KEMPF> <20020416182356.GA635@catfish> <017501c1e571$7dc915c0$7e6015ac@T23KEMPF> <20020416202226.GA659@catfish> <02a001c1e585$eecd2f40$7e6015ac@T23KEMPF> <20020416221149.GC659@catfish> <02fe01c1e595$de75e280$7e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <02fe01c1e595$de75e280$7e6015ac@T23KEMPF> User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 107 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <7AQvpC.A.6kF.kCYv8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Tue, Apr 16, 2002 at 03:27:18PM -0700, James Kempf wrote: > Sorry, I still don't see much point in separating the functional > entities just for the point of separation. > Having the EP and AA on a single default router, even if EP information > needs to get sent to other routers, isolates the decision and > enforcement point at the edge, where it belongs. More complication can > be introduced via a distributed AAA infrastructure, if needed. > > For a strong security argument about why enforcement and decision at the > edge are a good idea, see my previous email about DoS attackes. When we consider putting both EP and AA at the edge, we still have design choices. The first one is your model, which is: AR1[AA+EP] AR2[AA+EP] AR3[AA+EP] In this model each AR needs to support PANA, EAP and secure SNMP with firewall MIB The other one is the model that I mentioed "Yet another case" in my previous mail, which is: AA(at the edge subnet) AR1[EP] AR2[EP] AR3[EP] I think the security threat is the same for both models in that all AAs and EPs are in the edge subnet. The latter model makes the cost of the ARs lower than your model, since ARs does not have to support EAP and PANA at all. Those ARs just need to support secure SNMP with firewall MIB. So separating AA and EP makes sense when we consider implementation cost even if AA and EP are located at the edge. Yoshihiro Ohba > > jak > > > On Tue, Apr 16, 2002 at 01:33:14PM -0700, James Kempf wrote: > > > OK, but today the NAS model works fine with multiple access routers. > Why > > > does this need to be changed? > > > > Today's NAS model is based on PPP where a (PPP) client is always > > associated with a single AR even there are multiple ARs and thus > > no external communication occurs among access routers to carry > > access control information (thus co-locating AA and EP does make > > much sense). > > > > The scenario we are considering is already different from today's NAS > > model in that a client is to be assiciated with mulitple ARs at the > > same time and thus external communication inevitable between AA and EP > > (even in your model as I explained in the previous mail) to carry > > access control information. In this case, considering separation > > between AA and EP from the viewpoint of both functional architecture > > and network architecture makes much sense to me. > > > > Yoshihiro Ohba > > > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Yoshihiro Ohba" > > > To: "James Kempf" > > > Cc: "Yoshihiro Ohba" ; "George Tsirtsis" > > > ; "Hesham Soliman (ERA)" > > > ; "Alper E. YEGIN" > > > ; > > > Sent: Tuesday, April 16, 2002 1:22 PM > > > Subject: Re: Location of authentication agent > > > > > > > > > > I don't think I'm confused. Let me explain more accurately. Your > > > > model is also based on the separated model in that it requires > > > > external communication between the AA functional entity of an > access > > > > router network entity and the EP functional entities of other > access > > > > router network entities. Only the communication between the AA > and EP > > > > functional entities of the same access router network entity can > occur > > > > internally. Hence, it seems to me that your co-located model is > > > > essentially no different from the separated model. > > > > > > > > Yet another case is that AA is in the same subnet as the PaC but > is > > > > not co-located with any ARs on the same subnet. This case is > similar > > > > to your model in that all EP and AA are placed at the edge. I > still > > > > don't see a need for coupling AA and EP in access routers in load > > > > sharing scenario. > > > > > > > > Yoshihiro Ohba > > > > > > > > From pana-request@research.telcordia.com Wed Apr 17 10:27:41 2002 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 KAA20095 for ; Wed, 17 Apr 2002 10:27:41 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3HEMFlC025043; Wed, 17 Apr 2002 10:22:15 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 10:22:15 -0400 (EDT) Old-Return-Path: Date: Wed, 17 Apr 2002 11:20:50 -0400 To: James Kempf Cc: Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com Subject: Re: Location of authentication agent Message-ID: <20020417152050.GD1767@catfish> Mail-Followup-To: James Kempf , Yoshihiro Ohba , George Tsirtsis , "Hesham Soliman (ERA)" , "Alper E. YEGIN" , pana@research.telcordia.com References: <20020415223616.GA3780@catfish> <01f801c1e4c8$b4350410$7e6015ac@T23KEMPF> <20020416113523.GA669@catfish> <008801c1e564$72de0dd0$7e6015ac@T23KEMPF> <20020416182356.GA635@catfish> <017501c1e571$7dc915c0$7e6015ac@T23KEMPF> <20020416202226.GA659@catfish> <02a001c1e585$eecd2f40$7e6015ac@T23KEMPF> <20020416221149.GC659@catfish> <02fe01c1e595$de75e280$7e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <02fe01c1e595$de75e280$7e6015ac@T23KEMPF> User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 15 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Tue, Apr 16, 2002 at 03:27:18PM -0700, James Kempf wrote: > For a strong security argument about why enforcement and decision at the > edge are a good idea, see my previous email about DoS attackes. > > jak > BTW, I still don't understand what is the security threat that is said to occur when putting AA behind ARs. I think if the firewall parameters for the ARs are set in such a way that they only pass through PANA messages by default, the level of security is equivalent to the co-located model. Yoshihiro Ohba From pana-request@research.telcordia.com Wed Apr 17 11:27:16 2002 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 LAA22947 for ; Wed, 17 Apr 2002 11:27:16 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3HENeDO025466; Wed, 17 Apr 2002 10:23:40 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 10:23:40 -0400 (EDT) Old-Return-Path: Message-ID: <3CBD790D.27646FA1@research.telcordia.com> Date: Wed, 17 Apr 2002 09:30:53 -0400 From: subir Das X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alper E. YEGIN" CC: James Kempf , "Hesham Soliman (ERA)" , pana@research.telcordia.com Subject: Re: Location of authentication agent References: <4DA6EA82906FD511BE2F00508BCF053802C6AC68@Esealnt861.al.sw.ericsson.se> <032801c1e4df$a6411e90$736015ac@AlperVAIO> <004401c1e563$10c714d0$7e6015ac@T23KEMPF> <3CBC5316.3CAF772C@research.telcordia.com> <050401c1e5b5$a315f110$736015ac@AlperVAIO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Alper, > "Alper E. YEGIN" wrote: > > Subir, > > With AAA as the backend: > > PaC --- EP/PAA ------- AAAlocal ------- AAAhome For limited free access we are discussing the following model: PaC--- Edge ---- EP/PAA----- AS According to my understanding, your model and our model are same in this case. > So, now we'd like to separate EP from PAA, so that > PAA can control more than one EP: > > PaC --- EP --+- PAA ------- AAAlocal ------- AAAhome > | > --- EP --+ > > > Why can't we do the same by relying on the AAAlocal: > > PaC --- EP/PAA --+--- AAAlocal ------- AAAhome > | > --- EP/PAA --+ For Load sharing: PaC---- Edge/EP --- PAA ----- AS | ---- Edge/EP------+ This is similar to your top one. So for load sharing people have different views. Please see Yoshihiro's mail why cann't we achieve the usage scenario as described when EP and PAA are colocated? Now we have to figure out which model brings complexity. Apparently, I don't see much cost difference: you need N PAAs, but other people need one PAA and another protocol. Of course we have to consider the security aspects. As I mentioned earlier, without having a better understanding we should not rule out other options at this time. I agree that we should solve the simple case first, however, if we know additional requirements at the beginning it will be always better IMHO. Subir > > This was the scenario using AAA as the backend. But > we can replace "AAAlocal and AAAhome" with any other > authentication backend. AAA is not a must. > > > > alper > > > > ----- Original Message ----- > From: "subir Das" > To: "James Kempf" > Cc: "Alper E. YEGIN" ; "Hesham Soliman > (ERA)" ; > Sent: Tuesday, April 16, 2002 9:36 AM > Subject: Re: Location of authentication agent > > > ALper/James, > > > > Are we assuming that there will be always a AAA infrastructure at > the > > back end? > > Can you draw your model and explain? > > > > Subir > > > > > > > > James Kempf wrote: > > > > > > > Can't we achive the same by relying on the local AAA server > > > > even when PAA is co-located with the access routers? Local > > > > AAA server is behind PAAs and it can distribute similar state > > > > upon the PaC getting authenticated. > > > > > > > > > > Yes, exactly! This is the point that some of us have been > > > trying to make in and since Minneapolis. > > > > > > The PAA is duplicating a lot of functionality of the AAA server. > > > Keeping the PAA co-located with the access router and > > > distributing the AAA server is more robust, and is consistent > > > with the current NAS architecture. > > > > > > jak > > From pana-request@research.telcordia.com Wed Apr 17 15:29:00 2002 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 PAA03109 for ; Wed, 17 Apr 2002 15:28:37 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3HJNjI0025777; Wed, 17 Apr 2002 15:23:45 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 15:23:45 -0400 (EDT) Old-Return-Path: Message-ID: <019a01c1e644$5f130090$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Hesham Soliman \(ERA\)" , "'Erik Nordmark'" Cc: References: <4DA6EA82906FD511BE2F00508BCF053802C6AC7B@Esealnt861.al.sw.ericsson.se> Subject: Re: Location of authentication agent Date: Wed, 17 Apr 2002 12:16:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit The minimal PANA can be designed when: 1- PAA is on the same subnet as PaC, and 2- we assume PAA is co-located with EP. [1] makes the discovery real easy. It can be as simple as picking a link-scoped multicast address, for example. Also, this way PaC can do PANA before or after IP address allocation. With [2], we don't need another transport between PAA and EP. If people still would like to separate two when they deploy it (although they are on the same subnet), they can pick a protocol or design their own and do that. By stating [2], we can clearly leave this transport outside the scope of this WG. [1]+[2] gives you the model people are familiar with, widely used today. Having said this is the minimal PANA, now we need to look at if there are useful scenarios that cannot be handled with this protocol. > => I can understand that, but my fear is > 2 issues: > > 1. I just haven't been able to understand why > minimal means on-link PAA. I could understand See above. > it more if there is a clear decision to eliminate > the scenarios that won't work because of this > decision. But perhaps people think all scenarios > will work anyway. This might be clear by further > discussions. Yes, this is what we need. Goal is not to eliminate scenarios, it is to see if we need to eliminate any by choosing this minimal PANA. > > 2. People will do the minimum without leaving any > room for the additions. I think this is a very > likely case. We need to look at what scenarios are not satisfied with this design. > > > > > > There were concerns raised during the meeting about > > > the 'extra cost' associated with this separation, > > > but I didn't get a clear idea about where this cost > > > would come from. So maybe now is a good time to > > > discuss this. > > > > With the above approach the onus for motivating additions > > would be on those > > proposing additions, which is likely to lead to less > > complex solutions. > > => We tried to document them in the scenarios draft. > So we have 3 options I think: > > 1. Show that all scenarios work in the 'simple' > case. 1. Show the scenarios that do not work in the simple case. This should be the first step. > 2. Remove the scenarios that won't work if 1) > is not possible. > 3. Go with the flexible placement of PAA. > > I don't mind either option as long as the decision > is clear, but the discussion right now is not > clear, because some people are saying this is > complex and others are saying it's not complex. > No reasons, (I haven't finished reading the mails > yet though). > Obviously I've been doing the same because I can't > understand the complexity claim. alper > > Hesham > > > > > > Erik > > > From pana-request@research.telcordia.com Wed Apr 17 15:37:35 2002 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 PAA03564 for ; Wed, 17 Apr 2002 15:37:34 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3HJVXCd026223; Wed, 17 Apr 2002 15:31:33 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 15:31:33 -0400 (EDT) Old-Return-Path: Message-ID: <01a601c1e645$3a235310$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Yoshihiro Ohba" Cc: "subir Das" , "James Kempf" , "Hesham Soliman \(ERA\)" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AC68@Esealnt861.al.sw.ericsson.se> <032801c1e4df$a6411e90$736015ac@AlperVAIO> <004401c1e563$10c714d0$7e6015ac@T23KEMPF> <3CBC5316.3CAF772C@research.telcordia.com> <050401c1e5b5$a315f110$736015ac@AlperVAIO> <20020417134941.GA1767@catfish> Subject: Re: Location of authentication agent Date: Wed, 17 Apr 2002 12:22:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Yoshihiro, > We cannot always expect for all the AAA signaling messages > originated from those PAAs to pass through the same AAAlocal > when there are multiple AAA local proxies, since AAA message > routing topology can be arbitrary. In an extreme case, > two AAA messages originated from different PAAs can take > completely different paths to reach the AAAhome. But, this is a network design issue. If the operator wants the feature (one authentication, multiple EPs updated), then the network should be designed in a hierarchical way. Same with the separate EP and AA. All the EPs that need to be updated simultaneously need to be (logically) attached to the same AA. alper From pana-request@research.telcordia.com Wed Apr 17 16:41:13 2002 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 QAA06758 for ; Wed, 17 Apr 2002 16:41:12 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3HKWQ2O002011; Wed, 17 Apr 2002 16:32:26 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 16:32:26 -0400 (EDT) Old-Return-Path: Date: Wed, 17 Apr 2002 16:32:06 -0400 To: "Alper E. YEGIN" Cc: Yoshihiro Ohba , subir Das , James Kempf , "Hesham Soliman (ERA)" , pana@research.telcordia.com Subject: Re: Location of authentication agent Message-ID: <20020417203206.GA688@catfish> Mail-Followup-To: "Alper E. YEGIN" , Yoshihiro Ohba , subir Das , James Kempf , "Hesham Soliman (ERA)" , pana@research.telcordia.com References: <4DA6EA82906FD511BE2F00508BCF053802C6AC68@Esealnt861.al.sw.ericsson.se> <032801c1e4df$a6411e90$736015ac@AlperVAIO> <004401c1e563$10c714d0$7e6015ac@T23KEMPF> <3CBC5316.3CAF772C@research.telcordia.com> <050401c1e5b5$a315f110$736015ac@AlperVAIO> <20020417134941.GA1767@catfish> <01a601c1e645$3a235310$736015ac@AlperVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <01a601c1e645$3a235310$736015ac@AlperVAIO> User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 28 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com OK. My next question is, can the proposed solution be supported without changing the current Diameter NASREQ application specification? If it can't, I would say that it does not fit the existing NAS model and thus would be problematic. Yoshihiro Ohba On Wed, Apr 17, 2002 at 12:22:32PM -0700, Alper E. YEGIN wrote: > Yoshihiro, > > > We cannot always expect for all the AAA signaling messages > > originated from those PAAs to pass through the same AAAlocal > > when there are multiple AAA local proxies, since AAA message > > routing topology can be arbitrary. In an extreme case, > > two AAA messages originated from different PAAs can take > > completely different paths to reach the AAAhome. > > But, this is a network design issue. If the operator wants > the feature (one authentication, multiple EPs updated), then > the network should be designed in a hierarchical way. > > Same with the separate EP and AA. All the EPs that need > to be updated simultaneously need to be (logically) attached to the > same AA. > > alper > > From pana-request@research.telcordia.com Wed Apr 17 16:49:38 2002 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 QAA07208 for ; Wed, 17 Apr 2002 16:49:38 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3HKkEuR003417; Wed, 17 Apr 2002 16:46:14 -0400 (EDT) Resent-Date: Wed, 17 Apr 2002 16:46:14 -0400 (EDT) Old-Return-Path: Date: Wed, 17 Apr 2002 16:45:58 -0400 To: "Alper E. YEGIN" Cc: "Hesham Soliman (ERA)" , "'Erik Nordmark'" , pana@research.telcordia.com Subject: Re: Location of authentication agent Message-ID: <20020417204558.GB688@catfish> Mail-Followup-To: "Alper E. YEGIN" , "Hesham Soliman (ERA)" , 'Erik Nordmark' , pana@research.telcordia.com References: <4DA6EA82906FD511BE2F00508BCF053802C6AC7B@Esealnt861.al.sw.ericsson.se> <019a01c1e644$5f130090$736015ac@AlperVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <019a01c1e644$5f130090$736015ac@AlperVAIO> User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 117 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com On Wed, Apr 17, 2002 at 12:16:26PM -0700, Alper E. YEGIN wrote: > > The minimal PANA can be designed when: > > 1- PAA is on the same subnet as PaC, and > 2- we assume PAA is co-located with EP. > > [1] makes the discovery real easy. It can be as > simple as picking a link-scoped multicast address, > for example. I agree. > > Also, this way PaC can do PANA before or after > IP address allocation. > > With [2], we don't need another transport between > PAA and EP. If people still would like to separate two > when they deploy it (although they are on the same subnet), > they can pick a protocol or design their own and do that. > By stating [2], we can clearly leave this transport outside > the scope of this WG. This is incorrect for the load sharing case in which another protocol is necessary to transfer access control parameters to multiple access routers, regardless of the location of AA. So, the only advantage I can see so far for putting AA on AR is that it makes AA discovery easier. Yoshihiro Ohba > > [1]+[2] gives you the model people are familiar with, > widely used today. > > Having said this is the minimal PANA, now we need to look > at if there are useful scenarios that cannot be handled with > this protocol. > > > > => I can understand that, but my fear is > > 2 issues: > > > > 1. I just haven't been able to understand why > > minimal means on-link PAA. I could understand > > See above. > > > it more if there is a clear decision to eliminate > > the scenarios that won't work because of this > > decision. But perhaps people think all scenarios > > will work anyway. This might be clear by further > > discussions. > > Yes, this is what we need. Goal is not to eliminate scenarios, > it is to see if we need to eliminate any by choosing this minimal > PANA. > > > > > 2. People will do the minimum without leaving any > > room for the additions. I think this is a very > > likely case. > > We need to look at what scenarios are not satisfied with > this design. > > > > > > > > > > There were concerns raised during the meeting about > > > > the 'extra cost' associated with this separation, > > > > but I didn't get a clear idea about where this cost > > > > would come from. So maybe now is a good time to > > > > discuss this. > > > > > > With the above approach the onus for motivating additions > > > would be on those > > > proposing additions, which is likely to lead to less > > > complex solutions. > > > > => We tried to document them in the scenarios draft. > > So we have 3 options I think: > > > > 1. Show that all scenarios work in the 'simple' > > case. > > 1. Show the scenarios that do not work in the simple case. > This should be the first step. > > > 2. Remove the scenarios that won't work if 1) > > is not possible. > > 3. Go with the flexible placement of PAA. > > > > I don't mind either option as long as the decision > > is clear, but the discussion right now is not > > clear, because some people are saying this is > > complex and others are saying it's not complex. > > No reasons, (I haven't finished reading the mails > > yet though). > > Obviously I've been doing the same because I can't > > understand the complexity claim. > > > > alper > > > > > Hesham > > > > > > > > > > Erik > > > > > > > From pana-request@research.telcordia.com Thu Apr 18 07:46:09 2002 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 HAA01637 for ; Thu, 18 Apr 2002 07:46:09 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3IBdcTP001314; Thu, 18 Apr 2002 07:39:38 -0400 (EDT) Resent-Date: Thu, 18 Apr 2002 07:39:38 -0400 (EDT) Old-Return-Path: Message-ID: <20020418113814.75812.qmail@web20406.mail.yahoo.com> Date: Thu, 18 Apr 2002 04:38:14 -0700 (PDT) From: Reinaldo Penno Subject: Re: Location of authentication agent To: Yoshihiro Ohba , "Alper E. YEGIN" Cc: "Hesham Soliman \(ERA\)" , "'Erik Nordmark'" , pana@research.telcordia.com In-Reply-To: <20020417204558.GB688@catfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <4MxWsC.A.aU.6Brv8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com I think the "complexity" problem was already discussed and very good arguments against/pro it were presented by Yoshi, Hesham, James and others. But complexity is a very subject term and we might as well be here on this same thread 1 year from now. On the other hand we want the WG to be focused on real problems. So, I propose to forget the "complexity" discussion. The right questions are. "Do we have *real* deployment scenarios that will need this or not?" If the answer is yes then we need to find a away of accomodating this on the architecture. Maybe the easiest way is declaring this associated protocol out of scope and get on with life. As I said there several protocols to choose from and they all belong to other WGs. The other alternative is to start discussing the associated protocol and its implication on our architecture. But if the protocol is midcom/COPS/whatever, for instance, it might be a waste of time doing this since this discussion is already taking place on some other WG. regards, Reinaldo --- Yoshihiro Ohba wrote: > On Wed, Apr 17, 2002 at 12:16:26PM -0700, Alper E. > YEGIN wrote: > > > > The minimal PANA can be designed when: > > > > 1- PAA is on the same subnet as PaC, and > > 2- we assume PAA is co-located with EP. > > > > [1] makes the discovery real easy. It can be as > > simple as picking a link-scoped multicast address, > > for example. > > I agree. > > > > > Also, this way PaC can do PANA before or after > > IP address allocation. > > > > With [2], we don't need another transport between > > PAA and EP. If people still would like to separate > two > > when they deploy it (although they are on the same > subnet), > > they can pick a protocol or design their own and > do that. > > By stating [2], we can clearly leave this > transport outside > > the scope of this WG. > > This is incorrect for the load sharing case in which > another protocol > is necessary to transfer access control parameters > to multiple access > routers, regardless of the location of AA. > > So, the only advantage I can see so far for putting > AA on AR is that > it makes AA discovery easier. > > Yoshihiro Ohba > > > > > [1]+[2] gives you the model people are familiar > with, > > widely used today. > > > > Having said this is the minimal PANA, now we need > to look > > at if there are useful scenarios that cannot be > handled with > > this protocol. > > > > > > > => I can understand that, but my fear is > > > 2 issues: > > > > > > 1. I just haven't been able to understand why > > > minimal means on-link PAA. I could understand > > > > > See above. > > > > > it more if there is a clear decision to > eliminate > > > the scenarios that won't work because of this > > > > decision. But perhaps people think all > scenarios > > > will work anyway. This might be clear by > further > > > discussions. > > > > Yes, this is what we need. Goal is not to > eliminate scenarios, > > it is to see if we need to eliminate any by > choosing this minimal > > PANA. > > > > > > > > 2. People will do the minimum without leaving > any > > > room for the additions. I think this is a > very > > > likely case. > > > > We need to look at what scenarios are not > satisfied with > > this design. > > > > > > > > > > > > > > There were concerns raised during the > meeting about > > > > > the 'extra cost' associated with this > separation, > > > > > but I didn't get a clear idea about where > this cost > > > > > would come from. So maybe now is a good > time to > > > > > discuss this. > > > > > > > > With the above approach the onus for > motivating additions > > > > would be on those > > > > proposing additions, which is likely to lead > to less > > > > complex solutions. > > > > > > => We tried to document them in the scenarios > draft. > > > So we have 3 options I think: > > > > > > 1. Show that all scenarios work in the 'simple' > > > case. > > > > 1. Show the scenarios that do not work in the > simple case. > > This should be the first step. > > > > > 2. Remove the scenarios that won't work if 1) > > > is not possible. > > > 3. Go with the flexible placement of PAA. > > > > > > I don't mind either option as long as the > decision > > > is clear, but the discussion right now is not > > > clear, because some people are saying this is > > > complex and others are saying it's not complex. > > > No reasons, (I haven't finished reading the > mails > > > yet though). > > > Obviously I've been doing the same because I > can't > > > understand the complexity claim. > > > > > > > > alper > > > > > > > > Hesham > > > > > > > > > > > > > > Erik > > > > > > > > > > > > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From pana-request@research.telcordia.com Thu Apr 18 17:16:15 2002 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 RAA23236 for ; Thu, 18 Apr 2002 17:16:15 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3IL5NTp026949; Thu, 18 Apr 2002 17:05:23 -0400 (EDT) Resent-Date: Thu, 18 Apr 2002 17:05:23 -0400 (EDT) Old-Return-Path: content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Scope of PANA WG X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 18 Apr 2002 16:05:02 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12CAA@daebe007.NOE.Nokia.com> Thread-Topic: Scope of PANA WG Thread-Index: AcHnHLO5HabjCFLaEdax0wAAhj/HZA== From: To: Cc: , X-OriginalArrivalTime: 18 Apr 2002 21:05:03.0108 (UTC) FILETIME=[B55EE440:01C1E71C] X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA23236 Hello, As part of the exercise aimed at developing a narrow focus for the PANA WG, below is the minimum scope writeup for the PANA WG. Please review and comment. We would like to especially hear any opinions if they think that the scope of the WG is too narrow (as a result of this exercise) for it to be useful in scenarios they may have had in mind and this protocol would be applicable for. -WG Chairs Minimal Scope of PANA ===================== IP based hosts that connect or attach to the Internet via an access network need to provide their credentials and be authenticated before being authorized to access the network. PANA aims to provide a layer two agnostic protocol that allows a host to be authenticated for network access. A messaging protocol which is of type client-server allows authentication payload to be carried between the host/client (PaC) and an agent/server (PAA) in the access network. The PAA is on the same IP subnet as the PaC. The PAA itself may interface with other AAA backend infrastructures for authenticating and authorizing the service being requested by the host. The PAA enables access control to be enforced at the appropriate enforcement point in the network. A non-goal of PANA: It does not define any new authentication protocol. It is essentially a transport protocol between a host and an agent in an access network for EAP. V: 0.2 P.S: For people who may be still have questions about PANA, there is also an FAQ which has been posted to the list. From pana-request@research.telcordia.com Thu Apr 18 17:26:24 2002 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 RAA23461 for ; Thu, 18 Apr 2002 17:26:23 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3ILI7iK028098; Thu, 18 Apr 2002 17:18:07 -0400 (EDT) Resent-Date: Thu, 18 Apr 2002 17:18:07 -0400 (EDT) Old-Return-Path: Message-ID: <028501c1e71d$855bd360$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Pana \(E-mail\)" Cc: "Erik Nordmark" , Subject: PANA FAQ Date: Thu, 18 Apr 2002 14:10:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Hello, Along with the minimum scope write-up sent earlier, we also prepared this FAQ to answer commonly asked questions... Please see if this already answers the questions you might have. - WG Chairs PANA FAQ ========= Q1: What is PANA? A: PANA is - a layer two agnostic network layer messaging protocol for authenticating IP hosts for network access - a transport protocol for authentication payload (EAP) between a client (IP based) and a server (agent) in the access network. Q2: Does PANA aim to replace link layer authentication? A: No. PANA will complement and/or coexist with link layer authentication mechanisms to enable network layer authentication. Q3: Do we still need PANA if the link-layer supports authentication? A: It is a common practice to use higher-layer authentication on top of link-layer authentication. For example in 3GPP and 3GPP2, PPP is used for authentication after link-layer authentication succeeds. Or, http-redirect method is used as a higher-layer user authentication in some other network access architectures. Hence even if link-layer authentication exists, PANA is needed in certain scenarios. Q4: Access control should always be an L2 function. Does PANA violate the layering principles? A: No. While most networks today require authentication at L2, it is not based on any layered architecture principles. Hence performing authentication at L3 for network access does not violate architectural principles. Q5: Is PANA specifically targeted for mobile/wireless networks? A: No. PANA is applicable for any type of network that requires the host that is attaching to it for access to authenticate itself before being granted access. Q6: Does PANA deal with mobility? A: No. However mobile IP based networks may use PANA for network access authentication. Q7: Does PANA introduce new security vulnerabilities as a result of being an L3 solution? A: Requirements for dealing with security issues are part of the charter. Q8: Does PANA do access control? A: No. PANA enables access control indirectly. Q9: Does PANA require a AAA protocol/infrastructure in the access network? A: PANA may interact with backend AAA infrastructures such as RADIUS or Diameter. But it is not a requirement. Q10: What is the PaC and the PAA? A: PaC : PANA Client PAA : PANA Authentication Agent The PaC and PAA are the client and server elements of the protocol. Q11: Where is the PAA located in the access network? A: The PAA should be on an IP capable network element on the same subnet as the PaC. Hence it can be on the NAS or WLAN AP or first hop router. Q12: Is PAA always co-located with the enforcement point? It doesn't have to be. When they are separated, there needs to be another transport between two for client provisioning. This transport is outside the scope of PANA. Q13: How does the PaC know the address of the PAA? A: Possibilities include: - A discovery mechanism - Multicast or anycast Q14: Does PANA assign the client/host an IP address? A: No. PANA does not perform any address assignment functions. Q15: What type of authorization does PANA provide? A: It provides only a binary authorization to indicate whether the PaC can access the network or not. It doesn't deal with finer granularity authorization, such as negotiating QoS parameters. Q16: Is PANA applicable to IPv6 only? A: No. PANA is IP version agnostic in addition to being L2 agnostic. Q17: What is the role of EAP in PANA? A: EAP is the authentication protocol for which PANA is the transport. Q18: Is PANA a client-server or peer-peer protocol? A: PANA is a client-server protocol. Q19: Does the PAA know (or need to know) when the PaC has disconnected from the network? A: In some networks it may be required to know when the client has disconnected. This may be accomplished via mechanisms such as heartbeat etc. Q20: Does PANA provide per-packet authentication and encryption? A: No, this is outside the scope of PANA. Though, PANA carries EAP and certain EAP methods generates session keys for this purpose. Therefore PANA is an enabler for per-packet protection. The keys generated can be used with link-layer protection, or network layer protection (IPsec). Generation and distribution of these keys is outside the scope of PANA. Q21: Does the PaC have to configure an IP address before using PANA? A: No. Since both PaC and the PAA are on the same IP subnet, PaC can use unspecified IP address and still go through PANA. IP address allocation and configuration can happen before or after PANA authentication. V: 0.3 From pana-request@research.telcordia.com Fri Apr 19 01:41:37 2002 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 BAA02774 for ; Fri, 19 Apr 2002 01:41:14 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3J5b7h2024633; Fri, 19 Apr 2002 01:37:07 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 01:37:07 -0400 (EDT) Old-Return-Path: Message-ID: <000001c1e763$cb3b1530$4c6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "'Erik Nordmark'" Cc: "'Alper E. YEGIN'" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AC7B@Esealnt861.al.sw.ericsson.se> Subject: Re: Location of authentication agent Date: Thu, 18 Apr 2002 07:59:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > => I can understand that, but my fear is > 2 issues: > > 1. I just haven't been able to understand why > minimal means on-link PAA. I could understand > it more if there is a clear decision to eliminate > the scenarios that won't work because of this > decision. But perhaps people think all scenarios > will work anyway. This might be clear by further > discussions. > The scenarious should be checked that they work, of course, but if the existing NAS architecture works then why change it? > 2. People will do the minimum without leaving any > room for the additions. I think this is a very > likely case. > What is wrong with just doing something simple? > I don't mind either option as long as the decision > is clear, but the discussion right now is not > clear, because some people are saying this is > complex and others are saying it's not complex. > No reasons, (I haven't finished reading the mails > yet though). > Obviously I've been doing the same because I can't > understand the complexity claim. > It's complex because more entities are involved. So verifying things like security becomes more time consuming. jak From pana-request@research.telcordia.com Fri Apr 19 01:41:39 2002 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 BAA02775 for ; Fri, 19 Apr 2002 01:41:20 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3J5bQmq024669; Fri, 19 Apr 2002 01:37:26 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 01:37:26 -0400 (EDT) Old-Return-Path: Message-ID: <000401c1e763$d56cf230$4c6015ac@T23KEMPF> From: "James Kempf" To: "Reinaldo Penno" , "subir Das" , "John Schnizlein" Cc: "Reinaldo Penno" , References: <20020417123857.809.qmail@web20410.mail.yahoo.com> Subject: Re: Location of authentication agent Date: Thu, 18 Apr 2002 08:13:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Splitting the NAS into AA and EP is a major architectural change. If such a change is to be proposed, then it is incumbent upon the working group to work out all the details of the change, so that the interoperability and security implications are well known before the result is standardized. It is not acceptable to make the change, declare part of the consequences of the change (i.e. the protocol and security between PAA and EP) out of scope, then just work on the other part. jak ----- Original Message ----- From: "Reinaldo Penno" To: "James Kempf" ; "subir Das" ; "John Schnizlein" Cc: "Reinaldo Penno" ; Sent: Wednesday, April 17, 2002 5:38 AM Subject: Re: Location of authentication agent > Hello James, > > I only consider a major archiotectural change anything > that changes the PANA protocol or entities per se. > > Saying in a certain scenario you need to use another > protocol which is out of scope I do not consider a > major architectural change. > > Reinaldo > > --- James Kempf wrote: > > > the associated protocol is out of scope and also > > any > > > associted security threats. It wouldn't make sense > > to > > > say the protocol is out of scope but not the > > security > > > threats. > > > > > > I'm curious, can you think of an IETF architecture > > > where an assolciaed protocol is declared out of > > scope > > > but people felt the need to deal with the security > > > threats of this out of scopr protocol? IMHO this > > seems > > > weird. > > > > > > > If the WG is to propose a major architectural > > change, then neither the > > associated protocol nor the security is out of > > scope. > > > > jak > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Tax Center - online filing with TurboTax > http://taxes.yahoo.com/ > From pana-request@research.telcordia.com Fri Apr 19 01:44:51 2002 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 BAA02848 for ; Fri, 19 Apr 2002 01:44:50 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3J5anwK024534; Fri, 19 Apr 2002 01:36:49 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 01:36:49 -0400 (EDT) Old-Return-Path: Message-ID: <000701c1e763$df24bd30$4c6015ac@T23KEMPF> From: "James Kempf" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "George Tsirtsis" , "Hesham Soliman \(ERA\)" , "Alper E. YEGIN" , References: <20020415223616.GA3780@catfish> <01f801c1e4c8$b4350410$7e6015ac@T23KEMPF> <20020416113523.GA669@catfish> <008801c1e564$72de0dd0$7e6015ac@T23KEMPF> <20020416182356.GA635@catfish> <017501c1e571$7dc915c0$7e6015ac@T23KEMPF> <20020416202226.GA659@catfish> <02a001c1e585$eecd2f40$7e6015ac@T23KEMPF> <20020416221149.GC659@catfish> <02fe01c1e595$de75e280$7e6015ac@T23KEMPF> <20020417152050.GD1767@catfish> Subject: Re: Location of authentication agent Date: Thu, 18 Apr 2002 08:27:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Right, but the attacker can still continue to pump PANA packets at the PAA. jak ----- Original Message ----- From: "Yoshihiro Ohba" To: "James Kempf" Cc: "Yoshihiro Ohba" ; "George Tsirtsis" ; "Hesham Soliman (ERA)" ; "Alper E. YEGIN" ; Sent: Wednesday, April 17, 2002 8:20 AM Subject: Re: Location of authentication agent > On Tue, Apr 16, 2002 at 03:27:18PM -0700, James Kempf wrote: > > > For a strong security argument about why enforcement and decision at the > > edge are a good idea, see my previous email about DoS attackes. > > > > jak > > > > BTW, I still don't understand what is the security threat that is said > to occur when putting AA behind ARs. I think if the firewall > parameters for the ARs are set in such a way that they only pass > through PANA messages by default, the level of security is equivalent > to the co-located model. > > Yoshihiro Ohba > From pana-request@research.telcordia.com Fri Apr 19 10:31:25 2002 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 KAA21552 for ; Fri, 19 Apr 2002 10:31:25 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3JEQLrm029803; Fri, 19 Apr 2002 10:26:21 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 10:26:21 -0400 (EDT) Old-Return-Path: Message-ID: <20020419142512.61590.qmail@web20404.mail.yahoo.com> Date: Fri, 19 Apr 2002 07:25:12 -0700 (PDT) From: Reinaldo Penno Subject: Re: Location of authentication agent To: James Kempf , subir Das , John Schnizlein Cc: Reinaldo Penno , pana@research.telcordia.com In-Reply-To: <000401c1e763$d56cf230$4c6015ac@T23KEMPF> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com The protocol is not between PAA and EP. The protocol is between the COPS/midcom process running on the same device and the EP. regards, Reinaldo --- James Kempf wrote: > Splitting the NAS into AA and EP is a major > architectural > change. If such a change is to be proposed, then it > is > incumbent upon the working group to work out all > the details of the change, so that the > interoperability > and security implications are well known before the > result is standardized. It is not acceptable to make > the change, declare part of the > consequences of the change (i.e. the protocol > and security between PAA and EP) out of > scope, then just work on the other part. > > jak > > ----- Original Message ----- > From: "Reinaldo Penno" > To: "James Kempf" ; "subir > Das" > ; "John Schnizlein" > > Cc: "Reinaldo Penno" ; > > Sent: Wednesday, April 17, 2002 5:38 AM > Subject: Re: Location of authentication agent > > > > Hello James, > > > > I only consider a major archiotectural change > anything > > that changes the PANA protocol or entities per se. > > > > Saying in a certain scenario you need to use > another > > protocol which is out of scope I do not consider a > > major architectural change. > > > > Reinaldo > > > > --- James Kempf wrote: > > > > the associated protocol is out of scope and > also > > > any > > > > associted security threats. It wouldn't make > sense > > > to > > > > say the protocol is out of scope but not the > > > security > > > > threats. > > > > > > > > I'm curious, can you think of an IETF > architecture > > > > where an assolciaed protocol is declared out > of > > > scope > > > > but people felt the need to deal with the > security > > > > threats of this out of scopr protocol? IMHO > this > > > seems > > > > weird. > > > > > > > > > > If the WG is to propose a major architectural > > > change, then neither the > > > associated protocol nor the security is out of > > > scope. > > > > > > jak > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Tax Center - online filing with TurboTax > > http://taxes.yahoo.com/ > > > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From pana-request@research.telcordia.com Fri Apr 19 11:32:57 2002 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 LAA23992 for ; Fri, 19 Apr 2002 11:32:48 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3JFT091005940; Fri, 19 Apr 2002 11:29:00 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 11:29:00 -0400 (EDT) Old-Return-Path: Message-ID: <000101c1e7b6$98b075d0$746015ac@T23KEMPF> From: "James Kempf" To: "Alper E. YEGIN" , "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "subir Das" , "Hesham Soliman \(ERA\)" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AC68@Esealnt861.al.sw.ericsson.se> <032801c1e4df$a6411e90$736015ac@AlperVAIO> <004401c1e563$10c714d0$7e6015ac@T23KEMPF> <3CBC5316.3CAF772C@research.telcordia.com> <050401c1e5b5$a315f110$736015ac@AlperVAIO> <20020417134941.GA1767@catfish> <01a601c1e645$3a235310$736015ac@AlperVAIO> <20020417203206.GA688@catfish> Subject: Re: Location of authentication agent Date: Fri, 19 Apr 2002 06:41:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit I think NASREQ must be doable with PANA, but I don't think all of what PANA does must be doable with NASREQ. One could extend NASREQ or write a different extension. jak ----- Original Message ----- From: "Yoshihiro Ohba" To: "Alper E. YEGIN" Cc: "Yoshihiro Ohba" ; "subir Das" ; "James Kempf" ; "Hesham Soliman (ERA)" ; Sent: Wednesday, April 17, 2002 1:32 PM Subject: Re: Location of authentication agent > OK. My next question is, can the proposed solution be supported > without changing the current Diameter NASREQ application > specification? If it can't, I would say that it does not fit the > existing NAS model and thus would be problematic. > > Yoshihiro Ohba > > On Wed, Apr 17, 2002 at 12:22:32PM -0700, Alper E. YEGIN wrote: > > Yoshihiro, > > > > > We cannot always expect for all the AAA signaling messages > > > originated from those PAAs to pass through the same AAAlocal > > > when there are multiple AAA local proxies, since AAA message > > > routing topology can be arbitrary. In an extreme case, > > > two AAA messages originated from different PAAs can take > > > completely different paths to reach the AAAhome. > > > > But, this is a network design issue. If the operator wants > > the feature (one authentication, multiple EPs updated), then > > the network should be designed in a hierarchical way. > > > > Same with the separate EP and AA. All the EPs that need > > to be updated simultaneously need to be (logically) attached to the > > same AA. > > > > alper > > > > > From pana-request@research.telcordia.com Fri Apr 19 11:51:39 2002 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 LAA24699 for ; Fri, 19 Apr 2002 11:51:39 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3JFm9gr008253; Fri, 19 Apr 2002 11:48:09 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 11:48:09 -0400 (EDT) Old-Return-Path: content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: Location of authentication agent X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 19 Apr 2002 10:47:52 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12CB7@daebe007.NOE.Nokia.com> Thread-Topic: Location of authentication agent Thread-Index: AcHnZGzYeIL94owsQlSgG9KgV05EEgAVLqWA From: To: , Cc: , , , , X-OriginalArrivalTime: 19 Apr 2002 15:47:53.0291 (UTC) FILETIME=[912101B0:01C1E7B9] X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit James, > Right, but the attacker can still continue to pump PANA packets at the > PAA. There are mechanisms for preventing such flooding of PANA messages to a certain degree. But stopping DoS attacks completely is not a possibility. The same argument about an attacker doing DoS attacks is valid for the L2 mechanisms. So while what you say is true, I consider this just as a requirement for PANA. > > jak > Basavaraj From pana-request@research.telcordia.com Fri Apr 19 11:58:21 2002 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 LAA25039 for ; Fri, 19 Apr 2002 11:58:21 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3JFstAH008826; Fri, 19 Apr 2002 11:54:55 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 11:54:55 -0400 (EDT) Old-Return-Path: content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Location of authentication agent X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Fri, 19 Apr 2002 10:53:49 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44096946@daebe007.NOE.Nokia.com> Thread-Topic: Location of authentication agent Thread-Index: AcHnZ6i8c4ounJ7vS2SKH/tWN7vjAgAUfWEA From: To: , , , Cc: , X-OriginalArrivalTime: 19 Apr 2002 15:53:50.0150 (UTC) FILETIME=[65D55E60:01C1E7BA] X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA25039 A couple of clarifications: > > Splitting the NAS into AA and EP is a major architectural > change. PANA does not require or mandate that the NAS be split up into the AA and EP. You can colocate the AA and EP just as well as you could split them. If you split the AA and EP, then there are obviously a few more issues that the protocol needs to worry about. PANA does not recommend architectural changes for the well undertsood NAS model. However if there are reasons for splitting the AP and EP, then it should be possible to do so and PANA allows this. > If such a change is to be proposed, then it is > incumbent upon the working group to work out all > the details of the change, so that the interoperability > and security implications are well known before the > result is standardized. It is not acceptable to make > the change, declare part of the > consequences of the change (i.e. the protocol > and security between PAA and EP) out of > scope, then just work on the other part. I agree with what you are saying here. The limited scope charter that I sent out yesterday is essentially proposing to work on the simple aspects of the problem domain. So in the interest of moving forward with the WG tasks I can at least live with it for now. > > jak > -Basavaraj From pana-request@research.telcordia.com Fri Apr 19 12:01:33 2002 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 MAA25323 for ; Fri, 19 Apr 2002 12:01:33 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3JFvvVj009281; Fri, 19 Apr 2002 11:57:57 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 11:57:57 -0400 (EDT) Old-Return-Path: From: "Jean-Michel COMBES" To: "Pana \(E-mail\)" Subject: RE: PANA FAQ Date: Fri, 19 Apr 2002 17:57:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit Hi, some questions : - Will the interactions between PAA and AAA infrastructure be studied in PANA WG or in AAA WG ? - Will the PAA have the same role as the Attendant in AAA architecture ? Thanks. Regards. JMC. France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 -----Message d'origine----- De : Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Envoyé : jeudi 18 avril 2002 23:11 À : Pana (E-mail) Cc : Erik Nordmark; narten@us.ibm.com Objet : PANA FAQ Hello, Along with the minimum scope write-up sent earlier, we also prepared this FAQ to answer commonly asked questions... Please see if this already answers the questions you might have. - WG Chairs PANA FAQ ========= Q1: What is PANA? A: PANA is - a layer two agnostic network layer messaging protocol for authenticating IP hosts for network access - a transport protocol for authentication payload (EAP) between a client (IP based) and a server (agent) in the access network. Q2: Does PANA aim to replace link layer authentication? A: No. PANA will complement and/or coexist with link layer authentication mechanisms to enable network layer authentication. Q3: Do we still need PANA if the link-layer supports authentication? A: It is a common practice to use higher-layer authentication on top of link-layer authentication. For example in 3GPP and 3GPP2, PPP is used for authentication after link-layer authentication succeeds. Or, http-redirect method is used as a higher-layer user authentication in some other network access architectures. Hence even if link-layer authentication exists, PANA is needed in certain scenarios. Q4: Access control should always be an L2 function. Does PANA violate the layering principles? A: No. While most networks today require authentication at L2, it is not based on any layered architecture principles. Hence performing authentication at L3 for network access does not violate architectural principles. Q5: Is PANA specifically targeted for mobile/wireless networks? A: No. PANA is applicable for any type of network that requires the host that is attaching to it for access to authenticate itself before being granted access. Q6: Does PANA deal with mobility? A: No. However mobile IP based networks may use PANA for network access authentication. Q7: Does PANA introduce new security vulnerabilities as a result of being an L3 solution? A: Requirements for dealing with security issues are part of the charter. Q8: Does PANA do access control? A: No. PANA enables access control indirectly. Q9: Does PANA require a AAA protocol/infrastructure in the access network? A: PANA may interact with backend AAA infrastructures such as RADIUS or Diameter. But it is not a requirement. Q10: What is the PaC and the PAA? A: PaC : PANA Client PAA : PANA Authentication Agent The PaC and PAA are the client and server elements of the protocol. Q11: Where is the PAA located in the access network? A: The PAA should be on an IP capable network element on the same subnet as the PaC. Hence it can be on the NAS or WLAN AP or first hop router. Q12: Is PAA always co-located with the enforcement point? It doesn't have to be. When they are separated, there needs to be another transport between two for client provisioning. This transport is outside the scope of PANA. Q13: How does the PaC know the address of the PAA? A: Possibilities include: - A discovery mechanism - Multicast or anycast Q14: Does PANA assign the client/host an IP address? A: No. PANA does not perform any address assignment functions. Q15: What type of authorization does PANA provide? A: It provides only a binary authorization to indicate whether the PaC can access the network or not. It doesn't deal with finer granularity authorization, such as negotiating QoS parameters. Q16: Is PANA applicable to IPv6 only? A: No. PANA is IP version agnostic in addition to being L2 agnostic. Q17: What is the role of EAP in PANA? A: EAP is the authentication protocol for which PANA is the transport. Q18: Is PANA a client-server or peer-peer protocol? A: PANA is a client-server protocol. Q19: Does the PAA know (or need to know) when the PaC has disconnected from the network? A: In some networks it may be required to know when the client has disconnected. This may be accomplished via mechanisms such as heartbeat etc. Q20: Does PANA provide per-packet authentication and encryption? A: No, this is outside the scope of PANA. Though, PANA carries EAP and certain EAP methods generates session keys for this purpose. Therefore PANA is an enabler for per-packet protection. The keys generated can be used with link-layer protection, or network layer protection (IPsec). Generation and distribution of these keys is outside the scope of PANA. Q21: Does the PaC have to configure an IP address before using PANA? A: No. Since both PaC and the PAA are on the same IP subnet, PaC can use unspecified IP address and still go through PANA. IP address allocation and configuration can happen before or after PANA authentication. V: 0.3 From pana-request@research.telcordia.com Fri Apr 19 12:20:58 2002 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 MAA27783 for ; Fri, 19 Apr 2002 12:20:57 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3JGGh6W011223; Fri, 19 Apr 2002 12:16:43 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 12:16:43 -0400 (EDT) Old-Return-Path: content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: PANA FAQ Date: Fri, 19 Apr 2002 11:12:02 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12CBB@daebe007.NOE.Nokia.com> Thread-Topic: PANA FAQ Thread-Index: AcHnvBe5mmhpO1CFQQ2ro7wVLoU95wAAIgvQ From: To: , X-OriginalArrivalTime: 19 Apr 2002 16:12:02.0629 (UTC) FILETIME=[F1006F50:01C1E7BC] X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <2HIqjB.A.PvC.qLEw8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA27783 > Hi, > > some questions : > - Will the interactions between PAA and AAA infrastructure be studied in > PANA WG or in AAA WG ? The PAA interacts with backend AAA infrastructures. I am not so sure if we really need to study the interactions of PAA and AAA as much as we need to study the interaction of PANA with 802.1x and PPP. > - Will the PAA have the same role as the Attendant in AAA architecture ? Yes. > > Thanks. > > Regards. > > JMC. > > > France Telecom R&D - DTL/SSR > Jean-Michel COMBES, Internet/Intranet Security > E-Mail : jeanmichel.combes@francetelecom.com > Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 > PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 From pana-request@research.telcordia.com Fri Apr 19 12:40:17 2002 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 MAA00870 for ; Fri, 19 Apr 2002 12:40:16 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3JGU1cU012427; Fri, 19 Apr 2002 12:30:01 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 12:30:01 -0400 (EDT) Old-Return-Path: From: "Jean-Michel COMBES" To: , Subject: RE: PANA FAQ Date: Fri, 19 Apr 2002 18:29:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-f17ee994-52b2-11d6-ac23-00508b692753" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <697DAA22C5004B4596E033803A7CEF44A12CBB@daebe007.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com This is a multi-part message in MIME format. ------=_NextPartTM-000-f17ee994-52b2-11d6-ac23-00508b692753 Content-Type: multipart/alternative; boundary="----=_NextPart_000_033F_01C1E7D0.2AA69AA0" ------=_NextPart_000_033F_01C1E7D0.2AA69AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi, comments below France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 -----Message d'origine----- De : Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Envoyé : vendredi 19 avril 2002 18:12 À : COMBES jean-michel FTRD/DTL; pana@research.telcordia.com Objet : RE: PANA FAQ > Hi, > > some questions : > - Will the interactions between PAA and AAA infrastructure be studied in > PANA WG or in AAA WG ? The PAA interacts with backend AAA infrastructures. I am not so sure if we really need to study the interactions of PAA and AAA as much as we need to study the interaction of PANA with 802.1x and PPP. JMC : but in the AAA case, some information, needed by the PAA to allow access to the PaC, are provided by backend AAA infrastructures ... so, IMHO, the PAA/AAA interactions are important. > - Will the PAA have the same role as the Attendant in AAA architecture ? Yes. > > Thanks. > > Regards. > > JMC. > > > France Telecom R&D - DTL/SSR > Jean-Michel COMBES, Internet/Intranet Security > E-Mail : jeanmichel.combes@francetelecom.com > Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 > PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 ------=_NextPart_000_033F_01C1E7D0.2AA69AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PANA FAQ
Hi,
 
comments below

France Telecom R&D - = DTL/SSR  
Jean-Michel=20 COMBES, Internet/Intranet Security
E-Mail :=20 jeanmichel.combes@francetelecom.com
Phone +33 (0)1 45 29 45 94, Fax = +33 (0)1=20 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 = 9E33 CFA7=20 0214

-----Message d'origine-----
De :=20 Basavaraj.Patil@nokia.com=20 [mailto:Basavaraj.Patil@nokia.com]
Envoy=E9 : vendredi = 19 avril=20 2002 18:12
=C0 : COMBES jean-michel FTRD/DTL;=20 pana@research.telcordia.com
Objet : RE: PANA=20 FAQ

> Hi,
> =
> some questions :
> - Will = the=20 interactions between PAA and AAA infrastructure be studied in =
> PANA WG or in AAA WG ?

The PAA interacts with backend AAA infrastructures. = I am not=20 so sure if
we really need to study the = interactions of=20 PAA and AAA as much as we
need to study the = interaction of PANA with 802.1x and PPP.  

JMC=20 :  but = in the AAA case,=20 some information, needed by the PAA to allow access to the = PaC, are=20 provided by backend AAA infrastructures ... so, IMHO, the = PAA/AAA=20 interactions are important.

> - Will the PAA have the same role as the = Attendant in=20 AAA  architecture ?

Yes.

>
> Thanks. =
>
> Regards. =
>=20
> JMC.
>=20
>
> France = Telecom=20 R&D - DTL/SSR
> Jean-Michel COMBES,=20 Internet/Intranet Security
> E-Mail :=20 jeanmichel.combes@francetelecom.com
> = Phone +33=20 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
> PGP=20 fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 = 0214=20

------=_NextPart_000_033F_01C1E7D0.2AA69AA0-- ------=_NextPartTM-000-f17ee994-52b2-11d6-ac23-00508b692753-- From pana-request@research.telcordia.com Fri Apr 19 13:21:29 2002 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 NAA06393 for ; Fri, 19 Apr 2002 13:21:28 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3JHHbHp016755; Fri, 19 Apr 2002 13:17:37 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 13:17:37 -0400 (EDT) Old-Return-Path: Message-ID: <20020419171612.83452.qmail@web20405.mail.yahoo.com> Date: Fri, 19 Apr 2002 10:16:12 -0700 (PDT) From: Reinaldo Penno Subject: RE: Location of authentication agent To: Basavaraj.Patil@nokia.com, kempf@docomolabs-usa.com, subir@research.telcordia.com, jschnizl@cisco.com Cc: rapenno@yahoo.com, pana@research.telcordia.com In-Reply-To: <697DAA22C5004B4596E033803A7CEF44096946@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com In another email you just said. > I am not so sure if > we really need to study the interactions of PAA and > AAA as much as we > need to study the interaction of PANA with 802.1x > and PPP. or as much we need to study the interaction between PAA and EP. It's the same argument. It's another protocol! So, if I make a protocol called "Reinaldo's" which uses PAA data and communicates with "Reinaldo's Server", do I need to know anything or care about how Pac and PAA communicates? |---------------| Pac->>>| PAA | COPS |->>>EP | | | ----------------- |---------------| Pac->>>| PAA | AAA |->>>AAA server | | | ----------------- |-------------------| Pac->>>| PAA | Reinaldo's|->>>Reinaldo's server | | | --------------------| I do not know, maybe we are talking about different things... Reinaldo --- Basavaraj.Patil@nokia.com wrote: > > A couple of clarifications: > > > > > Splitting the NAS into AA and EP is a major > architectural > > change. > > PANA does not require or mandate that the NAS be > split up into > the AA and EP. You can colocate the AA and EP just > as well as > you could split them. If you split the AA and EP, > then there are > obviously a few more issues that the protocol needs > to worry about. > PANA does not recommend architectural changes for > the well > undertsood NAS model. However if there are reasons > for splitting > the AP and EP, then it should be possible to do so > and PANA > allows this. > > > If such a change is to be proposed, then it is > > incumbent upon the working group to work out all > > the details of the change, so that the > interoperability > > and security implications are well known before > the > > result is standardized. It is not acceptable to > make > > the change, declare part of the > > consequences of the change (i.e. the protocol > > and security between PAA and EP) out of > > scope, then just work on the other part. > > I agree with what you are saying here. The limited > scope > charter that I sent out yesterday is essentially > proposing > to work on the simple aspects of the problem domain. > So in the interest of moving forward with the WG > tasks > I can at least live with it for now. > > > > > jak > > > -Basavaraj > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From pana-request@research.telcordia.com Fri Apr 19 13:24:09 2002 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 NAA06768 for ; Fri, 19 Apr 2002 13:24:04 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3JHKYgD017150; Fri, 19 Apr 2002 13:20:34 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 13:20:34 -0400 (EDT) Old-Return-Path: Message-ID: <20020419172026.84421.qmail@web20405.mail.yahoo.com> Date: Fri, 19 Apr 2002 10:20:26 -0700 (PDT) From: Reinaldo Penno Subject: RE: PANA FAQ To: Jean-Michel COMBES , Basavaraj.Patil@nokia.com, pana@research.telcordia.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com --- Jean-Michel COMBES wrote: > Hi, > > comments below > > > > France Telecom R&D - DTL/SSR > Jean-Michel COMBES, Internet/Intranet Security > E-Mail : jeanmichel.combes@francetelecom.com > Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 > PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 > 9E33 CFA7 0214 > > -----Message d'origine----- > De : Basavaraj.Patil@nokia.com > [mailto:Basavaraj.Patil@nokia.com] > Envoyé : vendredi 19 avril 2002 18:12 > À : COMBES jean-michel FTRD/DTL; > pana@research.telcordia.com > Objet : RE: PANA FAQ > > > > > Hi, > > > > some questions : > > - Will the interactions between PAA and AAA > infrastructure be studied > in > > PANA WG or in AAA WG ? > > The PAA interacts with backend AAA infrastructures. > I am not so sure if > we really need to study the interactions of PAA and > AAA as much as we > need to study the interaction of PANA with 802.1x > and PPP. > > JMC : but in the AAA case, some information, needed > by the PAA to allow > access to the PaC, are provided by backend AAA > infrastructures ... so, > IMHO, the PAA/AAA interactions are important. RP: yes, but you can have a whole bunch of protocols on the same box that use data one from another. That does not mean you carry protocol requirements one to another. If that's the case every protocol that interacts today or in the future with the PAA server on the same box will need to be modified? I'm not saying that's the case, but let's not have double standards. If studying the interaction between PAA and AAA is not important, so it's not important to study the interaction between PAA and EP. Or vice-versa. > > > - Will the PAA have the same role as the Attendant > in AAA > architecture ? > > Yes. > > > > > Thanks. > > > > Regards. > > > > JMC. > > > > > > France Telecom R&D - DTL/SSR > > Jean-Michel COMBES, Internet/Intranet Security > > E-Mail : jeanmichel.combes@francetelecom.com > > Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 > 19 > > PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 > 5D75 9E33 CFA7 0214 > > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From pana-request@research.telcordia.com Fri Apr 19 14:30:44 2002 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 OAA15183 for ; Fri, 19 Apr 2002 14:30:43 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3JIQLEb022828; Fri, 19 Apr 2002 14:26:21 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 14:26:21 -0400 (EDT) Old-Return-Path: content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: PANA FAQ Date: Fri, 19 Apr 2002 13:20:47 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44096947@daebe007.NOE.Nokia.com> Thread-Topic: PANA FAQ Thread-Index: AcHnxohPqBV0AGUtSOqynyoBabXh8gABiWlQ From: To: , , X-OriginalArrivalTime: 19 Apr 2002 18:20:47.0638 (UTC) FILETIME=[ED774360:01C1E7CE] X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA15183 Hi Reinaldo, > If studying the interaction between PAA and AAA is not > important, so it's not important to study the > interaction between PAA and EP. Or vice-versa. Well I am not so sure about that. The PAA interaction w.r.t AAA backends deals with converting the PANA payloads into a RADIUS or Diameter message. So the PAA is simply a gateway that has the appropriate AAA protocol on one end. The end-result of the PANA messaging is to authorize access to some service/resources (in this case network access). So how the PAA does this seems to be more relevant for PANA to consider. If the PAA and the EP are separated, then the PANA WG should specify how the authorization for network access is enabled. -Basavaraj From pana-request@research.telcordia.com Fri Apr 19 14:31:34 2002 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 OAA15352 for ; Fri, 19 Apr 2002 14:31:29 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3JISeC9022978; Fri, 19 Apr 2002 14:28:40 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 14:28:40 -0400 (EDT) Old-Return-Path: Message-ID: <01b701c1e7ce$fc80c020$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Reinaldo Penno" , "Jean-Michel COMBES" , , References: <20020419172026.84421.qmail@web20405.mail.yahoo.com> Subject: Re: PANA FAQ Date: Fri, 19 Apr 2002 11:21:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > > > - Will the interactions between PAA and AAA > > infrastructure be studied > > in > > > PANA WG or in AAA WG ? > > > > The PAA interacts with backend AAA infrastructures. > > I am not so sure if > > we really need to study the interactions of PAA and > > AAA as much as we > > need to study the interaction of PANA with 802.1x > > and PPP. > > > > JMC : but in the AAA case, some information, needed > > by the PAA to allow > > access to the PaC, are provided by backend AAA > > infrastructures ... so, > > IMHO, the PAA/AAA interactions are important. > > RP: yes, but you can have a whole bunch of protocols > on the same box that use data one from another. That > does not mean you carry protocol requirements one to > another. > > If that's the case every protocol that interacts > today or in the future with the PAA server on the same > box will need to be modified? I'm not saying that's > the case, but let's not have double standards. PANA proposes nothing new as for the interactions between Authentication Agent and the AAA backend. PAA-AAA interactions are same as NAS-AAA, Access Point-AAA interactions. Does anyone see additional PANA requirements here? > > If studying the interaction between PAA and AAA is not > important, so it's not important to study the I think it's important. But, is there anything missing or different for PANA here? > interaction between PAA and EP. Or vice-versa. The limited scope charter does not propose or recommend PAA EP separation. People might want this separation for solving issues other than what PANA is aiming to solve. So, the interaction and protocol when two are separated is outside the scope of this WG. alper > > > > > > > > > - Will the PAA have the same role as the Attendant > > in AAA > > architecture ? > > > > Yes. > > > > > > > > Thanks. > > > > > > Regards. > > > > > > JMC. > > > > > > > > > France Telecom R&D - DTL/SSR > > > Jean-Michel COMBES, Internet/Intranet Security > > > E-Mail : jeanmichel.combes@francetelecom.com > > > Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 > > 19 > > > PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 > > 5D75 9E33 CFA7 0214 > > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Tax Center - online filing with TurboTax > http://taxes.yahoo.com/ > > From pana-request@research.telcordia.com Fri Apr 19 15:10:13 2002 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 PAA20161 for ; Fri, 19 Apr 2002 15:10:12 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3JJ7bt3027618; Fri, 19 Apr 2002 15:07:37 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 15:07:37 -0400 (EDT) Old-Return-Path: Message-ID: <20020419190721.79546.qmail@web20403.mail.yahoo.com> Date: Fri, 19 Apr 2002 12:07:21 -0700 (PDT) From: Reinaldo Penno Subject: RE: PANA FAQ To: Basavaraj.Patil@nokia.com, jeanmichel.combes@francetelecom.com, pana@research.telcordia.com In-Reply-To: <697DAA22C5004B4596E033803A7CEF44096947@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com --- Basavaraj.Patil@nokia.com wrote: > > Hi Reinaldo, > > > If studying the interaction between PAA and AAA is > not > > important, so it's not important to study the > > interaction between PAA and EP. Or vice-versa. > > Well I am not so sure about that. The PAA > interaction w.r.t > AAA backends deals with converting the PANA payloads > into > a RADIUS or Diameter message. So the PAA is simply a > > gateway that has the appropriate AAA protocol on one > end. > > The end-result of the PANA messaging is to authorize > access > to some service/resources (in this case network > access). So how > the PAA does this seems to be more relevant for PANA > to consider. well, I do not agree,..For me PANA will talk to AAA to find the necessary authorization rules to apply to a user/id and will use another protocol (e.g. cops) to pass this authorization to a EP. Everything is interconnected. The same authorization rules that come from the AAA are sent to the EP. For the "good of the WG", I'm okay with declaring out of scope, but cleary I think the two issues are the same.... cheers, Reinaldo > > If the PAA and the EP are separated, then the PANA > WG should > specify how the authorization for network access is > enabled. > > -Basavaraj __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From pana-request@research.telcordia.com Fri Apr 19 15:37:36 2002 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 PAA23849 for ; Fri, 19 Apr 2002 15:37:36 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3JJ1ifo026774; Fri, 19 Apr 2002 15:01:44 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 15:01:44 -0400 (EDT) Old-Return-Path: Message-ID: <20020419190125.8935.qmail@web20407.mail.yahoo.com> Date: Fri, 19 Apr 2002 12:01:25 -0700 (PDT) From: Reinaldo Penno Subject: Re: PANA FAQ To: "Alper E. YEGIN" , Jean-Michel COMBES , Basavaraj.Patil@nokia.com, pana@research.telcordia.com In-Reply-To: <01b701c1e7ce$fc80c020$736015ac@AlperVAIO> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com --- "Alper E. YEGIN" wrote: > > > > > - Will the interactions between PAA and AAA > > > infrastructure be studied > > > in > > > > PANA WG or in AAA WG ? > > > > > > The PAA interacts with backend AAA > infrastructures. > > > I am not so sure if > > > we really need to study the interactions of PAA > and > > > AAA as much as we > > > need to study the interaction of PANA with > 802.1x > > > and PPP. > > > > > > JMC : but in the AAA case, some information, > needed > > > by the PAA to allow > > > access to the PaC, are provided by backend AAA > > > infrastructures ... so, > > > IMHO, the PAA/AAA interactions are important. > > > > RP: yes, but you can have a whole bunch of > protocols > > on the same box that use data one from another. > That > > does not mean you carry protocol requirements one > to > > another. > > > > If that's the case every protocol that interacts > > today or in the future with the PAA server on the > same > > box will need to be modified? I'm not saying > that's > > the case, but let's not have double standards. > > PANA proposes nothing new as for the interactions > between Authentication Agent and the AAA backend. > PAA-AAA interactions are same as NAS-AAA, Access > Point-AAA interactions. Does anyone see additional > PANA > requirements here? > > > > > If studying the interaction between PAA and AAA is > not > > important, so it's not important to study the > > I think it's important. But, is there anything > missing or different > for PANA here? > > > interaction between PAA and EP. Or vice-versa. > > The limited scope charter does not propose or > recommend > PAA EP separation. People might want this separation > for solving > issues other than what PANA is aiming to solve. So, > the interaction > and protocol when two are separated is outside the > scope of this WG. As I said, I'm okay with being out of scope from the beggining. > > > alper > > > > > > > > > > > > > > > > - Will the PAA have the same role as the > Attendant > > > in AAA > > > architecture ? > > > > > > Yes. > > > > > > > > > > > Thanks. > > > > > > > > Regards. > > > > > > > > JMC. > > > > > > > > > > > > France Telecom R&D - DTL/SSR > > > > Jean-Michel COMBES, Internet/Intranet Security > > > > > E-Mail : jeanmichel.combes@francetelecom.com > > > > Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 > 65 > > > 19 > > > > PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 > 1F13 > > > 5D75 9E33 CFA7 0214 > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Tax Center - online filing with TurboTax > > http://taxes.yahoo.com/ > > > > > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From pana-request@research.telcordia.com Fri Apr 19 17:46:16 2002 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 RAA07669 for ; Fri, 19 Apr 2002 17:46:16 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3JLfKqG011613; Fri, 19 Apr 2002 17:41:20 -0400 (EDT) Resent-Date: Fri, 19 Apr 2002 17:41:20 -0400 (EDT) Old-Return-Path: content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: PANA FAQ Date: Fri, 19 Apr 2002 16:37:05 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12CC8@daebe007.NOE.Nokia.com> Thread-Topic: PANA FAQ Thread-Index: AcHn1XHEU47jTo7+SGekdw7IXs4ZugAFAxgQ From: To: , , X-OriginalArrivalTime: 19 Apr 2002 21:37:05.0957 (UTC) FILETIME=[59E41D50:01C1E7EA] X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA07669 > > well, I do not agree,..For me PANA will talk to AAA to > find the necessary authorization rules to apply to a > user/id and will use another protocol (e.g. cops) to > pass this authorization to a EP. I am not saying that PANA should design a new protocol for *transporting* the authorization info from the AP to the EP. I agree with your statement above. But what I am saying is that PANA should specify how and what protocol(s) is used to transport the authorization rules. We could leave this aspect as being out of the scope of PANA. That would definitely be one way to approach this (and maybe for now the best). But if you have a split AP and EP, PANA should specify the baseline mechanism/protocol for the AP and EP to communicate. From pana-request@research.telcordia.com Mon Apr 22 06:21:00 2002 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 GAA20658 for ; Mon, 22 Apr 2002 06:20:45 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3MAGuBY007693; Mon, 22 Apr 2002 06:16:56 -0400 (EDT) Resent-Date: Mon, 22 Apr 2002 06:16:56 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC92@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "Hesham Soliman (ERA)" , "'Erik Nordmark'" , "Hesham Soliman (ERA)" Cc: "'Alper E. YEGIN'" , "'pana@research.telcordia.com'" Subject: RE: Location of authentication agent Date: Mon, 22 Apr 2002 12:15:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > Seems like I didn't understand "load sharing". > Is load sharing in this context having a single device use > multiple ARs? => That was the intention, yes. Something that allows for Bob Hinden's load sharing draft. > > => Well, if you're in a hotel, they might tell you > > when you check in (in some way) that you can use the > > 'local' Hotel servers for free, but anything else you need > > to pay. The same in an Airport lounge, you could check > > flight information, or other airport stuff for > > free, but anything else you need to pay. They can inform > > you when you check in for example. > > Yes. But just because I looked at www.dn.se on Monday I > don't want to be > charged for Internet access for the whole week. > How can I as a user know that I've "logged out" from the > Internet access > part of the network and have reverted to only using the > free local info > part of it? => There are lots of different considerations here I think. I haven't thought of a solution but I can list my initial thoughts and let me know where it might be unrealistic or undoable. The first question is why does the user need to know? A reasonable answer is that the user wants to know what he/she are paying for. But this depends on the charging model. So if they're charge by time, there can be a default idle time, after which the PaC logs the user out. In this case the use might get some indication from a GUI (just like a modem logs a user out after a set idle time). This is the same issue for modems operating in countries where a phone call is charged by time, or when using a mobile phone for a dialup connection. If the user is charged by the number of packets, then logging out is not an issue. Perhaps the way the charging is done can be communicated during 'login'. The third option is flat rate, in which case re-athentication will be done, say every 24 hours, as is the case in some hotels today. Does that address your question? Hesham From pana-request@research.telcordia.com Mon Apr 22 07:11:10 2002 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 GAA20657 for ; Mon, 22 Apr 2002 06:20:45 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3MAH7UK007721; Mon, 22 Apr 2002 06:17:07 -0400 (EDT) Resent-Date: Mon, 22 Apr 2002 06:17:07 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC93@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "Hesham Soliman (ERA)" , "'James Kempf'" , "Hesham Soliman (ERA)" , "'Erik Nordmark'" Cc: "'Alper E. YEGIN'" , "'pana@research.telcordia.com'" Subject: RE: Location of authentication agent Date: Mon, 22 Apr 2002 12:15:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com James, > > 1. I just haven't been able to understand why > > minimal means on-link PAA. I could understand > > it more if there is a clear decision to eliminate > > the scenarios that won't work because of this > > decision. But perhaps people think all scenarios > > will work anyway. This might be clear by further > > discussions. > > > > The scenarious should be checked that they work, of course, > but if the existing NAS architecture works then why change it? => I didn't suggest changing anything, but at this time, our understanding says that to satisfy the scenarios documented, we need to separate the AA from PE in _some_ cases. > > 2. People will do the minimum without leaving any > > room for the additions. I think this is a very > > likely case. > > > > What is wrong with just doing something simple? => Simple and meets requirements is Great. Hesham From pana-request@research.telcordia.com Mon Apr 22 07:11:11 2002 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 GAA20656 for ; Mon, 22 Apr 2002 06:20:45 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3MAHbSX007827; Mon, 22 Apr 2002 06:17:37 -0400 (EDT) Resent-Date: Mon, 22 Apr 2002 06:17:37 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AC95@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "Hesham Soliman (ERA)" , "'Erik Nordmark'" , "Hesham Soliman (ERA)" Cc: "'Alper E. YEGIN'" , "'pana@research.telcordia.com'" Subject: RE: Location of authentication agent Date: Mon, 22 Apr 2002 12:16:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > > > 1. I just haven't been able to understand why > > > minimal means on-link PAA. I could understand > > > it more if there is a clear decision to eliminate > > > the scenarios that won't work because of this > > > decision. But perhaps people think all scenarios > > > will work anyway. This might be clear by further > > > discussions. > > > > > > 2. People will do the minimum without leaving any > > > room for the additions. I think this is a very > > > likely case. > > > > I wasn't saying that the working group should only work on > > some minimal > > thing. > > > > I was suggesting a *process* by which the WG can better > understand > > what is the minimum thing they can do and still end up with > > something > > that some number of people are interested in. > > > > Without this process I don't see how the WG can obtain focus. > => I fully agree. Hesham From pana-request@research.telcordia.com Tue Apr 23 10:49:21 2002 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 KAA20498 for ; Tue, 23 Apr 2002 10:49:21 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3NEidM2007727; Tue, 23 Apr 2002 10:44:39 -0400 (EDT) Resent-Date: Tue, 23 Apr 2002 10:44:39 -0400 (EDT) Old-Return-Path: Message-ID: <011f01c1ead4$62618890$1601a8c0@AlperVAIO> From: "Alper E. YEGIN" To: "Erik Nordmark" Cc: "Hesham Soliman \(ERA\)" , References: Subject: Re: Location of authentication agent Date: Tue, 23 Apr 2002 07:36:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > > 1- PAA is on the same subnet as PaC, and > > 2- we assume PAA is co-located with EP. > > > > [1] makes the discovery real easy. It can be as > > simple as picking a link-scoped multicast address, > > for example. > > An interesting question here is whether this can be > applied to IP-in-IP tunnels as a link layer. It should be applicable. > > Is that is the case then such tunneling might be a way to > handle cases when, through some out-of-band "discovery" mechanism, the PaC > desires to authenticate to an entity not on the physical link. > > An example of this might be to pre-authenticate to a (potential) future > access router when L2 is capable of indicating the IP address of the future > AR to the PaC. Yes. In this scenario, the PaC can go through a full PANA exchange while still attached to the current access point. This would establish authenticity of the client at the new access point (and establish session keys depending on the EAP method). As soon as the PaC attaches to the new access point, it can go through a partial PANA exchange, or partial 802.1x exchange (just identity exchanged to lookup the keys, no backend verification needed). alper From pana-request@research.telcordia.com Tue Apr 23 15:02:40 2002 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 PAA02476 for ; Tue, 23 Apr 2002 15:02:39 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3NIwOYw002352; Tue, 23 Apr 2002 14:58:24 -0400 (EDT) Resent-Date: Tue, 23 Apr 2002 14:58:24 -0400 (EDT) Old-Return-Path: Date: Tue, 23 Apr 2002 14:58:17 -0400 To: "Alper E. YEGIN" Cc: Erik Nordmark , "Hesham Soliman (ERA)" , pana@research.telcordia.com Subject: Re: Location of authentication agent Message-ID: <20020423185816.GA603@catfish> Mail-Followup-To: "Alper E. YEGIN" , Erik Nordmark , "Hesham Soliman (ERA)" , pana@research.telcordia.com References: <011f01c1ead4$62618890$1601a8c0@AlperVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <011f01c1ead4$62618890$1601a8c0@AlperVAIO> User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 49 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <_11IjB.A.ok.P7ax8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Interesting. That means, by allowing PANA messaging over IP-in-IP tunnel over multiple IP hops, local re-authentication at an event of interface switching would be still possible without mandating the use of other protocols such as context transfer and AAA. Is my understanding correct? Yoshihiro Ohba On Tue, Apr 23, 2002 at 07:36:54AM -0700, Alper E. YEGIN wrote: > > > > > 1- PAA is on the same subnet as PaC, and > > > 2- we assume PAA is co-located with EP. > > > > > > [1] makes the discovery real easy. It can be as > > > simple as picking a link-scoped multicast address, > > > for example. > > > > An interesting question here is whether this can be > > applied to IP-in-IP tunnels as a link layer. > > It should be applicable. > > > > > Is that is the case then such tunneling might be a way to > > handle cases when, through some out-of-band "discovery" mechanism, the PaC > > desires to authenticate to an entity not on the physical link. > > > > An example of this might be to pre-authenticate to a (potential) future > > access router when L2 is capable of indicating the IP address of the > future > > AR to the PaC. > > Yes. In this scenario, the PaC can go through a full PANA > exchange while still attached to the current access point. This would > establish authenticity of the client at the new access point (and establish > session keys depending on the EAP method). > > As soon as the PaC attaches to the new access point, it can go through a > partial PANA exchange, or partial 802.1x exchange (just identity exchanged > to lookup the keys, no backend verification needed). > > alper > > From pana-request@research.telcordia.com Tue Apr 23 18:22:57 2002 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 SAA08215 for ; Tue, 23 Apr 2002 18:22:57 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3NMHW1Z019735; Tue, 23 Apr 2002 18:17:32 -0400 (EDT) Resent-Date: Tue, 23 Apr 2002 18:17:32 -0400 (EDT) Old-Return-Path: Message-ID: <006b01c1eb13$90ccee60$396015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Yoshihiro Ohba" Cc: "Erik Nordmark" , "Hesham Soliman \(ERA\)" , References: <011f01c1ead4$62618890$1601a8c0@AlperVAIO> <20020423185816.GA603@catfish> Subject: Re: Location of authentication agent Date: Tue, 23 Apr 2002 15:09:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <7OXZU.A.O0E.71dx8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Yoshihiro, Based on the discussion, this seems like one way to use PANA. But of course it relies on an out-of-band PAA discovery. This shouldn't create any new requirement on the protocol. alper ----- Original Message ----- From: "Yoshihiro Ohba" To: "Alper E. YEGIN" Cc: "Erik Nordmark" ; "Hesham Soliman (ERA)" ; Sent: Tuesday, April 23, 2002 11:58 AM Subject: Re: Location of authentication agent > Interesting. > > That means, by allowing PANA messaging over IP-in-IP tunnel over > multiple IP hops, local re-authentication at an event of interface > switching would be still possible without mandating the use of other > protocols such as context transfer and AAA. > > Is my understanding correct? > > Yoshihiro Ohba > > > On Tue, Apr 23, 2002 at 07:36:54AM -0700, Alper E. YEGIN wrote: > > > > > > > > 1- PAA is on the same subnet as PaC, and > > > > 2- we assume PAA is co-located with EP. > > > > > > > > [1] makes the discovery real easy. It can be as > > > > simple as picking a link-scoped multicast address, > > > > for example. > > > > > > An interesting question here is whether this can be > > > applied to IP-in-IP tunnels as a link layer. > > > > It should be applicable. > > > > > > > > Is that is the case then such tunneling might be a way to > > > handle cases when, through some out-of-band "discovery" mechanism, the PaC > > > desires to authenticate to an entity not on the physical link. > > > > > > An example of this might be to pre-authenticate to a (potential) future > > > access router when L2 is capable of indicating the IP address of the > > future > > > AR to the PaC. > > > > Yes. In this scenario, the PaC can go through a full PANA > > exchange while still attached to the current access point. This would > > establish authenticity of the client at the new access point (and establish > > session keys depending on the EAP method). > > > > As soon as the PaC attaches to the new access point, it can go through a > > partial PANA exchange, or partial 802.1x exchange (just identity exchanged > > to lookup the keys, no backend verification needed). > > > > alper > > > > > From pana-request@research.telcordia.com Tue Apr 23 18:35:23 2002 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 SAA08496 for ; Tue, 23 Apr 2002 18:35:23 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3NMX7aS020695; Tue, 23 Apr 2002 18:33:07 -0400 (EDT) Resent-Date: Tue, 23 Apr 2002 18:33:07 -0400 (EDT) Old-Return-Path: Message-ID: <007701c1eb15$cab821b0$396015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Erik Nordmark" , "Hesham Soliman \(ERA\)" Cc: "'Erik Nordmark'" , References: Subject: Re: Location of authentication agent Date: Tue, 23 Apr 2002 15:25:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > > The first question is why does the user need to know? > > A reasonable answer is that the user wants to know > > what he/she are paying for. But this depends on > > the charging model. So if they're charge by time, > > there can be a default idle time, after which the > > PaC logs the user out. In this case the use might > > get some indication from a GUI (just like a modem > > logs a user out after a set idle time). This > > is the same issue for modems operating in countries > > where a phone call is charged by time, or when > > using a mobile phone for a dialup connection. > > I think I stated this before. Let me try again. > *Unless* you are going to ban/forbid/outlaw billing based on "connect time" > the approach taken MUST provide a mechanism by which the user is certain > that it has "disconnected" from the service that uses such billing. > > Thus the complexity of wanting to support some things being free and > other things not being free means that there needs to be an approach for > how to handle this. Note that this doesn't mean that any protocol is needed - > but the approach to solving the problem needs to take this into > account. > > So as long as the PANA usage scenarios document talk about this > case and it remains (significant) motivation for a requirement > that the PAA be separable from the access control enforcement point, > then I think we need to continue to explore this space until there is > an answer. Hesham, in addition to showing how this would work with separation, we still need to see how it doesn't work with co-location. Furthermore, we also need to understand how important of a problem this is to solve. If this can be solved by locating PAA one hop away from the PaC, then no problem (already covered). When on the same link as PaC, if we still need to separate PAA from EP, this is still OK, and we'd like to keep the additional transport between two outside the scope of PANA (see the FAQ). The goal is to define the minimum scope for PANA that is useful and can solve important/essential problems. alper From pana-request@research.telcordia.com Tue Apr 23 18:48:02 2002 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 SAA08804 for ; Tue, 23 Apr 2002 18:48:01 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3NMimh8021576; Tue, 23 Apr 2002 18:44:48 -0400 (EDT) Resent-Date: Tue, 23 Apr 2002 18:44:48 -0400 (EDT) Old-Return-Path: Date: Tue, 23 Apr 2002 18:44:36 -0400 To: "Alper E. YEGIN" Cc: Yoshihiro Ohba , Erik Nordmark , "Hesham Soliman (ERA)" , pana@research.telcordia.com Subject: Re: Location of authentication agent Message-ID: <20020423224436.GB1155@catfish> Mail-Followup-To: "Alper E. YEGIN" , Yoshihiro Ohba , Erik Nordmark , "Hesham Soliman (ERA)" , pana@research.telcordia.com References: <011f01c1ead4$62618890$1601a8c0@AlperVAIO> <20020423185816.GA603@catfish> <006b01c1eb13$90ccee60$396015ac@AlperVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <006b01c1eb13$90ccee60$396015ac@AlperVAIO> User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 90 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Alper, On Tue, Apr 23, 2002 at 03:09:36PM -0700, Alper E. YEGIN wrote: > > Yoshihiro, > > Based on the discussion, this seems like one way to use > PANA. But of course it relies on an out-of-band PAA discovery. What does the out-of-band PAA discovery mean in this case? > > This shouldn't create any new requirement on the protocol. Agreed. I'd just like to know whether the interface switching scenario is still worth being described in the usage scenario draft or not. Yoshihiro Ohba > > alper > > > ----- Original Message ----- > From: "Yoshihiro Ohba" > To: "Alper E. YEGIN" > Cc: "Erik Nordmark" ; "Hesham Soliman (ERA)" > ; > Sent: Tuesday, April 23, 2002 11:58 AM > Subject: Re: Location of authentication agent > > > > Interesting. > > > > That means, by allowing PANA messaging over IP-in-IP tunnel over > > multiple IP hops, local re-authentication at an event of interface > > switching would be still possible without mandating the use of other > > protocols such as context transfer and AAA. > > > > Is my understanding correct? > > > > Yoshihiro Ohba > > > > > > On Tue, Apr 23, 2002 at 07:36:54AM -0700, Alper E. YEGIN wrote: > > > > > > > > > > > 1- PAA is on the same subnet as PaC, and > > > > > 2- we assume PAA is co-located with EP. > > > > > > > > > > [1] makes the discovery real easy. It can be as > > > > > simple as picking a link-scoped multicast address, > > > > > for example. > > > > > > > > An interesting question here is whether this can be > > > > applied to IP-in-IP tunnels as a link layer. > > > > > > It should be applicable. > > > > > > > > > > > Is that is the case then such tunneling might be a way to > > > > handle cases when, through some out-of-band "discovery" mechanism, the > PaC > > > > desires to authenticate to an entity not on the physical link. > > > > > > > > An example of this might be to pre-authenticate to a (potential) > future > > > > access router when L2 is capable of indicating the IP address of the > > > future > > > > AR to the PaC. > > > > > > Yes. In this scenario, the PaC can go through a full PANA > > > exchange while still attached to the current access point. This would > > > establish authenticity of the client at the new access point (and > establish > > > session keys depending on the EAP method). > > > > > > As soon as the PaC attaches to the new access point, it can go through a > > > partial PANA exchange, or partial 802.1x exchange (just identity > exchanged > > > to lookup the keys, no backend verification needed). > > > > > > alper > > > > > > > > > > From pana-request@research.telcordia.com Tue Apr 23 19:10:57 2002 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 TAA09379 for ; Tue, 23 Apr 2002 19:10:57 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3NN88tm026638; Tue, 23 Apr 2002 19:08:08 -0400 (EDT) Resent-Date: Tue, 23 Apr 2002 19:08:08 -0400 (EDT) Old-Return-Path: Message-ID: <00a701c1eb1a$b561d810$396015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Yoshihiro Ohba" Cc: "Yoshihiro Ohba" , "Erik Nordmark" , "Hesham Soliman \(ERA\)" , References: <011f01c1ead4$62618890$1601a8c0@AlperVAIO> <20020423185816.GA603@catfish> <006b01c1eb13$90ccee60$396015ac@AlperVAIO> <20020423224436.GB1155@catfish> Subject: Re: Location of authentication agent Date: Tue, 23 Apr 2002 16:00:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > > Based on the discussion, this seems like one way to use > > PANA. But of course it relies on an out-of-band PAA discovery. > > What does the out-of-band PAA discovery mean in this case? Normally, PAA is assumed to be on the same link as PaC and PANA will define a PAA discovery method. But since in this particular usage, PAA is not on the same link as the PaC, this discovery method won't work. Instead some other mechanism/protocol should provide the identity of new PAA. An example is that PaC knows its geographic location (via GPS) and has a table with AP/PAA locations. Now it can do a simple lookup and discover the upcoming PAA(s). [disclaimer: this is just an illustration of out-of-band PAA discovery and absolutely outside the scope of PANA :) ] alper > > > > > This shouldn't create any new requirement on the protocol. > > Agreed. I'd just like to know whether the interface switching > scenario is still worth being described in the usage scenario draft or > not. > > Yoshihiro Ohba > > > > > > alper > > > > > > ----- Original Message ----- > > From: "Yoshihiro Ohba" > > To: "Alper E. YEGIN" > > Cc: "Erik Nordmark" ; "Hesham Soliman (ERA)" > > ; > > Sent: Tuesday, April 23, 2002 11:58 AM > > Subject: Re: Location of authentication agent > > > > > > > Interesting. > > > > > > That means, by allowing PANA messaging over IP-in-IP tunnel over > > > multiple IP hops, local re-authentication at an event of interface > > > switching would be still possible without mandating the use of other > > > protocols such as context transfer and AAA. > > > > > > Is my understanding correct? > > > > > > Yoshihiro Ohba > > > > > > > > > On Tue, Apr 23, 2002 at 07:36:54AM -0700, Alper E. YEGIN wrote: > > > > > > > > > > > > > > 1- PAA is on the same subnet as PaC, and > > > > > > 2- we assume PAA is co-located with EP. > > > > > > > > > > > > [1] makes the discovery real easy. It can be as > > > > > > simple as picking a link-scoped multicast address, > > > > > > for example. > > > > > > > > > > An interesting question here is whether this can be > > > > > applied to IP-in-IP tunnels as a link layer. > > > > > > > > It should be applicable. > > > > > > > > > > > > > > Is that is the case then such tunneling might be a way to > > > > > handle cases when, through some out-of-band "discovery" mechanism, the > > PaC > > > > > desires to authenticate to an entity not on the physical link. > > > > > > > > > > An example of this might be to pre-authenticate to a (potential) > > future > > > > > access router when L2 is capable of indicating the IP address of the > > > > future > > > > > AR to the PaC. > > > > > > > > Yes. In this scenario, the PaC can go through a full PANA > > > > exchange while still attached to the current access point. This would > > > > establish authenticity of the client at the new access point (and > > establish > > > > session keys depending on the EAP method). > > > > > > > > As soon as the PaC attaches to the new access point, it can go through a > > > > partial PANA exchange, or partial 802.1x exchange (just identity > > exchanged > > > > to lookup the keys, no backend verification needed). > > > > > > > > alper > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Tue Apr 23 19:42:22 2002 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 TAA09919 for ; Tue, 23 Apr 2002 19:42:18 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3NNd8Cj028408; Tue, 23 Apr 2002 19:39:08 -0400 (EDT) Resent-Date: Tue, 23 Apr 2002 19:39:08 -0400 (EDT) Old-Return-Path: Date: Tue, 23 Apr 2002 19:38:58 -0400 To: "Alper E. YEGIN" Cc: Erik Nordmark , "Hesham Soliman (ERA)" , pana@research.telcordia.com Subject: Re: Location of authentication agent Message-ID: <20020423233858.GD1155@catfish> Mail-Followup-To: "Alper E. YEGIN" , Erik Nordmark , "Hesham Soliman (ERA)" , pana@research.telcordia.com References: <007701c1eb15$cab821b0$396015ac@AlperVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <007701c1eb15$cab821b0$396015ac@AlperVAIO> User-Agent: Mutt/1.3.28i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 40 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com I agree on the revised scope as long as it still leaves possibilities anyway for locating PAA one hop away from the PaC and separating PAA from EP within the same link as PaC. Although those two things are not the main focus in the revised scope, I personally think that they are worth being described in the usage scenario draft for the following reasons: Locating PAA one hop away from the PaC might be useful for 3GPP/802.11 interworking scenario based on the recent comment from Lionel Morand. Separating PAA from EP within the same link as PaC might be useful for load sharing among multiple access routers from the viewpoint of implementation cost of the access routers. Yoshihiro Ohba On Tue, Apr 23, 2002 at 03:25:33PM -0700, Alper E. YEGIN wrote: > > > Hesham, in addition to showing how this would work with separation, > we still need to see how it doesn't work with co-location. > > Furthermore, we also need to understand how important of a problem > this is to solve. > > If this can be solved by locating PAA one hop away from > the PaC, then no problem (already covered). When on the same > link as PaC, if we still need to separate PAA from EP, this is still OK, > and we'd like to keep the additional transport between two outside > the scope of PANA (see the FAQ). > > The goal is to define the minimum scope for PANA that > is useful and can solve important/essential problems. > > alper > > > > From pana-request@research.telcordia.com Wed Apr 24 04:27:07 2002 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 EAA27474 for ; Wed, 24 Apr 2002 04:27:07 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3O8OMcG022378; Wed, 24 Apr 2002 04:24:22 -0400 (EDT) Resent-Date: Wed, 24 Apr 2002 04:24:22 -0400 (EDT) Old-Return-Path: Message-ID: <00c601c1eb69$284db800$b36015ac@T23KEMPF> From: "James Kempf" To: "Alper E. YEGIN" , "Yoshihiro Ohba" Cc: "Erik Nordmark" , "Hesham Soliman \(ERA\)" , References: <007701c1eb15$cab821b0$396015ac@AlperVAIO> <20020423233858.GD1155@catfish> Subject: Re: Location of authentication agent Date: Wed, 24 Apr 2002 01:09:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Sorry, Yoshi, but if this is considered in scope, then I believe it is incumbent on the working group to explore the implications of this radical change in the NAS architecture, including security. I would prefer if the WG focused on the simple task first, and that this was excised from the scenarios draft. jak ----- Original Message ----- From: "Yoshihiro Ohba" To: "Alper E. YEGIN" Cc: "Erik Nordmark" ; "Hesham Soliman (ERA)" ; Sent: Tuesday, April 23, 2002 4:38 PM Subject: Re: Location of authentication agent > > I agree on the revised scope as long as it still leaves possibilities > anyway for locating PAA one hop away from the PaC and separating PAA > from EP within the same link as PaC. Although > those two things are not the main focus in the revised scope, > I personally think that they are worth being described in the > usage scenario draft for the following reasons: > > Locating PAA one hop away from the PaC might be useful for > 3GPP/802.11 interworking scenario based on the recent comment from > Lionel Morand. Separating PAA from EP within the same link as PaC > might be useful for load sharing among multiple access routers > from the viewpoint of implementation cost of the access routers. > > Yoshihiro Ohba > > > On Tue, Apr 23, 2002 at 03:25:33PM -0700, Alper E. YEGIN wrote: > > > > > > Hesham, in addition to showing how this would work with separation, > > we still need to see how it doesn't work with co-location. > > > > Furthermore, we also need to understand how important of a problem > > this is to solve. > > > > If this can be solved by locating PAA one hop away from > > the PaC, then no problem (already covered). When on the same > > link as PaC, if we still need to separate PAA from EP, this is still OK, > > and we'd like to keep the additional transport between two outside > > the scope of PANA (see the FAQ). > > > > The goal is to define the minimum scope for PANA that > > is useful and can solve important/essential problems. > > > > alper > > > > > > > > > > From pana-request@research.telcordia.com Wed Apr 24 04:27:12 2002 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 EAA27486 for ; Wed, 24 Apr 2002 04:27:12 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3O8O1Up022347; Wed, 24 Apr 2002 04:24:01 -0400 (EDT) Resent-Date: Wed, 24 Apr 2002 04:24:01 -0400 (EDT) Old-Return-Path: Message-ID: <00c201c1eb69$222ad390$b36015ac@T23KEMPF> From: "James Kempf" To: "Alper E. YEGIN" , "Yoshihiro Ohba" Cc: "Erik Nordmark" , "Hesham Soliman \(ERA\)" , References: <011f01c1ead4$62618890$1601a8c0@AlperVAIO> <20020423185816.GA603@catfish> Subject: Re: Location of authentication agent Date: Wed, 24 Apr 2002 00:19:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Why would you want to do this? jak ----- Original Message ----- From: "Yoshihiro Ohba" To: "Alper E. YEGIN" Cc: "Erik Nordmark" ; "Hesham Soliman (ERA)" ; Sent: Tuesday, April 23, 2002 11:58 AM Subject: Re: Location of authentication agent > Interesting. > > That means, by allowing PANA messaging over IP-in-IP tunnel over > multiple IP hops, local re-authentication at an event of interface > switching would be still possible without mandating the use of other > protocols such as context transfer and AAA. > > Is my understanding correct? > > Yoshihiro Ohba > > > On Tue, Apr 23, 2002 at 07:36:54AM -0700, Alper E. YEGIN wrote: > > > > > > > > 1- PAA is on the same subnet as PaC, and > > > > 2- we assume PAA is co-located with EP. > > > > > > > > [1] makes the discovery real easy. It can be as > > > > simple as picking a link-scoped multicast address, > > > > for example. > > > > > > An interesting question here is whether this can be > > > applied to IP-in-IP tunnels as a link layer. > > > > It should be applicable. > > > > > > > > Is that is the case then such tunneling might be a way to > > > handle cases when, through some out-of-band "discovery" mechanism, the PaC > > > desires to authenticate to an entity not on the physical link. > > > > > > An example of this might be to pre-authenticate to a (potential) future > > > access router when L2 is capable of indicating the IP address of the > > future > > > AR to the PaC. > > > > Yes. In this scenario, the PaC can go through a full PANA > > exchange while still attached to the current access point. This would > > establish authenticity of the client at the new access point (and establish > > session keys depending on the EAP method). > > > > As soon as the PaC attaches to the new access point, it can go through a > > partial PANA exchange, or partial 802.1x exchange (just identity exchanged > > to lookup the keys, no backend verification needed). > > > > alper > > > > > > From pana-request@research.telcordia.com Wed Apr 24 04:27:37 2002 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 EAA27511 for ; Wed, 24 Apr 2002 04:27:37 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3O8Ovu9022410; Wed, 24 Apr 2002 04:24:57 -0400 (EDT) Resent-Date: Wed, 24 Apr 2002 04:24:57 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACB7@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Alper E. YEGIN'" , Erik Nordmark , "Hesham Soliman (ERA)" Cc: "'Erik Nordmark'" , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Wed, 24 Apr 2002 10:22:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > > Hesham, in addition to showing how this would work with separation, > we still need to see how it doesn't work with co-location. => Sure, it would be good if we share ideas on how this could really work when the PAA is on-link. Note that I don't assume that there is always a backend AAA infrastructure. > > Furthermore, we also need to understand how important of a problem > this is to solve. => This is a grey area. Very little engineering here and lots of speculation. I'd rather not go there. > > If this can be solved by locating PAA one hop away from > the PaC, then no problem (already covered). When on the same > link as PaC, if we still need to separate PAA from EP, this > is still OK, > and we'd like to keep the additional transport between two outside > the scope of PANA (see the FAQ). > > The goal is to define the minimum scope for PANA that > is useful and can solve important/essential problems. => Sure. Hesham > > alper > > > From pana-request@research.telcordia.com Wed Apr 24 04:29:45 2002 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 EAA27549 for ; Wed, 24 Apr 2002 04:29:45 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3O8QlLJ022488; Wed, 24 Apr 2002 04:26:47 -0400 (EDT) Resent-Date: Wed, 24 Apr 2002 04:26:47 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACB8@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Alper E. YEGIN'" , Yoshihiro Ohba Cc: Yoshihiro Ohba , Erik Nordmark , "Hesham Soliman (ERA)" , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Wed, 24 Apr 2002 10:24:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > > > Based on the discussion, this seems like one way to use > > > PANA. But of course it relies on an out-of-band PAA discovery. > > > > What does the out-of-band PAA discovery mean in this case? > > Normally, PAA is assumed to be on the same link as PaC and > PANA will define a PAA discovery method. > > But since in this particular usage, PAA is not on the same link > as the PaC, this discovery method won't work. Instead some > other mechanism/protocol should provide the identity of > new PAA. > > An example is that PaC knows its geographic location > (via GPS) and has a table with AP/PAA locations. Now it can do > a simple lookup and discover the upcoming PAA(s). > [disclaimer: this is just an illustration of out-of-band PAA > discovery and absolutely outside the scope of PANA :) ] > => Or even PAA.localdomain.X can be done. Hesham From pana-request@research.telcordia.com Wed Apr 24 04:34:59 2002 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 EAA27622 for ; Wed, 24 Apr 2002 04:34:58 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3O8J3vu022166; Wed, 24 Apr 2002 04:19:03 -0400 (EDT) Resent-Date: Wed, 24 Apr 2002 04:19:03 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACB6@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , "Hesham Soliman (ERA)" Cc: "'Alper E. YEGIN'" , "'pana@research.telcordia.com'" Subject: RE: Location of authentication agent Date: Wed, 24 Apr 2002 10:18:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > > The first question is why does the user need to know? > > A reasonable answer is that the user wants to know > > what he/she are paying for. But this depends on > > the charging model. So if they're charge by time, > > there can be a default idle time, after which the > > PaC logs the user out. In this case the use might > > get some indication from a GUI (just like a modem > > logs a user out after a set idle time). This > > is the same issue for modems operating in countries > > where a phone call is charged by time, or when > > using a mobile phone for a dialup connection. > > I think I stated this before. Let me try again. > *Unless* you are going to ban/forbid/outlaw billing based > on "connect time" > the approach taken MUST provide a mechanism by which the > user is certain > that it has "disconnected" from the service that uses such billing. => Agreed. My text above was an attempt to show one way of doing it. But as you say below the solution would need to take this into account. > > Thus the complexity of wanting to support some things being free and > other things not being free means that there needs to be an > approach for > how to handle this. Note that this doesn't mean that any > protocol is needed - > but the approach to solving the problem needs to take this into > account. > > So as long as the PANA usage scenarios document talk about this > case and it remains (significant) motivation for a requirement > that the PAA be separable from the access control enforcement point, > then I think we need to continue to explore this space > until there is > an answer. => Agreed. Hesham From pana-request@research.telcordia.com Wed Apr 24 11:42:26 2002 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 LAA19705 for ; Wed, 24 Apr 2002 11:42:26 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3OFbB4p026971; Wed, 24 Apr 2002 11:37:11 -0400 (EDT) Resent-Date: Wed, 24 Apr 2002 11:37:11 -0400 (EDT) Old-Return-Path: Message-ID: <004001c1eba4$d4348460$516015ac@AlperVAIO> From: "Alper E. YEGIN" To: "James Kempf" , "Yoshihiro Ohba" Cc: "Erik Nordmark" , "Hesham Soliman \(ERA\)" , "Pana \(E-mail\)" References: <007701c1eb15$cab821b0$396015ac@AlperVAIO> <20020423233858.GD1155@catfish> <00c601c1eb69$284db800$b36015ac@T23KEMPF> Subject: Re: Location of authentication agent Date: Wed, 24 Apr 2002 08:28:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Per minimum scope, PANA still leaves the possibility that PAA can be separated from EP, but PANA doesn't suggest or take extra actions to enable this feature. This separation can be done for some advanced features or optimizations, which are not what PANA is aiming to provide. If we have this scenario in the draft, we should clearly state that the additional transport and the possible security issues of this separation is outside the scope of PANA. And for that matter, I don't think this is a good/typical scenario to list in the draft. This is not the fundamental problem PANA is aiming to solve. I think it is sufficient to see that PANA doesn't prevent this scenario, for those who are interested in using PANA in such an architecure. The usage scenarios and the requirements draft will have to be updated based on the re-defined charter anyways.. alper > Sorry, Yoshi, but if this is considered in scope, then I believe it is > incumbent on the working group to explore the implications of this > radical change in the NAS architecture, including security. I would > prefer if the WG focused on the simple task first, and that this was > excised from the scenarios draft. > > jak > > ----- Original Message ----- > From: "Yoshihiro Ohba" > To: "Alper E. YEGIN" > Cc: "Erik Nordmark" ; "Hesham Soliman (ERA)" > ; > Sent: Tuesday, April 23, 2002 4:38 PM > Subject: Re: Location of authentication agent > > > > > > I agree on the revised scope as long as it still leaves possibilities > > anyway for locating PAA one hop away from the PaC and separating PAA > > from EP within the same link as PaC. Although > > those two things are not the main focus in the revised scope, > > I personally think that they are worth being described in the > > usage scenario draft for the following reasons: > > > > Locating PAA one hop away from the PaC might be useful for > > 3GPP/802.11 interworking scenario based on the recent comment from > > Lionel Morand. Separating PAA from EP within the same link as PaC > > might be useful for load sharing among multiple access routers > > from the viewpoint of implementation cost of the access routers. > > > > Yoshihiro Ohba > > > > > > On Tue, Apr 23, 2002 at 03:25:33PM -0700, Alper E. YEGIN wrote: > > > > > > > > > Hesham, in addition to showing how this would work with separation, > > > we still need to see how it doesn't work with co-location. > > > > > > Furthermore, we also need to understand how important of a problem > > > this is to solve. > > > > > > If this can be solved by locating PAA one hop away from > > > the PaC, then no problem (already covered). When on the same > > > link as PaC, if we still need to separate PAA from EP, this is still > OK, > > > and we'd like to keep the additional transport between two outside > > > the scope of PANA (see the FAQ). > > > > > > The goal is to define the minimum scope for PANA that > > > is useful and can solve important/essential problems. > > > > > > alper > > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Wed Apr 24 16:06:37 2002 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 QAA05744 for ; Wed, 24 Apr 2002 16:06:09 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3OJuIMr021418; Wed, 24 Apr 2002 15:56:18 -0400 (EDT) Resent-Date: Wed, 24 Apr 2002 15:56:18 -0400 (EDT) Old-Return-Path: Message-ID: <20020424195503.283.qmail@web20405.mail.yahoo.com> Date: Wed, 24 Apr 2002 12:55:03 -0700 (PDT) From: Reinaldo Penno Subject: Re: Location of authentication agent To: "Alper E. YEGIN" , James Kempf , Yoshihiro Ohba Cc: Erik Nordmark , "Hesham Soliman \(ERA\)" , "Pana \(E-mail\)" In-Reply-To: <004001c1eba4$d4348460$516015ac@AlperVAIO> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com I agree with Alper that this is the best course of action this time. Reinaldo --- "Alper E. YEGIN" wrote: > > Per minimum scope, PANA still leaves the possibility > that PAA can be separated from EP, but PANA doesn't > suggest or take extra actions to enable this > feature. > This separation can be done for some advanced > features or > optimizations, which are not what PANA is aiming to > provide. > > If we have this scenario in the draft, we should > clearly state > that the additional transport and the possible > security issues > of this separation is outside the scope of PANA. And > for that > matter, I don't think this is a good/typical > scenario to list in the > draft. This is not the fundamental problem PANA is > aiming > to solve. > > I think it is sufficient to see that PANA doesn't > prevent this scenario, > for those who are interested in using PANA in such > an architecure. > > The usage scenarios and the requirements draft will > have to be > updated based on the re-defined charter anyways.. > > > alper > > > > > Sorry, Yoshi, but if this is considered in scope, > then I believe it is > > incumbent on the working group to explore the > implications of this > > radical change in the NAS architecture, including > security. I would > > prefer if the WG focused on the simple task first, > and that this was > > excised from the scenarios draft. > > > > jak > > > > ----- Original Message ----- > > From: "Yoshihiro Ohba" > > To: "Alper E. YEGIN" > > Cc: "Erik Nordmark" ; > "Hesham Soliman (ERA)" > > ; > > > Sent: Tuesday, April 23, 2002 4:38 PM > > Subject: Re: Location of authentication agent > > > > > > > > > > I agree on the revised scope as long as it still > leaves possibilities > > > anyway for locating PAA one hop away from the > PaC and separating PAA > > > from EP within the same link as PaC. Although > > > those two things are not the main focus in the > revised scope, > > > I personally think that they are worth being > described in the > > > usage scenario draft for the following reasons: > > > > > > Locating PAA one hop away from the PaC might be > useful for > > > 3GPP/802.11 interworking scenario based on the > recent comment from > > > Lionel Morand. Separating PAA from EP within > the same link as PaC > > > might be useful for load sharing among multiple > access routers > > > from the viewpoint of implementation cost of the > access routers. > > > > > > Yoshihiro Ohba > > > > > > > > > On Tue, Apr 23, 2002 at 03:25:33PM -0700, Alper > E. YEGIN wrote: > > > > > > > > > > > > Hesham, in addition to showing how this would > work with separation, > > > > we still need to see how it doesn't work with > co-location. > > > > > > > > Furthermore, we also need to understand how > important of a problem > > > > this is to solve. > > > > > > > > If this can be solved by locating PAA one hop > away from > > > > the PaC, then no problem (already covered). > When on the same > > > > link as PaC, if we still need to separate PAA > from EP, this is still > > OK, > > > > and we'd like to keep the additional transport > between two outside > > > > the scope of PANA (see the FAQ). > > > > > > > > The goal is to define the minimum scope for > PANA that > > > > is useful and can solve important/essential > problems. > > > > > > > > alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ From pana-request@research.telcordia.com Thu Apr 25 11:02:23 2002 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 LAA08495 for ; Thu, 25 Apr 2002 11:02:22 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3PEv62P001896; Thu, 25 Apr 2002 10:57:06 -0400 (EDT) Resent-Date: Thu, 25 Apr 2002 10:57:06 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACC6@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , "Hesham Soliman (ERA)" Cc: "'Alper E. YEGIN'" , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Thu, 25 Apr 2002 16:54:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > > > Furthermore, we also need to understand how important > of a problem > > > this is to solve. > > > > => This is a grey area. Very little engineering > > here and lots of speculation. I'd rather not go > > there. > > If it's all speculation on how this would be used then I think it > is pretty clear that it isn't an important enough problem to solve. > > I think the WG should work on concrete, clear, and > important problems. => I guess I don't know how to prove beyond doubt that the problem is important from a 'market use' point of view. Perhaps people who suggested these scenarios have more input on how important they are, or can motivate others to say that they need them. Hesham From pana-request@research.telcordia.com Thu Apr 25 11:34:23 2002 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 LAA23896 for ; Thu, 25 Apr 2002 11:34:22 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3PFP6Bm004965; Thu, 25 Apr 2002 11:25:06 -0400 (EDT) Resent-Date: Thu, 25 Apr 2002 11:25:06 -0400 (EDT) Old-Return-Path: Message-ID: <3CC81365.2735DECF@research.telcordia.com> Date: Thu, 25 Apr 2002 10:32:05 -0400 From: subir Das X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alper E. YEGIN" , pana@research.telcordia.com Subject: Re: Location of authentication agent References: <007701c1eb15$cab821b0$396015ac@AlperVAIO> <20020423233858.GD1155@catfish> <00c601c1eb69$284db800$b36015ac@T23KEMPF> <004001c1eba4$d4348460$516015ac@AlperVAIO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit Alper, > The usage scenarios and the requirements draft will have to be > updated based on the re-defined charter anyways.. We will update the usage scenario draft according to minimally scoped PANA. Subir From pana-request@research.telcordia.com Thu Apr 25 12:25:03 2002 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 MAA26223 for ; Thu, 25 Apr 2002 12:24:53 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3PG2VNr009067; Thu, 25 Apr 2002 12:02:31 -0400 (EDT) Resent-Date: Thu, 25 Apr 2002 12:02:31 -0400 (EDT) Old-Return-Path: Message-Id: <4.3.2.7.2.20020425114729.01a93008@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Apr 2002 11:57:43 -0400 To: Erik Nordmark From: John Schnizlein Subject: Re: Location of authentication agent Cc: pana@research.telcordia.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Erik, You probably will have seen the discussion by the time this summary reaches you, but it doesn't hurt me to be more succinct. My hope is that deciding that support for walled-garden designs were non-goals of PANA would remove the "requirement" for the enforcement point to be at an edge other than the one near the point of access, which is where I would expect the authenticator to be located. Although this would not necessarily preclude the separation between the EP and Authenticator, it would remove the only reason I have seen for this separation. While I worry some about the complexity of this separation, the potential goal of supporting walled gardens is a greater worry. John At 10:36 AM 4/25/2002, Erik Nordmark wrote: >John, > >I'm behind on email but I'm trying to understand what >technical constraint but be created by an edict to not explicitly >support walled gardens. > > Erik > >> One of the technical implications drawn from the >> escape-walled-garden model was that the access control would not >> be at the edge between subscribers and Internet-like communication, >> but instead the edge would be defined between walled gardens. >> This "requirement" seems to have re-emerged when the question of >> locating the EP at the edge was asked explicitly. >> >> Making support for walled gardens a non-goal of the WG (instead >> of just removing it from the documents reviewed by the IESG) >> would allow finding other reasons (if they exist) for locating >> the EP somewhere other than the edge, but would avoid renewing >> this goal now that the WG has been chartered without it. From pana-request@research.telcordia.com Thu Apr 25 19:15:24 2002 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 TAA08770 for ; Thu, 25 Apr 2002 19:15:17 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3PNBCnH018365; Thu, 25 Apr 2002 19:11:12 -0400 (EDT) Resent-Date: Thu, 25 Apr 2002 19:11:12 -0400 (EDT) Old-Return-Path: Message-ID: <00ac01c1ecad$756d28b0$5d6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Erik Nordmark" , "Hesham Soliman \(ERA\)" Cc: References: Subject: Re: Location of authentication agent Date: Thu, 25 Apr 2002 16:03:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <-sI-sC.A.1eE.P0Iy8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Content-Transfer-Encoding: 7bit > > > > > > Furthermore, we also need to understand how important of a problem > > > this is to solve. > > > > => This is a grey area. Very little engineering > > here and lots of speculation. I'd rather not go > > there. > > If it's all speculation on how this would be used then I think it > is pretty clear that it isn't an important enough problem to solve. > > I think the WG should work on concrete, clear, and important problems. There are few issues with this scenario. One is that it is not fully cooked yet. It's still missing non-PANA related details, such as user interface (how to notify user what is happening, when to start and stop the authenticated/ authorized session). The other is, the current feedback we received doesn't indicate a need for this scenario. Even if we had decided to handle this case, I believe the current scope of PANA would allow this to work. We don't have to place the PAA somewhere deeper in the network to detect that a PaC is attempting to go beyond a certain topology. A PAA located at the edge of the network can very well detect this by examining the destination of the packets sent by the PaC. For the above reasons, I don't think we need to extend the current scope of PANA for this scenario. alper From pana-request@research.telcordia.com Mon Apr 29 05:35:08 2002 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 FAA16129 for ; Mon, 29 Apr 2002 05:35:08 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3T9VOWH024692; Mon, 29 Apr 2002 05:31:24 -0400 (EDT) Resent-Date: Mon, 29 Apr 2002 05:31:24 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACD4@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "Hesham Soliman (ERA)" , "'Alper E. YEGIN'" , "'James Kempf'" , "'Yoshihiro Ohba'" Cc: "'Erik Nordmark'" , "Hesham Soliman (ERA)" , "'Pana (E-mail)'" Subject: RE: Location of authentication agent Date: Mon, 29 Apr 2002 11:30:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com Alper, I agree with your approach below. Hesham > > -----Original Message----- > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > Sent: Wednesday, April 24, 2002 5:29 PM > > To: James Kempf; Yoshihiro Ohba > > Cc: Erik Nordmark; Hesham Soliman (ERA); Pana (E-mail) > > Subject: Re: Location of authentication agent > > > > > > > > Per minimum scope, PANA still leaves the possibility > > that PAA can be separated from EP, but PANA doesn't > > suggest or take extra actions to enable this feature. > > This separation can be done for some advanced features or > > optimizations, which are not what PANA is aiming to provide. > > > > If we have this scenario in the draft, we should clearly state > > that the additional transport and the possible security issues > > of this separation is outside the scope of PANA. And for that > > matter, I don't think this is a good/typical scenario > to list in the > > draft. This is not the fundamental problem PANA is aiming > > to solve. > > > > I think it is sufficient to see that PANA doesn't prevent > > this scenario, > > for those who are interested in using PANA in such an > architecure. > > > > The usage scenarios and the requirements draft will have to be > > updated based on the re-defined charter anyways.. > > > > > > alper > > > > > > > > > Sorry, Yoshi, but if this is considered in scope, then I > > believe it is > > > incumbent on the working group to explore the > implications of this > > > radical change in the NAS architecture, including > > security. I would > > > prefer if the WG focused on the simple task first, and > > that this was > > > excised from the scenarios draft. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Yoshihiro Ohba" > > > To: "Alper E. YEGIN" > > > Cc: "Erik Nordmark" ; "Hesham > > Soliman (ERA)" > > > ; > > > > Sent: Tuesday, April 23, 2002 4:38 PM > > > Subject: Re: Location of authentication agent > > > > > > > > > > > > > > I agree on the revised scope as long as it still leaves > > possibilities > > > > anyway for locating PAA one hop away from the PaC and > > separating PAA > > > > from EP within the same link as PaC. Although > > > > those two things are not the main focus in the > revised scope, > > > > I personally think that they are worth being > described in the > > > > usage scenario draft for the following reasons: > > > > > > > > Locating PAA one hop away from the PaC might be useful for > > > > 3GPP/802.11 interworking scenario based on the recent > > comment from > > > > Lionel Morand. Separating PAA from EP within the same > > link as PaC > > > > might be useful for load sharing among multiple > access routers > > > > from the viewpoint of implementation cost of the > access routers. > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > On Tue, Apr 23, 2002 at 03:25:33PM -0700, Alper E. > YEGIN wrote: > > > > > > > > > > > > > > > Hesham, in addition to showing how this would work > > with separation, > > > > > we still need to see how it doesn't work with co-location. > > > > > > > > > > Furthermore, we also need to understand how important > > of a problem > > > > > this is to solve. > > > > > > > > > > If this can be solved by locating PAA one hop away from > > > > > the PaC, then no problem (already covered). When > on the same > > > > > link as PaC, if we still need to separate PAA from > > EP, this is still > > > OK, > > > > > and we'd like to keep the additional transport > > between two outside > > > > > the scope of PANA (see the FAQ). > > > > > > > > > > The goal is to define the minimum scope for PANA that > > > > > is useful and can solve important/essential problems. > > > > > > > > > > alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From pana-request@research.telcordia.com Tue Apr 30 07:57:43 2002 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 HAA14974 for ; Tue, 30 Apr 2002 07:57:43 -0400 (EDT) Received: (from slmgr@localhost) by thumper.research.telcordia.com (8.12.1/8.12.1) id g3UBr822014116; Tue, 30 Apr 2002 07:53:08 -0400 (EDT) Resent-Date: Tue, 30 Apr 2002 07:53:08 -0400 (EDT) Old-Return-Path: Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ACFC@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , "Hesham Soliman (ERA)" Cc: "'Alper E. YEGIN'" , pana@research.telcordia.com Subject: RE: Location of authentication agent Date: Tue, 30 Apr 2002 13:52:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Resent-Message-ID: <7Q6D-.A.ccD.kWoz8@thumper> Resent-From: pana@research.telcordia.com X-Mailing-List: X-Loop: pana@research.telcordia.com List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: pana-request@research.telcordia.com > > > If it's all speculation on how this would be used > then I think it > > > is pretty clear that it isn't an important enough > problem to solve. > > > > > > I think the WG should work on concrete, clear, and > > > important problems. > > > > => I guess I don't know how to prove beyond doubt > > that the problem is important from a 'market use' > > point of view. Perhaps people who suggested these > > scenarios have more input on how important they > > are, or can motivate others to say that they > > need them. > > Hasham, > you quoted my email and you use the M-word. Just to make > sure; I didn't > refer to the Market. > > There has to be a clear technical motivation > for the use of what we build. Thus if folks can accomplish > 80, 90, or 95% of > what they need using existing tools (aka protocols) they > are likely to use > those even if the IETF specifies one that is a bit better. => oops, I thought you meant to ask whether operators would be interested in deploying this scenario. That's why I used the M-word. Sorry if I misquoted you. Hesham