Subject: [pcp] Summarizing THIRD_PARTY discussion

From: Dave Thaler <[email-masked]>
Date: Sat, 5 May 2012 21:21:11 +0000

There have been a number of proposals made, including:

1) Delay the base spec until some future time when we have finished advanced
security.   Although a few were in favor of this, WG consensus was against this.

2) Margaret's proposal summarized 4/1: http://www.ietf.org/mail-archive/web/pcp/current/msg02015.html
where there's only one THIRD_PARTY option, it's disabled by default,
but implementable on all devices.  Stephen Farrel was asked if that would
pass the IESG and he responded 4/1 saying "'Fraid not."
(His email 4/1 is attached.  It isn't showing up in the archives, so I'm separately
trying to track that down and get that fixed, since that seems to be the cause
of some confusion.)

Sam then re-summarized Stephen's position in email 4/3:
http://www.ietf.org/mail-archive/web/pcp/current/msg02040.html
So even though a bunch of WG people expressed support for this,
it turns out to be the same as option 1 (delay the base spec for a long time).
Hence this is not an option, since I do not see that people arguing for
Margaret's were in support of delaying the base spec.   However, 
this option did influence the updated points of the next approach below.

3) Have an UNSECURE_THIRD_PARTY (or UNSAFE_THIRD_PARTY)
option in the base spec, that MUST NOT be implemented in home gateways
or enterprise systems, only by web portals in secure networks.  This
was the compromise proposal I summarized in email 3/30:
http://www.ietf.org/mail-archive/web/pcp/current/msg02006.html
Stephen further sent points to be made in text in off-list email
4/2 to Margaret, Sam, and me which I quote from below, with his permission:

> It might take some iterations to get the language right but essentially it seems that:
>
> a) only a person can know when they're running in a "safe"
> environment, so the UNSAFE_THIRD_PARTY option (or whatever it gets 
> called) MUST be off by default
>
> b) there doesn't seem to be any known-safe case for this in the home
>
> c) there doesn't seem to be any known-safe case for this in a typical office environment
>
> d) a typical VM environment would not have any known-safe case for this 
> (just calling this out because sometimes you might consider networking 
> between VM's on the same h/w safe, but in general its not)
>
> e) where both hosts involved are equally trusted and operated by the 
> same entity and all traffic between them is fully trusted already then it 
> seems safe for one of them to be a PCP client that uses the 
> UNSAFE_THIRD_PARTY option to control a PCP server on the other one
> if the PCP server has an ACL for addresses allowed to use the option
>
> f) I think that a developer whose code will only run in environments 
> like (b)-(d) SHOULD NOT implement UNSAFE_THIRD_PARTY, but a developer
> whose code will run only in an place like (e) MAY implement it, and if you're
> not sure then don't write that code.
>
> I think that (e) captures the known-safe use-case that Dave described to 
> me where an operator hosts the PCP clients and servers inside its network.

In my view we have ROUGH consensus on the approach in the base spec with
restrictions noted in Stephen's (a-f), in order to get it published in a timely
fashion.  I saw a number of folks on the list saying they can live with it 
(assuming it's worded correctly of course), and only 2 people saying they 
preferred an option that we then found won't pass IESG, but I think that then 
influenced (f).

So at present, I'd like the document editors to try to craft text based on
Stephen's (a-f) above and post the proposed text to the list.

-Dave (as WG chair)

Subject: Re: [pcp] Confirming consensus from WG meetings: THIRD_PARTY revised
From: Stephen Farrell <[email-masked]>
To: Margaret Wasserman <[email-masked]>
Cc: Dave Thaler <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sun, 1 Apr 2012 12:21:55 +0000

Hi Margaret,

I'm sympathetic with both your and Sam's approaches.

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.

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.

On 04/01/2012 12:57 PM, Margaret Wasserman wrote:
>
> 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?

I think a separate opcode is less bad since there'd be no reason
to implement it for a bunch of implementations where a general
3rd party option would be unsafe.

> How can a PCP Server know when it is running in a trusted environment, anyway?

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

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

'Fraid not. I like that much less than #3 above. Reasons:

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

Hope that helps,
Cheers,
S.

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