Subject: Re: [karp] [IAB] Fwd: Attached: draft-lebovitz-kmart-roadmap-01-00.txt

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Wed, 04 Nov 2009 00:08:09 -0800

Danny,
the lastest version of the document contains changes based on your 
feedback. Thanks a ton for the thorough review. See comments below...

At 02:14 PM 3/18/2009, Danny McPherson wrote:
>Comments inline..
>
>-
>Seems this document is a framework, requirements, and
>in part, solutions draft, and this tends to muddy the
>objectives considerably.

Agree. It's a catch-all at present. I put in a paragraph in the intro 
stating as much, and suggesting how it might be broken up into 
smaller, more focused docs. We will break it up into more focused 
docs once the BoF is over, and the WG starts. Ideally we would have 
done it before, but I just didn't have the cycles.

>-
>I agree with Ward about per AF and even AF/SAF password
>pairs, as folks setup discrete sessions based on these
>today, and his other comments as well.
>
>-danny
>
>
>On Mar 11, 2009, at 1:19 AM, Gregory Lebovitz wrote:
>>
>>Internet-Draft
>>Juniper
>>Intended status: Informational                            March 10,
>>2009
>>Expires: September 11, 2009
>>
>>Roadmap for Cryptographic Authentication of Routing Protocol Packets
>>on
>>                                 the Wire
>>                     draft-lebovitz-kmart-roadmap-01
>....
>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>1.  Introduction
>>    In March 2006 the Internet Architecture Board (IAB) held a workshop
>>    on the topic of "Unwanted Internet Traffic".  The report from that
>>    workshop is documented in RFC 4948 [RFC4948].  Section 8.1 of that
>>    document states that "A simple risk analysis would suggest that an
>>    ideal attack target of minimal cost but maximal disruption is the
>>    core routing infrastructure."  Section 8.2 calls for "[t]ightening
>>    the security of the core routing infrastructure."  Four main steps
>>    were identified for that tightening:
>>    o  More secure mechanisms and practices for operating routers.
>>This
>>       work is being addressed in the OpSec Working Group.
>
>I believe it's 'OPSEC' from a capitalization perspective.

done.

>>    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 is being conducted through
>>       liaisons with the RIR's globally.
>
>The RIRs don't own most of the IRRs, and this is a bit confusing
>in this context.  I'm not sure this work is really happening,
>actually.

done.

>>    o  Specifications for cryptographic validation of routing message
>>       content.  This work is being done in the SIDR Working Group.
>
>Actually, the only thing SIDR has really done to date is define
>the repository structure for the RPKI.  They have not done anything
>with actual use of this information in the operational routing
>system itself.

made it a future reference, "this work will likely be done in the SIDR WG"

>>    o  Securing the routing protocols' packets on the wire
>>    This document addresses the last bullet, securing the packets on
>>the
>>    wire of the routing protocol exchanges.
>
>It might be nice if you define in the introduction where the
>term 'KMART' came from.

Done. Now called KARP.

>>1.1.  Terminology
>>    [to be filled out later]
>>    Base RP
>>    key_store
>>    KMP
>>    session keys

This whole sesssion filled in now.

>>1.2.  Requirements Language
>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>>this
>>    document are to be interpreted as described in RFC 2119 [RFC2119].
>>1.3.  Scope
>>    Four basic tactics may be employed in order to secure any piece of
>>    data as it is transmitted over the wire: privacy (or encryption),
>>    authentication, message integrity, and non-repudiation.  The focus
>>    for this effort, and the scope for this roadmap document, will be
>>
>>Lebovitz &             Expires September 11, 2009
>>[Page 4]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>    message authentication and packet integrity only.  This work
>>    explicitly excludes, at this point in time, the other two tactics:
>>    privacy and non-repudiation.  Since the objective of most routing
>>    protocols is to broadly advertise the routing topology, routing
>>    messages are commonly sent in the clear; confidentiality is not
>>    normally required for routing protocols.  However, ensuring that
>>    routing peers truly are the trusted peers expected, and that no
>>roque
>>    peers or messages can compromise the stability of the routing
>>    environment is critical, and thus our focus.  The other two
>>    explicitly excluded tactics, privacy and non-repudiation, may be
>>    addressed in future work.
>>    It is possible for routing protocol packets to be transmitted
>>    employing all four security tactics mentioned above using existing
>>    standards.  For example, one could run unicast, layer 3 or above
>>    routing protocol packets through IPsec ESP [RFC4303].  This would
>>    provide the added benefit of privacy, and non-repudiation.
>>However,
>>    routing products have been fine tuned over the years for the
>>specific
>
>"routing products" reads a bit odd.  Either say "routers" or
>"routing protocols".

I used "router platforms and systems"

>>    processing necessary for these routing protocols non-encapsulated
>>    formats.
>
>That last bit reads a bit odd, or is perhaps overly redundant
>given the earlier part of the text.

cleaned it a bit.

>>Operators are, therefore, quite unwilling to explore new
>
>s/unwilling/reluctant/

done.

>>    packet encapsulations for these tried and true protocols.
>>    In addition, at least in the case of BGP and LDP, these protocols
>>    already have existing mechanisms for cryptographically
>>authenticating
>>    and integrity checking the packets on the wire.  Products with
>>these
>>    mechanisms have already been produced, code has already been
>>written
>>    and both have been optimized for the existing mechanisms.  Rather
>>    than turn away from these mechanisms, we want to enhance them,
>>    updating them to modern and secure levels.
>
>What's a "modern and secure level"?
>
>>    There are two main work phases for this roadmap, and for any BaseRP
>
>What's "BaseRP"?  You use both it and "Base RP" throughout.  Also,
>RP, as you're likely aware, is commonly used to compress 'Relying
>Party" in PKI realms, so it might be confused when used in this
>context -- unless explicitly pre-defined.

I've replaced "RP" and "BaseRP" with Routing Protocol throughout the 
document, and I defined the capitalized  version in the terminology 
section to mean "Routing Protocol for which work is being done to 
provide or enhance its peer authentication mechanisms."

>>    work undertaken as part of this roadmap (discussed further in the
>>    Work Phases (Section 4.1) section).  The first is to enhance the
>>Base
>>    RP's current authentication mechanism, ensuring it employs modern
>
>So "RP" is "routing protocol"?  You might want to define that
>above, as I've not seen that employed in other places within the
>IETF as such.
>
>>    cryptographic algorithms and methods for its basic operational
>>model,
>>    fulfillling the requirements defined in the Requirements
>
>s/fulfillling/fulfilling/

done.

>>    (Section 4.2) section, and protecting against as many of the
>>threats
>>    as possible as defined in the Threats (Section 2.1)section.  Many
>>of
>
>s/Section 2.1)section/Section 2.1( section/

done.

>>    the BaseRPs' current mechanisms use manual keys, so the first phase
>>    updates will focus on shoring up the manual key mechanisms that
>>    exist.
>>    The second work phase is to define the use of a key management
>>    protocol (KMP) for creating and managing session keys used in the
>>    BaseRPs' message authentication and data integrity functions.  It
>>is
>>    hoped that a general KMP framework -- or a small number of
>>frameworks

>s/hoped/intended/

done

>You also need to expand KMP and all the other acronyms
>upon first use here.

done in the terminology section, which is now filled out in the most 
recent version.

>>    -- can be defined and leveraged for many BaseRPs.
>>
>>
>>Lebovitz &             Expires September 11, 2009
>>[Page 5]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>    Therefore, the scope of this roadmap of work includes:
>>    o  Making use of existing routing protocol security protocols,
>>where
>>       they exist, and enhancing or updating them as necessary for
>>modern
>>       cryptographic best practices,
>>    o  Developing a framework for using automatic key management in
>>order
>>       to ease deployment, lower cost of operation, and allow for rapid
>>       responses to security breaches, and
>
>>    o  Specifying the automated key management protocol that may be
>>       combined with the bits-on-the-wire mechanisms.
>>    The work also serves as an agreement between the Routing Area and
>>the
>>    Security Area about the priorities and work plan for incrementally
>>    delivering the above work.  This point is important.  There will be
>>    times when the best-security-possible will give way to vastly-
>>    improved-over-current-security-but-admittedly-not-yet-best- security-
>>    possible, in order that incremental progress toward a more secure
>>    Internet may be achieved.  As such, this document will call out
>>    places where agreement has been reached on such trade offs.
>
>
>>    This document does not contain protocol specifications.  Instead,
>>it
>>    defines the areas where protocol specification work is needed and
>>    sets a direction, a set of requirements, and a relative priority
>>for
>>    addressing that specification work.
>>    There are a set of threats to routing protocols that are considered
>>    in-scope for this document/roadmap, and a set considered out-of-
>>    scope.  These are described in detail in the Threats (Section 2)
>>    section below.
>>1.4.  Goals
>>    The goals and general guidance for this work roadmap follow:
>>    1. Provide authentication and integrity protection for packets on
>>the
>>       wire of existing routing protocols
>>    2. Deliver a path to incrementally improve security of the routing
>>       infrastructure.  The principle of crawl, walk, run will be in
>>       place.  Routing protocol authentication mechanisms may not go
>>       immediately from their current state to a state containing the
>>       best possible, most modern security practices.  Incremental
>>steps
>>       will need to be taken for a few very practical reasons.  First,
>>       there is a great deal of deployed routing devices in operating
>
>s/is a great deal of/are a considerable number of/

done.

>>       networks that will not be able to run the most modern
>>       cryptographic mechanisms without significant and unacceptable
>>
>>Lebovitz &             Expires September 11, 2009
>>[Page 6]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>       performance penalties.  The roadmap for any one routing protocol
>>       MUST allow for incremental improvements on existing operational
>>       devices.  Second, current routing protocol performance on
>>deployed
>>       devices has been achieved over the last 20 years through
>>extensive
>>       tuning of software and hardware elements, and is a constant
>>focus
>>       for improvement by vendors and operators alike.  The
>>introduction
>>       of new security mechanisms affects this performance balance.
>>The
>>       performance impact of any incremental step of security
>>improvement
>>       will need to be weighed by the community, and introduced in
>>such a
>>       way that allows the vendor and operator community a path to
>>       adoption that upholds reasonable performance metrics.
>>Therefore,
>>       certain specification elements may be introduced carrying the
>>       "SHOULD" guidance, with the intention that the same mechanism
>>will
>>       carry a "MUST" in the next release of the specification.  This
>>       gives the vendors and implementors the guidance they need to
>>tune
>>       their software and hardware appropriately over time.  Last, some
>>       security mechanisms require the build out of other operational
>>       support systems, and this will take time.  An example where
>>these
>>       three reasons are at play in an incremental improvement
>>roadmap is
>>       seen in the improvement of BGP's [RFC4271] security via the
>>update
>>       of the TCP Authentication Option (TCP-AO)
>>       [I-D.ietf-tcpm-tcp-auth-opt] effort.  It would be ideal, and
>>       reflect best common security practice, to have a fully specified
>>       key management protocol for negotiating TCP-AO's authentication
>>       material, using certificates for peer authentication in the
>>       keying.  However, in the spirit of incremental deployment, we
>>will
>>       first address issues like cryptographic algorithm agility,
>>replay
>>       attacks, TCP session resetting in the base TCP-AO protocol
>>before
>>       we layer key management on top of it.
>
>
>>    3. The deploy-ability of the improved security solutions on
>>currently
>>       running routing infrastructure equipment.  This begs the
>>       consideration of the current state of processing power available
>>       on routers in the network today.
>
>While this is certainly a consideration, I'm not sure why it's
>outlined in the Goals so explicitly, or even captured in the
>#2 bullet point as well.

so, what's your suggestion for how to change the text?

>>    4. Operational deploy-ability - A solutions acceptability will also
>>       be measured by how deployable the solution is by common operator
>>       teams using common deployment processes and infrastructures.
>>I.e.
>>       We will try to make these solutions fit as well as possible into
>>       current operational practices or router deployment.  This will
>>be
>>       heavily influenced by operator input, to ensure that what we
>>       specify can -- and, more importantly, will -- be deployed once
>>       specified and implemented by vendors.  Deployment of
>>incrementally
>>       more secure routing infrastructure in the Internet is the final
>>       measure of success.
>
>What's the actual Goal here and how do we measure and
>manage to deliver on that goal?

How about this text:
  "Measurably, we would like to see an increase in the number of 
surveyed respondents who report deploying the improved security 
mechanisms across their routers, both in any usage within the 
network, as well as the total number of routers enabled with the 
updated authentication mechanisms."

>>Lebovitz &             Expires September 11, 2009
>>[Page 7]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>       Interviews with operators show several points about routing
>>       security.  First, only about 25% of operators have deployed
>>       security in their routing protocols [REF???, Danny, you got
>>one?].
>
>It's slightly better than that, but not much, depending on
>whether or not what you call security is strictly transport
>connection protection, or something more.  If you're referring
>to IRR and prefix filtering functions, it's much worse.  Both
>vary considerably inter-domain v. intra-domain.
>
>[ISR2008] http://www.arbornetworks.com/dmdocuments/ISR2008_US.pdf,
>which you can download for the raw numbers.

Got it. Thx.

>>       Of those who have deployed, only about [25% ??] of their routers
>>       are deployed with the authentication enabled.  Most report
>>       deploying with one single manual key throughout the entire
>>       network.
>
>Most?  All that use standard TCP MD5 Signature Option stuff.

Well, for the one person that I didn't actually speak to who may have 
used a few different keys, I didn't want to be too extreme. But we 
agree, it's abismal. ;-)

>One or two still reported IPSEC for transport connection
>protection, as illustrated.

added that fact.

>>   These same operators report that the one single key has
>>       not been changed since it was originally installed, sometimes
>>five
>>       or more years ago.  When asked why, particularly for the case of
>>       BGP using TCP MD5, the following reasons are often given:
>>
>>       A.  Changing the keys brings down the links/adjacencies,
>>           undermining Service Level Agreements (SLAs).
>
>Might be useful to say "triggers TCP session reset" v.
>"brings down links".

done.

>>       B.  For external peers, difficulty of coordination with the
>>other
>>           organization.  They often don't know who the contact is at
>>the
>>           other organization, so they don't know where to start, and
>>           doing so takes a lot of time in research.
>
>Nah, that's not the issue.  They have the peering coordinators
>contact information, it's just that the coordination function
>is serialized and on a per peer/AS basis, and very cumbersome
>and tedious to execute in practice.

ok. I clarified that, and softened the "finding the contact" issue, 
which I did hear from several of the people that I interviewed.

>>       C.  Keys must be changed at precisely the same time in order to
>>           limit connectivity outage duration.  This is incredibly
>>           difficult to do, operationally, especially between different
>>           organizations.
>
>Or within some very small window (e.g., 60 seconds), which
>I believe at least the two primary vendors support.

added.

>>       D.  Relatively low priority compared to other operatoinal
>>issues.
>
>Yes!
>
>>       E.  Lack of staff to implement the changes device by device.
>>       F.  One operator reported that the same key is used for all
>>           customer premise equipment.  The same operator reported that
>>           if the customer mandated, a unique key could be created,
>>           although the last time this occurred it created such an
>>           operational headache that the administrators now usually
>>tell
>>           customers that the option doesn't even exist, to avoid the
>>           difficulties.  These customer-uniqe keys are never changed,
>>           unless the customer demands so.
>
>So you've got three areas of concern: peers and interconnection
>with other ISPs, Internal BGP and other routing sessions, and
>customer and CPE devices.  All three have very different properties.

added.

>>       The main threat at play here is that a terminated employee from
>>       such an operator who had access to the one (or few) keys used
>>for
>>       authentication in these environments could easily wage an attack
>>       -- or offer the keys to others who would wage the attack -- and
>>       bring down many of the adjacencies, causing destabilization to
>>the
>>       routing system.
>>       Whatever mechanisms we specify need to be easier than the
>>current
>>       methods to deploy, and should provide obvious operational
>>       efficiency gains along with significantly better security and
>>       threat protection.  This combination of value may be enough to
>>       drive much broader adoption.
>
>Sure..
>
>>
>>Lebovitz &             Expires September 11, 2009
>>[Page 8]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>    5. Address the threats enumerated above in the "Threats" section
>>       (Section 2) for each routing protocol, along a roadmap.  Not all
>>       threats may be able to be addressed in the first specification
>>       update for any one protocol.  Roadmaps will be defined so that
>>       both the security area and the routing area agree on how the
>>       threats will be addressed completely over time.
>
>In practice, it will be interesting to see how we gauge
>whether the IETF "Security Area" and "Routing Area" agree.
>I hope the ADs can help here with best determining how to
>accomplish such a goal.

I think we are well on the way. The KARP BoF seems to be coming along 
quite well, with good cooperation between routing and Sec. This has a 
lot to do with the personalities currently seated in the roles. I'm 
hopeful for the future as well.

>>    6. Reuse common mechanisms across routing protocols whenever
>>possible
>>       - For example, designers should aim to re-use the key management
>>       protocol that will be defined for BGP's TCP-AO key establishment
>>       for as many other routing protocols as possible.  This is but
>>one
>>       example.
>
>I think the is the crux of the KMART work, and that framework
>we define needs to be employed and common to all the relevant
>protocols here.

added.

>>    7. Bridge any gaps between routing and security engineers by
>>       recording agreements on work items, roadmaps, and guidance from
>>       the Area leads and Internet Architecture Board (IAB,
>>www.iab.org).
>
>s/engineers/areas/

done.

>Also, I'm not sure conveying that an IAB pivot function will
>service and identify all gaps, so we should exercise caution
>here.

Don't disagree, but also clear that IAB can help. Suggested new text?

>>    8. Create a re-usable architecture and guidelines for various IETF
>>       working teams who will address these security improvements for
>>       various protocols
>
>I like this, and see it's concise overlap with item 6 above.
>Should they not be one item?

Yeah, I think so. Done.

>>1.5.  Non-Goals
>>    The following two goals are considered out-of-scope for this
>>effort:
>>    o  Privacy of the packets on the wire, at this point in time.  Once
>>       this roadmap is realized, we may revisit work on privacy.
>>    o  Message content security.  This work is being deal with in other
>>       areas, like SIDR.
>
>s/deal/dealt/

s/deal/addressed

>>1.6.  Audience
>>    The audience for this roadmap includes:
>>    o  Routing Area working group chairs and members -   These people
>>are
>
>s/members/participants/

done.

>>         charged with updates to the routing protocol specifications.
>>         Any and all cryptographic authentication work on these
>>         specifications will occur in Routing Area working groups.
>
>But if there's a common model to be employed across multiple
>routing protocols, what "Routing Area working groups" and not
>THE "routing area WG"?

Not sure. I think in order to update OSPF we need the OSPF WG to 
update their specs, no?

>>    o  Security Area reviewers of routing area documents -   These
>>people
>>         are delegated by the Security Area Directors to perform
>>reviews
>>         on routing protocol specifications as they pass through
>>working
>>         group last call or IESG review.  They will pay particular
>>         attention to the use of cryptographic authentication and
>>         corresponding security mechanisms for the routing protocols.
>>         They will ensure that incremental security improvements are
>>
>>Lebovitz &             Expires September 11, 2009
>>[Page 9]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>         being made, in line with this roadmap.
>>    o  Security Area engineers -   These people partner with routing
>>area
>>         authors/designers on the security mechanisms in routing
>>protocol
>>         specifications.  Some of these security area engineers will be
>>         assigned by the Security Area Directors, while others will be
>>         interested parties.
>
>s/parties./parties in the relevant working groups./

done.

>>    o  Operators -   The operators are a key audience for this work, as
>>         the work is considered to have succeeded if the operators
>>deploy
>>         the technology, 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.
>
>And as such, the GROW and OPSEC WGs should be kept squarely
>in the loop as well.

ack. Added the text.

>>2.  Threats
>>    In RFC2828[RFC2828], a threat is defined as a potential for
>>violation
>>    of security, which exists when there is a circumstance, capability,
>>    action, or event that could breach security and cause harm.  This
>>    section defines the threats that are in scope for this roadmap, and
>>    those that are explicitly out of scope.  This document leverages
>>the
>>    "Generic Threats to Routing Protocols" model, RFC 4593 [RFC4593] ,
>>    capitalizes terms from that document, and offers a terse definition
>>    of those terms.  (More thorough description of routing protocol
>>    threats sources, motivations, consequences and actions can be found
>>    in RFC 4593 [RFC4593] itself).  The threat listings below expand
>>upon
>>    these threat definitions.
>>2.1.  Threats In Scope
>>    The threats that will be addressed in this roadmap are those from
>>    OUTSIDERS, attackers that may reside anywhere in the Internet, have
>>    the ability to send IP traffic to the router, may be able to
>>observe
>>    the router's replies, and may even control the path for a
>>legitimate
>>    peer's traffic.  These are not legitimate participants in the
>>routing
>>    protocol.  Message authentication and integrity protection
>>    specifically aims to identify messages originating from OUTSIDERS.
>>    The concept of OUTSIDERS can be further refined to include
>>attackers
>>    who are terminated employees, and those sitting on-path.
>>
>>
>>
>>Lebovitz &             Expires September 11, 2009              [Page
>>10]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>    o  On-Path - attackers with control of a network resource or a tap
>>       along the path of packets between two routers.  An on-path
>>       outsider can attempt a man-in-the-middle attack, in addition to
>>       several other attack actions.
>
>s/actions/classes/

done.

>>   A man-in-the-middle (MitM) attack
>>       occurs when an attacker who has access to packets flowing
>>between
>>       two peers tampers with those packets in such a way that both
>>peers
>>       think they are talking to each other directly, when in fact they
>>       are actually talking to the attacker only.  Protocols conforming
>>       to this roadmap will use cryptographic mechanisms to prevent a
>>       man-in-the-middle attacker from situating himself undetected.
>>    o  Terminated Employees - in this context, those who had access
>>       router configuration that included keys or keying material like
>>       pre-shared keys used in securing the routing protocol.  Using
>>this
>>       material, the attacker could attempt to impersonate a legitimate
>>       router.
>
>I don't understand the vector you're conveying here?  What
>does "impersonate" mean in this context?

added text to clarify it, as follows:
"... the attacker could send properly MAC'd spoofed packets appearing 
to come from router A to a router B, and thus impersonate a 
legitimate peer. The attacker could then send false traffic that 
changes the network from its operator's design."

>>The goal of addressing this source specifically is to
>>       call out the case where new keys or keying material becomes
>>       necessary very quickly, with little operational expense, upon
>>the
>>       termination of such an employee.  This grouping could also refer
>>       to any attacker who somehow managed to gain access to keying
>>       material, and said access had been detected by the operators
>>such
>>       that the operators have an opportunity to move to new keys in
>>       order to prevent attack.
>
>s/attack/[an|the] attack/

done.

>>    These ATTACK ACTIONS are in scope for this roadmap:
>>    o  SPOOFING - when an illegitimate device assumes the identity of a
>
>What's an "illegitimate device"?  A "legitimate one"?

A device born out of wedlock, duh!! JK.

Will change to "an unauthorized device"

>>       legitimate one.  Spoofing can be used, for example, to inject
>>       unrealistic routing information that causes the disruption of
>
>s/unrealistic/malicious/

done.

>>       network services.  Spoofing can also be used to cause a neighbor
>>       relationship to form that subsequently denies the formation of
>>the
>>       relationship with the legitimate router.
>
>Can you explain this vector to me?

Can a router configured to form an adjacency with routerA actually 
for two adjacencies with two router A's, simultanously? If an 
adjacency is formed with a spoofed/impersonated routerA, will a 
second adjacency be able to form with the real router A?

>>    o  FALSIFICATION - an action whereby an attacker sends false
>>routing
>>       information.  To falsify the routing information, an attacker
>>has
>>       to be either the originator or a forwarder of the routing
>>       information.  Falsification may occur by an ORIGINATOR, or a
>>       FORWARDER, and may involve OVERCLAIMING, MISCLAIMING, or
>>       MISTATEMENT of network resource reachability.
>
>What's the difference between "MISCLAIMING" and "MISTATEMENT"?
>Also, is the latter spelled as you intended?

Honestly, I don't recall. And I'm 10k meters in the air, w/o Internet 
connection, as I work through these edits.

 From the intro paragraph to Sect 2:
This document leverages the "Generic Threats to Routing Protocols" model, <xref
target="RFC4593"
 >RFC 4593</xref> , capitalizes terms from that document, and offers 
a terse definition of those terms. (More thorough description of 
routing protocol threats sources, motivations, consequences and 
actions can be found in <xref target="RFC4593">RFC 4593</xref> itself).

>>   We must be careful
>>       to remember that in this work we are only targeting
>>falsification
>>       from outsiders as may occur from tampering with packets in
>>flight.
>>       Falsification from BYZANTINES (see the Threats Out of Scope
>>       section (Section 2.2) below) are not addressed by this roadmap,
>>       but by other work in the IETF.
>
>REF in order here to this "other work"?

Good point. Preventing a router from becoming a BYZANTINE is the work 
of OPSEC, but I don't think I'll go into that in this paragraph.

s/this roadmap, but by other work in the IETF/the KARP effort.

>>Lebovitz &             Expires September 11, 2009              [Page
>>11]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>    o  INTERFERENCE - when an attacker inhibits the exchanges by
>>       legitimate routers.  The types of interference addressed by this
>>       work include:
>>       *  ADDING NOISE
>>       *  REPLAYING OUT-DATED PACKETS
>>       *  INSERTING MESSAGES
>>       *  CORRUPTING MESSAGES
>>       *  BREAKING SYNCHRONIZATION
>>       *  Changing message content
>>    o  DoS attacks on transport sub-systems - This includes any other
>>DoS
>>       attacks specifically based on the above attack types.  This is
>>       when an attacker sends packets aimed at halting or preventing
>>the
>>       underlying protocol over which the routing protocol runs, for
>>       example halting a BGP session by sending a TCP FIN packet.
>>       Another example is sending packets which confuse or overwhelm a
>>       security mechanism itself, for example initiating an
>>overwhelming
>>       load of keying protocol initiations from bogus sources.
>
>This example, can you explain that in the context of routing
>protocols today?

It would be the case for something like MSEC today, and for any KMP 
that we put into place.

>>   All other
>>       possible DoS attacks are out of scope (see next section).
>>2.2.  Threats Out of Scope
>>    Threats from BYZANTINE sources -- faulty, misconfigured, or
>>subverted
>>    routers, i.e., legitimate participants in the routing protocol --
>>are
>>    out of scope for this roadmap.  Any of the attacks described in the
>>    above section (Section 2.1) that may be levied by a BYZANTINE
>>source
>>    are therefore also out of scope.
>>    In addition, these other attack actions are out of scope for this
>>    work:
>>    o  SNIFFING - passive observation of route message contents in
>>flight
>>    o  FALSIFICATION by BYZANTINE sources - unauthorized message
>>content
>>       by a legitimate source.
>>    o  INTERFERENCE due to:
>>       *  NOT FORWARDING PACKETS - cannot be prevented with
>>cryptographic
>>          authentication
>>       *  DELAYING MESSAGES - cannot be prevented with cryptographic
>>          authentication
>>       *  DENIAL OF RECEIPT - cannot be prevented with cryptographic
>>          authentication
>>       *  UNAUTHORIZED MESSAGE CONTENT - the work of the IETF's SIDR
>>          working group
>>          grouphttp://www.ietf.org/html.charters/sidr-charter.html).
>
>s/grouphttp/group http/

done

>>       *  Any other type of DoS attack.  For example, a flood of
>>traffic
>>          that fills the link ahead of the router, so that the router
>>is
>>          rendered unusable and unreachable by valid packets is NOT an
>>
>>Lebovitz &             Expires September 11, 2009              [Page
>>12]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>          attack that this work will address.  Many other such examples
>>          could be contrived.
>
>It may be worth citing DS or related QoS functions to enable
>better response to these sorts of threats .. or not.

possibly DSCP could help, but then again the spoof-ing attacker 
sending junk to fill the pipe could just as easily set DSCP markings. 
So it's probably not worth going into the whole discussion at this 
spot in the paper.

>>3.  Categorizing Routing Protocols
>>    For the purpose of this security roadmap definition, we will
>>    categorize the routing protocols into groups and have design teams
>>    focus on the specification work within those groupings.  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.  The work items
>>    placed on the roadmap will be defined and assigned based on these
>>    categorizations.  It is also hoped that, down the road in the
>>Phase 2
>>    work, we can create one KMP per category (if not for several
>>    categories) so that the work can be easily leveraged by the various
>>    RP teams.  KMPs are useful for allowing simple, automated updates
>>of
>>    the traffic keys used in a base protocol.  KMPs replace the need
>>for
>>    humans, or OSS routines, to periodically replace keys on running
>>    systems.  It also removes the need for a chain of manual keys to be
>>    chosen or configured.  When configured properly, a KMP will enforce
>>    the key freshness policy of two peers by keeping track of the key
>>    lifetime and negotiating a new key at the defined interval.
>
>Sure, but the inter-domain aspects make this rosy goal considerably
>more challenging.

I don't see it. Could you clarify? Today the two domains need to 
exchange manual keys. In the case where KMP is used, they simply 
exchange a PSK, or SHA1 fingerprints of their self-signed certs (or 
whatever) and from then on the KMP takes care of traffic key 
lifetimes, renewals, etc. Did you mean something else?

>>3.1.  Category: Messaging Transaction Type
>>    The first categorization defines four types of messaging
>>transactions
>>    used on the wire by the base routing protocol, the Base RP.  They
>>    are:
>>
>>    One-to-One     One peer router directly and intentionally
>>delivers a
>>                   route update specifically to one other peer router.
>>                   Examples are BGP and LDP. [question to reviewers:
>>                   Should we list all protocols into these categories
>>                   right here, or just give a few examples?]
>
>IS-IS and OSPF have P-P modes, both on traditional PtP
>link layers, and multi-access layers.  I'm not sure this
>captures the distinction succinctly enough.

Good point. I'll site them as examples, saying:
  "Point-to-point modes of both IS-IS and OSPF, when sent over both 
traditional point-to-point links and when using multi-access layers, 
may both also fall into this category.

>>    One-to-Many    A router peers with multiple other routers on a
>>single
>>                   network segment -- i.e. on link local -- such that
>>it
>>                   creates and sends one route update message which is
>>                   intended for consumption by multiple peers.
>>Examples
>>                   would be OSPF and IS-IS.
>
>See above comment.

ack.

>>    Client-Server  A client-server routing protocol is one where one
>>                   router initiates a request for route information
>>from
>>                   another router, who then formulates a response to
>>that
>>                   request, and replies with the requested data.
>>                   Examples are a BGP Route Reflector and [????  Are
>>
>>Lebovitz &             Expires September 11, 2009              [Page
>>13]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>                   there other examples?  Is this the right example?].
>
>BGP Route Reflection is _exactly the same as BGP without
>route reflection from a transport connection and message
>process perspective.  The only differences that exist occur
>at the protocol application layer.

So, you think we (a) should not have "Client-Server" category, (b) 
should have "Client-Server" category but use another example other 
than BGP, (c) something else?

Pls provide text.

>>    Multicast      Multicast protocols have unique security properties
>>                   because of the fact that they are inherently group-
>>                   based protocols and thus have group keying
>>                   requirements at the routing level where link-local
>>                   routing messages are multicasted.  Also, at least in
>>                   the case of PIM-SM, some messages are are sent
>>unicast
>>                   to a given peer(s), as is the case with router- close-
>>                   to-sender and the "Rendezvous Point".  Some work for
>>                   application layer message security has been done in
>>                   the Multicast Security working group (MSEC,
>>                   http://www.ietf.org/html.charters/msec-charter.html)
>>                   and may be helpful to review, but is not directly
>>                   applicable.
>>    [author's note: I think the above definitions need clean up.
>>Routing
>>    area folks, especially ADs, PLEASE suggest new text.]
>
>Let's chat about this in SFO if you'd like, I agree.

Let's make some time to review these in Hiroshima. (Dang, it's taken 
a long time to processes this review.) I'll send you a separate email.

>>3.2.  Category: Peer vs. Group Keying
>>    The second axis of categorization groups protocols by the keying
>>    mechanism that will be necessary for distributing session keys to
>>the
>>    actual routing protocol transports.  They are:
>>
>>    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
>>    Group Keying   One router creates and distributes a single keying
>>                   message to multiple peers.  In this case an group SA
>>                   will be established and used between multiple peers
>>                   simultaneously.  Group keying exists for protocols
>>                   like OSPF [RFC2328] , and also for multicast
>>protocols
>>                   like PIM-SM [RFC4601].
>
>How about the case where multiple sessions exist between
>inter-domain peers and the same keys are used on every
>session during a given instant?

can you give me an example of when this happens?

>Also, customers, where it
>may or may not be the same for managed and unmanaged CPE
>devices?

Sorry, not following you here. Could you try clarifying?

>>3.3.  Security Characterization Vectors
>>    A few more considerations must be made about the protocol and its
>>use
>>    when initially categorizing the protocol and scoping the
>>    authentication work.
>>
>>
>>
>>Lebovitz &             Expires September 11, 2009              [Page
>>14]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>3.3.1.  Internal vs. External Operation
>>    The designers must consider whether the protocol is an internal
>>    routing protocol or an external one, i.e.  Does it primarily run
>>    between peers within a single domain of control or between two
>>    different domains of control?  Some protocols may be used in both
>>    cases, internally and externally, and as such various modes of
>>    authentication operation may be required for the same protocol.
>>    While it is preferred that all routing exchanges run with the
>>utmost
>>    security mechanisms enabled in all deployments, the exhortation is
>>    greater for those protocols running at a peering point between two
>>    domains of control, and greatest for those on public exchange point
>>    links, because the volume of attackers are greater from the
>>outside.
>
>You might want to use more technical language here to be
>clear.  E.g., inter-domain PtP links versus shared access
>interconnection link layers, or something to that effect.

done

>>    Note however that the consequences of internal attacks maybe no
>>less
>>    severe -- in fact they may be quite a bit more sever
>
>s/sever/severe/ - unless you indeed meant sever :-)

done

>>-- than an
>>    external attack.  An example of this internal versus external
>>    consideration is BGP which has both EBGP and IBGP modes.  Another
>>    example is a multicast protocol where the neighbors are sometimes
>>    within a domain of control and sometimes external, like at an
>>    exchange link.
>
>Are you referring to a protocol such as PIM here, or something
>more akin to MSDP?

I guess it could be either, no? Think I should say, "examples would 
be both PIM and MSDP."?

>>   It would be more acceptable to give up some security
>>    to get some convenience by using a group key on large broadcast
>>    networks
>
>I think you're mixing layers here and it's confusing.  The
>link layer types are orthogonal of the routing adjacencies.
>E.g., "It would be more acceptable to give up some security
>to gain some efficiencies by using a group key within internal
>BGP speakers under a single administrative control...".  I
>don't think the example of "exchange links" make sense in this
>context, as there are many bi-lateral agreements for inter-
>domain interconnection and each will most certainly employ a
>unique set of keys per peer, or at least per peer AS.

I'm trying to get at the point that, when on an external multi-access 
link layer -- at say a NAP -- and exchanging PIM, parties may want to 
use peer-wise unique keys, even though it's less efficient. However, 
on an internal multi-access link layer where PIM is exchanged, they 
would be well within reason to use a single group key for all peers 
on the link. It's this distinction between security vs convenience 
that I'm trying to draw out.

I tried to clear the text up.

>>within your domain, whereas operators may favor security
>>    over convenience and use unique keying on peering links.  In this
>>    case again, designers must consider both modes of operation and
>>    ensure the authentication mechanisms fit both.
>>    Operators are encouraged to run cryptographic authentication on all
>>    their adjacencies, but to work from the outside in, i.e.  The EBGP
>>    links are a higher priority than the IBGP links because they are
>>    externally facing.
>
>s/./and as a result, more difficult to secure from external
>attacks./

good point. How about:
s/./, and, as a result, more likely to be targeted in an attack.

Is that pretty much what you meant?

>>3.3.2.  Unique versus Shared Keys
>>    This section discusses security considerations of when it is
>
>s/of when/regarding when/

done.

>>    appropriate to use the same authentication key inputs for multiple
>>    peers and when it is not.  This is largely a debate of convenience
>>    versus security.  It is often the case that the best secured
>>    mechanism is also the least convenient mechanism.  For example, an
>>    air gap between a host and the network absolutely prevents remote
>>    attacks on the host, but having to copy and carry files using the
>>    "sneaker net" is quite inconvenient and unscalable.
>
>Indeed!  Conficker USB stick-enabled attacks appear to
>be much more effective today that the intial Conficker
>vectors that were enabled by the wormable MS08-067 :-)
>File shares are the other primary propagation vector
>today.
>
>>    Operators have erred on the side of convenience when it comes to
>>    securing routing protocols with cryptographic authentication.  Many
>>    do not use it at all.  Some use it only on external links, but
>>not on
>>    internal links.
>
>and some the inverse!
>
>>   Those that do use it often use the same key for all
>>    peers across their entire network.  It is common to see the same
>>key
>>    in use for years, and that being the same key that was entered when
>>
>>Lebovitz &             Expires September 11, 2009              [Page
>>15]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>    authentication was originally configured.
>
>s/configured/configured or routing gear deployed/

done.

>>    The goal for designers is to create authentication mechanisms that
>>    are easy for the operators to deploy, and still use unique keys.
>
>Unique keys where, per session?

and between peers. I clarified the text.

>>    Operators have the impression that they NEED shared keys, when in
>>    fact they do not.  What they need is the relative convenience they
>>    experience from deploying cryptographic authentication with shared
>>    keys, compared to the inconvenience they would experience if they
>>    deployed the same authentication mechanism using unique keys per
>>    pair.  An example is BGP Route Reflectors.  Here operators often
>>use
>>    the same authentication key between each client and the route
>>    reflector.  The roadmaps defined from this guidance document will
>>    allow for unique keys to be used between each client and the peer,
>
>Don't use of confuse client/peer terminology in this context, it's
>no different mechanically than non-RR BGP.

agreed.

>>    without sacrificing much convenience.  Designers should strive to
>>    deliver unique keying mechanisms with similar ease-of-deployment
>>    properties as today's shared keys.
>>    Operators must understand the consequences of using shared keys
>>    across many peers.  Unique keys are more secure than shared keys
>>    because the reduce both the attack target size and the attack
>>    consequence size.
>
>Perhaps the former, not necessarily the latter, depending on
>the attack vector.

ok. not sure there is new text needed?

>>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.  If a shared key is used across
>>    the entire internal domain of control, then the attack target
>>size is
>>    very large.  The larger the attack target, the easier it is for the
>>    attacker to gain access to analysis data, and greater the volume of
>>    analysis data he can access, both of which make his job easier.
>
>This is a refutable argument.  One could submit that it's
>the same cost for an attacker to gain access to one device
>and data analysis set as it is to gain access to the whole.
>I think the key issue here is that a common shared key
>makes the attack vulnerability surface more penetrable than
>unique keys.

Yes. AND, cryptogrpahically, the more protected data an attacker gets 
to analyze, the better for him. if he has access to the transactions 
of 1000 exchanges vs 1, then he will gain more data more quickly. 
That's the difference between the two points.

I like your last sentence, and have edited the paragraph to use it.

>>   In
>>    this context, the attack consequence size represents the amount of
>>    routing adjacencies that can be negatively affected once a breach
>>has
>>    occurred, i.e.  Once the keys have been acquired by the attacker.
>>    Again, if a shared key is used across the internal domain, then the
>>    consequence size is the whole network.  Ideally, unique key pairs
>>    would be used for each adjacency.
>
>Given that most of these are routing 'link' local, this is
>entirely dependent on the attack vector.

agreed.

>>    In some cases designers may need to use shared keys in order to
>>solve
>>    the given problem space.  For example, a multicast packet is sent
>>    once but then observed and consumed by several routing
>>neighbors.  If
>>    unique keys were used per neighbor, the benefit of multicast
>>would be
>>    erased because the casting peer would have to create a different
>>    announcement packet/stream for each listening peer.  Though this
>>may
>>    be desired and acceptable in some small amount of use cases, it is
>>    not the norm.  Shared group keys are an acceptable solution here,
>>and
>>    much work has been done already in this area (see MSEC working
>>    group).
>>
>>
>>
>>Lebovitz &             Expires September 11, 2009              [Page
>>16]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>3.3.3.  Out-of-Band vs. In-line Key Management
>>    This section discusses the security and use case considerations for
>>    keys placed on devices through out-of-band configurations versus
>>    through one routing peer-to-peer key management protocol exchanges.
>>    Note, when we say here "Peer-to-Peer KMP" we do not mean in-band to
>>    the RP.  Instead, we mean that the exchange occurs in-line, over
>>IP,
>>    between the two routing peers directly.  In in-line KMP the peers
>>    themselves handle the key and security association negotiation
>>    between themselves directly, whereas in an out-of-band system the
>>    keys are placed onto the device through some other configuration or
>>    management method or interface.
>>    An example of an out-of-band mechanism could be an administrator
>>who
>>    makes a remote management connection (e.g. using SSH) to a router
>>and
>>    manually enters the keying information -- like the algorithm, the
>>    key(s), the lifetimes, etc.  Another example could be an OSS system
>>    which inputs the same information via a script over an SSH
>>    connection, or by pushing configuration through some other
>>management
>>    connection, standard (Netconf-based) or proprietary.
>>    The drawbacks of an out-of-band mechanism include: lack of scale-
>>    ability, complexity and speed of changing if breech is suspected.
>
>s/breech/breach/

done.

>>    For example, if an employee who had access to keys was was
>>    terminated, or if a machine holding those keys was belived
>>    compromised, then the system would be considered insecure and
>>    vulnerable until new keys were defined by a human.  Those keys then
>>    need to be placed into the OSS system, manually, and the OSS system
>>    then needs to push the change -- often during a very limited change
>>    window -- into the relevant devices.  If there are multiple
>>    organizations involved in these connections, this process is
>>greatly
>>    complicated.
>>    The benefits of out-of-band mechanism is that once the new keys/
>>    parameters are set in OSS system they can be pushed automatically
>>to
>>    all devices within the OSS's domain of control.  Operators have
>>    mechanisms in place for this already.  In small environments with
>>few
>>    routers, a manual system is not difficult to employ.
>>    We further define an in-line key exchange as using cryptographicly
>>    protected identity verification, session key negotiation, and
>>    security association parameter negotiation between the two routing
>>    peers.  The KMP between the two peers may also include the
>>    negotiation of parameters, like algorithms, cryptographic inputs
>>    (e.g. initialization vectors), key life-times, etc.
>>    The benefits an in-line KMP are several.  An in-line KMP results in
>>    key(s) that are privately generated, and not recorded permanently
>>
>>Lebovitz &             Expires September 11, 2009              [Page
>>17]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>    anywhere.  Since the traffic keys used in a particular connection
>>are
>>    not a fixed part of a device configuration no steal-able 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.  They may gain access to key derivation
>>    material, like a PSK, but not current traffic keys in use.  In this
>>    example, these PSKs can be updated into the device configurations
>>    (either manually or through an OSS) without bouncing or impacting
>>the
>>    existing session at all.  In the case of using raw assymetric
>>keys or
>>    certificates, instead of PSKs, the data theft would likely not even
>>    result in any compromise, as the key pairs would have been
>>generated
>>    on the routers, and never leave those routers.  In such a case no
>>    changes are needed on the routers; the connections will continue to
>>    be secure, non-compromised.
>
>s/non-/un.

done

>>   Additoinally, with a KMP regular re-keys
>
>s/Additoinally/Additionally/

done

>>    operations occur without any operator involvement or oversight.
>>This
>>    keeps keys fresh.
>>    The drawbacks to using a KMP are few.  First, a KMP requires more
>>    cryptographic processing for the router at the very beginning of a
>>    connection.  This will add some minor start-up time to connection
>>    establishment versus a purely manual key approach.  Once a
>>connection
>>    with traffic keys have been established via a KMP, the
>>performance is
>>    the same in the KMP and the out-of-band case.  KMPs also add
>>another
>>    layer of protocol and configuration complexity which can fail or be
>>    misconfigured.  This was more of an issue when these KMPs were
>>first
>>    deployed, but less so as these implementaitons and operational
>>    experience with them has matured.
>>    The desired end goal is in-line KMPs.
>>
>>4.  The Roadmap
>>4.1.  Work Phases on any Particular Protocol
>>    The desired endstate for the KMART 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.  These
>>tools
>>    should be fairly simple to implement, and not more complex than the
>>    security mechanisms to which the operators are already accustomed.
>>    (Examples of security mechanisms to which router operators are
>>    accustomed include: the use of assymetric keys for authentication
>>in
>>    SSH for router configuration, the use of pre-shared keys (PSKs) in
>>    TCP MD5 for BGP protection, the use of self-signed certificates for
>>    HTTPS access to device Web-based user interfaces, the use of
>>strongly
>>    constructed passwords and/or identity tokens for user
>>identification
>>
>>Lebovitz &             Expires September 11, 2009              [Page
>>18]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>    when logging into routers and management systems.)  While the tools
>>    that we intend to specify may not be able to stop a deployment from
>>    using "foobar" as an input key for every device across their entire
>>    routing domain, we intend to make a solid, modern security system
>>    that is not too much more difficult than that.  In other words,
>>    simplicity and deployability are keys to success.  The Base RP's
>>will
>>    specify modern cryptographic algorithms and security mechanisms.
>>    Routing peers will be able to employ unique, pair-wise keys per
>>    peering instance, with reasonable key lifetimes, and updating those
>>    keys on a somewhat regular basis will be operationally easy,
>>causing
>>    no service interruption.
>>    The reach the above described end-state using manual keys may
>>only be
>
>s/The reach the/???/

s/The reach/Achieving/

>>    pragmatic in very small deployments.  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 lifecycle
>
>s/lifecycle/life cycle/

done.

>>    management, in the form of a key management protocol, or KMP.  We
>>    expect that the two forms, manual key usage and KMP usage, will co-
>>    exist in the real world.  For example, a provider's edge router
>>at a
>>    public exchange peering point will want to use a KMP for ensuring
>>    unique and fresh keys with external peers, while a manual key may
>>be
>>    used between a provider's access edge router and each of the same
>>    provider's customer premise routers with which it peers.
>>    In accordance with the desired end state just described, we define
>>    two main work phases for each Base RP:
>>    1.  Enhance the Base RP's current authentication mechanism.  This
>>        work involves enhancing a Base RP's current security mechanisms
>>        in order to achieve a consistent, modern level of security
>>        functionality within its existing keying framework.  It is
>>        understood and accepted that the existing keying frameworks are
>>        largely based on manual keys.  Since many operators have
>>already
>>        built operational support systems (OSS) around these manual key
>>        implementations, there is some automation available for an
>>        operator to leverage in that way, if the underlying mechanisms
>>        are themselves secure.  In this phase, we explicitly exclude
>>        embedding or creating a KMP.  A list of the requirements for
>>        Phase 1 work are below in the section "Requirements for Phase 1
>>        BaseRPs' Security Updates (Section 4.2).
>>    2.  Develop an automated keying framework.  The second phase will
>>        focus on the development of an automated keying framework to
>>        faciliate unique pair-wise (or perhaps group-wise, where
>>        applicable) keys per peering isntance.
>
>s/isntance/instance/

done

>>This involves the use of
>>        a KMP.  A KMP is helpful because [will add a more full
>>        description here, sorry, ran out of time].
>
>Nice :-)

filled this out with:
"A KMP is helpful because it negotiates unique, pair wise, random 
keys without administrator involvement. It also negotiates several of 
the SA parameters required for the secure connection, including key 
life times. It keeps track of those lifetimes using counters, and 
negotiates new keys and parameters before they expire, again, without 
administrator interaction. Additionally, in the event of a breach, 
changing the KMP key will immediately cause a rekey to occur for the 
Traffic Key on the connection.

>>The framework for any
>>        one BaseRP will fall under, and be able to leverage, the
>>generic
>>
>>Lebovitz &             Expires September 11, 2009              [Page
>>19]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>        framework described below in section Section 4.3.
>>4.2.  Requirements for Phase 1 BaseRPs' Security Update
>>    Here is a proposed list of requirements that SHOULD be addressed by
>>    Phase 1 (according to "1." above) security updates to Base RPs
>>[to be
>>    reviewed after -01 is released]:
>>    1.   Clear definitions of which elements of the transmission
>>(frame,
>>         packet, segment, etc.) are protected by the authentication
>>         mechanism
>>    2.   Strong algorithms, and defined and accepted by the security
>>         community, MUST be specified.  The option should use
>>algorithms
>>         considered accepted by the security community, which are
>>         considered appropriately safe.  The use of non-standard or
>>         unpublished algorithms SHOULD BE avoided.
>>    3.   Algorithm agility for the cryptograhpic algorithms used in the
>>         authentication MUST be specified, i.e. more than one algorithm
>>         MUST be specified and it is clear how new algorithms MAY be
>>         specified and used.
>
>Why must more than one algorithm be specified?

Great question. In case one gets broken suddenly. The security 
community has learned this the hard way. Research on how to break 
crypto is always going on. Breaking a cipher isn't a matter of if, 
but when. But it's highly unlikely that two different algo's will be 
broken simultaneously. So, if two are supported, and once gets 
broken, we can use the other until we get a new one in place. Having 
the ability within the protocols to allow for such an event, called 
crypto agility, is essential. Forcing two algos provides both a 
redundancy, and a mechanism for getting to that redundancy.

I placed an explanation in the text.

>>    4.   Secure use of simple PSKs, offering both operational
>>convenience
>>         as well as building something of a fence around stupidity,
>>MUST
>>         be specified.
>>    5.   Inter-connection replay protection.  Packets captured from one
>>         connection MUST NOT be able to be re-sent and accepted
>>during a
>>         later connection.
>>    6.   Intra-connection replay protection.  Packets captured during a
>>         connection MUST NOT be able to be re-sent and accepted during
>>         that same connection, to deal with long-lived connections.
>>    7.   A change of security parameters REQUIRES, and even forces, a
>>         change of session traffic keys
>>    8.   Intra-connection re-keying which occurs without a break or
>>         interruption to the current peering session, and, if possible,
>>         without data loss, MUST be specified.
>>    9.   Efficient re-keying SHOULD be provided.  The specificaion
>>SHOULD
>>         support rekeying during a connection without the need to
>>expend
>>         undue computational resources.  In particular, the
>>specification
>>         SHOULD avoid the need to try/compute multiple keys on a given
>>         packet.
>>    10.  Prevent DoS attacks as those described as in-scope in the
>>         threats section Section 2.1above
>
>s/1above/1 above/

done.

>>    11.  Default mechanisms and algorithms specified and defined as
>>         REQUIRED for all implementations
>>    12.  Manual keying MUST be supported.
>>    13.  Architecture of the specification MUST consider and allows for
>>         future use of a KMP.
>>
>>
>>Lebovitz &             Expires September 11, 2009              [Page
>>20]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>4.3.  Common Framework
>>    Each of the categories of routing protocols above will require
>>unique
>>    designs for authenticating and integrity checking their protocols.
>>    However, a single underlying framework for delivering automatic
>>    keying to those solutions will be pursued.  Providing such a single
>>    framework will significantly reduce the complexity of each step of
>>    the overall roadmap.  For example, if each Base RP needed to define
>>    it's own key management protocol this would balloon the total
>>amount
>>    of different sockets that needed
>
>s/that needed/that are needed/

done.

>>to be opened and processes that
>>    needed to be simultaneously running on an implementation.  It would
>>    also significantly increase the run-time complexity and memory
>>    requirements of such systems running multiple Base RPs, causing
>>    perhaps slower performance of such systems.  However, if we can
>>land
>>    on a very small set (perhaps one or two) of automatic key
>>management
>>    protocols, KMPs, that the various Base RP's can use, then we can
>>    reduce this implementation and run-time complexity.  We can also
>>    decrease the total amount of time implementers need to deliver the
>>    KMPs for the Base RPs that will provide better threat protection.
>>    The components for the framework are listed here, and described
>>    below:
>>    o  BaseRP security mechanism
>>    o  KMP
>>    o  KeyStore
>>    o  BaseRP-to-KMP API
>>    o  BaseRP-to-KeyStore API
>>    o  KMP-to-KeyStore API
>>    o  Common Base RP mechanisms
>>    o  Identifiers
>>    o  Proof of identity
>>    o  Profiles
>>    The framework is modularized for how keys and security association
>>    (SA) parameters generally get passed from a KMP to a transport
>>    protocol.  It contains three main blocks and APIs.
>>
>>
>>Lebovitz &             Expires September 11, 2009              [Page
>>21]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>       +------------+   +--------------------+
>>       |            |   |                    | Check     +-----------+
>>       | Identifier +-->|                    +---------->|           |
>>       |            |   |    KMP Function    |           |  Identity |
>>       +----------- +   |                    |<----------+   Proof   |
>>                        |                    |  Approve  |           |
>>                        +-+--------------+---+           +-----------+
>>                          |              |
>>          KMP-to-KeyStore |              |
>>             API          |              |
>>                         \|/             |
>>                  +-------+-------+      |
>>                  |               |      | KMP-to-BaseRP
>>                  |    Session    |      |  API
>>                  |    KeyStore   |      |
>>                  |               |      |
>>                  +-------+-------+      |
>>                          |              |
>>                          |              |
>>            KeyStore-to-  |              |
>>             BaseRP API   |              |
>>                          |             \|/
>>              +--------------------------+-------------+
>>              |           |                            |
>>              |          \|/          Common BaseRP    |
>>              |   +-------+-------+   Authentication   |
>>              |   |               |   Mechanisms       |
>>              +---|  Transport    |-----+--------------+
>>              |   |   Key(s)      |                    |
>>              |   |               |                    |
>>              |   +---------------+   Specific BaseRP  |
>>              |                       Authentication   |
>>              |                       Security         |
>>              |                       Mechanism        |
>>              |                                        |
>>              +----------------------------------------+
>>
>>                Figure 1: Automatic Key Management Framework
>>    Each element of the framework is described here:
>>
>>    o  Base RP -  Base RP security mechanism - In each case, the Base
>>RP
>>            will contain a mechanism for using session keys in their
>>            security option.
>
>But what if that option is a function of the transport
>substrate employed by the RP?  E.g., TCP MD5 Signature
>Option for MSDP, LDP, BGP.

clarification placed in the text.

>>Lebovitz &             Expires September 11, 2009              [Page
>>22]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>
>>
>>    o  KeyStore -   Each implementation will also contain a protocol
>>            independent mechanism for storing keys, called KeyStore.
>>The
>>            key_store will have multiple different logical containers,
>>            one container for each session key that any given Base RP
>>            will need.
>>    o  RP-KeyStore API -   There will be an API for Base RP to retrieve
>>            the keys from the KeyStore.  This will enable
>>implementers to
>>            reuse the same API calls for all their Base RPs.  The API
>>            will necessarily include facility to retrieve other
>>            parameters required for the construction of the BaseRP's
>>            packets, like key IDs or key lifetimes, etc.
>
>Are these other parameters contained in the KeyStore as well,
>and if so, it should be indicated as such above.  I think the
>word "parameters" should be in that definition.

added "here may also be associated parameters as required by the SA 
for any given Routing Protocol." to the KeyStore definition.

>>    o  KMP -   There will be an automated key management protocol, KMP.
>>            This KMP will run between the peers.  The KMP serves as a
>>            protected channel between the peers, through which they can
>>            negotiate and pass important data required to exchange
>>proof
>>            of key identifiers, derive session keys, determine re- keying,
>>            synchronize their keying state, signal various keying
>>events,
>>            notify with error messages, etc.  As an analogy, in the
>>IPsec
>>            protocol [RFC 4301, 4303 and 4306] IKEv2 is the KMP that
>>runs
>>            between the two peers, while AH and ESP are two different
>>            base protocols that take session keys from IKEv2 and use
>>them
>>            in their transmissions.  In the analogy, the Base RP, say
>>BGP
>>            and LDP, are analogous to ESP and AH, while the KMP is
>>            analogous to IKEv2 itself.
>
>I don't like this decoupling as it should be employing the
>facilities of the RP, if possible.

However, the Routing Protocols don't have KMP's, and they weren't 
designed to be KMPs. KMPs are VERY tricky things to get right, 
security wise. Look at IKE. We've been working for 15 yrs to get that 
right, and IKEv2 is very good, strong and secure, having undergone 
tremendous peer review, implementation and use. We want to leverage 
that goodness, not attempt to start over from scratch, one-by-one, in 
each routing protocol.

>  New sessions and a much
>larger attack surface are a primary reason no one uses this
>stuff today for infrastructure protocols.

not really. Everyone uses SSH today for managing their 
infrastructure. It's really no different. In fact, the same ID and 
Identity proof could be re-used as that used in SSH already.

>Also, this seems
>to assume solely two peers, versus multi-access networks
>and RP mechanisms.

There are keying protocols for multi-access situations, and they 
involve a GDOI model, where a key server exists, each peer uses IKE 
to get to the key server in 1:1 connections, then the key server 
delivers a group key. It's kind of like a route reflector for keying. 
At least that's one model. But the basic priniciple holds true: 
create a secure channel for keying and session specifics, and run the 
actual secured connection on its own.

>>    o  RP-KMP API -   There will be an API for the Base RP to request a
>>            session key of the KMP, and be notified when the keys are
>>            available for it.  The API will also contain a mechanism
>>for
>>            the KMP to notify the Base RP that there are new keys
>>that it
>>            must now use, even if it didn't request those keys.  The
>>API
>>            will also include a mechanism for the KMP to receive
>>requests
>>            for session keys and other parameters from the routing
>>            protocol.  The KMP will also be aware of the various Base
>>RPs
>>            and each of their unique parameters that need to be
>>            negotiated and returned.
>>    o  KMP-KeyStore API -   There will be an API for the KMP to place
>>            keys and parameters into the KeyStore after their
>>negotiation
>>            and derivation with the other peer.  This will enable the
>>            implementers to reuse the same calls for multiple KMPs that
>>            may be needed to address the various categories of RPs as
>>            described in the section definingcategories (Section 3).
>
>s/definingcategories/defining categories/

done.

>>Lebovitz &             Expires September 11, 2009              [Page
>>23]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>
>>    [after writing this all up, I'm not sure we really need the
>>key_store
>>    in the middle.  As long as we standardize fully all the calls
>>needed
>>    from any RP to any KMP, then there can be a generic hand-down
>>    function from the KMP to the RP when the key and parameters are
>>    ready.  Let's sleep on it.]
>>    [will need state machines and function calls for these APIs, as one
>>    of the work items.  In essence, there is a need for a core team to
>>    develop the APIs out completely in order for the RP teams to use
>>    them.  Need to get this team going asap.]
>
>This should be a guiding document, not a solutions document.
>Lots of concern here.

sorry, didn't quite catch that. Could you say more? Are you against 
the idea of a design team spinning up to draft these APIs?

>>    o Identifiers -   A KMP is fed by identities.  The identities are
>>            text strings used by the peers to indicate to each other
>>that
>>            each are known to the other, and authorized to establish
>>            connections.  Those identities must be represented in some
>>            standard string format, e.g. an IP address -- either v4 or
>>            v6, an FQDN, an RFC 822 email address, a Common Name [RFC
>>            PKI], etc.  Note that even though routers do not normally
>>            have email addresses, one could use an RFC 822 email
>>address
>>            string as a formatted identifier for a router.  They
>>would do
>>            so simply by putting the router's reference number or name-
>>            code as the "NAME" part of the address, left of the "@"
>>            symbol.  They would then place some locational context in
>>the
>>            "DOMAIN" part of the string, right of the "@" symbol.  An
>>            example would be "[email-masked]".  This
>>            document does not suggest this string value at all.
>
>In the weeds...
>
>>   Instead,
>>            the concept is used only to clarify that the type of string
>>            employed does not matter.  It also does not matter what
>>            specific text you chose to place in that string type.  It
>>            only matters that the type of string -- and it's format --
>>            must be agreed upon by the two endpoints.
>
>Is that a provisioning or dynamic function?  Something
>else that has to be specified manually to make things
>dynamic.

you have to decide what identity type and value you are using. Right 
now we do this implicitly; we use the IP address as the identity, and 
we use the manual key as the proof. All this is saying is that we 
could use something else, like a SubjAltName from an x.509 
certificate, or a CN, and a value appropriately structured for that ID type.

>>Further, the
>>            string can be used as an identifier in this context, even
>>if
>>            the string is not actually provisioned in it's source
>>domain.
>>            For example, the email address "[email-masked] "
>>            may not actually exist as an email address in that domain,
>>            but that string of characters may still be used as an
>>            identifier type(s) in the routing protocol security
>>context.
>>            What is important is that the community decide on a small
>>but
>>            flexible set of Identifiers they will all support, and that
>>            they decide on the exact format of those string.  The
>>formats
>>            that will be used must be standardized and must be sensible
>>            for the routing infrastructure.
>
>We're way in the weeds here, IMO.

Probably. The last sentence is the key. The other stuff above it was 
just examples. My point is that routing people get freaked out 
because they think KMP's means we have to use certs and PKI. But it 
doesn't. You could use whatever id type (or handful of them) we care 
to specify. For example, in IKE using PSK, we call out these 
6:  FQDN, RFC822name (email addr), IPaddr_v6, IPaddr_v4, 
X.509-Subject, X.509.SubjAltName. We could do the same or some subset 
for KARP. But it doesn't have to be certs.

>>Lebovitz &             Expires September 11, 2009              [Page
>>24]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>    o  Identity Proof -   Once the form of identity is decided, then
>>            there must be a cryptographic proof of that identity, that
>>            the peer really is who they assert themselves to be.  Proof
>>            of identity can be arranged between the peers in a few
>>ways,
>>            for example pre-shared keys, raw assymetric keys, or a more
>>            user-friendly representation of assymetric keys, like a
>>            certificate.  Certificates can be used in a way requiring
>>no
>>            additional supporting systems -- e.g. public keys for each
>>            peer can be maintained locally for verification upon
>>contant.
>
>s/contant/contact/

done.

>>            Certificate management can be made more simple and scalable
>>            with the use minor additional supporting systems, as is the
>>            case with self-signed certificates and a flat file list of
>>            "approved thumbprints".  Self-signed certificates will have
>>            somewhat lower security properties than Certificate
>>Authority
>>            signed certificates [RFC Certs].  The use of these
>>different
>>            identity proofs vary in ease of deployment, ease of ongoing
>>            management, startup effort, ongoing effort and management,
>>            security strength, and consequences from loss of secrets
>>from
>>            one part of the system to the rest of the system.  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.  The point here is that there are
>>            options, many of which are quite simple to employ and
>>deploy.
>
>Sure, and this is in the weeds as well, IMO.  Need to uplevel a
>few...

We could, but I've found this exact point to be a place of 
misunderstanding for many routing folks. Once they hear the above, 
they say, "oh, ok. I guess it's not so bad as I imagined; we already 
do that for SSH anyway..." And one more objection is lowered.

>>    o  Profiles -   Once the KMP, Identifiers and Proofs mechanisms are
>>            converged upon, they must be clearly profiled for each Base
>>            RP, so that implementors and deployers alike understand the
>>            different pieces of the solution, and can have similar
>>            configurations and interoperability across multiple
>>vendors'
>>            devices, so as to reduce management difficulty.  The
>>profiles
>>            SHOULD also provide guidance on when to use which various
>>            combinations of options.  This will, again, simplify use
>>and
>>            interoperability.
>>    Common Mechanisms - In as much as they exist, the framework will
>>    capture mechanisms that can be used commonly not only within a
>>    particular category of Base RP and Base RP to KMP, but also between
>>    Base RP categories.  Again, the goal here is simplifying the
>>    implementations and runtime code and resource requirements.
>>There is
>>    also a goal here of favoring well vetted, reviewed, operationally
>>    proven security mechanisms over newly brewed mechanisms that are
>>less
>>    well tried in the wild.
>>
>>
>>
>>
>>Lebovitz &             Expires September 11, 2009              [Page
>>25]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>4.4.  Work Items Per Routing Protocol
>>    Each Base RP will have a team (the [RP]-KMART team) working on
>>    incrementally improving their Base RP's security, These teams will
>>    have the following main work items:
>
>I'm not sure what we're attempting in this section, or
>if these teams are design teams or JWTs, or something
>else, but I don't think this should be in the draft, although
>it SHOULD be specified external to the draft.  The IETF
>has facilities and mechanics to enable this, we need to
>strictly employ those.

What are they; what are the best ways to capture this agreement about 
how to do the work?

Yes, agreed, this sort of statement about how the work will get done 
really is its own draft, or a charter or something. For now, I'm just 
using this doc as a catch all and recording the agreements to date 
between the ADs and ourselves.

>>    PHASE 1:
>>    Characterize the RP
>>       Assess the Base RP to see what authentication mechanisms it has
>>       today.  Does it needs significant improvement to its existing
>>       mechanisms or not?  This will include determining if modern,
>>       strong security algorithms and parameters are present.
>>    Define Optimal State
>>       List the requirements for the Base RP's session key usage and
>>       format to contain to modern, strong security algorithms and
>>       mechanisms, per the Requirements (Section 4.2)section above.
>
>s/)section/) section/

done.

>>The
>>       goal here is to determine what is needed for they BaseRP alone
>>to
>>       be used securely with at least manual keys.
>>    Gap Analysis
>>       Enumerate the requirements for this protocol to move from its
>>       current security state, the first bullet, to its optimal state,
>>       bullet two above.
>
>"Above" where?

just above. Clarified in the text.

>>    Define, Assign, Design
>>       Create a deliverables list of the design and specification work,
>>       with milestones.  Define owners.  Release a document(s)
>>
>>    PHASE 2:
>>    KMP Analysis
>>       Review requirements for KMPs [RFC????].  Identify any nuances
>>for
>>       this particular protocol's needs and its use cases for KMP.
>>List
>>       the requirements that this RP has for being able to be use in
>>       conjunctions with a KMP.  Define the optimal state.
>>    Gap Analysis
>>       Enumerate the requirements for this protocol to move from its
>>       current security state to its optimal state.
>>    Define, Assign, Design
>>
>>
>>
>>Lebovitz &             Expires September 11, 2009              [Page
>>26]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>       Create a deliverabels list of the design and specification work,
>>       with miletsones.  Define owners.  Do the design and document
>>work
>>       for a KMP to be able to generate the Base RP's session keys for
>>       the packets on the wire.  These will be the arguments passed in
>>       the API to the KMP in order to bootstrap the session keys to the
>>       Base RP.
>
>Isn't this a WG chartering or WG charter update sort of thing
>that should take place, to the point above?  There exists clear
>framework for this today.

Yeah, I think so too. Once the WG gets chartered, this whole doc 
becomes multiple more focused docs... as stated above a few times.

>>    There will also be a team formed to work on the base framework
>>    mechanisms for each of the main categories, i.e. the blocks and
>>API's
>>    represented in figure 1 (Figure 1).
>>4.5.  Protocols in Categories
>>    This section groups the Base RPs into like categories, according to
>>    attributes set forth in Categories Section (Section 3).  Each group
>>    will have a design team tasked with improving the security of the
>>    Base RP mechanisms and defining the KMP requirements for their
>>group,
>>    then rolling both into a roadmap document upon which they will
>>    execute.
>
>Again, we need to avoid mechanics of how the work should be
>carried out within the IETF, and focus on the problems and
>goals of the framework document here.  The other stuff needs
>to be captured, but that should happen as a management function
>external to this.

agreed.

>>    BGP, LDP and MSDP
>>        The Base RP's that fall into the category of the one-to-one
>>        peering messages, and will use peer keying protocols, AND are
>>all
>>        transmitted over TCP include BGP RFC 4271 [RFC4271], LDP
>>        [RFC3036] and MSDP [RFC3618].  A team will work on one
>>mechanism
>>        to cover these three protocols.  Much of the work on the BaseRP
>>        update for its existing authentication mechanism is already
>>        occuring in the TCPM Working Group, on the TCP-AO
>>        [I-D.ietf-tcpm-tcp-auth-opt] document, as well as its
>>        cryptography-helper document, TCP-AO-CRYPTO [I-D.ao-crypto].
>>The
>>        exception is the mode where LDP is used directly on the LAN
>>        [RFC????].  The work for this may go into the Group keying
>>        category (w/ OSPF) mentioned below.
>>    OSPF, ISIS, and RIP
>>        The Base RPs that fall into the category Group keying with one-
>>        to-many peering messages includes OSPF [RFC2328], ISIS
>>[RFC1195]
>>        and RIP [RFC2453].  Not surprisingly, all these routing
>>protocols
>>        have two other things in common.  First, they are run on a
>>        combination of the OSI datalink layer 2, and the OSI network
>>        layer 3.
>
>What?  IS-IS over the datalink layer, and RIP and OSPF over
>IP.  The statement above confuses me.

They all have specification for something that happens at layer 2, 
i.e. they aren't simply Layer 3 and Layer 3 alone. Their operation 
has specification in layer 2. Can you think of a better way to say this?

>>Second, they are all internal gateway protocols, or
>>        IGPs.  The keying mechanisms and use will be much more
>>        complicated to define for these.
>
>Depends, not if it's group keying and static :-)
>
>>Lebovitz &             Expires September 11, 2009              [Page
>>27]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>    BFD
>>        Because it is less of a routing protocol, per se, and more of a
>>        peer aliveness detection mechanism, Bidirectional Forwarding
>>        Detection (BFD) [RFC????] will have its own team.
>>    RSVP [RFC????], RSVP-TE [RFC????], and PCE
>>        These three protocols will be handled together. [what more
>>        characterisation should we give here?  Routing AD's, provide
>>text
>>        pls?]
>
>Heh, I'd drop the first RSVP, I think..  PCE, be interesting
>to see where that lands.

Any explanation for why?

>>    PIM-SM and PIM-DM
>>        Finally, the multicast protocols of PIM-SM [RFC4601] and PIM-DM
>>        [RFC3973] will be handled together.  PIM-SM multicasts routing
>>        information (Hello, Join/Prune, Assert) on a link-local basis,
>>        using a defined multicast address.  In addition, it specifies
>>        unicast communication for exchange of information (Register,
>>        Register-Stop) between the router closest to a group sender and
>>        the "rendezvous point" (RP).  The RP is typically not "on-link"
>>        for a particular router.  While much work has been done on
>>        multicast security for application-layer groups, little has
>>been
>>        done to address the problem of managing hundreds or thousands
>>of
>>        small one-to-many groups with link-local scope.  This will be
>>        necessary if we are to have unique keys per speaking router
>>in a
>>        PIM chain.
>
>Did we decide somewhere that unique keys are a requirement
>here?  I missed that?

I guess you are right. I pushed a certain solution type into the 
wording. I deleted that sentence.

>>Such an authentication mechanism should be considered
>>        along with the router-to-Rendezvous Point authentication
>>        mechanism.  The most important issue is ensuring that only the
>>        "legitimate neighbors"

s/legitimate/authorized/

>>get the keys for (S,G), so that rogue
>>        routers cannot participate in the exchanges.  Another issue is
>>        that some of the communication may occur intra-domain, e.g. the
>>        link-local messages in an enterprise, while others for the same
>>        (*,G) may occur inter-domain, e.g. the router-to-Rendezvous
>>Point
>>        messges may be from one enterprise's router to another.  One
>>        possible solution proposes a region-wide "master" key server
>>        (possibly replicated), and one "local" key server per speaking
>>        router.  There is no issue with propagating the messages
>>outside
>>        the link, because link-local messages, by definition, are not
>>        forwarded.  This solution is offered only as an example of how
>>        work may progress; further discussion should occur in this work
>>        team.  Specification of a link-local protection mechanism for
>>        PIM-SM occurred in RFC 4601 [RFC4601], and this work is being
>>        updated in PIM-SM-LINKLOCAL [I-D.ietf-pim-sm-linklocal].
>>        However, the KMP part is completely unspecified, and will
>>require
>>        work outside the expertise of the PIM working group to
>>        accomplish, which is why this roadmap is being created.
>>
>>
>>
>>Lebovitz &             Expires September 11, 2009              [Page
>>28]
>>
>>Internet-Draft                KMART Roadmap                   March
>>2009
>>
>>    These protocols are deemed out-of-scope for this current
>>iteration of
>>    the work roadmap.  Once all of the protocols listed above have had
>>    their work completed, or are clearly within site of completion,
>>then
>>    the community will revisit the need and interest for working on
>>    these:
>>    o  MANET
>>    o  FORCES
>>    [need text from routing ADs on why these are out of scope]
>>4.6.  Priorites
>>    Resources from both the routing area and the security area will be
>>    applied to work on these problem spaces as quickly as possible.
>>    Realizing that such resources are far from unlimited, a rank order
>>    priority for addressing the work of incrementally securing these
>>    groups of routing protocols is provided:
>>    o  Priority 1 - BGP / LDP / MSDP
>>    o  Priority 2 - BFD
>>    o  Priority 3 - OSPF / ISIS / RIP
>>    o  Priority 4 - RSVP and RSVP-TE
>>    By far the most important group is the Priority 1 group as these
>>are
>>    the protocols used on the most public and exposed segments of the
>>    networks, at the peering points between operators and between
>>    operators and their customers.  BFD, as a detection mechanism
>>    underlying the Priority 1 protocols is therefore second.
>
>Again, we need to structure this under IETF mechanics and
>ensure that the work and model are aligned, not invent a
>new one.

>>5.  Security Considerations
>>    This entire document focuses on improving the security of routing
>>    protocols by improving or implementing cryptographic authentication
>>    for each routing protocol.  Security considerations are largely
>>    contained within the body text of the document.
>>    The mechanisms that will be defined under this roadmap aim to
>>improve
>>    the security, better protect against more threats, and provider far
>>    greater operational efficiencies than the state of things at the
>>time
>>    of this writing.
>
>These comments are sorta rolling thoughts, please don't
>take any of them to harshly and discard at will (mostly :-)

Thanks for the great and thorough review, Danny. It's taken me hours 
to pour through it, respond and make the appropriate changes in the 
text. I think that time has been well spent. Pls excuse the fact that 
it has taken me SOOO LONG to get this done. On we go...

Gregory.

>-danny