Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBC] CR doc on pending comments in clause 9



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:
NOTE – The acceptable time difference at an EBCS proxy can be configured based on local policies or based on relationship with the specified destination. In addition, an EBCS proxy implementation can have a validity period for which it stores the last known Frame Count value for a certain transmitter. Furthermore, an EBCS proxy implementation can maintain an acceptable range to account for packet-loss when it performs a replay check.

 

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>
Sent: Friday, 23 April 2021 17:28
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBC] CR doc on pending comments in clause 9

 

Hi Mark,

Thank you for your additional feedback.

 

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.


Regards,
Abhi

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Thursday, April 22, 2021 4:04 AM
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Cc: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-11-TGBC] CR doc on pending comments in clause 9

 

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
Sent: Wednesday, 21 April 2021 15:14
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBC] CR doc on pending comments in clause 9

 

Hi Stephen,


Thank you for reviewing the doc and providing additional feedback.

Attached doc incorporates your inputs.


Regards,
Abhi

 

From: Stephen McCann <mccann.stephen@xxxxxxxxx>
Sent: Wednesday, April 21, 2021 2:46 AM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBC] CR doc on pending comments in clause 9

 

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:

Hi Mark,

Thank you for reviewing the doc and providing feedback.


I have revised the content based on your inputs. In addition, I have also provided by responses to each of your comments in the attached file.

 

Could you please take a look at the attachments and let me know if you have additional feedback?

Regards,
Abhi

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Tuesday, April 20, 2021 7:08 AM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: RE: CR doc on pending comments in clause 9

 

CAUTION: This email originated from outside of the organization.

Thanks for this, Abhi.  I attach some comments on 21/0305.

 

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: ** STDS-802-11-TGbc -- Enhanced Broadcast Service ** <STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx> On Behalf Of Abhishek Patil
Sent: Monday, 19 April 2021 22:32
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBC] CR doc on pending comments in clause 9

 

Hi All,


I have prepared doc 11-21/0305 which addresses all the pending comments related to clause 9 that were assigned to me. The proposed changes are in-line with the text in doc 11-21/0568r4.

 

The excel file for the comments can be found here.

 

Regards,
Abhi


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


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