Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hello
Abhi, - "The Frame Count subfield is an unsigned integer, initialized to 0"
doesn't say when it's initialised, and this is behaviour not format. Also you don't need to say it's an unsigned integer as this is covered by the general conventions Abhi: The text was updated to be in-line with baseline (please see 9.4.2.198, 9.6.14.2, 9.8.5.3). In
TGmd, under CID 4512, our direction was to just say it once, through a general statement in 9.2.2.
I'll have to raise a TGme comment on deleting "is an unsigned
integer"s from Clause 9, but let's not add to it. But even if we keep the "is an unsigned integer", the "initialised to 0" doesn't say when it's initialised, and this is still behaviour not format. - I don't understand "The Frame Count subfield is 0 and the value in the
previously received EBCS UL frame (if any) is not less than or equal to 232 – 1." How can the value not be "less than or equal to 232 – 1",
since it's a 32-bit field?
Abhi: The text was previously updated based on your earlier comment.
I am pretty sure I did not request "less than or equal to 232 – 1"!
Now revised to “equal to 232 – 1 or less (within an acceptable range)”.
The following NOTE is updated as: I am not persuaded that "(within an acceptable range)" is adequate for replay detection.
- "NOTE—[…]an EBCS proxy implementation is expected to account for packet-loss when it performs a replay check."
is informative and cannot override the normative requirement to dump
the frame if
The Frame Count subfield is nonzero and is less than or equal to the value in the previously received EBCS UL frame (if any). or
The Frame Count subfield is 0 and the value in the previously received EBCS UL frame (if any) is not less than or equal to 232 – 1. So there's still a problem if we miss the frame with FC=0 after a wrap-around. Please spell out the rules for handling wrap-around of a replay counter. I'm not convinced wrap-around is compatible with replay detection… Abhi: The operation at the proxy is out of scope of the standard. As I mentioned in my previous email, a proxy implementation can take into account frame loss. A simple scheme could be to maintain a sliding window
(size x) [i.e., an acceptable range] in which the received FC is checked against a previously received frame (i.e., FC-x). If moving the forwarding behaviour to an EBCS proxy makes the behaviour out of scope of the standard, then I oppose moving the behaviour to an EBCS proxy.
I think it is important that we have a clear and solid replay detection specification, making it clear which forms of replay attack will remain possible, if any.
I'll repeat my earlier request to please spell out the rules for handling wrap-around of a replay counter. Thanks, Mark --
Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Hi Mark, I’ve addressed all your comments in the updated doc. I’ve attached a copy for your review. Also attached is a doc with my responses to your comments.
From: Mark Rison <m.rison@xxxxxxxxxxx>
CAUTION: This email originated from outside of
the organization. Thanks, Abhi. Close now, I think! Comments attached. Mark --
Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre
Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 ROYAUME UNI WWW:
http://www.samsung.com/uk From: ** STDS-802-11-TGbc -- Enhanced Broadcast Service ** <STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx>
On Behalf Of Abhishek Patil Hi Stephen,
Attached doc incorporates your inputs.
From: Stephen McCann <mccann.stephen@xxxxxxxxx>
CAUTION:
This email originated from outside of the organization. Abhi, Thanks for the updated submission. I've added some additional points in the enclosed. I've not reviewed the clause 4 text within this submission (305r1), as I think it's a duplicate
of submission 568r4. Kind regards Stephen On Wed, 21 Apr 2021 at 07:55, Abhishek Patil <appatil@xxxxxxxxxxxxxxxx> wrote:
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 |