Re: I-D Action: draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt

Steven Bellovin <smb@cs.columbia.edu> Tue, 31 July 2012 14:30 UTC

Return-Path: <smb@cs.columbia.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5322621F85C7 for <ietf@ietfa.amsl.com>; Tue, 31 Jul 2012 07:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM1cuchpQJzl for <ietf@ietfa.amsl.com>; Tue, 31 Jul 2012 07:30:13 -0700 (PDT)
Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4994421F85C3 for <ietf@ietf.org>; Tue, 31 Jul 2012 07:30:13 -0700 (PDT)
Received: from [10.9.0.66] (fireball.cs.columbia.edu [128.59.13.10]) (user=smb2132 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q6VEU8wA023699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 Jul 2012 10:30:09 -0400 (EDT)
Subject: Re: I-D Action: draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Steven Bellovin <smb@cs.columbia.edu>
In-Reply-To: <5017BDFE.5020100@gmail.com>
Date: Tue, 31 Jul 2012 07:30:07 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D0D2246-86C9-4561-9EE9-3249DA7BAFF5@cs.columbia.edu>
References: <20120730082620.18701.51607.idtracker@ietfa.amsl.com> <50164E21.2040904@gmail.com> <225158E4-78BC-42BC-8339-EB9E0DE75AA7@sobco.com> <5017B60D.5050101@pi.nu> <5017BDFE.5020100@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1278)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5
Cc: IETF discussion list <ietf@ietf.org>, Scott O Bradner <sob@sobco.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jul 2012 14:30:14 -0000

Also note that RFC 3924 exists.

On Jul 31, 2012, at 4:14 AM, Brian E Carpenter wrote:

> Loa,
> 
> I can't speak for Scott, but I think the problem arises if any
> IANA assignments are needed, regardless of RFC status. That's
> because RFC 2804 speaks of "the process for creating and maintaining
> IETF standards." IANA assignments are part of standards maintenance
> (IMHO, of course).
> 
> Don't forget that 2804 *also* says
> 
> "  - On the other hand, the IETF believes that mechanisms designed to
>     facilitate or enable wiretapping, or methods of using other
>     facilities for such purposes, should be openly described, so as to
>     ensure the maximum review of the mechanisms and ensure that they
>     adhere as closely as possible to their design constraints. The IETF
>     believes that the publication of such mechanisms, and the
>     publication of known weaknesses in such mechanisms, is a Good
>     Thing."
> 
> So it's a delicate balance.
> 
>    Brian
> 
> On 31/07/2012 11:40, Loa Andersson wrote:
>> Scott,
>> 
>> would you say that drafts aimed for experimental status are "standards
>> work".
>> 
>> /Loa
>> 
>> On 2012-07-30 18:33, Scott O Bradner wrote:
>>> 2804 does not say not to talk about such things - or that such
>>> documents should
>>> not be published as RFCs  - 2804 says that the IETF will not do
>>> standards work
>>> in this area
>>> 
>>> Scott
>>> 
>>> On Jul 30, 2012, at 5:04 AM, Brian E Carpenter wrote:
>>> 
>>>> Under the long-standing IETF policy defined in RFC 2804, I trust
>>>> we will not be discussing this draft, or
>>>> draft-balaji-l2vpn-lawful-intercept-thru-label-dis, in the IETF.
>>>> 
>>>> Regards
>>>>   Brian Carpenter
>>>> 
>>>> On 30/07/2012 09:26, internet-drafts@ietf.org wrote:
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>> directories.
>>>>> 
>>>>> 
>>>>>    Title           : Label-based Provider-Provisioned Lawful
>>>>> Intercept for L3 VPNs
>>>>>    Author(s)       : Shankar Raman
>>>>>                          Balaji Venkat Venkataswami
>>>>>                          Gaurav Raina
>>>>>                          Vasan Srini
>>>>>                          Bhargav Bhikkaji
>>>>>    Filename        :
>>>>> draft-balaji-mpls-lawful-intercept-thru-label-dis-00.txt
>>>>>    Pages           : 12
>>>>>    Date            : 2012-07-30
>>>>> 
>>>>> Abstract:
>>>>>   In models of Single-AS and inter-provider Multi- Protocol Label
>>>>>   Switching (MPLS) based Virtual Private Networks (VPNs) Lawful
>>>>>   Intercept is a key requirement. For example, MPLS-based Layer 3 VPN
>>>>>   models like VPLS and the like do not have any provider provisioned
>>>>>   methods of lawful intercept that are comprehensive, quick and
>>>>> easy to
>>>>>   provision from one single point. More particularly the auto-
>>>>>   provisioning of lawful intercept for all sets of streams travelling
>>>>>   between VPN sites and consequent re-direction of these streams to
>>>>> the
>>>>>   appropriate government network has not been covered without multiple
>>>>>   instances of having to configure the intercept at various points in
>>>>>   the network both in the Single-AS case and the Inter-Provider VPN
>>>>>   case.
>>>>> 
>>>>>   this paper, we propose a technique which uses a set of pre-defined
>>>>>   labels called Lawful Intercept labels and a method for provisioning
>>>>>   lawful intercept amongst the various PE devices using these labels
>>>>>   both in the Single-AS and the inter-provider VPN cases. A single
>>>>>   point of configuration is the key to this idea. The intercepted
>>>>>   traffic is mirrored on a PE or a whole set of PEs or on all the PEs
>>>>>   participating in the VPN. A technique called the Domino-effect
>>>>>   provisioning of these Label-based Provider Provisioned Lawful
>>>>>   Intercept mechanism is also outlined.
>>>>> 
>>>>> 
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-balaji-mpls-lawful-intercept-thru-label-dis
>>>>> 
>>>>> 
>>>>> There's also a htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-balaji-mpls-lawful-intercept-thru-label-dis-00
>>>>> 
>>>>> 
>>>>> 
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>> 
>>>>> _______________________________________________
>>>>> I-D-Announce mailing list
>>>>> I-D-Announce@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>> 
>>> 
>> 
> 


		--Steve Bellovin, https://www.cs.columbia.edu/~smb