802.1x is very complicated and I won't go into it, but, DHCP snooping works by limiting L2 forwarding (MAC table population) to only what the DHCP server says the end device should have and it does this just by inspecting the DHCP replies (no custom protocol) with some vendor specific extensions on the DHCP server side for complex scenarios (you can even do things like put ports in a specific VLAN based on the DHCP reply). There are lots of technology which avoid this issue now, but the two primary ones are 802.1x (used in corporate/government environments) and DHCP snooping which can be much more broadly deployed. In practice, the other person is going to get annoyed and give up. You can win that fight by sending a lot of packets. If two devices in a network have the same MAC address, they will effectively "fight" for control of the packet flow. Network devices forward (switch, more technically) packets to and end device based on an internal MAC table (send packets for DE:AD:BE:EF to interface ge-0/0/0.0) and most devices populate their MAC table simply by looking at input packets and sending the "next" packet for that MAC address out the "last" received interface. WPA Enterprise), but these don't really have a good story for "pay via web portal" style usages and are more geared towards wireless carrier operated hotspot networks and corporate scenarios, respectively. This could then yield an authentication token, to be provided for seamless reconnections for the same session. able to only access a limited set of hosts such as the in-flight map as described in the article), or needs to pay/authenticate (and if so, at which URL). something to tell the client whether it's connected, restricted (i.e. for 3DS, for payments, sometimes emails for password reset codes etc and more).Ī standardized endpoint and API would also be nice, i.e. In any case, I'm sad that this isn't a solved problem yet, and paid Wi-Fi (as well as securing free Wi-Fi) still requires custom and clunky solutions like unreliable captive portals that need to pass through selective traffic (e.g. authenticate a given OWE session, not a given MAC address) if the device supports it, as at least modern Apple devices do? But I have no idea how stable an OWE session is it would be very inconvenient to have to login again every time my device switches between access points. I suppose they could use Opportunistic Wireless Encryption and bind session authentication to that (i.e. I'm not aware of an easy way for the airline to actually do better than this! The state of "open Wi-Fi" security is actually really sad. It should be resilient against DoS, so most protocols aren't going to have that vulnerability. I'm pretty sure that any such protocol which succumbs to any unencrypted (or incorrectly keyed) traffic that isn't from the designated counterparty is insecure to begin with. The only way this goes sideways is if a connection protocol is engineered to make it go sideways when you try to do that. The truth is probably YMMV by protocol, but there is truly no way for the wifi router to detect this is happening or isolate the redundant stations - it's an unencrypted broadcast. I'd guess that connectionless protocols will work fine and connected protocols will also work fine. Worst case scenario, the router/service endpoint sees your connection responses and the other party's strange NACK responses, but I honestly don't know enough about how it works to say "everything works fine" "everything works fine" might be overstating a bit, but what happens to packets you weren't expecting when you don't have a connection open for them to go into? They probably get ignored by the network stack.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |