[EFM] A Home for EPON security
Based on discussion on the reflector, it is obvious that
there are very different opinions on how security should be
defined for EPON. However, we need a home for this
discussion and final specification to guarantee
interoperability. The decision of whether to encrypt
MAC addresses is just a component of the security
architecture, and there are many more components.
The challenge is to identify those that should
be specified in 802.3.
I would like to use the reflector to get opinions on
the wording of a potential security objective. The goal
would be to shape the wording so that we can get it
approved in the next EFM/802.3 meeting. A proposed
wording for the objective is as follows.
The proposed security objective:
--------------------------------
Define a security transport mechanism for mapping a
selected security protocol and architecture onto the
ethernet standard.
Sub tasks are:
1) Identification of security threats to be
addressed by the security architecture
2) Selection of an existing standard that meets
these requirements
3) Define the transport mechanism of the security
information required in a per frame basis.
4) Based on this selection, specify the additional
mechanisms within the scope of 802.3 required
to map this architecture
Some justification of why this objective makes sense
for EFM and 802.3 in general is given below.
Why this objective?
-------------------
The entire group has already recognized that encryption
should be done at the link layer and hence there is a strong
interest in having security in EPON (Straw poll in Edinburgh
July meeting, 71 in favor, 1 against). Based on this, the
P2MP track worded an objective in the last meeting. But it
was rejected by 802.3. Analyzing the reasons, it seems
that there were two main reasons to reject the objective:
1) the objective was too vague; it did not describe well
the tasks to be done in 802.3, and 802.3 does not want to
take on the entire task; 2) Security at the link level
does not mean that it has to be done in 802.3; there is
the option of 802.10.
I would like to focus the attention on the second
topic, to decide where it needs to be specified.
I agree with people who believe that security requires
security experts. But at the same I think a good
security architecture requires a good fit with the MAC
header definition. And example is the adaptation mechanism
required to carry the security information per frame
basis to avoid fragmentation. There are more examples
depending on the framework selected.
At the end I attach a summary of 802.10 as a possible
example of a framework and highlight the issues related
to 802.3. As I say below, there is no normative
specification in 802.10 for these mechanisms only
informative examples. Hence we need a normative 802.3
related document, even if we decide to leverage/modify
802.10.
So the question is where a document and discussion of this
type should be done if we haven't agreed yet that 802.10
framework is the best choice? There are several existing
frameworks. Should we select the framework that has less
impact and defines the most clear architecture for EPON?
Or leverage 802.10 and modify it to be more 802.3 friendly?
What is the advantage of leveraging a framework that has
exception cases for ethernet (to fit in the overall LAN
security architecture) but no other LAN technology uses
it today?
Therefore, it seems that the tasks described in the
proposed objective should be done in 802.3.
Reaching consensus
------------------
The proposed objective wording is supposed to be general
enough to encompass all possible frameworks (including
802.11, 802.10, 802.1x, 802.15, 802.16, others), but
narrow enough to guarantee that 802.3 takes only the
tasks related to 802.3 and leaves the rest to other
bodies. It would be great if we could polish this wording
using the reflector and address all issues of at least
the 71 people that believe that link security is needed.
Please suggest comments, refinements or a completely new
wording that would allow you to vote in favor of the
objective.
Additional material: Summary of 802.10:
(why 802.10 may not be the best home (at least initially)?)
-----------------------------------------------------------
802.10 is an encapsulation protocol, called SILS (Standard
for Interoperable LAN/MAN Security), that falls between LLC
and MAC. It is a general protocol designed to run on top of
all LAN technologies. Based on this, the assumptions were
that the protocol should be flexible and MAC agnostic. In
order to be flexible the protocol supports all possible
security features and the actual choices can be indicated
through management messages or in the header. A complete
set of security MIBs (SMIBs) are specified. The actual
header definition is attached for reference. Its maximum
length can be more than 200 bytes. However, after
configuration it can be reduced to a small value. Each
particular application of 802.10 can use a different
configuration. An example of a configuration is offered
but this is just informative. The standard points out
that some configurations are not interoperable.
The existence of this protocol between MAC and MAC client
increases the size of the PDU passed between these two
layers. Due to this, fragmentation is required to make the
security layer completely transparent to both layers. In
this case, the SILS is configured with the maximum MAC PDU
size and fragments the PDU when it extends beyond this
maximum size. Fragmentation is optional. The other
alternative is to adjust the MAC-client to pass a smaller
PDU size, or define some other adaptation mechanism.
However this is not specified. And for interoperability
reasons the standard recommends that fragmentation be used.
It does not impose a specific encryption mechanism. Instead
it is up to the management SMIBs to configure the two parts
and agree on one. The same applies to the IVC algorithm.
Tagged frames are a special case because the ethertype can
come encrypted. It recommends a framework based on LLC
encapsulation to support tagged frames. This mechanism is
informative only.
In summary, 802.10 could potentially be leveraged as a
framework of a security architecture. However, in order to
adopt it and guarantee interoperability we need a normative
document that specifies the encryption and ICV algorithms to
be used, the configuration parameters to reduce the header
size to the minimum required, and adaptation mechanisms for
special cases (fragmentation and tagged
frames). Therefore, the adoption of 802.10 even without any
modification of the existing spec requires a normative
document to specify the configuration of SILS.
So where should a document of this type be specified? If we
assume that 802.10 framework needs to be leveraged, then a
place could be 802.10. However, some of the features to be
specified require more 802.3 expertise than security
expertise, for example, the adaptation mechanism to avoid
fragmentation. One possible approach to avoid fragmentation
could be the following. Note that this is not a proposal,
just an example. The 802.10 header could be reduced to a
minimum and carry this header in the preamble. The FCS could
take the place of the IVC. And hence, the entire SILS
overhead has been eliminated from the frame overhead. This
approach is very similar to the current proposals discussed
in the EPON track (if we leave aside the decision of
encrypting MAC addresses).
This example illustrates that the solutions that can be
explored inside 802.3 at this stage can
result in a cleaner and simpler architecture solution than
solutions specified outside with separate time frame and
context. But we should definitely define a task/objective
that focuses the 802.3 related tasks. The proposed
security objective tries to capture these tasks.