IETF Logo Mail Archive

Re: [pcp] Comparison of PCP authentication

Margaret Wasserman <mrw@lilacglade.org> Tue, 07 August 2012 10:14 UTC

Return-Path: <mrw@lilacglade.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 04E7021F866E for <pcp@ietfa.amsl.com>; Tue, 7 Aug 2012 03:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.708
X-Spam-Level:
X-Spam-Status: No, score=-95.708 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n60f+YQLrhsE for <pcp@ietfa.amsl.com>; Tue, 7 Aug 2012 03:14:11 -0700 (PDT)
Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 65E4421F867A for <pcp@ietf.org>; Tue, 7 Aug 2012 03:14:11 -0700 (PDT)
Received: from lilac-too.home (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id B9348200E1; Tue, 7 Aug 2012 06:14:10 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Margaret Wasserman <mrw@lilacglade.org>
In-Reply-To: <955DC538-A1D9-4B19-B1A5-A7741EA7FB35@yegin.org>
Date: Tue, 07 Aug 2012 06:14:10 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <28610FE5-6528-4AF1-B081-6B21AB4F0010@lilacglade.org>
References: <9B57C850BB53634CACEC56EF4853FF653B6EC381@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <7FE144CF-00E3-4451-8CBE-A6A684DB7CC4@yegin.org> <067d01cd73fd$765a6c50$630f44f0$@com> <D6D2DEED-C35A-45AB-8B72-96195C308DB9@yegin.org> <57FF0F8E-1B86-410F-8B6B-C4893A28222F@lilacglade.org> <075301cd7419$19557dd0$4c007970$@com> <5020688F.4060004@toshiba.co.jp> <955DC538-A1D9-4B19-B1A5-A7741EA7FB35@yegin.org>
To: Alper Yegin <alper.yegin@yegin.org>
X-Mailer: Apple Mail (2.1084)
Cc: pcp@ietf.org
Subject: Re: [pcp] Comparison of PCP authentication
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: Tue, 07 Aug 2012 10:14:12 -0000

On Aug 7, 2012, at 4:10 AM, Alper Yegin wrote:
> Those bits are reserved for "future." 
> And because of this demux design, "now" we want to make sure no one will ever set bit#7.
> What we need is to allocate that bit and state it's always set to 0. I don't think we need a separate RFC for this, this'd be the RFC that defines how PANA and PCP are used together.

Right.  If we choose the demultiplexing option, the RFC that defines how to run PANA and PCP together will Update the PANA RFC to allocate certain bits in the first octet.  We might or might not choose to update PANA in other ways, depending on whether we decide to include a TLV indicating that the request is for PCP authentication vs. network access authentication.

Margaret

v2.23.0 | Report a Bug | By Email