RE: [LinkSec] Failure of probe mechanisms to scale
>I do not see the problem. The security mechanism should be
>independent of network reconfiguration.
Ok ... I've read more closely the rest of this thread and do
see the potential problems. Thank's what I get for lurking :-)
The potential problems with placing link security midway in a
nework could be eliminated several ways. Ideally, the security
mechanisms should be independent of this bridging changes.
Most of the 'useful' scenarios can be made to be independent
of these type of changes.
This class of architectural problem is very similar to the older
dual versus single catenet debate for network security. I believe
that at the bridging level you could make some simplifing assumtions
and eliminate many of the problems associated with changes in the
spanning tree.
I'll try to draw aome pictures ....
Paul
>-----Original Message-----
>From: Paul Lambert
>Sent: Wednesday, April 30, 2003 1:32 PM
>To: mick_seaman@ieee.org; Russ Housley; Ken Alonge; LinkSec
>Subject: 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
>>> > > > >>
>>> > > >
>>> >
>>> >
>>> >
>>> >
>>
>>
>>
>>
>