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

[Juergen Quittek <[e-mail]>]

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:[e-mail]]
> Sent: Dienstag, 17. November 2015 20:08
> To: The IESG
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 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.
> 
> 
>