Internet DRAFT - draft-atwood-karp-aapm-rp

draft-atwood-karp-aapm-rp







KARP                                                           W. Atwood
Internet-Draft                                    R. Bangalore Somanatha
Intended status: Standards Track                Concordia University/CSE
Expires: January 16, 2014                                     S. Hartman
                                                       Painless Security
                                                                D. Zhang
                                                                  Huawei
                                                           July 15, 2013


    Authentication, Authorization and Policy Management for Routing
                               Protocols
                      draft-atwood-karp-aapm-rp-00

Abstract

   When tightening the security of the core routing infrastructure, one
   requirement is to ensure that the keying material for the routing
   protocol exchanges is distributed only to the appropriate routers.
   This document specifies requirements on the authentication and
   authorization of routers and proposes the use of policy distribution
   to achieve those requirements.

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 16, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Atwood, et al.          Expires January 16, 2014                [Page 1]

Internet-Draft                KARP AAPM-RP                     July 2013


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  System Overview . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  System Structure  . . . . . . . . . . . . . . . . . . . .   4
     2.2.  System Operation  . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Routing Authentication Policy Database  . . . . . . . . .   5
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Security Goals  . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Operational Goals . . . . . . . . . . . . . . . . . . . .   7
   4.  System Design . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Authentication  . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Authorization . . . . . . . . . . . . . . . . . . . . . .   8
     4.3.  Management of Cryptographic Material  . . . . . . . . . .   8
     4.4.  Router Installation . . . . . . . . . . . . . . . . . . .   8
     4.5.  Router Reboot . . . . . . . . . . . . . . . . . . . . . .   9
   5.  RAPD  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Contents of an RAPD entry . . . . . . . . . . . . . . . .  10
     5.2.  RAPD Authentication Information . . . . . . . . . . . . .  10
     5.3.  Organization and lookup . . . . . . . . . . . . . . . . .  11
     5.4.  Hierarchy of Policy . . . . . . . . . . . . . . . . . . .  11
   6.  Policy Distribution . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  System Configuration Information  . . . . . . . . . . . .  12
     6.2.  Router Authentication . . . . . . . . . . . . . . . . . .  12
     6.3.  Router Authorization  . . . . . . . . . . . . . . . . . .  12
     6.4.  Key Management  . . . . . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   9.  Change History (RFC Editor: Delete Before Publishing) . . . .  13
   10. Needs Work in Next Draft (RFC Editor: Delete Before
       Publishing) . . . . . . . . . . . . . . . . . . . . . . . . .  13
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     11.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Within the Keying and Authentication for Routing Protocols (KARP)
   working group, there are several goals:

   o  Determining how to update the security of existing routing
      protocols, and guiding this work;



Atwood, et al.          Expires January 16, 2014                [Page 2]

Internet-Draft                KARP AAPM-RP                     July 2013


   o  Development of automated mechanisms for management of the keying
      material.

   Within the first goal, each routing protocol has its own procedures
   for protecting a routing protocol message "on the wire", given
   appropriate parameters such as an appropriate traffic encryption key
   and the cryptographic transforms to be used.  How these parameters
   are placed is not defined by the routing protocol specification.

   Within the second goal, protocols and procedures for creating shared
   keys for specific environments have been developed
   [I-D.hartman-karp-mrkmp] [I-D.mahesh-karp-rkmp], under the assumption
   that the end points of the exchanges (the routers) are entitled to
   enter into the conversation.  However, these protocols rely on the
   authentication mechanisms of IKEv2 [RFC5996] to ensure the endpoints
   are who they say they are.  No way is offered to provide these
   mechanisms with expected endpoint identities or to provide
   information on whether an endpoint is entitled to be a neighbor.
   Provision of expected endpoint identities and neighbor authorization
   is in effect provision of a policy on what constitutes an acceptable
   identity and who is an acceptable neighbor.

   In addition, requirements for an operations and management model are
   specified in [I-D.ietf-karp-ops-model].

   This document addresses the issue of policy distribution for
   authentication and authorization of adjacent routers in secure
   routing protocols.  In particular, it addresses the need to ensure
   that cryptographic parameters are distributed only to routers that
   legitimately form part of the "authorized neighbor set" of a
   particular router.  It is not concerned with the contents of the
   exchanged Routing Protocol messages; this is the responsibility of
   the Routing Protocol specification documents.  It is also not
   concerned with the validity of the Routing Protocol messages
   themselves; this is being considered by the SIDR working group.
   Finally, in accordance with the KARP charter, only source
   authentication is provided for the Routing Protocol messages;
   confidentiality of these messages is out-of-scope at this time.

   If the proposed authentication and authorization mechanisms are not
   in place, the mechanism used for authentication is likely to be a
   preshared key, with the same key used throughout a specific area.  It
   is also likely never to be changed, given the difficulty of making
   this change.  When changes come in the topology of the network, it is
   difficult to tell whether a new router is legitimate or not.

1.1.  Terminology




Atwood, et al.          Expires January 16, 2014                [Page 3]

Internet-Draft                KARP AAPM-RP                     July 2013


   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].

2.  System Overview

2.1.  System Structure

   A network that is managed by a particular System Administrator will
   have some number of routers in it, each of which will be running some
   set of routing protocols.

   For a particular routing protocol, the network is divided into one or
   more Administrative Domains (AD).  An AD is a set of routers with a
   common policy.  An AD might encompass a collection of BGP routers
   spanning several Autonomous Systems, or all of the routers inside a
   particular Autonomous System, or all of the routers in an
   organization, or all of the routers in a unit within an organization,
   or simply a pair of routers with a point-to-point link.

   We distinguish four participants in the architecture:

   System Administrator (SA)  This is the human who controls the
          Administrative Domain.

   Administrative Domain Manager (ADM)  This is the manager for the
          entire AD.  Its role is to distribute the operational policies
          to the routers within the AD.

   Standby ADM (SADM)  This provides for robustness if the ADM is
          unavailable.

   Group Member (GM)  Any router within the AD.

   [[NOTE: A figure would be helpful here.]]

   The common policy for a particular AD is managed by the ADM.

   Each router has a unique identity in the context of a particular AD.
   To deal with the issue of interaction between routers in adjacent
   ADs, the link between two such routers may either be managed by one
   of the ADs, or a small AD may be created to manage that specific
   link.  In either case, this implies that a specific router may have
   more than one identity.  Authentication of a router involves
   presenting this identity and establishing its validity.

   For a particular routing protocol, a router needs to know which other
   routers are allowed to exchange routing messages with it.  This set



Atwood, et al.          Expires January 16, 2014                [Page 4]

Internet-Draft                KARP AAPM-RP                     July 2013


   of legitimate neighbors may, in general, be different for each
   routing protocol that a particular router is executing.
   Authorization of a router involves matching the identity of that
   router against the policy governing the set of permitted neighbors.

   Within an AD, there are two levels of interaction.  At the first
   level, there is the interaction between the ADM and each of the
   client routers (GMs).  At the second level, there are the
   interactions between a specific router and the members of its
   neighbor set.

   To participate in the activities within an AD, a router must be
   authenticated, i.e., it must be able to prove that it is a legitimate
   member of the AD.

   To be permitted to communicate with an adjacent router (however
   adjacency is defined for a particular routing protocol), a router
   must be authorized.  A router needs to present its identity when
   communicating with the ADM and also when communicating with the
   routers that are adjacent to it.

   The ADM will distribute to each router the policy that defines how
   the router is to assess the authenticity of a prospective neighbor,
   and how the router is to ascertain that the prospective neighbor is
   authorized to communicate with it.

2.2.  System Operation

   The SA interacts with the ADM to set the policies for the AD.

   The ADM establishes a mutually authenticated relationship with each
   client router, i.e., with each GM in the AD.

   The ADM then pushes the policy definitions to the GMs.

   Based on the policy, each GM establishes a mutually authenticated
   relationship with each of its authorized neighbors.

   Each GM will then negotiate cryptographic parameters with its
   neighbors, or distribute the parameters that it generates, depending
   on the policy in place.

2.3.  Routing Authentication Policy Database

   This specification introduces a new conceptual database on each GM,
   the Routing Authentication Policy Database (RAPD).  The RAPD
   compliments the key table [I-D.ietf-karp-crypto-key-table].  The key
   table provides manually configured keys and the RAPD provides policy



Atwood, et al.          Expires January 16, 2014                [Page 5]

Internet-Draft                KARP AAPM-RP                     July 2013


   for automated key management.  The RAPD provides services similar to
   the IPsec Security Policy Database and Peer Authentication Database
   [RFC4301]

   The RAPD serves the following purposes:

   o  Is automated key management expected for a particular routing
      protocol peer or group

   o  What identity and credentials are used to authenticate to a remote
      key-management peer

   o  What identities and credentials are accepted when a remote peer
      authenticates to us

   o  Is a particular peer authorized for a particular routing protocol

   o  What parameters and transforms are used for a particular security
      association

   o  What key management protocols does this router need to participate
      in and on what interfaces

   See Section 5 for details on the RAPD.

3.  Problem Statement

   The aim of this document is to specify an overall system for
   automated key management, which will eliminate the disadvantages of
   the manual method of key updating.  The basic function of this
   automated system is to distribute and enforce the key management
   policies of the Administrative Domain.  In accordance with these
   policies, secure generation and distribution will be effected of the
   keys or other cryptographic material that will be used for the
   router-to-router exchanges.  The system will also enable key updates
   at regular intervals so as to protect against both active intruders
   and passive intruders who could be eavesdropping the traffic after
   having gained access to the keys secretly.

   Along with these basic goals, a key management system should satisfy
   an additional set of requirements.  These requirements ensure among
   other things, security, easy deployment, robustness and scalability.
   We have compiled this set after referring to the KARP Design Guide
   [RFC6518], the KARP Threats and Requirements Guide [RFC6862] and the
   PIM-SM "security on the wire" specification [RFC5796].

3.1.  Security Goals




Atwood, et al.          Expires January 16, 2014                [Page 6]

Internet-Draft                KARP AAPM-RP                     July 2013


   [[NOTE: The following lists of goals were appropriate in the context
   of Revathi's thesis, which was on formal validation of the security
   of her proposed protocols.  Since we will probably meet at least some
   of these goals by using an already-standardized, secure protocol, the
   list is subject to revision as the details of the framework are
   established.]]

   1.  Peer authentication for unicast and authentication of all members
       of the group for multicast protocols.

   2.  Message authentication, which includes data origin authentication
       and message integrity.

   3.  Protection of the system from replay attacks.

   4.  Peer liveness.

   5.  Secrecy of key management messages.

   6.  Authorization to ensure that only authorized routers get the
       keys.

   7.  Resistance to man-in-the-middle attacks.

   8.  Resistance to DoS attacks.

   9.  Usage of strong keys; those that are unpredictable and are of
       sufficient length.

3.2.  Operational Goals

   1.  Possibility for easy and incremental deployment.

   2.  Smooth key rollover.

   3.  Robustness across router reboots.

   4.  Scalable design.

   5.  Policy for authentication and authorization can be shared between
       unicast and multicast key management.

4.  System Design

4.1.  Authentication

   Each router is assumed to have an identity, i.e., some way of
   distinguishing it from other routers.  The form of this identity is



Atwood, et al.          Expires January 16, 2014                [Page 7]

Internet-Draft                KARP AAPM-RP                     July 2013


   determined by the SA of the network.  It may be a simple string, or
   it may be a cryptographically strong identity such as that proposed
   by Chunduri [draft-chunduri].

   Each router is assumed to have a way to assert the validity of this
   identity.  The acceptable form(s) of this assertion mechanism will be
   determined by the policy set by the SA.

   [[NOTE: Insert examples here from Sections 4.1, 4.2 and 4.3 of the
   ops-model.]]

4.2.  Authorization

   A router has a neighbor set, which is the set of routers that it is
   able to exchange packets with.  The connection used for this exchange
   may be physical or virtual.

   A router has an authorized neighbor set, for a particular Routing
   Protocol, which is the set of routers that it is authorized to
   communicate with using the exchanges of that Routing Protocol.

   The verification that a router in the neighbor set is also in the
   authorized neighbor set for a particular Routing Protocol is governed
   by a policy that is set by the SA.

   [[NOTE: Insert examples here from ops-model, section 4.]]

4.3.  Management of Cryptographic Material

   When a router discovers one or more members of its authorized
   neighbor set, it will then generate, negotiate, or acquire the
   cryptographic parameters that it will use when exchanging Routing
   Protocol packets with these neighbors.  Depending on the procedures
   defined by the Routing Protocol specification for securing the
   exchanged packets, these cryptographic parameters may include the
   key(s) to be used, the IPsec Security Parameter Index (SPI) assigned,
   etc.

   For the case where inter-router communication is based on unicast
   communication, an approach has been developed, which is presented in
   [I-D.mahesh-karp-rkmp].  For the case where the inter-router
   communication is based on multicast exchanges, an approach has been
   developed, which is presented in [I-D.hartman-karp-mrkmp].

4.4.  Router Installation

   An important aspect of the design is ease of deployment.  When a new
   router is installed, the following steps must be taken:



Atwood, et al.          Expires January 16, 2014                [Page 8]

Internet-Draft                KARP AAPM-RP                     July 2013


   1.  Establish the existence of a new router identity in the AD, using
       the SA - ADM interface.

   2.  Define the policy or policies that are applicable to this new
       identity, using the SA - ADM interface.

   3.  For the router that will be the first router on the network path
       between the new router and the ADM, take whatever action is
       necessary to force the ADM to push revised configuration
       information to it.

   4.  At the new router, manually install sufficient policy to allow it
       to accept its neighbor as part of its authorized neighbor set,
       and to allow it to know the location of the ADM.  Then, force the
       ADM to push complete configuration information to it.

4.5.  Router Reboot

   A router must store the information concerning its governing policies
   in a form of storage that persists over a reboot.

   When a router reboots (and especially when a large number of routers
   reboot due to a power failure and restoration), a router must use the
   stored information to re-establish its neighbor relationships.  This
   will minimize the likelihood of an apparent denial of service attack
   on the ADM.

   Once the router has established its neighbor relationships, and after
   a suitable (random) interval, the router should contact its ADM to
   refresh its policy database.

5.  RAPD

   According to the key table, routing protocols specify a peer and
   protocol in order to request a key to send a message.  The peer is
   either the identity of a unicast peer or of a group.  The form of the
   peer identifier is specified by the specific routing protocol in
   question.

   The peer and protocol are enough to find an existing key.  As a
   result, the RAPD needs to be able to locate the appropriate automated
   key management policy given a peer and protocol.

   The RAPD is also used by key management applications when a peer
   attempts to authenticate or request a key.  In this instance, the key
   management application has the IKE identity of the peer.





Atwood, et al.          Expires January 16, 2014                [Page 9]

Internet-Draft                KARP AAPM-RP                     July 2013


5.1.  Contents of an RAPD entry

   In order to establish an IKE SA, the following information is needed:

   o  Identity of the local system to use

   o  Identities acceptable for the remote endpoint

   o  Credential to use for the local system

   o  Authentication information for the remote system; see Section 5.2

   o  Lifetime information

   o  Acceptable transforms

   In order to establish a routing SA keyed by an IKE SA, the following
   information is needed:

   o  Peer and protocol

   o  Acceptable transforms

   Additional information is required for multicast policy.

5.2.  RAPD Authentication Information

   The RAPD entry needs to include enough information that the remote
   peer can be authenticated.  The required information tends to break
   down along the same lines as the credential types discussed in
   section 4 of [I-D.ietf-karp-ops-model].

   For pre-shared keys, mutual authentication is obtained by using the
   same key in both directions.  In this case the credential for
   outbound authentication is a pre-shared key.  For inbound
   authentication, multiple acceptable credentials can be provided.

   For public keys used outside of authentication, authentication needs
   to happen in each direction.  Each peer needs a private key and
   potentially a certificate to send as a credential.  Each peer also
   needs a set of acceptable fingerprints for the remote key-management
   peer's key or certificate.

   When a PKI is used, each peer needs a private key and a certificate
   as a credential.  In addition, trust anchors and constraints on how
   to validate whether an asserted identifier is appropriate for the
   presented certificate are required.




Atwood, et al.          Expires January 16, 2014               [Page 10]

Internet-Draft                KARP AAPM-RP                     July 2013


5.3.  Organization and lookup

   One open question is how to organize the RAPD.  When initiating a
   connection, policy is found using the peer and protocol information.
   When receiving an incoming association, the peer and protocol might
   not be available until the routing protocol SA is requested so policy
   needs to be found based on the initiator's asserted identity.

   One approach would be to separate incoming and outgoing policy and
   use two different databases.  This is highly undesirable from an
   operational standpoint.  In general it is not possible to know ahead
   of time which router will initiate a key management exchange.  For
   this reason, it is strongly desired from an operational standpoint
   that the policy be symmetric.  That is, an association SHOULD
   successfully authenticate and be authorized independent of which
   party initiates the association.  There are exceptions; for example,
   in a multicast association, one router MAY be configured not to take
   on the role of a Group Controller/Key Server (GCKS) and such a router
   could not respond to key-management associations.

   Another approach is to have a single database indexed by the tuple
   containing peer and protocol as well as the set of acceptable remote
   identifiers.

   Another approach is to have two databases.  One contains the peer,
   protocol, unicast key management endpoint and a policy identifier.
   The second database contains the remaining information along with a
   policy identifier.  It is indexed by the policy identifier and by the
   set of acceptable remote identifiers.  This layout is very similar to
   the breakdown between IPsec's SPD and PAD.

   All of these approaches assume that the set of acceptable remote
   identifiers is enumerated in the policy database.  In a PKI this may
   be undesirable.

5.4.  Hierarchy of Policy

6.  Policy Distribution

   [[NOTE: I give below my initial suggestion on a list of policy items
   that will need to be distributed.  My student Nitin has suggested a
   different way to organize the information, specifically by looking at
   the types of interaction: SA - ADM; ADM - GM and GM - GM.  I expect
   that both views will be necessary and will revise the document
   appropriately.]]






Atwood, et al.          Expires January 16, 2014               [Page 11]

Internet-Draft                KARP AAPM-RP                     July 2013


   In this section, we give an initial list of the policy items that
   will need to be distributed.  The policy will have several facets,
   each derived from the operational steps.

6.1.  System Configuration Information

   The system configuration information consists of the following:

   1.  ADM information (how to reach it)

   2.  SADM information (how to reach it)

   This information is pushed regularly to allow for changes to the ADM
   location and the SADM location after the initial (manual)
   configuration.

6.2.  Router Authentication

   These entries deal with how to identify a legitimate member of the
   AD.

   Under certain circumstances, the ideas in KARP KMP: Simplified Peer
   Authentication [I-D.chunduri-karp-kmp-router-fingerprints] are
   appropriate.

   [[NOTE: I need to go through the ideas in section 4 of the ops-model
   document to clarify this.]]

6.3.  Router Authorization

   These entries deal with how to authorize a specific group member to
   communicate with its peers.

   At a minimumn, this will be a list of "authorized neighbors", along
   with the necessary cryptographic material to permit identifying them.

6.4.  Key Management

   o  Key generation/negotiation: acceptable procedures, acceptable
      transforms

   o  Key hygiene: lifetimes, etc.

   o  Operational rules (from, for example, Operations Model for Router
      Keying [I-D.ietf-karp-ops-model]

7.  IANA Considerations




Atwood, et al.          Expires January 16, 2014               [Page 12]

Internet-Draft                KARP AAPM-RP                     July 2013


   This document has no actions for IANA.

8.  Acknowledgements

9.  Change History (RFC Editor: Delete Before Publishing)

   [NOTE TO RFC EDITOR: this section for use during I-D stage only.
   Please remove before publishing as RFC.]

   atwood-karp-akam-rp-00

   o  Original submission.

10.  Needs Work in Next Draft (RFC Editor: Delete Before Publishing)

   [NOTE TO RFC EDITOR: this section for use during I-D stage only.
   Please remove before publishing as RFC.]

   List of stuff that still needs work

   o  Expand the set of policy descriptions

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2.  Informative References

   [I-D.chunduri-karp-kmp-router-fingerprints]
              Chunduri, U., Tian, A., Keranen, A., and T. Kivinen, "KARP
              KMP: Simplified Peer Authentication", draft-chunduri-karp-
              kmp-router-fingerprints-03 (work in progress), March 2013.

   [I-D.hartman-karp-mrkmp]
              Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router
              Key Management Protocol (MaRK)", draft-hartman-karp-
              mrkmp-05 (work in progress), September 2012.

   [I-D.ietf-karp-crypto-key-table]
              Housley, R., Polk, T., Hartman, S., and D. Zhang,
              "Database of Long-Lived Symmetric Cryptographic Keys",
              draft-ietf-karp-crypto-key-table-07 (work in progress),
              March 2013.

   [I-D.ietf-karp-ops-model]



Atwood, et al.          Expires January 16, 2014               [Page 13]

Internet-Draft                KARP AAPM-RP                     July 2013


              Hartman, S. and D. Zhang, "Operations Model for Router
              Keying", draft-ietf-karp-ops-model-07 (work in progress),
              July 2013.

   [I-D.mahesh-karp-rkmp]
              Jethanandani, M., Weis, B., Patel, K., Zhang, D., Hartman,
              S., Chunduri, U., Tian, A., and J. Touch, "Negotiation for
              Keying Pairwise Routing Protocols in IKEv2", draft-mahesh-
              karp-rkmp-04 (work in progress), February 2013.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC5796]  Atwood, W., Islam, S., and M. Siami, "Authentication and
              Confidentiality in Protocol Independent Multicast Sparse
              Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
              5996, September 2010.

   [RFC6518]  Lebovitz, G. and M. Bhatia, "Keying and Authentication for
              Routing Protocols (KARP) Design Guidelines", RFC 6518,
              February 2012.

   [RFC6862]  Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
              Authentication for Routing Protocols (KARP) Overview,
              Threats, and Requirements", RFC 6862, March 2013.

Authors' Addresses

   William Atwood
   Concordia University/CSE
   1455 de Maisonneuve Blvd, West
   Montreal, QC  H3G 1M8
   Canada

   Phone: +1(514)848-2424 ext3046
   Email: william.atwood@concordia.ca
   URI:   http://users.encs.concordia.ca/~bill











Atwood, et al.          Expires January 16, 2014               [Page 14]

Internet-Draft                KARP AAPM-RP                     July 2013


   Revathi Bangalore Somanatha
   Concordia University/CSE
   1455 de Maisonneuve Blvd, West
   Montreal, QC  H3G 1M8
   Canada

   Email: revathi.bs@gmail.com


   Sam Hartman
   Painless Security

   Email: hartmans@painless-security.com


   Dacheng Zhang
   Huawei

   Email: zhangdacheng@huawei.com
































Atwood, et al.          Expires January 16, 2014               [Page 15]