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

[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
| 
| 
| 
| 
|