Hello folks,
I continue to learn about the existing protocol and to infer
various
design guidelines. I have a lot of questions...
--> Are MIH_LL and MIH_N2N_LL messages
supposed to contain opaque LL
protocol messages?
==> If so, they need the
following additional information:
* Media
type
* LL
source+destination/MAC addresses
* Possibly
other framing fields which would encapsulate an
actual LL
message across a single link
==> If not, need an
explanation about relationship to LL
==> Anyway, these do not
fit readily into the design space
of
"SID/Opcode/AID" as detailed in Section 8.4.1 and Table 23.
--> The intention in Section 11.6 has
been enable L2-oriented signaling, but
still enable SPoS to
identify the TPoS and possibly also TPoA.
For this purpose:
==> UE has to be allowed
to provide hints to SPoS for the selection
various IEs from Table
G.1 (Information element identifiers)
containing
LINK_TYPE, DCD_UCD
values from Table F.10
(Data types for location)
values from Table F.11
(Value field format of PoA location ...)
values from Table F.14 (Network type and subtype representation)
--> The payloads specified for the key dissemination from
SPoS to TPoS and MN
are not specific to any link-layer
==> Probably need
alternate "MIH Message IDs" instead of MIH_*LL:
for example:
SPoS_MHTN_SA_ESTAB
SPoS_TNMH_SA_ESTAB
But I do not know the best way to
specify the parameters. According to the
payloads as currently proposed, it could be as follows,
depending on whether
or not the individual parameters are supposed to IEs
within an IE_CONTAINER
For the computed value, I can perhaps use ENCR_BLOCK:
Data type name:
ENCR_BLOCK
Description: (Key_x) XOR (PNG_x (PartnerID,
Nonce))
Derived from: OCTET_STRING
Primitive-style recipes:
SPoS_TNMH_SA_ESTAB.request
(
TransportType,
SourceAddress,
DestinationAddress,
MN_ID,
NONCE_VALUE,
ENCR_BLOCK,
)
SPoS_MHTN_SA_ESTAB.request
(
TransportType,
SourceAddress,
DestinationAddress,
TPoS_ID,
NONCE_VALUE,
ENCR_BLOCK,
)
IE_CONTAINER recipe:
SPoS_TNMH_SA_ESTAB
MN_ID, /* MN_networkaccessID */
NONCE_VALUE, /* nonce, see section .... */
ENCR_BLOCK /* K_tpos XOR computed_value */
SPoS_MHTN_SA_ESTAB TPoS_ID, /* TPoS
IP Addr */
NONCE_VALUE, /* nonce, see section .... */
ENCR_BLOCK /* K_tpos XOR computed_value */
MIH Message-style recipes:
SPoS_TNMH_SA_ESTAB:
MIH Header Fields (SID=Q,
Opcode=Q, AID=Q)
Source Identifier = sending
MIHF ID (Source MIHF ID TLV)
Destination Identifier =
receiving MIHF ID (Destination MIHF ID TLV)
MN_networkaccessID (MN_ID
TLV),
Nonce (NONCE_VALUE TLV),
/* see section .... */
Encrypted K_tpos
(ENCR_BLOCK) /* K_tpos XOR computed_value */
SPoS_MHTN_SA_ESTAB:
MIH Header Fields (SID=Q,
Opcode=Q, AID=Q)
Source Identifier = sending
MIHF ID (Source MIHF ID TLV)
Destination Identifier =
receiving MIHF ID (Destination MIHF ID TLV)
TPoS_ID
(TPoS_ID TLV),
Nonce (NONCE_VALUE TLV),
/* see section .... */
Encrypted K_tpos
(ENCR_BLOCK) /* K_tpos XOR computed_value */
Other questions:
Annex N:
- Is it necessary to have two rounds of
authentication and
establishing security
association with MN? Why does
Annex N figure 2 show
installing ky at MN for TPoA?
Isn't that key known as
MSPMRK? Shouldn't it be
derived from MIRK?
- Am not sure about the point of Annex N,
figure 4
= Need to rewrite the text to emphasize
derivation of MSMPRK from MIRK,
and verify that MSMPRK is
to be installed at TPoA as part
of the initial transaction
and exchange. MIRK is to be
transferred to MN, and
MSPMRK derived from MIRK.
==============================================================
Thanks for any advice. I expect to make a revision based on
the answers I get
to these questions and upload for comments ASAP.
Regards,
Charlie P.
Charlie
Perkins
华为技术有限公司
Huawei Technologies Co., Ltd.
Phone: +1-408-330-5305
Fax: +1-408-330-5000
Mobile: +1-408-421-1172
Email: charlie.perkins@xxxxxxxxxx
2330 Central Expressway
Futurewei Technologies Co., Ltd.
Santa Clara, CA 95050
http://www.huawei.com
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This
e-mail and its attachments contain confidential information
from HUAWEI, which
is intended only for the person or entity whose address is
listed above. Any use of the
information contained herein in any way (including, but not
limited to, total or partial
disclosure, reproduction, or dissemination) by persons other
than the intended
recipient(s) is prohibited. If you receive this e-mail in
error, please notify the sender by
phone or email immediately and delete it!