Dear Bernard,

Many Thanks for your comments !
Please see the replies below and the attached draft revision version.

Best Regards,
Jun Bi


Comments from Bernard Aboba

I took a look at the draft and found some fundamental problems.  I would 
suggest review by IEEE 802.11 before proceeding.
A few of the issues are noted below.

   In WLAN, a number of security
   mechanisms on link layer make MAC address a strong enough binding
   anchor, for instance, 802.11i, WAPI, WEP.
[BA] WAPI and WEP are most certainly *not* "strong enough" for 802.11 security, 
let alone to be considered a "strong enough" binding mechanism. 
IEEE 802.11i has long ago been obsoleted by more recent IEEE 802.11 
specifications, so I'd be concerned this is also not an appropriate reference.

   If MAC address has no protection, attackers can spoof MAC address to succeed 
in validation.
[BA] While this statement is true, the inverse statement (that spoofing is 
prevented by protection) is not true. 
WLAN security does not prevent one authenticated station from spoofing 
multicast packets from another authenticated station.

Reply:
  Thank you for your comment. As far as we know 802.11i has not been obsoleted. 
While WAPI and WEP are less secure (and we removed them in the latest draft), 
802.11i implemented as WPA2 offers strong protection and are being widely used.
  Further, the protocols listed are just examples of MAC address protection 
mechanisms in WLAN. Preventing MAC spoofing relies on WiFi security mechanisms. 
It could be 802.11i or newer protocols and it is out of the scope of this draft.



   An individual procedure handles binding DHCP addresses to MAC
   addresses.  This procedure snoops the DHCP address assignment
   procedure between attached hosts and DHCP server.  DHCP snooping in
   WLAN is the same as that in wired network specified in RFC7513
   [RFC7513].
   An individual procedure handles binding stateless addresses to MAC
   addresses.  This procedure snoops Duplicate Address Detection
   procedure.  ND snooping in WLAN is the same as that in wired network
   specified in [RFC6620] [RFC6620].
[BA] These paragraphs do not mention ARP, so either the draft does not apply to 
IPv4 at all, or it cannot handle IPv4 static addresses.

Reply:
  Regarding IPv4 static addresses, we’ve mentioned how static addresses are 
handled in Section 3.3:
    All the static IP-MAC address pairs are configured into the IP-MAC
    Mapping Table with the mechanism enabled.
  For dynamic address configuration in IPv4 we only have DHCP which is already 
covered by the draft. So this draft applies to IPv4.



   A host leaves this access point.  The entries for all related MAC
       addresses in MAC-IP table MUST be cleared.
[BA] This advice, if implemented would break basic WLAN roaming functionality 
which allows a station to seamlessly move its point of attachment. 

Reply:
  The MAC-IP table is a new table we added for source address validation 
according to this draft and it has nothing to do with WLAN roaming 
functionality. So removing entries in the MAC-IP table won’t affect WLAN 
roaming functionality.


_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to