RE: [LinkSec] Failure of probe mechanisms to scale
Patrick,
(1) The data rate is that which is sufficient to sustain the referenced tens
of thousands of conversations. Typically this is a Gigabit these days or an
aggregated Gigabit, but does not have to be. You can do your own math on the
number of pps of a link of given technology needed to keep TCP sessions live
and the rate at which conversations have been seen once more if there is a
particular scenario you are keen on looking at/disputing. I just wish to
make the point that this number of active conversations are not uncommon in
today's networks. If you allow me a faster (few milliseconds)
reconfiguration time then the maximum probe rate is simply the line rate in
pps for a while - not something that works well.
(2) The processor speed is not the rate determining factor, the system
architecture and the scheduling rate of flexible tasks and driver dispatch
times typically are. The work involved here is most architectures is
typically done in a way that 'exeception' rather than 'fast path' packets
are treated. None of these systems is to my knowledge today built to sustain
these rates, if you have a credible vendor who is prepared to explain that
this is not a problem across their currently shipping range of bridges to be
secured I'd be fascinated.
Mick
-----Original Message-----
From: owner-stds-802-linksec@majordomo.ieee.org
[mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Pat
Kinney
Sent: Friday, April 25, 2003 12:25 PM
To: mick_seaman@ieee.org; 'LinkSec'
Subject: RE: [LinkSec] Failure of probe mechanisms to scale
Hi Mick
Could you elaborate on your email? What link data rate(s) were you
referring to? (1Mb/s, 10 Mb/s, 100 Mb/s?). What performance (clock
speed?) of processor in the bridge?
Thanks,
Patrick Kinney
-----Original Message-----
From: owner-stds-802-linksec@majordomo.ieee.org
[mailto:owner-stds-802-linksec@majordomo.ieee.org] On Behalf Of Mick
Seaman
Sent: Friday, April 25, 2003 2:58 PM
To: 'LinkSec'
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
> > >>
> >