RE: [LinkSec] Requirements
Hi Paul & Jesse,
One of the items for the group is to suggest where the group should be
located. I don't follow why we would want this group as an 802 working
group. It makes more sense to me as an 802.3 task group. The reasons are,
1) An 802 working group will take longer to provide a solution for EPON and
applying a solution for ethernet switches. This is because the group will
need to work on a general solution.
2) IMHO, the general solution will most likely not provide an adequate
solution for all of the 802 working groups. As Jesse mentions, the
different MAC layers have specific needs.
Dave H.
At 08:00 PM 12/10/2002, Paul Lambert wrote:
>Jesse,
>Thanks for the quick feed-back. Comments on your comments are in-line.
>
>Paul
>
> > -----Original Message-----
> > From: Walker, Jesse [mailto:jesse.walker@intel.com]
> > Sent: Tuesday, December 10, 2002 2:00 PM
> > To: Paul Lambert; stds-802-linksec@ieee.org
> > Subject: RE: [LinkSec] Requirements
> >
> >
> > Paul:
> >
> > A nice enough list to start the conversation. Here is some feedback.
> >
> > > My preliminary view of requirements.
> > >
> > > Paul
> > >
> > -- snip --
> > > 2) Layering
> > > a) Be applicable to multiple 802 MAC protocols
> >
> > To me this implies that protection for MAC-specific control
> > messages is out
> > of scope, since by definition MAC-specific messages do not run within
> > different MACs. Is that your intent?
>
>Well ... this group was founded to meet the needs of multiple MAC layers,
>so the question is how can you make the work applicable to multiple MACs?
>
>You can:
> 1) Just develop a 'frameworks'
> (why bother ...)
> 2) Develop a 'link layer' solution.
> (using or akin to 802.10)
> 3) Develop multiple MAC layer mechanism
> (not very generic)
> 4) Focus on authentication/key management
> (compable with MAC or Link or Framework)
>
>Now ... I believe that MAC level management protection can be solved in a
>couple ways:
> 1) Punt, why bother
> 2) Build MAC specific mechanisms
> 3) Create new MAC control signalling (not likely)
> 4) re-map some MAC layer management messages to a new protected layer
>
>I'm personally partial to a link layer solution (2) with management
>protection mostly ignored (punt) except for identified critical messages
>that could be re-mapped (4)
>
>But ... I digress on possible implemenations rather than requirements. I
>did not include protection
>
>
> >
> > -- snip --
> > > d) Protect broadcast/multicast traffic and protocols
> >
> > What kind of broadcast/multicast protection do you have in
> > mind? Clearly it
> > is not economically feasible to solve the general problem with
> > public/private key techniques, but it is not technically
> > feasible to use
> > symmetric keys to provide much more than a veneer without the
> > additional
> > assumption that none of the members of the group will ever violate the
> > common goals of the group, either maliciously or inadvertantly.
>
>
>Yes. This is a hard requirement. The group could remove this requirement
>for limited types of deployments ... for example, pure point-to-point
>deployments.
>
>I put this in for completness to start discussion. The trust assumptions are
>quite interesting as you point out. I believe that a useful keying
>mechanism could
>could be created to support multicast traffic. THis is an area that would
>greatly benefit for more specific requirements from real world installations
>that would gice us the types of multicast traffic that might be expected.
>
> >
> > -- snip --
> > > 4) Cryptographic Mechanisms
> > > a) Provide suitable algorithms for threat/performance
> > > environment of PONs
> >
> > Do we know what the threats are? From the EPON discussion, it
> > sounds like
> > the major threat is theft of service, i.e., protection of the service
> > provider from its customers. Within 802.11 the major threat
> > has been (only
> > partly tongue in cheek) the provider, so the emphasis of the problem
> > solution goes the other way around, how to protect customers from the
> > providers. Is there enough commonality of threats to meet the
> > already stated
> > goal of providing a single protocol across 802 environments?
> > I'm not sure
> > there is, which is why I am skeptical of the marhing orders
> > to find one
> > solution for all of 802. Just what segment of 802 are we
> > talking about?
>
>The main supports for this study group seem to be coming from this
>arena. Other specific requirements for the environment should be added.
>
>The environment is differnet from .11 ... If anything, the threat/risk
>evaluation could make the solutions simplier. It's a wired environment
>so some short-cuts might be considered. Also ... the data rates are very high
>and speed is a important consideration.
>
>
>Also 2e is a typo ... I suspect it was supposed to say something about
>vlans.
>
>Paul
Dave Halasz
Cisco Systems, Inc.
320 Springside Drive
Akron, OH 44333