Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements
draft-ietf-karp-threats-reqs-07

Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

-- Section 2.1 --
   Three basic services may be employed in order to secure any piece of
   data as it is transmitted over the wire: confidentiality,
   authenticity, or integrity.

You're not talking about *employing* these to secure anything; they're not "services" that you use.  You're talking about what you *get* as a benefit from securing the data.  Your goal here, by securing the data, is to get authenticity an integrity, but not confidentiality.  Please re-word this accordingly.  You also say "privacy" right after this.  Do you really mean "privacy", or should it be "confidentiality"?

-- Section 2.3 --
OLD
   3.  Ensure that the improved security solutions on currently running
       routing infrastructure equipment are deployable.  This begs the
       consideration of the current state of processing power available
       on routers in the network today.

This is a bit awkward in phrasing.  I suggest this:
NEW
   3.  Ensure that the improved security solutions are deployable on
       currently running routing infrastructure equipment.  This requires
       consideration of the current state of processing power available
       on routers in the network today.

But anyway, isn't this part of item 4, "Operational deployability"?

In item 4:
OLD
      F. There are three use cases for operational peering at play
          here: peers and interconnection with other operators, iBGP,
          and other routing sessions within a single operator, and
          operator-to-customer devices.

I'm not sure I see the three cases.  I think the problem is that one of the cases is itself a list with commas.  You should use semicolons in the outer list when that happens, but in this case maybe you just need to remove the comma after "iBGP"?

-- Section 2.4 --
Privacy and confidentiality are not the same thing; please don't use them interchangeably.  You mean confidentiality, and you should probably scrub the document of all instances of "privacy", because this happened in Section 2.1 as well.

-- Section 3.1.2.1 --
The second paragraph is long, rambling, confused, and confusing.  Please tighten it, trim it, and take out the unnecessary stuff about "well, he could be an INSIDER, and he could be BYZANTINE, but he's unauthorized, and then he's *really* unauthorized, so then he's an OUTSIDER and......"  May I suggest this for the whole paragraph?:
NEW
   A terminated employee, once an INSIDER, becomes unauthorized
   and an OUTSIDER at the point of termination -- no longer a legitimate
   participant in the routing system.  It behooves the operator to change
   the keys, to enforce the revocation of authorization of the old keys, in
   order to minimize the threat source's window of opportunity.

The last two paragraphs also repeat themselves, and should probably be merged.  For instance, the penultimate one says that key changes need to happen "very quickly, with zero impact to the routing system, and with little operational expense," and the last paragraph says, "quickly with minimal impact to the routing system, at low operational cost."  Whether zero or minimal, you shouldn't say the same thing twice in two paragraphs.  Do a merger here.

-- Section 3.2 --
      attacker sends
      spoofed packets aimed at halting or preventing the underlying
      protocol over which the routing protocol runs.

I can't parse "preventing the protocol".  "Halting the protocol" is OK, but "preventing" doesn't work the same way (you have to prevent it *from doing something*).  Re-word.

More general: are all DoS attacks on the routing system really spoofing attacks?  In general, some DoS attacks are done by spoofing and some aren't.  Is that not the case with routing attacks?  (I don't know; I'm asking.)

-- Section 4 --
Requirement 2:
        Strong cryptographic algorithms, as defined and accepted by the
        IETF security community, MUST be specified.  The use of non-
        standard or unpublished algorithms SHOULD BE avoided.

These are contradictory: non-standard and unpublished algorithms won't be accepted by the IETF security community, and so are already declared MUST NOT by the first sentence.  Make it "MUST be avoided," or "MUST NOT be used."

Requirement 3:
        Algorithm agility for the cryptographic algorithms used in the
        authentication MUST be specified, i.e. more than one algorithm
        MUST be specified and it MUST be clear how new algorithms MAY be
        specified and used within the protocol.

Hm.  You don't really need to have more than one algorithm specified; you just have to *be able* to specify more than one, and have a way to add new ones.  This requirement isn't meant to say that if only one suitable algorithm exists at the time the protocol is written, that's a problem.  The "MAY" is also an improper use of 2119 language.  How about this?:

NEW
        Algorithm agility for the cryptographic algorithms used in the
        authentication MUST be specified.  That is, it MUST be possible to
        choose which algorithm is being used, and  it MUST be clear how
        new algorithms are specified and used within the protocol.

You may also need to make changes later in the paragraph, where you say "Mandating two algorithms".

Requirement 5:
Item "A" seems out of place here.  It's not a requirement nor an explanation of one.  It's a specific threat that you've stuck in the middle of the requirements section.  (I also don't see how it directly relates to requirement 5.)  It should be moved elsewhere (maybe a new Section 3.1.3?).

Requirement 6:
        A change of security parameters REQUIRES, and even forces, a
        change of session traffic keys.

"REQUIRES" is not a 2119 word.  If you want to keep 2119 language here, maybe this:
NEW
        A change of security parameters MUST force a
        change of session traffic keys.

Otherwise, just make "requires" lower case.

Requirement 7:
        Intra-session re-keying which occurs without a break or
        interruption to the current routing session, and, if possible,
        without data loss, MUST be specified.

There's a little too much in there, and "if possible" seems not to go so well in the same sentence as MUST.  How about this?:
NEW
        Intra-session re-keying that occurs without a break or
        interruption to the current routing session MUST be
        specified.  If possible, this ought to happen without
        data loss.

Requirement 22:
The second paragraph looks like it should be a separate requirement, number 23.

-- Section 5 --
The second Security Considerations paragraph doesn't seem to belong here. As with paragraph "A" in requirement 5, above, it really looks like it should be moved to the threats discussion, and, in fact, seems like a variation of that attack (a variation that's performed by a Byzantine insider).  I suggest putting both attacks into a new Section 3.1.3, because they're so closely related.

The first paragraph of the Security Considerations seems to stand alone as sufficient for this document.

- Section 1.1

s/assymetric/asymmetric/

- Section 2.1

* I agree with Barry that the document should not inter-change confidentiality and privacy.  They are different components and can be accomplished in vastly different ways.

- Section 2.3

* Does backwards compatibility need to be considered?  Or is it being implied within the incremental deployment discussion?

- Section 4

* It may be the way I am reading them, but requirements 21 and 22 seem to be contradictory.  Requirement 21 says "if you can, centralize some features to reduce the work load on all routers".  On the other hand, requirement 22 says "don't build in any external dependencies".

  Please consider the editorial comments from the Gen-ART Review by
  Vijay Gurbani on 18-July-2012.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07639.html

Thank you for addressing my concerns.

- Are there any weird cases where a lack of address
aggregtaion (esp for IPv6) could create a privacy
issue that would mean that a confidentiality service
might be needed? (Just checking)

- s/privacy/confidentiality/ please

- the language telling secdir reviewers what to do ought
be less presecriptive

- I agree with Sean's discuss