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?
- [pcp] PCP security model Francis Dupont
- Re: [pcp] PCP security model Dan Wing
- Re: [pcp] PCP security model Francis Dupont
- Re: [pcp] PCP security model Paul Selkirk
- Re: [pcp] PCP security model Dan Wing