[RPRWG] FW: [EFM-P2MP] RE: [EFM] P2MP Call Notes / Security
This is a thread on security requirements from the 802.3ah point-to-multipoint reflector. Can someone address the question asked by Jonathon? Is security (especially privacy) a concern for the RPR customers - especially taking into account the share nature of the media? If it is, how does 802.17 address this?
Thanks,
Dan
-----Original Message-----
From: Jonathan Thatcher [mailto:Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, August 14, 2002 3:28 AM
To: gkramer@xxxxxxxxxxx; Bemmel, Vincent; Gerry Pesavento (E-mail)
Cc: stds-802-3-efm-p2mp@xxxxxxxx; Romascanu, Dan (Dan)
Subject: RE: [EFM-P2MP] RE: [EFM] P2MP Call Notes / Security
Glen,
Good note.
It seems to me that EFM Copper is another strong candidate for encryption. My understanding is that it is relatively easy to sniff adjacent lines in a bundle. Does anyone know who might be able to confirm this?
Also, I presume that the 802.17 folk must be thinking through these same issues. A ring is also a shared media configuration. Does anyone know anything about what they are going to do? Are the ILECs putting the same requirements on RPR? If not, why not?
jonathan
| -----Original Message-----
| From: Glen Kramer [mailto:gkramer@xxxxxxxxxxx]
| Sent: Tuesday, August 13, 2002 3:36 PM
| To: 'Bemmel, Vincent'; 'Gerry Pesavento (E-mail)'
| Cc: stds-802-3-efm-p2mp@xxxxxxxx; dromasca@xxxxxxxxx
| Subject: RE: [EFM-P2MP] RE: [EFM] P2MP Call Notes / Security
|
|
|
| Vincent,
|
| I think you misread Dan's intentions. Or may be I did... To me Dan's
| email says that the security mechanism should be general
| enough to apply
| to "Metro and WAN transport" as well as subscriber area. The unified
| solution is better than "disparate and non-consistent solutions".
|
| > Areas of concern such as Security, per-user scheduling (via LLIDs),
| > and DBA in EPONs, among others, have not traditionally been a part
| > of the Ethernet standard. That is not to say that they are not
| > important /critical to some services, but the IEEE has not been
| > the audience for these issues.
|
| Not a valid argument. EPON itself was never part of Ethernet standard.
| All the areas you mentioned above are not separate services. They are
| components of EPON technology that is being standardized (no one is
| defining DBA or Security, but only the mechanisms to enable those).
|
| I agree with Dan that a security solution better be
| applicable not only
| to EPON. The question is how general should it be? For example 802.10
| is too general (it tried to find a unified solution for different
| LAN/MAN standards). Dolors gave very good explanation why
| this solution
| is not very good for 802.3.
|
| Another question if for Dan:
|
| > 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.
|
| Dan, does your crystal ball tell you when that will happen? If it
| doesn't happen very soon, the P2MP STF may be forced to look beyond
| 802.3 for a "home for EPON security". If it is the case, most likely,
| it won't be a general solution to cover metro and WAN as well. I hope
| more people understand that.
|
|
| Glen
|
|
|
|
|
|
|
| -----Original Message-----
| From: owner-stds-802-3-efm-p2mp@xxxxxxxxxxxxxxxxxx
| [mailto:owner-stds-802-3-efm-p2mp@xxxxxxxxxxxxxxxxxx] On Behalf Of
| Bemmel, Vincent
| Sent: Tuesday, August 13, 2002 12:54 PM
| To: Gerry Pesavento (E-mail)
| Cc: 'stds-802-3-efm-p2mp@xxxxxxxx'
| Subject: RE: [EFM-P2MP] RE: [EFM] P2MP Call Notes / Security
|
| Gerry,
|
| Dan has brought up a valid and most appropriate point: there is a
| distinct difference between defining a technology and
| defining a service
| offering.
|
| As part of the larger IEEE 802 group, the EPON group is tasked with
| defining a technology. Perhaps it is taking the narrow path,
| but this
| isn't the venue for defining a service offering.
|
| Areas of concern such as Security, per-user scheduling (via
| LLIDs), and
| DBA in EPONs, among others, have not traditionally been a part of the
| Ethernet standard. That is not to say that they are not
| important /critical to some services, but the IEEE has not been the
| audience for these issues.
|
| Services have traditionally been defined by the service providers.
| Bellcore when it was part of AT&T, the ITU, Sprint, MCI, NTT, etc.
| They take a technology and apply the requirements, practices and
| procedures that make it a service offering.
|
| This is especially true regarding Access service offerings.
| I can see
| no reason to change that paradigm unless the IEEE is ready and willing
| to go down that path.
|
| Vincent
| -----Original Message-----
| From: Romascanu, Dan (Dan) [mailto:dromasca@xxxxxxxxx]
| Sent: Tuesday, August 13, 2002 9:30 AM
| To: Gerry Pesavento; stds-802-3-efm-p2mp@xxxxxxxx
| Cc: stds-802-3-efm@xxxxxxxx
| Subject: [EFM-P2MP] RE: [EFM] P2MP Call Notes / Security
| Gerry,
|
| 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.
|
| Regards,
|
| Dan
|
| -----Original Message-----
| From: Gerry Pesavento [mailto:gerry.pesavento@xxxxxxxxxxxx]
| Sent: Tuesday, August 13, 2002 6:43 PM
| To: stds-802-3-efm-p2mp@xxxxxxxx
| Cc: stds-802-3-efm@xxxxxxxx
| 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
|
|
|
|
|