KARP Minutes - Thursday 17:40-19:40 Scribes: Acee Lindem - acee.lindem@ericsson.com and Richard Graveman - rfgraveman@gmail.com Chairs: Brian Weis/Joel Halpern Audio: http://www.ietf.org/audio/ietf79/ietf79-ch3-thur-noon3.mp3 Begins 13:58 from the beginning of the recording. Mailing list is karp@ietf.org. To Subscribe: https://www1.ietf.org/mailman/listinfo/karp. The archive is at http://www.ietf.org/mail-archive/web/karp/current/maillist.html. Document Status - Joel Halpern - Slides: http://www.ietf.org/proceedings/79/slides/karp-5.pdf - The N.B. was presented. - Need review of documents Progress Report - Joel Halpern - Intend to poll WG as to whether key table direction is agreed upon. Greg Lebovitz: What is the exact issue that will go to list? Joel Halpern: The architectural direction of key tables (Houseley/Polk) will be validated as the direction for the WG. KARP Design Guidelines - Gregory Lebovitz - Draft: http://tools.ietf.org/html/draft-ietf-karp-design-guide-01 - Slides: http://www.ietf.org/proceedings/79/slides/karp-3.pdf - See slides for detailed changes to document. - Will incorporate EKR's comment in next revision. - Frequency of key change has been actively and recently debated. New text exists. - Sam Hartman retracted his comment on the document. He confirmed text on slide 6. Sam Hartman: Encourages progress on the design guidelines. Work on manual keys first then automated key management procedures. Do not allow gates in getting work done. Consider forming design teams before document approved. Joel Halpern: We want to make sure this document is completed before work on solutions commences. Chartering design teams is under consideration. Greg: Agrees with Joel and believes the document is close to completion. Threat Analysis - Gregory Lebovitz - Draft: http://tools.ietf.org/html/draft-ietf-karp-threats-reqs-01 - Slides: http://www.ietf.org/proceedings/79/slides/karp-4.pdf - See slides for detailed changes. Russ White joined the design team. - More work on terminology may have limited returns. - Document is becoming stable. Joel Halpern: Didn't we get comments on this? Greg: No - those were Stephen's comments on the KARP Design Guide. Sam: Names for the various keys were confusing. Long-term key, traffic key, and peer key. Action Item: Greg and Sam will work on terminology for key. Russ Housley: Is the key table terminology not adequate? Acee: Found the key table document least confusing. Sam: There were keys that could not be described with the current terminology. Database of Long-Lived Cryptographic Keys - Tim Polk - Draft: http://tools.ietf.org/html/draft-housley-saag-crypto-key-table-04 - Draft: http://tools.ietf.org/html/draft-polk-saag-rtg-auth-keytable-04 - Slides: http://www.ietf.org/proceedings/79/slides/karp-6.pdf - See slides for content. - This is architectural, close to an information model. Not bits and bytes. - They considered IS-IS as a test case, i.e., stress test, especially for multicast. He explained timestamps, replay counters, and the flooding protocol Greg: Multicast routing or protocols using multicast? Tim: Protocols using multicast. Sam: Believes it will work with PIM. Brian: Thinks it will work for PIM. Tony Li: Sees no need for a separate password per interface for IS-IS. Tim: This is needed to assure you don't cross wires (mis-configurations) Sam: This is the worst case example. You wouldn't need to deploy it this way. Nothing forbids making the keys the same. The document describes the more general case. Tony: Possible but you need a trust relationship between routers. Tony: Timestamps in the IIH is easier than sequence number. Acee: Do not need to synchronize clocks or save every one. Allow a small window. Greg: Should these be separate documents or part of a single framework document? Tim: Thinks they should be separate since they are standalone and can be approved and published. Russ: Only the key table document absolutely has to move forward. Greg: Thinks multiple pieces may be more difficult for implementors. Sam: Key table document forms integral part of information model and should be separate. Joel Halpern: Should the key table be adopted as a WG document? Room: Full support of the document. Sam: What about the other document? Joel Halpern: Need discussion on the list as to whether it should even be completed. Greg Cauchie: Need to clearly differentiate between multicast protocols and Routing protocols using multicast Operations Model for Router Keying - Sam Hartman - Draft: http://tools.ietf.org/html/draft-hartman-karp-ops-model-01 - Slides: http://www.ietf.org/proceedings/79/slides/karp-1.pdf - See slides for content. Joel Halpern: Asked for clarification on trust boundaries and treating peers differently in one case from another. Greg: This is a good exercise. Does this reflect new requirement that will go into Requirements Document? Sam: Doesn't think so. Greg: BGP filter represents a new requirement. Sam: Shouldn't hold requirements hostage. Joel Halpern: Some of the RPs have their own constraints. Charter includes guidelines for operators as a work item. Do not have to hold the requirements document for this. Publish guidance for operators. This is important. Sam: Request WG adoption of document. Joel Halpern: Operators have differing views of whether the tools apply to both IGPs and BGP. Should this be reflected in the document? Sam: We build the tools for those who believe it is relevant. We are chartered to do this. Joel Halpern: If it is not used, should we do it? Should we discuss where this is applicable. Greg: This must be relevant to the operators. We need to find a way to get the operators to participate in the documents. Brian: We need to work with OPSEC to get review. Joel Jaeggli: Volunteers Chris Morrow to participate. Sam: Supports this type of collaboration. Joel Halpern: Should this be adopted as WG document or do we want one more round of comment? Room: Some support of document. Will take it to the mailing list. Multicast Router Key Management Protocol (MRKMP) - Sam Hartman - Draft: http://tools.ietf.org/html/draft-hartman-karp-mrkmp-00 - Slides: http://www.ietf.org/proceedings/79/slides/karp-2.pdf - See slides for content. - A lot can be learned from examining out-of-band KM and multicast issues. Support an approach that works for unicast too. - He discussed nonces and replays. This applies to OSPF in particular. Greg: If we can put nonces for inter-connection protection, it makes the KMP much easier. Connection is not well defined. Acee: Decouple GCKS from using protocol. One KMP per link would be desirable. Sam: Ok - if that is what WG decides. Greg: Did you look at sequence number wrap? Sam: We did but didn't think germane? Question will be taken to list. Joel Halpern: No call for adoption. Please review and provide comments. Automated Security Association Management for Routing Protocols - Yinxing Wei - Presented by Xiaoping Liang (Ellen) - Draft: http://tools.ietf.org/html/draft-liang-karp-auto-sa-management-rp-00 - Slides: http://www.ietf.org/proceedings/79/slides/karp-0.pdf - See slides for content. - She acknowledged the presentations on key management and asked about negotiation and algorithm agility. Ellen: Please review. Joel Halpern: Please send these comments to the ML. Sam: What are the Pros/Cons of IKEv2/ISAKMP alternatives? Ellen: Summarizes Pros/Cons. Brian: Thinks ISAKMP has been extended with DOI in a previous draft. Ellen: SA is needed to protect routing protocol. Ellen: Algorithm agility is requirement for KARP. No negotiation with of algorithm in MRKMP. Joel Halpern: Adjourned at 1928 local time.