For complete audio recording of proceedings please see: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ietf69-ch3- wed-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 has been forwarded to Ross/Dave for IESG processing. WGLC has been completed. 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 is one new charter item. The previous discussion on this was forwarded onto the list, please review. Now need to come up with solutions. There are a 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 the 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 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 rpsec, concerned with this same problem but for ospfv3. They can't assume any unicast routers exist upon boot up. Req's of that 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. Liu’s draft (draft-liu-ospfv3-automated-keying-req-01) needs a 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 liu’s view is subnet centered. req's a group with assoc keys per router per int. From perspective of router as speaker of pim packets: can bring down number of keys. 4 possibilities: pair of security associations 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 a dos Stig - you only accept messages from upstream. if you dont get this message that is the upstream 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.