| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi, Dan, Thanks for reviewing the contribution 13/0469 Please see my responses below inline. BR, Lei -----Original Message----- Hi Lei, I just read your document 11-13/0469r0 on the FILS
Wrapped Data element. I think there is a misunderstanding about how these
"variable" length fields are parsed. The element field is marked as
"variable" and does, indeed, end up in the middle of some other fields in a frame. But contrary to
your assertion, this is not a problem because the length of the field is inferred
by a fixed-length field that precedes the element, namely the finite cyclic
group. So what happens is the finite cyclic group is parsed (it is 2
octets in length) and the encoded group is looked up. Each group will have elements
in it that are a fixed length. If the AP doesn't understand the encoded
group then it won't know how big the element field should be but if it
doesn't understand the encoded group then it will fail processing
of the frame anyway (and reply with a status code of 77 per
11.11.2.2.2). So even though the element field is "variable", it is quite
easy to parse. I know, I wrote code that does it! <LW> I see your point,
and agree. Basically, for each value of Finite Cyclic Group field, there is a
corresponding “Element” field with a deterministic size. Since
different values of Finite Cyclic Group field may have different sizes of “Element”
field, the “Element” field in Authentication frames is a variable-size
field in general. Well, I have couple of follow-up questions below: a)
On page 435, in
802.11-2012 spec, Table 8-29, SAE with transaction sequence no. equals to 1, if
Status is zero, there are two variable-size fields, Scalar and Element. Your
above explanation tells how the “Element” field is decoded. Does the
same explanation work for decoding the Scalar field too? b)
Also, on page
435, in 802.11-2012 spec, Table 8-29, SAE with transaction sequence no. equals
to 2, the Confirm field is a variable-size field, following the same thinking, is
its size implied by the 2-byte Send-Confirm field? c)
Although your
above explanation is clear to me, I could not find similar text/info by just
reading the 802.11-2012 spec, including sections 8.3.3.11 and 11.3.4. can you
please point out the relevant text? Thanks. Similarly, the length of the FILS Wrapped Data
field can be determined without resorting to turning it into an Information
Element (and adding 2 more octets). That is because the field is, itself, an
EAP packet that has a parseable format. When an Authentication frame used for
FILS Authentication with a TTP has a transaction sequence
number of 1, the entirety of the FILS Wrapped Data field is a
EAP-Initiate/Re-auth packet whose format can be found in RFC 6696, in section 5.3.2,
Figure 9. There is no need to worry about a STA not knowing the format of
such a packet because if it didn't then it wouldn't know how to do FILS
Authentication with a TTP and if it didn't know how to do that then it
wouldn't be receiving such a frame in the first place. <LW> I see your point,
but for this one, I don’t agree based on the current 11ai draft spec, for
the reasons/questions below: a)
The FILS
Wrapped Data field is not always included in Authentication frames with
Authentication Algorithm equals “FILS”, as it is not needed for
FILS Authentication without TTP. b)
There are two
places in 11ai/D0.5, line 27 page 82 and line 42 page 82, talking about copying/extracting
“EAP-Initiate/Re-auth packet” into/from Wrapped Data field. It
means EAP packet can be a Wrapped Data, but it does not mean FILS Wrapped Data,
itself, is an EAP packet. If the TGai group agrees FILS Wrapped Data is EAP
packet, then at minimum, it should be clearly specified, i.e., FILS Wrapped
Data field is EAP packet as in RFC 6696. Well, during the previous 11ai
discussions, my understanding is that the higher layer protocol can also be
encoded as “Wrapped Data”, am I right? c)
If the FILS
Wrapped Data is EAP packet, then why do we just call it EAP Packet field? For these reasons, I am going to recommend that
your comment (as described in 11-13/0469r0) be rejected. I also advise
you against commenting on the TGmc draft (which you suggested in your
submission). regards, Dan. _______________________________________________________________________________ IF YOU WISH to be Removed from this reflector, PLEASE DO
NOT send your request to this CLOSED reflector. We use this valuable tool to
communicate on the issues at hand. SELF SERVICE OPTION: Point your Browser to -
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI and then amend your subscription on the form provided.
If you require removal from the reflector press the LEAVE button. Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________ IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand. SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button. Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________ |