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

joel jaeggli <joelja@bogus.com> Thu, 19 November 2015 05:43 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F1F1A888F; Wed, 18 Nov 2015 21:43:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEI1Zbofdtyp; Wed, 18 Nov 2015 21:43:19 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C9B1A8888; Wed, 18 Nov 2015 21:43:19 -0800 (PST)
Received: from mb-2.local (c-73-158-58-32.hsd1.ca.comcast.net [73.158.58.32]) (authenticated bits=0) by nagasaki.bogus.com (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 joelja@bogus.com)
To: Juergen Quittek <Quittek@neclab.eu>, The IESG <iesg@ietf.org>
References: <20151117190736.2752.16846.idtracker@ietfa.amsl.com> <9AB93E4127C26F4BA7829DEFDCE5A6E8A99F6DE6@PALLENE.office.hd> <9AB93E4127C26F4BA7829DEFDCE5A6E8A99F6FDD@PALLENE.office.hd>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <564D616C.4030208@bogus.com>
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: <9AB93E4127C26F4BA7829DEFDCE5A6E8A99F6FDD@PALLENE.office.hd>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nrlebsNa7B257mVGeppUGRbtpcjFLoglO"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pcp/Lb8dI_ZWqHMXNBoIS0I8hN6pYJc>
Cc: "pcp@ietf.org" <pcp@ietf.org>, "draft-ietf-pcp-third-party-id-option@ietf.org" <draft-ietf-pcp-third-party-id-option@ietf.org>, "pcp-chairs@ietf.org" <pcp-chairs@ietf.org>
Subject: Re: [pcp] Alissa Cooper's Discuss on draft-ietf-pcp-third-party-id-option-04: (with DISCUSS)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=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 [mailto:Quittek@neclab.eu]
>> Sent: Mittwoch, 18. November 2015 23:32
>> To: Alissa Cooper; The IESG
>> Cc: draft-ietf-pcp-third-party-id-option@ietf.org; pcp-chairs@ietf.org;
>> repenno@cisco.com; pcp@ietf.org
>> 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:alissa@cooperw.in]
>>> Sent: Dienstag, 17. November 2015 20:08
>>> To: The IESG
>>> Cc: draft-ietf-pcp-third-party-id-option@ietf.org; pcp-chairs@ietf.org;
>>> repenno@cisco.com; pcp@ietf.org
>>> 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.
>>>
>>>
>>>
> 
>