crossbow discuss - Aug 2006 - Announcing the CrossBow early access bits on OpenSolaris

The CrossBow team is pleased to announce the availability of the first 
CrossBow release on OpenSolaris.org.

http://www.opensolaris.org/os/project/crossbow/CrossbowRelease08-2006

This release delivers the core functionality of project CrossBow:

# Virtual NICs (VNICs)
# Bandwidth control for TCP
# Stack instances for Zones

CrossBow provides the building blocks for network virtualization and 
resource control by virtualizing the stack and NIC around any service 
(HTTP, HTTPS, FTP, NFS, etc.), protocol (TCP, UDP, SCTP, etc.), Zones, 
or Virtual machines (Xen, Logical Domains, etc.)

More information about CrossBow can be found at the OpenSolaris project 
home page at http://opensolaris.org/os/project/crossbow

For questions or comments about CrossBow in general or this release in 
particular, please send email to crossbow-discuss at opensolaris.org

Enjoy!

Nicolas.

-- 
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux

Hi Nicholas,

The page states Nevada build 44. What about later builds? Will work? 
Will not work? Use at your own risk?

Thanks
Steffen

Nicolas Droux wrote On 08/24/06 21:30,:
> The CrossBow team is pleased to announce the availability of the first 
> CrossBow release on OpenSolaris.org.
> 
> http://www.opensolaris.org/os/project/crossbow/CrossbowRelease08-2006
> 
> This release delivers the core functionality of project CrossBow:
> 
> # Virtual NICs (VNICs)
> # Bandwidth control for TCP
> # Stack instances for Zones
> 
> CrossBow provides the building blocks for network virtualization and 
> resource control by virtualizing the stack and NIC around any service 
> (HTTP, HTTPS, FTP, NFS, etc.), protocol (TCP, UDP, SCTP, etc.), Zones, 
> or Virtual machines (Xen, Logical Domains, etc.)
> 
> More information about CrossBow can be found at the OpenSolaris project 
> home page at http://opensolaris.org/os/project/crossbow
> 
> For questions or comments about CrossBow in general or this release in 
> particular, please send email to crossbow-discuss at opensolaris.org
> 
> Enjoy!
> 
> Nicolas.
>

On 8/24/06, Nicolas Droux <Nicolas.Droux at sun.com>
wrote:
> The CrossBow team is pleased to announce the availability of the first
> CrossBow release on OpenSolaris.org.
>
> http://www.opensolaris.org/os/project/crossbow/CrossbowRelease08-2006
>
> This release delivers the core functionality of project CrossBow:
>
Hi

Great Job, sounds Like an awesome project, hope the source release
comes very soon.

James Dickens
uadmin.blogspot.com

> # Virtual NICs (VNICs)
> # Bandwidth control for TCP
> # Stack instances for Zones
>
> CrossBow provides the building blocks for network virtualization and
> resource control by virtualizing the stack and NIC around any service
> (HTTP, HTTPS, FTP, NFS, etc.), protocol (TCP, UDP, SCTP, etc.), Zones,
> or Virtual machines (Xen, Logical Domains, etc.)
>
> More information about CrossBow can be found at the OpenSolaris project
> home page at http://opensolaris.org/os/project/crossbow
>
> For questions or comments about CrossBow in general or this release in
> particular, please send email to crossbow-discuss at opensolaris.org
>
> Enjoy!
>
> Nicolas.
>
> --
> Nicolas Droux, Solaris Kernel Networking
> Sun Microsystems, Inc. http://blogs.sun.com/droux
>
> _______________________________________________
> networking-discuss mailing list
> networking-discuss at opensolaris.org
>

What build of Nevada will this be integrated into?



Nicolas Droux wrote:
> The CrossBow team is pleased to announce the availability of the first 
> CrossBow release on OpenSolaris.org.
>
> http://www.opensolaris.org/os/project/crossbow/CrossbowRelease08-2006
>
> This release delivers the core functionality of project CrossBow:
>
> # Virtual NICs (VNICs)
> # Bandwidth control for TCP
> # Stack instances for Zones
>
> CrossBow provides the building blocks for network virtualization and 
> resource control by virtualizing the stack and NIC around any service 
> (HTTP, HTTPS, FTP, NFS, etc.), protocol (TCP, UDP, SCTP, etc.), Zones, 
> or Virtual machines (Xen, Logical Domains, etc.)
>
> More information about CrossBow can be found at the OpenSolaris 
> project home page at http://opensolaris.org/os/project/crossbow
>
> For questions or comments about CrossBow in general or this release in 
> particular, please send email to crossbow-discuss at opensolaris.org
>
> Enjoy!
>
> Nicolas.
>
-- 
Stephen Harpster
Director, Open Source Software
Sun Microsystems, Inc.

Hi Steffen,

Steffen Weiberle wrote:
> Hi Nicholas,
> 
> The page states Nevada build 44. What about later builds? Will work? 
> Will not work? Use at your own risk?
Use at your own risk, basically. We''ve tested only bfu on top of build 
44 for now, but other builds might work as well.

Thanks,
Nicolas.
> 
> Thanks
> Steffen
> 
> Nicolas Droux wrote On 08/24/06 21:30,:
> 
>> The CrossBow team is pleased to announce the availability of the first 
>> CrossBow release on OpenSolaris.org.
>>
>> http://www.opensolaris.org/os/project/crossbow/CrossbowRelease08-2006
>>
>> This release delivers the core functionality of project CrossBow:
>>
>> # Virtual NICs (VNICs)
>> # Bandwidth control for TCP
>> # Stack instances for Zones
>>
>> CrossBow provides the building blocks for network virtualization and 
>> resource control by virtualizing the stack and NIC around any service 
>> (HTTP, HTTPS, FTP, NFS, etc.), protocol (TCP, UDP, SCTP, etc.), Zones, 
>> or Virtual machines (Xen, Logical Domains, etc.)
>>
>> More information about CrossBow can be found at the OpenSolaris 
>> project home page at http://opensolaris.org/os/project/crossbow
>>
>> For questions or comments about CrossBow in general or this release in 
>> particular, please send email to crossbow-discuss at opensolaris.org
>>
>> Enjoy!
>>
>> Nicolas.
>>
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss
-- 
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux

Stephen,
> What build of Nevada will this be integrated into?
We don''t have a target integration build yet.

Nicolas.


-- 
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux

<i>Hi Nicholas,

The page states Nevada build 44. What about later builds? Will work?
Will not work? Use at your own risk?

Thanks
Steffen
</i>

I have it running on build 45. I have had no problems so far, other than the
global zone (using the bge0) and a non global zone (on vnic2) on the same subnet
cannot send packets to each other. Both have no problems talking to the DSL
router.

Doug
 
 
This message posted from opensolaris.org

Doug,
> I have it running on build 45. I have had no problems so far, other than
the global zone (using the bge0) and a non global zone (on vnic2) on the same
subnet cannot send packets to each other. Both have no problems talking to the
DSL router.
That''s a known limitation that I need to add to the release notes and 
address in the future. The way to go for now is to create an additional 
VNIC and use that instead of bge0 from the global zone. That VNIC will 
be able to communicate with the other VNICs accessed to the local zones.

This limitation due to the fact that there''s no loopback path at the
MAC
layer between VNICs and the underlying interface when it''s plumbed 
directly. However there is a loopback path at the VNIC layer between all 
the VNICs defined on top of the same NIC.

Nicolas.

-- 
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux

This is great stuff Nicolas! Is there a plan for integration into a particular
Solaris 10 Update?
 
 
This message posted from opensolaris.org

Nicolas Droux wrote:
> Doug,
>
>> I have it running on build 45. I have had no problems so far, other 
>> than the global zone (using the bge0) and a non global zone (on 
>> vnic2) on the same subnet cannot send packets to each other. Both 
>> have no problems talking to the DSL router. 
>
> That''s a known limitation that I need to add to the release notes
and
> address in the future. The way to go for now is to create an 
> additional VNIC and use that instead of bge0 from the global zone. 
> That VNIC will be able to communicate with the other VNICs accessed to 
> the local zones.
>
> This limitation due to the fact that there''s no loopback path at
the
> MAC layer between VNICs and the underlying interface when it''s
plumbed
> directly. However there is a loopback path at the VNIC layer between 
> all the VNICs defined on top of the same NIC.
>
> Nicolas.
>
Nicolas,
I have just create a small script to create some vnics and the dladm 
command gives errors (and scrambled output) with more than 1 vnic. Also 
is the source code availiable yet?

Doug

root at bangkok> ./create_vnics
vnic1 dev: bge0 IP: 192.168.1.131
vnic2 dev:
dladm non-existent vnic ID ''3''
dladm non-existent vnic ID ''4''
dladm non-existent vnic ID ''5''
dladm non-existent vnic ID ''6''
dladm non-existent vnic ID ''7''
dladm non-existent vnic ID ''8''
dladm non-existent vnic ID ''9''
root at bangkok> dladm show-vnic
vnic1 dev: bge0 IP: 192.168.1.131
vnic0 dev:
vnic0 dev:
vnic100 dev:
vnic0 dev: ??
vnic0 dev:
vnic2 dev:
vnic0 dev:
vnic0 dev:
root at bangkok> ls -l /dev/vnic*
lrwxrwxrwx 1 root root 30 Aug 25 19:08 /dev/vnic -> 
../devices/pseudo/clone at 0:vnic
lrwxrwxrwx 1 root root 30 Aug 26 11:22 /dev/vnic1 -> 
../devices/pseudo/vnic at 0:vnic1
lrwxrwxrwx 1 root root 30 Aug 25 19:08 /dev/vnic2 -> 
../devices/pseudo/vnic at 0:vnic2
lrwxrwxrwx 1 root root 30 Aug 26 11:21 /dev/vnic3 -> 
../devices/pseudo/vnic at 0:vnic3
lrwxrwxrwx 1 root root 30 Aug 26 23:33 /dev/vnic4 -> 
../devices/pseudo/vnic at 0:vnic4
lrwxrwxrwx 1 root root 30 Aug 26 23:33 /dev/vnic5 -> 
../devices/pseudo/vnic at 0:vnic5
lrwxrwxrwx 1 root root 30 Aug 27 10:47 /dev/vnic6 -> 
../devices/pseudo/vnic at 0:vnic6
lrwxrwxrwx 1 root root 30 Aug 26 23:34 /dev/vnic7 -> 
../devices/pseudo/vnic at 0:vnic7
lrwxrwxrwx 1 root root 30 Aug 27 10:55 /dev/vnic8 -> 
../devices/pseudo/vnic at 0:vnic8
lrwxrwxrwx 1 root root 30 Aug 27 10:55 /dev/vnic9 -> 
../devices/pseudo/vnic at 0:vnic9

--create_vnics-------------------------------------------------------------------
#!/bin/bash

ipbase=192.168.1
ipstart=130

for (( i=1; i<10 ; i++ )); do
ipaddr="${ipbase}.$(( ipstart + i ))"
[ -L "/dev/vnic${i}" ] && {
dladm delete-vnic ${i}
}
dladm create-vnic -d bge0 -i ${ipaddr} -b 100 ${i}
dladm show-vnic ${i}
done
------------------------------------------------------------------------------------

> Nicolas,
> I have just create a small script to create some vnics and the dladm 
command gives errors (and scrambled output) with more  than 1 vnic. Also  is the
source code availiable yet?
Ah, I just thought I would try it again running a 32bit kernel, and dladm
show-vnic works correctly. It is just a problem with a 64bit kernel.

root at bangkok> dladm show-vnic
vnic1   dev: bge0       IP:  192.168.1.131      bw limit: 100kbps
vnic2   dev: bge0       IP:  192.168.1.132      bw limit: 100kbps
vnic3   dev: bge0       IP:  192.168.1.133      bw limit: 100kbps
vnic4   dev: bge0       IP:  192.168.1.134      bw limit: 100kbps
vnic5   dev: bge0       IP:  192.168.1.135      bw limit: 100kbps
vnic6   dev: bge0       IP:  192.168.1.136      bw limit: 100kbps
vnic7   dev: bge0       IP:  192.168.1.137      bw limit: 100kbps
vnic8   dev: bge0       IP:  192.168.1.138      bw limit: 100kbps
vnic9   dev: bge0       IP:  192.168.1.139      bw limit: 100kbps
 
 
This message posted from opensolaris.org

Hi Doug

Doug Scott wrote:
>>Nicolas,
>>I have just create a small script to create some vnics and the dladm 
command gives errors (and scrambled output) with more  than 1 vnic. Also  is the
source code availiable yet?
> 
> 
> Ah, I just thought I would try it again running a 32bit kernel, and dladm
show-vnic works correctly. It is just a problem with a 64bit kernel.
Thanks for reporting this. From your previous email it looks like you 
hit a known bug (6462422) causing the show-vnic output to be corrupted 
on some platforms, we''ll fix this for the next release.

Nicolas.
> 
> root at bangkok> dladm show-vnic
> vnic1   dev: bge0       IP:  192.168.1.131      bw limit: 100kbps
> vnic2   dev: bge0       IP:  192.168.1.132      bw limit: 100kbps
> vnic3   dev: bge0       IP:  192.168.1.133      bw limit: 100kbps
> vnic4   dev: bge0       IP:  192.168.1.134      bw limit: 100kbps
> vnic5   dev: bge0       IP:  192.168.1.135      bw limit: 100kbps
> vnic6   dev: bge0       IP:  192.168.1.136      bw limit: 100kbps
> vnic7   dev: bge0       IP:  192.168.1.137      bw limit: 100kbps
> vnic8   dev: bge0       IP:  192.168.1.138      bw limit: 100kbps
> vnic9   dev: bge0       IP:  192.168.1.139      bw limit: 100kbps
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss
-- 
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux

Nicolas Droux wrote:
> Hi Doug
> 
> Doug Scott wrote:
> 
>>> Nicolas,
>>> I have just create a small script to create some vnics and the
dladm
>>> command gives errors (and scrambled output) with more  than 1 vnic.
>>> Also  is the source code availiable yet?
>>
>>
>>
>> Ah, I just thought I would try it again running a 32bit kernel, and 
>> dladm show-vnic works correctly. It is just a problem with a 64bit 
>> kernel.
> 
> 
> Thanks for reporting this. From your previous email it looks like you 
> hit a known bug (6462422) causing the show-vnic output to be corrupted 
> on some platforms, we''ll fix this for the next release.
and I am ready to putback the fix for this.  Basically it''s an
alignment
error where the kernel and user space get different values for the size
of a structure.

Unfortunately this problem popped up just as we were doing the early
access bits.

-Mike

Doug wrote:
> Nicolas,
> I have just create a small script to create some
> vnics and the dladm command gives errors
> (and scrambled output) with more than 1 vnic.
> Also is the source code availiable yet?
I thought I''d see if this got a response for a few days. Surely I
can''t be the only person who thinks that releasing binary-only code for
an open-source project is... odd at best?

Boyd
 
 
This message posted from opensolaris.org

> Doug wrote:
> > Nicolas,
> > I have just create a small script to create some
> > vnics and the dladm command gives errors
> > (and scrambled output) with more than 1 vnic.
> > Also is the source code availiable yet?
> 
> I thought I''d see if this got a response for a few days. Surely I
can''t be
> the only person who thinks that releasing binary-only code for an
open-source
> project is... odd at best?
> 
> Boyd
If we never released source that would be very odd indeed :)
No the source is coming soon. it was just easier to get the binary out
very fast. 

Cheers,
Sunay

 


-- 
Sunay Tripathi
Sr. Staff Engineer
Solaris Core Networking Technologies 
Sun MicroSystems Inc.

Solaris Networking:	http://www.opensolaris.org/os/community/networking
Project Crossbow:	http://www.opensolaris.org/os/project/crossbow

Hi Boyd,

Boyd Adamson wrote:
> Doug wrote:
> 
>>Nicolas,
>>I have just create a small script to create some
>>vnics and the dladm command gives errors
>>(and scrambled output) with more than 1 vnic.
>>Also is the source code availiable yet?
> 
> 
> I thought I''d see if this got a response for a few days. Surely I
can''t be the only person who thinks that releasing binary-only code for
an open-source project is... odd at best?
We''d love to share our code today but there''s some required
process that
we have to go through before this can happen.

Nicolas.
> 
> Boyd
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss
-- 
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux

The Network Virtualization and Resource Management project (code name 
CrossBow) team
is happy to announce the availability of the Beta Candidate Release
on OpenSolaris.org
        http://opensolaris.org/os/project/crossbow/pre-beta/

We are delivering
. SPARC and x86 binaries,
. Full source code
. Draft man pages.

Many new and enhanced features have been added in this release, please
see the What''s New section for more details.

For questions or comments please send email to 
crossbow-discuss at opensolaris.org

Regards,

Per the zonecfg manpage, if a zone has an exclusive IP instance, the IP address
is set from within
the non-global zone, not via zonecfg.

How do I give a zone an exclusive stack, and the isolation and
''control'' that I would like to
delegate (ifconfig up/down, ndd, etc.), yet make sure the zone does not take on
the IP address of a
different node/zone? How can I prevent a DoS by a rogue zone mascarading as
another system?

Thanks
Steffen

On 12/11/06, Kais.Belgaied at sun.com <Kais.Belgaied at sun.com>
wrote:
> The Network Virtualization and Resource Management project (code name
> CrossBow) team
> is happy to announce the availability of the Beta Candidate Release
> on OpenSolaris.org
>         http://opensolaris.org/os/project/crossbow/pre-beta/
>
> We are delivering
> . SPARC and x86 binaries,
> . Full source code
> . Draft man pages.
>
> Many new and enhanced features have been added in this release, please
> see the What''s New section for more details.
>
Yay!

-- 
Paul Durrant
http://www.linkedin.com/in/pdurrant

Steffen Weiberle wrote On 12/12/06 04:31,:
> Per the zonecfg manpage, if a zone has an exclusive IP instance, the 
> IP address is set from within the non-global zone, not via zonecfg.
>
> How do I give a zone an exclusive stack, and the isolation and 
> ''control'' that I would like to delegate (ifconfig
up/down, ndd, etc.),
> yet make sure the zone does not take on the IP address of a different 
> node/zone? How can I prevent a DoS by a rogue zone mascarading as 
> another system?

that are two parts to this,
1. preventing an exclusive zone from spoofing its source address. That 
may need filtering
    at L2 to intercept spoofed outbound packets
2. the actual limiting of the set of IP addresses that a zone is allowed 
to take.

Unfortunately both are not i currently possible.

Thanks,
    Kais
>
> Thanks
> Steffen
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss

Kais Belgaied wrote:
>
>
> Steffen Weiberle wrote On 12/12/06 04:31,:
>
>> Per the zonecfg manpage, if a zone has an exclusive IP instance, the 
>> IP address is set from within the non-global zone, not via zonecfg.
>>
>> How do I give a zone an exclusive stack, and the isolation and 
>> ''control'' that I would like to delegate (ifconfig
up/down, ndd,
>> etc.), yet make sure the zone does not take on the IP address of a 
>> different node/zone? How can I prevent a DoS by a rogue zone 
>> mascarading as another system?
>
>
>
> that are two parts to this,
> 1. preventing an exclusive zone from spoofing its source address. That 
> may need filtering
>     at L2 to intercept spoofed outbound packets
> 2. the actual limiting of the set of IP addresses that a zone is 
> allowed to take.
>
> Unfortunately both are not i currently possible.
The behavior is same as that of a non zone system. I am curious as to 
why  a should zone provide protection for this.

Rao.
>
> Thanks,
>     Kais
>
>>
>> Thanks
>> Steffen
>> _______________________________________________
>> crossbow-discuss mailing list
>> crossbow-discuss at opensolaris.org
>> http://opensolaris.org/mailman/listinfo/crossbow-discuss
>
>
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://opensolaris.org/mailman/listinfo/crossbow-discuss

Rao Shoaib wrote On 12/13/06 18:14,:
> Kais Belgaied wrote:
>>
>> Steffen Weiberle wrote On 12/12/06 04:31,:
>>
>>> Per the zonecfg manpage, if a zone has an exclusive IP instance,
the
>>> IP address is set from within the non-global zone, not via zonecfg.
>>>
>>> How do I give a zone an exclusive stack, and the isolation and 
>>> ''control'' that I would like to delegate (ifconfig
up/down, ndd,
>>> etc.), yet make sure the zone does not take on the IP address of a 
>>> different node/zone? How can I prevent a DoS by a rogue zone 
>>> mascarading as another system?
>>
>> that are two parts to this,
>> 1. preventing an exclusive zone from spoofing its source address. That 
>> may need filtering
>>     at L2 to intercept spoofed outbound packets
>> 2. the actual limiting of the set of IP addresses that a zone is 
>> allowed to take.
>>
>> Unfortunately both are not i currently possible.
Thanks. Any plans for 2.?
> The behavior is same as that of a non zone system. I am curious as to 
> why  a should zone provide protection for this.
One of the benefits of zones over other virtualition mechanisms is the central
control the global
administator(s) can have over the non-global zones. Everything provides
isolation but limits effects
on other zones on the system. Even when root is delegated to the zone
adminstrator. But with IP
instances, the network identity control it totally reliquished to the
zone''s administrator(s) or
compromizer(s), without any limits in this area. Typically I say a compromised
zone can mess itself
up but little else, besides burning resources without RM controls. But with
exlusive IP instance
that is not the case.

I agree it is the same as with a discrete system, or a VMware or Xen guest OS,
or an LDom.

I''m concerned about resistance to exclusive IP due to this but may be
overly cautious.

Thanks
Steffen
> 
> Rao.
> 
>>
>> Thanks,
>>     Kais
>>
>>>
>>> Thanks
>>> Steffen
>>> _______________________________________________
>>> crossbow-discuss mailing list
>>> crossbow-discuss at opensolaris.org
>>> http://opensolaris.org/mailman/listinfo/crossbow-discuss

Steffen Weiberle wrote:
> Rao Shoaib wrote On 12/13/06 18:14,:
>> Kais Belgaied wrote:
>>>
>>> Steffen Weiberle wrote On 12/12/06 04:31,:
>>>
>>>> Per the zonecfg manpage, if a zone has an exclusive IP
instance, the
>>>> IP address is set from within the non-global zone, not via
zonecfg.
>>>>
>>>> How do I give a zone an exclusive stack, and the isolation and 
>>>> ''control'' that I would like to delegate
(ifconfig up/down, ndd,
>>>> etc.), yet make sure the zone does not take on the IP address
of a
>>>> different node/zone? How can I prevent a DoS by a rogue zone 
>>>> mascarading as another system?

This sounds like an RFE for a new configurable privilege:
    NET_SETIPADDR: set IP address of network i/f''s.  Not included in a
zone''s
    default privileges.

I don''t know how feasible that is.


--------------------------------------------------------------------------
Jeff VICTOR              Sun Microsystems            jeff.victor @ sun.com
OS Ambassador            Sr. Technical Specialist
Solaris 10 Zones FAQ:    http://www.opensolaris.org/os/community/zones/faq
--------------------------------------------------------------------------

Hi Rao,

Rao Shoaib wrote On 12/13/06 15:14,:
>
> The behavior is same as that of a non zone system. I am curious as to 
> why  a should zone provide protection for this.

it''s an added value for the server consolidation: replacing multiple 
machines with a single
zoned box cuts down the effort of system installation, patch, 
application updates, etc...
Having a single place for expressing a global security policy, as 
opposed to replicating
the same work on each machine or zone would be a next step in that 
simplification.


    Kais.
>
> Rao.
>
>>
>> Thanks,
>>     Kais
>>
>>
>

Kais Belgaied wrote:
>
> Hi Rao,
>
> Rao Shoaib wrote On 12/13/06 15:14,:
>
>>
>> The behavior is same as that of a non zone system. I am curious as to 
>> why  a should zone provide protection for this.
>
>
>
> it''s an added value for the server consolidation: replacing
multiple
> machines with a single
> zoned box cuts down the effort of system installation, patch, 
> application updates, etc...
Sure these are all benefits of server virtualization.
> Having a single place for expressing a global security policy, as 
> opposed to replicating
> the same work on each machine or zone would be a next step in that 
> simplification.
I think of security policy as ipsec/ipfilter ploicies and I agree there 
should be a central place to describe them. What Steffen is asking for 
is protection against a zone causing network problems for another 
zones,  because in a zone model, each zone  is protected  from being 
harmed by the other zone and I agree with Steffen''s assertion.

Rao.
>
>
>
>     Kais.
>
>>
>> Rao.
>>
>>>
>>> Thanks,
>>>     Kais
>>>
>>>
>>

Steffen Weiberle wrote:
> Per the zonecfg manpage, if a zone has an exclusive IP instance, the IP 
> address is set from within the non-global zone, not via zonecfg.
> 
> How do I give a zone an exclusive stack, and the isolation and
''control''
> that I would like to delegate (ifconfig up/down, ndd, etc.), yet make 
> sure the zone does not take on the IP address of a different node/zone? 
> How can I prevent a DoS by a rogue zone mascarading as another system?
What IP Instances will deliver is the ability to ensure IP-level 
separation when different zones are connected to different VLANs or 
different LANs.

For that to be implementable in finite time and with a sane 
architecture, any enforcement of what can and can not be done towards 
the network needs to be done outside of the IP-stack proper.

We''ve looked at the various threats that a zone can launch towards the 
network, and while some (like ARP spoofing/IP address stealing) is 
prevented as a side-effect of how the shared-IP stack is configured, 
there are others that are not. For example, uid=0 in a shared-IP zone 
can spoof any ICMP, UDP, or TCP packets apart from the source address 
field. Thus it is possible to lauch attacks on the IP routing system by 
spoofing ICMP redirects or RIP packets.

We are moving towards an architecture where we can prevent that type of 
attacks using a future project.

    Erik