Subject: Re: a draft that missed the deadline
From: Tony Li <[email-masked]>
To: [email-masked] (Sandy Murphy)
Cc: [email-masked]
Date: 26 Nov 1997 17:02:08 -0800

Sandy,

Thank you for the note.  

I was quite disappointed to see no mention of
draft-heffernan-tcp-md5-02.txt.gz (admittedly, it has expired) or its
methods.  You alude to the benefits, but seem completely oblivious to the
fact that it's already in shipping code.

I was also hoping for more of a recommendation for the internal sources
solution.  The problem there is of the most theoretical interest and the
one that we would appreciate the assistance on.

Finally, I was really hoping to see more discussion of the prefix
assignment problem.  Again, you allude to it briefly in section 3.3, but
the authenticated delegation of prefixes is a serious problem that we could
use help with.

Regards,
Tony

Date: Wed, 26 Nov 1997 15:36:19 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: a draft that missed the deadline
Cc: [email-masked]
Sender: [email-masked]

Attached you will find an internet-draft describing the security
vulnerabilities in BGP, some possible solutions and the costs of those
solutions.  This is an item that I've been supposed to complete for an
unconscionable length of time.  Unfortunately, I did not get it done
in time for submission to the IETF by the Friday cutoff.

Yakov has suggested that I discuss this at the idr meeting in Washington.

--Sandy Murphy
  Trusted Information Systems
  Glenwood, MD  21738
-------------------------------------------------------------------------



Network Working Group                                       Sandra Murphy
INTERNET DRAFT                                Trusted Information Systems
draft-ietf-bgp-secr-00.txt                                  November 1997

                         BGP Security Analysis

Status of this Memo

This document is an Internet Draft.  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 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''.

To learn the current status of any Internet Draft, please check the
1id-abstracts.txt listing contained in one of the Internet Drafts Shadow
Directories on ds.internic.net (US East Coast), venera.isi.edu (US West
Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe).

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 data it communicates or of its own
behavior.  There are no mechanisms in BGP to protect against attacks
that modify, delete, forge, or replay data, any of which has the
potential to be destructive of 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.

1.  Introduction

The two most common inter-domain routing protocols, BGP and IDRP, were
created when the Internet environment had not yet reached the present
contentious state.  Consequently, neither protocol was designed with

Murphy                     Expires: Jun 1998                    [Page 1]

INTERNET DRAFT           BGP Security Analysis             December 1997

protection against deliberate or accidental errors causing disruptions
of routing behavior.

We here discuss the vulnerabilities of BGP, based on the BGP RFC [1].
Vulnerabilities in IDRP should be similar.  We propose several different
security solutions to protect these vulnerabilities, discuss the
benefits derived from each solution and its cost.

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.  The sources
can be either external or internal to the protocol, i.e., non-BGP
speakers or true BGP speakers.  Under the present BGP/IDRP design, any
external source can inject believable BGP/IDRP packets into the
communication between BGP/IDRP peers and thereby inject bogus routing
information or break the peer to peer connection.  With IP spoofing, the
external sources of bogus BGP information can reside anywhere in the
world.  Furthermore, external sources can disrupt communications between
BGP peers by breaking their TCP connection with spoofed RST packets.
Internal sources, i.e., BGP speakers themselves, can inject bogus
routing information masquerading as information from any other
legitimate BGP speaker.  Bogus information from either external or
internal sources can affect routing behavior in the Internet over a
wide, possibly unbounded, area.

Bogus routing information can have many different effects on routing
behavior.  If the bogus information removes routing information for a
particular network, that network can become unreachable for the portion
of the Internet that accepts the bogus information.  If the bogus
information changes the route to a network, then packets destined for
that network may be forwarded by a sub-optimal path, or a path that does
not follow the expected policy, or a path that will not forward the
traffic.  If the bogus information makes it appear that an autonomous
system originates a network when it does not, then packets for that
network may not be deliverable for the portion of the Internet that
accepts the bogus information.  A false announcement that an autonomous
systems originates a network may also fragment aggregated address blocks
in other parts of the Internet and cause routing problems for other
networks.

Murphy                     Expires: Jun 1998                    [Page 2]

INTERNET DRAFT           BGP Security Analysis             December 1997

2.  Specific Vulnerabilities

Each message introduces certain different vulnerabilities:

2.1.  OPEN

Because receipt of a new OPEN message in the Established state will
cause the close of the BGP peering session and thereby induce the
release of all resources and deletion of all associated routes, the
ability to spoof this message can lead to a severe disruption of
routing.

2.2.  KEEPALIVE

Receipt of a KEEPALIVE message when the peering connection is in the
OpenSent state can lead to a failure to establish a connection.  The
ability to spoof this message is a vulnerability, but difficult to
exploit deliberately, as it must be carefully timed in the sequence of
messages exchanged between the peers if it is to cause damage.

2.3.  NOTIFICATION

Receipt of a NOTIFICATION message will cause the close of the BGP
peering session and thereby induce the release of all resources and
deletion of all associated routes.  Therefore, the ability to spoof this
message can lead to a severe disruption of routing.

2.4.  UPDATE

The Update message carries the routing information.  The ability to
spoof any part of this message can lead to a disruption of routing.

2.4.1.  Unfeasible Routes Length, Total Path Attribute Length

There is a vulnerability arising from the ability to modify these
fields.  If a length is modified, the message is not likely to parse
properly, resulting in an error, the transmission of a NOTIFICATION
message and the close of the connection.  As a true BGP speaker is
always able to close a connection at any time, this vulnerability
represents an additional risk only when the source is external, i.e., it
presents no additional risk from internal sources.

Murphy                     Expires: Jun 1998                    [Page 3]

INTERNET DRAFT           BGP Security Analysis             December 1997

2.4.2.  Withdrawn Routes

An external source could cause the elimination of existing legitimate
routes by forging or modifying this field.  An external source could
also cause the elimination of reestablished routes by replaying this
withdrawal information from earlier packets.

A BGP speaker could "falsely" withdraw feasible routes using this field.
However, as the BGP speaker is authoritative for the routes it will
announce, it is allowed to withdraw any previously announced routes that
it wants.  As the receiving BGP speaker will only withdraw routes
associated with the sending BGP speaker, there is no opportunity for a
BGP speaker to withdraw another BGP speaker's routes.  Therefore, there
is no additional vulnerability from internal sources via this field.

2.4.3.  Path Attributes

The path attributes present many different vulnerabilities.

Attribute Flags, Attribute Type Codes, Attribute Length

An internal or external source could modify the attribute length or
attribute type (flags and type codes) so they did not reflect the
attribute values that followed.  If the length were modified, the likely
result would be that the UPDATE message would not parse correctly.  If
the flags were modified, the flags and type code could become
incompatible (i.e., a mandatory attribute marked as partial), or a
optional attribute could be interpreted as a mandatory attribute or vice
versa.  Modifying the type code could cause the attribute value to be
interpreted as if it were the data type and value of a different
attribute.  The most likely result from modifying the attribute flags or
type code would be a parse error of the UPDATE message.  A parse error
from any modification would cause the transmission of a NOTIFICATION
message and the close of the connection.  As a true BGP speaker is
always able to close a connection at any time, this vulnerability
represents an additional risk only when the source is external, i.e., it
presents no additional risk from internal sources.

ORIGIN

This field indicates whether the information was learned from IGP or EGP
information.  If the route is used in inter-AS multicast routing, a
values of INCOMPLETE may be used.  This field is not used in making
routing decisions, so there are no vulnerabilities arising from this
field, either from internal or external sources.

Murphy                     Expires: Jun 1998                    [Page 4]

INTERNET DRAFT           BGP Security Analysis             December 1997

AS_PATH

An internal or external source could announce an AS_PATH that was not
accurate for the associated NLRI.  Forwarding for the NLRI associated
with the AS_PATH could potentially be induced to follow a sub-optimal
path, a path that did not follow some intended policy, or even a path
that would not forward the traffic.

It is not clear how far an inaccurate AS_PATH could deviate from the
true AS_PATH.  It may be that the first AS in the AS_PATH, at least,
must be a legal hop.  The RFC states that a BGP speaker prepends its own
AS to an AS_PATH before announcing it to a neighbor.  If the BGP speaker
must prepend its own AS, then a BGP speaker that produced a bogus
AS_PATH could end up receiving the traffic for the associated NLRI.
This could be desirable if the error was deliberate and the intent was
to receive traffic that would not otherwise be received.  Receiving the
mis-routed traffic could be undesirable for the faulty BGP speaker if it
is not prepared to handle the extra (mis-routed) traffic.  So, if a
deliberately malicious speaker must prepend its own AS, it could be
motivated or discouraged from inventing an arbitrary AS_PATH.  If the
BGP speaker need not prepend its own AS, then it could announce a path
that begins with the AS of any BGP speaker.  Whether such an arbitrary
AS_PATH is a vulnerability would depend on whether BGP implementations
check the AS_PATH (to see if the first AS is the neighbor) and would
catch the error.  If there are legitimate situations in which a BGP
speaker could pass an AS_PATH to a neighbor without putting its own AS
at the head of the AS_PATH, then there is no way for implementations to
detect totally bogus AS_PATHs.

Originating Routes

A special case of announcing a false AS_PATH occurs when the AS_PATH
advertises a direct path to a very specific network address.  An
internal or external source could disrupt routing to the network(s)
listed in the NLRI field by falsely advertising a direct path to the
network.  The NLRI would become unreachable to the portion of the
network that accepted this route, unless the BGP speaker undertook to
tunnel the packets it was forwarded for this NLRI on toward their
destination by a legal path.  But even when the BGP speaker tunnels the
packets on to the correct destination, the route followed may not be
optimal or may not follow the intended policy.  Additionally, routing
for other networks in the Internet could be affected if the false
advertisement fragmented an aggregated address block.

Murphy                     Expires: Jun 1998                    [Page 5]

INTERNET DRAFT           BGP Security Analysis             December 1997

NEXT_HOP

The NEXT_HOP attribute defines the IP address of the border router that
should be used as the next hop when forwarding the NLRI listed in the
UPDATE message.  If the recipient is an external peer, then the
recipient and the NEXT_HOP address must share a subnet.  It is clear
that an outside source modifying this field could disrupt the forwarding
of traffic between the two AS's.  In the case that the NEXT_HOP address
is an inter-AS peer and the recipient of the message is an inter-AS peer
of a different AS (this is one of two forms of "third party" NEXT_HOP),
then the BGP speaker advertising the route has the opportunity to direct
the recipient to forward traffic to a BGP speaker (the NEXT_HOP peer)
that may not be able to continue forwarding the traffic.  It is unclear
whether this would also require the advertising BGP speaker to construct
an AS_PATH mentioning the NEXT_HOP inter-AS peer's AS.

MULTI_EXIT_DISC

The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted
between inter-AS BGP peers.  While the MULTI_EXIT_DISC received from an
inter-AS peer may be propagated within an AS, it may not be propagated
to other AS's.  Consequently, this field is only used in making routing
decisions internal to one AS.  Modifying this field, whether by an
external source or an internal source, could influence routing within an
AS to be sub-optimal, but the effect should be limited in scope.

LOCAL_PREF

The LOCAL_PREF attribute must be included in all messages with internal
peers and excluded from messages with external peers.  Consequently,
modification of the LOCAL_PREF could effect the routing process within
the AS only.  Note that there is no requirement in the BGP RFC that the
LOCAL_PREF be consistent among the internal BGP speakers of an AS.  As
internal sources are free to choose the LOCAL_PREF as they wish,
modification of this field is a vulnerability with respect to external
sources only.

ATOMIC_AGGREGATE

The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way
has received a more specific and a less specific route to the NLRI and
installed the aggregated route.  This route cannot be deaggregated
because it is not certain that the route to more specific prefixes will
follow the listed AS_PATH.  Consequently, BGP speakers receiving a route
with ATOMIC_AGGREGATE are restricted from making the NLRI any more

Murphy                     Expires: Jun 1998                    [Page 6]

INTERNET DRAFT           BGP Security Analysis             December 1997

specific.  Removing the ATOMIC_AGGREGATE attribute would remove the
restriction, possibly causing traffic intended for the more specific
NLRI to be routed incorrectly.   Adding the ATOMIC_AGGREGATE attribute
when no aggregation was done would have little effect, beyond
restricting the un-aggregated NLRI from being made more specific.  This
vulnerability exists whether the source is internal or external.

AGGREGATOR

This field may be included by a BGP speaker who has computed the routes
represented in the UPDATE message from aggregation of other routes.  The
field contains the AS number and IP address of the last aggregator of
the route.  It is not used in making any routing decisions, so it does
not represent a vulnerability.

2.4.4.  NLRI

By modifying or forging this field, either an external or internal
source could cause disruption of routing to the announced network,
overwhelm a router along the announced route, cause data loss when the
announced route will not forward traffic to the announced network, route
traffic by a sub-optimal route, etc.

3.  Possible Protections

3.1.  External sources

External sources can be prevented from disrupting routing by providing
cryptographic protection of the BGP peer connection.  The cryptography
chosen should protect the 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.  The
protection could be provided at the IP level by using existing IPSEC
mechanisms.  If IPSEC is not available, using cryptographic protection
within BGP or TCP would be necessary (but is not as yet defined).  Note
that applying the cryptographic protection within BGP does not provide
the same protection as applying it within TCP, as TCP information other
than the payload (BGP) data (e.g., the RST field) could still be spoofed
in ways that would harm the connection.

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

Murphy                     Expires: Jun 1998                    [Page 7]

INTERNET DRAFT           BGP Security Analysis             December 1997

3.2.  Internal sources

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, incorrect ORIGINs, etc., at any time.  Furthermore, detecting
the internal 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)  sign the originating AS.

(2)  sign the originating AS and predecessor information

(3)  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)  rely on a registry to say if AS_PATH and originating AS are valid

3.3.  Sign Originating AS

It would be beneficial to know which AS has first advertised a route to
a NLRI.  This could be done by including a new field which would contain
the originating AS number and the originating AS's digital signature [3]
of that plus the NLRI advertised. A digital signature is required
because the number and identities of all eventual recipients could not
be known and because non-repudiation would be desired.  This field could
be verified against an Internet registry, if a complete and accurate
registry existed.  If routing was disturbed by the presence of this
advertisement, then the culprit could be determined.

If a structure exists representing ownership of network addresses, then
the owner as well as the advertiser could sign.  A representation of an
owner could be useful when Internet service providers transfer sub-
blocks of their owned addresses to smaller ISP's.  The ISP's could
advertise NLRI but the ownership of the network could still be
determined.

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.  We suggest that the AGGREGATOR field

Murphy                     Expires: Jun 1998                    [Page 8]

INTERNET DRAFT           BGP Security Analysis             December 1997

become mandatory and that an aggregating BGP speaker append its
signature of the AGGREGATOR field and the aggregated NLRI.
Unfortunately, aggregation prevents identification of the specific
culprit should it be discovered that a network is being originated in
error.

3.4.  Sign Originating AS and Predecessor Information

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

To protect against the need to trust BGP speakers regarding NLRI
information not specific to their own AS, [2] suggests adding the
following information to the UPDATE message:

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

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

This field is digitally signed along with the NLRI, the
ATOMIC_AGGREGATOR, and other 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, even those who are transit only and originate no UPDATE
messages with NLRI contained in their own AS, will transmit this
"predecessor" information.  From all the signed predecessor information
received, it would be possible to verify that each of the adjacencies
represented in an AS_PATH is legitimate.  When a segment of an AS_PATH
is a sequence, each adjacent pair in the sequence must 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 NLRI.  In
particular, the rules for verifying an AS_PATH containing a segment that
is a set would be either very lenient or very complex.

Murphy                     Expires: Jun 1998                    [Page 9]

INTERNET DRAFT           BGP Security Analysis             December 1997

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.

3.5.  Sign Originating AS and AS_PATH

A protection against possibly faulty BGP speakers that does provide some
assurance that the AS_PATH is valid involves nested digital signatures
of the AS_PATH.

Each BGP speaker would receive signed AS_PATH information (including the
ATOMIC_AGGREGATOR and NLRI attributes) from its peer.  After making its
routing decision, it would augment the chosen AS_PATH with its own AS
and sign the result.  The BGP speaker would pass to its peers the
augmented AS_PATH, its signature, and the signature of its peer over the
base AS_PATH from which the augmented AS_PATH was formed.  The peer
receiving this information can verify that the received AS_PATH was
indeed constructed with some basis in reality 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 peer to provide similar
assurance that it constructed its advertised AS_PATH legitimately.

This procedure as described protects against one consecutive faulty
router in the path.  If it is desired to protect against more possibly
faulty routers in the path, then the procedure can be nested
arbitrarily.  To protect against n consecutive faulty routers, each
router would receive signed AS_PATH information from its neighbor along
with n signatures of the preceding n BGP speakers in the path, each
successive signature covering a shorter suffix of the path.  It would
pass on a newly constructed AS_PATH along with its own signature, its
neighbor's signature and n-1 of the included nested signatures.

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
should cover not only the AS_PATH but the intended receiver as well.

Murphy                     Expires: Jun 1998                   [Page 10]

INTERNET DRAFT           BGP Security Analysis             December 1997

For example, consider a case where it was decided to protect against
only one faulty BGP speaker.  Suppose AS1 receives an AS_PATH from AS2
of "AS2 AS3 ... ASk".  Then it should also receive AS2's signature of
"AS1, 'AS2 AS3 ... ASk'" and AS3's signature of "AS2, 'AS3 ... ASk'".
AS1 would compute a path "AS1 AS2 AS3 ... ASk", and pass on to AS0 this
path along with its signature of "AS0, 'AS1 AS2 AS3 ... ASk'" and AS2's
signature of "AS1, 'AS2 AS3 ... ASk'".

Note that 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 and
verification time at each aggregation point, rather than a decrease.
This cost would not have to be passed on to further neighbors, but it
does violate the spirit of aggregation.

Note that this scheme does not assure 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 - a peer that replays previous announcements, perhaps,
or does not change its announcements when it receives withdrawn routes.
These are a matter for the internal correct operation of the router and
cannot be induced by security protection.  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.

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.
Alternatively, each BGP speaker could possess its own asymmetric key
pair, at the cost of further complicating the protocol.  The protocol
would have to be altered to include the identity of the BGP speaker
within the AS who produces the AS_PATH and signature so that the
signature verification procedure could choose the correct public key to
use.

Symmetric cryptography could be used to protect the information by using
a keyed cryptographic hash instead of a digital signature.  However, in
order to provide the same level of protection against faulty routing,
each BGP speaker would have to share a different secret key with each of

Murphy                     Expires: Jun 1998                   [Page 11]

INTERNET DRAFT           BGP Security Analysis             December 1997

its neighbors and each of its neighbors' neighbors.  (In the case that
it is desired to protect against n>1 faulty BGP speakers, the number of
keys would grow exponentially - a different key with all 1-hop-away
neighbors, 2-hop-away neighbors, ..., and n+1-hop-away neighbors.) This
is obviously not a scalable solution.  It may also require autonomous
systems to reveal their peering agreements where they would not wish to
do so.

3.6.  Rely on Registries

The Internet registries can provide data that will help to assure that
AS_PATHS and NLRI origination data are correct.  If the data registered
in the Internet registries can be assumed to be correct, then the
peering information in the database can be used to verify each pair of
AS's in an AS_PATH sequence segment are truly peers.  Depending on the
sophistication of the information recorded in the registry, the
registries might also be used to verify that the AS_PATH as a whole was
valid.

The assurance provided by this protection would rely on the completeness
of the registry, on the authenticity of the registry data and on the
protection it received in storage and transit.  The protection is useful
if data from the registry is either available locally or retrievable
with an acceptable lag time.

The assurance provided by this protection also 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.

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

Murphy                     Expires: Jun 1998                   [Page 12]

INTERNET DRAFT           BGP Security Analysis             December 1997

4.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.  Ideally, a separate key should be used for each BGP
peering.  One key might be used for multiple peerings with a reduction
in the level of protection that is provided.  However, it is best to
remember that apocryphally, the more places know a secret, the more
chances it will be exposed.

This level of protection is low cost and protects against the vast
number of possible adversaries (i.e., any non-BGP speaker in the
internet).

4.2.  Sign Originating AS

The cost of signing the originating AS of each route is the cost of
providing a public key infrastructure to generate an asymmetric key pair
for each autonomous system and to distribute and maintain the public
keys associated with each autonomous system.  The Internet registries
might be sufficient to serve as an authorization structure for
advertising each NLRI, but the authorization of ownership of network
addresses would either have to come from the IANA or from some new
authorization structure.

4.3.  Sign Originating AS and Predecessor Information

This scheme requires the same public key infrastructure as is needed if
one simply signs the originating AS information.  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 UPDATE message transmitted and must verify one signature for
each UPDATE message received.  (Each UPDATE message must be separately
signed because the mechanism described in [2] 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 external sources 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.)  The predecessor information in each route must be stored

Murphy                     Expires: Jun 1998                   [Page 13]

INTERNET DRAFT           BGP Security Analysis             December 1997

indefinitely.  Each route received must be verified by comparison to
predecessor information previously received.

4.4.  Sign Originating AS and AS_PATH

This scheme requires the same public key infrastructure as is needed if
one simply signs the originating AS information.  For each UPDATE
message received, n signatures (the level of protection from consecutive
faulty routers) must be verified.  For each UPDATE message transmitted,
one signature must be computed.  Note that the signature includes the
recipient, so computing one signature per AS_PATH and NLRI announced is
insufficient.

4.5.  Rely on Registries

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 protect the registry information (e.g.,
anything from frequent complete download to real-time query and
response).

5.  Security Considerations

This entire memo is about security considerations.

6.  References

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

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

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

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

7.  Author's Address

Sandra Murphy
Trusted Information Systems
3060 Washington Road

Murphy                     Expires: Jun 1998                   [Page 14]

INTERNET DRAFT           BGP Security Analysis             December 1997

Glenwood, MD  21738
EMail: [email-masked]

Murphy                     Expires: Jun 1998                   [Page 15]

INTERNET DRAFT           BGP Security Analysis             December 1997

Table of Contents

 Status of this Memo ..............................................    1
 Abstract .........................................................    1
1 Introduction ....................................................    1
2 Specific Vulnerabilities ........................................    3
2.1 OPEN ..........................................................    3
2.2 KEEPALIVE .....................................................    3
2.3 NOTIFICATION ..................................................    3
2.4 UPDATE ........................................................    3
2.4.1 Unfeasible Routes Length, Total Path Attribute Length .......    3
2.4.2 Withdrawn Routes ............................................    4
2.4.3 Path Attributes .............................................    4
 Attribute Flags, Attribute Type Codes, Attribute Length ..........    4
 ORIGIN ...........................................................    4
 AS_PATH ..........................................................    5
 Originating Routes ...............................................    5
 NEXT_HOP .........................................................    6
 MULTI_EXIT_DISC ..................................................    6
 LOCAL_PREF .......................................................    6
 ATOMIC_AGGREGATE .................................................    6
 AGGREGATOR .......................................................    7
2.4.4 NLRI ........................................................    7
3 Possible Protections ............................................    7
3.1 External sources ..............................................    7
3.2 Internal sources ..............................................    8
3.3 Sign Originating AS ...........................................    8
3.4 Sign Originating AS and Predecessor Information ...............    9
3.5 Sign Originating AS and AS_PATH ...............................   10
3.6 Rely on Registries ............................................   12
4 Security Costs ..................................................   12
4.1 Protecting the Peer-Peer Link .................................   13
4.2 Sign Originating AS ...........................................   13
4.3 Sign Originating AS and Predecessor Information ...............   13
4.4 Sign Originating AS and AS_PATH ...............................   14
4.5 Rely on Registries ............................................   14
5 Security Considerations .........................................   14
6 References ......................................................   14
7 Author's Address ................................................   14

Murphy                     Expires: Jun 1998                   [Page 16]

To: [email-masked]
From: [email-masked] (Info Desk)
Subject: Advertisement: Website Hosting
Date: Tue, 25 Nov 1997 19:19:17 -0500
Sender: [email-masked]

-----------------------------------------------------------------------------
If you wish to be excluded from any future mailings,
reply with "remove" in the subject header.
-----------------------------------------------------------------------------

http://www.infowatch.net

InfoWatch would like to introduce our complete Hosting and Promotional
service.

	FOR ONLY $29.95 PER MONTH !

* 30 MB (megabytes) of disk space
* 1000 MB = 1 GB (gigabyte) of data transfer per month
* 8 E-mail accounts
* INTERNATIONAL Hosting
* Access to your account anytime via the Web Control Panel
* Full MS Front Page support
* Unlimited FTP updates
* Personal CGI directory for your own scripts (or use ours)
* Comprehensive statistics program shows you everything
* E-mail forwarding, auto responders and vacation reply
* Domain name registration (www.yourname.com)
* Register your domain with over 250 search engines-FREE
* Friendly customer support

* Inquire about our $24.95 plan

If for any reason you are not satisfied with InfoWatch's service after 30
days, we will transfer you back to your original host and pay any transfer fees.

http://www.infowatch.net 
[email-masked]

To: [email-masked] (Vivian_Lu)
cc: [email-masked], [email-masked]
Subject: Re: third party nexthop
From: Tony Li <[email-masked]>
Date: 24 Nov 1997 15:12:41 -0800
Lines: 27
Sender: [email-masked]

> It seems to me with the underlined restriction in the "third party" 
> NEXT_HOP case, the internal peer whose interface address is advertised
> in the NEXT_HOP attribute by the BGP speaker must be on the same subnet
> as BGP speaker and its external peer.

Yup, that's what that's trying to say.

> My question is when and how does this get used in the real world scenario?

How IS it used, or how COULD it be used?  Suppose that you had a LAN for an
inter-domain interconnect where particular providers showed up with more
than one router.  One router could be used to distribute routing info to
neighbors, and this feature would cause traffic to actually short cut this
router.

I'm not aware of anyone who actually makes use of this as the redundancy in
this mechanism is somewhat lacking...

> why will there be a need of a IBGP and EBGP running on two different machines
> on the same subnet?
> and how many vendors actually enforce this checking?

I know of at least two implementations that check this.  Further, not
checking is pretty much guaranteed to be suicidal (to your traffic).

Tony

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Multiprotocol Extensions for BGP-4 to Proposed Standard
Reply-to: [email-masked]
Date: Mon, 24 Nov 1997 17:03:13 -0500
Sender: [email-masked]

The IESG has received a request from the Inter-Domain Routing Working
Group to consider Multiprotocol Extensions for BGP-4
<draft-ietf-idr-bgp4-multiprotocol-01.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by January 2, 1998.

Files can be obtained via
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-01.txt

Date: Mon, 24 Nov 1997 16:24:36 -0500
From: [email-masked] (Vivian_Lu)
To: [email-masked]
Subject: third party nexthop
Cc: [email-masked]
Sender: [email-masked]

Hi,

We are currently implementing bgp4, and have the following questions.

In the latest draft, (section 5.1.3 NEXT_HOP)

  "The NEXT_HOP path attribute defines the IP address of the border
   router that should be used as the next hop to the destinations listed
   in the UPDATE message.  When advertising a NEXT_HOP attribute to an
   external peer, a router may use one of its own interface addresses in
   the NEXT_HOP attribute provided the external peer to which the route
   is being advertised shares a common subnet with the NEXT_HOP address.
   This is known as a "first party" NEXT_HOP attribute.  A BGP speaker
                                                         ^^^^^^^^^^^^^
   can advertise to an external peer an interface of any internal peer
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   router in the NEXT_HOP attribute provided the external peer to which
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the route is being advertised shares a common subnet with the
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   NEXT_HOP address.  This is known as a "third party" NEXT_HOP
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   attribute.  A BGP speaker can advertise any external peer router in
   ^^^^^^^^^
   the NEXT_HOP attribute provided that the IP address of this border
   router was learned from an external peer and the external peer to
   which the route is being advertised shares a common subnet with the
   NEXT_HOP address.  This is a second form of "third party" NEXT_HOP
   attribute."

It seems to me with the underlined restriction in the "third party" 
NEXT_HOP case, the internal peer whose interface address is advertised
in the NEXT_HOP attribute by the BGP speaker must be on the same subnet
as BGP speaker and its external peer.

My question is when and how does this get used in the real world scenario?
why will there be a need of a IBGP and EBGP running on two different machines
on the same subnet?
and how many vendors actually enforce this checking?

Your help is very much appreciated.

Vivian.
------------------------------------------------------------------------
Vivian H. Lu                 E-MAIL: [email-masked]
NetEdge Systems, Inc.        PHONE: (508)670-2934
85 Rangeway Road,            FAX: (508)262-0802
Billerica, Massachusetts.
------------------------------------------------------------------------

To: [email-masked]
cc: [email-masked]
Subject: IDR WG proposed agenda
Date: Fri, 21 Nov 97 07:19:06 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

Below is a proposed agenda for our meeting in December.
If you want to add any other items, please send them to
to either Sue Hares ([email-masked]), or to me.

Yakov.
---------------------------------------------------------------

1. Agenda bashing

  S. Hares, Y. Rekhter

2. To be Multihomed: Requirements and Definitions

  H. Berkowitz

3. BGP-4+ practice and experience for multicast

  D. Meyer

4. Route flap dampening

   C. Villamizar

5. BGP-4 over ATM and Proxy PAR

   T. Przygienda

6. Use of MD-5 for BGP authentication

   T. Przygienda

7. BGP-4+ for IPv6

   P. Marques, F. Dupont

Date: Fri, 21 Nov 1997 15:17:12 +0100
From: "Hannes R. Boehm" <[email-masked]>
To: [email-masked]
Subject: default free Internet -> default routes -> which router
Sender: [email-masked]

We are planning to get the default free Internet routes from two differnt
providers. -> at the moment we use a default route torwards the internet...

Our Backbone area operates at 10Mbit/s,  the speed of the 
Inter Provider Connections varies from 256 kBit/s to 2Mbit 
(but the speed will increase soon)

Which routers should I use as border routers and which should I use in
the backbone area (routers without a default route) ?

How much memory do they need ? 

At the moment we use cisco 4000 routers with 16 MB -> I assume that they 
can't handle the default free routing table.

Is a cisco 4700 with 64 MB sufficient ? 
Or is a 7xxx (e.g. the  7200) necessary ?

Hannes R. Boehm

-- 
!------------------------------------------------------------------!
  Hannes R. Boehm
        email   : [email-masked]
        www     : http://hannes.boehm.org
        PGP-key : http://hannes.boehm.org/hannes-pgp.asc
!------------------------------------------------------------------!

Date: Fri, 28 Nov 1997 09:49:21 -0500
From: Antoni Przygienda <[email-masked]>
Organization: Bell Labs, Lucent
To: [email-masked]
CC: [email-masked]
Subject: [Fwd: new draft  BGP-4 over ATM and Proxy PAR<draft-przygienda-bgp4-atm-00.txt>]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------56AA7FF1EEE82EE6BBFA66D1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

--------------56AA7FF1EEE82EE6BBFA66D1
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Message-ID: <[email-masked]>
Date: Wed, 19 Nov 1997 16:15:38 -0500
From: Antoni Przygienda <[email-masked]>
Organization: Bell Labs, Lucent Technologies
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.30 i586)
MIME-Version: 1.0
To: "[email-masked]" <[email-masked]>
Subject: new draft  BGP-4 over ATM and Proxy PAR
	                   <draft-przygienda-bgp4-atm-00.txt>

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

new draft draft-przygienda-bgp4-atm-00.txt

thank you for processing.

                                                        --- tony

Internet Engineering Task Force                            T. Przygienda
INTERNET DRAFT                            Bell Labs, Lucent Technologies
                                                        19 November 1997

                      BGP-4 over ATM and Proxy PAR
                   <draft-przygienda-bgp4-atm-00.txt>

Status of This Memo

   This document is an Internet Draft, and can be found as
   draft-przygienda-bgp4-atm-00.txt in any standard internet drafts
   repository.  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.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material, or to cite them other than as a
   ``working draft'' or ``work in progress.''

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.

Abstract

   This draft specifes for BGP-4 implementors and users mechanisms
   describing how the protocol operates in ATM networks over PVC and
   SVC meshes with the presence of Proxy PAR. These recommendations
   do not require any protocol changes and allow for simpler, more
   efficient and cost-effective network designs.  Proxy PAR can help to
   distribute changes of peer relationships when BGP-4 capable routers
   are reconfigured on the ATM cloud.

Przygienda                 Expires 25 May 1998                  [Page 1]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

1. Introduction

1.1. Introduction to Proxy PAR

   Proxy PAR [CPS96, PD97a] is an extension allowing for different ATM
   attached devices to interact with PAR capable switches and obtain
   information about non-ATM services without executing PAR [Ca96]
   which is an extension of PNNI [AF96b] themselves.  The client side
   is much simpler in terms of implementation complexity and memory
   requirements than a complete PAR protocol stack and should allow for
   easy implementation in e.g.  existing IP routers.  Additionally,
   clients can use Proxy PAR to register different non-ATM services and
   protocols they support.  Proxy PAR has consciously not been included
   as part of ILMI due to the complexity of PAR information passed in
   the protocol and the fact that it is intended for integration of
   non-ATM protocols and services only.  A device executing Proxy PAR
   does not necessarily need to execute ILMI or UNI signaling although
   this normally will be the case.  The context or reference model is
   aligned with the one included in ILMI [AF96a].

   The protocol in itself does not specify how the distributed service
   registration and data delivered to the client is supposed to be
   driving other protocols so e.g.  OSPF routers finding themselves
   through proxy PAR could use this information in RFC1577 [Lau94]
   fashion, forming a full mesh of point-to-point connections to
   interact with each other to simulate broadcast interfaces.  For the
   same purpose LANE [AF95] or MARS [Arm96] could be used.

   As a by-product, Proxy PAR could provide the ATM address resolution
   for IP attached devices but such resolution can be achieved by other
   protocols under specification in IETF as well, e.g.  [CH97a, CH97b].
   And last but not least, it should be mentioned here that the
   protocol coexists with and complements the ongoing work in IETF
   on server detection via ILMI extensions [Dav97] and opaque LSAs
   [CH97a, CH97b].

1.1.1. Proxy PAR Scopes

   Any Proxy PAR registration is carried only within a defined scope
   that is set during registration and is equivalent to the PNNI routing
   level.  Since no assumptions except scope values can be made about
   the information distributed (e.g.  IP addresses bound to NSAPs
   are not assumed to be aligned with them in any respect such as

Przygienda                 Expires 25 May 1998                  [Page 2]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

   encapsulation or functional mapping), registration information cannot
   be summarized.  This makes a careful handling of scopes necessary to
   preserve the scalability.  More detailed comments on these issues and
   optimizations possible when logical IP topology aligns with aspects
   of ATM topology can be found in [PD97b].

1.2. Introduction to BGP

   Border Gateway Protocol (BGP) is an Exterior Gateway Protocol (EGP)
   and described in [RL95, RL97] from which most of the following
   paragraphs have been taken almost literally.

   The primary function of a BGP speaking system is to exchange
   network reachability information with other BGP systems.  This
   network reachability information includes information on the
   list of Autonomous Systems (ASs) that reachability information
   traverses.  This information is sufficient to construct a graph of AS
   connectivity from which routing loops may be pruned and some policy
   decisions at the AS level may be enforced.

   BGP runs over a reliable transport protocol.  This eliminates the
   need to implement explicit update fragmentation, retransmission,
   acknowledgment, and sequencing.  Any authentication scheme used
   by the transport protocol may be used in addition to BGP's own
   authentication mechanisms.  The error notification mechanism used
   in BGP assumes that the transport protocol supports a "graceful"
   close, i.e., that all outstanding data will be delivered before the
   connection is closed.

   BGP deployments are normally configured such that that all BGP
   speakers within a single AS must be fully meshed so that any external
   routing information must be re-distributed to all other routers
   within that AS. This represents a serious scaling problem that
   has been well documented with several alternatives proposed.  The
   alternative supported in Proxy PAR are route reflectors [Bat96] due
   to their simplicity, easy migration and compatibility with existing
   BGP configurations.

Przygienda                 Expires 25 May 1998                  [Page 3]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

2. BGP over ATM

2.1. Model

   The model used for BGP operation over ATM in connection with
   Proxy PAR assumes that not only pre-configured peers exist but
   neighbor relationships can be formed dynamically based on discovery
   mechanisms.  Such a discovery must be provided by an underlying
   layer since BGP does not include peer auto-detection that would be
   comparable with e.g.  OSPF's hellos used to find all OSPF routers on
   a specific subnet.  To fulfill this purpose, Proxy PAR allows BGP to
   register and query the following data with the server:

    -  ATM address

    -  IP instance

    -  IP address

    -  IP mask

    -  BGP Identifier

    -  route reflector type as one of:

        *  reflector of a certain cluster or

        *  client of a certain cluster or

        *  non-client

   The motivation of such a model is to allow for a simpler maintainance
   of BGP router configuration when some router interfaces are connected
   over ATM. As an example, full mesh connectivity on a specific
   subnet does not require the configuration of peer relationsships in
   routersa priori but a router can register as providing BGP services
   on an interface and his possible peers discover it through Proxy
   PAR queries.  Figure 1 illustrates a possible BGP scenario with
   several cases of relationsships based on the following Proxy PAR
   registrations:

    -  Router R1 is configured to be BGP capable and has the interface

        *  1.1.1.1 reaching into DMZ subnet 1.1.1/255.255.255

Przygienda                 Expires 25 May 1998                  [Page 4]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

                               +--+
                               |R1|
                               +--+
                        1.1.1.1 | register BGP for
                                | AS101, BGP Id 1.1.1.1, no route
                                | reflector
                                |
        ======================= | ========================== AS101
         1.1.1/255.255.255.0    |
       +--------------+---------+-------------+------+ DMZ
                      |                       |
        ============= | ===================== | ============ AS100
                      |                       |
                      | 1.1.1.3               | 1.1.1.2
                      |                       |
                    +--+                     +--+
                    |R2| registers BGP for   |R3| registers BGP for
                    |  | AS100, Id 1.1.1.3,  |  | AS100, Id 1.1.1.2,
                    +--+ non-client          +--+ RR for cluster 4
                      |                       |
                      | 1.1.2.3               | 1.1.2.2
                      |                       |
       +---+----------+-----------------------+-----------+
           |                1.1.2/255.255.255.0
           |
           | 1.1.2.1     +
          +--+           |
          |R4|-----------+
          +--+ 1.1.3.1   |   1.1.3.2 +--+ registers BGP for AS100,
                         +-----------|R5| Id 1.1.2.1,
                         |           +--+ RR client cluster 4
                         +

Figure 1:  Logical IP Topology with Proxy PAR Registrations (Single ATM
                                network)

    -  Router R3 is configured to be BGP capable, is route reflector for
       cluster id 4, and has the interfaces

        *  1.1.1.2 reaching into DMZ subnet 1.1.1/255.255.255 and

        *  1.1.2.2 to the subnet 1.1.2/255.255.255 inside its AS

Przygienda                 Expires 25 May 1998                  [Page 5]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

    -  Router R2 is configured to be BGP capable and has the interfaces

        *  1.1.1.3 reaching into DMZ subnet 1.1.1/255.255.255 and

        *  1.1.2.3 to the subnet 1.1.2/255.255.255 inside its AS

    -  Router R5 is configured to be BGP capable, is a client of route
       reflector cluster id 4, and has the interface

        *  1.1.2.1 to a subnet 1.1.2/255.255.255 inside its AS

   It has to be stated here that the model assumes that E-BGP-multihop
   will not be supported through auto-configuration.  Based on such an
   assumption, the following queries are generated by the routers and
   conclusions drawn concerning the BGP sessions to be formed:

   Q1> Router R1 queries for all BGP capable routers on the DMZ
       subnet (1) and discovers R2 and R3 supporting interfaces 1.1.1.3
       and 1.1.1.2 and being in a different AS. Router R1 concludes to

        *  build a E-BGP connection to router R3 (shown with &'s in
           Figure 2)

        *  build a EBPG connection to router R2 (shown with #'s in
           Figure 2)

   Q2> Router R2 queries for all BGP capable routers on the DMZ subnet
       and discovers R3 and R1 on the same subnet and concludes to

        *  build a E-BGP connection to router R1 since it is in a
           different AS

        *  not to build a E-BGP connection to router R3 since it is in
           the same AS

   Q3> Router R3 issues a symmetric query to Q2 and comes to conclusions
       analogous to Q2>

   Q4> Router R2 queries for all routers supporting BGP inside of the
       same AS, detects R3 and R5 and concludes to

___________________________________________
1. since one of its interfaces is on this subnet

Przygienda                 Expires 25 May 1998                  [Page 6]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

                               +--+
                               |R1|
                               +--+
                        1.1.1.1 #&
                                #&
                                #&
                                #&
        ======================= #& ========================= AS101
                                #&
       +--------------###########&&&&&&&&&&&&&&------+ DMZ
                      #                       &
        ============= # ===================== & ============ AS100
                      #                       &
                      # 1.1.1.3               & 1.1.1.2
                      #                       &
                    +--+                     +--+
                    |R2|                     |R3|
                    |  |                     |  |
                    +--+                     +--+
                      %                       %@
                      % 1.1.2.3               %@ 1.1.2.2
                      %                       %@
                      %                       %@
       +--------------%%%%%%%%%%%%%%%%%%%%%%%%%@----------+
                      @@@@@@@@@@@@@@@@@@@@@@@@@@
                      @
                      @            +
                    +-@@           |
                    |R4@@@@@@@@@@@@@
                    +--+           @   1.1.3.2 +--+
                                   @@@@@@@@@@@@|R5|
                                   +           +--+

  Figure 2:  Active BGP Connections after Auto-Discovery in Figure 1.

        *  build an I-BGP connection to R3 since R3 is a reflector and
           R2 is a non-client (shown with %'s in Figure 2)

        *  not build an I-BGP connection to R5 since R5 is a client of a
           route reflector

Przygienda                 Expires 25 May 1998                  [Page 7]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

   Q5> Router R3 queries for all routers supporting BGP inside of the
       same AS, detects R2 and R5 and concludes to

        *  build an I-BGP connection to R2 since R3 is a reflector and
           R2 is a non-client

        *  build an I-BGP connection to R5 since R5 is a client of the
           route reflector for the same cluster (shown with @'s in
           Figure 2)

   Q6> Router R5 queries for all routers supporting BGP inside of the
       same AS, detects R2 and R3 and concludes to

        *  not build an I-BGP connection to R2 since R5 is a reflector
           client and R2 is a non-client

        *  to build an I-BGP connection to R3 since R3 is the reflector
           for the same cluster R5 is client of

   The resulting peerings are visualized in Figure 2.  Based on the
   configuration of BGP properties the network automatically set up
   valid and necessary connections between routers.  It should be
   obvious that especially for I-BGP such a mechanism faciliates the
   maintainance of many routers inside of an AS. The necessary route
   reflector and mesh connections for BGP are built correctly.  A
   carefull reader observes as well that the automatically formed full
   set of E-BGP connections between AS border routers is not always a
   good thing.  This problem will be given some special consideration.

   The intended auto-configuration behavior when registering and
   retrieving information can be split across the internal and external
   BGP functionality boundary.  Since I-BGP requires a full mesh
   configuration  (2) Proxy PAR information proves very beneficial to
   meet this necessary constraint in an automatic manner.  For E-BGP, as
   mentioned above, a full mesh between all peers on the same subnet is
   not always a good solution and therefore Proxy PAR information has to
   be treated more carefully or not used at all.

___________________________________________
2. with exceptions in presence of route reflectors, of course

Przygienda                 Expires 25 May 1998                  [Page 8]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

2.2. BGP Configuration Interaction with Proxy PAR

   To resolve problems with multiple IP subnets operating on top of a
   single ATM NSAP, multiple BGP instances, and possibly even multiple
   ATM clouds the router attaches to, router configuration has to define
   what information is feasible to be registered.  As default, any
   new upcoming IP interface running on top of an ATM link should be
   registered with the server on one of the ATM links interfacing with
   the same ATM cloud.  The necessary IP instance is determined by
   the BGP instance and the NSAP is equivalent to the NSAP of the ATM
   interface through which the registration is performed.

2.2.1. Registration of Information for Autoconfiguration of External BGP
   Peerings

   An implicit assumption when using Proxy PAR for autoconfiguration of
   BGP external peerings is that multihop peers are not supported.  A
   BGP router with an IP over ATM interface that attaches to a subnet
   between different AS'es registers the interface for the according IP
   instance with one of the proxy PAR servers on the same cloud.  It is
   possible, although not necessary, to omit multiple registrations in
   the case of a BGP router having multiple interfaces to the same IP
   subnet with broadcast capabilities.

2.2.2. Registration of Information for Autoconfiguration of Internal BGP
   Peerings

   For the IP over ATM interfaces on subnets being entirely inside of
   the router's AS, BGP instances should register with proxy PAR server.
   This allows for necessary sessions to be formed and consecutively
   provides full mesh connectivity between non-clients, and star
   connectivity inside route reflector clusters.  Same optimizations as
   described in section 2.2.1 are possible.

2.3. Proxy PAR Interaction with BGP Configuration

2.3.1. Autoconfiguration of Internal BGP Peerings

   Proxy PAR presence in a BGP network 'on the internal side' is helping
   to meet the requirement that all I-BGP peers have to be connected as
   full-mesh or connect to their route reflectors.  To make sure that

Przygienda                 Expires 25 May 1998                  [Page 9]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

   all route reflector clients and non-clients are configured correctly,
   Proxy PAR queries will present enough information to let the routers
   configure a minimal valid connectivity graph.  After being provided
   with the information about all BGP peers running in the same AS, a
   BGP router determines which peers it must initiate connections to
   based on the following criteria:

    -  looking at the other router's BGP identifier no session has been
       formed yet and

    -  the other router is in the same AS and

        *  one router is route reflector with the same cluster ID and
           the other router is a client of this cluster or

        *  one of the routers is a non-client

   The example in section 2.1 encompasses the different cases that can
   trigger initiation of connections.

2.3.2. Autoconfiguration of external BGP peerings

   Proxy PAR registration information made available can be used to
   determine which BGP routers are present to form sessions with.
   Normally, all routers on a specific DMZ subnet are interested in
   forming relationships with routers in different ASes to exchange
   route information.  However, to prevent unnecessary or insecure
   external sessions, each of the IP interfaces on a subnet reaching
   into other AS'es can filter information from query results based
   on any of the fields or combinations thereof.  The filter would
   prevent BGP from autodetecting the registration and effectively the
   possible neighbor.  Since the connection could be initiated from
   either side, the filters should be symmetrical in both BGP peers that
   try to prevent that session from forming.  If this is unenforcable,
   a peer accepting an E-BGP connection for which Proxy PAR information
   is filtered, could explicitly close it after providing appropriate
   notification.

2.4. IP to ATM Address Resolution

   Given the nature of Proxy PAR registrations that contain not only
   BGP specific information but always carry IP interface address and

Przygienda                 Expires 25 May 1998                 [Page 10]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

   the attached NSAP, when running BGP over IP interfaces on top of ATM
   with Proxy PAR capabilities, the information obtained in queries can
   be used to provide address resolution for the lower layers.  When
   BGP chooses to initiate a connection to a peer, lower layers of the
   TCP/IP protocol stack could use the available Proxy PAR information
   to resolve the IP address into the necessary NSAP of the registration
   point.  Such a solution however necessitates an appropriate stack
   architecture.

3. Acknowledgments

   Comments and contributions from several sources, especially Rob
   Coltun are included in this work.

4. Security Consideration

   Security issues in the context of BGP autoconfiguration in presence
   of Proxy PAR can be split into parts specific to either of the
   protocols.  BGP protocol addresses the issues in existing RFCs
   and ongoing work.  PNNI protocol in version 2 contains peer
   authentication mechanisms and Proxy PAR in itself could be extended
   to encompass the same security features in the future.  To address
   the problem of security of Proxy PAR client/server interactions,
   especially registrations that could be used for denial-of-service
   attacks is an issue not addressed so far.  Its scope is similar to
   the problem of a secure ILMI [AF96a].

5. Conclusions

   This RFC specifes for BGP implementors and users mechanisms
   describing how the protocol operates in ATM networks over PVC and
   SVC meshes with the presence of Proxy PAR. These recommendations
   do not require any protocol changes and allow for simpler, more
   efficient and cost- effective network designs.  Proxy PAR can help
   to distribute configuration changes when BGP capable routers are
   reconfigured on the ATM cloud and greatly facilitates consistence of
   I-BGP meshes and can be used for E-BGP auto-configuration as well.

Przygienda                 Expires 25 May 1998                 [Page 11]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

References

   [AF95]  ATM-Forum.  LAN Emulation over ATM 1.0.  ATM Forum
           af-lane-0021.000, January 1995.

   [AF96a] ATM-Forum.  Interim Local Management Interface (ILMI)
           Specification 4.0.  ATM Forum 95-0417R8, June 1996.

   [AF96b] ATM-Forum.  Private Network-Network Interface Specification
           Version 1.0.  ATM Forum af-pnni-0055.000, March 1996.

   [Arm96] G. Armitage.  Support for Multicast over UNI 3.0/3.1 based
           ATM Networks, RFC 2022.  Internet Engineering Task Force,
           November 1996.

   [Bat96] T. Bates.  BGP Route Reflection, RFC 1966.  Internet
           Engineering Task Force, June 1996.

   [Ca96]  R. Callon and al.  An Overview of PNNI Augmented Routing.
           ATM Forum 96-0354, April 1996.

   [CH97a] R. Coltun and J. Heinanen.  Opaque LSA in OSPF.  Internet
           Draft, 1997.

   [CH97b] R. Coltun and J. Heinanen.  The OSPF Address Resolution
           Advertisement Option.  Internet Draft, 1997.

   [CPS96] R. Coltun, T. Przygienda, and S. Shew.  MIPAR: Minimal PNNI
           Augmented Routing.  ATM Forum 96-0838, June 1996.

   [Dav97] M. Davison.  Simple ILMI-Based Server Discovery.  Internet
           Draft, 1997.

   [Lau94] M. Laubach.  Classical IP and ARP over ATM, RFC 1577.
           Internet Engineering Task Force, January 1994.

   [PD97a] T. Przygienda and P. Droz.  Proxy PAR.  ATM Forum 97-0495,
           97-0705, 97-0882, July 1997.

   [PD97b] T. Przygienda and P. Droz.  Proxy PAR.  Internet Draft, 1997.

   [RL95]  Y. Rekhter and T. Li.  A Border Gateway Protocol 4 (BGP-4),
           RFC 1771.  Internet Engineering Task Force, March 1995.

Przygienda                 Expires 25 May 1998                 [Page 12]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

   [RL97]  Y. Rekhter and T. Li.  A Border Gateway Protocol 4 (BGP-4).
           Internet Draft, 1997.

Authors' Addresses

Tony Przygienda
Bell Labs, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
[email-masked]

Przygienda                 Expires 25 May 1998                 [Page 13]

--------------56AA7FF1EEE82EE6BBFA66D1--

Date: Fri, 28 Nov 1997 09:43:51 -0500
From: Antoni Przygienda <[email-masked]>
Organization: Bell Labs, Lucent
To: [email-masked]
CC: [email-masked]
Subject: [Fwd: new draft  BGP-4 over ATM and Proxy PAR<draft-przygienda-bgp4-atm-00.txt>]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------050E607B595E026A23014C2D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

--------------050E607B595E026A23014C2D
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Message-ID: <[email-masked]>
Date: Wed, 19 Nov 1997 16:15:38 -0500
From: Antoni Przygienda <[email-masked]>
Organization: Bell Labs, Lucent Technologies
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.30 i586)
MIME-Version: 1.0
To: "[email-masked]" <[email-masked]>
Subject: new draft  BGP-4 over ATM and Proxy PAR
	                   <draft-przygienda-bgp4-atm-00.txt>

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

new draft draft-przygienda-bgp4-atm-00.txt

thank you for processing.

                                                        --- tony

Internet Engineering Task Force                            T. Przygienda
INTERNET DRAFT                            Bell Labs, Lucent Technologies
                                                        19 November 1997

                      BGP-4 over ATM and Proxy PAR
                   <draft-przygienda-bgp4-atm-00.txt>

Status of This Memo

   This document is an Internet Draft, and can be found as
   draft-przygienda-bgp4-atm-00.txt in any standard internet drafts
   repository.  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.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material, or to cite them other than as a
   ``working draft'' or ``work in progress.''

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.

Abstract

   This draft specifes for BGP-4 implementors and users mechanisms
   describing how the protocol operates in ATM networks over PVC and
   SVC meshes with the presence of Proxy PAR. These recommendations
   do not require any protocol changes and allow for simpler, more
   efficient and cost-effective network designs.  Proxy PAR can help to
   distribute changes of peer relationships when BGP-4 capable routers
   are reconfigured on the ATM cloud.

Przygienda                 Expires 25 May 1998                  [Page 1]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

1. Introduction

1.1. Introduction to Proxy PAR

   Proxy PAR [CPS96, PD97a] is an extension allowing for different ATM
   attached devices to interact with PAR capable switches and obtain
   information about non-ATM services without executing PAR [Ca96]
   which is an extension of PNNI [AF96b] themselves.  The client side
   is much simpler in terms of implementation complexity and memory
   requirements than a complete PAR protocol stack and should allow for
   easy implementation in e.g.  existing IP routers.  Additionally,
   clients can use Proxy PAR to register different non-ATM services and
   protocols they support.  Proxy PAR has consciously not been included
   as part of ILMI due to the complexity of PAR information passed in
   the protocol and the fact that it is intended for integration of
   non-ATM protocols and services only.  A device executing Proxy PAR
   does not necessarily need to execute ILMI or UNI signaling although
   this normally will be the case.  The context or reference model is
   aligned with the one included in ILMI [AF96a].

   The protocol in itself does not specify how the distributed service
   registration and data delivered to the client is supposed to be
   driving other protocols so e.g.  OSPF routers finding themselves
   through proxy PAR could use this information in RFC1577 [Lau94]
   fashion, forming a full mesh of point-to-point connections to
   interact with each other to simulate broadcast interfaces.  For the
   same purpose LANE [AF95] or MARS [Arm96] could be used.

   As a by-product, Proxy PAR could provide the ATM address resolution
   for IP attached devices but such resolution can be achieved by other
   protocols under specification in IETF as well, e.g.  [CH97a, CH97b].
   And last but not least, it should be mentioned here that the
   protocol coexists with and complements the ongoing work in IETF
   on server detection via ILMI extensions [Dav97] and opaque LSAs
   [CH97a, CH97b].

1.1.1. Proxy PAR Scopes

   Any Proxy PAR registration is carried only within a defined scope
   that is set during registration and is equivalent to the PNNI routing
   level.  Since no assumptions except scope values can be made about
   the information distributed (e.g.  IP addresses bound to NSAPs
   are not assumed to be aligned with them in any respect such as

Przygienda                 Expires 25 May 1998                  [Page 2]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

   encapsulation or functional mapping), registration information cannot
   be summarized.  This makes a careful handling of scopes necessary to
   preserve the scalability.  More detailed comments on these issues and
   optimizations possible when logical IP topology aligns with aspects
   of ATM topology can be found in [PD97b].

1.2. Introduction to BGP

   Border Gateway Protocol (BGP) is an Exterior Gateway Protocol (EGP)
   and described in [RL95, RL97] from which most of the following
   paragraphs have been taken almost literally.

   The primary function of a BGP speaking system is to exchange
   network reachability information with other BGP systems.  This
   network reachability information includes information on the
   list of Autonomous Systems (ASs) that reachability information
   traverses.  This information is sufficient to construct a graph of AS
   connectivity from which routing loops may be pruned and some policy
   decisions at the AS level may be enforced.

   BGP runs over a reliable transport protocol.  This eliminates the
   need to implement explicit update fragmentation, retransmission,
   acknowledgment, and sequencing.  Any authentication scheme used
   by the transport protocol may be used in addition to BGP's own
   authentication mechanisms.  The error notification mechanism used
   in BGP assumes that the transport protocol supports a "graceful"
   close, i.e., that all outstanding data will be delivered before the
   connection is closed.

   BGP deployments are normally configured such that that all BGP
   speakers within a single AS must be fully meshed so that any external
   routing information must be re-distributed to all other routers
   within that AS. This represents a serious scaling problem that
   has been well documented with several alternatives proposed.  The
   alternative supported in Proxy PAR are route reflectors [Bat96] due
   to their simplicity, easy migration and compatibility with existing
   BGP configurations.

Przygienda                 Expires 25 May 1998                  [Page 3]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

2. BGP over ATM

2.1. Model

   The model used for BGP operation over ATM in connection with
   Proxy PAR assumes that not only pre-configured peers exist but
   neighbor relationships can be formed dynamically based on discovery
   mechanisms.  Such a discovery must be provided by an underlying
   layer since BGP does not include peer auto-detection that would be
   comparable with e.g.  OSPF's hellos used to find all OSPF routers on
   a specific subnet.  To fulfill this purpose, Proxy PAR allows BGP to
   register and query the following data with the server:

    -  ATM address

    -  IP instance

    -  IP address

    -  IP mask

    -  BGP Identifier

    -  route reflector type as one of:

        *  reflector of a certain cluster or

        *  client of a certain cluster or

        *  non-client

   The motivation of such a model is to allow for a simpler maintainance
   of BGP router configuration when some router interfaces are connected
   over ATM. As an example, full mesh connectivity on a specific
   subnet does not require the configuration of peer relationsships in
   routersa priori but a router can register as providing BGP services
   on an interface and his possible peers discover it through Proxy
   PAR queries.  Figure 1 illustrates a possible BGP scenario with
   several cases of relationsships based on the following Proxy PAR
   registrations:

    -  Router R1 is configured to be BGP capable and has the interface

        *  1.1.1.1 reaching into DMZ subnet 1.1.1/255.255.255

Przygienda                 Expires 25 May 1998                  [Page 4]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

                               +--+
                               |R1|
                               +--+
                        1.1.1.1 | register BGP for
                                | AS101, BGP Id 1.1.1.1, no route
                                | reflector
                                |
        ======================= | ========================== AS101
         1.1.1/255.255.255.0    |
       +--------------+---------+-------------+------+ DMZ
                      |                       |
        ============= | ===================== | ============ AS100
                      |                       |
                      | 1.1.1.3               | 1.1.1.2
                      |                       |
                    +--+                     +--+
                    |R2| registers BGP for   |R3| registers BGP for
                    |  | AS100, Id 1.1.1.3,  |  | AS100, Id 1.1.1.2,
                    +--+ non-client          +--+ RR for cluster 4
                      |                       |
                      | 1.1.2.3               | 1.1.2.2
                      |                       |
       +---+----------+-----------------------+-----------+
           |                1.1.2/255.255.255.0
           |
           | 1.1.2.1     +
          +--+           |
          |R4|-----------+
          +--+ 1.1.3.1   |   1.1.3.2 +--+ registers BGP for AS100,
                         +-----------|R5| Id 1.1.2.1,
                         |           +--+ RR client cluster 4
                         +

Figure 1:  Logical IP Topology with Proxy PAR Registrations (Single ATM
                                network)

    -  Router R3 is configured to be BGP capable, is route reflector for
       cluster id 4, and has the interfaces

        *  1.1.1.2 reaching into DMZ subnet 1.1.1/255.255.255 and

        *  1.1.2.2 to the subnet 1.1.2/255.255.255 inside its AS

Przygienda                 Expires 25 May 1998                  [Page 5]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

    -  Router R2 is configured to be BGP capable and has the interfaces

        *  1.1.1.3 reaching into DMZ subnet 1.1.1/255.255.255 and

        *  1.1.2.3 to the subnet 1.1.2/255.255.255 inside its AS

    -  Router R5 is configured to be BGP capable, is a client of route
       reflector cluster id 4, and has the interface

        *  1.1.2.1 to a subnet 1.1.2/255.255.255 inside its AS

   It has to be stated here that the model assumes that E-BGP-multihop
   will not be supported through auto-configuration.  Based on such an
   assumption, the following queries are generated by the routers and
   conclusions drawn concerning the BGP sessions to be formed:

   Q1> Router R1 queries for all BGP capable routers on the DMZ
       subnet (1) and discovers R2 and R3 supporting interfaces 1.1.1.3
       and 1.1.1.2 and being in a different AS. Router R1 concludes to

        *  build a E-BGP connection to router R3 (shown with &'s in
           Figure 2)

        *  build a EBPG connection to router R2 (shown with #'s in
           Figure 2)

   Q2> Router R2 queries for all BGP capable routers on the DMZ subnet
       and discovers R3 and R1 on the same subnet and concludes to

        *  build a E-BGP connection to router R1 since it is in a
           different AS

        *  not to build a E-BGP connection to router R3 since it is in
           the same AS

   Q3> Router R3 issues a symmetric query to Q2 and comes to conclusions
       analogous to Q2>

   Q4> Router R2 queries for all routers supporting BGP inside of the
       same AS, detects R3 and R5 and concludes to

___________________________________________
1. since one of its interfaces is on this subnet

Przygienda                 Expires 25 May 1998                  [Page 6]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

                               +--+
                               |R1|
                               +--+
                        1.1.1.1 #&
                                #&
                                #&
                                #&
        ======================= #& ========================= AS101
                                #&
       +--------------###########&&&&&&&&&&&&&&------+ DMZ
                      #                       &
        ============= # ===================== & ============ AS100
                      #                       &
                      # 1.1.1.3               & 1.1.1.2
                      #                       &
                    +--+                     +--+
                    |R2|                     |R3|
                    |  |                     |  |
                    +--+                     +--+
                      %                       %@
                      % 1.1.2.3               %@ 1.1.2.2
                      %                       %@
                      %                       %@
       +--------------%%%%%%%%%%%%%%%%%%%%%%%%%@----------+
                      @@@@@@@@@@@@@@@@@@@@@@@@@@
                      @
                      @            +
                    +-@@           |
                    |R4@@@@@@@@@@@@@
                    +--+           @   1.1.3.2 +--+
                                   @@@@@@@@@@@@|R5|
                                   +           +--+

  Figure 2:  Active BGP Connections after Auto-Discovery in Figure 1.

        *  build an I-BGP connection to R3 since R3 is a reflector and
           R2 is a non-client (shown with %'s in Figure 2)

        *  not build an I-BGP connection to R5 since R5 is a client of a
           route reflector

Przygienda                 Expires 25 May 1998                  [Page 7]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

   Q5> Router R3 queries for all routers supporting BGP inside of the
       same AS, detects R2 and R5 and concludes to

        *  build an I-BGP connection to R2 since R3 is a reflector and
           R2 is a non-client

        *  build an I-BGP connection to R5 since R5 is a client of the
           route reflector for the same cluster (shown with @'s in
           Figure 2)

   Q6> Router R5 queries for all routers supporting BGP inside of the
       same AS, detects R2 and R3 and concludes to

        *  not build an I-BGP connection to R2 since R5 is a reflector
           client and R2 is a non-client

        *  to build an I-BGP connection to R3 since R3 is the reflector
           for the same cluster R5 is client of

   The resulting peerings are visualized in Figure 2.  Based on the
   configuration of BGP properties the network automatically set up
   valid and necessary connections between routers.  It should be
   obvious that especially for I-BGP such a mechanism faciliates the
   maintainance of many routers inside of an AS. The necessary route
   reflector and mesh connections for BGP are built correctly.  A
   carefull reader observes as well that the automatically formed full
   set of E-BGP connections between AS border routers is not always a
   good thing.  This problem will be given some special consideration.

   The intended auto-configuration behavior when registering and
   retrieving information can be split across the internal and external
   BGP functionality boundary.  Since I-BGP requires a full mesh
   configuration  (2) Proxy PAR information proves very beneficial to
   meet this necessary constraint in an automatic manner.  For E-BGP, as
   mentioned above, a full mesh between all peers on the same subnet is
   not always a good solution and therefore Proxy PAR information has to
   be treated more carefully or not used at all.

___________________________________________
2. with exceptions in presence of route reflectors, of course

Przygienda                 Expires 25 May 1998                  [Page 8]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

2.2. BGP Configuration Interaction with Proxy PAR

   To resolve problems with multiple IP subnets operating on top of a
   single ATM NSAP, multiple BGP instances, and possibly even multiple
   ATM clouds the router attaches to, router configuration has to define
   what information is feasible to be registered.  As default, any
   new upcoming IP interface running on top of an ATM link should be
   registered with the server on one of the ATM links interfacing with
   the same ATM cloud.  The necessary IP instance is determined by
   the BGP instance and the NSAP is equivalent to the NSAP of the ATM
   interface through which the registration is performed.

2.2.1. Registration of Information for Autoconfiguration of External BGP
   Peerings

   An implicit assumption when using Proxy PAR for autoconfiguration of
   BGP external peerings is that multihop peers are not supported.  A
   BGP router with an IP over ATM interface that attaches to a subnet
   between different AS'es registers the interface for the according IP
   instance with one of the proxy PAR servers on the same cloud.  It is
   possible, although not necessary, to omit multiple registrations in
   the case of a BGP router having multiple interfaces to the same IP
   subnet with broadcast capabilities.

2.2.2. Registration of Information for Autoconfiguration of Internal BGP
   Peerings

   For the IP over ATM interfaces on subnets being entirely inside of
   the router's AS, BGP instances should register with proxy PAR server.
   This allows for necessary sessions to be formed and consecutively
   provides full mesh connectivity between non-clients, and star
   connectivity inside route reflector clusters.  Same optimizations as
   described in section 2.2.1 are possible.

2.3. Proxy PAR Interaction with BGP Configuration

2.3.1. Autoconfiguration of Internal BGP Peerings

   Proxy PAR presence in a BGP network 'on the internal side' is helping
   to meet the requirement that all I-BGP peers have to be connected as
   full-mesh or connect to their route reflectors.  To make sure that

Przygienda                 Expires 25 May 1998                  [Page 9]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

   all route reflector clients and non-clients are configured correctly,
   Proxy PAR queries will present enough information to let the routers
   configure a minimal valid connectivity graph.  After being provided
   with the information about all BGP peers running in the same AS, a
   BGP router determines which peers it must initiate connections to
   based on the following criteria:

    -  looking at the other router's BGP identifier no session has been
       formed yet and

    -  the other router is in the same AS and

        *  one router is route reflector with the same cluster ID and
           the other router is a client of this cluster or

        *  one of the routers is a non-client

   The example in section 2.1 encompasses the different cases that can
   trigger initiation of connections.

2.3.2. Autoconfiguration of external BGP peerings

   Proxy PAR registration information made available can be used to
   determine which BGP routers are present to form sessions with.
   Normally, all routers on a specific DMZ subnet are interested in
   forming relationships with routers in different ASes to exchange
   route information.  However, to prevent unnecessary or insecure
   external sessions, each of the IP interfaces on a subnet reaching
   into other AS'es can filter information from query results based
   on any of the fields or combinations thereof.  The filter would
   prevent BGP from autodetecting the registration and effectively the
   possible neighbor.  Since the connection could be initiated from
   either side, the filters should be symmetrical in both BGP peers that
   try to prevent that session from forming.  If this is unenforcable,
   a peer accepting an E-BGP connection for which Proxy PAR information
   is filtered, could explicitly close it after providing appropriate
   notification.

2.4. IP to ATM Address Resolution

   Given the nature of Proxy PAR registrations that contain not only
   BGP specific information but always carry IP interface address and

Przygienda                 Expires 25 May 1998                 [Page 10]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

   the attached NSAP, when running BGP over IP interfaces on top of ATM
   with Proxy PAR capabilities, the information obtained in queries can
   be used to provide address resolution for the lower layers.  When
   BGP chooses to initiate a connection to a peer, lower layers of the
   TCP/IP protocol stack could use the available Proxy PAR information
   to resolve the IP address into the necessary NSAP of the registration
   point.  Such a solution however necessitates an appropriate stack
   architecture.

3. Acknowledgments

   Comments and contributions from several sources, especially Rob
   Coltun are included in this work.

4. Security Consideration

   Security issues in the context of BGP autoconfiguration in presence
   of Proxy PAR can be split into parts specific to either of the
   protocols.  BGP protocol addresses the issues in existing RFCs
   and ongoing work.  PNNI protocol in version 2 contains peer
   authentication mechanisms and Proxy PAR in itself could be extended
   to encompass the same security features in the future.  To address
   the problem of security of Proxy PAR client/server interactions,
   especially registrations that could be used for denial-of-service
   attacks is an issue not addressed so far.  Its scope is similar to
   the problem of a secure ILMI [AF96a].

5. Conclusions

   This RFC specifes for BGP implementors and users mechanisms
   describing how the protocol operates in ATM networks over PVC and
   SVC meshes with the presence of Proxy PAR. These recommendations
   do not require any protocol changes and allow for simpler, more
   efficient and cost- effective network designs.  Proxy PAR can help
   to distribute configuration changes when BGP capable routers are
   reconfigured on the ATM cloud and greatly facilitates consistence of
   I-BGP meshes and can be used for E-BGP auto-configuration as well.

Przygienda                 Expires 25 May 1998                 [Page 11]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

References

   [AF95]  ATM-Forum.  LAN Emulation over ATM 1.0.  ATM Forum
           af-lane-0021.000, January 1995.

   [AF96a] ATM-Forum.  Interim Local Management Interface (ILMI)
           Specification 4.0.  ATM Forum 95-0417R8, June 1996.

   [AF96b] ATM-Forum.  Private Network-Network Interface Specification
           Version 1.0.  ATM Forum af-pnni-0055.000, March 1996.

   [Arm96] G. Armitage.  Support for Multicast over UNI 3.0/3.1 based
           ATM Networks, RFC 2022.  Internet Engineering Task Force,
           November 1996.

   [Bat96] T. Bates.  BGP Route Reflection, RFC 1966.  Internet
           Engineering Task Force, June 1996.

   [Ca96]  R. Callon and al.  An Overview of PNNI Augmented Routing.
           ATM Forum 96-0354, April 1996.

   [CH97a] R. Coltun and J. Heinanen.  Opaque LSA in OSPF.  Internet
           Draft, 1997.

   [CH97b] R. Coltun and J. Heinanen.  The OSPF Address Resolution
           Advertisement Option.  Internet Draft, 1997.

   [CPS96] R. Coltun, T. Przygienda, and S. Shew.  MIPAR: Minimal PNNI
           Augmented Routing.  ATM Forum 96-0838, June 1996.

   [Dav97] M. Davison.  Simple ILMI-Based Server Discovery.  Internet
           Draft, 1997.

   [Lau94] M. Laubach.  Classical IP and ARP over ATM, RFC 1577.
           Internet Engineering Task Force, January 1994.

   [PD97a] T. Przygienda and P. Droz.  Proxy PAR.  ATM Forum 97-0495,
           97-0705, 97-0882, July 1997.

   [PD97b] T. Przygienda and P. Droz.  Proxy PAR.  Internet Draft, 1997.

   [RL95]  Y. Rekhter and T. Li.  A Border Gateway Protocol 4 (BGP-4),
           RFC 1771.  Internet Engineering Task Force, March 1995.

Przygienda                 Expires 25 May 1998                 [Page 12]

Internet Draft       BGP-4 over ATM and Proxy PAR       19 November 1997

   [RL97]  Y. Rekhter and T. Li.  A Border Gateway Protocol 4 (BGP-4).
           Internet Draft, 1997.

Authors' Addresses

Tony Przygienda
Bell Labs, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
[email-masked]

Przygienda                 Expires 25 May 1998                 [Page 13]

--------------050E607B595E026A23014C2D--

Date: Fri, 28 Nov 1997 09:43:02 -0500
From: Antoni Przygienda <[email-masked]>
Organization: Bell Labs, Lucent
To: [email-masked]
CC: [email-masked]
Subject: [Fwd: new draft   BGP-4 MD5 Authentication<draft-przygienda-bgp-md5-00.txt>]
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------521AAEE7A3B2AD860D695146
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

--------------521AAEE7A3B2AD860D695146
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Message-ID: <[email-masked]>
Date: Wed, 19 Nov 1997 16:10:54 -0500
From: Antoni Przygienda <[email-masked]>
Organization: Bell Labs, Lucent Technologies
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.30 i586)
MIME-Version: 1.0
To: [email-masked]
Subject: new draft   BGP-4 MD5 Authentication
	                   <draft-przygienda-bgp-md5-00.txt>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

new draft draft-przygienda-bgp-md5-00.txt or IETF 

thank you for processing.

							--- tony

Internet Engineering Task Force                            T. Przygienda
INTERNET DRAFT                            Bell Labs, Lucent Technologies
                                                         5 November 1997

                        BGP-4 MD5 Authentication
                   <draft-przygienda-bgp-md5-00.txt>

Status of This Memo

   This document is an Internet Draft, and can be found as
   draft-przygienda-bgp-md5-00.txt in any standard internet drafts
   repository.  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.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material, or to cite them other than as a
   ``working draft'' or ``work in progress.''

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.

Abstract

   This memo describes MD5 authentication scheme for BGP-4 routing
   protocol analogous to the one proposed for SNMP Version 2 and RIP-2.
   The mechanism provides greatly enhanced probability for a system
   attacked to detect and ignore messages received.  A sequence number
   improves additionally the resistance against replay attacks.

1. Use of Imperatives

   Throughout this document, the words that are used to define the
   significance of particular requirements are capitalized.  These words
   are:

Przygienda                 Expires 10 May 1998                  [Page 1]

    Internet Draft         BGP-4 MD5 Authentication          5 November
1997

      MUST This word or the adjective "REQUIRED" means that the item is
an
           absolute requirement of this specification.

  MUST NOT This phrase means that the item is an absolute prohibition of
           this specification.

    SHOULD This word or the adjective "RECOMMENDED" means that there may
           exist valid reasons in particular circumstances to ignore
this
           item, but the full implications should be understood and the
case
           carefully weighed before choosing a different course.

SHOULD NOT This phrase means that there may exist valid reasons in
           particular circumstances when the listed behavior is
acceptable
           or even useful, but the full implications should be
understood
           and the case carefully weighed before implementing any
behavior
           described with this label.

       MAY This word or the adjective "OPTIONAL" means that this item is
           truly optional.  One vendor may choose to include the item
           because a particular marketplace requires it or because it
           enhances the product, for example; another vendor may omit
the
           same item.

    2. Introduction

       Recent developments in the Internet has introduced a stronger
       need for improved authentication of routing information.  RIP-2
       and OSPF provide originally for unauthenticated service and
       clear-text password authentication.  Both are not sufficient to
       withstand attacks currently widespread in the Internet.  In case
       of disabled authentication only misconfiguration can be detected
       and clear password protections can be intercepted easily by an
       hostile attacker.  Recently, both OSPF [Moy97] and RIP-2 [BA97]
(1)
       added additional mechanisms using well-known MD-5 signature
       algorithms [Riv92] that is considered to be secure and fast
enough
       for protection of routing protocol data units [Tou95].  BGP-4
       [RL95, RL97] contains already authentication information marker
       in the message header that can be used for a MD5 signature.  Its
       fixed length however prevents a more generic approach using keyed

    ___________________________________________
    1. on which large parts of this document are based

    Przygienda                 Expires 10 May 1998                 
[Page 2]

Internet Draft         BGP-4 MD5 Authentication          5 November 1997

   algorithms generating more than 128 bits long signatures without
   redefining its meaning.

   This memo proposes an authentication algorithm, as was originally
   proposed for SNMP Version 2, augmented by a sequence number.  Keyed
   MD5 is chosen here as the authentication algorithm for BGP-4.
   This mechanism will provide a greatly enhanced probability that a
   system being attacked will detect and ignore hostile information.
   This property derives from the fact that only the output of an
   authentication algorithm (e.g., Keyed MD5) rather than the secret
   Authentication Key is transmited.  This output is a one-way
   function of a message and a secret Authentication Key.  Again, the
   Authentication Key is never sent over the network unencrypted,
   therefore providing protection against passive attacks.

   Protection against forgery or message modification is inherent to
   this scheme.  A sequence number is provided that makes a replay
   attack much harder.  It is possible to replay a message until
   the sequence number changes.  The mechanism does not provide
   confidentiality.  The messages are not encrypted.  Such a protection
   is provided in other protocols such as PNNIv2 [AF97] or IETF's recent
   work [Atk95] and could be considered in the future.

   Keyed MD5 is being used for OSPF cryptographic authentication
   [Moy97], and is therefore present in routers already, as is some form
   of password management.

3. Method Description

   The method requires three issues to be addressed:

    1. Changed packet formats,

    2. Authentication procedures, and

    3. Management controls.

3.1. OPEN Message Extensions

   The OPEN message in BGP-4 specifies an optional parameter that
   is specifically reserved for authentication purposes.  For MD-5
   purposes the authentication code with value 1 MAY be used by an

Przygienda                 Expires 10 May 1998                  [Page 3]

Internet Draft         BGP-4 MD5 Authentication          5 November 1997

   implementation.  In case this authentication code is used, the OPEN
   message contains the parameter and it MUST be formatted the following
   way:

        0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+
       |  Auth. Code   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | reserved 0                                                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The meaning of fields specified reads as:

    1. The "Authentication Code" is Keyed Message Digest Algorithm,
       indicated by the value 1.

   All other octets are reserved and MUST be set to 0.

3.2. Message Header Format

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Auth. Type     |                  0x000000                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Auth Data Len   |                  0x000000                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Sequence Number                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Key ID       |                  0x000000                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Length               |      Type     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The message header format for the OPEN and subsequent UPDATE and
   KEEPALIVE messages MUST have the marker formatted in the following
   way:

Przygienda                 Expires 10 May 1998                  [Page 4]

Internet Draft         BGP-4 MD5 Authentication          5 November 1997

    1. The "Authentication Type" is Keyed Message Digest Algorithm,
       indicated by the value 1.

    2. An unsigned 8-bit field that contains the length in octets of the
       trailing Authentication Data field.  The presence of this field
       permits other algorithms (e.g., Keyed SHA) to be substituted for
       Keyed MD5 if desired.

    3. An unsigned 32 bit sequence number.  The sequence number MUST be
       non-decreasing for all messages sent with the same Key ID.

    4. An unsigned 8-bit field that contains the Key Identifier or
       Key-ID. This identifies the key used to create the Authentication
       Data for this BGP-4 message.  In implementations supporting more
       than one authentication algorithm, the Key-ID also indicates
       the authentication algorithm in use for this message.  A key is
       associated with a session.

   The trailer consists of the Authentication Data, which is the output
   of the Keyed Message Digest Algorithm.  When the Authentication
   Algorithm is Keyed MD5, the output data is 16 bytes; during digest
   calculation, this is effectively followed by a pad field and a length
   field as defined by [Riv92].

3.3. UPDATE and KEEPALIVE Message Trailer

   The OPEN and all subsequent UPDATE and KEEPALIVE messages MUST be
   trailed after length padded to 32-bit boundary with the indicated
   length of authentication data.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  BGP Header
      +  ...............
      |  BGP Data
      +  ...............
      |  Padding to 32-bit boundary with reserved 0 octets
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      +  0xFFFF                         |  0x0001                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /  Authentication Data (var. length; 16 bytes with Keyed MD5)   /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Przygienda                 Expires 10 May 1998                  [Page 5]

Internet Draft         BGP-4 MD5 Authentication          5 November 1997

   In memory, the following trailer is appended by the MD5 algorithm and
   treated as though it were part of the message.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              sixteen octets of MD5 "secret"                   |
   /                                                               /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | zero or more pad bytes (defined by RFC 1321 when MD5 is used) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        64 bit message length MSW              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        64 bit message length LSW              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.4. Message Generation

   The BGP-4 packet is created as usual, except that the marker is set
   to contain the authentication type (1), the authentication data
   length, the sequence number and the Key Identifier.

   The value used in the sequence number is arbitrary, but two
   suggestions are the time of the message's creation or a simple
   message counter.

   The BGP-4 Authentication Key is selected by the sender based on the
   session.  Each key has a lifetime associated with it.  No key is ever
   used outside its lifetime.

    1. The BGP-4 header's packet length field indicates the standard
       BGP-4 portion of the packet.

    2. The Authentication Data Offset, Key Identifier, and
       Authentication Data size fields are filled in appropriately.

    3. The BGP-4 Authentication Key, which is 16 bytes long when the
       Keyed MD5 algorithm is used, is now appended to the data.  For
       all algorithms, the BGP-4 Authentication Key is never longer than
       the output of the algorithm in use.

Przygienda                 Expires 10 May 1998                  [Page 6]

Internet Draft         BGP-4 MD5 Authentication          5 November 1997

    4. Trailing pad and length fields are added and the digest
       calculated using the indicated algorithm.  When Keyed MD5 is the
       algorithm in use, these are calculated per [Riv92].

    5. The digest is written over the BGP-4 Authentication Key.  When
       MD5 is used, this digest will be 16 bytes long.

   The trailing pad is not actually transmitted, as it is entirely
   predictable from the message length and algorithm in use.

3.5. Message Reception

   When the message is received, the process is reversed:

    1. The digest is set aside,

    2. The appropriate algorithm and key are determined from the value
       of the Key Identifier field,

    3. The BGP-4 Authentication Key is written into the appropriate
       number (16 when Keyed MD5 is used) of bytes starting at the
       offset indicated,

    4. Appropriate padding is added as needed, and

    5. A new digest calculated using the indicated algorithm.

   If the calculated digest does not match the received digest,
   the message is discarded and appropriate Authentication failed
   NOTIFICATION sent.  The connection is closed subsequently.

   If the sequence number is not zero and smaller than the last received
   one, the message is discarded and appropriate Authentication failed
   NOTIFICATION sent.  The connection is closed subsequently.

   A router that has forgotten its current sequence number but remembers
   its key and Key-ID MUST send its next packet with a sequence number
   of zero.  This leaves a small opening for a replay attack although
   appropriate procedures can be provided by an implementation to report
   excessive zero key usage.  Router vendors are encouraged to provide
   stable storage for keys, key lifetimes, Key-IDs, and the related
   sequence numbers.

Przygienda                 Expires 10 May 1998                  [Page 7]

Internet Draft         BGP-4 MD5 Authentication          5 November 1997

   Acceptable messages are now truncated to a BGP-4 message itself and
   treated normally.

4. New UPDATE Message Error Subcode

   A new UPDATE Message Error subcode with the value 12 - Authentication
   Failure MUST be understood by all implementations supporting keyed
   authentication.

5. Management Procedures

5.1.  Key Management Requirements

   It is strongly desirable that a hypothetical security breach in
   one Internet protocol not automatically compromise other Internet
   protocols.  The Authentication Key of this specification SHOULD NOT
   be stored using protocols or algorithms that have known flaws.

   Implementations MUST support the storage of more than one key at
   the same time, although it is recognized that only one key will
   normally be active on a session.  They MUST associate a specific
   lifetime (i.e., date/time first valid and date/time no longer valid)
   and a key identifier with each key, and MUST support manual key
   distribution (e.g., the privileged user manually typing in the
   key, key lifetime, and key identifier on the router console).  The
   lifetime may be infinite.  If more than one algorithm is supported,
   then the implementation MUST require that the algorithm be specified
   for each key at the time the other key information is entered.  Keys
   that are out of date MAY be deleted at will by the implementation
   without requiring human intervention.  Manual deletion of active keys
   SHOULD also be supported.

   It is likely that the IETF will define a standard key management
   protocol.  It is strongly desirable to use that key management
   protocol to distribute BGP-4 Authentication Keys among communicating
   BGP-4 implementations.  Such a protocol would provide scalability
   and significantly reduce the human administrative burden.  The Key
   ID can be used as a hook between BGP-4 and such a future protocol.
   Key management protocols have a long history of subtle flaws that
   are often discovered long after the protocol was first described
   in public.  To avoid having to change all BGP-4 implementations

Przygienda                 Expires 10 May 1998                  [Page 8]

Internet Draft         BGP-4 MD5 Authentication          5 November 1997

   should such a flaw be discovered, integrated key management protocol
   techniques were deliberately omitted from this specification.

5.2.  Key Management Procedures

   As with all security methods using keys, it is necessary to change
   the BGP-4 Authentication Key on a regular basis.  To maintain routing
   stability during such changes, implementations MUST be able to store
   and use more than one BGP-4 Authentication Key for a given session at
   the same time.

   Each key will have its own Key Identifier, which is stored locally.
   The combination of the Key Identifier and the session associated with
   the message uniquely identifies the Authentication Algorithm and
   BGP-4 Authentication Key in use.

   The party creating the BGP-4 message will select a valid key from
   the set of valid keys for that session.  The receiver will use
   the Key Identifier and session to determine which key to use for
   authentication of the received message.  More than one key may be
   associated with a session at the same time.

   Hence it is possible to have fairly smooth BGP-4 Authentication
   Key rollovers without losing legitimate BGP-4 messages because the
   stored key is incorrect and without requiring people to change all
   the keys at once.  To ensure a smooth rollover, each communicating
   BGP-4 system must be updated with the new key several minutes before
   the current key will expire and several minutes before the new key
   lifetime begins.  The new key should have a lifetime that starts
   several minutes before the old key expires.  This gives time for each
   system to learn of the new BGP-4 Authentication Key before that key
   will be used.  It also ensures that the new key will begin being
   used and the current key will go out of use before the current key's
   lifetime expires.  For the duration of the overlap in key lifetimes,
   a system may receive messages using either key and authenticate the
   message.  The Key-ID in the received message is used to select the
   appropriate key for authentication.

Przygienda                 Expires 10 May 1998                  [Page 9]

Internet Draft         BGP-4 MD5 Authentication          5 November 1997

5.3.  Pathological Cases

   Two pathological cases exist which must be handled, which are
   failures of the network manager.  Both of these should be exceedingly
   rare.

   During key switchover, devices may exist which have not yet been
   successfully configured with the new key.  Therefore, routers SHOULD
   implement (and would be well advised to implement) an algorithm
   that detects the set of keys being used by its neighbors, and
   transmits its messages using both the new and old keys until all of
   the neighbors are using the new key or the lifetime of the old key
   expires.  Under normal circumstances, this elevated transmission rate
   will exist for a single update interval.

   In the event that the last key associated with an session expires,
   it is unacceptable to revert to an unauthenticated condition, and
   not advisable to disrupt routing.  Therefore, the router should send
   a "last authentication key expiration" notification to the network
   manager and treat the key as having an infinite lifetime until the
   lifetime is extended, the key is deleted by network management, or a
   new key is configured.

6.  Conformance Requirements

   To conform to this specification, an implementation MUST support
   all of its aspects.  The Keyed MD5 authentication algorithm MUST
   be implemented by all conforming implementations.  MD5 is defined
   in [Riv92].  A conforming implementation MAY also support other
   authentication algorithms such as Keyed Secure Hash Algorithm (SHA).
   Manual key distribution as described above MUST be supported by all
   conforming implementations.  All implementations MUST support the
   smooth key rollover described under "Key Change Procedures."

   The user documentation provided with the implementation MUST contain
   clear instructions on how to ensure that smooth key rollover occurs.

   Implementations SHOULD support a standard key management protocol
   for secure distribution of BGP-4 Authentication Keys once such a key
   management protocol is standardized by the IETF.

Przygienda                 Expires 10 May 1998                 [Page 10]

Internet Draft         BGP-4 MD5 Authentication          5 November 1997

7. Security Consideration

   This memo describes and specifies an authentication mechanism for the
   BGP-4 routing protocol that is believed to be secure against active
   and passive attacks.

   Users need to understand that the quality of the security provided by
   this mechanism depends completely on the strength of the implemented
   authentication algorithms, the strength of the key being used, and
   the correct implementation of the security mechanism in communicating
   BGP-4 implementations.  This mechanism also depends on the BGP-4
   Authentication Key being kept confidential by all parties.  If any of
   these incorrect or insufficiently secure, then no real security will
   be provided to the users of this mechanism.

   Specifically with respect to the use of SNMP, compromise of
   SNMP security has the necessary result that the various BGP-4
   configuration parameters (e.g.  routing table, BGP-4 Authentication
   Key) manageable via SNMP could be compromised as well.  Changing
   Authentication Keys using non-encrypted SNMP is no more secure than
   sending passwords in the clear.

   Confidentiality is not provided by this mechanism.

8. Acknowledgements

   Large parts of this memo are based or has been taken over from the
   RIP-2 MD-5 authentication [BA97].

References

   [AF97]  ATM-Forum.  Private Network-Network Interface Specification
           Version 2.0.  ATM Forum, work in progress, 1997.

   [Atk95] R. Atkinson.  IP Encapsulating Security Payload.  Internet
           Engineering Task Force, August 1995.

   [BA97]  F. Baker and R. Atkinson.  RIP-2 MD5 Authentication.
           Internet Engineering Task Force, January 1997.

Przygienda                 Expires 10 May 1998                 [Page 11]

Internet Draft         BGP-4 MD5 Authentication          5 November 1997

   [Moy97] J. Moy.  OSPFv2, RFC 2178.  Internet Engineering Task Force,
           July 1997.

   [Riv92] R. Rivest.  The MD5 Message-Digest Algorithm, RFC 1321.
           Internet Engineering Task Force, April 1992.

   [RL95]  Y. Rekhter and T. Li.  A Border Gateway Protocol 4 (BGP-4),
           RFC 1771.  Internet Engineering Task Force, March 1995.

   [RL97]  Y. Rekhter and T. Li.  A Border Gateway Protocol 4 (BGP-4).
           Internet Draft, 1997.

   [Tou95] J. Touch.  Report on MD5 Performance, RFC 1810.  Internet
           Engineering Task Force, June 1995.

Authors' Addresses

Tony Przygienda
Bell Labs, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
[email-masked]

Przygienda                 Expires 10 May 1998                 [Page 12]

--------------521AAEE7A3B2AD860D695146--

To: [email-masked]
Subject: IDR sessions at the IETF
Date: Thu, 20 Nov 97 17:38:18 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

fyi
------- Forwarded Message

Date: Thu, 20 Nov 1997 16:37:04 -0500
To: Yakov Rekhter <[email-masked]>
From: Marcia Beaulieu <[email-masked]>
Subject: 40th IETF-WASHINGTON: IDR
Cc: [email-masked], [email-masked]

This is to confirm two sessions for IDR as follows:

        Wednesday, December 10 at 1930-2200
                (opposite lsma, drums, disman, manet, pint)
        Friday, December 12 at 0900-1130
                (opposite disman, ipngwg)

Please submit an agenda (to [email-masked]) for these meetings as
soon as possible.

Thanks,

Marcia

**********************************************************************
Marcia Beaulieu <[email-masked]>
IETF Meeting Coordinator
Voice: 703-620-8990 ext. 210
Fax: 703-758-5913

------- End of Forwarded Message

To: "Hannes R. Boehm" <[email-masked]>
cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: Filtering on IBGP-Sessions ? 
Date: Tue, 11 Nov 1997 00:50:23 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

> I wonder wether it is possible (recommended) or not to filter on IBGP

A *Real Bad Idea* (sm).

If you have inconsistent routing within you IBGP mesh you can get
route loops.

Curtis

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-ipv6-00.txt
Date: Mon, 10 Nov 1997 10:05:41 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: Use of BGP-4 Multiprotocol Extensions 
                          for IPv6 Inter-Domain Routing
	Author(s)	: F. Dupont, P. Marques
	Filename	: draft-ietf-idr-bgp4-ipv6-00.txt
	Pages		: 5
	Date		: 07-Nov-97
	
   BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP
   attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to
   announce and withdraw the announcement of reachability information.
   This document defines how compliant systems should make use of those
   attributes for the purpose of conveying IPv6 routing information.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-ipv6-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-ipv6-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-ipv6-00.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-ipv6-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-ipv6-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 10 Nov 1997 13:26:02 +0100
From: "Hannes R. Boehm" <[email-masked]>
To: [email-masked]
Subject: Filtering on IBGP-Sessions ?
Sender: [email-masked]

--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii

I wonder wether it is possible (recommended) or not to filter on IBGP sessions.

I've got a transit area in my autonomous system. If I do not filter on the IBGP sessions
all routers in the transit area have full BGP routes. -> since I don't want to upgrade
all my routers to the same amount of RAM, I am thinking about filtering on some
of the IBGP sessions.

-> our Router at the local Exchange does not have to have full BGP routes  
   (-> we do not offer transit for any party at the local Exchange)
   
My Questions:

Is it possible to filter on IBGP sessions (-> is it recommended ?) ?
Should I use a conferderation of two or more private AS to solve this problem ?

Hannes R. Boehm

-- 
--
"The nice thing about standards is that there's so many to choose from." 
        -- Andrew S. Tannenbaum
!------------------------------------------------------------------!
  Hannes R. Boehm
        email   : [email-masked]
        www     : http://hannes.boehm.org
        PGP-key : http://hannes.boehm.org/hannes-pgp.asc
!------------------------------------------------------------------!

--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature

--FL5UXtIhxfXey3p5--

To: [email-masked]
Subject: WG Agenda
Date: Thu, 06 Nov 97 07:10:41 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

Please send your suggestions on the Agenda to me and Sue Hares.

Yakov.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-route-damp-00.txt,.ps
Date: Thu, 06 Nov 1997 09:55:30 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: BGP Route Flap Damping
	Author(s)	: C. Villamizar, R. Govindan, R. Chandra
	Filename	: draft-ietf-idr-route-damp-00.txt,.ps
	Pages		: 28
	Date		: 05-Nov-97
	
  A usage of the BGP routing protocol is described which is capable of
  reducing the routing traffic passed on to routing peers and therefore
  the load on these peers without adversely affecting route convergence
  time for relatively stable routes.  This technique has been
  implemented in commercial products supporting BGP. The technique is
  also applicable to IDRP.
 
  The overall goals are:
 
  o  to provide a mechanism capable of reducing router processing load      
     caused by instability
 
  o  in doing so prevent sustained routing oscillations
 
  o  to do so without sacrificing route convergence time for generally
     well behaved routes.
 
  This must be accomplished keeping other goals of BGP in mind:
 
  o  pack changes into a small number of updates
 
  o  preserve consistent routing
 
  o  minimal addition space and computational overhead

  Excessive updates to reachability state has been widespread in the
  Internet.  This observation was made in the early 1990s by many people
  involved in Internet operations and remains to case to date.  These   
  excessive updates are not necessarily periodic so route oscillation
  would be a misleading term.  The informal term used to describe this
  effect is ``route flap''.  The techniques described here are now
  widely deployed and are commonly referred to as ``route flap
  damping''.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-route-damp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-idr-route-damp-00.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-idr-route-damp-00.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-route-damp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-route-damp-00.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Koestler, Sonja (IT Man.)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: latest bgp+ version
Date: Thu, 6 Nov 1997 09:18:57 -0000
Sender: [email-masked]

Hi all !

Where can I get the latest BGP+ version on the internet?

TIA, _sonja