Re: [pcp] Confirming consensus from WG meetings

Olivier Vautrin <ovautrin@juniper.net> Thu, 29 March 2012 13:57 UTC

Return-Path: <ovautrin@juniper.net>
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 C8AD521F85FD for <pcp@ietfa.amsl.com>; Thu, 29 Mar 2012 06:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.779
X-Spam-Level:
X-Spam-Status: No, score=-5.779 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
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 SXI7TO17RubR for <pcp@ietfa.amsl.com>; Thu, 29 Mar 2012 06:57:23 -0700 (PDT)
Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7242D21F85CC for <pcp@ietf.org>; Thu, 29 Mar 2012 06:57:22 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT3RqQcRO1erJ09BhvDv26BXnR7UN7uB/@postini.com; Thu, 29 Mar 2012 06:57:22 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 29 Mar 2012 06:57:06 -0700
From: Olivier Vautrin <ovautrin@juniper.net>
To: "pcp@ietf.org" <pcp@ietf.org>
Date: Thu, 29 Mar 2012 06:57:10 -0700
Thread-Topic: [pcp] Confirming consensus from WG meetings
Thread-Index: Ac0Ns9OF/OpIYa1RQLO3SX4Zs8T5GA==
Message-ID: <CB9A3480.3999E%ovautrin@juniper.net>
In-Reply-To: <CB9A33FC.39998%ovautrin@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pcp] Confirming consensus from WG meetings
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, 29 Mar 2012 13:57:25 -0000

This would be my proposal as well. The THIRD_PARTY option will be in use
in all our first deployments of PCP, I don't see how we could have a
working solution today without it.

ACL/Filters should be a good enough protection.

/Olivier

On 3/29/12 3:45 PM, "Olivier Vautrin" <ovautrin@juniper.net> wrote:

>Margeret,
>
>My proposal is to keep THIRD PARTY in the base spec and mandate simple
>security using ACLs as a mandatory solution. The full security should come
>in another document.
>
>Wim
>
>-----Original Message-----
>From: Margaret Wasserman [mailto:mrw at lilacglade.org]
>Sent: donderdag 29 maart 2012 10:58
>To: Henderickx, Wim (Wim)
>Cc: 'christian.jacquenet at orange.com'; 'mohamed.boucadair at
>orange.com'; 'dthaler at microsoft.com'; 'pcp at ietf.org'
>Subject: Re: [pcp] Confirming consensus from WG meetings
>
>
>Hi Wim,
>
>As I said in my response to Christian, we do not have the option of
>publishing the Base Specification now with the THIRD_PARTY option in it
>and no mandatory-to-implement security mechanism.  We either need to add a
>normative reference to a security mechanism to the Base Spec (and wait for
>the security mechanism to be approved before we publish the Base Spec), or
>break the THIRD_PARTY option out in to a separate document (that will
>normatively reference a security mechanism), so that we can get the rest
>of the Base Spec published now.
>
>Could you please read my response to Christian (my previous message to
>PCP), and let me know which of the two choices listed in that message you
>would actually prefer?
>
>Thanks,
>Margaret
>
>
>On Mar 29, 2012, at 10:30 AM, Henderickx, Wim (Wim) wrote:
>
>> +1
>> 
>> Cheers,
>> Wim
>> _________________
>> sent from blackberry
>> 
>> ----- Original Message -----
>> From: christian.jacquenet at orange.com [mailto:christian.jacquenet at
>>orange.com]
>> Sent: Thursday, March 29, 2012 10:29 AM
>> To: BOUCADAIR Mohamed OLNC/NAD/TIP <mohamed.boucadair at orange.com>;
>>Dave Thaler <dthaler at microsoft.com>; pcp at ietf.org <pcp at ietf.org>
>> Subject: Re: [pcp] Confirming consensus from WG meetings
>> 
>> Dave, all,
>> 
>> I'd like to second Med's comment.
>> 
>> I'm too opposed to motion #1 below, especially in light of the need for
>>the THIRD_PARTY option for DS-Lite deployments that will start in a
>>couple of months from now as far as some service providers are concerned.
>>The security concerns that have been raised so far do not apply to
>>DS-Lite scenarios, as reminded by Med below.
>> 
>> I think the -24 is in a sufficiently good shape to be published as is,
>>whereas DS-Lite scenarios remain one of the most straightforward use
>>cases for PCP applicability, and was actually a key driver for the
>>initial base spec effort back in 2010.
>> 
>> Simply ignoring what becomes a fact in the very short term because of
>>security considerations that do not apply to such use case is not a good
>>enough reason for me to defer the standardization of the THIRD PARTY at
>>who-knows-when.
>> 
>> Cheers,
>> 
>> Christian.
>> 
>> -----Message d'origine-----
>> De : pcp-bounces at ietf.org [mailto:pcp-bounces at ietf.org] De la part
>>de mohamed.boucadair at orange.com
>> Envoyé : jeudi 29 mars 2012 10:15
>> À : Dave Thaler; pcp at ietf.org
>> Objet : Re: [pcp] Confirming consensus from WG meetings
>> 
>> Dear Dave, all,
>> 
>> I was one of the 2 who objected to remove the THIRD_PARTY Option from
>>the base spec. I maintain my objection because I see THIRD_PARTY as an
>>important feature: allow to instruct mappings for non pcp compliant
>>hosts/applications.
>> 
>> Adding a normative ref to draft-wasserman for the THIRD_PARTY is too
>>strong IMHO. The major scenarios which driven so far the development of
>>PCP do not require authenticated PCP communications: why doing this for
>>explicit mapping while this is not required for implicit mappings!
>> 
>> I do not want to slow down the progress of PCP base spec but cutting the
>>important features from the base spec won't help too.
>> 
>> Cheers,
>> Med 
>> 
>>> -----Message d'origine-----
>>> De : pcp-bounces at ietf.org [mailto:pcp-bounces at ietf.org] De la
>>>part de 
>>> Dave Thaler Envoyé : jeudi 29 mars 2012 10:00 À : pcp at ietf.org Objet
>>>: 
>>> [pcp] Confirming consensus from WG meetings
>>> 
>>> We got consensus among those at the meetings on the following, and want
>>> to confirm WG consensus on the list, in case there are new objections
>>> raised or folks who were not present in the room at the time.
>>> 
>>> 1) Move THIRD_PARTY out of pcp-base to a separate spec (12 in favor, 2
>>> against)
>>> 	This would resolve Stephen Farrell's discuss, allowing the base spec
>>> 	to be published quickly.   The alternative would likely
>>> take a lot more
>>> 	time to address, especially given that we already moved DS-lite
>>> 	discussion out of the base spec, and the DS-lite scenario was a key
>>> 	motivation for THIRD_PARTY.
>>> 
>>> 2) Add a client-specified per-mapping nonce (no strong objections)
>>> 	Belief is this is needed to resolve the transaction ID discuss's.
>>> 	WG will not add a transaction id, but will add a per-mapping
>>> 	nonce instead.
>>> 
>>> 3) Without having resolved the question of inline vs PANA first, adopt
>>> draft-wasserman-pcp-authentication as a working group document
>>> (12 in favor, 3 against)
>>> 	This would be the basis of the pcp security document.  Belief is
>>> 	that much of the current document is independent of the
>>> 	unresolved question on the table, and the WG draft should
>>> 	be agnostic on that question.
>>> 
>>> 4) Adopt draft-bpw-pcp-proxy as WG document (broad consensus
>>> 	among those who've read it)
>>> 
>>> Barring new objections that were not raised at the meeting, we plan to
>>> go forward with the above consensus items.
>>> 
>>> -Dave
>>>