[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
> > >>
> >