Re: [STDS-802-11-TGBC] eBCS frame authentication proposal uploaded
Hello Abhi,
Thank you for the feedback.
1.The revised slides don’t address the issue of data injection by a rouge device (issue is discussed on slide #7 in 11-19/1675r0). Such an attack would overburden the clients as they have no way to differentiate between genuine eBCS data frames and injected (fake) frames until they receive the key. During such time an attacker could inject hundreds of frames.
Please see the slide #37.
2.Suggest removing slide #25 and limiting Tesla based authentication to streaming use-cases where the data is periodic. If we allow Tesla for irregular sequence, the client don’t have a way to know when to expect the next eBCS Data frames – as a result, the client would burn power listening to every frame in the medium to see if it is an eBCS frame from the AP.
I agree. I will remove #25 in the next revision.
3.On slide #19, a client device that just entered an eBCS AP’s neighborhood would need to wait for long period of time (order or several seconds) in order to review the 1st eBCS Info frame. Without any indication, the client would burn power listening for each frame on the medium. We need to think of ways to indicate the offset to the next eBCS frame.
I suppose Beacons can advertise the timing of the eBCS Info frame transmission.
Receivers can refer it and power off until the eBCS Info transmission.
Best Regards,
On 2019/10/13 3:50, Abhishek Patil wrote:
Hello Morioka-san,
Thank you for incorporating our feedback and updating the slides based on our discussion during the September F2F.
I have a some more inputs on the topic:
1.The revised slides don’t address the issue of data injection by a rouge device (issue is discussed on slide #7 in 11-19/1675r0). Such an attack would overburden the clients as they have no way to differentiate between genuine eBCS data frames and injected (fake) frames until they receive the key. During such time an attacker could inject hundreds of frames.
2.Suggest removing slide #25 and limiting Tesla based authentication to streaming use-cases where the data is periodic. If we allow Tesla for irregular sequence, the client don’t have a way to know when to expect the next eBCS Data frames – as a result, the client would burn power listening to every frame in the medium to see if it is an eBCS frame from the AP.
3.On slide #19, a client device that just entered an eBCS AP’s neighborhood would need to wait for long period of time (order or several seconds) in order to review the 1st eBCS Info frame. Without any indication, the client would burn power listening for each frame on the medium. We need to think of ways to indicate the offset to the next eBCS frame.
Please let me know if you have any thoughts on the above items.
Regards,
Abhi
-----Original Message-----
From: ** STDS-802-11-TGbc -- Enhanced Broadcast Service ** <STDS-802-11-TGBC@xxxxxxxx> On Behalf Of Hitoshi MORIOKA
Sent: Wednesday, October 2, 2019 1:05 AM
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBC] eBCS frame authentication proposal uploaded
-------------------------------------------------------------------------
CAUTION: This email originated from outside of the organization.
-------------------------------------------------------------------------
Hi all,
I have uploaded a proposal of frame authentication.
Please review and give me feedback.
https://mentor.ieee.org/802.11/dcn/19/11-19-0451-05-00bc-ebcs-frame-authentication-proposal.pptx
Best regards,
--
SRC Software Inc.
Hitoshi MORIOKA (hmorioka@xxxxxxxxxxxx <mailto:hmorioka@xxxxxxxxxxxx>)
________________________________________________________________________
To unsubscribe from the STDS-802-11-TGBC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBC&A=1
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------!
---
To unsubscribe from the STDS-802-11-TGBC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBC&A=1
--
SRC Software Inc.
Hitoshi MORIOKA (hmorioka@xxxxxxxxxxxx)
________________________________________________________________________
To unsubscribe from the STDS-802-11-TGBC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBC&A=1