RE: [LinkSec] Failure of probe mechanisms to scale
Russ,
The point is that some changes in the core of the network will see a lot of
changes. My focus is on securing these links as well, not just those at the
edge of the net. I don't want a separate, not to be specified, mechanisms to
cover these core links. If SDE-enabled bridges are in front of protected
networks, what is protecting the internals of these networks? These
networks often have their fiber routed through patch panels not under the
direct physical lock and key of the network provider but of the colo
operator (your security mileage may vary).
If your answer is that SDE associations are always tunneled across networks
then I have other technology today I can use - with much pain and manual
configuration so it is not really adequate but its problems are tunneling
problems.
I'd be interested in how you propose that an SDE bridge may be able to
figure out what security associations are to be affected. In cases other
than the SDE bridge being the edge bridge of the network I don't regard this
as possible in bridge networks as currently defined.
Mick
-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com]
Sent: Tuesday, April 29, 2003 12:19 PM
To: mick_seaman@ieee.org; 'Ken Alonge'; 'LinkSec'
Subject: 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
> > > > >>
> > > >
> >
> >
> >
> >