RE: [LinkSec] Requirements
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