Re: [RPRWG] BOUNCE stds-802-17@xxxxxxxxxxxxxxxxxx: Admin request of type /\bsubscribe\b/i at line 5
Mike,
Even though your reply was target towards Jonathan, I would still want to send my response to it.
In case of DOCSIS public/private key exchanges and encryption in done at the MAC layer. This helps them protect the shared media over which traffic from multiple consumers can flow. The domain of security starts at the Cable Modem and ends at the CMTS (headend office of the MSO).
As you comment about 802 MAC's are concerned, it may not be an impossible or unreasonable requirment to have a security for all 802 MAC's, just that it going to take a long time to convince all.
As far as VPN's are concerned, since MAC level security don't span over multiple hops one would have to have a higher level of security, which the VPN does. Secured tunnelling is achieved by it. (It is also difficult to say anything as VPN exists at multiple layers, L2, L3, etc). If from your source site to the destination there are three shared hops (i.e Ethernet segments for eg) and if packets are secured at all the three segments then any higher level security may not be deemed necessary. Since MAC level security can traditionally initiate at one MAC and terminate at the other end, it needs a higher level protocol that can see end to end (i.e. Source IP to destination IP ) to build the end to end security.
Anyway, I think I am not going to convince anybody of this need. I get the feeling that everybody is against it so I will stop responding to emails. If security is not deemed necessary then great. It provides more opportunity for small startups to come up with solutions in this space to make money off.
Regards
SG
*********** REPLY SEPARATOR ***********
On 8/14/2002 at 11:27 PM Mike Takefman wrote:
>Jonathon,
>
>our reflector is closed due to all of the spam, I am
>forwarding your reply to the reflector and my reply.
>If you wish to join our reflector please do so.
>Otherwise I will try to forward your replies, but I
>cannot guarantee timely response.
>
>I suspect you mean hierarchical rings such as an access ring
>connected to a metro ring connected to a regional ring
>when you said rings on rings on rings.
>
>Certainly the rings may be owned by separate service
>providers or even have multiple service providers
>on the same ring as an exchange point. I know of
>deployments of pre-standard RPR that are doing this
>successfully without encryption. But as I said in
>my original reply, this is just one man's opinion.
>
>I hope that others who disagree with me speak up
>so that there can be a real debate. Service providers
>have tremendous weight, is there a good presentation
>on the EFM web-site that might give more details?
>
>How is this ring on ring on ring scenario all that
>different from a network of incomplete ethernet meshes,
>that might connect multiple service providers and
>customers together at various levels of the hierarchy?
>It strikes me the traffic will go through multiple
>providers equipment.
>
>I had thought the issue was that PONs do have a security
>hazard due to their shared nature and the "type" of
>user that gets access to the media. i.e. an end user
>as compared to a box controlled by a service provider.
>
>IMO RPR is not currently assumed to be showing up in
>the first mile. But I would be keen to know if there are
>any RPR companies who are targetting that market (and
>would they even admit it :)
>
>However, the PON strikes me as quite similar to a cable modem.
>I admit that I have no idea how DOCSIS handles the
>"security" threat there. I do know that Cisco makes
>me use a VPN client for any communications to Cisco
>from the outside world, and that would include running
>over a PON that was already encrypted.
>
>My interpretation of the scenario (incomplete ethernet
>mesh) you gave suggests that the issue is not just PON
>related but is useful for all 802 MACs used to connect
>multiple service providers. Is this correct? If so,
>a much wider audience is called for.
>
>cheers,
>
>mike
>
>
>
>> Mike,
>>
>> Thanks for this point of view.
>>
>> In various conferences I have seen large concepts of large deployments
>of RPR with Rings on Rings on Rings. The strong implication is that the
>nodes would not be owned by the same SP.
>>
>> Hmmmmmmm.
>>
>> jonathan
>>
>> | -----Original Message-----
>> | From: Mike Takefman [mailto:tak@xxxxxxxxx]
>> | Sent: Wednesday, August 14, 2002 1:16 PM
>> | To: Romascanu, Dan (Dan)
>> | Cc: stds-802-17@xxxxxxxx; Jonathan Thatcher
>> | Subject: 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
>> |
>
>--
>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