RE: [EFM] OAM developing Geoff's observation.
Hi Roy,
At 08:10 PM 09/17/2001 -0500, Roy Bynum wrote:
>
>Faye,
>
>For P2P and Cu you already have physical segregation between customers on
>the link between the aggregation box and the CPE.
I did not understand the functionality of the aggregation box here? Is it not an ethernet
802.3d box that does the forwarding based on the ethernet mac addresses?
Thanks,
Sanjeev
For P2MP TDMA, it it is
>done right, it might be treaded as physical time domain segregation just
>like the existing TDM network. For P2MP that used a Poll/Grant mechanism
>to control service and uplinks, then it might, if done right, work as a
>"Virtual Private Line" type segregation. It all depends on a combination
>of how P802.3ah does the OAM overhead and how the vendors implement the
>services.
>
>Thank you,
>Roy Bynum
>
>At 05:55 PM 9/17/01 -0700, Faye Ly wrote:
>>Roy,
>>
>>Exactly! Don't have a good answer. If we are trying to keep the
>>cost of the CPE down, pushing for encryption for that segment will be
>>hard.
>>But if we don't, does it still meet the security requirement? Or does
>>data
>>segration suffice?
>>
>>-faye
>>
>> -----Original Message-----
>> From: Roy Bynum
>> Sent: Mon 9/17/2001 5:41 PM
>> To: Faye Ly; Harry Hvostov; mattsquire@xxxxxxx;
>>"HHvostov\"@luminous.com;"@squid.squirehome.org;
>>"malcolm.herring\"@btinternet.com"@squid.squirehome.org;
>>stds-802-3-efm@ieee.org
>> Cc:
>> Subject: RE: [EFM] OAM developing Geoff's observation.
>>
>>
>>
>> Faye,
>>
>> The real question, since the encryption is at the aggregation
>>"box" then
>> how much of that would apply to EFM which is between the
>>aggregation "box"
>> and the CPE or does this issue even apply at all?
>>
>> Thank you,
>> Roy Bynum
>>
>>
>> At 05:28 PM 9/17/01 -0700, Faye Ly wrote:
>> >Harry,
>> >
>> >Can you please clarify the network segment where encryption
>>covers?
>> >Judging from the PPPoE discussion we had, the encryption starts
>> >at the subscriber termination point and it may very well be at
>>the
>> >aggregation box. Not at the CPE.
>> >
>> >So the big question is "Is data segration alone satisfy the
>>needs for
>> >security for user data travelling from home/office to the
>>subscriber
>> >termination point?"
>> >
>> >-faye
>> >
>> > -----Original Message-----
>> > From: Harry Hvostov
>> > Sent: Mon 9/17/2001 3:59 PM
>> > To: 'mattsquire@xxxxxxx';
>> >"HHvostov\"@luminous.com;"@squid.squirehome.org;
>> >"malcolm.herring\"@btinternet.com"@squid.squirehome.org;
>> >stds-802-3-efm@ieee.org
>> > Cc:
>> > Subject: RE: [EFM] OAM developing Geoff's observation.
>> >
>> >
>> >
>> >
>> > Cable industry is deploying X.509 digital certificate
>>and key
>> >management
>> > protocol now. I believe the requirement to
>> > be quite realistic and a direct consequence of MSO's
>>experience
>> >with more
>> > relaxed authentication mechanisms.
>> >
>> > I believe that the precedent for public access network
>> >authentication has
>> > been set and its feasibility will be proven in the
>>nearest
>> >future, with real
>> > deployments.
>> >
>> > Harry
>> >
>> > -----Original Message-----
>> > From: Matt Squire [mailto:mattsquire@xxxxxxx]
>> > Sent: Monday, September 17, 2001 12:51 PM
>> > To: "HHvostov\"@luminous.com;"@squid.squirehome.org;
>> >
>>"malcolm.herring\"@btinternet.com"@squid.squirehome.org;
>> > stds-802-3-efm@ieee.org
>> > Subject: RE: [EFM] OAM developing Geoff's observation.
>> >
>> >
>> >
>> >
>> > This seems like a new and unrealistic requirement.
>>Simple
>> >password
>> > authentication has served users well for a long time.
>>Although
>> >I
>> > understand the benefits of managed certificates, I've
>>also had a
>> >taste
>> > of their complexity and the interoperability problems
>>that lay
>> >in wait.
>> > Managed certificates for authentication cannot be a
>>requirement
>> >for EFM
>> > services.
>> >
>> > - Matt
>> >
>> > >
>> > > Malcolm,
>> > >
>> > > User authentication will likely require the use of
>>digital
>> > > certificates and
>> > > key management. As such, this can be transported
>>inside
>> >conventional
>> > > Ethernet frames. There is no requirement for
>>additional
>> > > concurrent protocol
>> > > such as PPP to accomplish this.
>> > >
>> > > Harry
>> > >
>> >
>>
>>
>