RE: [LinkSec] Requirements
Jesse,
At 07:41 AM 12/11/2002 -0800, Walker, Jesse wrote:
>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),
If one end control of IPSec can be in the hands of users, then why giving
other end
to users is so bad? If doing that has scalability (or is it practical)
issue then it is IPSec
design flaw, no?
>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)--
Since this troubleshooting tool may be a threat too, that may be one of the
reasons
IT would not want sniffers around on the LAN, only the authorized ones, no?
>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.
If I look around seriously then it seems that re-inventing or not in most cases
things and ideas are being re-used from one standard to another and security
is not an exception. Though in each case the re-used stuff is adapted to
best suit
the protocol/application.
>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?
From encryption and MAC algo. point of view it is true and what you mentioned
above is what I see happening, whereas security protocol design goes I guess
design core primitives once and adaptable for all may not be a realistic
goal as
the challenges and issues are similar to designing any other protocol, no?
Thanks,
Sanjeev
>-- Jesse