Re: [STDS-802-21] Some questions about 802.21c document
I revised my answer in the attached file.
Yoshihiro Ohba
(2012/08/24 3:55), Charles E. Perkins wrote:
>
> Hello folks,
>
> While revising the document, I have compiled the following list of
> questions along with a few notes about various editorial changes
> I have made.
>
> Your comments will be greatly appreciated. I really need to
> have some reality check as I go along, and many things are
> not really very clear to me.
>
> I will post later today an intermediate version with my revisions
> on a public website and send a URL. The intermediate version
> is not guaranteed to be in a consistent state. My next task will
> be to fix up some of the diagrams, but to do that I need to
> install Visio which will take me a little while (even it is actually
> possible, which I have not verified).
>
> Regards,
> Charlie P.
>
Questions about 802.21-2008 etc.
- Why is the packet specification repeated between "primitives"
and protocol messages?
= Wouldn't the protocol message specification alone be sufficient?
[YO] There is no packet specification in primitives. Primitives define parameters but without assuming a specific encoding format. Parameters carried in MIH protocol messages are encoded using the “Binary Encoding Rule” defined in Table F.1 of 802.21-2008.
Also, some parameters that are carried in an MIH message but are not passed from/to MIH user are not listed in primitives.
- What is the rule about request/indicate/response/confirm?
= Annex N of 802.21(c) seems incompatible with ..-2008 Figure 17
[YO] The rule on use of ES primitives are described in Figure 14. The rule on use of CS pritmives are described in Figure 17. The rule on use of IS pritmives are described in Figure 20. I could not find a similar figure that explains the rule for service management primitves. We first need to determine which service (command service or service management service?) the MIH_LL_Transfer and MIH_N2N_LL_Transfer primitives used in Annex N of 802.21(c) belong to. If these primitives belong to CS, then I think Annex N of 802.21(c) compatible with Figure 17 of 802.21-2008.
- What is the purpose of MIH registration? Wouldn't pre-registration suffice?
[YO] Please see 6.2.4 of 802.21-2008. Pre-registration and MIH registration are different things.
- What about 9.2.2.1 Derivation of media independent session keys (MISKs)?
[YO] Actual text for 9.2.2.1 is described in 802.21a-2012.
- In section 9.2.2.2, why isn't L included as a "Fixed input value"?
[YO] I think L should be included as a "Fixed input value".
= Changed L to be 512 bits instead of 64 bytes so the arithmetic works.
[YO] Agreed.
= We should also specify that Nonce-T and Nonce-N are 32 bits
[YO] Why does a Nonce need to have a fixed length of 32 bits?
= The reason for step (b) is not clear
[YO] I think the inequation n > 2v -1 in step (b) is wrong. It sould be n > 2**v - 1.
= We should also specify that ID strings are not zero-terminated
[YO] Agreed.
= Changed MISK to be MIRK
[YO] Agreed.
= The meaning of concatenation is not clear unless each component
has a predictable length in bits (or bytes).
[YO] Which component has a non-predictable length?
- In section 11, the term "target radio" refers to a radio on the MN. This
will be confusing if people preconceive the "target radio"
to be part of the target PoA.
[YO] Agreed.
- Note section 11.4 is written without consideration of the Media-Independent
messaging.
- Should use PoA or POA consistently, and PoS or POS consistently.
[YO] Agreed, and it should PoA and PoS.
- Why "MiCLSAP" but "MICSAP"? Should use 'I' or 'i' consistently.
[YO] Agreed.
- In Figure 11.3, it would be nicer to have MICSAP on top instead of on the side
[YO] It's up to Editor.
- Sections 11.4.{5-7} seem very repetitive, and basically just say that the MN
can communicate with remote SRCFs if the IP address is known, and shows
various representations of the encapsulation. I'm pretty sure this
is largely unnecessary.
[YO] I fully agree with you that most of these sections are not necessary.
- Why are Annexes A and B red?
- What is the MICF/SRCF port number?
[YO] It's 4551. (cf: RFC 5677)
- If the term "SRC frame" is used, it should be defined somewhere. Why not
just use "MICF frame"?
[YO] Agreed.
- The terminology in section 11.6.1 should be made to be consistent with the
terminology in the TLVs listed for the MIH_LL_Transfer et al.
message names. I am continuing to do this.
- I have tried to italicize most of the single-character variable names,
but I don't think any of the subscripts should be italicized
- In Figure N.6.1:
--> How to get the caption to actually read N.6.1?
--> Shouldn't TPoA be on the right side of TPoS?
[YO] I am ok with either way.
--> MN.MAC is not used
[YO] You are right. Some internal communications between MN.MAC and MN.MIH_user may need to be added.
--> Are "internal" communications really helpful to understand?
==> Other diagrams use function blocks for such things
(i.e., rectangle with legend such as "Processing")
[YO] I think so.
--> Need to identify various TLVs at each step
--> MSRK should NOT be chosen by SPoS, but instead chosen
by TPoS and sent to TPoA
[YO] I don't understand this. How TPoA can compute MSRK prior to establishing
a key hierarchy with MN?
==> ... and sent to MN also?!
==> ... or alternatively MN must know how to compute.
[YO] If EAP-based authentication is used for MIH service access authentication between
MN and SPoS, then MSRK is computed using the algorithm defined in 10.2.1.1 of 802.21a-2012.
--> "LL Frames sent to TPoA" is not very informative. How about:
"Set up TPoA to facilitate link establishment with MN"
[YO] The suggested text looks confusing. How about this: "LL frames are sent to TPoA to establish a link between MN and TPoA"?
--> How is MNID different from MNnetworkaccessid?
[YO] It is explained in Annex P. MNnetworkaccessid is used for media-specific authentication. MNID is MIHF-ID of MN and used by the MIH protocol. The two IDs are different regardless of whether the MN can directly contact TPoS or not.
- Note that MN can directly contact TPoS even if TPoS is not the same as SPoS
It could be that MN was recently in contact with TPoS and has all
the necessary security association, and so forth.
- Suggestion: "MIHF_spos" might be better than "SPoS's MIHF", etc.
[YO] Which part are you referring to?
- Suggestion: what about renaming TMGW to be TPoS, etc.
==> and, K_tmgw to be K_tpos, etc.
[YO] Agreed.