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

[STDS-802-16] [Relay TG][MPDU Construction Adhoc] 4th teleconf minutes



Dear all:

Please find the attached minutes for the 4th teleconf of Relay TG MPDU construction adhoc.

Best regards,

Jeff

_________________________________________
 
Jeffrey Z. TAO, Ph.D.
Member of Technical Staff
Mitsubishi Electric Research Laboratories (MERL)
201 Broadway, 8th floor
Cambridge, MA 02139
 
P 617.621.7557
F 617.621.7550
E tao@merl.com
_________________________________________
Title: Minutes of the fourth Relay TG MPDU construction adhoc conference call

 

Minutes of the fourth Relay TG MPDU construction adhoc conference call

Wednesday April 25 2007

(13:00 GMT, 7:00 PDT, 8:00 CDT, 9:00 EDT, 21:00 P.R.C/R.O.C, 22:00 Japan)

 

 

Chair: Jeffrey (Zhifeng) Tao

 

Participants:

Kanchei (Ken) Loa

Hang Zhang

Yuefeng Zhou

Chie-Ming Chou

Mike Hart

Haihong Zheng

Yousuf Saifullah

Youn-Tai Lee

Seleznev Sergey

Guoqiang Wang (G. Q.)

Cancan Huang

D. J. Shyy

 

The meeting was started at 13:00 GMT on April 25 2007 and chaired by Jeffrey Z. Tao.  The meeting was primarily focused on the discussion of security implication of certain MPDU format design, and also the resolution of remaining comments.

 

1.     Roll call

Roll call was conducted at the beginning of the adhoc and participants listed above were identified.

 

2.     Contribution discussion

  1. Security implication of MPDU design
    1. K. Loa reiterated the general concern he had regarding the security implication of MPDU format design.

                                               i.     Protection of MPDU header for both management and data packet

                                             ii.     Protection of subheader

                                            iii.     Protection of the ACK message proposed in 07/285

    1. J. Tao noted that the tunnel definition in the current baseline revision 3 does not preclude the possibility of a tunnel-in-tunnel setting.  Nevertheless, it is yet to be confirmed whether this is the initial intent of the authors or it’s an artifact due to the language presentation.
    2. K. Loa explained that more security threat may be imposed, if a CID encapsulation type of format is used, wherein the forwarding is directly based upon the CID contained in the MAC header.  He further suggested entertaining the idea of having two levels of security.  One is at the individual MPDU level, using 802.16e security feature.  The other is at the tunnel header level.
    3. H. Zhang further raised the question of whether a RS can be trusted if it has been authenticated and admitted into the network.  She suggested that this is essentially a general question related to the security model assumed in the TG, and should be discussed in conjunction with security adhoc or in the TG.
    4. Y. Saifullah asked K. Loa if the security problem would still arise, if explicit path management method is used.  Or the security problem is only for the tunnel mode.
    5. H. Zhang argued that K. Loa’s concern is valid for every forwarding scheme in the current baseline, regardless of whether it is in the tunnel or non-tunnel mode.  In the explicit path management case, even though the routing table is established in a secure way, if the intermediate RS tampers with the CID in the MAC header, the traffic will still be routed to a different path.
    6. K. Loa stated that his intent is to initiate this discussion and make the floor aware of this potential security issue.  He still supported 09/198, which in fact can provide format support to additional security feature if needed at all.

 

  1. Security issue related to the ACK message proposed in 07/285
    1. Y. Zhou restated his concern that same level of security should be assured for both the management message and its associated acknowledgement.  However, the ACK message proposed in 07/285 does not have HMAC/CMAC.
    2. C. Huang clarified that this proposed ACK is an optional feature.
    3. M. Hart commented that it has not been explicitly stated in the current version of 07/285 that it is an optional feature.  Moreover, he suggested the authors to further specify in the contribution a signaling/negotiation procedure to enable and disable this optional ACK.  Also, it is desirable to have an exhaustive list of those management messages, for which this proposed ACK can be applied.

 

  1. Comments related to 07/267r2
    1. During the last teleconf, no sufficient time was given to the participants to review the updated version of this contribution.
    2. H. Zheng provided some comments to the authors on the mailing list after the last teleconf.  No final consensus has been built since then regarding this contribution.
    3. The authors of 07/267r2 are strongly encouraged to address the comments made by H. Zheng.

 

  1. Comments related to 07/256r1
    1. M. Chion provided some comments to the authors after the last teleconf on the mailing list.
    2. The contribution has been updated by the authors to address the comments.
    3. The new revision was uploaded to the server before this teleconf.

 

  1. Security issue related to QoS subheader proposed in 07/195r3
    1. H. Zhang et al. has split the 07/195r3 into 07/195r4 and 07/309, per the recommendation yielded in the last teleconf.
    2. H. Zhang stated that the security concern is applicable not only for this QoS subheader, but also for all other existent or new subheaders in 16j.
    3. H. Zheng argued that the security concern is particularly acute for this QoS subheader, as it will be read and used by all the intermediate RSs on the route.
    4. H. Zheng further questioned the efficacy and necessity of introducing such a QoS subheader.  On one hand, the 8 levels of QoS may not be sufficient for scheduler to make any meaningful decision.  On the other, the subheader may incur non-negligible overhead, as it will be carried by each and every MPDU.
    5. Y. Saifullah questioned that if the intention of introducing a QoS subheader is to reduce the complexity of scheduler at RS, a centralized scheduling approach may be a desirable alternative.
    6. H. Zhang questioned the practical feasibility and efficacy of centralized scheduling for an MMR network with more than 3 hops.
    7. J. Tao sought confirmation from H. Zhang that the 07/195 is intended for both tunnel and non-tunnel scenario.
    8. H. Zhang further clarified that the approach proposed in 07/195r4 can be considered as a special instantiation of tunneling mechanism, wherein only 1 transport tunnel connection is established between an access RS and the BS, instead of one transport tunnel connection per QoS requirement.

 

3.     Action items

1.     07/285

a.     The authors will explicitly state in the contribution whether the proposed ACK is optional or not;

b.     The authors will specify in the contribution a signaling/negotiation procedure to enable and disable this ACK, if it is an optional feature;

c.     It is also desirable to provide an exhaustive list of those management messages in the contribution, to which this proposed ACK can be applied.

 

2.     07/267r2

a.     The authors of 07/267r2 are strongly encouraged to address the comments from H. Zheng.

 

3.     07/256r1

a.     M. Chion will review 07/256r1 to assure the comments have been addressed by the authors.

 

 

The teleconference was adjourned at 15:10 GMT.