Dolors,
I disagree with this statement:
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
[sic] July meeting, 71 in favor, 1 against)
In Edinburgh in May, the straw poll was worded as follows:
Straw poll to gauge interest in adding encryption in EPON:
Those who would like to support encryption in EPON: 71
Those who would be opposed to support encryption in EPON: (1) Tom Dineen
reference the minutes at:
http://www.ieee802.org/3/efm/public/may02/minutes_05_2002.pdf
In Vancouver in July, there were three more straw polls on this subject:
Straw Poll to see if hiironen_general_1_0702.pdf reflects the
direction the
TF wants to go regarding security and encryption.
Those who favor the direction offered in hiironen_general_1_0702.pdf: 21
Those who are opposed to the direction offered in
hiironen_general_1_0702.pdf: 23
Those who abstain: 31
Straw Poll to see how many attendees think that encryption belongs
at the MAC
client layer or above
Those who agree: 46
Those who disagree: 12
Those who have no opinion: 18
Straw Poll to see how many attendees think that a security scheme which
only provides content encryption (MAC payload) is sufficient:
Those who agree: 43
Those who disagree: 12
reference the minutes at:
http://www.ieee802.org/3/efm/public/jul02/minutes_1_0702.pdf
To my interpretation, these straw polls indicate:
a) The Task Force generally believes that some set of security
mechanisms are
desireable, perhaps required, in EPONs.
b) The Task Force (as of the Vancouver meeting) had not yet reached
concensus on
the set of required features or functions or the scope of the security
mechansims.
c) A strong majority of the Task Force members believe that encryption
should
be performed at or above the MAC Client.
d) A strong majority of the Task Force members believe that it is
sufficient to
encrypt the MAC payload.
For these reasons, I believe it is incorrect to assert that
The entire group has already recognized that encryption
should be done at the link layer
I believe that the group as a whole as determined that
encryption should not be done in the Physical layer or the MAC sublayer.
Whether it is to be done in the link layer above the MAC, or whether it
is to be done somewhere above the link layer is a subject for debate.
However, our responsibility in 802.3ah ends at the top of the MAC
(or MAC Control), and does not extend up into the MAC Client.
I appreciate your detailed analysis and description of 802.10. You may
wish to consider the idea of initiating a new project in a reactivated
802.10
Working Group to address the issues and short comings you have described.
Howard Frazier
Chair, IEEE 802.3ah EFM Task Force
Dolors Sala wrote:
>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.
>
>
>