| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi, Dan, Thanks for your quick response. Please see my follow-up
response below. BR, Lei -----Original Message----- Hi Lei, On 5/7/13 9:47 AM, "Lei Wang"
<leiw@xxxxxxxxxxxxxx> wrote: >Hi, Dan, > >Thanks for reviewing the contribution 13/0469 > >Please see my responses below inline. > >BR, > >Lei > >-----Original Message----- >From: *** 802.11 TGai - Fast Initial Link Set-Up *** >[mailto:STDS-802-11-TGAI@xxxxxxxx] On Behalf Of Dan
Harkins >Sent: Monday, May 06, 2013 6:08 PM >To: STDS-802-11-TGAI@xxxxxxxxxxxxxxxxx >Subject: [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! ><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? Yes, the scalar is the size of the order of the group. >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? No, that's determined by the size of digest created by
H() which you know because you negotiated it. <LW>
negotiated it? When / how? Not clear to me, by reading Subsection 11.3.7.5 in
802.11-2012. Again, could you please point out the relevant text? Thanks. >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. You're just looking at fields that are variable and
raising issues. If you look into what is contained in the field and how the field is
created you will not have these issues. <LW>
I did look at the descriptions given in Subsection 11.3.4, in addition to frame
format in 8.3.3.11, still not clear to me. Again, your explanation is clear,
but could not found similar text in the current spec. Probably the current spec
text looks very clear to the original contributors and to those people who were
actively involved in the relevant text development discussions. > > 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. Yes, if you look in table 8-29 you will see that this
is only present when a TTP is used. And that's why I said "when an
Authentication frame used for FILS Authentication with a TTP...." So what's your
point? <LW>
Ok, the point is that, if it is not always included, then it should be encoded
as Information Element, not an Information Field, as any non-mandatory info
items in a MAC management should be self-identifiable. >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? 8.4.1.53, which describes the field in question, says
"The FILS wrapped data field is used for the STA and AP to communicate data used
by the FILS authentication algorithm." And, as we have just established above,
it is only used in FILS authentication when there is a TTP. The text in 11.11.2.2.1 describes
FILS Authentication with a TTP and how to populate this field. So I think the use of this
field is already pretty tightly constrained. <LW>
ok, your above answer basically tells me that this FILS Wrapped Data won’t
be extended to carry HLD (Higher Layer Data) as part of still on-going effort
of TGai group to complete the higher layer protocol data piggyback scheme. Ok
with me, no objection. >c) >If the FILS Wrapped Data is EAP packet, then why do
we just call it EAP >Packet field? I don't think the name is
the issue here. <LW>
cannot agree here. Wrapped Data indicates the MAC management frame processing
module passes it to other layer/module without a need to interpreter/decode its
contents; while EAP-Packet field or any other meaningful name can be used to indicate
the MAC frame management frame processing module decodes it as EAP-packet. Dan. > > 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 _______________________________________________________________________________ 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 _______________________________________________________________________________ |