Re: [pcp] Implementation Analysis: strong preference for PCP-specific approach

Alper Yegin <alper.yegin@yegin.org> Thu, 20 September 2012 08:45 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 97CC921F86FD for <pcp@ietfa.amsl.com>; Thu, 20 Sep 2012 01:45:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.466
X-Spam-Level:
X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 OXrey7RNZeUY for <pcp@ietfa.amsl.com>; Thu, 20 Sep 2012 01:45:32 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1F321F847D for <pcp@ietf.org>; Thu, 20 Sep 2012 01:45:32 -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=mrus0) with ESMTP (Nemesis) id 0MHItv-1TIkys1xUB-00Du6r; Thu, 20 Sep 2012 04:45:30 -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: <70154AB6-F7B5-47B0-B721-811EA5DF9926@lilacglade.org>
Date: Thu, 20 Sep 2012 11:45:11 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <97AF094F-ABD8-4B50-80B7-30D8E2F34567@yegin.org>
References: <tslipbdzzwy.fsf@mit.edu> <74FC8E41-02D8-4BFC-A15F-035FA328DDC1@yegin.org> <70154AB6-F7B5-47B0-B721-811EA5DF9926@lilacglade.org>
To: Margaret Wasserman <margaretw42@gmail.com>
X-Mailer: Apple Mail (2.1278)
X-Provags-ID: V02:K0:VQcijeVsWmWsMPF7dCisVezDtqydB+CC1gh1yQg+U0F enBEVJHtPFa+dYEpvuZO4HVj/7RWXbHDr/v17+aLascvGCOXu+ UaIfQN/5jUSIVIDLZEr9Y1uuUpqGmiuzfZL1/XLDxnJBOUmOeB qq4ohseFQcEcYKDhhplGQvCtrg/k8Yg9vXlps+k8w7Bp+xM7lU Nk5KHZr7+w3WtqK1YmY9Tih5/bDy+f82tW5kKsKADvplqxGR2b ZEehT9pM5opJ5drwl5VfRPvglK42W2V1Cf2+zNdcMmw1G140gG LhCmr1EkadqUjq6dDaitxewaMZUkVq1D0izmnoiNcjvfduzx0H 0R8KuvJHqCqVePIMoqPUA+fdkbArNqMuj8W94uAKogskkxA4VA VeKsesRCDdhAA==
Cc: pcp@ietf.org
Subject: Re: [pcp] Implementation Analysis: strong preference for PCP-specific approach
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: Thu, 20 Sep 2012 08:45:33 -0000

Hi Margaret,

On Sep 19, 2012, at 1:11 PM, Margaret Wasserman wrote:

> 
> Hi Alper,
> 
> On Sep 17, 2012, at 5:24 AM, Alper Yegin wrote:
>> Yep, they are implementing "EAP lower layers". "EAP-over-UDP/PCP" is an EAP lower-layer and it'll have the same thing (once people realize it's more than defining a EAP container to qualify as a "working" and "compliant" EAP lower layer).
> 
> You have mentioned this several times, but you haven't provided any specifics.  What do you think is missing from the PCP-specific approach, as document, that would need to be added to make it a "working" and "compliant" EAP lower layer?  Is there an RFC that specifies the requirements that the PCP-Specific approach is failing to meet? 

The major missing piece is the support for EAP re-authentication. It's totally omitted.

Security considerations section is too light on content. Please see PANA's. We need to see a thorough analysis to conclude that the design is complete. For example, there's a mention of DoS resilience, but it's not sufficient. Please refer back to PANA to see how DoS resilience is achieved with EAP lower-layer.

Also, I don't see the message validity checks (again, see PANA). It's not possible to get a standard state machine w/o that (either in a dedicated section like in RFC 5191, or captured in a distributed way in the document).

Alper