Subject: [Int-area] To Bernard Aboba -- Re: ACTION REQUIRED: Handling reviews for draft-bi-savi-wlan

From: "Jun Bi" <[email-masked]>
Date: Sun, 4 Nov 2018 21:39:24 +0800

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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 4 Nov 2018 19:41:34 +0000

Hello Jun

While I agree that the snooping behavior allows operations without changing protocols and that is a real plus, experience from the real world proves you wrong on the robustness of snooping in WLANs. Ap ND has benefits to WiFi too. The future will say if it gets adopted there or not.

 My ask is that you indicate exactly the above:
- snooping may not be able to track rapid movements and may miss some for a while
-We can have a better reliability but that requires a protocol change; for this a pointer on AP ND is useful.
- in the meantime snooping is deployed and people should be aware of it

Regards,

Pascal

Le 4 nov. 2018 à 20:34, Jun Bi <[email-masked]<mailto:[email-masked]>> a écrit :

Dear Pascal，

Many Thanks for your review comment !
Please see the reply below and the attached draft revision version.

Best Regards,
Jun Bi

Comments from Pascal Thubert

I agree with Lorenzo, this scheme is at a high level what we can find in commercial products, and I have first-hand experience on that.

As an informational document, this RFC could be a useful reference to consider if we were to change the protocols in a way that would impact those existing and non-standard snooping behaviors.

Snooping has proven to be very useful, but as one may guess, it is not reliable; it may miss packets, may fail to create bindings, may point on an incorrect location as well.

So I’d say that if we publish as RFC, we should also indicate that with draft-ietf-6lo-ap-nd, we (will) have a more robust solution for devices that are willing to announce themselves.

Reply:

  Thank you for your comment. Regarding reliability issues of snooping in our case like DAD packet loss, please see responses to Lorenzo above.

  While draft-ietf-6lo-ap-nd proposes a security solution for low-power and lossy network (LLN), we focus on WLAN networks in this draft. WLAN network is much more stable than     LLN. And with solutions proposed for handling DAD message loss, the draft gives a mechanisms that is robust enough for source address validation in WLAN networks.

  Also, the proposed solution doesn’t affect existing protocols nor does it require any modifications to existing protocols.

<draft-bi-savi-wlan-16(1).txt>

---

From: "Jun Bi" <[email-masked]>
Date: Sun, 4 Nov 2018 21:31:34 +0800

Dear Lorezon，

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

Best Regards,
Jun Bi

Comments from Lorenzo Colitti

I skimmed the draft. It looks well-written, and it addresses an important problem which I think is probably solved in (different?) proprietary ways on various implementations in the field today. I'm not very familiar with the AD sponsorship process, so not sure what the has to happen from a process perspective. But I think the document requires further review, especially given that it's making statements about very widely-deployed scenarios (IPv6 over wifi). Should the document be adopted by a WG such as 6man or v6ops? If not, it should definitely be reviewed by those WGs.
As a concrete example, here are some things that need to be resolved before the document advances:

1. The proposed scheme relies on DAD packets to create mapping entries. That means that if a DAD packet is lost (which can happen even though 802.11 employs retransmissions at L2), a station could have an IPv6 address that doesn't work with no indication that it's not working. This is basically a non-recoverable outage. Perhaps the document should specify another solution instead, e.g., it could say that mapping entries could be created when a wired station receives a solicited NA response from a wireless station.

Reply:
   Thank you very much for your comment. We’ve already discussed about this issue in Section 3.3:
     Data packets MAY also trigger the establishment of new IP-MAC binding
     entries.  Data packet with non-bound source IP address with a limited
     rate is collected to handle DAD message loss in SLAAC procedure,
     which can be quite frequent in wireless network.  The detail of the
     procedure is specified in Section 4.  
  And we also have related security discussions in Section 7.1.

2. The document says that the lifetime of SLAAC addresses is the address lifetime, but the network has no way of knowing what the address lifetime is because it depends on which RA(s) the host has received.

Reply:
  As we already discussed in Section 3.1.1 and 3.3, the binding entries come from DHCP/ND snooping which is the same as that in wired network specified in RFC6620 and RFC7513. Thus the lifetime of SLAAC addresses are learnt by snooping RA messages sent to hosts.

---

From: "Jun Bi" <[email-masked]>
Date: Sun, 4 Nov 2018 21:34:24 +0800

Dear Pascal，

Best Regards,
Jun Bi

Reply:

---

From: "Jun Bi" <[email-masked]>
Date: Sun, 4 Nov 2018 21:40:24 +0800

Dear Bernard，

Best Regards,
Jun Bi

Reply:

Reply:

Reply:

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 13 Nov 2018 01:06:38 +0800

Dear Pascal,

Thanks for your comment.

Regarding reliability of snooping, we agree that packet loss can happen in WLAN. However we’ve already mentioned that in Section 3.3:

   Data packet with non-bound source IP address with a limited
   rate is collected to handle DAD message loss in SLAAC procedure,
   which can be quite frequent in wireless network.

In the same section the draft also proposed solution for packet loss which will always work as long as the moving host sends data packets.

We also agree that reliability could get improved by introducing new protocols. However since this draft proposes a SAVI solution, it’s “prohibited from creating its own protocols or extensions/modifications of current protocols.” which is specified as part of the WG charter. Therefore, instead of talking about AP-ND in this draft we would like to support it in other ways.

Best Regards,

Jun Bi
 
From: Pascal Thubert (pthubert)
Date: 2018-11-05 03:41
To: Jun Bi
CC: Int-area; Suresh?Krishnan; 吴建平老师; 王优; lintao
Subject: Re: To Pascal Thubert -- Re: ACTION REQUIRED: Handling reviews for draft-bi-savi-wlan
Hello Jun  

Regards, 

Pascal

Le 4 nov. 2018 à 20:34, Jun Bi <[email-masked]> a écrit :

Dear Pascal， 

Best Regards,
Jun Bi

Reply:

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 Nov 2018 23:28:00 +0000

Hello Jun

I think this is a misinterpretation of the mandate. Pointing on IETF work done outside SAVI like RFC-to-be 8505 and AP-ND does not constitute creating a solution yourself. It is in the interest of the reader to find the reference in your doc.

Suresh, what do you think ?

Pascal

Le 13 nov. 2018 à 00:06, Jun Bi <[email-masked]<mailto:[email-masked]>> a écrit :

Dear Pascal,

Thanks for your comment.

________________________________

Best Regards,

Jun Bi

From: Pascal Thubert (pthubert)<mailto:[email-masked]>
Date: 2018-11-05 03:41
To: Jun Bi<mailto:[email-masked]>
CC: Int-area<mailto:[email-masked]>; Suresh?Krishnan<mailto:[email-masked]>; 吴建平老师<mailto:[email-masked]>; 王优<mailto:[email-masked]>; lintao<mailto:[email-masked]>
Subject: Re: To Pascal Thubert -- Re: ACTION REQUIRED: Handling reviews for draft-bi-savi-wlan
Hello Jun

Regards,

Pascal

Dear Pascal，

Best Regards,
Jun Bi

Reply:

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 13 Nov 2018 11:59:41 +0800

Dear Pascal，

Thanks for the explanation.
You didn't mention your RFC-to-be 8505 in the previous email, so I didn't get what you meant.

If you just hope we point it as a reference, I think that would be no problem.

Best Regards,

Jun Bi
 
From: Pascal Thubert (pthubert)
Date: 2018-11-13 07:28
To: Jun Bi
CC: Int-area; Suresh Krishnan; 吴建平老师; 王优; lintao
Subject: Re: To Pascal Thubert -- Re: ACTION REQUIRED: Handling reviews for draft-bi-savi-wlan
Hello Jun 

Pascal

Le 13 nov. 2018 à 00:06, Jun Bi <[email-masked]> a écrit :

Dear Pascal,

Thanks for your comment.

Best Regards,

Jun Bi

Regards, 

Pascal

Dear Pascal， 

Best Regards,
Jun Bi

Reply:

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 13 Nov 2018 05:42:45 +0000

On Nov 12, 2018, at 6:28 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Jun

I don’t think adding this reference should be a problem.

Thanks
Suresh