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

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

Hi Mark,

Thank you for the discussion on this topic.

I had offline discussion with a few members and I have updated the replay protection logic to help address your concerns.

With the new changes, the spec would make Replay Protection a mandatory field with the following considerations:

If the device has time information, then the format of Replay Protection field is same as defined in D1.02:

32 bits for Time expressed in seconds (UTC from Jan 1^st 2020) + 32 bits of Frame Count (incremented for each transmission).

If the device doesn’t have accurate time information, then the frame count field expands to 64 bits (i.e., extension of the counter into the upper 32 bits).

64 bit field eliminates the wraparound condition.

A bit in the Control field signals the presence of Time subfield.

The attached doc provides the updated spec text (format changes to EBCS UL frame and normative behavior in clause 11).

In addition, the doc also resolves all pending CIDs assigned to me.

Could you please take a look and let me know if you have any feedback?

Regards,
Abhi

From: ** STDS-802-11-TGbc -- Enhanced Broadcast Service ** <STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx> On Behalf Of Mark Rison
Sent: Tuesday, April 27, 2021 4:30 AM
To: 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.

I think I oppose this direction. Wi-Fi has had enough security scares

that we don't want to line ourselves up for yet another one ("Many IoT

devices using the 802.11bc (EBCS) technology launched to great fanfare

last year are vulnerable to a so-called replay attack, allowing people

to cause spurious multiple micropayments!!!" or somesuch).

We need to be clear on how UL replay protection will work in 11bc

in the context of:

- frame count wrap-around at the transmitting non-AP STA

- non-AP STAs without a RTC

- limited or no replay counter caching at the receiving AP, for

unassociated STAs

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 Sadeghi, Bahareh
Sent: Tuesday, 27 April 2021 00:46
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBC] CR doc on pending comments in clause 9

Hello Abhi,

I have a few comments regarding the following paragraph:

The Replay Protection field is present and any of the following is true:

The Time subfield is set to a nonzero value and the difference between that value and the time the EBCS UL frame is received is greater than an acceptable value.
The Frame Count subfield is nonzero and is less than or equal to the value in the previously received EBCS UL frame (if any).
The Frame Count subfield is 0 and the value in the previously received EBCS UL frame (if any) is not equal to 2³² – 1 or less (within an acceptable range).

While the note that follows somewhat allows for implementation flexibility, I believe the normative text is too specific. There are multiple set of rules that can be used for replay attack detection, as you refer to in your email, and I do not believe we should get into the specifics and the window size for frame count that should be used. I would request combining b. and c. to the following text:

b. The difference between the value of the Frame Count subfield and the value in the previously received EBCS UL frame (if any) is outside a prespecified acceptable range. The calculation of the acceptable range is implementation specific and should account for the wrap-around of the Frame Control subfield and packet-losses that may occur.

And also modifying the note that follows 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.

NOTE – An EBCS proxy implementation can have a validity period for which it stores the last known Frame Count value for a certain transmitter.

Regards,

-bahar

From: ** STDS-802-11-TGbc -- Enhanced Broadcast Service ** <STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx> On Behalf Of Mark Rison
Sent: Monday, April 26, 2021 4:41 AM
To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: 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 2³² – 1."

How can the value not be "less than or equal to 2³² – 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 2³² – 1"!

Now revised to “equal to 2³² – 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).

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 2³² – 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