Subject: [dhcwg] Lifetime draft: refresh time should never be more than IRT_DEFAULT

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Nov 2004 08:47:20 -0500

In reading the lifetime draft, I am generally _very_ happy with it.   
However, there is one point that I think is a mistake - allowing the 
time to be set to an unreasonably large value.   In considering this, I 
think it's useful to look at other configuration parameters that IP 
hosts frequently acquire, such as the IP address of a server.   When 
acquiring the IP address of a server, we go to the DNS and do a lookup. 
   It would be extremely unusual for the result that we get back to have 
a TTL that is more than a week, and I think pretty commonly the TTL 
would be more like a day, or even an hour.

DHCPv6 Information Request transactions are like DNS transactions.   
They do not require a database write, so they are relatively 
low-impact.   They can be implemented in routers.   Basically, there 
are ways to make them really, really cheap.   So optimizing the 
protocol with the intention of making them happen really infrequently 
seems like a mistake to me.

I think that the maximum refresh time a client should ever accept is a 
single day.   I can imagine someone arguing for a larger time, such as 
a week, but I think that generally the only reason you'd ever get a 
time that big would be because someone was trying to spoof your client.

Aside from this comment, I think that it's past time to advance this 
draft - it looks very good.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Stig Venaas <[email-masked]>
Date: Tue, 9 Nov 2004 16:17:35 +0100

> time to be set to an unreasonably large value.   In considering this, I 

I understand your concern, but I don't see why it should be disallowed.
The administrator should be able to figure out what's reasonable in
hers/his environment.

To use the DNS ttl analogy, there's nothing stopping you from setting
a needlessly large ttl value either.

As for the minimum time. I think 600 is small enough, but I don't see
any harm in making it smaller if you or others see a potential need.
I think the minimum should be in the order of minutes, but I don' have
a strong opinion on the exact value.

Stig

---

From: Tim Chown <[email-masked]>
Date: Tue, 9 Nov 2004 16:15:46 +0000

> a needlessly large ttl value either.

Right, but the draft can state the issues and leave it for the admin to
make an informed choice.
 
-- 
Tim

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Nov 2004 11:22:47 -0500

> a needlessly large ttl value either.

It's a really phat DoS attack - you send out one bogus message with a 
really long lifetime, and the information will never be refreshed.   I 
would argue that DNS needs to have a limit on TTLs also, but that's not 
my bailiwick.   :')

---

From: Stig Venaas <[email-masked]>
Date: Tue, 9 Nov 2004 17:42:41 +0100

> would argue that DNS needs to have a limit on TTLs also, but that's not 

Which means you don't want infinity either then?

Stig

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Nov 2004 14:03:44 -0500

> Right, but the draft can state the issues and leave it for the admin to

That's not the problem.   The problem is that if we don't specify a 
maximum, a rogue server will be able to give the client bogus 
information and arrange for the client to retain that information until 
the next time the router is rebooted.   This could be quite a useful 
attack.   You can also do this with a DNS query, but I would argue that 
it's harder, because DNS queries are spontaneous, whereas DHCP queries 
are cyclic (particularly if you have, say, a refresh time option... :')

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Nov 2004 14:04:23 -0500

> Which means you don't want infinity either then?

'fraid so.  :'}