Re: [secdir] secdir review of draft-ietf-dhc-leasequery-by-remote-id-07

Pavan Kurapati <kurapati@juniper.net> Thu, 02 December 2010 16:03 UTC

Return-Path: <kurapati@juniper.net>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42FFA28C125; Thu, 2 Dec 2010 08:03:20 -0800 (PST)
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRLuA5EKSMdZ; Thu, 2 Dec 2010 08:03:19 -0800 (PST)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id A609128C0CE; Thu, 2 Dec 2010 08:03:14 -0800 (PST)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTPfDjhAiYl5dwY58HBaTrFMvsSlEeqNz@postini.com; Thu, 02 Dec 2010 08:04:35 PST
Received: from p-emfe01-bng.jnpr.net (10.211.204.19) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 2 Dec 2010 08:03:47 -0800
Received: from EMBX02-BNG.jnpr.net ([fe80::8ce3:7a6:9990:3c6e]) by p-emfe01-bng.jnpr.net ([::1]) with mapi; Thu, 2 Dec 2010 21:33:35 +0530
From: Pavan Kurapati <kurapati@juniper.net>
To: Samuel Weiler <weiler@watson.org>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-dhc-leasequery-by-remote-id.all@tools.ietf.org" <draft-ietf-dhc-leasequery-by-remote-id.all@tools.ietf.org>
Date: Thu, 2 Dec 2010 21:33:32 +0530
Thread-Topic: secdir review of draft-ietf-dhc-leasequery-by-remote-id-07
Thread-Index: AcuR0TuaOEFf+oqzTdmHH2RH//pnmAAaP3Mw
Message-ID: <408677E9A8F78149B5DC29F87FBF27A94507290217@EMBX02-BNG.jnpr.net>
References: <alpine.BSF.2.00.1012012218180.54384@fledge.watson.org>
In-Reply-To: <alpine.BSF.2.00.1012012218180.54384@fledge.watson.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Thu, 02 Dec 2010 08:39:39 -0800
Subject: Re: [secdir] secdir review of draft-ietf-dhc-leasequery-by-remote-id-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Dec 2010 16:03:20 -0000

Hi Sam,
Thanks for the review. Please find my comments tagged with "<Pavan>"

Thanks,
Pavan

-----Original Message-----
From: Samuel Weiler [mailto:weiler@watson.org] 
Sent: Thursday, December 02, 2010 9:00 AM
To: secdir@ietf.org; iesg@ietf.org; draft-ietf-dhc-leasequery-by-remote-id.all@tools.ietf.org
Subject: secdir review of draft-ietf-dhc-leasequery-by-remote-id-07

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

Sorry for getting this out so late.

I'm a bit confused by this doc -- in particular, I'm not understanding how the Remote ID field is being set so that querying based on it gives a complete set of relevant leases.

<Pavan> The Remote ID is pre-provisioned in the access concentrator per circuit/connection and hence the same will remain available to the access concentrator after reboot. Since the servers index the lease binding information based on remote ID, it can reply complete set of information based on remote ID field.
</Pavan>

I'm also wondering if the use case envisioned (filtering spoofed source addresses based on the assumption that you can collect a complete list of leases using this method) is dangerous -- at the very least, it suggests that authentication of the queries here is every more important than in 4388. Furthermore, what risks are there if answers to these queries are spoofed away? 

<Pavan> The chance of spoofing has not increased with introducing this query type. In fact, it will be difficult to spoof a remote ID compared to spoofing an IP address.
Like RFC 4388, employing authentication techniques given in RFC 3118 will help preventing such attacks </Pavan>

</Pavan>

In this model, could a relay agent be induced to filter out a legitimate client for want of an answer to a DHCPLEASEQUERY?

<Pavan> Actually, a query by remote ID will reduce such instances of filtering out a legitimate client when compared to earlier query types. Since we obtain the consolidated lease information, filtering out a legitimate client is less likely. Whereas, in a query by IP or MAC, until the query for specific IP is resolved, the relay agent may filter out the packets.
</Pavan>

Also, I'm not a fan of referral Security Considerations sections -- I'd rather see a repeat of the text than a reference.

<Pavan> Yes, Tim Polk had also suggested the same. We will implement it in our next revision

-- Sam