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

From: Samuel Weiler <[email-masked]>
Date: Wed, 1 Dec 2010 22:29:56 -0500 (EST)

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.

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?  In this model, could a 
relay agent be induced to filter out a legitimate client for want of 
an answer to a DHCPLEASEQUERY?

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

-- Sam

---

From: Pavan Kurapati <[email-masked]>
Date: Thu, 2 Dec 2010 21:33:32 +0530

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

Thanks,
Pavan

-----Original Message-----
From: Samuel Weiler [mailto:[email-masked]] 
Sent: Thursday, December 02, 2010 9:00 AM
To: [email-masked]; [email-masked]; [email-masked]
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.

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