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

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

[Ballot discuss]
I believe that this document needs to offer design guidance that
  support the architecture that the KARP WG has already decided.
  Below is my understanding of this direction.  The document needs
  to reflect the WG direction, which may be different than my
  understanding.  Also, the design guide ought to say what work
  needs to be done and when each of these cases ought to be
  employed.

  Since we know that manual key management must be supported,
  the KARP WG has decided to specify a crypto key table.  Manual
  key management is populating the table, but this needs to be
  accomplished using an interface that protects the keying material
  from disclosure or alteration.

  In addition, we want to specify automated key management.  A
  protocol to automatically populate the crypto key table will be used.
  Several cases need to be considered:

  1) pairwise keys -- IKEv2 and TLS already offer mechanisms that
  are directly applicable.

  2) group keys --

  2a) group keys distributed by a key center -- KeyProv offers
  mechanisms that are directly applicable, but additional attributes
  may be needed.

  2b) group keying protocols -- new protocol work is needed for this
  approach to be employed.

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

[Ballot discuss]
I believe that this document needs to offer design guidance that
  support the architecture that the KARP WG has already decided.
  Below is my understanding of this direction.  The document needs
  to reflect the WG direction, which may be different than my
  understanding.  Also, the design guide ought to say what work
  needs to be done and when each of these cases ought to be
  employed.

  Since we know that manual key management must be supported,
  the KARP WG has decided to specify a crypto key table.  Manual
  key management is populating the table, but this needs to be
  accomplished using an interface that protects the keying material
  from disclosure or alteration.

  In addition, we want to specify automated key management.  A
  protocol to automatically populate the crypto key table will be used.
  Several cases need to be considered:

  1) pairwise keys -- IKEv2 and TLS already offer mechanisms that
  are directly applicable.

  2) group keys --

  2a) group keys distributed by a key center -- KeyProv offers
  mechanisms that are directly applicable, but additional attributes
  may be needed.

  2b) group keying protocols -- new protocol work is needed for this
  approach to be employed.

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

#1) incorporated

#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) incorporated

#6) incorporated

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) incorporated

#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) incorporated

#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) incorporated 

#14) incorporated

#15) incorporated

#17) incorporated

#18) incorporated

#19) incorporated

#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 keys/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/with the send and the receive keys/with the send and the received keys ?

#24) incorporated

#25) incorporated

#26) incorporated

#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) incorporated

#29) incorporated

#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) incorporated

#33) incorporated

#34) incorporated

#35) incorporated

#36) incorporated

#37) incorporated

#38) incorporated

#39) incorporated

#40) incorporated

#41) incorporated

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

[Ballot discuss]
I removed the portions of this DISCUSS position that have been
  resolved.

  This is a long DISCUSS write-up.  That is because I find that
  this document is not providing the design guidance that I expected
  based on the title of the document.

  Please consider these four points, each of them is significant I
  believe.  Addressing them all together will, I fear, require a
  significant revision to the document.

  [Removed point 1.]

  2.  The KARP WG charter says:

    This working group is concerned with message authentication,
    packet integrity, and denial of service (DoS) protection.

  This document talks about authentication and integrity, but it
  says noting about DoS protection.
 
  [Points 3 and 4 removed.]

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

[Ballot discuss]
This is a long DISCUSS write-up.  That is because I find that
  this document is not providing the design guidance that I expected
  based on the title of the document.

  Please consider these four points, each of them is significant I
  believe.  Addressing them all together will, I fear, require a
  significant revision to the document.

  1.  The KARP WG charter says:

    A goal of the working group is to add incremental security
    to existing mechanisms rather than replacing them. Better
    deployable solutions to which vendors and operators can
    migrate is more important than getting a perfect security
    solution.
 
  This is a very important bit of design guidance.  The document does
  say that incremental deployment is needed, but I cannot find this
  important tradeoff described in this document.
 
  2.  The KARP WG charter says:

    This working group is concerned with message authentication,
    packet integrity, and denial of service (DoS) protection.

  This document talks about authentication and integrity, but it
  says noting about DoS protection.

  3.  The KARP WG charter says:

    Routing protocols use a range of transport mechanisms and
    communication relationships. There are also differences in
    details among the various protocols. The working group will
    attempt to describe the security relevant characteristics of
    routings protocols, such as the use or non-use of TCP, or the
    frequent use of group communication versus purely pairwise
    communication. Using these characteristics, the working group
    will then provide suitable common frameworks that can be applied,
    and tailored, to improve the communication security of the routing
    protocols.

  This document covers much of this material.  It talks about
  "transport mechanisms" and "communications relationships".
  It covers part of the material I would expect in a discussion of
  "security relevant characteristics of routings protocols".  It
  covers the difference in "group" and "pairwise" communications.
  It does not come up with "common frameworks".  I suggest that
  this document is a very good start at this charter deliverable.
 
  4.  Please update [I-D.ietf-saag-crypto-key-table] to point to
  the KARP WG document: draft-ietf-karp-crypto-key-table.

[Ballot discuss]
I had great difficulty getting through this document because I found it really hard to understand.  I know I should learn to let go more, but since I think this is important I decided not to.  I apologize for not spending more time with this document earlier.  I have a lengthy set of comments, but none came to the level of discuss until I got to the last section and I couldn't get "it".

#1) s7.4: Contains the following:

  The desired end goal for KARP WG is to develop a strong peer-
  to-peer KMP; an Out-of-and external Key Management protocol is
  out of scope.

s4.1 said there there were several goals for the end state of KARP.  The second goal is a KMP.  Maybe it's better to say something like:

  One of the desired end goals for KARP is to develop a KMP.  We
  further refine that goal by specifying a peer-to-peer KMP and
  declaring an out-of-band KMP out-of-scope.

After reading the bullets that follow, I'm confused.  In the bullets that follow, you're saying an out-of-band KMP is out-of-scope but the first option in the constraint is to use a out-of-band key management protocol?

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

[Ballot discuss]
I had great difficulty in getting through this document because I found it really hard to understand.  I know I should learn to let go more, but since I think this is important I decided not to.  I apologize for not spending more time with this document earlier.  I have a lengthy set of comments, but none came to the level of discuss until I got to the last section and I couldn't get "it".

#1) s7.4: Contains the following:

  The desired end goal for KARP WG is to develop a strong peer-
  to-peer KMP; an Out-of-and external Key Management protocol is
  out of scope.

s4.1 said there there were several goals for the end state of KARP.  The second goal is a KMP.  Maybe it's better to say something like:

  One of the desired end goals for KARP is to develop a KMP.  We
  further refine that goal by specifying a peer-to-peer KMP and
  declaring an out-of-band KMP out-of-scope.

After reading the bullets that follow, I'm confused.  In the bullets that follow, you're saying an out-of-band KMP is out-of-scope but the first option in the constraint is to use a out-of-band key management protocol?

[Ballot comment]
--- 04 and -05 cleared up my discuss points

---- 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?

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

[Ballot discuss]
-04 cleared up other discuss points, but this one remains:

I don't get why 3.1 talks about SHA-1 fingerprints. It seems
very unlikely that any new KMP would use SHA-1 like this.

s/SHA-1/collision resistant hash function/ or just "strong
hash" would work as a change.

[Ballot discuss]
First two points are discuss-discuss things:

(1) cleared

(2) cleared

(3) cleared

(4) I don't get why 3.1 talks about SHA-1 fingerprints. It seems
very unlikely that any new KMP would use SHA-1 like this.

(5) cleared

(6) cleared

(7) cleared

(8) Section 7.4 seems to say that if a PSK is stolen, that that
doesn't expose the traffic key presumably derived from the PSK via a
standard, openly defined KMP. That just seems wrong. The text in
question is: "They may gain access to key derivation material, like a
PSK, but not current traffic keys in use."

[Ballot discuss]
First two points are discuss-discuss things:

(1) cleared

(2) cleared

(3) Section 2 calls out "several" categories (though only two are
identified?) and says that the hope is to have one design team per
category, and "down the road," one KMP per category. I don't
understand what's being presented here, e.g. how many KMPs are
envisaged - just two (mapping to sections 2.1 and 2.2) or something
else?

(4) I don't get why 3.1 talks about SHA-1 fingerprints. It seems
very unlikely that any new KMP would use SHA-1 like this.

(5) Are you really saying that keys MUST (in 2119 terms) be changed
"when an operator leaves" (section 3.2)? That seems plain wrong.

(6) cleared

(7) Section 6 says "while defining the new...mechanisms." Why
are you ruling re-use of existing mechanisms out of scope?

(8) Section 7.4 seems to say that if a PSK is stolen, that that
doesn't expose the traffic key presumably derived from the PSK via a
standard, openly defined KMP. That just seems wrong. The text in
question is: "They may gain access to key derivation material, like a
PSK, but not current traffic keys in use."

[Ballot comment]
Thank you for your work on this important document. I am balloting
"Yes", but I have a small raft of comments that you should look
through.

---

There is no need to include a reference to RFC 3036. That has been
obsoleted and is no more.

---

Section 1

      o  More secure mechanisms and practices for operating routers.
        This work is being addressed in the OPSEC Working Group.

Increased security or increased number? Please clarify.

---

Section 2

      and have design
      teams focus on the specification work within those groupings.

I think you can leave out this piece of IETF process that may or may
not be executed as it is not really relevant to the discussion of how
the protocols are split up on the road map or in this document.

Similarly

OLD
      so that the work can be easily leveraged by the
      various Routing Protocol teams.
NEW
      so that the work can be easily leveraged by for
      use in the various Routing Protocol groupings.

---

Section 2

      It is believed that the groupings will have like requirements
      for their authentication mechanisms, and that reuse of
      authentication mechanisms will be greatest within these
      grouping.

Yeah I know what you mean :-)

How about:

      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 deisrable within each group.

---

Section 2.1

s/some mechanism for some protocols/some mechanisms for some protocols/

---

Section 2.1

      The first categorization defines four types of messaging
      transactions used on the wire by the base Routing Protocol. 

You go on to list only three mechanisms under sub-headings. It is
possible that you intend "Mixed" to be the fourth type.

---

Section 2.2

OLD
The second axis of categorization groups protocols by the
NEW
The second axis of categorization groups protocols is by the

---

Section 2.2

      Peer keying 
     
      One router sends the keying messages directly and only to one
      other router, such that a one-to-one, unique keying security
      association (SA) is established between the two routers. This
      would be employed by protocols like BGP, BFD, LDP, etc.

How "direct" does the sending have to be? For example, can't it be
via a trusted proxy or key server? I am not sure that "directly" is
relevant to the distinction that needs to be drawn between "peer
keying" and "group keying".

(And, for what it is worth, "directly" means in time, and "direct"
means in space - except in some US usage where meaning has become
confusnicatified.)

---

Section 2.2 Peer keying

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

The "etc." is very ambiguous in this case because the last time
protocols were mentioned in groupings they included other protocols
along with BGP, BFD, and LDP. One was RSVP-TE and we know that group
keys are potentially applicable to RSVP-TE.

Maybe just strike "etc." as it is bad style to say "such as" (which
you mean in place of "like") and "etc." in the same clause.

---

Section 3.1

      The form of the identity proof could be either raw keys, the
      more easily administrable self-signed certificate format, or a
      PKI issued certificate credential.

I think you intend there to be a choice of three options here, in
which case delete "either" to avoid confusion.

---

Section 3.2

This one is almost at the level of a Discuss...

      Additionally, key chains
      will not help if the routing transport subsystem does not
      support rolling over to the new keys without bouncing the
      adjacencies. So the first step is to fix all routing protocols
      so that they can change keys without breaking or bouncing the
      adjacencies.
                                                                 
It is not clear that the conclusion is correct. This is certainly
an option, but so are:

- changing usage such that the routing protocol uses a different
  routing transport subsystem that does not bounce the adjacency

- changing (fixing?) the preferred routing tansport subsystem
  such that it does not bounce the adjacensy

---

Section 5

Would it be OK to add PCEP [RFC5440] to the category "BGP, LDP and
MSDP" as it runs over TCP, is peer-based, and would simply pick up
TCP-AO in the same way as BGP?

---

Section 5

I find no fault with the discussion of "RSVP and RSVP-TE", but I
note that other categories in this section describe the categroy
in a brief(ish) paragraph while for RSVP we have a lecture.

This also seems to make use of RFC2119 language in earnest. Is
that right?

Does this text actually belong in one of the later, protocol-
specific documents?

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

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

[Ballot discuss]
First two points are discuss-discuss things:

(1) I'm confused by this document. It says things like "have design
teams focus on..." which is not a typical thing to put in an RFC,
are there in fact design teams formed to work on specifications or
roadmaps or what?

(2) Its unclear to me if other karp documents are really expected to
adhere to these guidelines or not. If this is not being followed, then
why bother with this document? (Or why bother now - why not keep
it as an I-D and write up later what actually happened?)

(3) Section 2 calls out "several" categories (though only two are
identified?) and says that the hope is to have one design team per
category, and "down the road," one KMP per category. I don't
understand what's being presented here, e.g. how many KMPs are
envisaged - just two (mapping to sections 2.1 and 2.2) or something
else?

(4) I don't get why 3.1 talks about SHA-1 fingerprints. It seems
very unlikely that any new KMP would use SHA-1 like this.

(5) Are you really saying that keys MUST (in 2119 terms) be changed
"when an operator leaves" (section 3.2)? That seems plain wrong.

(6) 4.1 says that "in the event of a breach" just changing the
"KMP key" will fix things. How can you know that? It depends on
the kind of breach surely? How can you know that this is less
trouble than just changing "Traffic keys" in the event of a
breach?

(7) Section 6 says "while defining the new...mechanisms." Why
are you ruling re-use of existing mechanisms out of scope?

(8) Section 7.4 seems to say that if a PSK is stolen, that that
doesn't expose the traffic key presumably derived from the PSK via a
standard, openly defined KMP. That just seems wrong. The text in
question is: "They may gain access to key derivation material, like a
PSK, but not current traffic keys in use."

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

[Ballot discuss]
(1) I'm confused by this document. It says things like "have design
teams focus on..." which is not a typical thing to put in an RFC,
are there in fact design teams formed to work on specifications or
roadmaps or what?

(2) Its unclear to me if other karp documents are really expected to
adhere to these guidelines or not. If they are, the write-up's
statement that some people are not following them seems problematic?
If this is not being followed, then why bother with this document?
(Or why bother now - why not keep it as an I-D and write up later
what actually happened?)

(3) Section 2 calls out "several" categories (though only two are
identified?) and says that the hope is to have one design team per
category, and "down the road," one KMP per category. I don't
understand what's being presented here, e.g. how many KMPs are
envisaged - just two (mapping to sections 2.1 and 2.2) or something
else?

(4) I don't get why 3.1 talks about SHA-1 fingerprints. It seems
very unlikely that any new KMP would use SHA-1 like this.

(5) Are you really saying that keys MUST (in 2119 terms) be changed
"when an operator leaves" (section 3.2)? That seems plain wrong.

(6) 4.1 says that "in the event of a breach" just changing the
"KMP key" will fix things. How can you know that? It depends on
the kind of breach surely? How can you know that this is less
trouble than just changing "Traffic keys" in the event of a
breach?

(7) Section 6 says "while defining the new...mechanisms." Why
are you ruling re-use of existing mechanisms out of scope?

(8) Section 7.4 seems to say that if a PSK is stolen, that that
doesn't expose the traffic key presumably derived from the PSK via a
standard, openly defined KMP. That just seems wrong. The text in
question is: "They may gain access to key derivation material, like a
PSK, but not current traffic keys in use."

[Ballot comment]
Various paragraphs mention "modern, strong security algorithms", but those 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 here.

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:  (Keying and Authentication for Routing Protocols (KARP) Design Guidelines) to Informational RFC


The IESG has received a request from the Keying and Authentication for
Routing Protocols WG (karp) to consider the following document:
- 'Keying and Authentication for Routing Protocols (KARP)  Design
  Guidelines'
  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-06-30. 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


In the March of 2006 the IAB held a workshop on the topic of
      "Unwanted Internet Traffic".  The report from that workshop is
      documented in RFC 4948 [RFC4948]. Section 8.2 of RFC 4948 calls
      for [t]ightening the security of the core routing
      infrastructure."  Four main steps were identified for improving
      the security of the routing infrastructure.  One of those steps
      was "securing the routing protocols' packets on the wire."  One
      mechanism for securing routing protocol packets on the wire is
      the use of per-packet cryptographic message authentication,
      providing both peer authentication and message integrity.  Many
      different routing protocols exist and they employ a range of
      different transport subsystems.  Therefore there must
      necessarily be various methods defined for applying
      cryptographic authentication to these varying protocols.  Many
      routing protocols already have some method for accomplishing
      cryptographic message authentication.  However, in many cases
      the existing methods are dated, vulnerable to attack, and/or
      employ cryptographic algorithms that have been deprecated. 
      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.  In particular, it defines
      the framework for a key management protocol that may be used to
      create and manage session keys for message authentication and
      integrity.  The overall roadmap reflects the input of both the
      security area and routing area in order to form a jointly
      agreed upon and prioritized work list for the effort.



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

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


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

1.a: Joel Halpern, 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. More reviews would have been appreciated, but I (and my
co-chair) believe that sufficient review did occur.)

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. During
review, it was noted that the process used may evolve past what is
described here. It is believed that this is a good process, and a good
documented baseline for the working group to work with.

1.e: There is solid WG consensus behind this document. There may still
be a small number of security experts who are uncomfortable with the
basic approach, the document approach matches the agreement document in
the charter, and re-confirmed recently on the WG email list.

1.f: There are no known threatened appeals or indications of extreme
unhappiness.

1.g: The document passes id-nits checks. There is a warning about page
length, which will presumably resolved in final editing.

1.h: The document properly splits its references. There are no blocking
references.

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

1.j: There is no formal lanuage 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 defines a roadmap of
protocol specification work for the use of modern cryptographic
mechanisms and algorithms for message authentication in routing
protocol. It also defines a path towards the use of key management
protocols in conjunction with routing protocol authentication mechanisms.

Working Group Summary:
The working group support publication of this document as an
informational document. If there is significant evolution in practice
based on experience with this, a revision may be published if that is
deemed useful for future reference.

Document Quality:
As a guideline document for future work, there is not a machine
implementation. It is to be noted that some folks have been bypassing
the procedures in this document. It is hoped that Tf approval of the
document will provide support for better inter-working-group cooperation
to make this process work well for all concerned.