Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Use of MACsec (1) from customer to provider (2) from customer to customer across provider ---------------------------------------------------------------------------- -------------------------------------------------------- Looking at Allyn's notes from this week's call, I see this subject came up again. I believe that there is one clear architectural approach, and this may be what everyone on the call was thinking, but there appears to be scope for confusion. Hopefully this note will help sort this out, though it may confuse some people more. The trouble seems to start with a requirement stated more or less as follows: "A customer bridge attached to a provider network wishes to use Linksec/MACsec to (a) authenticate, authorise, and secure the access link between that bridge and the provider premises bridge to which it is directly (i.e. by a single LAN) attached, and (b) authenticate, authorise, and secure traffic across the provider network to the other customer bridges attached to the same customer MAC Service instance." which may cause some to react in the following way: "There is one MAC Security Entity (call it a SecE pronounced 'secky' to rhyme with "techy") associated with each Bridge Port, at least according to our discussion so far, so this requirement means that we have to devise a way for any given SecE to have multiple 'secure links' and we have to select a new addressing mechanisms to distinguish between frames allocated to each 'secure link', and by the way one may be wrapped up in another, quite a mystery ..." Restating the requirement may help: Requirement "A customer system incorporating bridging functionality attached to a provider network wishes to use Linksec/MACsec to (a) authenticate, authorise, and secure the access link between that bridge and the provider premises bridge to which it is directly (i.e. by a single LAN) attached, and (b) authenticate, authorise, and secure traffic across the provider network to the other similar customer systems attached to the same customer MAC Service instance." Adding in layering it becomes clearer that the entities responsible for (a) and (b) above are not one and the same, they are both secEs that's all. They behave in exactly the same way and do not have any additional addressing/type codes beyond those necessary to distinguish S-VLANs (service/provider VLANs) from C-VLANs (customer VLANs). One of them (the C- one) is looking after the customer to customer security, and the other (the S- one) is layered 'below' looking after the link to/between provider bridges. Consider the composite functionality labelled 'CPE3' in the network model in Clause 16 of P802.1ad/D1, this looks broadly as follows: |------| |------| | |----------| | Customer eqpt <=====| VB | | PB | ======== Access LAN ===> Provider network | |----------| | |------| |------| (Consult P802.1ad/D1 if email has trashed this attempt to a draw a diagram in fixed width font) Leaving aside for now the issue as to whether CPE3 is customer or provider operated, the CPE3 system functionality contains two copies of bridge functionality connected by 'internal LANs' each of which corresponds one to one with a MAC Service instance (as provided by the provider). There are 'internal Ports' on the VB and PB 'bridge functions' that connect to these internal LANs. So a C-secE bound to a VB internal Port provides security for customer to customer across the particular provider Service instance that corresponds to the 'internal LAN', and a SecE bound to the PB real port that attaches to the Access LAN is responsible for securing the link into the provider network as far as the next Provider bridge. To make this a little more concrete it is worth working through what happens to the frame format from the customer equipment on one site to the customer equipment on another, in the case where both layers of security are required at the same time. In order to do this I have to pick a specific frame format proposal, although in principle any format that meets our other basic requirements would do. So assuming the basic MACsec format looks as follows (using "/" as a field separaor to avoid the diagram in email problems) DA / SA / VLAN TAG / MACsec TAG/ user data / ICV / FCS where the MACsec TAG is probably MACsec Ethertype / SAID-DOID and using C-TAG for a Customer VLAN TAG and S-TAG for a Service VLAN TAG we find that a frame sent by customer equipment from the left of the diagram as: DA / SA / C-TAG / user data / FCS gets allocated to a Service Instance by the VB functionality, and passing through the internal Port corresponding to that Service instance is transformed by the secE on that Port into: DA / SA / C-TAG / MACsec TAG / user data / ICV / FCS' and is taken in by the PB bridge function as if it were an untagged frame (no S-TAG present), and further security protected (as far as the next provider bridge) by the secE on the Access LAN Port to become: DA / SA / S-TAG / MACsec TAG / C-TAG / MACsec TAG / user data / ICV / ICV/ FCS" where obviously the SAID-DOIDs in the two MACsec TAGs differ. If customer 'end to end' MACsec protection (the secE on the internal port) is turned off the frame across the provider network would look like: DA / SA / S-TAG / MACsec TAG / C-TAG / user data / ICV / FCS" and if only "end to end protection were employed it would look like: DA / SA / S-TAG / C-TAG / MACsec TAG / user data / ICV / FCS" I think that covers the required cases, no extra addressing required, except possibly for ease of implementation to set up the security associations in the first place. Obviously exactly the same straightforward application of layering and decomposition of the bridge functionality within a system could be used to run Link Aggregation over links to the provider, 'end to end', or both at once (small problem, because link aggregation is embedded in 802.3 there is a group address problem, though this could be easily solved). Obviously again the same approach can be applied to any other layered in shim functionality, WITHOUT MODIFYING the provider bridge specification or even mentionning the functionality in the provider bridge spec. Could anyone who seriously wants the CPE3 functionality in P802.1ad collapsed into a single relay entity with all external ports explain at the July meeting how the above and similar functions can be properly specified, with particular reference to management and the use of standard MIBs for such functionality in the collapsed model. Mick