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

[Ballot discuss]
Based on -06

1) s4 #5: Needs more detail about inter- and intra-session replay protection.

2) s4 #8: I don't entirely understand this:

8.  Re-keying SHOULD be supported in such a way that it can occur
      during a session without the peer needing to use multiple keys
      to validate a given packet.  The rare exception will occur if a
      routing protocol's design team can find no other way to re-key
      and still adhere to the other requirements in this section.  The
      specification SHOULD include a key identifier, which allows
      receivers to choose the correct key (or determine that they are
      not in possession of the correct key).

I don't understand how the 1st and 2nd relate.  The first sentence says use one key, and then it says implement a key identifier so I can pick from the two keys?  Aren't we really just asking for re-keying in session - not necessarily under the same key. That is:

8.  Re-keying SHOULD be supported in such a way that it can occur
      during a session. ....

[Ballot comment]
Updated based on -06:

1)  s2.3: Step 4: Still having issues with the following but I think you're getting closer:

Measurably, we
would like to see an increase in the number of surveyed
respondents who report deploying the updated authentication and
integrity mechanisms in their networks, as well as a sharp rise
in usage for the total percentage of their network's routers.

I think you're trying to say this:

We would like to see a measurable increase in the number of surveyed
respondents who report [ISR2008] deploying ....

2) s4 #7: I think it's true that any good policy would require a key changed ... r/Keys may need to/Keys need to

3) s4 #14: Maybe: r/immediately verifiable by/immediately and independently verifiable by

4) s4 #19: I think the 1st and 3rd sentences are duplicated.  And "some benefit" is a little squishy:

19.  Every new KARP-developed security mechanisms MUST support
        incremental deployment. 

        Proposed solutions MUST
        support an incremental deployment method that provides some
        benefit for those who participate.

[Ballot comment]

- 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

[Ballot comment]

  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

[Ballot discuss]
Thanks to the authors for getting the draft this far.  First off a big mea cupla for following KARP and not getting to this earlier.

Steve Kent's secdir review pointed out many issues with this draft.  Many of those are in the comments section and some are here.  I guess I'm willing to be shouted down that the following things turned up during the secdir aren't blocking, but I think we might be doing a disservice to others if we don't fix these because I find the draft hard to follow and some of the requirements are vague.

1) s1.1: The KDF definition lists four sources from which to generate keys.  Two seem to be the same, (i) a random or pseudorandom seed value and (iii) a non-uniform random source, I'd like to understand how they differ.

2) s1.1: The KMP definition indicates that the KMP determines how secret keys are generated - this isn't always true.  Are you presupposing a solution?  Here's some suggested text:

OLD:

It determines how secret keys are generated and made
  available to both the parties. 

NEW:

It determines how secret keys are made available to both
parties and in some cases also determines how the secret
keys are generated. 

3) s1.1: PRF vs KDF: The definitions look to be pretty similar.  It'd be worth saying how they're different or whether they're the same.  Often times PRFs are used in KDFs.  Maybe Brian can help with this based on (https://datatracker.ietf.org/doc/draft-irtf-cfrg-kdf-uses/).

4) s2.3 Step 4: Is there an agreement about the common operator teams and common deployment process?  How will this help evaluations?  Who will conduct the survey?  Who's going to perform the interviews?  Is there a citation for the interviews?

5) s2.3: Step 4: Having some trouble parsing the following:

Measurably, we
would like to see an increase in the number of surveyed
respondents who report deploying the updated authentication and
integrity mechanisms in their networks, as well as a sharp rise
in usage for the total percentage of their network's routers.

Are you asking for more people to deploy and to fill out the surveys?

6) s3.1.2: Stolen Keys (s3.1.2) aren't a threat source but Terminated Employees are (s3.1.2.1).

6a) How about re-titling s3.1.2.1 to INSIDERS and moving it to s3.1.2 and moving s3.1.2 to somewhere else (not sure where yet).

6b) RFC 4593 says there's two sources: outsiders (addressed) and byzantine (addressed). Are we updating RFC 4593 by adding a new type of adversary?

7) s3.2: I thought a non-goal was "Message content validity (routing database validity)" so it's unclear why FALSIFICATION is in scope?

8) s3.2: I know 4593 uses INTERFERENCE, but how are the things that are listed under that any different than the DoS attacks (or integrity violations that an attacker would try to us in a DoS attacks) introduced here?  In s3.3 you list DoS under INTERFERENCE so maybe we should try to make the two sections be more alike and group them together somehow.

9) I know 4593 uses "noise" but how's that any different than inserting messages, replying out-dated messages, corrupting messages, changing message contents?  I can hear everybody saying it's in 4593 go away, but we don't have to continue to repeat the sins of our fathers/mothers.

10) s3.2: The brute force paragraph indicates that the key should be long enough to thwart attacks 10 or more years out.  That's a big range - is it 11 or 100 years?  The answer is going to drive the solution.

11) s3.2/3.3: FALSIFICATION is listed as in scope in 3.2 and out of scope in 3.3.  Very confusing.

12) s4 #3: Algorithm agility is about being able to transition from one alg to another not supporting two MTI algs at the same time. I think #3 needs to be reworded.

13) s4 #5: Needs more detail about inter- and intra-session replay protection.

14) s4 #7: If keys are only changed when somebody leaves it is not very periodic, confidentiality is out-of-scope, and I'm not sure what you mean by entropy (are you saying to add more entropy - i.e., bigger key). How about:

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.  Keys need to be changed
periodically, for operational confidentiality (e.g. when an
administrator who had access to the keys leaves an organization)
and for entropy purposes, and a re-keying mechanism enables the
operators to execute the change without productivity loss.

To:

  Security mechanisms MUST specify a means to effect
  intra-session re-keying without disrupting a routing
  session.  Keys need to be changed periodically, for
  authentication and integrity (e.g., when an administrator
  who had access to the keys leaves an organization).

15) s4 #7 & #8: Are #7 and #8 at odds?  Is there any other way to rekey an intra-session without sending the thing twice under two different keys?  Maybe "intra-" should be dropped?

16) s4 #8: "Efficient" rekeying - how do we measure this?  One person's efficiency is another person's IPR ;)  Maybe this just needs to be reworded:

  Re-keying SHOULD be supported in such a way that it can occur
  during a session without the peer needing to use multiple
  keys to validate a given packet.

17) s4 #12: Why not MUST consider and allow for future use of KMP?  I guess we could define one and then chuck it away but would we really do that?

18) s4 #13: Levies the following requirement:

It MUST be
obvious how the keying material was obtained, and the process
for obtaining the keying material MUST exist outside of the
Routing Protocol. 

Obvious to some is not obvious to others.  I think this needs to be restated.  Is this just about a key identifier so you can locate it in the table?

19) s4 #14: Levies a requirement of no more than 5% increase in convergence time.  It then goes on to say this time will be measured by router vendors and ISPs. Are folks not in that group going to be able to verify the data too?

20) s4 #19: In the following:

Proposed solutions MUST support an incremental
deployment method that provides some benefit for those who
participate. 

Who are those?  Is that inter- or intra-AS deployments?

21) s5: Isn't the last paragraph in the security misplaced?  Ought it be in the mainbody describing what's in and what's out?

[Ballot comment]
There's a whole lotto these and I'm willing to provide the authors with an update .nroff or .txt file.

1) abstract:

OLD:

Different routing protocols exist and each employs its own mechanism
for securing the protocol packets on the wire.

NEW:

  Different routing protocols employ different mechanisms
  for securing protocol packets on the wire. 

OLD:

... routing protocols' transport systems, including any
mechanisms built into the routing protocols themselves, which
accomplish packet authentication.

NEW:

... routing protocol transport systems. This includes any
mechanisms built into the routing protocols themselves, to authenticate
packets. 

2) s1:

OLD:

This document addresses the last item in the list above, securing the
transmission of routing protocol packets on the wire, or rather
securing the routing protocols' transport systems, including any
mechanisms built into the routing protocols themselves which
accomplish packet authentication.  This effort is referred to as
Keying and Authentication for Routing Protocols, or "KARP".  KARP is
concerned with issues and techniques for protecting the messages and
their contents between directly communicating peers.  This may
overlap with, but is strongly distinct from, protection designed to
ensure that routing information is properly authorized relative to
sources of information.  Such assurances are provided by other
mechanisms and are outside the scope of this document and work that
relies on it.

NEW:

This document addresses the last item in the list above, securing
the transmission of routing protocol packets on the wire. More
precisely, it focuses on securing the transport systems employed by
routing protocols, including any mechanisms built into the protocols
themselves to authenticate packets.  This effort is referred to as
Keying and Authentication for Routing Protocols, or "KARP".  KARP is
concerned with issues and techniques for protecting the messages and
their contents between directly communicating peers.  This may
overlap with, but is strongly distinct from, protection designed to
ensure that routing information is properly authorized relative to
the source of the information.  Such assurances are provided by other
mechanisms and are outside the scope of this document.

In this text is the "their content" trying to distinguish between contents and headers but it's ambiguous.

OLD:

and to provide a set of requirements for KARP design teams to
follow as they tackle [RFC6518], Section 4.1's "Work Phase 1", the
update to a routing protocol's existing transport security.

NEW:

and to provide a set of requirements for KARP design teams to
follow as they update a routing protocol's existing transport
security (see [RFC6518], Section 4.1's "Work Phase 1’).

OLD:

Section 3 lists the
threats from [RFC4593], Generic Threats To Routing Protocols, that
are in scope for routing protocols' transport systems' per packet
authentication.

NEW:

Section 3 lists the
threats from [RFC4593] (Generic Threats To Routing Protocols) that
are in scope for per-packet authentication for routing protocol
transport systems.

OLD:

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

NEW:

Individual
protocol analysis documents will need to be more specific in their
use of this phrase.

3) s1.1:

Probably worth adding some text about the terms later defined in s3.1.

Identity Authentication: The point here is that you get an authenticated identity after it's been verified.

OLD:

Once the identity is determined

NEW:

Once the identity is verified

OLD:

or an assymetric key containted in a certificate

NEW:

or an asymmetric key contained in a certificate.

OLD:

The use of these different identity authentication

NEW:

The use of these different identity verification

For the next one it's not clear what's meant by "ongoing effort".  I'd just delete it because I think that supposed to be management.

OLD:

  ongoing effort and management

NEW:

  management

OLD:

For example, they differ in resistance
to a security breach, and the effort required to remediate the
whole system in the event of such a breach. 

NEW:

For example, they differ in resistance
to a security breach, and the effort required to recover
in the event of such a breach. 

KDF: The or derive part isn't really needed.

OLD:

A KDF is a function in which an input key and other input data is
used to generate (or derive) keying material that can be employed
by cryptographic algorithms.

NEW:

A KDF is a function in which an input key and other input data is
used to generate keying material for use with
cryptographic algorithms. 

NEW:

and r/a truly random/a random

KMP:

r/(or a group)/(or among a group)


The last paragraph isn't really need it's is copied from the RFC 6518.

KMP Function:

r/Any actual/Any

Peer Key

r/authentication mechanism used ina/uthentication mechanism are used in
r/a KMP that would/a KMP and would

PRF:

r/PRF/Pseudorandom Function (PRF)
r/efficiently-computable functions, which emulate
  /efficiently-computable functions that emulate

Routing Protocol: Since this is about the last item in the intro we should stick with that terminology:

r/to provide or enhance its peer authentication mechanisms
  /to its packets on the wire

SA:

OLD:

  Examples of items that may
  exist in an SA include: Identifier, PSK, Traffic Key,
  cryptographic algorithms, key lifetimes.

NEW:

  Examples of attributes that may be associated with an SA include:
  Identifier, PSK, Traffic Key, cryptographic algorithms, key lifetimes.

Traffic Key:

OLD:

protecting the routing protocol traffic.  Since the traffic keys
used in a particular connection are not a fixed part of a device
configuration no data exists anywhere else in the operator's
systems which can be stolen, e.g. in the case of a terminated or
turned employee.  If a server or other data store is stolen or
compromised, the thieves gain no access to current traffic keys.

NEW:

protecting routing protocol traffic. A traffic key should not be
a fixed value in a device configuration. A traffic key should be
known only to the participants in a connection, so that a
compromise of stored , e.g. in the case of a terminated or
turned employee, does not result in disclosure of traffic keys.
If a server or other data store is stolen or compromised,
the attackers gain no access to current traffic keys.

4) s2.1:

Lines up with the three services listed earlier:
r/privacy service/confidentiality

r/have existing/incorporate

r/and both have/and have (there's four protocols listed earlier assume you mean all four)

r/use of existing/use of existing (exist is used later so remove this one or the later one)

(I think you're trying to say with the Routing Protocol)
r/with the bits-on-the-wire mechanisms
  /Routing Protocol

5) s2.2:

r/The work/This document
r/The roadmap for any one routing protocol/The roadmap for any routing protocol
r/The performance impact of any incremental step of security improvement
  /The performance impact of any incremental security improvement
r/However,in the spirit of incremental deployment, we first
  /However, in the spirit of incremental deployment, the IETF first

6) s2.3:
r/the wire of existing/the wire for existing
r/in the earlier sections/in Section 2.2.

OLD:

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.

NEW:

Ensure that the improved security solutions is deployable on the
current routing infrastructure.  The current state of processing
power available on routers will need to be investigated.

Get rid of "we"
r/to ensure that what we specify can
  /to ensure that what solutions can be specified

r/Protoco/Protocol
r/The survey/The survey [ISR2008]

Get rid of our - I've heard this too :)
r/From our personal conversations with operators, of those using MD5,
  /Anecdotal evidence from operators using MD% shows

r/as cumbersome/as cumbersome to manage securely
r/threat at play here/threat here

r/security and threat protection/security

6) s2.4:

r/privacy/confidentiality
r/efforts, like SIDE/working groups (e.g., SIDR).

7) s2.5:

r/with updates to the Routing/with updating Routing
r/with close/in close
r/are delegated/are tasked

OLD:

... , presumably due to a perception of significantly
improved security value coupled with relative similarity to
deployment complexity and cost.  Conversely, the work will be
considered a failure if the operators do not care to deploy it,
either due to lack of value or perceived (or real) over-
complexity of operations.

NEW:

... . It is anticipated that deployment will take place
only if operators perceive that the improved security offered
by the Routing Protocol updates warrant the complexity and cost
of deployment and opertation.  Conversely, the work will be
considered a failure if operators do not deploy it,
either due to lack of perceived value or due to perceived
operational complexity.

8) s3:

r/"threat" defined in/"threat" from
r/and simply listing/and listing

OLD:

As such, the below text intentionally does not constitute
a self-standing, complete threat analysis, but rather describes the
applicability of the existing threat analysis [RFC4593]relevant to
KARP.

NEW:

As such, the following text intentionally is not a comprehensive
threat analysis. Rather it describes the
applicability of the existing threat analysis [RFC4593] to
KARP.

9) s3.1.

The BYZANTINE sources should be listed here to align with [RFC4593].  Then you can say they're out of scope in s3.3.

10) s3.1.1:

r/sources/attackers
r/path of packets between the two routing/path between two routing
r/attacker actually/attacker
r/attacker only/attacker
r/treat/reject
r/may often eventually/may

An MitM can also spoof packets.  So maybe:

11) s3.1.2 (assuming it'll get moved someplace):

r/router A to router B/router A, destined for router B
r/having/one has
r/The stolen keys,/The stolen keys
r/keying material will become necessary with little or
  no advanced warning
  /keying material will need to be put in place with little
  or no advanced warning
r/short, or make nonexistent,/short
r/the source with stoke keys attack by creating
  /this type of attack by
r/habitually/regularly (frequently)

12) s3.1.2.1:

To avoid any confusion just use the definition from 4593
r/On the other hand, they aren't really a BYZANTINE
  attacker, which is defined to be an attack from an INSIDER, a
  legitimate router
  /One the other hand, they aren't really a BYZANTINE attacker which
  is defined in [RFC4593] as: faulty, misconfigured, or subverted
  routers; i.e., legitimate participants in the routing protocol.
r/to be legitimate participants/to be a legitimate participant
r/"insider"/INSIDER

13) s3.2:

Title and first sentence don't match.  assume r/ATTACK/THREAT.  Lines up nicely with 4593.

SPOOFING: I hate to copy text, but it might really help to copy this bit from 4593 about spoofing as a  second sentence:

Spoofing is special in that it can be used to carry out
other threat actions causing other threat consequences.

I tend to agree with Steve, if this is an example of Spoofing then I'm not sure why it's not indented below SPOOFING.

It would make more sense to have one DoS bullet and say that DoS involving the routing protocol is in scope (opposite of what's in the out-of-scope section), generally describe DoS, and then give two examples.  There might be a bunch of others that we think of later.

14) s3.3:
r/(Section 2.1)/(Section 3.2)
r/SNIFFING/SNIFFING (passive wiretapping) - you mentioned active wiretapping earlier so it only makes sense to add it here.
r/privacy/confidentiality

15) s4:

r/how each of the below requirements are met
  /how each of the following requirements are met

Please do a review of the 2119-language to make sure that all the MUSTs/SHOULDs are capitalized.  Also sometimes the "p" isn't capitalized in Router protocols when maybe it should.

#1: r/by the authentication mechanism/by an authentication/integrity mechanism

#5: r/The ability … IP address.
    /The ability to run a MAC operation with K is used
      for (group-level) authentication  and message integrity, and
      (currently) no other authentication check is performed.

#6: r/REQUIRES, and even forces,/MUST trigger

#9: r/must/MUST
    r/filter/reject

#10:
r/for a routing protocol/for each routing protocol security mechanism
r/at or below/at
Not sure you need the explanation to understand the requirement - just delete that bit.


#11: r/For backward compatibility reasons/For backward compatibility reasons,

#12: r/Architecture of the/The

#13: r/the Routing/a Routing
    r/This will allow for the various key
        generation methods, like manual keys and KMPs, to be used with
        the same Routing Protocol mechanism.
      /This will accommodate both manual keying and use of KMPs and use of KMPs./

#14: I don't think the alternate way of stating the requirement adds anything - it's really squishy: minimal increase.  I'd drop it.
  Also, does this contradict the earlier measurement criteria, which WILL be affected by specific implementations. Which criteria do you really want to employ?

#15: r/advertisments/advertisements

#17: r/Routing protocols MUST only send minimal information regarding
      the authentication mechanisms and the parameters in its protocol
      packets.  One reason for this is to keep the Routing Protocols
        as clean and focused as possible, and load security negotiations
        into the future KMP as much as possible.
      /The Routing Protocol MUST send minimal information regarding the
      the authentication mechanisms and associated parameters in its protocol
      packets.  This keeps the Routing Protocols
        as clean and focused as possible, and loads security negotiations
        into the KMP as much as possible.

#18: r/seperate/separate
    r/that are based on this requirement/that motivate this requirement

#19:  The 2nd and 3rd sentences are redundant.  Delete the 3rd.

#19:
B: r/compatibility in the message/compatibility with respect to message
B: r/mixed security/secure and non-secure
C: r/systems/routers

#20: r/to destabilize routers/to degrade router perform

#22:
r/for the routing system to function/for the routing system to be secure
r/information/security association?  (If by information you mean shared secret key)?
r/okay/acceptable X2

[Ballot comment]
I am pleased to support the publication of this document.

Requirement 20 in Section 4 seems to be the only one without an RFC 2119
word.

Think this should be:

        Thus proposed solutions SHOULD be evaluated carefully with

[Ballot comment]
- 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".

[Ballot comment]
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.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports) to Informational RFC


The IESG has received a request from the Keying and Authentication for
Routing Protocols WG (karp) to consider the following document:
- 'The Threat Analysis and Requirements for Cryptographic Authentication
  of Routing Protocols' Transports'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-08-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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 has two main parts - the first describes the threat
  analysis for attacks against routing protocols' transports and the
  second enumerates the requirements for addressing the described
  threats.  This document, along with the KARP design guide will be
  used by KARP design teams for specific protocol review and overhaul.
  This document reflects the input of both the IETF's Security Area and
  Routing Area in order to form a jointly agreed upon guidance.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/


No IPR declarations have been submitted directly on this I-D.

(1.a) Brian Weis, co-chair of the KARP working group, is the document shepherd for this document. He has personally reviewed the most current version of this document, and believes it is ready for forwarding to the IESG for publication.

(1.b) The document has had sufficient review both inside and outside of the WG.

(1.c) I have no concerns that specific areas were under-reviewed. There were sufficient routing and security reviews of the document.

(1.d) I do not have any concerns or issues with this document.

(1.e) WG consensus behind this document was strong; no public opinions were expressed that it should not be published.

(1.f) There are no known threatened appeals.

(1.g) The document passes id-nits checks & there are no other reviews required.

(1.h) References are in good shape.

(1.i) There are no IANA issues in the document, and there is a placeholder section stating that.

(1.j) There is no formal language usage in the document.

(1.k) Draft Writeup:

Technical Summary
Existing IAB work recommends the tightening of the security of the core routing infrastructure. This document provides a threat analysis for attacks against routing protocols' transports and the then enumerates the requirements for addressing the described threats. It is intended to be used by KARP design teams in their analysis of routing protocols, and will generally be useful in the analysis of routing protocols.

Working Group Summary:
The working group support publication of this document as an informational document.

Document Quality:
This informational document does not specify a protocol or other semantics that can be directly implemented, thus there are no machine implementations. However, in terms of quality it has been reviewed by a number of security experts.