Subject: [pcp] Do we need to provide the confidentiality protection for PCP?

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Sun, 2 Mar 2014 20:12:18 +0000

Hi, all:

This Friday, I joined the Strint Workshop which discussed how pervasive monitoring (PM) attacks will affect the security work in IETF and W3C. It seems that opportunistic encryption on meta-data will be a common requirement in order to deal with the PM. So, maybe it is also the right time for us to discuss whether the confidentiality protection on the mapping information (or other information which can be used by attackers to perform attacks) transported in the PCP messages should be provided or not.

Thoughts?

Dacheng

---

From: Ted Lemon <[email-masked]>
Date: Sun, 2 Mar 2014 20:31:18 +0000

> Thoughts?

I think it would be the same argument you'd make for DHCP, since the scope of transit is sort of similar, and the ad-hoc nature of the protocols are quite similar: you can't count on a pre-shared key.   There are certainly arguments to be made in favor of it, but the question is, can you realistically do it?

I think it's not the highest priority, because a lot of the things we'd be concerned about don't matter within the expected scope.   pcp packets typically won't wind up hitting remote servers, and won't be correlatable.   Information in the packets is available on the local link anyway, although perhaps more work to collect.

But it's definitely worth thinking about.   You might want to ask on the perpass mailing list for someone who is knowledgable enough to talk it through with you.

---

From: Dave Thaler <[email-masked]>
Date: Tue, 4 Mar 2014 10:25:00 +0000

My comment to Dacheng was that for most things, it's probably not important
because the 5-tuple is already visible in the packets of the actual communication.
The only possible exception that came to mind was the PCP DESCRIPTION option.

The security considerations section of that document (currently in the RFC editor
queue) already says this:
>  If the PCP client and the PCP server are not under the same
>  administrative entity, the DESCRIPTION option has the potential to
>  leak privacy-related information.  PCP clients should not use
>  DESCRIPTION option for such leakage.  For example, the option should
>  not be used to include user identifiers, locations, or names.  Refer
>  to Section 3.2 of [RFC6462] for a discussion on information leakage.

-Dave

> -----Original Message-----
> From: pcp [mailto:[email-masked]] On Behalf Of Ted Lemon
> Sent: Sunday, March 2, 2014 8:31 PM
> To: Zhangdacheng (Dacheng)
> Cc: [email-masked]
> Subject: Re: [pcp] Do we need to provide the confidentiality protection for
> PCP?
> 
> I think it would be the same argument you'd make for DHCP, since the scope
> of transit is sort of similar, and the ad-hoc nature of the protocols are quite
> similar: you can't count on a pre-shared key.   There are certainly arguments
> to be made in favor of it, but the question is, can you realistically do it?
> 
> I think it's not the highest priority, because a lot of the things we'd be
> concerned about don't matter within the expected scope.   pcp packets
> typically won't wind up hitting remote servers, and won't be correlatable.
> Information in the packets is available on the local link anyway, although
> perhaps more work to collect.
> 
> But it's definitely worth thinking about.   You might want to ask on the
> perpass mailing list for someone who is knowledgable enough to talk it
> through with you.
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp