RE: [LinkSec] Failure of probe mechanisms to scale
>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.
I do not see the problem. The security mechanism should be independent of
network reconfiguration.
- If the path/tree has changed between two end points, the
security association should still work and should not need to track the
change
- If connectivity is no longer available, than this is it's own issue
and can be detected and appropriate responses provided
Paul
>-----Original Message-----
>From: Mick Seaman [mailto:mick_seaman@ieee.org]
>Sent: Wednesday, April 30, 2003 12:02 AM
>To: 'Russ Housley'; 'Ken Alonge'; 'LinkSec'
>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
>> > > > >> 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
>> > > > >>
>> > > >
>> >
>> >
>> >
>> >
>
>
>
>