IETF 81
Keying and Authentication for Routing Protocols WG (karp WG, RTG Area)
Wednesday, July 27, 2011, 13:00-15:00

Chairs: Joel Halpern <jmh@joelhalpern.com>, Brian Weis <bew@cisco.com>
Area Director: Stewart Bryant <stbryant@cisco.com>

Tech Advisor: Tim Polk <tim.polk@nist.gov>

Minute Taker: Richard Graveman kindly provided minutes for this meeting.

Jabber Scribe: Wes George kindly acted as Jabber scribe and relayed Jabber comments to the mike.

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

Jabber Chat Room Address:xmpp:karp@jabber.ietf.org
Logs:<http://jabber.ietf.org/logs/karp/>

AGENDA:

Administrative Items

Note Well
Scribes (Meeting Minutes & Jabber)
Blue Sheets

Welcome & Document Status, Chairs (BW)

See slides. Design Guide completed WG LC; waiting for new draft.

Threats and Requirements is in IETF LC.

Russ Housley (RH) has changes for key tables.

Little news on OSPF Analysis and Ops Model. Sam Hartman (SH) asked about a WG LC on OSPF Analysis. The boot stuff should be in and it should be LC ready. Work is needed to synch Ops Model with Crypto Tables. Will wait to hear more on the ML.

For Routing TCP Analysis more reviews on the mailing list are welcomed.

Charter has more work. IS-IS and RSVP-TE need work. Work started on PIM. May be a gap on PCEP. Tell the Chairs if starting to work on something.

Routing Protocols Using TCP

LDP Hello Cryptographic Authentication, Vero Zheng
     - draft-zheng-mpls-ldp-hello-crypto-auth-02
See slides. Presented in Prague. Now a WG document karp-routing-tcp-analysis-00 exists. RFC 5036 does not protect Hello (UDP). Added optional crypto authentication TLV based on SHA-256 (MUST). A sequence number was added. Error fixed. Auth Type removed. Asked for review. Will request adoption in MPLS.

Brian Weis (BW): Protection similar to the OSPF solution.

Paul Hoffman (PH) asked how KARP tracks what other WGs are doing.

Joel Halpern (JH): WG-Chair-level coordination.

BW: OSPFv3 was the first example.

Sean Turner (ST): Asked about TCP MD5.

Vero: No, this is UDP. (SH: It’s called AH. J)

Unicast Router Key Management Protocol (RKMP) - Dacheng Zhang and Sam Hartman
     - draft-zhang-karp-rkmp-00

See slides. Unicast KMP to complement multicast (MRKMP) work. Based on IKEv2’s exchanges (4306).

PH and Tero Kivinen (TK): clarification of nonces and multiple SAs.

SH: May have multiple SAs for, say, multiple protocols. Share IKE SAs.

Steve Kent (SK): Asked about more values in the SA. Suggested traffic selectors.

SH: Only Protocol ID is needed.

SK: Disagrees. Before you throw something away, traffic selectors were designed to do this. Code reuse.

SH: The traffic selectors would be different at the bit-level. Ports.

TK: Encouraged keeping existing SA payload structures—complicated to change.

Dan Harkins (DH): DOI? Answer: No.

Uma Chunduri (UC): Need source port numbers.

SH: Disagrees. Will you have multiple BGP SAs between the same two endpoints? Not clear this needs to be negotiated at the IKE layer.

Jabber: Put in TS for different RPs.

UC: Asked about the keys given to TCP-AO.

SH: Works like ESP.

UC: TCP-AO only uses one key.

SH: Details still needed. Protocol Master Key is given to the protocol.

Jabber: Can you have a single SA across different RPs?

SH: Why do you want to do that?

UC: Traffic keys or master key?

SH: Take it off line.

Key Management for Pairwise Routing Protocol, Keyur Patel                                 
     - draft-mahesh-karp-kmprp-00
See slides. Described KMPRP. Again IKEv2-like. Uses a different port from IKEv2.

RPs can end up with multiple keys.

Key rollover is out of scope.

UC: Is this restricted to the exchanges described?

Keyur Patel (KP): Can extend this.

BW: EAP? Probably not applicable.

UC: Certificate-based mechanisms are required.

BW: Have not made this decision.

DH: What EAP credential are you considering?

UC: EKE.

SH: Have made general recommendation on this in ops model. Argued for consistency.

DH: Argued again against the IKEv2 structures.

SH: See the Ops Model.

BW and UC: Supported the IKEv2-style exchanges.

BW: Defined protocols and transforms distinct from IKEv2. Included TS for reasons cited before. More discussion was invited.

TK: Asked about registry reuse (e.g., for transforms). Shared but aligned.

BW: Important. Using real IKEv2 is a separate discussion.

SH: Recommended against that. Want separate daemons.

UC: Have two similar drafts. How do we move these two forward?

JH: Authors should try to converge. Will pick one.

PIM

Analysis of Protocol Independent Multicast Sparse Mode (PIM-SM) Security According to KARP Design Guide, Yiqun Cai
     - draft-bhatia-karp-pim-gap-analysis-00

See slides. Gap analysis covers more than PIM-SM. Lively debate in PIM WG.

Bill Atwood (BA): Clarified no replay detection with manual KM per RFC 5996. And also in older IKE docs as well.

Security is really only needed between immediate neighbors.

PH: Licensing issues?

BA: Vendor charges more.

No deployment of IPsec to protect PIM-SA, so similar approach to that taken by OSPFv3 was proposed—authentication trailer.

PH: Some vendors charge more is a weak reason for a new protocol.

Yiqun Cai (YC): Agree that the reasoning is not totally logical.

JH: Should “some vendors charge more” be removed from the gap analysis? Many agreed.

SH: Rephrased as a deployment issue. Lack of deployment is the question.

SK: Pricing is no basis for designing a new protocol.

BA: PIM-SM is different from OSPF. Requirements differ too. OSPF is older. Hope KARP makes it easy to deploy secure PIM.

Jeff Haas (JHaas): In some cases IPsec make actually require additional hardware or other overhead. Tradeoffs exist either way.

PH: Yes, there are other ways to do what IPsec does. They may have about the same overhead. Count the pieces. It comes out the same.

BW: As with OSPFv3, manual keying was the original sin. Multicast. Can do that.

PH: Is KARP getting away from manual keying?

BW: Eventually, not necessarily right away.

PH: Are we looking for a two-phase solution is each case? Short term and long term design will never get to the long term.

BA: Supposed to do short term things that facilitate longer term solutions.

David McGrew (DMcG): Do not invent new cryptography. Manual keying should not be done. ESP has an extended sequence number.

BW: Like boot counter.

Wes George (WG): Can’t in reality change from those manual keys. Best we can hope for is to solve the problem once. Don’t do something that makes it hard later.

JH: Confirm removing manual keying on the ML.

BFD

Analysis of Bidirectional Forwarding Detection (BFD) Security
     According to KARP Design Guide, Dacheng Zhang
     - draft-bhatia-zhang-karp-bfd-analysis-01

See slides. Identified replay protection, strong algorithms, and DoS attacks.

JHaas: Other documents in BFD cover most of this. May be a question on replay.

JH: Please send a note on this to the ML.

OSPF

Supporting Authentication Trailer for OSPFv3, Acee Lindem
     - draft-ietf-ospf-auth-trailer-ospfv3-05

See slides. Prior to IETF 80, there was a lot of discussion of replay and extended sequence numbers. Draft has now been updated. Uses 64 bit sequence numbers and a new OSPFv2 AuthType, defines key selection rules, and protects source address.

WG: Call it a wrap counter.

BW: Why is the address repeated four times (in the APAD)?

AL: To fill the field.

SH: It does not matter.

SH: Please review the key tables part.

PH: What is the motivation on the boot-wrap counter vis-à-vis IPsec?

SH: For manual keying.

OSPF Discussion - Chairs

See slides

BW: Asked for comments.

SH: Asked for reviews of gap analyses.