Peter Dunlap writes:
> James Carlson wrote:
> > Why RADIUS in the kernel? This should only be a feature on the server
> > ('target') side of the protocol, so it shouldn't be a requirement in
> > order to boot.
Note: I've since learned that I'm wrong about that. Both sides need
RADIUS, because both are able to demand authentication from the other.
However, the idea of having RADIUS requests coming from a system
that's attempting to mount file systems in order to boot seems at
least a touch bizarre to me and begs other questions about how keying
and configuration is actually done. (I'm focussing on that particular
problem as it seems to me to be the only clear reason to have this
machinery down in the kernel.)
> > Couldn't connection authentication (a control-path
> > item) be done in user space rather than in kernel space?
> >
>
> We originally started with a split user/kernel model, then decided to
> keep the code together for the sake of simplicity. It has since become
> clear that a substantial amount of code would be better off in
> user-space including (probably):
>
> Login
> Authentication
> iSNS
OK.
> Needless to say we are too close to integration to make such changes
> without a significant schedule hit but we plan to move some
> functionality into user-space in the future. Would it be OK to address
> this by filing an RFE to move the login, authentication code (including
> RADIUS) and iSNS into user space?
Yes ... though this is another area where we have bad experiences.
> Is there an existing user-space RADIUS facility we could leverage if we
> handled authentication in user-space?
Sadly, no. Solaris is severely lacking in the AAA department. We've
discussed it on and off at least as long as I've been here, but
nobody's ever put up the resources to solve the problem. :-<
(I think at one point SunLabs was convinced that there was no reason
for Sun to do RADIUS because DIAMETER would or should sweep it away.
I'm not sure that's true in the marketplace, and I certainly have
never believed it, but it's one of the historical factors here ...)
On the plus side, you have a chance to be a hero. ;-}
> > idm_impl.c:
> >
> > (Not completely reviewed; I ended up here after seeing generic CRC
> > routines with unexpected "idm_" prefix on them in idm_so.c.)
> >
> > 524-722: consider using vmem_alloc to allocate IDs instead.
> >
>
> Is an RFE OK? (I know I'm saying that a lot. I will followup with a
> complete list of RFE's)
Yes, I think that's ok for this one.
> > 725-875: please remove. You're undoing the work that was done for
> > CR 4784660.
> >
>
> I didn't know there was a generic implementation of this -- if we had
> known we definitely would have used it. We definitely don't want to
> deliver duplicate code (the first thing we did in our iSER initiator
> changeset was yank out the duplicate MD5 code).
>
> Because of our schedule constraints I'd like to file an RFE for this too
> (P2, P1 whatever is acceptable).
It looks like this is actually the same reversed polynomial used by
SCTP.
You should coordinate with them and have both of them excised. As
they're _not_ actually duplicates of sys/crc32.h (due to the different
polynomial), I think I can live with an RFE, but it should cite
4784660 as a "see also."
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
