Re: [pcp] PCP security model

Francis Dupont <Francis.Dupont@fdupont.fr> Mon, 01 November 2010 15:22 UTC

Return-Path: <Francis.Dupont@fdupont.fr>
X-Original-To: pcp@core3.amsl.com
Delivered-To: pcp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C7323A69FA for <pcp@core3.amsl.com>; Mon, 1 Nov 2010 08:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoKIhSL0YhGO for <pcp@core3.amsl.com>; Mon, 1 Nov 2010 08:22:26 -0700 (PDT)
Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 628C83A69E8 for <pcp@ietf.org>; Mon, 1 Nov 2010 08:22:26 -0700 (PDT)
Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id oA1FMQxj066977; Mon, 1 Nov 2010 15:22:26 GMT (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201011011522.oA1FMQxj066977@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: Dan Wing <dwing@cisco.com>
In-reply-to: Your message of Fri, 29 Oct 2010 11:45:01 PDT. <13c001cb7799$64c3db50$2e4b91f0$@com>
Date: Mon, 01 Nov 2010 16:22:26 +0100
Sender: Francis.Dupont@fdupont.fr
Cc: pcp@ietf.org
Subject: Re: [pcp] PCP security model
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 01 Nov 2010 15:22:28 -0000

 In your previous mail you wrote:

   > between subscribers:
   >  - a subscribe is not authorized to steal another subscriber PFs.
   >   So the PCP server of a CGN is required to keep its state
   >   (PFs and subscriber identities) in stable storage.
   
   The actual requirement is to not give the mapping to another 
   subscriber until the lifetime expires.

=> in fact it is lifetime + hold down but this doesn't change
the problem (i.e., it is an implementation detail).

   That can be implemented by using stable storage, true.

=> I am afraid stable storage is required for other reasons
(legal constraints for instance) so I don't worry too much
about this. And we can put a MUST for the reason and a SHOULD
for the solution: this will make everybody happy.

   Two *examples* of ways to implement
   that requirement, without stable storage of PCP-mappings:
   
     * algorithmically assigning certain ports to certain 
       subscribers -- like A+P (port range routing) does for 
       its dynamic connections.
     * using a completely different pool of IPv4 addresses upon 
       NAT server restart, as explained for dynamic connections
       with cold standby in Section 6 of 
       draft-xu-behave-stateful-nat-standby.
   
=> interesting (BTW these solves the deep issue, i.e., they work
for the legal stuff too).

   >  - if the subscriber identity is the HG address on the infrastructure,
   >   some measures must be taken to ensure a subscriber can't use
   >   the address of another subscriber, i.e., access control on the
   >   infrastructure including ingress filtering.
   >   (with other words the identification should be able to provide
   >    authentication)
   
   That's needed anyway, without PCP -- to prevent subscribers from 
   clobbering each others sessions.
   
=> yes and IMHO it is a good thing PCP doesn't add new constraints.

   >  - the support of subscriber renumbering requires a subscriber
   >   authentication which is not based on addresses (proposal in PPS).
   
   I don't care about maintaining PCP mappings during a subscriber 
   renumbering event.

=> I agree it is a minor goal but if we can get it for free there
is no reason to not provide it. And I believe we agree it must
not be provided in a not-secure way.

Thanks

Francis.Dupont@fdupont.fr

PS: can you provide a better wording for the stable storage for CGN
requirement?