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

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.
> 
> 
> 
>