opinion, there are two flaws in this approach.
are assuming that security is handled at the PHY level. This is not a given, and
many people would not agree without a proper analysis of the security threats,
option to answer them, and relative costs of implementation and
are also looking only at the privacy at the EFM link that also happens to be
EPON. However, the concern of the customer is for a complex of security
threats (privacy, authentication, protection against DOS, no replication,
etc.) that spreads end-to-end.
is why security needs to be analyzed also at the service level, and in all its
complex. We might reach the conclusion that one of the things to do is to
encrypt EPONs at PHY layer, but this should be the outcome of proper 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
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
*********** REPLY SEPARATOR
On 8/13/2002 at 7:29 PM Romascanu, Dan (Dan)
could not attend the call because of a scheduling conflict. I hope that you
would accept my feedback, however ;-)
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.
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.
Here are my notes from the
P2MP call today concerning Security.
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.
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
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.
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.
To continue to explore this
path, I will invite a former 802.10 Chair on one of the upcoming P2MP
An opinion to leave some bits
in the LLID field undefined so as not to limit future options was
Regardless of the document
host, we need continued discussion on the security threats, existing
standards, and the most appropriate security mechanism.
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
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.