RE: [STDS-802-21] [REFORMATTED]: [STDS-802-21] More questions for 802.21(c) document revision
Charles,
May I suggest that you use the explicit term "message" or "frame"
in the names of those messages that go across the wire? E.g.,
MIH_N2N_LL_Transfer Request Message.
-Pete
Charles E. Perkins wrote:
>
>
>
>
> Hello folks,
>
>
> This is the same email that I sent out a few minutes ago, but with
> better formatting. I don't know why my previous email lost most of
> the white space...
>
>
>
> ============================================================
>
>
>
> 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.
>
>
>
>