RE: stds-802-handoff: Par 5 Criteria Text
Alper,
Within 802, there is a substantial likelyhood that the 802 Handoff Study
Group will be placed in 802.1 which is also the group that is defining
the pan-802 security standards (802.1x, 802.1aa, linksec). So for layer
2 security, we will be in pretty close quarters with the people that
matter. Regardless of where we end up, we would be closely coupled with
802.1x/aa and linksec anyway, since they are part of the architecture in
which we are working.
IP level security is a broader subject and in my mind, where the
interesting interactions happen. My assertion has been that we should
make the right information available to devices to make appropriate
decisions on handoff. That information must include security related
information so that a device can include it in its handoff optimization
strategies or use it to implement a security policy. So in the context I
have been thinking, our problem might be one of quantifying and
representing types of security (That AP supports linksec, this AP
requires EAP-archie, ipass supported here etc).
There has been a pretty clear consensus in the group that as far as is
practical, we should leave security to the security groups and experts.
But that doesn't let us off the hook. We are in a position to compromise
security, to render ourselved incompatible with security mechanisms and
to fail to enable devices to do the security part of handoff right. So
we have something of a due dilligence requirement not to mess things up.
I like to think the wording lower down in this thread captures those
requirements and constraints but of course betters ideas for the text
are most welcome.
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: Alper Yegin [mailto:alper@docomolabs-usa.com]
> Sent: Monday, July 28, 2003 7:04 PM
> To: Johnston, Dj; Michael.G.Williams@nokia.com
> Cc: stds-802-handoff@ieee.org
> Subject: Re: stds-802-handoff: Par 5 Criteria Text
>
>
>
>
> I'm not too familiar with IEEE, but having been working on
> the IP-layer
> mobility and network access security at IETF, I can easily
> say setting the
> goal of maintaining the level of security during a handoff is
> necessary but
> not sufficient for this SDO. There is so much room (and need)
> to optimize
> the security aspects around handovers, I think this group
> would need to
> clarify how much (if any) would be done in this group. If
> security will be
> dealt in other groups, than there at least needs to be an
> almost formal
> communication channel between two. They should bring in their
> requirements,
> and understand the interfaces.
>
> My o.o2 cents.
>
> Alper
>
>
>
> On 7/28/03 6:13 PM, "Johnston, Dj" <dj.johnston@intel.com> wrote:
>
> > 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)
> >>
> >>
> >
> >
>
>