[LinkSec] Use of MACsec (1) from customer to provider (2) from customer to customer across provider
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