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

From: Margaret Wasserman <[email-masked]>
Date: Sun, 1 Apr 2012 07:57:15 -0400

Personally, I don't see the value in splitting THIRD_PARTY into two separate option codes that do exactly the same thing.  What is the difference between having two different option codes, and having one option code that is restricted to be used either in safe situations OR with cryptographic security?

How can a PCP Server know when it is running in a trusted environment, anyway?  I realize that this is mean to be some shorthand for the DS-Lite case, but it is simply not the case that all DS-Lite deployments will meet these criteria, since I've heard discussion of a B4 running on customer-owned equipment and/or hosts.  How can a PCP Server, even if it is running on a DS-Lite AFTR _know_ that every B4 that tries to send a THIRD_PARTY option to the server is owned by the same entity as the PCP Server?

I'd rather see us go with a solution like this:

- Keep one THIRD_PARTY option, and don't write a separate THIRD_PARTY document.

- Add text to the place in the PCP spec where THIRD_PARTY is defined to state that it MUST be disabled by default in PCP Servers, and that it SHOULD NOT be enabled unless an access control list (ACL) has been configured.  The ACL SHOULD contain a list of PCP Clients (by internal IP Address) that are allowed to send the THIRD_PARTY option, and a list of addresses or address ranges for which each authorized PCP Client can issue THIRD_PARTY requests.

- Add text to the Security Considerations section that the use of THIRD_PARTY without a cryptographic security mechanism opens various attack vectors, and that THIRD_PARTY should only be enabled without cryptographic security in environments where the authorized PCP Client(s) and the PCP Server are under the same administrative control AND where there is some form of protection against address spoofing, such as layer 2 security or another type of restricted network access.

Stephen would that work for you?

Margaret

On Mar 30, 2012, at 10:43 AM, Dave Thaler wrote:

> Based on the feedback received during the meeting and on this thread
> from various people reporting they were blocked on THIRD_PARTY for
> deploying PCP for the web portal case, I met with Stephen Farrell today
> to report on the WG feedback and have a new proposal for the WG's
> review, which Stephen would be okay with if worded properly.
> 
> The proposal is to split how we think about THIRD_PARTY into two
> separate options with different Option Codes (though the rest of 
> the option format may be identical), one in the base spec and one
> moved out of it.  Specifically:
> 
> * One is for use cases where the PCP client and PCP server are owned
>   and operated by the same entity and are placed on an entirely
>   trusted network.   That is explicitly not a home network nor a typical
>   enterprise network.   A PCP server intended for a home network
>   MUST NOT support this option.    This option can appear in the
>   pcp-base spec with the above restrictions and is intended to 
>   unblock the deployments of the people who objected to the 
>   "separate it out" proposal.   As noted below, we rename this option
>   to something else (SAME_PARTY?) and use the term THIRD_PARTY
>   for the next one.
> 
> * The second option would be separated out of the pcp-base spec,
>   would mandate that it be protected via whatever advanced security
>   mechanism we decide on, and be usable for more general cases
>   where the PCP client and PCP server could even be owned by
>   different entities and hence the term "THIRD_PARTY" is more
>   appropriate to retain for this option.
> 
> With appropriate wordsmithing, is this approach something we
> can quickly get consensus on?
> 
> -Dave
> 
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 2 Apr 2012 06:56:48 -0400

On Apr 1, 2012, at 8:21 AM, Stephen Farrell wrote:
> The basic problem here is that the PCP wg want to define
> something that needs security before that security is
> defined. Doing stuff backwards like that is just going to
> make it harder and that's what we face.

I understand.
> 
> In terms of ordering my preferences, most preferred 1st,
> that'd be:
> 
> 1. wait until the required security is defined
> 2. split out 3rd party until the required security is defined
>   and progress the base in the meantime with no 3rd party
>   option
> 3. the compromise that Dave outlined, which is to use a new
>   opcode constrained for use (as best we can) only in
>   environments that are "safe" without the additional
>   security that a general 3rd party option needs
> 
> I'm not at all fond of #3 but can live with it.

I'm not entirely comfortable with this option either, but if it works for the rest of the WG, I'll document it in the Security Considerations.  Can you help me, though, to understand what the Security Considerations should say about what constitutes a "safe" environment?  And, how a PCP Server wll know if it is running in a safe environment, or not?  What advices would you give, specifically, to implementors to help them decide whether to implement the new UNSECURE_THIRD_PARTY option, and when it would be safe to turn it on?

> I absolutely agree this is not a good part of the compromise. Some
> developers will however know that they're never in that environment
> and won't write the 3rd party code (I hope).

Oh, I understand what you are hoping for now...  Maybe, once we have a secure THIRD_PARTY option available, everyone will realize that they don't want to support the UNSECURE_THIRD_PARTY option?  I guess I think that the same thing could happen without having two options, where implementation start checking that it has been received in a secure message/  It isn't particularly _expensive_ to define another option, though, so I guess I can deal with that.

I do have some concern that once an UNSECURE_THIRD_PARTY option is available, the WG might have little motivation to define a more secure one...  I guess I can increase the chances of that happening, though, by working with folks to write it.  And maybe I can convince folks that we should officially deprecate the UNSECURE_THIRD_PARTY option when we do that...
> 
> - If all PCP code includes 3rd party then it will be unsafely turned
>  on in lots of places and we don't even have a WG -00 document for
>  how to address that.

We did accept PCP-Authentication as a WG document in Paris,  So, if there are no new issues raised on the list, we will have a WG -00 in a couple of weeks.

> - Defining a feature that MUST be implemented, MUST NOT be turned on
>  by default, that SHOULD almost always be disabled, and that can
>  only be turned if you have some (as yet) undefined security stuff
>  is just not a good place to be

Actually, the current THIRD_PARTY option is optional, so there is no requirement that it MUST be implemented.  

> - I don't see how we can add a "you SHOULD do x" statement to the PCP
>  base now when we don't know what x is, unless you want to hold the
>  pcp base document in the RFC editor queue to wait for x.

I understand.  Thanks for trying to help us move forward here.  

If you could help me understand how to define a "safe" environment in the Security Considerations, that would be very helpful.

Thanks,
Margaret

---

From: <[email-masked]>
Date: Mon, 2 Apr 2012 13:47:04 +0200

Dear Dave,

I don't see the value to define two Options. I'm still convinced we can keep the THIRD_PARTY Option in the base spec and clarify the remaining security concerns against it.

FWIW, the scenario I'm interested in is:

* Provide a user-interface hosted in the CPE. 
* The user will log into that interface using a login/password
* The user is invited to instruct mappings for hosts connected to the CPE. PCP messages are then generated by the UI. THIRD_PARTY Option is mandatory to be included otherwise packets can not be forwarded to the internal hosts.

The base spec may emphasis the followings:

* The CPE SHOULD disable by default THIRD_PARTY Option
* The PCP Server MUST enforce address validation

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la 
>part de Dave Thaler
>Envoyé : vendredi 30 mars 2012 16:43
>À : [email-masked]
>Cc : Stephen Farrell
>Objet : [pcp] Confirming consensus from WG meetings: 
>THIRD_PARTY revised
>

---

From: <[email-masked]>
Date: Mon, 2 Apr 2012 13:51:48 +0200

Re-,

The proposal made my Margaret works for me.

Cheers,
Med 

>part de Margaret Wasserman
>Envoyé : dimanche 1 avril 2012 13:57
>À : Dave Thaler
>Cc : [email-masked]; Stephen Farrell
>Objet : Re: [pcp] Confirming consensus from WG meetings: 
>THIRD_PARTY revised
>
>
>Personally, I don't see the value in splitting THIRD_PARTY 
>into two separate option codes that do exactly the same thing. 
> What is the difference between having two different option 
>codes, and having one option code that is restricted to be 
>used either in safe situations OR with cryptographic security?
>
>How can a PCP Server know when it is running in a trusted 
>environment, anyway?  I realize that this is mean to be some 
>shorthand for the DS-Lite case, but it is simply not the case 
>that all DS-Lite deployments will meet these criteria, since 
>I've heard discussion of a B4 running on customer-owned 
>equipment and/or hosts.  How can a PCP Server, even if it is 
>running on a DS-Lite AFTR _know_ that every B4 that tries to 
>send a THIRD_PARTY option to the server is owned by the same 
>entity as the PCP Server?
>
>- Add text to the place in the PCP spec where THIRD_PARTY is 
>defined to state that it MUST be disabled by default in PCP 
>Servers, and that it SHOULD NOT be enabled unless an access 
>control list (ACL) has been configured.  The ACL SHOULD 
>contain a list of PCP Clients (by internal IP Address) that 
>are allowed to send the THIRD_PARTY option, and a list of 
>addresses or address ranges for which each authorized PCP 
>Client can issue THIRD_PARTY requests.
>
>- Add text to the Security Considerations section that the use 
>of THIRD_PARTY without a cryptographic security mechanism 
>opens various attack vectors, and that THIRD_PARTY should only 
>be enabled without cryptographic security in environments 
>where the authorized PCP Client(s) and the PCP Server are 
>under the same administrative control AND where there is some 
>form of protection against address spoofing, such as layer 2 
>security or another type of restricted network access.
>

---

From: Sam Hartman <[email-masked]>
Date: Mon, 02 Apr 2012 07:57:38 -0400

>>>>>   <[email-masked]> writes:

    > * Provide a user-interface hosted in the CPE.  * The user will log
    > into that interface using a login/password * The user is invited
    > to instruct mappings for hosts connected to the CPE. PCP messages
    > are then generated by the UI. THIRD_PARTY Option is mandatory to
    > be included otherwise packets can not be forwarded to the internal
    > hosts.

Is the CPE also the PCP server in this environment?

---

From: <[email-masked]>
Date: Mon, 2 Apr 2012 13:58:15 +0200

Hi,

Thanks to Margaret for this proposal, which is fine by me.

Cheers,

Christian. 

[snip]

Margaret

On Mar 30, 2012, at 10:43 AM, Dave Thaler wrote:

> deploying PCP for the web portal case, I met with Stephen Farrell 
> today to report on the WG feedback and have a new proposal for the 
> WG's review, which Stephen would be okay with if worded properly.
> 
> separate options with different Option Codes (though the rest of the 
> option format may be identical), one in the base spec and one moved 
> out of it.  Specifically:
> 
> With appropriate wordsmithing, is this approach something we can 
> quickly get consensus on?
> 
> -Dave
> 
> 

_________________________________________________________________________________________________________________________

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: Mon, 2 Apr 2012 14:02:02 +0200

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: maandag 2 april 2012 13:52
To: Margaret Wasserman; Dave Thaler
Cc: [email-masked]; Stephen Farrell
Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised

Re-,

Cheers,
Med

---

From: <[email-masked]>
Date: Mon, 2 Apr 2012 14:03:57 +0200

Re-,

No. It behaves only as PCP Client. 

Cheers,
Med 

>De : Sam Hartman [mailto:[email-masked]] 
>Envoyé : lundi 2 avril 2012 13:58
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : Dave Thaler; [email-masked]; Stephen Farrell

---

From: Sam Hartman <[email-masked]>
Date: Mon, 02 Apr 2012 08:17:56 -0400

>>>>>   <[email-masked]> writes:

Hi.
As I recall the ds-lite case has been ruled out of scope for a future
document.

I'd like to understand  two things.
1) What is the use case where the CPE is a PCP client but we are not
using ds-lite?

2) Can you please walk through the analysis of the simple security model
for your use case and explain how we know that the third party option
will not introduce new vulnerabilities beyond those permitted by
implicit mappings?

Thanks,
--Sam

    > Re-, No. It behaves only as PCP Client.

    > Cheers, Med

    >> -----Message d'origine----- De : Sam Hartman
    >> [mailto:[email-masked]] Envoyé : lundi 2 avril
    >> 2012 13:58 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Dave
    >> Thaler; [email-masked]; Stephen Farrell Objet : Re: [pcp]
    >> Confirming consensus from WG meetings: THIRD_PARTY revised
    >> 
    >> > * Provide a user-interface hosted in the CPE.  * The user will
    >> log > into that interface using a login/password * The user is
    >> invited > to instruct mappings for hosts connected to the
    >> CPE. PCP messages > are then generated by the UI. THIRD_PARTY
    >> Option is mandatory to > be included otherwise packets can not be
    >> forwarded to the internal > hosts.
    >>

---

From: <[email-masked]>
Date: Mon, 2 Apr 2012 14:55:03 +0200

Re-,

The current situation is there are no (yet) PCP-enabled applications so we would have a bootstrapping issue: provide means to subscribers to control their mappings in PCP-controlled devices without requiring all applications/hosts be PCP-enabled. A PCP-controlled device can be a CGN (NAT44), a DS-Lite AFTR or a NAT64.

This issue can be met by combining one or all of the following pieces:

* Provide a user-interface to control the mapping (we already have such port forwarding interface). This interface will be modified to trigger PCP messages. For this case, the internal IP address is not the same as the address of the PCP client; THIRD_PARTY Option is needed.
* Enable a IGD/PCP Interworking function
* Enable a PCP Proxy

If we consider the three deployments I mentioned above: CGN (NAT44), DS-Lite AFTR and NAT64. The PCP Server can enforce policies to validate the content of the THIRD_PARTY Option:

* DS-Lite AFTR case: the THIRD_PARTY Option MUST embed a private IP address. This is the same validation for implicit mappings.
* NAT64 case: The THIRD_PARTY Option and the source IP address of the PCP Client MUST belong to the same IPv6 prefix (e.g. /56). This is the same constraint as for implicit mapping

Please let me know if I answered your question.

Cheers,
Med 

>Envoyé : lundi 2 avril 2012 14:18

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 Apr 2012 07:09:06 -0400

> Re-, The current situation is there are no (yet) PCP-enabled
    > applications so we would have a bootstrapping issue: provide means
    > to subscribers to control their mappings in PCP-controlled devices
    > without requiring all applications/hosts be PCP-enabled. A
    > PCP-controlled device can be a CGN (NAT44), a DS-Lite AFTR or a
    > NAT64.

    > * Provide a user-interface to control the mapping (we already have
    > such port forwarding interface). This interface will be modified
    > to trigger PCP messages. For this case, the internal IP address is
    > not the same as the address of the PCP client; THIRD_PARTY Option
    > is needed.  * Enable a IGD/PCP Interworking function * Enable a
    > PCP Proxy

Hi.

He believes that even for a solution like Margaret proposes, we'd need
to explicitly restrict against implementing the base spec third party
option for CPE or enterprise equipment.  It would look a lot more like
the third-party option for trusted networks Dave proposed on Friday than
what Margaret described.

So, it would not help the use case you have.

I think the third-party option would need a mandatory-to-implement
security mechanism for Stephen to be comfortable with your use case
above.
So,  I believe the solutions you've been supporting in the last few days
are solutions that the IESG would not approve.

What I'd like to understand is who in the WG believes it is worth
delaying the base spec for the portal use case.  The portal use case is
one where the PCP server is running on ISP equipment (CGN for
example). The ISP runs a website on their servers (not CPE) that allows
users to log in with some ISP-issued credentials and manipulate
mappings.  That style of use case is the only one where Stephen is
indicating flexibility with a mandatory-to-implement security mechanism.

So, I'd like to better understand who in the WG believes it's worth
delaying the base spec to address this use case but not the broader
third-party use case. We'd do the broader third-party use case in a
separate document as dave suggested Friday. The delay introduced would
be greater than if we simply move all third-party use cases to a
separate document but not nearly as long as adding a
mandatory-to-implement security mechanism to the base spec.

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 03 Apr 2012 08:56:58 -0700

>third-party use case.

The portal case I've been pushing forward for a long time is the one most
broadband ISPs are trying to deploy due to the fact out of the ~500M CPEs
none of them support PCP, but support some form of  port forwarding. And
btw, when they do support PCP might be UPnP<->PCP in order to leverage the
millions of ready applications.

Mobile (3G/4G) is different, port forwarding is not status quo. Third
party applicability is for a different scenario.

I believe having third-party in the base spec is very important.

> We'd do the broader third-party use case in a

---

From: <[email-masked]>
Date: Tue, 3 Apr 2012 18:43:47 +0200

Dear Sam, 

Please see inline.

Cheers,
Med 

>Envoyé : mardi 3 avril 2012 13:09

Med: Why?

>are solutions that the IESG would not approve.

Med: The solution proposed by Margaret works for me. For my own use case, there is no need to enforce authentication for PCP while the same validation rules for implicit mappings apply.

>delaying the base spec for the portal use case.

Med: We are not delaying the progress of the base spec. We are asking to maintain the THIRD_PARTY option in the base spec, with the appropriate security checks (like the ones suggested by Margaret), because we have deployment plans requiring that option. 

What is wrong with the proposal made by Margaret?

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 Apr 2012 13:23:44 -0400

>> He believes that even for a solution like Margaret proposes, we'd
    >> need to explicitly restrict against implementing the base spec
    >> third party option for CPE or enterprise equipment.  It would
    >> look a lot more like the third-party option for trusted networks
    >> Dave proposed on Friday than what Margaret described.
    >> 

    > Med: Why?

Are you asking why  a solution that forbids implementation for equipment
targeted at CPEs would be problematic for the use case you've defined
or are you asking why Stephen requires additional restrictions beyond
what Margaret originally proposed?

    > What is wrong with the proposal made by Margaret?

Stephen believes that additional restrictions similar to those proposed
by Dave are required in order to address his concerns.
So, margaret's proposal would be insufficient for Stephen to remove his
blocking objection to the approval of the base spec.

If you're asking why Stephen believes that, I'd refer you to him or to
his comments in the IETF datatracker (the formal text of his objection).

Hope that helps.

--Sam