Re: [LinkSec] Failure of probe mechanisms to scale
Ken -
That is not what you wrote. You stated that Bridges A and B had an existing
SA (for X, Y), and that B subsequently determines that it doesn't have an
SA (for X, Y) anymore. The missing part of your description is simpy put:
"How does B make this subsequent determination?".
I believe this was essentially the same question Mick was posing: in the
general case, how does Bridge X (that has established a number of SAs)
determine which of those SAs are still valid following any given network
reconfiguration?
Regards,
Tony
At 10:04 30/04/2003 -0400, Ken Alonge wrote:
>Tony-
>
>A bridge has what we termed a Security Management Information Base (SMIB) --
>a glorified MIB -- which holds all of its current SAs. In the case I
>presented, Bridge B would not have an SA with Bridge A for the pair of
>Stations X & Y.
>
>Ken
>----- Original Message -----
>From: "Tony Jeffree" <tony@jeffree.co.uk>
>To: "Ken Alonge" <kenneth.alonge@verizon.net>
>Cc: <mick_seaman@ieee.org>; "'Russ Housley'" <housley@vigilsec.com>;
>"'LinkSec'" <stds-802-linksec@ieee.org>
>Sent: Wednesday, April 30, 2003 9:41 AM
>Subject: Re: [LinkSec] Failure of probe mechanisms to scale
>
>
>Ken -
>
>My reading of Mick's question was not "what does Bridge B do when it has
>figured out that it doesn't have an SA", but "How does Bridge B figure out
>that it doesn't have an SA". I think you answered the former, not the
>latter.
>
>Regards,
>Tony
>
>At 09:26 30/04/2003 -0400, Ken Alonge wrote:
>
> >Mick-
> >
> >I believe the way we envisioned that a broken security association (SA)
> >would be discovered (and Russ will correct me if I'm wrong) is as follows:
> >
> >Bridge A had an existing SA with Bridge B for Stations X and Y (X is
> >attached to A and Y is attached to B). Station Y has been moved to Bridge
> >C. Bridge A sends a protected frame to Bridge B on behalf of Station X,
> >destined for Station Y. Upon receipt of the frame at Bridge B, Bridge B
> >determines that it does not have an SA for Stations X & Y and returns an
> >error to Bridge A. Bridge A then generates a Probe sequence to determine
> >which SDE-enabled bridge now has Station Y. Bridge C responds and a new SA
> >is established between Bridge A and Bridge C for Stations X & Y.
> >
> >Ken
> >
> >----- Original Message -----
> >From: "Mick Seaman" <mick_seaman@ieee.org>
> >To: "'Russ Housley'" <housley@vigilsec.com>; "'Ken Alonge'"
> ><kenneth.alonge@verizon.net>; "'LinkSec'" <stds-802-linksec@ieee.org>
> >Sent: Wednesday, April 30, 2003 3:01 AM
> >Subject: 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 scenar
>io
> > > 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
> > > > > > > >>
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> > >
>
>Regards,
>Tony
Regards,
Tony