RE: [LinkSec] Failure of probe mechanisms to scale
Mick:
I think that you and Ken are not communicating.
An SDE-enabled bridge may be able to figure out that a spanning tree change
will impact some or all of the security associations to which it is a party.
Also, a security association may not be impacted in any way by a spanning
tree change. I envision a topology where SDE-enabled bridges are "in
front" of protected networks. In this topology, few spanning tree changes
have any impact on the security associations.
Russ
At 02:34 PM 4/25/2003 -0700, Mick Seaman wrote:
>Ken,
>
>No misunderstanding at all, every link in a spanning tree necessarily is the
>only way all the stations on one side of a link in the active topology
>communicate with all stations on the other side, so a network
>reconfiguration of a spanning tree typically moves all the stations from the
>point of view of at least one bridge.
>
>Mick
>
>-----Original Message-----
>From: owner-stds-802-linksec@majordomo.ieee.org
>[mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Ken
>Alonge
>Sent: Friday, April 25, 2003 2:06 PM
>To: mick_seaman@ieee.org; 'LinkSec'
>Subject: Re: [LinkSec] Failure of probe mechanisms to scale
>
>
>
>Mick-
>
>I think there may be a slight misunderstanding of the 802.10 Probe
>mechanism. A Probe is only issued when a conversation is attempted by an
>end entity and the lack of a Security Association between the sending end
>entity and the receiving end entity is discovered. Just because a network
>reconfiguration has occurred doesn't mean that even one Probe will be
>issued -- it depends on whether the population of end stations attached to
>an SDE-enabled bridge changes. End stations moving to a new SDE-enabled
>bridge will have to have new Security Associations established for it for
>its peer-to-peer communications.
>
>Ken
>
>----- Original Message -----
>From: "Mick Seaman" <mick_seaman@ieee.org>
>To: "'LinkSec'" <stds-802-linksec@ieee.org>
>Sent: Friday, April 25, 2003 2:57 PM
>Subject: [LinkSec] Failure of probe mechanisms to scale
>
>
> >
> >
> > Here is some data on scale from an earlier email ....
> >
> > Today's implementations of RSTP (Rapid Spanning Tree Protocol) can
> > reconfigure after failure in a few hundred milliseconds or better (I
> > consider two milliseconds per bridge in path to be achievable) in networks
> > where tens of thousands of conversations can be carried. That's a peak
>probe
> > issuance/response rate of ~10**5 per second. It is just such large
>networks
> > where the demand for security may be highest. The best bridges can (or
> > claim) to learn source addresses at line rate after reconfiguration, I
>don't
> > think anyone has an architecture which could issue/respond to probes at
> > anywhere close to that rate.
> >
> > Mick
> >
> >
> > -----Original Message-----
> > From: owner-stds-802-linksec@majordomo.ieee.org
> > [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Russ
> > Housley
> > Sent: Thursday, April 24, 2003 7:36 AM
> > To: Dolors Sala; Mats Näslund; LinkSec
> > 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
> > > > >>
> > > >
> >
> >
> >
> >