Re: [pcp] Capability discovery

Alper Yegin <alper.yegin@yegin.org> Fri, 05 October 2012 20:23 UTC

Return-Path: <alper.yegin@yegin.org>
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 792D421F842D for <pcp@ietfa.amsl.com>; Fri, 5 Oct 2012 13:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.503
X-Spam-Level:
X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 ucNkOtxNFqiR for <pcp@ietfa.amsl.com>; Fri, 5 Oct 2012 13:23:24 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id DAE3F21F8667 for <pcp@ietf.org>; Fri, 5 Oct 2012 13:23:23 -0700 (PDT)
Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MC4Ay-1TBSz50sLo-009GR7; Fri, 05 Oct 2012 16:23:22 -0400
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B8101A7@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
Date: Fri, 05 Oct 2012 23:23:00 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <E13227DD-3096-4D38-B9EF-93342335B7F2@yegin.org>
References: <506E4E07.3000807@toshiba.co.jp> <034101cda301$4972d690$dc5883b0$@com> <506EF948.40303@toshiba.co.jp> <9B57C850BB53634CACEC56EF4853FF653B8101A7@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
To: Dave Thaler <dthaler@microsoft.com>
X-Mailer: Apple Mail (2.1278)
X-Provags-ID: V02:K0:k/2+LamTG10JHP+UvOQmE6C3pNrvcjU3qyLlchYYiN1 mYZybcUSKCFEaSoXmUdMEccU46NBpWMC5yImtiMifwylrMGmOJ vaqLepNxBx9FMLmJM6wVPIKmAz6m10k6sY2LOyDBdtYSgWbN/V /gjyKtACEblbcubG7eq2wwMLCUtmG8r+Usa2NpadLnT3zJ9MtA t1wseGyYaDacfNDYGy1j4R3BtRfuM7ZdQeE1KAoIQlpTjvNy5u ZU346QiacHo71azRaKrhh2kqbAvjVCENOY0dErkW18pe8z2o8r +jUX4o3biFEtLbTa6Alb5ST544AwSl8vuxqIj467Vc0muEmlM/ sZzCoXDMKldl0GHv0iIETgW5XO+ZG4/EM1WN2GYo5tc/QoKCUO GYe1ZCg8eQEBw==
Cc: "pcp@ietf.org" <pcp@ietf.org>
Subject: Re: [pcp] Capability discovery
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, 05 Oct 2012 20:23:24 -0000

>>>> -----Original Message-----
>>>> From:pcp-bounces@ietf.org  [mailto:pcp-bounces@ietf.org] On Behalf Of
>>>> Yoshihiro Ohba
>>>> Sent: Thursday, October 04, 2012 8:04 PM To:pcp@ietf.org
>>>> Subject: [pcp] Capability discovery
>>>> 
>>>> There has been a question on what to do when PCP client supports PCP
>>>> authentication while PCP server does not, and vise versa.
>>> Yes, that problem needs to be solved.
>>> 
>>>> The same issue will exist for future PCP extensions.
>>> I disagree that problem exists for PCP extensions.  The client can
>>> simply try to use the extension, and will either get back an error
>>> (e.g., UNSUPP_OPCODE or UNSUPP_OPTION error), or the option will
>>> not be included in the response (for options outside the mandatory-
>>> to-process range).
>> 
>> In that case, the problem is specific to side-by-side PANA approach
>> which does not use PCP opcode/options.  Is this correct?
> 
> Yes, I believe that's correct.


Let's look at the whole space and see where the issue arises.

1. PANA tunneling
No problem. 

2. PANA port-sharing (side-by-side)

2.1. DHCP-based PCP server discovery
Not a problem, we can easily define auth_requirement as an attribute of the PCP server.

2.2. Implicit (non-DHCP-based) PCP server discovery (PCP server is the default gateway).

2.2.a. Client and server supports auth
No problem

2.2.b. Client does not support, server supports&requires auth
Not a problem. Server sends an error in response to unauthenticated request.

2.2.c. Client and server does not support auth
No problem

2.2.d. Client supports auth, server does not support auth.
Earlier example to cause an issue was when the client starts with auth, and the server does not understand what was going on (server would think the client is talking version PCP 128).

But, we can easily require "clients that do  not know the server's capability and policy" to start with "no auth" and see what happens.
Either the PCP goes thru, which is fine; or the client receives a PCP auth error in which case it learns to go back and try with auth.

So, overall, there does not seem to be an issue. Am I missing something?


Alper