crossbow discuss - Dec 2007 - Ideas for growing the community

I just got off the phone with Jim Grisanzio, THE OpenSolaris evangelist, 
see http://blogs.sun.com/jimgris/ Jim was sharing his experience on how 
to grow communities on OpenSolaris. In Jim''s opinion engaging 
universities and attending open source conferences are one of the best 
venues for that. One thing that is key for attracting people is to 
actively call out projects that people can work on. I have to admit, in 
the past we haven''t been very good at calling out what kind of 
contributions we are specifically looking for. I''d suggest that we 
prepare a list of things that we''d like to see from the community to 
provide guidance to people interested in contributing. Some of the 
things that come to my mind are a basic GUI (Someone in my team already 
did a first pass at this, but I''m sure there is a lot more that can be 
added to it) as well as contributing bug fixes. In addition to that 
Crossbow makes the HW classification capabilities of Network Interfaces 
transparent. This allows people to build more effective fire walls and 
IDS systems by pushing filtering and classification of packets down into 
the NIC HW.

There are probably thousands of other ways for people in the community 
to contribute: Documentation of typical use cases, best practices for 
managing virtual NICs, creating demos etc. Any other ideas?

Markus


---
Markus Flierl
Manager, Solaris Core OS
17 Network Circle
Menlo Park, CA 94025

phone: 650-786-2056
http://blogs.sun.com/roller/page/markusflierl

Markus Flierl wrote:

<snipped>

pushing filtering and classification of packets down
into
> the NIC HW.
> 
> There are probably thousands of other ways for people in the community 
> to contribute: Documentation of typical use cases, best practices for 
> managing virtual NICs, creating demos etc. Any other ideas?
Hear! Hear! about the above. In Solaris system admin docs (my group), we 
are practically begging the community for use cases. As soon as the next 
round of Crossbow code goes onto the OpenSolaris site, i''ll put a 
pointer to it in several places. Maybe that will help to generate 
interest. The best way to get use cases to have the code available for 
system administrators to play with. But first, they need to know that 
it''s available.

- Steff

Markus Flierl wrote:
> I just got off the phone with Jim Grisanzio, THE OpenSolaris evangelist, 
> see http://blogs.sun.com/jimgris/ Jim was sharing his experience on how 
> to grow communities on OpenSolaris. 
Thanks, Markus. It was very nice talking with you as well. I often have 
conversations like that, and you reminded me that I should really write 
some of this stuff down. :) I have many blogs on community building 
(hundreds, probably), but it''s not all in one place. Nor is it all 
fresh. So, today I wrote up some of the things we discussed on the 
phone, and I''ll keep adding to that post over time:

http://blogs.sun.com/jimgris/entry/building_opensolaris_communities

Also, I did a talk on contributing to OpenSolaris at FOSS.IN that is 
really another aspect of community building:

http://foss.in/2007/register/speakers/talkdetailspub.php?talkid=256

And Glynn Foster did a talk on contributing to OpenSolaris from a 
developer perspective (which was really excellent):

http://foss.in/2007/register/speakers/talkdetailspub.php?talkid=363

> In Jim''s opinion engaging 
> universities 
Yep. Joey Guo in China and Joe George in India are the two Sun people 
who are really driving various education programs. They are great guys 
and very open to visitors and new technical content to talk about.
> and attending open source conferences are one of the best 
> venues for that. One thing that is key for attracting people is to 
> actively call out projects that people can work on. I have to admit, in 
> the past we haven''t been very good at calling out what kind of 
> contributions we are specifically looking for. 
This was literally a requirement for the Project Days talks at FOSS.IN 
in Bangalore. See the FOSS.IN schedule http://foss.in/2007/schedules/ 
for all the presentations. The OpenSolaris Project Day was on the first 
day (listed in purple on the right side of the schedule). The talks were 
all centered around how to contribute to various technical projects, and 
they were presented by Sun and non-Sun community members.
> I''d suggest that we 
> prepare a list of things that we''d like to see from the community
to
> provide guidance to people interested in contributing. Some of the 
> things that come to my mind are a basic GUI (Someone in my team already 
> did a first pass at this, but I''m sure there is a lot more that
can be
> added to it) as well as contributing bug fixes. In addition to that 
> Crossbow makes the HW classification capabilities of Network Interfaces 
> transparent. This allows people to build more effective fire walls and 
> IDS systems by pushing filtering and classification of packets down into 
> the NIC HW.
Cool. Be as specific as possible. You may want to flush out ideas on 
list and then post them on the project page so people can blog about 
them. I''d love to be able to point to lists of things we need as well
as
people who are contributing.

See the Intel project for two grids listing some of their contributors:
http://opensolaris.org/os/project/intel-platform/
http://opensolaris.org/os/project/intel-platform/code-contributions/
> There are probably thousands of other ways for people in the community 
> to contribute: Documentation of typical use cases, best practices for 
> managing virtual NICs, creating demos etc. Any other ideas?
Also consider working with the globalization community to see if the 
community is interested in translating use cases into other languages.

Jim
-- 
http://blogs.sun.com/jimgris

Steff

Here are some applications that may be interesting crossbow use cases.  

1) A VoIP aware firewall provides secured connections between a customer and
partners.  Multiple types of services may run on the device, e.g., SIP on UDP,
H.323 on TCP, etc.  Each service may also run on multiple IPs or multiple ports
on same IP for different groups of users (e.g., separate IPs for trusted,
semi-trusted, and untrusted usrs).  Device may be connected to the public
network and may be attacks.  The goal is to use crossbow to mitigate / control
attacks on VoIP services.  For example
    a) Attacks on one IP (VNIC) should not affect services running on other IP 
    (VNIC)
 
    b) Attacks on one protocol (e.g., H.323/TCP) should not affect services 
    running on other protocols (e.g., SIP/UDP).  

    c) Attacks on one port should not affect services running on other ports or 
    IP/ports (that means at most one group of users may be affected.)


2) This use case is similar to case 1 but has additional goal to use crossbow to
protect all services, including the service under attacks.  The hope is to use
crossbow?s h/w based packet classification and flow control functions,
integrated with network and application level intrusion detection functions, to
detect and block bad traffics at near wire speed.

Note case 2 is more interesting because: 1)  for critical services user wants to
protect all users, including the user whose service is under attack; 2) it seems
there have not much study on how fast crossbow can block packets (v.s., some
work has been done on how fast crossbow can forward packets).  Such data is
important for security applications and I think many users will be interesting
in knowing the results.

Hope it helps

Xiaobo
 
 
This message posted from opensolaris.org

Hi Xiaobo -

Thanks for your suggestions. I''ve been on medical leave most of January
so apologies for not responding to you sooner. It''s possible that
others
on the Crossbow team may have responded already.

The use cases sound interesting indeed. I''m not sure that we can 
implement them here in our Labs. Engineers, any thoughts?  If the cases 
are deemed too specific for our more generic docs, I still think they 
are great. Therefore, my question to you is, do you have documentation, 
HowTos, etc., on how to set up and test your use cases? We have an 
enthusiastic OpenSolaris documentation community that provides HowTos 
and other information, like use cases, on the Documentation web site and 
on the Documentation Wiki. Here''s a URL to the System Administration 
Wiki, for example:

http://opensolaris.org/os/community/documentation/doc_index/sysadmin

If you are interested in providing material, I could work with you, or 
at least point you to the OpenSolaris documentation community.

- Steff

Xiaobo Wang wrote:
> Steff
> 
> Here are some applications that may be interesting crossbow use cases.  
> 
> 1) A VoIP aware firewall provides secured connections between a customer
and partners.  Multiple types of services may run on the device, e.g., SIP on
UDP, H.323 on TCP, etc.  Each service may also run on multiple IPs or multiple
ports on same IP for different groups of users (e.g., separate IPs for trusted,
semi-trusted, and untrusted usrs).  Device may be connected to the public
network and may be attacks.  The goal is to use crossbow to mitigate / control
attacks on VoIP services.  For example
>     a) Attacks on one IP (VNIC) should not affect services running on other
IP
>     (VNIC)
>  
>     b) Attacks on one protocol (e.g., H.323/TCP) should not affect services
>     running on other protocols (e.g., SIP/UDP).  
> 
>     c) Attacks on one port should not affect services running on other
ports or
>     IP/ports (that means at most one group of users may be affected.)
> 
> 
> 2) This use case is similar to case 1 but has additional goal to use
crossbow to protect all services, including the service under attacks.  The hope
is to use crossbow?s h/w based packet classification and flow control functions,
integrated with network and application level intrusion detection functions, to
detect and block bad traffics at near wire speed.
> 
> Note case 2 is more interesting because: 1)  for critical services user
wants to protect all users, including the user whose service is under attack; 2)
it seems there have not much study on how fast crossbow can block packets (v.s.,
some work has been done on how fast crossbow can forward packets).  Such data is
important for security applications and I think many users will be interesting
in knowing the results.
> 
> Hope it helps
> 
> Xiaobo
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss

We''re using crossbow to facilitate Zone routing while using the global
zone as a router and OpenVPN (an SSL-based VPN solution)

It allows us to create (using VNICS) exclusive IP stack non-global zones on the
same physical interfaces, so that we can route each zone independently of the
other.

The end result is a security product that has segregated zones as resources to
the network for whatever capacity they need to be in.

-Trish (SPL)
> -----Original Message-----
> From: crossbow-discuss-bounces at opensolaris.org [mailto:crossbow-
> discuss-bounces at opensolaris.org] On Behalf Of Stephanie.Brucker at
Sun.COM
> Sent: Monday, February 04, 2008 2:54 PM
> To: Xiaobo Wang
> Cc: Michelle.Olson at Sun.COM; crossbow-discuss at opensolaris.org
> Subject: Re: [crossbow-discuss] Ideas for growing the community
> 
> Hi Xiaobo -
> 
> Thanks for your suggestions. I''ve been on medical leave most of
January
> so apologies for not responding to you sooner. It''s possible that
> others
> on the Crossbow team may have responded already.
> 
> The use cases sound interesting indeed. I''m not sure that we can
> implement them here in our Labs. Engineers, any thoughts?  If the cases
> are deemed too specific for our more generic docs, I still think they
> are great. Therefore, my question to you is, do you have documentation,
> HowTos, etc., on how to set up and test your use cases? We have an
> enthusiastic OpenSolaris documentation community that provides HowTos
> and other information, like use cases, on the Documentation web site
> and
> on the Documentation Wiki. Here''s a URL to the System
Administration
> Wiki, for example:
> 
> http://opensolaris.org/os/community/documentation/doc_index/sysadmin
> 
> If you are interested in providing material, I could work with you, or
> at least point you to the OpenSolaris documentation community.
> 
> - Steff
> 
> Xiaobo Wang wrote:
> > Steff
> >
> > Here are some applications that may be interesting crossbow use
> cases.
> >
> > 1) A VoIP aware firewall provides secured connections between a
> customer and partners.  Multiple types of services may run on the
> device, e.g., SIP on UDP, H.323 on TCP, etc.  Each service may also run
> on multiple IPs or multiple ports on same IP for different groups of
> users (e.g., separate IPs for trusted, semi-trusted, and untrusted
> usrs).  Device may be connected to the public network and may be
> attacks.  The goal is to use crossbow to mitigate / control attacks on
> VoIP services.  For example
> >     a) Attacks on one IP (VNIC) should not affect services running on
> other IP
> >     (VNIC)
> >
> >     b) Attacks on one protocol (e.g., H.323/TCP) should not affect
> services
> >     running on other protocols (e.g., SIP/UDP).
> >
> >     c) Attacks on one port should not affect services running on
> other ports or
> >     IP/ports (that means at most one group of users may be affected.)
> >
> >
> > 2) This use case is similar to case 1 but has additional goal to use
> crossbow to protect all services, including the service under attacks.
> The hope is to use crossbow?s h/w based packet classification and flow
> control functions, integrated with network and application level
> intrusion detection functions, to detect and block bad traffics at near
> wire speed.
> >
> > Note case 2 is more interesting because: 1)  for critical services
> user wants to protect all users, including the user whose service is
> under attack; 2) it seems there have not much study on how fast
> crossbow can block packets (v.s., some work has been done on how fast
> crossbow can forward packets).  Such data is important for security
> applications and I think many users will be interesting in knowing the
> results.
> >
> > Hope it helps
> >
> > Xiaobo
> >
> >
> > This message posted from opensolaris.org
> > _______________________________________________
> > crossbow-discuss mailing list
> > crossbow-discuss at opensolaris.org
> > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
> 
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss

hi Steff

Thanks for the information. I will check the documents you pointed out.  

Regarding the use case, here is a simplified one.   Assume a server provides
certain service (email, voice, web, etc) on three links:

 1) protected link for trusted users;
 2) semi-protected link for semi-trusted users;
 3) unprotected links for untrusted users.

The server may be configured like: 

 Config 1: 
    nxge0 for protected link, 
    nxge1 for semi-protected link
    nxge2 for unprotected link

or
Config 2: 
    nxge0 for protected link
    vnic1 on nxge1 for semi-protected link, 
    vnic2 on nxge1 for unprotected link

Now assume the unprotected link has heavy traffic load, e.g., it is under flood
type attack and is receiving more than 200,000 pkts/sec.   We hope that crossbow
can be used to achieve several goals:

1) Traffics on the protected/semi-protected link are not affected, e.g., packets
should not be dropped because, e.g., CPUs are saturated.

2) Application processes have adequate CPU cycles to handle service requests.
Service quality on protected/unprotected links is not degraded.

3) If user can isolate bad traffics by L3/L4 classification and direct bad
packets to one CPU, then other CPUs are available to process good packets.  That
means that services on the unprotected link is avaialble under heavy traffic
condition or flood attack.


goal 1) and 2) are critical, and goal 3) is a nice-to-have.  To achieve goal 1)
and 2), the thought is to create four CPU sets, one for application, and one for
each linke.  Traffics on unprotected link may saturate its CPUs but does not
create load on CPUs in other sets.  The achieve goal 3), the idea is to classify
and drop packets at the lowest possible level so the server has enough resource
to handle good traffics under heavy lod condition.

This is just ideas. We haven''t tried with crossbow.  We are eager to
know whether  / how crossbow can achieve those goals.  If you and other folks
have suggestions, I will very appreciate it.

There was some discusson on traffic load and CPU fanout. 
(http://www.opensolaris.org/jive/thread.jspa?threadID=41120&tstart=30)
Our case is similar but differ in the sense that we are also interested in how
fast a server can block or drop packets v.s. receive and process packets.

A related question is:  is it possible to assign a flow to a dummy CPU, e.g.,
the flow acts like a sink hole and packets to the flow are dropped withtout
interrupt or polling?  That may save one CPU and also avoid other problems
between NIC and system


Thanks

Xiaobo
 
 
This message posted from opensolaris.org