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

More questions for 802.21(c) document revision



Hello folks,

I have made great progress after the recent discussions. I have some
more suggestions and additional questions.

- My current understanding about nomenclature is that
"internal signaling" in the signaling diagrams uses the '.'
(as in MIH_LL_Transfer.indication"), and inter-node
signaling does not (as in MIH_N2N_LL_Transfer Request).

- To emphasize this, I will use lower-case for the '.'-ed "signaling"
and upper case for the actual inter-node signaling messages,
e.g "MIH_LL_Transfer.request" vs. "MIH_N2N_LL_Transfer Request"

- Looking at Figures 14, 15, and 16 in document "802.21-2008-Updated",
I find mention of, e.g., "REQUEST FRAME". I understand this to
mean <MIH protocol header> as in Figure 21, with Opcode = 1.
There does not seem to be any explicit definition of the terms
"REQUEST FRAME" or "RESPONSE FRAME", nor any use of an
analogous "INDICATION FRAME".

- I have added another "fat bar" to the signaling diagram N.6.1 to
indicate the continuing process of preregistration.

- Note: must include TPoS PoS's address IE in description

- Having finally read section 10.2.1 in document 802.21a, I see that
what I was calling MSRK should really have been called MSPMK. MIRK
in 802.21c is the same as denoted MSK (rMSK) in Figure 47. The
goal in 802.21(c) should be to maintain compatibility with the
key derivation hierarchy in Figure 47. To this end, I propose:
= MSPMK be derivable from MIRK by the (already specified) algorithm
which can be computed by both TPoS and MN.
= MISK be also computed from MIRK as specified in section 9.2.2
(presumably including MIAK, MIEK, MIIK as needed by TPoS/TPoA)

- In Figure 44, section 10.2.1,
is it intended that each of MSPMK_a and MSPMK_b are to be used by
different candidate target PoSs?

- Which key will be used by MN for authentication with TPoA during
handover execution? Is it MIAK or MSPMK?

- Is there any need for MSRK to be different than MSPMK in the case
where there is only one candidate TPoS? In order to compute
MSPMK as specified, MN_LINK_ID is required. Can this be the same
as MNnetworkaccessID?

- It is intended that MN may keep its security association with TPoS
for the entire lifetime of the security association. I think that
the terminology MIRK is preferable to 'K' as shown in Figure 47.

- Is the method in 802.21c for symmetric key distribution also called
"bundled" proactive authentication? If so that term should be
referenced in the 802.21c SRHO document section 11.6

- For the authentication specified in section 11.6, the MN can rely
on SPoS to identify the TPoS. This requires some changes to the
language in section 10.1.1.1. Also changes in section 9.2.1.

- Need to specify a new IE or TLV for the SPoS to use
when sending MIRK to TPoS and to MN. Also need IE to identify
radio access technology type, but this may already exist.

- General idea:
= SPoS sends the following to TPoS
* MN_ID to TPoS
* Nonces
* MIRK in a new IE or TLV
= TPoS derives MISK=(MIAK | MIIK | MIEK) and MSPMK
* sends MSPMK to TPoA in a media-specific container
* sends MIH_N2N_LL_transfer Response to SPoS
* sends MNnetworkaccessID to SPoS
= SPoS sends the following to MN
* TPoS_ID
* MNnetworkaccessID
* Nonces
* MIRK in a new IE or TLV

=========================================================

In a few minutes, I will send out a substantially updated signaling diagram
incorporating some of the above ideas, with new descriptive text.

Your comments and suggestions are greatly appreciated.

Regards,
Charlie P.