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

RE: [EFM] P2MP Call Notes / Security

   If the security is handled at the PHY level then I am not sure how a generic will let to benefits for other EFM technologies. Frankly speaking I am not even sure what other EFM technologies we are talking about (Pardon my ignorance here). I would definetely like to know more about it.
  In my previous email I was suggesting EPON level security since they can leverage the best out of it. But if you think and are aware of other EFM solutions that will come up soon the handling it at the 802.3 MAC level would be a more fruitful effort. But then the concern is that the EPON work may slow down as more thinking and discussion needs to happen at that layer.

*********** REPLY SEPARATOR ***********

On 8/13/2002 at 7:29 PM Romascanu, Dan (Dan) wrote:
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.
-----Original Message-----
From: Gerry Pesavento [mailto:gerry.pesavento@xxxxxxxxxxxx]
Sent: Tuesday, August 13, 2002 6:43 PM
Subject: [EFM] P2MP Call Notes / Security

Here are my notes from the P2MP call today concerning Security. 


(1)     There is agreement within P2MP that security (encryption, authentication) needs to be defined for EFM market acceptance and interoperability.  This is most acute in EPON which is a shared network.  

(2)     We are still looking for the right standards body in which to attack this solution, but it is starting to be narrowed down.  The choices still under discussion are: 802.10 reactivation, an 802.3 security transport mechanism, or a supplier alliance/agreement.

(3)     Paul N. offered guidance for the 802.10 reactivation approach, which was very helpful.  What is of most interest here is that a new PAR for 802.10, can be a *focused* effort on P2MP fiber security.  That means we do not have to be bounded by the existing 802.10 architecture.  The steps would be to identify the technical activity to be worked on, bringing in security experts as well as 802.3 knowledge, with a core team of (say) ~20 people, and submit a PAR request.  A focused PAR would need to go through the 802 process, but could move quickly if the scope is narrowed to a specific requirement.

(4)     The concerns voiced about 802.10 were the time period required to go through an 802 process (it would likely be a March PAR approval), and also uncertainty about the ability to be flexible to handle below MAC layer encryption if that was decided that was the best approach.  

(5)     To continue to explore this path, I will invite a former 802.10 Chair on one of the upcoming P2MP calls.

(6)     An opinion to leave some bits in the LLID field undefined so as not to limit future options was expressed.

(7)     Regardless of the document host, we need continued discussion on the security threats, existing standards, and the most appropriate security mechanism.  

(8)     I’d like to solicit a volunteer to lead the security effort for EPON to make sure it happens quickly.  It is possible that this will become an independent effort, although strongly tied to EFM P2MP.   


Did I capture this right?   My personal opinion is that the 802.10 reactivation, if, and only if, it can be a PAR focused on P2MP Fiber and not bounded by current 802.10 definitions – is now a more attractive option.  And if that is true, then the challenge becomes moving faster than the 802 process, and this can be done by working now in the P2MP group and external alliance meetings to reach consensus and setup the work.   I’d appreciate feedback from others who were on the call.




Gerry Pesavento