RE: [LinkSec] Requirements
Mick:
>Certainly the identity of whoever is doing the protection/encryption needs
>to be known (or easily guessable - but we needn't go down that hole for the
>moment) at layer 2, but the form of that identity depends on how far away
>from it the "remote enforcement" as you term it takes place.
Agree. However, if the MAC address works, then I do not see the need to
invent anything new.
>The identity only needs to distinguish those who are allowed to transmit on
>a link if envforcement is restricted to the other end of the link,(obviously
>intruders can't be relied upon to uniquely label themselves!) so the
>identity on a point to point protected link can simply be "the other end of
>this link".
Agree.
>Some of the MACs in design (.17, .3ah have or are considering - a murky
>subject in itself) a source station identifier that is unique only to that
>LAN (I would prefer it to be a globally unique 48-bit address for robustness
>of design, but it is an issue local to the MAC, and in at least one case I
>believe they are considering a 16 bit id). So on a shared media LAN of those
>types there is an identifier (in each bridged frame) of the last MILS-SAP
>(MAC Internal Layer Service Service Access Point) that a frame got bridged
>through. I would be surprised if other MACs have not got useable local
>identifiers, although protection of control traffic to the point they
>acquire these is a difficult task, that traffic at least has as its end
>points MAC addressed entities).
>The last MIL-SAP identifier can be generalised as a concept across shared
>LANs requiring protection, although it may change size etc. etc.
I just reread Clause 5.2 of IEEE Std 802-1990. This clause discusses the
48-bit Universal LAN Address, and it provides a very solid justification
for their use.
I was on the 802 Executive Committee when we got rid of 16-bit
addresses. It took several years. If I was still on the ExecCom, I would
fight their return.
I guess this is an area where some research is needed....
Russ