Re: [pcp] Stephen Farrell's Discuss on draft-ietf-pcp-third-party-id-option-04: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

Hiya,

On 24/01/16 12:20, Rolf Winter wrote:
> Hi Stephen,
> 
> please see inline:
> 
> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park,
> West End  Road, London, HA4 6QE, GB | Registered in England 2832014
> 
>> Stephen Farrell has entered the following ballot position for 
>> draft-ietf-pcp-third-party-id-option-04: Discuss
>> 
>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to
>> cut this introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss- 
>> criteria.html for more information about IESG DISCUSS and COMMENT
>> positions.
>> 
>> 
>> The document, along with other ballot positions, can be found
>> here: 
>> https://datatracker.ietf.org/doc/draft-ietf-pcp-third-party-id-option/
>>
>>
>>
>>
>> 
----------------------------------------------------------------------
>> DISCUSS: 
>> ----------------------------------------------------------------------
>>
>>
>>
>> 
(1) The THIRD_PARTY stuff in PCP was always a bit concerning from a
>> security point of view. RFC 6887 says that you MUST NOT implement
>> or use that except in some specific environments. At the time we
>> would have liked to say that you MUST use PCP authentication when
>> using that but RFC 7652 wasn't done until some time later. My
>> DISCUSS question though is: why can't you distinguish based on a
>> Key ID used with PCP authentication?
> 
> Because you'll need a tunnel technology specific ID. 

Yet the current draft says that the value used is just
agreed out of band between pcp client and server with
no typing. Seems the same to me.

> The
> PCP-controlled device needs to know to which tunnel this requested
> mapping (IP in the third party option) belongs.
> 
> We added some text to the document which hopefully makes this
> clearer:
> 
> The THIRD_PARTY option carries a value of an internal IP address of
> a NAT map entry.  The THIRD_PARTY_ID carries a value of an internal 
> realm of a NAT map entry.
> 
> Upon receiving a valid request with a legal THIRD_PARTY_ID option 
> identifier, the message is processed as specified in [RFC6887], 
> except that the identifier contained in the THIRD_PARTY_ID is used
> in addition when accessing a mapping table.  Instead of just using
> the value contained in the THIRD_PARTY option when accessing the
> internal Internet address of a mapping table, now the combination of
> the two values contained in the THIRD_PARTY option and in the
> THIRD_PARTY_ID option is used to access the combination of internal
> Internet address and internal realm of a NAT map entry.
> 

Yes, that's clear but doesn't answer the question about 7652.

> 
>> Wouldn't that help with the privacy concerns (one can manage Key
>> IDs well if one wants) and also with the secrity concerns, and I
>> would guess it should solve the tunnel issues that this is intended
>> to address as well? (There may be good reasons why that doesn't
>> work of course, but I'd like to understand them.)
> 
> I am not sure how that would solve the overall problem. Say someone
> uses L2TPv3 or GRE (or any other protocol really) as the tunneling
> protocol, then you're bound to use IDs from those protocols. They are
> not linked to the PCP sessions (indeed the scenario in the draft
> shows that PCP messages are not even delivered over the tunnel).

That's a fair point actually. Ok, I agree that PCP authentication
isn't designed for these use cases. (It could I guess be made to
work but yeah, that'd I agree be a pretty odd implementation.)

I'll clear this point.

> 
> Regarding authentication, we added text to the security
> considerations section and used normative language to mandate
> authenticated access to the PCP client function.
>

Yet with no reference to 7652? Pity.

> 
>> 
>> (2) Section 7: The "must be fully trusted" phrase is not a good one
>> to use - iirc that was a compromise figured out to allow PCP to
>> proceed ahead of the PCP auth spec.  And of course, it's really a
>> nonsense. I think you should properly characterise the issues or
>> else delete the unfortunate phrase.
> 
> We added text to the security considerations section (incl. normative
> language).
> 
>> I also think you should not encourage the use of this for carrying
>> location or profile information.  What "Means" exist that could be
>> used to really protect this? And why do you want to "protect
>> unauthorized access"? that's oddly phrased at best. All in all I
>> think you need better text for section 7, and I'm happy to try
>> help find that.
> 
> We now restrict the usage of the option as defined in this document
> to the exact use case as described. In particular, the document now
> clearly states:
> 
> However, the use of the THIRD_PARTY_ID option as specified in this
> document is restricted to scenarios where the option is needed for
> the purpose of uniquely identifying an internal host in addition to
> the information found in the THIRD_PARTY option.

Well, the current text has a bunch of SHOULD statements saying to
be good and not send this stuff out of the operator network. I
don't get why those aren't MUST NOT statements. Why is that?

Couldn't you just simplify and say that this option MUST NOT be
sent outside an operator network?

S

> 
>> 
>> 
>> ----------------------------------------------------------------------
>>
>> 
COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>>
>> 
I share the concerns relating to possible use of long term identifiers
>> here and thus support the DISCUSSes from Alissa and Joel.
> 
> We have text that discusses this now in the security considerations
> section.
> 
> Best,
> 
> Rolf
> 
> 
>> 
>> 
>> _______________________________________________ pcp mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/pcp
>