[openbeosnetteam] Re: general or PPP ideas
- From: "Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx>
- To: <openbeosnetteam@xxxxxxxxxxxxx>
- Date: Wed, 30 Apr 2003 21:26:53 +0200
> > This is possible only if you are a client. I want to add support for
> > PPP
> > servers. A PPP server should be able to ask a RADIUS or LDAP server
> > for all
> > users.
> > I would have to hard-code PAP and CHAP into the PPP module. There are
> > many
> > other authentication methods (e.g., MS CHAP) and if someone wants add
> > them
> > it is very hard to read the source and find the right places where to
> > put
> > the extensions.
> > Do you think this is too much modularity?
> > At least for PPP servers the user-DB source should be a module.
>
> Why not just provide them as add-ons? After all, they are protocols in
> their own rights, especially CHAP, which requires renewal of
> authentication at various points in the connection. You could turn them
> off or on in the settings panel, and specify negotiation preference in
> however you configure the ppp server.
With add-ons you mean kernel modules, don't you? I want to do that, but how
does the server know which users are available and which password they have?
Some methods need the raw password from the authenticator and some can tell
the unencrypted password to the authenticator. If you want to authenticate
with the OS user DB (like in Unix) it is only possible with PAP because the
unencrypted password is needed for the user DB which then encrypts the raw
password and compares it with the encrypted password in the user db. Using
CHAP is not possible here, for example. Other system could supply the
unencrypted password to CHAP which then encrypts it for authentication.
I would like to use userland user-DB-add-ons because it puts less code into
the kernel. But this removes the possibility to make a PPP connection inside
the kernel. And it adds dependency on a userland application or complicated
userland API. I would prefer to make it very easy. If the authenticator asks
the userland DB it must block until each user is authenticated.
Multithreading would be impossible. So, in order to be fast we must use
kernel-land db-add-ons. In order to be secure against crashes in the
authenticator and reducing code size (libraries could be used from userland)
we must drop multithreading.
Which solution is the best? Or do you have a better solution?
I want the PPP server implementation to scale well. This means the PPP
implementation must be in the kernel (not like the Linux PPP servers).
> > > On the "which protocol to support" point, why not all? I mean, PPP
> > > could
> > > support IP, IPX, etc, no? I don't see why we should specified for a
> > > DialUp
> > > connection only IP or IPX or both packets should be allowed to pass
> > > thru
> > the
> > > PPP link. If an application send IPX (SPX packet) data and the
> > > dialup
> > > connection is the link on the road, or PPP module know how to
> > > encapsulate
> > IPX
> > > packets and he do it, or he don't and drop it.
> > > Is it a wrong idea?
> >
> > I thought about this, but I came to the conclusion that as an ISP you
> > do not
> > want to support IPX. What if some protocol is not secure and you want
> > to
> > close it? Anyway, Appletalk or IPX would not be useful for an ISP and
> > a
> > waist of resources.
>
> This is negotiated by LCP. If you try to bring up a protocol's NCP that
> the ISP doesn't like, it sends back a protocol-reject packet.
> Essentially, all you need is an ability to close down specific
> protocols. Again, in the case of servers, there should be a way to
> specify things, but for the user, little needs to be hardcoded. The
> server can just never notify protocols it doesn't like of an open link.
I would like the client and the server to specify their wishes. :)
> > And there is the problem that you must specify some settings anyway.
> > The IP
> > module must know its IP address which can be a statically assigned
> > address
> > (set by the user).
> >
> > Another problem is that the user might want to use some IP
> > compression to
> > increase the connection speed. How does IP know that?
> >
> > And if you have a PPP server you must tell the IP module which
> > dynamic IPs
> > it can assign to clients. This is only possible with settings.
>
> Of course we need settings. The issue is how much need be set.
Only the basics should be needed, but everything should be possible.
NCPs should be specified, for example.
> > > But, for a start, let's focus on IP in PPP support.
> > >
> > > BTW, sorry if I sounds too newbie on PPP... ;-)
> > > Does someone around have a better PPP technical documentation than
> > > just
> > RFCs?
> > > URLs? PDF(s)?
> >
> > I did not really intend to support anything else than IPv4 and IPv6.
> > To make
> > it easy for someone to extend the PPP implementation I want to create
> > an API
> > so that he/she does not hack into the PPP module.
>
> IMHO, This should be a standard, and not PPP specific, API.
Does anybody want to implement it as the standard? :)
Waldemar
Other related posts:
