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

[STDS-802-11-TGAI] document 11-13/0469r0



  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!

  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.

  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
_______________________________________________________________________________