Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6

From: Changming Liu <[email-masked]>
Date: Tue, 2 Mar 2004 14:13:56 -0800

This draft comes at the exact time we need it. We just implemeneted DHCP
server and client and one of our big customers run into this reconfig issue
in their planned deployment right away! I wish I would have read it early.

The scenario is different from the two described in section 3. Our customer
runs DHCP clients on two unpstream interfaces and DHCP server on on
downstream interface which connects to a LAN with PCs, etc, The DHCP is used
just to pass configuration info . Depending on the availaibility of upstream
routers which have different DNS server setup among other configs, the DHCP
server needs to update DNS to the LAN immediately to avoid service outage.
Note that these DNS servers are in different zones. This, to my opinion,
should be another major scenario: dynamic change of config info.

In section 5, among three proposed mechanisms, to me, only 1) looks viable.
Multicast support should not be any issue anyway. Is it true that the entire
stateless auto-config and ND are based on that? The only concern may be
security for forged reconfigure message. But this is a more generic issue
than just for reconfigure message itself. Or am I missing something?

The lifetime has several significant drawbacks. The first one is how to
engineer the lifetime value? A difficult choice. if too long it will cause
too long delay, which is unacceptable for service shortage. if too short, it
may cause periodic storms of request/replies. This itself sounds like a
attack to me. The second one is the maintenance effort for both server and
client to maintain these timers as someone pointed out in the meeting. 

The third option looks better, but it won't work between upstream router and
downstream router using DHCPv6 to pass auto-config info. The draft requires
the DHCP relay which may not exist in the scenario I just described.

I guess, actually, the debate, if any,  will boil down to event-driven or
polling? which is better and efficient? Agree?

Changming Liu
Netscreen Technologies Inc.

-----Original Message-----
From: JINMEI Tatuya / ????
To: Tim Chown
Cc: [email-masked]
Sent: 3/1/2004 5:11 PM
Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6

>>>>> On Tue, 10 Feb 2004 13:45:49 +0000, 
>>>>> Tim Chown <[email-masked]> said:

> There have not been any list comments on a draft that I wrote with
Stig and
> A.K. after Minneapolis on the issue of how nodes using DHCPv6 only for
non
> address configuration options should leanr ofconfiguration changes.

http://www.ietf.org/internet-drafts/draft-chown-dhc-stateless-dhcpv6-ren
umbering-00.txt

I've read the draft, and don't see a major problem in it.

One minor comment:  the draft repeatedly say there should be no
additional security concerns in actual proposals to address the
renumbering issues:

In Section 4, it says
   The solution should also be secure, such that additional security
   concerns are not added to the stateless DHCPv6 networking
   environment.

And in Section 7, it says
   However, whatever mechanism is designed or chosen to address this
   problem should avoid the introduction of new security concerns for
   (stateless) DHCPv6.

I have sympathy for you here, but is this actually a clear and
realistic requirement?  In fact, draft-venaas-dhc-lifetime-01.txt,
which is expected to be a proposal to address the renumbering issue,
has the following security concern:

   An attacker could send a fake DHCP reply with a very low lifetime
   value.  This could make a client request new data almost immediately.
   The value is however not kept when the next request is made.

Regarding the clarity, I'm not sure by this consideration if an
additional security concern is not added.

Regarding the reality, I guess it is likely to see some security
concerns in actual proposals, since the proposals would be a protocol
extension that affects a core part of the base specification.

I don't think this comment is a technical issue though.  This is
probably a matter of wording.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba
Corp.
					[email-masked]

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

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Mar 2004 09:01:13 +0900

Why would the lifetime solution cause packet storms?  We don't have 
similar problems with similar protocols.   Choosing a lifetime is easy, 
and you can adjust the lifetime when you plan a change.   I don't 
understand the objection.

Reconfigure would work, but it opens a vulnerability on the client 
(which now has to be listening for DHCP messages all the time), and 
requires a lot more infrastructure support than the lifetime solution.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 3 Mar 2004 07:50:41 +0100

On Tue, Mar 02, 2004 at 02:13:56PM -0800, Changming Liu wrote:
[...]
> too long delay, which is unacceptable for service shortage. if too short, it

Yes, so for unplanned changes it's difficult. Lifetime helps, but is
not a complete solution. See my other mail.

> may cause periodic storms of request/replies. This itself sounds like a
[...]

If you set the lifetime to one hour (or I gues you may want a smaller
value in your case). Hosts that receive the option will refresh their
configuration one hour later. If hosts are say turned on at different
time, the queries will also be made at different times. So the queries
will be distributed throughout the hour. If all hosts are powered up
simultaneously, like after a power failure, they will query at about
the same time. The randomization will help here. As time goes, they
will be dispersed more and more. You will get periods with many
queries, but not simultaneously.

The effect above is the same as for lease times, there's nothing new
about this I think.

In the worst case, it will behave like reconfigure...

Stig

---

From: Naiming Shen <[email-masked]>
Date: Tue, 02 Mar 2004 23:03:42 -0800

Stig,

 ] On Tue, Mar 02, 2004 at 02:13:56PM -0800, Changming Liu wrote:
 ] [...]
 ] > The lifetime has several significant drawbacks. The first one is how to
 ] > engineer the lifetime value? A difficult choice. if too long it will cause
 ] > too long delay, which is unacceptable for service shortage. if too short, it
 ] 
 ] Yes, so for unplanned changes it's difficult. Lifetime helps, but is
 ] not a complete solution. See my other mail.
 ] 
 ] > may cause periodic storms of request/replies. This itself sounds like a
 ] [...]
 ] 
 ] If you set the lifetime to one hour (or I gues you may want a smaller
 ] value in your case). Hosts that receive the option will refresh their
 ] configuration one hour later. If hosts are say turned on at different
 ] time, the queries will also be made at different times. So the queries
 ] will be distributed throughout the hour. If all hosts are powered up
 ] simultaneously, like after a power failure, they will query at about
 ] the same time. The randomization will help here. As time goes, they
 ] will be dispersed more and more. You will get periods with many
 ] queries, but not simultaneously.
 ] 
 ] The effect above is the same as for lease times, there's nothing new
 ] about this I think.

I think the scaling issue is missing in your text. The router we have 
in the network right now handles 60K customers per box, and ISPs demand that
there need to be 1 or 2 second detection delay if any host is gone. This
customer number per box can dramatically increase in the future, just
to give some examples here. Randomness does not help here.

Regards,

 ] 
 ] In the worst case, it will behave like reconfigure...
 ] 
 ] Stig
 ] 
 ] _______________________________________________
 ] dhcwg mailing list
 ] [email-masked]
 ] https://www1.ietf.org/mailman/listinfo/dhcwg

- Naiming

---

From: Stig Venaas <[email-masked]>
Date: Wed, 3 Mar 2004 08:15:47 +0100

> to give some examples here. Randomness does not help here.

OK, so all of these areusing the same DHCP server? Would reconfigure
help? If all hosts get a reconfigure message you have the same problem.
I think reconfigure has the same issue unless you could send reconfig
to different hosts (or different subnets) at different times.

I must confess I'm not sure I understand your scenario. But I'm not
saying that lifetime works in all cases. It's a simple solution I
believe helps in many cases, but there are cases where other solutions
are better.

Stig

---

From: Naiming Shen <[email-masked]>
Date: Tue, 02 Mar 2004 23:32:49 -0800

] On Tue, Mar 02, 2004 at 11:03:42PM -0800, Naiming Shen wrote:
 ] > I think the scaling issue is missing in your text. The router we have 
 ] > in the network right now handles 60K customers per box, and ISPs demand that
 ] > there need to be 1 or 2 second detection delay if any host is gone. This
 ] > customer number per box can dramatically increase in the future, just
 ] > to give some examples here. Randomness does not help here.
 ] 
 ] OK, so all of these areusing the same DHCP server? Would reconfigure
 ] help? If all hosts get a reconfigure message you have the same problem.
 ] I think reconfigure has the same issue unless you could send reconfig
 ] to different hosts (or different subnets) at different times.

No, reconfig may have the same problem. I would like to see to have
the server give out a 'lease-time' of 1 hour, but report back to me
every 1 minute. this way we cut down the traffic to half(only busy
in one direction).

 ] 
 ] I must confess I'm not sure I understand your scenario. But I'm not
 ] saying that lifetime works in all cases. It's a simple solution I
 ] believe helps in many cases, but there are cases where other solutions
 ] are better.
 ] 
 ] Stig

- Naiming

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Mar 2004 07:28:24 +0900

> to give some examples here. Randomness does not help here.

What does this have to do with DHCP?   DHCP doesn't provide the 
capability you're talking about, whether you use reconfigure or 
lifetimes.   If you are doing something like this, correct me if I am 
wrong, but I would assume you are relying on some kind of layer 1 or 
layer 2 mechanism.