Re: [LinkSec] Consensus on Scope?
Dolors:
If we only ever consider the very simple link-by-link case, we might create
a solution that does not accommodate the alternatives. I think that Mats
and I have already said that ...
Russ
At 01:45 PM 4/24/2003 -0400, Dolors Sala wrote:
>Russ,
>
>If the only issue is peer discovery, isn't this signaling that can be
>specified (or selected) any time? if so, what is the problem (or your
>concerns) in doing it later and start with a link solution?
>
>Dolors
>
>----- Original Message -----
>From: "Russ Housley" <housley@vigilsec.com>
>To: "Dolors Sala" <dolors@ieee.org>; "Mats Näslund"
><mats.naslund@era.ericsson.se>; "LinkSec" <stds-802-linksec@ieee.org>
>Sent: Thursday, April 24, 2003 10:36 AM
>Subject: Re: [LinkSec] Consensus on Scope?
>
>
>Dolors:
>
>I think that the only contentious issue is peer discovery. Mick and others
>have said that the probe approach specified by 802.10 does not scale. No
>convincing argument has been presented. So far, it is just emphatic
>assertion with the promise of a more complete discussion some time over a
>beer. I observe that the probe approach is not all that different than
>ARP, so it cannot be too badly broken.
>
>The link-by-link approach completely avoids peer discovery. However, I am
>not convinced that this approach really resolves any important
>problems. It seem to me that the device that is implementing the security
>protocol will be placed in the hands of the customer. If the customer
>messes with it, can all traffic be exposed. In an end-to-end scheme, the
>key needed to expose neighbor traffic will not be present, significantly
>reducing the motive for messing with the box.
>
>Russ
>
> At 07:01 AM 4/23/2003 -0400, Dolors Sala wrote:
> >Russ, Mats,
> >
> >I understand your concerns but we need to identify a work plan to make some
> >progress towards the current needs represented by the interests and
> >participation in the group.
> >
> >It seems to me there is significant interest in working on the link-by-link
> >protection, and very little interest on the end-to-end security solution
> >right now. If this interest is correct, we need to work on how we can
> >characterize this first effort so that it addresses the immediate needs
> >and is an step forward towards a unified architecture. It would be
> >great if you can prepare material on the needs imposed by the unified
> >architecture to the link solution.
> >
> >My specific suggestion or question was to explore if it is possible to
> >characterize the unified architecture in a set of requirements that can be
> >imposed to the link solution. Another way to express this could be.
> >
> >Let's say that the unified end-to-end solution defines a complete
> >"link-layer security architecture". A link-layer solution would cover a
> >complete L2 network security solution including the secure bridge network
> >and the single link secure communication. But we would like to focus
> >just on the single link solution component. So we need to define
> >a link security architecture solution
> >with the right hooks so that it is possible to build a complete link-layer
> >solution on top of it. What is the best way to characterize these hooks? Is
> >a list of requirements enough? if so, what are the requirements we would
> >like to impose to the link security architecture?
> >
> >Russ, based on 802.10 and other IEEE security experiences,
> >can you recommend a list of requirements or other form of material
> >to capture this characterization?
> >
> >We need a framework expressing the extendibility needs of the link
>solution.
> >Any material or contribution on this respect will be very helpful.
> >
> >Dolors
> >
> >
> >
> >
> >----- Original Message -----
> >From: "Mats Näslund" <mats.naslund@era.ericsson.se>
> >To: <stds-802-linksec@ieee.org>
> >Sent: Wednesday, April 23, 2003 3:58 AM
> >Subject: Re: [LinkSec] Consensus on Scope?
> >
> >
> > >
> > >
> > > Hi,
> > >
> > > I completely agree. Since the general bridged architecture
> > > is considered difficult to handle, I am slightly worried that
> > > corners will be cut so that later extensions beyond link-by-link
> > > protection becomes cumbersome (or even impossible). It could thus
> > > be that we need to "almost" solve also the general case at the
> > > same time to be future proof.
> > >
> > > Best,
> > >
> > > /Mats
> > >
> > > Russ Housley wrote:
> > > > Dolors:
> > > >
> > > > I do not have any problem with the priorities. However, I do have
>some
> > > > concerns with the "do it later, if needed" tone. If we look at 802.1X
> > > > development, it focused on 802.3 problems. This solved real-world
> > > > problems. Since a 802-wide view was not applied from the beginning,
> > > > significant changes are needed to make it work in 802.11, and other
> > > > wireless technologies.
> > > >
> > > > If we do not start with the big picture, we will inadvertently make
> > > > deployment in other topologies impossible without changes to the
> >standard.
> > > >
> > > > Russ
> > > >
> > > >
> > > > At 09:10 PM 4/21/2003 -0400, Dolors Sala wrote:
> > > >
> > > >> There seems to be significant consensus in leaving the scenario of
> > > >> untrusted bridges for a later stage (although the final unified
> > > >> architecture should support a complete secure bridge network
> > > >> solution). It seems we may be close to identify the scope of the
> > > >> initial project.
> > > >>
> > > >> In the last call, Bob Moskowitz recommended to initially focus on the
> > > >> link level and leave the entire bridge network definition for a later
> > > >> stage. If I interpret him correctly, he considers that there is
>enough
> > > >> work in defining the provider side of the link security specification
> > > >> because it doesn't exist an specification or example from where we
>can
> > > >> leverage from. This work would involve to specify the
>(bi-directional)
> > > >> authentication and the link protection components of the unified
> > > >> architecture. Bob please clarify or extend as you feel appropriate.
> > > >>
> > > >> We would need to guarantee that the initial effort defines components
> > > >> that fit the unified and general architecture. Could we guarantee
>this
> > > >> by imposing a set of general requirements to an initial link
> > > >> specification?
> > > >>
> > > >> If so we could define a gradual roadmap where we focus first on the
> > > >> link components and later on the bridged network components. We could
> > > >> first focus on capturing a complete set of requirements from the
> > > >> unified architecture and define an initial project to specify a link
> > > >> security for 802.3 links. At a later stage, additional projects would
> > > >> be defined to complete the architecture for bridged networks (and/or
> > > >> other links if needed).
> > > >>
> > > >> I would like to solicit opinions and comments on this roadmap
>approach
> > > >> and recommendations on the specific scope and components of an
>initial
> > > >> project.
> > > >>
> > > >> Dolors
> > > >>
> > >