Re: [STDS-802-21] IEEE 802.21c conf call on May 2, 2012 21:00 ET

["Charles E. Perkins" <charles.perkins@xxxxxxxxxxxxx>]

Hello folks,

I have made an initial review of the document from Yoshi, Rafael,
and Antonio:
    21-12-0020-03-srho-secure-key-distribution

Attached, please find my notes.  If time, I would like to discuss
some of these comments on the call this evening.

Regards,
Charlie P.


On 4/26/2012 6:34 PM, Junghoon Jee wrote:

Dear all,

 

The IEEE 802.21c conf call will be held on May 2, 2012  21:00 ET.

 

Agenda Item:

1. Proposal Discussion, “IEEE 802.21c Protocol Frame”

2. Proposal Discussion, “Secure Key distribution”

 

Please refer the following bridge information:

US number: +1.646.746.3029, Access code: 9639652

 

Best Regards,

Junghoon Jee

Chair of IEEE 802.21c TG

 

-- 
Regards,
Charlie P.

6.5.1	Information Element --->  6.5.1	Information Elements

defined --> as defined for

Table 1:
	IE_NET_CAPABILITIES
		This is a good idea.  Is it expected to have a
		separate document per access network media type?
	IE_SFF_TUNN_MGMT_PRTO
		What are the likely possibilities?  Is GRE the default?

MIHF_ID: is it a FQDN?

SFF_ID: is it a FQDN?

7.4.29.1.3	When generated
	... should it be to start pre-registration at tPoS?

"must rely"  -->  "must relay"

8.6.3.26	MIH_N2N_LL_Auth request:
	"Section (must be section)"



Should instances of SFF be changed (to something related to "Mobility Gateway")?
	idea: "MIMG" for Media-Independent Mobility Gateway

Section 9.2:
	The MIRK and the MIHF identifier of the MN that holds the MIRK are
	used as the symmetric key credentials for a symmetric key based EAP
	method

Does it have to be EAP?  What happens if 802.21c passes the key as part of
the LL_TRANSFER_REQ?

Section 9.2.2.1:
	Is the XOR-based delivery and derivation suggested previously
	a feasible alternative?

Section 9.2.2.2
	What is the origin of the algorithmic formulae on page 24?
	Compromising SPoS only compromised the key for MN on TPoS, not
		any other data on TPoS.

Section 11.4.2
	Need more precise citation for ANDSF

> "If the target POA’s are legacy POA’s lacking MICF support, the M-GW will
>  need other communication mechanism in order to proxy between the MN and
>  the target POA."

Wouldn't any such "other" mechanism qualify for "MICF support"?

Figure 9.7:
(1) First sentence is declarative.  (?)

As a more general point, can 802.21(c) support a SPoS MIGW function by
which the network identifies a candidate target network?  If so, then we
could have the following sequence:
- MN requests handover by sending Handover Request message to source MIGW
  = parameter specifies appropriate RAT(s)
  = optional parameters for policy constraints
- source MIGW consults location database, inserts appropriate IEs to MN's
  Handover Request message
- Upon reply by target PoS/MIGW, source MIGW appends appropriate information
  about target PoS/PoA to Handover Response message destined for MN

"target radio is of" --> "target radio has"

"POA" --> "PoA"  [?? (a global change)]

Proposal: change instances of ANDSF to be ALDB (Access Location Database)
except in places where the 3GPP module is explicitly intended.

Section 11.6.4.1

--> A good example of where OSFF (or SPoS or "source MIGW") should be allowed
    to identify the target network on behalf of the MN, in contrast to the
    statement:
    "If the MN does not know the IP address of the target 3GPP eNB,
     it will need at least something, such as the link-layer address,
     to identify the target 3GPP eNB."

Various figures, e.g., Figure 9.24:

Signaling is shown between the MN and the source network
	before the handover.  OK.
Signaling is shown between the MN and the target network
	after the handover.  OK.
Signaling is shown between the MN and the network infrastructure
	DURING handover.  For a single radio MN, how can this be??
	Should these be labeled "When Initiating Handover"...?

Section 11.7.:
	Reviewed and generally seems good, but terminology probably
	needs to be updated.  I'll try to submit a revised figure very soon.

Annex N.6 also reviewed.  Seems pretty good.  I'll review again to ensure
	consistency of detail.

An example is needed for particular network utilization, along the lines
of particular examples in, for example, sections 11.