[RPRWG] Call for a Volunteer! Re: Link Security presentation
All, per the attached note from Mike Takefman, there has been a request from
the Link Security Study Group to have representatives from 802.17 present to
them on the Monday morning of the March plenary session in Dallas, to
explain our technology. Specifically, they have requested input on 1) RPR
motivation and target scenarios, 2) The RPR MAC, and 3) RPR bridging. I
have volunteered to present RPR motivation and target scenarios. Mark
Holness has volunteered to present on Bridge operation. That still leaves
room for one volunteer to present on the RPR MAC. It is important for RPR
that any IEEE 802 group developing link security algorithms do so with an
understanding of our RPR MAC.
Please, any of you MAC experts that will be available on Monday morning.
Your participation in this presentation would be greatly appreciated.
Thank you.
Best regards,
Robert D. Love
President, LAN Connect Consultants
7105 Leveret Circle Raleigh, NC 27615
Phone: 919 848-6773 Mobile: 919 810-7816
email: rdlove@xxxxxxxx Fax: 208 978-1187
----- Original Message -----
From: "Mike Takefman" <tak@xxxxxxxxx>
To: "RPRWG" <stds-802-17@xxxxxxxx>
Sent: Wednesday, February 12, 2003 10:31 AM
Subject: [RPRWG] [Fwd: Re: Link Security presentation]
>
> RPRWGers,
>
> I am looking for a volunteer to give a talk to the
> Link Security SG on the monday morning of the
> March meeting. I will be at the SEC meeting during
> their meeting so I cannot be there.
>
> Another thing people should be aware of is that this
> group will likely move under .1 as a SG there rather
> than an SEC SG. Given this fact I might suggest the
> volunteer be someone with an interest in .1 issues.
>
> The chair Dolors Sala has given below an idea of
> what kind of information they are looking for on
> a dump. I am hoping that a number of people will
> volunteer to pull this together so that it is
> not a large amount of work. I suspect that:
>
> item 1) should be generatable from Alliance slides
> item 2) should be generatable by someone from the BAH
> item 3) is a bit of a debate, but I would argue that
> we would want the MAC control to be in the
> clear, and the encryption to be layered on top
>
> Note below that they are NOT asking us to do the security
> analysis, that is their job. They just want to understand
> RPR enough so that they can do their job correctly.
>
> Please respond to me if you are willing to help on
> this issue.
>
> mike
>
>
>
> -------- Original Message --------
> Subject: Re: Link Security presentation
> Date: Tue, 11 Feb 2003 18:52:11 -0500
> From: "Dolors Sala" <dolors@xxxxxxxx>
> To: "Mike Takefman" <tak@xxxxxxxxx>
> References: <035a01c2d20f$47245120$6501a8c0@HomeWlan>
> <3E49780E.513BFC2A@xxxxxxxxx>
>
> Mike, Thanks,
>
> I think a 20-30 min talk would be appropriate.
>
> Right now we are working on three scenarios:
>
> 1) EPON
> 2) General (for any MAC) link security mechanism (this targets just one
hop)
> 3) Secure bridged networks (this targets multi-hop in a bridge network)
>
> The last one is very new and still needs some justification for some
people.
> RPR is discussed as an application for scenarios 2) and 3).
>
> I think it will be good to describe:
>
> 1) RPR motivation and target scenarios
> Describe where it is deployed and how it is been used.
> It is of particular importance to describe where the
> devices are located (in trusted buildings, locked but
> accessible cabinets, ...). Other questions may come too.
>
> 2) Bridge operation
> Describe the bridging operation if there are extensions to a
normal
> bridge.
> I recall some common sessions with 802.1, 802.17 and EPON to
define
> an extension based on an extra field. We need to collect the cases
> for
> transparently passing encrypted packets for scenario 3.
>
> 3) MAC operation
> Depending on where encryption is put MAC control frames may be sent in
> clear.
> Therefore it is important to understand at this time what information
is
> generated at
> the MAC level to decide whether it is confidential or not. But the
level
> of confidentiality
> needed is "subjective" depending on application.
>
> Conversely, it is important to think about what happens if the packet
> comes encrypted
> or must be encrypted in the MAC.
> What fields would not be possible to encrypt?
> What is the impact of a larger frame size?
> Does RPR have any special cases for VLAN support?
>
> In summary, we need a description of the scenarios, MAC operation and any
> impact of this operation to other 802 protocols. We do not expect a
security
> analysis of RPR. In fact this presentation is an overview material to help
> the group doing the security analysis. So the speaker is released of this
> "responsibility". If you mention this, it may be easier to identify a
> volunteer. Otherwise, people can get intimidated.
>
> If we can get the material in advance, people can review it and ask
> questions to help refine the material. The contribution deadline for the
SG
> is the week before the meeting on Monday (march 3rd). Also, we have a
weekly
> call where we can have an initial discussion with the person preparing the
> material.
>
> Let me know what will work and I can get the arrangements.
>
> Thanks,
>
> Dolors
>
> ----- Original Message -----
> From: "Mike Takefman" <tak@xxxxxxxxx>
> To: "Dolors Sala" <dolors@xxxxxxxx>
> Sent: Tuesday, February 11, 2003 5:24 PM
> Subject: Re: Link Security presentation
>
>
> > Dolors,
> >
> > we are actually going to be doing comment resolution
> > during that timeframe, but I will endeavor to send
> > someone. How long a talk are you looking for?
> >
> > In terms of special needs, I would be interested in
> > knowing what (if any) special needs other MACs require
> > so that it can get us thinking in the right mindset
> > to indentify requirements.
> >
> > thanks,
> >
> > mike
> >
> > > Dolors Sala wrote:
> > >
> > > Hello Mike,
> > >
> > > I am looking for someone to give an overview presentation of RPR to
the
> Link
> > > Security SG.
> > >
> > > There is significant interest within the group in making sure that the
> > > security mechanism defined works for RPR, but no one is knowledgable
> enough of
> > > the RPR definition. We may not be able to guarantee anything specific
> for RPR
> > > unless we get this knowledgable participation. But it would help to
have
> at
> > > least a presentation overview now that we are discussing scenarios and
> > > requirements.
> > >
> > > As you saw in the SEC reflector, we are having a session on Monday
> morning.
> > > Therefore, 802.17 participants can come and contribute to this session
> without
> > > having any overlap with normal .17 schedule.
> > >
> > > In fact, I would like to have an 802.17 representative in this session
> to give
> > > a overview presentation and answer questions related to the standard.
> The best
> > > would be a good speaker who can give an impartial presentation and
give
> > > background history of the group's evolution, discussions and decisions
> if
> > > asked.
> > >
> > > I know you have to be in the SEC meeting at that time, Could you
> recommend
> > > someone?
> > >
> > > I'll appreciate your help,
> > >
> > > Thanks,
> > >
> > > Dolors
> > >
> >
> > --
> > 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 cell:613-220-6991