|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
I could not attend the call because of a scheduling conflict. I hope that you would accept my feedback, however ;-)
I would strongly advice the EPON group to avoid taking a narrow path. I understand your concerns and I support your effort on defining a solution for EPON. I think that you are just one step ahead of other application fields of Ethernet targeting the subscriber access, Metro and WAN applications in hearing the strong requirement of the market. As Ethernet crosses boundaries and enters new territories of deployment, I estimate that we will here other markets raising this type of requirements very soon. The IETF went through that same path, as the IP technology started to be infrastructure for public services, and the result was the creation of the Security Area in the IETF. My crystal ball says that the IEEE will go soon through the same process if it intents to design technologies that will be deployed in subscriber access, Metro and WAN transport. Having each of the PHY specialized groups design its own security mechanisms when the alarm sounds will soon result in more expensive disparate and non-consistent solutions, that will work exactly in the direction contrary to the goals of large deployment of Ethernet that we all want to achieve.
In my opinion, the security requirements need to be discussed at the level of the whole 802.3 Working Group, if not at the level of all 802. The solutions that will be pursued should allow for security mechanisms to be deployed beyond the EPON PHYs. Maybe the privacy and authentication requirements in the first phase will be mandatory only for EPON, but mechanism should be in place to add such capabilities to other EFM technologies and beyond. An EFM copper link is for example susceptible to all security attacks related to wiretapping. To make this possible a mechanism similar tot he OAM in Frames (maybe we can even use the vendor extensions in OAM) should be in place to discover capabilities and negotiate the mode of work for the security functions at the two sides of the link.
This does not prevent the EPON track pursuing its own focused work to solve its specific issues. However, this work needs to be done in the context of a broader discussion of the security requirements in 802 and 802.3, which should also lead to a clear architecture understanding what layer each solution should belong.