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

From: [email-masked]
Date: Tue, 9 Nov 2004 10:15:19 -0800 (GMT-08:00)

> On Nov 9, 2004, at 10:17 AM, Stig Venaas wrote:
> >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.
> 
> 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.   :')

The amount of damage that can be done in 1 day or even 1 hour is great. Not sure a TTL is really the device to protect against a DoS attack. However, I think there are other reasons for keeping the max time smaller and those can be used to argue for lower values but ulimately the admin controls the setting.

--rich

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

---

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

On Nov 9, 2004, at 1:15 PM, [email-masked] wrote:
> The amount of damage that can be done in 1 day or even 1 hour is 
> great. Not sure a TTL is really the device
> to protect against a DoS attack

What you say is true, but not compelling.   I would rather that 
something that can be accomplished with ten minutes' access to the 
network not last indefinitely - it's better for a machine to be offline 
for a day than for an unbounded period of time.

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 9 Nov 2004 17:34:09 -0500

I'm not convinced we need to restrict the upper bound of the value.

Today, without this option, there is no value. So, it is up to the client to
decide when it will refresh this information.

With the introduction of the lifetime option, I still think it is up to
clients to decide what values they'll accept and when they'll refresh. Just
because a "server" tells you to use 1 year or infinity, would you really
honor that request? Would you really save this information across reboots?
(You might save it, but I think you'd want to refresh it and only use the
saved information if you didn't get any new.)

Note that the draft says:

   When the client detects that the refresh time has expired, it SHOULD
   try to update its configuration data by sending an Information-
   Request as specified in section 18.1.5 of [RFC 3315], except that the
   client MUST delay sending the first Information-Request by a random
   amount of time between 0 and INF_MAX_DELAY.

So, the value is just *another* trigger, not the only trigger. There is NO
language that says a client is prohibited from refreshing this information
sooner.

So, while we COULD have an upper bound, I don't see that this is that
critical.

I do agree that the security section should point out that the client may
not want to honor very long values. And, it already has something about
this: "or with a large or infinite value which would be no worse than a
client that does not make use of this option."

Note that the opposite argument for not needing a lower bound could also be
made, but I think there's much more value in that since we don't want it
easy to cause a DoS attack because based on the above language, a client
WOULD refresh its information.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ted Lemon
> Sent: Tuesday, November 09, 2004 2:06 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [dhcwg] Lifetime draft: refresh time should 
> never be more thanIRT_DEFAULT
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Nov 2004 17:58:05 -0500

> decide when it will refresh this information.

Right.   That's why we need this draft.   The protocol is slightly 
broken without this draft.

> clients to decide what values they'll accept and when they'll refresh.

Right.   And I am suggesting that we give client implementations a 
recommendation as to what the maximum value for this trigger is that 
they should use.   Actually, I guess I'm suggesting that we give the 
clients a requirement, but I'd be okay with making it a recommendation, 
like "clients SHOULD use a value of 1 day if the value is greater than 
one day."

> So, while we COULD have an upper bound, I don't see that this is that

I didn't say it was critical.   However, I think it is useful.

> WOULD refresh its information.

A lower value doesn't help you to do a DoS attack, because there is no 
amplification (well, unless your client is broken and retransmits 
continuously if it gets a value of zero, but we could fix that by 
setting the minimum value to 1, or 15, and pointing out why it's 
important to enforce this limit).   However, I think it was Ralph who 
pointed out that this is not a good idea, because unlike a DNS TTL 
which simply causes data to be discarded, this causes a packet to be 
transmitted.   So I'm not arguing for a lower minimum value anymore.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 10 Nov 2004 17:32:29 +0100

On Tue, Nov 09, 2004 at 05:34:09PM -0500, Bernie Volz wrote:
[...]
> language that says a client is prohibited from refreshing this information

It also says
   The information refresh time option specifies an upper bound for how
   long a client should wait before refreshing information retrieved
   from DHCPv6.

So I think this should be pretty clear.

> client that does not make use of this option."

Yes, I also see problems with large values, and think some recommendation
like this should be sufficient. I'm a bit concerned with infinity perhaps.
If we don't think large values are good, do we want infinity?

I must say though, that I don't think this option changes much. Currently
you can also easily send clients forged responses listing wrong info, and
there's no telling when client will choose to update it. The triggers a
client currently uses, should still be used to refresh info when using
this option.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 16 Nov 2004 14:24:15 +0100

I'm not sure we should limit the value to 1 day (default). I'm not
sure the security problem is that big, and there might be reasons
for using larger values.

If we make say 1 day a requirement, then practically all stateless
clients, assuming most will implement this option, will refresh
their info daily. I can think of some possible scenarios where this
might be a bad thing. Is it unlikely that you have say a network of
thousands of very simple IPv6 devices, say sensors, that use
stateless DHCP and where things are quite static?

If I want to do an attack forging DHCP responses I would rather
change other options like e.g. DNS server than IRT. A high IRT value
won't do anything wrong in itself unless changes occur. A high value
might be used in conjunction with change of other values though, so
that clients will have wrong info for a longer time. This can be
useful if an attacker cannot forge later responses.

If say DNS doesn't work due to a forged message, then I think it
is likely to be fixed quickly (within 1 day), at least if the host
is in use, and not waiting until IRT expires. There are some attacks
though where the user of the host may be not be aware of anything
being wrong.

So, I think limiting the value to 1 day helps a bit, but it doesn't
really help much and it might have some negative effects too.

If we can make stateless DHCP secure, then the IRT value can be very
high or even infinite with no security risks, and I think there's a
need for that. Perhaps we can recommend that clients don't accept
high values unless reply is authenticated? By leaving it as a
recommendation, specialized devices can choose to something else
without breaking the spec.

Stig

---

From: Joe Quanaim <[email-masked]>
Date: Tue, 16 Nov 2004 10:50:55 -0500

> sure the security problem is that big, and there might be reasons

I agree with this assessment.  I do not think there is enough deployment 
experience in dhcpv6 to say that a client MUST cap the value to 1 day.  The 
draft could contain a recommendation saying that this value may be 
appropriate for some networks.

Also, I am not sure a value of 1 day makes a network any more secure.  A rogue 
dhcpv6 server could do much worse than to set the lifetime option to an 
excessive value.  And if a client does not implement the lifetime option 
(which will probably be true for the near term), it is still vulnerable to 
this attack whatever we decide the maximum value should be.

Joe.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Nov 2004 17:40:45 -0800

On Nov 16, 2004, at 7:50 AM, Joe Quanaim wrote:
> A rogue
> excessive value.

Or it could do both, for a triple word score.   This is my concern - 
clients that don't restrict the length of the lifetime option simply 
never recover from an attack like this, where as clients that do 
restrict it do recover.

> And if a client does not implement the lifetime option

I think such clients are unlikely to be an issue in practice at this 
stage of deployment.

I think that it should be sufficient to say that clients SHOULD 
restrict the lifetime to a day, and explain why, and let the 
implementor decide how to handle it.   Or maybe just say "clients MAY 
limit the lifetime", not specify any particular limit, and explain the 
tradeoffs.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 17 Nov 2004 08:48:25 +0100

On Tue, Nov 16, 2004 at 05:40:45PM -0800, Ted Lemon wrote:
[...]
> limit the lifetime", not specify any particular limit, and explain the 

This sounds good to me. That text should also note the INFINITY value.

I don't think this issue should stop us from going to WGLC then. After-
wards I'll propose new text to resolve this, Jinmei's list of issues
and of course other issues raised in the LC.

Or do you want me to propose something now?

Stig