Subject: Re: [karp] Work on framework & Mcast Keying (was "Re: follow up from our discussion on Sun 7/25")

From: Gregory Lebovitz <[email-masked]>
Date: Wed, 28 Jul 2010 08:12:26 -0700

and now cc'd to karp list too...

On Wed, Jul 28, 2010 at 8:11 AM, Gregory Lebovitz <[email-masked]>wrote:

> Sure, tomorrow (Tuesday) lunch works for me too.
>
> Should we grab a table toward the back of the lunch room and meet there at
> 11:45, after having gotten food?
>
> I'm changing the title, and cc'ing the WG so that we keep this an open
> process.
>
> Gregory
>
> On Wed, Jul 28, 2010 at 7:44 AM, Brian Weis <[email-masked]> wrote:
>
>> Hi Sam,
>>
>> Thursday lunch works for me. If that doesn't work for others, Friday lunch
>> would work too.
>>
>> Brian
>>
>>
>> On Jul 28, 2010, at 4:25 PM, Sam Hartman wrote:
>>
>>  Dacheng Zhang and I worked on the original analysis in this area We'd
>>> love to participate in a discussion of the multicast KMP.
>>> Could people meet at lunch tomorrow or some time on Friday?
>>>
>>
>>
>> --
>> Brian Weis
>> Security Standards and Technology, ARTG, Cisco Systems
>> Telephone: +1 408 526 4796
>> Email: [email-masked]
>>
>>
>>
>> On 7/28/2010 3:37 AM, Brian Weis wrote:
> > Hi Sam,
> >
> > Thanks for your summary regarding a KMP for multicast link-local
> > protocols. As Gregory mentioned we spent some time thinking along
> > similar lines. To put this in context, I was recently involved in a key
> > agreement specification for MACsec (an IEEE 802.1 layer 2 security
> > protocol), which was published as part of IEEE 802.1X-2010 and it
> > actually solves a very similar problem. That is, agreement of a key
> > among a group of devices on a network segment. If you're interested and
> > available sometime this week, I'd be happy to describe the constraints
> > we were given and the lessons we learned in building that protocol.
>
> JWA>  I would love to be a fly on the wall (or a participant!) for this
> discussion.  Unfortunately, I am stuck here in Montreal.
>
> >
> > Whether the IETF needs a seperate KMP for routing protocols or whether
> > the KMP should be integrated into the routing protocols will probably be
> > largely determined by what the routing protocol folks themselves can
> > stomach. I personally expect they won't find revising all of their
> > protocols to include a MKP to be palatable.
>
> JWA> For PIM-SM, no revisions are necessary; it can all happen in the
> IPsec level.  OSPF is a different story.
>
> > But on the other hand a
> > large part of a MKP at this level is a neighbor discovery and dead peer
> > detection, which tend to be integral to the routing protocols jobs
> > anyway. Also the routing protocol folks may have some sensitivity to
> > latency added having to wait for a KMP to complete.
>
> JWA> Which is why we need a fully-distributed solution to cover the
> reboot situation, where you cannot allow newly-rebooted routers to go to
> the KMP (at least not right away).
>
> > So it may be there's
> > actually some value to the integration. I'd personally like to see both
> > approaches thought through a bit by a team of routing and security
> > folks. With my co-chair hat on, I think that might be a good job for a
> > design team -- probably doing that as part of an OSPF design team.
> >
> > I absolutely agree with your point that authentication method reuse
> > across routing protocols would be a major win.
>
> JWA> +1
> >
> > Thanks,
> > Brian
> >
> > On Jul 27, 2010, at 6:36 PM, Sam Hartman wrote:
> >
> >> Greg, I'll resend the analysis point.
> >>
> >> I actually am not sure we need a different KMP for macast, but I think
> >> we need a layer between the KMP and the macast protocol.  I.E. the KMP
> >> delivers you a group key that is current; rekeys involve the GKS.  We
> >> probably can reuse the same GKS with all our macast protocols, although
> >> we probably want to take advantage of the multicast protocols mechanisms
> >> for electing someone to be GKS if present.
> >>
> >> We could also have a separate KMP for the macast siuation, but I think
> >> that reusing the KMP or at least the authentication stages would be a
> >> major win in terms of deployment and code reuse.
> >>
> >> My point was not so much that I thought that having KMP separate from
> >> routing protocols was a good idea is that I didn't see any huge problems
> >> with it.  Given the constraints you've presented that means we should do
> >> it.  I can't say I'm entirely happy to live in a universe with those
> >> constraints:-)
> >
> >
>
> On Tue, Jul 27, 2010 at 9:45 AM, Gregory Lebovitz <g<[email-masked]>
> [email-masked]> wrote:
>
> >On Tue, Jul 27, 2010 at 9:36 AM, Sam Hartman <[email-masked]>
>  wrote:
>
>> Greg, I'll resend the analysis point.
>>
>> I actually am not sure we need a different KMP for macast, but I think
>> we need a layer between the KMP and the macast protocol.  I.E. the KMP
>> delivers you a group key that is current; rekeys involve the GKS.  We
>> probably can reuse the same GKS with all our macast protocols, although
>> we probably want to take advantage of the multicast protocols mechanisms
>> for electing someone to be GKS if present.
>>
>
> GML> Brian and I spent a long time discussing this and bouncing ideas
> around and I think we have a pretty good possible solution in mind. It's a
> bit too much for a quick email. I think we'll need to write it up. But it is
> very much in line with what you are saying here.
>
>
>
>>
>> We could also have a separate KMP for the macast siuation, but I think
>> that reusing the KMP or at least the authentication stages would be a
>> major win in terms of deployment and code reuse.
>>
>
> GML> Agreed fully.
>
>
>
>>
>> My point was not so much that I thought that having KMP separate from
>> routing protocols was a good idea is that I didn't see any huge problems
>> with it.  Given the constraints you've presented that means we should do
>> it.  I can't say I'm entirely happy to live in a universe with those
>> constraints:-)
>>
>
> GML> Understood. Ideally we'd do the ideal, but that's idealistic... ;-)  -
> Gregory
>
>
> On Tue, Jul 27, 2010 at 8:45 AM, Gregory Lebovitz <g<[email-masked]>
> [email-masked]> wrote:
> Sam,
> Here are the things I took away from our talk at the reception on Sunday.
> Pls confirm I got the main messages correct:
>  - your analysis has now led you to believe that we do indeed need to
> separate the KMP from the routing protocol daemons
>  - as the karp documents have been stating clearly (or trying to, anyway),
> there will need to be a radically different base auth AND KMP model for the
> mcast'ing protocols (or modes of protocols) than for the 1:1 peer-wise
> protocols/models.
>
> I thought you said that you had written an email to me about the first
> point above. I believe I've now read (or at least scanned) all your emails
> to me over the past months, and I did not see an email stating the results
> of your analysis specifically about that topic. Did I miss that one, or scan
> too quickly through the others?
>
> We should probably sit down while here and talk in more detail about this
> stuff, so that I can get an update of the framework document out sooner than
> later. I'll send a different email to set time together.
>
> Thanks again for your partnership on this stuff,
> Gregory
> (cc'ing Bill, Brian and Joel, as I'm sitting here with Brian talking about
> making progress on the framework document.)
>
> --
>
> --
>
> Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
> Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
> Department of Computer Science
>   and Software Engineering
> Concordia University EV 3.185     email: [email-masked]
> 1455 de Maisonneuve Blvd. West    http: //users.encs.concordia.ca/~bill
> Montreal, Quebec Canada H3G 1M8
>
>
>
> --
> ----
> IETF related email from
> Gregory M. Lebovitz
> Juniper Networks
>

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks

---

From: Gregory Lebovitz <[email-masked]>
Date: Wed, 28 Jul 2010 23:33:10 -0700

minor correction to a typo:  the design session will be today 
(THURSDAY) at lunch.
Gregory

On 7/28/10 8:12 AM, Gregory Lebovitz wrote:
> On Wed, Jul 28, 2010 at 8:11 AM, Gregory Lebovitz 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Should we grab a table toward the back of the lunch room and meet
>     there at 11:45, after having gotten food?
>
>     I'm changing the title, and cc'ing the WG so that we keep this an
>     open process.
>
>     Gregory
>
>     On Wed, Jul 28, 2010 at 7:44 AM, Brian Weis <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi Sam,
>
>         Thursday lunch works for me. If that doesn't work for others,
>         Friday lunch would work too.
>
>         Brian
>
>
>         Email: [email-masked] <mailto:[email-masked]>
>
>
>
>     On Tue, Jul 27, 2010 at 9:45 AM, Gregory Lebovitz <g
>     <mailto:[email-masked]>[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     >On Tue, Jul 27, 2010 at 9:36 AM, Sam Hartman
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     GML> Brian and I spent a long time discussing this and bouncing
>     ideas around and I think we have a pretty good possible solution
>     in mind. It's a bit too much for a quick email. I think we'll need
>     to write it up. But it is very much in line with what you are
>     saying here.
>
>
>     GML> Understood. Ideally we'd do the ideal, but that's
>     idealistic... ;-)  - Gregory
>
>
>     On Tue, Jul 27, 2010 at 8:45 AM, Gregory Lebovitz <g
>     <mailto:[email-masked]>[email-masked]
>     <mailto:[email-masked]>> wrote:
>     Sam,
>     Here are the things I took away from our talk at the reception on
>     Sunday. Pls confirm I got the main messages correct:
>      - your analysis has now led you to believe that we do indeed need
>     to separate the KMP from the routing protocol daemons
>      - as the karp documents have been stating clearly (or trying to,
>     anyway), there will need to be a radically different base auth AND
>     KMP model for the mcast'ing protocols (or modes of protocols) than
>     for the 1:1 peer-wise protocols/models.
>
>     I thought you said that you had written an email to me about the
>     first point above. I believe I've now read (or at least scanned)
>     all your emails to me over the past months, and I did not see an
>     email stating the results of your analysis specifically about that
>     topic. Did I miss that one, or scan too quickly through the others?
>
>     We should probably sit down while here and talk in more detail
>     about this stuff, so that I can get an update of the framework
>     document out sooner than later. I'll send a different email to set
>     time together.
>
>     (cc'ing Bill, Brian and Joel, as I'm sitting here with Brian
>     talking about making progress on the framework document.)
>
>     -- 
>
>     --
>
>     <mailto:[email-masked]>
>     <http://users.encs.concordia.ca/%7Ebill>

-- 
~~~~~~~~~~~~~~
IETF related Email from
Gregory Lebovitz
Juniper Networks