Re: [RPRWG] FW: [EFM-P2MP] RE: [EFM] P2MP Call Notes / Security
Speaking now as a Cisco person.
We have not seen any requests from either Service provider or
Enterprise customers for additional security in terms of
encryption. Part of this is the due to the difference in
deployment in RPR versus a PON.
I am assuming (perhaps wrongly) that in a PON the SP
is expecting to place multiple customers on the same
"fiber" so everyone does have a chance to see every
other packet.
In RPR the SP owns the RPR node that might serve multiple
customers, it is not the customers themselves who own
the ring nodes. Hence there is not quite the same
security threat, or put differently, the security
threat is similar to that encountered by an ADM.
Now, there was discussion within .17 that a customer
separation field (something like a nested VLAN) would
be useful to add a simple layer of separation between
customers, but no proposals suggested a need for
encryption.
Really personal opinion:
In the end, I must admit that I believe that the MAC
should not add encryption. Encryption is a user
problem, and with technology advancing at the pace it
does, companies and individuals who are really concerned
with privacy will always encrypt themselves anyay.
mike
"Romascanu, Dan (Dan)" wrote:
>
> 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
> |
> |
> |
> |
> |
--
Michael Takefman tak@xxxxxxxxx
Manager of Engineering, Cisco Systems
Chair IEEE 802.17 Stds WG
2000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-254-3399 fax: 613-254-4867