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

[REFORMATTED]: [STDS-802-21] More questions for 802.21(c) document revision



 

 

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.