Subject: Re: [pcp] Alissa Cooper's Discuss on draft-ietf-pcp-third-party-id-option-04: (with DISCUSS)

From: Juergen Quittek <[email-masked]>
Date: Wed, 18 Nov 2015 22:32:26 +0000

Dear Alissa,

Thank you very much for your review.

(1)
In your first point you explain that the draft "seems workable when the
THIRD_PARTY_ID is a tunnel ID, but not for any identifier that anyone
might stick in there". 

Initially, the draft was about tunnel IDs only and the option name was 
not THIRD_PARTY_ID, but TUNNEL_ID. But after several reviews, there
was consensus in the PCP WG that we should widen the scope to more
general applications of this option.

If we now go back to limiting the scope again to tunnel IDs only, then this
is OK with the authors of the draft. But I don't know if we then need to get 
back to the WG and get consensus there on reducing the scope back to the 
initial one.

Can you advise us how to proceed?

(2)
Your second point can probably be resolved much easier. We (the authors)
Will soon suggest a more elaborated description for section 5.2.

Best regards,
    Juergen

> -----Original Message-----
> From: Alissa Cooper [mailto:[email-masked]]
> Sent: Dienstag, 17. November 2015 20:08
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Alissa Cooper's Discuss on draft-ietf-pcp-third-party-id-option-04: (with
> DISCUSS)
> 
> Alissa Cooper 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:
> ----------------------------------------------------------------------
> 
> I have a couple of questions and observations I'd like to discuss.
> 
> (1)
> >From Section 3:
> 
> "The scenarios serve as examples.  This document does not restrict the
>    applicability of the THIRD_PARTY_ID to certain scenarios.  The
>    THIRD_PARTY_ID can include any Layer-2 identifier like a MAC address
>    or other subscriber identifiers as, for example, mentioned in section
>    6 of [I-D.boucadair-pcp-sfc-classifier-control].  The THIRD_PARTY_ID
>    can also be used for the firewall control, including the case of a
>    virtual CPE, see section 3 of [I-D.lee-vhs-usecases]."
> 
> I think the document makes a reasonable case for why carrying a tunnel ID
> in a THIRD_PARTY_ID option is useful. I don't think it makes a reasonable
> case for any other use of the option, though, given the potential
> security and privacy issues associated with sending a potentially unique
> and permanent subscriber identifier. The drafts mentioned above envision
> much broader uses for both the option and PCP than the use case in this
> document, and suggest some uses of the option that seem like a mismatch
> for what the identifiers embedded within it were originally intended for
> (e.g., using an IMSI for traffic classification/policing).
> 
> Conflating these cases also makes it difficult to understand how the
> THIRD_PARTY_ID relates back to NAT. Presumably, a PCP-controlled NAT
> needs traffic on the incoming side to always include the THIRD_PARTY_ID
> -- otherwise, the fact that the mapping table contains the additional ID
> is only useful in one direction. This seems workable when the
> THIRD_PARTY_ID is a tunnel ID, but not for any identifier that anyone
> might stick in there. Again coming back to the traffic policing scenario,
> it seems unlikely that every time I as the subscriber send traffic
> through the NAT, my IMSI will be included to differentiate my traffic
> from another subscriber who has the same internal address as I do. So by
> allowing this field to contain any identifier, it becomes less obvious
> why PCP should be used to communicate it in the first place.
> 
> In short, I think this draft needs to either more narrowly specify a
> means to communicate a tunnel ID, or provide both a more thorough
> security and privacy analysis of the implications of sending any
> identifier and an explanation of the implications on the availability of
> those identifiers in traffic sent to a PCP-controlled NAT.
> 
> (2)
> Section 5.2 seems underspecified. RFC 6887 has a lot logic riding on the
> question of whether two requests are meant to identify the same host
> or not (in sec 11.3 and sec 12.3) based on the combination of internal
> address, protocol, and port, but this draft leaves unspecified what the
> comparison logic is supposed to be or the error conditions that result
> from adding another field to the determination of whether
> two hosts are the same or not. For example, is every instance of
> "internal address, protocol, and port" in those sections meant to be
> replaced with "internal address, protocol, port, and THIRD_PARTY_ID"? If
> a device that already has a mapping for a particular internal address,
> port, protocol and THIRD_PARTY_ID receives a new request for the same
> internal address, port, and protocol but has no THIRD_PARTY_ID, what
> steps is it supposed to follow? Saying that the THIRD_PARTY_ID should be
> "used in addition when accessing a mapping table" doesn't seem like
> enough detail to go implement this.
> 
> 
>

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 18 Nov 2015 23:02:11 +0000

Dear Joel,

The authors did not receive an email related to your DISCUSS.
That's why I use a reply to Alissa's DISCUSS to address yours.

Here is what you entered:
   "I see the secdir reviewer has raised this issue as well, but 
   from my vantage point the issue of is slightly different. the 
   use of the mac address or alternatively a different third 
   party identifier is underspecified. What's the purpose of 
   using a stable identifier except to facilitate tracking? if that's 
   the case then it should be a spelled out,  a pcp interworking 
   function could use basically anything to distinguish between 
   two hosts when requesting a mapping, e.g. the mapping is 
   bound to ip addresses.

   Extending the the option to applications outside of the L2 domain 
   (as described in section 3) proposes to extended the use of this 
   mac based identifier still further, which seems like an opportunity 
   for information leakage outside the scope of the L2 domain, 
   when ephemeral or session based identifiers might be more 
   appropriate."

It seems that Alissa's DISCUSS can be solved by reducing the scope 
of the THIRD_PARTY_ID option to tunnel IDs only. 
Would that also solve your DISCUSS?

Best regards,
    Juergen

> From: Juergen Quittek [mailto:[email-masked]]
> Sent: Mittwoch, 18. November 2015 23:32
> To: Alissa Cooper; The IESG
> Subject: RE: Alissa Cooper's Discuss on draft-ietf-pcp-third-party-id-option-04:
> (with DISCUSS)
> 
> Dear Alissa,
>

---

From: joel jaeggli <[email-masked]>
Date: Wed, 18 Nov 2015 21:43:08 -0800

> Would that also solve your DISCUSS?

possibly we'll probably have to dicuss that with the opsdire reviewer
and the other parties.

---

From: <[email-masked]>
Date: Thu, 19 Nov 2015 06:53:49 +0000

Hi Jueren, all,

I was one of those asking to rename the option as its applicability is not limited to tunnel environments nor it is required for any tunnel environment. For example, DS-Lite is an encapsulation-based solution but it does not require such option.

I'm personally interested in this option for deployments where both the pcp client and the pcp server belong to the same administrative entity (e.g., virtual CPE case). In such deployments, the information enclosed in the option is not revealed outside the domain given that:
* the PCP server terminate the PCP session, and 
* the information included in the option by the PCP client is an information that is already visible/available to the PCP server (e.g., extra-ds-lite case (RFC6619), a layer 2 information for L2-aware NAT, etc.)

If the PCP client and pcp server are not managed by the same administrative entity, then the same issues we had for THIRD_PARTY apply for this one.

The information in the THIRD_PARTY_ID option can be any information that allows to unambiguously distinguish traffic from two hosts at the PCP server AND which is ALREADY VISIBLE to the PCP server. 

A generic comment: the PCP-controlled device is not necessarily a NAT, but it can be a firewall, a port range router (A+P), or any other flow-aware function.

I suggest the privacy/security section to be updated if needed. 

Cheers,
Med

> -----Message d'origine-----
> De : pcp [mailto:[email-masked]] De la part de Juergen Quittek
> Envoyé : mercredi 18 novembre 2015 23:32
> À : Alissa Cooper; The IESG
> Cc : [email-masked]; [email-masked]; pcp-
> [email-masked]
> Objet : Re: [pcp] Alissa Cooper's Discuss on draft-ietf-pcp-third-party-
> id-option-04: (with DISCUSS)
> 
> Dear Alissa,
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp