new draft: draft-murphy-bgp-protect-00.txt

[[e-mail]]

Network Working Group                                      Sandra Murphy
INTERNET DRAFT                                                  NAI Labs
draft-murphy-bgp-protect-00.txt                       February 2002


                        BGP Security Protections



Status of this Memo

This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

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

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

Abstract

BGP, along with a host of other infrastructure protocols designed before
the Internet environment became perilous, is designed with little
consideration for protection of the information it carries.  There are
no mechanisms in BGP to protect against attacks that modify, delete,
forge, or replay data, any of which has the potential to disrupt overall
network routing behavior.

This internet draft discusses some of the security issues with BGP
routing data dissemination, and possible security solutions and the
costs of those solutions.  This internet draft does not discuss security
issues with forwarding of packets.








Murphy                    Expires: August 2002                  [Page 1]

INTERNET DRAFT          BGP Security Protections           November 2001


Table of Contents


 Status of this Memo ..............................................    1
 Abstract .........................................................    1
1 Introduction ....................................................    3
2 Possible Protections ............................................    4
2.1 Threats from outsiders ........................................    4
2.1.1 IP level protection .........................................    5
2.1.2 TCP level protection ........................................    5
2.2 Threats from BGP peers ........................................    5
2.3 Origination Protection ........................................    6
2.4 Origination and Adjacency Protection ..........................    7
2.5 Origination and Route Protection ..............................    8
2.5.1 Remaining Issues ............................................    9
2.6 Filtering .....................................................   11
3 Security Costs ..................................................   12
3.1 Protecting the Peer-Peer Link .................................   12
3.2 Origination Protection ........................................   12
3.3 Origination and Adjacency Protection ..........................   13
3.4 Origination and Route Protection ..............................   13
3.5 Filtering .....................................................   14
4 Security Considerations .........................................   14
5 References ......................................................   14
6 Author's Address ................................................   15

























Murphy                    Expires: August 2002                  [Page 2]

INTERNET DRAFT          BGP Security Protections           November 2001


1.  Introduction

The inter-domain routing protocol BGP was created when the Internet
environment had not yet reached the present contentious state.
Consequently, the BGP protocol was not designed with protection against
deliberate or accidental errors causing disruptions of routing behavior.

Other work [11] discusses the vulnerabilities of BGP, based on the BGP
RFC [1] and on [2].  We here propose several different security
solutions to protect these vulnerabilities and discuss the benefits
derived from each solution and its cost.  Readers are expected to be
familiar with the BGP RFC and the behavior of BGP.

It is clear that the Internet is vulnerable to attack through its
routing protocols.  BGP is no exception.  Faulty, misconfigured or
deliberately malicious sources can disrupt overall Internet behavior by
injecting bogus routing information into the BGP distributed routing
database (by modifying, forging, or replaying BGP packets).  The same
methods can also be used to disrupt local and overall network behavior
by breaking the distributed communication of information between BGP
peers.  The sources of bogus information can be either outsiders or true
BGP peers.

Under the present BGP design, cryptographic authentication of the peer-
peer communication is not mandated.  As a TCP/IP protocol, BGP is
subject to all the TCP/IP attacks, like IP spoofing, session stealing,
etc.  Any outsider can inject believable BGP messages into the
communication between BGP peers and thereby inject bogus routing
information or break the peer to peer connection.  Any break in the peer
to peer communication has a ripple effect on routing that can be wide
spread.  Furthermore, outsider sources can also disrupt communications
between BGP peers by breaking their TCP connection with spoofed RST
packets.  Outsider sources of bogus BGP information can reside anywhere
in the world.

BGP speakers themselves can inject bogus routing information, either by
masquerading as information from any other legitimate BGP speaker, or by
distributing unauthentic routing information as themselves.
Historically, misconfigured and faulty routers have been responsible for
widespread disruptions in the Internet.

The damage that might result from these attacks is discussed in [11].

The risks in BGP arise from three fundamental vulnerabilities:






Murphy                    Expires: August 2002                  [Page 3]

INTERNET DRAFT          BGP Security Protections           November 2001


     no mechanism has been mandated that provides strong protection of
     the integrity, freshness and source authenticity of the messages in
     peer-peer BGP communications.

     no mechanism has been specified to validate the authority of an AS
     to announce NLRI information.

     no mechanism has been specified to ensure the authenticity of the
     AS_PATH announced by an AS.

There are four different BGP message types - OPEN, KEEPALIVE,
NOTIFICATION, and UPDATE.  A discussion of the vulnerabilities arising
from each message and the ability of outsiders or BGP peers to exploit
the vulnerabilities is contained in [11].  To summarize, outsiders can
use bogus OPEN, KEEPALIVE, or NOTIFICATION messages to disrupt the BGP
peer-peer connections and can use bogus UPDATE messages to disrupt
routing.  Outsiders can also disrupt BGP peer-peer connections by
inserting bogus TCP RST packets.  BGP peers themselves are permitted to
break peer-peer connections at any time, and so they cannot be said to
be issuing "bogus" OPEN, KEEPALIVE or NOTIFICATION messages.  However,
BGP peers can disrupt routing by issuing bogus UPDATE messages.  In
particular, bogus ATOMIC_AGGREGATE and AS_PATH attributes and bogus NLRI
in UPDATE messages can disrupt routing.

2.  Possible Protections

2.1.  Threats from outsiders

Outsiders can be prevented from disrupting routing by providing
cryptographic protection of the BGP peer-peer connection.  The
cryptography chosen should protect the source authenticity and integrity
of the message and should also protect against replay.  As the
protection is only of the peer-peer communications, asymmetric
cryptography is not needed.  Two different protection against spoofing
in the peer-peer connection have been suggested:

     IP level protection as defined by IPSEC [7]

     TCP level protection as defined by [8]

Prevention of IP spoofing completely removes any risk associated with
bogus OPEN, KEEPALIVE, or NOTIFICATION messages, as the only
vulnerabilities from these messages come from outsiders.  It also
protects against all threats from bogus UPDATE messages and from bogus
TCP messages arising from outsiders.





Murphy                    Expires: August 2002                  [Page 4]

INTERNET DRAFT          BGP Security Protections           November 2001


2.1.1.  IP level protection

Protection as specified for the IPSEC [7] can be used to provide
connectionless integrity, data origin authentication, and a anti-replay
service.

2.1.2.  TCP level protection

It is possible to protect the peer-peer connection by applying
cryptographic protection at the TCP level to provide connectionless
integrity and data origin authentication.  This has been in use with
some vendors for some time as specified in [8].  Note, however, that the
protections specified in [8] were put in place some time ago.  The IPSEC
protections have advanced since that time.  In particular, the
protections of [8] use MD5 directly, where the IPSEC protections mandate
the use of HMAC-MD5 because of recently publicized concerns of
collisions in MD5.  Also, [8] does not have the provisions for anti-
reply found in IPSEC.  The TCP sequence numbers do provide some
protection against replay. But as some packets, notably a RST packet,
need only be within the receive window to be accepted, the TCP sequence
number protection is not complete.  Finally, [8] has no provisions for
multiple keys to be used in rekeying.  As these are pairwise keys used
for long-lived sessions, the inability to specify multiple keys may not
cause operational difficulties.

Although the TCP level protection specified in [8] has deficiencies when
compared with the protection of IPSEC [7], it is vastly preferable to a
unprotected connection.  If IPSEC is not available, then the TCP level
protection of [8] should definitely be used.  When IPSEC is available,
IPSEC is preferable.  One or the other must be used.

2.2.  Threats from BGP peers

Protection of the communication between BGP peers does nothing to
protect against errors introduced by the BGP speakers themselves.  BGP
speakers can introduce bogus routing information, e.g., invalid
AS_PATHs, false origination announcements of NLRI, etc., at any time.
Furthermore, detecting the BGP source of bogus information (if and when
the bogus-ness is detected) can be difficult if not impossible.

There are several possible solutions to prevent a BGP speaker from
inserting bogus information in its advertisements to its peers.

 (1)   Origination Protection: sign the originating AS.






Murphy                    Expires: August 2002                  [Page 5]

INTERNET DRAFT          BGP Security Protections           November 2001


 (2)   Origination and Adjacency Protection: sign the originating AS and
       predecessor information.

 (3)   Origination and Route Protection: sign the originating AS, and
       nest signatures of AS_PATHs to the number of consecutive bad
       routers you want to prevent from causing damage.

 (4)   Filtering: rely on a registry to verify the AS_PATH and NLRI
       originating AS.

The first three solutions are implemented within the protocol exchanges.
The last solution is an operational protection and leaves the protocol
messages unchanged.

2.3.  Origination Protection

It would be beneficial to authenticate the AS that first advertises a
route to a NLRI.  This could be done by including a new path attribute
which would contain the originating AS number and the originating AS's
digital signature [4] of the AS number plus the NLRI advertised.  A
digital signature (as opposed to a message integrity check using a
shared secret) is preferable because the number and identities of all
eventual recipients are not known and because non-repudiation would be
desired.  If routing was disturbed by the presence of this
advertisement, then the culprit could be determined.

If an infra-structure exists representing ownership of network
addresses, then the owner as well as the originator could sign.  This
signature would indicate that the AS was authorized by the owner to
originate the network.  A BGP speaker receiving a protected origination
could verify that the origination was legitimate.

If routes are aggregated by a BGP speaker and the aggregated route
advertised, then the idea of "originator" and "owner" become less
useful.  There might be several "originators" and "owners" represented
among the aggregated routes.  Furthermore, aggregation prevents
identification of the specific culprit should it be discovered that a
network is being originated incorrectly.

The AGGREGATOR field could be mandatory and an aggregating BGP speaker
could append its signature of the AGGREGATOR field and the aggregated
NLRI.  The protection of the AGGREGATOR field would make it possible to
trace an incorrectly originated network back to an aggregation point.
Unfortunately, the protection of the aggregator information still does
not make it possible to discover the culprit who is incorrectly





Murphy                    Expires: August 2002                  [Page 6]

INTERNET DRAFT          BGP Security Protections           November 2001


originating a network.  The aggregation point, however, would have the
information necessary to continue the trace, at least to the next
aggregation point.

This protection does not ensure that the AS_PATH is authentic or
current.

2.4.  Origination and Adjacency Protection

Reference [3] suggests several different types of cryptographic
protection of BGP.  The suggested protection against possibly faulty BGP
speakers introduces some link state topology information (as in OSPF
[5]) that can be used to verify AS_PATHs.

To obviate the need to trust BGP speakers regarding NLRI information not
specific to their own AS, [3] suggests adding the following information
to the UPDATE message in new path attributes:

-    a sequence number for the UPDATE

-    the AS originating the information (either the aggregator or the
     originator of a direct route) and

-    the "predecessor" of the originating AS (i.e., the neighbor to
     which the NLRI is first advertised).

This information is digitally signed by the BGP originator along with
the NLRI, the ATOMIC_AGGREGATE, the ORIGIN, and the AGGREGATOR fields of
the UPDATE message.  The signature and the predecessor information must
be included as the route in the UPDATE message propagates across the
network, i.e., it is transitive.

This information distributes a bit of link state topology information,
concerning just the last hop before the destination network's AS, into
the usual BGP distance vector (some say "path vector") protocol.  Each
BGP speaker will propagate this "predecessor" information.  Any BGP
speaker could use the signed predecessor information received to verify
that each of the adjacencies represented in an AS_PATH is legitimate.
That is, when a segment of an AS_PATH is a sequence, each adjacent pair
in the sequence could be verified to correspond to a received signed
predecessor tuple.

The protection provided by the signed predecessor information becomes
more difficult to use past an aggregation point where a BGP speaker
advertises a less specific route which includes the originated NLRI.  In





Murphy                    Expires: August 2002                  [Page 7]

INTERNET DRAFT          BGP Security Protections           November 2001


particular, the rules for verifying an AS_PATH containing a segment that
is a set would be either very lenient or very complex.

While this predecessor information assures that each adjacency in a
sequence of an AS_PATH is valid, it does not ensure that the AS_PATH as
a whole is valid.  Each AS's decision regarding routes it will advertise
and traffic it will transit is individual and totally unconstrained.
The fact that a valid path of ASs exists to a destination does not
ensure that the corresponding AS_PATH is valid.  This mechanism also
does not assure that any information which comes from one router alone
(LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.)  is accurate.  A router, then,
can still falsely announce that its neighbor should be forwarded the
traffic for an NLRI.

2.5.  Origination and Route Protection

A protection against possibly faulty BGP speakers that does provide some
assurance that the AS_PATH is valid is described in [9].  The protection
requires digital signatures of nested prefixes of the AS_PATH, carried
in a transitive path attribute.

Each BGP speaker would receive signed route information (including the
AS_PATH, the ATOMIC_AGGREGATE attribute and NLRI) from its peer.  The
signature represents permission from the peer for the speaker to
advertise the route.  After making its routing decision, the BGP speaker
would augment the chosen AS_PATH with its own AS and sign the resulting
route (NLRI + AS_PATH) and ATOMIC_AGGREGATE.  The BGP speaker would pass
to its peers the augmented AS_PATH, its signature, and the signature it
received from its peer which covers the received AS_PATH.  The neighbor
receiving this information can verify that the received AS_PATH was
indeed constructed from an authorized path, by verifying the signature
of the BGP speaker's peer over the tail of the received AS_PATH.  The
BGP speaker's signature will be passed on by the neighbor to provide
similar assurance that it constructed its advertised AS_PATH
legitimately.

A BGP speaker could snip out a suffix of the data it received as well as
the associated signatures and pass those on as the proof that its
AS_PATH was based on reality.  To prevent this, the signatures generated
must cover not only the route information but the intended receiver as
well.

This procedure as described protects against one consecutive faulty
router in the path.  If it is desired to protect against more than one
possibly faulty routers in the path, then the procedure can be nested





Murphy                    Expires: August 2002                  [Page 8]

INTERNET DRAFT          BGP Security Protections           November 2001


arbitrarily.  To protect against K consecutive faulty routers, each
router would receive signed AS_PATH information from its neighbor along
with K signatures of the preceding K BGP speakers in the path, each
successive signature covering a shorter suffix of the AS_PATH.  It would
pass on a newly constructed AS_PATH along with its own signature, its
neighbor's signature and K-1 of the included nested signatures.

For example, consider a case where it was decided to protect against two
faulty BGP speakers.  Suppose AS1 receives an AS_PATH from AS2 of 'AS2
AS3 AS4 ... ASk'.  (In this discussion as well as the next,
ATOMIC_AGGREGATE would be included in the signature, but is omitted for
brevity.)  Then AS1 should also receive AS2's signature of "AS1, 'AS2
AS3 ... ASk', NLRI" as well as AS3's signature of "AS2, 'AS3 ... ASk',
NLRI" and AS4's signature of "AS3, 'AS4 ... ASk', NLRI".  AS1 would
verify the authenticity of AS2's route by verifying the authorizing
signatures from AS3 and AS4.

AS1 uses AS2's signature in authorizing its own announcements.  AS1
would compute a path as 'AS1 AS2 AS3 ... ASk', and pass to its neighbor
AS0 this path along with its signature of "AS0, 'AS1 AS2 AS3 ... ASk',
NLRI" and the authorizing signatures of AS2 and AS3.

Because the intended recipient is included in the signature, each BGP
speaker with N peers generates N signatures for each route announced,
one for each peer.

This discussion is predicated on the use of asymmetric cryptography.
Each autonomous system would be required to possess an asymmetric key
pair.  The public key would have to be accessible to all recipients of
the digital signature.  The private key would have to be available to
all BGP speakers in the autonomous system, but protected from exposure.

2.5.1.  Remaining Issues

This scheme becomes more complicated when one of the BGP speakers
performs aggregation of a set of routes.  To assure recipients of the
validity of the aggregated route, it would be necessary to pass on the
text and signatures of each of the aggregated component routes.  This
means an enormous increase in transmission bandwidth at each aggregation
point and a similar increase in verification time at each verification
point's peers.  This cost would not have to be passed on to further
neighbors further than K (the nesting level of signatures) hops away,
but it does violate the spirit of aggregation.  Alternatively, an
aggregation point could be treated as another type of origination point,
and signatures and verification would stop at that point.





Murphy                    Expires: August 2002                  [Page 9]

INTERNET DRAFT          BGP Security Protections           November 2001


Unfortunately, that provides a mechanism for malicious BGP peers to
announce bogus routes, simply by claiming to have aggregated the
information.  Aggregation also prevents identification of the specific
culprit should it be discovered that a network is being originated in
error.

Neither this scheme nor the Origination and Adjacency Protection assures
that the received route is the best route the peer could have computed.
In particular, it does not guard against a peer that does not announce
the best result of its decision process - for example, a peer that
replays previous updates instead of forwarding a withdrawal, or does not
change its announcements when it receives withdrawn routes, or replays
withdrawal information after a route is reestablished, or replays an
update after having forwarded a withdrawal.  These are a matter for the
internal correct operation of the router and cannot be precluded by
authentication or authorization protection.  This mechanism also does
not assure that any information which comes from one router alone
(LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.)  is accurate.  With these
fields, a router can still falsely announce that its neighbor should be
forwarded the traffic for an NLRI.

The verification process chooses the key to use based on the AS's
mentioned in the AS_PATH.  If implementations do not verify that the
peer BGP speaker prepended its own AS to the AS_PATH, i.e. if a BGP
speaker might pass on an AS_PATH in which it's own AS is not the first
in the PATH, then the AS's mentioned in the AS_PATH are not necessarily
the AS's that produced the signature.  In that case, this verification
process could be using the wrong key.  This signature scheme would have
to be complicated by requiring either

     - that the sender's AS be included in the UPDATE message and the
     signature (so that the verification process could find the
     appropriate key for the signature)

     - or that each sender know the private key of the first AS in the
     AS_PATH (so that the signature and verification processes would be
     using the same key).

Sharing keys between AS's makes those AS's indistinguishable to the
cryptography; the second alternative design should only be chosen with
that caution clearly understood.









Murphy                    Expires: August 2002                 [Page 10]

INTERNET DRAFT          BGP Security Protections           November 2001


2.6.  Filtering

The Internet registries can provide data that will help to assure that
AS_PATHS and NLRI origination data are authorized.  If the data
registered in the Internet registries is available, then an NLRI
origination can be verified against the registry.  Also, peering
information in the registry can be used to verify that the AS_PATH as a
whole was valid.

The assurance provided by this protection would rely on the registry
data being:

     complete:  AS's that do not register their peering relationships or
     assigned networks would hamper the ability to protect the BGP data.

     accurate:  AS's must register peering relationships that exactly
     match their policies.  If the peering relationships are described
     too broadly, bogus routes will pass the filter.  If the peering
     relationships are described too narrowly, legitimate routes will
     fail.

     timely: Additions and changes to the registry data must be
     communicated to the AS's in a timely manner.

     secure: The registries must be known to ensure the authenticity,
     integrity and authorization of provided information while in
     storage and in transmission to an AS.

The assurance provided by this protection relies on the openness of the
data recorded in the registries.  To be truly useful, each autonomous
system's policy would have to be recorded in the registry, in order that
the AS_PATH as a whole can be verified to be valid.  Information about
policy, however, can be sensitive to an autonomous system and not openly
available to every other autonomous system.  Any restrictions on the
availability of information stored in the registry will restrict its
applicability as a protection mechanism.

Filtering based on the registries can also not ensure the authenticity
of the received routes.  The registries currently contain permitted
routes, not necessarily the current forwarding routes.  If, for example,
an AS will accept the same network from multiple peer, with one route to
serve as a backup, filtering based on the registry would not be able to
distinguish which is the route currently in use.







Murphy                    Expires: August 2002                 [Page 11]

INTERNET DRAFT          BGP Security Protections           November 2001


3.  Security Costs

Choosing the protection to apply in any situation depends on the
perception of the risk of attack, of the damage that can result, of the
benefits derived from providing the protection, and of the cost of
providing the protection.  This section discusses the cost of each of
the protection options mentioned above.

3.1.  Protecting the Peer-Peer Link

The cost of this protection is the processing required for the
cryptography and the need to establish and manage the cryptographic
keys.  The cryptography need not be computationally expensive; HMAC or
similar algorithms can be used.  Shared secret keys are adequate for
this protection, as the protection applies only to the communication
between peers, so the key management cost is low.  A separate key must
be used for each BGP peering.  Using one key for multiple peerings even
at a peering point reduces the level of protection that is provided.

This level of protection is low cost and protects against the vast
number of outsiders who pose a threat.

3.2.  Origination Protection

The cost of signing the originating AS of each route is the cost of the
processing required for the cryptography -- generating and verifying
digital signatures -- as well as the need to establish and manage the
cryptographic keys.  For digital signatures, establishing and managing
the cryptographic keys means providing a public key infrastructure to
generate an asymmetric key pair for each autonomous system and to
distribute and maintain certifications of the public keys associated
with each autonomous system.

While the key distribution and signature generation and verification
provides for authentication and integrity of the messages, there is also
a need to ensure the authorization of the origination.  This requires
another infrastructure that would provide certifications of the
authority of an AS to originate a route to a network.

The infrastructures required for authentication of AS messages and for
authorization of origination information might be colocated.  The
establishment and secure operation (e.g., [6]) of the security
infrastructure as well as the cost of secure communication with the
infrastructure are additional costs of this technique.






Murphy                    Expires: August 2002                 [Page 12]

INTERNET DRAFT          BGP Security Protections           November 2001


3.3.  Origination and Adjacency Protection

This scheme requires the same public key infrastructure and origination
infrastructure as is needed for Origination Protection.  It also
requires that each adjacency for a BGP speaker be signed (the
"predecessor" information) and transmitted along with an AS_PATH.
Essentially, each BGP speaker must announce its peers, something that
does not currently occur in the BGP protocol.

Each BGP speaker must compute one signature for each NLRI in each UPDATE
message transmitted and must verify one signature for each NLRI in each
UPDATE message received.  Each UPDATE message must be separately signed
because the mechanism described in [3] includes a sequence number, the
Withdrawn Routes and the Unfeasible Route Length fields, so the
information to be signed changes with each message.  (These fields are
protected from outsiders by the peer-peer communication protection and
so do not need to be digitally signed.  If only the NLRI,
ATOMIC_AGGREGATE and predecessor information were signed each time, then
the signature might not have to be computed with each new UPDATE
message, i.e., AS_PATH changes would not induce new signature
computations.)

The signed predecessor information in each route must be stored by the
recipient indefinitely.  Each route received must be verified by
comparison to the store of predecessor information previously received
in UPDATE messages from all AS sources.

3.4.  Origination and Route Protection

The operational cost of this scheme is described in detail in [10].

This scheme requires the same public key infrastructure and origination
infrastructure as is needed for Origination Protection.

For each UPDATE message received, K signatures (where K is the level of
protection desired from consecutive faulty routers) must be verified.

For each UPDATE message transmitted, one signature must be computed for
each NLRI per recipient.  As discussed before, prevention of cut and
paste attacks requires that the signature include the recipient, so
computing one signature per AS_PATH and NLRI announced is insufficient.

The signatures contained in an UPDATE must be retained for all received
routes in case the route is ever chosen and announced to the peers.
This increases the size of the routing tables.





Murphy                    Expires: August 2002                 [Page 13]

INTERNET DRAFT          BGP Security Protections           November 2001


For efficiency in situations where route flapping is occuring, withdrawn
AS_PATHs and their signatures could be retained.  This would mean that
new announcements of flapped routes still retained would not require new
signature verifications.

3.5.  Filtering

The cost of relying on registries would vary considerably depending on
the protection provided to the information in storage and in transit.
Any latency, above that caused by the use of cryptography, would depend
on the mechanism used to transmit the registry information (e.g.,
anything from frequent complete download to real-time query and
response).

4.  Security Considerations

This entire memo is about security, describing the possible security
solutions to protect vulnerabilities in BGP.  The vulnerabilities are
described in a companion work, [11].

5.  References

[1]  Y. Rekhter and T. Li,  "A Border Gateway Protocol 4 (BGP-4)",
     RFC1771, March 1995.

[2]  Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", work
     in progress, November 2001.  available as
     <<draft-ietf-idr-bgp4-17.txt>> at Internet-Draft shadow sites.

[3]  B. Smith and J.J. Garcia-Luna-Aceves, "Securing the Border Gateway
     Routing Protocol", Proc. Global Internet'96, London, UK, 20-21
     November 1996.

[4]  Bruce Schneier.  Applied Cryptography Protocols, Algorithms, and
     Source Code in C, John Wiley & Sons, Inc 1994.

[5]  John Moy, "OSPF Version 2", RFC 1583, March 1994.

[6]  C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy and C. Orange,
     "Routing Policy System Security", RFC 2725,  December, 1999.

[7]  S. Kent and  R.Atkinson, "Security Architecture for the Internet
     Protocol", RFC2401, November 1998.







Murphy                    Expires: August 2002                 [Page 14]

INTERNET DRAFT          BGP Security Protections           November 2001


[8]  A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature
     Option", RFC2385, August 1998.

[9]  S.Kent, C.Lynn, and K. Seo, "Secure Border Gateway Protocol
     (Secure-BGP)", IEEE Journal on Selected Areas in Communications,
     Vol. 18, No. 4, April 2000, pp. 582-592.

[10] S. Kent, C. Lynn, J. Mikkelson, and K. Seo, "Secure Border Gateway
     Protocol (S-BGP) -- Real World Performance and Deployment Issues",
     Proceedings of the IEEE Network and Distributed System Security
     Symposium (NDSS 2000), February 2000.

[11] S. Murphy, "BGP Security Vulnerabilities Analysis", work in
     progress, February 2002. available as
     <<draft-murphy-bgp-vuln-00.txt>> at Internet-Draft shadow sites.

6.  Author's Address

Sandra Murphy
Network Associates, Inc.
NAI Labs
3060 Washington Road
Glenwood, MD  21738
EMail: [e-mail]


























Murphy                    Expires: August 2002                 [Page 15]