Subject: [pcp] Confirming consensus from WG meetings

From: Dave Thaler <[email-masked]>
Date: Thu, 29 Mar 2012 08:00:27 +0000

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

---

From: <[email-masked]>
Date: Thu, 29 Mar 2012 10:15:00 +0200

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
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp
>

---

From: <[email-masked]>
Date: Thu, 29 Mar 2012 10:29:19 +0200

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,

Cheers,
Med 

>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.
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 29 Mar 2012 10:30:46 +0200

+1

Cheers,
Wim
_________________
sent from blackberry

----- Original Message -----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 29, 2012 10:29 AM
To: BOUCADAIR Mohamed OLNC/NAD/TIP <[email-masked]>; Dave Thaler <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [pcp] Confirming consensus from WG meetings

Dave, all,

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,

Cheers,
Med

---

From: Tina TSOU <[email-masked]>
Date: Thu, 29 Mar 2012 08:41:52 +0000

+1

Sent from my iPad

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 29 Mar 2012 10:54:29 +0200

Hi Christian,

> 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 provider…

I think you are missing a key point of information here which is that Stephen Farrell, one of the security ADs, currently has a blocking "DISCUSS" (an IESG issue) outstanding against our document that requires that we provide a stronger security solution that must be implemented when the THIRD_PARTY option is implemented.

Also, to be clear, the proposed change is not to eliminate THIRD_PARTY from PCP.  The proposal is to move THIRD_PARTY (which is already optional in the Base Spec) into a separate document, so that we can address the blocking issues raised by Stephen Farrell, WITHOUT HOLDING UP THE BASE SPEC.  We don't have the alternative of leaving the base spec as-is and getting it published now.  Realistically, we only have two choices:

1) Keep THIRD_PARTY in the Base Spec, state that security is mandatory to implement in PCP clients and servers that implement the optional THIRD_PARTY option, and add a normative reference to a security mechanism in the Base Spec.  This option  will DELAY RFC PUBLICATION OF THE BASE SPEC until the security mechanism is also approved for publication as an RFC.

OR

2) Move "THIRD_PARTY" to a new document and deal with the security issues there by normatively referencing a security mechanism and stating that it is mandatory to implement (but not mandatory to deploy) whenever the THIRD_PARTY option is implemented.  This option will allow us to PUBLISH THE BASE SPEC AS AN RFC ASAP, and will not delay the THIRD_PARTY option any longer than it will be delayed, anyway.

Given those two choices, which one do you prefer?

> 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 drive…

Everything about how to use PCP in DS-Lite is _also_ being moved to a separate document.  That document will include any special information about deploying PCP in the DS-Lite scenario and could (if we have WG consensus) say that it is safe to implement THIRD_PARTY without a security mechanism in DS-Lite equipment (B4s and AFTRs).  

Also, I think it is a bit limited to think of PCP as something that only serves the DS-Lite use case.  NAT-PMP and UPNP-IGD are in widespread use today in non-DS-Lite situations, and we expect that PCP will be widely deployed and used in those use cases, as well.  I believe that this is why THIRD_PARTY is optional instead of mandatory in the Base Spec.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 29 Mar 2012 10:58:08 +0200

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

---

From: Simon Perreault <[email-masked]>
Date: Thu, 29 Mar 2012 10:58:28 +0200

On 03/29/12 10:54, Margaret Wasserman wrote:
> 2) Move "THIRD_PARTY" to a new document and deal with the security
> issues there by normatively referencing a security mechanism and
> stating that it is mandatory to implement (but not mandatory to
> deploy) whenever the THIRD_PARTY option is implemented.  This option
> will allow us to PUBLISH THE BASE SPEC AS AN RFC ASAP, and will not
> delay the THIRD_PARTY option any longer than it will be delayed,
> anyway.

If your only use for THIRD_PARTY is in a DS-Lite setting, you don't need 
an additional security mechanism. You can just enforce a simple ACL 
ensuring that the address is a DS-Lite address. IMHO this use case is 
important enough to make this option unworkable.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 29 Mar 2012 11:02:31 +0200

Hi Tina,

As I indicated to Wim, you are agreeing to a choice that is not available to us.  We _can not_ publish the current PCP Base Spec as is.  We need to make changes to address Stephen Farrell's discuss.  So, just publish the Base Spec as-is is not a choice we can make.

Given that fact, which of the options in my previous message would you like to see us pursue:  (1) Delay the Base Spec while we wait for a security mechanism to be approved, or (2) break out THIRD_PARTY so that the rest of the PCP Base Spec can be published now?  

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 29 Mar 2012 11:04:25 +0200

Hi Simon,

On Mar 29, 2012, at 10:58 AM, Simon Perreault wrote:
> If your only use for THIRD_PARTY is in a DS-Lite setting, you don't need an additional security mechanism. You can just enforce a simple ACL ensuring that the address is a DS-Lite address. IMHO this use case is important enough to make this option unworkable.

Everything about DS-Lite deployment that was in the Base Spec is being moved to a separate document.  That document could state that it is okay to use THIRD_PARTY in the DS-Lite case, as long as support for an ACL is provided on the PCP Server/AFTR.

Margaret

---

From: Qiong <[email-masked]>
Date: Thu, 29 Mar 2012 17:05:03 +0800

+1 support.

We need to move forward asap.

Best wishes
Qiong

On Thu, Mar 29, 2012 at 4:29 PM, <[email-masked]> wrote:

> 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.
>
> [email-masked]
> 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
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> Thank you.
>

---

From: Alper Yegin <[email-masked]>
Date: Thu, 29 Mar 2012 12:05:46 +0300

Dave,

> 3) Without having resolved the question of inline vs PANA first, adopt

Please note that, the primary issue is "inline vs. separate KMP (key management protocol) for PCP"

I use PANA as a way to illustrate separate KMP. 
There are certainly other ways of performing separate KMP as well.

Does it make sense to define a PCP-based (i.e., inline) KMP for PCP?
This is the question we need to answer. 

> 	be agnostic on that question.

If so, the WG draft shall not have any details about the use of EAP (e.g., section 5.4, 5.5., 5.7, etc.).
That's the way to separate KMP from the I-D, and just leave PCP integrity protection in.
And if this is done, I do support such an I-D as well.

Let's be very clear on these details, otherwise it's ambiguous what the decision and actions are.

Thanks.

Alper

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 29 Mar 2012 11:09:19 +0200

One further technical question on this...

> If your only use for THIRD_PARTY is in a DS-Lite setting, you don't need an additional security mechanism. You can just enforce a simple ACL ensuring that the address is a DS-Lite address. IMHO thi…

Given that the B4 and the AFTR will not necessarily be located in a single administrative domain (the B4 can be customer-owned equipment, or even a host), why do you assume it is safe to use the THIRD-PARTY option without security in the DS-Lite case?  In other words, what would stop an injection attack where an attacker takes over my printer and sends messages from that printer that spoof THIRD_PARTY messages from the IPV6 address of the B4 running on another host in my house, to open incoming holes to additional nodes in my network that may be entirely unaware of DS-Lite?

Margaret

---

From: Simon Perreault <[email-masked]>
Date: Thu, 29 Mar 2012 11:09:22 +0200

On 03/29/12 11:02, Margaret Wasserman wrote:
> As I indicated to Wim, you are agreeing to a choice that is not
> available to us.  We _can not_ publish the current PCP Base Spec as
> is.  We need to make changes to address Stephen Farrell's discuss.

"Discuss" means "discuss", not "kill THIRD_PARTY". There's a wide range 
of options available. It's not binary. We can tweak things a bit, try to 
convince the AD with new arguments, etc.

Simon

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 29 Mar 2012 11:11:02 +0200

On Mar 29, 2012, at 11:05 AM, Alper Yegin wrote:
> , the WG draft shall not have any details about the use of EAP (e.g., section 5.4, 5.5., 5.7, etc.).

My understanding is that the draft would indicate that we have not decided between the two proposals that have presented to the WG:  use of PCP over EAP (as described in our original non-WG document) or use of EAP over PANA (as described in your e-mail).

Margaret

---

From: Simon Perreault <[email-masked]>
Date: Thu, 29 Mar 2012 11:12:21 +0200

On 03/29/12 11:04, Margaret Wasserman wrote:
>> If your only use for THIRD_PARTY is in a DS-Lite setting, you don't
>> need an additional security mechanism. You can just enforce a
>> simple ACL ensuring that the address is a DS-Lite address. IMHO
>> this use case is important enough to make this option unworkable.
>
> Everything about DS-Lite deployment that was in the Base Spec is
> being moved to a separate document.  That document could state that
> it is okay to use THIRD_PARTY in the DS-Lite case, as long as support
> for an ACL is provided on the PCP Server/AFTR.

Ok so "ACL" would be an acceptable "security mechanism". I thought it 
was implied that the PANA stuff needed to be implemented if you wanted 
to use THIRD_PARTY.

Simon

---

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

Re-,

As I already said, THIRD_PARTY is NOT only for DS-lite: it is also for hosts belonging to the same subscriber but which do not support PCP (eg., webcam, server).

Cheers,
Med 

>part de Margaret Wasserman
>Envoyé : jeudi 29 mars 2012 11:04
>À : Simon Perreault
>Cc : [email-masked]
>> If your only use for THIRD_PARTY is in a DS-Lite setting, 
>you don't need an additional security mechanism. You can just 
>enforce a simple ACL ensuring that the address is a DS-Lite 
>address. IMHO this use case is important enough to make this 
>option unworkable.
>
>
>Everything about DS-Lite deployment that was in the Base Spec 
>is being moved to a separate document.  That document could 
>state that it is okay to use THIRD_PARTY in the DS-Lite case, 
>as long as support for an ACL is provided on the PCP Server/AFTR.
>
>Margaret
>
>
>

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 29 Mar 2012 11:14:09 +0200

Hi Simon,

On Mar 29, 2012, at 11:09 AM, Simon Perreault wrote:

> "Discuss" means "discuss", not "kill THIRD_PARTY". There's a wide range of options available. It's not binary. We can tweak things a bit, try to convince the AD with new arguments, etc.

There have been several off-line discussions with Stephen Farrell, attempting to understand what we need to do to resolve this issue, and this is the best plan that we were able to come up with...

If you have a better alternative that you think Stephen will be willing to accept, please propose it!  

Saying "publish the document as-is", though, doesn't make any sense.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 29 Mar 2012 11:26:21 +0200

On Mar 29, 2012, at 11:12 AM, Simon Perreault wrote:
> Ok so "ACL" would be an acceptable "security mechanism". I thought it was implied that the PANA stuff needed to be implemented if you wanted to use THIRD_PARTY.

ACL might be an acceptable security mechanism, if we can constrain the environment so that an ACL _is_ sufficiently secure.  I do, personally, think that an ACL is sufficient for DS-Lite deployments where the B4 and AFTR are running in a single administrative domain (i.e. they are both in the ISPs network).

I expect that the security considerations in the DS-Lite document will be similar to what we tried to say in the Base Spec with the simple and advanced security models:  

If you know that your PCP client implementation will only be used in situations that have certain constraints (i.e. your B4 implementation is running on ISP equipment), it is okay not to implement any crypto security.  However, we will probably want to mandate implementation of an ACL in this case, so that one B4 can't make THIRD_PARTY requests that affect another...  This is just common sense, and I think we all assumed the PCP Server on the AFTR would check the address range in THIRD_PARTY requests, we just didn't say so in the document, perhaps because we thought it was obvious.

However if your PCP client implementation may run in other environments (i.e. on a desktop PC), it is mandatory to implement (but not mandatory to use) a cryptographic security mechanism.  I think this would include cases where a B4 runs in a separate administrative domain from its AFTER, such as hosts that serve as their own B4s.

It also follows that if a PCP Server wants to serve PCP Clients that run in separate administrative domains, it will need to implement a cryptographic security mechanism that can be used to authenticate those B4s.  An ACL would probably be fine for a typical AFTR, though, one that only talks to B4s in the same ISP domain.

Does that make sense?

Margaret

---

From: Xiaohong Deng <[email-masked]>
Date: Thu, 29 Mar 2012 17:28:55 +0800

+1 for keep THIRD PARTY. Since both voice of keeping it and killing it
existent and hear the majority of keeping ，don't see a justice of killing
it.
 在 2012-3-29 上午10:09，"Simon Perreault" <[email-masked]>写道：

> "Discuss" means "discuss", not "kill THIRD_PARTY". There's a wide range of
> options available. It's not binary. We can tweak things a bit, try to
> DTN made easy, lean, and smart --> http://postellation.viagenie.**ca<http://postellation.viagenie.ca>
> ______________________________**_________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/pcp<https://www.ietf.org/mailman/listinfo/pcp>
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 29 Mar 2012 18:29:10 +0900

> My understanding is that the draft would indicate that we have not decided between the two proposals that have presented to the WG:  use of PCP over EAP (as described in our original non-WG documen…

I agree that such statement is required indeed.

*In addition*, any details on inband scheme that is the main part of
conflict should not be included in a WG draft.

Yoshihiro Ohba

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 29 Mar 2012 11:30:59 +0200

Hi Qiong,

> We need to move forward asap.

These two lines are mutually incompatible.

The proposal to move THIRD_PARTY out of the Base Spec is a proposed way forward to get the Base Spec published ASAP.

Mohammed's proposal will involve _delaying_ the Base Spec until we can resolve the blocking issues raised by Stephen Farrell.  This would probably involve blocking publication of the Base Spec until we have a cryptographic security mechanism that is ready for RFC publication.

Could you read my mail on this thread, and let us know which of the available paths you would actually prefer?

Thanks,
Margaret

---

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

On Mar 29, 2012, at 11:28 AM, Xiaohong Deng wrote:
> +1 for keep THIRD PARTY. Since both voice of keeping it and killing it existent and hear the majority of keeping ，don't see a justice of killing it.
> 
> 
There is no proposal on the table to kill THIRD_PARTY.

Margaret

---

From: Alper Yegin <[email-masked]>
Date: Thu, 29 Mar 2012 12:32:43 +0300

> My understanding is that the draft would indicate that we have not decided between the two proposals that have presented to the WG:  use of PCP over EAP (as described in our original non-WG documen…

There's no agreement on whether KMP shall be bundled up with PCP integrity protection. There's no value in having discussions and multiple solutions in the WG I-D.
Let's split draft-wassermann-pcp-auth into two:

1. PCP integrity protection.
2. EAP-over-PCP based KMP for PCP

It makes sense to make the 1st one a WG I-D.

We can keep discussing 2 along with other alternatives.

Regards,

Alper

---

From: Dave Thaler <[email-masked]>
Date: Thu, 29 Mar 2012 09:45:14 +0000

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, March 29, 2012 10:15 AM
> To: Dave Thaler; [email-masked]
> Subject: RE: Confirming consensus from WG meetings
> 
> Dear Dave, all,
> 
> 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!
> 

Thanks, though as you note this is not a new objection since you were at the meeting.

That said, I'll remind folks that THIRD_PARTY is already optional, not mandatory
 to implement, and hence in the consensus being confirmed, there will NOT be a
normative ref to draft-wasserman.  (If there were, it would hold up publication
which would defeat the purpose of moving it to a separate document.)

-Dave

---

From: <[email-masked]>
Date: Thu, 29 Mar 2012 12:00:38 +0200

Hello Margaret,

Thanks for your feedback - please see inline. 

[snip]

CJ: I'm perfectly aware of that DISCUSS.

Also, to be clear, the proposed change is not to eliminate THIRD_PARTY from PCP.

CJ: I also fully understand that.  

The proposal is to move THIRD_PARTY (which is already optional in the Base Spec) into a separate document, so that we can address the blocking issues raised by Stephen Farrell, WITHOUT HOLDING UP THE BASE SPEC.  We don't have the alternative of leaving the base spec as-is and getting it published now.

CJ: I'm not convinced this situation is that black and white. In the meantime, the clock's ticking and removing the THIRD PARTY from the base spec, jeopardizes the progress of several deployments this year because the reference to the THIRD_PARTY standard (if any) will be missing.  

Realistically, we only have two choices:

OR

CJ: there is a high risk that the second option is a showstopper to short-term deployments as far as vendors are concerned. The base spec was initially due for May 2011. We're one year later, with several service providers who not only need the base spec but also the THIRD_Party option as currently documented in the -24 to ignite operational deployments. And I really think that the IETF (let alone the AD who originated the DISCUSS) should take into account such operational concerns.

CJ: see above.

CJ: fine, but that's not what I'm worried about.  

Also, I think it is a bit limited to think of PCP as something that only serves the DS-Lite use case.

CJ: let me assure you that I don't see myself as a limited mind.  

NAT-PMP and UPNP-IGD are in widespread use today in non-DS-Lite situations, and we expect that PCP will be widely deployed and used in those use cases, as well.

CJ: agreed and fair enough.  

I believe that this is why THIRD_PARTY is optional instead of mandatory in the Base Spec.

CJ: right. And again, I don't think I demanded that the THIRD_PARTY should become a mandatory feature.

Christian.

---

From: Dave Thaler <[email-masked]>
Date: Thu, 29 Mar 2012 10:28:27 +0000

Thanks Margaret.

All these +1's are not useful, since they are +1'ing an option we don't have
(publish immediately as is).   The options are:

(1) Delay the Base Spec while we wait for security text that we have consensus
on and that Stephen Farrell will be happy with, and that does not reference
DS-lite.   (This could take a very long time, as certainly this is not a topic that 
is easy to get consensus on.)

Note subtle wording different from Margaret's wording... this does not
necessarily assume a security mechanism, but rather consensus on text
stating under what instances it is "safe", where those instances require 
no normative references to things not in the spec (for example, it must
require no normative references to use of PCP with DS-lite).   From discussions
with Stephen Farrell, this is not likely to be quick.

(2) break out THIRD_PARTY so that the rest of the PCP Base Spec can be 
published now?

So those who didn't already make their point at the meeting should
repeat their point in the context below.

If you believe we shouldn't take it out, then it's ok to respond saying you'd
support:
"Delay the Base Spec while we wait for new consensus on safe non-DSlite
cases"
for example, but it better start with "Delay the Base Spec ..."

-Dave

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Margaret Wasserman
> Sent: Thursday, March 29, 2012 11:03 AM
> To: Tina TSOU
> Cc: [email-masked]
> As I indicated to Wim, you are agreeing to a choice that is not available to us.
> We _can not_ publish the current PCP Base Spec as is.  We need to make
> changes to address Stephen Farrell's discuss.  So, just publish the Base Spec
> as-is is not a choice we can make.
> 
> Given that fact, which of the options in my previous message would you like
> to see us pursue:  (1) Delay the Base Spec while we wait for a security
> mechanism to be approved, or (2) break out THIRD_PARTY so that the rest of
> the PCP Base Spec can be published now?
> 
> Margaret
> 
>

---

From: Dave Thaler <[email-masked]>
Date: Thu, 29 Mar 2012 10:33:19 +0000

[email-masked] writes:
> I think you are missing a key point of information here which is that Stephen
> Farrell, one of the security ADs, currently has a blocking "DISCUSS" (an IESG
> issue) outstanding against our document that requires that we provide a
> stronger security solution that must be implemented when the THIRD_PARTY
> option is implemented.
> 
> The proposal is to move THIRD_PARTY (which is already optional in the Base
> Spec) into a separate document, so that we can address the blocking issues
> raised by Stephen Farrell, WITHOUT HOLDING UP THE BASE SPEC.  We don't
> have the alternative of leaving the base spec as-is and getting it published
> now.
> 
> CJ: I'm not convinced this situation is that black and white. In the meantime,
> the clock's ticking and removing the THIRD PARTY from the base spec,
> jeopardizes the progress of several deployments this year because the
> reference to the THIRD_PARTY standard (if any) will be missing.
>
> 1) Keep THIRD_PARTY in the Base Spec, state that security is mandatory to
> implement in PCP clients and servers that implement the optional
> THIRD_PARTY option, and add a normative reference to a security
> mechanism in the Base Spec.  This option  will DELAY RFC PUBLICATION OF
> THE BASE SPEC until the security mechanism is also approved for publication
> as an RFC.
> 
> OR
> 
> 2) Move "THIRD_PARTY" to a new document and deal with the security issues
> there by normatively referencing a security mechanism and stating that it is
> mandatory to implement (but not mandatory to deploy) whenever the
> THIRD_PARTY option is implemented.  This option will allow us to PUBLISH
> THE BASE SPEC AS AN RFC ASAP, and will not delay the THIRD_PARTY option
> any longer than it will be delayed, anyway.
> 
> CJ: there is a high risk that the second option is a showstopper to short-term
> deployments as far as vendors are concerned. The base spec was initially due
> for May 2011. We're one year later, with several service providers who not
> only need the base spec but also the THIRD_Party option as currently
> documented in the -24 to ignite operational deployments. And I really think
> that the IETF (let alone the AD who originated the DISCUSS) should take into
> account such operational concerns.

Can you elaborate on the scenario that requires THIRD_PARTY without
DS-lite?   (If DS-lite, you're blocked on the DS-lite spec anyway so that's
a non-issue here.)

And further on what you believe the security solution is in said deployments?

> Given those two choices, which one do you prefer?

I looked above and couldn't find a preference for one of the two, only
for an option that's not open to us.

It does sound like your primary goal is to get THIRD_PARTY published
asap, regardless of what document it's in.   I didn't hear you providing
reasons why it needs to be in the same spec, only a reason to not delay
that option.

Separating it out means the two can progress as soon as possible
independently without one blocked on the other.
 
> > 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.
> 
> Everything about how to use PCP in DS-Lite is _also_ being moved to a
> separate document.  That document will include any special information
> about deploying PCP in the DS-Lite scenario and could (if we have WG
> consensus) say that it is safe to implement THIRD_PARTY without a security
> mechanism in DS-Lite equipment (B4s and AFTRs).
> 
> NAT-PMP and UPNP-IGD are in widespread use today in non-DS-Lite
> situations, and we expect that PCP will be widely deployed and used in those
> use cases, as well.
> 

-Dave

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 29 Mar 2012 13:21:48 +0200

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:[email-masked]] 
Sent: donderdag 29 maart 2012 10:58
To: Henderickx, Wim (Wim)
Cc: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [pcp] Confirming consensus from WG meetings

Hi Wim,

Thanks,
Margaret

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 29 Mar 2012 04:31:40 -0700

The subscriber web portal case since CPEs and hosts will take quite some
time to be PCP ready.

Subscriber accesses an ISP provided  mapping/port forwarding portal. This
portal (in full control of ISP) talks PCP to CGN to install mappings. PCP
Client 9web portal) and CGN are within ISP's administrative domain. I
mentioned this case explicitly in the last IETF meeting and asked if
security was needed. WG (chair) answer at the time was no.

Thanks,

Reinaldo

---

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

>De : Dave Thaler [mailto:[email-masked]] 
>Envoyé : jeudi 29 mars 2012 12:33
>À : JACQUENET Christian OLNC/NAD/TIP; Margaret Wasserman
>Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
>Objet : RE: [pcp] Confirming consensus from WG meetings

>DS-lite?   (If DS-lite, you're blocked on the DS-lite spec 

Med: Please refer to: http://www.ietf.org/mail-archive/web/pcp/current/msg01981.html

---

From: Dave Thaler <[email-masked]>
Date: Thu, 29 Mar 2012 12:36:02 +0000

Thanks Reinaldo.

> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Thursday, March 29, 2012 1:32 PM
> To: Dave Thaler; [email-masked]; Margaret Wasserman
> Cc: [email-masked]
> The subscriber web portal case since CPEs and hosts will take quite some time
> to be PCP ready.
> 
> portal (in full control of ISP) talks PCP to CGN to install mappings. PCP Client
> 9web portal) and CGN are within ISP's administrative domain. I mentioned
> this case explicitly in the last IETF meeting and asked if security was needed.
> WG (chair) answer at the time was no.
> 
> Thanks,
> 
> Reinaldo
> 
>

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 29 Mar 2012 15:34:09 +0200

>> DS-lite?   (If DS-lite, you're blocked on the DS-lite spec 

My understanding is that 3rd party will be used for all sorts of proxies (UPNP-to-PCP proxies and PCP-to-PCP proxies), not just for the PCP proxies in an ISP-controlled B4 device.

Margaret