Subject: [Idr] RE: FSM review - comments on Administrative events 8.1.1 - Urgent

From: "Susan Hares" <[email-masked]>
Date: Mon, 30 Jun 2003 16:44:24 -0400

Tom and Alex: 

I need to your help on resolving Tom's comments.
I've got conflicting comments. 

(Tom - Thanks for the note.  Your Thursday email got to me
delayed due to a mailer problem.  We got a lot of spam last
week.) 

On your comments:

pre-1) 8.2.1.3 - Can you propose text? Or suggest changes?
	 Can you confirm your text with Alex 1st?

1) I Will change session to connection
2) true/False on values 
	Please agree with Alex on Value or just flag.
	
3) stops/starts - I'm happy to use the stops/starts.
	1) For optional - we do need a value to indicate the timer is there.
	2) I'll be glad to use the 3 types
		xxxTime in seconds (initial value)
	      xxxTimer - starts, stops is reset etc.
		xxxTimerAttribute - that signals use?
  
	The comments from the previous information (including yours)
	indicated the stop/start values.

	Please confirm what you would like to have.

4) connection attributes 

	I am glad to use connection or session attributes.
	I simply need you and Alex (or his AD-Commentors)
	to agree on a text.

	If we are banning sessions, then connections are
	OK with me.  I think session is a more accurate term
	for the FSM - but if it is binned nothing in this world
	can drag me into a longer discussion. 

But, I need again -- I need to see email from both of you
confirming the change.  

Sue

-----Original Message-----
From: Tom Petch [mailto:[email-masked]]
Sent: Monday, June 30, 2003 1:01 PM
To: Susan Hares; Alex Zinin
Cc: [email-masked]
Subject: Re: FSM review - comments on Administrative events 8.1.1

Sue

I am not clear that you have received the comments I sent, plus
attached corrections, last Thursday, which I sent, in the way of
e-mail, before I received your Wednesday lunchtime e-mail.

I think there are some basic unresolved questions which make it
premature to focus on the detail.

8.2.1.3 was a good summary but is now inconsistent with 8.1,
unacceptably so for me; needs changing.

1)Session was binned as I understood it by Yakov last October,
connection being the correct term.

2) We may only still have flags and timers but ....  The new 8.1 turns
the flags into Boolean variables, whether or not you use that term.
They always have a value, True or False.  Therefore, we can no longer
talk of set, not set, off or reset; these terms are meaningless.  We
have to talk in terms of these attributes (if that is the right term)
having the value True or False.   Or else get rid of all your text on
True or False :-)

3)  Timers in the base document are xxxTime in seconds and xxxTimer
which starts, stops is reset etc.  We should, unless you have a cogent
argument otherwise, use the same for optional timers and currently we
do not - ever  We have no clear way of indicating that an optional
timer is implemented.  We can have a xxxTime in second representing
the initial or default value but need something more to say this is or
is not implemented.  Should each optional timer have a True/False to
indicate presence or absence?  If this is xxxTimer, we then need a
third term in the actions, where xxxTimeyyy is started or stopped.  We
don't yet need a fourth term to denote the current value of this thing
but we could do so the way we are expanding this section.

4) Is 'connection attributes' the right term for however many types of
objects we have?  Depends on the resolution of 3)

Turning to your proposed new paragraph in 8.1.2, no, not ok.  We need
to resolve the issues of optional whatevers first and document that in
8.1, reword and move 8.2.1.3 in there right at the start and use the
principles we have documented there as the basis to decide what is
right and what is wrong for the lesser sections such a Admin or TCP or
other groups of etc,  only then can we satisfactorily document the
settablility, MIBability etc.

I resend my e-mail of last Thursday separately just in case it fell
into some spam trap.

Tom Petch
[email-masked]
+(44) 192 575 3018
-----Original Message-----
From: Susan Hares <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Tom Petch <[email-masked]>; [email-masked]
<[email-masked]>; [email-masked] <[email-masked]>
Date: 30 June 2003 15:15
Subject: RE: FSM review - comments on Administrative events 8.1.1

Alex and Tom:

Suggested changed text in 8.1.2 -- please approve as AD reviewers.

AD comments:

> 8.1.2 Administrative Events
>
>
>    Please note that only Event 1 (manual start) and Event 2 (manual
>    stop) are mandatory administrative events. All other
administrative
>    events are optional (Events 3-8).   Each event below has a name,
>    definition, status (mandatory or optional), and what optional
session
>    attributes SHOULD be set at each stage.

Can we make it clear whether these settings are the conditions under
which a given event is considered valid, or actions when an even is
seen?

Also, if those are the conditions, what should be done when the
settings are different?

==========

Text Resolution:

8.1.2 Administrative Events

   An administrative event is an event in which the operator interface
   and BGP Policy engine signal the BGP finite state machine to start
   or stop the BGP state machine.  The basic start and stop indication
   are augmented by optional session attributes to signal a certain
   type of start or stop mechanism to the BGP FSM. An example of this
   combination is event 5:
AutomaticStart_with_PassiveTCPEstablishment.
   With this event, the BGP implementation signals to the BGP FSM
   that the implementation is using an Automatic Start with option
   to use a Passive TCP Establishment.  The Passive TCP establishment
   signals that this BGP FSM will wait for the remote side to start
   the TCP establishment.

   Please note that only Event 1 (manual start) and Event 2 (manual
   stop) are mandatory administrative events. All other administrative
   events are optional (Events 3-8).   Each event below has a name,
   definition, status (mandatory or optional), and what optional
session
   attributes SHOULD be set at each stage.

   The settings of optional session attributes may be implied by some
   implementations and not settable by external operator. Section
8.2.1.5
   describes these implied settings of the optional session
attributes.
   The administrative states described below may also be implied
   by some implementations and not directly settable by an external
   operator.  Section 8.2.1.4 describes these implied states further.

       Event1: ManualStart

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 30 Jun 2003 16:44:24 -0400

Tom and Alex: 

On your comments:

	

4) connection attributes 

Sue

-----Original Message-----
From: Tom Petch [mailto:[email-masked]]
Sent: Monday, June 30, 2003 1:01 PM
To: Susan Hares; Alex Zinin
Cc: [email-masked]
Subject: Re: FSM review - comments on Administrative events 8.1.1

Sue

Tom Petch
-----Original Message-----
From: Susan Hares <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Tom Petch <[email-masked]>; [email-masked]

Alex and Tom:

administrative
session

==========

Text Resolution:

       Event1: ManualStart

Content-Class: urn:content-classes:message
Date: Mon, 30 Jun 2003 16:44:45 -0400
From: "Susan Hares" <[email-masked]>
To: "Alex Zinin" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: [Idr] RE: FSM review - urgent (Tom and Alex please confirm changes)
Sender: [email-masked]

Alex:

1) All States will start with a capital.
2) All bgp resources - will either 
	1) stay at "all BGP resources" or
	2) change to "All BGP resources for this BGP connection"
	
	Please work with Tom Petch to determine
	which of these two you both approve or
	I will leave it at "all BGP resources". 

3) Garbled text in Event23 is correct to the sentence: 

	Event23 is an administrative action
      called by implementation specific logic
      that determines that this connection
      needs to be dropped. 

[Alex/AD-review] Why "implementation-specific logic"?

[Sue]   Implementations code 6.8 in a particular form.
[Sue]    Policy + Administrative events creation is an 
[Sue]    Implementation specific logic.  FSM defines what
[sue]    happens on the wire.

4) > 8.2.1.1 Terms "active" and "passive"

>    The terms active and passive have been in our vocabulary for almost a
>    decade and have proven useful.

will be replaced with:

	The terms active and passive have been in the Internet operator's
      vocabulary for almost a decade and have proven useful.

	Please confirm (with Tom Petch and AD reviewers) that
	you like the replacement text.

Sue

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]]
Sent: Tuesday, June 24, 2003 8:56 PM
To: Susan Hares
Subject: FSM review
>        Event23: OpenCollisionDump
> 
>               Definition: An event generated administratively
>                           when a connection collision has been
>                           detected while processing an incoming
>                           OPEN message and this connection has been
>                           selected to be disconnected. See Section
>                           6.8 for more information on collision
>                           detection.
> 
>                           Event23 is an administrative action
>                          called by implementation specific logic

[Alex/AD-review] Why "implementation-specific logic"?

[Sue:]   Implementations code 6.8 in a particular form.
[Sue]    Policy + Administrative events creation is an 
[Sue]    Implementation specific logic.  FSM defines what
[sue]    happens on the wire.

>                         that determines that this connection
>                         needs to be dropped.  The action
>                         the control of implementation specific
>                           policy.

Couldn't parse this sentence.

[sue]		The text was garbled.. thanks for the input!!
[sue]  	new text:  Event23 is an administrative action called
[sue]       by implementation specific logic that determines that 
[sue]       this connection needs to be dropped.  
[sue]
[sue]		leave the last sentence off.

> This event may occur if the FSM
>                           is implemented as two linked state machines.
> 
> 
>               Status:     Optional, depending on local system
> 
>               Optional
>               Attribute
>             Status:     If the state machine is to process this
>                           attribute in Established state,
>                            1) CollisionDetectEstablished
>                                flag SHOULD be set to TRUE
> 
> 
>                            Please note: The Open collision dump can occur
                                              ^^^^^^^^^^^^^^^^^^^
                                              OpenCollisionDump?
                                              
[Thanks for catching -- will turn to normalized form.]

>                            in Idle, Connect, Active, OpenSent, OpenConfirm
>                            without any optional flags being set.

[snip]
>    the idle state, or configured to remain passive, will attempt to

[Alex] "Idle" instead?

[Sue]  thanks - missed that one. idle.

>    connect to the other.  For the purpose of this discussion, the active
>    or connecting side of the TCP connection (the side of a TCP connection
>    sending the first TCP SYN packet) is called outgoing.  The passive or
>    listening side (the sender of the first SYN ACK) is called an incom-
>    ing connection. (See Section 8.2.1.1 for information on the terms
>    active and passive used below.)
> 
>    A BGP implementation MUST connect to and listen on TCP port 179 for
>    incoming connections in addition to trying to connect to peers.  For
>    each incoming connection, a state machine MUST be instantiated.

[alex] For each or only for a valid one. i.e, if I don't support unconfigured
[alex] peers and I receive a connection request from someone I don't know, I
[alex] should not create an FSM for it.

[Sue]  This text was agreed upon by lots of discussions.
[sue]  I am sure if I change it the working group last call will
[sue]  need to be redone.  Please tell me why other text associated with
[sue]  this text doesn't clarify this.  Propose text to the list. 

>    There exists a period in which the identity of the peer on the other
>    end of an incoming connection is known, but the BGP identifier is not
>    known.  During this time, both an incoming and an outgoing connection
>    for the same configured peering may exist. This is referred to as a
>    connection collision. (See Section 6.8.)
> 
>    A BGP implementation will have at most one FSM for each configured
>    peering plus one FSM for each incoming TCP connection for which the
>    peer has not yet been identified. Each FSM corresponds to exactly one
>    TCP connection.
> 
>
> 8.2.1.1 Terms "active" and "passive"
> 
> 
>    The terms active and passive have been in our vocabulary for almost a
>    decade and have proven useful.

[Alex] Ed: personalization and time dependency?
[Sue]  Can we replace "our vocabulary" with "the Internet operator' vocabulary"
[Sue]  
[Sue]  I need your confirmation, the working groups, Tom Petch's, and Jeff 
[Sue]  Haas on this comment. 

>   The words active and passive have
>    slightly different meanings applied to a TCP connection or applied to
>    a peer.  There is only one active side and one passive side to any
>    one TCP connection per the definition above and the state machine
>    below. When a BGP speaker is configured active, it may end up on
>    either the active or passive side of the connection that eventually
>    gets established.  Once the TCP connection is completed, it doesn't
>    matter which end was active and which end was passive.  The only
>    difference is which side of the TCP connection has port number 179.
> 
> 
> 
> 8.2.1.2 FSM and collision detection
> 
> 
>    There is one FSM per BGP connection.  Prior to determining what peer
>    a connection is associated with a bgp session there may be 
> 
> 
> 
> 
> Expiration Date September 2003                                 [Page 46]
> 
> 
> 
> 
> 
> RFC DRAFT                                                     March 2003
> 
> 
>    two connections for a given peer.  There SHOULD be no more than one
>    connection per peer session.

[Alex] Does this assume that a peer is identified by the Router ID?
[Alex] Don't existing implementations use IP addresses instead?

[Sue:] My understanding is the remote side is identified by IP address.
[Sue:] The local side has lots of confirmation knobs?  So, what exactly
[Sue:] Do you mean with this comment?  Can you suggest text that
[sue:] would be a replacement? 

>    The collision detection identifies the case where there is more than
>    one connection per peer and provides guidance for which connection to
>    get rid of.  When this occurs, the corresponding FSM for the connec-
>    tion that is closed SHOULD be disposed of.
> 
>
[snip]..

> 8.2.1.5 FSM actions that are implementation dependent.
> 
>    The BGP FSM specifies at certain points that BGP initialization will
>    occur or that BGP resources will be delete.  The initialization of the
>    BGP FSM and the associate resources depend on the policy portion of
>    the BGP implementation.  The details of these actions are outside
>    the scope of the FSM document.   

[Alex] So, does it really add any value to talk about them here if
[Alex] we don't define what those really are?

[Sue] The FSM actions clarify the actions of the protocol interaction.
[Sue] We cannot simply wave our standards hands and say "implementation"
[Sue] be non-conformant to many working BGP implementations.  Unless
[Sue] you provide some latitude for implementations to have implied
[Sue] optional connection (was session) attributes - you make all
[Sue] implementations obsolete.  My understanding of the ADs charter
[Sue] for this re-write is that type of obsoleting fell under the
[Sue] BAD idea category.  Please clarify this comment.

        - changes its state to Active.
[...]

>       Connect State:
> 
>         In this state, BGP FSM is waiting for the TCP connection to
>         be completed.
> 
> 
>         The start events [Events 1, 3-7] are ignored in connect
>         state.
> 
>         In response to a ManualStop event [Event2], the local system:
>            - drops the TCP connection,
>            - releases all BGP resources,

[Alex] all resources? 

[Sue start] - All appropriate resources for this BGP connection (or session).
[Sue]	  The text was agreed upon.  AGain - I am willing to change the
[Sue]	  text if it is incorrect or to add "BGP connection resources".
[Sue]
[Sue]   But!!! - you (or your AD reviewers)  and Tom Petch must agree
[Sue]   on the comment so I don't go back/forth on comment, or you
[Sue]	  must decide to over-rule Tom.
[Sue end] 

>            - sets ConnectRetryCounter to zero, 
>            - stops the ConnectRetryTimer and sets ConnectRetryTimer
>              to zero, and
> 
> 
> 
> Expiration Date September 2003                                 [Page 48]
> 
> 
> 
> 
> 
> RFC DRAFT                                                     March 2003
> 
> 
>            - changes its state to Idle.
> 
> 
>         In response to the ConnectRetryTimer_Expires event [Event
>         9], the local system:
>            - drops the TCP connection,
>            - restarts the ConnectRetryTimer,
>            - stops the OpenDelayTimer and resets the timer to zero,
>            - initiates a TCP connection to the other BGP peer,
>            - continues to listen for a connection that may be
>              initiated by the remote BGP peer, and
>            - stays in Connect state.
> 
>         If the OpenDelayTimer_Expires event [Event12] occurs in the
>         Connect state, the local system:
>            - sends an OPEN message to its peer,
>            - sets the HoldTimer to a large value, and
>            - changes its state to OpenSent.
> 
>         If the BGP FSM receives a TCPConnection_valid event
>         [Event 14], the TCP connection is processed, and
>         the connection remains in the Connect state.
> 
>         If the BGP FSM receives a ReceiveTCPInvalid event [Event 15]:
>         the local system rejects the TCP connection, and the connection
>         remains in the Connect state.
> 
>         If the TCP connection succeeds [Event 16 or
>         Event 17], the local system checks the DelayOpen attribute prior
>         to processing.  If the DelayOpen attribute is set, the local system:
>              - stops the ConnectRetryTimer (if running) and sets the
>              ConnectRetryTimer to zero,
>              - sets the Open Delay timer to the initial value, and
>              - stays in the Connect state.
>         If the DelayOpen attribute is not set, the local system:
>              - stops the ConnectRetryTimer (if running) and sets the
>              ConnectRetryTimer to zero,
>              - completes BGP initialization
>              - sends an OPEN message to its peer,
>              - sets HoldTimer to a large value, and
>              - changes its state to OpenSent.
> 
>         A hold timer value of 4 minutes is suggested.
> 
>         If the TCP connection fails (TCPConnectionFails [Event18]),
>         the local system checks the OpenDelayTimer.  If the
>         OpenDelayTimer is running, the local system:
>             - restarts the ConnectRetryTimer with initial value,
>             - stops the OpenDelayTimer and resets value to zero,
>             - continues to listen for a connection that may be
> 
> 
> 
> Expiration Date September 2003                                 [Page 49]
> 
> 
> 
> 
> 
> RFC DRAFT                                                     March 2003
> 
> 
>               initiated by the remote BGP peer, and
>             - changes its state to Active.
> 
>         If the OpenDelayTimer is not running, the local system:
>            - stops the ConnectRetryTimer to zero,
>            - drops the TCP connection,
>            - releases all BGP resources, and

all bgp resources?

>            - changes its state to Idle.
> 
>         If an OPEN message is received while the OpenDelayTimer is
>         running [Event 20], the local system:
> 
>            - stops the ConnectRetryTimer (if running) and
>            sets the ConnectRetryTimer to zero,
>            - completes the BGP initialization,
>            - stops and clears the OpenDelayTimer
>              (sets the value to zero),
>            - sends an OPEN message,
>            - sends a KEEPALIVE message,
>            - if the HoldTimer initial value is non-zero,
>                    - starts the keepalive timer to inital value and
>                    - resets the hold timer to the negotiated value,
>              else if HoldTimer Initial value is zero,
>                    - resets the keepalive timer and
>                    - resets the HoldTimer value to zero, 
>            - and changes its state to OpenConfirm.
> 
>         If the value of the autonomous system field is the same as the local
>         Autonomous System number, set the connection status to an internal
>         connection; otherwise it is "external".
> 
>         If BGP message header checking detects an error [Event 21] or
>         OPEN message checking detects an error [Event 22] (see section
>         6.2), the local system:
>            - [optionally] If the SendNOTIFICATIONwithoutOpen attribute 
>               is set to TRUE, then the local system first sends
>               a NOTIFICATION message with the appropriate error
>               code, and then
> 
>            - stops the ConnectRetryTimer (if running)
>              and sets the ConnectRetryTimer to zero,
>            - releases all BGP resources,

all bgp resources?

>            - drops the TCP connection,
>            - increments the ConnectRetryCount by 1,
>            - [optionally] performs peer oscillation damping
>            if the DampPeerOscillation attribute is set to TRUE, and 
>            - changes its state to Idle.
> 
>         If a NOTIFICATION message is received with a version
>         error[Event24], the local system checks the OpenDelayTimer.
>         If the OpenDelayTimer is running, the local system:
>            - stops the ConnectRetryTimer (if running) 
>            and sets the ConnectRetryTimer to zero,
>            - stops and resets the Open Delay timer (sets to zero),
>            - releases all BGP resources,

all bgp resources

>            - drops the TCP connection, and
> 
> 
> 
> Expiration Date September 2003                                 [Page 50]
> 
> 
> 
> 
> 
> RFC DRAFT                                                     March 2003
> 
> 
>            - changes its state to Idle.
> 
>         If the Open Delay timer is not running, the local system:
>            - stops the ConnectRetryTimer and sets the
>            ConnectRetryTimer to zero,
>            - releases all BGP resources,

ditto throughout the rest of the doc

I glanced through the rest seems fine, _assuming_ that you checked
the correctness of the FSM.

Thanks.

Alex

Content-Class: urn:content-classes:message
Date: Mon, 30 Jun 2003 16:44:24 -0400
From: "Susan Hares" <[email-masked]>
To: "Tom Petch" <[email-masked]>, "Alex Zinin" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: [Idr] RE: FSM review  - comments on Administrative events 8.1.1 - Urgent
Sender: [email-masked]

Tom and Alex: 

On your comments:

	

4) connection attributes 

Sue

-----Original Message-----
From: Tom Petch [mailto:[email-masked]]
Sent: Monday, June 30, 2003 1:01 PM
To: Susan Hares; Alex Zinin
Cc: [email-masked]
Subject: Re: FSM review - comments on Administrative events 8.1.1

Sue

Tom Petch
-----Original Message-----
From: Susan Hares <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Tom Petch <[email-masked]>; [email-masked]

Alex and Tom:

administrative
session

=====

Text Resolution:

       Event1: ManualStart

Content-Class: urn:content-classes:message
Date: Mon, 30 Jun 2003 10:15:08 -0400
From: "Susan Hares" <[email-masked]>
To: "Alex Zinin" <[email-masked]>
Cc: "Tom Petch" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: [Idr] RE: FSM review  - comments on Administrative events 8.1.1
Sender: [email-masked]

Alex and Tom:

AD comments:

>    definition, status (mandatory or optional), and what optional session

=====

Text Resolution:

   combination is event 5:  AutomaticStart_with_PassiveTCPEstablishment.

   definition, status (mandatory or optional), and what optional session

   The settings of optional session attributes may be implied by some
   implementations and not settable by external operator. Section 8.2.1.5
   describes these implied settings of the optional session attributes.
   The administrative states described below may also be implied
   by some implementations and not directly settable by an external
   operator.  Section 8.2.1.4 describes these implied states further. 

       Event1: ManualStart

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp-vuln-00.txt
Date: Thu, 26 Jun 2003 08:05:20 -0400
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 Security Vulnerabilities Analysis
	Author(s)	: S. Murphy
	Filename	: draft-ietf-idr-bgp-vuln-00.txt
	Pages		: 19
	Date		: 2003-6-25
	
BGP, along with a host of other infrastructure protocols designed before
the Internet environment became perilous, was originally designed with
little consideration for protection of the information it carries.
There are no mechanisms internal to the BGP protocol to protect against
attacks that modify, delete, forge, or replay data, any of which has the
potential to disrupt overall network routing behavior.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-vuln-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also 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-bgp-vuln-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp-vuln-00.txt".
	
NOTE:	The mail server at ietf.org 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-bgp-vuln-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-vuln-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Date: Wed, 25 Jun 2003 13:06:10 -0400 (EDT)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: draft-ietf-idr-bgp-vuln-00.txt
Cc: [email-masked]
Sender: [email-masked]

I sent the vulnerabilities draft off to the internet-drafts on Monday.
I thought it might be a good idea to send it here as well.

--Sandy

Network Working Group                                      Sandra Murphy
INTERNET DRAFT                                                  NAI Labs
draft-ietf-idr-bgp-vuln-00.txt                                 June 2003

                 BGP Security Vulnerabilities Analysis

Status of this Memo

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

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

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

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

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

Specification of Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].

Abstract

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

Murphy                   Expires: December 2003                 [Page 1]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

This internet draft discusses some of the security issues with BGP
routing data dissemination.  This internet draft does not discuss
security issues with forwarding of packets.

Murphy                   Expires: December 2003                 [Page 2]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

Table of Contents

 Status of this Memo ..............................................    1
 Specification of Requirements ....................................    1
 Abstract .........................................................    1
1 Introduction ....................................................    4
2 Attacks .........................................................    6
3 Vulnerabilities and Risks .......................................    8
3.1 Vulnerabilities in BGP messages ...............................    8
3.1.1 Message Header ..............................................    8
3.1.2 OPEN ........................................................    9
3.1.3 KEEPALIVE ...................................................   10
3.1.4 NOTIFICATION ................................................   10
3.1.5 UPDATE ......................................................   10
3.1.5.1 Unfeasible Routes Length, Total Path Attribute Length .....   10
3.1.5.2 Withdrawn Routes ..........................................   11
3.1.5.3 Path Attributes ...........................................   11
 Attribute Flags, Attribute Type Codes, Attribute Length ..........   11
 ORIGIN ...........................................................   11
 AS_PATH ..........................................................   12
 Originating Routes ...............................................   12
 NEXT_HOP .........................................................   13
 MULTI_EXIT_DISC ..................................................   13
 LOCAL_PREF .......................................................   13
 ATOMIC_AGGREGATE .................................................   14
 AGGREGATOR .......................................................   14
3.1.5.4 NLRI ......................................................   14
3.2 Vulnerabilities through Other Protocols .......................   15
3.2.1 TCP messages ................................................   15
3.2.1.1 TCP SYN ...................................................   15
3.2.1.2 TCP SYN ACK ...............................................   15
3.2.1.3 TCP ACK ...................................................   15
3.2.1.4 TCP RST/FIN/FIN-ACK .......................................   16
3.2.1.5 DoS and DDos ..............................................   16
3.2.2 Other supporting protocols ..................................   16
3.2.2.1 Manual stop ...............................................   16
3.2.2.2 Timer events ..............................................   16
4 Security Considerations .........................................   17
4.1 Residual Risk .................................................   17
4.2 Operational Protections .......................................   17
5 References ......................................................   19
6 Author's Address ................................................   19

Murphy                   Expires: December 2003                 [Page 3]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

1.  Introduction

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

We here discuss the vulnerabilities of BGP, based on the BGP
specification [1].  Readers are expected to be familiar with the BGP RFC
and the behavior of BGP.

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

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

Consequently, the current BGP specification requires that a BGP
implementation must support the authentication mechanism specified in
[5].  However, the requirement for support of that authentication
mechanism cannot ensure that the mechanism is configured for use.  The
mechanism of [5] is based on a pre-installed shared secret; it does not
have the capability of IPSEC [4] to agree on a shared secret
dynamically.  Consequently, the use of [5] msut be a deliberate
decision, not an automatic feature or default.

The current BGP specification also allows for implementations that would
accept connections from "un-configured peers" ([1] Section 8), however,
the specification is not clear as to what an unconfigured peer might be

Murphy                   Expires: December 2003                 [Page 4]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

or how the protections of [5] would apply in such a case.  It is
therefore not possible to include an analysis of the security issues of
this feature.  When a specification is released that describes this
feature more fully, a security analysis should be part of that same
specification.

BGP speakers themselves can inject bogus routing information, either by
masquerading as any other legitimate BGP speaker, or by distributing
unauthorized routing information as themselves.  Historically,
misconfigured and faulty routers have been responsible for widespread
disruptions in the Internet.  The legitimate BGP  peers have the context
and information to produce believable bogus routing information and
therefore have the opportunity to cause great damage.  The cryptographic
protections of [5] and operational protections cannot exclude the bogus
information arising from a legitimate peer.  The risk of disruptions
caused by legitimate BGP speakers is real and cannot be ignored.

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.  As a consequence, traffic to that network could be delayed by
a longer than necessary path.  The network could become unreachable from
areas where the bogus information is accepted.  Traffic might also be
forwarded along a path that permits some adversary a view of the data.
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.

The damage that might result from these attacks are:

     starvation: data traffic destined for a node is forwarded to a part
     of the network that cannot deliver it,

     network congestion: more data traffic is forwarded through some
     portion of the network than would otherwise need to carry the
     traffic,

Murphy                   Expires: December 2003                 [Page 5]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

     blackhole: large amounts of traffic are directed to be forwarded
     through one router that cannot handle the increased level of
     traffic and drops many/most/all packets,

     delay: data traffic destined for a node is forwarded along a path
     that is in some way inferior to the path it would otherwise take,

     looping: data traffic is forwarded along a path that loops, so that
     the data is never delivered,

     eavesdrop: data traffic is forwarded through some router or network
     that would otherwise not see the traffic, affording an opportunity
     to see the data,

     partition: some portion of the network believes that it is
     partitioned from the rest of the network when it is not,

     cut: some portion of the network believes that it has no route to
     some network that is in fact connected,

     churn: the forwarding in the network changes at a rapid pace,
     resulting in large variations in the data delivery patterns (and
     adversely affecting congestion control techniques),

     instability: BGP become unstable so that convergence on a global
     forwarding state is not achieved, and

     overload: the BGP messages themselves become a significant portion
     of the traffic the network carries.

     resource exhaustion: the BGP messages themselves cause exhaustion
     of critical router resources, such as table space.

These consequences can fall exclusively on one end system prefix or may
effect the operation of the network as a whole.

2.  Attacks

The BGP protocol, in and of itself, is subject to the following attacks
(list taken from the IAB Internet-Draft providing guideline for the
security considerations section of Internet-Drafts [8]):

     eavesdropping:  The routing data carried in BGP is carried in
     cleartext, so eavesdropping is a possible attack against routing
     data confidentiality.  (Routing data confidentiality is not a

Murphy                   Expires: December 2003                 [Page 6]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

     common requirement.)

     replay: BGP does not provide for replay protection of its messages.

     message insertion: BGP does not provide protection against
     insertion of messages.  However, because BGP uses TCP, when the
     connection is fully established, message insertion by an outsider
     would require accurate sequence number prediction (not entirely out
     of the question, but more difficult with mature TCP
     implementations) or session stealing attacks.

     message deletion: BGP does not provide protection against deletion
     of messages.  Again, more difficult against a mature TCP
     implementation but not entirely out of the question

     message modification: BGP does not provide protection against
     modification of messages.  A modification that did not change the
     length of the TCP payload would in general not be detectable.

     man-in-the-middle: BGP does not provide protection agains man-in-
     the-middle attacks.  As BGP does no peer entity authentication, a
     man-in-the-middle attack is childs-play.

     denial of service:  While bogus routing data can present a denial
     of service attack on the end systems that are trying to transmit
     data through the network and on the network infrastructure itself,
     certain bogus information can represent a denial of service on the
     BGP routing protocol.  For example, advertising large numbers of
     more specific routes (longer prefixes) can cause BGP traffic and
     router table size to increase, even explode.

The mandatory-to-support mechanism of [5] will counter the message
insertion, deletion, and modification, man-in-the-middle attacks and the
denial of service attacks from outsiders.  The use of [5] does not
protect against eavesdropping attacks, but routing data confidentiality
is not a goal of BGP.  The mechanism of [5] does not protect against
replay attacks, so the only protection against replay is provided by the
TCP sequence number processing.  The mechanism of [5] cannot protect
against bogus routing information originating with an insider.  A replay
attack could be mounted against a BGP connection protected with [5] but
only in very carefully timed circumstances.

Murphy                   Expires: December 2003                 [Page 7]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

3.  Vulnerabilities and Risks

The risks in BGP arise from three fundamental vulnerabilities:

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

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

     no mechanism has been specified within BGP to ensure the
     authenticity of the path attributes announced by an AS.

The first fundamental vulnerability motivated the mandated support of
[5] in the BGP specification.  When that is employed, message integrity
and peer entity authentication is provided.  The mechanism of [5]
assumes that the MD5 algorithm is secure and that the shared secret is
protected and chosen to be difficult to guess.

3.1.  Vulnerabilities in BGP messages

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

Each message introduces certain different vulnerabilities and risks.

3.1.1.  Message Header

Event 21: Each BGP message starts with a standard header.  In all cases,
syntactic errors in the message header will cause the BGP speaker to
close the connection, release all associated BGP resources, delete all
routes learned through that connection and run its decision process to
decide on new routes.

Murphy                   Expires: December 2003                 [Page 8]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

3.1.2.  OPEN

Event 19: Receipt of an OPEN message in state Connect, Active or
Established will cause the cause the BGP speaker to bring down the
connection, release all associated BGP resources, delete all associated
routes, run its decision process and cause the state to return to Idle.
The deletion of routes can cause a cascading effect of routing changes
propogating through other peers.  Also, optionally, an implementation
specific peer oscillation damping may be performed.  The peer
oscillation damping process can affect how soon the connection can be
restarted.  In state OpenSent, the arrival of an OPEN message will cause
the BGP speaker to transition to the OpenConfirm state.  The later
arrival of the legitimate peer's OPEN message will lead the BGP speaker
to declare a connection collision.  The collision detection procedure
may cause the legitimate connection to be dropped.  Consequently, the
ability to spoof this message can lead to a severe disruption of routing
over a wide area.

Event 20: If an OPEN message arrives when the OpenDelay timer is running
when the connection is in state OpenSent or Established, the BGP speaker
will bring down the connection, release all associated BGP resources,
delete all associated routes, run its decision process and cause the
state to return to Idle.  The deletion of routes can cause a cascading
effect of routing changes propogating through other peers.  Also,
optionally, an implementation specific peer oscillation damping may
performed.  The peer oscillation damping process can affect how soon the
connection can be restarted.  However, as the OpenDelay timer should
never be running in the state OpenSent, this could only be caused by an
error in the implementation (which is why the error code is "Finite
State Machine Error").  It would be difficult, if not impossible, for an
outsider to induce this error.

Event 22: Errors in the OPEN message (e.g., unacceptable Hold state,
malformed Optional Parameter, unsupported version, etc.) will cause the
BGP speaker to bring down the connection, release all associated BGP
resources, delete all associated routes, run its decision process and
cause the state to return to Idle.  The deletion of routes can cause a
cascading effect of routing changes propogating through other peers.
Also, optionally, an implementation specific peer oscillation damping
may performed.  The peer oscillation damping process can affect how soon
the connection can be restarted.  Consequently, the ability to spoof
this message can lead to a severe disruption of routing over a wide
area.

Murphy                   Expires: December 2003                 [Page 9]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

3.1.3.  KEEPALIVE

Event 26: Receipt of a KEEPALIVE message when the peering connection is
in the Connect, Active, and OpenSent states would cause the BGP speaker
to transition to the Idle state and fail to establish a connection.  The
ability to spoof this message is a vulnerability.  To exploit this
vulnerability deliberately, the KEEPALIVE must be carefully timed in the
sequence of messages exchanged between the peers; otherwise, it causes
no damage.

3.1.4.  NOTIFICATION

Event 25: Receipt of a NOTIFICATION message in any state will cause the
BGP speaker to bring down the connection, release all associated BGP
resources, delete all associated routes, run its decision process and
cause the state to return to Idle.  The deletion of routes can cause a
cascading effect of routing changes propogating through other peers.
Also, optionally, an implementation specific peer oscillation damping
may performed.  The peer oscillation damping process can affect how soon
the connection can be restarted.  Consequently, the ability to spoof
this message can lead to a severe disruption of routing over a wide
area.

Event 24: A NOTIFICATION message carrying an error code of "Version
Error" behaves the same as in Event 25, with the exception that the
optional peer oscillation damping is not performed (in states Connect
and Active, only when the OpenDelay timer is running).  The damage
caused is therefore one small bit less, in that restarting the
connection is not affected.

3.1.5.  UPDATE

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

3.1.5.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 (see Event 28, below).  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 not
the configured BGP peer, i.e., it presents no additional risk from BGP

Murphy                   Expires: December 2003                [Page 10]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

sources.

3.1.5.2.  Withdrawn Routes

An outsider could cause the elimination of existing legitimate routes by
forging or modifying this field.  An outsider 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 risk from BGP peers via this field.

3.1.5.3.  Path Attributes

The path attributes present many different vulnerabilities and risks.

Attribute Flags, Attribute Type Codes, Attribute Length

A BGP peer or an outsider could modify the attribute length or attribute
type (flags and type codes) so they did not reflect the attribute values
that followed.  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.  If the type code were modified,  the attribute
value could be interpreted as if it were the data type and value of a
different attribute.

The most likely result from modifying the attribute length, flags, or
type code would be a parse error of the UPDATE message.  A parse error
would cause the transmission of a NOTIFICATION message and the close of
the connection (see Event 28, below).  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 an outsider, i.e., it presents
no additional risk from a BGP peer.

ORIGIN

This field indicates whether the information was learned from IGP or EGP
information.  This field is used in making routing decisions, so there
is some small vulnerability in being able to affect the receiving BGP

Murphy                   Expires: December 2003                [Page 11]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

speaker's routing decision by modifying this field.

AS_PATH

A BGP peer or outsider could announce an AS_PATH that was not accurate
for the associated NLRI.

As it is legitimate for a BGP peer not to verify that a received AS_PATH
begins with the AS number of its peer, a malicious BGP peer could
announce a path that begins with the AS of any BGP speaker with little
impact on itself.  This could affect the receiving BGP speaker's
decision procedure and choice of installed route.  The malicious peer
could considerably shorten the AS_PATH, which will increase that route's
chances of being chosen, possibly giving the malicious peer access to
traffic it would otherwise not receive.  The shortened AS_PATH also
could result in routing loops, as it does not contain the information
needed to prevent loops.

It is possible for a BGP speaker to be configured to accept routes with
its own AS number in the AS path.  Such operational considerations are
defined to be "outside the scope" of the BGP specification, but the fact
that AS_PATHs can have loops means that implementations cannot
automatically reject routes with loops.  Each BGP speaker verifies only
that its own AS number does not appear in the AS_PATH.

Coupled with the ability to use any value for the NEXT_HOP, this gives a
malicious BGP speaker considerable control over the path traffic will
take.

Originating Routes

A special case of announcing a false AS_PATH occurs when the AS_PATH
advertises a direct connection to a specific network address.  An BGP
peer or outsider could disrupt routing to the network(s) listed in the
NLRI field by falsely advertising a direct connection to the network.
The NLRI would become unreachable to the portion of the network that
accepted this false route, unless the ultimate AS on the AS_PATH
undertook to tunnel the packets it was forwarded for this NLRI on toward
their true destination AS by a valid path.  But even when the packets
are tunneled to the correct destination AS, 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, forcing the
routers to handle (issue UPDATES, store, manage) the multiple fragments
rather than the single aggregate.  False originations for multiple

Murphy                   Expires: December 2003                [Page 12]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

addresses can result in routers and transit networks along the announced
route to become flooded with mis-directed traffic.

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 outsider modifying this field could disrupt the forwarding of
traffic between the two AS's.

In the case that the recipient of the message is an external peer of an
AS and the route was learned from another peer 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 at the NEXT_HOP address.  This affords the opportunity to
direct traffic at a router that may not be able to continue forwarding
the traffic.  A malicious BGP speaker can also use this technique to
force another AS to carry traffic it would otherwise not have to carry.
In some cases, this could be to the malicious BGP speaker's benefit, as
it could cause traffic to be carried long-haul by the victim AS to some
other peering point it shared with the victim.

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
outsider or an BGP peer, 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
BGP peers are free to choose the LOCAL_PREF as they wish, modification
of this field is a vulnerability with respect to outsiders only.

Murphy                   Expires: December 2003                [Page 13]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

ATOMIC_AGGREGATE

The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way
has aggregated several routes and advertised the aggregate NLRI without
the AS_SET formed as usual from the AS's in the aggregated routes'
AS_PATHs.  BGP speakers receiving a route with ATOMIC_AGGREGATE are
restricted from making the NLRI any more 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 a BGP peer or an outsider.

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.

3.1.5.4.  NLRI

By modifying or forging this field, either an outsider or BGP peer
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.

Event 28: If the UPDATE message is mal-formed (Withdrawn Routes Length,
Total Attribute Length, or Attribute Length that are improper, missing
mandatory well-known attributes, Attribute Flags that conflict with the
Attribute Type Codes, syntactic errors in the ORIGIN, NEXT_HOP or
AS_PATH, etc.), then the BGP speaker will bring down the connection,
release all associated BGP resources, delete all associated routes, run
its decision process and cause the state to return to Idle.  The
deletion of routes can cause a cascading effect of routing changes
propogating through other peers.  Also, optionally, an implementation
specific peer oscillation damping may be performed.  The peer
oscillation damping process can affect how soon the connection can be
restarted.  Consequently, the ability of an outsider to spoof this
message could cause wide-spread disruption of routing.  As a BGP speaker
has the authority to close a connection whenver it wants, this message
gives BGP speakers no opportunity to cause damage than they already had.

Murphy                   Expires: December 2003                [Page 14]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

3.2.  Vulnerabilities through Other Protocols

3.2.1.  TCP messages

BGP runs over TCP, listening on port 179.  Therefore, BGP is subject to
attack through attacks on TCP.

3.2.1.1.  TCP SYN

SYN flooding: BGP is as subject to the effects on the TCP implementation
of SYN flooding attacks as other protocols, and must rely on the
implementation's protections against this attack.

Event 14:  If an attacker were able to send a SYN to the BGP speaker,
then the legitimate peer's SYN would appear to be a second connection.
If the attacker were able to continue with a sequence of packets
resulting in a BGP connection (guessing the BGP speaker's choice for
sequence number on the SYN ACK, for example), then, the attacker's
connection and the legitimate peer's connection would appear to be a
connection collision.  Depending on the outcome of the collision
detection (i.e., the attacker chose a BGP identifier so as to win the
race), the legitimate peer's true connection could be destroyed.  The
use of [5] will counter this attack.

3.2.1.2.  TCP SYN ACK

Event 16: If an attacker were able to respond to a BGP speaker's SYN
before the legitimate peer, then the legitimate peer's SYN-ACK would
receive a empty ACK reply, causing the legitimate peer to issue a RST
that would break the connection.  The BGP speaker would bring down the
connection, release all associated BGP resources, delete all associated
routes and run its decision process.  This attack requires that the
attacker be able to predict the sequence number used in the SYN.  The
use of [5] will counter this attack.

This attack has no corollary from the legitimate BGP peer.

3.2.1.3.  TCP ACK

Event 17: If an attacker were able to spoof an ACK at the appropriate
time, then the BGP speaker would consider the connection complete, send
an OPEN (Event 17) and transition to the OpenSent state.  The arrival of
the legitimate peer's ACK would not be delivered to the BGP process, as
it would look like a duplicate packet.  This message, then, presents no
particular vulnerability to BGP.

Murphy                   Expires: December 2003                [Page 15]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

3.2.1.4.  TCP RST/FIN/FIN-ACK

Event 18: If an attacker were able to spoof a RST, the BGP speaker would
bring down the connection, release all associated BGP resources, delete
all associated routes and run its decision process.  If an attacker were
able to spoof a FIN, then data could still be transmitted, but any
attempt to receive would receive a notification that the connection is
closing.  In most cases, this results in the connection being placed in
an Idle state, but if the connection is in the OpenSent state at the
time, the connection returns to an Active state.  Spoofing a RST in this
situation requires an attacker to guess a sequence number that is in the
proper half of the sending window, generally an easier task than
guessing the exact sequence number so as to spoof a FIN.  The use of [5]
will counter this attack.

3.2.1.5.  DoS and DDos

Because the packet directed to TCP port 179 are passed to the BGP
process, that potentially resides on a slower processor in the router,
flooding a router with TCP port 179 packets is an avenue for DoS attacks
against the router.  No BGP protocol mechanism can defeat such attacks;
other mechanisms must be employed.

3.2.2.  Other supporting protocols

3.2.2.1.  Manual stop

Event 2: A manual stop event causes the BGP speaker to bring down the
connection, release all associated BGP resources, delete all associated
routes and run its decision process.  If the mechanism by which a BGP
speaker was informed of a manual stop were not carefully protected, the
BGP connection could be destroyed by an attacker. Consequently, BGP
security is secondarily dependent on the security of whatever protocols
are used to operate the platform.

3.2.2.2.  Timer events

Events 9-13:  The Keepalive, Hold, and Open Delay timers are critical to
BGP operation.  For example, if the Hold timer value were changed, the
remote peer might consider the connection unresponsive and bring the
connection down, releasing resources, deleting associated routes, etc.
Consequently, BGP security is secondarily dependent on the security of
the protocols by which the platform is managed and configured.

Murphy                   Expires: December 2003                [Page 16]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

4.  Security Considerations

This entire memo is about security, describing an analysis of the
vulnerabilities that exist in the BGP protocol.

Use of the mandatory-to-support mechanisms of [5] counter the message
insertion, deletion, and modification attacks and man-in-the-middle
attacks from outsiders.  If routing data confidentiality were desired
(there being some contraversy as to whether that is a desirable security
service), the use of IPSEC ESP could provide that service.

4.1.  Residual Risk

As cryptographic-based mechanisms, both [5] and IPSEC assume that the
cyrptographic algorithms are secure, that secrets used are protected
from exposure and are chosen well so as not to be guessable, that the
platforms are securely managed and operated to prevent break-ins, etc.

These mechanisms do not prevent attacks that arise from a router's
legitimate BGP peers.  There are several possible solutions to prevent a
BGP speaker from inserting bogus information in its advertisements to
its peers, i.e., from mounting an attack on a network's origination or
AS-PATH.

 (1)   Origination Protection: sign the originating AS.

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

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

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

Filtering is in use near some customer attachment points, but is not
effective near the Internet center.  The other mechanisms are still
controversial and are not yet in common use.

4.2.  Operational Protections

The primary usage of BGP is as a means to provide reachability
information to Autonomous Systems (AS) and to distribute external
reachability internally within an AS.  BGP is the routing protocol used

Murphy                   Expires: December 2003                [Page 17]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

to distribute global routing information in the Internet.  BGP is
therefore used by all major Internet Service Providers (ISP) and many
smaller providers and other organizations.

The role which BGP plays in the Internet puts BGP implementations in
unique conditions and places unique security requirements on BGP.  BGP
is operated over interprovider interfaces in which traffic levels push
the state of the art in specialized packet forwarding hardware and
exceed the performace capabilities of hardware implementation of
decryption by many orders of magnitude.  The capability of an attacker
using a single workstation with high speed interface to generate false
traffic for denial of service (DoS) far exceeds the capability of
software based decryption or appropriately priced cryptographic hardware
to detect the false traffic.  One means to protect the network elements
from DoS attacks under such conditions is to use packet based filtering
techniques based on relatively simple inspections of packets.  As a
result, for an ISP carrying large volumes of traffic, the ability to
packet filter on the basis of port numbers is an important protection
against DoS attacks, and a necessary adjunct to cryptographic strength
in encapsulation.

Current practice in ISP operation is to use certain common filtering
techniques to reduce the exposure to attacks from outside the ISP.  To
protect Internal BGP (IBGP) sessions, filters are applied at all borders
to an ISP network which remove all traffic destined for addresses of
network elements internal addresses (typically contained within a single
prefix) and the BGP port number (179).  Packets from within an ISP are
not forwarded from an internal interface to the BGP speaker's address on
which External BGP (EBGP) sessions are supported, or to a peer's EBGP
address if the BGP port number is found.  With appropriate consideration
in router design, in the event of failure of a BGP peer to provide the
equivalent filtering, the risk of compromise can be limited to the
peering session on which filtering is not performed by the peer or the
interface or line card on which the peering is supported.  There is
substantial motivation and little effort for ISPs to maintain such
filters.

These operational practices can considerably raise the difficulty for an
outsider to launch a DoS attack against an ISP.  Prevented from
injecting sufficient traffic from outside a network to effect a DoS
attack, the attacker would have to undertake much more difficult tasks,
such as compromise of the ISP network elements or undetected tapping
into physical media.

Murphy                   Expires: December 2003                [Page 18]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis        June 2003

5.  References

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

[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]  C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy and C. Orange,
     "Routing Policy System Security", RFC 2725,  December, 1999.

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

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

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

[8]  E. Rescorla and B. Korver, "Guidelines for Writing RFC Text on
     Security Considerations", work in progress, January 2003.
     available as
     <<draft-iab-sec-cons-03.txt>> at Internet-Draft shadow sites.

6.  Author's Address

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

Murphy                   Expires: December 2003                [Page 19]

Date: Wed, 25 Jun 2003 12:06:34 -0400 (EDT)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: old comments to Curtis's recommended addition to vulnerabilities draft
Cc: [email-masked], [email-masked]
Sender: [email-masked]

My response  to Curtis's message of Apr 3 don't appear on the idr mail
archive, so I am sending them now.

Fortunately, others made the same observations, although much more tersely
than what follows.

--Sandy

 Curtis, here are some comments on your recommended additions to the
 BGP Security Vulnerabilities Analysis draft.

 First, let me say that I agree with the "mandate TCP-MD5" part of the
 following:
   "Until such time as IPSEC is modified, there is little choice but to
    mandate TCP-MD5 implementation and recommend TCP-MD5 usage for BGP and
    discourage IPSEC usage for BGP."

 The fact that this version of BGP is supposed to document existing
 practice and the widespread deployment of TCP MD5 means that TCP MD5 is
 the only thing to mention in the current spec.

 But the "discourage IPSEC usage part" I don't agree with.

 You've brought up two points that I'd like to address:

 (1) IPSEC and filtering

   "These practical considerations yield the situation in which TCP-MD5,
   though cryptographic weak, far better serves ISP security needs than
   the cryptographicly much stronger IPSEC which makes packet filtering
   infeasible."

 This paragraph and other of your messages imply that using IPSEC
 obscures the port numbers.

 That's not the case when you are not doing confidentiality protection(^*).

 In IPSEC AH, the packet format leaves the port numbers in the clear.
 (I took the following format pictures directly from RFC 2402.)

                   BEFORE APPLYING AH
             ----------------------------
       IPv4  |orig IP hdr  |     |      |
             |(any options)| TCP | Data |
             ----------------------------

 In transport mode:

                   AFTER APPLYING AH
             ---------------------------------
       IPv4  |orig IP hdr  |    |     |      |
             |(any options)| AH | TCP | Data |
             ---------------------------------
             |<------- authenticated ------->|
                  except for mutable fields

 In tunnel mode:

           ------------------------------------------------
     IPv4  | new IP hdr* |    | orig IP hdr*  |    |      |
           |(any options)| AH | (any options) |TCP | Data |
           ------------------------------------------------
           |<- authenticated except for mutable fields -->|
           |           in the new IP hdr                  |

 The authentication data (keyed MAC, digital signature, etc.) is in the AH
 portion of the packet.

 Using IPSEC ESP with the null algorithm (i.e., authentication only) also
 leaves the port numbers in the clear.  Yes, I know it says "encrypted",
 but the null algorithm does nothing to the data.  (These pictures are
 from RFC2406)

                  BEFORE APPLYING ESP
             ----------------------------
       IPv4  |orig IP hdr  |     |      |
             |(any options)| TCP | Data |
             ----------------------------

 In transport mode:

                  AFTER APPLYING ESP
             -------------------------------------------------
       IPv4  |orig IP hdr  | ESP |     |      |   ESP   | ESP|
             |(any options)| Hdr | TCP | Data | Trailer |Auth|
             -------------------------------------------------
                                 |<----- encrypted ---->|
                           |<------ authenticated ----->|

 In tunnel mode:

             -----------------------------------------------------------
       IPv4  | new IP hdr* |     | orig IP hdr*  |   |    | ESP   | ESP|
             |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
             -----------------------------------------------------------
                                 |<--------- encrypted ---------->|
                           |<----------- authenticated ---------->|

 So the port numbers are visible in both cases.

 Maybe you meant that the filtering has to look down further into the
 packet to find the port numbers because they're offset from the usual
 position?  Are current hardware filtering mechanisms that rigid?

 Or perhaps the concern is that the authentication header is variable
 in size because the algorithms vary in how much authentication data
 they produce?  But the size of the AH header does not vary within one
 SPI - for any one SPI, the size of the AH is constant.  Can the filters
 not be configured individually for each peer?  Actually, if you were using
 the same algorithm for every peer, you wouldn't even have to adjust the
 filters - the AH header would be the same size for each peer.

 (^*) There have been discussion in the rpsec group of the need to
 protect the confidentiality of the routing data.  That doesn't
 necessarily mean using IPSEC ESP for confidentiality protection (it
 could mean doing the confidentiality protection within the protocol).
 Right now, the discussion is focussed on whether routing confidentiality
 is needed, with vehement speakers on both sides.  But it couldn't
 hurt to add your opinion about the layer at which that confidentiality
 should be provided.

 (2) IPSEC performance vs TCP MD5 performance

   "The
   capability of a single workstation with high speed interface to
   generate false traffic far exceeds the capability of software based
   decryption or appropriately priced cryptographic hardware.  From a
   practical standpoint, these networks are also better served by
   appropriate administrative care, filtering, and TCP-MD5 than by IPSEC."

 There's a suggestion here and in other of your messages that you
 believe that IPSEC processing is computationally much more expensive
 than TCP MD5 processing.

 I presume that you are concerned about the performance of the
 cryptographic parts of the two techniques, not the packet marshalling
 parts.  So let's compare the HMAC-MD5 processing supported in IPSEC AH
 with TCP MD5 processing.

 The TCP MD5 computation is:
    MD5 (packet contents, key)
    where packet contents = pseudo header, TCP header, TCP segment payload

 The HMAC-MD5 computation is:
    MD5 (key OR string, MD5 ( to-be-authenticated-text, key OR string)
    where "to-be-authenticated text" varies with IPSEC option used, as noted
    above

 Perhaps you are concerned about the fact that this looks like twice as
 many MD5 operations.  But that's not a true picture.  MD5 has to break
 up the to-be-authenticated input into 512 bit (bit, not byte) blocks and
 process the blocks separately.  So if your input is less than 512 bits
 (actually, it would have to be less than 448 bits, because of padding
 to position the key), then there's only one block to process.

 The output of MD5 is 16 bytes, so the HMAC outer MD5 always processes
 exactly one block of input.  So if your original to-be-hashed text is
 less than 448 bits, then the HMAC-MD5 runs the MD5 computation over
 two blocks.  Of course, if your payload is bigger than 448 bits (56
 bytes), the HMAC-MD5 runs the MD5 computation over at least 1 +
 (packetsizeinbits/512) blocks {the "at least" is because of that
 padding}.

 Since the payload being processed includes the TCP header
 and the ESP header (24 bytes and 10 bytes minimum, respectively) and
 the minimum BGP packet is a Keepalive at 19 bytes, it is pretty
 certain that most BGP packets, particularly BGP Update packets, will be
 larger than 56 bytes.

 So if the BGP packets were under 448 bits (56 bytes), HMAC would be
 twice as expensive as TCP MD5.

 If, however, the typical BGP packet were, say, 1024 bytes, then TCP MD5
 would process 1024/64 = 16 blocks and HMAC would process 17, so HMAC
 would be 6% more expensive.

 So IPSEC processing with HMAC might not be that much more expensive
 than TCP MD5, depending on the typical size of your BGP updates.

 (unless you're worried about the performance hit of doing the OR  :-))

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp-issues-00.txt
Date: Wed, 25 Jun 2003 10:53:40 -0400
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		: Issues in Revising BGP-4
	Author(s)	: A. Lange
	Filename	: draft-ietf-idr-bgp-issues-00.txt
	Pages		: 180
	Date		: 2003-6-24
	
This document records the issues discussed and the consensus reached
in the Interdomain Routing (IDR) Working Group during its efforts to
revise and bring up to date the base specification for the BGP-4
protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-issues-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also 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-bgp-issues-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp-issues-00.txt".
	
NOTE:	The mail server at ietf.org 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-bgp-issues-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-issues-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Date: Tue, 24 Jun 2003 06:56:25 -0400
Subject: [Idr] I-D ACTION:draft-weis-sobgp-certificates-00.txt
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Secure Origin BGP (soBGP) Certificates
	Author(s)	: B. Weis
	Filename	: draft-weis-sobgp-certificates-00.txt
	Pages		: 38
	Date		: 2003-6-23
	
This document describes the format of digital certificates that are 
used by the Secure Origin BGP (soBGP) extensions to BGP, as well as 
acceptable use of those certificates. Included are certificates 
providing authentication, authorization, and policy distribution.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-weis-sobgp-certificates-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also 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-weis-sobgp-certificates-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-weis-sobgp-certificates-00.txt".
	
NOTE:	The mail server at ietf.org 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-weis-sobgp-certificates-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-weis-sobgp-certificates-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--

Date: Mon, 23 Jun 2003 18:16:46 +0200
From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: Daniel Golding <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-raszuk-idr-ibgp-auto-mesh-00.txt
Sender: [email-masked]

Daniel,

> A few comments:
> 
> 2. B - Full iBGP mesh between all members of confederation
> 
> should probably read "Full iBGP mesh between all members of a
> confederation sub-as"

Correct.

> Also...
>     Another operational benefit of using IBGP auto mesh is the ease of AS
>     renumbering or merges/migrations. It is generally very difficult to
>     manually change the AS number on all BGP speakers in a short
>     maintenance window. With the automation such task would be much
>     easier to accomplish.
> 
> Ease or difficulty of AS renumbering is hugely implementation specific.
> On a Juniper platform, its pretty easy with an Expect or Perl script.
> On a Cisco platform, much more difficult. Its not so much about having
> to "touch" all the routers - thats what scripts are for, in any network
> large enough to be concerned with this. Its the device behavior when
> you change the AS number. Of course, the other large difficulty is
> communication/interaction with peers and customers, and use of the
> various (and confusingly non-standard) local-as features.
> 
> Perhaps I'm missing how the automation aspect would make iBGP AS
> renumbering easier. Because you don't have to specify the remote-as of
> each iBGP neighbor, just your own?

Yes that one as well as with single sided signalling implementation
reflector announcements the amout of changes one would need to execute
synchronously on both sides of any given peering is significantly
reduced.

> The other issue with this document is the contention that there is a
> frequent complaint to vendors that a full IBGP mesh is too difficult to
> maintain. Most folks have little difficulty with this, and if they do,
> their general path is to shift to a more scalable BGP architecture.

Well yes, but the main motivation is to maintain multiple planes of IBGP
meshes - each for different AFI/SAFI combination. With just ipv4 unicast
I am not worried and would maybe even agree of the limited use of
proposed automation. But for current other AFI/SAFIs as well as quite a
number of them comming peer's auto discovery does make sense.

> Finally, please consider that a poor implementation of this draft could
> lead to difficult to isolate (and perhaps intermittent) routing loops
> in the effected network.

It would help if you could provide some examples so I/we could update
the draft in a such a way to help implementors avoid accidental mistakes
;-).

R.

> Thanks,
> Daniel Golding

Date: Mon, 23 Jun 2003 09:59:01 -0400
Subject: Re: draft-raszuk-idr-ibgp-auto-mesh-00.txt
Cc: [email-masked]
To: [email-masked]
From: Daniel Golding <[email-masked]>
Sender: [email-masked]

A few comments:

2. B - Full iBGP mesh between all members of confederation

should probably read "Full iBGP mesh between all members of a 
confederation sub-as"

Also...
    Another operational benefit of using IBGP auto mesh is the ease of AS
    renumbering or merges/migrations. It is generally very difficult to
    manually change the AS number on all BGP speakers in a short
    maintenance window. With the automation such task would be much
    easier to accomplish.

Ease or difficulty of AS renumbering is hugely implementation specific. 
On a Juniper platform, its pretty easy with an Expect or Perl script. 
On a Cisco platform, much more difficult. Its not so much about having 
to "touch" all the routers - thats what scripts are for, in any network 
large enough to be concerned with this. Its the device behavior when 
you change the AS number. Of course, the other large difficulty is 
communication/interaction with peers and customers, and use of the 
various (and confusingly non-standard) local-as features.

Perhaps I'm missing how the automation aspect would make iBGP AS 
renumbering easier. Because you don't have to specify the remote-as of 
each iBGP neighbor, just your own?

The other issue with this document is the contention that there is a 
frequent complaint to vendors that a full IBGP mesh is too difficult to 
maintain. Most folks have little difficulty with this, and if they do, 
their general path is to shift to a more scalable BGP architecture.

Finally, please consider that a poor implementation of this draft could 
lead to difficult to isolate (and perhaps intermittent) routing loops 
in the effected network.

Thanks,
Daniel Golding

Date: Sun, 22 Jun 2003 23:07:49 +0200
From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: [email-masked]
Cc: [email-masked]
Subject: draft-raszuk-idr-ibgp-auto-mesh-00.txt
Sender: [email-masked]

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

--------------BC70003E6E923610524F5015
Content-Type: text/plain; charset=us-ascii;
 name="draft-raszuk-idr-ibgp-auto-mesh-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-raszuk-idr-ibgp-auto-mesh-00.txt"

Network Working Group                             Robert Raszuk (Editor)
Internet Draft                                           Chandra Appanna
Category: Standards Track                             Cisco Systems, Inc
Expires: December 2003                               Pedro Roque Marques
                                                   Juniper Networks, Inc
                                                               June 2003
                             IBGP Auto Mesh
                 draft-raszuk-idr-ibgp-auto-mesh-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsolete 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".

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

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

Abstract

   The distribution of BGP routing information within an autonomous
   system requires all border routers to be fully meshed. This
   constitutes a significant operational problem in terms of
   configuration management.

   This has led to the wide-spread adoption of route reflection
   [RFC2796], primarily in order to reduce the number systems which
   configuration must be modified in order to introduce or remove a new
   internal BGP speaker. Route reflection, however, implies with it
   information reduction which is not always desired.

   This document defines a discovery mechanism that is designed to
   address the problem of introducing (or removing) a BGP speaker into
   an iBGP mesh without implying any other behavior change when compared

Raszuk, et. all             Expires Dec 2003                    [Page 1]

Internet Draft               IBGP Auto Mesh                    June 2003

   to manual configuration.

1. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2. Introduction

   One of the most common complains received from operators is the
   comment on complexities associated with configuration of BGP meshes.

   This draft attempts to make this claim a history by proposing auto
   discovery of internal BGP peers via configuration information
   flooding as well as a set of procedures which would allow to
   establish IBGP sessions automatically.

   It should be noted that for easy and fast deployment flooding of
   information is piggybacked on top of existing IGP mechanisms. This
   feature is designed with flooding mechanism transparency in mind.
   When new and more effective flooding protocol is introduced and
   deployed into production networks it should be with no additional
   effort on the BGP component to migrate the flooding from IGPs to such
   a new protocol.

   Unlike other attempts in this area it does not relay on any
   management station. Also it keeps all BGP functional and transport
   mechanism unchanged.

   The particular piece of functionality this draft addresses is
   distribution of related local configuration to all routers within
   flooding scope as well as usage of this information in establishment
   of IBGP peering.

   Today we can observe a number of network topologies where IBGP is
   being used to distribute routing information between BGP speakers:

   A - Full iBGP mesh between all routers in the AS
   B - Full iBGP mesh between all members of confederation
   C - Route reflectors clusters peering
   D - Full iBGP mesh between all PEs/ASBRs and BGP free core

   In the operation section we will describe how this draft can automate
   IBGP peering in all of the above scenarios.

Raszuk, et. all             Expires Dec 2003                    [Page 2]

Internet Draft               IBGP Auto Mesh                    June 2003

   Another very important observation is that today BGP often play other
   roles than just distribution of IPv4 reachability information. With
   introduction of multiprotocol BGP extensions [RFC2858] BGP speakers
   may be configured to keep and maintain data belonging to multiple
   address families.

   In multiprotocol environments, the IBGP mesh for one address family
   may not match the mesh for a different address family as in the case
   where different route reflectors are used for different applications.
   This draft will also automate IBGP session establishment with
   matching AFIs taken into consideration of the auto discovered peers.

   Historically introduction of route reflection drastically removed the
   need for full mesh manual configuration of all BGP speakers in a
   domain. It also reduced the number of TCP session each BGP speakers
   needed to handle.

   Another characteristics of route reflection is their ability to
   eliminate number of advertised paths to a given peer to only best
   path from reflector's point of view.

   While this last point was originally thought of a benefit (at least
   from the perspective of best effort ipv4 reachability) today's
   applications require a bit more granular path's classification and
   features like IBGP multipath is becoming already a production
   requirement. To keep the former benefit of reduced configuration or
   low number of TCP sessions approaches like add-paths draft [ADD-PATH]
   are being currently under investigation.

   It should be noticed that idea presented in this draft eliminates any
   manual configuration for full mesh BGP peering. Also modern operating
   systems implementations can hold and maintain much more TCP sessions
   that their predecessors could. Therefore by auto meshing all or
   selected address families on BGP speakers the need for route
   reflection becomes obsolete in some cases.

   In order to reduce amount of information distributed across IBGP
   sessions to only a required subset outbound route filtering
   techniques could be employed [IDR-ORF].

   Another operational benefit of using IBGP auto mesh is the ease of AS
   renumbering or merges/migrations. It is generally very difficult to
   manually change the AS number on all BGP speakers in a short
   maintenance window. With the automation such task would be much
   easier to accomplish.

Raszuk, et. all             Expires Dec 2003                    [Page 3]

Internet Draft               IBGP Auto Mesh                    June 2003

3. The BGP Auto Discovery TLV

   This section proposes an encoding to be used in IPv4 & IPv6 networks.

   The BGP Auto Discovery TLV is defined as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   TLV Type    |    Length     |     FLOODING RESERVED     |F|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        BGP Identifier                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  FRAG |     BGP  RESERVED     |        16 bit CHECKSUM        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Autonomous System(s) or confederation sub-AS(s) sub-TLV    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             IPv4/IPv6  Peering Address sub-TLV                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             AFI/SAFI for mesh topologies sub-TLV              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          AFI/SAFI for reflection topologies sub-TLV           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Old BGP Identifier sub-TLV (opt)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1. BGP Auto Discovery TLV

3.1. TLV Type

   BGP Auto Discovery TLV is proposed to be carried in OSPF Router
   Information LSA [LINDEM1] with area scope or domain wide scope
   depending on the configuration. Details describing OSPF specifics and
   encoding will be described in [OSPF-BGP].

   In ISIS BGP Auto Discovery TLV is proposed to be carried as a new TLV
   with flooding scope local to the intra area or domain wide. Details
   describing ISIS specific encoding will be described in [ISIS-BGP].

   The selection of ISIS and OSPF for flooding is mostly based on the
   fact that those protocols already have a flooding mechanism which can
   be reused for the purpose of required in this proposal information
   distribution.

   It is a strong design goal that flooding of BGP Auto Discovery TLV
   can be realized over any other protocol when such is deployed and
   when it can provide further benefits. For example: selective groups
   of destinations or disjoined information distribution trees per

Raszuk, et. all             Expires Dec 2003                    [Page 4]

Internet Draft               IBGP Auto Mesh                    June 2003

   AFI/SAFI.

   In cases of multiple bgp processes running on a router each BGP
   process should send it's own BGP Auto Discovery TLV with a different
   BGP Identifier.

3.2. TLV Length

   Length  - Total length in octets of this TLV

   The minimum TLV length can be 10 octets.

   When a size of the TLV reaches 255 octets TLV fragmentation needs to
   occur. A special "FRAG" 4 bit counter has been allocated in the BGP
   Control Information's first octet for unlikely cases where BGP Auto
   Discovery TLV needs to be splitted across multiple TLVs for a given
   BGP speaker.

   It is estimated that the average size of BGP Auto Discovery TLV in
   today's production environments will be anywhere from 30-50 octets.

3.3. Global flooding flags

   This comprises of one or more global for given BGP Auto Discovery TLV
   flags related to flooding. Currently defined are the following flags:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   TLV Type    |    Length     |     FLOODING RESERVED     |F|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 2. Value field of global flags

   Symbol          Definition

   F               Flooding scope
   D               Down Bit

   "F" {flooding} flooding scope of this TLV. When set domain wide
       flooding scope is required, when not set TLV should not be
       flooded into other areas or levels. Default not set
       indicating area/level wide flooding only.

   "D" {down} down bit set by ISIS when leaked to other areas/levels.

   When advertised BGP Auto Discovery TLV for a given BGP Identifier
   does not contain any sub-TLVs it should be interpreted as an implicit

Raszuk, et. all             Expires Dec 2003                    [Page 5]

Internet Draft               IBGP Auto Mesh                    June 2003

   withdraw of any previously advertised BGP Auto Discovery TLV for a
   given BGP Identifier.

   This is intentional not to duplicate BGP capabilities in this
   message. BGP operation in session establishment to auto discovered
   peers should remain without any changes as compared to today's
   operation.

   All reserved flags and not defined yet should be set to zeros.

3.4. BGP Identifier

   4 octet value set to BGP ID [IDR-BGP4]. When BGP ID is being changed
   on a BGP speaker next BGP Auto Discovery TLV announced should contain
   "Old BGP ID sub-TLV". Presence of this sub-TLV is an indication that
   the received BGP Auto Discovery TLV is being related to previously
   flooded BGP information with the contained in this sub-TLV BGP
   Identifier.

3.5. BGP Control Information

   The below 4 octets with BGP specific control information has been
   defined:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  FRAG |     BGP  RESERVED     |        16 bit CHECKSUM        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3 BGP Control Information

3.6. Fragmentation counter

   When a size of the BGP Auto Discovery TLV reaches 255 octets TLV
   fragmentation needs to occur. A special "FRAG" 4 bit counter has been
   allocated for unlikely cases where BGP Auto Discovery TLV needs to be
   splitted across multiple TLVs for a given BGP speaker.

3.7. Checksum

   Depending on the flooding protocol being utilized BGP may be
   receiving identical information periodically. To allow easy
   determination if the content of the TLV has changed for a given BGP
   Identifier 16 bit checksum has been defined. Checksum should be
   computed from the content of the entire BGP Auto Discovery TLV
   (before potential fragmentation) excluding first 4 octets of the TLV.

Raszuk, et. all             Expires Dec 2003                    [Page 6]

Internet Draft               IBGP Auto Mesh                    June 2003

4. The BGP Auto Discovery sub-TLVs

   In following subsections we will focus on describing each of the
   sub-TLVs directly related to BGP operation. The format of each sub-
   TLV will be following:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            RESERVED           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value(s)...                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 4. BGP Sub-TLV

4.1. BGP Autonomous System(s) sub-TLV

   Type        One octet field set to value of 1.
   Length      One octet field that indicates the length of the value
               portion in octets.
   Reserved    Two octet field reserved for flags and sub-TLV control
   Value       4 octet BGP Autonomous System Number(s) [IDR-BGP4]
               [IDR-AS4] or confederation sub-AS [RFC1965].

   Advertising multiple autonomous system numbers may be required during
   AS renumbering and merges with other ASes. Therefore this proposal
   does not limit advertisement to a single AS value per BGP speaker.

   The peering attempt should be made only to those peers which match
   locally configured AS number or numbers (multi-as migration case).

   When confederation is used sub-AS will limit the scope of full mesh
   peering only to a given sub-AS even if flooding scope is common to
   all sub-ASes. Usage of route reflectors within each confederation
   sub-AS is also supported.

4.2. IPv4 Peering Address sub-TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |           RESERVED          |F|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      IPv4 Peering Address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 5. BGP IPv4 Peering Sub-TLV

Raszuk, et. all             Expires Dec 2003                    [Page 7]

Internet Draft               IBGP Auto Mesh                    June 2003

   Type        One octet field set to value of 2.
   Length      One octet field that indicates the length of the value
               portion in octets.
   Reserved    Set to all zeros
   Flag        "F"   - Force new peering. Default not set.
   Value       4 octet ipv4 peering address

   This address will be used by BGP speakers as a destination in BGP
   Open message. Sending a BGP Auto Discovery TLV with new peering
   address is an explicit withdraw of the previously advertised one.

   When such a messages is received old peering should remain intact
   when "F" flag is not set (default). When session is cleared manually
   or IGP reachability to the old peering address disappears new peering
   address should be used.

   When "F" flag is set new peering address should be used immediately
   and current BGP session to the peer restarted.

4.3. IPv6 Peering Address sub-TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            RESERVED         |F|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                      IPv6 Peering Address                     |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 6. BGP IPv6 Peering Sub-TLV

   Type        One octet field set to value of 3.
   Length      One octet field that indicates the length of the value
               portion in octets.
   Reserved    Set to all zeros
   Flag        "F"   - Force new peering. Default not set.
   Value       16 octet ipv6 peering address

   This address will be used by BGP speakers as the destination in BGP
   Open message. Sending a BGP Auto Discovery TLV with new peering
   address is an explicit withdraw of the previously advertised one.

   When such a messages is received old peering should remain intact
   when "F" flag is not set (default). When session is cleared manually
   or IGP reachability to the old peering address disappears new peering

Raszuk, et. all             Expires Dec 2003                    [Page 8]

Internet Draft               IBGP Auto Mesh                    June 2003

   address should be used.

   When "F" flag is set new peering address should be used immediately
   and current BGP session to the peer restarted.

   When both IPv4 & IPv6 peering addresses are present it is up to the
   implementation to decide on the peering address selection.

4.4. AFI/SAFI for mesh topologies sub-TLV

   Type        One octet field set to value of 4.
   Length      One octet field that indicates the length of the value
               portion in octets.
   Reserved    Set to zero
   Value       2 octet Address Family Identifier(s) [RFC2858]
               1 octet Subsequent Address Family Identifier [RFC2858]
               1 octet Per AFI/SAFI Flags

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            RESERVED           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Address Family Identifier 1 |     SAFI 1    |   RESERVED  |O|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                .....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Address Family Identifier 1 |     SAFI 2    |   RESERVED  |O|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 7. Value field of BGP AFI/SAFI mesh topologies sub-TLV

   Sub-TLV Value Flags:

   "O"  - Originator or EBGP speaker

   Originator flag:

   IBGP sessions in a full or partial mesh topology are required to
   directly peer with those BGP speakers which originate routes or which
   maintain EBGP sessions. This flag should be used to mark such a bgp
   speakers when advertising BGP Auto Discovery TLV. On reception this
   flag should be used for selection or required IBGP peering
   candidates.

   It is important to note that the actual state of EBGP session or
   present or not in the routing table of redistribuited prefix is not
   relevant and this bit should be set always when EBGP session or local

Raszuk, et. all             Expires Dec 2003                    [Page 9]

Internet Draft               IBGP Auto Mesh                    June 2003

   route origination is configured.

4.5. AFI/SAFI for reflection topologies sub-TLV

   Type        One octet field set to value of 5.
   Length      One octet field that indicates the length of the value
               portion in octets.
   Reserved    Set to zero
   Value       2 octet Address Family Identifier(s) [RFC2858]
               1 octet Subsequent Address Family Identifier [RFC2858]
               1 octet Per AFI/SAFI Flags

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            RESERVED           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Address Family Identifier N |     SAFI N    |  RESERVED |R|O|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Cluster ID  N                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ......
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Address Family Identifier X |     SAFI X    |  RESERVED |R|O|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Cluster ID X                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 8. Value field of AFI/SAFI reflection sub-TLV

   Sub-TLV Value Flags:

   "O"  - Originator or EBGP speaker
   "R"  - Route Reflector for given AFI-SAFI/Cluster_ID combination

   See section "AFI/SAFI for mesh topologies sub-TLV" for explanation of
   "O" flag.

   "R"  - Route reflector flag.

   When "R" flag is set BGP speaker announcing this TLV is configured
   for route reflection function for a given AFI/SAFI combination. In
   addition when "R" bit is set the following cluster ID 4 octet value
   [RFC2796] indicates cluster id assigned for a given reflection
   function.

   Clients of route reflection will send their cluster ID lists assigned
   to each AFI/SAFI without "R" bit set. When client wishes to indicate

Raszuk, et. all             Expires Dec 2003                   [Page 10]

Internet Draft               IBGP Auto Mesh                    June 2003

   the request to become a member of all possible cluster_ids for given
   AFI/SAFI combination within a flooding scope of his BGP Auto
   Discovery TLV the "R" bit should not be set and the value of
   cluster_id associated with the AFI/SAFI should be set to all zeros.

   To allow chain of route reflection (hierarchy) it is perfectly valid
   for a BGP speaker to have for a given AFI/SAFI a "R" bit set for one
   cluster IDs (ie to perform a route reflection function) and in the
   same time for other cluster ID values be a client of other route
   reflectors (R bit not set).

   Network designs of reflection within confederations are also
   supported.

   At this time of publication authors will also leave the implementor's
   freedom to allow single sided signaling only from route reflectors to
   the clients. When client receives the BGP Auto Discovery TLV which
   contains the interesting cluster ID and has R bit set it can initiate
   BGP Open without injecting any information about his own BGP
   configuration in the reflection topologies into the network.

4.6. Old BGP Identifier sub-TLV

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            RESERVED           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Old BGP Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 9. Old BGP Identifier Sub-TLV

   Type        One octet field set to value of 6.
   Length      One octet field that indicates the length of the value
               portion in octets.
   Reserved    Set to all zeros
   Value       4 octet BGP Identifier [IDR-BGP4].

   When BGP Identifier is being replaced with a new value the "Old BGP
   Identifier" sub-TLV must be present and contain a previously
   advertised BGP ID for this given BGP speaker.

Raszuk, et. all             Expires Dec 2003                   [Page 11]

Internet Draft               IBGP Auto Mesh                    June 2003

5. Operation

   Each BGP speaker configured to participate in an IBGP auto mesh
   should pass to flooding component BGP Auto Discovery TLV with it's
   own local configuration dependent information.

   On the receive side, a cache should be maintained by BGP with all
   received information from flooding component about other BGP speakers
   announcing their BGP Auto Discovery TLVs in a given area or domain.

   IBGP auto mesh configuration should allow for per address family and
   subsequent address family disjoint topologies granularity.

   When multiple AFI/SAFI pairs match on any two BGP speakers only one
   IBGP session should be attempted. Regular BGP capabilities will be
   used to negotiate given AFI/SAFI mutual set. Never less AFI/SAFI
   granularity is required to allow for very fine grade disjoint
   topologies for different types of distributed by BGP information.

5.1. Full mesh topologies

   When operator finds required to fully or partially mesh BGP speakers
   "AFI/SAFI for mesh topologies" sub-TLV should be utilized.

   BGP speakers may be eligible for origination of routes or may be
   configured for EBGP peering. We will call them "O" flag eligible (see
   section "AFI/SAFI for mesh topologies sub-TLV").

   BGP speakers "O" flag eligible may establish session with any other
   BGP speaker if passing all peering criteria for a given AFI/SAFI.

   BGP speakers "O" flag not eligible (ex: P routers) should not
   establish IBGP peering to any other "O" flag not eligible BGP
   speakers.

   One possible example of such a configuration could be vpnv4 AF
   connecting all PEs in a domain into a full IBGP mesh.

   After reception of peers BGP Auto Discovery TLV BGP speaker should
   check for autonomous system numbers match as well as AFI/SAFI
   identifiers match. Positive results from the above actions should
   trigger a standard process of connection establishment attempt with
   the peer.

   It is also highly recommened that a local range of allowed peering
   addressed be also maintained and consulted at each attempt to
   establish a new IBGP peering.

Raszuk, et. all             Expires Dec 2003                   [Page 12]

Internet Draft               IBGP Auto Mesh                    June 2003

   BGP Auto Discovery TLV may be area/level or domain wide in full mesh
   topologies. The default should be area/level wide flooding.

5.2. Confederations

   To automate iBGP full mesh establishment in each confederation sub-AS
   each confederation member should advertise it's confederation sub-AS
   instead of main AS (confederation_id) it is a member of in BGP
   Autonomous System(s) sub-TLV.

   There could be two cases here:

   A) Confederation sub-ASes strictly contained within flooding scope
   B) Confederation sub-ASes unrelated to flooding topology

   Case (A) BGP auto discovery TLV flooding scope should be limited to
   one area/level.

   Case (B) BGP auto discovery TLV flooding scope should be domain wide
   and use of Auto Peering Range(s) sub-TLV is highly recommended.

   In the cases where reflectors are used within each confederation
   rather then direct peering "AFI/SAFI for reflection topologies sub-
   TLV" should be used instead of "AFI/SAFI for mesh topologies sub-
   TLV".

5.3. Route Reflectors

   When operator wishes to automate establishment of BGP sessions to
   route reflectors the only additional information required is
   configuration of at least one identical cluster id on both route
   reflector as well as on route reflector client. As mentioned earlier
   even this requirement could be relaxed by implementation supporting
   single sided signaling of reflector capabilities. The drawback in
   such a case is that route reflector injecting his BGP Auto Discovery
   TLV would also need to be configured with an additional information
   allowing to distinguish BGP Open requests coming from clients as well
   as those coming from non clients based on the peering address range
   and mark such a peering accordingly.

   Routers or devices designated to serve route reflector function shall
   advertise their "AFI/SAFI for reflection topologies" sub-TLV with "R"
   flag set as well as with their cluster id(s) attached.

   If IBGP session will be established between route reflector ("R" flag
   set) and non route reflector BGP speaker ("R" flag not set) who's
   specific AFI/SAFI cluster ID matches on at least one entry with given
   route reflector cluster id it should be marked as route reflector

Raszuk, et. all             Expires Dec 2003                   [Page 13]

Internet Draft               IBGP Auto Mesh                    June 2003

   client.

   BGP speakers which are not to act as route reflectors ("R" flag not
   set) and do not have configured cluster id value(s) indicating their
   designation as route reflector clients would attempt to establish
   regular IBGP peering to other BGP speakers in the domain (per rules
   described in section "Full mesh topologies").

   An implementation may also allow the additional route reflection
   client to client full mesh. This is left for the implementor's choice
   to be enabled with a configuration option.

   Route reflection chaining (reflector hierarchy) is fully supported.
   Route reflector server may advertise for a given AFI/SAFI his ability
   to reflect routes for one set of cluster ID(s) ("R" bit set) and in
   the same time for the same AFI/SAFI value submit a list of cluster
   IDs without "R" bit set indicating the willingness to become a
   regular client on servers eligible to reflect those cluster ID(s).

   When client wishes to indicate the request to become a member of all
   possible cluster_ids for given AFI/SAFI combination within a flooding
   scope of his BGP Auto Discovery TLV the "R" bit should not be set and
   the value of cluster_id associated with the AFI/SAFI should be set to
   all zeros.

6. Local peering verification

   It is highly recommended for an implementation to support local
   configuration of all possible remote peering address ranges expected
   to be received via BGP Auto Discovery TLV messages.

   In particular this can protect from configuration mistakes when
   peering in a full or partial mesh and setting flooding scope
   accidentally to domain wide.

   In this version of the draft the decision has been made not to flood
   this local peering range list to the remote peers. Such a flooding
   could further protect from even sending BGP Open message when given
   bgp speaker own peering address does not match received list from a
   peer.

   That decision can be revisited in the future versions of this work
   and new sub-TLV for flooding this information can be added.

Raszuk, et. all             Expires Dec 2003                   [Page 14]

Internet Draft               IBGP Auto Mesh                    June 2003

7. Deployment Considerations

   The idea described in this document should not present any deployment
   challenges. It is expected that all implementations would still allow
   manual neighbor establishments which in fact could be complimentary
   and co-existing to the IBGP auto mesh.

   In addition BGP Auto Discovery TLV exchange could be enabled just for
   informational purposes while provisioning would remain manual before
   operational teams get familiar with new functionality.

   Incremental deployment with enabling just a few routers to advertise
   BGP Auto Discovery TLV while maintaining manual configuration based
   peering with the rest of the network is supported. An implementation
   may also allow for mixed peering for example reflector client being
   configured automatically while reflector's clusters itself being
   interconnected manually.

8. IANA Considerations

   There are no IANA considerations required in this document.
   Extensions to ISIS [ISIS-BGP] & OSPF [OSPF-BGP] will have their own
   IANA consideration sections.

9. Security Considerations

   This document fully relies on authentication mechanism that an
   implementation of BGP MUST support as specified in [RFC2385]. The
   authentication provided by this mechanism could be done on a per peer
   basis.

   It also relies on security of flooding mechanism being used for
   information distribution.

Raszuk, et. all             Expires Dec 2003                   [Page 15]

Internet Draft               IBGP Auto Mesh                    June 2003

10. Acknowledgments

   I would like to express our thanks to Alvaro Retana, Keyur Patel,
   Barry Friedman & Gargi Nalawade for their valuable comments.

11. Normative References

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

   [RFC2434]  Narten, T., Alvestrand, H., "Guidelines for Writing an
       IANA Considerations Section in RFCs", RFC2434, October 1998.

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

12. Informative References

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

   [IDR-BGP4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
       (BGP-4)", Work in Progress (draft-ietf-idr-bgp4-21.txt), April
       2003.

   [RFC1965]  Traina, P., "Autonomous System Confederations for BGP",
       RFC 1965, June 1996.

   [RFC2796]  Bates, T., Chandra, R., and Chen, E., "BGP Route
       Reflection An Alternative to Full Mesh IBGP", RFC 2796, April
       2000.

   [RFC2858]  Bates, T., Rekhter, Y., Chandra, R., Katz, D.,
       "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000

   [IDR-ORF]  Chen, E., Rekhter, Y., "Cooperative Route Filtering
       Capability for BGP-4", draft-ietf-idr-route-filter-08.txt

   [IDR-AS4]  Vohra, Q., Chen, E., "BGP support for four-octet AS number
       space" draft-ietf-idr-as4octets-06.txt, January 2003

   [LINDEM1]  Lindem, A. at all, "Extensions to OSPF for Advertising
       Optional Router Capabilities", draft-lindem-ospf-cap-00.txt, May
       2003

   [ADD-PATH] Walton, D.,at all, "Advertisement of Multiple Paths in

Raszuk, et. all             Expires Dec 2003                   [Page 16]

Internet Draft               IBGP Auto Mesh                    June 2003

       BGP" draft-walton-bgp-add-paths-01.txt

   [ISIS-BGP] Raszuk, R., "ISIS Extensions for BGP Peer Discovery" ,
       draft-raszuk-isis-bgp-peer-discovery-00.txt, June 2003 Work in
       progress

   [OSPF-BGP] Raszuk, R., "OSPF Extensions for BGP peer discovery",
       draft-raszuk-ospf-bgp-peer-discovery.txt, Work in Progress

13. Authors' Addresses

      Robert Raszuk
      Cisco Systems, Inc.
      Al. Jerozolimskie 146C
      02-305 Warsaw, Poland
      E-mail: [email-masked]

      Pedro Marques
      Juniper Networks, Inc.
      1194 N. Mathilda Ave.
      Sunnyvale, CA 94089
      E-mail: [email-masked]

      Chandrashekhar Appanna
      Cisco Systems, Inc
      170 West Tasman Dr
      San Jose, CA 95134
      E-mail: [email-masked]

14. IPR Notices

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can

Raszuk, et. all             Expires Dec 2003                   [Page 17]

Internet Draft               IBGP Auto Mesh                    June 2003

   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

15. Terms of Use

   Cisco has a pending patent which relates to the subject matter of
   this Internet Draft.  If a standard relating to this subject matter
   is adopted by IETF and any claims of any issued Cisco patents are
   necessary for practicing this standard, any party will be able to
   obtain a license from Cisco to use any such patent claims under
   openly specified, reasonable, non-discriminatory terms to implement
   and fully comply with the standard.

16. Full Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the  purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Raszuk, et. all             Expires Dec 2003                   [Page 18]

--------------BC70003E6E923610524F5015--

Date: Fri, 20 Jun 2003 09:05:49 +0530
From: Manav Bhatia <[email-masked]>
Subject: Re: draft-bhatia-ecmp-routes-in-bgp-00.txt
To: Erblichs <[email-masked]>, [email-masked]
Reply-To: Manav Bhatia <[email-masked]>
Sender: [email-masked]

Erblichs,

----- Original Message ----- 
From: "Erblichs" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, June 20, 2003 12:33 AM
Subject: draft-bhatia-ecmp-routes-in-bgp-00.txt

> Section 4. Advertisement of ECMP BGP routes
>
> 1) Paragraph 3 assumes that all ECMP capable speakers are equal.
>
> What is the result when two ECMP capable speakers with different
> ECMP granualar capabilities (say 3 vs 16 ECMP routes) exchange
> this new attribute? Should the selection process of "Next Hops"
> be sequential in nature?

"ECMP granular capabilities" isn't very clear to me? Are you referring to
the number of equal cost routes that can be injected into the FIB?

If yes, then its strictly an implementation specific issue and BGP can
randomly select the next-hops it injects into the FIB.

>
> Randomizing the selection process may allow two or more simultaneous
> flows
> from different BGP speakers for better load balancing. Sequential
> selection
> may under-utilize the bandwidth of the latter "Next Hops", given that
> their
> are more next hops than ECMP capable flows.
>
>
> 2) Nit.. Length of next Hop Network Address
>
> Should IPv4 length be specified since you are specifying IPv6 lengths?

I assume that you are referring to the "Length of the Next Hop" field.

This has been included to keep the attribute as generic as possible and to
be able to accommodate other different Network Layer Protocols.

Regards,
Manav

P.S.

You need to be subscribed to idr-post in order to send mails to
[email-masked].

> Mitchell Erblich
> Sr Software Engineer

Date: Tue, 17 Jun 2003 21:14:26 -0700 (PDT)
From: Mareline Sheldon <[email-masked]>
Subject: FW: BGP anomalous Behaviour
To: [email-masked]
Sender: [email-masked]

Found this interesting mail from the archives.

Would love to hear from others on this.

Regards,
Mareline S.
----- Original Message ----- 
From: "Tulip Rasputin" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, May 20, 2003 12:25 PM
Subject: BGP anomalous Behaviour

> Hello,
> I understand that this message is more pertinent to the BGP Working Group but since i am
unable to
> send mails to that WG i am posting it here - as its anyway related to routing.
> 
> Suppose a BGP Peer receives three UPDATEs for the same prefix (say a.b.c.d/mask) with the
> following attributes:
> 
> Route 1:
> AS_PATH 10 100
> MED 10
> NEXT_HOP NH1
> calculated IGP cost to reach the next-hop NH1 is 6
> 
> Route 2:
> AS_PATH 6 100
> MED 1
> NEXT_HOP NH2
> IGP cost to reach NH2 is 5
> 
> Route 3:
> AS_PATH 6 100
> MED 0
> NEXT_HOP NH3
> IGP cost to reach NH3 is 12
> 
> Now this router starts running its decision process. I want to know if the final outcome of
the
> Decision Process depends upon the order in which the paths are processed.
> 
> Case 1: If the receiving router processes Paths 1,2 and 3 respectively in this order.
> 
> From 1 and 2 it will not compare the MEDs as they are from different ASes. Hence it looks at
the
> IGP cost which is less in case of 2. It thus selects Path 2 and discards 1.
> 
> Next it picks up 3. Here the AS is the same and hence compares the MED - and thus selects as
Path
> 3 as the best one and uses this and this is the route which is propogated to everyone else.
> 
> Case II:
> It processes as paths 2,3 and 1 respectively.
> 
> From 2 and 3 it compares the MED as they are from same AS. It selects 3 as the MED is small.
Next
> it compares this with 1 and selects the latter as the IGP cost to reach the NH is smaller
there
> (6<12).
> 
> Thus it now arrives at a different best path!!!
> 
> Please let me know if i am correct in my understanding.
> 
> Would appreciate the comments from the routing fraternity.
> 
> Thanks
> Rasputin.

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Date: Tue, 17 Jun 2003 14:14:16 -0400
From: Mathew Richardson <[email-masked]>
To: [email-masked]
Subject: Re: Traditional NLRI not present in UPDATE -- 1771bis and 2858
Sender: [email-masked]

> Howard C. Berkowitz <[email-masked]> [Sun, Jun 15, 2003 at 12:06:38PM -0400]:

<snip>

>Am I missing it, or is there no explicit statement that an UPDATE 
>need not contain NLRI?

I don't believe there is an explicit statement that the NLRI field is
optional.  In fact, there appears to be at least one sentence that
implies the opposite:

	Reachability information is encoded as one or more 2-tuples of
	the form <length, prefix>, whose fields are described below:

This should probably read:

	Reachability information is encoded as zero or more 2-tuples of
	the form <length, prefix>, whose fields are described below:

Which makes explicit the fact that NLRI does not need to be included.

mrr

Date: Sun, 15 Jun 2003 12:06:38 -0400
From: "Howard C. Berkowitz" <[email-masked]>
Subject: Traditional NLRI not present in UPDATE -- 1771bis and 2858
To: [email-masked]
Sender: [email-masked]

This is one of those things where I'm feeling that I can't read, that 
the specific point I'm questioning MUST be written down somewhere. 
Nevertheless, here's my question, the specific answer to which I'm 
not finding either in 2858 or Draft 20.

Section 5 of Draft 20 describes conditions on handling legitimate 
UPDATEs when no regular NLRI field is present, but the basic 
description of the UPDATE never says NLRI may not be present. This is 
different than the case where the NLRI field has a length of zero, 
which means it matched all addresses.  Otherwise, I'd say the zero 
length is appropriate to indicate that NLRI deliberately is not 
present.

Am I missing it, or is there no explicit statement that an UPDATE 
need not contain NLRI?

For example, if MULTI-REACH-NLRI is present as an attribute, I assume 
there is no utility to having anything in the regular NLRI field.

I am assuming that Section 4 of 2858 tells how the NLRI is encoded in 
the Type 16/17 attributes, not the NLRI at the end of the UPDATE.

To: [email-masked]
Cc: [email-masked]
Subject: draft-chen-bgp-avoid-transition-00.txt
Date: Thu, 12 Jun 2003 11:16:29 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, folks:
The following draft has been posted. Please let us know if you have
any comments.

Regards,  -- Enke

------- Forwarded Message

To: IETF-Announce: ;
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-chen-bgp-avoid-transition-00.txt
Date: Thu, 12 Jun 2003 07:18:34 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Avoid BGP Best Path Transition from One External to 
                          Another
	Author(s)	: E. Chen, S. Sangli
	Filename	: draft-chen-bgp-avoid-transition-00.txt
	Pages		: 5
	Date		: 2003-6-11
	
In this document we propose an algorithm that would help improve the
overall network stability by avoiding BGP best path transition from
one external to another (under certain conditions)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-00.txt

------- End of Forwarded Message

To: "Tom Petch" <[email-masked]>
Cc: "Alex Zinin" <[email-masked]>, "Yakov Rekhter" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: AD-review comments on draft-ietf-idr-bgp4-20 
Date: Tue, 10 Jun 2003 08:52:19 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Tom,

> Some nits below but chiefly, what happened to the comments on section
> 8, the section closest to my processing engine/heart?

Sue is going to respond to the comments on section 8.

Yakov.

To: "Tom Petch" <[email-masked]>
Cc: "Alex Zinin" <[email-masked]>, "Yakov Rekhter" <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: AD-review comments on draft-ietf-idr-bgp4-20 
Date: Thu, 05 Jun 2003 11:34:47 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <005e01c32b6e$3445ea60$0301a8c0@tom3>, "Tom Petch" writes:
> 
> And can we get ie do we need to cater for an AS_PATH consisting of
> AS_SEQUENCE
> AS_SET
> AS_SEQUENCE
> ?

We used to see AS_SEQUENCE AS_SET and other combinations are valid.
If an aggregator does create an AS_SET, then the route can be passed
along and an AS_SEQUENCE added to it.  I suppose if you got "a x y"
and "b x y" the AS_PATH "[a,b] x y" would be a valid aggregate,
although I don't know of anyone who does this.

On the left to right topic, where is AS path notation specified
(besides RPSL)?  I didn't find it in the CIDR RFCs.  If unspecified,
then we should get rid of references to leftmost or rightmost.

Curtis

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Alex Zinin" <[email-masked]>, "Yakov Rekhter" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: AD-review comments on draft-ietf-idr-bgp4-20 
Date: Thu, 5 Jun 2003 15:23:27 +0100
Sender: [email-masked]

Some nits below but chiefly, what happened to the comments on section
8, the section closest to my processing engine/heart?

Tom Petch
>>
>> > 5.1.2 AS_PATH
>> ...
>> >       b) When a given BGP speaker advertises the route to an
external
>> >       peer, then the advertising speaker updates the AS_PATH
attribute
>> >       as follows:
>> >
>> >          1) if the first path segment of the AS_PATH is of type
>> >          AS_SEQUENCE, the local system prepends its own AS number
as the
>> >          last element of the sequence (put it in the leftmost
position).
>>
>> 'Leftmost position'... isn't this still open for interpretation?
How
>> about wording this relative to the position of the octets in the
>> protocol message?
>
>I'll replace "the leftmost position" with "the leftmost position with
>respect to the position of octets in the protocol message".

I find this less clear - and I am never comfortable with left as I do
not know how well it translates in other cultures; I prefer a numeric
reference which I believe translates better.

But here, I see the problem arising from the use of first and last
without saying first or last what; first octet/AS number/path segment
encountered in decoding the packet? first prepend?  I think it is that
that needs fixing rather than left.
Also, while the order of AS within a path segment is said to be
significant, I see nothing about the order of the path segments
themselves which matters as much(in 4.3 perhaps)
And can we get ie do we need to cater for an AS_PATH consisting of
AS_SEQUENCE
AS_SET
AS_SEQUENCE
?

>> > 6. BGP Error Handling.
>> ...
>> >    The phrase "the BGP connection is closed" means that the TCP
connec-
>> >    tion has been closed, the associated Adj-RIB-In has been
cleared, and
>> >    that all resources for that BGP connection have been
deallocated.
>> >    Entries in the Loc-RIB associated with the remote peer are
marked as
>> >    invalid. The fact that the routes have become invalid is
passed to
>> >    other BGP peers before the routes are deleted from the system.
>>
>> What does "the fact is passed" mean? Should we instead say that
local
>> route recalculation happens and peers are sent either updated best
>> routes or withdrawals?
>
>How about the following replacement for the last sentence:
>
>   The local system recalculates its best routes for the destinations
>   of the routes marked as invalid, and advertises to its peers
either
>   withdraws for the routes marked as invalid, or the new best routes
>   before the invalid routes are deleted from the system.

I find this ambiguous.  Does it mean

The local system recalculates its best routes for the destinations of
the routes marked as invalid and -
before the invalid routes are deleted from the system - advertises to
its peers either the new best routes
or, if no route now exists, withdrawals for the routes marked as
invalid.

?

>> >    If the UPDATE message is received from an external peer, the
local
>> >    system MAY check whether the leftmost AS in the AS_PATH
attribute is
>>
>> Same comment about 'leftmost'... Maybe we should define this
somewhere
>> in the beginning of the spec?
>
>I will replace "the leftmost AS" with "the leftmost AS with
>respect to the position of octets in the protocol message".

as above

>
>> > 9.1.1 Phase 1: Calculation of Degree of Preference
>> ...
>> >       If the route is learned from an external peer, then the
local BGP
>> >       speaker computes the degree of preference based on
preconfigured
>> >       policy information. If the return value indicates that the
route
>> >       is ineligible, the route MAY NOT serve as an input to the
next
>> >       phase of route selection; otherwise the return value is
used as
>> >       the LOCAL_PREF value in any IBGP readvertisement.
>>
>> So, AFAIK, the major implementations do not follow this step
>> (calculating the degree of preference, and then announcing).
Instead,
>> implementations allow setting the LOCAL_PREF value locally, which
is
>> taken into consideration during the best path selection, and is
also
>> reannounced further.
>
>It is important to keep in mind that the whole section on the BGP
>decision process does *not* mean that an implementation must
implement
>it precisely as it is described in the spec, as long as the
implementation
>support the described functionality and its externally visible
behavior
>is the same. With this in mind how about if I'll add the following:
>
>   The BGP Decision Process in this document is conceptual and do

does
>   not have to be implemented precisely as described here, as long
>   as the implementations support the described functionality and
>   their externally visible behavior is the same.