From tom.taylor.stds@gmail.com Sun Dec 1 12:50:20 2013 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E60E1AE10E for ; Sun, 1 Dec 2013 12:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 bNw0UTnEFEdr for ; Sun, 1 Dec 2013 12:50:18 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3001AE136 for ; Sun, 1 Dec 2013 12:50:18 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id x13so18741616ief.6 for ; Sun, 01 Dec 2013 12:50:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=W/ey0sCV2MqABCx8w0wUJXakLP6bSNHgBRUJ2n/gv3Q=; b=Wd23zKkfpjbWJMfGd8KPWZGsf9LqOIIhj8weFUS38fC+KnVOIRlHcVe/lwKxamL2Qf dN+Dgf1KY8kxxtMl1t6XspSwZvMxii/hYG2n70Zx+ZPGfqdI8JqhPaXv9D4k2IPiPuMn fZMUnliqCuHl4TiynbmcN7wv4Km+D669ccz9P36hal8K5YTnksndwZqqTlxyuZXRs5AM iJu0uvLjRcvA/QVwCkT/4oX2cTxO6hL65xsg9FoGbL1TUXju4WX+eFTQggXwx3US+8aa y3P/D4hzcgSiMZO2ZGRNDiajqhicLd1SAYSk79ANzpUfEgqCaluEWCnbH4Vo8I0Msmh2 3gSw== X-Received: by 10.50.39.51 with SMTP id m19mr14495027igk.51.1385931016267; Sun, 01 Dec 2013 12:50:16 -0800 (PST) Received: from [192.168.1.65] ([64.56.250.4]) by mx.google.com with ESMTPSA id da14sm22749446igc.1.2013.12.01.12.50.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Dec 2013 12:50:15 -0800 (PST) Message-ID: <529BA104.2050500@gmail.com> Date: Sun, 01 Dec 2013 15:50:12 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "ancp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ANCP] Privacy issue in draft-ietf-ancp-mc-extensions-12 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 20:50:20 -0000 In his review of draft-ietf-ancp-mc-extensions-12, our AD pointed out that the optional presence of the Request-Source-IP or Request-Source-MAC TLV in the ANCP Multicast Admission Control message posed privacy issues. Looking through the ANCP requirements in RFC 5851 and TR-101, I could find no requirement that these be reported. I proposed that these TLVs be dropped from the message and from the document. I will assume that I have consent for this change if I do not hear arguments against it by the end of Wednesday, December 18. Tom Taylor From flefauch@cisco.com Mon Dec 2 01:11:43 2013 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2107F1AE387 for ; Mon, 2 Dec 2013 01:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ydG4kxtaUb9q for ; Mon, 2 Dec 2013 01:11:35 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 806131AE23C for ; Mon, 2 Dec 2013 01:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2161; q=dns/txt; s=iport; t=1385975464; x=1387185064; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2KRoRsOiJAU6bIwCrt1/ljl/tB0Q97vDlD1aomlIs1I=; b=N3n+vOtC8a2ccp6dxAce6H9pqpK0h1UPZuAAK4vsHEBeoH5DrU14ObMl TzkX6GtQgCE2qTUX01Ivwv9e24I7Fcsb7ycR+Xs1sY5CupGRLG+MFEEm9 k4fkSpp9xjWBwUSYHSgNDyIKLmZY3FD2mx5D2dxvPvxUSTAqdEATd5+Tg w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAINNnFKtJXG//2dsb2JhbABPCoMHOFO4V4EhFnSCJQEBAQMBAQEBNzQLBQsCAQg2ECEGCyUCBA4Fh28DCQYNt1ENhzQTBIx3gSUQKTMHgyCBEwOWKYFrjFqFOYMpgXE5 X-IronPort-AV: E=Sophos;i="4.93,809,1378857600"; d="scan'208";a="3575705" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-5.cisco.com with ESMTP; 02 Dec 2013 09:11:04 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB29B4e2016683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 09:11:04 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 03:11:03 -0600 From: "Francois Le Faucheur (flefauch)" To: Tom Taylor Thread-Topic: [ANCP] Privacy issue in draft-ietf-ancp-mc-extensions-12 Thread-Index: AQHO7tb0SgZ58E8jaUem8VSz3VS2I5pBA78A Date: Mon, 2 Dec 2013 09:11:02 +0000 Message-ID: <6EE0FD67-10BB-480C-941A-2C7986A91314@cisco.com> References: <529BA104.2050500@gmail.com> In-Reply-To: <529BA104.2050500@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.199] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ancp@ietf.org" Subject: Re: [ANCP] Privacy issue in draft-ietf-ancp-mc-extensions-12 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:11:43 -0000 Hello Tom, I think these TLVs bring some value: The ANCP Multicast Admission Control message supports the "Conditional Acce= ss and Admission Control Use Case". When conditional access is to be perfor= med on a per device basis (as opposed to per DSL line basis), the message n= eeds to provide the NAS with a way to identify the device. In general (and more or less by definition) the NAS has a lot of visibility= on each DSL line (certainly for unicast), so I assume the privacy concern = is not so much about communicating the info to the NAS but has more to do w= ith the risk of a monitoring attack of the ANCP protocol. Right? How about an alternative approach where we keep these TLVs in the document = and keep them as optional, but add a note that says that: * including those TLVs in the message is only useful when the NAS is to pe= rform per-device "Conditional Access and Admission Control" * including those TLVs in the message results in an increased privacy conc= ern because it exposes on the wire the corresponding privacy information ab= out which IP/MAC is accessing which multicast channel, which could be explo= ited by a monitoring attack on the ANCP protocol. * these TLVs SHOULD NOT be included when per-device "Conditional Access an= d Admission Control" by the NAS is not used Makes sense? Francois On 1 Dec 2013, at 21:50, Tom Taylor wrote: > In his review of draft-ietf-ancp-mc-extensions-12, our AD pointed out tha= t the optional presence of the Request-Source-IP or Request-Source-MAC TLV = in the ANCP Multicast Admission Control message posed privacy issues. Looki= ng through the ANCP requirements in RFC 5851 and TR-101, I could find no re= quirement that these be reported. >=20 > I proposed that these TLVs be dropped from the message and from the docum= ent. I will assume that I have consent for this change if I do not hear arg= uments against it by the end of Wednesday, December 18. >=20 > Tom Taylor > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From tom.taylor.stds@gmail.com Mon Dec 2 01:59:59 2013 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BAB1AE09E for ; Mon, 2 Dec 2013 01:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 zcEHAKA0Vndm for ; Mon, 2 Dec 2013 01:59:57 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id BBA4F1A1F3F for ; Mon, 2 Dec 2013 01:59:57 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id e14so20911200iej.28 for ; Mon, 02 Dec 2013 01:59:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=K6cVUITrGyFE0ituV8rz0TTnLLq0B3fOQynQ4daISlg=; b=ZgDbRespm5ykQfD361nsABcdIpHBEtGN2P3s6oHojvg2EIV9k9C1uNe92l3OQ4ApXr rgnkaUl29zP1rly8f+Wc8VyVNCqqAOncfhkH0kmgbhWFrWR4pITjYMPlPp55GfAVoM6l RfcuXqNTgJXe/lSYdvkYsDTQ2mWVRDp/vxqdr+r2QN1R7FTecFdxJQGt1WkiWNWjY2E5 hB7e/wkx3AhFf0csjNVBWZvpvfLIFKi720dorLebPzsn3tgNFZjdcIA5U63lHxPgxE+z sI27v0vBSWN0QYmOrYk+lseFoTEjjQ32PslCxOOR/xgyUoeecB/Gkhl4Ys7sGCPsH0Fe mzLA== X-Received: by 10.50.134.99 with SMTP id pj3mr16858194igb.14.1385978395369; Mon, 02 Dec 2013 01:59:55 -0800 (PST) Received: from [192.168.1.65] ([64.56.250.4]) by mx.google.com with ESMTPSA id i11sm65246781igh.0.2013.12.02.01.59.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 01:59:54 -0800 (PST) Message-ID: <529C5A19.7080204@gmail.com> Date: Mon, 02 Dec 2013 04:59:53 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Francois Le Faucheur (flefauch)" References: <529BA104.2050500@gmail.com> <6EE0FD67-10BB-480C-941A-2C7986A91314@cisco.com> In-Reply-To: <6EE0FD67-10BB-480C-941A-2C7986A91314@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ancp@ietf.org" Subject: Re: [ANCP] Privacy issue in draft-ietf-ancp-mc-extensions-12 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:59:59 -0000 This justification makes sense. I can think of use cases where one would want per-device control. Tom On 02/12/2013 4:11 AM, Francois Le Faucheur (flefauch) wrote: > Hello Tom, > > I think these TLVs bring some value: > The ANCP Multicast Admission Control message supports the "Conditional Access and Admission Control Use Case". When conditional access is to be performed on a per device basis (as opposed to per DSL line basis), the message needs to provide the NAS with a way to identify the device. > > In general (and more or less by definition) the NAS has a lot of visibility on each DSL line (certainly for unicast), so I assume the privacy concern is not so much about communicating the info to the NAS but has more to do with the risk of a monitoring attack of the ANCP protocol. Right? > > How about an alternative approach where we keep these TLVs in the document and keep them as optional, but add a note that says that: > * including those TLVs in the message is only useful when the NAS is to perform per-device "Conditional Access and Admission Control" > * including those TLVs in the message results in an increased privacy concern because it exposes on the wire the corresponding privacy information about which IP/MAC is accessing which multicast channel, which could be exploited by a monitoring attack on the ANCP protocol. > * these TLVs SHOULD NOT be included when per-device "Conditional Access and Admission Control" by the NAS is not used > > Makes sense? > > Francois > > On 1 Dec 2013, at 21:50, Tom Taylor > wrote: > >> In his review of draft-ietf-ancp-mc-extensions-12, our AD pointed out that the optional presence of the Request-Source-IP or Request-Source-MAC TLV in the ANCP Multicast Admission Control message posed privacy issues. Looking through the ANCP requirements in RFC 5851 and TR-101, I could find no requirement that these be reported. >> >> I proposed that these TLVs be dropped from the message and from the document. I will assume that I have consent for this change if I do not hear arguments against it by the end of Wednesday, December 18. >> >> Tom Taylor >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www.ietf.org/mailman/listinfo/ancp > > From tom.taylor.stds@gmail.com Mon Dec 2 02:23:01 2013 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730441AE1CF for ; Mon, 2 Dec 2013 02:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 lUQNC5FZgv3n for ; Mon, 2 Dec 2013 02:23:00 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0B91AE17B for ; Mon, 2 Dec 2013 02:22:59 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id ar20so19818100iec.2 for ; Mon, 02 Dec 2013 02:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=HBsMpVvdir04XviioB8mIBmaLc9I+S4c00wrQ2iLOD0=; b=Cbl0hlysUfpFh1OF/awmMtODhI2ykOaSOIAYunSM94WYMtniEW2/xKOWo2FnO7Tbfy /9J4JiySgbWiq2ZTvb4pyXr8kKdtxTIWtcwlYPk0GAgCxdCv2q2g+4yzSG1EdC6bngiT zi+Fz61U5F7AhuIhTIY0Bg0HI5+OFMRg8B9eqKYMAwfyn0XtMQ04ZpO5MVkZVdcjumN8 KoWsRhyyqOHBdWeo5DHmG2JIOh92m1+2cwNJ6fWtRuQK5NjYOakrZUfUsrCpAxtzMLtq rgY1Yd8QW3z3AE5+SQq115pNzi519PzaP9egNZNuadqAcA+bjTKeqL7TPgQSwQLDwPkP d7uw== X-Received: by 10.42.227.195 with SMTP id jb3mr37655718icb.27.1385979777791; Mon, 02 Dec 2013 02:22:57 -0800 (PST) Received: from [192.168.1.65] ([64.56.250.4]) by mx.google.com with ESMTPSA id l7sm65977313igx.2.2013.12.02.02.22.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 02:22:57 -0800 (PST) Message-ID: <529C5F80.2000809@gmail.com> Date: Mon, 02 Dec 2013 05:22:56 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "ancp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ANCP] CAC vs. Admission Control in draft-ietf-ancp-mc-extensions X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 10:23:01 -0000 To clear up a misunderstanding that led to an AD comment, I propose to add the following definitions to the terminology section of the document: Within this document, the term "conditional access control (CAC)" refers to a procedure wherein a decision is made to allow or disallow a subscriber request for a new media flow based on the subscriber profile. "Admission control" is a separate procedure wherein the admission decision is based on the availability of bandwidth to serve the request. Both procedures are applied to make the final decision. The NAS controls which procedures are performed at the Access Node and which by itself based on the capabilities both devices support and the provisioning information it sends to the Access Node. Based on these definitions, some of the protocol elements in the document are misnamed. So far I have identified three cases: -- Multicast Admission Control Message (which is sent from the AN to the NAS for grey-listed flows, hence is for CAC to start with) -- White-List-CAC and MRepCtl-CAC TLVs, which are actually controlling whether the AN does admission control Would it be OK to rename these, given that it doesn't affect the bits on the wire? Of course, the first question is whether the proposed definitions are acceptable. Tom Taylor From Ted.Lemon@nominum.com Mon Dec 2 07:16:36 2013 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2EB1AE057 for ; Mon, 2 Dec 2013 07:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 YdUVGVatAvnQ for ; Mon, 2 Dec 2013 07:16:35 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 950B51A1F56 for ; Mon, 2 Dec 2013 07:16:07 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUpykNdUBWA05gWor5v5OiHMLwpy2Le1X@postini.com; Mon, 02 Dec 2013 07:16:05 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4FEA21B82D0 for ; Mon, 2 Dec 2013 07:16:05 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2B778190043; Mon, 2 Dec 2013 07:16:05 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 07:16:05 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <6EE0FD67-10BB-480C-941A-2C7986A91314@cisco.com> Date: Mon, 2 Dec 2013 10:15:59 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <8FB5A82B-9938-4D66-BE24-BD0E8EAC73E0@nominum.com> References: <529BA104.2050500@gmail.com> <6EE0FD67-10BB-480C-941A-2C7986A91314@cisco.com> To: "Francois Le Faucheur (flefauch)" X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: "ancp@ietf.org" Subject: Re: [ANCP] Privacy issue in draft-ietf-ancp-mc-extensions-12 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 15:16:36 -0000 I think that I've failed to adequately communicate the concern I have = about this. It might help for folks to review = http://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy= -00, particularly section 3.1 (but you should probably read up to that = so that you get the context). I am assuming here that the device whose MAC address is being identified = is some end-user device, not the home gateway. On an IPv4 network, or = an IPv6 network for devices that use stable privacy addresses = (http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-15), = there is no ability to correlate activities based on the MAC address of = the host. So using the MAC address as an identifier for access control = goes against the current trend in the IETF of avoiding using global, = fixed identifiers like the MAC address in this way. If there is a need for an identifier to be used for access control, it = should be an identifier specific to the context, which will not be used = in other contexts. So it shouldn't be the MAC address. From tom.taylor.stds@gmail.com Tue Dec 3 11:31:24 2013 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1B61AC404 for ; Tue, 3 Dec 2013 11:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 CzlmjE_ibZfj for ; Tue, 3 Dec 2013 11:31:22 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6A21AE1A0 for ; Tue, 3 Dec 2013 11:31:22 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id qd12so24734659ieb.31 for ; Tue, 03 Dec 2013 11:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QsS8WphMfrnxPLaLfOQze9Y5+KhK8WNxMBw/8tuamRw=; b=HftpEaPaYoFrdDaO9yph5Gup3bs0vyUUEprvxtZVCxihcoKEKjaV7BWcgnSKgZ3O8x 37bJsl6svgG5DpxJfnw46MrwpIH8LiR2ZPsHjfpTpV4W5/9VFt2hOLDJie29C71cLglA mUA3UMe4pk/GiX6eGOMAu5n7sOWWcVxWRLbRqcpsEc78bd1A/f7bK9Y52yKgAhhHFhzv Jbj63caovdRBHLNszoqgzdTZwbTAVCC9dSjhdwfNimC9WPWi8f3QmOJqkUZTcqBKzrBQ T0EPCh/kuuzZ4yMmhQ+yqFXNCyUSEEKhvJEcPYe/Ao6BsGR92whWPXMiktEBnrM6qouT L0zQ== X-Received: by 10.42.47.201 with SMTP id p9mr47456652icf.4.1386099079366; Tue, 03 Dec 2013 11:31:19 -0800 (PST) Received: from [192.168.1.65] ([64.56.250.4]) by mx.google.com with ESMTPSA id p14sm4620637igr.7.2013.12.03.11.31.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 11:31:18 -0800 (PST) Message-ID: <529E3183.8010602@gmail.com> Date: Tue, 03 Dec 2013 14:31:15 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ted Lemon , "Francois Le Faucheur (flefauch)" References: <529BA104.2050500@gmail.com> <6EE0FD67-10BB-480C-941A-2C7986A91314@cisco.com> <8FB5A82B-9938-4D66-BE24-BD0E8EAC73E0@nominum.com> In-Reply-To: <8FB5A82B-9938-4D66-BE24-BD0E8EAC73E0@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ancp@ietf.org" Subject: Re: [ANCP] Privacy issue in draft-ietf-ancp-mc-extensions-12 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 19:31:24 -0000 On 02/12/2013 10:15 AM, Ted Lemon wrote: > I think that I've failed to adequately communicate the concern I have > about this. It might help for folks to review > http://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy-00, > particularly section 3.1 (but you should probably read up to that so > that you get the context). > > I am assuming here that the device whose MAC address is being > identified is some end-user device, not the home gateway. On an > IPv4 network, or an IPv6 network for devices that use stable privacy > addresses > (http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-15), > there is no ability to correlate activities based on the MAC address > of the host. So using the MAC address as an identifier for access > control goes against the current trend in the IETF of avoiding using > global, fixed identifiers like the MAC address in this way. > > If there is a need for an identifier to be used for access control, > it should be an identifier specific to the context, which will not be > used in other contexts. So it shouldn't be the MAC address. > > [PTT] Point about MAC address privacy accepted. Thinking over the IP address alternative, I can see practical problems -- since the device is in the home network, the provider has no control over the stability of the address (if IPv6), and can't determine the device from the address (if IPv4 with the usual NAT at the home gateway). My proposed technical solution would be to require the AN to create a context-specific device identifier by hashing the MAC address with something stable at the AN, with the result predictable so that the subscriber AAA profile can be set up as required. The use cases I could see for this are not essential but possible: -- provider-enforced parental controls on selected devices -- provider-enforced device-specific limitations (e.g., mobile vs. fixed) Have to admit the second case at least seems very weak. Tom Taylor From flefauch@cisco.com Wed Dec 4 07:49:42 2013 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8A11AE2B5 for ; Wed, 4 Dec 2013 07:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 L_p2VouRyAdW for ; Wed, 4 Dec 2013 07:49:40 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6A20C1AE2B3 for ; Wed, 4 Dec 2013 07:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2891; q=dns/txt; s=iport; t=1386172176; x=1387381776; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9uccq03WkYJ+4OdHtcysPzIrrPKE4mIVwF97FhUTMDk=; b=B1FK23WBVYfStb6OKrt6PnWxucrBKqWmZtPVheoY0kEVbCziKmcakqd+ JQE/Oc09RdkpHRRcc8S3JSp5NmDCu6dexwQ4ewupugbKx3jXjvGRGt9b5 UpSSYnOf3/YJtVMBfxNVkcj04y4C5kW3PWSD1v2EDg5Rnt6e+IlVBlJvV U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALVNn1KtJV2d/2dsb2JhbABagwc4U7hmgSMWdIIlAQEBAwEBAQE3NAsFCwIBCDYQIQYLJQIEDgWHcAMJBg26Qg2HExMEjG2BXjMHgyCBEwOWKYFrjFqFOYMpgio X-IronPort-AV: E=Sophos;i="4.93,825,1378857600"; d="scan'208";a="4279994" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 04 Dec 2013 15:49:36 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rB4FnbGe014071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 15:49:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 09:49:36 -0600 From: "Francois Le Faucheur (flefauch)" To: Tom Taylor Thread-Topic: [ANCP] CAC vs. Admission Control in draft-ietf-ancp-mc-extensions Thread-Index: AQHO70iBrme9cj45Q02spBfRECT50ppEluEA Date: Wed, 4 Dec 2013 15:49:36 +0000 Message-ID: <9156506C-A97E-47B1-9ACC-A5A06BB556A7@cisco.com> References: <529C5F80.2000809@gmail.com> In-Reply-To: <529C5F80.2000809@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.199] Content-Type: text/plain; charset="us-ascii" Content-ID: <0518E5FBB80379439C727C78CF9CBD33@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ancp@ietf.org" Subject: Re: [ANCP] CAC vs. Admission Control in draft-ietf-ancp-mc-extensions X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:49:42 -0000 Hello Tom, I think it is a good idea to provide a definition for the two concepts (pol= icy-based admission vs resource-based admission). With respect to the actual names for the two concepts, I am very uncomforta= ble in using a name that abreviates to "CAC" for the policy-based admission= control because "CAC" (abbreviation of "Connection Admission Control") ha= s been extensively used in the industry for many years and generally implie= d either (i) resource-based admission or (ii) a combination of policy-based= admission and resource-based admission (and never just policy-based admiss= ion). My preference would be to just always use non-abbreviated terms. I'd probab= ly go with "policy-based admission" and "resource-based admission", but can= go with some variations of these such as "policy-based admission control" = and "resource-based admission control (or "bandwidth-based admission contro= l"). I had trouble parsing the last sentence of the definition. I'd suggest=20 s/The NAS controls which procedures are performed at the Access Node and wh= ich by itself/The NAS controls which procedures are performed by the Access= Node and which are performed by itself/ HTH Francois On 2 Dec 2013, at 11:22, Tom Taylor wrote: > To clear up a misunderstanding that led to an AD comment, I propose to ad= d the following definitions to the terminology section of the document: >=20 > >=20 > Within this document, the term "conditional access control (CAC)" refers = to a procedure wherein a decision is made to allow or disallow a subscriber= request for a new media flow based on the subscriber profile. "Admission c= ontrol" is a separate procedure wherein the admission decision is based on = the availability of bandwidth to serve the request. Both procedures are app= lied to make the final decision. The NAS controls which procedures are perf= ormed at the Access Node and which by itself based on the capabilities both= devices support and the provisioning information it sends to the Access No= de. >=20 > >=20 > Based on these definitions, some of the protocol elements in the document= are misnamed. So far I have identified three cases: >=20 > -- Multicast Admission Control Message (which is sent from the > AN to the NAS for grey-listed flows, hence is for CAC to start > with) >=20 > -- White-List-CAC and MRepCtl-CAC TLVs, which are actually > controlling whether the AN does admission control >=20 > Would it be OK to rename these, given that it doesn't affect the bits on = the wire? >=20 > Of course, the first question is whether the proposed definitions are acc= eptable. >=20 > Tom Taylor > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From tom.taylor.stds@gmail.com Wed Dec 4 13:40:38 2013 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B81A1ADF2E for ; Wed, 4 Dec 2013 13:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 RgUhm57pMXiw for ; Wed, 4 Dec 2013 13:40:36 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 24F971ACC81 for ; Wed, 4 Dec 2013 13:40:35 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id e14so28418021iej.0 for ; Wed, 04 Dec 2013 13:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=m4CIDF5FsGVQdJNild1PbH5/axKbdjGrJEaTY4AkUeQ=; b=lTT2EqDg467vDNy0v7Psj4ea2831yyZR43j5e75nhwRf4AQOvQNjgw0980zBZb9qxy 33k8MjUSp/0n4lBKV4+dOYGMKil0ApfcCtu09itOOeE35qySNAaBtN3bvqgcNQH9vHRT 301xjo2SmEwI71+Ejz1+Obe3flXGsoBMcITTj31iBhGPpgFmDxyhaXjocf3H37a8yK2l hPXoFgpMICLYArnvRMf/ZBeTSgNbk2Jm7CA4w6roApX7FhSahSUhXBDf/Qr/b/JG7EAT wFao+ll2n+FwhVKoFuQG3DW5CxeAhbQ6KlwWcQxngaSjVtrOeKdkwm/26wlO5PAQkF02 Crkw== X-Received: by 10.50.87.36 with SMTP id u4mr3019325igz.40.1386193232794; Wed, 04 Dec 2013 13:40:32 -0800 (PST) Received: from [192.168.1.65] ([64.56.250.4]) by mx.google.com with ESMTPSA id da14sm6485026igc.1.2013.12.04.13.40.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 13:40:32 -0800 (PST) Message-ID: <529FA14C.1090305@gmail.com> Date: Wed, 04 Dec 2013 16:40:28 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Francois Le Faucheur (flefauch)" References: <529C5F80.2000809@gmail.com> <9156506C-A97E-47B1-9ACC-A5A06BB556A7@cisco.com> In-Reply-To: <9156506C-A97E-47B1-9ACC-A5A06BB556A7@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ancp@ietf.org" Subject: Re: [ANCP] CAC vs. Admission Control in draft-ietf-ancp-mc-extensions X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 21:40:38 -0000 Sounds good to me. I won't bother changing TLV or command names, since the current ones work if I adopt your suggested terminology. Aside from the MAC privacy issue, I think this takes care of any open questions I had. I'll update the draft. One possibility for the device identifier is to specify it as such in the TLV, leaving it up to the operator to configure a local mapping on the AN between MAC address and device identifier. Tom On 04/12/2013 10:49 AM, Francois Le Faucheur (flefauch) wrote: > Hello Tom, > > I think it is a good idea to provide a definition for the two concepts (policy-based admission vs resource-based admission). > > With respect to the actual names for the two concepts, I am very uncomfortable in using a name that abreviates to "CAC" for the policy-based admission control because "CAC" (abbreviation of "Connection Admission Control") has been extensively used in the industry for many years and generally implied either (i) resource-based admission or (ii) a combination of policy-based admission and resource-based admission (and never just policy-based admission). > > My preference would be to just always use non-abbreviated terms. I'd probably go with "policy-based admission" and "resource-based admission", but can go with some variations of these such as "policy-based admission control" and "resource-based admission control (or "bandwidth-based admission control"). > > > I had trouble parsing the last sentence of the definition. I'd suggest > s/The NAS controls which procedures are performed at the Access Node and which by itself/The NAS controls which procedures are performed by the Access Node and which are performed by itself/ > > HTH > > Francois > > > On 2 Dec 2013, at 11:22, Tom Taylor wrote: > >> To clear up a misunderstanding that led to an AD comment, I propose to add the following definitions to the terminology section of the document: >> >> >> >> Within this document, the term "conditional access control (CAC)" refers to a procedure wherein a decision is made to allow or disallow a subscriber request for a new media flow based on the subscriber profile. "Admission control" is a separate procedure wherein the admission decision is based on the availability of bandwidth to serve the request. Both procedures are applied to make the final decision. The NAS controls which procedures are performed at the Access Node and which by itself based on the capabilities both devices support and the provisioning information it sends to the Access Node. >> >> >> >> Based on these definitions, some of the protocol elements in the document are misnamed. So far I have identified three cases: >> >> -- Multicast Admission Control Message (which is sent from the >> AN to the NAS for grey-listed flows, hence is for CAC to start >> with) >> >> -- White-List-CAC and MRepCtl-CAC TLVs, which are actually >> controlling whether the AN does admission control >> >> Would it be OK to rename these, given that it doesn't affect the bits on the wire? >> >> Of course, the first question is whether the proposed definitions are acceptable. >> >> Tom Taylor >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www.ietf.org/mailman/listinfo/ancp > > From robmgl.ietf@gmail.com Thu Dec 5 06:57:00 2013 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7CE1ADF30 for ; Thu, 5 Dec 2013 06:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 Nqe3PaK61rZc for ; Thu, 5 Dec 2013 06:56:58 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 955A41AC863 for ; Thu, 5 Dec 2013 06:56:57 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id n7so10174231lam.7 for ; Thu, 05 Dec 2013 06:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=90s/zwl0h5OVMuIEmUBDyT+/efIcCt9ArLTiE7TMHx8=; b=Ed50OqkvslTY7cY/8adsd5Y9TB9mNJ1WiA9RucQlLUzVFpyiwneVFx9OiVHgyn0i/a dOr3dAuZD/Nukb1bAtRWJTA32ts0WmhlxsPl1pBfkAF0yiKlqSifIcMGhFU6+Djx7bje +Nb4luJ3ysH2nXrYINwkf1csCpr8QhIvXFaSxNOsLQ3TpA7oT/3RCPChhr3zgF7CD1ia 3Y3nWOt+/AMd+GxPi43gW/UG0+yZE+DLs+WqzPM0xeWK+31Yj+iURDDY15dsTAPAJEKk 37OpqdIIukgekIS5vNQHWJhaf9UGC0dO7pR5rleqgm9jzWCfzUI+oPlWDgH2dNWUJGj+ M2AA== MIME-Version: 1.0 X-Received: by 10.152.143.101 with SMTP id sd5mr7511696lab.26.1386255413513; Thu, 05 Dec 2013 06:56:53 -0800 (PST) Received: by 10.112.143.8 with HTTP; Thu, 5 Dec 2013 06:56:53 -0800 (PST) In-Reply-To: <529E3183.8010602@gmail.com> References: <529BA104.2050500@gmail.com> <6EE0FD67-10BB-480C-941A-2C7986A91314@cisco.com> <8FB5A82B-9938-4D66-BE24-BD0E8EAC73E0@nominum.com> <529E3183.8010602@gmail.com> Date: Thu, 5 Dec 2013 09:56:53 -0500 Message-ID: From: Roberta Maglione To: Tom Taylor , roberta.maglione@telecomitalia.it Content-Type: multipart/alternative; boundary=001a113458547d918104eccabde1 Cc: "ancp@ietf.org" Subject: Re: [ANCP] Privacy issue in draft-ietf-ancp-mc-extensions-12 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:57:01 -0000 --001a113458547d918104eccabde1 Content-Type: text/plain; charset=ISO-8859-1 Hello, I understand the privacy concerns related to MAC address you mentioned. However in some DSL Broadband environments the source MAC address (taken from the DHCPv4 discover message sent by the DHCP client) has been used as one of the identifiers to trigger the authorization (through AAA/RADIUS Server) for a new subscriber session. For more details please see requirements R-43 and R-44 from BBF TR-146. In my opinion using the source MAC address for conditional access purposes seems in-line with this approach, so I would prefer to keep a link with the MAC address (or the device id) in the ANCP message, mitigating the privacy issues either by using an optional hashing/mapping function as you suggested or by adding some clarifications notes as proposed by Francois. Thanks Roberta On Tue, Dec 3, 2013 at 2:31 PM, Tom Taylor wrote: > On 02/12/2013 10:15 AM, Ted Lemon wrote: > >> I think that I've failed to adequately communicate the concern I have >> about this. It might help for folks to review >> http://tools.ietf.org/html/draft-ietf-6man-ipv6-address- >> generation-privacy-00, >> particularly section 3.1 (but you should probably read up to that so >> that you get the context). >> >> I am assuming here that the device whose MAC address is being >> identified is some end-user device, not the home gateway. On an >> IPv4 network, or an IPv6 network for devices that use stable privacy >> addresses >> (http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-15), >> there is no ability to correlate activities based on the MAC address >> of the host. So using the MAC address as an identifier for access >> control goes against the current trend in the IETF of avoiding using >> global, fixed identifiers like the MAC address in this way. >> >> If there is a need for an identifier to be used for access control, >> it should be an identifier specific to the context, which will not be >> used in other contexts. So it shouldn't be the MAC address. >> >> >> [PTT] Point about MAC address privacy accepted. Thinking over the IP > address alternative, I can see practical problems -- since the device is in > the home network, the provider has no control over the stability of the > address (if IPv6), and can't determine the device from the address (if IPv4 > with the usual NAT at the home gateway). My proposed technical solution > would be to require the AN to create a context-specific device identifier > by hashing the MAC address with something stable at the AN, with the result > predictable so that the subscriber AAA profile can be set up as required. > > The use cases I could see for this are not essential but possible: > -- provider-enforced parental controls on selected devices > -- provider-enforced device-specific limitations (e.g., mobile vs. fixed) > > Have to admit the second case at least seems very weak. > > Tom Taylor > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > --001a113458547d918104eccabde1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=A0

Hello,

I understand the privacy concerns related to MAC address you mentioned. Howev= er in some DSL Broadband environments the source MAC address (taken from the DHCPv4 discover message sent by the DHCP client) has been used as one of th= e identifiers to trigger the authorization (through AAA/RADIUS Server) for a new subscriber session. For more details please see requirements=A0 R-43 and R-44 from BBF TR-146. =A0

In my opinion using the source MAC =A0address for conditional access purposes seems in-line with this approach, so I would prefer to keep a link with the= MAC address (or the device id) in the ANCP message, mitigating the privacy issu= es either by using an optional hashing/mapping function as you suggested or by adding some clarifications notes as proposed by Francois.

Thanks

Roberta

=A0



On Tue, Dec 3= , 2013 at 2:31 PM, Tom Taylor <tom.taylor.stds@gmail.com> wrote:
On 02/12/2013 10:15 = AM, Ted Lemon wrote:
I think that I've failed to adequately communicate the concern I have about this. =A0 It might help for folks to review
http://tools.ietf.org/html/draft-ie= tf-6man-ipv6-address-generation-privacy-00,
particularly section 3.1 (but you should probably read up to that so
that you get the context).

I am assuming here that the device whose MAC address is being
identified is some end-user device, not the home gateway. =A0 On an
IPv4 network, or an IPv6 network for devices that use stable privacy
addresses
(http://tools.ietf.org/html/draft-ietf-6ma= n-stable-privacy-addresses-15),
there is no ability to correlate activities based on the MAC address
of the host. =A0 So using the MAC address as an identifier for access
control goes against the current trend in the IETF of avoiding using
global, fixed identifiers like the MAC address in this way.

If there is a need for an identifier to be used for access control,
it should be an identifier specific to the context, which will not be
used in other contexts. =A0 So it shouldn't be the MAC address.


[PTT] Point about MAC address privacy accepted. Thinking over the IP addres= s alternative, I can see practical problems -- since the device is in the h= ome network, the provider has no control over the stability of the address = (if IPv6), and can't determine the device from the address (if IPv4 wit= h the usual NAT at the home gateway). My proposed technical solution would = be to require the AN to create a context-specific device identifier by hash= ing the MAC address with something stable at the AN, with the result predic= table so that the subscriber AAA profile can be set up as required.

The use cases I could see for this are not essential but possible:
-- provider-enforced parental controls on selected devices
-- provider-enforced device-specific limitations (e.g., mobile vs. fixed)
Have to admit the second case at least seems very weak.

Tom Taylor

_______________________________________________
ANCP mailing list
ANCP@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ancp

--001a113458547d918104eccabde1-- From Ted.Lemon@nominum.com Thu Dec 5 08:03:10 2013 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CB01AE09E for ; Thu, 5 Dec 2013 08:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 eeN3qFbmJvlf for ; Thu, 5 Dec 2013 08:03:08 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 844591AE07C for ; Thu, 5 Dec 2013 08:03:05 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUqCjtiabaIHvPUawjAnp4AR00s/rBf+e@postini.com; Thu, 05 Dec 2013 08:03:02 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 058361B82E5 for ; Thu, 5 Dec 2013 08:03:02 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D37EA190043; Thu, 5 Dec 2013 08:03:01 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Dec 2013 08:03:01 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: Date: Thu, 5 Dec 2013 11:02:57 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <249E65A6-2248-4E9F-B70D-F2D919B127B5@nominum.com> References: <529BA104.2050500@gmail.com> <6EE0FD67-10BB-480C-941A-2C7986A91314@cisco.com> <8FB5A82B-9938-4D66-BE24-BD0E8EAC73E0@nominum.com> <529E3183.8010602@gmail.com> To: Roberta Maglione X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: roberta.maglione@telecomitalia.it, "ancp@ietf.org" Subject: Re: [ANCP] Privacy issue in draft-ietf-ancp-mc-extensions-12 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:03:10 -0000 On Dec 5, 2013, at 9:56 AM, Roberta Maglione = wrote: > In my opinion using the source MAC address for conditional access = purposes seems in-line with this approach, so I would prefer to keep a = link with the MAC address (or the device id) in the ANCP message, = mitigating the privacy issues either by using an optional = hashing/mapping function as you suggested or by adding some = clarifications notes as proposed by Francois. Roberta, I understand where you are coming from. However, the way = these things go is that you do something expedient at time T, which = seems harmless. Then at time T+N, you learn that there are negative = consequences to doing that thing. There is never any time T+M, where = M>N, at which the cost of implementing a better solution is lower than = it is at time T+N. So either you fix the problem once you've = discovered it, or you don't fix the problem. So I'm asking you, now that we understand the problem, to fix it. I = would also encourage you to work within the BBF to get the next version = of TR-146 to switch over to using the same identifier we are proposing = to use here. I think this is a better approach in the long run than = doing nothing, although I fully understand that it is not without cost. From tom.taylor.stds@gmail.com Thu Dec 5 08:39:50 2013 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA701AE0EB for ; Thu, 5 Dec 2013 08:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 7HBn1odLGbge for ; Thu, 5 Dec 2013 08:39:48 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1421AE0E7 for ; Thu, 5 Dec 2013 08:39:48 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so29729861iec.41 for ; Thu, 05 Dec 2013 08:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3Jc/DtE+WxEV17j5DlrGJYB/VVSGXAAS8fPw4a+ZtvU=; b=wESFtwHfNsvAiQpUKgrLSem0ntQ03FGNovVihhkbsJ7plcx4FNA4olu6pErtazgEJx PhJnsFhKaEbWutvX4HzE758UnSfkKImlDQfRUaVeodwHO4UqmkwokMW1SsoPOYyL0e+R uPV1+H3h+dEpfPwpV0CyHlIz21kUA89WMoUhcGTg6gFDF7z1LZolnUzLx9Gba+f1oycu 16C88z/ZK3cK/QfxUWlt9/iNoqcx3WW+6T1o8s29e1qLQrV0dnyNSmw79SE15m52ihRp uspz893cs/OWPZupatkXXrVwCpnLI/5dv2gL7jD1tGbKg8bw7qtsUTjsWJ37CYSDYrib +ztw== X-Received: by 10.50.129.39 with SMTP id nt7mr7227403igb.13.1386261584978; Thu, 05 Dec 2013 08:39:44 -0800 (PST) Received: from [192.168.1.65] ([64.56.250.4]) by mx.google.com with ESMTPSA id w4sm4443221igb.5.2013.12.05.08.39.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Dec 2013 08:39:44 -0800 (PST) Message-ID: <52A0AC4C.1090906@gmail.com> Date: Thu, 05 Dec 2013 11:39:40 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ted Lemon , Roberta Maglione References: <529BA104.2050500@gmail.com> <6EE0FD67-10BB-480C-941A-2C7986A91314@cisco.com> <8FB5A82B-9938-4D66-BE24-BD0E8EAC73E0@nominum.com> <529E3183.8010602@gmail.com> <249E65A6-2248-4E9F-B70D-F2D919B127B5@nominum.com> In-Reply-To: <249E65A6-2248-4E9F-B70D-F2D919B127B5@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roberta.maglione@telecomitalia.it, "ancp@ietf.org" Subject: Re: [ANCP] Privacy issue in draft-ietf-ancp-mc-extensions-12 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:39:50 -0000 I propose to say in the main section that implementations MUST provide a mapping capability, either table-based or algorithmic, to map between device MAC and device identifier. Rather than separate requesting address and requesting MAC TLVs, define a single requesting device identifier TLV. Then in the Security Considerations section I can say that operators SHOULD deploy that mapping capability in the interest of privacy and untrackability. Tom On 05/12/2013 11:02 AM, Ted Lemon wrote: > On Dec 5, 2013, at 9:56 AM, Roberta Maglione wrote: >> In my opinion using the source MAC address for conditional access purposes seems in-line with this approach, so I would prefer to keep a link with the MAC address (or the device id) in the ANCP message, mitigating the privacy issues either by using an optional hashing/mapping function as you suggested or by adding some clarifications notes as proposed by Francois. > > Roberta, I understand where you are coming from. However, the way these things go is that you do something expedient at time T, which seems harmless. Then at time T+N, you learn that there are negative consequences to doing that thing. There is never any time T+M, where M>N, at which the cost of implementing a better solution is lower than it is at time T+N. So either you fix the problem once you've discovered it, or you don't fix the problem. > > So I'm asking you, now that we understand the problem, to fix it. I would also encourage you to work within the BBF to get the next version of TR-146 to switch over to using the same identifier we are proposing to use here. I think this is a better approach in the long run than doing nothing, although I fully understand that it is not without cost. > > From robmgl.ietf@gmail.com Thu Dec 5 08:41:49 2013 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3873D1AE0E2 for ; Thu, 5 Dec 2013 08:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 YAq_OtGc7VqU for ; Thu, 5 Dec 2013 08:41:44 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7A79A1AE0E1 for ; Thu, 5 Dec 2013 08:41:44 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id z5so10287936lbh.31 for ; Thu, 05 Dec 2013 08:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=stdZcAD1cf30Dse6InQNlhov26emF+ypUypWLlVztcs=; b=uc6W6CjeA5yOKkL3+Nv+x3JkYoI8bGgZsznzJylyZpp2Ro92BTXIhr7bdNaWsHOUo3 b9hGE6CYz/fLiJu/8y85dtjKMPTz2STBUsywCz2WCv16lkMfXhtvSYPVcJOYNjVcD5PX 7oKCErPtjoMcjyQSVl3TFE1QnCH/9BcXrbIzdRx4FsJ/eJaDFa+98leE6Qvf3fGF684n e0MGaWHPo0CfZtpqAccULj+DvGAvwN41QWX8eRaArAbwi+bJpc1gedd551bR39HDdxCV AC9ytKrt1RaxeKty47VAEQsrFW3rVtcCZNPceGZs0l9szKgO/ptyL/pOjVGxrMTcutHy f8Qw== MIME-Version: 1.0 X-Received: by 10.112.143.163 with SMTP id sf3mr5072705lbb.20.1386261700366; Thu, 05 Dec 2013 08:41:40 -0800 (PST) Received: by 10.112.143.8 with HTTP; Thu, 5 Dec 2013 08:41:40 -0800 (PST) In-Reply-To: <249E65A6-2248-4E9F-B70D-F2D919B127B5@nominum.com> References: <529BA104.2050500@gmail.com> <6EE0FD67-10BB-480C-941A-2C7986A91314@cisco.com> <8FB5A82B-9938-4D66-BE24-BD0E8EAC73E0@nominum.com> <529E3183.8010602@gmail.com> <249E65A6-2248-4E9F-B70D-F2D919B127B5@nominum.com> Date: Thu, 5 Dec 2013 11:41:40 -0500 Message-ID: From: Roberta Maglione To: Ted Lemon Content-Type: multipart/alternative; boundary=089e01227a0c3753a704eccc3430 Cc: "ancp@ietf.org" Subject: Re: [ANCP] Privacy issue in draft-ietf-ancp-mc-extensions-12 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:41:49 -0000 --089e01227a0c3753a704eccc3430 Content-Type: text/plain; charset=ISO-8859-1 Hello Ted, I got your point. Thanks Roberta On Thu, Dec 5, 2013 at 11:02 AM, Ted Lemon wrote: > On Dec 5, 2013, at 9:56 AM, Roberta Maglione > wrote: > > In my opinion using the source MAC address for conditional access > purposes seems in-line with this approach, so I would prefer to keep a link > with the MAC address (or the device id) in the ANCP message, mitigating the > privacy issues either by using an optional hashing/mapping function as you > suggested or by adding some clarifications notes as proposed by Francois. > > Roberta, I understand where you are coming from. However, the way these > things go is that you do something expedient at time T, which seems > harmless. Then at time T+N, you learn that there are negative > consequences to doing that thing. There is never any time T+M, where M>N, > at which the cost of implementing a better solution is lower than it is at > time T+N. So either you fix the problem once you've discovered it, or you > don't fix the problem. > > So I'm asking you, now that we understand the problem, to fix it. I > would also encourage you to work within the BBF to get the next version of > TR-146 to switch over to using the same identifier we are proposing to use > here. I think this is a better approach in the long run than doing > nothing, although I fully understand that it is not without cost. > > --089e01227a0c3753a704eccc3430 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Ted,
I got your point.
T= hanks
Roberta


On Thu, Dec 5, 2013 at 11:02 AM, Ted Lemon &= lt;ted.lemon@nom= inum.com> wrote:
On Dec 5, 2013, at 9:56 AM= , Roberta Maglione <robmgl.ietf= @gmail.com> wrote:
> In my opinion using the source MAC =A0address for conditional access p= urposes seems in-line with this approach, so I would prefer to keep a link = with the MAC address (or the device id) in the ANCP message, mitigating the= privacy issues either by using an optional hashing/mapping function as you= suggested or by adding some clarifications notes as proposed by Francois.<= br>
Roberta, I understand where you are coming from. =A0 However, the way= these things go is that you do something expedient at time T, which seems = harmless. =A0 Then at time T+N, you learn that there are negative consequen= ces to doing that thing. =A0 There is never any time T+M, where M>N, at = which the cost of implementing a better solution is lower than it is at tim= e T+N. =A0 So either you fix the problem once you've discovered it, or = you don't fix the problem.

So I'm asking you, now that we understand the problem, to fix it. =A0 I= would also encourage you to work within the BBF to get the next version of= TR-146 to switch over to using the same identifier we are proposing to use= here. =A0 I think this is a better approach in the long run than doing not= hing, although I fully understand that it is not without cost.


--089e01227a0c3753a704eccc3430-- From internet-drafts@ietf.org Tue Dec 10 11:16:27 2013 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3902D1AE17E; Tue, 10 Dec 2013 11:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 WbjY6WlTYYPg; Tue, 10 Dec 2013 11:16:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCD81AE1CE; Tue, 10 Dec 2013 11:16:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131210191624.18823.33574.idtracker@ietfa.amsl.com> Date: Tue, 10 Dec 2013 11:16:24 -0800 Cc: ancp@ietf.org Subject: [ANCP] I-D Action: draft-ietf-ancp-mc-extensions-13.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 19:16:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Access Node Control Protocol Working Grou= p of the IETF. Title : Multicast Control Extensions for ANCP Author(s) : Francois Le Faucheur Roberta Maglione Tom Taylor Filename : draft-ietf-ancp-mc-extensions-13.txt Pages : 89 Date : 2013-12-10 Abstract: This document specifies the extensions to the Access Node Control Protocol required for support of the multicast use cases defined in the Access Node Control Protocol framework document and one additional use case described in this document. These use cases are organized into the following ANCP capabilities: o NAS-initiated multicast replication; o conditional access with white and black lists; o conditional access with grey lists; o bandwidth delegation; o committed bandwidth reporting. These capabilities may be combined according to the rules given in this specification. This document updates RFC 6320 by assigning capability type 3 to a capability specified in this document and by changing the starting point for IANA allocation of result codes determined by IETF Consensus from 0x100 to 0x64. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ancp-mc-extensions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ancp-mc-extensions-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ancp-mc-extensions-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tom.taylor.stds@gmail.com Tue Dec 10 11:18:20 2013 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF861AE171 for ; Tue, 10 Dec 2013 11:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 2WRsObQDup7z for ; Tue, 10 Dec 2013 11:18:17 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0321AE06B for ; Tue, 10 Dec 2013 11:18:17 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id qd12so9451107ieb.3 for ; Tue, 10 Dec 2013 11:18:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=So7SIU0cUgswfLdgobNuJwVzx0oZzMo8eAuWcDaHJ+w=; b=UqWPYahA+A5XMKxqVMt+WQpFroRJHPooGOyOEMRaTV9D3xrqA9zsidDDuXct7i++KK pl48UOZAAKdeN3S7iznIx+A2t12c5G87ENB1hLiCyiZsoyGbM9UPsw5pTzsTC6vaGD90 oa5Elw6BO/h8rmVHb0a22kHMwDNNs9b8vGkzrizi7WKl0wylzOQxsWFjIvqHnC1O8rSl jm7Dt594ZYQBe5jIUG4dsBbvs/jYzZYv9ZbwM6PM8tZOK2nQrXhNo5VJYikAGy/euuq9 e6yP9nXape9SB0KE34ZksCM06k+GZpMpKQ85MEBvm50ebQr/zNYvR3BD0PtgMMXUN7xC hpUw== X-Received: by 10.43.148.69 with SMTP id kf5mr1845845icc.80.1386703092085; Tue, 10 Dec 2013 11:18:12 -0800 (PST) Received: from [192.168.1.65] ([64.56.250.4]) by mx.google.com with ESMTPSA id lp9sm4670959igb.2.2013.12.10.11.18.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 11:18:11 -0800 (PST) Message-ID: <52A768EE.8020409@gmail.com> Date: Tue, 10 Dec 2013 14:18:06 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "ancp@ietf.org" , Ted Lemon , Francois Le Faucheur IMAP , Maglione Roberta Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ANCP] New version draft-ietf-ancp-mc-extensions-13.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 19:18:20 -0000 I have created a new version of the multicast extensions draft responding to Ted's AD review comments. The changes are as follows: SUBSTANTIVE Section 4: Added a general provision that elements of any message that are not supported by the set of negotiated capabilities are ignored. Dropped the paragraph in Section 6 that said the opposite, that they would cause an error to be generated. Section 4.2.2, second paragraph: Previously read that if a new bandwidth allocation is less than already committed bandwidth for that access line at the AN, flows SHOULD NOT be deleted to bring the bandwidth down to the new limit. Added the qualification "unless otherwise directed by local policy". Issue: this is not consistent with the MUST NOT for a similar condition at the end of Section 4.6.2.2. RFC 5851 places responsibility for avoiding such a situation on the NAS rather than the AN (second last paragraph of Section 3.4.2.1. Section 4.4: Deleted the recommendation that the receiver of the error message should attempt to correct the error, if possible, for new Result Code values 0x64 and 0x65. Also in Section 4.4: Replaced the Request-Source-IP and Request-Source-MAC optional TLVs with a new generic Subs-Session-Id TLV described by the following text: "A Subs-Session-ID TLV as defined in Section 5.9 MAY be appended to the Command TLV as an additional embedded TLV. The need or this TLV depends on what type of subscriber session identifier the operator is using to retrieve the subscriber profile information from AAA. Some of the types identified by [TR-146] requirement R43 are covered by the contents of the Target TLV." Section 4.4.1: Deleted text relating to Request-Source-IP and Request-Source-MAC and replaced it with: "Depending on local configuration, the Subs-Session-Identifier embedded TLV MAY be included by the AN. The content of this TLV depends on local practice." Section 5.9: Replaces old sections 5.9 and 5.10 describing the Request-Source-IP and Request-Source-MAC TLVs, with a new section describing the Subs-Session-Id TLV. The description is: "The Subs-Session-Id TLV provides a subscriber session identifier for the entity that originated a specific request to join or leave a multicast channel. The subscriber session identifier is a value derived according to local policy from one of the types specified in [TR-146] requirement R43." Section 6.1.4, Table 4: Replaced Request-Source-IP and Request-Source-MAC TLVs with Subs-Session-Id TLV. Section 6.2.4.2, end of paragraph 1: Another change relating to Request-Source-IP and Request-Source-MAC. IANA section: Register Subs-Session-Id rather than Request-Source-IP and Request-Source-MAC TLVs. References: deleted [IEEE48] and [IEEE64] and added [TR-164]. EDITORIAL Section 2: Defined the term "conditional access and admission control (CAC)" and introduced the terms "policy-based admission control" and "resource-based admission control" as suggested by Francois. Followed through in the rest of the document. Most changes were to add "resource-based" in front of "admission control". Section 4.2 and sub-sections: Replaced the term "Access Port", used here only, with the generally used term "access line". Section 4.3: made a couple of corrections to the unlabelled figure at the end of the section. -- Propagate Subs-Session-Id to example Figures 23 and 25 (previously 24 and 26). Global: Numerous edits to provide uniform editorial treatment: -- most field values now shown in decimal rather than hex. Key exceptions follow precedent set by RFC 6320: TLV types, the Result field, and Result Codes (but 0 is shown as decimal). Leading zeroes are omitted from Result Codes. -- adopted convention of "Text definition", (numerical value) for values in enumerations. e.g., "Add" (1) for a Command Code value. -- TLV types shown in figures as "TLV Type = name code", with truncation as necessary starting on the left, depending on the name length. -- Various other clarifications and typo corrections. From Ted.Lemon@nominum.com Tue Dec 10 11:28:14 2013 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EE71AE17A for ; Tue, 10 Dec 2013 11:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 IMYpdt7Knj2P for ; Tue, 10 Dec 2013 11:28:13 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5251ADFAA for ; Tue, 10 Dec 2013 11:28:13 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUqdrR6CAhysKvfoquFmgOYpo0o6UYHaR@postini.com; Tue, 10 Dec 2013 11:28:08 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AD0281B82D0 for ; Tue, 10 Dec 2013 11:28:07 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id A5E43190043; Tue, 10 Dec 2013 11:28:07 -0800 (PST) Received: from vpna-132.vpn.nominum.com (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 11:28:07 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <52A768EE.8020409@gmail.com> Date: Tue, 10 Dec 2013 14:28:03 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <073B6089-3C3A-479D-AF7F-5C1A2DA5028F@nominum.com> References: <52A768EE.8020409@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: Maglione Roberta , "ancp@ietf.org" Subject: Re: [ANCP] New version draft-ietf-ancp-mc-extensions-13.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 19:28:14 -0000 On Dec 10, 2013, at 2:18 PM, Tom Taylor = wrote: > "A Subs-Session-ID TLV as defined in Section 5.9 MAY be appended to = the Command TLV as an additional embedded TLV. The need or this TLV = depends on what type of subscriber session identifier the operator is = using to retrieve the subscriber profile information from AAA. Some of = the types identified by [TR-146] requirement R43 are covered by the = contents of the Target TLV." This is kind of the opposite of what I thought we'd agreed to, since = TR-146 actually recommends using the MAC address, source IP address or = DUID.