Re: RADIUS for MAC authentication in WLAN, how doing it?

• Previous message: james hal-pc.org: "Re: *BSD compatibility - request for improved collaboration"
• In reply to: Igor Sobrado: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
• Next in thread: jpd: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
• Reply: jpd: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Wed, 21 Jan 2004 20:52:04 +0000 (UTC)

jpd <read_the_sig@do.not.spam.it> wrote:
>
> Some multinationals really do use all, or at least most of that space.
> And some just had them grandfathered from before CIDR.

Indeed, but using all those addresses is very difficult. Some
corporations allocated those big address spaces before Internet
being run out of addresses. A good example is my University.
Now RedIRIS (a NSF-like organisation) assigns only 256 address
blocks.

> I don't see much difference from CIDR, except that they pre-labeled
> certain bits of the prefix with things that may or may not survive
> the first two decades of widespread IPv6 use. The main difference,
> as I see it, is that IPv6 is so much bigger that it'll take that much
> longer before petty global sub-divisions will turn around and bite
> us all in the ass. Then again, I could be wrong.
>
> Back in the day, IPv4 seemed to provide ample space. Nobody could
> have envisioned the net would explode the way it did. Better yet, the
> most famous predictions point in the exact other direction.

:-)

> No use to condemn the people that didn't know better because there
> wasn't any data pointing either way.

Certainly the growth of Internet was not expected in the last 80's.
Surprisingly, one of the most harmful services provided by this network
(the World Wide Web) is at same time the key to explain its successful
and wide availability.

> I can only wait and see. :-)

We will see what happens, but looks like communication between
autonomous systems will be simplified. The hierarchical addresses
allocation provided by IPv6 should make easier routing traffic
between autonomous systems.

>> Our University owns a /16 address space (156.35/16). It is spplited
>
> That looks like an original B.

You are absolutely right! Our University joined EARN (the European
academic research network) in the last 70's and, if I am not in a
mistake, Internet in 1988-89. We have a low AS number:

$ traceroute -a ftp.uniovi.es
traceroute to zeus.etsimo.uniovi.es (156.35.23.24), 30 hops max, 40 byte packets
 1 [AS766] r031205.red.uniovi.es (156.35.31.205) 2.303 ms 1.633 ms 1.465 ms
 2 [AS766] zeus.etsimo.uniovi.es (156.35.23.24) 2.991 ms 3.282 ms 4.406 ms

>> in 256 subnets with 256 addresses on each one of those subnets.
>
> That looks like they haven't updated and still run RIPv1. Which was
> superseded by RIPv2 (and a few other internal routing protocols) for
> exactly that reason: it can't deal with CIDR.

Yep! That is not a technological issue... we joined Internet soon,
a nice and innovative project, but I suspect that as happens with
other Universities here, there is not a real interest in research now.

In the last year I submitted three emails to the managers mailing list
at our University asking for information about an important problem
that must be solved: we are *not* participating in any IPv6 initiative
and I am unable to establish a tunnel to a free IPv6 provider (freenet6).
I have not received a reply to those emails.

It looks like there is a filter at some point (either at our firewall
or at a machine owned by RedIRIS). I am not sure about the problem
(IANA TCP port 3653 filtered, protocol number 41 filtered, ...who knows!)

After configuring NetBSD to connect to Freenet6:

# ./tspc -f tspc.conf
delete net default
add net default: gateway 3ffe:0bc0:8000:0000:8000:0001:9c23:61c5

...the routing table looks like this one (172.16/16 is a private network
I use most time, but I am using a public address when I try to build
a tunnel to freenet6):

# netstat -nr
Routing tables

Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 156.35.97.205 UGS 2 108 - wi0
127 127.0.0.1 UGRS 0 0 33220 lo0
127.0.0.1 127.0.0.1 UH 6 21 33220 lo0
156.35.97/24 link#8 UC 1 0 - wi0
156.35.97.205 00:50:0b:35:98:08 UHLc 1 0 - wi0
172.16.54.1 127.0.0.1 UGHS 0 0 33220 lo0

XNS:
Destination Gateway Flags Refs Use Mtu Interface

ISO:
Destination Gateway Flags Refs Use Mtu Interface

X.25:
Destination Gateway Flags Refs Use Mtu Interface

AppleTalk:
Destination Gateway Flags Refs Use Mtu Interface

Internet6:
Destination Gateway Flags Refs Use Mtu Interface
::/104 ::1 UGRS 0 0 33220 lo0 =>
::/96 ::1 UGRS 0 0 33220 lo0 =>
default 3ffe:bc0:8000:0:8000:1:9c23:61c5 UGS 0 0 - gif0
::1 ::1 UH 12 0 33220 lo0
::127.0.0.0/104 ::1 UGRS 0 0 33220 lo0
::224.0.0.0/100 ::1 UGRS 0 0 33220 lo0
::255.0.0.0/104 ::1 UGRS 0 0 33220 lo0
::ffff:0.0.0.0/96 ::1 UGRS 0 0 33220 lo0
2002::/24 ::1 UGRS 0 0 33220 lo0
2002:7f00::/24 ::1 UGRS 0 0 33220 lo0
2002:e000::/20 ::1 UGRS 0 0 33220 lo0
2002:ff00::/24 ::1 UGRS 0 0 33220 lo0
3ffe:bc0:8000:0:8000:0:9c23:61c5 ::1 UH 0 0 33220 lo0
3ffe:bc0:8000:0:8000:1:9c23:61c5 3ffe:bc0:8000:0:8000:0:9c23:61c5 UH 1 0 - gif0
fe80::/10 ::1 UGRS 0 0 33220 lo0
fe80::%lo0/64 fe80::1%lo0 U 0 0 33220 lo0
fe80::%wi0/64 link#8 UC 0 0 - wi0
fe80::%gif0/64 link#9 UC 0 0 - gif0
fe80::260:1dff:fe1e:2bb2%gif0 ::1 UH 0 0 33220 lo0
fec0::/10 ::1 UGRS 0 0 33220 lo0
ff01::/32 ::1 U 0 0 33220 lo0
ff02::%lo0/32 fe80::1%lo0 UC 0 0 33220 lo0
ff02::%wi0/32 link#8 UC 0 0 - wi0
ff02::%gif0/32 link#9 UC 0 0 - gif0

It looks like the tunnel do not works:

$ ftp ftp.netbsd.org
Trying 2001:4f8:4:7:2e0:81ff:fe21:6563...
ftp: connect to address 2001:4f8:4:7:2e0:81ff:fe21:6563: Connection timed out
Trying 204.152.184.75...
Connected to ftp.netbsd.org.
220 ftp.NetBSD.org FTP server (NetBSD-ftpd 20020615) ready.
Name (ftp.netbsd.org:sobrado):

But it looks right:

$ ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
        tunnel inet 156.35.97.197 --> 206.123.31.115
        inet6 fe80::260:1dff:fe1e:2bb2%gif0 -> :: prefixlen 64 scopeid 0x9
        inet6 3ffe:bc0:8000:0:8000:0:9c23:61c5 -> 3ffe:bc0:8000:0:8000:1:9c23:61c5 prefixlen 128

There is not real interest in new technologies here. As you can see,
IPv6 research in Spain is done at the research and development
division at the editorial office of one of our newspapers (El Mundo).
It's really incredible!

With some help, perhaps I will be able to find a workaround to get
IPv6 connectivity from here.

> This incompetence and/or immovability fits in the overall picture
> you scetched of the computing dept., though. Can't say whose fault
> it is, but their setup looks archaic and dusty.

Indeed... you see the big picture... :-)

>> But I supposed that it is done for management purposes. Private
>
> Routing protocol limitations, rather.

I understand that point now.

> No. RFC1918 is justifiable in a lot of situations, but it is not the
> solve-all cure-all. It breaks a very fundamental property of `public'
> ip: all IPs are unique in the world. Which is why you have to go to
> such lenghts to keep them from spilling into the big bad internet.
>
> EG surfnet (again) has a, well, holland-wide policy of _no NAT_ for
> the student dialup/adsl links. To this end they provide multiple
> IPs and DCHP with some advanced tricks to the multi-user ADSL links.
> The reason is that NAT makes subnets opaque, which is hell if you're
> trying to track down an abuse report. Given that we're dealing with
> several tens of thousends of users...

I fully agree with you... one of the strongest points about RFC 1918
is that network addresses do not need to be registered, one of the
weaknesses is that we depend on the ability (interest?) of those
private networks to track down a cracker.

Hopefully this problem will be fixed when running IPv6. Both stateless
and stateful address auto-configuration will make very easy adding new
devices to a network without allocating spaces of addresses inside
the organisation that is running an IPv6 network.

Looks like the old Novell scheme but applied to IPv6. Each device
has its own (unique) address ---Ethernet devices can translate the
IEEE 48-bit MAC addresses to IEEE EUI-64; IPv6 devices can have
its own EUI-64 address provided, for example, by the 6-pin TSOC
surface mount DS2502P-E64 node address chip distributed by Dallas
Semiconductors---. This is the key for building those addresses,
we only need to add the network part!

In this case, running NAT will make non sense.

> You could NAT your whole company of twenty-thousand people and require
> everyone to use the few proxies and mail-servers and the like to
> communicate with the rest of the world. You can because you're within
> the ``opaquity boundary''.
>
> But if you're running a public network, you can't do that. And even if
> you could, you might not want to. ``It all depends.''

Agreed... those private networks are a real nightmare when tracking
the activities of some users. Obviously, each private network needs
a responsible with the knowledge required to track those activities,
sometimes managers of those opaque networks do not want to cooperate.
Others do not have the required technical skills.

> Splitting in a non-standard way? I don't see how? If you want to play
> RFC1918 without CIDR, you pick as many 192.168.x C blocks as you need,
> or just the one 172.{16,17,...31} block, or whatever.
> That they're contiguous and easily notated with CIDR notation doesn't
> mean they don't fit the old classes. If you would check, you'd see
> that it fits the old classful addressing _exactly_, you just can't
> notate it the same way you would as with CIDR. :-)
>
> As a matter of fact, you can much more easily pretend we're still
> full of classes in RFC1918-space, as it's wide and available, compared
> to public ips. I've heard more than one report that RIPE likes to
> act out as total asses when it comes to handing out IPs.

I was thinking on the first bits of each address. Those bits are
used to classify addresses. There is a default netmask and I was
thinking that there was not reason for changing the default netmask
except for address spaces like the one assigned to our University.
Our default netmask 0xffff0000 is unmanageable. I see the advantages
of running contiguous address spaces. We can define address spaces
like 172.16/12 or 192.168.23.64/26. If we have a class A space
(10/8), some class B spaces (172.x/16, with x from 16 up to 31),
and a lot of class C address spaces (192.168.x/24, with x from 0 up
to 255) there is not reason for using non-default netmasks a priori.

But you are absolutely right, there are some technical issues for
not running, we say, a 10/8 address space. :-)

> HUBs are level2 devices, at least traditionally, so that usually poses
> no problem. Routers are a different story, but attach a hub to the
> desired router port and you're all set. The one most glaring problem
> with classful routing is that for two routers to link up in a peer-to-
> peer fashion they still need the smallest allocation available. This
> means burning a full /24 just for two addresses.
>
> Nowadays any router worth its salt can deal with any CIDR subnet. The
> hosts that have trouble or suffer from weirdness are usually helped by
> punching a few suitable holes in a DCHP-pool, or something like that.

Smaller allocations are desiderable for those devices. Perhaps
even a /30 address space. As you said, a netmask with 31 bits
makes non sense (and a netmask with 32 bits is sometimes
misunderstood by some operating systems and unroutable).

> Time for a bit more advice: write, proof read, cut out all the
> unnecesairy detail and wooly language that slipped in, proofread
> again, cut out more, etc.
>
> I noticed my postings did really get better when I started doing that.
> I still don't do it enough, but hey, at least we're on the way. I don't
> mind throwing half the post away before posting it. It helps. :-)

Trust me... I HIGHLY appreciate your advices. :-)

> Ah um, you forget that you have no authority. The VP has.
> If you provide the guidelines and the VP chooses to enforce them on
> those people... Then indirectly you have forced them to dance.
>
> In that case, they will. But as I hinted already, this is a subtle game,
> not for the faint of heart. It's just that you're in such a nice
> position to make them dance without you having to stick your neck out.
> On top of that, from what you've been describing, they completely
> deserve what they get. It'd be a real waste if you let this slip.

The VP of the Faculty of Sciences is not responsible of that network.
He will probably not be able to force them to run a secure network.
In any case, if there is a big problem with that WLAN setup they should
fix it. And I proposed building a RADIUS server for them. Not a
difficult task, and they are able to maintain that server in the
future.

> Worst case? 15 APs, with, say, 150 users concurrent, evenly spread.
> (All users on one AP means the AP will throttle because, quite simply,
> the waves have run out of bandwidth).

Indeed, that is a *worst* case...
Hopefully there is not physical space for all those users! ;-)
They will need to share at least two or three APs!

In this case, I guess that the worst problem is not running out
of bandwidth, but requesting access to the medium itself, CSMA/CD
will probably not be able to manage all those stations asking for
permission to transmit/receive at same time!

Wow... really a worst case.

> This means 15*(max bandwith per AP). In the absolute theoretical worst
> case this means 15*11Mbit, for which two 100Mbit lines, bonded together
> (look up FastEtherChannel[tm]) will be ample. This means you need a PC
> that can take four ethernet ports (two, bonded together, to the APs and
> two, bonded together, to the outside), and can push that much data back
> and forth.
>
> The practical worst case revolves around the quality of the APs and
> the wireless NICs involved: I believe you won't get much more than
> 7Mbit per AP, which, times 15, just about fits in one 100Mbit channel.
> Even more so of you set the 100Mbit to FDX. (Do the math, check FDX.)

That is a very good point. Those APs are 802.11g+ compatible (up to
100 Mbps at least theoretically) and support concurrently 802.11b
and 802.11g[+] devices, but I doubt that most users will run at that
high speed at least most time. I will do the math.

> From the above, I believe your users won't saturate a 100Mbit FDX link.
> This means the NetBSD box will survive with two well-used but not
> saturated 100Mbit FDX links (one to the 'net, one to the wlan). If
> you're still unsure you can always throw in two GigE cards. But I think
> that's overkill.

Indeed, it looks overkill. But it should be possible. We have 2 Gbps
links between floors, and higher speeds between campuses. Indeed, we have
an obsolete and dusty network, but we are running a Synchronous Digital
Hierarchy (SDH) ring with a data transfer rate of 2.5 Gbps since 1996.
This fiber-optic double ring connect three cities (Oviedo, Gijon,
and Mieres). A nice infrastructure, but as you observed we fail at a
protocols level. We are running RIPv1 and there is not interest in
IPv6. Bad news.

> Then again, if the NetBSD box is NOT to route all traffic, just to
> provide radius to the APs, and they'll handle the rest, then you can
> get away with one 10Mbit link, or even less, from the NetBSD box.

Of course! I was looking about giving a nice IBM ValuePoint (a 486DX
personal computer) running NetBSD for authenticating users. I own
that computer and I think that it should be a good RADIUS server
(answering the requests of the NASes is not a CPU/bandwidth expensive
task, a NetBSD machine running UBC should do a fine work). The issue
here is that the NIC (an old Novell 2000 compatible Ethernet ISA card)
loses network connection two or three times/day. I am not sure about
the problem, but I am looking for a replacement for this RADIUS server.

On the other hand, high quality hardware (and IBM sells nice personal
computers) is more important that a fast machine. I really want to
get that machine running as RADIUS server if it is possible.

> WEP only ``lives'' ``on the waves''. Ie, it won't help you on copper.

As we are running switches now, encryption is not so important.
On the other hand, I can provide a relatively secure network. What
users are doing with that network is another matter. Those users
are currently running unsecure protocols. I guess that most of them
are running telnet instead of ssh.

I want to assure that a WLAN NIC in promiscuous mode is not able
to capture traffic from mobile devices, what happens on the copper
is responsibility of those users. After all, running a secure vpn
means nothing if people is using our network to, we say, read email
from remote machines without using encryption or connecting to other
machines using telnet. We cannot protect users' traffic on the
WAN port of the NetBSD router, if they are not running a secure
protocol between the vlan router and other computers, we should we
care about security between the mobile devices and the router?

Users will not be able to connect to other mobile machines directly
(except if those devices are running, we say, NetBSD). In the latter
case, users will probably run their own secure communication
channels. Sadly, there is no way to protect those users when the
traffic leaves the NetBSD router (a side of the vlan).

> That is the authorisation part.
>
>
> The VLAN provides an extra outer fence to shield off the copper part
> of the wlan (the NetBSD<->AP bit, not the AP<->clients bit) from the
> rest of the copper network. That is its sole purpose.

But there is no way to shield off the copper part between the
NetBSD router and other hosts (mail servers, scientific workhorses
-we are running for example a Cray descendant made by SGI-, web
servers, general purpose machines...)

I doubt that traffic between mobile devices will be important.
And those mobile devices will have dynamically assigned addresses
(ok, there is a leasing time... but addresses will be dynamic
after all).

> Much like pulling separate cables from the APs to the NetBSD boxen to
> be sure nobody accidentally wanders off to the rest of the network
> before the NetBSD boxen give the go-ahead. Only you don't actually
> lay out extra cables.

I hope that USR will build good NASes. Those APs should not allow
traffic to go to our network without being authorised. At least,
I hope that it will not happen!!!

>> I hope this will be a reasonable set-up.
>
> Probably will. And it is already much better than the wide-open alternative.

Well... when I travel to Mieres I take advantage of that wide-open WLAN.
Good for reading email... I do not have a workstation with access
to our network on that city. But I proposed building a more secure
network to the responsible of that area (even if it means that I will
lose my own ---and fully unauthorised--- access to that WLAN). But I am
really worried about the current status of that network, and I want
to solve their authentication problem (in other words, there is not
authentication at all) even if it means that I will lose the possibility
of using that network when I go to Mieres (about ten times each year).

Cheers,
Igor.

-- 
Igor Sobrado, UK34436 - sobrado@acm.org

• Previous message: james hal-pc.org: "Re: *BSD compatibility - request for improved collaboration"
• In reply to: Igor Sobrado: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
• Next in thread: jpd: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
• Reply: jpd: "Re: RADIUS for MAC authentication in WLAN, how doing it?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]