RE: FW: [LinkSec] Requirements
Mick:
>I'm not sure our models have converged yet, but they are probably getting
>closer, so let me see if this answer makes any sense as a reply to your
>question, or at least gets us another step forward.
>
>In my basic model (at least the only variant of it that has seriously been
>worked out and deployed) all the links that are ever at a network perimeter
>(statically or dynamically as the network 'grows' from its core) are point
>to point and protection is applied on a link hop by link hop basis so the
>answer to the question 'where is the bridge through which I wish to access
>the rest of the network' is an easy one. It is the bridge at the other end
>of the link.
This is a huge simplification over the problem that 802.10 tried to handle
with probes. If this simplification meets the requirements of all known
potential users, then I can see how probes are easily avoided.
>A bridge or end station that has multiple links will independently attempt
>to seek connectivity on all its links. This process takes no account of the
>spanning tree active topology at any time, .1D has a section that explains
>that getting connectivity from a port to the rest of the network is
>independent of the relay connectivity provided by the spanning tree
>controlled MAC Relay Entity. This means that all the possible links
>are/should be preauthenticated and preauthorised before the spanning tree
>active topology needs to use them - so A&A doesn't impact reconfig time.
Since each port could be associated with a different Authentication
Service, I would not expect the bridge to wait for all of the ports to be
authenticated before passing traffic. What state is a port that is waiting
authentication in? Disabled?
>Clearly this model needs extending and refining to shared or semi-shared
>media, and how that is done depends on the number of possible links. For a
>.3ah ONU there is really only one link (to the OLT) so the fact that the
>media is (semi) shared doesn't alter the basic procedure at all. Note that,
>just as with Link Aggregation, A&A needs to run below any 'fixup bridging'
>layer which converts the intrinsic point-to-multipoint nature of .3ah to a
>shared media (this is not an architectural problem, and has no bearing on
>which group should do the work).
I agree. In fact, 802.10b SDE had a similar layer placement. SDE is below
the 802.1D, so it can be used to protect BPDUs.
>For a shared media such as wireless there may be an embarassing number of
>links. If I were designing a (rapid) data roaming service (as opposed to a
>telephone roaming service) I would use an unprotected link layer discovery
>protocol which selectively elicited responses on some criteria that would
>avoid a deluge of replies to identify two or three likeley network access
>ports/points and then preauth at those points, selecting one of the points
>to be the active attachment point (and firing a couple of multicasts into
>the network with the roaming stations MAC address to teach the rest of the
>network where the roamer is, note that the attachment points themselves
>don't have to know which is the active one, so they are out of the time
>critical piece).
Seems reasonable to me.
>Note that in my models (basic and roaming extended) the end station never
>has the task of finding out which bridge is doing crypto after that bridge
>has begun crypto. The crypto wrapper is removed and separately applied hop
>by hop.
In 802.10, we assumed that some bridges were crypto enabled and the some
were not. You are making the same assumption, but with different
consequences. If a non-crypto-enabled bridge was between two
crypto-enabled ones, 802.10 would provide encryption between the two
crypto-enabled ones, and the non-crypto-enabled bridge would pass
ciphertext. In your proposal, all of the traffic would be plaintext, as
neither pair of neighbors is capable of doing crypto.
Is this an acceptable constraint?
>In the bridged networks we deployed across the country we didn't imagine of
>course that we could safeguard all control traffic back to the (twinned)
>NOCs by such hop by hop protection. In each metro area we had a IPSEC tunnel
>(the real picture is rather more sophisticated to cope with all sorts of
>network partitions and failures in unattended locations without opening up
>points of attack, but that detail is not relevant here) inside the enclave
>(to borrow your term) for that area which went back to the NOC enclave. So
>basically any time the protection couldn't be covered by hop by hop layer 2
>mechansism it goes in a fixed higher layer tunnel (only for control
>traffic).
This is not MAC control frames, right? By control traffic you mean SNMP
and RADIUS and other stuff that is on top of IP, right? If so, then I can
see how such an architecture could be made to work. Are there other
architectures, with non-crypto-enabled bridges passing ciphertext, that we
need to consider?
Russ