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]=20
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 co=
mments were written primarily for the benefit of the security area director=
s. 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 compl=
ete set of relevant leases.

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

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

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

</Pavan>

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

<Pavan> Actually, a query by remote ID will reduce such instances of filter=
ing out a legitimate client when compared to earlier query types. Since we =
obtain the consolidated lease information, filtering out a legitimate clien=
t is less likely. Whereas, in a query by IP or MAC, until the query for spe=
cific 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 rat=
her 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