Keying and Authentication for Routing Protocols (KARP) Design Guidelines
draft-ietf-karp-design-guide-10

Various paragraphs mention "modern, strong security algorithms", but that term is never defined. Given that the only algorithm mentioned in the text is SHA-1, the reader is left to wonder what is meant by "modern" and "strong".

I don't see a need for the use of RFC 2119 keywords in this document.

The document tries to define "on the wire".  I do not find the
  definition helpful.  I think it is sufficient to say that "on the
  wire" protection can be achieved by the addition of authentication
  and integrity mechanisms to the routing protocol or by running the
  routing protocol over a security protocol the provides them.

  Why define the KMP acronym?  It is not used many places.

  Please remove the URL to the MSEC charter.

I do not mean for any of these comments to change the intent of what was there before.

#1) s1: I think you should quote the bullets from 4948 and then say where they're being done:

OLD:
       
  o  Increased security mechanisms and practices for operating  
     routers. This work is being addressed in the OPSEC Working  
     Group. 
       
  o  Cleaning up the Internet Routing Registry repository [IRR],   
     and securing both the database and the access, so that it  
     can be used for routing verifications.  This work should be  
     addressed through liaisons with those running the IRR's  
     globally. 
     
  o  Specifications for cryptographic validation of routing  
  message content.  This work is being addressed in the  
  SIDR Working Group. 
       
  o  Securing the routing protocols' packets on the wire 


NEW:
  
  o  Increased security mechanisms and practices for operating  
     routers.
       
  o  Cleaning up the Internet Routing Registry repository [IRR],   
     and securing both the database and the access, so that it  
     can be used for routing verifications.
       
  o  Specifications for cryptographic validation of routing  
     message content. 
       
  o  Securing the routing protocols' packets on the wire. 

The first bullet is being addressed in the OPSEC Working Group.
The second bullet should be addressed through liaisons with
those running the IRR's globally.  The third bullet is being
addressed in the SIDR Working Group.

This document addresses ...

#2) s1: Contains the following:

  This may overlap with, but is strongly distinct from, 
  protection designed to ensure that routing information is 
  properly authorized relative to sources of this information.

maybe "protection" is supposed to be "mechanism":

  This may overlap with, but is strongly distinct from, 
  mechanisms designed to ensure that routing information is 
  properly authorized relative to sources of this information.

#3) s1: Contains the following:

  Such assurances are provided by other mechanisms and are 
  outside the scope of this document and work that relies on it. 

maybe "assurances" is "authorizations":

  Such authorizations are provided by other mechanisms and are 
  outside the scope of this document and work that relies on it. 

#4) s1: Contains the following:

  In 
  this document, it is used to refer both to information 
  exchanged between routing protocol instances, and to underlying 
  protocols that may also need to be protected in specific 
  circumstances.

what's a routing protocol instance?  Is it just routing protocols or maybe it should be "exchanged between routers"?

#5) s1: Contains the following:

  Individual protocol analysis documents will 
  need to be more specific in their usage. 

Maybe:

  Other documents that will analyze individual protocols will
  need to indicate how they use the term "on the wire".

#6) s1: I couldn't parse this:

  The 
  term is used here to allow a referent for discussing both 
  common and disparate issues that affect or interact with this 
  dimension of the routing systems.

actually the 2nd to last paragraph confuses me.  I think you're trying to say that:

  The term "routing transport" is used to refer to the layer
  that exchanges the routing protocols.  Examples include: TCP, UDP,
  or even direct link level messaging.

Do you need to say anything else?

#7) s2: Contains the following:

   For the purpose of this security roadmap definition, we categorize 
   routing protocols into groups and anticipate that design teams will 
   focus on the specification of security mechanisms within each 
   group. The protocols will be grouped according to the requirements 
   for authentication mechanisms that they are believed to have, and 
   it is assumed that reuse of authentication mechanisms will be 
   possible and desirable within each group. The work items placed on 
   the roadmap will be defined and assigned based on these 
   categorizations.

How about 

  This document places the routing protocols into two categories according
  to their requirements for authentication.  We hope these categories will
  allow design teams to focus on security mechanisms for a given category.
  Further, we hope that the each protocol in the group will be able to reuse
  the authentication mechanism.

#8) s2: Contains the following:

  KMPs are useful for 
  allowing simple, automated updates of the traffic keys used in a 
  base protocol.

Maybe:

   KMPs allowing simple, automated updates of the traffic keys used in a 
   base protocol.

#9) s2.1: r/categorization/category
          r/message which is intended for consumption by multiple peers/
            message which is intended for multiple peers
          r/because of the fact that they are inherently/
            because they are inherently/  


#10) s2.1: Need to describe how multicast is different from one-to-many

#11) s2.1: Contains the following:

  As a result, some mechanisms for a few routing protocols,

I'm not sure what you mean by "some mechanisms"?  Are these message transaction types?

#12) s2.1: Contains the following:

   This may include any ...

What's the "this referring to?

#13) s2.1: contains the following:

   the techniques that are used for the message exchanges. 

Maybe:

   the techniques that are used for the message transaction type.   
 
#14) s2.2: Contains the following:

   The second axis of categorization groups protocols is by the 
   keying mechanism that will be necessary for distributing 
   session keys to the actual Routing Protocol transports.

Maybe:

   The second category is the
   keying mechanism that will be used to distribute the
   session keys to the routing transports.

#15) s2.2: Contains the following:

   routers. This would be 
   employed by protocols like BGP, BFD and LDP. 

Maybe:

   routers (e.g., BGP, BFD, and LDP).

#17) s3.1: r/2048 for/2048 bits for

#18) s3.1: When describing the symmetric key to asymmetric key size comparison please add a reference to RFC 3766.  It describes exactly this comparison (look in Section 5).

#19) s3.1:r/using SSH/using Secure SHell (SSH) Protocol
          r/employed to by SSH/employed by SSH
          r/when a user/when an administrator

#20) s3.1: Contains the following:

  Once an asymmetric key pair is generated, the KMP generating 
  security association parameters and keys for routing protocol 
  may use the machine's asymmetric keys for the identity proof.

r/asymmetric key/asymmetric key (the sentence is talking about one key pair)

Is it an "identity proof" or is it that the public key is used during an authentication token/credential?  Maybe it's use "the machine's asymmetric key pair as an authentication credential".  Then the next sentence is about the type of token/credential:

   The form of the token could be raw keys, the more 
   easily administrable self-signed certificate, or a PKI-
   issued certificate [RFC5280]. 

and then:

  Regardless of which credential is standardized, the proof of 
  this identity presentation can be as simple as a strong hash,
  which could be represented in a human readable and transferable 
  form of some pairs of ASCII characters. 

Actually I'm not sure what the "proof of this identity presentation" is all about.  Maybe it's authentication:

  Regardless of which credential is standardized, the authentication
  mechanism can be as simple as a strong hash over a string of ASCII
  characters.

later r/identity proof/authentication mechanism

#21) s3.1: I'll give you a free pass on the self-signed certificate, but it's at least one person's hot button in PKIX - that 5280 only defines self-signed certificates as a CA certificates.

#22) s3.2: Is there a reference for the key chain?  I think I know what you're talking about, but is that written down for a protocol now?

#23) s3.2: r/for doing the same./for rolling the key.  
           r/they are likely to get disclosed/they are likely to be disclosed
           r/with the send and the receive keys/with the send and the received keys ?

#24) s4.1: Contains the following:

  It is believed that improving security for any routing protocol 
  will be a two step process or could be said to involve two 
  phases.

just pick one :)

  It is believed that improving security for any routing protocol 
  will be a two phase process.

#25) s4.1: Contains the following:

  The first would be to fix the manual key management 
  procedures that currently exist within the routing protocols 
  today using modern cryptography algorithms and key agility. 

Isn't the first step to add modern crypto and key agility to the protocols?

  The first phase would be to modify routing protocols to support modern
  cryptography algorithms and key agility. 

#26) s4.1: this is a little wordy:

  In order to deliver that to the operators in a way 
  that we could complete these action items a little bit a time 
  and make some incremental advance over what is currently 
  deployed in the wild, we believe that it is therefore useful to 
  cleanly separate the key management protocol from the routing 
  transport subsystem mechanism.

How about:

  In order for operators to accept these phases, we believe that
  the key management protocol should be clearly separated from the
  routing transport.

and later:

  written by 
  people good in security and who will be maintaining it over the 
  time and insert those parameters in the routing exchange.

with

  written, maintained, and operated by security experts

#27) s4.1: contains the following:

  The desired end state for the KARP work contains several items.  
  First, the people desiring to deploy securely authenticated and 
  integrity validated packets between routing peers have the 
  tools specified, implemented and shipping in order to deploy.

Maybe

  The ultimate goals of KARP contain several items.  
  First, provide a mechanism to allow routing peers to exchange
  authenticated and integrity protected packages.

#28) s4.1: contains the following:

  In larger 
  deployments, this end state will be much more operationally 
  difficult to reach with only manual keys.  Thus, there will be 
  a need for key life cycle management, in the form of a key 
  management protocol, or KMP.


Maybe the following to be explicit that a KMP is the second goal:

  However, manual keying in larger deployments will be too burdensome
  for operators.  Thus, the second goal is to support key life cycle
  management with a KMP.

and maybe instead of:

  We expect that the two forms, 
  manual key usage and KMP usage, will co-exist in the real 
  world.   

this:

  We expect that both manual and automated key management will
  co-exist in the real world.

#29) s5: r/[RFC2747/[RFC2747]

#30) s6: r/be at least on set of cryptography algorithms or constructions 
          /be at least one set of cryptographic algorithms

I'd just strike "or constructions" from the rest of the draft.  I'm not sure what you mean by it.

#31) s6: contains the following:

   If such algorithms or constructions 
   are not available then some should be defined to support 
   interoperability by having a single default. 

I think you're trying to say:

   If such algorithms have not been defined, then define them and
   pick a default algorithm.

#32) s6: I think you want to say support algorithm agility:

   Care should also be taken to ensure that the routing protocol 
   authentication scheme is capable of supporting algorithms other 
   than its defaults, in order to adapt to future discoveries. 

Maybe:

   Care should also be taken to ensure that the routing protocol 
   authentication scheme has algorithm agility (i.e., it is capable
   of supporting algorithms other than its defaults).

#33)  s6:

OLD:

   Ideally, authentication MUST be performed on routing protocols 
   packets oblivious to the order in which they have arrived, so 
   that it does not get influenced by packets loss and reordering. 

NEW:

   Ideally, the authentication mechanism MUST NOT be affected by
   packets loss and reordering. 

#34) s6: r/authentication mechanism remains oblivious of how the 
          /authentication mechanism remains oblivious to how the

#35) s6: Maybe

OLD:
   
   The KARP work is but one step in 
   a necessary system of security improvements.

NEW:

   The KARP work is but one step needed to improve core routing
   infrastructure.

#36) s7: Need to add something in the first paragraph to talk about key lengths.  Maybe the pointer to RFC 3766.  Maybe:

  In addition to generating good keys, care should be taken when
  choosing the length of the key.  [RFC3766] provides some additional
  information on asymmetric and symmetric key sizes and how they related
  to system requirements for attack resistance.

#37) s7:

   This is because if 
   attackers sitting between two routers learn or guess the 
   Traffic Key for that connection, it still does not gain them 
   access to the Traffic key being used in other connections.

Maybe:

   Consider an attacker that learns or guesses the Traffic Key used
   by two peer-routers: if the Traffic key is only used between those
   two routers, then the attacker has only compromised that one connection
   not the entire network.

#38) s7: doesn't the following presuppose a solution:

   Doing so has the following advantages: the Traffic Keys 
   used in the per-message MAC operation are peer-wise unique, it 
   provides inter-connection replay protection, and, if the per-
   message MAC covers some connection counter, intra-connection 
   replay protection. 

Maybe replace MAC with authentication mechanism?  Or are we all really just fooling ourselves?

#39) s7.1: contains the following:

  Administrators are encouraged to follow [RFC4086.

Add the "]" and maybe we should also be pointing to the NIST spec on password (Special Publication 800-118)

r/, in as/as

It might be worth mixing in that the reason you need the key prep is that administrators are NEVER EVER going to put in a password that is 16 bytes in length ;)

And, maybe saying operators do stupid things isn't such a good idea ;)

#40) s7.3: r/The goal for designers/ One goal for designers    - s4.1 says there's more than one goal.

#41) s7.4: r/Out-of-and/Out-of-band

I don't know what "very strong keys" might be. Keys are either good
or bad, not very good or very bad.

I still don't see a reference for a two time pad. You really need that.

---- original comments on -03 below

- Abstract: "This document is one of a series concerned with
defining a roadmap of protocol specification work for the use of
modern cryptographic mechanisms and algorithms for message
authentication in routing protocols. " What does that mean? What
series? Why is the document "concerned with defining a roadmap" and
not just setting out a roadmap or guidelines or something
understandable?

- Abstract: presumably the KMP "framework" is for managing keys for
routing protocol security and not more generally?

- Section 1: "Thus, it is concerned with guidelines for describing
issues and techniques for protecting the messages and their contents
between directly communicating peers." That is incredibly vague -
the guidelines are really about "describing issues"?

- Section 1: What are "individual protocol analysis" documents?
RFCs tend to specify, but not analyse, protocols.  (This became
clear later but was not at this point.)

- Section 2: what is "Phase 2"? Does it assume a "Phase 1"? If so,
what is/was phase 1? (You explain that in section 4.2 but refer to
it much earlier).

- Section 3.1: "will be very secret" seems optimistic (and is 
presumably referring only to the private component of the key 
pair). "will not be subject to change" seems to make a lot of
assumptions. I've never heard tell of a dictionary attack on
an asymmetric key pair - why even mention it?

- Section 3.1: asymmetric algorithm key lengths are discussed
in rfc 3766 and in the literature, some references would be
good here (and maybe better than the current text) in particular
to the "NIST guidlines" cited but not referenced.

- 3.1: s/Once asymmetric key pair/Once an asymmetric key pair/

- 3.1 is missing references to rfcs related to PKI (5280 etc.)

- 3.2 says "using the key chains" - what are those? There is at
least a missing reference. And use "key chain" or "keychain" but not
both. 

- 4.1: The first paragraph here is confusing. I don't get what "KARP
parameters" might mean.

- 4.1: References for "inter-connection replay" and "two time pads"
would be good.

- Section 6 says: "Design teams while defining the new
authentication and security mechanisms MUST design in such a manner
that the routing protocol authentication mechanism remains oblivious
of how the keying material is derived." What does that mean? How
does one validate the MUST there? Does it really mean that a
'pluggable' KDF must be used to generate keying material? If so, why
not say so?

- There are many typos. Too many to identify.

- Section 7.1 says "...use of a KMP network-wide increases peer-wise
security so greatly." I don't think that can be justified in the
absence of a specific KMP. 

- Section 7.3 says: "In this context, the attack target size
represents the number of unique routing exchanges across a network
that an attacker may be able to observe in order to gain security
association credentials, i.e. crack the keys." I disagree with that.
I don't know how "attack size" is defined, but it sounds like you
should be discussing the impact of a successful attack. Also,
"cracking" keys by observing routing exchanges should really not be
possible and doesn't distinguish between key management schemes - if
that's possible, the routing protocol's security mechanism is just
broken at least for any sensible number of (pairs of) nodes, or else
a weak key has been chosen.

- Section 7.4: I've no idea what "one routing peer-to-peer key
management protocol exchanges" means.

- Section 7.4: I think peer-to-peer isn't a great term here. Maybe
router-to-router would be better?

- Section 7.4: " The desired end goal for KARP WG is develop a
strong peer-to- peer KMP as an Out-of-and external Key Management
protocol is out of scope." Huh?