RE: stds-802-handoff: Par 5 Criteria Text

["Johnston, Dj" <dj.johnston@intel.com>]

I agree. I expect that we will have to deal with security related
information even if we are not defining any core security protocols or
algorithms. The trick would be to say that we are allowed to do just
that while putting a bar on doing things like authentication procotols
that would collide with other parts of the 802 architecture.

I think I still like the first sentence:
  "Consideration will be made to ensure that compatibility is maintained
with 802 security mechanisms including 802.1x"
Since it seems to be something we must do.

But as you point out:
  "Neither security algorithms nor security protocols shall be defined
in the specification."
Is clearly wrong.

How about a couple more clarifying sentences added to yours..

"Security will be based on interworking effectively with existing 802
security standards. The standard will not define unecessary encryption
or authentication algorithms or protocols."

Gluing it together and tweaking a bit gives..

"Consideration will be made to ensure that compatibility is maintained
with 802 security mechanisms including 802.1x. Security will be based on
interworking effectively with existing 802 security standards. The
standard will not define unecessary encryption or authentication
algorithms or protocols. The security of the mechanisms defined in this
standard will be at least as strong as the mechanisms of the underlying
802 technologies."

Thoughts?

DJ


David Johnston
Intel Corporation
Chair, IEEE 802 Handoff ECSG

Email : dj.johnston@intel.com
Tel   : 503 380 5578 (Mobile)
Tel   : 503 264 3855 (Office)

> -----Original Message-----
> From: Michael.G.Williams@nokia.com 
> [mailto:Michael.G.Williams@nokia.com] 
> Sent: Monday, July 28, 2003 10:43 AM
> To: Johnston, Dj; stds-802-handoff@ieee.org
> Subject: RE: stds-802-handoff: Par 5 Criteria Text
> 
> 
> Hi DJ,
> 
> Could we express the security portion of the scope in a more 
> "positive" way, instead of : 
> 
> Consideration will be made to ensure that compatibility is maintained
> with 802 security mechanisms including 802.1x. Neither security
> algorithms nor security protocols shall be defined in the 
> specification.
> 
> Something like:
> 
> Security of the mechanisms defined in this standard will be 
> as strong as the mechanisms of the individual 802 technologies. 
> 
> Without a comprehensive matrix, we can't say that all the 
> technologies offer the same security at L2, or even 
> equivalent security. It might be that information exchange 
> between two technologies will involve a reduction in 
> security. It might be appropriate for this standard to 
> provide indicators that such a change in security is 
> occurring. This could be construed as a security algorithm or 
> protocol.
> 
> Best Regards,
> Michael
> 
> -----Original Message-----
> From: ext Johnston, Dj [mailto:dj.johnston@intel.com]
> Sent: Sunday, July 27, 2003 9:53 PM
> To: stds-802-handoff@ieee.org
> Subject: stds-802-handoff: Par 5 Criteria Text
> 
> 
> 
> I would like us to make some progress on the text of the PAR and 5
> criteria.
> So far I have thought up text for 4 critera and I welcome 
> input on those
> or suggestions for the remaining one (economic feasibility).
> 
> We have agreed on draft text for the purpose and scope with the
> intention of tweaking on this reflector and approving them in Denver.
> 
> So here they are as they currently stand. The text inserted in the PAR
> form is encapsulated in [] to distinguish it from the PAR form text:
> 
> Scope
> -----
> [
> The scope of this project is to develop a standard that shall define
> mechanisms that may be adopted into implementations so that handoff of
> handoff-capable upper layer entities, e.g. MobileIP sessions, can be
> optimized between homogeneous or heterogeneous media types both wired
> and wireless, where handoff is not otherwise defined.
> Consideration will be made to ensure compatibility with the 802
> architectural model.
> Consideration will be made to ensure that compatibility is maintained
> with 802 security mechanisms including 802.1x. Neither security
> algorithms nor security protocols shall be defined in the 
> specification.
> ]
> 
> Purpose
> -------
> [
> The purpose of the project is to
> 	a) facilitate the optimization of handoff between networks that
> may be of different media types both wired and wireless, 
> where 802 level
> handoff is not otherwise defined 
> 	b) to make it possible for mobile devices to perform seamless
> handoff where the network environment supports it.
> This will improve the user experience of mobile devices by 
> improving the
> available network coverage through the support of multiple media types
> and preventing the interruption of upper layer sessions 
> during handoff.
> ]
> 
> 5 Criteria
> ----------
> Criteria #1: Broad Market Potential
> A standards project authorized by IEEE 802 shall have a broad market
> potential. Specifically, it shall have the potential for:
> 
> a) Broad sets of applicability.
> [
> An 802 handoff standard would be applicable to 802 media types, both
> wired and wireless. For example handoff between 802.3 and 
> 802.11 within
> a single device is a plausible application of such a standard.
> ]
> 
> b) Multiple vendors and numerous users.
> [
> A key requirement for generalized seamless handoff is that handoff can
> occur between administrative domains, and between different
> technologies. Thus the standard will be applicable to vendors 
> of network
> services as well as vendors of multiple equipment types.
> A wide variety of vendors currently build numerous wired and wireless
> products for the network equipment market segments.  It is 
> expected that
> the majority of those vendors, and others, will participate in the
> standards development process and subsequent commercialization
> activities.
> ]
> 
> c) Balanced costs (LAN versus attached stations).
> [
> The likely mechanisms through which 802 handoff can be achieved are
> message passing protocols that are implemented within 802 compatible
> devices. Handoff mechanisms common in existing mobile systems, such as
> 802.11 and cellular systems indicate that software will be the most
> common implementation medium for these protocols. This is unlikely to
> represent a major factor in the unit cost of networking 
> devices adopting
> a handoff standard, whether for LAN equipment or attached stations.
> ]
> 
> Criteria #2: Compatibility
> IEEE 802 defines a family of standards. All standards shall be in
> conformance with the IEEE 802.1 Architecture, Management and
> Interworking documents as follows: 802. Overview and Architecture,
> 802.1D, 802.1Q and parts of 802.1f. If any variances in conformance
> emerge, they shall be thoroughly disclosed and reviewed with 802.
> Each standard in the IEEE 802 family of standards shall include a
> definition of managed
> objects which are compatible with systems management standards.
> [
> The proposed standard is contrained by its scope to maintain
> compatibility with the 802 architecture. The work of the 802 Handoff
> ECSG has failed identified any potential conflicts with the 802
> architecture. 
> ]
> 
> Criteria #3: Distinct Identity
> Each IEEE 802 standard shall have a distinct identity. To 
> achieve this,
> each authorized
> project shall be:
> a) Substantially different from other IEEE 802 standards.
> b) One unique solution per problem (not two solutions to a problem).
> c) Easy for the document reader to select the relevant specification.
> [
> There are no handoff standards in 802 that are focussed on 
> facilitating
> optimized handoff of entities above the LLC by providing the necessary
> services and information within the MAC or PHY. 
> ]
> 
> Criteria #4: Technical Feasibility
> For a project to be authorized, it shall be able to show its technical
> feasibility. At a minimum, the proposed project shall show:
> a) Demonstrated system feasibility.
> [
> Handoff is a common mechanism, present in many systems such as cell
> phones or 802.11 ESSs. Mobile IP, in both v4 and v6 forms, has shown
> that roaming across heterogeneous systems is possible. Work 
> in the IEFT
> SEAMOBY and TRIGTRAN projects has highlighted the need for greater
> interaction between 802 MAC and PHY layers and a roaming layer 3 in
> order to coordinate smoother, faster handoffs. Accordingly it is clear
> that roaming within the confines of different 802 technologies is
> feasible and that approaches that might be adopted for 
> roaming at higher
> layers are feasible. Since the IETF has published in draft 
> form, a role
> that 802 networks can play in higher level of handoff it is clear that
> it is possible incorporate such mechanisms into the 802 framework.
> ]
> b) Proven technology, reasonable testing.
> [
> The proven ability to handoff within 802.11 networks, within 
> cell phone
> networks and within the internet, using mobile IP has proved a minimum
> set of capabilities for roaming technologies.
> The nature of message passing protocols is such that the timing and
> passage of the messages is subject to observation and testing. Methods
> of testing interruptions to established sessions while being 
> handed over
> (such as voice bearers) are well established in telephony and VoIP
> practices. 
> ]
> c) Confidence in reliability.
> [
> Mobile IP, cellular systems and 802.11 provide real world examples of
> reliable handoff mechanisms using diverse techniques. Thus it is
> feasiblr for 802 handoff mechanims to also be reliable.
> ]
> 
> Criteria #5 Economic Feasibility
> For a project to be authorized, it shall be able to show economic
> feasibility (so far as can reasonably be estimated), for its intended
> applications. At a minimum, the proposed project shall show:
> a) Known cost factors, reliable data.
> b) Reasonable cost for performance.
> c) Consideration of installation costs.
> [ TBD ]
> 
> 
> Thanks,
> DJ
> 
> David Johnston
> Intel Corporation
> Chair, IEEE 802 Handoff ECSG
> 
> Email : dj.johnston@intel.com
> Tel   : 503 380 5578 (Mobile)
> Tel   : 503 264 3855 (Office)
> 
>