Re: [EFM] Re: [EFM-P2MP] A Home for EPON security
Dolors,
The proposals that I made to provide the OAM, and P2MP protocol "out of
band" to the MAC/PCS would have provided support for different forms of
security, encryption, FEC, bandwidth management, metering/control, etc,
without effecting the MAC, MAC control, or support for 802.1. The frame
based OAM could have been supported by this proposal as well. The group as
a whole regarded those proposals as not reflecting the philosophy of
802.3. I have been told that my proposal more closely reflected the
direction and philosophy taken by 802.9.
It is not unusual to find that specific protocols such as 802.3 are
specific in their "target" functionality and are not well suited to radical
change. We are finding this to be the case with 802.3.
Thank you,
Roy Bynum
At 02:07 PM 8/12/2002 -0700, Howard Frazier wrote:
>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.
>>
>>
>