Re: [karp] [OPSEC] FW: WG LC: draft-ietf-karp-ops-model-05 to Informational

"George, Wes" <> Wed, 03 April 2013 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58C2721F8F35 for <>; Wed, 3 Apr 2013 08:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.713
X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oe3epJ2pu0mu for <>; Wed, 3 Apr 2013 08:21:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7A71521F8F41 for <>; Wed, 3 Apr 2013 08:21:47 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,402,1363147200"; d="scan'208";a="51302005"
Received: from unknown (HELO ([]) by with ESMTP/TLS/RC4-MD5; 03 Apr 2013 11:21:17 -0400
Received: from ([]) by ([]) with mapi; Wed, 3 Apr 2013 11:21:36 -0400
From: "George, Wes" <>
To: "" <>
Date: Wed, 3 Apr 2013 11:21:35 -0400
Thread-Topic: [OPSEC] FW: [karp] WG LC: draft-ietf-karp-ops-model-05 to Informational
Thread-Index: AQHOLxXw3vWrcjE1GEWl9qEmYdf7sZjCpHeQgAHiHVA=
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 03 Apr 2013 08:27:38 -0700
Cc: "" <>
Subject: Re: [karp] [OPSEC] FW: WG LC: draft-ietf-karp-ops-model-05 to Informational
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Apr 2013 15:21:50 -0000

I've reviewed this draft before at Sam's request, so I don't have a lot of comments, but here are a few items I see in the most recent version in WGLC.

3.2 key expiration -- Might be useful to have a pointer to 6.2 where handling expiration faults is discussed in more detail. Also, would it be appropriate to discuss a config knob to more finely control expiration handling? I'm thinking of something that would allow a fail-open or fail-safe condition, where expiration generates a fairly insistent warning but instead of immediately tearing down that session, the implementation will maintain the session as long as it stays up, but if it goes down for some other reason (lost connectivity, etc.) it will not be permitted to re-establish until the expired key is addressed. I'm sure there are some security risks to this, but it might be a useful tradeoff for folks still getting the hang of managing key expiration.

5. Grouping peers - need to be able to ungroup a peer or peers without impacting routing - one of the problems with things like BGP Peer groups using a common MD5 password today is that if you need to change the password, you affect the entire peer group at once. The ability to override a group config with a peer-specific config as an extension of key rollover provides a lot of flexibility, such that it may be useful to make that an explicit requirement. This is discussed some in Section 7, but may need some companion text here.

6.1 - not sure I'd assume that proper procedures are in place to be followed. The overlap between "Router people" and "security people" is often limited, so I'm of the mind that some amount of specifics in terms of rules of thumb are useful, or at least discussing what if anything might be different in handling this provisioning step.
see also draft-ietf-sidr-rtr-keying's discussion of provisioning a router. Discussion on some of that in my review of that document. Thread here:


Wes George

> -----Original Message-----
> From: [] On Behalf
> Of Gunter Van de Velde (gvandeve)
> Sent: Tuesday, April 02, 2013 5:11 AM
> To:
> Cc: Joel Halpern
> Subject: [OPSEC] FW: [karp] WG LC: draft-ietf-karp-ops-model-05 to
> Informational
> Dear OPSEC WG,
> Please take some time to comment upon draft-ietf-karp-ops-model-05.
> Make take your comments direct to the authors and copy the KARP WG.
> The KARP working group is designing improvements to the cryptographic
> authentication of IETF routing protocols.  These improvements include
> improvements to how integrity functions are handled within each protocol
> as well as designing an automated key management solution.
> Kind Regards,
> G/ (OPSEC Co-chair)
> > From: Brian Weis <>
> > Subject: [karp] WG LC: draft-ietf-karp-ops-model-05 to Informational
> > Date: March 26, 2013 5:00:19 PM PDT
> > To: "" <>
> >
> > This begins a two week WG last call to determine if folks will support
> the chairs to submit
> >     <>
> > to our AD for publication as an Informational RFC.
> >
> > Please send comments of support, or raising issues or concerns, to the
> WG email list by 5pm PDT on 9-April-2013.
> >
> > Thank you,
> > Joel M. Halpern
> > and Brian Weis
> > co-chairs
> > _______________________________________________
> > karp mailing list
> >
> >
> --
> Brian Weis
> Security Engineering, SRG, Cisco Systems
> Telephone: +1 408 526 4796
> Email:
> _______________________________________________
> OPSEC mailing list

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.