Subject: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt

From: [email-masked]
Date: Thu, 10 May 2012 10:53:13 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Keying and Authentication for Routing Protocols Working Group of the IETF.

	Title           : Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements
	Author(s)       : Gregory Lebovitz
                          Manav Bhatia
	Filename        : draft-ietf-karp-threats-reqs-05.txt
	Pages           : 32
	Date            : 2012-05-10

   Different routing protocols exist and each employs its own mechanism
   for securing the protocol packets on the wire.  While most already
   have some method for accomplishing cryptographic message
   authentication, in many cases the existing methods are dated,
   vulnerable to attack, and employ cryptographic algorithms that have
   been deprecated.  The "Keying and Authentication for Routing
   Protocols" (KARP) effort aims to overhaul and improve these
   mechanisms.

   This document does not contain protocol specifications.  Instead, it
   defines the areas where protocol specification work is needed and a
   set of requirements for KARP design teams to follow.  RFC 6518,
   "Keying and Authentication for Routing Protocols (KARP) Design
   Guidelines" is a companion to this document; KARP design teams will
   use them together to review and overhaul routing protocols.  These
   two documents reflect the input of both the IETF's Security Area and
   Routing Area in order to form a mutually agreeable work plan.

   This document has three main parts.  The first part provides an
   overview of the KARP effort.  The second part lists the threats from
   RFC 4593, Generic Threats To Routing Protocols, that are in scope for
   attacks against routing protocols' transport systems, including any
   mechanisms built into the routing protocols themselves, which
   accomplish packet authentication.  The third part enumerates the
   requirements that routing protocol specifications must meet when
   addressing those threats for RFC 6518's "Work Phase 1", the update to
   a routing protocol's existing transport security.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/

---

From: Gregory Lebovitz <[email-masked]>
Date: Thu, 10 May 2012 11:04:12 -0700

Hey all,
This version -05 addressed all the known content issues (a total of 6) that
were brought to our attention during the 2nd WG LC.

Brian - I think we are ready to go back for IESG approval.

FYI, we started a simple GoogleDoc tracker for this last version. It is
located here:

https://docs.google.com/document/d/10lSS99Rq3wCDKgyrNuv-9dxbbInOIIVDb_BWaPxrm9Q/edit

Hope it helps,
Gregory

On Thu, May 10, 2012 at 10:53 AM, <[email-masked]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Keying and Authentication for
> Routing Protocols Working Group of the IETF.
>
>        Title           : Keying and Authentication for Routing Protocols
> (KARP) Overview, Threats, and Requirements
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

-- 
----
IETF related email from
Gregory M. Lebovitz

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 18 May 2012 20:00:17 -0400

Dear Authors,

I read this version and the document is in good shape.

If, it's not too late, I have few comments on the 05 version.

1.a) Page 4: Section 1.  Introduction
    Third Bullet:
    "   o  Create specifications for cryptographic validation of routing
      message content."
    "The third bullet is being addressed in the SIDR
   working group."
   Though we can understand what SIDR is doing -  "routing message content" just doesn't imply BGP message?
   I can understand what you are trying to say, but IMO, what is said is not representative.

  b) 7. Sec 2.4:
   "Message content validity (routing database validity).  This work
      is being addressed in other IETF efforts, like SIDR."

   I am not sure "routing database" above is synonymous to BGP. Be explicit calling out, as this can wrong impression on SIDR scope.

2. Section 1, Last paragraph, unnecessary ending quote.

3. Section 1.1, Page 6:
   "If session or traffic
      keys are being used, KMP is responsible for generating them and
      determining when they should be renewed."

   This is not necessarily the only way as it sounds. KMP can also be used for only master key generation and
   traffic keys are generated from the same by the master key consumer. And also determining when the keys should
   be renewed may not be KMP function. So I am not quite you define KMP this way.

4. Sec 2.2:
   "However,in the spirit of incremental
   deployment, we first addressed issues like cryptographic algorithm
   agility, replay attacks, and TCP session resetting in the base TCP-AO
   protocol, and then later began work to layer key management on top of
   it."
   Though authors might have worked on AO, but the above can be better
   represented how TCP-AO is planned to be evolved.

5. Sec 2.3, Page 13, Point 7.
   " For example, designers should aim to re-use the key management
       protocol that will be defined for BGP's TCP-AO key establishment
       for as many other routing protocols as possible."

       Why this should be BGP's TCP-AO ?? I presume, TCP-AO is a generic protocol
       and any TCP-based pair wise RP or client/server can use this. It's better to
       say "other routing protocols with similar [characteristics/properties] as possible"

6. Section-4 Page 20
   >>document(s)."
   Extra ending quote.

7."   21.  Given the number of routers that would require the new
        authentication mechanisms in a typical ISP deployment, solutions
        can increase their appeal by minimizing the burden imposed on
        all routers in favor of confining significant work loads to a
        relatively small number of devices.  Optional features or
        increased assurance that engenders more pervasive processing
        loads MAY be made available for deployments where the additional
        resources are economically justifiable."
     What is the requirement?

--
Uma C.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gregory Lebovitz
Sent: Thursday, May 10, 2012 11:04 AM
To: [email-masked]; Brian Weis; Bhatia, Manav (Manav)
Subject: Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt

Hey all,
This version -05 addressed all the known content issues (a total of 6) that were brought to our attention during the 2nd WG LC.

FYI, we started a simple GoogleDoc tracker for this last version. It is located here:

Hope it helps,
Gregory

On Thu, May 10, 2012 at 10:53 AM, <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________
karp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/karp

--
----
IETF related email from
Gregory M. Lebovitz

---

From: Brian Weis <[email-masked]>
Date: Fri, 18 May 2012 18:06:50 -0700

Hi Gregory,

> Brian - I think we are ready to go back for IESG approval.

Stewart will be reviewing -05 and decide whether it's ready to forward to the IETG.

Thanks!
Brian

-- 
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Gregory Lebovitz <[email-masked]>
Date: Thu, 31 May 2012 07:57:56 -0700

Hello, Uma. Thanks for your input.

No, I don't believe it's too late. It looks like these are all fairly minor
clarification issues, and no major content debates, which gives me great
hope that we are very near completed!!

Please find comments inline below. Let me know if the proposed resolution
text for each point is ok. Once agreed, I'll issue draft-06.

Manav, could you please address the last issue ASAP?

Note to community:  I have updated the karp-threats-reqs issue tracker
(google doc, public access) with ID's for the noted items below.

Thanks again for the review,
Gregory

On Fri, May 18, 2012 at 5:00 PM, Uma Chunduri <[email-masked]>wrote:

> **

How about this:
NEW: The third bullet is being addressed in other efforts within the IETF. *For
example, BGP message content validity is being addressed in the SIDR
working group.*
*
*
*(Tracker ID 08)*

>    I am not sure "routing database" above is synonymous to BGP. Be
> explicit calling out, as this can wrong impression on SIDR scope.
>

How about this:
NEW: This work is being addressed in other efforts within the IETF. *For
example, BGP message content validity is being addressed in the SIDR
working group.*
*
*
*(Tracker ID 08)*

> 2. Section 1, Last paragraph, unnecessary ending quote.

Got it. Tracker ID 09.

>    traffic keys are generated from the same by the master key consumer.
> And also determining when the keys should

Understood. How about this:

NEW:   In some routing protocols traffic keys are derived by the routing
protocol from session / master keys. In this case, KMP is responsible for
the session / master key generation. In other cases, there are only traffic
keys (and no session / master keys), and KMP is responsible for the traffic
key generation.

tracker ID 10.

>    represented how TCP-AO is planned to be evolved.

TCP-AO's published RFC contains "cryptographic algorithm
   agility, replay attacks, and TCP session resetting". And it is true that
after AO's RFC published, the community began work on the key management
for it. So I think the sentence is ok. No change.

>        say "other routing protocols with similar
> [characteristics/properties] as possible"
>

Understood. How about this:
NEW:  For example, designers should aim to re-use the key management
protocol that will be defined for BGP, which will establish keys for
TCP-AO, for as many other routing protocols with similar characteristics
and properties as possible.

tracker ID 11

>    Extra ending quote.

Got it. ID 09

>         resources are economically justifiable."

We've been back and forth on this requirement since its original insertion,
i.e. you are not the only one with this question. I'm going to let my
co-author, Manav, handle this question. I've entered it on the tracker as
ID 12. Manav, could address this ASAP?

Thanks again, Uma, for the detailed review,
Gregory

>
> --
> Uma C.
>
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Gregory Lebovitz
> *Sent:* Thursday, May 10, 2012 11:04 AM
> *To:* [email-masked]; Brian Weis; Bhatia, Manav (Manav)
> *Subject:* Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt
>
> Hey all,
> This version -05 addressed all the known content issues (a total of 6)
> that were brought to our attention during the 2nd WG LC.
>

-- 
----
IETF related email from
Gregory M. Lebovitz

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 31 May 2012 14:33:20 -0400

Hi Gregory,

Changes look fine to me. See my comments in-line..[Uma]
--
Uma C.

________________________________
From: Gregory Lebovitz [mailto:[email-masked]]
Sent: Thursday, May 31, 2012 7:58 AM
To: Uma Chunduri; Bhatia, Manav (Manav)
Cc: [email-masked]; Brian Weis
Subject: Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt

No, I don't believe it's too late. It looks like these are all fairly minor clarification issues, and no major content debates, which gives me great hope that we are very near completed!!

Please find comments inline below. Let me know if the proposed resolution text for each point is ok. Once agreed, I'll issue draft-06.

Note to community:  I have updated the karp-threats-reqs issue tracker (google doc, public access) with ID's for the noted items below.

On Fri, May 18, 2012 at 5:00 PM, Uma Chunduri <[email-masked]<mailto:[email-masked]>> wrote:
Dear Authors,

How about this:
NEW: The third bullet is being addressed in other efforts within the IETF. For example, BGP message content validity is being addressed in the SIDR working group.

[Uma]: Sure.

(Tracker ID 08)

  b) 7. Sec 2.4:

How about this:
NEW: This work is being addressed in other efforts within the IETF. For example, BGP message content validity is being addressed in the SIDR working group.
[Uma]: Sure.
(Tracker ID 08)

Got it. Tracker ID 09.

3. Section 1.1, Page 6:
   "If session or traffic

NEW:   In some routing protocols traffic keys are derived by the routing protocol from session / master keys. In this case, KMP is responsible for the session / master key generation. In other cases, there are only traffic keys (and no session / master keys), and KMP is responsible for the traffic key generation.

[Uma]: Perhaps you can drop "session/" in the above, as that sounds more synonymous to traffic keys rather than master key (both places).

tracker ID 10.

4. Sec 2.2:

TCP-AO's published RFC contains "cryptographic algorithm
   agility, replay attacks, and TCP session resetting". And it is true that after AO's RFC published, the community began work on the key management for it. So I think the sentence is ok. No change.

[Uma]: Ok.

Understood. How about this:
NEW:  For example, designers should aim to re-use the key management protocol that will be defined for BGP, which will establish keys for TCP-AO, for as many other routing protocols with similar characteristics and properties as possible.
[ Uma]: Sure.
tracker ID 11

6. Section-4 Page 20
   Extra ending quote.

Got it. ID 09

We've been back and forth on this requirement since its original insertion, i.e. you are not the only one with this question. I'm going to let my co-author, Manav, handle this question. I've entered it on the tracker as ID 12. Manav, could address this ASAP?

--
Uma C.

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Gregory Lebovitz
Sent: Thursday, May 10, 2012 11:04 AM
To: [email-masked]<mailto:[email-masked]>; Brian Weis; Bhatia, Manav (Manav)
Subject: Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt

Hey all,

Hope it helps,
Gregory

--
----
IETF related email from
Gregory M. Lebovitz

--
----
IETF related email from
Gregory M. Lebovitz