RE: [LinkSec] Requirements
Hi Paul,
> > 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
I think I agree that starting with 802.10 is the right place, too, because
it fits the way I think about the security problem. The reason for my
question is it is not evident to me that the group or the industry or the
market share my frame of mind, or 802.10 would have been demanded and
deployed and used in all 802 products long, long, ago. So one important
point to discover is why 802.10 is not being used and has not been deployed
and is not demanded, as this will shed light why we should have this work
done at the 802 level instead of 802.3.
-- 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.
My point was to try to get people to clarify the requirements. This
ultimately comes down to deciding whom one will try to protect from whom, as
the answer to this question implies the design center. Protocols that
protect everyone from everyone else are usually not interesting, because
they tend to be null. The point of security is to enforce the fact that
there are both plain-bellied and star-bellied sneeches.
This suggests a possible answer to my question above, of why 802.10 has not
been universally embraced. It suggests there cannot be a one-size fits all
solution acceptable to the market, because different players in the market
will have different sensitivities to compromise of their data. When security
technology gets deployed, it is because it is perceivd as helping someone
maintain an advantage over someone else. People are only willing to pay for
the security technologies that give them some advantage.
For instance, I believe IT departments have not deployed end-to-end IPsec or
802.10 in part because it transfers control over the activities in the
network from IT to the end users (strike one), and because these
technologies interfer with IT's ability ability to troubleshoot problems
with service--the packet sniffer is the troubleshooting tool of last resort
(strike two)--and because any real security scheme requires credentials and
access control management within the LAN, a new expense for most IT
departments, in that they have not had to manage network credentials before
(strike three). Providers that deliver content over EPON, on the other hand,
seems willing to pay for security over the EPON links, because prior to a
serious cost analysis, it appears to this market segment that security
technology can help protect their revenue stream without imposing an undue
cost burden, buy eliminating the delivery service as a compromise vehicle.
So at this point I guess I have argued myself into a radically different
position from that I started with: if we really need an 802-wide solution,
then we need to identify the tangible market problem that it solves, and it
seems to me no one has offered up one at this point.
This conclusion makes me very unhappy, because specialized security
solutions for this or that data link of necessity continually reinvent the
wheel. I expect that is why the SG has marching orders to find a "general"
solution. This in turn suggests that we haven't even grasped the problem
correctly. Perhaps what we really need is a way to design the security
primitives once, but reassemble them differently in all the gazillion
different market segments different people are willing to pay for?
-- Jesse