Port/mac/IP authentication, authorization, auditing. Is it possible ?
Is it possible by default or by using additional modules to authentice, authorize devices plugged to managed switch not only by mac, btu also by mac/ip or port/mac/ip, especially for statically assigned devices ?
On Jun 1, 2019, at 2:57 PM, CpServiceSPb <cpservicespb@gmail.com> wrote:
Is it possible by default or by using additional modules to authentice, authorize devices plugged to managed switch not only by mac, btu also by mac/ip or port/mac/ip, especially for statically assigned devices ?
You can generally authenticate by MAC, but not by IP. RADIUS is about network access. And the device doesn't have an IP until after it's been given network access. Look at the debug output: radiusd -X. Then, see which attributes are in the input packet. Those attributes are the ones that you can use for authorization / authentication checks. Alan DeKok.
сб, 1 июн. 2019 г. в 21:57, CpServiceSPb <cpservicespb@gmail.com>:
Is it possible by default or by using additional modules to authentice, authorize devices plugged to managed switch not only by mac, btu also by mac/ip or port/mac/ip, especially for statically assigned devices ?
You can generally authenticate by MAC, but not by IP. RADIUS is about network access. And the device doesn't have an IP until after it's been given network access.
Look at the debug output: radiusd -X.
Then, see which attributes are in the input packet. Those attributes are the ones that you can use for authorization / authentication checks.
Alan DeKok.
You are not quite right. Just imagine. There is managed (supporting Radius) switch with some free not used RJ45 cords. Once some visitor comes with his/her laptop and plugs free cord to its laptop ethernet connector. So we have wired client. But that's not all. I talk about stacially assigned IP for the device. His/her laptop is statically assigned IP/mask/gate/dns. That is device has b esides mac and IP. So, device send first packets to the switch. Switch examine the packet for mac and for IP, yes it engage L2 and L3. And collect port #, mac and IP, if any, wrap it to a unicast packet and send to Radius server. Radius server look through its own DB for port-mac-IP trinity existence. And if it is any, Radius send out (reply) to th switch to alllow the deice acces to a network, if Radius ddon' t find occurance it send out command to the swithc to deny to very device access to network via the port. If there is no IP at a firtst packet, switch examine port and mac only, and send the data to Radius and searching and makig of a decision to allow or grant acces to the network is made by couple of port=mac. It is in a case of dynamically assigned IP for example.
On 6/9/2019 2:42 PM, CpServiceSPb wrote:
сб, 1 июн. 2019 г. в 21:57, CpServiceSPb <cpservicespb@gmail.com>:
Is it possible by default or by using additional modules to authentice, authorize devices plugged to managed switch not only by mac, btu also by mac/ip or port/mac/ip, especially for statically assigned devices ?
You can generally authenticate by MAC, but not by IP. RADIUS is about network access. And the device doesn't have an IP until after it's been given network access.
Look at the debug output: radiusd -X.
Then, see which attributes are in the input packet. Those attributes are the ones that you can use for authorization / authentication checks.
Alan DeKok.
You are not quite right. Just imagine. There is managed (supporting Radius) switch with some free not used RJ45 cords. Once some visitor comes with his/her laptop and plugs free cord to its laptop ethernet connector. So we have wired client. But that's not all. I talk about stacially assigned IP for the device. His/her laptop is statically assigned IP/mask/gate/dns. That is device has b esides mac and IP. So, device send first packets to the switch. Switch examine the packet for mac and for IP, yes it engage L2 and L3. And collect port #, mac and IP, if any, wrap it to a unicast packet and send to Radius server. Radius server look through its own DB for port-mac-IP trinity existence. And if it is any, Radius send out (reply) to th switch to alllow the deice acces to a network, if Radius ddon' t find occurance it send out command to the swithc to deny to very device access to network via the port.
If there is no IP at a firtst packet, switch examine port and mac only, and send the data to Radius and searching and makig of a decision to allow or grant acces to the network is made by couple of port=mac. It is in a case of dynamically assigned IP for example.
It seems you are not grasping the concepts here. (see also http://deployingradius.com/book/concepts/) The authentication process involves two elements: 1) a client (the NAS = Network Access Server) which in your case is your switch; 2) an authentication server, in this case a Radius server, for example Freeradius. Simplistically speaking, the server is fed some data, looks at it, somehow processes it and replies with a "yes" or a "no". What Alan was trying to explain to you: The server can only act on the data it is given. You are asking the wrong people here. Go ask your switch vendor to send an IP address as part of the authentication. Please make sure to forward a copy of their response to this list. BTW for dynamically assigned IP address an option is to use DHCP snooping on the switch. That will make sure the MAC/IP tuple must match.
On Jun 9, 2019, at 8:42 AM, CpServiceSPb <cpservicespb@gmail.com> wrote:
You are not quite right.
How nice that you know more about RADIUS than people who've been doing it for 25 years.
Just imagine. There is managed (supporting Radius) switch with some free not used RJ45 cords. Once some visitor comes with his/her laptop and plugs free cord to its laptop ethernet connector. So we have wired client. But that's not all. I talk about stacially assigned IP for the device. His/her laptop is statically assigned IP/mask/gate/dns. That is device has b esides mac and IP.
That's not how RADIUS works.
So, device send first packets to the switch. Switch examine the packet for mac and for IP, yes it engage L2 and L3. And collect port #, mac and IP, if any, wrap it to a unicast packet and send to Radius server.
That's not how switches work.
Radius server look through its own DB for port-mac-IP trinity existence.
That's not how RADIUS works.
And if it is any, Radius send out (reply) to th switch to alllow the deice acces to a network, if Radius ddon' t find occurance it send out command to the swithc to deny to very device access to network via the port.
If there is no IP at a firtst packet, switch examine port and mac only, and send the data to Radius and searching and makig of a decision to allow or grant acces to the network is made by couple of port=mac. It is in a case of dynamically assigned IP for example.
Please imagine that you've completely misunderstood how RADIUS works. And, that you're working hard to explain it to someone who's written half of the RADIUS standards. Alan DeKok.
* You are not quite right. *> How nice that you know more about RADIUS than people who've been doing it for 25 years.
If you read more carefully you will be able that this exact phrase was connected with " ...And the device doesn't have an IP until after it's been given network access...." . And I provided the exact situation when ___device has an IP__ . At least at itself. It is not received from dhcp server after checking access rights to a network. It is set up manually before plugging to the switch. I supposed that switches wrap usually only macs, may be ports to uncast packet sent to Radius server. As a dhcp relay. But initially my quiestion was about ability to extend functionality of Radius by using some modules and of some switches to __limit / manage access__ to a network at access level witch on hybrid assigning IP environment - dymanically and statically but with controlling and making if a decision from server not switch side. So, the quesion was is it possible by Radius (may be with some additional modules) or are there plans to implement it ?
On Jun 9, 2019, at 11:15 AM, CpServiceSPb <cpservicespb@gmail.com> wrote:
And I provided the exact situation when ___device has an IP__ .
At least at itself.
You're replying as if I didn't understand your message. I did understand it, I just think it's not relevant. Here's your choice. You can: a) learn from other people b) insist that you know better. One approach is productive. The other approach is unproductive.
It is not received from dhcp server after checking access rights to a network.
It is set up manually before plugging to the switch.
That IP is entirely useless and irrelevant. It doesn't matter what is on the end system. The rest of the network will ignore it.
I supposed that switches wrap usually only macs, may be ports to uncast packet sent to Radius server.
As a dhcp relay.
Or, via MAC address authentication. Which is common on many switches. If you have some experience with network equipment, you would know that switches don't send IP address information in RADIUS packets for MAC auth.
But initially my quiestion was about ability to extend functionality of Radius by using some modules and of some switches to __limit / manage access__ to a network at access level witch on hybrid assigning IP environment - dymanically and statically but with controlling and making if a decision from server not switch side.
Sure. Replace all of the switches with ones that implement your magic scheme.
So, the quesion was is it possible by Radius (may be with some additional modules) or are there plans to implement it ?
This is the FreeRADIUS list. That means the subject of this list is FreeRADIUS. We don't re-define how RADIUS works on this list. If you want to re-define RADIUS, go ahead. But since no one will implement your magic extensions to RADIUS, they won't have any relevant to anyone. Again, you're arguing against people who've done this for 25 years. All of these ideas have been thought of before. They've been dealt with in detail. The people doing RADIUS aren't dumb, and you haven't thought of anything new. Alan DeKok.
You are asking the wrong people here. Go ask your switch vendor to send an IP address as part of the authentication. Please make sure to forward a copy of their response to this list.
I understand it. And along to it I started some ight duscussion of one of switch (amanged one) representatives to add such funtional for it. And I asked this quiestion here because this case is two side - server (Freeradius) and switch where server send out simply "yes" or "no" that is it gives an order to a switch "yes" or "no" and a switch simply ececute it - to allow or to deny access. And if such functional is at switch but is not at server (Radius) , it will not work at all. That is if switch is able to send port:mac:IP but Freeradius can not accept of such data and can not further handle it in a right way, such functinality will not work. One more, I tried to ask both "sides" - server developers/community and switch maker (one of brand) personell as well.
On Jun 9, 2019, at 12:27 PM, CpServiceSPb <cpservicespb@gmail.com> wrote:
I understand it.
And along to it I started some ight duscussion of one of switch (amanged one) representatives to add such funtional for it.
The switch vendors don't control RADIUS.
And I asked this quiestion here because this case is two side - server (Freeradius) and switch where server send out simply "yes" or "no" that is it gives an order to a switch "yes" or "no" and a switch simply ececute it - to allow or to deny access. And if such functional is at switch but is not at server (Radius) , it will not work at all.
In part, but not completely. The IETF controls RADIUS. No one will implement anything without a standard from the IETF.
That is if switch is able to send port:mac:IP but Freeradius can not accept of such data and can not further handle it in a right way, such functinality will not work.
One more, I tried to ask both "sides" - server developers/community and switch maker (one of brand) personell as well.
That's just not how things work. Standards bodies (like the IETF) create standards. The switch vendors and RADIUS server authors won't implement things unless they're a standard. Alan DeKok.
participants (3)
-
Alan DeKok -
CpServiceSPb -
jm+freeradiususer＠roth.lu