RE: [EFM] OAM - Faye's seven points - MAC address
See below:
> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Andrew
> Smith
> Subject: RE: [EFM] OAM - Faye's seven points - MAC address
>
> Bob,
>
> Not sure if you can specify in a PHY standard anything that uses,
> let alone
> requires, a MAC address - maybe the architecture police will bend
> the rules
> on this but it seems like you're violating layering with your
> P2MP proposal.
I am not an EPON exponent :-). Gerry Pesavento may pick up your point on
this. I think the proposals all assume that all EPON OTE (CPE) will operate
at the MAC layer with a MAC address.
>
> Regarding encryption, I do not follow your argument: if the OAM data is
> sensitive enough to need encryption when mixed in with the payload then
> surely it is also sensitive enough to need it on a side-band. Maybe I am
> misunderstanding the threat you want to protect against here? Are
> people on
> this thread perhaps confusing encryption with authentication (the
> latter is
> usually much more important for management of IP-based networks)?
>
My thinking is that even a standardised OAM side band is likely to be
inaccessible (to the subscriber), except from within the CPE, or via the CPE
craft port. It is not something they can hack into from their desktop over
the LAN (they potentially could hack into a layer two in-band MAC layer OAM
protocol stream from their desk top). The protocol running over the side
band is likely not to be IP based; it's more likely to be an end to end
skinny bit stream. If the subscriber hacked into this via the CPE craft port
all they would be able to do is mess up their own connection, so the
consequence is not drastic for the network operator (so long as they can
trace what has been done and point the finger). Security is a balance of
risk, consequence and 'implementation complexity' (a.k.a. relative cost). I
am a simple minded sort of chap that likes uncomplicated implementations
that work, and I find simple H/W developments easier to manage and control
that software projects :-).
Bob Barrett
> Andrew Smith
>
>
> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Bob Barrett
> Sent: Wednesday, September 19, 2001 1:04 PM
> To: Faye Ly; Geoff Thompson; fkittred@xxxxxxx
> Cc: stds-802-3-efm@ieee.org
> Subject: RE: [EFM] OAM - Faye's seven points - MAC address
>
>
>
> Fletcher,
>
> If the CPE is essentially a media converter / repeater
> (relatively dumb and
> with minimal hardware) it may not need to have a MAC address in order to
> support a management entity, however, a management entity and registration
> would be desirable.
>
> A MAC address is not essential to find a CPE on the end of a p2p fiber /
> copper loop. The CPE is either there or not there, and there is only ever
> one of them in p2p.
>
> P2MP is a different issue and I agree that a MAC address is the logical
> choice in that case, but I wouldn't want to see the inclusion of a MAC
> entity made mandatory in the p2p fiber or p2p copper EFM standard.
>
> I don't think encryption of OAM data is necessary on a p2p link
> if it is in
> a side-band.
> If OAM data is mixed in with the payload, even with VLAN, then
> encryption is
> probably necessary.
> I guess that's one of my 'pro' arguments for side band ;-).
>
> Best regards
>
> Bob Barrett
>
> > -----Original Message-----
> > From: owner-stds-802-3-efm@majordomo.ieee.org
> > [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Fletcher E
> > Kittredge
> > Sent: 18 September 2001 16:42
> > To: bob.barrett@xxxxxxxxxxxxxxx
> > Cc: Faye Ly; Geoff Thompson; stds-802-3-efm@ieee.org
> > Subject: Re: [EFM] OAM - Faye's seven points
> >
> >
> >
> >
> > Below, please read "Ethernet MAC address" for MAC address.
> >
> > On Tue, 18 Sep 2001 11:25:43 +0100 "Bob Barrett" wrote:
> > > > 3. CPE registration or inventory (The former is the action
> > and the later
> > > > is
> > > > the results).
> > >
> > > Some form of registration, even if it is operator driven is mandatory.
> > > Auto registration is desirable.
> >
> > Is this not just the use of an Ethernet MAC address? As a provider of
> > both cable and dsl based public ethernets, we think the MAC address
> > works well.
> >
> > One of the reasons the Ethernet MAC address works well is that the SP
> > already has the necessity of monitoring the network in order to pick
> > up the MAC addresses of customer equipment beyond the CPE. This
> > information is sufficent to provide the ability to map any given
> > Ethernet Frame to a customer. Such a mapping is required in order to
> > provide secure networks.
> >
> > For a SP, two illustrations of the necessity of such a mapping are the
> > recent "Code Red" infestation when SPs needed to contact customers to
> > inform them of infected servers and the events of September 11th,
> > 2001. For those outside the US, like most (all?) SPs serving the US
> > market, we have been spending time this week responding to subpoenas.
> >
> > thank you,
> > fletcher
> >
>