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

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 02 Mar 2004 10:11:08 +0900

>>>>> 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-renumbering-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

---

From: [email-masked]
Date: Wed, 3 Mar 2004 03:08:37 -0000

Changming, 

>  For unplanned change, how can you set the lifetime? The 
> solution should work for both planned and unplanned changes. 
> The unplanned changes are more demanding. Please see the 
> scenario described in my previous email.

I don't agree at all. There is no requirement to work in the event of
unplanned events - it would be nice, but I don't agree that it is
required. There will always be breakage in the case of unplanned events,
which is precisely why operators try to avoid them. I think we are
deluded if we think that there is a solution out there that could be
guaranteed to work in the case of an unplanned event. Given that,
lifetimes are necessary and sufficient in my opinion.

> For reconfig, we already have one defined, but unicast only. 
> So the infrastruture should be there.

Why require infrastructure when it isn't necessary?
 
>  It only problem is it's unicast which does not scale well. 
> The problem is well defined in this draft and no need to repeat here.

Unicast doesn't scale and multicast is difficult to secure - that's the
bind that reconfig is in.

Mat

---

From: Changming Liu <[email-masked]>
Date: Wed, 3 Mar 2004 00:41:59 -0800

Stig,
 
>My thinking is that with a network or environment that is known to be
>unstable and with not too many clients, you can set the lifetime to a
>small value. It might be okay to set it to small values like 10 minutes.
>It's rather short, but with few hosts it wouldn't really be a problem.

10 minutes is long time. ANyone of you want your laptop to be out of service
for 10 minutes?

>I guess you could come up with cases where you need things to change
>immediately. I agree that lifetime doesn't help you then. In addition
>it would help if hosts make a new request when RAs give you a new
>prefix or perhaps if host is connected to new link.

We are the same page

>To fully solve the unplanned change case you need reconfigure. The
>question is whether it's worth the cost. I'm not sure you can do that
>safely without state on server.

Worth it or not depends on situation. There is no perfect world. It is full
of trade-off, especially in engineering. 

The security is a concern. But think about the case that a client just
reboots and which DHCP server does it trust? For ND,now we have SEND. for
DHCPv6, do we have Secure SEDHCPv6? Why does security just matter to this
message? 

Stig

---

From: Changming Liu <[email-masked]>
Date: Wed, 3 Mar 2004 03:51:44 -0800

Hi Mat, 

>This doesn't make it a requirement, it just says, 'It would be nice if
>we could cater for unplanned events.' I agree it would be nice, but I
>don't think it is possible in any really useful way, without imposing
>considerable burdens and costs on network operators, and therefore
>believe that lifetime's are sufficient here.

If this one can be interpreted as "nice to have" one. In section 2, it says
highly desirable. If this "highly desirable" still does not do the trick,
why do we removed it completely fom the draft? Why bother? 

>Is it implemented? Is it deployed?

Can not speak for other implementations. Our implementation is in alpha
testing now because ou customer demands it and we don't have other solutions
at this point! I wish this draft and the solution draft come out earlier.

>I've seen enough IPv6 networks hosed by rogue RAs to know that the way
>forward is not to add another unsecured multicast technology into the
>mix, but to work on solutions for securing those we've already got, e.g.
>SEND (although I think they may have backed off from the RA-auth
>problem).

How about othe applications using link-local multicast such as RIPng,
OSPFv3, etc. We really have a bigger poblem to solve. Unless someone comes
to say link-local multicast should not be used at all and lets obsolete it
(just like the site-local), I guess it sould not be limited to one
particular message.

Changming

---

From: Changming Liu <[email-masked]>
Date: Wed, 3 Mar 2004 04:26:17 -0800

Naiming and Stig,

You two just brought up an issue about scability with these two approaches
in cases of power outage and unplanned config changes, which is very good.

The solution to this, if we really decide to go with e-configure solution,
is to implement a push model instead of request-reply model.   

Just a thought.

Changming

---

From: Changming Liu <[email-masked]>
Date: Wed, 3 Mar 2004 06:30:53 -0800

Mark,

Thanks for the suggestion. We already have this DNS proxy solution
implemented. That will work for DNS in this situation. How about other
configurations? How about other scenarios that configration can change in
the fly? Without a good infrustruture in place, we need to conquer this
problem one by one. Why don't we have once-for-all solution? 

Another point is that not all the people buy into the proxy idea. Remember
that in old days, the firwalls are almost all proxy based. Look at now, they
almost are stateful. What a change!

Changming

-----Original Message-----
From: Mark Stapp
To: Bernie Volz
Cc: 'Changming Liu'; 'Ted Lemon '; '''JINMEI Tatuya / ???? ' ' ';
[email-masked]; '''Tim Chown ' ' '
Sent: 3/3/2004 6:05 AM
Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6

or the CPE could supply its own address (if it has an address on the 
downstream link) as the dns server address, and act as a forwarder for
its 
clients. the CPE knows which upstream links and upstream dns resolvers
to 
use, so it should make the decision, not the clients. the downstream 
clients should be insulated from upstream network issues as much as 
possible, imo. I agree with Bernie: this doesn't sound like a problem
that 
should be solved by reconfiguring the clients repeatedly.

-- Mark

At 08:48 AM 3/3/2004 -0500, Bernie Volz wrote:
>For this situation, why don't you advertise BOTH DNS servers (primary
and
>secondary) and simply have the CPE do the proper routing? If the
primary
>link is up, the CPE sends the packets over the primary link. If the
primary
>is down, the CPE sends the packets over the secondary link. Using the
>routing infrastructure and CPE knowledge of which link is up or down
seems
>to me to be the best solution.
>
>Note that you need to do this anyway with any active sessions that are
>running - as I'm sure your big customer doesn't want all sessions to be
>broken.
>
>It seems to me, unless I don't understand something, there really is no
>issue here.
>
>- Bernie
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Changming Liu
>Sent: Wednesday, March 03, 2004 3:33 AM
>To: 'Ted Lemon '; Changming Liu
>Cc: '''JINMEI Tatuya / ???? ' ' '; [email-masked] ' ' '; '''Tim
Chown ' '
>'
>Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6
>
>Hi Ted,
>
> >Your scenario seems like a configuration error.   Setting things up
so
> >that the client has to update DNS server information immediately on a
> >frequent basis is simply bad network design.   I don't think the goal
> >of this renumbering effort is to accommodate that kind of
> >configuration.   The right way to fix this is to put a DNS cache
> >downstream of the flaky link.
>
>If I  was not clear in describing the scenario, pleae forgive me. Our
>customer is one of the biggest Telecoes in the world. Without their
>permission, I can not disclose too much details. Needless to say, it
should
>not be that bad design after so many engineers working on it.
>
>Let me try it again in different way. Let's say a multi-homed CPE with
two
>upstream links, one connected to one of its ISPs, one is primary and
one is
>backup. DHCP are enabled on both links for configuration info such as
DNS.
>These two ISPs offer different DNS servers. The requirement is that as
long
>as primary ISP is up, use it right away including DNS. This is due to
cost
>struture. Is this reasonable requirement?
>
>This CPE runs DHCP server on the downstream link to pass the DNS info
to the
>local LAN. Once the primary ISP is up, its DNS info neends to push to
>downstream. Of course, you an hope the primary links never goes down
>unplanned(if it is true, why dualhome at the first palce?). The
lifetime
>solution does not solve this problem.
>
>If you need more info, we can get together to discuss this.
>
>Changming
>Netscreen Technoloies Inc
>

---

From: Changming Liu <[email-masked]>
Date: Wed, 3 Mar 2004 08:46:49 -0800

I think we are going into a rat hole here. My original point  is that the
lifetime approach works well for planned change, but it does not work for
unplanned changes. If we decide not to deal with unplanned situation, that's
fine although it is better to have one solution for both. 

But in my situation, we need to deal with unplanned changes now. I don't
know who else has such an experience or requirement. If they do, please
speak up. If our customer's situation is unique, we just need to deal with
it ourselves.

Good luck to the lifetime proposal, which solves problems in its own space,
in my opinion.

Changming 

-----Original Message-----
From: Bernie Volz
To: 'JINMEI Tatuya / _-?BÆ'
Cc: 'Changming Liu'; [email-masked]
Sent: 3/3/2004 7:38 AM
Subject: RE: [dhcwg] Renumbering Requirements for Stateless DHCPv6

>>> The requirement is that as long
cost
>>> struture.

>to mean that we do not want to use the secondary DNS (which would be
>located in the secondary ISP) if the primary ISP is up, due to the
>cost reason (and perhaps reachability/latency issue also?).

I don't know of anyone that charges for use of the DNS to resolve
addresses,
do you? Latency could be an issue; but that all depends on the routing
infrastructure (the secondary link might be slower than the primary, but
if
the primary link is up, you'll use the primary link). Place the primary
DNS
first in the list and it should be preferred; yes there may be some
latency
before the DNS resolvers switch back to using the primary, but you'll
always
have some small issue like that. It could also be that the secondary DNS
provider won't accept queries from the primary providers addresses, and
in
that case you'll have the normal failover between the two DNS servers
(resolver will try primary and give up after a timeout and try
secondary).
Note that the hosts (clients) would likely be using the provider's
address
as the source address (I'd presume the CPE would advertise both prefixes
and
the client would configure addresses on both).

Also, if the DNS fails because of addressing issues, what does that say
about any open sessions (or connections)? In order for this to be
successful, the two providers will have to have some agreement between
them
to cross route packets and the DNS (and any other essential services)
would
just have to be part of that. Remember, the providers are after the best
experience for the customer - or if they're not, they'll loose
customers.

>I've not reached a conclusion (of myself) on whether or not this is
>really a serious issue that can be a show-stopper for the lifetime
>proposal.  However, at least I think Changming has some valid points.

Look, you can always find an argument against any solution or at least
to
reduce the effectiveness of that solution. But remember that keeping it
simple is the best. Needlessly reconfiguring clients is no way to go. It
also has latency issues since transactions could be in progress or
clients
might miss the first (or first few) reconfiguration signals.

Putting all this in the routing logic of the CPE means that all the
smarts
about what to do is located in ONE place and all traffic is treated
equal.
This, to me, is such a basic routing issue that moving it up to any
other
layer is, frankly, stupid.

- Bernie

-----Original Message-----
From: JINMEI Tatuya / _-¾'BÆ [mailto:[email-masked]] 
Sent: Wednesday, March 03, 2004 10:14 AM
To: Bernie Volz
Cc: 'Changming Liu'; [email-masked]
Subject: Re: [dhcwg] Renumbering Requirements for Stateless DHCPv6

>>>>> On Wed, 3 Mar 2004 08:48:36 -0500, 
>>>>> "Bernie Volz" <[email-masked]> said:

and
primary
primary
seems
> to me to be the best solution.

I read the scenario

>> The requirement is that as long
cost
>> struture.

to mean that we do not want to use the secondary DNS (which would be
located in the secondary ISP) if the primary ISP is up, due to the
cost reason (and perhaps reachability/latency issue also?).

I've not reached a conclusion (of myself) on whether or not this is
really a serious issue that can be a show-stopper for the lifetime
proposal.  However, at least I think Changming has some valid points.

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

---

From: Changming Liu <[email-masked]>
Date: Wed, 3 Mar 2004 21:40:35 -0800

>No, I am talking about a DNS caching name server, not a proxy.   There 
>are no proxies in DNS.   I'd suggest reading RFC1033 and RFC1034 to get 
>some background on how this is done.

I guess I can assume I know how DNS works having implemented DNS client, and
proxy and NATPT for DNS. What you have asked effectively is to ask routers
to look up DNS cache for through traffic without being a proxy. I don't know
how many moderm routers do that. DNS is just one of the configurations
passed by the DHCP. How about NTP server? How about many many opotions?
THat's what I said in another email, we are going into rat hole. We need to
take one step back to look at the bigger picture.

>You seem to be attempting to re-engineer the Internet on the back of 
DHCP.   

No, I am not. We will consider whatever good sugguestions some of you have
made. As long as it works, who cares.

>You are not talking about unplanned renumbering - you are 
>talking about a planned system for on-the-fly reconfiguration based on 
>asynchronous events.   

Whatever the definition is, there is a problem. The lifetime based solution
does not work for this planned system for the on-the-fly change. BTW, how
many system deployed are not "planned system"? 

>Whether or not this is a good idea, it is out of 
>scope for the DHC working group, and is not part of the stated goal of 
>the effort we are currently undertaking.

I am quite new to this group. Don't know who else has a say on this besides
you? I originally thought it is entire working group's decision, not a
particular person. But I could be completely wrong. If that's the case,
please forgive me. I'll stop posting.

Changming

---

From: [email-masked]
Date: Wed, 3 Mar 2004 09:34:07 -0000

Hi Changming, 

> Changming: If you have read the draft, in both sectin 2 
> (problem statement)
> and section 4 (renumbering requirement) state it very clearly 
> and I agree
> 100% with. Here is the quote fom the draft in case you don't 
> have access:
> 
>  
> The unplanned renumbering event, which may be more common in smaller,
>    unmanaged networks, is more difficult to cater for.   Ideally, any
>    solution for the problem should consider planned and unplanned
>    events

> Changming: That's not my point. My point is whatever 
> infrastruture needed to
> support the unicast reconfigure message will be reused for 
> multiast. The
> unicast RECONFIGURE message is defined in RFC 3315 section 15.11.

> Changming: true statement and in general I agree. "Two 
> advantages of IPv6
> are that support for multicast is required and nodes can 
> create link-local
> addresses during initialization. " from RFC 3315 section 3. 
> If multicast is
> not secure, why don't we abandon it all together? We use 
> multicast address
> in many places such as RA, why not here?

Mat