FreeLists / openbeosnetteam / [openbeosnetteam] Networking Wish List - Summary

["Emmanuel Jacobs" <emmanuel.jacobs@xxxxxxxxxxxx>]

Several days ago we queried the people on the main OpenBeOS mailing list for
ideas and wishes about the future implementation of the Networking Stuff
within OpenBeOS.

Please note this is not a design of the OpenBeOS's Network Functionalities
but only a collection of ideas expressed by people.

I suggest now we complete that info with core stuff.
Then we could build some kind of time line of objectives to reach and
distribute the work amoung us.

Ok, let's start designing ;-)

          Emmanuel
_______________________________________________

OBOS - Network Team - The Networking Whish List
_______________________________________________

* Document revisions:

[eja-011018] - first version.

* Introduction:

In the process of setting up a design and a time line for the OpenBeOS
Network components rewrite, the Network team tried to collect ideas from
BeOS users through the OpenBeOS mailing list.

This document's purpose is to collect all those.

                                                      Emmanuel

___________________________________________________

         - The OBOS Networking Whish List -

* Protocol-wise:

- IPv6 support
- ATM and PPPoA support
- Full PPPoE and PPTP support with CHAP authentication
- Token Ring support
- IPSec support
- IPSec key management: IKE and possibly photuris
- RSVP support

* Design-wise:

- Protocols could be handled as separate add-ons, which could be loaded
  and unloaded automatically

* Feature/API-wise:

- Some kind of built-in firewall functions in the network code
  (flooding and malformed packets protection).
- Some kind of built-in "translators" for non-transparent
  firewall/proxy so they could be used easily by applications and
  configured once.
- Clustering, High Availability (Beowulf, Possibility to pass sockets
  from one machine to another [original idea from OSNews,
  Eugenia's interview of some *BSD people] ).
- Integration of network protocols and filesystem would be nice. E.g. you
  can cd to "/net/ftp/ftp.be.com/pub/" and arrive at the server without
  using a special ftp client. Similar for SMB, HTTP, NFS etc... kind of
  like automounting, only no predefined directory entries are needed.
  (i.e.: doing an "ls" command on the "/net/ftp" directory does NOT
  display "ftp.be.com" unless you have already been at that location.
  [it's maybe a FileSystem service, http://ftpfs.sourceforge.net/]
- WON, Windows Network and AppleTalk Network browsing.
- The ability to have several network "profiles"
  (home/travel/company).

Application-wise:
- OpenSSL/OpenSSH.
- Apache.
- Perl build for OBOS with socket support




----- Original Message -----
From: "Ksyu & Dima" <k2d2@xxxxxxxxxxxxxxx>
To: <openbeosnetteam@xxxxxxxxxxxxx>
Sent: Wednesday, October 17, 2001 9:15 PM
Subject: [openbeosnetteam] Re: Status update


>
> Hi everybody,
>
> I am being a bit late with this reply but it is better later than never
> (or so they say...)
>
> >
> >2/ On the *OpenBeOS Network Team* side:
> >During the GeekDay event I could meet Guillaume Maillard, developer of
the Eden application and
> >Leader of the BlueOS project. Interestingly enough, they have someone
from Gobe, Inc working
> >closely with them. I also talked with Guillaume about a development that
could possibly be part
> >of OpenBeOS and BlueOS at the same time: the BeOS network API rewrite,
mapped after
> >traditional BSD sockets. I *have started* this API rewrite.
> >
> Do you need a hand with the rewrite?
>
> >Well hum... you can start thinking about the wish list anyway :o) It's
quite easy, just tell ALL
> >things you would like to see in OBOS Network layer. Don't mind if it is
feasable at all or not, just
> >think of a "perfect world".
> >For example as far as I am concerned I'd like to see:
> >Protocol-wise:
> >- IPv6 support
> >- ATM and PPPoA support
> >- Full PPPoE and PPTP support of course, with CHAP authentication ^_^
> >- Token Ring support (yes, I like Token Ring and think it is a
well-designed protocol, and
> >remember: I talked of a perfect world :P)
> >
> Here goes my wishlist:
>
> - IPSec support
> - IPSec key management: IKE and possibly photuris (btw, do we have any
> plans on BSD-compatible sockets API? That would make the task of porting
> of a lot of applications much easier)
> - RSVP support (a perfect world clause applies ;-))
>
> >
> >Design-wise:
> >- I wish every protocol would be handled by a separate add-on, then the
necessary add-on gets
> >loaded when a given kind of network traffic is recognized by the lower
layer.
> >
> There are some security issues associated with this approach. One way
> around could be for a user to select what protocol(s) he/she wants to
use...
>
> > That way it is
> >easy to add protocols and to update some protocols' support. The add-on
doesn't get unloaded
> >from memory unless there is a given timer without network traffic
observed (if the timer is
> >reached however it will be wise to assume the machine has been
disconnected from the network
> >and warn the user about it :P)
> >
> Good idea... (some protocols support keepalives though (tcp comes first
> to my mind) and can keep the connection open forever without any actual
> data being exchanged)
>
> >
> >
> >Feature/API-wise:
> >- An automatic flooding and malformed packets protection for applications
asking for it. e.g. an
> >application may call a FilterArrivingPackets() function that would tell
the network API to monitor
> >certain kind of parameters, some kind of built-in firewall working at a
lower level than user-
> >launched firewalls.
> >
> I think flooding protection can be implemented the same way as OpenBSD
> guys did it: when the queue of the opened (but not accepted) connections
> becomes too big, connections are being randomly dropped from the queue.
> The protection from the malformed packets is a bit trickier though: a
> user may or may not want to use IP options, for example; on the other
> hand malformed fragmented packets should always be dropped.
>
> >
> >- An automatic non-transparent firewall/proxy support. e.g. an
application opens a connection
> >(BNetEndpoint, BNetAddress...) and instead of having to care about
firewall/proxy itself it tells
> >the BNetEndpoint->UseProxyFirewall("socks5"). Then it doesn't care
afterwards whether it's
> >talking to a firewall/proxy or not, it justs sends the packets as it
would to a given server, and
> >the net_server handles the "translation" in firewall/proxy protocol for
it. What's the benefit?
> >Any application can then handle any kind of non-transparent
firewall/proxy supported by the
> >net_server without having to implement it. Kind of a "translator"
function applied to the network
> >if you prefer :o)
> >
> again, sounds like a good idea...
>
> >
> >- I read on OSNews (in Eugenia's interview of some *BSD people) about the
project of BSD
> >developers to enable sockets to be passed from a server to another one,
which would enable
> >QoS by ensuring a connection isn't dropped when a server is taken offline
for maintenance of
> >after a crash. I definitely want this in OBOS :o)
> >
> >Application-wise:
> >- I'd like OpenSSL/OpenSSH and Apache to compile right out of the box
(currently not the case,
> >it's even lacking proper header files)
> >
> A must have, IMHO ;-)
>
> >
> >- I'd like to have a Perl build for OBOS with socket support
> >
> would be nice to have.
>
> >
> >I realize I've been quite long and already offered an insight about the
wish-list topic :o) Well
> >anyway... hope you made it until here and read a little bit of
everything, but most of all... I hope you'll react to it ^_^
> >
> >Cheers,
> >
> >Jean
> >
> >
>
> Cheers,
> Dmitri
>
> >
>