You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently When configuring Faucet with Chewie for MAB, Faucet forwards only dhcp packets to the nfv port and chewie also filters out only dhcp packets (opens up a socket that will only listen to dhcp packets).
As an experiment, this might be okay but if we want to add static ip addresses to end devices, we run into the problem of not being able to authenticate devices that don't send out dhcp discovery packets.
Maybe as a solution to this, we could have chewie can open up a socket that listens to all packets, and on the FAUCET end, make the packets that will be sent to the nfv port configurable. The drawback to this though would be that if we make this a list of types of packets that are forwarded to the nfv_port of socket, then we have to decide which types of packets to allow (dhcp, ARP, ipv6 nd, etc.).
Enabling dot1x_mab basically adds an extra flow to block all packets other than dhcp until a device with a certain MAC address is authenticated. Is the dhcp part then necessary? We could do that using Faucet ACLs right? (Not suggesting we make it so we have to write acls for all packets we want to send to nfv. Just throwing considerations.)
Forwarding all packets to the nfv port also could be a network inefficiency if we add a L2 hub to a dot1x_mab port and attach a ton of devices that send out all different kinds of packets around where we allow authentication on all of them. (Not sure how much of a network inefficiency but maybe also a security issue if we add IOT devices to the mix?)
The text was updated successfully, but these errors were encountered:
To answer the first part of your question, we intentionally only send DHCP packets to chewie for MAB. This is because of the reason you point at in your last paragraph (to avoid DoS attack vector).
I believe it's common for per-existing vendor MAB implementations to only use DHCP request packets to kick off MAB, but agree we can probably do better than other vendor implementations.
We had another option of just sending all packets with a broadcast address destination (would catch arp/nd traffic) to the chewie socket but in the end decided to go with DHCP as it was simpler.
The way I see it, we could implement the "all broadcast" option and have a flag to turn it on, or as you say implement a version where we have a MAB ACL the user can supply which matches whatever packets they want.
Currently When configuring Faucet with Chewie for MAB, Faucet forwards only dhcp packets to the nfv port and chewie also filters out only dhcp packets (opens up a socket that will only listen to dhcp packets).
As an experiment, this might be okay but if we want to add static ip addresses to end devices, we run into the problem of not being able to authenticate devices that don't send out dhcp discovery packets.
Maybe as a solution to this, we could have chewie can open up a socket that listens to all packets, and on the FAUCET end, make the packets that will be sent to the nfv port configurable. The drawback to this though would be that if we make this a list of types of packets that are forwarded to the nfv_port of socket, then we have to decide which types of packets to allow (dhcp, ARP, ipv6 nd, etc.).
Enabling dot1x_mab basically adds an extra flow to block all packets other than dhcp until a device with a certain MAC address is authenticated. Is the dhcp part then necessary? We could do that using Faucet ACLs right? (Not suggesting we make it so we have to write acls for all packets we want to send to nfv. Just throwing considerations.)
Forwarding all packets to the nfv port also could be a network inefficiency if we add a L2 hub to a dot1x_mab port and attach a ton of devices that send out all different kinds of packets around where we allow authentication on all of them. (Not sure how much of a network inefficiency but maybe also a security issue if we add IOT devices to the mix?)
The text was updated successfully, but these errors were encountered: