Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[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 

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 

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.