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

Chairs: Joel Halpern <jmh@joelhalpern.com>, Brian Weis <bew@cisco.com>

Administrative Items

Mailing List Address: karp@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/karp
Archive: http://www.ietf.org/mail-archive/web/karp/

Scribes, blue sheets, note well.

Welcome and Document Status, Chairs

See slides karp-4.

There were no additions or deletions to the agenda. The scheduling of the Design Guide discussion may be rearranged.

The status of WG documents was reviewed. The Design Guide will go back through the WG after resolving the IESG DISCUSS. The Threats document is waiting for the Design Guide.

Core Documents

· Design Guide Frameworks Discussion, draft-ietf-karp-design-guide-07

See mailing list comments on Russ Housley’s DISCUSS. See also slides karp-4.

This was deferred.

· Database of Long-Lived Symmetric Cryptographic Keys, draft-ietf-karp-crypto-key-table-02, Tim Polk

See slides karp-2.

This draft has existed for a while. Applying the methods in it to 802.1x required changes. WG LC was delayed. The -02 draft was submitted at the deadline.

Sam Hartman (SH): Indicated that some comments were not addressed. These arose when applying this to OSPFv2. Time Polk (TP): Perhaps these comments are covered—please wait.

Explained how a peer identifies a key.

Mentioned virtual interfaces.

For 802.1x, the Protocol field was insufficient. A ProtocolSpecificInfo field and registry were added.

KDFs and AlgorithmIDs now also have registries.

Because of OSPFv2, four time values for keys are now included.

Open issue: Change the LocalKeyID field from 16 bits to Integer.

Back to SH: (1) OSPF virtual links need a way to identify keys for receive and send. (2) Key Table authors were asked to review the Ops Model draft. (3) The relationship between Key Tables and automated key management needs clarification. SH offered to follow up on these points on a conference call. Accepted. December.

Manav Bhatia (MB): Question about widely shared keys. See Ops Model draft.

SH: Argued against using four time values. TP: Will reconsider. Four seems to be the exception.

Brian Weis (BW): Recounted the history of the draft and asked whether this is moving towards Standards Track. TP: Regards this as a conceptual model and not a mandate. But complete enough to build a reference implementation. Open to more discussion of Informational versus Standards Track. SH: Promoted making this document authoritative. If not, the document needs to say less.

Joel Halpern (JH): Need to get the details right. Then address the status.

BW: Requested a new version.

· Resumption of the Design Guide Discussion

Picked up after the Key Table presentation.

The DISCUSS and the mailing list comment from MB were reviewed.

The question was posed. Does this capture the DISCUSS?

Russ Housley (RH): Do not need to reference the Key Table document, rather the concept.

MB: What exactly is needed? RH: Routing protocols will use a key table. The population of the key table may be (1) manual, (2) two-party automated, or (3) group key management.

Keyur Patel (KP): Is this implementation dependent? RH: No.

SH: Proposed a three-step process to define how this works. RH: Agreed. SH: Will not cover specific group key management methods—too many complications. RH: Wants it to say that automated key management will leverage existing work and populate the key table.

MB: to standardize this? RH: Yes.

Uma Chunduri (UC): Asked for a clarification of how parts of this works. RH: Explained key rollover.

SH: Advocated a single module that handles key tables and provides mappings. JH: Agree; please write up for the mailing list.

UC: Asked how rekeying is triggered for TCP. JH: Belongs in the mapping document. RH: Several specific cases have been examined.

· Operations Model for Router Keying, draft-ietf-karp-ops-model-01, Sam Hartman

See slides karp-6.

This document refers to the Key Tables document. Both documents need to be changed in concert.

Requested volunteers to discuss actual operations about deployment questions. Particularly, failure conditions. JH: Will talk to OPS Area.

Covered vendor issues, which also need discussion.

Thanked reviewers.

Sean Turner: Suggested NANOG. SH: Some reservation. Sean Turner (ST): Way to meet people. JH: Attends and may be able to help.

Routing Protocol Analysis Documents

· KARP IS-IS security gap analysis, draft-chunduri-karp-is-is-gap-analysis-00, Uma Chundauri

See slides karp-0.

Reviewed prior work and listed relevant RFCs. Listed steps of gap analysis process.

Current practice: Separate keys for sub-network dependent and sub-network independent cases. Mostly MD5. No coordinated key change mechanism.

Described replay, spoofing, and DoS attacks.

For manual systems, extended sequence numbers solves the wrap-around problem. Need a simple mechanism to change keys. Also made recommendation for automated KMP.

MB: why was the sequence number reintroduced? It is single hop.

UC: Gave rationale. MB: Asked for text clarifying this point.

SH: Asked about replay. Such attacks can be serious. UC: Discussed specific messages. SH: Asked about sequence number wrapping. UC: Will reconsider.

BW: Asked about the size of areas or domains. UC: 600 or 700 routers.

MB: Raised another point related to replay.

Automated Key Management for Routing Protocols Using TCP

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

See slides karp-1.

Reviewed previous work. Wants to minimize changes to all TCP-based Routing Protocols when introducing automated key management protocol. For IKEv2, what kind of authentication is appropriate—symmetric, asymmetric, or EAP-based?

What is needed from IKEv2?

Covered BGP multisession requirements.

Discussed how to use key tables. Explained steps with a diagram. Covered what is needed from TCP-AO.

KP: Differences from IKEv2?

Steve Kent (SK): Why is the process different from IPsec?

Joe Touch (JT): Explained how policy is enforced. SK: Different question.

Tero Kivinen (TK): Argued for flexibility in the authentication mechanism. Operators can decide. Also, run IKEv2 for RPs on a different port.

MB: Why would you want different authentication methods for different RPs? JH: Gave examples of where this may happen. SH: asked on what criteria? Address? UC: Different lifetimes. MB: Why? SH: Pick the shortest lifetime. Argued for simplicity. JT: If you want to do different cases, a different socket pair is needed. But it is possible to automate this to a simple set of rules. Chris (Google): Asked about different entities versus different protocols between the same two entities. Clarification made.

· Key Management for Pairwise Routing Protocol, draft-mahesh-karp-rkmp-00, Dacheng Zhang

See slides karp-3.

Merged two drafts presented at the last meeting.

Described the RKMP state machine, exchanges based on IKEv2, and payloads (SA and TS).

JH: How does the RP initiated KM related to Key tables? SH: The Routing Protocol, in all proposals, triggers key management when needed. This is a requested clarification to Key tables.

TK: Looks like more work, not reusing much from IKE. SH: Believes it is the same except for TS part. TK: SA payload also appeared different. Speaking from the viewpoint of code reuse. JH: If it is just like IKEv2, make them the same.

Dan Harkins (DH): What is the authentication method? Answer: Same as IKE.

TK: Easier to implement if specific differences from IKEv2 are enumerated. Continued to list many points.

SK: Advocated a profile of IKEv2.

Automated Key Management for Multicast-Based Routing Protocols

· The Use of G-IKEv2 for Multicast Router Key Mgmt, draft-tran-karp-mrmp-00, Paulina Tran

See slides karp-5.

Described key management for Routing Protocols that use multicast addresses by applying a group key management model with a key server.

Summarized and listed next steps.

There was no discussion.