Re: [pim] IETF69 pimwg mtg minutes

[JW Atwood <[e-mail]>]

see comments/corrections inline:-

Mike McBride (mmcbride) wrote:
> For complete audio recording of proceedings please see:
>
> http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ietf69-ch3-we
> d-afnoon.mp3
>
> Mike: Agenda review. Welcome to Stig Venaas as new pimwg co  chair.
> Thank you to Tom Pusateri for the many years of work  in the pim wg. He
> has now stepped down.
>
> Stig: looking forward to getting to even more useful work in the  pimwg.
>
> Mike: Update on existing drafts and charter. bsr mib draft is  done and
> forwarded to Ross/Dave for IESG processing. WGLC was  complete. pim join
> attributes draft is complete as well. rpf vector draft will have wglc
> now that recent changes completed. Last hop threats draft ready also for
> wglc. bidir draft - Mike to answer final questions from rfc editor. 
>
> Mike: Charter now approved/updated. refresh reduction one new  charter
> item. The previous discussion on this was forwarded onto the list,
> please review. Now need to come up with solutions. variety of proposed
> solutions:  join/prune acks. tcp based approach. Since no one
> volunteered, Mike/Stig to create a doc to bound the requirements
> (requirements or problem statement).
>
> Bill:
> linklocal draft. 01 draft came out before deadline. minor changes  to
> reflect output of San Diego meeting. We put back requirement  to support
> per interface choosing of the SAs because v6 speakers  can use linklocal
> addresses that are not not globally unique. And  since no one saw need
> to use a different address took out text  that gave the choice and
> confined it to all pim routers.
>
> Bill: 
> Looking at 4552 doc which does authentication and  confidentiality. Put
> both in his doc. Might change his title from security to authentication
> and confidentiality. new stuff:  identifying what the groups are and
> group per speaker (router).  Need to establish agency relationships and
> control them in group  controller. In parallel with this work there is a
> draft, in  ipsec, concerned with this same problem but for ospfv3. They
>   
                          rpsec
> can't assume any unicast routers exist upon boot up. Req's of htat draft
> will be the same as Atwood but constraints on those requirements more
> difficult. That draft is giving him ideas. They started req's doc. Bills
> view is that router is the center of the world. Talk about security
> association mgmt. 4552 has two models one having a pair of security
> assocs for the entire region and they recommend that for the manual
> keying. The other one in 4552 one sec assoc per speaker, the router has
> to maintain n+1 SAs. One for itself and one outgoing. Leos draft needs a
>   
Liu's draft (draft-liu-ospfv3-automated-keying-req-01.txt)
> key server on each segment.  They have 4 models proposed but no
> solutions. They need a key server on network. How do you keep that key
> server live and which router. 
>
> Bill: routers as speakers of pim packets, we can bring down  numbers of
> keys. draft leo view is subnet centered. req's a group  with assoc keys
>   
draft-liu (as above)
> per router per int. From perspective as router as  speaker of pim
> packets: can bring down number of keys. 4  possibilities: pair of
> security assocations for whole domain. A  pair of input/output sec assoc
> for a subnet. An SA per speaker.  An sa per speaker per subnet. 
>
> Bill: question of who to distribute the keys to. The 4th option req's
> the gcks to keep track of the adjacency of every router along with the
> interface info. Option 3 requires gcks to keep track only of a single
> router. Then look at how to control who we distribute the keys to since
> we don't want to distribute the keys to everyone. key server should have
> a database associated with it listing the wires connected and if any new
> routers come up, shut him off. We need to complete the req's statement
> and map that reqs statement to the various group key  mgmt protocols. 
>
> Question to WG: what group key mgmt protocols should he look at  first?
> comments please. 
>
> Stig - BSR. 
> submitted new revision. bsr went to ietf lc few months ago. some
> feedback during that lc. Alex went through the changes last ietf. Also
> reviews by security directorate. Wasn't so easy to do ipsec replay
> protection for bsr. They point informationally to Atwoods draft. bsr
> messages do go out hop by hop so Atwoods draft will work. 
>
> another change: using acls for checking who should receive BSM's.  In
> the bsm you have the address of the bsr who originated the  bsm. They
> have recommended having acl to block bsm that were not one of the
> desired ones. realized its not that useful. BSR border is a good
> mechanism to drop all bsr messages at the border. remove  recommendation
> for acl and mention bsr border. if someone wants  to use acl they can.
> revision 12 soon and tell iesg that we are  ready to move on.
>
> Stig - pim unreachable draft in behalf of authors. Anyone at the edge
> can join a group towards the RP or source and its easy to do dos attack.
> if a join message fails and creates a tree, its hard to track down the
> problem. proposing a  mechanism to provide feedback down the tree where
> the problem is.  tell the admins where it might be. dos attacks if there
> is no one interested in receiving the content or joining towards RP that
> doesn't exist, it would be nice to flush the tree/state. could use
> embedded rp to launch an attack. lots of joins for lots of groups going
> to the same RP. RPs just trust embedded RP packets. SSM joins is another
> attack, pick a random unicast address and lots of joins towards that.
> pim tree unreachability would be a  message forwarded hop by hop where
> the problem occurred and what the problem was. proposal is to not send
> on mcast group, but send it hop by hop and aggregate info. If a router
> receives a message upstream it can take note in its pim attributes that
> there was a problem. send unreachability info to the edges so they can
> no what the problem is. If edge router realizes there is a problem,
> could stop sending joins up stream. as an operator this could help. you
> know the problem is upstream somewhere but not sure where. mtrace is
> another option. If you have certain permanent errors you would signal
> downstream and you would stop joining upstream. 
>
> Gorry - How do you know the message (saying that you have the  wrong RP)
> that you received is valid?????
>
> Atwood - wouldn't want to put in hands of an end user or edge  router
> the ability to tell everyone to stop joining this group,  there is an
> dos 
>
> Stig - you only accept messages from upstream. if you dont get  this
> message that is the upstram that you sent the join to, you  ignore this
> message and you trust your pim neighbors. if you get  an ipsec message
> saying I'm not the rp, you will trust it. Its  transitive. the first
> router would get it from the rp and he will  accept and trust and he
> passes it down and the next one gets it  and he trusts his neighbors.
>
> Fenner - i'm much more comforable with the informational aspect of this.
> Its helpful for debugging. but it makes me very nervous to say that this
> is going to stop joins from going upstream. and it may make things worse
> in certain failure situations because the network wont heal as quickly
> because this will suppress the messages that would have helped the
> failure heal.
>
> Stig - yes, it could take longer time. I'm  also concerned with this
> mechanism for actually stopping the joins.
>
> Stig - how much extra effort for routers to do the signalling?  the few
> extra messages used for signalling is a small fraction of  the number of
> useless messages you would avoid. Not much extra  memory consumption. 
>
> Stig - in general, do you think its useful for signalling  downstream to
> see where the error might be, worth considering  that further? or what
> mechanisms are missing to diagnose problems  or fix them as quickly as
> possible? please give comments on the  list.
>
> Mike - another draft entitled pim ping, sent to the list, for the  wg to
> consider. something the wg should review and consider as  well. 
>
>
> _______________________________________________
> pim mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pim
>   

-- 

Dr. J.W. Atwood, Eng.             tel:   [phone] x3046
Professor Emeritus                fax:   [phone]
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email: [e-mail]
1455 de Maisonneuve Blvd. West    http: //users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8


_______________________________________________
pim mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pim