[pcp] Server's auth policy discovery

Alper Yegin <alper.yegin@yegin.org> Fri, 12 October 2012 08:30 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 65B8221F8540 for <pcp@ietfa.amsl.com>; Fri, 12 Oct 2012 01:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level:
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 YsiWjwc9W-EO for <pcp@ietfa.amsl.com>; Fri, 12 Oct 2012 01:30:04 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id BFCE421F8545 for <pcp@ietf.org>; Fri, 12 Oct 2012 01:30:04 -0700 (PDT)
Received: from [192.168.2.7] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lpu1v-1TpJ0w1nr5-00fgyG; Fri, 12 Oct 2012 04:30:03 -0400
From: Alper Yegin <alper.yegin@yegin.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Oct 2012 11:29:46 +0300
Message-Id: <0BC19EAB-01F2-4AB9-B706-FD7C98FFAE86@yegin.org>
To: pcp@ietf.org
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
X-Provags-ID: V02:K0:YXKLCH8E8E5r1s5ReWtLYDp9vkd7JYRcHPibgF1bkZ/ flh9VGgOB8SLASN42INLwwM650ojYQFDuJNy2993rDLbBAwbDt o5XlvOIN2jAb8rN+uORoeiUoSRsH2Y/KlxJjVBOidkaJdLsXIE coRx6v0uXoLPTbPH3xsHyvvyhrb9p1b0ZfbhLvZ0NY89VMqsMZ Kr+sisV0yY45otq3XlgWKGUAdZ3YwNww4kAIfSnR8eobARF3p9 XPg5SjbElv5AkTEclai17awEK24qFKtcKG+UXWIcyVx4SKST4H /23SCekLdF+Fd6RgR7Jh1lviJAIzulM4/GNrG16jM6Ys0Y5Nol 8L2lPjdzki97UMyN7eSoYTgwNcNENvjPGMs0KkxgHnNbcP5o+5 VWTtua7Fw15Qw==
Subject: [pcp] Server's auth policy 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, 12 Oct 2012 08:30:05 -0000

Hello,

Let me compile the auth policy discovery solutions that were discussed on the ML so far.


There are 3 possible auth policies on a PCP server
1. auth not used (not supported, or disabled)
2. use of auth is optional (i.e., PCP Client's decision)
3. auth is mandatory to use

The question is, how does the PCP client know the server's policy.


With the tunneled PANA approach:

The client starts with either unauthenticated PCP or PANA-over-PCP, then observes what it gets back from the server. Either an error, or progress of what it started.

With the port-sharing PANA approach:


PCP client starts without using auth, and observes what happens.
If the server policy is 1 or 2, then PCP works without a problem.
If the server policy is 3, then the PCP server returns an appropriate error message.


Now, coming to Sam's scenario where it is not acceptable for some PCP clients to operate in unauthenticated mode.
He said this is needed for the firewall case.

In that case, DHCP-based discovery needs to be used (irrespective of the auth scenario), as the firewall is not necessarily the first-hop router from PCP Client's perspective.
We can update the DHCP-based discovery solution to deliver "auth policy" of the PCP server along with the "IP address of the server".

In addition to DHCP-based solution, or alternatively, we can define an ANNOUNCE-based single round-trip between the PCP client and PCP server for the client to discover the server's auth policy before proceeding. 


Alper