[LinkSec] Notes on teleconf 1/28/03
1/28/03 ECSG LinkSec
Dolors Sala, chair, dolors@ieee.org
Allyn Romanow, notes, allyn@cisco.com
Dave Nelson, Allyn Romanow, Bob Moskowitz, Dennis Volpano, Antti Pietilainen,
Dolors Sala, Mani Mahalingam
Dolors
Slides she sent on mailing list - represent line of thought of
non-security person trying to understand the various proposals
Levels of trust, means how much want to protect
Secure bridge network, not just a link as in case 1 and 2
1. EPON MAC only 2. other types of MACS 3. bridged network
Wants to capture where these scenarios are relevant, where used
Does the first slide cover all the thoughts that have been expressed?
Dave Nelson - seems complete
if go beyond what's here, then have gone beyond L2
Slide 2
Dolors - Why will provider use a bridge rather than a router?
Are there are other scenarios?
Send email
Assume enterprise only one using bridged network, may not be a true
assumption
Why she chose RPR? because it's another example MAC that's not EPON
Cases:
1. a single form of MAC
2. different forms of MAC
3. bridged, difft. MACs
Bob - should restructure 1 and 2? RPR more like EPON than different,
from a security perspective.
Dolors - need classification based on threat model?
Antti - likes classification based on biz model-
Dolors- that's fine, we want to look at it from all the different perspectives
Dolors - levels of trust, classification of scenarios by trust models
T1- enterprise trust model
Dennis- T1 is closest to what Mick proposed. Bridges trust each other, if
do need to secure, then do it on a hop by hop basis. This model rules
out a bridge that doesn't do the security protocol, that can't do the hop
by hop mechanism. In this case, have to go in clear from sta to
sta. So, don't allow this case to occur in the enterprise.
Can't have security if a bridge doesn't do the protocol.
How difft are scenarios 1 and 2?
In EN case, trust all bridges in clouds, don't need SDE on those bridges.
Is that also the case for provider network? thinks not
Dolors, what's different between ES and EN on the left hand side in
the slide?
Dennis - End station vs access bridge - they have different responsibilities
End sta has to do less than access point
ES only has to understand baseline encapsulation, it is not involved
in reconfiguration, where as an access bridge would be.
Access bridge has additional obligations that endsta wouldn't.
PN pushes SDE into net, whereas in case 1, SDE is on end sta alone
T3 multiple administrative domains,
Dolors- what does it mean? each domain difft VLANS??
MACs are independent. Some are shared media
Dennis - In T1, EN is trusted, don't run SDE between bridges
In T2 and T3, need to push SDE into network
Mick says can just start with T1
Dennis - not sure, what's the biz case?
Offer a security service to customer, a secure L2 connection,
Where end not running SDE, there need to push SDE into the network
then bridges need to preserve secure link, between reconfigs
Dennis- T2 means one PN provider network
T3 means multiple PNs
Dennis has talked with various people and finds no agreement between
SPs on a set of threats with which they are concerned
So, instead of basing a solution on a set of threats given by user
community, he proposes looking at what you know about trust
relationships between the devices and logically deriving the threats
Look at who is controlling what equipment
Derive threats, analytically from these relationships
Dolors- how do these relationships map to slide 1?
Bob - trouble seeing the scenario where the end sta is the first
secured bridge in the network. This is EN in the T2 scenario, so would
put T2 into #3 in slide 1?
Authentication issues will be different for ES connection to PN or to
EN, especially if end sta is roaming. How do authentication looks different
from how do it for wired EPON.
Dennis - the distinction between T1 and T2 is where SDE lives. If SDE
is in the network one thing, if SDE in ES only, perimeter, than
another. Much easier to constrain to ES.
Mick is suggesting this.
Maybe we should talk about where SDE lives rather than EN vs PN?
Dennis -This is the key difference between 802.10c and what Mick has
proposed as first step.
Pairwise SDE on bridges. If it fails, can't recover, no security. Russ
says, can recover and find another secure bridge. If topology changes,
again have to find a secure bridge. This is more than what Mick wants to bite
off right now.
Provider scenario really calls for pushing SDE into the network.
Dolors - what about SA from the same point of view? 802.10 vs 802.l1 point of
views. See slide 6, case a is single hop - needs SDE running in all
bridges.
Case b, multi-hop - can accommodate when some bridge doesn't run SDE.
multi-hop allows jumping between bridges
difference is reconfiguration and ST Spanning Tree discovery
Is this a fundamental difference, or can it be done in stages?
Simply at perimeter, recover on a point to point basis, doesn't scale.
Mick says less problematic if just on end stas.
If end point of SA for two stas is a bridge and bridge goes down, need
another bridge whose connectivity and SA can be built. In .10 must be
done on a pt to pt basis, for every pair, for all pt to pt links
Dave- this is an argument why this shouldn't be done at L2
Mixing topology with SA is dangerous.
Cloud is opaque, user doesn't care what's in it, doesn't care what's
in, bridges, routers, etc.
that's where case b. breaks down. SAs depend on exact topology. At the least,
don't draw topology details in the cloud, that's what's meant by a cloud.
Dennis disagrees - new ST needs to preserve connectivity if link goes down
between bridges. Makes topology more complex. This was in the scope of
802.10 to address.
We are insulating ES in this case.
Complicates things.
Keeps Links local.
no discovery??
Keys, different between cases a and b. Network manager has keys for
internal hops within the cloud for case b but not for case a. Implies
different security provided. access internally with b.
slide p.7 Factors on single-hop and multi-hop SAs
Bob- importance of control and management frame? DOS attack is the one
to be concerned with. Breaks relationship between two pairs and link
if control packets are sent improperly.
Protecting control packets is preferable. So authenticating, message
integrity, control frames is desirable, a value add.
Sometimes can't do it because no secure relationship.
If use multi-hop model, then you are limited to restricting protection
only to data frames, not management frames.
Dave - How about using model a for user data, and model b for control messages
model b, assumes that security associations have the property of associativity
Dolors - describe all the issues with single hop and multi-hop models
Most control frame compromise involves DOS
Model a for data, risk for control is DOS only
Need to prove that control attacks couldn't divert data to untrusted node
create man in middle thru control frames? in model b