Re: [STDS-802-16] [NETMAN_SG] Network Management Study Group

A lot of this makes good sense. Looking at it from a deployment point of view brings up the need for interfacing to existing networks and inter-technology hand-over, for example with WiFi. Many user related security issues should be the same between dot11 and dot16, at least for the mobile applications and probably for the fixed applications as well. Having the same solution, notably where the network side of things is concerned, would be very useful from the viewpoint of those who already operate WiFi networks.

In the case of dot11, the (external) AAA services and related protocol elements are part of the security spec rather then the Network Management spec. Would that model be useful here too?

Regards,

Jan

-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Johnston, Dj
Sent: 30 March 2004 02:04
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] [NETMAN_SG] Network Management Study Group

Here's my thoughts on what we might do with security:

There are arguably three (partially overlapping) layers to 802.16 mobile security, the link cipher (AES-CCM and DES-CBC), the local network entry and key management (PKM) and the interaction with network side AAA architectures (currently lightly defined but involving EAP).

Not withstanding the need for a more efficient secure link cipher (GCM based?) I believe the link ciphers are done for now. It would be prudent to wait for 802.1ae and others to go through the pain of specifying an authenticated encryption mode that is fast, efficient and secure (pick any two) before 802.16 attempts another upgrade. In the meantime, I think the actual requirements will become much more detailed as we gain deployment experience.

We know PKM to have a number of security flaws, albeit mitigated by the very high practical barriers to misuse that derive from the nature of P2PM high frequency fixed equipment. Rather than attempt incremental upgrades to security with backwards compatible delta changes to the PKM messaging, I suggest that we go for a separate PKMv2 with messaging aimed at the needs of mobile equipment. In the medium term there would be a rough alignment of fixed=PKMv1 and mobile=PKMv2. PKMv2 would have secure authenticated key exchange, mutual authentication, base certs etc., generally borrowed from current examples available elsewhere (802.11i, IETF). This would allow us to let the current PKMv1 go through without too much fuss and meet the needs of fixed equipment. Mobile equipment might have something that meets the needs of mobile operators with PKMv2.

PKMv2 could be done in 16e, A network management PAR or a security PAR. I think 16e is becoming a stretch and dealing with PKMv2 in a new PAR would remove a road block from the other mobility work in 16e.

The AAA network interaction is something tied into the nature of the networks 802.16 becomes part of. I see this as being right on track for a network management PAR.

So in summary..

Ignore link ciphers until a clear need for something new turns up.

PKM remains as it is, with a version 1 tag as per the current spec.

PKMv2 gets defined either in a network management PAR or a security PAR.

AAA is an integral part of a network management PAR.

Feedback is most welcome..

-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Chou, Joey
Sent: Monday, March 29, 2004 9:34 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] [NETMAN_SG] Network Management Study Group

Here is the list of items that can be included in the new Network Management PAR.

·    802.16 MIB for SS and BS, including fault management (e.g. fault notification, loop-back, …), account management (e.g. usage data capture, …), performance management (performance data capture), security management

·    Provisioned and Dynamic service flow creation models

·    Service deployment scenarios and models from the service provider perspective

·    Service flow context switching during BS – BS handoff from management perspective

·    Service flow context downloading while roaming into a network that belongs to the same of different service providers

·    SS management models (e.g. through the host, circuit city model, through the air interface, …)

Joey Chou

Intel Corporation

-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Johnston, Dj
Sent: Friday, March 26, 2004 7:53 PM
To: STDS-802-16@listserv.ieee.org
Subject: [STDS-802-16] [NETMAN_SG] Network Management Study Group

All,

We need to get moving on inputs to the network management study group. The goal I put forth to the WG is that we do our work before and during the May meeting, so this will require us to work some of the issues on the reflector and maybe have a conference call or two, if we are to produce a PAR and five criteria during the interim. If we don't have a workable basis for consensus going into the May meeting, then I expect we will be asking for an extention in July, and that is a long time, given that it would then be November before the TG request would be approved by the EC and NesCom would add more time to the process, so maybe we would be looking at 2005 before we had a group for real. Finishing in May is a good plan.

I propose that email directed to this effort has [NETMAN_SG] in the subject line to allow appropriate filtering.

The primary thing that led me to suggesting a study group was the plethora of different things people wanted to do with respect to network management, network architectures, interfaces, MIBs and so on and the rapid closure of .16d as a forum in which to address them. My personal wish list is no secret, you will find it in the comment databases - security, interfaces, MIBs.

So as a first step, I would like to request that people forth their ideas for what problems they think network management group or groups (don't let the name predjudice the function) should be solving, or what features they should be introducing. This will give us a list of issues that we can enumerate, sort, sift, rejig, classify and generally argue about until we can approach consensus on scope and purpose. But first we need the issues out on the table for all to see.

A potential benefit I suggested was that items of questionable scope in .16e might find a more secure home in a new group. This is not my idea and I have not been in the loop on these discussions (although I do like the idea), so perhaps it would be useful input for people who are thinking along these lines to start describing specifics of what bits in .16e are problematic and might benefit from a group with a clear scope to address them.

I'll make my suggestions in a separate email..

DJ

(chair 802.16 network management study group)