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

[joel jaeggli <[e-mail]>]

On 11/18/15 3:02 PM, Juergen Quittek wrote:
> 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?

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

> Best regards,
>     Juergen
> 
> 
>> -----Original Message-----
>> From: Juergen Quittek [mailto:[e-mail]]
>> Sent: Mittwoch, 18. November 2015 23:32
>> To: Alissa Cooper; The IESG
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: RE: Alissa Cooper's Discuss on draft-ietf-pcp-third-party-id-option-04:
>> (with DISCUSS)
>>
>> 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.
>>>
>>>
>>>
> 
>