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

joel jaeggli <> Thu, 19 November 2015 05:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 12F1F1A888F; Wed, 18 Nov 2015 21:43:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZEI1Zbofdtyp; Wed, 18 Nov 2015 21:43:19 -0800 (PST)
Received: from ( [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64C9B1A8888; Wed, 18 Nov 2015 21:43:19 -0800 (PST)
Received: from mb-2.local ( []) (authenticated bits=0) by (8.14.9/8.14.9) with ESMTP id tAJ5hFQD015381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 Nov 2015 05:43:16 GMT (envelope-from
To: Juergen Quittek <>, The IESG <>
References: <> <> <>
From: joel jaeggli <>
Message-ID: <>
Date: Wed, 18 Nov 2015 21:43:08 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Thunderbird/42.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nrlebsNa7B257mVGeppUGRbtpcjFLoglO"
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [pcp] Alissa Cooper's Discuss on draft-ietf-pcp-third-party-id-option-04: (with DISCUSS)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Nov 2015 05:43:24 -0000

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 []
>> Sent: Mittwoch, 18. November 2015 23:32
>> To: Alissa Cooper; The IESG
>> Cc:;;
>> 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 []
>>> Sent: Dienstag, 17. November 2015 20:08
>>> To: The IESG
>>> Cc:;;
>>> Subject: Alissa Cooper's Discuss on draft-ietf-pcp-third-party-id-option-04:
>> (with
>>> 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
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> The document, along with other ballot positions, can be found here:
>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> 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.