Subject: Re: [pcp] Confirming consensus from WG meetings

From: <[email-masked]>
Date: Thu, 29 Mar 2012 11:13:05 +0200

+1

Gilles

-----Message d'origine-----
De : JACQUENET Christian OLNC/NAD/TIP
Envoyé : jeudi 29 mars 2012 10:29
À : BOUCADAIR Mohamed OLNC/NAD/TIP; Dave Thaler; [email-masked] Objet : RE: 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 : [email-masked] [mailto:[email-masked]] De la part de [email-masked] Envoyé : jeudi 29 mars 2012 10:15 À : Dave Thaler; [email-masked] 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 : [email-masked] [mailto:[email-masked]] De la part de 
>Dave Thaler Envoyé : jeudi 29 mars 2012 10:00 À : [email-masked] 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
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp
>
_______________________________________________
pcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

---

From: Olivier Vautrin <[email-masked]>
Date: Thu, 29 Mar 2012 06:57:10 -0700

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" <[email-masked]> 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'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.
>> 
>> 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 
>> 
>>> 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
>>>: