AGENDA:

Administrative Items, Brian Weis (BW)                                               
   - Mailing list: karp@ietf.org
     * To Subscribe: https://www1.ietf.org/mailman/listinfo/karp
     * Archive: http://www.ietf.org/mail/archive/web/karp/current/maillist.html
   - Scribes (Meeting Minutes & Jabber)
   - Blue Sheets

Welcome & Document Status, BW

See slides karp-3.

Note well.

No changes to agenda.

Comments on WG documents requested.

Gregory Lebovitz over jabber (GJ(j)): Maybe do need to work on framework document. (See the email on the list that took place during the session.)

Acee Lindem (AL): May find someone to do IS-IS. May not be able to present.

Joel Halpern (JH): OK

Analysis of BGP, draft-mahesh-bgp-ldp-msdp-analysis-00, LDP and MSDP Security According to KARP Design Guide, Mahesh Jethanandani

See slides karp-2.

Slide 5: Encryption out of scope.

Slide 8: Anantha Ramaiah: Have methods for TCP.

Asked for WG adoption.

JH: Should we fold other protocols using TCP into this document? Ans.: If there is no other requirement. JH: Find someone to help. Sam Hartman (SH): A helpful document exists.

What other protocols (TCP)? Only one.

Keyur Patel (KP): Should do this. Yinxing Wei: what other messages?

Xiaoping Liang (XL): Working on a comprehensive KMP solution. Ans: Yes, this should be discussed.

LDP Hello Cryptographic Authentication, draft-zheng-mpls-ldp-hello-crypto-auth-01, Vero Zheng

See slides karp-0.

BW: Need to talk to MPLS chairs. May want to do this there.

AL: Acknowledge text from 5709, and (BW) correct boilerplate as needed.

Analysis of OSPF Security According to KARP Design Guide, draft-ietf-karp-ospf-analysis-00, Sam Hartman

See slides karp-1.

Changed to work from requirements. Action plan pending WG direction.

Changes based on JH, comments. Adjusted to intended audience.

Plan to address comments.

Asked for review. GL(j): Should we wait for AL's comments to be incorporated. Ans: Changes should not impact review substantially.

Discussed inadvisability of using same key for different protocols.

Discussed choice of replay prevention: extended seq no is simpler than challenge-response.

Dan Harkins (DH): Clarification on KDF and replay.

AL: Only the simpler (extended seq no) approach was presented in OSPF.

AL: OK with this.

GL(j): OSPF through a NAT? JH: Should be rare. SH: Can use the OSPFv3 approach. AL: Only one type of packet sent more than one hop.

RG: OSPFv2 is used differently in GMPLS (OSPF-TE).

Lou Berger (LB): Yes, but it just does not work with NATs.

AL: There is an overlay model to handle these other applications.

Multicast Router Key Management Protocol (MRKMP), draft-hartman-karp-mrkmp-01, Dacheng Zhang

See slides karp-5.

GL(j): Like description. Need a graphic or table to understand more clearly. Align Terminology.  SH: Will help with this. AL: Hard to explain state machine with text. Look at BGP.

DH: Section 5 in draft is blank. SH: This is not complete. Assume we are bootstrapping pairwise credentials to multiparty case. Do insure election and try to verify it securely. More details needed in document. JH: Diagrams are needed. SH: Yes, they are coming.

AL: Understand the problem. All the timers, states, and variables make it complicated. SH: Want to prevent bogus traffic from bringing the system down. DH: Asked for a clarification.

GL(j): Can we discuss more before the next mtg?
JH: Can we use self-signed certs? SH: Yes, but need a way to use them securely.

Section 2.4: Another clarification requested by GL.

JH: Other jabber comments. Where do we stand on BGP? Can focus on unicast too. A version of IKEv2 that handles this. Steve Kent (SK): Suggested not trying to simplify multicast to unicast. Cited minimal IKEv2 work by Tero Kivinen (TK). SH: Obvious how to use IKEv1 but not IKEv2. The IKEv2 protocol is clear, but the specification is IPsec wedded. DH: Why the complexity of IKE? SH: Trying to do something specific for RPs.

TK: Clarified the goals of minimal IKEv2. It is not exactly what is needed here.

XL: Asked about using MRKMP in other cases. SK: More about IKEv1. SH: No, a reworking of IKEv2. SH: Value of using similar exchanges in unicast and multicast has advantages. GL(j): Agree on benefits of commonality. SH: Work from simple to complex, not the other way. Wanted to confirm that the multicast case was possible before starting.

DH: Questioned IKEv2 approach again.

AL: Agree with SH. Should be able to collapse the multiparty case to two parties easily. SH: Need different names in the KMP.

GL: Agree with approach.