Re: [dhcwg] Re: Renumbering DNS with stateless DHCPv6 - bug?

[Stig Venaas <[e-mail]>]

On Tue, Nov 18, 2003 at 12:57:01AM +0900, Masataka Ohta wrote:
> >I suggest for server to send reconfigure to clients via relays.

After some thinking I see that this is much harder than I first
anticipated (like always...). I'm still thinking about it, but
it's not easy.

> >>From server to relay:
> >
> >    If multicast routing available in the site:
> 
> "site" is not a useful concept for autoconfiguration, when
> the "site" is really small, which is, perhaps, the primary
> target case of "stateless", which is why I asked multicast
> over site boundaries.

Yes, I also see cases where it wouldn't work. Unicast to relays
have advantages, also wrt to security. Only issue is that server
will need to know their addresses.

> >	unicast to each relay, server has a list of relays
> 
> is a rational approach for either case.

I may agree. I'm trying to think of good ways to do reconfigure.
For now I think I'll do more thinking of that before I go into
possible solutions. As I said above it seems to be rather complex.

> Of course, the server have a stable storage.
> 
> However, some says "has a list of relays" is a "stateful"
> approach and is no good.

Yes, my feeling too.

> Lack of well definedness of "stateless" is making design and
> discussion very hard.

Yes. I would say that the DHCP server has configuration state,
but no dynamic state. A static list of relays is not ideal, but
might be ok. There are levels of dynamic state too though, it
should be avoided, but I feel the most essential is to not
require state through restarts/reboots. If reconfigure requires
state, it may be better to forget it.

> >Then from relay to client you can always use multicast on link.
> 
> It is unreliable that relays also should have lists of clients
> and stable storages or the server directly take care of the
> clients, in either of which case, unicast is good enough.

Yes, relays should not have lists of clients. I'm not insisting
on multicast in itself, but multicast is the only way I see to
avoid having per client state.

> >Reconfigure messages should be protected due to possible DoS
> >attacks. I didn't consider that at first. I think that can be
> >done using public key crypto. Server has a single key pair.
> >Clients get public key together with the config info, and the
> >reconfigure message is signed with the private key.
> 
> Sorry, public key crypto is computationary expensive that it
> rather amplifies than prevents DoS effect.

Yes, that is a good point.

> With your case, reconfigure messages with bogus signature will
> force clients perform expensive public key crypto computation.

Yes. It can avoid DoS attack on DHCP server (because all clients
do reconfigure), but it puts a big burden on clients. This is a
problem.

> >>W.r.t. inter-link multicast, what multicast protocols is intended
> >>to be used by people in DHC WG?
> 
> >I'm not sure that should be specified. At least as long as it
> >isn't SSM, the DHCP infrastructure is completely independent
> >of which multicast protocols are used, just like other
> >multicast applications.
> 
> I asked not "specified" but "intended".

I can't speak for people's intentions, but I don't expect people
to have given it much thought. I may be wrong. But SSM will not
work with current spec. Current spec allows site multicast to be
used, but doesn't require it. So I would say it's up to the
implementor and administrator.

> >Interesting question. It's relatively easy with standard
> >PIM-SM. You only need to reconfigure the RP address on the
> >routers, and if you use say BSR, you only need to change on
> >the c-BSRs and c-RPs.
> 
> It is more straight forward to change addresses of a DHCP server
> on relayes to be used for unicast relaying. However, a DHCP server
> is a single point of failure.

I don't agree on this. And if you have multicast deployed, you
will make sure that works as well.

> >Discussion on multicast reliability and renumbering could be
> >a good topic for mboned wg. It doesn't belong here.
> 
> I'm afraid it is not an attractive idea to involve yet another
> WG in the thread.

I agree, and I'm removing dnsop from this one. I don't think they
are interested in these details. But if you want to discuss
multicast and renumbering in general, you could if you like
create a new thread on mboned and not mention DHCP. Well, just a
suggestion. My point is that discussions on that problem is
much better in that group. There is more expertise there, and
I'm not sure how interested people are in dhc...

> >For SSM, relays would need to know unicast addresses of DHCP
> >servers, and if you do reconfigure with multicast, you also
> >need servers to know unicast addresses of relays. Then you
> >might as well use unicast.
> 
> Yup. But, is it "stateless"?

Not sure, I would like to avoid it though. It for sure adds
complexity to implementation.

> >>Is a well known unicast address is assigned to a primary and
> >>a back-up CORE/RP/SS, which means ANYCAST.
> 
> >Anycast might be used
> 
> An interesting fact is that there are someone who don't want to
> use "anycast" for DNS servers, because it intermingles DNS and
> routing system. However DNS servers by DHCP with multicast is 
> already eaqually bad. Then, are we having DHCP with multicast
> with anycast CORE/RP/SS?

I'm not too sure about using anycast myself. But if you use
anycast for RP, that's limited to the network. But let's not
discuss how to make multicast reliable here.

> Sure. However, mboned is the worst place to discuss "multicast
> does not work at all".

Well yes, people may not like it (; But there are people there
that think that multicast could be improved. And I'm not sure
renumbering has been given much thought.

> My intention here is to demonstrate that, with multicast, routing
> and DHCP are intermingled.

I would say that multicast and routing is in the network, while
DHCP is an application making use of multicast and routing.

DHCP may use site-scoped multicast if available, but it's not
required. However link-local multicast is required for IPv6 in
general, also DHCP.

Stig

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