Re: [pcp] [ Side-by-side or nested protocols

Margaret Wasserman <margaretw42@gmail.com> Tue, 18 September 2012 10:29 UTC

Return-Path: <margaretw42@gmail.com>
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 30F8821E8064 for <pcp@ietfa.amsl.com>; Tue, 18 Sep 2012 03:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 bg5rrI3osimx for <pcp@ietfa.amsl.com>; Tue, 18 Sep 2012 03:29:51 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 916F021F8717 for <pcp@ietf.org>; Tue, 18 Sep 2012 03:29:51 -0700 (PDT)
Received: by qafi29 with SMTP id i29so2395818qaf.10 for <pcp@ietf.org>; Tue, 18 Sep 2012 03:29:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Oq5u/HXLIo+jghczuevpO+RyZr86VstgEHYzsseIHvE=; b=xS+upDikWKE9lyP5DH2PgJpEaM0FgFHCRWMC1fYrjHWecKYIx2xnQu9lv6lkoWf1rX 8jV2gGSTdGHl5lxge30Dkbrx8D0B/KtpyoefxviDfp+AfHBL2JSeOWX/ncbcinqLnMpY KDKJTHoaF8cl0nM63PjfwCU9xj2FdfosORZX8/vr6CAn0ktcPKhcjSZV3SkckU3UD1YW +mDwAnvLo/x30T7K9h2DJ2mKeCkh7v45E0jX3XcEn0+XYFEjaqNR+amQRxW0IeXU8rzM 0u7SvUFlKJpxWqYrXv2rlKCCkoRYx/zOzMb2OqqMIwR8l0sTFbotnWoYZhTtXPxrpqby LAPw==
Received: by 10.224.209.8 with SMTP id ge8mr637988qab.0.1347964190856; Tue, 18 Sep 2012 03:29:50 -0700 (PDT)
Received: from lilac-too.home (pool-71-184-79-25.bstnma.fios.verizon.net. [71.184.79.25]) by mx.google.com with ESMTPS id o10sm18992116qaj.4.2012.09.18.03.29.45 (version=SSLv3 cipher=OTHER); Tue, 18 Sep 2012 03:29:47 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Margaret Wasserman <margaretw42@gmail.com>
In-Reply-To: <E91C9554-FBCF-4324-A1BF-5C4D75F5264A@yegin.org>
Date: Tue, 18 Sep 2012 06:29:44 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C7BB117C-F794-4BE0-8AC9-2D4852F1CA3F@lilacglade.org>
References: <14C7F4F06DB5814AB0DE29716C4F6D6702E12ABC28@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <CB96F2AF-7545-457D-96EB-F78B7666C00C@yegin.org> <tsl1ui0wvmo.fsf_-_@mit.edu> <E91C9554-FBCF-4324-A1BF-5C4D75F5264A@yegin.org>
To: Alper Yegin <alper.yegin@yegin.org>
X-Mailer: Apple Mail (2.1084)
Cc: "'pcp@ietf.org'" <pcp@ietf.org>
Subject: Re: [pcp] [ Side-by-side or nested protocols
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, 18 Sep 2012 10:29:52 -0000

Hi Alper,

On Sep 18, 2012, at 2:58 AM, Alper Yegin wrote:
> Again, I'm confused. With PANA, you get re-use of spec, implementation, security analysis. 
> Which one of these do you get with yet-to-be specified EAP-over-PCP?

Just to clarify -- you only get "implementation re-use" if you are able to use an existing PANA implementation on your platform.  That would require that the existing implementations:

- exist
- integrate well with your PCP implementation
- support the features that you require

People should read the long message that Sam Hartman sent to the list about existing PANA implementations, and make their own determination about whether one of the existing PANA implementations would work for them.  Two issues that are important here, IMO, are: 

- whether PANA brings in more complexity than is needed in the PCP case, because it is designed for the (more complex) network access case.
- whether the limitations of the existing PANA implementations (i.e. limited EAP methods support) are acceptable for PCP

If you won't be able to reuse an existing PANA implementation, then the "implementation re-use" benefit doesn't exist.

I don't understand how we can re-use the security analysis, since the PCP case is very different from a network access case.  In fact, the security requirements for PCP are very unusual, and quite specific to PCP.

Code reuse is also very desirable.  In any of our proposed cases, we could get code-reuse for the EAP portion on systems that use 802.11 security mechanisms or use EAP for other reasons. It is potentially possible that you could get additional code-reuse in the PANA case, if systems end up using PANA for more than one purpose.  Right now, though, there isn't much overlap between the types of systems that use PANA and the types of systems that are likely to use PCP.

None of this reuse is valuable at all, though (again, IMO), if it presents the user with an unintegrated experience and/or results in a hard-to-support or hard-to-maintain product.  Running two different protocols side-by-side and trying to present them as a single function to end-users and administrators presents various system design challenges that need to be weighed against the complexity of performing in-band PCP key management.

Margaret