Re: [pcp] PANA implementatinos to consider

Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp> Fri, 14 September 2012 13:22 UTC

Return-Path: <yoshihiro.ohba@toshiba.co.jp>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A4321F84A5 for <pcp@ietfa.amsl.com>; Fri, 14 Sep 2012 06:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.289
X-Spam-Level:
X-Spam-Status: No, score=-7.289 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW4DmWPAyD20 for <pcp@ietfa.amsl.com>; Fri, 14 Sep 2012 06:22:37 -0700 (PDT)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 42F3721F8470 for <pcp@ietf.org>; Fri, 14 Sep 2012 06:22:37 -0700 (PDT)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q8EDMVwY016361 for <pcp@ietf.org>; Fri, 14 Sep 2012 22:22:31 +0900 (JST)
Received: (from root@localhost) by arc11.toshiba.co.jp id q8EDMVNS014468 for pcp@ietf.org; Fri, 14 Sep 2012 22:22:31 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA14467; Fri, 14 Sep 2012 22:22:31 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q8EDMU3R009705 for <pcp@ietf.org>; Fri, 14 Sep 2012 22:22:31 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id q8EDMU0p009827; Fri, 14 Sep 2012 22:22:30 +0900 (JST)
Received: from [133.199.17.78] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0MAC0091CD5HL1K0@mail.po.toshiba.co.jp> for pcp@ietf.org; Fri, 14 Sep 2012 22:22:30 +0900 (JST)
Date: Fri, 14 Sep 2012 22:22:35 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <B860EA81-0451-4F26-BF46-382176DC9103@lilacglade.org>
To: pcp@ietf.org
Message-id: <50532F9B.9030104@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-2022-JP"
Content-transfer-encoding: 7bit
References: <0MZjvC-1SyMXc0ZaA-00Lf23@mx.perfora.net> <F621C78A-2005-46E4-969C-DF25495A735A@yegin.org> <B860EA81-0451-4F26-BF46-382176DC9103@lilacglade.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0
Subject: Re: [pcp] PANA implementatinos to consider
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Sep 2012 13:22:38 -0000

Hi Margaret,

I agree that there is a room to specify more details in the pana-pcp
draft to address your comments.  In general some interactions are
needed between an "AKM (Authentication and Key Management) function"
and the base PCP funtion.

On the other hand, if my understanding is correct, the needed set of
interactions between an AKM function and the base PCP functions are
not much different regardless of whether the AKM function is PANA or
PCP-specific, and therefore I think the interactions do not have to be
considered as a disadvantage of PANA-based approaches.

Please correct me if my understanding is wrong.

Yoshihiro Ohba

(2012/09/14 18:50), Margaret Wasserman wrote:
> 
> Hi Alper,
> 
> On Sep 14, 2012, at 2:52 AM, Alper Yegin wrote:
>> As for the implementation complexity, I don't quite understand why PANA (which is basically EAP over UDP) would ever be more complicated then to-be-designed "EAP over UDP within PCP framework". While I don't see a reason for former being more complicated, I see reasons for seeing the latter being more complicated, as the whole thing now needs to live within another protocol framework (read: format, flow, state machine harmonization between the two).
> 
> I don't understand how you get away from coupling PANA and PCP, even in the demultiplexing case where they run side-by-side on the same port.  I think a number of details are being glossed over in your latest document when you refer to a need for an "API" between PANA and PCP...
> 
> Let's start with a simple case where the PCP Client wants to initiate and authenticated PCP request...
> 
> The Client needs to ask the PANA Client to initiate authentication.  How?  Will that request include any details about the mapping request that is being made?  i.e. will the PANA Client be asking for authentication _and authorization_ to perform a particular action?  Or do we assume that a PCP client is authenticated via PANA, and that authorization for a particular action is a separate step that is performed as part of PCP?  If they are separate, do we need a new set of PCP error codes for the situation where an authenticated PCP client performs an unauthorized action, or is that already covered in the PCP spec?
> 
> When the PCP Client asks the PANA Client to perform authentication, what are the possible results that can be returned from that request, and how are they communicated back to the PCP Client?  You have only described the success case in your document.
> 
> How does this work in the case where the PCP Server is not running a PANA Server?  I _think_ that if a PCP Client asks its PANA Client to perform authentication, and the PCP Server does support authentication, some sort of "unsupported version" error code will be returned to the _PCP Client_ (due to the details of your proposed demultiplexing scheme), and that nothing will be returned to the PANA Client, at all.  We would need to make sure that secure PCP clients are specified to handle an "unsupported version" error differently when the PANA Client is in this particular state, but how does the PCP Client know that this is why that error was returned?  If this does happen, how does the PCP client inform the PANA Client that it should stop trying to perform authentication with that particular PCP Server?
> 
> Also, how does the PCP Client know when the _PCP Server_ is ready to receive its request?  Are we assuming that the PANA Server will not return an indication to the PANA Client that the client has been authenticated until _after_ it has provisioned the necessary SA on the PANA Server?
> 
> What if an additional application on the same PCP Client system wants to perform an authenticated request with the same PCP Server in the meantime?  Will that second request result in a second (interleaved) PANA negotiation, or will the PCP Client be told that a PANA negotiation is already pending?  If the latter, how will the second PCP Client thread by informed when the PANA negotiation has completed?  (Note:  The right answer here depends heavily on whether the PANA authentication depends, in any way, on the contents of a specific PCP request -- the authentication vs. authentication/authorization question above).
> 
> All of these questions will need to be answered, IMO, in a full specification of the PCP/PANA demultiplexing mechanism, precisely _because_ PCP and PANA are running separately.  The "API" is where this coupling is provided between the two "state machines", as you refer to them.  Why is this any simpler if PANA and PCP are running side-by side than if we run PANA encapsulated in PCP?  (or, if we run PCP directly over EAP, for that matter)
> 
> Margaret
> 
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
>