Keying and Authentication for Routing Protocols WG
(karp WG; RTG Area)

Chairs: Joel Halpern <>, Brian Weis <>

Administrative Items, Chairs

Mailing List Address:
To Subscribe:


Scribes (Meeting Minutes and Jabber)

-      Richad Graveman (Meeting Minutes)

-      Wes George (Jabber)


Blue Sheets

Links to slides are on the KARP agenda & proceedings pages for IETF 83.

Welcome and Document Status, Chairs

See presentation slides.

Note well.

RFC 6518 was published.

The threats-reqs draft is waiting for AD go-ahead. Other drafts depend on this.

The document dependencies tree was shown.

RFC 6518 (Design Guide) promises work on KMPs. The threats-reqs draft promises more work on KMP requirements. The WG will do generic solutions (e.g., IKEv2) and then protocol-specific documents, not more pure requirements documents on KMP. OK?

Core Document

KARP Overview, Threats, and Requirements, draft-ietf-karp-threats-reqs-04, Manav Bhatia

See presentation slides. He covered changes, new title, application of RFC 4593, restructuring to include threat sources, specific requirements like shared keys, default mechanisms, and circular dependencies.

He proposed a quick second WG LC.

Mike St.Johns (MStJ): There was a change in Requirement 6. What is the impact on routing infrastructure? Immediate?

Sam Hartman (SH): New parameters do not imply not using old ones. The requirement is useless but harmless.

MStJ: Disagree. Matter of language. Clarify the text.

Steve Kent (SK): Slide 9. Default mechanism. Can anything work without configuration?

Manav Bhatia (MB): He cited IS-IS as an example. It does not specify a default.

SK: Is one a MUST?

MB: Yes. But what is the default?

SK: Still need to do keying. That is a configuration [step].

MB: See the entire document.

Gregory Lebovitz (GL) (from Jabber): On the first topic. This occurred in TCP-AO. On the second: He learned this doing IKEv2 testing.

Brian Weis (BW): Please review and comment.

Routing Protocol Analysis

KARP IS-IS security gap analysis, draft-chunduri-karp-is-is-gap-analysis-01, Uma Chunduri

See presentation slides: This was updated to the -01 version. It uses RFC 6518. Questions from IETF 82 were reviewed.

#1: BW asked for a clarification about lifetime 0.

#2: MB: What changed since RFC 5310? Ans.: Deployment experience. IS-IS may be on the broadcast network.

Chairs: Discuss WG adoption on the ML.

Key Management

Database of Long-Lived Symmetric Cryptographic Keys, draft-ietf-karp-crypto-key-table-02, Sam Hartman

See presentation slides:

       Goals were derived from discussions among authors (GL: What does communicating secret mean? Ans.: covered later)

       What key tables include


       Proposed changes in DB(1) (GL: provide an example of separate key name and key ID? Ans.: Russ Housley (RH) cited 802.1)

       Proposed changes in DB(2) (Acee Lindem (AL): Sharing keys across protocols? Ans.: No, not done. If share keying info, then multiple entries) (BW: Clarification: BGP is not interface specific. Ans.: Use peer, not interface, for things like BGP)

       Textual Conventions (Jabber: With respect to local and remote, sending and receiving is clearer),

       What protocols specify(1)

       What protocols specify(2) (Jeff Haas (JH): An example is IPv6 link local. SH: Need to document this.) (Tero Kivinens comments on the ML will be addressed.)

       Management Approach (Wes George (WG): Need for more operator feedback).

Key Management for Pairwise Routing Protocols, draft-mahesh-karp-rkmp-01, Dacheng Zhang

See presentation slides:

SA Payload:

SK: TCP-AO is not a RP. LDP discovery is UDP over a certain port. SH: Wait for next slide. SK: No, still not clear.

TCP-AO (GL: Need more field to make this work.)

Traffic Selector Payload:

SK: Can use existing IKEv2 structure, even if it has more than needed. Analysis of both approaches is should be done.

SH: Consider in context of previous presentation. Desirable to use key tables (KT). Using IKEv2 may be more work.

JH: Clarification: KT is an abstraction. If KMP uses the KT abstraction, is this the conceptual simplification?

RH and SK: There must be a mapping back to KT.

SK: Still is a need to analyze both approaches.

Tero Kivinen (TK): IKEv2 traffic selectors use addresses and other things that may not be used here. Most RP parameters use protocols or port numbers that can be expressed in IKEv2.

SH: Yes, the comparative analysis should be done.

Uma Chunduri (UC): Agree, can use IKEv2 TSs.

Using IKEv2 with TCP-AO, draft-chunduri-karp-using-ikev2-with-tcp-ao-01, Uma Chunduri

See presentation slides:

SK: Pulled in TCP-AO key derivation functions. Questioned need. Clarified.

BW: Difference between Gatekeeper and KT? Ans.: Gatekeeper handles lifetimes, has configuration and keying information.

SH: Need to do the same analysis as above with respect to KT.

TK: Two proposals are similar and may be missing some pieces, e.g., lifetimes and data management. Can push much of Gatekeeper to KT.

TK: The IKEv2 and KT designs need to be harmonized. Merge IKEv2 drafts. Specify interface to keying material.

GL: Does IKEv2 do the timing. Ans.: NO.

GL: Interface with UI? [see Jabber log]

TK: If this is all pushed into IKE, a lot of policy is needed. KT does not have policy information, which IKEv2 needs.

GL: KT is not the right place for IKE-specific policy information.

Multicast Router Key Management Protocol, draft-hartman-karp-mrkmp-04 and draft-tran-karp-mrmp-01, Paulina Tran

See presentation slides.

Drafts will be merged. A simplified state machine is now included.

GL: Need one solution, not two. BW: Group KM is different.

BW and RH: Had previous discussions on choosing key server. Key server may not be a router. (GL: Or a router that is now acting just as a key server.)

MB: Should be independent of the DR.

SH: Analysis of state 1 is questionable.

Key Management and Adjacency Management for KARP-based Routing Systems, Bill Atwood

See presentation slides.

SK: Identifiers exist in the BGP (including I-BGP) sense.

GL: This is good for the pairwise key case. See Jabber log.

Time ran out.