[pim] IETF69 pimwg mtg minutes

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
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
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
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
pim@ietf.org
https://www1.ietf.org/mailman/listinfo/pim