Re: RADIUS for MAC authentication in WLAN, how doing it?
From: Igor Sobrado (sobrado_at_string1.ciencias.uniovi.es)
Date: 01/21/04
- Previous message: Ted Spradley: "Re: *BSD compatibility - request for improved collaboration"
- In reply to: jpd: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
- Next in thread: Igor Sobrado: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
- Reply: Igor Sobrado: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 21 Jan 2004 09:03:03 +0000 (UTC)
[When I was replying to your last post this morning I was disconnected
from the WLAN. It never happened to me before (with Lucent hardware)
but happened two times today. Hopefully I was able to send a signal
to the news client to dump part of the post to a file (a backup file
of elvis running on a Slackware workstation). It must be a
joke using those low quality USR APs!]
jpd <read_the_sig@do.not.spam.it> wrote:
>
> IIRC surfnet (dutch university interconnect network) had one, but I can't
> seem to find it: their delegations are all continuous but don't have
> a superblock record anymore. Too bad.
Indeed, it is a very good example. I was not aware about surfnet
running one of those blocks of addresses.
> Oh and there are still organisations with an original class A delegation,
> of course. :-)
An example is MSFT. I think that class A delegations should be avoided.
It is difficult for an organisation using a 2^24 bits address space.
That is the reason IPv4 address space is full of big holes and we are
now running out of addresses. CIDR is a more rational approach for
sharing addresses.
> IPv6 uses mostly the same notation, altough its terminology is a wee
> bit different. Mostly the same ideas though.
IMHO, IPv6 follows a more rational approach. The network portion
of an IPv6 address (the most significative 64-bit block) is splitted
in a public topology chunk (with the format prefix field and two
really useful fields, the top-level aggregation and the next-level
aggregation identifiers) and a site topology part, where the
secondary level aggregation resides. There are some reserved bits
that can be used to expand the aggregatable global unicast addresses
TLA and NLA fields. It will make routing an easier task in IPv6
when compared to routing in current version 4 networks.
I think that IPv6 provides a much better approach to the problem
of routing traffic between ASes.
> Routing has quite interesting issues. :-)
Certainly, it has!
> I do not know of any organisation that has any serious delegation that
> doesn't split it up internally. How they represent themselves to the
> outside is a different matter, but eg RIPE doesn't allow any netblock
> smaller than /24 to be announced on its own. And those are the exception,
> even, most `normal' blocks need to be at least a /20 or /18 aggregate
> to be announced.
Our University owns a /16 address space (156.35/16). It is spplited
in 256 subnets with 256 addresses on each one of those subnets.
But I supposed that it is done for management purposes. Private
address spaces [RFC 1918, BCP 005] provide a much better approach
for those networks that do not need to be announced to the
outside world. RFC 1918 specifies a 10/8 prefix (class A),
a 172.16/12 prefix (16 class B subnets), and a 192.168/16 prefix
(256 consecutive class C subnets). In this case, I supposed that
splitting those address spaces in a non-standard way was a bad
design, as we are not limited by the availability of addresses
on a given space for our organisation (those addresses do not
need to be registered before using them). Obviously, I did not
considered restrictions in hardware and software (stackable HUBs
do not provide 2^16 ports on each management stack, and some
buggy software packages do not understand about subnets
different from /24 ones).
You clearly helped me to change my point of view about those
big address spaces.
> That is the point. You write up what your design is and how the components
> interact (protocols, etc) but leave the actual details as implementation
> examples. Instead you specify performance requirements and present your
> implementation as meeting or exceeding those requirements. That way they
> have not much incentive and less reason to change a workgin setup.
>
> Don't lock it down too much on details, or they can dismiss it as
> ``unworkable''.
That is a problem I have when writing papers too... I write a lot
of superfluous details that do not help improving papers. :-(
Thanks for the advice.
> Well, putting the keeping of logs and the authentication of users in
> the requirements makes their setup non-compliant with your proposal,
> doesn't it? :-)
>
> It's their setup, so they're responsible. However, if you make the
> rules (the requirements paper), you can make them dance.
They will not dance. I personally spoke with one of the responsibles
of that open network. I show him that I was able to connect my laptop
without registering it, and without an authorisation. In short, anyone
with a laptop can use that network without being registered.
I proposed building a RADIUS server for that network (after all,
I have one for my Lucent Technologies AP-1000 and they are running
Lucent devices too). After two months I am awaiting his answer yet.
> If the above looks like a battle plan, you'd be right and that is also
> precisely the reason why you don't officially hand in that report until
> you're finished and almost gone. If done well it really fscks up ``the
> other side''. You might want to cautiously(!) poll your VP for his
> opinion on giving him the paper. It's your goodbye gift to him; which
> he can then use to get that dept. back in line. But if he doesn't like
> it, it won't do anyone good.
> Then make sure they won't mind you writing such a paper (figuring out
> the consequences is their job, not yours). They probably won't, but
> you still could opt to show them a draft and ask for input, since
> they'll too be using the network.
I will follow your advice. Thanks a lot for helping me on this issue!
> My point is exactly that: I don't think it will be a bottleneck. Still,
> it would be good to _check_ it won't be. But I expect it to not be a
> bottleneck, as the actual traffic coming from the APs, even 15 of them,
> will never be enough to fully fill up one or two 100Mbit FDX lines.
>
> Which makes the fact that the APs have 100Mbit ports on ``the copper side''
> just that: a roomy channel to deliver the wavelan packets, but nothing more.
>
> And a well chosen PC with a well-tuned proper OS, even an older PC, can
> deal with two 100Mbit FDX channels no problem.
Once running, this network will support all users in our Campus.
I believe that there will be at least 50-100 concurrent users
in our WLAN. That means that a single router in
one of the sides of the vlan will have a limited bandwidth
for those users. Some of those users will probably run bandwidth
aggresive tools (like FTP client).
> The point was that if you're going to setup tunnels and such, that is,
> if the ``demarc'' between wavelan and the fixed network is to be not on
> the APs but on a NetBSD box (or somesuch), you want to shield all
> traffic until the demarc, lest someone reshuffle his routes and bypasses
> your authentication and logging setup. This is more easily achieved
> (than pulling more wires) by putting all APs and one side of the demarc
> in one vlan and the other side of the NetBSD box in the vlan of the
> network where you'll deliver.
>
> If you're having the APs be the demarcation points, you don't have to,
> but for administrative reasons you still may want to prefer to
> concentrate that pass-over point in one spot instead of at every single
> AP.
I will consider building a vlan between the APs and the NetBSD box.
But I believe that we will achieve a good security level on that
network (random WEP keys with a lifetime of less than two hours
dynamically distributed to authorised clients, per-user login/password
authentication, encryption, and a digital certificate to assure that
each client is connecting to the right NetBSD box).
Each AP has its own logs (accesible through the http interface)
and those logs will be automatically sent to management stations
(using SNMP) or network managers (by email).
I fully agree with you, management should be done in a single point.
That point is the NetBSD box where we will authorise/deny users
and look for illegal activities.
But if all this fails, I will build a vlan like the one you proposed.
I hope this will be a reasonable set-up.
Cheers,
Igor.
-- Igor Sobrado, UK34436 - sobrado@acm.org
- Previous message: Ted Spradley: "Re: *BSD compatibility - request for improved collaboration"
- In reply to: jpd: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
- Next in thread: Igor Sobrado: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
- Reply: Igor Sobrado: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
