RE: [LinkSec] Requirements
Comments in-line.
At 03:35 AM 12/11/2002, Romascanu, Dan (Dan) wrote:
>David,
>
>Here are a few counter-arguments:
>
>1) 802.3 has declined in the past assuming the responsibility of starting
>such a work. At least part of the reason was that 802.3 felt it does not
>gather a critical mass of security expertise to deal with the multitude of
>issues and implications related to cryptography, authentication, and other
>similar technologies.
{DEH} It sounds like you're saying 802.3 can not justify this work being
done. If this is true, my suggestion is that the whole effort be dropped.
This is because the majority of the people asking for the work are out of
802.3. When the "802.3" people were asked they said, "Yeah, lets create a
general solution". It sounds like, "My Mom says I can't play this game in
my backyard, so how about if we do it in yours."
>2) In the New Orleans and Kauai meetings participants from several
>companies (including mine and yours - ask Norm Finn) expressed the view
>that it would be much easier to draw the attention of the security experts
>home if the scope of the work and targeted solutions would cover a broader
>range of technologies, rather than a narrow EPON scope
{DEH}I agree.
>3) The argument was made that a myriad of 802 architectural issues is
>involved, competing with the complexity of the technology issues.
>
>I agree that a 802 working group may take longer to specify a EPON
>solution. Minimizing this risk should be a goal of the future activity to
>be chartered. The advantage of defining a framework that includes the
>generic architectural principles and common technologies where possible,
>while allowing for focused MAC-specific development where needed is IMO a
>fee worth paying.
{DEH}I think this is where the I have a different opinion. imho, "defining
a framework that includes the generic architectural principles" will lead
to either a) an insufficient solution... so why bother making the solution
generic or b) a much longer than expected timeline
Dave H.
>Dan
>
>
> > -----Original Message-----
> > From: David Halasz [mailto:dhala@cisco.com]
> > Sent: Wednesday, December 11, 2002 5:37 AM
> > To: Paul Lambert
> > Cc: Walker, Jesse; stds-802-linksec@ieee.org
> > Subject: 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
> >
Dave Halasz
Cisco Systems, Inc.
320 Springside Drive
Akron, OH 44333