RE: [LinkSec] Consensus on Scope?
The timing of discovery can be very important in light of security and
authentication. For example, it might be nice to discover what network
service is out there in order to select an appropriate identity to
authenticate. This would imply running some signaling protocols prior to
authentication protocols.
Paul
-----Original Message-----
From: Dolors Sala [mailto:dolors@ieee.org]
Sent: Thursday, April 24, 2003 10:45 AM
To: Mats Näslund; LinkSec; Russ Housley
Subject: Re: [LinkSec] Consensus on Scope?
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
> > >>
> >