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

Juergen Quittek <Quittek@neclab.eu> Wed, 18 November 2015 23:02 UTC

Return-Path: <Quittek@neclab.eu>
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 E87741B3306; Wed, 18 Nov 2015 15:02:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 dKB0C8iRtuic; Wed, 18 Nov 2015 15:02:25 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91EFC1B3302; Wed, 18 Nov 2015 15:02:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 59CAE10B0A0; Thu, 19 Nov 2015 00:02:24 +0100 (CET)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcVl1K8ein_h; Thu, 19 Nov 2015 00:02:24 +0100 (CET)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 3614010B092; Thu, 19 Nov 2015 00:02:12 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.59]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Thu, 19 Nov 2015 00:02:12 +0100
From: Juergen Quittek <Quittek@neclab.eu>
To: joel jaeggli <joelja@bogus.com>, The IESG <iesg@ietf.org>
Thread-Topic: Alissa Cooper's Discuss on draft-ietf-pcp-third-party-id-option-04: (with DISCUSS)
Thread-Index: AQHRIWs+eiAm6OTvFEe5id6zk7M69J6iWx+ggAAKgLA=
Date: Wed, 18 Nov 2015 23:02:11 +0000
Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E8A99F6FDD@PALLENE.office.hd>
References: <20151117190736.2752.16846.idtracker@ietfa.amsl.com> <9AB93E4127C26F4BA7829DEFDCE5A6E8A99F6DE6@PALLENE.office.hd>
In-Reply-To: <9AB93E4127C26F4BA7829DEFDCE5A6E8A99F6DE6@PALLENE.office.hd>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.7.0.205]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/pcp/zL_CfWOj7KkXbx_Kyy_oIeRGKOM>
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: Wed, 18 Nov 2015 23:02:28 -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


> -----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.
> >
> >
> >