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
- Security
implication of MPDU design
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Security
issue related to the ACK mechanism proposed in 07/285
- Y. Zhou restated his concern that same
level of security should be assured for both the management message and
its associated acknowledgement. However,
the proposed ACK header does not contain HMAC/CMAC.
- C. Huang clarified that the ACK
header proposed in 07/285 is an optional feature. Moreover, he provided several examples
in the current 802.16e, wherein MAC signaling header is used for
acknowledgment purpose. This
represents a tradeoff between the bandwidth saving and security.
- 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.
- Comments
related to 07/267r2
- During
the last teleconf, no sufficient time was given to the participants to
review the updated version of this contribution.
- 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.
- The authors of 07/267r2 are strongly
encouraged to address the comments made by H. Zheng.
- Comments
related to 07/256r1
- M. Chion
provided some comments to the authors after the last teleconf on the
mailing list.
- The
contribution has been updated by the authors to address the comments.
- The
new revision was uploaded to the server before this teleconf.
- Security
issue related to QoS subheader proposed in 07/195r3
- H. Zhang et al. has split the 07/195r3
into 07/195r4 and 07/309, per the recommendation yielded in the last
teleconf.
- 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.
- 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.
- 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.
- 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.
- H. Zhang questioned the practical
feasibility and efficacy of centralized scheduling for an MMR network
with more than 3 hops.
- J. Tao sought confirmation from H. Zhang that the 07/195 is
intended for both tunnel and non-tunnel scenario.
- 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.