On 12/05/10 04:29 PM, [email protected] wrote:
On (05/12/10 14:43), Darren Reed wrote:
What is done to ensure the alignment of "allowed-ips" and the
addresses configured?
We've already had extensive internal discussions about this, but
let me reiterate..
I don't know what you mean by "alignment", but as Erik explained to you
"Today if you set allowed-ips with dladm and then use ifconfig/ipadm to
set the IP address to something which is not in allowed-ips, then the
system silently drops all your sent packets on the floor.
With this proposal instead the SIOCSLIFADDR ioctl will fail, so ifconfig
and ipadm can report that failure to the admin."
The first problem cited here is independent of the one that this
project is aiming to solve: making it easier and more secure to
configure networking for a zone with an exclusive IP instance.
I'm also at a loss to see why solving that problem of silently
dropped packets is required to solve the problem of supporting
a configuration transition for those running with shared IP
instances that we want to get running on exclusive IP instances.
If the link already has a non-empty set of IP addresses set
in its "allowed-ips" property, will this feature add new addresses
to it or remove all of the existing ones and insert only the
new one?
If I change the "allowed-ips" directly with dladm after a zone
has booted, will there be any warning?
No, you would only be able to do this from the Global Zone, and the
assumption is that the GZ is the authoritative source of configuration,
so if that's the choice made in the GZ, nothing will prevent this.
Does this make sense?
New bits have been added to force synchronisation of IP
with what has been loaded into the MAC layer (it cannot
set the interface IP to something not in the advertised
set) but there is no further synchronisation if the details
change in the MAC layer.
For example, in that case, shouldn't further messages
from GLD be sent up to IP?
At the top, it states that if the global zone configures the address
for a network interface then the local zone is not permitted to
change it. Why should that have anything to do with forwarding?
Is the right approach being taken here? This would appear to
be a security issue (revoking the right of a zone to make a change
to its network configuration) but yet the implementation of the
support for this does not make use of any security fundamentals.
Why not?
In internal discussions, it was my understanding that *you* had expressed
the objection that setting allowed-ips on the interface would, in effect,
prevent the NGZ from forwarding out of that interface, and that this
behavior would happen without warning. Also in internal discussions
many of us have repeatedly explained to you that this is the
case where we want to simplify the simple network configuration case
using the same techniques that are already familiar to shared-IP users.
I cannot see why a configuration requirement of only being
able to set the IP address to that specified in the zone's
configuration file needs to be tied to the list of IP addresses
that are allowed in the source address field of a packet.
Solving that problem should be independent of solving
the problem that packets with a source address not in
the list of allowed IP addresses disappear silently.
At the bottom of this document, the man page update mentions
that this feature is incompatible with enabling forwarding. Why?
Shouldn't we be engineering Solaris to make features compatible
with each other rather than incompatible?
This feature does not introduce any feature incompatibility. It merely
makes the error semantics explicit.
Yes, it does. The use of "allowed-ips", today, is not incompatible
with a zone functioning as a router and nor is configuring a
zone with an exclusive instance of IP incompatible. Nor does
the operation of either feature introduce any specific errors
or failure conditions that preclude forwarding from functioning.
I'm uncomfortable with this because it increases the complexity
of the interaction with GLD and IP for questionable gain. My
view of this is that it is an attempt to make up for the lack
of proper architecture whereby networking resources for a zone
are supplied, set and applied.
:
If, for example, I wanted to extend this work to supply other layer-3
network properties, how would I do that? Implement a new mechanism
for each one? Does that really scale?
My concern here is that given a problem that would have future benefit
from real architecture being developed, the solution that we're being
given is a few hacks to solve specific problems.
perhaps we should just agree to disagree, because from the numerous
internal discussions, I don't think your opinion is shared by a majority.
Whilst I have no issue with the changes and interfaces presented
for zonecfg's configuration file, what goes on behind that smells
bad to me and nothing that I've read in terms of explanations from
anyone has done anything to change that. But if that's what you
really want to do, I can't stop you.
Darren
_______________________________________________
opensolaris-arc mailing list
[email protected]
