Re: [dhcwg] Lifetime draft: refresh time should never be more thanIRT_DEFAULT

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

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg